sBC50_Using IBM System Storage for i5OS High Availability

7/31/2019 sBC50_Using IBM System Storage for i5OS High Availability

1/140

IBM System i Technology Center (iTC)

2007 IBM Corporation

i want stress-free IT.

i want control.i want ani.

i5/OS Copy Services


2/140

2007 IBM Corporationi want ani.

IBM System i


Agenda

Introduction to Copy Services

Flash Copy Overview

Flash Copy Configuration Examples

Remote Mirror and Copy Overview

Metro Mirror Global Mirror

Metro/Global Mirror

Remote Mirror and Copy Configuration Examples


3/140


IBM System i


IBM System Storage

The IBM System Storage Units provide two powerful copy servicesfunctions.

FlashCopy

Remote Mirror and Copy (RMC)

RMC formerly known as RMC (Peer-to-peerRemote Copy)


4/140 2007 IBM Corporationi want ani.

IBM System i


Flash CopyFlash Copy

Flash Copy Volume Pairs

Point in Time Copy

No Copy

Full Copy

System Storage


5/140 2007 IBM Corporationi want ani.

IBM System i


Flash Copy Overview

FlashCopy is a hardware solution. The copy function occurs at thestorage subsystem level, the application does not need to know of its

existence.

When you initiate a FlashCopy operation, a FlashCopy relationship ormapping is created between a source volume and a target volume.

FlashCopy mappings allow a point-in-time copy of a source volume to be

copied to an associated target volume.


6/140


IBM System i


Flash Copy Overview

The secondary volumes must be in the same IBM System Storage Unit as

the primary set of volumes.

The FlashCopy relationship exists between the volume pairs until all data

is copied from the source volume to the target volume or the FlashCopyrelationship is deleted.

Once the FlashCopy relationship is established the point-in-time copy(target volume) is immediately available for read and write processing.


7/140


IBM System i


Flash Copy Overview

Multiple Relationship FlashCopy A volume can participate in multipleFlashCopy relationships.

One source to many targets. Up to 12

Only 1 target can be setup for incremental updates

A volume can not be both a source and a target of a FlashCopy

A FlashCopy Target can be a RMC source using a special option ( -tgtpprcwith DS CLI, Target is RMC source on ESS 800 )


8/140


IBM System i


Flash Copy FullCopy

This FlashCopy option creates a full point-in-time copy of the data on the

source drives.

A background process is used to copy tracks from the source volume to the

target volume.

The FlashCopy relationship exists between the volume pairs until all data is

copied from the source volume to the target volume.

When reads of the target volume are attempted against data, that has not yetbeen copied from the source volume, the data is read from the sourcevolume.


9/140


IBM System i


Flash Copy NoCopy

Use the nocp option in the DS CLI

Inhibits background copy. Data is copied from the source volume to thetarget volume only if a track on the source volume is modified.

The FlashCopy volume pair relationship remains indefinitely until it isbroken, or until all tracks on the source volume are modified.

When reads of the target volume are attempted and the data has not

changed on the source volume, the data is actually read from the sourcevolume.

S


10/140


IBM System i


Copy data command issued

Tim

e

Copy immediately available

Read and write to both source and

Target possible.

Write Read

When copy is complete,

relationship between

source and target ends

FlashCopy provides a 'Time 0' copyFlashCopy mapping

IBM S t i


11/140


IBM System i


Other FlashCopy Options

Consistency groups ( -freeze ) Creates a consistent point-in-time copy of multiple volumes, withnegligible host impact. Must be used in conjunction with the unfreezeflash DS CLI command.

Persistent FlashCopy ( - persist ) Allows the FlashCopy relationship to remain even after theFlashCopy operation completes. You must explicitly delete the relationship.

Change recording ( -record ) Activates the change recording function on the volume pair that isparticipating in a FlashCopy relationship. This enables a subsequent refresh to the targetvolume.

Inhibit Target writes ( -tgtinhibit ) Prevents writes against the target. This will prevent the

System i from varying on the IASP or IPLing from a full copy. Do not use for System i. Quiet ( -quiet ) The option on the removal of a flashcopy prevents the DS CLI from requesting

an acknowledgement of the removal action.

IBM S stem i


12/140


IBM System i


Other FlashCopy Functions

Re-synchronizing FlashCopy - provides the ability to update an initial point-in-timecopy of a source volume that has been established as a Persistent FlashCopy withChange recording on.

Full Copy must be established No out of sync sectors from full copy or previous resync allowed when

invoking this function Changed sectors on the target will be backed out as part of a new resync

Reverse Flash/Restore - Reverses the FlashCopy relationship and copies data fromthe target volume to the source volume.

Select current source as source and current target as target Selecting volumes in the reverse direction will run without the desired effect

An IPL of the system will be required to use a reversed IASP.

