IBM Developer

Article

IBM FlashSystem policy-based replication support with IBM VM Recovery Manager

Disaster recovery management with auto creation of host, disk mapping, and volume group creation at the target storage system

By Pandi Jai Sree, Dishant Doriwala, Adhish Kapoor, Jes Kiran, Michael Herrara

On this page

IBM FlashSystem supports policy-based replication, which uses volume groups and replication policies to automatically deploy and manage replication. Policy-based replication significantly simplifies configuring, managing, and monitoring replication between two systems, which user need to do manually. As many of the users are now taking advantage of policy-based replication, IBM VM Recovery Manager needs to support that replication for disaster recovery (DR) management.

This article explains how to enable policy-based replication using VM Recovery Manager DR solution that supports automatic creation of host, disk mapping in target storage, and volume group creation added to a user-defined policy. Users can set the replication_type option to policybased through the KSYS node to enable this support.

IBM VM Recovery Manager

IBM VM Recovery Manager provides disaster recovery and high availability solution for virtual machines (VMs). IBM VM Recovery Manager DR supports many storage replications along with existing replications VM Recovery Manager DR introduced a new replication type known as policy-based replication for IBM FlashSystem.

The policy-based replication feature is supported exclusively with IBM Storwize and IBM FlashSystem storage for version 8.5.2 and later. Policy-based replication uses volume groups and replication policies to automatically deploy and manage replication. It significantly simplifies configuring, managing, and monitoring replication between two systems. The required firmware level for storage is mandatory to enable policy-based replication support with VM Recovery Manager. Policy-based replication is a replacement of Metro Mirror and Global Mirror for Storwize and FlashSystem.

For more details about policy-based replication, refer to policy-based replication in IBM Documentation.

To integrate with policy-based replication, you need to specify the replication type to policy-based between the sites that are involved in a disaster recovery setup at system level and assign the new replication policy type in KSYS which supports at system/host group and workgroup level.

KSYS version support:

IBM FlashSystem policy-based replication for DR configurations is available starting in version 1.8.0 SP1 of VM Recovery manager.

Syntax to set the new replication_type option

Users must manually set the replication_type to policy-based replication before first discovery with siteA and siteB involved in disaster recovery. SiteA and SiteB are the names of the virtual sites created during the VM Recovery Manager DR cluster configuration.

# ksysmgr modify system [replication_type=<async | sync | shared | policybased>  sites=<A,B>]

To set the feature attribute to policybased, run the following command:

ksysmgr modify system replication_type=policybased sites=SiteA,SiteB

Refer to the following example to set replication_type:

(0)root @ KSYS1: /
# ksysmgr modify system replication_type=policybased sites=India,Austin
KSYS replication_type has been updated between Austin and India

(0)root @ KSYS1: /

An example to query the replication type follows:

(0) root @ KSYS1: /
# date;ksysmgr q system | grep replication
Wed Nov 27 08:45:43 CST 2024
replication_type: policybased

(0) root @ KSYS1: /

Assign a replication policy name

Users must manually create a policy at the storage level and then assign it to the system, host group, and workgroup based on user requirements in the VM Recovery Manager. Ensure that the policy updated in KSYS exists in the storage system.

At the system level: Policy name defines the replication rules and settings that are applied consistently across the specified sites.

Use the following syntax to assign a specific replication policy to the system:

# ksysmgr modify system replicationpolicyname=<replication policy name>

Refer to the following example to assign a replication policy name at the system level:

(0) root @ KSYS1: /
# ksysmgr modify system replicationpolicyname=test_policy
KSYS ReplicationPolicyName has been updated

(0) root @ KSYS1: /

At the host group level: Replication policy to a host group allows all resources within that group to adhere to the specified replication rules. This ensures that the replication policy is enforced uniformly across the host group.

Refer to the following syntax to assign a specific replication policy to the host group:

# ksysmgr modify host_group <host group name> options replicationpolicyname=<replication policy name>

