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

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.
Option 1: Simple Clusters with Separated Packages
Cluster Layout Constraints:
• The liveCache package does not share a failover node with the APO Central Instance package.
• There is no MAXDB or additional liveCache running on cluster nodes.
Planning the Volume Manager Setup 111