Cisco MDS 9000 Family SAN Volume Controller Configuration Guide
Configuring Copy Services
Download this chapter
Configuring Copy ServicesConfiguring Copy Services
 Feedback

Table Of Contents

Configuring Copy Services

Data Migration

Data Migration Application

Data Migration Operation

Migrating VDisks between MDisk groups

FlashCopy

FlashCopy Applications

FlashCopy Mapping

FlashCopy Consistency Groups

Starting the FlashCopy

Stopping FlashCopy

Remote Copy

Disaster Recovery

Remote Copy Relationships

Remote Copy Consistency Groups

Configuring Remote Copy

Starting Remote Copy

Stopping Remote Copy

Failover and Recovery Process


Configuring Copy Services

The SVC copy services function available in all Cisco MDS 9216 switches and directors in the Cisco MDS 9500 Family enables you to copy virtual Disks (VDisks). These copy services include data migration, FlashCopyTM, and Remote Copy.

This chapter includes the following sections:

•Data Migration

•FlashCopy

•Remote Copy

Data Migration

The Data Migration feature allows you to change the mapping of VDisk extents to MDisk extents without interrupting a host's access to that VDisk.

Data Migration Application

You can perform data migration on any VDisk managed by the SVC for the following purposes:

•Redistributing workload within a Cluster across back-end storage.

•Moving workload onto newly installed storage.

•Moving workload off old/failing storage

•Moving workload to rebalance a changed workload

•Migrating in data from legacy back-end storage to SVC managed storage

Data Migration Operation

After a data migration, the virtualisation policy of the VDisk is set to striped. When you request an operation which requires some migration activity, SVC checks that sufficient suitable free extents exist to complete the requested migration operation. If this is not the case then the migration will not be started and the configuration command fails. However, once the operation starts, SVC does not reserve free extents for the future use of the migration activity. This means that another migration activity can be started to contend for free extents with existing migrations. If this happens, and no suitable free extent is available to proceed with the migration, then the migration operation fails. The implications of this are that migration between MDisk groups will normally be suspended and all other types of migration is normally stopped.

Migrating VDisks between MDisk groups

To migrate VDisks from one managed MDisk group to another MDisk group, follow these steps.

Step 1 Create a cluster and the required VDisks (see "Creating and Managing Clusters").

Step 2 Display the configured VDisks in the newly-created cluster (called SampleCluster). 

switch(svc)# show cluster SampleCluster vdisk 

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

Name             Capacity     iogroup mdisk-grp name    Policy      Status

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

fn-data          1.00 GB      1       finance1          striped     online

fn-log           1.00 GB      1       finance1          striped     online

switch(svc)#

Step 3 Create the new MDisk group to migrate the VDisks (see "Managing Back-End Storage").

Step 4 Display the configured MDisk group (called finance2). 

switch(svc)# show cluster SampleCluster mdisk-grp finance2

mdisk-grp finance2 is online

    Total capacity is 17.08 GB 

    Free capacity is 17.08 GB 

    Extent size is 16 MB

    Number of mdisks is 1

    Number of vdisks using this group is 0

Tip In order to migrate a VDisk from its existing MDisk group to a new one MDisk group, both the MDisk groups must have the same extent size.

Step 5 Enter the cluster configuration submode for the cluster called SampleCluster. 

switch(svc)# cluster config SampleCluster

switch(svc-cluster)#

Step 6 Issue the migration command to the new MDisk group. 

switch(svc-cluster)# migrate vdisk fn-data new-mdisk-grp finance2

switch(svc-cluster)# migrate vdisk fn-log new-mdisk-grp finance2

switch(svc-cluster)#

Step 7 Exit to the svc-config submode 

switch(svc-cluster)# exit

switch(svc)#

Step 8 Check the progress of the migration by issuing the status command. 

switch(svc)# show cluster SampleCluster status migration 

        migrating vdisk fn-data to mdisk grp finance2 : 68%

        migrating vdisk fn-log to mdisk grp finance2 : 0%

switch(svc)#

Step 9 Verify that the migration has completed, by using the show VDisk command. The mdisk-grp name column should have the new MDisk group name. 

switch(svc)# show cluster SampleCluster vdisk 

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

Name             Capacity     iogroup mdisk-grp name    Policy      Status

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

fn-data          1.00 GB      1       finance2          striped     online

fn-log           1.00 GB      1       finance2          striped     online

switch(svc)#

FlashCopy

