© 2009 ibm corporation ibm system storage ibm software ibm services ibm systems introduction to...

© 2009 IBM Corporation

IBM System Storage

IBM Software IBM Services

IBM Systems

Introduction to Selling Rapid Recovery Technology & Business Solutions

John SingExecutive IT Consultant WW System Storage [email protected]

2© 2009 IBM Corporation

Storage Sales Academy

IBM Software IBM Services IBM Systems

John Sing 27 years of experience with IBM in high end servers, storage, and software

► 2002-2009: IBM Systems Group Executive IT Consultant – IT and Business Continuity Strategy and Planning

► 1998-2001: IBM Storage Subsystems Group - Enterprise Storage Server Marketing Manager, Planner for ESS Copy Services (FlashCopy, PPRC, XRC, Metro Mirror, Global Mirror)

► 1994-1998: IBM Hong Kong, IBM China Marketing Specialist for High-End Storage

► 1989-1994: IBM USA Systems Center Specialist for High-End S/390 processors

► 1982-1989: IBM USA Marketing Specialist for S/370, S/390 customers (including VSE and VSE/ESA)

[email protected]

© 2009 IBM Corporation

IBM System Storage

IBM Software IBM Services

IBM Systems

Introduction to IBM DS8000 Metro Mirror Consistency Group




Concepts of Disk Mirroring

Copy data / logical LUN / file to a remote disk system ► Basically transferring a cache image to remote disk system

Important feature is Suspend / Resume

► When mirroring is suspended:● Disk subsystem uses bitmaps to track incremental changes during suspend

► Upon resync, only incremental changes need to be sent

Highly, highly recommended is a ‘tertiary’ copy (third copy)► Used for testing the restart, while keeping mirroring running

► Used for saving a golden’ copy

● In case of failure during resync● In case of problems during recovery / restart




Synchronous Disk Mirroring What is synchronous disk

mirroring used for?► For applications that need zero data loss,

► Provides the tightest Recovery Point Objective

► BC Tier 6 or BC Tier 7 solution

Can be to a:► Remote location : for Disaster recovery with

zero data loss OR

► Local high availability: for local resiliency of storage in the local data center

Highly recommended to:► Have enough remote site disk to make ‘safety

copy’ (FlashCopy) of secondary disk - called “tertiary copy”

► In case of failure during resync

► To preserve a ‘golden’ copy, in case of problems during recovery / restart

SAN SAN

1. Application sends a write request1. Application sends a write request

3. Receipt confirmation from remote disk system

3. Receipt confirmation from remote disk system

2. Data written to remote disk cache2. Data written to remote disk cache

4. Write complete signal to the application4. Write complete signal to the application

Remote disk is exactly in “lock step”at the write I/O level




Different ways to implement storage replication

In storage subsystem itself

In a storage

appliance

or

or




Additional ways to use storage replication - 1

Point-in-Time followed by remote mirror

A

B

C

D

Point-in-Time followed by remote mirror followed by Point-in-Time




Additional ways to use storage replication - 2

A C

B

A C

D

Point-in-Time from a remote mirror primary

Make a Point-in-Time safety copy of remote mirror




Additional Ways to use replication - 3

A C

G

Sync mirroring for local / metro high availability

Async mirroring for Out of region recovery




IBM Disk Mirroring Technologies

DS8000

DS6000

ESS

DS5000DS3000 DS4000

N3000

.

N6000N7000

Entry

Midrange NAS/iSCSI Enterprise

SVC

Virtualization

Metro / Global MirrorThree site synchronous and asynchronous mirroring

► DS8000, N series

Global Mirror Asynchronous Mirroring DS8000, DS6000, ESS,

SVC, DS4000 / DS5000, N series

Metro Mirror Synchronous Mirroring DS8000, DS6000, ESS, SVC, XIV, DS4000 / DS5000, N series

XIV




What is Data Consistency




Proper sequence of writes - for data consistency at application level

Many examples where start of one write operation is time dependent on the completion of a previous write

► Can be on a different disk group or even different disk frame► Database logs, catalogs, VTOCs, index & data components

Note that storage hardware by itself is just replicating the storage bit pattern► By itself, storage does NOT know about application inter-LUN, inter-volume dependencies

1. Log update

2. Updatedatabase

3. Mark Log - Update complete




i.e. do we wish to stop production, due to telecom line failure?

Usually, No. We wantproduction to keep running

If so, then what mayhappen is…..

Many application-level issues in disk mirroring This is just one example…..

In this example …. on a permanent link failure, disk mirroring simply marked the link as down, and accepted the I/O, in order to keep primary site production running ► i.e. do not want to stop production just because telecom went down

► As a result, #3 “Log Update Complete” flowed to remote.

Storage mirroring, by itself, doesn’t know about application-level, inter-LUN dependencies.

1. Log update

XPermanent

LinkFailure

3. Mark Log - Update complete

What Action?

Does remote

database match?

No! (bad!!)




Wake Up Question“Synchronous disk mirroring all by itself, assures no application

data loss, and assures application restart.”True or False?

False




By itself, storage does not know about:► The inter-volume, application-level relationships

Therefore, when mirroring databases:► The concept of a session needs to be added to the disk mirroring functionality

This session is called a Consistency Group (CG)► Consistency Group session defines all of the volumes in the database

