ibm xiv storage system series asynchronous mirroring

7/30/2019 IBM XIV Storage System Series Asynchronous Mirroring

http://slidepdf.com/reader/full/ibm-xiv-storage-system-series-asynchronous-mirroring 1/16

IBM Systems and Technology

Technical White Paper

IBM XIV Storage

System Series Asynchronous Mirroring Promoting System Optimization for Business Continuity

Contents

2 The impact of dataunavailability

4 Key requirements of asynchro-

nous mirroring solutions

6 Powerful XIV mirroring features

9 High performance mirroring

10 Flexible XIV deployment and

implementation

11 Minimal administration

13 Low total cost of ownership

13 Conclusion

14 The XIV Storage System series

Executive summary This paper highlights the importance of mirroring as a data protection

strategy to minimize risk of data and system unavailability and the

advantages of IBM® XIV ® Storage System asynchronous mirroring.It covers the system’s essential mirroring solution characteristics and

organizational mirroring requirements that ensure business continuity.

While this paper touches on the value of synchronous mirroring in

certain situations, its primary focus is asynchronous mirroring.

Reading this paper will give you a clear understanding of effective

enterprise mirroring implementations and the IBM XIV Storage System

series solution, which offers a comprehensive, successful mirroring

strategy for today and the future.

IntroductionEnterprises rely on their data for business success. It is impossible for

most organizations to function day-to-day without online information

about customers and products or the data infrastructure that supports

business processes. Organizations use data replication to ensure data is

available in the event of a system failure or a disaster that degrades system

functionality or renders a data center inaccessible. Regardless of the

cause—equipment failure, natural disaster, or terrorist attack—companies

need to implement a method to minimize and remedy the adverse

business outcomes of these situations, which can heavily impact revenues,



2



expose organizations to high risk, and cause a slew of other

serious problems. Data mirroring , one of the primary data

replication methods, enables organizations to preserve data

by copying it to secondary systems as it is created online.

Measuring the impact of data

unavailability Two measures define mirroring solution recovery requirements

for organizations: recovery point objective (RPO) and recovery time

objective (RTO). RPO describes the acceptable amount of data

loss measured in time. The RPO is the point in time to which

one must recover data as defined by the organization. This is

generally a definition of what an organization determines is an

“acceptable loss” in a disaster situation.

RTO defines the maximum acceptable amount of time torestore both data and the systems to access the data in order

to prevent unacceptable consequences associated with a break

in business continuity.

The optimal RPO and RTO are zero (zero data loss and zero

recovery time following a disaster), but such objectives may

not be always possible—or justified—due to implementation,

support, and recovery costs, and the latency resulting from the

distance between replication sites.

While mission-critical applications typically require a very low

RPO, non-critical applications may be able to suffice with ahigh RPO. For instance, a backup routine that runs once a

day can have an RPO of 24 hours. Assigning a low RPO to

non-critical applications wastes precious system and network

resources.

Acceptable

data loss

0+ Seconds Minutes Hours

Critical applications;

financial

data,transactions

Low priority

backup applications;

testingenvironment

Productivity applications;

email

RPO

Figure 1: RPO and data value. The higher the RPO, the higher the potentialdata loss

Synchronous versus asynchronous mirroring

Synchronous mirroring and asynchronous mirroring are two

approaches for accommodating application-mirroring

requirements.

With synchronous mirroring, data written by a host to a storage

volume (the Master peer on a primary system) is replicated to

a secondary storage system (the Slave peer) before the write



3



Synchronous mirroring

Asynchronous mirroring

Host Master Slave

Host Master Slave

1. Host writes new data to Master

4. Master acknowledges write by host

Extended response time lag

Synchronization gap between peers2. Master acknowledges write by host

1. Host writes new data to Master

2. Master replicates to Slave

3. Master replicates to Slave

3. Slave acknowledges write by Master

4. Slave acknowledges write by Master

Figure 2: Synchronous and asynchronous mirroring. With synchronousmirroring, RPO is 0, yet response times increase as the distance between

