第一章 容災中心建設方法

容災建設項目和業(yè)務連續(xù)性項目與用戶的業(yè)務要求、應用現(xiàn)狀密切相關，并涉及眾多技術和產品以及繁多的供應商，因而屬于建設復雜、風險較高的項目之一。為降低項目風險，保證容災中心建設的成功，選擇有經驗的合作伙伴、并且有成熟實用的方法論指導對信息中心容災建設非常重要。

EMC為企業(yè)提供“容災中心建設”或業(yè)務連續(xù)性建設提出了BCSI（業(yè)務連續(xù)性解決方案集成）方法論，遵循的方法如下：

如上圖，EMC為企業(yè)進行業(yè)務連續(xù)性或容災系統(tǒng)建設分為三個階段。三個階段是（不包含項目啟動等前期工作）：

• 規(guī)劃（Plan）——科學的規(guī)劃是項目成功的前提。規(guī)劃階段需要對企業(yè)的IT系統(tǒng)現(xiàn)狀進行評估分析，根據(jù)企業(yè)的業(yè)務發(fā)展的要求明確進行需求定義，從而在確定的需求基礎上選擇合適的技術，進行技術架構設計，選擇合適的技術方案并采購相應的產品。

• 建設(Build) ——本階段主要是進行技術平臺建設（包括整合、數(shù)據(jù)遷移等）、測試，建設完整的“災難恢復計劃(DRP)”或“業(yè)務連續(xù)性計劃(BCP)”。在科學、合理的規(guī)劃前提下，建設階段將相對比較有序。

• 管理(Manage)——對容災建設項目或業(yè)務連續(xù)性項目而言，建設了容災技術平臺及相關的人員、流程要求僅僅是開始，而不是結束，必須定期更新、維護確保能夠滿足不斷變化的業(yè)務發(fā)展要求。

  貫穿“規(guī)劃、建設、管理”三個階段的是“項目管理和服務集成能力”。容災或業(yè)務連續(xù)性建設涉及的技術和產品非常廣泛，針對不同的業(yè)務應用也可能采用不同的技術方案，這些方案來自不同的廠商；由于業(yè)務的相互關聯(lián)，不同的技術方案之間也存在密切的聯(lián)系，甚至相互依賴。同時，在容災建設過程中，將有多方供應商提供服務支持，能夠協(xié)調多方關系，對項目實施進度及質量進行統(tǒng)一控制，對多方服務進行集成調度是“項目管理和服務集成”的重要工作，也是保證項目按時完成并保證質量的重要因素。

  EMC的BCSI方法論為每個階段定義了所需要完成的工作和步驟（總共十大步驟），對每一步驟都有進一步詳細的定義，后面章節(jié)將針對本設計項目相關的地方提供了詳細步驟圖。針對不同的客戶，EMC將按照以上科學的方法論，在需要時可按照客戶的實際情況進行“量體裁衣”，設計合適步驟，為用戶進行有計劃、有步驟容災系統(tǒng)、業(yè)務連續(xù)性方案建設。

第二章 通用容災技術框架

2.1 企業(yè)信息系統(tǒng)保護層次

現(xiàn)代企業(yè)的數(shù)據(jù)中心IT平臺（包括主機平臺、網絡平臺、存儲平臺等）的保護和恢復有不同等級的技術手段，未來企業(yè)的業(yè)務連續(xù)性建設將需要不斷提高企業(yè)的信息、數(shù)據(jù)的保護和恢復的等級。

不同層次的數(shù)據(jù)中心保護

如上圖所示，對企業(yè)集中化數(shù)據(jù)中心的IT系統(tǒng)和業(yè)務數(shù)據(jù)進行保護可以有多種不同層次的保護方案，主要分為本地保護和遠程保護兩個方面。

  企業(yè)數(shù)據(jù)中心面向運營的保護及恢復包括三個層次：

1. 平臺保護—主要是平臺的高可用，如采用主機群集系統(tǒng)和高可用存儲平臺（包括SAN網絡環(huán)境的高可用和存儲系統(tǒng)的高可用），保證IT平臺沒有單點故障，實現(xiàn)業(yè)務和應用的高可用性。

2. 數(shù)據(jù)備份—對業(yè)務數(shù)據(jù)進行經常性的本地備份，在IT系統(tǒng)出現(xiàn)物理故障或邏輯故障時，數(shù)據(jù)備份都能提供可靠的數(shù)據(jù)保護。

3. 數(shù)據(jù)恢復—在出現(xiàn)數(shù)據(jù)錯誤或丟失時能夠進行快速、可預見的數(shù)據(jù)恢復，減少IT系統(tǒng)的中斷時間，降低對業(yè)務運營的影響。

 建設了完善的本地保護和恢復后，企業(yè)需要規(guī)劃建設面向災難保護及恢復的“遠程”數(shù)據(jù)及業(yè)務保護，它包括三個層次：

1. 遠程的信息保護—是將企業(yè)的所有重要數(shù)據(jù)安全的存儲在遠程站點，提供保護，避免災難性的事件破壞數(shù)據(jù)。

2. 遠程自動處理—除了提供對生產數(shù)據(jù)的遠程保護外，能夠自動進行系統(tǒng)切換、回切及數(shù)據(jù)恢復等工作，從而在災難事件發(fā)生時能夠快速恢復業(yè)務運行。

3. 多數(shù)據(jù)中心保護—通過建設多個數(shù)據(jù)中心，采用多數(shù)據(jù)中心的數(shù)據(jù)保護、恢復技術，防范更大范圍的災難事件。

2.2 容災技術模型

容災技術平臺建設是企業(yè)業(yè)務連續(xù)性建設的重要基礎。EMC公司將企業(yè)的IT平臺劃分為“接入平臺、應用平臺、數(shù)據(jù)平臺”三部分，建議企業(yè)的容災技術平臺建設應該主要著眼于對業(yè)務處理平臺，數(shù)據(jù)平臺和接入平臺這三個重要的系統(tǒng)領域的保護。

容災技術模型示意圖

