Global Mirror feature on IBM Storwize

You can use the Global Mirror functionality of IBM® Storwize® for volume replication. With PowerVC version 2.0.2, you can also manage Global Mirror Change volumes.

Before using Global Mirror or Global Mirror Change Volume with Storwize

Before using Storwize Global Mirror or Global Mirror Change Volume, ensure that Storwize is configured with remote copy licenses. You can verify by running lslicense on the Storwize backend and check the license_remote property should be more than zero.

Registering Global Mirror with Storwize

You can register a secondary storage for Global Mirror in PowerVC for a primary storage provider. You can perform this activity on the Storage details page of the user interface or through API. When you register a secondary storage, a default Global Mirror storage template is added to the Storage templates list. For API details, see Storage controller registration.

After setting up Global Mirror with PowerVC, when you create a volume using the Global Mirror storage template - the volume will be available in the primary storage and replicated on the secondary storage.

Once the volume is in a consistent synchronized state - the remote copy relationship is considered as stable; and in this state, the volumes on primary and secondary storage are similar. Refer to the States section for different states possible.

Note: Creation of group snapshot and live capture of Global Mirror volumes will fail if the remote relation is not in consistent_synchronized state.

Retype and Delete operations on a volume with Global Mirror template

When a volume is retyped from a Global Mirror template to a non mirror template, the remote copy relationship is deleted at the storage backend. Also, the default behavior is to delete the replicated volume (or aux volume) on the secondary storage as well. Same is the case for deleting a volume with Global Mirror template. When a delete operation is performed on a volume with Global Mirror template - the remote copy relationship is deleted at the storage backend and the replicated volume (or aux volume) on the secondary storage is deleted as well.

PowerVC has introduced a CLI that helps you to change the default behavior of deletion of volumes on secondary storage when retype or delete of Global Mirror volume is performed. This is a system wide setting which affects all Global Mirror volumes managed in PowerVC. For details, see Commands.

Global Mirror with VM Recovery Manager (VMRM) for disaster recovery (DR)

PowerVC can work in coordination with VMRM for Global Mirror volumes for group operations on Global Mirror volumes. For details, see VM Recovery Manager DR.

By default, VMRM adds new volumes on IBM Storwize in a group (known as RCCG). For enabling group operations of these volumes from PowerVC, you can create a group type key in PowerVC with name - replication_enabled_vmrm and perform group operations like group clone.

Failover to secondary storage and failback operations for the virtual machine need to be planned using the VM Recovery Manager tool.

Global Mirror Change Volume (GMCV) enablement

Starting PowerVC version 2.1.0, you can register and manage GMCV volumes by using PowerVC GUI or API.

Alternatively, you can use registered Global Mirror Storwize to manage GMCV volumes. After registering secondary storage for Global Mirror in PowerVC, you can create a copy of existing Global Mirror base template or update the template properties with GMCV by using the below CLI
cinder type-key gmcv-template set replication_enabled='<is> True' replication_type="<in> gmcv" drivers:cycle_period_seconds=500 drivers:storwize_svc_src_child_pool="src_child" drivers:storwize_svc_target_child_pool="target_child"

If the storage child pools are configured, you can also mention those settings using the cinder type-key with optional cinder type extra-specs properties for configuring source and child pool.

Example (optional properties):

After enabling the GMCV template, you can create GMCV volumes in PowerVC GUI. All virtual machine and volume lifecycle operations are supported for GMCV volumes.

Limitations and considerations

Consider the following when working with Global Mirror Change Volume.
  • If GMCV final volume mirroring is in consistent_copying state, then consistency group state will also be in consistent_copying state.
  • You can only add volumes to consistency group when the volume mirroring state and consistency group state are same. Else, add volume operation fails, and the consistency group (CG) goes into error state. Then you need to reset the state from PowerVC to retry the operation.
  • Live capture for GM or GMCV is supported in a scenario where none of the selected volumes are part of the consistency group (CG) or all selected volumes are part of the same CG.
  • Resize volume operation fails if volumes are part of the consistency group.
  • When a GMCV volume is deleted, both primary and change volumes relationship is deleted.