FlashCopy copies a set of source VDisks to a set of target VDisks. The original contents of the target VDisks are lost. After the copy operation is completed, the target VDisks have the contents of the source VDisks as they existed at a single point-in-time, when the FlashCopy was started. Although the copy operation takes a finite amount of time to complete, the resulting data at the target appears as if the copy was made instantaneously. FlashCopy is sometimes described as an instance of a Time-Zero copy (T0) or point-in-time copy technology. This time is much less than the time required to copy the same data using conventional techniques.

Point-in-time copy techniques are used to help solve the problem of making a consistent copy of a data set which is being constantly updated. If a copy of a data set is taken using a technology which did not provide point-in-time semantics and the data set changes during the copy operation then the resulting copy may contain data which is not consistent with the latest version.

FlashCopy Applications

The following list provides some examples of using FlashCopy services:

•An important use of FlashCopy service is for taking consistent backups of changing data. In this usage, a FlashCopy is created in order to capture a point-in-time and the resulting image is backed up to tertiary storage such as tape. In this case the FlashCopy target is primarily treated as read only although a few writes are occasionally involved.

•Another use of FlashCopy is for application testing. In a business setting it is often important to test a new version of an application on real business data prior to updating the production copy of the software. This reduces the risk of the software upgrade failing because it is incompatible with the actual data in use at the time of the update. This application requires read/write access to the FlashCopy target.

•Other uses of FlashCopy in the business environment include creating copies for auditing purposes and for data mining.

•In the scientific and technical arena one way in which FlashCopy is employed is to create restart points for long running batch jobs. This means that if a batch job fails many days into its run it may be possible to restart the job from a saved copy of its data rather than re-running the entire multi-day job.

FlashCopy Mapping

FlashCopy mapping is done between a source VDisk and a target VDisk. The VDisks must be the same size. FlashCopying part of a VDisk is not supported. The source and target VDisks must both be managed by the same SVC cluster but may be in different I/O groups within that cluster.

Each VDisk may be a member of only one FlashCopy mapping. VDisks participating in FlashCopy mapping cannot have their size increased or decreased while they remain participants of the FlashCopy mapping.

FlashCopy Consistency Groups

A FlashCopy consistency group contains a number of FlashCopy mappings. A consistency group can contain an arbitrary number of FlashCopy mappings up to the maximum number of FlashCopy mappings supported by a SVC cluster. When the start command is issued for a consistency group, all of the FlashCopy mappings in the consistency group are started at the same time, resulting in a point-in-time copy which is consistent across all of the FlashCopy mappings which are contained in the consistency group.

The FlashCopy function accepts one of two mode to copy the source VDisk contents to the destination VDisk—full or copy-on-write.

•Full mode—The source VDisk is copied to the destination VDisk even if the source VDisk is not changed after the FlashCopy operation is started. The copy process is implemented at the rate specified by the rate parameter (see Table 7-1).

Table 7-1 Copy Rate Translation

Copy-rate
KB/sec.

1-10

128

11-20

256

21-30

512

41to50

2048

91 to 100

64MB


•Copy-on-write mode—The source VDisk is only copied to the destination VDisk if the source VDisk is changed (by a write operation) after the FlashCopy operation is started.

To configure consistency groups, follow these steps.

Step 1 Create the source, and target VDisks for FlashCopy ("Managing Virtual Disks").

Step 2 Verify the VDisk configuration. 

switch(svc)# show cluster SampleCluster vdisk 

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

Name             Capacity     iogroup mdisk-grp name    Policy      Status

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

fndata-snapshot  1.00 GB      1       finance           striped     online

fnlog            2.00 GB      1       finance           striped     online

fnlog-snapshot   2.00 GB      1       finance           striped     online

fndata           1.00 GB      1       finance           striped     online

Note The target VDisk, and the source VDisk in a FlashCopy mapping need to be of same size.

Step 3 Enter the cluster configuration submode 

switch(svc)# cluster config SampleCluster

switch(svc-cluster)#

Step 4 Enable the FlashCopy feature. 

switch(svc-cluster)# feature enable flash-copy

Note The FlashCopy feature must be licensed and enabled before configuring any FlashCopy mappings.

Step 5 Create a FlashCopy consistency group. 

switch(svc-cluster)# flash-copy add fcgrp

Step 6 Enter the FlashCopy consistency group submode 

switch(svc-cluster)# flash-copy name fcgrp

switch(svc-cluster-flash-copy)#