2.2.1 業(yè)務平臺的保護——業(yè)務處理能力的冗余

容災技術方案建設中，對于企業(yè)的業(yè)務平臺的保護，主要表現(xiàn)為對業(yè)務處理能力的冗余和復用，其中牽涉：

• 支持應用系統(tǒng)運行的服務器和操作系統(tǒng)等系統(tǒng)軟件

• 支持應用系統(tǒng)運行的存儲器及存儲器和服務器的連接（存儲網絡等）

• 連接服務器的IP網絡系統(tǒng)

• 支持應用系統(tǒng)實現(xiàn)的中間件或數(shù)據(jù)庫等

  客戶將需要在容災中心應該配置與需要保護的生產中心相同廠家、相同版本、相同配置的應用服務器、中間件和數(shù)據(jù)庫。要確保主數(shù)據(jù)中心和容災中心的軟件運行環(huán)境相同。

• 實現(xiàn)業(yè)務邏輯的應用軟件系統(tǒng)

  EMC咨詢服務部門將可以為客戶對上述各方面進行調查評估，分析客戶的當前生產中心業(yè)務平臺當前的現(xiàn)狀和特定技術要求，并提出建設容災方案的具體要求。

2.2.2 數(shù)據(jù)平臺的保護——業(yè)務狀態(tài)數(shù)據(jù)的復制

在容災系統(tǒng)中，對數(shù)據(jù)平臺的保護主要表現(xiàn)為對業(yè)務狀態(tài)數(shù)據(jù)的保護、備份和恢復以及復制，需要保護的業(yè)務狀態(tài)數(shù)據(jù)包括：

• 業(yè)務交易狀態(tài)（數(shù)據(jù)本身的數(shù)據(jù)屬性為文件、數(shù)據(jù)庫等）

• 系統(tǒng)狀態(tài)-包括應用軟件的初始數(shù)據(jù)、參數(shù)設置、以及系統(tǒng)軟件的配置數(shù)據(jù)、參數(shù)設置等。

• 中間數(shù)據(jù)（或臨時數(shù)據(jù)）

  在容災系統(tǒng)建設中，數(shù)據(jù)平臺的保護是實現(xiàn)企業(yè)災難恢復的核心。保證數(shù)據(jù)的安全永遠是第一位的，只有支撐企業(yè)業(yè)務運營的數(shù)據(jù)能夠及時、完整地復制到容災中心，才可以在災難發(fā)生時，在容災中心恢復受災難影響的業(yè)務應用。

  對不同企業(yè)，EMC將根據(jù)需求分析的結果，對企業(yè)的不同重要級別的應用或業(yè)務單元采取不同的數(shù)據(jù)復制方法，對不同類型的應用，根據(jù)其訪問特點等也將采取不同的數(shù)據(jù)復制方法。 

2.2.3 接入平臺冗余和切換

接入平臺在容災備份系統(tǒng)里，需要實現(xiàn)對外部接口的冗余及切換，其中牽涉：

• 應用數(shù)據(jù)接口的切換-包括文件傳輸、消息機制等

• 應用連接接口的切換- HTTP連接、數(shù)據(jù)庫連接、遠過程調用、對象的調用等…

• 網絡連接的冗余和切換–包括城域網網絡連接、撥號連接等等…

  企業(yè)的“接入平臺冗余和切換”的關鍵在于實現(xiàn)在容災中心應該配置相同訪問能力的網絡設備，并在網絡配置上確保能快速、方便地將網絡訪問從主生產中心切換到備份生產中心 

2.3 容災模式

將根據(jù)項目啟動前期的“現(xiàn)狀評估、業(yè)務需求分析”等結果，可以從容災層次、容災范圍、運營方式、容災規(guī)模等多角度進行綜合分析，得出適用于用戶容災要求的容災模式和運營方式。

2.3.1 容災層次

根據(jù)業(yè)務恢復時間的長短可以將容災建設劃分為不同的層次：

• 只做數(shù)據(jù)的災難保護，僅能保證數(shù)據(jù)的完整性，此類業(yè)務在容災中心只需要配置存儲平臺，實現(xiàn)數(shù)據(jù)的遠程復制和存儲即可。這種方式可以降低投資，但業(yè)務恢復時間很長（一般在3天以上）。數(shù)據(jù)的災難保護是僅將生產中心的數(shù)據(jù)完整地復制到容災中心的容災方式。數(shù)據(jù)的災難保護是異地容災的最低級形式，也是最基本的方式，是實現(xiàn)更高級容災方式的基礎。

  在災難發(fā)生時，僅有數(shù)據(jù)的災難保護無法保證業(yè)務的連續(xù)性，僅可以保證數(shù)據(jù)是可用的，若技術策略選擇得當，可以保證業(yè)務數(shù)據(jù)的完整性。采用這種模式有以下特性：

• 業(yè)務恢復速度較慢，通常情況下RTO>72小時

• 業(yè)務恢復難度大，需要新增設備

• 實現(xiàn)技術難度比較低

• 運行維護成本較低

• 投資比較節(jié)省

• 除數(shù)據(jù)的災難保護外，實現(xiàn)應用的高可用，確保業(yè)務可以快速恢復。容災系統(tǒng)的應用不改變原有的業(yè)務處理邏輯，是對生產中心系統(tǒng)的基本復制。這種方式有以下特性：

• 業(yè)務恢復速度較快，通常情況下RTO小于24小時，也可以達到幾小時級別

• 業(yè)務恢復過程相對簡單

• 實現(xiàn)技術難度比較高

• 運行維護成本較高，如：增加軟件版本管理、軟件部署、維護人員等

• 投資比較高

2.3.2 容災范圍

根據(jù)業(yè)務影響分析結果，容災備份存儲平臺項目的業(yè)務將劃分為關鍵業(yè)務和非關鍵業(yè)務兩大類。未來可以根據(jù)需要選擇要做容災保護的業(yè)務種類，可以先建設關鍵業(yè)務容災，未來實現(xiàn)全業(yè)務容災。

