Challenges and Solutions in Remote Mirroring - IBM

IBM Labs in Haifa

© 2004 IBM Corporation1 IBM Confidential

© Copyright IBM Corporation 2001

IBM TotalStorage™

© 2004 IBM Corporation

Challenges and Solutions in Remote Mirroring

IBM Labs in Haifa


Business Impact of a Disaster

Analysis showed that in the business segments, banking,distribution,

manufacturing, and insurance, IT outages that were 2 days, 3.3 days, 5.0

days and 5.6 days, respectively resulted in 25 % of the enterprises were

bankrupt immediately, 40 % were bankrupt within 2 years, and less than 7 %

were still in business after 5 years.

University of Minnesota, 1978

"50% of the companies that lose critical business systems for 10 or more

days (after a disaster) never recover. Ever ... 93% of the companies without

disaster-recovery plans in place were out of business five years later."PC Week, February 1995

IBM Labs in Haifa


Financial Impact of Disasters

Type of Business Average Hourly Impact

Retail Brokerage $6,450,000

Credit Card Sales Authorization $2,600,000

Home Shopping Channel $113,750

Catalog Sales Centers $90,000

Airline Reservations Centers $89,500

Cellular Service Activation $41,000

Package Shipping Service $28,250

On-line Network Connect Fees $25,250

ATM Service Fees $14,500

Source: Contingency Planning Research (12/95)

IBM Labs in Haifa


Synchronous Mirroring

Host

StorageCU #1

StorageCU #2

1

2

4

3

• The host must wait for the remote write

• No data loss

• Limited distance

• e.g., PPRC –Metro Mirroring

IBM Labs in Haifa


Asynchronous Mirroring

Host

StorageCU #1

StorageCU #2

1

3

2

4

• The host does not wait for the remote write

• Continuous background copy process

• Data loss is possible

• Practically unlimited distance

• e.g., XD PPRC

IBM Labs in Haifa


Data Consistency

� Dependent operations:� A: unassign Mr. X from Department 1� B: assign Mr. X to Department 2

� Consistency is lost if operation B is recorded whereas operation A is not.

� Loss of consistency is not acceptable.

� Data is lost if both operations A and B are not recorded.

� One of our customers is willing to lose 24 hours of data in a CAD system

IBM Labs in Haifa


The Bad Paths

� No Single Point of Failure (SPOF)

� Operations must continue normally even when mirroring fails

� Mirroring should resume as soon as possible

� Suspended mode – unmirrored operations are recorded

� Inconsistent mirror during Resume

� Point in time copy

IBM Labs in Haifa


Synchronous Mirroring – bad path #1

Host

StorageCU #1

StorageCU #2

1

2

4

3

• Host write fails because of mirroring

• Mirroring is suspended

• Host redrives write to CU1

• Unmirrored writes are recorded on CU1

• Consistency at risk when resuming

IBM Labs in Haifa



Host

StorageCU #1

StorageCU #2

1

2

4

3

• Host write fails because of mirroring


• Host redrives write to CU1

• Unmirrored writes are recorded on CU1

• Point in Time copyPiT copy

IBM Labs in Haifa



Host

• Host write A fails because of mirroring


• Host successfully redrives write A to CU1

• Host write B succeeds on both sites

• INCONSISTENCY!

StorageCU #1.2

StorageCU #2.2

StorageCU #1.1

StorageCU #2.1

A

B

IBM Labs in Haifa


Asynchronous Mirroring – good path

Host

• Host writes A

• Host writes B

• When is the mirror consistent?

StorageCU #1.2

StorageCU #2.2

StorageCU #1.1

StorageCU #2.1

A

B

IBM Labs in Haifa


Asynchronous Mirroring – good path

Host 2

• Host 1 writes A

• Host 2 writes B that depends on A

• When is the mirror consistent?

• There is no common time base for Open systems

StorageCU #1.2

StorageCU #2.2

StorageCU #1.1

StorageCU #2.1

A

BHost 1

IBM Labs in Haifa


Consistency Groups

� Groups of write operations s.t. a write in an older group is never dependent on a write in a newer group

� Procedure:� Instruct all control units to stop acknowledging writes (Freeze)� Wait for all control units to acknowledge� Instruct all control units to form new consistency groups� Wait for all control units to acknowledge� Instruct all control units to resume acknowledging writes

(Thaw)

� Note that writes are not stopped during the “freeze”

IBM Labs in Haifa


Consistency Group Formation

Coordinate Sharks(host impact)

Let CG data drain to remoteRecord new writes

Prepare for FLC

Commit FLC

. . .

CG Interval Time(Possibly 0)

Max coordinationTime (default: 50 ms)

Max Drain Time(default 4 mins.)

* Tuneables in blue

•Prepare for FLC – Establish Revertible (can roll back if fails)•Commit – Now you have a consistent copy of the data

IBM Labs in Haifa


Global Mirroring – A Superior Disaster Recovery Solution

� Currency� IBM: 3-5 seconds� EMC - 5-10 secs, default is 30-60

secs

� Cache requirements� IBM – minimal, no mandatory delay,

CGs formed on the remote site� EMC - additional cache needed. the

SRDF/A solution fills up the cache� Main differentiator - when cache fills

up EMC stops sending data, ESS continues to send until the opportunity arises to build a CG

� Fibre Channel links� IBM - 2 recommended� EMC - more than 2 recommended

� Volume allocation� IBM - 2 volumes at the remote site

for each volume at the primary site � EMC - says one is sufficient, but

recommends 2

� Cross system data consistency� IBM - Cross box in Open

environments as well as in z/OS environments

� EMC - z/OS environments only

� Consistency Group Management� IBM - no special Host software

required, CG maintained by ESS� EMC - Host software required

IBM Labs in Haifa


Sync PPRC Performance Quotes (Sonny Williams)

� At 0 distance with 8 links DMX tops out at 14275 ops/second - we do better with 1 link

� Both solutions work the same when DMX with 8 links and 0 distance, and ESS with 1 link at 100km

� With 2 links at 100km we beat their 8 link config at 0 km� Better performance with much less infrastructure and greater distance

IBM Labs in Haifa


�The performance data contained herein was obtained in a controlled environment based on the use of specific data. Actual results that may be obtained in other operating environments may vary significantly. These values do not constitute a guarantee of performance.

�Product data is accurate as of initial publication and is subject to change without notice.

�No part of this presentation may be reproduced or transmitted in any form without written permission from IBM Corporation.

�References in this document to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM program product in this document is not intended to state or imply that only IBM's program product may be used. Any functionally equivalent program may be used instead.

�The information provided in this document is distributed on an "AS IS" basis without any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into their operating environment.

�While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

�IBM, DFSMS, DFSMShsm, DFSMSdss, Enterprise Storage Server, ESCON, FICON, OS/390, S/390, z/OS, zSeries and TotalStorage are trademarks or registered trademarks of International Business Machines Corporation.

�Other company, product, and service names may be trademarks or registered trademarks of their respective companies.

Disclaimers and Trademarks

Challenges and Solutions in Remote Mirroring - IBM

Documents

Transcript of Challenges and Solutions in Remote Mirroring - IBM