XIV (5)--Data Recovery Protection (XDRP)

As with most storage systems, XIV also offers multiple disaster recovery solutions. XIV Data Recovery Protection (XDRP) has three implementations, synchronous mirroring; asynchronous mirroring; Data migration. In addition, of course, also support flashcopy,volumecopy

First, synchronous mirroring

XDRP is a real-time copy between two or more XIV systems, supporting Fiber Channel or iSCSI links "Most use FC" considering the reliability and bandwidth of long-range disaster preparedness. There are master System and slave system. This describes how the two XIV systems work.

650) this.width=650; "title=" image "style=" border-right-width:0px;border-bottom-width:0px;border-top-width:0px; " Border= "0" alt= "image" Src= "http://s3.51cto.com/wyfs02/M01/55/42/wKiom1SJM1fRmKR9AAHKCRX6dBs804.jpg" width= "644" height= "459"/>

• Three different states:

–initialization-Sync is being done and data is being copied from master copy to Slave

–synchronized-Complete sync with consistent data at both ends

–unsynchronized–remote Mirror problems occurred

If there is a problem with the remote mirror, such as the link section, Master will change the source vol on the tracking.

– When the link is restored, all tracking's change is immediately copied to the slave, which is called "uncommitteddata". When Vol resynced is automatically created on Slave Master by a special Snapshot, this Snapshot is called "lastconsistent Snapshot". It is the system snapshot, the user can not be deleted manually, will be automatically deleted after fully resynced, it does not consider the size limit, if necessary, will occupy the disk all the remaining space.

Consistency Groups

• Synchronous mirroring supports consistency groups for mirrored volumes

• You can switch the role of the entire consistency group

–this the Master/slave location of all member volumes in the consistency group

• Both the Master and the Slave system must be configured with a empty CG that's configured for mirroring

• After the CG mirror are created and synchronized you can start adding volumes to it

–All volumes must is at a synchronized state and of the same sync type

Second, asynchronous mirroring

only the changed data blocks will be sent to the slave, which can be sorted by the pre-defined interval of time sync, such as 20s (min_interval), 30s, 1m, 2m, 5m, 10m, 15m, 30m, 1h, 2h, 3h, 6h, 8h, 12h

650) this.width=650; "title=" image "style=" border-right-width:0px;border-bottom-width:0px;border-top-width:0px; " Border= "0" alt= "image" Src= "http://s3.51cto.com/wyfs02/M02/55/42/wKiom1SJM3KwoR31AAGjnnH34lU783.jpg" width= "644" height= "389"/>

Mirroring is starting with initialization, support (Online initialization and offline initialization, as explained below)

– Once initialization is complete, master will determine the scope of the synchronization

When a new mirror is define, Master generates a snapshot to represent the initial state of the system before mirror starts.

650) this.width=650; "title=" image "style=" border-right-width:0px;border-bottom-width:0px;border-top-width:0px; " Border= "0" alt= "image" Src= "http://s3.51cto.com/wyfs02/M00/55/40/wKioL1SJNBqRmYWkAAC2ugu6InI408.jpg" width= "644" height= "178"/>

The XIV system uses special snapshot to determine the range of sync

Snapshots is maintained on the Master:

, Haven most_recent Snapshot denotes the most recent mirroring-related snapshot of the Master

, Haven last_replicated Snapshot reflects the most recent state of the Master which have a consistent replica on the Slave

One snapshot is maintained on the Slave

, Haven last_replicated Snapshot reflects the most recent state of the Master which have a consistent replica on the Slave

650) this.width=650; "title=" image "style=" border-right-width:0px;border-bottom-width:0px;border-top-width:0px; " Border= "0" alt= "image" Src= "http://s3.51cto.com/wyfs02/M01/55/42/wKiom1SJM5OQcBmbAADYy_XQHx0076.jpg" width= "644" height= "167"/>

Offline initialization

-offline initialization (previously dubbed ' Truck ' initialization) enables initialization of a remote mirror peer (the ' Sl Ave ') without being required to replicate the contents of the local peer (the ' Master ') over the link (a.k.a. Online Initi Alization)

-the feature applies to asynchronous mirroring, and entails validation of the replica data prior to ongoing mirroring only for Asynchronous mirror this way, reduce bandwidth consumption, save initialization time, before mirror will "transport" over the replica do check

Asynchronous Replication Offline initialization ("Truck" Mode) process

1.Create Snapshot of Future Master volume

2.Backup Snapshot to transportable media (e.g. tape)

3.Transport Media to remote site

4.Restore Slave volume from transported media

5.Create Async Mirror Specifying ' offline initialization '

6.Activate Async Mirror

–offline initialization would begin

-Checksum exchange on 64K boundaries

-Reduces bandwidth and time required for initialization

650) this.width=650; "title=" image "style=" border-right-width:0px;border-bottom-width:0px;border-top-width:0px; " Border= "0" alt= "image" Src= "http://s3.51cto.com/wyfs02/M00/55/40/wKioL1SJNDeBOqGfAADVheZB8sQ668.jpg" width= "644" height= "194"/>

Third, Data migration

XIV DM can migrate data on any other storage to XIV via FC or iSCSI without downtime, enabling online migrations in production environments. (This is actually a bit inaccurate, the middle will be down for a period of time, that is, the following DM process Step2)

During data migration, XIV will continue to process IO from the host.

– All read operations are handled according to the current data:

If the data is already written to XIV, read it from XIV.

If the data is not written to XIV, the read from host to XIV is read from the source array and returned to the host

–XIV handles all write operations sent by the host:

There are two ways to handle a write request, which is when you define the data migration, you select either source Updating or no source Updating

Source Updating

---two sets of storage (source storage and XIV) write data, that is, the source storage is keep updated during the migration process, like XDRP, which is written both to XIV and to source storage To send acknowledge to host. If the communication with the source storage is broken during the migration process, then XIV will also set the write to fail

No Source Updating

---Migration process, the source storage is not write any data, that is, two sets of storage on the data is not synchronized

XIV Data Migration Process

1.Server is connected to legacy system & accessing Legacy LUNs

2.Unmap LUNs and Disconnect server from legacy system

–remove any proprietary device drivers from server

–prepare server to use native multipathing (MPIO)

3.Connect XIV to Legacy system

–define XIV as a Linux ' host ' to legacy system

–map legacy LUNs to XIV ' host '

4.Start XIV Data Migration

– "Keep Source Updated" is recommended

–XIV reads LUN sequentially

5.Connect Server to XIV

–map new XIV LUN to server

6.Production resumes and continues during migration

7.Disconnect Legacy Storage from XIV after migration are complete

8.Discard or repurpose legacy storage

650) this.width=650; "title=" image "style=" border-right-width:0px;border-bottom-width:0px;border-top-width:0px; " Border= "0" alt= "image" Src= "http://s3.51cto.com/wyfs02/M00/55/40/wKioL1SJNESTf0nlAABzISKcikA285.jpg" width= "126" height= "484"/>

more information on Copy service and data migration can be found in this book, SG24-7759-02,IBM XIV Storage system:copy Services and migration. BTW, all IBM Redbook can come here to find http://www.redbooks.ibm.com/, very useful, engineers must.

-------------------------

At this point, XIV comes to a very simple point, knowing a fur only, if the future work involves XIV will be more detailed study. The IBM high-end storage DS8000 series is covered at the beginning of the next section, with a lot of Redbook. But there's nothing to do but step by step.

This article is from the "star&storage" blog, make sure to keep this source http://taotao1240.blog.51cto.com/731446/1588693

XIV (5)--Data Recovery Protection (XDRP)