• 關鍵業(yè)務容災：業(yè)務需求定義中通過業(yè)務影響分析定義關鍵業(yè)務的容災

• 全業(yè)務容災。

2.3.3 同級容災或降級容災

根據(jù)容災中心配置的處理能力不同，可以分為同級容災和降級容災。若未來的在容災中心為需要進行容災保護的業(yè)務系統(tǒng)都配置與生產中心相同處理能力和高可用能力的業(yè)務處理平臺（主要是指主機性能，高可用群集等），則為同級容災設計。如果未來的在容災中心為需要進行容災保護的業(yè)務系統(tǒng)配置比生產中心的處理能力低或高可用能力降低（比如沒有做群集等），則為降級容災設計。采用同級或降級容災方式取決于業(yè)務需求和投資預算，降級容災可以減少投資（在主機方面的投資）。

第三章 不同容災技術介紹

3.1 不同容災技術方案概述

不同企業(yè)的不同業(yè)務需求和應用特點將可能需要有不同的容災技術要求，可以采用多種容災技術來建容災系統(tǒng)，EMC專業(yè)咨詢服務部將根據(jù)客戶的實際需求提供不同的技術方案。對所有客戶的容災技術平臺建設而言，容災方案的技術核心是數(shù)據(jù)的保護，實現(xiàn)遠程數(shù)據(jù)復制，并能夠在災難發(fā)生時在遠端利用復制數(shù)據(jù)提供企業(yè)業(yè)務運營支撐服務，因此數(shù)據(jù)復制技術是構建容災技術平臺的核心。不同數(shù)據(jù)復制技術的分類如下：

如上圖所示，對容災項目而言，比較可行的是采用連續(xù)數(shù)據(jù)復制技術。

根據(jù)不同容災方案所采用數(shù)據(jù)遠程復制技術位于企業(yè)IT架構不同層面又可以分為以下三類容災方案：

• 基于存儲層面的容災方案—利用存儲系統(tǒng)的遠程數(shù)據(jù)復制功能建設容災系統(tǒng)，它包括：

• 同類存儲平臺之間的數(shù)據(jù)復制；

• 異構存儲平臺之間利用虛擬存儲技術實現(xiàn)數(shù)據(jù)復制。

• 基于主機層面的容災方案—利用主機廠家提供的相關功能軟件或第三方的主機軟件實現(xiàn)遠程的數(shù)據(jù)復制，建設容災系統(tǒng)。

• 基于應用層的容災方案—如利用應用軟件如Oracle數(shù)據(jù)庫的本身的遠程數(shù)據(jù)復制技術建設容災系統(tǒng)

  本節(jié)將針對以上“基于存儲層面數(shù)據(jù)復制的容災方案” 、“基于主機層面的容災方案” 和“基于應用層容災方案（以Oracle Data Guard為例）”等三類不同方式容災方案進行分析。

  對不同的用戶，EMC將根據(jù)客戶的容災技術方案的實際需要以及技術條件進行評估，為用戶最合適的容災技術方案。

   

3.2 基于存儲的數(shù)據(jù)復制技術建設容災系統(tǒng)

采用基于存儲的容災方案的技術核心是利用存儲陣列自身的盤陣對盤陣的數(shù)據(jù)塊復制技術實現(xiàn)對生產數(shù)據(jù)的遠程拷貝，從而實現(xiàn)生產數(shù)據(jù)的災難保護。在主數(shù)據(jù)中心發(fā)生災難時，可以利用災備中心的數(shù)據(jù)在災備中心建立運營支撐環(huán)境，為業(yè)務繼續(xù)運營提供IT支持。同時，也可以利用災備中心的數(shù)據(jù)恢復主數(shù)據(jù)中心的業(yè)務系統(tǒng)，從而能夠讓企業(yè)的業(yè)務運營快速回復到災難發(fā)生前的正常運營狀態(tài)。

基于存儲的容災方案示意圖如下：

基于存儲數(shù)據(jù)復制技術的容災方案示意圖

采用基于存儲的數(shù)據(jù)復制技術建設容災系統(tǒng)是目前金融、電信企業(yè)、政府采用較多的容災方案，有非常多的應用案例，是容災建設可選擇的技術方案之一。

基于存儲的復制可以是如上示意圖的“一對一”復制方式，也可以是“一對多或多對一”的復制方式，即一個存儲的數(shù)據(jù)復制到多個遠程存儲或多個存儲的數(shù)據(jù)復制到同一遠程存儲；而且復制可以是雙向的。

基于存儲的容災方案有兩種方式：同步方式和異步方式，說明如下：

同步方式，可以做到主/備中心磁盤陣列同步地進行數(shù)據(jù)更新，應用系統(tǒng)的I/O寫入主磁盤陣列后(寫入Cache中)，主磁盤陣列將利用自身的機制（如EMC的SRDF/S）同時將寫I/O寫入后備磁盤陣列，后備磁盤陣列確認后，主中心磁盤陣列才返回應用的寫操作完成信息。

異步方式，是在應用系統(tǒng)的I/O寫入主磁盤陣列后(寫入Cache中)，主磁盤陣列立即返回給主機應用系統(tǒng)“寫完成”信息，主機應用可以繼續(xù)進行讀、寫I/O操作。同時，主中心磁盤陣列將利用自身的機制（如EMC的SRDF/A）將寫I/O寫入后備磁盤陣列，實現(xiàn)數(shù)據(jù)保護。

采用同步方式，使得后備磁盤陣列中的數(shù)據(jù)總是與生產系統(tǒng)數(shù)據(jù)同步，因此當生產數(shù)據(jù)中心發(fā)生災難事件時，不會造成數(shù)據(jù)丟失。為避免對生產系統(tǒng)性能的影響，同步方式通常在近距離范圍內（FC連接通常是200KM范圍內，實際用戶部署多在35KM左右）。

而采用異步方式應用程序不必等待遠程更新的完成，因此遠程數(shù)據(jù)備份的性能的影響通常較小，并且備份磁盤的距離和生產磁盤間的距離理論上沒有限制（可以通過IP連接來實現(xiàn)數(shù)據(jù)的異步復制）。

