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

The hot standby mechanism also includes data replication. The standby maintains its own set of
liveCache data on storage at all times.
SGeSAP provides a runtime library to liveCache that allows to automatically create a valid local
set of liveCache devspace data via Storageworks XP Business Copy volume pairs (pvol/svol BCVs)
as part of the standby startup. If required, the master liveCache can remain running during this
operation. The copy utilizes fast storage replication mechanisms within the storage array hardware
to keep the effect on the running master liveCache minimal. Once the volume pairs are synchronized,
they get split up immediately. During normal operation, each of the two liveCache instances
operates on a set of LUNs in SIMPLEX state.
The detection of volumes that need replication as part of the standby startup is dynamically identified
within the startup procedure of the standby. It does not require manual maintenance steps to trigger
volume pair synchronizations and subsequent split operations. Usually, synchronizations occur
only in rare cases, for example, for the first startup of a standby or if a standby got intentionally
shut down for a longer period of time. In all other cases, the liveCache logging devspaces will
contain enough delta information to update the standby data without the requirement to do hardware
replications of full LUNs.
The ongoing operation of the standby as well as the master failover does not require the business
copy mechanisms. The standby synchronizes the data regularly by accessing the master log files,
which therefore reside on CVM/CFS volumes. No liveCache content data needs to be transferred
via LAN at any point in time.
The liveCache logging gets continuously verified during operation. An invalid entry in the log files
gets detected immediately. This avoids the hazardous situation of not becoming aware of corrupted
log files until they fail to restore a production liveCache instance.
During operation of the liveCache master, a data storage corruption could happen at the physical
level. As the liveCache standby is synchronized with the master at a logical level and not at a
physical level, the corruption will not get replicated to standby. The standby LUNs used for devspace
content do not necessarily keep the same data as the master LUNs. At least not on a physical level.
But logically the standby keeps consistency and stays close to the content of the master LUNs. The
standby can then be promoted to become the new master immediately. With access to the original
log of the master, it is able to update itself without any data loss.
Planning the Volume Manager Setup
In the following, the lc package of SGeSAP gets described. The lc package was developed
according to the SAP recommendations and fulfills all SAP requirements for liveCache failover
solutions.
liveCache distinguishes an instance dependant path /sapdb/<LCSID> and two instance
independent paths IndepData and IndepPrograms. By default all three point to a directory
below /sapdb.
NOTE: <LCSID> denotes the three-letter database name of the liveCache instance in uppercase.
<lcsid> is the same name in lowercase.
There are different configuration options for the storage layout and the filesystems caused by a
trade-off between simplicity and flexibility. The options are described below ordered by increasing
complexity. The cluster layout constraints that need to be fulfilled to allow the simplifications of a
given option are stated within a bullet list.
The subsequent sections refer to the options by the numbers that are introduced here.
120 SAP Supply Chain Management