Step 7 Map the source VDisk to the target VDisk. 

switch(svc-cluster-flash-copy)# map src-vdisk fnlog dst-vdisk fnlog-snapshot

switch(svc-cluster-flash-copy)# map src-vdisk fndata dst-vdisk fndata-snapshot

Step 8 Refer to Table 7-1 and obtain the required copy rate. The copy rate specifies the rate of background copy. It is expressed as a percentage, and its translation to bandwidth is given below. If the optional copy rate is not configured, a default rate of 50 is configured. This example uses the full mode with a copy rate of 90.

Step 9 Configure the copy rate for the FlashCopy group. 

switch(svc-cluster-flash-copy)# mode full rate 90

Step 10 Exit to the SVC configuration submode 

switch(svc-cluster-flash-copy)# exit

switch(svc-cluster)# exit

switch(svc)#

Step 11 Verify the FlashCopy configuration. 

switch(svc)# show cluster SampleCluster flash-copy fcgrp

Flash-copy mapping 1:

    src vdisk is fnlog

    dest vdisk is fnlog-snapshot

    state is idle_or_copied

    copy rate is 90

    progress 0% done


Flash-copy mapping 2:

    src vdisk is fndata

    dest vdisk is fndata-snapshot

    state is idle_or_copied

    copy rate is 90

    progress 0% done


Starting FlashCopy

Step 12 Refer to the "Starting the FlashCopy" section to start the FlashCopy configuration.

Starting the FlashCopy

You can only start the FlashCopy process if you have configured a consistency group as specified in the "FlashCopy Consistency Groups" section.

To start the FlashCopy process, follow these steps:

Step 1 Check the status of the FlashCopy consistency group. 

switch(svc)# show cluster SampleCluster flash-copy 

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

Name             Status

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

fccstgrp0        idle_or_copied    

fcgrp            idle_or_copied

Step 2 Issue the cluster name cluster-name flash-copy fcgrp prepare command to prepare the source and target VDisks for FlashCopy. This will flush the cache of any data destined for the source VDisk and force the cache into write through until the FlashCopy is started. 

switch(svc)# cluster name SampleCluster flash-copy fcgrp prepare

Step 3 Check the status of the FlashCopy consistency group, to make sure that the prepare operation is completed. If the prepare operation is completed, the status for the group will be prepared. If the prepare operation is not completed, wait till it completes. 

switch(svc)# show cluster SampleCluster flash-copy 

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

Name             Status

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

fccstgrp0        idle_or_copied    

fcgrp            prepared

Step 4 Once, the FlashCopy consistency group is prepared for FlashCopy, issue the cluster name cluster-name flash-copy fcgrp start command to start the FlashCopy. This makes a point-in-time copy of the source VDisk the moment the command is executed. 

switch(svc)# cluster name SampleCluster flash-copy fcgrp start

Step 5 Check the progress of the FlashCopy operation. 

switch(svc)# show cluster SampleCluster status flash-copy fcgrp

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

src vdisk        dest vdisk       progress

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

fnlog            fnlog-snapshot   46%

fndata           fndata-snapshot  6%

If the progress fields indicate 100%, for all the mappings in the FlashCopy consistency group, then the FlashCopy is completed.

Stopping FlashCopy

A FlashCopy, once started, can be stopped by issuing the cluster name cluster-name flash-copy fcgrp stop command. Once stopped, use the cluster name cluster-name flash-copy fcgrp prepare command for the FlashCopy group before it is started.

Remote Copy

Remote copy is a feature that seeks to maintain two copies of a data set. The relationship between the two copies is not symmetric. One copy of the data set is considered the primary copy—or the source. This copy provides the reference for normal run-time operation. Updates to this copy are shadowed to a secondary copy—or the auxiliary. The secondary copy is not normally referenced for performing I/O.

This release of SVC supports synchronous remote copy. Synchronous remote copy ensures that updates are committed at both primary and secondary before the application is given completion to an update. This ensures that the secondary is fully up-to-date should it be needed in a failover. However, this means that the application is fully exposed to the latency and bandwidth limitations of the communication link to the secondary.

Disaster Recovery

If the primary copy fails, you can enable the secondary copy for I/O operation. A typical use of this function may involve two sites where the first provides service during normal running and the second is only activated when a failure of the first site is detected.

The secondary copy is not accessible for application I/O other than the I/Os that are performed for the remote copy process itself.

Enabling the secondary copy for active operation require some SVC, operating system and possibly application specific configuration.

