There is no hard requirement on how far the third location has
to be from the two main data centers. The third location can be as
close as the room next door with its own power source or can be as
far as in another site across town. The distance between all three
locations dictates that level of disaster tolerance a cluster can
provide.
A two data center and third location have the following configuration
requirements:
The third location, also known as the Arbitrator data
center, can contain either Arbitrator nodes or a Quorum Server node.
If Arbitrator nodes are used there must be an equal
number of nodes (1–7) in each Primary data center, and the
third location can contain one or two Arbitrator nodes. The Arbitrator
nodes are standard Serviceguard nodes configured in the cluster, however,
they are not allowed to be connected to the shared disks in either
of the Primary data centers. Arbitrator nodes are used as tie breakers
to maintain cluster quorum when all communication between the two
Primary data centers is lost. The data center containing the Arbitrator
Nodes must be located separately from the nodes in the Primary data
centers. If the Primary data centers each contain a single node,
then only one Arbitrator node is allowed. Cluster lock disks are not
supported in this configuration. Arbitrator nodes are not supported
if CVM or CFS is used in the cluster.
If a Quorum Server node is used, there must be an
equal number or nodes (1–8) in each Primary data center. The
third location can contain a single Serviceguard Quorum Server node
(running HP UX or Linux), with a separate power circuit. The Quorum
Server does not have to be on the same subnet as the cluster nodes,
but network routing must be configured such that all nodes in the
cluster can contact the Quorum Server via separate physical routes.
Prior to Quorum Server A.03.00 only one IP address could be configured
for a Quorum Server, so it is suggested to make the Quorum Server
more highly available by running it in it’s own Serviceguard
cluster, or to configure the LAN used for the Quorum Server IP address
with at least two LAN interface cards using APA (Automatic Port Aggregation) LAN_MONITOR mode to improve the availability if a LAN
failure occurs. Beginning with Quorum Server revision A.03.00, cluster
nodes can communicate with the Quorum Server on a primary and an alternate
subnet, for improved tolerance to network failures between the Quorum
Server and the cluster nodes. This functionality is supported in Serviceguard
A.11.17 on HP UX 11i v2, with the patch PHSS_35427 or later and with
Serviceguard A.11.18 and the patches, PHSS_36997 or later (11i v2)
or PHSS_36998 or later (11i v3). In addition, for Serviceguard A.11.17
you will need to apply the Cluster Object Manager (COM) patch PHSS_35372
or later, in order to use Serviceguard Manager to manage a cluster
that uses more than one subnet for communication with the Quorum Server.
 |
| |
|
 | NOTE: Prior to Quorum Server revision A.02.00, it was not supported
to run the Quorum Server in a Serviceguard cluster. |
|
| |
|
No routing is allowed for the networks between the
data centers, except in Cross-Subnet configurations. Routing is allowed
to the third location if a Quorum Server is used in that site
MirrorDisk/UX mirroring for LVM and VxVM mirroring
is supported for clusters of up to 16 nodes.
CVM 3.5, 4.1 or 5.0 mirroring is supported for Serviceguard
and EC RAC clusters containing 2, 4, 6 or 8 nodes. In CVM and CFS
configurations, Arbitrator nodes are not supported, and a Quorum Server
node must be used instead.
MirrorDisk/UX mirroring for Shared LVM volume groups
is supported for EC RAC clusters containing 2 nodes.
|
| |
|
| NOTE: For the most up-to-date support and compatibility information
see the SGeRAC for SLVM, CVM & CFS Matrix and Serviceguard
Compatibility and Feature Matrix on http://docs.hp.com-> High Availability -> Serviceguard Extension for Real Application
Cluster (ServiceGuard OPS Edition) -> Support Matrixes |
|
| |
|
The following table shows the possible configurations using
a three data center architecture.
Table 2-5 Supported System and Data Center Combinations
| Data Center A | Data Center B | Data Center C |
|---|
| 1 | 1 | 1 Arbitrator Node |
1 | 1 | Quorum
Server System |
1 | 1 | Quorum
Server System |
2 | 1 | 2 Arbitrator Nodes |
| 1 | 2 | 2 Arbitrator Nodes |
| 2 | 2 | 1 Arbitrator Node |
| 2 | 2 | 2* Arbitrator Nodes |
2 | 2 | Quorum Server System |
| 3 | 3 | 1 Arbitrator Node |
| 3 | 3 | 2* Arbitrator Nodes |
3 | 3 | Quorum Server System |
| 4 | 4 | 1 Arbitrator Node |
| 4 | 4 | 2* Arbitrator Nodes |
4 | 4 | Quorum Server System |
| 5 | 5 | 1 Arbitrator Node |
| 5 | 5 | 2* Arbitrator Nodes |
5 | 5 | Quorum Server System |
| 6 | 6 | 1 Arbitrator Node |
| 6 | 6 | 2* Arbitrator Nodes |
6 | 6 | Quorum Server System |
| 7 | 7 | 1 Arbitrator Node |
| 7 | 7 | 2* Arbitrator Nodes |
7 | 7 | Quorum Server System |
8 | 8 | Quorum Server System |
* Configurations with two arbitrators are preferred because
they provide a greater degree of availability, especially in cases
when a node is down due to a failure or planned maintenance. It is
highly recommended that two arbitrators be configured in Data Center
C to allow for planned downtime in Data Centers A and B.
|
| |
|
| NOTE: Serviceguard Extension for RAC clusters are limited to 2, 4,
6, or 8 nodes. |
|
| |
|
The following is a list of recommended arbitration methods for
Extended Distance Clusters in order of preference:
2 arbitrator nodes, where supported
1 arbitrator node, where supported
Quorum Server running in a Serviceguard cluster
For more information on Quorum Server, refer to the Serviceguard Quorum Server Version Release Notes for HP-UX located at http://docs.hp.com —> High
Availability —> Quorum Server.
Figure 2-2 is an example
of a two data center and third location configuration using WDM, with
arbitrator nodes in the third location.
Figure 2-3 is an example
of a two data center and third location configuration using WDM, with
a quorum server node on the third site and is specifically for a SGeRAC
cluster. The WDM boxes connected between the two Primary Data Centers
are configured with redundant dark fibre links and the standby fibre
feature has been enabled.
Note that there is a separate network (indicated by the lines
to switches #3 and #4) being used for the RAC Cache Fusion traffic
to ensure good RAC performance. Switches #2 and #5 are used for the
Standby network, which can provide local LAN failover for both the
Primary Heartbeat network and the Primary RAC Cache Fusion network.
However it must be noted that the Standby network can only provide
local failover capability for one of the Primary networks at a time.
For that reason, it is preferable to have a separate Standby network
for the Heartbeat network and for the RAC Cache Fusion network.
There are no requirements for the distance between the Quorum
Server Data center and the Primary Data Centers, however it is necessary
to ensure that the Quorum Server can be contacted within a reasonable
amount of time (should be within the NODE_TIMEOUT period). Cluster
lock disks are not allowed in this configuration. There can be 2,
4, 6, or 8 nodes in this cluster if CVM 3.5 is used and the distance
is 10 kilometers or less. However, there can be only 2 nodes in this
cluster if CVM is used, the distance is 100 kilometers and if shared
LVM is used.
Since there are 4 nodes shown in this example cluster, this
means that this cluster can only use CVM as the volume manager, and
the distance between the Primary data centers cannot exceed 10 kilometers.
Printable version
