HyperIP boosts data replication

HyperIP boosts data replication

Remote replication of storage is more popular today than ever, and it promises to become even more important, thanks to government regulations such as Sarbanes-Oxley that require data replication. To transport the data, some organizations lease dark fibre and run long-distance FC (Fibre Channel) connections, but this approach can be very expensive due to the equipment and the leased lines. The alternative is to use an IP storage protocol over a TCP/IP WAN, but this method also has a drawback, namely the inherent inefficiency of TCP/IP for transmitting storage protocols.

Storage protocols tend to assume that each packet will get through in the right order and with minimal delay. However, TCP/IP is not engineered to ensure either of these things; all the packets will get through, but they won't necessarily be delivered in the order they're sent. Instead, they'll be reassembled at the receiver. Given the amorphous nature of the Internet, timely delivery is also impossible to guarantee. Both these conditions play havoc with storage replication over IP via the Internet.

Network Executive Software's NetEx HyperIP appliance is designed to address these issues with three functions: counteracting the effects of latency over a WAN link; compressing data at the block level; and increasing the tolerance of TCP applications for latency, jitter, bit error rate, and bandwidth variation. It is designed to work across private (point-to-point leased line) WAN connections, but it will improve tunnels through the Internet as well. This is a relatively specialized appliance, designed to optimize only storage protocols; it would have little or no effect on other types of TCP/IP WAN traffic, and in its normal configuration doesn't even look at other protocols. The HyperIP doesn't so much accelerate traffic as negate the effects of a poor WAN connection.

Built for storage

The HyperIP is certified to support various major storage applications from companies including EMC, IBM's Tivoli, McData, Microsoft, Network Appliance, NSI, Oracle, and Veritas Software. Any other vendor's applications that use storage over IP protocols should work as well.

Setting up the HyperIP is straightforward. Note that there must be a HyperIP appliance on each end of a connection. The interface is simple, although it is not wizard-driven. Each device must be configured separately; there is no unified management of all devices because they are all on separate networks.

The HyperIP has two basic configurations: gateway mode and proxy mode. In the gateway mode, your storage application uses the HyperIP as its TCP gateway, and the appliance then routes traffic to the WAN. In the proxy mode, the HyperIP serves as a proxy to the storage app, which allows greater control of routing, because many applications can specify that only certain data goes through the proxy and other data does not. In either case, only traffic that uses the HyperIP's address as gateway or proxy goes through the HyperIP; normal traffic is not disrupted. The HyperIP can also be configured in a hot standby configuration for fail-over.

For my testing, I used the Shunra Software WAN Emulator to create a simulated WAN connection between two subnets. I then routed both iSCSI and FC over IP storage traffic across the connection, first across the raw connection, and then through the two HyperIP boxes, one on each end of the WAN connection. In each case, I impaired the WAN link by gradually increasing latency from 40 milliseconds to 1200 milliseconds, increasing jitter and bit error rate from zero to levels simulating a poor WAN connection, and changing the middle of a three-step connection from 10Mbps to 768Kbps -- all conditions that might arise in the real world.

Traffic conditions

With the highest levels of latency, jitter, and bit errors, the HyperIP's throughput was about 10 times faster than the raw connection. When I enabled compression, I saw a maximum of about 18 times the throughput, although this was dependent on how compressible the data being moved was; text and XML files, for instance, are very compressible, whereas many graphics files are already compressed and can't be reduced much further.

These numbers are somewhat deceptive. Disregarding compression, The HyperIP did not achieve any greater throughput than would have been available over a clean connection. Instead it ameliorated the effects of a bad connection, to the point where there was very little difference between the traffic flows over the impaired and clean links. This is great news for IT managers looking to use the Internet for replication. However, for those using private leased lines, the benefits may not be as great.

One interesting feature is that the appliance's bandwidth capacity can be purchased in increments. The hardware is the same, but the box can be upgraded from 10Mbps to 480Mbps of throughput without lifting a finger. The appliances I tested had no problem handling the full 480Mbps of traffic.

Each box handles as many as 118 TCP connections; anything more will require additional units, and applications that tend to use multiple connections will need to be modified. Traffic from each application can be throttled individually.

Security features include a separate Ethernet interface for management, so that control of the system cannot be subverted across the WAN connection, if requirements dictate. Management across the WAN port can also be enabled, for instance, for a remote office.

If you have a clean leased line with low latency and few bit errors, you won't see much improvement with the HyperIP. On the other hand, if you have a dirty line, or are tunnelling through the Internet with an SSL or other tunnelling connection, you should see substantial improvements, more than enough to justify the price of the units.

IT consultant Logan Harbaugh is the author of two books on networking

Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments