Chapter 13

© 2009 EMC Corporation. All rights reserved.

EMC Proven Professional

The #1 Certification Program in the information storage and management industry

Local ReplicationLocal Replication

Chapter 13

Section 3 : Business Continuity


Chapter Objective

After completing this chapter you will be able to:

o Discuss local replication and the possible uses of local replicas

o Explain consistency considerations when replicating file systems and databases

o Discuss host and array based replication technologieso Functionalityo Differenceso Considerationso Selecting the appropriate technology


Lesson: Local Replica and Data Consistency

Upon completion of this lesson, you will be able to:

o Define local replication

o Discuss the possible uses of local replicas

o Explain replica considerations such as Recoverability and Consistency

o Describe how consistency is ensured in file system and database replication

o Explain Dependent write principle


What is Replication

o Replica - An exact copy

o Replication - The process of reproducing data

o Local replication - Replicating data within the same array or the same data center

Source Replica (Target)

REPLICATIONREPLICATION


Possible Uses of Local Replicas

o Alternate source for backupo An alternative to doing backup on production volumes

o Fast recoveryo Provide minimal RTO (recovery time objective)

o Decision supporto Use replicas to run decision support operations such as creating a reporto Reduce burden on production volumes

o Testing platformo To test critical business data or applications

o Data Migrationo Use replicas to do data migration instead of production volumes


Replication Considerations

o Types of Replica: choice of replica tie back into RPO (recovery point objective)o Point-in-Time (PIT)

o non zero RPOo Continuous

o near zero RPO

o What makes a replica goodo Recoverability/Re-startability

o Replica should be able to restore data on the source deviceo Restart business operation from replica

o Consistencyo Ensuring consistency is primary requirement for all the replication technologies


Understanding Consistency

o Ensure data buffered in the host is properly captured on the disk when replica is createdo Data is buffered in the host before written to disk

o Consistency is required to ensure the usability of replica

o Consistency can be achieved in various ways:o For file Systems

o Offline: Un-mount file systemo Online: Flush host buffers

o For Databaseso Offline: Shutdown databaseo Online: Database in hot backup mode

o Dependent Write I/O Principle o By Holding I/Os


File System Consistency: Flushing Host Buffer

File System

Application

Memory Buffers

Logical Volume Manager

Physical Disk Driver

Data

SyncDaemon

Source Replica


Database Consistency: Dependent write I/O Principle

o Dependent Write: A write I/O that will not be issued by an application until a prior related write I/O has completedo A logical dependency, not a time dependency

o Inherent in all Database Management Systems (DBMS) o e.g. Page (data) write is dependent write I/O based on a successful log

write

o Necessary for protection against local outageso Power failures create a dependent write consistent imageo A Restart transforms the dependent write consistent to transitionally

consistento i.e. Committed transactions will be recovered, in-flight transactions will be

discarded


Database Consistency: Dependent Write I/O

Inconsistent Consistent

Source Replica

4 4

3 3

2 2

1 1

Source Replica

4 4

3 3

2

1


Database Consistency: Holding I/O

5

Source Replica

Consistent

4 4

3 3

2 2

1 1

5


Lesson Summary

Key points covered in this lesson:

o Possible uses of local replicaso Alternate source for backupo Fast recoveryo Decision supporto Testing platformo Data Migration

o Recoverability and Consistency

o File system and database replication consistency

o Dependent write I/O principle


Lesson: Local Replication Technologies

Upon completion of this lesson, you will be able to:

o Discuss Host and Array based local replication technologieso Optionso Operationo Comparison


Local Replication Technologies

o Host basedo Logical Volume Manager (LVM) based replication (LVM mirroring)o File System Snapshot

o Storage Array basedo Full volume mirroringo Pointer based full volume replicationo Pointer based virtual replication


Host Based Replication: LVM-based Replication

Host Logical Volume

Logical Volume

PhysicalVolume 1

PhysicalVolume 2


LVM-based Replication: Limitations

o LVM based replicas add overhead on host CPUso Each write is translated into two writes on the disko Can degrade application performance

