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

NOTE: For installation steps in this chapter that require the adjustment of SAP specific parameter
in order to run the SAP application in a switchover environment usually example values are
given. These values are for reference ONLY and it is recommended to read and follow the
appropriate SAP OSS notes for SAP's latest recommendation. Whenever possible the SAP OSS
note number is given.
More About Hot Standby
A fatal liveCache failure concludes in a restart attempt of the liveCache instance. This will take
place either locally or, as part of a cluster failover, on a remote node. It is a key aspect here, that
liveCache is an in-memory database technology. While the bare instance restart as such is quick,
the reload of the liveCache in-memory content can take a significant amount of time, depending
on the size of the liveCache data spaces. Modern Supply Chain Management (SCM) business
scenarios cannot afford unplanned loss of liveCache functionality for the span of time that it
takes to reload the liveCache after failover. The situation becomes worse, since a restarted
liveCache requires additional runtime to gain back its full performance. In many cases, systems
that are connected to the liveCache can't continue with the information exchange and the outbound
queues run full. The communication gets stuck until a manual restart of the queues is triggered.
The requirement to enable even the most mission- and time-critical use-cases of SCM triggered
the introduction of the hot standby liveCache system (hss). Refer ti figure 4-1.
Figure 4-1 Hot Standby liveCache
A hot standby liveCache is a second liveCache instance that runs with the same System ID as
the original master liveCache. It will be waiting on the secondary node of the cluster during
normal operation. A failover of the liveCache cluster package does not require any time consuming
filesystem move operations or instance restarts. The hot standby simply gets notified to promote
itself to become the new master. The Serviceguard cluster software will make sure that the
primary system is shut down already in order to prevent a split-brain situation in which two
liveCache systems try to serve the same purpose. Thus, a hot standby scenario provides extremely
fast and reliable failover. The delay caused by a failover becomes predictable and tunable. No
liveCache data inconsistencies can occur during failover.
The hot standby mechanism also includes data replication. The standby maintains its own set
of liveCache data on storage at all times.
110 SAP Supply Chain Management