Prerequisites for implementing the GDR solution

The KSYS node must be able to perform HTTPS-based communication to all HMCs on both sites. In addition, the KSYS node must be able to communicate to the storage subsystems on both sites by using the storage vendor methods.

Ensure that you have the following information available for each HMC that you plan to include in the GDR implementation:

• HMC name or IP address
• User name
• Password

During the verification phase, the GDR solution displays a warning message about any VIOS issues. For example, if any of the VIOS partitions is down, a warning message is displayed. The GDR solution skips this check if you use the lose_vios_redundancy attribute persistently. For more information about this option, see Managing the system attributes.

Even after you use this option, the source virtual machines can be moved to the backup host only when the VIOS in the target host can accommodate all the virtual adapters of the virtual machine. Problems might occur during the disaster recovery operation if one of the VIOS or Fiber Channel adapters are down. Review the following scenarios to determine the VIOS configuration issues:

Scenario 1

The following figure shows an N_Port ID virtualization (NPIV)-based VIOS configuration in which the source host contains 2 VIOS partitions that use 2-port Fibre Channel (FC) adapters. If the target host does not contain dual VIOS configuration or if one of the Virtual I/O Servers in the target host is not functioning, the virtual machine can be moved from the source host to the target host only when the VIOS in the target host uses 4-port FC adapter.

Figure 1. VIOS configuration during disaster recovery: Scenario 1

Scenario 2

The following figure shows an NPIV-based VIOS configuration in which the source host contains a VIOS partition (VIOS_1_11) that uses 2-port FC adapter. In this example, 70 virtual machines are running in the Host_1_1, where 64 VMs are mapped to the fcs0 adapter and the remaining 6 VMs are mapped to the fcs1 adapter.

Figure 2. VIOS configuration during disaster recovery: Scenario 2

If the active site fails, the 70 virtual machines must be moved from the source host to the target host. The recovered virtual machines in the target host must ideally be using the VIOS partition (VIOS_2_11) that uses the 2-port FC adapter in the target host. However, if one of the adapters of the VIOS partition is not functional, the virtual machines that must be mapped to the nonoperational adapter are moved to the target host but remain inactive. Even when you have a dual VIOS configuration in the target host, the inactive virtual machines are not mapped to other available VIOS adapters.

In this case, the administrator must manually resolve the issues in the adapter and activate the virtual machines.

• Allocate the primary storage based on the current storage requirements.
• Map primary storage logical unit numbers (LUNs) to appropriate virtual machines and VIOS as required (vSCSI or NPIV).
• Allocate backup or mirror LUNs at the backup site.
• Identify the storage agent count and storage agent names based on the current storage configuration. The storage controller software that interacts with the storage subsystem must be installed on the KSYS node.
• Configure the physical connectivity and zoning of backup storage LUNs to appropriate adapters. It ensures the storage availability when virtual machines are started in the backup site.
• Set up replication relationships between primary storage LUNs and backup storage LUNs. Ensure to include virtual machine operating system LUNs in the replication. You do not need to set up consistency groups. The KSYS subsystem performs those operations.
• Have the storage administrative information ready to specify in the KSYS configuration settings (for example, storage agent count and name, user name, password, serial number of the storage disks, IP address of the storage controller server.)
• For EMC storage, review the existing SRDF composite groups. Verify that the storage disks, which are planned to be included in the GDR implementation, are not part of any existing composite groups.

• Email
• SMS
• Pager email