► Storage Consistency Group function manages and keeps data consistency across all of these volumes

Storage microcode (sometimes in combination with external server software) implements the Consistency Group function ► Possible to have CG span disk subsystems

● Using appropriate microcode or software

Data Consistency is provided by a Consistency Group function




Global Mirror and Consistency Groups

Source Target

Data consistent copy

Across multiple LUNsConsistency Group

Method to maintain Consistency differs between sync and async mirroring

Asynchronous – CG creation and maintenance can be accomplished by different methods including:

►Point in Time identify at primary site and transmit changes;

►Time-stamping, Sequence numbers and sorting

►FIFO queue




Consistency Group technology is different – many methods. The most commonly mis-understood is synchronous mirroring:

► We will show how DS8000 uses the concept of FREEZE

► FREEZE will suspend writing data to secondary, consistently, across all volumes in the Consistency Group

► Automation on a server is needed to monitor and manage synchronous mirroring Consistency Groups and FREEZE

► Understanding this allows one to more easily understand other storage replication Consistency Group mechanisms

Metro Mirror and Consistency Groups

REMEMBER : The goal is to create a consistent Point in Time copy at the secondary site that is recoverable.




DS8000 Metro Mirror Consistency Group FREEZE - 1

Upon error, top priority message gets sent to automation server

Automation server responds by sending FREEZE/SUSPEND command to all disk logical subsystems (LSSs)

Mirrored volumes in LSSs all go into “Extended Long Busy” – to assure that any and all write IO’s are queued across all volumes in Consistency Group

1. Log update

X

Automationserver

Action?





Production continues to run, but incoming write I/Os are queued long enough so that automation server can…

SUSPEND all the mirroring links, across all LSSs and volumes in the CG

1. Log update

Automationserver





Once FREEZE/SUSPEND is reported complete…

Automation server will issue FREEZE/RUN command, releasing all the queued IO to run locally. Production runs. If just a link failure, no outage to production.

1. Log update

Automationserver

However, as the mirroring links are suspended, the remote site received no further IOs, and is an exact Point in Time image as of the last instant before the error trigger event




Consistency Group Consistency Group is a requirement for:► Any disk mirroring of multi-LUN, multi-

volume databases

Therefore, a disk platform selection consideration is:

► Always ask the customer what the maximum number of LUNs will be required to be in the same Consistency Group

► Various disk subsystems might have limits on maximum number of LUNs in a Consistency Group

● If more LUNs are required in a Consistency Group, you need to upgrade to a higher function storage subsystem

Source Volumes

Consistent secondaryvolumes

Database

Database Logs and Journals match

Data Tables

L

J

D

D

D

D

LD

DDD

JMirroring

L = Log J = Journal D = Data




Consistency Group Scalability and General Hierarchy

Metro Mirror Consistency Group

DS 3000► No native support (3400 via SVC)

DS5000/4000► Note: Does not support Metro Mirror Consistency

Group

XIV► Will support CG in YE2009, doesn’t support today

N series► Equivalent function provided by N series software

SAN Volume Controller► Maximum CG: 1,024 LUNs► Up to 256 consistency groups, 256TB target and

source capacity

DS8000, DS6000, ESS 800► Has largest and most scaleable Metro Mirroring► Maximum CG: Unlimited ► Multiple disk subsystems (or LSS’s) requires

automation software

Global Mirror Consistency Group

DS 3000► No native support (3400 via SVC)

DS5000/4000► DS5000 Global Mirror supports up to 128 LUNs in

a Consistency Group

XIV► Available YE2009, doesn’t support today

N Series► Equivalent function provided by N series software

SAN Volume Controller (at SVC 5.1)► Maximums CG: 1024 LUNs► Up to 256 consistency groups, 256TB target and

source capacity

DS8000, DS6000, ESS 800► Largest and most scaleable Global Mirroring► Maximum CG: Up to 17 primary side DS8000

systems ► Supports any attaching platforms (can be mix of

platforms )



IBM Software IBM Services IBM Systems 23

Learning Points

The concept of Consistency Groups can be explained as follows:

By itself, storage does not know about:

► The inter-volume, application-level relationships

Therefore, when mirroring databases:

► The concept of a session needs to be added to the disk mirroring functionality.

This session is called a Consistency Group

► Consistency Group session defines all of the volumes in the database

► Consistency Group function manages and keeps data consistency across all of these volumes

Storage microcode (sometimes in combination with external server software) implements the Consistency Group function




8 IBM Corporation 1994-2008. All rights reserved.References in this document to IBM products or services do not imply that IBM intends to make them available in every country.

Trademarks of International Business Machines Corporation in the United States, other countries, or both can be found on the World Wide Web at http://www.ibm.com/legal/copytrade.shtml.

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.UNIX is a registered trademark of The Open Group in the United States and other countries.Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.Other company, product, or service names may be trademarks or service marks of others.

Information is provided "AS IS" without warranty of any kind.

The customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.

Information concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products.

All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.

Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning.

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here.

Photographs shown may be engineering prototypes. Changes may be incorporated in production models.

Trademarks and Disclaimers

© 2009 ibm corporation ibm system storage ibm software ibm services ibm systems introduction to...

Documents

ibm hong kong

ibm systems group executive

ibm usa marketing specialist

ibm china marketing

highend storage

storage replication

storage appliance

local resiliency of