Logical Volume Manager(LVM)是 AIX 上用於邏輯卷管理的軟件。LVM 本身提供 Logical Volume (LV)數據在多個 Physical Volume (PV)之間做數據鏡像的功能，以達到存儲的本地高可用性。在 LVM Mirror 方案中寫 I/O 與底層設備交互如下圖所示。
當服務器發出寫 I/O 時，該 I/O 在 Parallel 模式下會同時並行發送到兩台存儲設備上。如上圖中 Step 1, Step 2 和 Step 1’, Step 2’。只有當 Step 2 和 Step 2’都完成時，一個寫 I/O 才會被服務器認為完成。
在該解決方案中，當底層任一存儲，即 PV，出現故障時，LVM 會自動將停止該 PV 上所有的 I/O 活動，並將相應讀寫切換到剩下的正常 PV 上。整個切換過程在 LVM 層完成，所有 LV 在故障切換過程中狀態保持在線，對應用層透明。切換時間最低在 15 秒左右，甚至更短。
DS8000 Metro Mirror (MM)技術是一種滿足 Recovery Point Object (RPO)為 0 的存儲級同城容災解決方案。該方案中，數據通過存儲底層的 I/O 同步復制到容災站點來達到相應的容災目的。在 DS8000 MM 方案中寫 I/O 與不同站點間 DS8000 存儲交互如下圖所示。
當服務器發出寫 I/O 時，首先該寫 I/O 首先放往在生產站點主存儲設備上；其次該寫 I/O 由生產站點主存儲發往災備站點備存儲；接著備存儲發回寫 I/O 完成信息；最後主存儲向服務端發送寫 I/O 完成信息。整個過程中，每個寫 I/O 保證會在生產和容災站點間同步完成。
在該解決方案中，當生產站點發生災難時，會觸發站點切換場景，即生產站點所有設備宕機，災備站點服務器和存儲在容災端被啟用並提供服務。由於容災端存儲的數據是通過同步復制技術產生，數據與生產保持一致，從而保證了 RPO 為 0。值得注意的時 DS8000 MM 該方案本身不提供生產站點的本地存儲高可用保證。當本地存儲發生故障且無法恢復時，最終需要將生產切換到容災站點。整個過程一般為幾個小時或更高。
AIX LVM Mirror 結合 DS8000 Metro Mirror 解決方案是一種融合兩種方案優點的存儲高可用加容災解決方案。該解決方案的基本架構圖如下圖所示。
AIX LVM Mirror 結合 DS8000 Metro Mirror 解決方案其優點是顯而易見的：其為企業基礎架構提供本地存儲高可用保護的同時，也提供了存儲級同城容災的能力。
但是在本方案中，由於生產端服務器的 AIX LVM 的 LV Copy 存在兩份，而容災端只有一份，因此在容災端的單份 Copy 對容災切換的影響成為客戶主要關注點，主要有以下幾點：
容災切換時影響：容災端應用在單份 Copy 情況下其 LVM VG 和應用是否能正常拉起，以及相應 RTO 影響。
生產回切時影響：生產端 LVM Mirror 能否正常重新同步，及其對生產的性能影響。
整個操作流程復雜度：復雜度是否可控，是否會對運維團隊帶來額外負擔。
對於以上問題我們將分計劃內和計劃外兩種切換場景在第二章節進行詳細討論。
一般容災切換場景可分為計劃內和計劃外兩種，以下章節分別就該兩種場景進行討論。所有討論均基於實際測試結果，測試環境如下:
硬件為 Power 570，4 核 CPU，16G 內存。
操作系統 AIX 6100-05 + PowerHA 6.1.0.9，雙機配置為 Active-Standby 方式。
應用為 Oracle 10g。（這裡以 Oracle 應用為例，本方案也適用於其他應用場景。）
整個測試數據容量大小約為 1 TB。
計劃內切換特點在於容災站點切換以業務驗證為主，容災端應用運行時間短，期間 AIX LVM 和存儲不會做變更。因此在此短時間期間 AIX LVM 可以以非健康狀態運行。針對其特點，設計 LVM Mirror + DS8000 MetroMirror 的存儲架構切換流程如下圖。
步驟一，容災切換：
停止生產端應用和卸載相關文件系統。
在生產端應用服務器執行 varyoffvg 和 exportvg 操作。
將 DS8000 MetroMirror Failover 到容災端。
在容災端服務器通過 importvg –f 方式導入 VG 配置信息，varyonvg。注意，importvg 增加-f 參數將保證 vg 即使在單份 copy 不存在的情況下也會被導入。
在容災端啟動應用。
步驟二，數據回遷：
將 DS8000 MetroMirror 配置從容災端 failback 到生產端，該過程不影響容災端應用運行。經過此步驟，生產端的兩台 DS8000 數據將不一致。
步驟三，生產恢復：
停止容災端應用和卸載相關文件系統。
在容災端應用服務器執行 varyoffvg 和 exportvg 操作。
將 DS8000 MetroMirror Failover 到生產端。
在生產端應用服務器執行 importvg 和 varyonvg -n 操作。注意，varyonvg 增加-n 參數將保證 vg 在兩份 copy 不一致的情況下不會被自動同步，而以最新 copy 為准。
在生產端啟動應用。經過此步驟，生產應用正常啟動，但是兩份 DS8000 的 LV Copy 還處於不一致階段，數據還未進行同步。
步驟四，結束：
在選取適當時間段，如業務不繁忙的時間，執行 syncvg 操作，將兩份 LV Copy 進行同步。
至此，計劃內容災切換演練結束，生產端應用恢復正常。
以下對本方案和常規 DS8000 MetroMirror 非 LVM Mirror 容災方案就計劃內切換流程作三方面對比。
容災切換時 RTO 影響和其他影響。
在容災端進行切換的時候，相對普通 DS8000 MetroMirror 方案，由於生產端采用了 LVM Mirror 的方式，在容災端少了一組 LV Copy，因此在容災端服務器需要通過 importvg –f 方式在容災端導入 vg 信息。相比直接 importvg 方式，經過實測，總計 1T 共 4 個 VG 導入過程正常，時間並未有明顯增加，耗時僅增加約 2%不到，RTO 影響幾乎可以忽略不計。隨後應用能正常啟動無異常。
生產回切時 RTO 影響、性能和其他影響。
當應用在生產端進行回切時，相對普通 DS8000 MetroMirror 方案，由於生產端的兩份 LVM 的 LV Copy 在回切後數據不一致，需要有一個數據同步過程。由於數據同步期間性能會對生產應用造成一定影響，因此在恢復過程中，生產端 LVM 采用 varyonvg –n 的方式拉起 VG，以最快速度掛載 VG，正常啟動應用，且避免數據提前同步。在應用正常運行後，挑選合適階段設置合適的同步線程數目再進行數據同步。因此整個恢復過程中，比對普通非 LVM Mirror 方式，RTO 無影響，性能影響相對可控。
另外 LVM Mirror 重新同步的方式 Physical Partition(PP)級別的增量同步方式進行同步，因此同步數據量較少，具體大小取決於應用特征和數據規模。在本例中 1T 總容量的的重新同步的數據量約占 1/3。采用雙線程同步，同步速率約 200MB 左右，同步時間約半小時。
整個操作流程復雜度。
在整個流程中，唯一增加的復雜度在於在生產回切時，需要重新對 LVM Mirror 的兩份數據進行重新同步。在實際操作中，使用 syncvg 對整個 VG 進行同步。該過程可通過設定同步線程數來平衡同步速率和對生產的性能影響，操作相對簡單直接。
計劃外切換特點在於生產站點不可用，容災端應用運行時間可能會較長，期間 AIX LVM 和存儲有可能做變更。因此在此長時間期間 AIX LVM 須以健康狀態運行。針對其特點，設計其切換流程如下圖。
查看本欄目更多精彩內容：http://www.bianceng.cn/OS/unix/
步驟一，容災切換：
直接將 DS8000 MetroMirror Failover 到容災端。
在容災端服務器通過 importvg –f 方式導入 VG 配置信息，varyonvg。注意，importvg 增加-f 參數將保證 vg 即使在單份 copy 不存在的情況下也會被導入。
在容災端啟動應用。
步驟二，在線刪除單份不存在的 copy：
使用 rmlvcopy 命令將不存在的 copy 在線刪除。
使用 reducevg 命令將不存在的 pv 通過制定 pv id 的方式在線刪除。經過該步驟後，LVM Mirror 被拆除，整個 LVM 恢復單份 copy 正常狀態，容災端應用存儲可進行常規的變更。
步驟三，數據回遷：
在生產站點恢復後，將 DS8000 MetroMirror 配置從容災端 failback 到生產端，該過程不影響容災端應用運行。
步驟四，生產恢復：
停止容災端應用和卸載相關文件系統。
在容災端應用服務器執行 varyoffvg 和 exportvg 操作。
將 DS8000 MetroMirror Failover 到生產端。
在生產端應用服務器執行 importvg 和 varyonvgn 操作。
在生產端啟動應用，經過此步驟，生產應用正常啟動，但是只有單份 LV Copy，本地還不具備存儲高可用能力。
步驟五，結束：
在選取適當時間段，如業務不繁忙的時間，重新執行 mklvcopy 和 syncvg 操作，實施 LVM Mirror。
至此，計劃外容災切換演練結束，生產端應用恢復正常。
以下對本方案和常規 DS8000 MetroMirror 非 LVM Mirror 容災方案就計劃外切換流程作三方面對比。
容災切換時 RTO 影響和其他影響。
計劃內切換流程和計劃外切換流程對 RTO 影響相同，且亦能保證應用正常啟動。唯一不同在於需要額外使用 rmlvcopy 和 reducevg 命令將多余的不存在的 lv copy 刪除，保證系統正常長時間運行。在本例中整個過程操作不到半小時完成，且此過程對生產透明，亦可在線運行，因此影響很低。
生產回切時 RTO 影響、性能和其他影響。
計劃外的生產回切其實和常規 DS8000 MetroMirror 非 LVM Mirror 容災方案計劃外回切相同，因此無 RTO 影響和性能影響。但是為了恢復到本地存儲高可用狀態，需要重新建立 LVM Mirror 關系，因此在這裡多了重新實施 LVM Mirror 的過程。整個過程長短與應用規模有關系。在本例中 1TB 的數據量采用雙線程同步速率大約 200MB 左右，總計後台同步時間約一個半小時，加上實際操作時間總計約兩個半小時左右。
整個操作流程復雜度。
在整個流程中，增加的復雜度主要在於切換時在容災端需要在線刪除不存在的 lv copy，在生產回切後，需要重新再次實施 LVM Mirror。這些操作雖然相對比較復雜，但在理論和實際實驗中都能對應用做到透明，在性能方面通過合理規劃都能將影響降到最低。
AIX LVM Mirror 和 DS8000 Metro Mirror 分別是業界內成熟的技術。通過實踐證明，其兩者結合可以充分結合組成一種整體的存儲高可用和容災解決方案。該方案有效為客戶消除了本地存儲單點故障和帶來了同城容災能力的同時，在日常運維，特別是站點切換流程中，使增加的運維成本相對可控。
請注意，本文中的方案並不一定適用於您的 IT 環境或問題。具體情況請經過實際測試或咨詢當地 IBM IT 專家進行論證。