peers increases. With asynchronous mirroring response times are notdependent on link bandwidth and quality, but the RPO is greater than 0.

completion acknowledgement is sent back to the host. This

approach yields complete data currency between the Master

and the Slave (RPO of 0), yet introduces latency while the

host waits for acknowledgement.

With asynchronous mirroring, data written to the Master

is acknowledged immediately to the originating host, yet is

replicated to the Slave at a later time. Therefore, asynchronous

mirroring offers lower write latency at the cost of increased

RPO (less data currency and lack of synchronization between

the Master and Slave).

Asynchronous mirroring is advantageous for a variety of use

cases and is a compelling solution for replication between

distant sites, since it eliminates the latency inherent to

synchronous mirroring; it can offer lower implementation

costs as well.

Effective asynchronous-mirroring planning and implementation

can both minimize the currency gap between mirrored peers

and help organizations realize better data availability with lower

implementation and operational costs.

The RPO possible with asynchronous mirroring is a function

of variables such as network bandwidth, line quality, distance,

latency, and mirroring system functionality. RPO can range

from mere seconds to minutes or hours, depending on

application requirements and the mirroring implementation. With its low latency and flexibility in supporting low and

high RPOs, asynchronous mirroring is an attractive option,

particularly when long distance, low latency replication is

required.

IBM XIV Storage System series asynchronous mirroring

The IBM XIV Storage System series, with pioneering

architecture and a powerful feature set, offers comprehensive

asynchronous mirroring functionality that helps guarantee data

availability in the event of failure or disaster, providing valuable

enterprise-class benefits not available in traditional mirroringsolutions.



4



Key requirements of asynchronous

mirroring solutionsIn addition to being reliable, mirroring solutions need to

provide other essential data replication features:

Requirement #1: An enterprise-class

feature setLow RPO for prioritized applications. Because of the severe

repercussions that data loss can have on organizations, minimal

data loss with quick data recovery is a principal mirroring

solution requirement.

Synchronous mirroring enables administrators to restore all

Master data from its corresponding Slave peer at the price of

increased write latency. This solution, however, is appropriate

for replication distances no greater than 62 miles/100 km(potentially up to 186 miles/300 km—with more powerful

equipment and infrastructure). Synchronous mirroring is less

appropriate over links where latency is already pronounced.

Asynchronous mirroring virtually eliminates latency concerns at

the price of reduced data currency, with the RPO reflecting

the organization’s acceptable amount of data loss in time units.

An RPO setting of 30 seconds indicates that the Slave’s data

currency should be no more than 30 seconds older than the

Master’s. An RPO equal to or less than 30 seconds is common

for many high-end mirrored applications.

Multiple RPOs. In an optimal environment, all applications

would mirror with an RPO of 0. Factors governing application

profiles, disaster recovery (DR) requirements, replication

topology, infrastructure, and cost rarely enable organizations

to realize this objective.

Assigning the same RPO for all mirrored applications regard-

less of their data’s criticality can typically result in suboptimized

bandwidth utilization and impaired performance. In order to

balance application criticality with available resources and net-

working bandwidth, most organizations prefer instead to set

individual RPOs per application. Assigning application-based

RPOs can help organizations optimize bandwidth utilization

for mirroring, accommodating a mix of low and high criticality

applications.

Support for application-consistent recovery points. An

application-consistent recovery point represents the data whose state

is guaranteed to be consistent from an application perspective.

Creating an application-consistent snapshot on a storage system

requires integrated host software that generates the snapshot

only after ensuring an application-consistent state. In addition,

creating application-consistent snapshots requires host process-

ing, which can adversely affect application response time.

A crash consistent recovery point recovers data to the point in time

at which the crash occurred, but does not guarantee application

data integrity. Therefore, to promote recovery data integrity,

an application-consistent recovery point is superior to a crash

consistent recovery point.

The ability to support both application- and crash-consistent

recovery for any mirror is extremely advantageous, since it

allows organizations to implement their preferred recovery approach based on data criticality.

