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

In Figure 1 as an example, we see that the database can either run on server sg-serv1 or server

sg-serv2. However, the database listener is not configured to bind to either the sg-serv1 or sg-serv2

network endpoints, but rather to the alias of “ebsdatabase” which is the associated virtual hostname

for the database. It is this “ebsdatabase” alias which is mapped to the floating IP alias address that

Serviceguard will manage during the database Serviceguard package startup.

As Serviceguard brings up the environment for the database to run on sg-serv1, part of its package

initialization process is to provision the floating IP address so that the database can bind to the

“ebsdatabase” network alias. During normal operations, if a complete server failure occurs for

sg-serv1, then Serviceguard detects this condition and starts the failover process to sg-serv2. During

failover, the floating IP alias address is relocated by Serviceguard to node sg-serv2 ready for the

database to bind to once again.

From the APPS tier’s point of view, the database failover from one machine to the other does not alter

the single network end point at which it connect for service. As there is no change in the networking

end point, no special reconfiguration of applications is required to handle the database failover

sequence.

Much of the process of setting up the virtual hostname environment for the database tier is automated

during the installation process by using the –servername flag with the RapidInstall EBS Installer

command. Details on this command option can be found in the Oracle Applications Release 12

installation guide.

As an example, for the configuration shown in Figure 1, the RapidInstall command used to install the

database tier was started with the –servername ebsdatabase command line option. This installed the

database product components, built the appropriate configuration files and file system directory

layout automatically and used the virtual hostname ebsdatabase in place of the actual server

hostname on which the install was run.

EBS APPS tier

The HP approach for configuring the APPS tier within the Serviceguard cluster draws upon the

standard EBS implementation technique of defining application services over multiple servers so that

any active node can process user workload.

Applications tier instance with a single APPL_TOP and INST_TOP

SGeEBS design uses the concept of sharing the APPS tier filesystem by multiple APPS tier servers. The

EBS APPS tier filesystem should be housed in the shared disk storage that can be shared by multiple

instance-specific information defined for each APPS tier servers in the cluster. The instance-specific

filesystem can be housed locally in the respective servers or it can be installed in the shared storage.

During the APPS tier startup process, the storage is automatically relocated by Serviceguard to be

accessible on the active APPS tier server and is mounted at standard file system mount points ready

for EBS initialization to begin.

Advantages of housing instance-specific information in the shared storage

Regardless of which server the applications tier is currently running on, the instance-specific

information for that and the inactive server is accessible within the shared file system. This allows

reports, logs, and output files for both the currently active and the inactive servers in the cluster to be

available, if required.