Refer to the following example to assign a replication policy name at the host group level:

(0) root @ KSYS1: /
# ksysmgr modify hg HG1 options replicationpolicyname=test_policy
For Host Group HG1 attribute(s) 'replicationpolicyname' was successfully modified.

(0) root @ KSYS1: /

At the work group level: Replication policy to a workgroup ensures that all resources within the workgroup follow the designated replication settings.

Refer to the following syntax to assign a specific replication policy to the work group:

# ksysmgr modify system replicationpolicyname=<replication policy name>

Refer to the following example to assign a replication policy name at the work group level:

(0) root @ KSYS1: /
# ksysmgr modify wg wg1 replicationpolicyname=test_policy
For Workgroup wg1 attribute(s) 'replicationpolicyname' was successfully modified.

(0) root @ KSYS1: /

Note: if multiple workgroup exists, and each workgroup has different policy same command can be repeated for other workgroups. In such case under same policy name at storage volume groups will be created based on each workgroup.

Eg : ksysmgr modify wg wg2 replicationpolicyname=test_policy01
For Workgroup wg2 attribute(s) 'replicationpolicyname' was successfully modified.

Enable policy-based replication with VM Recovery Manager

With VM Recovery manager using replication types such as Global Mirror, Global Mirror Change Volume , or Metro Mirror, the administrator must manually create the host on the target storage, perform LUN mapping, and set up the replication configuration. For policy-based replication, the target volume and replication setup are automatically handled by the storage system. VM Recovery Manager will then create a host on the target using the same Worldwide Port Name (WWPN) as the source and perform LUN mapping during the discovery process.

This section explains how VM Recovery Manager manages policy-based replication in various scenarios.

Scenario 1: No host and no disk on the target storage

In contrast to Metro Mirror and Global Mirror, when using policy-based replication, there is no need to perform manual configuration for the host and target storage definitions at the DR site.

If policy-based replication is enabled and there is no host and disk on the target storage during first discovery, KSYS will create a host using the same name as in the home storage and perform disk mapping.

The following screenshots show that there is no host and disk created for the hat014 VM on the target storage.

alt

alt

The output below displays the results of the discovery operation. During the process, policy-based replication automatically created the target volume, volume group, and replication setup. The KSYS controller then creates a host on the target storage and maps the target volume generated by the policy-based replication.

(0) root @ KSYS1: /
# date;ksysmgr -t discover site India
Fri Dec 13 04:14:54 CST 2024
04:15:16  Running discovery on entire site, this may take a few minutes...
        04:15:32  Storage state synchronization has started for Host Group HG1
        04:15:32  Storage state synchronization has completed for Host Group HG1
        04:15:32  Discovery has started for VM hat014
        04:15:32  Configuration information retrieval started for VM hat014
        04:15:45  Configuration information retrieval completed for VM hat014
        04:15:45  Storage information retrieval from VIOS started for VM hat014
        04:15:45  Storage information retrieval from VIOS completed for VM hat014
        04:15:45  Discovery for VM hat014 is complete
        04:16:04  Disk Group creation on storage subsystem started for Host Group HG1
        04:16:23  Disk Group creation on storage subsystem completed for Host Group HG1
04:16:52  Discovery has finished for India
1 out of 1 managed VMs have been successfully discovered
(0) root @ KSYS1: /

The following screenshots show that host is created, and the disk is mapped to the host on the target storage after first discovery.

alt

alt

The following screenshots show that the volume group is created and a disk is added to the volume group.

alt

alt

Scenario 2: Host and target LUNs had already been created on the target storage

If a host with the same worldwide port name (WWPN) already exists, the KSYS will use that host for policy-based replication and if a target disk with the same name is already on the target storage, KSYS will create a new disk with a suffix name, which will then be used for volume group creation.

The following screenshots show that the host and the disk exist on the target storage without disk mapping.

alt

alt

During first discovery (with an already existing host), the KSYS will use the same host and create a new disk with the same name and suffix added.

