IBM Storwize V7000, Introduction And Implementation Manual

Page: 437 / 670

Chapter 9. IBM Flex System V7000 Storage Node Copy Services
417
Interaction between Remote Copy and FlashCopy
Table 9-5 lists which combinations of FlashCopy and Remote Copy are supported.
Table 9-5 FlashCopy and Remote Copy interaction
If you are not using Global Mirror with Change Volumes, you can, for disaster recovery
purposes, use the FlashCopy feature to create a consistent copy of an image before you
restart a Global Mirror relationship.
When a consistent relationship is stopped, the relationship enters the consistent_stopped
state. While in this state, I/O operations at the primary site continue to run. However, updates
are not copied to the secondary site. When the relationship is restarted, the synchronization
process for new data is started. During this process, the relationship is in the
inconsistent_copying state.
The secondary volume for the relationship cannot be used until the copy process completes
and the relationship returns to the consistent state. When this situation occurs, start a
FlashCopy operation for the secondary volume before you restart the relationship. While the
relationship is in the Copying state, the FlashCopy feature can provide a consistent copy of
the data. If the relationship does not reach the synchronized state, you can use the
FlashCopy target volume at the secondary site.
9.4 Troubleshooting Remote Copy
Remote Copy (Global Mirror and Metro Mirror) has two primary error codes: 1920 or 1720. A
1920 error is a congestion error. This error means that either the source, the link between
source and target, or the target were not able to keep up with the rate of demand. A 1720
error is a heartbeat or cluster partnership communication error. This error tends to be more
serious, as failing communication between your cluster partners involves some extended
diagnostic time.
Component Remote Copy primary site Remote Copy secondary site
FlashCopy source Supported Supported.
When the FlashCopy
relationship is in the Preparing
and Prepared states, the cache
at the Remote Copy secondary
site operates in write-through
mode. This process adds
additional latency to the already
latent Remote Copy
relationship.
FlashCopy destination This combination is supported.
It has several restrictions:
򐂰 Issuing stop -force might
cause the Remote Copy
relationship to fully
resynchronize.
򐂰 The code level must be
Version 6.2.x or higher.
򐂰 The I/O group must be
the same.
This combination is supported
with the restriction that the
FlashCopy mapping cannot be
copying, stopping, or
suspended. Otherwise, the
restrictions are the same as at
the Remote Copy primary site.