• No results found

Disaster Recovery: Weighing Data Replication Alternatives

N/A
N/A
Protected

Academic year: 2021

Share "Disaster Recovery: Weighing Data Replication Alternatives"

Copied!
6
0
0

Loading.... (view fulltext now)

Full text

(1)

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.

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.

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 hot-site providers Comdisco, IBM BRS and SunGard, or at Web-hosting 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

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?

(2)

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-to-disk 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.

(3)

Copyright 2001

T-13-6012

15 June 2001 3

Figure 1

Data Replication Options for Disaster Recovery Platform

Dependency

Company/Product Supported Host Platforms Transaction Aware? Replication Type: Mirroring or Shadowing Replication Selection Granularity Production Deployment to 100+ Customers? Simultaneous Use of Replica for Reporting? Host-independent, disk-dependent (disk-to-disk remote copy)

Compaq DRM Unix (Compaq, IBM, Sun), Windows

No Mirroring Physical disk volume

No No

Host-independent, disk-dependent (disk-to-disk remote copy)

EMC SRDF MVS–OS/390, Unix (IBM, HP, Sun), Windows, Unisys, Bull, FSC, ICL, AS/400

No Mirroring Physical disk volume

Yes No

Host-independent, disk-dependent (disk-to-disk remote copy)

Hitachi HRC MVS-OS/390, Major Unix (HP, Sun, IBM AIX and NUMA-Q, Compaq, NCR, SGI), Windows, NetWare

No Mirroring Physical disk volume

Yes No

Host-independent, disk-dependent (disk-to-disk remote copy)

Hitachi HOARC MVS-OS/390, Major Unix (HP, Sun), Windows

No Shadowing Physical disk volume

No No

Host-independent, disk-dependent (disk-to-disk remote copy)

IBM PPRC MVS-OS/390, Unix (IBM AIX and NUMA-Q, Sun, HP, Compaq, DG), Windows, Novell NetWare

No Mirroring Physical disk volume Yes, OS/390 only No Host-independent, disk-dependent (disk-to-disk remote copy)

HP Continuous Access XP

Major Unix (HP, Sun, IBM, Compaq), HP MPE, Novell, Windows and Red Hat Linux

No Mirroring Physical disk volume

No No

Host-independent, disk-dependent (disk-to-disk remote copy)

HP Continuous Access XP Extended

Major Unix (HP, Sun, IBM, Compaq), HP MPE, Novell, Windows and Red Hat Linux

No Shadowing Physical disk volume

No No

MVS-OS/390 ENET RRDF MVS-OS/390 Yes; supports DB2, IMS, CICS, IDMS, CPCS, ADABAS and SuperMICR Electronic journaling (logging) and optional shadowing for IMS and DB2

DBMS (IMS and DB2) Yes Yes MVS-OS/390 Amdahl XRC, Hitachi HXRC, IBM XRC

MVS-OS/390 No Shadowing Physical disk volume

No No

NSK (Compaq Himalaya)

Compaq RDF NSK Yes Shadowing Transaction Yes Yes Oracle Oracle Standby

Database

All platforms Oracle DBMS supports

Yes Shadowing; log-shipping and apply

Database Yes No Oracle Quest Software

SharePlex (for Unix)

Unix (HP, Sun) Yes Shadowing; log-based

Tablespace Yes Yes OS/400 Data Mirror High

Availability Suite

OS/400 Only when using AS/400 commitment control

Shadowing; wide-area cluster support

DB2/400 DBMS, OS/400 object Yes Yes OS/400 Lakeview Technology MIMIX software suite

OS/400 Only when using AS/400 commitment control

Shadowing; wide-area cluster support

DB2/400 DBMS, OS/400 object

Yes Yes

OS/400 Vision Solutions High Availability Suite

OS/400 Only when using AS/400 commitment control

Shadowing; wide-area cluster support

DB2/400 DBMS, OS/400 object

Yes Yes

(4)

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

Figure 2

Data Replication Options for Disaster Recovery (Continued) Platform

Dependency

Company/Product Supported Host Platforms Transaction Aware? Replication Type: Mirroring or Shadowing Replication Selection Granularity Production Deployment to 100+ Customers? Simultaneous Use of Replica for Reporting? SQL Server Microsoft SQL Server EE – Log Shipping

Windows 2000 Yes Shadowing; log-shipping and apply

Database No Yes

Unix IBM Geographic Remote Mirror for AIX

AIX No Mirroring or

Shadowing; optional integration with HACMP for wide-area cluster (HAGEO)

Logical volume No No

Unix NSI Double-Take Solaris No Shadowing File No Yes for file systems (not databases) Unix Sun StorEdge

Network Data Replicator (SNDR)

Solaris No Mirroring or shadowing

Logical volume No No

Unix Veritas Volume Replicator

HP-UX, Sun Solaris (Windows 2000 planned 4Q01)

No Mirroring or Shadowing; optional wide area cluster support through integration with VCS and Global Cluster Manager

Logical volume No No

Windows Legato Octopus Windows NT, 2000 No Shadowing File Yes Yes for file systems (not databases) Windows Legato

Co-StandbyServer

Windows NT No Mirroring Logical volume Yes No Windows NSI Double-Take Windows NT, 2000 No Shadowing; optional

integration with MSCS for wide area cluster support

File Yes Yes for file systems (not databases) Windows Veritas Storage

Replicator

Windows NT, 2000 No Shadowing File No Yes for file systems (not databases) Source: Gartner Research

(5)

Copyright 2001

T-13-6012

15 June 2001 5

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 roll-forward/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.

(6)

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.

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.

Acronym Key

CPCS Check Processing Control System

DBMS Database management system

DG Data General

DRM Data Replication Manager

FSC Fujitsu Siemens Computers

HACMP High-Availability Clustered

Multiprocessing

HAGEO Geographic High Availability HOARC Hitachi Open Asynchronous

Remote Copy

HP Hewlett-Packard

HRC Hitachi Remote Copy

HXRC Hitachi Extended Remote Copy

IDMS Integrated Database Management System

ISP Internet service provider

MSCS Microsoft Cluster Server

NSK NonStop Kernel

OS Operating system

PPRC Peer-to-Peer Remote Copy

RDF Remote Database Facility

RRDF Remote Recovery Data Facility

SRDF Symmetrix Remote Data Facility

VCS Veritas Cluster Server

References

Related documents