o If host volumes are already storage array LUNs then the added redundancy provided by LVM mirroring is unnecessaryo The devices will have some RAID protection already

o Both replica and source are stored within the same volume groupo Replica cannot be accessed by another hosto If server fails, both source and replica would be unavailable

o Keeping track of changes on the mirrors is a challenge


File System Snapshot

o Pointer-based replicao Uses Copy on First Write principleo Uses bitmap and block map

o Bitmap: Used to track blocks that have changed on the production/source FS after creation of snap – initially all zero

o Block map: Used to indicate block address from which data is to be read when the data is accessed from the Snap FS – initially points to production/source FS

o Requires a fraction of the space used by the original FSo Implemented by either FS itself or by LVM


Metadata

File System Snapshots – How it Works

Prod FSMetadata

1 Data a2 Data b

Snap FS

1 Nodata

3 no data4 no data

BitBLK1-0 1-02-0 2-0

N Data N

New writes

o Write to Production FS

3 Data C

2 no data

c

2 Data c

3-03-2

4 Data dD 1 no data1 Data d

4-04-13-13-04-14-0


File System Snapshots – How it Works

o Reads from snap FSo Consult the bitmap

o If 0 then direct read to the production FS

o If 1 then go to the block map get the block address and read data from that address

MetadataSnap FS

1 Nodata2 Data c

3 no data4 no data

BitBLK1-0 1-02-03-24-1

2-03-14-1

1 Data d

Prod FSMetadata

1 Data a2 Data b

3 Data C4 Data D

N Data N


o Replication performed by the Array Operating Environment

o Replicas are on the same array

o Types of array based replicationo Full-volume mirroringo Pointer-based full-volume replication o Pointer-based virtual replication

Storage Array Based Local Replication

Production Server BC Server

Array

Source Replica


Full Volume Mirroring: Attached

o Target is a full physical copy of the source device

o Target is attached to the source and data from source is copied to the target

o Target is unavailable while it is attached

o Target device is as large as the source device

o Good for full backup, decision support, development, testing and restore to last PIT

Source Target

Attached

Array

Read/Write Not Ready


Full Volume Mirroring: Detached

o After synchronization, target can be detached from the source and made available for BC (business continuity) operations

o PIT is determined by the time of detachment

o After detachment, re-synchronization can be incrementalo Only updated blocks are resynchronizedo Modified blocks are tracked using bitmaps

Source Target

Detached - PIT

Read/Write Read/Write

Array


Full Volume Mirroring: Source and Target Relationship

Attached/Synchronization

Source = Target

Detached

Source ≠ Target

Resynchronization

Source = Target


Pointer-based Full Volume Replication

o Provide full copy of source data on the target

o Target device is made accessible for business operation as soon as the replication session is started

o Point-in-Time is determined by time of session activation

o Two modeso Copy on First Access (deferred) o Full Copy mode

o Target device is at least as large as the source device


Write to Source

Copy on First Access (CoFA) Mode: Deferred Mode

Source Target


Write to Target

Read from Target

Source Target

Source Target




Full Copy Mode

o On session start, the entire contents of the Source device is copied to the Target device in the background

o If the replication session is terminated, the target will contain all the original data from the source at the PIT of activationo Target can be used for restore and recoveryo In CoFA mode, the target will only have data was accessed until

termination, and therefore it cannot be used for restore and recovery

o Most vendor implementations provide the ability to track changes: o Made to the Source or Target o Enables incremental re-synchronization


Pointer Based Virtual Replication

o Targets do not hold actual data, but hold pointers to where the data is located o Target requires a small fraction of the size of the source volumes

o A replication session is setup between source and target devices o Target devices are accessible immediately when the session is started o At the start of the session the target device holds pointers to data on

source device

o Typically recommended if the changes to the source are less than 30%


Virtual Replication: Copy on First Write Example

Source Save Location

TargetVirtual Device


Tracking Changes to Source and Target

o Changes will/can occur to the Source/Target devices after PIT has been created

o How and at what level of granularity should this be trackedo Too expensive to track changes at a bit by bit level