采用基于存儲數(shù)據(jù)復制技術建設容災方案的必要前提是：

• 通常必須采用同一廠家的存儲平臺，通常也必須是同一系列的存儲產品，給用戶的存儲平臺選擇帶來一定的限制。

• 采用同步方式可能對生產系統(tǒng)性能產生影響，而且對通信鏈路要求較高，有距離限制，通常在近距離范圍內實現(xiàn)（同城容災或園區(qū)容災方案）

• 采用異步方式與其他種類的異步容災方案一樣，存在數(shù)據(jù)丟失的風險,通常在遠距離通信鏈路帶寬有限的情況下實施。

  盡管有以上限制，基于存儲的容災技術方案仍然是當前最優(yōu)先選擇的容災技術平臺，尤其是基于EMC公司的存儲系統(tǒng)建設容災方案有非常廣泛的應用，這主要是由于基于存儲的容災技術方案有如下優(yōu)點：

• 采用基于存儲的數(shù)據(jù)復制獨立于主機平臺和應用，對各種應用都適用，而且完全不消耗主機的處理資源；

• 基于存儲得數(shù)據(jù)復制技術，由于在最底層，實施起來受應用、主機環(huán)境等相關技術的影響最小，非常適合于這樣主機和業(yè)務系統(tǒng)很多、很復雜的環(huán)境，采用此種方式可以有效降低實施和管理難度；

• 采用同步方式可以完全不丟失數(shù)據(jù)，在同城容災或園區(qū)內容災方案中，只要通信鏈路帶寬許可，完全可以采用同步方案，而不會對主數(shù)據(jù)中心的生產系統(tǒng)性能產生顯著影響。采用EMC基于存儲的同步復制方式的容災案例有很多，有非常多的成功經驗，如江蘇移動、中國光大銀行、遼寧移動、黑龍江移動都采用了EMC同步復制技術，并能滿足大規(guī)模I/O吞吐情況下的同步數(shù)據(jù)復制要求。而目前同城容災環(huán)境中已經具備上述條件，可以很方便部署同步方式復制；

• 采用異步方式雖然存在一定的數(shù)據(jù)丟失的風險，但沒有距離限制，可以實現(xiàn)遠距離保護。異地數(shù)據(jù)中心，則采用與北京兩個中心的異步復制方式進行數(shù)據(jù)保護。

• 災備中心的數(shù)據(jù)可以得到有效利用。

  對于基于應用、基于主機、基于存儲的三種容災方案而言，災備中心的數(shù)據(jù)通常不可用，僅為生產系統(tǒng)中的數(shù)據(jù)提供災難保護和災難恢復。但對采用基于存儲技術的容災方案中，有很靈活的技術手段可以充分利用災備中心的數(shù)據(jù)，從而提高企業(yè)的業(yè)務運營效率，帶來更多的投資回報。如下圖所示：

基于存儲的容災方案有效利用災備數(shù)據(jù)

如上圖所示，生產中心的“源數(shù)據(jù)—R1”通過存儲本身的數(shù)據(jù)復制機制被復制到了災備中心，即“目標數(shù)據(jù)R2”。 “目標數(shù)據(jù)R2”在正常生產情況下是不可訪問的，災備中心的后備主機只能在災難發(fā)生時，主中心服務停止后，才可以訪問“目標數(shù)據(jù)”，接管主中心的服務（基于主機和應用的容災方案的災備中心數(shù)據(jù)與此類似）。但采用基于存儲的容災方案時，我們可以為“目標數(shù)據(jù)”建立一個BCV卷或快照、克隆，從而可以給到另外的服務器使用。

利用這種機制，用戶可以在容災中心做很多工作：

• 用戶開發(fā)測試人員可以利用R2-BCV或R2快照得到真實的數(shù)據(jù)進行新應用開發(fā)、測試工作，從而保證新應用的質量，加快新產品上市時間。這種方式在采用基于主機方案和基于應用方案都很難實現(xiàn)，或在獲得一份真實數(shù)據(jù)進行開發(fā)測試時需要很長的時間，消耗大量的資源。

• 用戶的其它應用也可以利用R2-BCV或R2快照滿足其它業(yè)務的需要。如數(shù)據(jù)倉庫應用通常需要從生產系統(tǒng)抽取數(shù)據(jù)，一旦進行大規(guī)模數(shù)據(jù)抽取，生產系統(tǒng)幾乎處于停頓狀態(tài)，這時可以利用R2-BCV卷進行數(shù)據(jù)抽取，從而避免數(shù)據(jù)抽取給生產系統(tǒng)帶來的巨大性能沖擊。企業(yè)的決策分析系統(tǒng)的數(shù)據(jù)來源也都可以基于R2-BCV來實現(xiàn)。

  由于以上優(yōu)點，基于存儲災難保護方案是目前采用最多的災難保護方案。

   

3.3 采用虛擬化存儲技術建設容災系統(tǒng)

存儲虛擬化的技術方法，是將系統(tǒng)中各種異構的存儲設備映射為一個單一的存儲資源，對用戶完全透明，達到屏蔽存儲設備的異構和主機的異構的目的。通過虛擬化技術，用戶可以利用已有的硬件資源，把SAN內部的各種異構的存儲資源統(tǒng)一成對用戶來說是單一視圖的存儲資源（Storage Pool），而且采用Striping、LUN Masking、Zoning等技術，用戶可以根據(jù)自己的需求對這個大的存儲池進行方便的分割、分配，保護了用戶的已有投資，減少了總體擁有成本（TCO）。另外也可以根據(jù)業(yè)務的需要，實現(xiàn)存儲池對服務器的動態(tài)而透明的增長與縮減。

通過存儲虛擬化技術可實現(xiàn)數(shù)據(jù)的遠程復制，以確保容災中心與主站點的數(shù)據(jù)保持同步以實現(xiàn)數(shù)據(jù)容災。

