Remote Copy Implementation Options

With an understanding of how remote copy processes work, it's possible to explore different points along the I/O path at which remote copy applications can be implemented, including host software, networking equipment, and disk subsystem controllers.

We'll now explore these options and attempt to highlight their relative advantages and disadvantages. One of the issues with all remote copy implementations is they are proprietary products that do not interoperate. When you choose a remote copy solution, you need to have matching forwarding and receiving controllers from the same vendor. However, it is possible to have multiple remote copy applications running in the same environment, even using the same intermediary network, but the two systems cannot be used as spares for each other.

Remote Copy in Disk Subsystems

Most remote copy implementations today run as software in disk subsystems. Examples of disk subsystems remote copy products are the EMC SRDF (Symmetrix Remote Data Facility), IBM PPRC (Peer-to-Peer Remote Copy), Hitachi Truecopy, HP Storageworks DRM (Data Replication Manager), and Storageworks Continuous Access EVA products.

There are different variations of how these products work and which operating modes they support, but all are designed to provide data integrity at remote storage sites.

The main advantage of these products is that they have been in the market the longest and have the longest successful track records. And it needs to be stated that these products have been proven in some of the most difficult environments and have come through with flying colors.

Another advantage of the subsystem approach is that it does not depend on external storage to get the job done. All remote copy operations are done in a "closed" environment where all variables are known, with relatively few surprises. Internal engineering with known configurations and disk drives is less likely to experience unexpected SCSI command responses.

The main weakness of these products is that their scope is limited to a single subsystem and they do not coordinate writes written to multiple subsystems. It is certainly possible that an application could be using storage on different storage subsystems. Certainly both subsystems could have remote copy applications running, but there is no way to coordinate their functions. Write ordering and write atomicity may not be able to be maintained if remote communications problems occur.

NOTE

There are business advantages and disadvantages to be weighed in using subsystem remote copy solutions. To start with, the same vendor's subsystem products typically need to be used at both ends, which means seldom-used remote storage might cost a lot more than you want to pay (this would be a disadvantage). However, it may be easier to get the support you need when you need it if you've already spent all that money with a vendor that, by now, ought to like you for sending all that money their way.

Remote Copy in the SAN with SAN Virtualization Systems, SAN Appliances, and Switch Application Blades

Chapter 12, "Storage Virtualization: The Power in Volume Management Software and SAN Virtualization Systems," discusses SAN virtualization in detail. For now, it's worth knowing that systems between servers and storage have the ability to merge storage address spaces for use by host filing systems. This is an area that has seen a great deal of innovation and development in recent years as existing vendors and startups have created a wide variety of products. Remote copy is often integrated with virtualization products that run in SAN switches, routers, and appliances.

One of the more interesting opportunities for providing remote copy functions in a SAN is to put the function in an application blade running in a SAN switch or routing device. Integrating remote copy functionality in a SAN switch consolidates more functions where they can be centrally managed. Examples of this approach include Cisco's MDS9000 product line with its Advanced Services and Caching Services modules. Other SAN switch vendors also offer remote copy application solutions.

Some of the products that fall into this category that could provide remote copy functions are the IBM SVC (SAN Volume Controller), Dell Powervault 530F, Kashya KBX4000, StoreAge SAN Volume Manager, StorageTek Mirrorstore Replication Appliance, Data Core SAN Symphony, HP CASA (Continuous Access Storage Appliance), Falconstor IPStor, Revivio CPS (Continuous Protection System), and VERITAS Storage Foundation for Networks.

Obviously, there are many options in this category, none of them having the stellar track records of the subsystem products. With so many entrants it is difficult to predict at this point what the future holds for these products.

One of the main advantages of the in-SAN approach is the main weakness of the subsystem approach: applications that write data to multiple subsystems can do so through a centralized in-SAN virtualization system, which can theoretically coordinate the writes from multiple servers, solving the write ordering and atomicity problems of an application using more than one subsystem.

In addition, the independence of in-SAN remote copy means companies may be able to use storage products from different vendors in their remote copy solutions. That way, secondary and tertiary storage tiers can be implemented with different and less expensive storage products than those used for primary storage. This has the potential of saving IT organizations significant amounts of money in their remote copy budgets.

The disadvantage of the in-SAN approach is that storage is not integrated within the same system that the remote copy controllers are, opening the possibility for unexpected behavior related to SCSI command execution and responses. For that reason, the certification of downstream storage subsystems by in-SAN remote copy application vendors is the key to creating a reliable and stable remote copy system.

Remote Copy in Host Software

Remote copy can also be implemented in host software, where it is often referred to as replication. Host replication applications include the Veritas Volume Replicator, the Fujitsu Softek Replicator, and the Topio SANSafe.

These products do not necessarily work with SCSI commands, but they do work with I/O operations targeted for specific block storage address space. In other words, they operate "above" the SCSI device driver layer. For that reason the data that is forwarded does not necessarily need to use SCSI protocols and SAN products. It can use many different networks, including IP networks.

Like in-SAN remote copy, host-based replication can use different storage subsystems at both local and remote sites. In addition, all I/Os from the system can be forwarded to the remote site, maintaining consistency and atomicity independent of the mix of primary storage subsystems used by the application.

The drawback of host-based replication is the CPU load that can be placed on the system. The faster the I/O rates are for an application, the more work that is required of the replication application. At some point this could potentially become a problem.

NOTE

Another class of host software, also referred to as replication, works on file system objects, as opposed to I/O operations. The subject of file replication is covered in more detail in Chapter 17, "Data Management."