Managing Serviceguard Extension for SAP Version B.05.10, December 2012

Serviceguard are already installed properly on all cluster hosts. Sometimes a condition is specified
with the installation step. Follow the information presented only if the condition is true for your
situation.
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 15 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.
More About Hot Standby 119