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

Having a single shared storage area for APPS tier filesystem and instance-specific information can be

particularly useful should an EBS instance fail for some unexpected reason. When a failure occurs,

Serviceguard will automatically execute a failover of the APPS tier to the alternate node which

includes moving the shared storage from the failed server to the operational system. Within the shared

storage the instance-specific files for the failed EBS instance are now accessible on the operational

system and so problem determination and root cause analysis of the original failure can be

investigated.

For continentalcluster environment, it is recommended that, each APPS tier server house their instance-

specific information locally and APPS tier filesystem in the shared storage.

EBS APPS tier configuration

At each node in the cluster, an EBS APPS tier instance is defined either through the initial RapidInstall

process for the first server or via the standard cloning process for the second server. When building

the applications tier configurations the underlying physical server’s hostname is used so that each

instance definition is tied to that specific server node. This will produce multiple AutoConfig

configuration files (one for each node in the cluster) as well as several node-specific directories in the

instance-specific file system hierarchy.

Further details of available capabilities and options in sharing an Applications tier file system can be

found in My Oracle Support Knowledge Document 384248.1, sharing the Application Tier.

For details of the latest Rapid Clone patches and general usage of the tool, see My Oracle Support

Knowledge Document 406982.1 Cloning Oracle Applications Release 12 with Rapid Clone.

It is clearly unacceptable for end users to have to know that there are two possible URLs at which they

might find an active instance of the EBS system (which might be assumed to be the case with the

current configuration). To simplify access, SGeEBS configuration allows end users to connect via a

symbolic hostname. This symbolic hostname needs to be associated with a floating IP address

(Serviceguard package IP) and will be automatically activated in the currently active APPS instance.

The floating IP address is one that is defined for exclusive use by the APPS as its networking end point

and is normally included in the Domain Name Service.

Since users always connect to the EBS implementation using the symbolic hostname, they do not need

to know which APPS systems is currently active or inactive.

From an EBS configuration point of view, this capability is enabled by setting the Web entry point

and external URL parameters within the EBS APPS tier configuration. They are set so that instead of

pointing to their default value which uses the local system name they are assigned to the symbolic

hostname that was chosen for the APPS tier in the cluster.

Further details on configuring for an external entry point can be found in Oracle Metalink note

380489.1.

For example, using the configuration shown in Figure 1, the Web entry point and external URLs for

node sg-serv2 would be changed from containing sg-serv2 to ebsapps.