轉載自：https://www.talkwithtrend.com/Article/161411
【摘要】：隨着全球IT產業的飛速發展，金融行業的IT建設逐步成為主導金融企業業務發展的核心驅動力，基於金融行業IT系統容災建設的各種行業標准以及監管標准也相應提高。而決定容災架構健壯與否的最關鍵因素就是數據復制技術，它是實現高標准RTO和RPO的前提條件。本文基於業界主流數據復制技術的原理、復雜度、關鍵因素以及復制效果等多個維度進行分析及論述，旨在為同業在此類項目規划和建設過程中提供一些啟示和幫助。
【關鍵字】：數據中心；容災；同步復制；異步復制
1.背景及綜述
在金融行業內，綜所周知其對業務連續性的要求以及對各種IT風險的應對能力的要求都是非常高，尤其是對容災能力的要求，這是由它的業務特殊性以及集中式架構所決定的。在金融企業容災架構中，所謂的數據復制技術主要是指能夠將結構化數據進行復制，從而保證數據具備雙副本或者多副本的技術。目前業界發展來看，可以實現數據復制的技術多種多樣，有基於數據庫層面的數據復制技術，例如Oracle公司的Active Data Gurad、IBM公司的 db2 HADR等；有基於系統層面的數據復制技術，例如賽門鐵可的vxvm、傳統的邏輯卷管理（LVM）、Oracle公司的自動存儲管理（ASM）冗余技術、IBM公司的GPFS等；有基於存儲虛擬化實現的數據復制技術，例如EMC公司Vplex Stretch Cluster、IBM公司SVC Split Cluster、NetAPP公司Metro Cluster等； 也有基於存儲底層實現的數據復制技術，例如IBM公司的DS8000 PPRC技術、EMC公司的SRDF技術、HP公司的CA技術等等。每一種技術都有其實現的前提條件，也有各自的技術特點和實現的不同效果。本文將從復制技術的原理、特點、復雜程度以及復制效果等多方面展開分析及論述，並從多個維度進行對比分析，將業界主流數據復制技術的發展現狀以及技術優劣給予一個清晰的展示，並就數據復制技術發展的未來以及趨勢予以展望。
2.數據復制技術價值分析
2.1 數據復制在容災中的必要性
一、RPO保障
如果沒有數據復制技術，那么容災也就無從談起。當面臨站點及故障時，由於沒有數據復制技術的支撐，我們的數據無法在其他站點再現，這將意味着RPO將無法保障。對於一個金融企業來講，最終要的就是客戶的數據，它是企業的生命。從這個意義上來講，金融企業不能沒有容災體系，容災體系的前提條件是能夠實現數據復制。那么數據復制的效率如何，復制的效果如何，復制技術的先進與否也就決定了金融企業生命線的穩固與否。
二、RTO保障
所謂RTO就是在容災系統在面臨站點級故障時，多長時間能夠恢復業務。假設站點故障恢復的時間不可容忍或者根本沒有可能，那么業務必須能夠切到另外一個數據中心，從數據、應用以及網絡層都需要具備這個切換能力。但是最終的目的就是要保障業務能正常恢復，而業務恢復的前提條件就是數據，沒有數據的應用切換和網絡切換沒有任何意義。也就是說數據恢復是應用切換以及網絡切換的前提條件，從這個意義上講，數據復制效率和效果直接決定了一些列切換，也就是它使得RTO成為可能。
2.2 評價數據復制技術的維度分析
對於數據復制來講，我們可以從多個層面、多種技術去實現。各有各的特點，那么究竟哪一種數據復制技術更適合我們？活着說哪一種復制技術更科學合理？這需要一系列從不同緯度進行的科學評估。本文認為應該從以下幾個方面來展開分析，並結合我們自己的需求來選擇合理的數據復制方案。
一、投資成本分析
建設任何一個項目，投資成本的分析都是必不可少的分析維度。對數據復制技術的投資成本分析來講，我們需要從它的首次建設成本、持續維護成本以及容災管理成本等多方面去考慮。
二、技術成熟度及健壯性分析
對於數據復制技術的成熟度和健壯性分析來講，一方面我們要從技術本身的原理上來分析，另外我們還需要從技術的發展以及應用范圍以及應用的持久穩定性等方面來考慮。
三、風險評估分析
數據復制技術本身來講是要幫助我們解決站點級故障帶給我們的IT風險，但是對於技術應用本身來講，它也會存在一些技術風險。比如說特殊場合下的一些技術風險、容災管理過程中的一些風險、極端場合下的一些技術風險等等。
四、功能拓展性分析
對於數據復制技術本身來講，其主要功能就是完成數據的復制。但是在完成數據復制的同時，由於其架構的特點以及技術特點等因素有可能對於我們的應用產生積極的拓展性作用，也有可能限制了我們的應用架構模式，還有可能對我們的基礎架構擴展性以及靈活性造成一定的限制。
3.數據復制技術原理分析
3.1 基於應用事務日志回放技術
圖3.1是Oracle數據庫層面的數據復制技術（ADG）的架構原理圖。
對於該架構原理圖，本文從其實現的基本條件、數據復制原理、數據復制的模式以及數據復制的關鍵因素等幾個方面來進行深度剖析。
圖3.1-1 Oracle Active Data Guard
3.1.1前提條件
容災站點之間需要有三層以太網連通，軟件層面需要數據庫的集群軟件模塊（Oracle Active Data Gurard）或者是db2 purscale hadr。服務器層面需要至少兩套服務器系統分別部署於兩個數據中心。存儲層面需要兩套存儲空間分別部署於兩個站點作為主庫存儲和備庫存儲，他們互相之間獨立。
3.1.2復制原理
對於主站點的數據庫來講，客戶端的數據更新請求首先要由日志寫入進程寫到重做日志當中，然后由數據寫進程再周期性地寫入數據文件當中。重做日志當中以SCN為數據庫獨有的時間搓序列來記錄所有數據庫更新的先后順序，從而保障數據庫恢復能夠按照正確的順序執行保障數據一致性和完整性。那么對於配置了Active Data Guard的數據庫讀寫的完成在以上所述過程中，日志寫進程在本地日志文件寫入過程的同時，日志傳輸進程會將緩存里面的重做日志通過ADG傳輸給災備站點的備庫實例，備庫實例的日志接收進程根據接受到的重做日志在備庫上重新執行數據庫的更新操作，從而保證主庫和備庫的事務性更新行為一致性，最終保證數據的一致。當然也有一個前提條件，那就是在ADG作用之前，必須保證備庫的數據保持與主庫的某一固定時間點的完整副本，這需要靠傳統數據備份技術來實現備庫的初始數據復制。因為事務復制的本質是行為復制，那么行為作用的初始數據副本必須保持一致，才能保證最終兩副本的一致性。
對於事務日志的復制技術，本文根據主庫IO周期特點可以分為絕對同步模式、近似同步模式和異步模式三種。絕對同步模式是指主庫的一個完整更新事務的結束既要包括主庫的重做日志落盤也要包括備庫的重做日志落盤，也就是說備庫重做日志落盤之后返回給主庫，主庫才能執行下一個事務。近似同步模式是指在傳輸正常情況下保持與絕對同步模式一樣的模式，在網絡傳輸超時的情況下，就會剝離備庫重做日志的過程，只要保證主庫重做日志落盤就可以了。異步模式是指主庫只保證本地重做日志落盤，並不會等待備庫重做日志落盤的返回信號。在后兩種模式下，當主備庫傳輸管理剝離之后，主庫會主動通過以下兩種方式探測並嘗試重新和備庫建立聯系，第一是歸檔日志進程會周期性ping備庫，成功情況下，它會根據獲得的備庫控制文件的記錄的最后歸檔點和自己的歸檔日志決定向備庫推送哪些歸檔日志。第二是日志發送進程會在重做日志准備發生歸檔的時刻點主動去ping備庫日志接受進程並把剩余的重做條目發送給備庫接受進程。
3.1.3關鍵因素
基於事務日志回放技術的數據復制架構，從技術規划上以及運維管理層面上有幾個關鍵因素需要把握才能將這種數據復制技術運用自如，才能幫我們真正實現高標准的容災體系建設。
一、重做日志管理策略設計
我們知道對於數據庫來講，我們是靠其在線重做日志和離線重做日志來進行數據恢復的。對於離線重做日志也就是歸檔日志，我們是需要周期性備份並刪除的，否則離線重做日志就會無限占用數據庫有限的存儲資源。那么對於事務日志型數據復制架構來講，無論是主庫還是備庫，都需要有合理的日志管理策略來配合才能正常運行。策略的規划和設計需要把握以下幾個原則：
1．完成應用的日志要及時轉儲，包括主庫傳輸完畢的歸檔日志和備庫應用完畢的歸檔日志。
2．沒有完成應用的日志必須能夠保留，主庫沒有傳輸到備庫的歸檔日志如果被提前轉儲會造成備庫數據丟失，備庫沒有被應用的日志如果轉儲，備庫同樣會丟失數據。
3．存儲資源的科學規划，如果主備庫暫時中斷，又因為原則2導致歸檔日志堆積，那么勢必造成存儲資源的需求超過正常時刻的存儲需求量，如果存儲資源不夠，又會造成數據庫發生宕機事故。
以上各個原則的科學設計既需要依賴於數據庫參數的合理設置，又需要依賴於備份工具的轉儲策略合理配合，同時更需要根據不同的業務系統以及負載特點，通過歷史數據評估以及仿真測試數據來設計合理的數值並進行動態評估和優化。
二、架構擴展性及靈活性
在今天的互聯網線上時代，系統架構的擴展性和靈活性顯得尤為重要。對於容災架構來講，它的擴展性和靈活性同樣非常重要。對於業務型的數據復制架構來講，它有兩種基本架構：級聯架構和串聯架構。級聯架構是指一點為主多點為備，串聯架構是指主備模式依次類推。級聯架構更有利於主庫的多點保障，串聯架構更有利於主庫的性能保障。具體采用什么樣的架構組合，是要根據主庫數據的具體業務需求進行合理評估和設計。
三、容災切換管理
主備庫的切換，包括兩種類型的切換：Fail Over & Switch Over。
Fail Over是指故障情況下的強制切換，Switch Over是指計划性的切換。無論是哪種切換首先是要保障備庫數據和主庫數據一致或者可容忍范圍內的近似一致。其次當數據發生切換時，實際上主庫的服務IP地址就會轉化成備庫的服務地址，無論是通過域名轉換還是通過應用重連的方式都需要保障上層的服務地址能夠無縫切換。最后切換之后，原來的主庫如果沒有時間戳恢復功能的話，那么原主庫里面的數據就會變成無效數據，需要重新初始化數據副本。但是如果保持時間戳恢復功能的化，就會巨大的存儲空間消耗。
3.2 基於系統級邏輯卷鏡像技術
下面三張圖都是基於系統級邏輯卷鏡像技術實現的數據雙重復制。圖3.2-1是基於ORACLE自動存儲卷管理技術實現的ASM磁盤卷鏡像復制技術；圖3.2-2是基於UNIX存儲卷管理（LVM）實現的邏輯卷鏡像技術；圖3.2-3是基於IBM GPFS分布式文件系統底層邏輯磁盤鏡像實現的數據復制。三種技術雖然依賴的具體技術不同，但是其底層原理都是基於系統層面的雙寫實現的數據復制。
圖3.2-1 ORACLE ASM復制鏡像架構
圖3.2-2 LVM鏡像復制架構
圖3.2-3分布式文件系統GPFS鏡像復制架構
3.2.1 前提條件
容災站點之間需要SAN環境聯通。軟件層面，架構一需要具備ORACLE集群軟件當中的自動存儲卷管理模塊，架構二需要借助UNIX操作系統層的邏輯卷管理器，架構三需要借助GPFS或者類似的分布式文件系統軟件。存儲層面需要兩套存儲空間分別部署於兩個站點作為主庫存儲和備庫存儲，他們互相之間獨立。
3.2.2 復制原理
對於ASM和LVM模式來講，都是將底層來自不同站點的兩個物理存儲卷作為鏡像對組合成一個可用的邏輯存儲卷提供給上層應用來存放數據，本地物理卷和遠程物理卷分別是由存儲經過本地SAN環境以及跨數據中心SAN環境提供給服務器操作系統層。LVM是對操作系統的PP寫入進行實時雙向復制，而ASM是對Oracle數據文件AU寫入進行實時雙向復制。本地寫完並且遠端寫完才能算是一個完整的寫入，假設遠端存儲卷寫入超時就會被標為故障或者是離線狀態，當遠端存儲寫入恢復之后，對於LVM來講需要重新進行手動同步實現鏡像副本完全一致。而對於ASM來講，會有一個短時間內的日志記錄會幫助恢復離線鏡像恢復數據，但是如果超過這個時間，同樣需要一個全新的同步來保證數據的一致性。二者的區別在於LVM的邏輯卷與物理卷的映射關系在創建邏輯卷的時候就已經定義好了，所以對於壞塊兒問題，LVM無法完成塊兒指針的動態轉移。而ASM是在數據寫入時才會分配具體的AU，完全可以做到通過指針轉移的方式避免壞塊兒導致的數據寫入失敗問題。
對於GPFS模式來講，它是通過將底層來自不同站點的兩個物理存儲卷歸屬到不同的Failure Group當中，然后由這些物理存儲卷經過文件系統格式化形成分布式文件系統，提供給上層應用以文件的形式寫入數據。文件本身會被GPFS文件系統打散形成若干文件碎片，這些碎片在落盤時分別落入不同Failure Group當中的物理磁盤，從而保證底層數據的雙副本。這種模式與前兩種模式的最大區別在於它的數據落盤是根據NSD磁盤定義的服務實例順序來決定的，正常情況下我們需要定義本站點的服務節點為磁盤的主服務節點，這樣的話兩個鏡像寫入的時候是靠GPFS位於不同中心的兩個服務實例節點分別寫入，兩個服務實例之間也需要私有協議的交互，相當於數據的雙寫多了一個環節。
3.2.3 關鍵因素
基於系統級邏輯卷鏡像技術實現的數據復制，相對於其他類型的數據復制技術來講風險性較高，主要表現為以下幾個方面：
一、性能方面的問題
對於LVM和GPFS方式來講，對於數據庫的結構化數據復制性能會有較大損耗。因為數據庫的讀寫需要經過數據庫本身的存儲映射以及操作系統層的存儲映射之后才能真正寫入存儲緩存。縱向的路勁很長，性能損耗會比較大。而ASM本身是將數據庫的映射和系統級的映射做到了一起，相對性能損耗會低很多。所以如果利用這類型數據復制技術的話，數據庫層的存儲塊兒參數和操作系統層的存儲塊兒參數設置要經過一系列優化。
二、容錯性問題
如果我們用做本地存儲高可用實現這種方式的鏡像，那么容錯性就不會有問題。因為兩個鏡像副本的鏈路指標可以認為是同質的，鏡像之前的IO讀寫不會有差異。但是如果用在容災場合下，由於兩個鏡像副本的鏈路指標完全不同，那么就要求系統層能對正常場合下、故障場合下以及故障恢復后場合下的讀寫差異有很好的容錯性。比如說故障場合下的IO超時反饋速度、故障恢復之后的數據再同步問題。再有就是關於應用數據的容錯性，對於純粹操作系統層面的復制，完全無法避免應用邏輯錯誤。
三、負擔過載問題
其實這種技術在設計之初並沒有過多考慮過其在容災中的數據復制問題，設計初衷還是系統層的存儲卷的虛擬化管理。所以其靈活性以及擴展性優於其在容災數據復制中的作用。如果非要把這類技術應用到容災場合的數據復制當中，那么操作系統層一方面要完成應用功能載體作用，另外一方面要完成本地存儲卷虛擬化作用，還要一個重量級的容災數據復制作用。這種負擔會直接影響到其承載的數據庫應用。
3.3 基於存儲網關雙寫復制技術
所謂存儲網關雙寫復制技術，就是在物理存儲層之上增加一層網關技術用以實現存儲底層的虛擬化以及高可用鏡像，並且由存儲網關來控制鏡像寫入的策略和模式。IBM、EMC、NETAPP等公司都有相應技術的產品方案。基於寫入原理及策略的不同，又各有區別。圖3.3-1、圖3.3-2、圖3.3-3分別是IBM SVC Split Cluster、EMC Vplex Stretch Cluster、Netapp Metro Cluster。下面我們就其圖示、從原理上分別進行分析和論述。
圖3.3-1 IBM SVC Split Cluster
圖3.3-2 EMC Vplex Stretch Cluster
圖3.3-3 NetaApp Metro Cluster
3.3.1 前提條件
容災站點之間需要SAN環境聯通，TCP/IP實現三層可達。兩個站點分別要部署各自的存儲集群節點，共同組成存儲網關集群。假設要實現雙中心的自動化仲裁及切換，那么第三個仲裁站點以及站點中承載仲裁軟件的計算及存儲載體也是必須的。
3.3.2 復制原理
對於Vplex Stretch Cluster來講，首先兩個存儲網關節點是一對類似ORACLE RAC模式的AA模式集群節點。如圖3.3.2-2所示，兩個節點都可以接受來自上層應用的讀寫請求。假設來A和B分別是來自底層存儲的兩個物理卷，那么經過Vplex集群化之后，這兩個物理卷被虛擬化集成為一個分布式共享卷C，對於C來講，兩邊的應用節點都可以看得到，都可以讀寫，它的底層又是有A和B兩個物理鏡像組成。兩個站點在寫請求到來時，首先要完成本地A或B的寫入，然后需要把寫入請求傳送給另外一個VPLEX節點來完成鏡像盤B或A的寫入。很顯然，兩邊同時寫入就有可能帶來同一個數據塊兒的訪問競爭，這個時候Vplex節點靠他們共同維護的分布式一致性緩存目錄來對競爭數據塊兒進行加鎖以及釋放等協同操作，最終完成對數據塊兒的最后更新。當發生鏈路故障而導致一邊節點無法寫入時，那么節點會保存相應存儲日志用以故障恢復之后的數據同步。我們可以理解該同步模式類似於Oracle的最大可用模式，正常情況下保證鏡像數據寫入的同步完成，當故障時刻會有timeout時間閾值來決定是否暫時切斷其中一個鏡像的寫。
對於IBM SVC和NETAPP MCC架構來講，它們同樣在存儲網關節點上實現對底層兩個物理卷的鏡像綁定，但是這個卷並不是一個分布式共享卷的模式，僅僅是一個實現了鏡像綁定的虛擬卷，對於卷的讀寫只能以其中一側節點為主，另外一側節點為備。節點發生故障場合下實現節點主備切換，它比傳統HA模式的切換先進在哪里呢？它的備節點是要從主節點上同步緩存的，所以一旦切換發生，時間僅僅耗費在虛擬卷的Ownership轉換上，緩存不需要重新讀入，從切換的時間上來講要比傳統HA快很多，從而保障了容災的RTO。
那么MCC和SVC的區別在於什么地方呢？對於SVC的Split Cluster的兩個節點來講，它們是兩個控制器節點組成的一個IO組，這個IO組意味着故障切換只能發生在這兩個控制器節點之間，而且對於一個物理卷來講只能歸屬於一個IO組，當這個IO組不可用時，那么這個卷也就無法讀寫了。對於MCC來講，承載虛擬卷讀寫的載體是SVM虛擬機，這個虛擬機是一個資源的組合體，可以動態組合網絡、存儲以及存儲操作系統等資源，所以它能在組成集群的四個控制器節點上進行動態切換，理論上可以切換到任何一個控制器節點上，只不過其切換本身有一個故障優先級控制其切換的順序。如圖，SVM可以首先切換到A2節點上，當A2節點也發生故障時，可以切換到B1節點上，當B1節點也發生故障時可以切換到B2節點上。
3.3.3 關鍵因素
基於存儲網關雙寫技術實現的容災數據復制，可以將數據容災管理功能從應用及系統層剝離，從而對上層影響相對很小，而且容災針對性設計保障其功能實現上會更優。但是其實施的復雜度相對較高，而且對於以上不同架構來講，其所承擔的風險也是不一樣的，所以在這類技術的應用上，我們需要特別關注以下幾個方面：
一、架構復雜性
無論是以上哪種存儲網關復制技術，那么從硬件條件上來講，存儲這一層需要通過硬件節點組成一層統一存儲集群。要想實現自動切換的話，那需要仲裁站點的參與。也就是說從存儲這一層來講，其實兩個站點就是一個系統的整體了，底層的復雜性就很高了。如果數據庫層、網絡層以及應用層的架構再稍微復雜一些的話，那么整個容災架構的復雜度就會直線上升。
二、架構擴展性問題
在這種容災架構下，其實存儲層不僅僅是作了一層虛擬化和集群化，更重要的是作了一層存儲的集中化，存儲網關成為存儲的統一出口。那么存儲網關集群的橫向拉伸能力制約了整個存儲系統的可擴展能力。當我們的業務出現快速膨脹的場合下，存儲網關集群的最大擴展能力以及其本身的縱向性能擴展性就會是一個關鍵性問題，我們必須考慮。
3.4 基於存儲底層塊兒復制技術
基於物理存儲層之間的軟件復制技術是相對比較傳統的存儲復制技術，應用的時間也比較長。幾乎每一個存儲廠商都會有針對性的解決方案。圖3.4-1是基於存儲軟件復制技術的基本原理圖。
圖3.4-1 存儲層軟件復制
3.3.1 前提條件
對於物理存儲底層的塊兒復制技術來講，對於環境要求主要是存儲層的要求。容災站點之間需要SAN環境聯通，兩邊的存儲一般要求型號一致並且配置有專門的存儲復制軟件以及相關許可。
3.3.2 復制原理
其實對於存儲存儲底層的塊兒復制技術來講，它跟上層的應用層關系不大，主要是依靠存儲層兩個節點來完成源到目標的復制。當上層應用將數據寫入存儲的時候，那么由存儲將這一IO請求再以塊兒的方式傳輸到另外一個存儲上，從而保證存儲設備在塊兒級別上的一致性副本。對於同步復制來講，需要應用端的IO請求等到存儲層的復制完畢之后才會正常返回，對於異步復制來講，應用IO請求跟底層復制沒有任何關系，不需要等待復制結果。對於這種復制技術來講，兩個數據副本僅僅是數據內容相同，在上層沒有任何邏輯捆綁或者是虛擬化，所以上層應用也是完全隔離的兩套應用，一旦存儲發生故障，無論上層應用節點及網絡節點是否可用都需要發生站點級切換實現業務連續性，存儲本身不能隔離開應用發生切換。
3.3.3 關鍵因素
對於物理存儲層面的塊兒復制技術，它剝離了對上層應用的依賴，直接靠存儲來完成數據復制。好的地方在於它的架構相對簡單、相關影響面較小，不好的地方在於它的功能狹窄，功能僅僅在於數據的拷貝，對於上層應用的支撐面兒很窄。所以對於這種復制技術的把握需要注意以下幾個點：
一、容災的切換管理
對於容災的切換管理，我們需要決定好幾個問題：
1.切換的決策問題。如果故障集中在存儲層面，而其他層面不受任何影響的場合下，那么是不是一定要執行容災切換？這需要一個完善的決策體系來支撐各種場合下的故障應對。
2.切換的流程以及技術管理體系建設。由於這種數據復制技術對上層依賴的耦合性非常低，那么單純的存儲切換無法實現，這就需要從上到下的一系列技術措施和管理流程來應對容災切換。
3.回切的流程及技術管理體系建設。同樣當故障恢復之后，我們需要回切的時候，這個過程雖然是個計划內的事件，但是可能相對比容災切換更要復雜、更需要關注。
二、技術兼容性
基於存儲底層的塊兒復制技術，其中最重要的軟件依賴就是存儲復制軟件，但是這個存儲復制軟件一般都是基於特定的存儲設備實現的，具有廠家或者設備壁壘。當我們的存儲呈現五花八樣的時候，那么這個核心的復制軟件可能也會呈現五花八門。對於存儲的升級換代或者更換品牌等事件更是有諸多限制。所以我們在應用此類技術的時候要充分考慮到這一點。
4.數據復制技術對比分析
4.1 關鍵維度的對比分析
4.1.1 投資成本對比分析
對於投資成本的分析，我們不僅僅要看建設成本更需要關注運維成本，不僅僅需要關注設備成本更需要關注管理成本。本文首先將成本划分為幾個部分，然后根據每一個部分成本按照定性分為高中低三個指標，最終得出的綜合分析如表4.1.1所示：
表4.1.1-1 成本分析表
A = 基於數據庫失誤日志回放技術。
B.1 = 基於系統級邏輯卷鏡像技術（數據庫管理存儲卷鏡像）。
B.2 = 基於系統級邏輯卷鏡像技術（系統層管理存儲卷鏡像）。
C.1 = 基於存儲網關雙寫復制技術（Vplex模式）。
C.2 = 基於存儲網關雙寫復制技術（SVC&MCC模式）。
D = 基於存儲底層塊兒復制技術。
對於以上成本分析，有幾個需要說明的地方。
對於網絡成本，以太網三層可達我們認為成本屬於低指標，對於二層可達或者是需要FC協議環境的我們認為成本屬於中指標，對於二層可達或者是FC環境的，而且對帶寬要求非常苛刻的我們認為是高；對於設備成本，對於存儲兼容性沒有任何要求的而且不需要購置硬件設備的，我們認為屬於低指標。對存儲設備型號有關聯性要求的我們認為屬於中指標，對需要購置網關設備的我們認為是高指標；對於軟件成本，如果有在數據庫層、系統層以及存儲層沒有任何附帶軟件許可的我們認為屬於低指標，如果既有附帶軟件模塊兒而且還有容量許可等我們認為屬於高指標；對於運維管理，不需要數據庫層面做特殊運維的我們認為屬於低指標，需要數據庫維護的屬於中指標，需要存儲高度支持而且需要數據庫應用等熟練實施整套切換的屬於高指標；對於容災管理來講，可以實現自動化切換或半自動切換的我們認為低指標，需要人工切換的我們認為是中指標；需要組成專門的容災決策管理體系並實施專家級切換的我們認為是高指標；對於風險管理成本完全取決於架構本身的風險程度高低。
4.1.2 技術健壯性對比分析
單就數據庫層面的數據來講，從復制有效性上來講基於事務日志回放技術可以有效避開底層物理存儲卷的物理視圖，就數據庫邏輯層面組成很好的邏輯視圖，數據的復制可以很好避開底層發生的邏輯塊兒錯誤等問題。而其他任何一項技術都無法避免存儲塊兒邏輯錯誤問題，因為它們在復制數據的過程中跟上層應用沒有任何校驗過程，那么當存儲塊兒上發生的配置性邏輯錯誤就會導致上層應用數據出現校驗錯誤。
從技術的專有屬性上來講，基於系統級邏輯卷鏡像技術的初衷在於數據的本地保護，並不是基於容災需求所生的技術，所以在跨地域鏈路的容錯技術上要弱於其他的專用容災數據復制技術。
從數據傳輸的復雜性上來講，除了上述C.1屬於雙向同步技術，其他技術全部屬於單向同步技術，雙向同步技術的穩定性和技術可靠性相對會低於單向同步技術。
4.1.3 技術風險對比分析
一、應用數據有效性風險
舉一個極端的案例，假設一個系統層面的誤操作把數據庫卷的元數據清除掉了，那么主庫在下次要訪問到這個卷上數據的時候可能就要發生宕機。這個時候如果我們是基於事務回放技術做的數據復制，那么這部分誤操作就不會被復制到備庫，備庫數據依然可用。但是如果從操作系統層或者是存儲層做的數據復制，它是無法感知這一誤操作的無效性，所以邏輯錯誤依然會被復制到災備中心，那么最終的結果就是兩個數據中心的數據庫都無法工作。
二、遠程鏈路抖動風險
容災必然會涉及到遠程鏈路，那么遠程鏈路相對於本地鏈路來講，抖動問題就是一個很難解決掉的問題。既然不能解決這個問題，那么就應該看到一旦這個問題發生了，帶給我們的風險是什么：
首先我們來看事務日志回放技術，假設我們使用的是近似同步模式，那么鏈路一旦發生抖動，直接影響就是日志同步會隨着發生不間斷超時，主庫緩存里的日志條目無法及時同步到備庫。當鏈路恢復穩定之后，歸檔日志和在線日志分別發起同步請求將主備庫數據追為同步，這期間主庫不受任何影響。
接着我們來看系統級鏡像技術，遠程鏈路抖動導致遠程鏡像寫入失敗，當然這個失敗會有一個從底層存儲、光纖鏈路以及操作系統等多層的超時的傳遞效應，每一層都會有自己的超時策略，反應到數據庫層之后，這就是一個不小的應用等待。當鏈路恢復穩定之后，會有一系列的鏡像同步過程，這個鏡像同步過程需要對主鏡像進行掃描分析，會有很高的性能消耗。
然后我們再來看存儲網關雙寫技術，鏈路抖動一旦超過仲裁閥值就會引起存儲網關集群的仲裁，這個仲裁結果不確定，有可能會發生切換而且會頻繁切換，一旦發生切換不僅僅要面對兩邊數據主備同步模式頻繁變化，而且還會面對上層應用在面臨鏈路抖動情況下的跨數據中心的頻繁訪問，相當於將不穩定問題又向上轉嫁了一層。這樣的復雜問題組合到一起，風險性相對較高。
最后我們再看物理存儲層的塊兒復制技術，其實他和事務日志回放技術面臨的風險幾乎相當，影響的僅僅是遠程數據副本的繼續同步，本地存儲寫入不受任何影響。鏈路穩定后，同樣面臨存儲層底層數據追平問題，當然這個策略和模式根據不同廠商的設計原理會有優劣之分，這里就不再詳細討論。
三、容災切換技術復雜度風險
探討這個問題的前提條件是拋開一切其他類似鏈路抖動之類問題，僅僅探討當發生站點級故障並且短時間無法恢復故障時刻，不同數據復制技術帶給我們整個容災切換的復雜度。基於存儲網關雙寫技術基本上會有一套完善的存儲層切換機制，依靠仲裁站點能夠實現自動化切換，只要雙中心之間的SAN環境相通，數據庫應用層自然也是無縫切換。基於應用事務日志回放技術就完全要靠人工來實現數據庫的切換以及應用訪問的切換了，需要依靠數據庫專家來判斷主備庫狀態以及具體的切換策略。這個不僅僅是技術上的風險而且是管理決策上的風險。基於系統級鏡像技術的切換需要依靠操作系統層的共享卷組或者共享文件系統或者是ORACLE集群來完成切換，屬於自動化或者半自動化切換。而基於物理存儲塊兒復制技術的切換則是一系列的冷切換，數據庫是一個全新數據庫的重新初始化，只不過底層存儲卷上的數據是主站點上的副本而已。
四、性能上的風險
對於性能上風險主要是指數據復制過程本身消耗的存儲資源以及計算資源的性能對業務上的性能影響如何。我們希望的是數據復制過程本身對主業務沒有任何性能影響，但是由於這兩者的高度關聯性，尤其是同步模式或者近似同步模式的場合。對此我們可以描述為下表（近似同步模式）：
表4.1.3-1 性能影響程度及范圍
A = 基於數據庫失誤日志回放技術。
B.1 = 基於系統級邏輯卷鏡像技術（ASM模式）。
B.2 = 基於系統級邏輯卷鏡像技術（LVM模式）。
B.2 = 基於系統級邏輯卷鏡像技術（GPFS模式）。
C.1 = 基於存儲網關雙寫復制技術（Vplex模式）。
C.2 = 基於存儲網關雙寫復制技術（SVC&MCC模式）。
D = 基於存儲底層塊兒復制技術。
4.1.4 功能擴展性對比分析
這一項的對比分析在於我們應用的數據復制技術對於應用層以及整個架構的擴展性和靈活性的影響程度，容災架構固然重要，但是對於真個基礎架構來講，容災指標是其中很重要的衡量指標之一，我們還有對架構擴展性、靈活性以及性能評估等多個方面。所以容災架構的設計不能制約其他指標的發展。詳細對比分析參照表4.1.4-1。
表4.1.4-1 功能擴展性對比分析匯總表
5.總結及展望
本文對企業容災過程當中涉及到的各種數據復制技術進行深入調研分析，並且根據其實現的技術原理進行剖析，從原理底層來分析其在實際容災應用過程中的技術優勢和面臨的風險劣勢，同時根據企業容災應用過程中所面臨的具體需求來對比分析幾類復制技術的差異，旨在為同行選型及實施提供技術參考。同時也希望有更多同業基於此提出更優化更科學的思路和想法。