Computer Drive User Manual

Chapter 12. Metro Mirror overview 131
12.2 Metro Mirror volume state
Volumes participating in a Metro Mirror session can be found in any of the following states:
򐂰 Copy pending: volumes are in
copy pending state after the Metro Mirror relationship is
established, but the primary and secondary volumes are still out of sync. In that case, data
still needs to be copied from the primary to the secondary volume of the Metro Mirror pair.
This may be the case immediately after a relationship is initially established, or
reestablished after being suspended. The Metro Mirror secondary volume is not
accessible when the pair is in copy pending state.
򐂰 Full duplex: a volume copy pair is in
full duplex state when its members are in sync; that
is, both primary and secondary volumes contain exactly the same data. The secondary
volume is not accessible when the pair is in full duplex.
򐂰 Suspended: volumes are in the
suspended state when the primary and secondary storage
subsystems cannot communicate anymore, or when the Metro Mirror pair is suspended
manually. In this state, writes to the primary volume are not mirrored onto the secondary
volume. The secondary volume becomes out of sync.
During this time, Metro Mirror keeps a bitmap record of the changed tracks in the primary
volume. Later, when the volumes are resynchronized, only the tracks that were updated
will be copied.
򐂰 Target copy pending: indicates that the primary volume is unknown or cannot be queried
and the secondary state is copy pending.
򐂰 Target full-duplex: indicates that the primary volume is unknown or cannot be queried and
the secondary state is full duplex.
򐂰 Target suspended: indicates that the primary volume is unknown or cannot be queried and
the secondary state is suspended.
򐂰 Not remote copy pair: indicates that the relationship is not a Metro Mirror pair.
򐂰 Invalid-state: indicates that the relationship state is invalid.
12.3 Data consistency
In order to restart applications at the remote site successfully, the remote site volumes must
have consistent data. In normal operation, Metro Mirror keeps data consistency at the remote
site. However, in case of a rolling disaster type of situation, a certain mechanism is necessary
to keep data consistency at the remote site.
For Metro Mirror, consistency requirements are managed through use of the
Consistency
Group
option. You can specify this option when you are defining Metro Mirror paths between
pairs of LSSs or when you change the default LSS settings. Volumes or LUNs that are paired
between two LSSs whose paths are defined with the Consistency Group option can be
considered part of a Consistency Group.
Consistency is provided by means of the
extended long busy (for z/OS) or queue full (for open
systems) conditions. These are triggered when the DS6000 detects a condition where it
cannot update the Metro Mirror secondary volume. The volume pair that first detects the error
will go into the extended long busy condition, such that it will not do any writes. For z/OS, a
system message will be issued (IEA494I state change message); for open systems, an
SNMP trap message will be issued. These messages can be used as a trigger for automation
purposes that will provide data consistency.