mkrcrelationship

Edit online

Specify the mkrcrelationship command to create a new Global Mirror or Metro Mirror relationship.

Syntax

Parameters

-master master_vdisk_id | master_vdisk_name

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

-aux aux_vdisk_id | aux_vdisk_name

(Required) Specifies the ID or name of the aux_vdisk_id or aux_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

-cluster cluster_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.

-name new_name_id

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

-consistgrp consist_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: 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 requires that the master and auxiliary volumes contain identical data at the point that the relationship is created. You must ensure that the auxiliary volume is created to match the master volume and that no writes take place to either volume before you issue the create command. The initial background synchronization is skipped.

Important: If -sync is used when the contents of the two volumes are not identical, then the secondary volume will not contain a valid, complete copy of the data from the primary volume.

-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.

-cyclingmode none | 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 FlashSystem 7300 .
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.

-migration

(Flag) Specifies a relationship that is being created and used for migrating the master volume to the target system.

Note: Migration relationship parameter is mutually exclusive with:

-consistgrp
-sync
-global
-cyclingmode
-activeactive

Description

This command creates a new remote copy relationship between two volumes for disaster recovery or migration. 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.

Remote copy relationships use one of the following copy types:

An Active-Active type is used for HyperSwap volumes to maintain synchronization between the two copies. This is a synchronous relationship type which ensures that updates are committed to both the primary and secondary volumes before confirmation of the write I/O is completed to the host application. It is capable of automatically switching the direction, suspending and resuming to ensure volumes are highly available.
A Migration copy allows for a volume to be migrated from one system to another. It is a synchronous relationship type that ensures any updates are committed to both the primary and secondary volumes before confirmation of the write I/O is completed to the host application. Both the primary and secondary copies present the same UUID allowing for a non-disruptive migration.
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 be 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.

A Metro Mirror relationship is created if neither the -global or the -migration parameters are specified.

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

Note: This command fails if you attempt to create a Remote Copy relationship with a secondary volume that is in a protected storage pool on a secondary system with volume protection enabled and the secondary volume has received host I/O in the volume protection time period. This check is completed only when both systems are running a software level that includes this validation.

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

Note:

The mkrcrelationship command cannot be used to create an active-active relationship. An active-active relationship is created automatically by the following ways:

Using the management GUI
Using mkvolume command
Adding HyperSwap copy to an existing volume using the GUI or the addvolumecopy command.

An invocation example

mkrcrelationship -master prodVolume12 -aux prodVolume12 -cluster system2 -migration

The resulting output:

No feedback