Ability to consistently mirror a group of volumes.

Applications may require consistent replication of more than

one volume. For example, a database application that spans

multiple volumes requires cross-volume mirroring consistency.



5



Requirement #2: Enterprise-class

mirroring performanceHigh-performance mirroring is critical for facilitating low

RPO replication with little to no impact on general application

performance. The storage system should provide high perform-

ance even when mirroring is configured over suboptimal links

that experience intermittent disruptions.

Requirement #3: Flexible mirroring

deployment and implementationFlexible topology configurations. The most common

mirroring topology is a one-to-one mirror between systems

at different sites, with multisite organizations increasingly

implementing—or considering—multisystem/multisite

mirroring configurations. Two popular options for such

deployments are the many-to-one and one to-many topologies(see Figures 7 and 8 below).

With the one-to-many configuration, a single system (hosting

one or more Master volumes) replicates to several systems

(functioning as Slaves). Each of the Master’s mirrored volumes

replicates to one of several Slaves. This enables the organization

to distribute replication load across multiple links and share the

recovery responsibility among multiple sites.

A many-to-one configuration replicates multiple independent

Masters to a single designated Slave system at a single recovery

site. As with the one-to-many configuration, the many-to-one

configuration also leverages multiple links for distributed

replication.

A hybrid option (see Figure 9 below) combining characteristics

of both one-to-many and many-to-one topologies is not

uncommon.

Organizations are increasingly considering using iSCSI

(Internet Small Computer System Interface) links for low-cost

inter-site mirroring. Customers expect advanced mirroring

solutions to offer mirroring over both Fibre Channel (FC)

and iSCSI.

Bidirectional mirroring . Traditional storage mirroring imple-

mentations may be unidirectional—with replication from a local

system (also referred to as a Primary system) to a remote system

(also referred to as a Secondary system)—but not the other way

around. More advanced configurations allow each system to

function as a Master for certain volumes and as a Slave for other

volumes. This configuration enables organizations to distribute

the application load and traffic to better accommodate business

needs and performance goals offering greater storage deploy-

ment flexibility.

Ability to accommodate changing mirroring requirements.

Mirroring requirements are dynamic; they are dependent upon

business requirements, infrastructure changes, and/or new

application priorities. Increasingly, organizations are evaluating

improved disaster recovery topologies for their environments,

wanting to make changes to their topologies with minimal

effort. For example, an organization may want to change an

existing synchronous mirror configuration to asynchronous

replication. Being able to make this type of change without

reinitializing the Slave helps minimize mirroring setup time,

maximizing system availability and optimizing utilization of network bandwidth for other mirror processing.

Requirement #4: Minimal administrative

overhead Mirroring deployments are notorious for their complexity and

heavy setup and implementation requirements—as well as hefty

planning, training, and setup time. Overly imposing and cryptic

mirroring documentation often makes the implementation

more cumbersome.



6



Mirroring complexity notwithstanding, enterprise-class mirror-

ing should be streamlined, offering significantly lower effort

than traditional solutions. The enterprise mirroring solution

should feature:

1. Easy and quick setup. Mirroring configuration options

should be laid out clearly, with remote connectivity easily

defined through a graphical user interface (GUI) or a

straightforward command line interface (CLI). Volume

mirroring should be a seamless process, with minimum

setup steps.

2. Streamlined management . Mirroring management should

feature streamlined status monitoring with automatic

alerting. Mirroring displays should be simple and straight-

forward. Common mirroring management tasks, such

as changing a mirroring role or adding a volume to a

consistency group, should be easy to perform.

3. Simple testing and failover processes . The mirroring solution

should enable customers to easily test and validate the

mirroring configuration and replica. More importantly,

the solution must feature a reliable, no-fuss failover

process that does not mandate extensive training.

4. Comprehensive and clear reporting and alerting . The mirror-

ing solution should feature effective, helpful mirroring

status reporting and alerts when the RPO cannot beaccommodated, and clearly indicate the networking issues

