Use 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 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 currently 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 -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. Subsequently, 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.
- 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 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.)
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 sending 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 that, in the event of a disconnection of the relationships, the
data in all relationships within the group is in a consistent state.
This can be important in, for example, a database application where
data files and log files are stored on separate volumes and consequently
are managed by separate relationships. 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 will stop in a consistent manner
if the relationships that are associated with the volumes are not
in 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 have
been created 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 specified with -cluster must be
the local system.
- -global must not be specified.
- The volume specified with -master must:
- Be in an I/O group with both nodes having 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 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 in an I/O group with a different site ID and site name to the master volume, and must not
have any volume host mappings 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 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
specified by the
-master parameter. Both I/O
groups of the volumes specified by the
-master and
-aux parameters
have a local physical copy and cache, allowing access (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