Introduction to native IP replication in SVC/Storwize
This chapter describes the new functionality introduced with code version 7.2, which supports native IP replication across the IBM Storwize family, including IBM System Storage SAN Volume Controller (SVC). The functionality of the new feature is covered, along with a summary of the SVC/Storwize remote mirror technologies.
 
Important: Although this paper provides information about the Storwize V7000 and SVC, it also applies to the Storwize V5000 and the Storwize V3700.
1.1 IP replication overview
The native Internet Protocol (IP) replication feature enables replication between any SVC/Storwize family member running code version 7.2 or higher, using the built-in networking ports of the cluster nodes. Following a recent partnership with IBM, it uses SANslide technology developed by Bridgeworks Limited of Christchurch, UK. They specialize in products that can bridge storage protocols and accelerate data transfer over long distances.
Adding this technology at each end of a wide area network (WAN) Transmission Control Protocol/Internet Protocol (TCP/IP) link significantly improves the usage of the link. It does this by applying patented Artificial Intelligence (AI) to hide latency normally associated with WANs. Therefore, doing so can greatly improve the performance of mirroring services, in particular Global Mirror with Change Volumes (GM/CV) over long distances.
 
Tip: Although all versions of 7.2 code offer native IP replication, versions 7.2.0.4 and later offer performance enhancements to the SANslide technology.
1.2 Metro Mirror and Global Mirror overview
Metro Mirror (MM) and Global Mirror (GM) are technologies that enable you to keep a real time, or near real-time, copy of a disk at a remote site that contains another SVC cluster or Storwize V7000 system.
1.2.1 Metro Mirror
MM makes synchronous copies, which means that the original writes are not considered complete until the write to the destination disk has been confirmed. The distance between two sites is usually determined by how much latency the applications can handle. Therefore, MM is typically used within metropolitan distances in conjunction with a zero recovery point objective (RPO), that is, zero data loss.
Figure 1-1 shows the order of MM write operations.
Figure 1-1 Metro Mirror write sequence
1.2.2 Global Mirror
GM makes asynchronous copies of your disk. This means that the write is considered complete after it is complete at the local disk; it does not wait for the write to be confirmed at the remote cluster like MM does. This greatly reduces the latency experienced by applications if the other cluster is far away. However, it also means that, during a failure, the data on the remote copy might not have the most recent changes committed to the local disk.
Figure 1-2 shows the order of GM write operations.
Figure 1-2 Global Mirror write sequence
1.2.3 Global Mirror with Change Volumes
This function (also known as Cycle-Mode Global Mirror), was introduced in Storwize V7000 V6.3, and can best be described as Continuous Remote IBM FlashCopy®. If you use this feature, the Storwize V7000 will essentially take periodic flash copies of a disk, and write them to your remote destination.
This feature completely isolates the local copy from WAN issues, such as line glitches, and from sudden spikes in workload that might occur. Bear in mind that your remote copy might lag behind the original, depending on how you have set up the cycle time.
Figure 1-3 shows a high-level conceptual view of GM/CV. GM/CV uses FlashCopy to maintain image consistency, and to isolate host volumes from the replication process.
Figure 1-3 Global Mirror with Change Volumes
 
 
 
 
 
Information: For more information about SVC and Storwize V7000 replication, see IBM System Storage SAN Volume Controller and Storwize V7000 Replication Family Services, SG24-7574.
For more information about the SVC, see Implementing the IBM System Storage SAN Volume Controller V7.2, SG24-7933.
For more information about the Storwize V7000, see Implementing the IBM Storwize V7000 V7.2, SG24-7938.
For more information about the Storwize V5000, see Implementing the IBM Storwize V5000, SG24-8162
For more information about the Storwize V3700, see Implementing the IBM Storwize V3700, SG24-8107
1.3 Example scenarios
A SVC/Storwize cluster in one location can be connected to another SVC/Storwize cluster at a remote location using various designs. The following sections show example connectivity designs.
1.3.1 Single WAN link to a single input/output group
Figure 1-4 shows a single WAN link connecting two Storwize V7000 clusters consisting of a single input/output (I/O) group each. In this design, there is a redundant connection from each Storwize V7000. Either Ethernet port 1 or 2 can be configured for IP replication, but not both. This protects against a node connection failure or a node canister outage (for example, for a code upgrade). However, it does not protect against a WAN connection failure.
Figure 1-4 Single WAN link to a single I/O group
In this scenario, the remote-copy port group on each system includes two IP addresses, one from each node. When the system initially configures, one of these IP addresses is chosen from each side. This pairing cannot be chosen or changed by an administrator. In the previous example, H1 and M2 have established a connection. If M2 fails, the session will be lost but the connection will automatically be re-established between either H1 or H2 and M1.
The IP addresses do not fail over between nodes for the purposes of IP replication. Although the address does in fact move to the other node, as can be seen from the output of the lsportip command when a node does fail, this is for Internet Small Computer System Interface (iSCSI) purposes only. The IP replication link will be re-established with the previously assigned original IP address of the port.
1.3.2 Single WAN link to dual I/O groups
Figure 1-5 on page 6 shows a single WAN link connecting two Storwize V7000 clusters consisting of dual I/O groups. This design also provides redundancy against a node failure, but not against a WAN failure. The remote-copy port group on each system has four IP addresses, one from each node.
When the system initially configures, one of these IP addresses is chosen from each side. This pairing cannot be chosen or changed by an administrator. If one of the paired nodes fails, for example H1, then the connection will be lost as before, but re-established between either H2, H3, or H4 and M1, M2, M3, or M4.
 
