mkrcrelationship

Specify the mkrcrelationship command to create a new Global Mirror, Metro Mirror, or active-active relationship with volumes in the same clustered system (system), forming an intrasystem Metro Mirror relationship or intersystem relationship (if it involves more than one system).

Syntax

mkrcrelationship -master { master_vdisk_id | master_vdisk_name } -aux { aux_vdisk_id | aux_vdisk_name } -cluster { cluster_id | cluster_name } [ -name new_name_id ] [ -consistgrp { consist_group_id | consist_group_name } ] [ -sync ] { [ -global [ -cyclingmode { none | multi } ] ] | [ -activeactive ] }

Parameters

-mastermaster_vdisk_id | master_vdisk_name

(Required) Specifies the ID or name of the master_vdisk_id or master_vdisk_name.

If a new remote copy relationship is mapped to a host of type hide_secondary, the secondary volume is not presented to the host; however, it is mapped for configuration purposes. The secondary volume is presented to the host if the:

Host type is changed to a type other than hide_secondary
Remote copy relationship is stopped by specifying stoprcrelationship -access
Volume is no longer a secondary volume because the remote copy relationship is deleted or switched

-auxaux_vdisk_id | aux_vdisk_name

(Required) Specifies the ID or name of the aux_vdisk_id or aux_vdisk_name.

-clustercluster_id | cluster_name

(Required) Specifies the ID or name of the remote cluster.

If you are creating an intrasystem relationship, enter the ID of the local system. The volumes in the relationship must belong to the same I/O group within the system.
If you are creating an intersystem relationship, enter the ID of the remote system. To create a relationship in two different systems, the systems must be connected at the time that the mkrcrelationship command is received.

-namenew_name_id

(Optional) Specifies a label to assign to the relationship.

-consistgrpconsist_group_id | consist_group_name

(Optional) Specifies a consistency group that this relationship joins. If you do not supply the -consistgrp parameter, the relationship is created as a stand-alone relationship that can be started, stopped, and switched on its own.

Note: Metro Mirror, Global Mirror, and active-active relationships cannot belong to the same consistency group. When the first relationship is added to the consistency group, the group takes on the same type as the relationship. Then, only relationships of that type can be added to the consistency group.

-sync

(Optional) Specifies that you want the system to create a synchronized relationship. The -sync parameter guarantees that the master and auxiliary disks contain identical data at the point that the relationship is created. You must ensure that the auxiliary disk is created to match the master disk and that no input transactions take place to either disk before you issue the create command. The initial background synchronization is skipped.

-global

(Optional) Specifies that you want the system to create a new Global Mirror relationship. If you do not specify the -global parameter, a Metro Mirror relationship is created instead. You cannot specify this keyword with -activeactive.

-cyclingmodenone | multi

(Optional) Specifies the behavior of Global Mirror for this relationship.

Specifying none, the default, gives identical behavior to Global Mirror in previous versions of Lenovo Storage V series system.
Specifying multi uses the cycling protocol.

The default cycle period is 300 seconds. The cycle period can be modified after the relationship is created by using the chrcrelationship command. To start a relationship with cycling_mode set to multi, change volumes must be defined for the relationship.

Important: This parameter must be specified with -global.

-activeactive

(Optional) Specifies that the relationship is created in an active-active mode. You cannot specify this keyword with -global (this parameter defaults to a Metro Mirror relationship that is being created).

Description

This command creates a new Global Mirror, Metro Mirror, or active-active relationship. A Metro Mirror relationship defines the relationship between two volumes. One volume is a master volume and the other volume is an auxiliary volume. This relationship persists until deleted. The auxiliary volume must be identical in size to the master volume or the command fails. This command also returns the new relationship ID.

The master and auxiliary cannot be in an existing relationship. Any defined FlashCopy mappings that have the proposed master volume as the target of the FlashCopy mapping must be using the same I/O group as the master volume. Any defined FlashCopy mappings that have the proposed auxiliary volume as the target of the FlashCopy mapping must be using the same I/O group as the auxiliary volume.

Note: You cannot create a remote copy relationship with this command if the auxiliary volume is an active FlashCopy mapping target. If the I/O group has enough bitmap space available to allocate for remote copy and the allocated space for the remote copy is not large enough to accommodate the new relationship, space is automatically added. (Remote copy includes Global Mirror, Metro Mirror, and active-active relationships.)

