Configuring HADR

Edit online

After the VM Recovery Manager HADR software is installed, you must complete some mandatory configuration steps to use the disaster recovery feature and high availability feature of the HADR type of deployment of the VM Recovery Manager DR solution. You can use the ksysmgr command to interact with the KSYS daemon to manage the entire environment. For more information about HADR configuration, see Deployment steps: IBM VM Recovery Manager HADR cluster.

Prerequisite

The following are the hardware configuration prerequisite for the IBM VM Recovery Manager HADR cluster:

Two hosts at source site and minimum one host at the backup site are required.
Two VIOS instances at the home site hosts are required.
Home site VIOS instances must have at least two shared disks between them for an SSP cluster, and Cluster Aware AIX (CAA) volume group for repository. The size of the shared disks must be 10 GB, or more.
The managed VMs must have disks on the source storage and the target storage, and replication process must run successfully between disks.

Configuring HADR

Complete the following procedures to configure the HADR type of deployment of the VM Recovery Manager DR solution.

Configuring the KSYS node
Creating sites
Adding HMCs to the KSYS subsystem
Adding hosts to the KSYS subsystem
Adding storage agent
Creating host group

Note:

You can use asymmetric and symmetric host group configurations while creating and adding host groups.
You can add VM agents to the HADR type of deployment of the VM Recovery Manager DR solution. For more information about VM agents, see the VM agents topic in the IBM VM Recovery Manager HA 1.9 deployment document.

Configuring the KSYS node

After the HADR type of deployment of the VM Recovery Manager DR solution is installed on the KSYS LPAR, you must configure the HADR cluster type before you set up environment for the HADR type of deployment of the VM Recovery Manager DR solution.

To configure the HADR cluster type, specify HADR while configuring the cluster. For example:

ksysmgr add ksyscluster cluster_name ksysnodes=ksysnode1 type=HADR

Creating sites

You must create sites that are used to map all the HMCs, hosts, and storage devices. You must create an active site where the workloads are currently running and a backup site that acts as a backup for the workloads during a disaster or a potential disaster situation.

Sites are logical names that represent your sites. A site name can be any American Standard Code for Information Interchange (ASCII) string that is limited to 64 characters. A site name cannot contain any special characters or spaces.

By default, the active site is the home site. You can configure only two sites. When you create sites, the replication type of the site is asynchronous by default. After you create the sites, you can modify the storage replication type as required.

To create sites for the HADR type of deployment of the VM Recovery Manager DR solution, complete the following steps in the KSYS logical partition:

Create an HADR cluster by running the following command:

ksysmgr add ksyscluster <HADR_CLUSTER_NAME> type=HADR ksysnodes=<hostname> sync=yes

Add the home site (Site1) by running the following command:
```
ksysmgr add site <Site1> sitetype=home
```
Add backup site (Site2) by running the following command:
```
ksysmgr add site <Site2> sitetype=backup
```

Adding HMCs to the KSYS subsystem

The KSYS interacts with the HMC for discovery, verification, monitoring, recovery, and cleanup operations. HMCs that are configured in both the active and backup sites provide details about the hosts and VIOS partitions that are managed by the HMCs in each site. The HADR type of deployment of the VM Recovery Manager DR solution cannot be implemented without configuring the HMCs. Therefore, you must provide the HMC details to the KSYS.

Note: The HMC user, whose user name and password details are provided to the KSYS, must have hmcsuperadmin privileges with remote access enabled.

To add the HMCs to a specific site, complete the following steps in the KSYS LPAR:

To add the HMC (for example, HMC name: HMC1_name, IP of the HMC: HMC IP1, login: hscroot, password: abc123) that manages the host or hosts in the active site (Site1), run the following command:
```
ksysmgr add hmc <HMC1_name> ip=<HMC IP1> login=hscroot password=<abc123> site=<Site1>
```
Add the HMC (for example, HMC name: HMC2_name, IP of the HMC IP2, login: hscroot, password: abc123) that manages the host or hosts in the backup site (Site2), run the following command:
```
ksysmgr add hmc <HMC2_name> ip=<HMC IP2> login=hscroot password=<abc123> site=<Site2>
```

