local replication chapter 13(9.2) ismdr:beit:viii:chap9.2:madhu n:piit1

ISMDR:BEIT:VIII:chap9.2:Madhu N:PIIT 1

Local Replication

Chapter 13(9.2)

ISMDR:BEIT:VIII:chap9.2:Madhu N:PIIT - 2

Chapter Objective

After completing this chapter 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


Lesson: Local Replica and Data Consistency

Upon 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

Source Replica (Target)

REPLICATIONREPLICATION


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 Buffer

File System

Application

Memory Buffers

Logical Volume Manager

Physical Disk Driver

Data

SyncDaemon

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


Database Consistency: Dependent Write I/O

D InconsistentC Consistent

Source Replica

4 4

3 3

2 2

1 1

Source Replica

4 4

3 3

2

1

C


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:• 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


Lesson: Local Replication Technologies

Upon 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 Volume

Logical Volume

PhysicalVolume 1

PhysicalVolume 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


Metadata

File System Snapshots – How it Works

Prod FS

Metadata

1 Data a

2 Data b

Snap FS

1 Nodata

3 no data

4 no data

BitBLK

1-0 1-0

2-0 2-0

N Data N

New writes

• 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-1

3-13-0

4-14-0


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

Metadata

Snap FS

1 Nodata

2 Data c

3 no data

4 no data

BitBLK

1-0 1-0

2-0

3-2

4-1

2-0

3-1

4-1

1 Data d

Prod FS

Metadata

1 Data a

2 Data b

3 Data C

4 Data D

N Data N


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


• 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 replication

Storage Array Based Local Replication

Production Server BC Server

Array

Source Replica


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 PIT

Source Target

Attached

Array

Read/Write Not Ready


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

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

• 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


Write to Source

Copy on First Access Mode: Deferred Mode

Source Target


Write to Target

Read from Target

Source Target

Source Target




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 Example

Source Save Location

TargetVirtual Device


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


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

• 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


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


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

Full-volume mirroring

Pointer-based full-volume replication

Pointer-based virtual replication

Performance impact on source

No impactCoFA mode -some impact

Full copy – no impactHigh impact

Size of targetAt 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 accessibleImmediately 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

• Replication management software residing on storage array

• Provides an interface for easy and reliable replication management

• Two types of interface:– CLI– GUI


Lesson Summary

Key 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


Exercise 1• Click the attached file

Adobe Acrobat Document


Exercise 2• Click the attached file

Adobe Acrobat Document


Chapter Summary

Key points covered in this chapter:• 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


EMC Local Replication Video


Check Your Knowledge

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

• How can consistency be ensured when replicating a database?

• 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?

ISMDR:BEIT:VIII:chap9.2:Madhu N:PIIT 44

local replication chapter 13(9.2) ismdr:beit:viii:chap9.2:madhu n:piit1

Documents

madhu n

emc corporation

dependent write consis

database consistency

local replicationdiscuss

file system consistency

prior related write

file systemsoffline