Configure: Convert a local synchronous volume to an asynchronous DR1




Customer Procedures


Procedures: Configure

Configure: Convert a local synchronous volume to an asynchronous DR1




Convert local volumes to asynchronous distributed volumes. 3

Best practices. 3

Procedure example. 3

Before you begin. 4

Task 1:   Verify an asynchronous consistency group is available. 4

Task 2:   Create corresponding local devices on target cluster 5

Task 3:   Create an asynchronous consistency group. 6

Procedure: convert the devices. 6



Convert local volumes to asynchronous distributed volumes

Use this procedure to convert volumes that reside on local devices at a single source cluster (local volumes) into volumes that reside on asynchronous distributed devices (asynchronous distributed volumes) in a VPLEX Geo system.

CAUTION:    During this procedure, volumes are temporarily both synchronous and distributed. If the inter-cluster latency is large, this may increase I/O latency on the volumes.

CAUTION:    If an application using the volumes is sensitive to increases in I/O latency, this procedure could lead to application time-outs and data unavailability. For these scenarios, select a maintenance period or other time at which I/O load is light.

Best practices

·    Create a new consistency group or use a consistency group dedicated to the application using the volumes being converted. Do not use consistency groups with critical applications.

·    To minimize the impact of conversion, perform this procedure during periods of low writes to the volume being converted.

·    If possible; take the volumes being converted offline.

·     If it is not possible, remove detach rules from the synchronous DR1s (recently converted from local to DR).

·     If a link failure happens in the middle of the procedure, do not detach.

·    Convert all volumes for a given application at the same time. Operating with some volumes in synchronous mode and others in asynchronous mode can lead to an inconsistent state.

Procedure example

The examples in this procedure use the following configuration:

Two local volumes:

·    device_1_vol

·     device_2_vol

These volumes reside at cluster cluster-1. The corresponding local devices are:

·    device_1

·    device_2

These local volumes are in a view called view1 and are used by a host application running at cluster-1.

The ls view-name command in the storage-view CLI context shows the two volumes in the view:

VPlexcli:/clusters/cluster-1/exports/storage-views> ls view1






This example shows the conversion of the two local volumes into asynchronous distributed volumes, while I/O continues at cluster-1.

Before you begin

Task 1:    Verify an asynchronous consistency group is available

VPLEX Geo supports up to 16 asynchronous consistency groups. In order to complete this procedure, there must be no more than 15 asynchronous consistency groups configured.


Use the following command to display the names of all asynchronous consistency groups in the system:

ls -CA $g:::consistency-group where $g::cache-mode \== asynchronous


For example:

VPlexcli:/> ls -CA $g:::consistency-group where $g::cache-mode \== asynchronous
















If there are already 16 asynchronous groups in the on a cluster:

·    Do not perform this procedure, or

·    Identify an existing consistency group with the following attributes:

·     Detach rules and other settings appropriate for the volumes and associated application

·     Capacity sufficient to accept all the new volumes without exceeding the limit of 1000-volumes per consistency group.

Task 2:    Create corresponding local devices on target cluster

  1. [   ]    Use the ls command in the CLI context for each local device you want to convert to an asynchronous distributed device.

In the following example, the ls command in the CLI context for device_1 shows all the properties of the device:

VPlexcli:/clusters/cluster-1/devices/device_1> ls


Name                    Value

----------------------  ------------

application-consistent  false

block-count             2560

block-offset            0

block-size              4K

capacity                10M

geometry                raid-1

health-indications      []

health-state            ok

locality                local

operational-status      ok

rebuild-allowed         true

rebuild-eta             -

rebuild-progress        -

rebuild-status          done

rebuild-type            full

rule-set-name           -

service-status          running

stripe-depth            -

system-id               device_1

transfer-size           2M

virtual-volume          device_1_vol

visibility              local


  2. [   ]    Note the local device’s capacity.

In the example, the capacity is 10MB.

  3. [   ]    For each device to be converted, locate or create a device of the same capacity at cluster-2. These devices will become the new distributed device legs at cluster-2.

In the following example, there are four free 10MB extents at cluster-2.

The local-device create command  creates 2 raid-1 geometry devices at cluster-2.

The new devices are named'device_1_mirror' and 'device_2_mirror':

VPlexcli:/> local-device create device_1_mirror raid-1 extent_0x200_1,extent_0x201_1 --force

VPlexcli:/> local-device create device_2_mirror raid-1 extent_0x202_1,extent_0x203_1 --force


VPlexcli:/> ll /clusters/cluster-2/devices



Task 3:    Create an asynchronous consistency group


  1. [   ]     Navigate to the consistency-group context and use the create consistency-group-name command to create a new consistency group at either cluster. For example:

VPlexcli:/> cd /clusters/cluster-1/consistency-groups

VPlexcli:/clusters/cluster-1/consistency-groups> create group_1


  2. [   ]    Use the cd command to navigate to the context of the new consistency group. For example:

VPlexcli:/clusters/cluster-1/consistency-groups> cd group_1


  3. [   ]    Use the set visibility cluster-1,cluster-2 command to set the visibility property to both clusters. For example:

VPlexcli:/clusters/cluster-1/consistency-groups/group_1> set visibility cluster-1,cluster-2


  4. [   ]    Use set storage-at-clusters cluster-1,cluster-2 command to set the storage-at-clusters property to both clusters. For example:

VPlexcli:/clusters/cluster-1/consistency-groups/group_1> set storage-at-clusters cluster-1,cluster-2


  5. [   ]    Use the set cache-mode asynchronous command to set the cache-mode property to 'asynchronous. For example:


VPlexcli:/clusters/cluster-1/consistency-groups/group_1> set cache-mode asynchronous

Changing the detach rule to 'active-cluster-wins' on consistency-group 'group_1'.


Note:  The set cache-mode command announces that it is changing the detach rule to active-cluster-wins. This is the default detach-rule for asynchronous consistency groups, and is a good choice of rule for this procedure.

Procedure: convert the devices

Note:  Perform this procedure on the management server at the cluster where the local volumes are located. In the example, the management server at cluster-1.


  1. [   ]    Use the cd command to navigate to the devices context at the source cluster. For example:

VPlexcli:/> cd /clusters/cluster-1/devices


  2. [   ]    For each device at the source cluster, use the device attach-mirror command to convert the device into a distributed device.

CAUTION:    This step causes a full rebuild across clusters. This will reduce the inter-cluster communication bandwidth, and may degrade the performance of other distributed volumes.

The syntax of the command is:

device attach-mirror

[-d|--device] {<context path>|<name>}

[-m|--mirror] {<context path>|<name>}


For the –mirror argument, specify the corresponding device created on the target cluster in Task 2: on page 5.  For example:

VPlexcli:/clusters/cluster-1/devices> device attach-mirror device_1 --mirror device_1_mirror

Distributed device 'device_1' is using rule-set 'cluster-1-detaches'.


CAUTION:    At this point in the procedure, the volume resides on a distributed device that is doing synchronous I/O. If an application using the volume is sensitive to increases in I/O latency, this is the point in the procedure where there is risk of the application experiencing problems.


  3. [   ]    Use the consistency-group add-virtual-volumes command to move the volumes into the asynchronous consistency group created in Task 3: on page 6. For example:

VPlexcli:/clusters/cluster-1/devices> consistency-group add-virtual-volumes -g ../consistency-groups/group_1 device_1_vol


  4. [   ]    Use the export storage-view addvirtualvolume command to add the volumes to storage-views at the target cluster.

CAUTION:    There may be additional I/O latency penalties at the target cluster until the rebuilds complete.