The following screenshot shows a new disk created with suffix prefix added which will be used for volume group creation.

alt

DR rehearsal

In VM Recovery Manager for Power, a disaster recovery rehearsal is a failover simulation that allows you to test the recovery process without impacting the production virtual machines. This feature is especially useful for compliance audits and internal DR drills, and to ensure that business continuity plans are effective.

Users must manually create IBM FlashCopy mappings using a new disk and the target disk created by the policy-based replication. In a policy-based replication environment, after performing operations such as removing the KSYS cluster or modifying host groups or workgroups, the system does not automatically remove FlashCopy mappings from the consistency group or IBM Storwize storage system.

Users must create FlashCopy mappings at the target storage for DR rehearsal after first discovery is successfully completed. As part of the first successful DR discovery, a target replicated volume along with a volume group will be created at both the source and target storages. Volumes will also be mapped to the host created by VM Recovery Manager. The following screenshots show volume groups and target volumes created for the replication policy mentioned.

test_volume_pbr is the replicated volume created on the target storage which is part of the test_vg volume group.

alt

alt

alt

The following screenshot shows the manual creation of a FlashCopy volume for the replicated target storage volume

Note: Users only need to create FlashCopy volumes and FlashCopy mappings. Need not map to the target host. Mapping to the target host will be done by the VM Recovery Manager DR Rehearsal move operation.

alt

The following screenshot shows the FlashCopy mappings created between the target replication volume and FlashCopy volume.

alt

After this is configured, you can run DR test discovery from the KSYS controller node and take advantage of the DR Rehearsal feature.

Note: If a user has already created a policy-based replication before using VM Recovery Manager, the user must adhere to the following standards when creating a VM Recovery Manager DR cluster:

  • Use the same policy name that exists on the storage system in the replicationpolicyname attribute at the appropriate level.

  • Specify the existing volume group name in the customcgname attribute at the required level (workgroup or host group).

Limitations and recommendations

Refer to the following limitations and recommendations while using policy-based replication with VM Recovery Manager DR solution:

  • The attributes, replicationpolicyname and replication_type=policybased in VM Recovery Manager will be supported only for IBM FlashSystem.

  • Users must manually update the policy name in KSYS and ensure that the policy exists in the storage system.

  • Later, users can create a new policy and assign it to KSYS at the system level, host group level, or workgroup level as per their requirement.

  • Storage pool mapping must be done before you initiate the replication configuration.

  • Storage agent must be added before setting the policy-based replication type in the KSYS cluster. If the storage added does not support the policy-based replication feature, during modifying replication type in KSYS, user will be notified with error mentioning about unsupported storage system.

Note: There are no restrictions on adding a storage agent after updating the replication type. However, when setting the replication type to policybased, it is verified that the added storage supports the required firmware version.

  • One valid replication policy with a volume group must exist on the source and backup storage for policy-based replication to function correctly. If the storage does not have any replication policies, then the KSYS system might encounter errors during site discovery or replication setup.

  • In a policy-based replication environment, after performing operations such as removing the KSYS cluster or modifying host groups or workgroups, the system does not automatically remove FlashCopy mapping from the consistency group or the Storwize storage system.

  • KSYS 1.8.0.1 deployment currently does not support policy-based replication converted from a Metro Mirror or Global Mirror deployment using older enclosures. This restriction may be removed in a future update. Currently for migration purposes from an older replication type you should consider deploying a new KSYS instance configured to use policy-based replication.

  • Policy-based replication will be updated in the initial KSYS GUI-based configuration wizard in a future product update. Currently, the initial configuration must be performed using the CLI.

Summary

This article explained how to enable and initiate policy-based replication at sites that are involved in disaster recovery setup at the system level and assign a replication policy name in KSYS that supports at system, host group, and workgroup levels. It also described how policy-based replication operates using VM Recovery Manager, including disk mapping (on the target storage) and volume creation (which is then added to the user-defined policy).