o Would require an equivalent amount of storage to keep tracko Based on the vendor some level of granularity is chosen and a bit map is

created (one for source and one for target)o For example one could choose 32 KB as the granularityo If any change is made to any bit on one 32KB chunk the whole chunk is flagged

as changed in the bit mapo For 1GB device, map would only take up 32768/8/1024 = 4KB space


Source

Target

Tracking Changes to Source and Target: Bitmap

0= unchanged = changed

Logical OR

At PIT

Target

SourceAfter PIT…

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

1 0 0 1 0 1 0 0

0 0 1 1 0 0 0 1

1 0 1 1 0 1 0 1

1

For resynchronization/restore


Restore/Restart Operation

o Source has a failureo Logical Corruptiono Physical failure of source deviceso Failure of Production server

o Solutiono Restore data from target to source

o The restore would typically be done incrementally o Applications can be restarted even before synchronization is complete

-----OR------o Start production on target

o Resolve issues with source while continuing operations on targeto After issue resolution restore latest data on target to source


Restore/Restart Considerations

o Before a Restoreo Stop all access to the Source and Target deviceso Identify target to be used for restore

o Based on RPO and Data Consistencyo Perform Restore

o Before starting production on targeto Stop all access to the Source and Target deviceso Identify Target to be used for restart

o Based on RPO and Data Consistencyo Create a “Gold” copy of Target

o As a precaution against further failureso Start production on Target


Restore/Restart Considerations (cont.)

o Pointer-based full volume replicaso Restores can be performed to either the original source device or to any

other device of like sizeo Restores to the original source could be incremental in natureo Restore to a new device would involve a full synchronization

o Pointer-based virtual replicaso Restores can be performed to the original source or to any other device of

like size as long as the original source device is healthyo Target only has pointers

o Pointers to source for data that has not been written to after PIT o Pointers to the “save” location for data was written after PIT

o Thus to perform a restore to an alternate volume the source must be healthy to access data that has not yet been copied over to the target


Array Replicas: Which Technology?

Factor Full-volume mirroring Pointer-based full-volume replication

Pointer-based virtual replication

Performance impact on source No impact

CoFA mode – some impact

Full copy – no impactHigh impact

Size of target At least same as the source At least same as the source Small fraction of the

source

Accessibility of source for restoration

Not requiredCoFA mode – required

Full copy – not requiredRequired

Accessibility to target

Only after synchronization and

detachment from the source

Immediately accessible Immediately accessible


Creating Multiple Replicas

06:00 A.M.

: 12 : 01 : 02 : 03 : 04 : 05 : 06 : 07 : 08 : 09 : 10 : 11 : 12 : 01 : 02 : 03 : 04 : 05 : 06 : 07 : 08 : 09 : 10 : 11 :

P.M.A.M.

12:00 P.M.

06:00 P.M.

12:00 A.M.

Source

Target Devices

Point-In-Time


Local Replication Management: Array Based

o Replication management software residing on storage array

o Provides an interface for easy and reliable replication management

o Two types of interface:o CLIo GUI


Lesson Summary

Key points covered in this lesson:

o Replication technologieso Host based

o LVM based mirroringo File system snapshot

o Array basedo Full volume mirroringo Pointer-based full volume copyo Pointer-based virtual replica


Chapter Summary

Key points covered in this chapter:

o Definition and possible use of local replicas

o Consistency considerations when replicating file systems and databases

o Host based replicationo LVM based mirroring, File System Snapshot

o Storage array based replicationo Full volume mirroring, Pointer based full volume and virtual replicationo Choice of technology

Additional Task

Research on EMC Replication Products


Check Your Knowledge

o Describe the uses of a local replica in various business operations.

o How can consistency be ensured when replicating a database?

o What are the differences among full volume mirroring and pointer based replicas?

o What is the key difference between full copy mode and deferred mode?

o What are the considerations when performing restore operations for each array replication technology?


#1 ITcompany

For more information visit http://education.EMC.com

Date post:	29-Dec-2015
Category:	Documents
Upload:	amant
View:	18 times
Download:	0 times

Chapter 13

Documents