Metro Mirror

Setting up multiple Copy Services Manager sessions with DS8000 Metro Mirror pairs

Starting with the Copy Services Manager 6.2.0 release, it is now possible to set up multiple Copy Services Manager sessions with DS8000 Metro Mirror pairs. By performing this set up, a suspend by command or event suspends the sessions consistently by freezing all sessions before thawing any session, according to the session policy.

Metro Mirror Single Direction

Figure 1 illustrates a Metro Mirror Single Direction session.

TVT Instructions: This graphic was updated for Copy Services Manager 6.2.1 frg_i_metro_mirror_v2.jpg. To capture this graphic from the Copy Services Manager GUI, click Sessions > Click Create Session > In the Create Session window, select a storage system other than XIV in the Choose Hardware Type list > In the Choose Session Type list, select Metro Mirror Single Direction.

Metro Mirror Failover/Failback

Using Metro Mirror Failover/Failback, the data exists on the second site, which is less than 300 KM away, and you can switch the direction of the data flow. You can use this session type to run your business from the secondary site, and to copy changes that are made at the second site back to the primary site when you want to resume production at the primary site.

Figure 2 illustrates a Metro Mirror with Failover/Failback session.

TVT Instructions: This is same graphic as previous.

Metro Mirror Failover/Failback with Practice

A Metro Mirror Failover/Failback with Practice session combines Metro Mirror and FlashCopy® features to provide a point-in-time copy of the data on the remote site. You can use this session type to practice what you might do if a disaster occurs, without losing your disaster recovery capability.

This solution consists of two host volumes and an intermediate volume.

Figure 3 illustrates a Metro Mirror Failover/Failback with Practice session.

TVT Instructions: This graphic was updated for Copy Services Manager 6.2.1 frg_i_metro_mirror_pract_v2.jpg. To capture this graphic from the Copy Services Manager GUI, click Sessions > Click Create Session > In the Create Session window, select a storage system other than XIV in the Choose Hardware Type list > In the Choose Session Type list, select Metro Mirror Failover/Failback w/Practice.

Metro Mirror Failover/Failback with HyperSwap

You can enable a Metro Mirror Failover/Failback session to have HyperSwap® capabilities. To enable HyperSwap processing, see Setting up the environment for HyperSwap.

Metro Mirror Failover/Failback with HyperSwap combines the high availability of Basic HyperSwap with the redundancy of a two-site Metro Mirror Failover/Failback solution for managing count key data (CKD) volumes on z/OS. If the primary volumes encounter a permanent I/O error, the I/O is automatically swapped to the secondary site with minimal effect on the application.

A swap can be planned or unplanned. A planned swap occurs when you issue a HyperSwap command from the Session Actions list in the graphical user interface (GUI) or when you issue a cmdsess -action hyperswap command.

Figure 4 illustrates a Metro Mirror Failover/Failback session that is enabled for HyperSwap.

TVT Instructions: This graphic was updated for Tivoli Storage Productivity Center for Replication 5.2.1, swapcapable.jpg. To capture this graphic from the TPC-R GUI, the TPC-R server must be on or attached to a z/OS host. Click Sessions > Click Create Session > In the Create Session window, select DS8000, DS6000, or ESS in the Choose Hardware Type list > In the Choose Session Type list, select Basic HyperSwap.

Metro Mirror Failover/Failback with Open HyperSwap

You can enable a Metro Mirror Failover/Failback session to have Open HyperSwap capabilities. To enable Open HyperSwap processing, see Setting up the environment for Open HyperSwap.

Metro Mirror Failover/Failback with Open HyperSwap combines the high availability of Basic HyperSwap on z/OS for fixed-block AIX® volumes with the redundancy of a two-site Metro Mirror Failover/Failback solution. If the primary volumes encounter a permanent I/O error, the I/O is automatically swapped to the secondary site with minimal effect on the application.

A swap can be planned or unplanned. A planned swap occurs when you issue a HyperSwap command from the Session Actions list in the GUI or when you issue a cmdsess -action hyperswap command.

Figure 5 illustrates a Metro Mirror Failover/Failback session that is enabled for Open HyperSwap.

TVT Instructions: This is same graphic as previous.

Metro Mirror - Metro Mirror

A Metro Mirror - Metro Mirror session is a multi-target session that consists of three sites. You can define any of the sites as the primary site and then run Metro Mirror replication from the primary site to either of the other sites individually or both sites simultaneously. For example, if Site 1 is the primary site, data replication can occur between the H1 and H2 volumes and the H1 and H3 volumes separately or at the same time.

