Metro Mirror and Global Mirror partnerships define an association
between a local system and a partner system. Partnerships can be used to create a disaster recovery
environment or to migrate data between systems that are in different locations.
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.
Figure 1 depicts two systems
that are not in a partnership.Figure 1. Two systems with no partnerships
Figure 2 depicts two systems
with one Fibre Channel partnership.Figure 2. 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
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
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
Figure 6 depicts four systems
in three Fibre Channel partnerships.Figure 6. 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
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.
Figure 8 depicts two systems
with no partnerships.Figure 8. Two systems with no partnerships
Figure 9 depicts two systems
with one Fibre Channel or IP partnership.Figure 9. 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.
Figure 11 depicts three systems
and three partnerships.Figure 11. Three systems with two Fibre Channel partnerships and one IP partnership.
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.
Figure 13 depicts four systems
in three partnerships.Figure 13. Four systems with one Fibre Channel partnership and two IP partnerships
Figure 14 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 14. An unsupported system configuration
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. 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.
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.
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.
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.
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.
Note: Within a remote-copy
group, only one IP address pair is selected as the active connection at any time. If this connection
fails, a new address pair is selected. This failover results in the partnership being disconnected
for a few seconds. To determine the ports which have been selected as the active connection, select Settings > Networks > Ethernet Ports. If a port is used for IP partnerships, the remote-copy setting is selected and a
remote-copy group is defined.
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.
Metro Mirror and Global Mirror between SAN Volume Controller and other Storwize family
systems
You can create partnerships with SAN Volume Controller and other Storwize® family 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 Storwize family system is in the storage
layer by default, but the system can be configured to be in the replication layer instead.
Figure 15 shows an example of a partnership between a
SAN Volume Controller and a Storwize V7000 system.Figure 15. Example configuration for replication between SAN Volume Controller and a Storwize V7000 system