Note: You cannot use this command if cloud snapshot is enabled on the volume or the volume owner type is cloud_backup.

Metro Mirror relationships use one of the following copy types:

A Metro Mirror copy ensures that updates are committed to both the primary and secondary volumes before the copy sends confirmation of I/O completion to the host application. This ensures that the secondary volume is synchronized with the primary volume if a failover operation is performed.
A Global Mirror copy allows the host application to receive confirmation of I/O completion before the updates are committed to the secondary volume. If a failover operation is performed, the host application must recover and apply any updates that were not committed to the secondary volume.

You can optionally give the relationship a name. The name must be a unique relationship name across both systems.

The relationship can optionally be assigned to a consistency group. A consistency group ensures that a number of relationships are managed so if the relationships disconnect, the data in all relationships within the group is in a consistent state. For example, the state can be important in a database application where data files and log files are stored on separate volumes and consequently are managed by separate relationships.

Remember: In the event of a disaster, the primary and secondary sites might become disconnected.

As the disconnection occurs and the relationships stop copying data from the primary to the secondary site, there is no assurance that updates to the two separate secondary volumes stop in a consistent manner if the relationships that are associated with the volumes do not belong to a consistency group.

For proper database operation, it is important that updates to the log files and the database data are made in a consistent and orderly fashion. It is crucial in this example that the log file volume and the data volume at the secondary site are in a consistent state. This can be achieved by putting the relationships that are associated with these volumes into a consistency group. Both Metro Mirror and Global Mirror processing ensure that updates to both volumes at the secondary are stopped, leaving a consistent image based on the updates that occurred at the primary site.

If you specify a consistency group, both the group and the relationship must are created by using the same master system and the same auxiliary system. The relationship must not be a part of another consistency group. If the consistency group is empty, it acquires the type of the first relationship that is added to it. Therefore, each subsequent relationship that you add to the consistency group must have the same type.

If the consistency group is not empty, the consistency group and the relationship must be in the same state. If the consistency group is empty, it acquires the state of the first relationship that is added to it. If the state has an assigned copy direction, the direction of the consistency group and the relationship must match that direction.

If you do not specify a consistency group, a stand-alone relationship is created.

If you specify the -sync parameter, the master and auxiliary volumes contain identical data at the point when the relationship is created. You must ensure that the auxiliary is created to match the master and that no data movement occurs to either volume before you issue the mkrcrelationship command.

If you specify the -global parameter, a Global Mirror relationship is created. Otherwise, a Metro Mirror relationship is created instead.

The volumes that are specified on the -master and -aux parameters cannot be master or auxiliary volumes in an existing relationship.

If you specify -activeactive:

The system that is specified with -cluster must be the local system.
-global must not be specified.
The volume that is specified with -master must:
- Be in an I/O group with both nodes that have the same site name and site ID
- Have all volume copies stored in storage pools in the same site as the volume's I/O group
- Not be the target of a FlashCopy mapping
- Not be the source of any FlashCopy mappings to volumes in a different site or by using bitmap memory from nodes in a different site (but the volume can be the source of a FlashCopy mapping in which the target volume and map are in the same site)
The volume that is specified with -aux must:
- Be part of an I/O group with a different site ID and site name than the master volume (with no volume host mappings that are defined)
- Have all volume copies stored in storage pools in the same site as the volume's I/O group
- Not be the target of a FlashCopy mapping
- Not be the source of any FlashCopy mappings to volumes in a different site or by using bitmap memory from nodes in a different site (but the volume can be the source of a FlashCopy mapping in which the target volume and map are in the same site)

Access the data stored on these volumes by accessing the volume you specify using the -master parameter. Both I/O groups of the volumes that are specified by the -master and -aux parameters have a local physical copy and cache, allowing access (by using the master volume ID) whether the auxiliary volume's site is available or not.

Remember: This command cannot be used on a volume that is owned by a file system.

An invocation example

mkrcrelationship -master vdisk1 -aux vdisk2 -name rccopy1 
 -cluster 0000020063432AFD

The resulting output:

RC Relationship, id [28], successfully created

An invocation example

mkrcrelationship -master vdiskA -aux vdiskB -cluster clusterB -name new_rel -global -cyclingmode multi

The resulting output:

RC Relationship, id [28], successfully created

An invocation example

mkrcrelationship -master volA -aux volB -cluster localCluster -activeactive

The resulting output:

RC Relationship, id [28], successfully created