Adding hosts to the KSYS subsystem

The KSYS monitors and manages the disaster recovery operations across sites. For symmetric host_group each host must be paired to another host across sites. This type of pairing allows the virtual machines to move from one host to another host across sites. You must plan the host pairing across sites in advance, and then implement the pairing.

For asymmetric host_group host pairing is not required, you has to add all hosts in a hostgroup with option mxn_pairing=yes

After the HMCs are added to the KSYS, you can review the list of managed hosts by each HMC, and then identify the hosts that you want to add to the KSYS for disaster recovery. You must connect the source hosts and target hosts to different HMCs across sites. If you connect the source hosts and target hosts to the same HMC, it leads to an invalid configuration in the KSYS subsystem and can cause failures in disaster recovery operations.

When a host is added to a host group, all the virtual machines in the host are included by default in the disaster recovery management scope. However, the disaster recovery management starts only after you configure the subsystems and run the discovery and verification operations. Therefore, if you plan to exclude a set of virtual machines after adding the hosts, you can unmanage those virtual machines, and then run the discovery and verification operations.

To add the hosts to the KSYS configuration, complete the following steps in the KSYS LPAR:

Add the managed host (for example, host names: Host1, Host2), which is running the workload, to the KSYS subsystem by running the following commands:
```
ksysmgr add cec <Host1> site=<Site1>
```
```
ksysmgr add cec <Host2> site=<Site1>
```
Add the backup host (for example, host name: Host3), which acts as a backup host, to the KSYS subsystem by running the following command:
```
ksysmgr add cec <Host3> site=<Site2>
```

Adding storage agent

After adding hosts to the KSYS subsystem, you must add storage agents to the KSYS subsystem. For instruction, see Adding storage agents to the KSYS.

To add an storage agent, run the following command:

ksysmgr add storage_agent <name> hostname|ip=<storage> login=<username> password=<password> storagetype=<type of storage> serialnumber=<storage_serialnumber> site=<site_name>

Creating host group

You can group a set of hosts based on your business requirements. For example, you can group the hosts that run similar type of workloads. You can also group important hosts together so that the monitoring and recovery operations can be performed for the set of hosts together and quickly. In disaster situations, you can move a host group separately to the backup site.

Guidelines to manage host groups:

A host must be added to the KSYS configuration settings, and the host must be paired with a backup host in the backup site in symmetric hostgroup.
If you add or remove hosts from a host group, you must run a discovery operation to manage or unmanage all the virtual machines from the recovery management. The modified host group displays the correct list of managed virtual machines only after a discovery operation.
The corresponding hosts in the backup site that are paired with the active site hosts are grouped logically within the same host group. For example, if host1 in the active site is paired with host2 in the backup site and you create a host group hg1 with host1, then host2 is automatically added to the host group hg1.
Each host group must be associated with a separate disk group. The disks in the disk group must not be shared among different host groups. The disk groups are named in the following format:
```
VMRDG_{peer_domain_name}_{site_name}_{host_group_ID}
```
However, the disk group name must not exceed the maximum number of characters that is supported for a consistency group at storage level.
For SAN Volume Controller and DS8000® series of storage systems, host groups can span across a single type of storage. Multiple host groups can use same type of storage disks but the disks must not be shared among different host groups.

Identify the available disks that you can designate as the repository disk and the HA disk for the Shared Storage Pool (SSP) cluster by running the following command for the VIOSes which are part of the host group on the home site.
```
ksysmgr query viodisk vios=VIOS1,VIOS2,VIOS3,VIOS4
```
You can create symmetric or asymmetric host group and add the existing hosts to it.
1. Symmetric host group:
  Before creating a symmetric host group, you must create host pairs. After the hosts are added to the KSYS subsystem, identify the hosts that must be paired across the active site and the backup site. Each backup host in the host pair must meet all the resource requirements so that the backup host can run the same workload in a disaster or a potential disaster situation.
  Pair the identified host (for example, host name: Host1, Host3) in the active site to the identified host (for example, host name: Host2, Host4) in the backup site by running the following commands:
