Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), February 2008

Understanding Serviceguard Extension for SAP on Linux
Designing Serviceguard Extension for SAP on Linux Cluster Scenarios
Chapter 1 15
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 (dbciSID).
It is a good practice to keep a cluster setup as simple as possible. Less
packages need less system resources and can easily be monitored. If
database and Central Instance get combined in a single package, this can
save administration overhead.
It is not required to maintain an expensive idle standby. Serviceguard
Extension for SAP on Linux allows utilizing 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 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 be restarted triggered by a failover.
A sample configuration in Figure 1-3 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.
NOTE A J2EE Engine might be part of the Central Instance. The JAVA
instance will then be moved with the package automatically.