This section contains some guidelines and recommendations that you should consider before you use the point-in-time function (FlashCopy) and remote mirror and copy features such as Metro Mirror, Global Copy, and Global Mirror.
Before you can use Copy Services functions, you must obtain the feature activation keys by connecting to the IBM Disk Storage Feature Activation (DSFA) Web site at http://www.ibm.com/storage/dsfa. After you obtain the feature activation keys, you must enter them in the DS Storage Manager Web interface. This allows you to use the licensed features (remote mirror and copy and point-in-time copy) of Copy Services. The activation keys are required for both the source and target storage units for the remote mirror and copy feature.
You can use either the DS Storage Manager or DS CLI interfaces to manage Copy Services functions.
Point-in-time function (FlashCopy)
FlashCopy® operations provide the ability to create point-in-time copies. As soon as the FlashCopy operation is processed, both the source and target volumes are available for application use.
- Identify the source volumes and target volumes for FlashCopy relationships. You should select FlashCopy target volumes in different ranks for better performance.
- Create a FlashCopy relationship without a background copy. This option allows for a more efficient use of the storage unit's resources when a physical copy of the source volume is not needed.
- Identify the LSSs that contain the desired source volumes and target volumes. Distribute the FlashCopy pairs evenly across LSSs for better performance.
- Understand FlashCopy data
consistency considerations. There are environments where data is stored in
server memory cache and written to disk at some later time. Buffers for a
database management subsystem (DBMS) or metadata for a journaled file system
are two examples of these environments. If a FlashCopy operation copies a source
volume to a target volume but buffers from the DBMS or metadata from the journaled
file system are not flushed first, you might have to perform an incremental
update. For a DBMS, you might have to back out of current transactions. For
a journaled file system, you might have to run the fsck utility
on the target volume.
To avoid these types of restart actions, ensure that all data that is related to the FlashCopy source volume has been written to disk before you perform the FlashCopy operation. For a DBMS, you can quiesce the subsystem or use a DBMS command such as DB2’s LOG SUSPEND. For a journaled file system, you can unmount the source volume before you perform a FlashCopy operation.
Note: If you are going to automate your FlashCopy procedures, consider verifying the data consistency on your target volumes frequently. On some systems, such as AIX®, Windows®, and Linux®, before performing FlashCopy operations, you must quiesce your applications that access FlashCopy source volumes. The source volumes must then be unmounted during the FlashCopy establishment. This is to ensure that there is no data in the buffers that could be flushed to the target volumes and potentially corrupt them. - You can establish multiple FlashCopy relationships (up to 12) at one time using the same source volume. Among all the FlashCopy relationships using the same source volume, only one can be an incremental FlashCopy.
- You can use an existing Metro Mirror source volume as a FlashCopy target volume. This allows you to create a point-in-time copy using a target volume of a FlashCopy pair and then mirror that data to a source Metro Mirror volume at a remote location.
Remote mirror and copy functions
- The source and target volumes in a Metro Mirror relationship must be the same storage type: fixed block or count-key data.
- The source and target logical volumes must be the same size or the target must be larger in size to establish a FlashCopy or Metro Mirror relationships.
- Ensure that you have a sufficient number of FCP paths established between
the source and target site logical subsystems. This is especially important
in configurations where the same logical subsystems manage both source and
target volumes.
In addition, if you plan to use functions such as Metro Mirror and Global Copy modes between a pair of storage units, establish separate logical paths over separate physical paths for the copy pairs managed by each of the modes. In other words, for your Metro Mirror copy pairs, use one set of logical and physical paths between the source and target LSSs. For your Global Copy copy pairs, use another set of logical and physical paths between the source and target storage units. By keeping the paths separate for the two copy modes, the updates to Global Copy target volumes minimize the effect on the I/O performance of the Metro Mirror pairs. This recommendation applies only to environments where the distance between source and target storage units do not exceed the synchronous range.
- For Metro Mirror environments, distribute the work loads by not directing all updates to a small set of common volumes on a single target storage unit. The performance impact at the target site storage unit adversely affects the performance at the source site.
- If you plan to use Global Mirror,
consider the following guidelines:
- FlashCopy is required at the remote site if you are planning to return control to your local site using Global Mirror after a planned or unplanned outage.
- An LSS to LSS association must be established with the master for each subordinate storage unit that is available on the master storage unit.
After determining that your system meets the requirements for running Global Mirror, you must set up your environment for this processing.
Figure 1 shows what a typical Global Mirror configuration looks like.
