Metro Mirror and Global Mirror partnerships

Metro Mirror and Global Mirror partnerships define an association between a local system and a partner system.

Before a Metro Mirror or Global Mirror relationship or consistency group can be created with a remote system, a partnership between the two systems must be established. If Global Mirror or Metro Mirror relationships or consistency groups exist between two remote systems, those systems must maintain their partnership. Each system can maintain up to three partnerships, and each partnership can be with a single partner system. As many as four systems can be directly associated with each other.

Systems also become indirectly associated with each other through partnerships. If two systems each have a partnership with a third system, those two systems are indirectly associated. A maximum of four systems can be directly or indirectly associated.

The nodes within the system must be configured to detect the relationship between the two volumes but also about an association among systems.

The following examples show possible Fibre Channel partnerships that can be established among the systems.

Two systems with no partnerships depicts two systems that are not in a partnership.

Figure 1. Two systems with no partnerships
This figure depicts two systems that are not in a partnership.

Two systems with one Fibre Channel partnership depicts two systems with one Fibre Channel partnership.

Figure 2. Two systems with one Fibre Channel partnership
This figure depicts two systems with one Fibre Channel partnership.

Four systems in a Fibre Channel partnership depicts four systems in a Fibre Channel partnership. System A might be a disaster recovery site.

Figure 3. Four systems in a Fibre Channel partnership
This figure depicts four systems in a Fibre Channel partnership.

Three systems in a migration situation depicts three systems in a migration situation. Data Center B is migrating to C. System A is host production, and System B and System C are disaster recovery.

Figure 4. Three systems in a migration situation
This figure depicts three systems in a migration situation.

Systems in a fully connected mesh configuration depicts systems that are in a fully connected mesh configuration. Every system has a partnership to each of the three other systems.

Figure 5. Systems in a fully connected mesh configuration
This figure depicts systems that are in a fully connected mesh configuration.

Four systems in three Fibre Channel partnerships depicts four systems in three Fibre Channel partnerships.

Figure 6. Four systems in three Fibre Channel partnerships
This figure depicts four systems in three Fibre Channel partnerships.

An unsupported system configuration depicts a system configuration that is not supported. Five systems are in the connected set, even though no individual system is in more than two Fibre Channel partnerships.

Figure 7. An unsupported system configuration
This figure depicts a system configuration that is not supported. Five systems are in the connected set.

This figure depicts a system configuration that is not supported. Five systems are in the connected set.

The following examples show Fibre Channel and IP partnerships that can be established with the systems. For more information about configuring and deploying systems with IP partnerships, see Configuring IP partnerships.

Two systems with no partnerships depicts two systems with no partnerships.

Figure 8. Two systems with no partnerships
This figure depicts two systems that are not in a partnership.

Two systems with one Fibre Channel or IP partnership depicts two systems with one Fibre Channel or IP partnership.

Figure 9. Two systems with one Fibre Channel or IP partnership
This figure depicts two systems with one Fibre Channel or IP partnership.

Four systems with either one Fibre Channel partnership or one IP partnership. depicts four systems in a partnership. System D might be a disaster recovery site.

Figure 10. Four systems with either one Fibre Channel partnership or one IP partnership.
This figure depicts four systems in a partnership.

Three systems with two Fibre Channel partnerships and one IP partnership. depicts three systems and three partnerships.

Figure 11. Three systems with two Fibre Channel partnerships and one IP partnership.
This figure depicts three systems with three partnerships.

Four systems in a fully connected mesh configuration. depicts systems that are in a fully connected mesh configuration. Every system has a Fibre Channel or IP partnership to each of the three other systems.

Figure 12. Four systems in a fully connected mesh configuration.
This figure depicts systems that are in a fully connected mesh configuration.

Four systems with one Fibre Channel partnership and two IP partnerships depicts four systems in three partnerships.

Figure 13. Four systems with one Fibre Channel partnership and two IP partnerships
This figure depicts four systems in three partnerships.

Figure 14. An unsupported system configuration
This figure depicts a system configuration that is not supported. Five systems are in the connected set.

To establish a Metro Mirror and Global Mirror partnership between two systems that are connected through Fibre Channel connections, you must run the mkfcpartnership command from both systems. For example, to establish a partnership between system A and system B, you must run the mkfcpartnership command from system A and specify system B as the remote system. The partnership is then partially configured and is sometimes described as one-way communication. Next, you must run the mkfcpartnership command from system B and specify system A as the remote system. When this command completes, the partnership is fully configured for two-way communication between the systems. If the local and remote system uses IP connections, you need to enter the mkippartnership command on both the local and remote system to fully configure the partnership. You can also use the management GUI to create Metro Mirror and Global Mirror partnerships.

The state of the partnership helps determine whether the partnership operates as expected. In addition to being fully configured, a system partnership can have the following states:

Partially Configured: Local (partially_configured_local): Indicates that only the local system has the partnership defined. For the displayed system to be fully configured and to complete the partnership, you must define the system partnership from the system that is displayed to this system. Run the mkfcpartnership command for Fibre Channel connections, run the mkippartnership command for IP connections, or use the management GUI on the remote system.
Fully Configured (fully_configured): Indicates that the partnership is active on the local and remote system and is started.
Not Present (not_present): Indicates the remote system is not visible. This could be caused by a problem with the connectivity between the local and remote system or by the remote system being inactive.
Partially Configured: Local Stopped (partially_configured_local_stopped): Indicates that only the local system has the partnership defined, and the partnership has been stopped on the local system.
Note: It is the partnership that is stopped, not the system.
Fully Configured: Stopped (fully_configured_stopped): Indicates that both the local system and the remote system have the partnership defined, and the partnership has been stopped on the local system.
Note: It is the partnership that is stopped, not the system.
Fully Configured: Remote Stopped (fully_configured_remote_stopped): Indicates that both the local system and the remote system have the partnership defined, and the partnership has been stopped on the remote system.
Note: It is the partnership that is stopped, not the system.
Fully Configured: Local Excluded (fully_configured_local_excluded): Indicates that both the local system and the remote system have the partnership defined; however, the local system is currently excluding the link to the remote system. This state usually occurs when the link between the two systems has been compromised by too many errors or slow response times of the partnership.
Fully Configured: Remote Excluded (fully_configured_remote_excluded): Indicates that both the local system and the remote system have the partnership defined; however, the remote system is currently excluding the link to the local system. This state usually occurs when the link between the two systems has been compromised by too many errors or slow response times of the partnership.
Fully Configured: Exceeded (fully_configured_exceeded): Indicates that both the local system and the remote system have the partnership defined; however, the partnership is disabled because the network of systems exceeds the number of systems allowed in partnerships. To resolve this error, reduce the number of systems that are partnered in this network. Partnerships can be defined between up to four systems in a network.Only one partnership can be defined in a network.

These IP partnerships can be connections through Ethernet switches, or direct connections between local and partner systems. Partnerships must be created as either an IPv4 or IPv6 partnership.Data compression is also supported for IPv4 or IPv6 partnerships. To enable data compression, both systems in an IP partnership must be running a software level that supports IP partnership compression. To fully enable compression in an IP partnership, each system must enable compression. When compression is enabled on the local system, data sent to the remote system is compressed. To send compressed data to the local system, the remote system in the IP partnership must also enable compression.

Remote-copy groups are unique to IP partnerships and contain local and remote IP addresses accessible to each other through an IP partnership. A remote-copy group must contain at least one IP address in the local system and one IP address in the remote system. You must create the remote-copy groups before establishing the IP partnership.

Each Ethernet port can be associated with two IP addresses; one using IPv4 addressing and the other using IPv6. Use either IPv4 or IPv6 for IP partnership. You should configure more than two IP addresses within one system of the remote-copy group to allow for IP connection failover if the local or partner system experiences a node or port failure.

To change Metro Mirror and Global Mirror partnerships, use the chpartnership command. To delete Metro Mirror and Global Mirror partnerships, use the rmpartnership command.

Attention: Before you run the rmpartnership command, you must remove all relationships and groups that are defined between the two systems. To display system relationships and groups, run the lsrcrelationship and lsrcconsistgrp commands. To remove the relationships and groups that are defined between the two systems, run the rmrcrelationship and rmrcconsistgrp commands.

Background copy management

In a multiple-cycling Global Mirror copy, the linkbandwidthmbits parameter of the mkfcpartnership and mkippartnership commands controls the rate at which updates are propagated to the remote system. To ensure that the remote copies are as similar as possible to the local copies, the bandwidth parameter needs to be at least the average rate that write operations are applied to all volumes that are replicated by using multiple-cycling Global Mirror across this partnership. For optimum remedial process optimization (RPO), keep the bandwidth parameter less than the actual available bandwidth to ensure that multiple-cycling Global Mirror relationships do not congest the fabric. Also, leave sufficient bandwidth for Metro Mirror and noncycling Global Mirror relationships to support the I/O that are being replicated.

Using CHAP with an IP partnership (optional)

You can protect data exchange between the local system and partner system over an IP connection through challenge handshake authentication protocol (CHAP), which uses a shared secret to authenticate systems with each other when sending requests.

Note: You can also use a CHAP secret to authenticate with iSCSI-attached hosts. The system-wide CHAP secret is used for all CHAP authentication from the local system to partner systems and to iSCSI-attached hosts.

To configure CHAP for IP partnership, use the Modify CHAP Configuration dialog on each system to specify a system-wide CHAP secret, and select Use for IP partnerships. Two paths exist to this dialog in the management GUI:

Select Copy Services > Partnerships, then select Actions > Modify CHAP Configuration.
Select Settings > Network > iSCSI > Modify CHAP configuration.

Before creating an IP partnership, define a CHAP secret for each system, then configure CHAP to be used for IP partnerships on each system.

For example, when creating an IP partnership that uses CHAP between system A and system B, first define a CHAP secret on each system. The CHAP secret value on systems A and B can differ. On system A, specify the system B CHAP secret in the Create Partnership or Partnership Properties dialog, then on system B, specify the system A CHAP secret using one of the dialogs.

When creating an IP partnership on a local system using CHAP, if you do not specify the system-wide CHAP secret of the partner system, the local system displays a CHAP authentication failure message. If an IP partnership using CHAP is active, you must stop the partnership before modifying the CHAP configuration.

Metro Mirror and Global Mirror between SAN Volume Controller and other Lenovo V series systems

You can create partnerships with SAN Volume Controller and other Lenovo V series systems to allow Metro Mirror and Global Mirror to operate between the two systems. To create these partnerships, the clustered systems must be at version 6.3.0 or later.

A clustered system is in one of two layers: the replication layer or the storage layer. The system is always in the replication layer. To create partnerships, a system must be in replication layer.

A Lenovo V series system is in the storage layer by default, but the system can be configured to be in the replication layer instead.

Example configuration for replication between SAN Volume Controller and a Storwize V7000 for Lenovo system shows an example of a partnership between a SAN Volume Controller and a Storwize V7000 for Lenovo system.

Figure 15. Example configuration for replication between SAN Volume Controller and a Storwize V7000 for Lenovo system
This figure shows an overview of system layers

This figure shows an overview of system layers