that risk attainment of the RPO.

The powerful XIV storage mirroring

feature set The IBM XIV storage meets and exceeds enterprise-class

mirroring requirements through a rich set of features.

Proven snapshot-based technology for asynchronous

mirroring . Asynchronous mirroring employs patented

IBM XIV breakthrough snapshot technology, which streamlines

implementation while demonstrating stellar performance for

low-RPO mirroring applications. In contrast with traditional

snapshot implementations, IBM XIV snapshot technology is

an inherent part of the base system architecture; it has not been

appended to a preexisting system architecture. This level of

integration obviates architectural restrictions that have tradi-

tionally prevented systems from providing high snapshot related

performance.

Notable IBM XIV snapshot mirroring features include:

● Support for a large number of snapshots● Functionality to snapshot a volume, a volume consistency

group, or another snapshot ● Ability to restore a volume, a volume consistency group,

or a snapshot—from a snapshot ● High performance by leveraging effective snapshot

technology

Smart IBM XIV asynchronous mirroring design . With

asynchronous mirroring, mirror-related snapshots are used

to determine the data that needs to be replicated. The system

uses these snapshots to capture the state of the Master being

mirrored.

XIV asynchronous mirroring attains synchronization between

Master and Slave peers through a recurring data replication

process, called a Sync Job, which is triggered automatically according to user-configurable schedules. (The Sync Job can

also be triggered manually or via a script.) The Sync Job takes a

snapshot of the Master and looks for data differences between

that snapshot and the previous mirroring-related Master snap-

shot on the Slave. The Sync Job then replicates Master data

corresponding to these differences with the Slave. At the

completion of a Sync Job, new mirroring-related snapshots

are created on the Slave and the Master.



7



Low RPO for critical applications. The IBM XIV system

supports mirroring RPOs as low as 30 seconds and

replication intervals as low as 20 seconds.

Independent RPO and interval. In addition to IBM XIV

system support for broad RPO and interval ranges,

the IBM XIV mirroring implementation allows administrators

to set RPOs and intervals for each mirror independently

(or per IBM XIV consistency group). This enables administra-

tors to accommodate mirroring requirements based on applica-

tion criticality, rather than forcing them to set the same RPO

for all applications—which could cause inefficient utilization

of system resources and adversely impact performance.

Automatic and manual replication . The IBM XIV system

supports both automatic and manual initiation of

asynchronous replication jobs. With automatic replication,

the system allows administrators to specify schedules based

on intervals ranging from 20 seconds to 12 hours. Manual

replication makes it possible to create an ad hoc synchroniza-

tion job or to trigger a synchronization job from a script.

Manual replication can be coordinated with host activitiesto create snapshots that represent application-consistent

recovery points.

For additional business continuity benefit, the system allows

administrators to concurrently employ both manual and

schedule-based replication types for each mirror—enabling

manual synchronization for mirrors already using an interval

based schedule.

Support for both application- and crash-consistent

recovery . The XIV system supports both application-

and crash-consistent recovery points for any given mirror.

Support for mirroring volume groups. With IBM XIV

system support for mirrored consistency groups, administrators

can mirror volume groups consistently, easily adding volumes

to mirroring groups and safely removing volumes from them

without stopping or otherwise affecting volume mirroring.

Online and off line initialization options. The objective of

the initialization process is to establish an initial replica of the

Master state on the Slave. XIV storage initialization establishes

a baseline for the master state when mirroring begins. IBM XIV

online initialization enables over-the-wire Slave initialization.

Local

site

Master peer Slave peer

most_recent

last_replicated

Replication

last_replicated

Remote

site

Figure 3: Asynchronous mirroring snapshots. The IBM XIV system maintains three snapshots per mirror coupling: two on the Master and one on the Slave.

The system captures a consistent (recoverable) Master state in the last_replicated snapshot (stored on both Master and Slave). The most_recent snapshotrepresents the most recent Master state that needs to be replicated to the Slave. The system determines the data to replicate by comparing the Master’s

