和大多數存儲系統一樣，XIV也提供多地容災的解決方案。XIV Data Recovery Protection (XDRP)有三種實現方式， Synchronous Mirroring; ASynchronous Mirroring; Data Migration。除此之外，當然也支持Flashcopy，VolumeCopy
一、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
二、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
三、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會更加詳細地研究下。