Technology, T-13-6012 D. Scott, J. Krischer, J. Rubin
Research Note 15 June 2001
Disaster Recovery: Weighing Data Replication Alternatives Enterprises with short disaster recovery time objectives use data replication technologies. We provide a framework for understanding the myriad of available options.
Core Topics Software Infrastructure: Database Scalability and Availability for Transactional Systems; Disaster Recovery and Business Resumption Planning Key Issue How will technologies for business continuity and resumption evolve?
Inextricable business process dependence on IT has increased economic vulnerabilities associated with downtime. No longer can enterprises wait the traditional two, three or more days for recovery of critical applications in the event of a disaster. In fact, the most-critical applications, such as those used in e-commerce and customer service, often require either continuous availability (no interruption in service for any reason) or recovery in minutes to a few hours. In addition, many enterprises require no loss of transactions in the event of a disaster. Achieving short recovery times requires that enterprises build data replication architectures into their disaster recovery plans to replicate from a primary processing site to an alternate site, which can then be used in the event that the primary site becomes unavailable. Evaluating data replication technologies can be a daunting task, because of the large number of products on the market with differing implementation options and features. To add to this complexity, data replication solutions are specific to a database, file system, OS or disk subsystem; thus, enterprises often must use multiple solutions to protect their critical data — as well as multiple methods to protect a single application environment. Solutions can be implemented at a secondary internal data center, at service providers, such as hotsite providers Comdisco, IBM BRS and SunGard, or at Webhosting facilities/ISPs. Figure 1 and Figure 2 present data replication options with some differentiating features (defined in this Research Note). The most-popular solutions are disk-to-disk remote copy (with EMC SRDF leading in installations). These solutions operate at the disk volume level and are significantly less complex to set up and administer than host-based replication. They also offer the benefit of capturing all application environment (e.g., DBMS and file system) changes. A drawback, however, is their lack of transaction knowledge and the potential for data corruption in the Gartner Entire contents © 2001 by Gartner, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.
unlikely event of a disaster (enterprises should plan for an alternative recovery approach should corruption occur). However, enterprises that use solutions that guarantee the block write sequence (data consistency) between the primary and disaster recovery sites should expect their DBMS systems to restart and provide normal recovery at the disaster site, including database rollback to the last committed transaction. Most disk-todisk remote-copy solutions operate in synchronous mode, which degrades performance of production applications unless the solution can be deployed over fiber link to the recovery site. The distance can generally be from a few kilometers up to about 60 km, depending on the solution. For some, the distances can be extended by channel extenders.
Copyright 2001
T-13-6012 15 June 2001
2
Figure 1 Data Replication Options for Disaster Recovery Platform Dependency
Company/Product Supported Host Platforms
Production Deployment to 100+ Customers? No
Simultaneous Use of Replica for Reporting?
Physical disk volume
Yes
No
Mirroring
Physical disk volume
Yes
No
Shadowing
Physical disk volume
No
No
No
Mirroring
Physical disk volume
Yes, OS/390 only
No
No
Mirroring
Physical disk volume
No
No
No
Shadowing
Physical disk volume
No
No
Yes; supports DB2, IMS, CICS, IDMS, CPCS, ADABAS and SuperMICR
Electronic journaling DBMS (IMS and Yes DB2) (logging) and optional shadowing for IMS and DB2
Yes
MVS-OS/390
No
Shadowing
Physical disk volume
No
No
NSK
Yes
Shadowing
Transaction
Yes
Yes
Oracle Standby Database Quest Software SharePlex (for Unix) Data Mirror High Availability Suite
All platforms Oracle DBMS supports Unix (HP, Sun)
Yes
Database
Yes
No
Tablespace
Yes
Yes
DB2/400 Yes DBMS, OS/400 object
Yes
OS/400
Lakeview Technology MIMIX software suite
OS/400
DB2/400 Yes DBMS, OS/400 object
Yes
OS/400
Vision Solutions High Availability Suite
OS/400
DB2/400 Yes DBMS, OS/400 object
Yes
Host-independent, Compaq DRM disk-dependent (diskto-disk remote copy) Host-independent, EMC SRDF disk-dependent (diskto-disk remote copy) Host-independent, Hitachi HRC disk-dependent (diskto-disk remote copy)
Host-independent, Hitachi HOARC disk-dependent (diskto-disk remote copy) Host-independent, IBM PPRC disk-dependent (diskto-disk remote copy)
Host-independent, HP Continuous disk-dependent (disk- Access XP to-disk remote copy) Host-independent, HP Continuous disk-dependent (disk- Access XP to-disk remote copy) Extended MVS-OS/390
ENET RRDF
MVS-OS/390
Amdahl XRC, Hitachi HXRC, IBM XRC Compaq RDF
NSK (Compaq Himalaya) Oracle Oracle OS/400
Transaction Replication Type: Aware? Mirroring or Shadowing
Replication Selection Granularity
No
Mirroring
Physical disk volume
No MVS–OS/390, Unix (IBM, HP, Sun), Windows, Unisys, Bull, FSC, ICL, AS/400 MVS-OS/390, Major Unix No (HP, Sun, IBM AIX and NUMA-Q, Compaq, NCR, SGI), Windows, NetWare MVS-OS/390, Major Unix No (HP, Sun), Windows
Mirroring
Unix (Compaq, IBM, Sun), Windows
MVS-OS/390, Unix (IBM AIX and NUMA-Q, Sun, HP, Compaq, DG), Windows, Novell NetWare Major Unix (HP, Sun, IBM, Compaq), HP MPE, Novell, Windows and Red Hat Linux Major Unix (HP, Sun, IBM, Compaq), HP MPE, Novell, Windows and Red Hat Linux MVS-OS/390
OS/400
Shadowing; logshipping and apply Yes Shadowing; logbased Shadowing; wideOnly when using AS/400 area cluster support commitment control Shadowing; wideOnly when using AS/400 area cluster support commitment control Shadowing; wideOnly when using AS/400 area cluster support commitment control
No
Source: Gartner Research
Copyright 2001
T-13-6012 15 June 2001
3
Figure 2 Data Replication Options for Disaster Recovery (Continued) Platform Dependency
Company/Product Supported Host Platforms
Transaction Replication Type: Aware? Mirroring or Shadowing
Replication Selection Granularity
SQL Server
Microsoft SQL Server EE – Log Shipping IBM Geographic Remote Mirror for AIX
Windows 2000
Yes
Shadowing; logshipping and apply
Database
AIX
No
Unix
NSI Double-Take
Solaris
No
Logical volume No Mirroring or Shadowing; optional integration with HACMP for widearea cluster (HAGEO) Shadowing File No
Unix
Sun StorEdge Network Data Replicator (SNDR) Veritas Volume Replicator
Solaris
No
Windows
Legato Octopus
Windows NT, 2000
No
Logical volume No Mirroring or Shadowing; optional wide area cluster support through integration with VCS and Global Cluster Manager Shadowing File Yes
Windows
Legato CoStandbyServer NSI Double-Take
Windows NT
No
Mirroring
Windows NT, 2000
No
Windows NT, 2000
No
Shadowing; optional File integration with MSCS for wide area cluster support Shadowing File
Unix
Unix
Windows
Windows
Veritas Storage Replicator
HP-UX, Sun Solaris No (Windows 2000 planned 4Q01)
Mirroring or shadowing
Production Deployment to 100+ Customers? No
Logical volume No
Logical volume Yes
Simultaneous Use of Replica for Reporting? Yes
No
Yes for file systems (not databases) No
No
Yes for file systems (not databases) No
Yes
Yes for file systems (not databases)
No
Yes for file systems (not databases)
Source: Gartner Research
Host-based disk block replication alternatives, such as IBM’s Geographic Remote Mirror for AIX and Veritas Software’s Volume Replicator, are fairly new to the market and have not made significant market inroads yet. However, as they mature, they offer the potential for a less expensive solution to replicate all enterprise data, regardless of the disk platform chosen. For Windows environments, file-based replication solutions from NSI Software and Legato Systems have garnered a significant number of installations, and Veritas has recently entered this market. Also popular, and generally less costly, are log-based database replication solutions. These include solutions from DataMirror, Lakeview Technology, Microsoft, Oracle, Quest Software and Vision Solutions. Note that traditional trigger-based native DBMS replication is generally not appropriate for disaster recovery because of high system and administrative overhead on the primary site.
Copyright 2001
T-13-6012 15 June 2001
4
When making replication decisions, enterprises must first evaluate recovery point objectives. If some number of minutes (typically between five and 60 minutes) of lost transactions is acceptable, an asynchronous solution will probably provide a more cost-effective solution while still offering fast recovery. Where a small number of transactions can be lost (e.g., those uncommitted at the primary system and the secondary system), synchronous mirroring must be deployed. Other product evaluation criteria should be platform support, integration with other complementary products such as clustering technology, cost, speed of deployment, performance impact, product completeness and manageability. Finally, enterprises must keep in mind that the replication solutions are just one part of the disaster recovery plan. To ensure confidence in the recovery capability of the enterprise, frequent testing of these plans is vital (one to four times a year, depending on the amount of change to the applications and infrastructure). This includes testing of replication solutions under various failure/disaster scenarios to ensure appropriate recovery behavior of databases, file systems and applications. Definition of Terms Transaction-Aware Replication: Transaction-aware replication offers transaction-level replication, typically by electronically transmitting database or file changes (e.g., through logs) to the secondary site and applying those changes to a replica image. The primary advantage of this approach is that the replication method understands units of work (e.g., transactions) and has a greater potential for data integrity (via transaction rollforward/back), although data integrity is not guaranteed. Mirroring or Shadowing: Shadowing maintains a replica of databases and/or file systems, typically by continuously capturing changes and applying them at the recovery site. Shadowing is an asynchronous process, thus requiring less network bandwidth than synchronous mirroring. Recovery time objectives (RTOs) are significantly reduced (generally between one and eight hours, depending on the lag time for applying logs), while recovery point objectives (RPOs) are as up-to-date as the last receipt and apply of the logs. Mirroring maintains a replica of databases and/or file systems by applying changes at the secondary site in lock step with or synchronous to changes at the primary site. As a result, RTOs can be reduced to 20 minutes to several hours, while RPOs are reduced only to the loss of uncommitted work. Because it is synchronous, mirroring requires significantly greater network bandwidth than shadowing. Too little bandwidth and/or high latencies will degrade the performance of the production system. Copyright 2001
T-13-6012 15 June 2001
5
Deployed to 100 or More Sites? The number of production deployments will aid enterprises in understanding the maturity of the solution. In general, the fewer the production deployments, the higher the degree of risk associated with implementing the solution.
Acronym Key Check Processing Control CPCS System Database management system DBMS Data General DG Data Replication Manager DRM Fujitsu Siemens Computers FSC HACMP High-Availability Clustered Multiprocessing HAGEO Geographic High Availability HOARC Hitachi Open Asynchronous Remote Copy Hewlett-Packard HP Hitachi Remote Copy HRC Hitachi Extended Remote Copy HXRC Integrated Database IDMS Management System Internet service provider ISP Microsoft Cluster Server MSCS NonStop Kernel NSK Operating system OS Peer-to-Peer Remote Copy PPRC Remote Database Facility RDF Remote Recovery Data Facility RRDF Symmetrix Remote Data Facility SRDF Veritas Cluster Server VCS Extended Remote Copy XRC
Copyright 2001
Use Replica for Reporting? Most data replication solutions supporting disaster recovery do not enable inquiry/reporting of the replica at the secondary site (most require a third copy to be made for reporting). Using the replica for reporting offloads production workloads for horizontal scalability and achieves better resource utilization of the disaster recovery configuration (e.g., it reduces the total cost of ownership of a disaster recovery configuration). Bottom Line: Using data replication for disaster recovery has moved into the mainstream, as critical business processes are increasingly dependent on IT services. Selecting an approach, however, is not that simple, because each solution is dependent on specific IT infrastructure items, including disk subsystems, OSs, databases or file systems. Consequently, most enterprises will employ multiple tools to protect their critical data and applications. IT management needs to weigh all the factors discussed in this Research Note in making these decisions.
This research is part of a broader article consisting of a number of contemporaneously produced pieces. See COM-13-6392 on www.gartner.com for an overview of the article.
T-13-6012 15 June 2001
6