most_recent to the last_replicated snapshots.



8



Online (over-the-wire)initialization

Initialization starts

Initializationreplicates initial

image to the Slave

Master Slave

Master finishes Initialization

Time

Initializationstarts

Initialization finished and

ongoingmirroring can

commence

Figure 4: Online initialization. After a new mirror is defined, a snapshot of the

Master is taken, representing the initial peer state. When mirroring is first acti-vated, the system identifies the data that needs be replicated as part of theinitialization phase. An over the-wire synchronization process then replicates

the data from the Master to the Slave.

The IBM XIV offline initialization feature enables administrators

to initialize the Slave peer without requiring an inter-site link

to replicate the Master to the Slave. When a mirror is first acti-

vated after offline initialization, the system takes a snapshot of the Master, compares that snapshot with the Slave replica, and

replicates differences to the Slave. One of the salient benefits

of an off-line initialization implementation is that prior to

ongoing mirroring, the system verifies the Slave’s contents

against the Master and does not automatically assume the

Slave is a valid replica.

Offline initialization

Initialization starts

Initialization comparesimages and only

replicates differences

Initialization complete

Initialization

starts

Master Slave

Time

Initialization

finished and

ongoing

mirroring can

commence

Figure 5 : Of fline initialization. Instead of running an over-the-wire initializa-

tion, a backup of the Master can be shipped to a remote recovery site. Oncethe backup is restored on the Slave, the system can establish mirroring afterfirst comparing the Master with the restored Slave replica. This approach

can shorten the initialization process considerably and optimize bandwidthutilization. The mirror is defined with a parameter indicating that a Masterreplica exists on a remote system. Based on this parameter, the system

determines that offline initialization is set.

Maximized data resilience thanks to mirroring . With

mirroring, an IBM XIV system can overcome a storage

media error on the Master system using data from its Slave.

IBM XIV supports both synchronous mirroring and

asynchronous mirroring recovery (as long as the media

error is in a partition shared between the volume and the

Last Replicated Snapshot ).



9



IBM XIV mirroring also enables effective scrubbing that com-

pares data between local and remote systems. IBM XIV scrub-

bing is a nonstop background activity that verifies the integrity

and redundancy of stored data by examining each data partition

on the system. This process enables essential early detection of

drive read/write errors, minimizing their impact and expediting

recovery processes. The scrubbing process runs continuously

on all modules, checking all drives in parallel, and all drive areas

(including areas never written to). With IBM XIV mirroring,

when the scrubbing process encounters a partition mirrored on

a remote target, it compares the partition copies and looks for

data inconsistencies between primary and remote machines.

High performance with IBM XIV

mirroring

Enterprise-class data replication demands a powerful solution toaccommodate low RPO mirroring requirements without impairing

overall application performance.

Following are notable IBM XIV features that facilitate high

mirroring performance:

High memory utilization minimizes disk access and

maximizes mirroring speed. The IBM XIV system maximizes

the utilization of cache memory for asynchronous mirroring

replication. This minimizes time- and process-intensive disk

access for high performance data replication.

Notably, the IBM XIV caching implementation and large

memory also enable better resilience during link disconnections

and link bandwidth fluctuations, and minimize the mirroring

performance impact on non-mirrored volumes that might

experience cache conflicts.

Low replication granularity minimizes replication traffic.

IBM XIV asynchronous mirroring is extremely efficient, repli-

cating only actual data changes; if one block of data changes,

only one block is replicated. This low granularity replication

helps maximize the network bandwidth available for mirroring

applications.

Independent RPO and interval configuration helps admin-

istrators match RPO with application criticality . IBM XIV

system support for independently set RPOs and intervals

per mirror enables administrators to optimally accommodate

mirroring requirements based on application criticality. One

example is setting a low RPO for critical applications, setting

relatively high RPOs for lower priority applications—and

specifying the same minimal interval for all mirrors. This con-

figuration permits the system to prioritize replication based on

application RPO—which helps promote increased performance.

Offline initialization maximizes bandwidth and reduces

