IBM DS6000 Computer Drive User Manual


 
132 IBM System Storage DS6000 Series: Copy Services with IBM System z
Data consistency, dependent writes, extended long busy, are all discussed in detail in 13.3,
“Consistency Group function” on page 136.
12.4 Rolling disaster
In disaster situations, it is unlikely that the entire complex will fail at the same moment.
Failures tend to be intermittent and gradual, and a disaster can occur over many seconds,
even minutes. Because some data may have been processed and other data lost in this
transition, data integrity on the secondary volumes is exposed. This situation is called a
rolling disaster. The mirrored data at the recovery site must be managed so that
cross-volume or LSS data consistency is preserved during the intermittent or gradual failure.
Metro Mirror itself does not offer a means of controlling this scenario. Instead, it offers the
Consistency Group and Critical attributes, which along with appropriate automation
solutions, can manage data consistency and integrity at the remote site. The Metro Mirror
volume pairs are always consistent, due to the synchronous nature of Metro Mirror; however,
cross-volume or LSS data consistency must have an external management method. IBM
offers the GDPS® and eRCMF service offerings to deliver solutions in this area; refer to
Part 8, “Solutions” on page 431, for more information. You can also visit the IBM Web site and
refer to the Services & Industry Solutions page for more information.
12.5 Automation and management
Metro Mirror is a hardware mirroring solution. A volume (or LUN) is paired with a volume (or
LUN) in the remote disk subsystem. As the size of the environment grows, so does the
complexity of managing it. Therefore, you need a means for managing the pairs, ensuring
they are in duplex status, adding volume pairs as required, monitoring for error conditions,
and more importantly, for managing data consistency across LSS and across disk
subsystems.
When planning a Metro Mirror environment, the following topics should be considered:
Design of the automation solution
Maintenance
Testi ng
Support
All these considerations need to be thought about, because you do not want to be in a
situation where you are relying on your mirroring implementation for data to be consistent in a
disaster situation, only to find that it has not worked, or perhaps worse, you not being aware
that your data is not consistent.
IBM offers services and solutions for the automation and management of the Metro Mirror
environment, which include GDPS and eRCMF. For more information on GDPS and eRCMF
see Part 8, “Solutions” on page 431. You can also visit the IBM Web site and refer to the
Services & Industry Solutions page.
Note: Dduring normal Metro Mirror processing, the data on disk at the secondary site is an
exact mirror of that at the primary site. During or after an error situation this depends on the
options specified for the pair and the path. Remember that any data still in buffers or
processor memory is not yet on disk and so will not be mirrored to the secondary site. A
disaster will then appear to be a similar situation to a power failure in the primary site.