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

和大多数存储系统同样，XIV也提供多地容灾的解决方案。XIV Data Recovery Protection (XDRP)有三种实现方式， Synchronous Mirroring; ASynchronous Mirroring; Data Migration。除此以外，固然也支持Flashcopy，VolumeCopy

1、Synchronous Mirroring

XDRP是在两个或多个XIV系统之间作real-time copy，支持 Fiber Channel 或iSCSI links【考虑到长距离灾备时的可靠性和带宽，大多数使用FC】。有Master system和Slave system。以下图描述了两个XIV系统是如何运做的。

 

 

• 三种状态:

–Initialization -正在作Sync，数据正从Master copy到Slave

–Synchronized - 完成Sync，两端数据一致

–Unsynchronized – Remote Mirror出现问题

 

那一旦remote mirror出问题了,好比链路段了，Master会对tracking它上面Source Vol的change.

–当链路恢复后，全部tracking的change会被马上copy到Slave上，这部分数据叫作 “Uncommitted Data”。当Vol resynced时系统在Slave Master上自动建立的一个Special Snapshot，这个Snapshot叫作""Last consistent snapshot”。它是系统Snapshot，用户不能手动删除，会在Fully resynced以后自动删除，它不会考虑大小限制，若是有须要，会占据磁盘全部剩余空间。

 

Consistency Groups--同时对一组voume作snapshot，好比数据库应用，数据库文件和Log文件不在同一个volume上，为了确保一致性，必须味数据库文件volume和log文件volume建立一个consistency group，而后基于consistency group作flashcopy。

• You can switch the role of the entire consistency group

–This will change the Master/Slave location of all member volumes in the consistency group

• Both the Master and the Slave system must be configured with an empty CG that is configured for mirroring

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

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

 

2、Asynchronous Mirroring

 只会发送改变的数据块给Slave，能够按事先定义的间隔时间段Sync，好比20s (min_interval), 30s, 1m, 2m, 5m, 10m, 15m, 30m, 1h, 2h, 3h, 6h, 8h, 12h

Mirroring是以Initialization开始，支持（Online Initialization和Offline Initialization，具体解释以下）

 

–一旦Initialization完成，Master会决定Synchronization的范围

当Define了新的Mirror以后，Master会在Mirror开始以前对系统生成一个Snapshot来表明初始状态

 

 

XIV系统使用特殊的Snapshot来决定Sync的范围

Two snapshots are maintained on the Master:

–The most_recent snapshot denotes the most recent mirroring-related snapshot of the Master

–The last_replicated snapshot reflects the most recent state of the Master which has a consistent replica on the Slave

One snapshot is maintained on the Slave

–The last_replicated snapshot reflects the most recent state of the Master which has a consistent replica on the Slave

 

Offline initialization

-Offline Initialization (previously dubbed ‘Truck‘ initialization) enables initialization of a remote mirror peer (the ‘Slave’) without being required to replicate the contents of the local peer (the ‘Master’) over the link (a.k.a. online initialization)

-The feature applies to asynchronous mirroring, and entails validation of the replica data prior to ongoing mirroring 只适用于异步Mirror这种方式，减小带宽占用，节省Initialization的时间，在Mirror以前会对“运输”过来的replica作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 future Slave volume from transported media

5.Create async mirror specifying ‘offline initialization’

6.Activate async mirror

–Offline initialization will begin

- Checksum exchange on 64K boundaries

- Reduces bandwidth and time required for initialization

3、Data Migration

  XIV DM能够经过FC或者iscsi将其余任何存储上的数据迁移到XIV上且不须要停机，实现生产环境下在线迁移。（这个实际上是有点不许确的，中间会停机一段时间，即下面的DM Process的Step2）

 

在迁移数据过程当中，XIV仍是会继续处理主机发过来的IO

–全部读操做会根据目前数据在哪里来处理：

 若是数据已经写到XIV了，那就从XIV读

 若是数据还没写到XIV，那从host发给XIV的读操做就从legacy storage中读取并返还给主机

–XIV处理全部主机发过来的写操做:

  处理写请求时，有两种方式，这是在你定义data migration时就选择了Source Updating仍是No Source Updating

Source Updating

--- 两套Storage（legacy Storage和XIV）上都写数据，即Source Storage在migration过程当中是keep updated的，就像XDRP，是既写到XIV，也写到legacy Storage后，才会给Host发送Acknowledge。若是migration过程当中和legacy Storage的通讯断了，那么XIV也会将这个写操做置为Fail

No Source Updating

--- Migration过程当中legacy Storage是不写任何数据的，即两套存储上数据是不一样步的    

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 is complete

8.Discard or repurpose legacy storage

 

附：

XIV_1300023>>target_list

Name          SCSI Type   Connected   

XIV_1310138       FC          yes   

XIV_1300023>>target_connectivity_list

Target Name   Remote Port        FC Port         IP Interface   Active   Up    

XIV_1310138   50017380279A0152   1:FC_Port:7:2                  yes      yes   

更多关于Copy Service和Data Migration的内容能够参考这本书《SG24-7759-02，IBM XIV Storage System:Copy Services and Migration》。BTW,全部的IBM redbook均可以到这里找http://www.redbooks.ibm.com/，很是好用，工程师必备。

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

至此XIV到此就告一段落，讲的很是简单，知道个皮毛而已，若是之后的工做涉及到XIV会更加详细地研究下。