存儲虛擬化技術可以在不同層面實現(xiàn)，如在智能交換機層面、存儲層面或增加第三方設備來實現(xiàn)。采用虛擬存儲技術進行數(shù)據(jù)復制同樣也可以有同步復制方案和異步復制方案，需要根據(jù)具體的需求選擇合適的產品。

采用虛擬存儲化技術建設容災方案有以下優(yōu)點：

• 主生產中心和容災中心的存儲陣列可以是不同廠家的產品，存儲平臺選擇不受現(xiàn)有存儲平臺廠商的廠商限制（但目前市場上產品還沒有做到這一點）；

• 對不同廠家的存儲陣列提供統(tǒng)一的管理界面；

  在虛擬存儲環(huán)境下，無論后端物理存儲是什么設備，服務器及其應用系統(tǒng)看到的都是其熟悉的存儲設備的邏輯鏡像。即便物理存儲發(fā)生變化，這種邏輯鏡像也永遠不變，系統(tǒng)管理員不必再關心后端存儲，只需專注于管理存儲空間，所有的存儲管理操作，如系統(tǒng)升級、建立和分配虛擬磁盤、改變RAID級別、擴充存儲空間等比從前的任何產品都容易，存儲管理變得輕松簡單。

  采用虛擬存儲化技術建設容災方案需要考慮以下問題：

• 虛擬存儲技術比較新，雖然為異構環(huán)境設計，但在異構環(huán)境種保證兼容性和數(shù)據(jù)的完整性依然存在很大風險；

• 采用虛擬存儲技術，尤其是增加第三方硬件的方式將需要評估對整個系統(tǒng)的高可用性和性能的影響；

• 需要驗證選擇的產品和技術的成熟性以及和現(xiàn)有設備、未來設備的兼容性能力，尤其是難以滿足復雜環(huán)境、大規(guī)模容災要求的實際適用情況；

• 虛擬存儲技術目前尚不夠成熟，還處于發(fā)展階段，而且對于異構存儲環(huán)境部署基于虛擬存儲技術的容災方案，目前還無任何案例和應用；

3.4 采用基于主機的數(shù)據(jù)復制技術建設容災系統(tǒng)

采用基于主機的容災方案的示意圖如下：

基于主機的容災方案示意圖

采用基于主機系統(tǒng)的容災方式的核心是利用主、備中心主機系統(tǒng)通過IP網絡建立數(shù)據(jù)傳輸通道，通過主機數(shù)據(jù)管理軟件實現(xiàn)數(shù)據(jù)的遠程復制，當主數(shù)據(jù)中心的數(shù)據(jù)遭到破壞時，可以隨時從備份中心恢復應用或從備份中心恢復數(shù)據(jù)，從而給企業(yè)提供了應用系統(tǒng)容災的能力。

實現(xiàn)遠程數(shù)據(jù)復制的數(shù)據(jù)管理軟件有很多產品，主機廠商和一些第三方軟件公司(如Veritas)提供基于主機的數(shù)據(jù)復制方案，如Sun公司的Availability Suite軟件和Veritas Volume Replicator(VVR)等軟件可實現(xiàn)基于主機的遠程數(shù)據(jù)復制，從而構建基于主機的容災系統(tǒng)。

采用基于主機的數(shù)據(jù)復制技術建設容災方案有以下優(yōu)點：

• 基于主機的方案最主要的優(yōu)點是只對服務器平臺和主機軟件有要求,完全不依賴于底層存儲平臺，生產數(shù)據(jù)中心和后備數(shù)據(jù)中心可以采用不同的存儲平臺；

• 既有針對數(shù)據(jù)庫的容災保護方案，也有針對文件系統(tǒng)的容災保護方案；

• 有很多不同的基于主機的方案，可以滿足用戶的不同數(shù)據(jù)保護要求，提供多種不同數(shù)據(jù)保護模式；

• 基于IP網絡,沒有距離限制；

   

  同時，采用主機的數(shù)據(jù)復制技術建設容災方案有以下局限：

• 基于主機的方案需要同種主機平臺；

• 基于主機的數(shù)據(jù)復制方案由于生產主機既要處理生產請求，又要處理遠程數(shù)據(jù)復制，必須消耗生產主機的計算資源，對于主機的內存、CPU進行升級是非常昂貴的，因而對生產主機性能產生較大的影響，甚至是產生嚴重影響；

• 災備中心的數(shù)據(jù)一般不可用，如果用戶需要在遠程數(shù)據(jù)中心使用生產數(shù)據(jù)給開發(fā)測試、DW/BI應用使用將非常困難；

• 利用主機數(shù)據(jù)復制軟件的方案比較復雜，尤其是和數(shù)據(jù)庫應用結合的時候需要很復雜的機制或多種軟件的結合，從而對生產系統(tǒng)的穩(wěn)定性、可靠性、性能帶來顯著影響；

• 如果有多個系統(tǒng)、多種應用需要災難保護，采用基于主機的方案將無法有統(tǒng)一的技術方案來實現(xiàn)。

• 管理復雜，需要大量的人工干預過程，容易發(fā)生錯誤。

   

  目前，企業(yè)采用基于主機的數(shù)據(jù)復制技術建設容災方案相對比較少，通常適合單一應用或系統(tǒng)在I/O規(guī)模不大的情況下局部使用。在應用I/O負載比較大，需要災難保護的應用及應用類型比較多、主機環(huán)境復雜的時候，基于主機系統(tǒng)的方案并不適用。

   

3.5 基于應用的數(shù)據(jù)復制建設容災系統(tǒng)

基于應用之間的數(shù)據(jù)復制技術也有很多種，以下按常用的Oracle 9i/10G用自帶的Oracle Data Guard技術來進行分析(Microsoft SQL*Server的Mirror技術采用類似方式)。

Oracle Data Guard技術是Oracle數(shù)據(jù)庫系統(tǒng)特有的災難備份和恢復技術，利用了Oracle數(shù)據(jù)庫系統(tǒng)的日志備份和恢復機制。Data Guard的基本原理是在與主系統(tǒng)完全一致的硬件和操作系統(tǒng)平臺上建立后備數(shù)據(jù)庫系統(tǒng)，同時對主數(shù)據(jù)庫的數(shù)據(jù)庫日志(Log)和控制文件等關鍵文件進行備份。

