What is a Metropolitan Cluster? |
 |
A MetroCluster is one of HP's Disaster Tolerant solution.
Two types of Metropolitan Cluster are provided, depending on the
type of data storage and replication you are using. You will need
MetroCluster with Continuous Access CA or MetroCluster EMC Symmetrix
Remote Data Facility SRDF if you want to secure an application whose
data is on an HP-XP array or an EMC Symmetrix ICDA which data is
replicated to a second HP-XP array or EMC Symmetrix ICDA using Continuous
Access (CA) or Symmetrix Remote Data Facility (SRDF).
Beginning with SGeSAP 3.05, ServiceGuard 11.13, MetroCluster
3.0 and HA-NFS 1.1, the integration of all four products is possible
without any change of the standard MC/ServiceGuard control files.
The ServiceGuard 11.13 control file version now has a call out function
to MetroCluster embedded.
MetroCluster: Cluster Architecture Constraints |
|
All host systems in a MetroCluster environment must be members
of a single MC/ServiceGuard cluster.
Either a single Data Center architecture without an arbitrator
or a Three Data Center architecture with one or two arbitrator systems
can be implemented. The arbitrator(s) are not physically connected
to the storage units. In a three data center architecture, no cluster
lock device is used since it does not work across the ESCON link.
Three hosts are allowed for each data center. In a campus
environment, the same number of systems must be present in each
of the two data centers whose systems are connected to the storage
units.
The ESCON fibre that realizes the dual ESCON links between
the ICDAs can extend to 40km.
Combining MetroCluster and SGeSAP |
|
Beginning with SGeSAP 3.05, ServiceGuard 11.13, MetroCluster
3.0 and HA NFS 1.1, the integration of all four product is possible
without any change of standard control files. The ServiceGuard 11.13
control file version has a call out function to MetroCuster embedded.
The standard ServiceGuard 11.13 package control file controls
the runtime steps during a package setup. Before the SGeSAP specific
logic step is started within the customer_defined_runcommands section, the package control file has hooks embedded
for MetroCluster and HA NFS specific runtime steps. This allows
a smooth integration of all products (ServiceGuard, MetroCluster,
HA-NFS and SGeSAP) that are needed to run a SAP Application in a
disaster tolerant environment.
The following example shows how this is technically realized:
verify_physical_data_replication: This
function checks the availability of a file called "DRCheckDiskStatus". If the file exists, the MetroCluster specific runtime
steps will be executed.
verify_ha_nfs $1: This function
checks the availability of the $HA_NFS_SCRIPT file that is defined
in the controlfile. In SGeSAP environments the convention is that
these files are to be called "hanfs.db" for the two package SGeSAP
concept and "hanfs.dbci" for the one package SGeSAP concept. If this file exists,
the HA-NFS specific runtime steps will be executed.
customer_defined_run_cmds: This
function is used to call the SGeSAP specific runtime steps. It is
required to add the script that has to be called appropriately.
In SGeSAP environment this script is called "sapdbci.cntl for the
one package SGeSAP concept and "sapdb.cntl" / "sapci.cntl" for he two package concept. More details
can be found in Chapter 2 “Step by Step Installation Guide” of this manual.
All other implementation steps in regards to MetroCluster,
HA NFS and SGeSAP are standard and have to be performed according
to the standard documentation. Refer to Designing Disaster
Tolerant HA Clusters for complete details.
A MetroCluster environment may increase package startup time significantly.
Packages with many disk devices will take longer to start up than
those with fewer devices due to the time needed to get device status
from the XP / Symmetrix array. Clusters with multiple packages that
use devices on the XP / Symmetrix will cause package startup time to
increase when more than one package is starting at the same time. You
have to add the time needed to restart all attached R/3 application servers
to get an estimation of the total package startup time. It is strongly
recommended to disable the timeout mechanism of MC/ServiceGuard
that monitors the switchover.
If you are planning to control additional SAP application
servers out of the SAP SG packages, an analysis of the physical
machine environment for the APP-servers is required. In disaster
tolerant configurations it is required to run the complete SAP production,
including all the SAP application servers in the primary DC and
fail it over completely to the secondary DC in case of a disaster.
This requires changes in the APP-server configuration within the
SGeSAP environment. You need a sap.conf for the primary DC and a sap.conf file for the secondary DC. Refer to chapter 2 of this
documentation to get more details on APP-server configuration within
the SGeSAP environment.
It is required to follow all configuration steps that are
referenced in the MetroCluster and HA-NFS documentation. These documents
can be found at http://docs.hp.com/hpux/ha/index.html.
Printable version