```
ksysmgr pair host Host1 pair=Host2
```
```
ksysmgr pair host Host3 pair=Host4
```
  Now, to create a symmetric host group ( for example host group name : Host_group1, ha_disk : SSP_disk1 , repo_disk :SSP_disk2), run the following command
```
ksysmgr add host_group Host_group1 hosts=Host1,Host3 ha_disk=SSP_disk1 repo_disk=SSP_disk2
```
  Note: After you add one counterpart from the host-pair to a host group, the other counterpart of the host-pair will be automatically added to the respective host group in the other site. These hosts forms symmetric host group, which contains one-to-one paired hosts.
2. Asymmetric host group: To create an asymmetric host group (for example, host group name: Host_group1, HA disk: SSP_disk1, repo_disk : SSP_disk2) and to add the existing hosts (for example, hosts: Host1, Host2, Host3) to the asymmetric host group, run the following command:
```
ksysmgr add host_group Host_group1 hosts=Host1,Host2,Host3 mxn_pairing=yes ha_disk=SSP_disk1 repo_disk=SSP_disk2
```
  Note: By default, the mxn_pairing attribute is set to no. To create an asymmetric host group, which contains one-to-many paired hosts, set the mxn_pairing attribute to yes. You must not pair the hosts before adding the hosts to the host group. You must specify host and host-group pair of all hosts manually.
For HADR and HADRHA cluster types, host groups can be created with workgroup support enabled to participate in workgroup-level operations. Host groups that are created with workgroup support can participate in all workgroup operations, such as workgroup creation, discovery, verification, and modification. Workgroup support is required for performing high availability and disaster recovery operations at the workgroup level.
To create a host group with workgroup support enabled, run the following command:
```
ksysmgr add hg <host_group_name> hosts=<host1,host2,...> workgroup_support=yes mxn_pairing=yes
```
The workgroup_support=yes attribute enables workgroup operations for the host group.

After the host group is created with workgroup support enabled, you must perform the discovery and verification operations to ensure that the virtual machines associated with the host group are managed correctly by the KSYS subsystem.
To perform the discovery operation and the verify operation at the site level, run the following command:
```
ksysmgr discover site sitename verify=yes
```
To perform the discovery operation and the verify operation for a specific host group, run the following command:
```
ksysmgr discover host_group hg_name verify=true
```
To perform the discovery operation and the DR only verify operation for a specific host group, run the following command:
```
ksysmgr discover host_group hg_name verify=true option=DRonly
```

Disabling LPM operations

You can enable or disable the Live Partition Mobility (LPM) feature at the system, host group, or host level through the lpm_support tunable attribute. If disabled, the KSYS subsystem does not allow LPM operations. The lpm_support attribute is enabled by default.

To set the LPM tunable attribute at the system level, run the following command:
```
ksysmgr modify system lpm_support=<Enable|Disable>
```
To set the LPM tunable attribute at the host group level, run the following command:
```
ksysmgr modify hg <host_group_name> options lpm_support=<Enable|Disable|None>
```
To set the LPM tunable attribute at the host level, run the following command:
```
ksysmgr modify host <host_name> lpm_support=<Enable|Disable|None>
```
Note: When host group (HG) or site-level verification is triggered, Logical Partition Mobility (LPM) operations are disabled at both the host group and system levels.

By default, the LPM feature is enabled at the system level. You can enable or disable LPM feature at the system level. By default, the LPM status for host and host group is set to none. You can set LPM status as enable, disable or none at the host and host group level. If the LPM status is not modified at the host and host group level, the LPM status that is set at the system level is also applicable at the host and host group level. If the LPM status is modified at the host or host group level, the first preference is given to the LPM status that is set at the host level, then the LPM status set at the host group level, and then the LPM status set at the system level.