在主系統(tǒng)正常工作的同時將主系統(tǒng)產生歸檔日志文件(Archived Log)不斷的傳送到后備數(shù)據(jù)庫系統(tǒng)，并且利用這些日志文件在后備數(shù)據(jù)庫系統(tǒng)上連續(xù)進行恢復(Recover)操作，以保持后備系統(tǒng)與運行系統(tǒng)的一致。當主系統(tǒng)發(fā)生故障時，使用備份的數(shù)據(jù)庫日志文件在后備數(shù)據(jù)庫上恢復主數(shù)據(jù)庫內的數(shù)據(jù)。

                                             圖5.18. 采用Oracle Data Guard的容災方案

Oracle9i/10G Data Guard提供了三種模式：

• 最大保護模式

• 最大可用模式

• 最大性能模式

  Oracle Data Guard最大保護模式提供了對于主數(shù)據(jù)庫最高級別的數(shù)據(jù)可用度，是一種保證零數(shù)據(jù)丟失的容災解決方案。當運行最大保護模式時，Redo紀錄以同步的方式從主數(shù)據(jù)庫發(fā)送到后備數(shù)據(jù)庫，而且，在主數(shù)據(jù)庫方的事務，一定要等到至少有一個后備數(shù)據(jù)庫確認接收到事務數(shù)據(jù)，該事務才被提交。在這種模式下，一般配置至少兩個后備數(shù)據(jù)庫，以提供雙重容錯保護。如果后備數(shù)據(jù)庫不可用，則主數(shù)據(jù)庫方會自動掛起處理進程。

  最大可用性模式提供了對于主數(shù)據(jù)庫次高級別的數(shù)據(jù)可用度，保證零數(shù)據(jù)丟失，并對單個組件的失敗提供保護。與最大保護模式一樣，redo數(shù)據(jù)被同步地從主數(shù)據(jù)庫發(fā)送到后備數(shù)據(jù)庫。在主數(shù)據(jù)庫方的事務，一定要等到后備數(shù)據(jù)庫確認接收事務數(shù)據(jù)，該事務才被提交。然而，如果后備數(shù)據(jù)庫因為諸如網絡連接之類的問題而不可用時，主數(shù)據(jù)庫方的處理會繼續(xù)執(zhí)行。這樣，會出現(xiàn)后備數(shù)據(jù)庫暫時與主數(shù)據(jù)庫不一致的情況，但是一旦后備數(shù)據(jù)庫恢復可用，數(shù)據(jù)庫會自動同步，不會有數(shù)據(jù)丟失。

  最大性能模式是缺省的保護模式。與最大可用性模式相比，它對于主數(shù)據(jù)庫提供稍弱一點的保護，但是性能更高。在這種模式下，當主數(shù)據(jù)庫對事務進行處理時，日志數(shù)據(jù)被以異步的方式傳送到后備數(shù)據(jù)庫。在主數(shù)據(jù)庫方，提交操作在完成寫的動作前、無需等待后備數(shù)據(jù)庫的接收確認。在任何時候，如果后備方不可用，主數(shù)據(jù)庫方的處理繼續(xù)執(zhí)行，這樣對性能不會有什么影響。

   

  采用Oracle 9i/10G Data Guard技術進行災難備份需要滿足以下前提條件：

• 后備系統(tǒng)與主系統(tǒng)的硬件平臺、操作系統(tǒng)、操作系統(tǒng)版本等保持一致；

• 后備系統(tǒng)與主系統(tǒng)上Oracle用戶的權限一致；

• 后備系統(tǒng)與主系統(tǒng)的Oracle數(shù)據(jù)庫版本一致；

• 后備系統(tǒng)與主系統(tǒng)的Oracle數(shù)據(jù)庫配置文件一致。

  采用Oracle Data Guard建設容災方案有以下優(yōu)點：

• 完全通過Oracle數(shù)據(jù)庫機制來實現(xiàn)，完全不依賴于其它軟件和底層存儲平臺；

• 可以滿足用戶的不同性能、數(shù)據(jù)保護要求，提供多種不同數(shù)據(jù)保護模式；

• 可以實現(xiàn)一對多的數(shù)據(jù)復制，提供多重保護；

• 后備數(shù)據(jù)庫可以在很短的時間內提升到生產狀態(tài)（因為數(shù)據(jù)庫已經在運行）；

• 基于IP網絡,沒有距離限制；

   

  同時，采用Oracle Data Guard建設容災方案有以下限制：

• Oracle Data Guard的三種模式都將對生產數(shù)據(jù)庫系統(tǒng)的性能產生影響,因而需要更多的處理資源；

• 后備數(shù)據(jù)庫不可用，如果用戶需要在遠程數(shù)據(jù)中心使用生產數(shù)據(jù)給開發(fā)測試、DW/BI應用使用將非常困難；

• 只能對Oracle數(shù)據(jù)庫數(shù)據(jù)提供保護，不能對其它應用數(shù)據(jù)—如文件應用等提供災難保護；

• 管理復雜，需要大量的人工干預過程，并且要精通數(shù)據(jù)庫恢復技術，容易發(fā)生錯誤；

• 難以實現(xiàn)大數(shù)據(jù)量源數(shù)據(jù)庫和目標數(shù)據(jù)庫初次同步，沒有相應解決方案；

業(yè)界其它基于應用的的容災方案的優(yōu)點和局限性與Oracle Data Guard模式基本相同，如Golden Gate和Quest Shareplex軟件，下面也介紹一下：

其實現(xiàn)原理和Oracle DataGuard類似，針對數(shù)據(jù)庫的日志進行數(shù)據(jù)的增量復制，通過Queue技術來保證傳輸?shù)目煽啃?。其方案?yōu)勢是：

• 同Oracle DataGuard相同的缺點（見上面部分）