This session type is available only for IBM DS8000® storage systems with a microcode level that supports single source to multi-target relationships. To determine whether you can use this session type, refer to the IBM DS8000 documentation for the microcode level that you are using.

Figure 6 illustrates a Metro Mirror - Metro Mirror session.

TVT Instructions: This graphic is new for Copy Services Manager 6.2.1 frg_i_mm_mm_v2.jpg. This graphic is not available in the 6.2.1 GUI . To capture this graphic from the Copy Services Manager 6.2.1 GUI, click Sessions > Click Create Session > In the Create Session window, select DS8000, DS6000, ESS 800 in the Choose Hardware Type list > In the Choose Session Type list, select Metro Mirror - Metro Mirror.

Examples

Read the following scenarios for information on using Metro Mirror for synchronous, remote data replication between two sites.

Metro Mirror Single Direction

At the beginning of a work week, Jane is notified that between 10:00 AM and 11:00 AM on the next Friday, power in her building is going to be shut off. Jane does not want to lose any transactions during the power outage, so she decides to transfer operations to the backup site during the outage. She wants a synchronous copy method with no data loss for the critical business functions, so she chooses Metro Mirror, which can be used between locations that are less than 300 KM apart.

In a synchronous copy method, when a write is issued to change the source, the change is propagated to the target before the write is posted. This method of replication maintains identical data in both the source and target. The advantage of this method is when a disaster occurs, there is no data loss at the recovery site because both writes must complete before signaling completion of a write to the source application. Because the data must be copied to both IBM DS8000 devices before the write is completed, Jane can be sure that the data is safe.

The night before the planned outage, Jane quiesces the database and servers in San Francisco and starts the database and servers in Oakland. To accomplish this task, Jane issues the Suspend and Recover commands, and then issues the Start command on the secondary site. She shuts down the equipment in San Francisco to avoid any power spikes when she restarts the system after the power is turned on.

Metro Mirror in Global Copy mode

At the beginning of a work week, Jane is notified that between 10:00 AM and 11:00 AM on the next Friday, power in her building is going to be shut off. Jane does not want to lose any transactions during the power outage, so she decides to transfer operations to the backup site during the outage. She wants a synchronous copy method with no data loss for the critical business functions, so she chooses Metro Mirror, which can be used between locations that are less than 300 KM apart.

Jane wants to limit the effect on any applications while completing the initial Metro Mirror synchronization, so she begins the session in Global Copy mode. After she sees that approximately 70% of the data is copied, Jane decides to switch the session to Metro Mirror mode, assuring data consistency.

Metro Mirror with Practice

Jane wants to run a Metro Mirror with Practice from San Francisco to Oakland. She wants to verify the recovery procedure for the Oakland site, but she cannot stop running the Metro Mirror session while she takes time to practice a recovery. By using a Metro Mirror with Practice session, Jane can practice the disaster recovery scenario in Oakland while the Metro Mirror session runs uninterrupted. By practicing running the applications at the Oakland site, Jane is better prepared to recover data if a disaster occurs at the San Francisco site.

While her session is running in Prepared state, Jane practices a recovery at the Oakland site by issuing the Flash command. This command momentarily pauses the session and starts a FlashCopy to the H2 volumes. As soon as the FlashCopy is started, the session is restarted. These FlashCopy files create a consistent version of the data on the H2 volume that she can use for recovery testing, while the session continues to replicate data from San Francisco to Oakland. As a result, she can carry out the recovery testing without stopping the replication for any extended duration of time.

If, at some point, the Metro Mirror session is suspended because of a failure, Jane can use the practice session to restart the data replication process. She maintains a consistent copy of the data at the Oakland site, in case of a failure during the resynchronization process. When the session is suspended, she can issue a Recover command to create a consistent version of the data on the H2 volumes. After the Recover command completes, she can issue the Start H1->H2 command to resynchronize the data from the San Francisco site to the Oakland site.

If a failure occurs before the restarted session is in Prepared state, she has a consistent version of the data on the H2 volumes. She only has to issue the Recover command to put the session into Target Available state and make the H2 volumes accessible from the servers. If the session was not in Prepared state when it was suspended, the subsequent Recover command does not issue the FlashCopy files to put the data on the H2 volumes. This means that the consistent data on the H2 volumes is not overwritten if the data to be copied to them is not consistent.

Metro Mirror Failover/Failback enabled for Open HyperSwap