Enabling the secondary copy needs to be performed as part of the entire failover process. The SVC cluster at the secondary must be instructed to Stop the relationship which will have the affect of making the secondary logical unit accessible for normal I/O access. The operating system might need to mount file systems. The application might have some log of work to recover.

Remote Copy Relationships

A remote copy relationship consists of two VDisks—a source VDisk and an auxiliary VDisk. In the most common use of remote copy the source VDisk contains a production copy of the data and is the VDisk that normally used by an application. The auxiliary VDisk contains a backup copy of the data and is used in disaster recovery scenarios.

Both VDisks in a remote copy relationship must be of the same size.

Both VDisks can be in the same cluster (and consequently, the same I/O group). Optionally, the VDisks can come from two clusters that are configured to recognize each other and can be in any I/O group in each of those two clusters.

Each VDisk in a remote copy relationship takes on a specific role, behaving as a primary or a secondary. A primary VDisk contains a valid copy of application data and is accessible for application write I/O. A secondary VDisk contains a valid copy of application data but is not available for application write I/O.

Remote Copy Consistency Groups

Certain uses of remote copy require the manipulation of more than one relationship. Remote copy provides the ability to group relationships so that they are manipulated in unison. For some uses it might be that the relationships share a loose association and that the grouping simply provides a convenience for the administrator. But a more significant use arises where the relationships contain VDisks that have a tighter association. For example, if an application's data is spread across more than one VDisk. A more complex example is where multiple applications run on different host systems, where each application has data on different VDisks, and these applications exchange data with each other.

A consistency group can contain zero or more relationship. All relationships in a consistency group must have matching source and auxiliary clusters.

Configuring Remote Copy

To configure remote copy, follow these steps.

Note In this example, we choose separate local, and remote clusters, although they can be the same cluster.

Step 1 Create the local, and remote cluster (see "Creating and Managing Clusters").

Step 2 Create the Virtual Disks in the local, and remote cluster that form part of the remote copy relationship ("Managing Back-End Storage"). 

local-switch(svc)# show cluster local-cluster vdisk 

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

Name             Capacity     iogroup mdisk-grp name    Policy      Status

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

fndata-src       2.00 GB      1       finance           striped     online

fnlog-src        1.00 GB      1       finance           striped     online


remote-switch(svc)# show cluster remote-cluster vdisk 

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

Name             Capacity     iogroup mdisk-grp name    Policy      Status

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

fnlog-aux        1.00 GB      1       finance           striped     online

fndata-aux       2.00 GB      1       finance           striped     online

Step 3 Enter the cluster config submode of the local cluster 

local-switch(svc)# cluster config local-cluster

local-switch(svc-cluster)#

Step 4 Enable the remote copy feature in the local cluster 

local-switch(svc-cluster)# feature enable remote-copy 

local-switch(svc-cluster)#

Note The remote copy feature must be licensed and enabled before configuring remote copy.

Step 5 Enter the cluster config submode of the remote cluster 

remote-switch(svc)# cluster config remote-cluster

remote-switch(svc-cluster)#

Step 6 Enable the remote copy feature in the remote cluster 

remote-switch(svc-cluster)# feature enable remote-copy 

remote-switch(svc-cluster)#

Step 7 Establish a remote copy partnership with the remote cluster at the local cluster. 

local-switch(svc-cluster)# remote-copy cluster remote-cluster

local-switch(svc-cluster)#

Step 8 Establish a remote copy partnership with the local cluster at the remote cluster. 

remote-switch(svc-cluster)# remote-copy cluster local-cluster

remote-switch(svc-cluster)#

Step 9 Create a remote copy consistency group in the local cluster. 

local-switch(svc-cluster)# remote-copy add rcgrp cluster remote

local-switch(svc-cluster)#

Step 10 Enter the remote copy consistency group submode in the local cluster. 

local-switch(svc-cluster)# remote-copy name rcgrp

local-switch(svc-cluster-remote-copy)#

Step 11 Create remote copy relationships between the source VDisks, and auxiliary VDisks, under the remote copy consistency group. 

local-switch(svc-cluster-remote-copy)# map src-vdisk fndata-src aux-vdisk fndata-aux 

local-switch(svc-cluster-remote-copy)# map src-vdisk fnlog-src aux-vdisk fnlog-aux 

local-switch(svc-cluster-remote-copy)#

Step 12 Return to the svc-config submode in the local switch. 

