第一章 容災中心建設方法

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

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

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

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

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

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

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

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

第二章 通用容災技術框架

2.1 企業信息系統保護層次

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

不同層次的數據中心保護

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

  企業數據中心面向運營的保護及恢復包括三個層次：

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

2. 數據備份—對業務數據進行經常性的本地備份，在IT系統出現物理故障或邏輯故障時，數據備份都能提供可靠的數據保護。

3. 數據恢復—在出現數據錯誤或丟失時能夠進行快速、可預見的數據恢復，減少IT系統的中斷時間，降低對業務運營的影響。

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

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

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

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

2.2 容災技術模型

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

容災技術模型示意圖

2.2.1 業務平臺的保護——業務處理能力的冗余

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

• 支持應用系統運行的服務器和操作系統等系統軟件

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

• 連接服務器的IP網絡系統

• 支持應用系統實現的中間件或數據庫等

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

• 實現業務邏輯的應用軟件系統

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

2.2.2 數據平臺的保護——業務狀態數據的復制

在容災系統中，對數據平臺的保護主要表現為對業務狀態數據的保護、備份和恢復以及復制，需要保護的業務狀態數據包括：

• 業務交易狀態（數據本身的數據屬性為文件、數據庫等）

• 系統狀態-包括應用軟件的初始數據、參數設置、以及系統軟件的配置數據、參數設置等。

• 中間數據（或臨時數據）

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

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

2.2.3 接入平臺冗余和切換

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

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

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

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

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

2.3 容災模式

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

2.3.1 容災層次

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

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

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

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

• 業務恢復難度大，需要新增設備

• 實現技術難度比較低

• 運行維護成本較低

• 投資比較節省

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

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

• 業務恢復過程相對簡單

• 實現技術難度比較高

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

• 投資比較高

2.3.2 容災范圍

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

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

• 全業務容災。

2.3.3 同級容災或降級容災

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

第三章 不同容災技術介紹

3.1 不同容災技術方案概述

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

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

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

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

• 同類存儲平臺之間的數據復制；

• 異構存儲平臺之間利用虛擬存儲技術實現數據復制。

• 基于主機層面的容災方案—利用主機廠家提供的相關功能軟件或第三方的主機軟件實現遠程的數據復制，建設容災系統。

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

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

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

   

3.2 基于存儲的數據復制技術建設容災系統

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

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

基于存儲數據復制技術的容災方案示意圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 災備中心的數據可以得到有效利用。

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

基于存儲的容災方案有效利用災備數據

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

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

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

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

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

   

3.3 采用虛擬化存儲技術建設容災系統

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

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

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

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

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

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

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

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

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

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

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

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

3.4 采用基于主機的數據復制技術建設容災系統

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

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

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

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

采用基于主機的數據復制技術建設容災方案有以下優點：

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

• 既有針對數據庫的容災保護方案，也有針對文件系統的容災保護方案；

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

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

   

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

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

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

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

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

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

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

   

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

   

3.5 基于應用的數據復制建設容災系統

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

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

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

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

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

• 最大保護模式

• 最大可用模式

• 最大性能模式

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

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

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

   

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

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

• 后備系統與主系統上Oracle用戶的權限一致；

• 后備系統與主系統的Oracle數據庫版本一致；

• 后備系統與主系統的Oracle數據庫配置文件一致。

  采用Oracle Data Guard建設容災方案有以下優點：

• 完全通過Oracle數據庫機制來實現，完全不依賴于其它軟件和底層存儲平臺；

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

• 可以實現一對多的數據復制，提供多重保護；

• 后備數據庫可以在很短的時間內提升到生產狀態（因為數據庫已經在運行）；

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

   

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

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

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

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

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

• 難以實現大數據量源數據庫和目標數據庫初次同步，沒有相應解決方案；

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

其實現原理和Oracle DataGuard類似，針對數據庫的日志進行數據的增量復制，通過Queue技術來保證傳輸的可靠性。其方案優勢是：

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

• 更加靈活，此方案不依賴于主機系統平臺，在主生產主機和備用節點主機不同的情況更具有優勢；

  缺點是：

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

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

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

   

3.6 容災方案涉及內容

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

• 容災總體架構設計

• 存儲級容災數據復制方案設計

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

• SAN網絡規劃設計

• IP網絡規劃設計

• 主機及應用部署方案

• 系統調優（根據需要選擇）

• 數據遷移方案

• 存儲部署規劃

• 備份系統設計（根據需要）

• 機房設計或機房環境要求。

• 等等

   

3.7 小結

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

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

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

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

第四章 容災通信鏈路設計

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

4.1 通信鏈路設計概述

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

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

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

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

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

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

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

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

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

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

   

4.2 容災通信鏈路的比較

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

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

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

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

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

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

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

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

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

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

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

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

采用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 容災通信鏈路帶寬估算

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

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

1. 當前生產中心I/O性能數據收集

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

    

4.4 EMC容災數據復制方案設計工具簡介

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