7ab339adc0564b3372bde144623-280109091204

Local Replication

Module 3.3

2009 EMC Corporation. All rights reserved.

Local ReplicationAfter completing this module you will be able to: Discuss local replication and the possible uses of local replicas Explain consistency considerations when replicating file systems and databases

Discuss host and array based replication technologies Functionality Differences Considerations Selecting the appropriate technology


Local Replication - 2

Lesson: Local Replica and Data ConsistencyUpon completion of this lesson, you will be able to: Define local replication

Discuss the possible uses of local replicas Explain replica considerations such as Recoverability and Consistency Describe how consistency is ensured in file system and database replication Explain Dependent write principle



What is Replication Replica - An exact copy Replication - The process of reproducing data

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

REPLICATION

Source 2009 EMC Corporation. All rights reserved.

Replica (Target)Local Replication - 4

Possible Uses of Local Replicas Alternate source for backup Fast recovery

Decision support Testing platform Data Migration



Replication Considerations Types of Replica: choice of replica tie back into RPO Point-in-Time (PIT) non zero RPO

Continuous near zero RPO

What makes a replica good Recoverability/Re-startability Replica should be able to restore data on the source device Restart business operation from replica

Consistency Ensuring consistency is primary requirement for all the replication technologies



Understanding Consistency Consistency is required to ensure the usability of replica Consistency can be achieved in various ways: For file Systems Offline: Un-mount file system Online: Flush host buffers

For Databases Offline: Shutdown database Online: Database in hot backup mode Dependent Write I/O Principle By Holding I/Os



File System Consistency: Flushing Host BufferApplication File System Sync Daemon Memory Buffers Logical Volume Manager Physical Disk Driver Data

Source

Replica



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

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

Necessary for protection against local outages Power failures create a dependent write consistent image A Restart transforms the dependent write consistent to transitionally consistent i.e. Committed transactions will be recovered, in-flight transactions will be discarded 2009 EMC Corporation. All rights reserved. Local Replication - 9

Database Consistency: Dependent Write I/OSource Replica Source1

Replica

1

1

2

2

2

3

3

3

3

4

4

4

4

C

Consistent

D

InconsistentLocal Replication - 10


Database Consistency: Holding I/OSource Replica

1

1

5

5

2

2

3

3

4

4

Consistent



Lesson SummaryKey points covered in this lesson: Possible uses of local replicas Alternate source for backup Fast recovery Decision support Testing platform Data Migration

Recoverability and Consistency File system and database replication consistency Dependent write I/O principle 2009 EMC Corporation. All rights reserved. Local Replication - 12

Lesson: Local Replication TechnologiesUpon completion of this lesson, you will be able to: Discuss Host and Array based local replication technologies Options Operation Comparison



Local Replication Technologies Host based Logical Volume Manager (LVM) based mirroring File System Snapshot

Storage Array based Full volume mirroring Pointer based full volume replication Pointer based virtual replication



Host Based Replication: LVM Based Mirroring

Host

Logical VolumeLogical Volume

Physical Volume 1

Physical Volume 2



File System Snapshot Pointer-based replica Uses Copy on First Write principle Uses bitmap and block map Bitmap: Used to track blocks that have changed on the production/source FS after creation of snap initially all zero 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

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



File System Snapshots How it Works Write to Production FS Snap FS Metadata BLK 1-0 2-0 3-2 3-0 4-1 4-0 Bit 1-0 2-0 3-0 3-1 4-0 4-1

Prod FS Metadata1 Data a 2 Data b c 3 Data C d 4 Data D

New writes

N Data N 2009 EMC Corporation. All rights reserved.

1 Nodata no data Data d 2 Data c no data 3 no data 4 no dataLocal Replication - 17

File System Snapshots How it Works Reads from snap FS Consult the bitmap If 0 then direct read to the production FS If 1 then go to the block map get the block address and read data from that address

Prod FS Metadata 1 Data a 2 Data b 3 Data C 4 Data D

Snap FS Metadata BLK 1-0 2-0 3-2 4-1 Bit 1-0 2-0 3-1 4-1

N Data N 2009 EMC Corporation. All rights reserved.

1 Nodata Data d 2 Data c 3 no data 4 no dataLocal Replication - 18

Host Based Replication: Limitations LVM based replicas add overhead on host CPUs If host volumes are already storage array LUNs then the added redundancy provided by LVM mirroring is unnecessary The devices will have some RAID protection already

Host based replicas can be usually presented back to the same server Keeping track of changes is a challenge after the replica has been created



Storage Array Based Local Replication Replication performed by the Array Operating Environment Replicas are on the same array Types of array based replication Full-volume mirroring Pointer-based full-volume replication Pointer-based virtual replicationArray Source

Replica

Production Server 2009 EMC Corporation. All rights reserved.

BC ServerLocal Replication - 20

Full Volume Mirroring: Attached Target is a full physical copy of the source device Target is attached to the source and data from source is copied to the target Target is unavailable while it is attached Target device is as large as the source device

Good for full backup, decision support, development, testing and restore to last PITAttachedRead/Write Not Ready

SourceArray 2009 EMC Corporation. All rights reserved.

TargetLocal Replication - 21

Full Volume Mirroring: Detached After synchronization, target can be detached from the source and made available for BC operations PIT is determined by the time of detachment After detachment, re-synchronization can be incremental