The KSYS subsystem checks the LPM status of host, then the LPM status of host group, and then the LPM status of system. For example, the KSYS subsystem checks the LPM status of a host, if the status is set to enable or disable, the same is applicable to the host. If the LPM status of the host is set to none, the KSYS subsystem checks the LPM status of the host group. If the status is set to enable or disable for the host group, the same is applicable to the host group and all the hosts within the host group that have LPM status set as none . If the LPM status of the host group is set to none, the KSYS subsystem checks the LPM status at the system level.

Enabling workgroup support for HADR and HADRHA

You can enable workgroup operations for the HADR and HADRHA cluster types by creating the host group with the workgroup_support attribute. When this attribute is enabled, the host group can participate in all workgroup operations such as creation, discovery, verification, and modification. Workgroups created in the HADR and HADRHA cluster type can participate in both high availability and disaster recovery operations.

To enable workgroup support while creating the host group, run the following command:

ksysmgr add hg <host_group_name> hosts=<host1,host2,...> [workgroup_support=yes] [mxn_pairing=yes]

The workgroup_support=yes attribute enables workgroup operations for the host group. The mxn_pairing=yes attribute must be specified when you are creating asymmetric host groups or when multi-to-one pairing is required in HADR or HADRHA environments.

When you create host_group with workgroup_support=yes default_wg is created for that host_group with the name Default_WG_<hg_id>. During HG or site discovery all the orphan vms are added to default wg.

Creating workgroups in HADR and HADRHA

After the host group is created with workgroup support enabled, you can create workgroups for the virtual machines that are managed under the host group.

To create a workgroup and associate a virtual machine with a custom consistency group, run the following command:

ksysmgr add wg <workgroup_name> vm=<VM_Name> [customcgname=<custom_name>]

This command creates the workgroup, adds the specified virtual machine to it, and associates a custom consistency group name with the workgroup. Workgroups created in the HADR cluster type can participate in both high availability and disaster recovery operations, and workgroups created in the HADRHA shared mode cluster type participate in disaster recovery operations.

Modifying and deleting workgroup

To modify and delete a workgroup, run the following command:

ksysmgr modify workgroup <name> -h

An output that is similar to the following example is displayed:


[ policy=<add | delete> 
vm=<vmname1 | vmuuid1[,vmname2 | vmuuid2 ...]> ]
[ customcgname=<CgName> ]
[ bsitecgname=<CgName> ]
[ network=<vlanmap | vswitchmap> sites=<siteA,siteB> <siteA>=<vlanID1[,vlanID2,...]> 
<siteB>=<vlanID1[,vlanID2,...]> ]
[ dr_test=<yes | no> ]
[ policy=delete ]
[ replicationpolicyname=<name> ]
[[ snapshotpolicyname=<snapshot_policy_name> ] 
| suspendsnapshotpolicy 
| resumesnapshotpolicy ]
modify => mod*, ch*, set 
workgroup => workg*, work_g*, wg

Note: bsitecgname is applicable only for EMC storage.

Note: customcgname and bsitecgname can be modified only before first discovery.

Note: snapshotpolicyname, suspendsnapshotpolicy, and resumesnapshotpolicy options are supported only for SVC storage.

To delete workgroup, user must remove all vms from workgroup using command "

ksysmgr
modify workgroup vm=<vmname1,vmname2 ..> policy=delete

" and then try delete workgroup command, run the following command:

ksysmgr delete workgroup -h

An output that is similar to the following example is displayed:

ksysmgr delete workgroup <name>
delete => de*, remove, rm, erase
workgroup => workg*, work_g*, wg

Note: if any policies are configured for the vms belong to the workgroup, user must remove them first.

Note: User is not allowed to remove default_wg, it will be removed by the ksys at the time of host_group deletion.