IP partnership requirements

Consider the following requirements and constraints when creating and configuring IP partnerships.

You can only create IP partnerships between two systems.
A system can only be part of one IP partnership.
You can create IP partnerships between any two Storwize products on the same layer. In other words, both systems must be at the storage layer or both systems must be at the replication layer.
You cannot use link-local addressing.
If you use IPv4 addressing, the management IP addresses on both systems must be IPv4-compliant, and these addresses must have connectivity with each other.
If you use IPv6 addressing, the management IP addresses on both systems must be IPv6-compliant, and these addresses must have connectivity with each other.
If your system has IPv4 and IPv6 addressing on the ports, you must configure all remote copy links between the local and remote site for one of those addresses.
You can configure ports from at most two I/O groups from each system for an IP partnership.
If your system has 10 Gbps and 1 Gbps Ethernet ports, you must configure all remote copy links between the local and remote site for one of those speeds.
A system can have simultaneous partnerships over FC and IP but with separate systems.
The IP partner systems must not be visible to each other over Fibre Channel or Fibre Channel over Ethernet (FCoE) connections. Fibre Channel/FCoE ports of either systems should not be listed as parameters to the svcinfo lsfabric command.
Clusters configured in active IP partnerships should not be zoned with each other for Fibre Channel/FCoE.
iSCSI Hosts can access volumes over IP ports participating in an IP partnership, although this might result in an impact on performance.
VLAN tagging of the IP addresses configured for remote copy is supported. If VLAN is to be configured, ports in the same remote copy group must be on same VLAN on both systems.
Do not attempt to use Network Access Translation (NAT) with IP partnerships. It will prevent IP partnerships from establishing.
If you configure two intersite links, you must configure separate remote-copy port groups, one for each link.
If you have one intersite link, you must configure one remote-copy port group for that link.
No more than two intersite links/remote-copy port groups are supported.
If you have one remote-copy port group, then configure one port from each node in one I/O group in that remote-copy port group.
For systems with more than one I/O group, ports from a second I/O group can be added to the remote-copy port group.
If you have two remote-copy port groups and just a single I/O group, then on each system configure one port from one node in the first remote-copy port group, and then a port from the other node in the second remote-copy port group.
For systems with more than one I/O group, ports from a second I/O group can be added to each of the two remote-copy port groups.
A node can have only one port configured in an IP partnership.
If you connect systems by directly attaching them without switches, then you must have only two direct-attach links, and both direct-attach links must be on the same I/O group. You should use two port groups where a port group should only contain the two ports that are directly linked.

Supported IP partnership configurations

The following general configurations are supported in this release, but the number of I/O groups configured for each site can be different.

Configurations 3 and 6 also apply to systems with four I/O groups. Only two I/O groups in a system can be used for an IP partnership.

Configuration 1: In this configuration, only a single intersite link is available. Therefore, only a single Remote Copy port group is configured on each node.

Figure 1. One intersite link, one I/O group per system

Only one port from either of the nodes in each system actively participates in the IP partnership. The other port acts as the failover port. If a critical failure is observed on node H1 in Site H, the IP partnership will failover to node H2 and continue. Remote copy relationships might stop momentarily during the failover.

Configuration 2: In this configuration, again only a single intersite link is available. Both I/O groups in each system have a single remote-copy port group configured on each node. However, out of all of the available ports, only one port from either of the nodes in each system actively participates in the IP partnership. The other ports act as failover ports.

Figure 2. One intersite link, two I/O groups per system

If a critical failure is observed on node H1, in Site H, the IP partnership will failover to node H2, H3, or H4 and continue. Remote copy relationships might stop momentarily during the failover.

Configuration 3: In this configuration, 8-node systems are available. However, only two I/O groups are supported in IP partnerships. Both I/O groups in each system have a single remote-copy port group configured on each node. However, out of all the available ports, only one port from either of the node in each system actively participates in IP partnership. The other ports act as failover ports.

Note: Configuration 3 also applies to systems with four I/O groups. Only two I/O groups in a system can be used for IP partnership.

Figure 3. One intersite link, three I/O groups per system

If a critical failure is observed on node H1 in Site H, the IP partnership will failover to node H2, H3, or H4 and continue. Remote Copy relationships might stop momentarily during the failover.

Configuration 4: In this configuration, there are two intersite links available - therefore, two remote-copy port groups are configured. One port from each of the node in each system actively participates in the IP partnership. If a critical failure is observed on node H1 in Site H, the IP partnership will continue over the other port on node H2.

No failure will occur in this scenario; however, the effective bandwidth is reduced to half. In other words, if there are two links, then, in this case, effectively only one link will be available to facilitate IP partnership traffic. Once the failure is corrected, ports will failback and the IP partnership will continue to operate over both links.

Figure 4. Two intersite links, one I/O group per system

Configuration 5: This is a multi-node configuration with two intersite links available - therefore, two remote-copy port groups are configured. In this configuration, although four ports (one per node) are configured in remote-copy port groups "1" and "2", out of the four ports only two ports will actively facilitate the IP partnerships. This port and path selection is maintained by an internal algorithm. The other ports act as failover ports.

Figure 5. Two intersite links, two I/O groups per system

If a critical failure occurs on node H1 in Site H, the IP partnership will failover to node H3 and continue. There will be no impact on link bandwidth, as the failover will happen immediately and complete quickly while IP partnership traffic continues from node H2.

Configuration 6: In this configuration, there are 8-node systems available. However, only two I/O groups are currently supported for IP partnerships. Both I/O groups in each system have four ports (one per node) configured in remote-copy port groups "1" and "2". Out of the four ports, only two ports will actively facilitate the IP partnerships. This port and path selection is maintained by an internal algorithm. The other ports act as failover ports.

Note: Configuration 6 also applies to systems with four I/O groups. Only two I/O groups in a system can be used for IP partnership.

Figure 6. Two intersite links, three I/O groups per system

If a critical failure is observed on the node H1, in Site H, the IP partnership will failover to node H3 and continue. There will be no impact on link bandwidth, as the failover will happen immediately and complete quickly while IP partnership traffic continues from node H2. The other I/O groups, or all the I/O Groups, can be connected over a Fibre Channel partnership with another system.