• 更加靈活，此方案不依賴于主機系統(tǒng)平臺，在主生產主機和備用節(jié)點主機不同的情況更具有優(yōu)勢；

  缺點是：

• 同Oracle DataGuard相同的缺點（見上面部分）

• 只能是異步模式（基于日志和Queue技術），不適合于同城容災和高要求的容災要求，如的零數(shù)據(jù)丟失要求；

• Oracle對此技術方案不宣布技術支持和問題處理，因此提高了此容災方案的風險；

   

3.6 容災方案涉及內容

根據(jù)的現(xiàn)狀評估、需求分析和技術選型的結果，容災技術方案設計將需要包含以下內容：

• 容災總體架構設計

• 存儲級容災數(shù)據(jù)復制方案設計

• 應用級別（或其它方式）的數(shù)據(jù)復制方案設計

• SAN網絡規(guī)劃設計

• IP網絡規(guī)劃設計

• 主機及應用部署方案

• 系統(tǒng)調優(yōu)（根據(jù)需要選擇）

• 數(shù)據(jù)遷移方案

• 存儲部署規(guī)劃

• 備份系統(tǒng)設計（根據(jù)需要）

• 機房設計或機房環(huán)境要求。

• 等等

   

3.7 小結

基于應用的容災方案、基于主機的容災方案和基于存儲(包括虛擬存儲技術)的容災方案都有各自的適用范圍，適用于不同的災難保護需要。用戶需要根據(jù)具體的實際需求來選擇合適的容災保護方案。

不同的用戶不同的業(yè)務系統(tǒng)、不同應用對容災的要求不同，要求不同的容災服務等級。EMC在未來將按照科學流程和方法，并利用EMC公司在信息存儲管理領域的專業(yè)技能和經驗為用戶進行IT環(huán)境的評估和業(yè)務影響分析，發(fā)掘客戶業(yè)務需求對容災技術的要求，從而建議最合適的容災方案。

對企業(yè)而言，選擇容災方案既要考慮選擇合適技術方案，也需要考查實現(xiàn)該方案的產品在技術上是否成熟、可靠，性能和靈活性是否滿足要求，同時也需要考查提供該解決方案的供應商是否有豐富的經驗和認證的技能來保證方案的確實可行并能夠成功實施。

EMC公司在容災領域有領先的技術并已經得到了廣大用戶的實際應用檢驗，方案的可行性、產品的成熟度、穩(wěn)定性、可靠性、靈活性都的到了大量實際應用的考驗。EMC的技術服務隊伍已經在眾多容災項目成功實施過程中表現(xiàn)出強大的技術力量，能夠確保用戶容災方案的成功實施。

第四章 容災通信鏈路設計

容災通信鏈路設計是容災系統(tǒng)建設非常重要的部分，也是容災方案設計的難點、要點之一,所以單列本章節(jié)進行闡述。

4.1 通信鏈路設計概述

下面是針對鏈路設計的相關技術介紹，供參考：

基于主機或基于應用的容災技術來建設容災系統(tǒng)，則將采用標準的IP網絡連接，通信鏈路可以是ATM、E1/E3、IP等；如果采用基于存儲或虛擬存儲的技術來建設容災方案，則可以采用Fibre Channel、ESCON、DWDM、SONET等通信鏈路，也可以通過FCIP設備利用ATM、E1/E3、IP等通信鏈路。

不同的通信鏈路有不同的要求，如距離限制、帶寬能力等；而不同的容災技術、不同的容災應用對通信鏈路的要求不同；采用同步方式或采用異步方式進行數(shù)據(jù)復制對通信鏈路的要求也大不相同。

對于一個容災方案，無論采用哪種復制技術，都需要解決以下問題.

在我當前選擇的容災中心距離的情況下:

• 我需要哪種鏈路? 需要多少條？成本如何？

• 這么遠的距離對應用影響是什么? 如采用同步方式，響應時間是否太長？I/O數(shù)量能否滿足？

• 如采用異步方式，我的RPO是多少？需要配多大的Cache量？

  設計的鏈路是否一定滿足預期的目標？

  根據(jù)用戶的不同要求進行科學的通信鏈路設計是保障用戶在合理的通信成本下成功實現(xiàn)容災系統(tǒng)建設的重要步驟之一。

   

4.2 容災通信鏈路的比較

當前業(yè)界容災方案的通訊鏈路基本采用有“裸光纖直連交換機方式、通過DWDM設備連接裸光纖方式、IP網絡方式”等，每種方式各有利弊，以下對不同通信鏈路方式進行比較。

1. 通過裸光纖直連交換機，采用FC協(xié)議

采用FC協(xié)議的通信鏈路只適用于基于存儲復制或虛擬存儲復制的容災方案。在這類方案中，生產中心與備份中心的光纖交換機通過裸光纖直連，如下圖所示：

裸光纖直連交換機的通信鏈路模式

兩個中心存儲系統(tǒng)的容災端口通過光纖交換機和裸光纖進行連接，可以保證同步或異步數(shù)據(jù)復制的性能。為保證高可用，通常采用冗余連接鏈路設計。容災鏈路裸光纖可以和生產主機共享SAN交換機，也可以獨立SAN交換機（也需要冗余）或SAN Router。通常為避免容災鏈路通信和主機訪問存儲的相互干擾，采用獨立的SAN來連接容災通信鏈路的方式采用較多。

不同容災方案需要的通信鏈路數(shù)量是不同的，具體需要鏈路的條數(shù)（即帶寬要求）需要具體分析、計算獲得。

1. 通過CWDM/DWDM設備直連裸光纖

   采用密集波分復用技術，可以加載多協(xié)議，例如FC協(xié)議、IP協(xié)議，如下圖所示：

采用CWDM/DWDM設備的通信鏈路模式

如上圖所示, 通過CWDM/DWDM技術，主數(shù)據(jù)中心和容災數(shù)據(jù)中心的IP網絡連接、FC連接都可以復用到共享裸光纖，比較好的解決了裸光纖的利用率和多協(xié)議復用的問題。為避免單點故障，同樣可以采用冗余連接、沒有單點故障的解決方案。同時，采用CWDM/DWDM方式有更多的拓撲方案，需要在具體設計時進行分析后確定。