Jane wants to run a Metro Mirror with Practice from San Francisco to Oakland. She wants to verify the recovery procedure for the Oakland site, but she cannot stop running the Metro Mirror session while she takes time to practice a recovery. By using a Metro Mirror with Practice session, Jane can practice the disaster recovery scenario in Oakland while the Metro Mirror session runs uninterrupted. By practicing running the applications at the Oakland site, Jane is better prepared to recover data if a disaster occurs at the San Francisco site.

While the session is running in a Prepared state, Jane practices a recovery at the Oakland site by issuing the Flash command. This command momentarily pauses the session and starts a FlashCopy to the H2 volumes. As soon as the FlashCopy is started, the session is restarted. These FlashCopy files create a consistent version of the data on the H2 volume that she can use for recovery testing, while the session continues to replicate data from San Francisco to Oakland. As a result, she can carry out the recovery testing without stopping the replication for any extended duration of time.

If the Metro Mirror session is suspended because of a failure, Jane can use the practice session to restart the data replication process while she maintains a consistent copy of the data at the Oakland site, in case of a failure during the resynchronization process. When the session is suspended, she can issue a Recover command to create a consistent version of the data on the H2 volumes. After the Recover command completes, she can issue the Start H1->H2 command to resynchronize the data from the San Francisco site to the Oakland site.

If a failure occurs before the restarted session is in Prepared state, she has a consistent version of the data on the H2 volumes. She only has to issue the Recover command to put the session into Target Available state and make the H2 volumes accessible from the servers. If the session was not in Prepared state when it was suspended, the subsequent Recover command does not issue the FlashCopy files to put the data on the H2 volumes. This means that the consistent data on the H2 volumes is not overwritten if the data to be copied to the volumes is not consistent.

Selecting a HyperSwap session

A global insurance company decided to use Copy Services Manager to manage its disaster recovery environment. Jane wants minimal data exposure, both for planned outages such as routine maintenance, and for unplanned disasters. They have CKD volumes on IBM DS8000 devices, and use z/OS operating systems. They have two data centers in New York.

Jane chooses a Metro Mirror recovery solution because her priority is to protect the system from regional disasters. Jane decides to use Metro Mirror solution because her company has two data centers that are located near each other. Jane realizes that because she uses a z/OS operating system, CKD, and IBM DS8000 hardware, she can also use a HyperSwap solution. Using Metro Mirror Failover/Failback with HyperSwap, Jane can minimize the effects on any applications, while she maintains the failover process to the secondary site. Jane decides Metro Mirror Failover/Failback with HyperSwap is the best solution.

After installing and configuring Copy Services Manager on z/OS, Jane starts the Copy Services Manager GUI. She adds the Copy Services Manager storage devices that she intends to use on all sites. From the Sessions page, Jane opens the Create Session window and selects the Metro Mirror Failover/Failback session type. After completing the information in the window, Jane clicks Launch Add Copy Sets Wizard. After she completes the wizard, she selects the Manage H1-H2 with HyperSwap option in the View/Modify Properties notebook.

Jane then issues a Start H1->H2 command. After the initial copy is completed, Jane can safely replicate the data between both sites. She can also issue the HyperSwap command between sites 1 and 2 to switch sites with minimal effect on the application during either a disaster or maintenance period.

Performing a planned HyperSwap

Jane's company used Metro Mirror Failover/Failback with HyperSwap sessions for the past three months. However, Jane must perform maintenance on an H1 volume. During this time, Jane does not want the applications or replication to be interrupted. To prevent this interruption, before the maintenance is scheduled to begin, Jane uses the Copy Services Manager GUI to perform a HyperSwap operation to the H2 volumes. This process changes the applications so that the data is written to H2. To perform a planned HyperSwap operation, Jane issues a HyperSwap command.

Understanding what happens when an unplanned HyperSwap occurs

Several weeks after the planned maintenance at Jane's company is completed, an incident occurs at the H1 site. A disk controller fails, causing one of the H1 volumes to encounter a permanent I/O error. Jane's data is safe because she used Metro Mirror Failover/Failback with HyperSwap, and the H2 volume is an exact duplicate of the H1 volume. When the permanent I/O error is detected, a HyperSwap is triggered. The application changes to write data to the H2 volumes. The applications are not interrupted.

Jane configured a Simple Network Management Protocol (SNMP) listener to alert her to any events, so she receives the SNMP event that indicates that a HyperSwap occurred. Jane investigates the cause of the HyperSwap process and uses the z/OS console to identify the volume that triggered the HyperSwap process. Jane replaces the faulty disk controller. Then, to recover from the unplanned HyperSwap process, Jane issues the Start H2->H1 command.