Partnerships

Two-site partnerships replicate volume data that is on one system to a remote system. Two-site partnerships are required for policy-based replication. Partnerships can be used for migration, 3-site replication, and disaster recovery situations.

Both policy-based replication and remote-copy function use partnerships for creating copies in recovery system. Policy-based replication currently supports asynchronous, 2-site replication.

Before you can configure policy-based replication or configure remote-copy objects, a partnership between all the systems must be established. If relationships or consistency groups exist between different systems, those systems must maintain their partnership. Each system can maintain up to three partnerships. The system can either support maximum of three IP partnerships, three Fibre Channel partnership, or combination of these two type of partnerships. 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 state of the partnership helps determine whether the partnership operates as expected. A partnership can have the following states:
Configured
Both the local and remote systems have a partnership that is defined and are running as expected.
Partial Local

For the partnership to be fully configured, you must create a partnership from the remote system to the local system. The system supports both Fibre Channel and IP connections between partnered systems. Use the management GUI to configure partnerships or use the mkfcpartnership for Fibre Channel connections or the mkippartnership for IP connections.

Local Stopped
Indicates that the partnership is defined on both the systems, but the partnership is stopped on the local system.
Remote Stopped
Indicates that the partnership is the defined on both the systems, but the partnership is stopped on remote system.
Partial Local Stopped
Indicates that only the local system has the partnership that is defined and the partnership is stopped on the local system.
Local Excluded
Indicates that both the local system and the remote system have the partnership that is defined, but the local system is excluding the link to the remote system. This state usually occurs when the link between the two systems is compromised by too many errors or slow response times of the partnership.
Remote Excluded
Indicates that both the local system and the remote system are defined in a partnership, but the remote system is excluding the link to the local system. This state usually occurs when the link between the two systems is compromised by too many errors or slow response times of the partnership.
Exceeded
Indicates that the partnership is unavailable because the network of systems exceeds the number of systems that are allowed in partnerships. To resolve this error, reduce the number of systems that are in partnerships in this network.
Not Present
Indicates that the remote system is not visible. This state can be caused by a problem with the connectivity between the local and remote system or if the remote system is unavailable.

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

Figure 1 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.
Figure 2 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.
Figure 3 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.
Figure 4 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.
Figure 5 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.
Figure 6 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.
Figure 7 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.

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 IP partnership configuration.

Figure 8 depicts two systems with no partnerships.
Figure 8. Two systems with no partnerships
This figure depicts two systems that are not in a partnership.
Figure 9 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.
Figure 10 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.
Figure 11 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.
Figure 12 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.
Figure 13 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 depicts systems that are in a fully connected mesh configuration. Every system has IP partnerships to each of the three other systems.
Figure 14. Four systems in a fully connected mesh configuration with multiple IP partnership
Four systems in a fully connected mesh configuration with multiple IP partnership
Figure 15 depicts four systems in a partnership with multiple IP partnership. System D might be a disaster recovery site.
Figure 15. Four systems with one Fibre Channel partnership or multiple IP partnership
Four systems with one Fibre Channel partnership or multiple IP partnership or one IP partnership.
Figure 16 depicts three systems and three partnerships.
Figure 16. Three systems with one Fibre Channel partnerships and two IP partnership
Three systems with one Fibre Channel partnerships and two IP partnership
Figure 17 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 or IP partnerships.
Figure 17. An unsupported system configuration
This figure depicts a system configuration that is not supported. Five systems are in the connected set.

To establish a 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 partnerships.

Portsets replace the requirement for creating groups for IP partnerships. Dedicated portsets can be created for remote copy traffic. The dedicated portsets provide group of IP addresses for IP Partnerships. Each node can have one IP address that is assigned to a portset for traffic. If the local system in the IP partnership contains four nodes, a portset can be created that defines four IP addresses, one per each node. Similarly, the remote system with four nodes, a portset on that system can also have four IP addresses to handle traffic exclusively. During updates of the software, any IP addresses that are assigned to groups with an existing IP partnership are automatically moved to a corresponding portset. For example, if group 1 is defined on the system before the update then IP addresses from that remote-copy group are mapped to portset 1 after the update. Similarly, IP address in group 2 is mapped to portset 2. Before you can configure a new IP partnership, you need to define a portset and assign IP addresses to nodes.

You can configure portsets so that each IP partnership can be mapped to two portsets, one for each WAN link between systems. For network configurations that have a single link between systems in an IP partnership, a single portset can be defined in the Portset Link 1 field on the Create Partnership page from GUI. You can also use the -link1 attribute in the mkippartnership command for partnerships with a single link. For a partnership with dual links, a second portset must be mapped defined in the Portset Link 2 field. Use the -link2 attribute to specify the second portset for a dual link configuration.

Background copy management

Note: Background copy management is not applicable for policy-based replication.
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 Recovery Point Objective (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.

Replication between IBM Spectrum Virtualize systems

Systems that run IBM Spectrum Virtualize software are in one of two layers: the replication layer or the storage layer.
  • A SAN Volume Controller system is always in the replication layer.
  • A FlashSystem family system is in the storage layer by default, but the system can be configured to be in the replication layer instead.
To create a partnership between systems, both systems must be in the same layer. You can change layer of IBM Spectrum Virtualize systems. For more information, see System layers.
Figure 18. Example configuration with systems in different layers
This figure shows an overview of system layers