Understanding the HP Serviceguard Extension for Oracle E-Business Suite (SGeEBS)

Configuring EBS for SGeEBS

SGeEBS is designed to avoid the need for custom modifications of EBS configuration files, application

code, or AutoConfig generate scripts. This will ensure that as future EBS configuration and patching

processes are carried out, no unexpected surprises are met.

SGeEBS uses standard EBS administration scripts to start, stop, and (where possible) check the status

of the database and applications tiers ensuring that all interaction with EBS is based on Oracle

provided standard and supported interfaces.

High-level EBS architecture

SGeEBS draws upon common and well established high availability architecture techniques for both

the EBS DB and APPS tier.

For the DB tier, we use the Serviceguard and Oracle database support for “virtual hostnames” thereby

enabling the database to be relocated from one server to the other without EBS configuration

changes. This method uses IP network aliases within HP-UX so that the database system always

appears to be bound at the same network address regardless of which physical server it happens to

be running on. Serviceguard manages the allocation and creation of the necessary networking

resources to allow this to happen automatically and the database configuration simply utilizes the

network address associated with the virtual hostname for connectivity. There is only one database

instance created for the EBS high availability environment and the internal EBS topology data mirrors

this view by having a single DB node defined which is identified by the virtual hostname.

For the APPS tier, a different mechanism from the “virtual hostname” approach is taken due to the

special needs of certain EBS application tier components that require binding to the underlying

server’s real hostname. Instead of using a virtual hostname, the Serviceguard integration topology

calls for multiple APPS tier instances with one instance defined at each physical node within the

cluster. Although there are multiple APPS tier instances defined, the design calls for only one to be

active at any point in time. The EBS definitions at every APPS tier node include all services that the

EBS system must support and are functionally the same for all nodes apart from the hostname used.

Thus, the EBS topology database will include a definition for each node in the Serviceguard cluster

and each EBS instance will use the underlying server’s hostname as its node identifier.

The Oracle EBS includes many features and capabilities that implementers may select to support

various business needs. Our approach in SGeEBS was to work with the common core technology

stack features (Web, forms, and concurrent manager).

EBS DB tier

High availability for the EBS database tier is achieved using the very same technique that many

standalone Oracle database implementations with Serviceguard have used in production for a

considerable time. Using re-locatable storage devices and a special “floating” IP network address, the

database can failover from one physical server to another within the Serviceguard cluster while

retaining the same outward appearance to applications.

From a network communications point of view, the Oracle database is not configured to bind to the

network address associated with the actual physical server but rather to a specially-reserved “floating”

IP address. This floating IP address, called in Serviceguard terms the package IP, is an IP alias that is

mapped to one of the real underlying network interfaces. The floating IP address is one that is defined

for exclusive use by the database as its networking end point and is normally included in the Domain

Name Service so that the database can be located by its applications. The symbolic name that is

associated with the floating IP address is the “virtual hostname” and it is this name that will be used

as the database’s hostname within the EBS topology configuration.