initialization time. Offline initialization reduces mirroring

initialization time, maximizing available network bandwidth for

non-initialization replication traffic. The benefit is pronounced

with low-bandwidth mirroring links.

Manual replication helps optimize mirroring scheduling .

IBM XIV manual replication makes it possible for administra-

tors to schedule mirroring at specified hours for any given

application to efficiently accommodate traffic peaks andmaximize the replication rate.



10



Multiple mirroring target support maximizes potential

replication bandwidth . IBM XIV system support

for multiple target connectivity enables organizations to

harness expanded connectivity bandwidth for mirroring

instead of requiring all mirroring traffic to go through a

single dedicated line.

Replication throttling enables control over synchronization

rates per target . The IBM XIV mirroring solution features the

ability to dynamically accommodate connections with fluctuat-

ing bandwidth and latency. The system examines the bandwidth

and I/O latency of the mirroring link and adjusts its I/O rate

to the estimated available bandwidth. This accommodation of

fluctuating bandwidth characteristics minimizes potential repli-

cation disruptions that could degrade performance.

Flexible IBM XIV deployment and

implementation IBM XIV asynchronous mirroring presents administrators with

flexible deployment and implementation options, streamlining both

setup and maintenance activities alike.

Connectivity with multiple targets allows for flexible

deployment choices● Each IBM XIV system can set mirroring relationships with

up to eight other systems● Each IBM XIV system features simultaneous support for

separate replication sources and targets per system. A systemcan therefore function as a Master peer for some mirrors and

as a Slave peer for other mirrors

● Each IBM XIV system can support hundreds of mirrors● Each mirror can be configured to run independently over

FC or iSCSI● A mirror can be defined either for a single volume or for a

volume group (consistency group)● The system supports both synchronous and asynchronous

mirroring● Each mirror can have an independent schedule type and

interval● Mirror topology configurations supported include:

one-to-one, one-to-many, many-to-one, and hybrid

XIV System2 XIV System3




XIV Sys tem1

Figure 6 : Each system can set mirroring relationships with up to 8 othersystems



11



Figure 7 : Many-to-one topology. One system (or site) serves as a centralhub target for all other systems

Figure 8: One-to-many topology. One system (or site) replicates to multiple

targets

Figure 9: Hybrid IBM XIV topology. Some systems (or sites) function as bothMaster and Slave

Independent RPO and interval configuration helps

administrators tailor RPO to application priority and

available resources. IBM XIV system support for independ-

ently set RPO and interval per mirror enables administrators

to optimally accommodate mirroring requirements based on

application criticality.

Minimal administration with IBM XIV

asynchronous mirroring Asynchronous mirroring is simple to set up and manage, with

straightforward support for mirroring failover and failback.



12



Powerful GUI functionality . The IBM XIV storage sports an

intuitive GUI console and a simple command line interface that

facilitate streamlined administration, supporting these key mir-

roring features:

● Clear status monitoring and alerting: the system generates

system events and monitors critical asynchronous mirroring-

related processes to produce important mirroring assessment

information and statistics● Easy mirroring schedule assignment and adjustment ● Ability to easily change mirroring peer roles from Master

to Slave and vice versa● Straightforward failover and failback ● Simple deployment configuration using graphical

topology tools

Figure 10: The IBM XIV GUI displays a user-friendly view of the deploymenttopology

Independent RPO and interval settings. IBM XIV adminis-

trators can specify an independent RPO per mirror without

adjusting the mirroring interval. Assignment of the same

minimal interval to all mirrors enables the system to prioritize

replication with no user intervention.

Consistency group support . IBM XIV administrators can

easily manage a mirrored volume group using commands that

apply to the whole group, including activation, deactivation,

role change, and streamlined restoration of consistent volume

groups from a remote site after local site disruption.

Automatic dynamic sync rate control. With IBM XIV

dynamic sync rate control, no administrator intervention

is needed to tune the system to accommodate fluctuating

link speed.

Easy failover process. The IBM XIV system facilitates easy

