Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

Figure 1-1 Two-Package Failover with Mutual Backup Scenario
A Serviceguard package is a description of resources such as file system, storage volumes or network
addresses and commands for starting, stopping or monitoring an application within a Serviceguard cluster.
Each SGeSAP/LX package name should include the SAP System Identifier (SID) of the system to which the
package belongs.
It is strongly recommended to base the package naming on the naming conventions for the SGeSAP/LX
package type. This should be done by prefixing the package type to the SID to get the package name. This
allows easy identification and support.
Robust Failover Using the One Package Concept
In a one-package configuration, both the database (db) and Central Instance (ci) run on the same node at
all times and are configured in one Serviceguard Extension for SAP on Linux package. Other nodes in the
Serviceguard cluster function as failover nodes for the primary node on which the system runs during normal
operation.
The naming convention for this package is (dbci<SID>)for an ABAP configuration and dbjci for a JAVA
configuration.
It is a good practice to keep a cluster setup as simple as possible. Less number of packages can easily be
monitored. If database and Central Instance get combined in a single package, this can save administration
overhead.
Serviceguard Extension for SAP on Linux allows utilizing the secondary node(s) with different instances during
normal operation. Therefore it is not required to maintain an expensive idle standby node. 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 Serviceguard Extension
for SAP on Linux during failover to free up the computing resources for the critical production system.
Development environments tend to be less stable than production systems. This should be taken into
consideration before mixing these 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
Designing Serviceguard Extension for SAP on Linux Cluster Scenarios 15