InfoScale™ 9.0 Disaster Recovery Implementation Guide - Linux

To modify the ClusterService group for global clusters using the global clustering wizard

1. On the primary cluster, start the GCO Configuration wizard:

   # /opt/VRTSvcs/bin/gcoconfig
   			

2. The wizard discovers the NIC devices on the local system and prompts you to enter the device to be used for the global cluster. Specify the name of the device and press Enter.
3. If you do not have NIC resources in your configuration, the wizard asks you whether the specified NIC will be the public NIC used by all the systems. Enter y if it is the public NIC; otherwise enter n. If you entered n, the wizard prompts you to enter the names of NICs on all systems.
4. Enter the virtual IP address for the local cluster.
5. If you do not have IP resources in your configuration, the wizard prompts you for the netmask associated with the virtual IP. The wizard detects the netmask; you can accept the suggested value or enter another one.

   The wizard starts running commands to create or update the ClusterService group. Various messages indicate the status of these commands. After running these commands, the wizard brings the ClusterService failover group online on any one of the nodes in the cluster.

To define the remote cluster and heartbeat

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

   # haconf -makerw
   			

2. On the primary site, define the remote cluster and its virtual IP address.

   In this example, the remote cluster is clus2 and its IP address is 10.11.10.102:

   # haclus -add clus2 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.

   In this example, the primary cluster is clus1 and its IP address is 10.10.10.101:

   # haclus -add clus1 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 enable you to define the virtual IP address for the remote cluster.

   For example:

   # hahb -modify Icmp ClusterList clus2
   # hahb -modify Icmp Arguments 10.11.10.102 -clus clus2
   			

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

   # haconf -dump -makero
   			

7. Complete step 4-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. It is advisible to modify "OnlineRetryLimit" & "OfflineWaitLimit" attribute of IP resource type to 1 on both the clusters:

   # hatype -modify IP  OnlineRetryLimit  1

   # hatype -modify IP  OfflineWaitLimit  1

9. Verify cluster status with the hastatus -sum command on both clusters.

   # hastatus -sum

10. Display the global setup by executing haclus -list command.

    # haclus -list
    				clus1
    				clus2
    			

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

    .
    .
    remotecluster clus2 (
    Cluster Address = "10.11.10.102"
    )
    heartbeat Icmp (
        ClusterList = { clus2 }
        Arguments @clus2 = { "10.11.10.102" }
        )
    
    system sys1 (
        )
    .
    .

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

    .
    .
    remotecluster clus1 (
        Cluster Address = "10.10.10.101"
        )
    
    heartbeat Icmp (
        ClusterList = { clus1 }
        Arguments @clus1 = { "10.10.10.101" }
        )
    
    system sys3 (
        )
    .
    .

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

To configure global service groups for database resources

1. Configure and enable global groups for databases and resources.

   • Configure VCS service groups at both sites.

   • Configure the replication agent at both sites.

   • For SF Oracle RAC, make the Oracle RAC service group a global service group, enabling failover across clusters.

   • For SF Sybase CE, make the database service group (sybasece) a global service group, enabling failover across clusters.

   • For example:

     See Modifying the Cluster Server (VCS) configuration on the primary site.

2. To test real data in an environment where HA/DR has been configured, schedule a planned migration to the secondary site for testing purposes.

   For example:

   See “To migrate the role of primary site to the remote site”.

   See “To migrate the role of new primary site back to the original primary site”.

3. Upon successful testing, bring the environment into production.