Managing Serviceguard Extension for SAP Version B.05.10, September 2010

It is a best practice to base the package naming on the SAP instance naming conventions whenever
possible. Each package name should also include the SAP System Identifier (SID) of the system
to which the package belongs. If similar packages of the same type get added later, they have a
distinct namespace because they have a different SID.
Example: A simple mutual failover scenario for an ABAP application defines two packages,
called dbSID and ascsSID (or ciSID for old SAP releases).
Robust Failover Using the One Package Concept
In a one-package configuration, the database, NFS and SAP SPOFs run on the same node at all
times and are configured in one SGeSAP package. Other nodes in the Serviceguard cluster
function as failover nodes for the primary node on which the system runs during normal
operation.
NOTE: Module-based SGeSAP packages cannot be combined with a legacy based NFS toolkit
to create a single package.
It is not required to maintain an expensive idle standby. SGeSAP allows to utilize the secondary
node(s) with different instances during normal operation. A common setup installs one or more
non-mission critical SAP Systems on the failover nodes, typically SAP Consolidation, Quality
Assurance, or Development Systems. They can gracefully be shutdown by SGeSAP during
failover to free up the computing resources for the critical production system. For modular
packages, the sgesap/sapextinstance module can be added to the package to allow specifying
this kind of behavior.
Development environments tend to be less stable than production systems. This should be taken
into consideration before mixing these use-cases in a single cluster. A feasible alternative would
be to install Dialog Instances of the production system on the failover node.
If the primary node fails, the database and the Central Instance fail over and continue functioning
on an adoptive node. After failover, the system runs without any manual intervention needed.
All redundant Application Servers and Dialog Instances, even those that are not part of the
cluster, can either stay up or be restarted triggered by a failover. A sample configuration in Figure
1-2 shows node1 with a failure, which causes the package containing the database and central
instance to fail over to node2. A Quality Assurance System and additional Dialog Instances get
shut down, before the database and Central Instance are restarted.
Robust Failover Using the One Package Concept 15