Managing Serviceguard Extension for SAP Version B.05.10, September 2010
and virtualization by reading the Serviceguard product manual, Managing Serviceguard, at
www.hp.com/go/hpux-serviceguard-docs —> HP Serviceguard —> User guide.
Serviceguard packages can be distinguished into legacy packages and module-based packages.
SGeSAP provides solutions for both approaches. SGeSAP consists of several SAP-related modules,
legacy script templates, SAP software service monitors as well as specialized additional features
to integrate hot standby liveCache scenarios, HP Workload Management scenarios, and HP
Event Monitors.
There are three major Serviceguard modules delivered with SGeSAP. For the standard SAP
Netweaver web application server stack, it provides a Serviceguard module called
sgesap/sapinstance. This module can be used to easily add a set of SAP instances that belong
to the same Netweaver-based system to a module-based Serviceguard package. The package
can encapsulate the failover entity for a combination of ABAP-stack, JAVA-stack and dual-stack
instances, and optionally Central Service Instances or Enqueue Replication Service Instances of
an SAP System. For MAXDB or Oracle-based SAP database services, the module
sgesap/dbinstance can be used. The module to cluster SAP liveCache instances is called
sgesap/livecache. In addition to these three major modules, there are two more modules
that enable easy clustering of smaller SAP infrastructure software tools sgesap/sapinfra and
allow to manipulate the behavior of non-clustered SAP instances sgesap/sapextinstance.
The covered infrastructure tools include the SAP sapccmsr, saposcol, rfcadapter and
saprouter binaries. Other SGeSAP module names exist that provide a combination or subset
of the functionality of some of the five modules mentioned above. They were primarily defined
for convenience reasons to simplify configuration steps for standard use cases.
In legacy packaging, each software Single Point of Failure defines a SGeSAP package type.
SGeSAP follows a consistent naming convention for these package types. The naming conventions
were created to be independent of SAP software release versions. This provides a similar approach
for each SPOF, regardless of whether it appears in the latest SAP Netweaver stack or SAP software
that was released before the first design of SAP Application Server. Older SAP components
sometimes only support a subset of the available clustering options.
Defining a mixture of legacy packages and module-based packages is possible in the same cluster.
MDM 5.5 packages are available in legacy-style packages only. All legacy-style packages will be
discontinued at a later point in time.
Table 1-1 Mapping the SGeSAP legacy package types to SGeSAP modules and different SAP naming
conventions
Commonly used SAP instance namesSGeSAP module namesSGeSAP legacy package type
DVEBMGS (as Central Instance), ASCS
sgesap/sapinstance
alternatives: sgesap/scs
sgesap/ci
ci
SCSjci
AREP, ENR, ERS
sgesap/sapinstance
alternatives: sgesap/ers
arep
REP, ENR, ERSrep
D, DVEBMGS (new)
sgesap/sapinstance
d
JDI, JD, JC, Jjd
sgesap/dbinstance
alternatives:sgesap/db
sgesap/maxdb sgesap/oracledb
db
sgesap/livecache
lc
Mutual Failover Scenarios Using the Two Package Concept
Most SAP applications rely on two central software services that define the major software Single
Point of Failure (SPOF) for SAP environments: the SAP Enqueue Service and the SAP Message
12 Designing SGeSAP Cluster Scenarios