IBM System i


13/140


IBM System i


Warm vs. Cold Flash

iSeries can leverage FlashCopy to:

Create a copy of an IASP for backup

Create a full system copy for disaster recovery (DR)

IBMs recommendation is to quiesce the IASP or system before takingthe Flash

Known as a cold Flash

It is the only way to guarantee complete data integrity

It is also possible to use the freeze option to temporarily queue writesfrom a system or IASP, then take a Flash

Known as a warm Flash

Not recommended, but sometimes necessary in 24/7 clientenvironments

Journaling strongly recommended

IBM System i


14/140


IBM System i


Flash Copy and Cluster Services - Requirements

A cluster with at least two nodes in a device domain a CRG is notneeded

An IASP using SAN-based storage that is the source for theFlashCopy

Sufficient disk space in the same storage unit for the FlashCopytarget

An IOA attached to the target volumes capable of RESET/RELOAD

Copy Descriptions for the source and target volumes

A session to make and remove the FlashCopy

IBM System i


15/140


IBM System i


IBM System i


16/140


IBM System i


IBM System i


17/140


IBM System i


IBM System i


18/140


y


IBM System i


19/140


y


IBM System i


20/140

2007 IBM Corporationi want ani. IBM System i Technology Center (iTC)


21/140

IBM System i


22/140


IBM System i


23/140


IBM System i


24/140


IBM System i


25/140


IBM System i


26/140


IBM System i


27/140


IBM System i


28/140


IBM System i


29/140


IBM System i


30/140


IBM System i


31/140


IBM System i


32/140


IBM System i


33/140


IBM System i


34/140


IBM System i


35/140


IBM System i


36/140



37/140

IBM System i


38/140


IBM System i


39/140


IBM System i


40/140


IBM System i


41/140


IBM System i


42/140


IBM System i


43/140


IBM System i


44/140


IBM System i


45/140


IBM System i


46/140


IBM System i


47/140


IBM System i


48/140


IBM System i


49/140


IBM System i


50/140


IBM System i


51/140


IBM System i


52/140


IBM System i


53/140


IBM System i


54/140



55/140

IBM System i


56/140


IBM System i


57/140


IBM System i


58/140


IBM System i


59/140


IBM System i


60/140


IBM System i


61/140


IBM System i


62/140


IBM System i


63/140


IBM System i


64/140


Remote Mirror and CopyRemote Mirror and Copy

RMC

Synchronous (Metro Mirror)

Asynchronous + Consistency Groups (Global Mirror)

Cascading (Metro/Global Mirror)

System Storage

IBM System i


65/140


RMC Overview

RMC is a real-time remote copy technique that mirrors a primaryset oflogical volumes (that are being updated by applications) onto a secondaryset of logical volumes.

The secondary volumes can either be in the same or a different IBMSystem Storage Unit than the primary set of volumes.

RMC is a hardware solution, thus it is application independent. The copyfunction occurs at the storage subsystem level, the application does not

need to know of its existence.

IBM System i

RMC Overview


66/140


RMC is a function of the IBM System

Storage Unit, replication occurs at the

storage control level.

RMC Volumes Pairs

IBM System i

Metro Mirror (Sync PPRC)


67/140


( y )

Synchronous mirroring: when Metro Mirror receives a host update to thesource volume, it completes the corresponding update to the targetvolume.

Guarantees data consistency by ensuring that a write operation thatcompletes is received by the host application after the update has beencommitted to the target storage unit and acknowledged by both thesource and target storage units.

Consistency is guaranteed across all volumes on which an applicationdoes write operations as long as all volume pairs are in full duplex state.

IBM System i

Metro Mirror


68/140


Metro Mirror copying supports a maximum distance of 300 km

(based on good performance, not functionality)

Delays in response times for Metro Mirror are proportional to thedistance between the volumes. However, 100% of the source datais available at the recovery when the copy operation ends.

Performance Considerations for Metro Mirror


69/140

2003 IBM Corporation| 2005 IBM Corporation

System i5DS6000 DS6000

Metro Mirror

(Sync RMC)

SYSBAS

LSU

1

2

43

1. Local write

2. Remote write

3. Remoteacknowledgement

4. Localacknowledgement

System paging/temp I/O

Application/Database I/O

Mirroring of system and

temp I/O will affectapplication performance

in SYSBAS

SYSBAS

Performance Considerations for Metro Mirror


70/140


System i5DS6000 DS6000

Metro Mirror

(Sync RMC)

SYSBAS

LSU

1

4

3

1. Local write

2. Remote write

3. Remoteacknowledgement

4. Localacknowledgement Application/Database I/O

No mirroring of system and temp I/O

IASP

Sync replication of I/O willhave minimal affect on

application performance in

an IASP

2

IASP