mirroring failover through a single command that changes the

role of the specified peer.

Easy support for planned maintenance scenarios. The

IBM XIV system makes it easy to validate the mirror replica

on the Slave without disrupting the mirroring process. The

administrator simply creates a duplicate of the mirrored replica

and maps that copy to a host.

When both mirroring peers are available, IBM XIV facilitateschanging peer roles by enabling mirror switching. With this

feature, the administrator instructs the system to simultaneously

switch the roles of both peers in a specified mirroring relation-

ship; the Master changes to become the Slave and vice versa.

Quick, streamlined failback . The system facilitates a stream-

lined failback process by supporting offline initialization.

The storage administrator initializes the original Master with

data from the current Master (the promoted Slave). As already

noted, offline initialization helps an organization avoid long

resynchronization periods, especially with suboptimal lines,

and realize improved bandwidth utilization.



13



Figure 11: The IBM XIV mirroring GUI features a clear status display andeasy-to-use functionality, such as change role.

Low total cost of ownershipThe IBM XIV asynchronous mirroring function can help organiza-

tions realize reduced setup and operational costs—which translates

into lower TCO.

Offline initialization helps save precious time and cost .

With offline initialization, administrators can expedite initial-ization by eliminating over-the-wire traffic. This approach

benefits performance and leads to cost savings as well. A good

case for offline initialization is with mirroring failback, in which

restoring a Master after failover can demand long, costly initial-

ization; offline initialization eliminates this overhead. Offline

initialization can also avoid over-the-wire traffic when changing

mirroring type from synchronous to asynchronous.

Support for mirroring over iSCSI helps reduce costs. Due

to its potential cost savings, replication over iSCSI is becoming

a viable mirroring option for enterprises. The IBM XIV system

supports mirroring over iSCSI, facilitating streamlined deploy-

ment at reduced costs.

Mirroring leverages thin-provisioning functionality .

The IBM XIV system supports mirroring of thinly provisioned

volumes, ensuring efficient, low-cost space consumption and

allocation for mirroring applications.

Mirroring is an integral function of the IBM XIV solution

at no extra cost . With the IBM XIV storage system series, all

mirroring functionality and features are available out-of-the-box

at no extra charge:

● Synchronous mirroring● Asynchronous mirroring● Scheduled and manual replication● Support for mirrored volumes and consistency groups● Mirroring failover and recovery ● Online and offline initialization● Graphical user interface for storage management

Effective bandwidth utilization . With IBM XIV asynchro-

nous mirroring, only the data changes on the Master peer

replicate to the Slave peer: if one block changes, only one block

is replicated. The IBM XIV system maintains strong control

over synchronization rates per mirror, which helps attain

efficient bandwidth utilization.

Optimized performance warrants no extra hardware. High

performance asynchronous mirroring does not warrant special

hardware or hardware upgrades, e.g., cache upgrades. The

IBM XIV system maintains the optimal hardware configuration

to support enterprise-class mirroring.

Conclusion

Data is often considered the most important asset of an enter-prise and absolutely critical to business success. The IBM XIV

system features powerful asynchronous mirroring that

satisfies short- and long-term enterprise-class requirements

for data mirroring. With the IBM XIV system, asynchronous

mirroring is easy to set up and offers flexible configuration

options, providing simple data restoration and recovery to

support organizations’ business continuity objectives. The

special blend of breakthrough IBM XIV storage architecture

and features places its asynchronous mirroring solution in

the highest echelon of mirroring solutions by ensuring data

availability in the event of failure or disaster and maintaining

enterprise-class performance with low RPO/quick RTOmirroring, while minimizing overall costs.



14



About the IBM XIV Storage System series

IBM XIV storage is proven, high-end disk storage designed

by listening to customers and addressing their storage chal-lenges across the broadest spectrum of business applica-

tions. The XIV series of fers highly affordable storage

suitable for even the most demanding workloads, providing

tier 1 consistent high performance and high reliability at tier

2 costs. Never compromising performance for reliability, the