Restriction: Storwize V7000 and SVC nodes with more than two I/O groups are supported. However, there is a limitation that only four IP addresses, from two I/O groups per system, can be included in a remote-copy port group. If there is only one intersite link there must be only one port group.
Figure 1-5 shows a single WAN link connecting two Storwize V7000 clusters.
Figure 1-5 Dual I/O group with a single WAN link
1.3.3 Dual WAN links to a single I/O group
The design shown in Figure 1-6 shows a dual redundant WAN link connecting two Storwize V7000 clusters consisting of a single I/O group each. In this design, port group 1 and 2 have two IP addresses, each on a different node in a different system. This design enables two simultaneous IP replication sessions; however, there is only one active port per node. If any node should fail, the associated connection would also fail with the loss of half the bandwidth.
Figure 1-6 Dual WAN links to a single I/O group
1.3.4 Dual WAN links to dual I/O groups
If the required bandwidth means that there must be dual links, then a failure of one might lead to an effect on MM or GM if there is no redundancy at the node canister level. In this case, the advice would be to have two I/O groups at each site to enable recovery from any single node failure or outage, as shown in Figure 1-7.
Figure 1-7 Dual WAN links to dual I/O groups
1.4 SVC/Storwize IP replication in more detail
The introduction of native IP replication provides an alternative to the traditional use of a pair of Fibre Channel over IP (FCIP) routers, or wave division multiplexors (WDMs) for WAN connectivity and to native Fibre Channel (FC) connectivity. Before the release of the version 7.2 code, if there was a need for replication, the only option was FC connectivity.
FC technology uses the concept of buffer-to-buffer (B2B) credits as a flow control method to maximize the performance of an individual link. The B2B credits are calculated depending on the speed and the distance of the link, and represent the number of frames a port can store. The faster the link, the more frames can be in flight, and the higher the B2B credit. Traditional IP does not have this concept.
1.4.1 Performance degradation with TCP/IP
Put simply, with TCP/IP, information transfer slows the farther you go. This is because of the latency caused by waiting for acknowledgment of each set of packets sent, because the next packet set cannot be sent until the previous one has been acknowledged:
Latency = Round Trip Time (RTT) for a single packet set
Figure 1-8 illustrates this packet flow for a typical IP link.
Figure 1-8 Link usage on a standard IP link
Figure 1-9 shows how throughput drops off as latency increases.
Figure 1-9 Effect of latency on performance
1.4.2 How SVC/Storwize improves performance
The technology built into the SVC/Storwize code uses TCP/IP latency to its advantage. Rather than wait for the acknowledgment to come back, it sends more sets of packets across other virtual connections. The number of virtual connections is controlled by the AI engine. This improves WAN connection use, which results in a data transfer rate approaching full line speed.
If packets are lost from any virtual connection, the data will be retransmitted, and the remote unit will wait for it. Presuming that this is not a frequent problem, overall performance is only marginally affected because of the delay of an extra round trip for the data that is resent.
Figure 1-10 illustrates data flow with multiple virtual connections.
Figure 1-10 Link usage on an SVC/Storwize IP link
The AI monitors the link performance during data transfer, in addition to the memory and processor use of the node. It can adjust the number of virtual connections, the receive window size, and the packet size as appropriate to maintain optimum performance. This information is retained in the node so that, if the link is stopped and started again, it will restart with the previously learned settings.
What it does not do
SVC/Storwize IP replication does not manipulate the data in any way. It does not perform any of the following actions:
•Compress data
•Use deduplication
•Use User Datagram Protocol (UDP)
•Modify TCP/IP
•Use hard disk drive (HDD) caching
What it does do
It improves performance in several ways:
•Uses patented AI
•Fills the pipe
•Operates beneath the operating system
•Uses standard TCP/IP
•Is not affected by compressed and encrypted files
In summary, the SVC/Storwize solution is designed around the principle of using all of the pipe rather than changing the data. It works best with larger, more consistent amounts of data rather than bursty type data, which is another reason why we advocate GM/CV for IP replication. However, it also works with MM and GM.
1.4.3 Performance benefit
Figure 1-11 shows how the SVC/Storwize solution maintains near line-speed performance by masking the latency of the line. Even as the line latency increases, the performance of the technology enables the line to continue to exceed that of a plain link.
Figure 1-11 Storwize V7000 transfer rate comparison
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.143.214.56