Metro Mirror and Cluster Services -Requirements


71/140


A cluster with at least two nodes in a device domain

A device CRG with the two nodes in the recovery domain

An IASP using SAN-based storage that are the preferred sourcevolumes

Identical number and size of SAN-based storage volumes that arethe preferred target (preferably in a different storage unit than thepreferred source volumes)

An active metro mirror relationship between the two sets ofvolumes

Copy descriptions for the source and target volumes

An active session managing the metro mirror relationship


72/140



73/140



74/140



75/140



76/140



77/140



78/140



79/140



80/140



81/140



82/140



83/140



84/140



85/140



86/140



87/140



88/140



89/140



90/140



91/140



92/140



93/140



94/140



95/140



96/140



97/140



98/140



99/140



100/140



101/140



102/140



103/140



104/140



105/140



106/140



107/140



108/140



109/140



110/140



111/140



112/140



113/140



114/140



115/140



116/140


Global Mirror

Global Mirror Architecture A Disaster Recovery (DR) data replication solution

Premier DR replication solution in the market place today zSeries, iSeries & Open

2-site


117/140


A local or production site and a second, remote site Asynchronous data transfer

Minimal impact to the production write I/Os Peer-to-peer hardware solution (no, outside the box, server MIPS)

Global Mirror is microcode controlled Peer-to-peer data copy mechanism is Global Copy Consistency Group formation managed by master

Very long distance Continental distances

Very little data loss - Recovery Point Objective (RPO)

Optimally 3-5 sec Scalable

1 master, multiple primaries & multiple secondaries (8 total, more with RPQ)


118/140

Global Mirror Volumes

REMOTE

APPLICATION

PRIMARY

APPLICATION

HOSTS


119/140


Volumes are exactly the same size Failover & Failback considerations

Global CopyOVER LONGDISTANCE

CHANEX T

FlashCopy

N

HOSTS

PPRC 'A'

PRIMARY

CHANEX T

FLC CTarget

Local Site

PPRC BSecondary

Remote Site

FLC Source

i5/OS Copy Services Global Mirror (9/08)

Establish the global mirror environment in the DS Provide a cluster with at least two nodes


120/140


The two nodes of the cluster must be in the same device domain

An inactive CRG that identifies the node with the source

volumes (primary) and the target volumes (backup) Add copy descriptions for the volumes present in the global

mirror environment Preferred source

Preferred target

Target consistency group flash volumes Source consistency group flash volumes for symmetric global mirror

Start an ASP session in i5/OS (note: this is different from theglobal mirror session in the DS)

Start the CRG Control the primary location of the data using the cluster andCRG functions


121/140



122/140



123/140



124/140



125/140



126/140



127/140



128/140



129/140



130/140



131/140



132/140


An i5/OS session for asymmetrical global mirror


133/140


An i5/OS session for symmetrical global mirror


134/140



135/140



136/140


Metro/Global Mirror

Metro/Global Mirror

Solution: Data replication business continuity remote

i i di t t t l ti


137/140


mirroring disaster recovery at remote location

3 site

Metro + continental, transcontinental distances

For IBM enterprise storage

ESS w/o Incremental Resync

DS8000

Not for San Volume Controller or DS4000

Metro/Global Mirror Architecture

Server or Servers


138/140


Local Site (site A) Intermediate Site (site B) Remote Site (siteC)

BA C

D

Metro Mirror

Global Mirror

***

normal application I/Os

up to 300 KM Intercontinental distance

Global Mirror network

asynchronous

large distance

Global Mirror FlashCopy

nocopy

Metro Mirror network

synchronous

small distance

Metro/Global Mirror Architecture

***Server or Servers

4

B volume created with cascade option CGs will fail if Metro Mirror pair is duplex

pending

CGs will fail if Metro Mirror pair suspends


139/140


Local Site (Site A) Intermediate Site (Site B) Remote Site (SiteC)

BA C

D

Metro Mirror

Global MirrorMetro Mirror networksynchronous

small distance

Global Mirror network

asynchronouslarge distance

Global Mirror FlashCopy

NOCOPY

normal application I/Os

12

3

4

Metro Mirror write

1. application to VolA2. VolA to VolB

3. write complete to A

4. write complete to application

ab

c

Global Mirror consistency group formation (CG)

a. write updates to B volumes paused (< 3ms) to create CGb. CG updates to B volumes drained to C volumes

c. after all updates drained, FlashCopy changed data from C to Dvolumes

Incremental resync

turned on

IBM System i

Summary

System Storage Copy Services provide powerful point-in-time andreplication tools

All Copy Services technologies are supported for System i and i5/OS


140/140


All Copy Services technologies are supported for System i and i5/OS

Can be managed through both DS GUI and DS CLI

Documents

sBC50_Using IBM System Storage for i5OS High Availability