Configuring HADRHA

Edit online

After the VM Recovery Manager DR software is installed, you must complete some mandatory configuration steps to use the disaster recovery feature and high availability feature of the VM Recovery Manager DR software. You can use the ksysmgr command to interact with the KSYS daemon to manage the entire environment.

Complete the following procedures to configure the VM Recovery Manager HADRHA.

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 HADRHA 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 VM Recovery Manager DR solution is installed on the KSYS LPAR, you must configure the HADRHA cluster type before you set up the environment for the VM Recovery Manager HADRHA solution.

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

ksysmgr add ksyscluster HA_DR type=HADRHA ksysnodes=ksysnode1 sync=yes

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 sites, you can change from storage replication to synchronous.

To create sites for the VM Recovery Manager HADRHA, complete the following steps in the KSYS logical partition:

Create an HADRHA cluster by running the following command:

ksysmgr add ksyscluster HA_DR type=HADRHA ksysnodes=<ksysnode> 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 VM Recovery Manager HADRHA 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> login=hscroot password=abc123 hostname=<host_name1> site=<site1> ip=<HMC IP1>
```
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> login=hscroot password=abc123 hostname=<host_name2> site=<site2> ip=<HMC IP2>
```

Adding hosts to the KSYS subsystem

The KSYS monitors and manages the disaster recovery operations across sites. The KSYS requires that 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.

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 host <host1> site=<site1>
```
```
ksysmgr add host <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 host <host3> site=<site2>
```
Add another backup host (for example, host name: host4), which acts as a backup host, to the KSYS subsystem by running the following command:
```
ksysmgr add host <host4> site=<site2>
```

Adding storage agent

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

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 a set of hosts together and quickly. In disaster situations, you can move a host group separately to the backup site.

Shared mode for HADRHA cluster

To create a shared mode cluster, you need to change the replication attribute to type=shared. For shared mode, you do not need to add a storage agent. You can use the same storage and stack configuration for both the Home site and the Backup site. Run the following command:

ksysmgr modify system replication_type=shared sites=<HomeSite, Backupsite>

Note: For HADRHA clusters with shared mode replication type, you can create workgroups from both the Home site and the Backup site.

Note: Workgroup support for HADRHA follows the same configuration model as HADR. The complete procedure for enabling workgroup operations, creating host groups with workgroup_support=yes, and understanding default workgroup behavior is documented in the HADR section. For more information, see Enabling workgroup support for HADR and HADRHA.

Guidelines to manage host groups:

A host must already be added to the KSYS configuration settings and the host must have been paired with a backup host in the backup site.
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, which 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.

To create a host group, complete the following steps:

Identify the available ha_disk and repo_disk by using the ksysmgr query vios command in the backup site. You can use the modify host_group option after creating the host group to add the backup site's SSP disks.
```
ksysmgr query viodisk vios=VIOS1,VIOS2,VIOS3,VIOS4 site=sitename
```
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,Host4 > mxn_pairing=yes ha_disk=SSP_disk1 repo_disk=SSP_disk2
```
  Note: By default, the mxn_pairing attribute is set to no. To create 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.

You can use the modify host_group option after creating the host group to add the backup site's SSP disks

ksysmgr modify host_group <Host_group1> options ha_disk=<Backup_site_SSP_disk1> repo_disk=<Backup_site_SSP_disk2> site=<Backup_sitename>

To perform the discovery operation and the verify operation at the site level, run the following command:
```
ksysmgr discover site Austin verify=yes change to ksysmgr discover site <Site Name> 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 option=DRonly
```
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
```

Note: After the move operation is completed, the KSYS subsystem performs the discovery operation to enable the HA infrastructure. For HADRHA clusters, both sites need to be up to complete the discovery operation. If any site is not in a healthy state, you must resolve the errors and then rerun the discovery operation.

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>
```

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.