1. 利用IP網絡，采用ATM或E1、E3線路

   采用基于主機和基于應用的容災方案可以直接利用IP網絡，在此不再多加說明。采用“基于存儲或基于虛擬存儲”的容災技術將需要進行FC協(xié)議到IP協(xié)議的轉換，從而將FC加載在IP網絡中傳輸。此方案采用國際流行的IP網絡協(xié)議和鏈路，通過FC/IP轉換設備（例如Nishan），將FC通道協(xié)議打包在IP數(shù)據(jù)包內，通過IP鏈路傳輸，理論上沒有距離的限制，適用于遠程異步數(shù)據(jù)復制，是性價比很好的選擇。連接示意圖如下：

采用FC到IP設備的通信鏈路模式

1. 各種種通信鏈路所提供的帶寬（只供參考）

• T1 - 1.544 megabits per second

• T3 - 43.232 megabits per second (28 T1s)

• OC3 - 155 megabits per second (84 T1s)

• OC12 - 622 megabits per second (4 OC3s)

• OC48 - 2.5 gigabits per seconds (4 OC12s)

• OC192 - 9.6 gigabits per second (4 OC48s)

   

4.3 容災通信鏈路帶寬估算

存儲系統(tǒng)的性能配置要求和通信鏈路帶寬要求需要根據(jù)用戶的數(shù)據(jù)中心的實際情況進行分析計算決定。準確地估算用戶的容災通信鏈路的帶寬要求需要對各中心需要容災保護的應用的I/O負載進行數(shù)據(jù)收集，采集各應用I/O特征、負載大小，尤其是寫I/O的數(shù)據(jù)，利用所收集的寫I/O數(shù)據(jù)并結合所采用的容災數(shù)據(jù)復制技術以及數(shù)據(jù)復制模式（同步、異步）、應用恢復的RTO/RPO要求來計算容災通信鏈路的帶寬要求。

EMC公司提供標準的方法和工具為客戶進行容災數(shù)據(jù)復制通信鏈路的設計，通常按以下步驟來估算容災方案的通信鏈路帶寬需求：

1. 當前生產中心I/O性能數(shù)據(jù)收集

   主要收集需要進行容災保護的應用、主機存儲的I/O性能數(shù)據(jù)。數(shù)據(jù)的收集從兩方面獲得：

• 從主機上獲得I/O性能數(shù)據(jù)（如在UNIX平臺上可利用IOSTAT，SAR可得到I/O性能數(shù)據(jù)；在Windows服務器上可利用Perfmon工具獲得Windows服務器的I/O性能數(shù)據(jù)）；

• 從存儲平臺上獲得I/O性能數(shù)據(jù)，通過存儲平臺的性能采集工具可以獲得訪問存儲的每個LUN上的I/O分布情況，包括I/O特征(EMC提供完整的工具收集存儲平臺的I/O性能信息)。

   

2. 利用EMC設計軟件過濾I/O性能數(shù)據(jù)，得到I/O寫的數(shù)據(jù)

   容災通信鏈路的設計與I/O寫的性能要求相關，只有寫I/O才復制到遠程容災中心，因此寫I/O的特征及負荷決定了鏈路的要求。此過程將過濾無關數(shù)據(jù)（如非關鍵應用的I/O—不需要容災），得到每秒寫I/O次數(shù)，不同應用類型的平均I/O塊大小，是否有調優(yōu)的需要等。下圖是通過EMC工具獲得的寫I/O性能數(shù)據(jù)參考樣本。

I/O寫性能數(shù)據(jù)參考樣本(EMC工具收集)

1. 根據(jù)采集的I/O寫性能數(shù)據(jù)估算客戶應用的總體峰值帶寬和平均帶寬

2. 根據(jù)容災鏈路類型，連接方案估算容災通信的“延時”

   要考慮不同通信協(xié)議的額外開銷以及物理鏈路帶來的“延時”。

3. 估計未來性能增長要求和需要預留的峰值空間

   通信鏈路的設計（包括所有能力規(guī)劃）都需要考慮未來業(yè)務的增長，并預留增長空間。

4. 確定同步復制模式還是異步復制模式，如選擇異步復制模式，則需要確定RPO要求（最多允許丟失多少數(shù)據(jù)）--根據(jù)RPO要求和業(yè)務的I/O量可以設計鏈路需求；也可以根據(jù)現(xiàn)有鏈路情況，結合業(yè)務的I/O量分析可以實現(xiàn)的RPO能力以及在源數(shù)據(jù)端需要為異步復制額外增加的Cache開銷。

5. 利用EMC的專門工具進行設計

   根據(jù)不同復制模式，將收集的I/O性能等參數(shù)輸入到EMC工具中，同時考慮鏈路容余的要求，將可以為客戶計算出所需要的帶寬要求。

   EMC公司未來將采用以上方法為用戶進行容災鏈路設計，該方法已經在很多EMC為重要提供的容災方案中得到應用并獲得成功。利用EMC科學的鏈路設計方法及獨到的設計工具，EMC將能夠為用戶提出合理的鏈路規(guī)劃方案，為成功實施容災方案奠定基礎。

    

4.4 EMC容災數(shù)據(jù)復制方案設計工具簡介

EMC公司根據(jù)已經為廣大高端用戶提供容災建設的經驗，開發(fā)設計了專門的工具—ET Tools，用來做容災數(shù)據(jù)復制方案的設計。該工具利用用戶當前的業(yè)務I/O情況和用戶的服務水平要求可以分析設計復制方案中的關鍵要求：通信鏈路帶寬和復制平臺（如主機或存儲）的處理能力。也可以用來評估用戶在受限的通信條件下所能達到的RPO要求。該工具在未來用作用戶容災技術平臺服務水平的評估工具，可以定期進行I/O性能統(tǒng)計、分析性評估容災數(shù)據(jù)復制平臺是否滿足不斷變化了的業(yè)務發(fā)展要求。