XIV grid architecture deploys massive parallelism to allocate

system resources evenly at all times and scale seamlessly,

without the need for complex, time-consuming tuning and

configuration. Comprehensive XIV storage disaster recovery

infrastructure and functionality, including synchronous and

asynchronous mirroring, self-healing, internal data redun-

dancy, and flexible failover and failback scenarios promote

reliable, effective, expedited enterprise disaster recoverystrategies.

A recognized industry leader in enterprise storage

manageability, the XIV system sets a new standard for

ease of use by automating most tasks and providing an

exceptionally intuitive user interface. It also offers “any-time,

anywhere” monitoring via the IBM XIV Mobile Dashboard

app for mobile devices. The XIV architecture enables

performance to grow with capacity and tightly meshes

with cloud technologies for even greater agility in meeting

business needs.

The XIV Storage System has met with rapid marketacceptance and success, with thousands of installations in

diverse industries worldwide, including financial services,

healthcare, energy, education and manufacturing. The

XIV series supports a wide range of workload needs, from

capacity-hungry to ultrahigh per formance. It integrates

easily with virtualization, email, database, analytics, data

protection and other solutions from leading providers,

such as Microsoft, IBM, SAP, Oracle, SAS, VMware

and Symantec. The XIV series plays a key role in

IBM’s end-to-end dynamic infrastructure solutions,

integrating with IBM ProtecTIER®, SONAS, SAN Volume

Controller, IBM Storwize® V7000 and IBM Tivoli® products.

For more information To learn more about the IBM XIV Storage System series,

please contact your IBM representative or IBM Business

Partner, or visit the following website:

ibm.com /storage/disk/xiv

Additionally, IBM Global Financing can help you acquire the

IT solutions that your business needs in the most cost-effective

and strategic way possible. We’ll partner with credit-qualified

clients to customize an IT financing solution to suit your busi-

ness goals, enable effective cash management, and improve your

total cost of ownership. IBM Global Financing is your smartest

choice to fund critical IT investments and propel your business

forward. For more information, visit: ibm.com /financing

About the author Rami Elron is a senior product manager within the

IBM Systems and Technology Group. He is a subject

matter expert in storage architecture, mirroring, and security.

He has been helping drive technical strategy and innovation

for the IBM XIV Storage System series since 2008. He can be

contacted at [email protected].

http://www.ibm.com/storage/disk/xiv


http://www.ibm.com/financing







Notes



Please Recycle

© Copyright IBM Corporation 2012

IBM CorporationRoute 100Somers, NY 10589

Produced in the United States of America January 2012

IBM, the IBM logo, ibm.com, ProtecTIER, Storwize, Tivoli, and XIV are trademarks of International Business Machines Corporation in theUnited States, other countries or both. If these and other IBM trademarkedterms are marked on their first occurrence in this information with atrademark symbol (® or ™), these symbols indicate U.S. registered orcommon law trademarks owned by IBM at the time this information

was published. Such trademarks may also be registered or commonlaw trademarks in other countries. Other product, company or servicenames may be trademarks or service marks of others. A current list of IBM trademarks is available on the web at “Copyright and trademark information” at ibm.com /legal/copytrade.shtml

Microsoft is a trademark of Microsoft Corporation in the United States,other countries, or both.

This document is current as of the initial date of publication and may bechanged by IBM at any time. Not all offerings are available in every country in which IBM operates.

The performance data discussed herein is presented as derived underspecific operating conditions. Actual results may vary. It is the user’sresponsibility to evaluate and verify the operation of any other productsor programs with IBM products and programs. THE INFORMATIONIN THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITIONOF NON-INFRINGEMENT. IBM products are warranted according tothe terms and conditions of the agreements under which they are provided.

Statements regarding IBM’s future direction and intent are subject to change or withdrawal without notice, and represent goals andobjectives only.

TSW03094-USEN-00

http://www.ibm.com/legal/copytrade.shtml



ibm xiv storage system series asynchronous mirroring

Documents