< Previous  | TOC | Index | Next  >

Configuring global clustering

Review the requirements for global clustering:

  Cluster names on the primary and secondary sites must be unique.

  Node and resource names must be unique within a cluster but not across clusters.

  Each cluster requires a virtual IP address associated with the cluster. The VCS installation and creation of the ClusterService group typically involves defining this IP address. If you did not configure the ClusterService group when you installed Storage Foundation, configure it when you configure global clustering.

  One WAN (Wide Area Network) heartbeat must travel between clusters, assuming each cluster has the means to monitor the health of the remote cluster. Configure the heartbeat resource manually.

  All oracle s must be the same on all nodes.

  The Oracle database, which VVR replicates from the storage on the primary site to the secondary site, must be defined in a global group having the same name on each cluster. Each resource in the group may differ from cluster to cluster, but clients redirected to a remote cluster after a wide-area failover must see the same application as the one in the primary cluster.

You can modify the global clustering configuration using the following methods:

• global clustering wizard
• manual modification of the main.cf file

The global clustering wizard results is generally more accurate for basic configurations. The manual modification method provides greater opportunity for customazation but also greater opportunity for errors.

See the Veritas Cluster Server User's Guide for complete details on global clustering.

Modifying the global clustering configuration using the wizard

The global clustering wizard completes the following tasks:

• Validates the ability of the current configuration to support a global cluster environment.
• Creates the components that enable the separate clusters, each of which contains a different set of GAB memberships, to connect and operate as a single unit.
• Creates the ClusterService group, or updates an existing ClusterService group.

Run the global clustering configuration wizard on each of the clusters; you must have the global clustering license in place on each node in the cluster.

 To use the global clustering wizard

1. On a node in the primary site, start the global clustering configuration wizard:

   # /opt/VRTSvcs/bin/gcoconfig

2. After discovering the NIC devices on the local node, specify or confirm the device for the cluster joining the global cluster environment.
3. Indicate whether the NIC you entered is for all cluster nodes. If you enter n, enter the names of NICs on each node.
4. Enter or confirm the virtual IP address for the local cluster.
5. When the wizard discovers the net mask associated with the virtual IP address, accept the discovered value or enter another value.

   With NIC and IP address values configured, the wizard creates a ClusterService group or updates an existing one. After modifying the VCS configuration file, the wizard brings the group online.

6. Perform through step 1 through step 5 on the secondary cluster.

Modifying the global clustering configuration using the main.cf

After you run the global clustering configuration wizard, the modifications to the main.cf file typically involve specifying the virtual IP address for the local cluster and defining the ClusterService group for the local cluster.

The example global clustering configuration shows the rac_cluster101 cluster on the primary site. The additions to the configuration appear in bold text. Use the example as guidelines to add a cluster service group to main.cf.

include "types.cf"

include "CFSTypes.cf"

include "CVMTypes.cf"

include "OracleTypes.cf"

include "VVRTypes.cf"

cluster rac_cluster101 (

UserNames = { admin = "cDRpdxPmHpzS." }

ClusterAddress = "10.10.10.101"

Administrators = { admin }

CounterInterval = 5

UseFence = SCSI3

)

system galaxy (

)

system nebula (

)

group ClusterService (

SystemList = { galaxy = 0, nebula = 0 }

AutoStartList = { galaxy, nebula }

OnlineRetryLimit = 3

OnlineRetryInterval = 120

)

Application wac (

StartProgram = "/opt/VRTSvcs/bin/wacstart"

StopProgram = "/opt/VRTSvcs/bin/wacstop"

MonitorProcesses = "/opt/VRTSvcs/bin/wac" }

RestartLimit = 3

)

IP gcoip (

Device =hme0

Address = "10.10.10.101"

NetMask = "255.255.240.0"

)

NIC csgnic (

Device =hme0

)

gcoip requires csgnic

wac requires gcoip

.

.

.

group cvm (

.

.

.

After using the global clustering wizard, the main.cf for the secondary site has a similar configuration to the one above.

Defining the remote cluster and heartbeat Cluster Objects

After configuring global clustering, add the remotecluster cluster object to define the IP address of the cluster on the secondary site, and the heartbeat object to define the cluster-to-cluster heartbeat.

Heartbeats monitor the health of remote clusters. VCS can communicate with the remote cluster only after you set up the heartbeat resource on both clusters.

 To define the remote cluster and heartbeat

1. On the primary site, enable write access to the configuration:

   # haconf -makerw

2. Define the remotecluster and its virtual IP address. In this example, the remote cluster is rac_cluster102 and its IP address is 10.11.10.102:

   # haclus -add rac_cluster102 10.11.10.102

3. Complete step 1 and step 2 on the secondary site using the name and IP address of the primary cluster (rac_cluster101 and 10.10.10.101).
4. On the primary site, add the heartbeat object for the cluster. In this example, the heartbeat method is ICMP ping.

   # hahb -add Icmp

5. Define the following attributes for the heartbeat resource:
   • ClusterList lists the remote cluster.
   • Arguments enables you to define the virtual IP address for the remote cluster.

     For example:

     # hahb -modify Icmp ClusterList rac_cluster102

     # hahb -modify Icmp Arguments 10.11.10.102 -clus rac_cluster102

6. Save the configuration and change the access to read-only on the local cluster:

   # haconf -dump -makero

7. Complete step 4 through step 6 on the secondary site using appropriate values to define the cluster on the primary site and its IP as the remote cluster for the secondary cluster.
8. Verify clusters in the global setup by executing haclus -list command.

   # haclus -list

   rac_cluster101

   rac_cluster102

   Example additions to the main.cf file on the primary site:

   .

   .

   remotecluster rac_cluster102 (

   Cluster Address = "10.11.10.102"

   )

   heartbeat Icmp (

   ClusterList = { rac_cluster102 }

   Arguments @rac_cluster102 = { "10.11.10.102" }

   )

   system galaxy (

   )

   .

   .

   Example additions to the main.cf file on the secondary site:

   .

   .

   remotecluster rac_cluster101 (

   Cluster Address = "10.190.88.188"

   )

   heartbeat Icmp (

   ClusterList = { rac_cluster101 }

   Arguments @rac_cluster102 = { "10.190.88.188" }

   )

   system galaxy (

   )

   .

   .

See the Veritas Cluster Server User's Guide for details for configuring the required and optional attributes of the heartbeat object.