Detached - PITRead/Write Read/Write

SourceArray 2009 EMC Corporation. All rights reserved.


Full Volume Mirroring: Source and Target Relationship

Attached/ Synchronization

Detached

Resynchronization

Source = Target

Source Target

Source = Target



Pointer based Full Volume Replication Provide full copy of source data on the target Target device is made accessible for business operation as soon as the replication session is started Point-in-Time is determined by time of session activation Two modes Copy on First Access (deferred) Full Copy mode

Target device is at least as large as the source device



Copy on First Access Mode: Deferred ModeWrite to SourceRead/Write Read/Write

Source

Target

Write to TargetRead/Write Read/Write

Source

Target

Read from TargetRead/Write Read/Write

Source 2009 EMC Corporation. All rights reserved.


Full Copy Mode On session start, the entire contents of the Source device is copied to the Target device in the background Most vendor implementations provide the ability to track changes: Made to the Source or Target Enables incremental re-synchronization



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

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

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



Virtual Replication: Copy on First Write ExampleTarget Virtual Device

Source

Save Location



Tracking Changes to Source and Target Changes will/can occur to the Source/Target devices after PIT has been created How and at what level of granularity should this be tracked Too expensive to track changes at a bit by bit level Would require an equivalent amount of storage to keep track

Based on the vendor some level of granularity is chosen and a bit map is created (one for source and one for target) For example one could choose 32 KB as the granularity If any change is made to any bit on one 32KB chunk the whole chunk is flagged as changed in the bit map For 1GB device, map would only take up 32768/8/1024 = 4KB space



Tracking Changes to Source and Target: BitmapSource 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

At PITTarget

After PIT

Source Target

1 0

0 0

0 1

1 1

0 0

1 0

0 0

0 1

For resynchronization/restore Logical OR 1 0 1 1 0 1 0 1

0 = unchanged 2009 EMC Corporation. All rights reserved.

1 = changedLocal Replication - 30

Restore/Restart Operation Source has a failure Logical Corruption Physical failure of source devices Failure of Production server

Solution Restore data from target to source The restore would typically be done incrementally Applications can be restarted even before synchronization is complete

-----OR----- Start production on target Resolve issues with source while continuing operations on target After issue resolution restore latest data on target to source 2009 EMC Corporation. All rights reserved. Local Replication - 31

Restore/Restart Considerations Before a Restore Stop all access to the Source and Target devices Identify target to be used for restore Based on RPO and Data Consistency

Perform Restore

Before starting production on target Stop all access to the Source and Target devices Identify Target to be used for restart Based on RPO and Data Consistency

Create a Gold copy of Target As a precaution against further failures

Start production on Target 2009 EMC Corporation. All rights reserved. Local Replication - 32

Restore/Restart Considerations (cont.) Pointer based Full Volume Replicas Restores can be performed to either the original source device or to any other device of like size Restores to the original source could be incremental in nature Restore to a new device would involve a full synchronization

Pointer Based virtual Replicas Restores can be performed to the original source or to any other device of like size as long as the original source device is healthy Target only has pointers Pointers to source for data that has not been written to after PIT

Pointers to the save location for data was written after PIT

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 Performance impact on source Full-volume mirroring No impact Pointer-based fullvolume replication CoFA mode -some impact Full copy no impact At least same as the source At least same as the source CoFA mode required Full copy not required Small fraction of the source Pointer-based virtual replication High impact

Size of target

Accessibility of source for restoration

Not required

Required

Only after synchronization and Accessibility to target Immediately accessible detachment from the source

Immediately accessible



Creating Multiple ReplicasTarget Devices06:00 A.M.

Source

12:00 P.M.

Point-In-Time06:00 P.M.

12: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 : A.M. 2009 EMC Corporation. All rights reserved.

P.M.Local Replication - 35

Local Replication Management: Array Based Replication management software residing on storage array Provides an interface for easy and reliable replication management Two types of interface: CLI GUI



Lesson SummaryKey points covered in this lesson: Replication technologies Host based LVM based mirroring File system snapshot

Array based Full volume mirroring Pointer-based full volume copy Pointer-based virtual replica



Module SummaryKey points covered in this module: Definition and possible use of local replicas

Consistency considerations when replicating file systems and databases Host based replication LVM based mirroring, File System Snapshot

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



Concept in Practice EMC Local Replication Solutions

EMC Symmetrix Arrays EMC TimeFinder/Clone Full volume replication

EMC TimeFinder/Mirror Full volume mirroring

EMC TimeFinder/SNAP Pointer based replication

EMC CLARiiON Arrays EMC SnapView Clone Full volume replication

EMC SnapView Snapshot Pointer based replication



Check Your Knowledge Describe the uses of a local replica in various business operations. How can consistency be ensured when replicating a database? Discuss one host based replication technology What are the differences among full volume mirroring and pointer based replicas? What is the key difference between full copy mode and deferred mode? What are the considerations when performing restore operations for each array replication technology? 2009 EMC Corporation. All rights reserved. Local Replication - 40

7ab339adc0564b3372bde144623-280109091204

Documents

replication replica

local replication module

virtual replication

emc corporation

volume replication pointer

local replicationafter

data center replication

exact copy replication