local-switch(svc-cluster-remote-copy)# exit

local-switch(svc-cluster)# exit

local-switch(svc)#

Step 13 Verify the remote copy consistency group configuration. 

local-switch(svc)# show cluster local-cluster remote-copy rcgrp

Remote-copy mapping 1:

    master cluster is local-cluster

    master vdisk is fndata-src

    aux cluster is remote-cluster

    aux vdisk is fndata-aux

    status is inconsistent_stopped

    progress 0% done


Remote-copy mapping 2:

    master cluster is local-cluster

    master vdisk is fnlog-src

    aux cluster is remote-cluster

    aux vdisk is fnlog-aux

    status is inconsistent_stopped

    progress 0% done


local-switch(svc)#

Starting Remote Copy

Once the remote copy configuration is completed for a consistency group, start (activate) the remote copy relationships by issuing the start command. This command triggers the background copy from the corresponding source VDisks to the auxiliary VDisks respectively. Any subsequent writes issued to a particular source VDisk are also mirrored in the corresponding auxiliary VDisk, in the remote copy relationship.

To start remote copy relationships, follow these steps:

Step 1 Enter the svc-config submode in the local switch. 

local-switch# svc-config 

local-switch(svc)#

Step 2 Issue the start command for the remote copy consistency group to activate the remote copy relationships in the consistency group. 

local-switch(svc)# cluster name local-cluster remote-copy rcgrp start 

local-switch(svc)#

Step 3 Check the progress of the remote copy by issuing the Status command. 

local-switch(svc)# show cluster local-cluster status remote-copy rcgrp

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

src vdisk        dest vdisk       progress

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

fndata-src       fndata-aux       8%

fnlog-src        fnlog-aux        16%

local-switch(svc)#

Step 4 Once, the background copy of the data in source VDisks to auxiliary VDisks are completed, the status of all the relationships in the consistency group will be consistent_synchronized, and the auxiliary VDisks will be up to date with the corresponding source VDisks. 

local-switch(svc)# show cluster local-cluster remote-copy rcgrp

Remote-copy mapping 1:

    master cluster is local-cluster

    master vdisk is fndata-src

    aux cluster is remote-cluster

    aux vdisk is fndata-aux

    status is consistent_synchronised

    progress 100% done


Remote-copy mapping 2:

    master cluster is local-cluster

    master vdisk is fnlog-src

    aux cluster is remote-cluster

    aux vdisk is fnlog-aux

    status is consistent_synchronised

    progress 100% done


local-switch(svc)#

Stopping Remote Copy

Use the stop command to suspend the remote copy relationships in a consistency group. Subsequently, the writes issued to a source VDisk, in a relationship, are not reflected at the corresponding auxiliary VDisk. 

local-switch(svc)# cluster name local-cluster remote-copy rcgrp stop

local-switch(svc)#

Failover and Recovery Process

When remote copy relationships are active during a normal operation, the source VDisks in the relationships are fully accessible, and the auxiliary VDisks are not available for write operations.

After a failure in the local (master) cluster, you must stop the remote copy relationship using the aux-enable option, to allow write access to the auxiliary VDisks in the remote cluster. 

remote-cluster(svc)# cluster name remote-cluster remote-copy rcgrp stop aux-enable 

remote-cluster(svc)#

If the local cluster comes back up, the administrator can choose to resume the remote copy relationships in one of two ways.

•Resume the remote copy relationships with the local cluster acting as the primary or master of the relationships.

•Resume the remote relationships with the remote cluster acting as the primary or master of the relationships. In either case, the force option is required when you resume the remote copy—background copy is required to make the source VDisks, and auxiliary VDisks up to date.

The following command resumes the remote copy relationships in the consistency group with the local cluster as the primary. 

local-cluster(svc)# cluster name local-cluster remote-copy rcgrp start force

local-cluster(svc)#

The following commands resume the remote copy relationships in the consistency group with the remote cluster as the primary, by enabling the aux option in the start command. 

remote-cluster(svc)# cluster name remote-cluster remote-copy rcgrp start aux force

remote-cluster(svc)#

Verify the primary configuration for a remote copy consistency group using the show remote-copy command. The Primary column indicate whether the auxiliary VDisks or source VDisks have the primary (or master) role. 

remote-cluster(svc)# show cluster remote-cluster remote-copy 

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

Name             Remote Cluster   Mappings Primary Status

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

rcgrp            remote           2        aux     consistent_synchronised

remote-cluster(svc)#