“兩地三中心”和“雙活”簡介--容災技術方案

---

---

當前 市場上常見的 容災 模式可分為同城容災、異地容災、 雙活 資料中心、 兩地 三中心幾種。

1、 同城 容災

同城 容災 是在同城或相近區域內 （ ≤ 200K M ）建立兩個資料中心 : 一個為資料中心，負責日常生產執行 ; 另一個為災難備份中心，負責在災難發生後的應用系統執行。同城災難備份的資料中心與災難備份中心的距離比較近，通訊線路質量較好，比較容易實現資料的同步 複製 ，保證高度的資料完整性和資料零丟失。同城災難備份一般用於防範火災、建築物破壞、供電故障、計算機系統及人為破壞引起的災難。

2、 異地 容災

異地 容災 主備中心之間的距離較遠 （＞ 200KM ) ， 因此一般採用非同步映象，會有少量的資料丟失。異地災難備份不僅可以防範火災、建築物破壞等可能遇到的風險隱患，還能夠防範戰爭、地震、水災等風險。由於同城災難備份和異地災難備份各有所長，為達到最理想的防災效果，資料中心應考慮採用同城和異地各建立一個災難備份中心的方式解決。

本地容災 是指在本地機房建立容災系統，日常情況下可同時分擔業務及管理系統的執行，並可切換執行；災難情況下可在基本不丟失資料的情況下進行災備應急切換，保持業務連續執行。與異地災備模式相比較，本地雙中心具有投資成本低、建設速度快、運維管理相對簡單、可靠性更高等優點；異地災備中心是指在異地建立一個備份的災備中心，用於雙中心的資料備份，當雙中心出現自然災害等原因而發生故障時，異地災備中心可以用備份資料進行業務的恢復。

本地機房的容災主要是用於防範生產伺服器發生的故障，異地災備中心用於防範大規模區域性災難。本地機房的容災由於其與生產中心處於同一個機房，可透過區域網進行連線，因此資料複製和應用切換比較容易實現，可實現生產與災備伺服器之間資料的實時複製和應用的快速切換。異地災備中心由於其與生產中心不在同一機房，災備端與生產端連線的網路線路頻寬和質量存在一定的限制，應用系統的切換也需要一定的時間，因此異地災備中心可以實現在業務限定的時間內進行恢復和可容忍丟失範圍內的資料恢復。

3、 兩地 三中心

結合近年國內出現的大範圍自然災害，以同城雙中心加異地災備中心的 “兩地三中心”的災備模式也隨之出現，這一方案兼具高可用性和災難備份的能力。

同城雙中心 是指在同城或鄰近城市建立兩個可獨立承擔關鍵系統執行的資料中心，雙中心具備基本等同的業務處理能力並透過高速鏈路實時同步資料，日常情況下可同時分擔業務及管理系統的執行，並可切換執行；災難情況下可在基本不丟失資料的情況下進行災備應急切換，保持業務連續執行。與異地災備模式相比較，同城雙中心具有投資成本低、建設速度快、運維管理相對簡單、可靠性更高等優點。

異地災備中心 是指在異地的城市建立一個備份的災備中心，用於雙中心的資料備份，當雙中心出現自然災害等原因而發生故障時，異地災備中心可以用備份資料進行業務的恢復。

兩地三中心 ： 是指 同城雙中心 加 異地災備 一種商用容災備份解決方案；

兩地 是指同城、異地；

三中心 是指生產中心、同城容災中心、異地容災中心。（ 生產中心、同城災備中心、異地 災備 中心 ）

4、 雙活 資料中心

所謂 “ 雙活 ” 或 “ 多 活 ” 資料中心，區別於 傳統 資料中心 和 災備中心的模式，前者 多個 或兩個資料中心都處於執行當中， 執行相同的應用，具備同樣的資料，能夠提供跨中心業務負載均衡執行能力，實現持續的應用可用性和災難備份能力， 所以稱為 “雙活 ” 和 “ 多 活 ” ；後者是 生產 資料中心投入執行， 災備 資料中心處在不工作狀態，只有當災難發生時，生產資料中心癱瘓，災備中心才啟動。

“ 雙活 ” 資料中心最大的特點是 ： 一、充分利用資源，避免了一個資料中心常年處於閒置狀態而造成浪費 ， 透過資源整合， “ 雙活 ” 資料中心的服務能力是 翻 倍的 ；   二 、 “ 雙活 ” 資料中心如果斷了一個資料中心， 其 業務可以 迅速 切換到另外一個 正在 執行的資料中心， 切換 過程對使用者來說是不可感知的。

在 “ 雙活 ” 的模式中，兩地資料中心同時接納交易，技術難度很大，需要更改眾多底層程式 ， 因而在現實中，國內還沒有 真正 “ 雙活 ” 資料中心 的成功 應用 案例。

資料容災技術選擇度量標準

在構建 容災 系統時，首先考慮的是結合實際情況選擇合理的資料複製技術。 在 選擇合理的資料複製技術時主要考慮以下因素：

Ø  災難承受程度 ：明確計算機系統需要承受的災難型別，系統故障、通訊故障、長時間斷電、火災及地震等各種意外情況所採取的備份、保護方案不盡相同。

Ø  業務影響程度 ：必須明確當計算機系統發生意外無法工作時，導致業務停頓所造成的損失程度，也就是定義使用者對於計算機系統發生故障的最大容忍時間。這是設計備份方案的重要技術指標。

Ø  資料保護程度 ：是否要求資料庫恢復所有提交的交易 ， 並且要求實時同步 ，保證 資料的連續性和一致性， 這是 備份方案複雜程度的重要依據。

 對IT企業來說，傳統的單資料中心，已不足以保護企業資料的安全。當單資料中心儲存故障後，可能會導致業務長時間中斷，甚至資料丟失。只做本地的資料冗餘保護或容災建設，已不能規避區域性災難對企業資料的破壞。遠端容災保護資料及保障企業業務連續性成為了企業亟待解決的問題。另外，企業在遠端容災建設中，也面臨網路鏈路租賃費用高昂和網路頻寬不夠的問題。

 

2.“兩地三中心”的架構實踐

（1）華為的“基於華為統一儲存多級跳複製技術的兩地三中心方案”

         基於華為統一儲存多級跳複製技術，並結合專業的容災管理軟體實現資料的兩地三中心保護。該方案在生產中心、同城災備中心和異地災備中心分別部署華為OceanStor統一儲存裝置，透過非同步遠端複製技術，將生產中的資料複製到同城災備中心，再到異地災備中心，實現資料的保護，方案原理組網如圖（1）所示。若生產中心發生災難，可在同城災備中心實現業務切換，並保持與異地災備中心的容災關係；若生產中心和同城災備中心均發生災難，可在異地災備中心實現業務切換。

（2）中興通訊的“基於雲端計算IaaS和PaaS層面的雲端計算技術，推出分散式雙活資料中心”

         中興的分散式雙活資料中心的建設和部署架構如下圖所示，在同城建設兩個資料中心，同時為外提供業務服務，同時在異地建設災備中心，用於資料的備份。中興通訊分散式雙活資料中心方案可以幫助客戶找到最佳化投資利用率、保證業務連續性的新思路。

---

---

資料庫容災-沒有最好，只有最適合

繼911之後，四川大地震又一次給資料中心工作者上了一堂鮮活的安全教育課，眼睜睜看著一些企業由於關鍵業務資料遭到破壞導致整個企業的破產，也許這個時候那些平日一直認為IT是隻花錢不賺錢的CXO們才能深刻感覺到資料是企業生命的真諦所在。“容災”-這幾年一直是IT廠商在炒作的熱門概念，似乎每個人都想在這塊大蛋糕上分享一塊。隨之而來的是花樣繁多的容災解決方案，儲存廠商、主機廠商、虛擬帶庫廠商、資料庫複製廠商、資料庫廠商紛紛踏入這片熱門地帶。軟體容災、硬體容災、資料級容災、應用級容災、低成本、異構性、高可擴充套件性。。。，看起來似乎每個方案都有自己獨有的優勢，每個廠商都可以找出充分的論據來證明為什麼自己的解決方案是最適合的，使用者的大腦也很容易在撲面而來的洗腦風暴中失去判斷力，最能忽悠的往往成為最終的勝利者。

如何為企業選擇一個最優的容災解決方案？投資最多的方案就是最安全、最滿足實際需求的嗎？顯然答案是否定，應該說容災方案沒有最好，只有最適合。選擇方案時需要考慮多方面因素：投資、複雜度、可行性、可管理性、可擴充套件性、RPO、RTO。。。下面就對幾種主流的資料庫容災方案進行分析，希望能在容災方案選型階段給大家一點思路。

        基於儲存的複製方案

        典型代表：EMC SRDF ，HDS Truecopy，IBM PPRC，任何資料中心的建立都離不開磁碟陣列，所以這些廠商也就有機會在第一時間給客戶灌輸自己基於陣列的容災方案，在市場上的聲音也是最大的。但他們在設計方案的時候往往更多地考慮如何讓使用者多買陣列，而不是將舊陣列加以重用。

        方案優勢：同步非同步方式可供選擇，資料同步過程不佔用主機資源，頻寬利用率高。

        方案限制：生產中心與災備中心必須選擇同品牌同級別的盤陣，也就是要綁死一家廠商，商務上很容易處於被動狀態，拿不到好折扣，將來的擴容也沒有其他選擇。資料同步過程中災備中心處於standby狀態，不能進行任何讀寫操作，即使使用高階盤陣也只能在災難發生時才能發揮體會到其優越的處理能力，造成資源浪費。需要建立光纖網作為複製鏈路，又是一筆不小的費用。在儲存級定製複製策略，無法在作業系統級控制和分辨復制內容，不管是資料庫還是普通檔案統統進行全盤複製，而無法進行應用區分，即使是一些不需要複製的檔案也不能進行篩選，浪費頻寬、浪費儲存。    

基於卷的複製技術

        典型代表：Veritas Volume Replicator

        方案優勢：IP網作為複製鏈路，成本低，不受距離限制，以卷作為複製物件，可以實現資料庫和普通檔案的容災，支援異構儲存。

        方案限制：需要複製的資料庫和檔案必須建立在Veritas Volume Manager之上，即使是已經上線的系統也必須要進行資料的遷移，可實施性差，相信沒有人可以接受一個7x24執行的生產系統進行線上儲存格式轉換。複製過程在主機作業系統級實現，佔用作業系統資源而且是不小的比例。為保證資料一致性，需要在生產中心維護複製log，發生的每一個I/O操作都要寫複製一致性需要的log，所以很容易造成I/O效能瓶頸。如果出現線路故障導致堆積的log堆積過多出現空間溢位，生產中心和災備中心只能進行完全同步。複製過程中災備中心的資料庫處於standy狀態，不能進行任何讀寫，造成資源浪費。

        基於資料庫的複製

        典型代表：Oracle Data Guard。在人們印象中要提到Oracle Data Guard，首先會想到Oracle免費提供的物理備用資料庫功能，透過傳輸和恢復Redo log實現資料庫的同步，同步過程中備用資料庫完全處於standby狀態，不能進行任何讀寫訪問。在這裡我更想多說一下Oracle在11g企業版裡推出的Active Data Guard ，為什麼要強調active呢？一句話解釋就是在同步複製過程中備用資料庫一直處於active狀態，使用者可以在備用資料庫上進行查詢、報表等操作。同時資料同步的效率更高、對硬體的資源要求更低，這樣可以更大程度地發揮物理備用資料庫的硬體資源的利用率。Active Data Guard不單可以資料庫的容災目的，還可以將一些原本執行於主資料庫的分析、統計、報表、備份、測試等應用遷移到備用資料庫，從而降低主庫的負載，變相提高了生產環境的處理能力和服務質量，

        方案優勢：災備端處於Active狀態，可程式正常的查詢操作，提高硬體利用率。透過IP網實現資料複製，成本低，傳輸資料量小，頻寬佔用低。與資料庫整合在一起，管理簡單，資料庫一致性得到很好保證，支援異構儲存，距離不受限制。如果資料中心完全為Oracle環境，本人力推Active Data Guard作為資料庫容災方案的首選！低成本、易管理、高效率，其他方案只能望其項背。

        方案限制：只能進行Oracle的複製，對於其他資料庫無能為力，對Oracle資料庫的版本有要求。

        第三方資料庫複製技術：

        典型代表：Quest Shareplex

        方案優勢：IP網作為複製鏈路，成本低，支援異構儲存，生產中心和災備中心雙活，資源利用率高，針對不同資料庫型別有相應複製方案。

        方案限制：以Shareplex基於Oracle的資料複製為例，Shareplex透過Oracle Redo log複製技術實現資料同步，但是Quest用到的Redo log解析方法不在Oracle官方認證和支援範圍內，可以說是一種後門技術，隨時可能出現安全隱患，另外Redo log的解析和恢復演算法效率較低，會導致資料複製過程中主庫的資源佔用過高，備庫也一直處於繁忙的運算狀態。如果主庫的增刪改操作頻繁，一旦出現資料鏈路中斷等問題，備用資料庫與主庫的時間差會越來越大，最終導致複製失敗。

        上面簡單分析了一下市場上常見的幾種型別資料庫容災解決方案，當然還有一些其他的方案提供商，如Falcon、GoldenGate、Netapp等。到底選擇哪一方案，依然那句話：沒有最好、只有最適合，把握資料庫容災的基本原則：省錢、實用、簡單、高效！

---

---

1. 的核心技術及選擇

容災系統是指在相隔較遠的異地，建立兩套或多套功能相同的 IT 系統，互相之間可以進行健康狀態監視和功能切換，當一處系統因意外 ( 如火災、地震等 ) 停止工作時，整個應用系統可以切換到另一處，使得該系統功能可以繼續正常工作。容災技術是系統的高可用性技術的一個組成部分，容災系統更加強調處理外界環境對系統的影響，特別是災難性事件對整個 IT 節點的影響，提供節點級別的系統恢復功能。

1.1. 衡量指標

衡量容災系統的主要指標有 RPO （ Recovery Point Object ，災難發生時允許丟失的資料量）、 RTO （ Recovery Time Objective ，系統恢復的時間）、容災半徑（生產系統和容災系統之間的距離）以及 ROI(Return of Investment ，容災系統的投入產出比 ) 。

RPO 是指業務系統所允許的災難過程中的最大資料丟失量（以時間來度量），這是一個災備系統所選用的資料複製技術有密切關係的指標，用以衡量災備方案的資料冗餘備份能力。

RTO 是指“將資訊系統從災難造成的故障或癱瘓狀態恢復到可正常執行狀態，並將其支援的業務功能從災難造成的不正常狀態恢復到可接受狀態”所需時間，其中包括備份資料恢復到可用狀態所需時間、應用系統切換時間、以及備用網路切換時間等，該指標用以衡量容災方案的業務恢復能力。例如，災難發生後半天內便需要恢復，則 RTO 值就是十二小時。

容災半徑是指生產中心和災備中心之間的直線距離，用以衡量容災方案所能防禦的災難影響範圍。

容災方案的 ROI 也是使用者需要重點關注的，它用以衡量使用者投入到容災系統的資金與從中所獲得的收益的比率。

顯然，具有零 RTO 、零 RPO 和大容災半徑的災難恢復方案是使用者最期望的，但受系統效能要求、適用技術及成本等方面的約束，這種方案實際上是不大可行的。所以，使用者在選擇容災方案時應該綜合考慮災難的發生機率、災難對資料的破壞力、資料所支撐業務的重要性、適用的技術措施及自身所能承受的成本等多種因素，理性地作出選擇。

1.2. 級別

按照容災系統對應用系統的保護程度可以分為資料級容災 、 應用級容災 和 業務級容災。

資料級容災 僅 將生產中心的資料複製到容災中心，在生產中心出現故障時，僅能實現 儲存 系統的接管或是資料的恢復 。容災 中心的資料可以是本地生產資料的完全複製（ 一般 在同城實現） ， 也可以比生產資料略微落後，但必定是可用的 （一般 在異地實現） ， 而差異的資料 通常 可以透過一些工具（ 如 操作記錄、日誌等） 可以 手工補回。基於資料容災 實現 業務恢復的速度 較慢 ，通常情況下 RTO 超過 24 小時， 但是這種 級別 的容災系統執行維護成本較低。

應用級容災是 在資料級容災的基礎上，進一步實現應用 可用性 ，確保業務的快速恢復。這就 要求 容災系統 的 應用不能改變原有業務處理邏輯，是對生產中心繫統的基本複製 。因此 ，容災中心需要建立起一套和本地生產相當的備份環境，包括主機、網路、應用、 IP 等 資源均有配套，當 生產 系統發生災難時，異地系統可以 提供 完全可用的生產環境。 應用級 容災的 RTO 通常 在 12 個 小時 以內 ，技術複雜度較高，執行維護的成本也比較高。

業務級 容災 是生產中心 與容災中心對業務請求同時進行 處理 的容災方式，能夠確保 業務 持續可用。這種 方式 業務 恢復 過程的自動化程度高， RTO 可以 做到 30 分鐘 以內 。 但是 這種容災級別 的 專案 實施難度大， 需要從 應用層對系統進行改造，比較適合流程固定 的 簡單業務系統 。 這種 容災系統 的執行維護成本最高。

1.3. 容災建設模式

當前 ，市場上常見的 容災 模式可分為同城容災、異地容災、 雙活 資料中心、 兩地 三中心幾種。

1.3.1. 容災

同城 容災 是在同城或相近區域內 （ ≤ 200K M ）建立兩個資料中心 : 一個為資料中心，負責日常生產執行 ; 另一個為災難備份中心，負責在災難發生後的應用系統執行。同城災難備份的資料中心與災難備份中心的距離比較近，通訊線路質量較好，比較容易實現資料的同步 複製 ，保證高度的資料完整性和資料零丟失。同城災難備份一般用於防範火災、建築物破壞、供電故障、計算機系統及人為破壞引起的災難。

1.3.2. 容災

異地 容災 主備中心之間的距離較遠 （＞ 200KM ) ， 因此一般採用非同步映象，會有少量的資料丟失。異地災難備份不僅可以防範火災、建築物破壞等可能遇到的風險隱患，還能夠防範戰爭、地震、水災等風險。由於同城災難備份和異地災難備份各有所長，為達到最理想的防災效果，資料中心應考慮採用同城和異地各建立一個災難備份中心的方式解決。

1.3.3. 三中心

結合近年國內出現的大範圍自然災害，以同城雙中心加異地災備中心的 “兩地三中心”的災備模式也隨之出現，這一方案兼具高可用性和災難備份的能力。

同城雙中心是指在同城或鄰近城市建立兩個可獨立承擔關鍵系統執行的資料中心，雙中心具備基本等同的業務處理能力並透過高速鏈路實時同步資料，日常情況下可同時分擔業務及管理系統的執行，並可切換執行；災難情況下可在基本不丟失資料的情況下進行災備應急切換，保持業務連續執行。

異地災備中心是指在異地的城市建立一個備份的災備中心，用於雙中心的資料備份，當雙中心出現自然災害等原因而發生故障時，異地災備中心可以用備份資料進行業務的恢復。

1.3.4. 資料中心

所謂 “ 雙活 ” 或 “ 多 活 ” 資料中心，區別於 傳統 資料中心 和 災備中心的模式，前者 多個 或兩個資料中心都處於執行當中， 執行相同的應用，具備同樣的資料，能夠提供跨中心業務負載均衡執行能力，實現持續的應用可用性和災難備份能力， 所以稱為 “雙活 ” 和 “ 多 活 ” ；後者是 生產 資料中心投入執行， 災備 資料中心處在不工作狀態，只有當災難發生時，生產資料中心癱瘓，災備中心才啟動。

“ 雙活 ” 資料中心最大的特點是 ： 一、充分利用資源，避免了一個資料中心常年處於閒置狀態而造成浪費 ， 透過資源整合， “ 雙活 ” 資料中心的服務能力是 翻 倍的 ；   二 、 “ 雙活 ” 資料中心如果斷了一個資料中心， 其 業務可以 迅速 切換到另外一個 正在 執行的資料中心， 切換 過程對使用者來說是不可感知的。

在 “ 雙活 ” 的模式中，兩地資料中心同時接納交易，技術難度很大，需要更改眾多底層程式 ， 因而在現實中，國內還沒有 真正 “ 雙活 ” 資料中心 的成功 應用 案例。

1.4. 的資料複製技術

在構建容災系統所涉及的諸多要素中，資料複製 技術 是基礎，只有保證了資料的安全可用，應用 或是 業務的恢復才有可能。 正常情況下系統的各種應用在資料中心執行，資料存放在資料中心和災難備份中心兩地儲存。當災難發生時，使用備份資料對工作系統進行恢復或將應用切換到備份中心。

資料 複製技術的選擇決定災備系統的 RPO 指標 ，災難備份系統中資料備份技術的選擇應符合資料恢復時間或系統切換時間滿足業務連續性的要求。

資料複製（ Replication ）是指利用複製軟體把資料從一個磁碟複製到另一個磁碟，生成一個資料副本。這個資料副本是資料處理系統直接可以訪問的，不需要進行任何的資料恢復操作，這一點是複製與 D2D 備份的最大區別。

根據不同容災方案所採用資料複製技術位於企業 IT 架構不同層面，資料複製可分為基於儲存層的複製、基於主機層複製和 基於應用的複製 。

具體 到一個 I/O 從 磁碟到應用的流程上，可能經由 磁碟陣列 、儲存網路、卷管理軟體、檔案系統、 資料 庫系統和應用系統 全部 流程或是其中的幾個流程， 那麼 資料複製就可以在這些 流程 的任一層次上實現，如下圖所示：

 

基於儲存層的複製可以是由儲存裝置的控制器執行，也可以是由網路 層的 虛擬化儲存管理平臺來執行，基於儲存層的複製基於 主機和應用的無關性，相容性要求最低， 實施 難度最小，但是由於是卷級別的資料複製，對網路頻寬要求最高； 基於主機的複製可以 由安裝在主機上的卷管理軟體或是檔案系統來實現，在實際的應用場景中，以基於卷管理軟體的資料複製技術居多， 這種 方式通常要求主機平臺相關，實施難度 升高 ，但是頻寬要求降低； 基於資料 層的複製透過 資料庫 的容災功能模組來實現， 對 網路頻寬要求最低，但是 只能 實現資料庫資料 的 容災；基於應用層的資料複製 需要 對應用程式進行定製開發，現實場景中很難見到。

下面就重點 介紹一下 幾種 常見的資料複製技術。

1.4.1.  

1.4.1.1. 基於儲存 裝置的資料複製

基於儲存裝置的資料 複製 技術的核心是利用儲存陣列自身的盤陣對盤陣的資料塊複製技術實現對生產資料的遠端複製，從而實現生產資料的災難保護。在主資料中心發生災難時，可以直接利用災備中心的資料建立運營支撐環境，為業務繼續運營提供 IT 支援。同時，也可以利用災備中心的資料恢復主資料中心的業務系統，從而能夠讓企業的業務運營快速回復到災難發生前的正常運營狀態。

基於儲存裝置 的資料複製技術 示意圖如下：

 

基於儲存裝置的複製可以是如上示意圖的 “一對一”複製方式，也可以是“一對多或多對一”的複製方式，即一個儲存的資料複製到多個遠端儲存或多個儲存的資料複製到同一遠端儲存；而且複製可以是雙向的。

基於儲存的資料 複製技術 有兩種方式：同步方式和非同步方式。

同步方式：可以做到主 / 備資料中心磁碟陣列同步地進行資料更新，應用系統的 I/O 寫入主磁碟陣列後 ( 寫入 Cache 中 ) ，主磁碟陣列將利用自身的機制同時將寫 I/O 寫入後備磁碟陣列，後備磁碟陣列確認後，主中心磁碟陣列才返回應用的寫操作完成資訊。  

非同步方式：是在應用系統的 I/O 寫入主磁碟陣列後 ( 寫入 Cache 中 ) ，主磁碟陣列立即返回給主機應用系統“寫完成”資訊，主機應用可以繼續進行寫 I/O 操作。同時，主中心磁碟陣列將利用自身的機制將寫 I/O 寫入後備磁碟陣列，實現資料保護。

採用同步方式，使得後備磁碟陣列中的資料總是與生產系統資料同步，因此當生產資料中心發生災難事件時，不會造成資料丟失，可以 實現 RPO 為零。為避免對生產系統效能的影響，同步方式通常在近距離範圍內（ FC 連線通常是 200KM 範圍內，實際使用者部署多在 35KM 之內）。

而採用非同步方式應用程式不必等待遠端更新的完成，因此遠端備份 儲存裝置 的效能的影響通常較小，並且生產中心的距離和災備 中心 的距離理論上沒有限制（通常基於 IP 連線來實現資料的非同步複製）。

採用基於儲存裝置 資料 複製技術構建容災方案的必要前提是：

Ø  通常必須採用同一廠家統一 系列的 且同時 具有資料複製技術的高階 儲存平臺，給使用者的儲存平臺選擇帶來一定的限制。

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

Ø  採用非同步方式與其他種類的非同步容災方案一樣，存在資料丟失的風險 , 通常在遠距離通訊鏈路頻寬有限的情況下實施。

儘管有以上限制，基於儲存裝置 的資料複製技術 仍然是當前選擇較多的容災技術平臺，這主要是由於基於儲存的複製技術方案有如下優點：

Ø  採用基於儲存的資料複製獨立於主機平臺和應用，對各種應用都適用，而且完全不消耗主機的處理資源；

Ø  基於儲存得資料複製技術，由於在最底層，實施起來受應用、主機環境等相關技術的影響最小，非常適合於主機和業務系統很多、很複雜的環境，採用此種方式可以有效降低實施和管理難度；

Ø  採用同步方式可以完全不丟失資料，在同城容災或園區內容災方案中，只要通訊鏈路頻寬許可，完全可以採用同步方案，而不會對主資料中心的生產系統效能產生顯著影響；

Ø  採用非同步方式雖然存在一定的資料丟失的風險，但沒有距離限制，可以實現遠距離保護；

Ø  災備中心的資料可以得到一定 程度上的 有效利用（用作 測試或 報表 等） 。

構建 成本 ：

儲存層容災產品報價，都是採用磁碟陣列的高階功能許可授權方式進行報價。並按照磁碟陣列的具體數量進行報價。越是高階盤陣，高階功能模組授權價格成階梯式增長。

除了這些高階功能授權的許可外，其還有 MA （維護）費用以及實施費用， MA 費用整體磁碟陣列報價（含高階功能模組）的 25% 左右。

實施費用一般按人天費用方式進行計算，總體成本很高。

另外，其對頻寬要求很高，容災網路建設費用更高。

適用 場景 ：

儲存裝置 複製技術 利用磁碟陣列自身卷複製功能實現，首先要求必須是同構高階儲存系統，其次對頻寬要求較高，實現的是底層資料塊級別的複製，屬於資料層容災範疇。

這類容災產品由於其自身的功能特性，作為高階盤陣衍生出來的附加高階功能來實現容災，其投資巨大，從盤陣本身到鏈路的要求都極高，需要專門的鏈路確保資料的一致性。當災難 發生時，需要透過 人工調整的方式，將映象卷提供給遠端生產業務系統，實現業務系統的容災， RTO 在 數小時以上。

經過 以上分析可以看出，基於 儲存層 的災備方案對 儲存 平臺要求 非常 嚴格， 適合用於為底層 儲存平臺單一、伺服器平臺 構成 複雜、上層應用 繁多 的 IT 系統構建資料級 的容災方案 ，不 適合 於複雜 、 異構 儲存平臺 的 容災場景 需求 。

1.4.1.2. 基於 虛擬化 儲存技術 的 資料複製

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

透過儲存虛擬化技術可以實現資料的遠端複製，這種 資料複製技術原理和基於儲存裝置的 原理 基本一樣，唯一的區別就是前者由儲存虛擬化控制器實現，或者由磁碟陣列控制器實現 ， 所以這種技術不要求底層磁碟陣列同構。 儲存虛擬化技術通常 在 儲存 網路 層面實現， 其 資料複製同樣也可以有同步複製方案和非同步複製方案，需要根據具體的需求選擇合適的技術。

 

基於 儲存虛擬化控制器的 兩地三中心容災方案架構

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

Ø  主生產中心和容災中心的儲存陣列可以是不同廠家的產品，儲存平臺選擇不受現有儲存平臺廠商的限制；

Ø  對不同廠家的儲存陣列提供統一的管理介面。

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

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

Ø  需要驗證選擇的產品和技術的成熟性以及和現有裝置、未來裝置的相容效能力；

Ø  儲存 虛擬化控制器作為一種帶內接管方式， 儲存 系統的效能直接和儲存虛擬化控制器相關，在 高 I/O 負載 應用場景下，需要考慮儲存虛擬化控制器的效能瓶頸問題 。

虛擬化技術 即繼承了基於儲存裝置實現資料複製方案的優點，同時又能 相容 異構儲存系統， 並且 切換過程 比較 簡單，甚至可以實現自動切換，成為越來越多 容災 使用者的選擇。

構建 成本 ：

儲存網路層產品報價，一般採用虛擬化閘道器的數量和容量結合起來的報價方式，儲存閘道器數量的多少和虛擬化儲存容量的多少都直接影響整個報價。

除此之外還有 MA 費用和實施費用， MA 費用整體價格的 25% 左右。

實施費用一般按人天費用方式進行計算，總體成本較高。

另外，其對頻寬要求比較高，容災網路建設費用比較高。

適用場景 ：

儲存網路層容災產品，利用了儲存虛擬化技術，將後臺儲存進行統一池化的方式進行管理。利用其映象和複製技術，實現池化後資料塊的映象和複製，保證資料的一致性。從實現方式上面來講，屬於資料層容災範疇。

其有兩種實現方式：

一種是映象的方式，透過映象技術實現資料塊的完全同步，這種採用的是同步方式，對頻寬要求極高。

另外一種複製的方式，採用虛擬化閘道器機頭之間的資料複製實現，它可以採用同步方式也可以採用非同步的方式，往往受限於頻寬的限制，這種複製方式往往採用非同步的方式進行復制。

不管採用哪種方式進行資料的一致性保證，資料卷都存在主備關係，遠端資料卷不能被前端業務系統進行訪問，當災難發生時，透過自動 切換 人工調整的方式，將遠端卷提供給遠端業務系統，實現業務系統的容災。

這類產品採用的都是帶內虛擬化方式，很好的解決了異構儲存容災問題，但是其資料流都要經過虛擬化閘道器，前端業務系統效能會有所下降，其吞吐能力受到限制。

綜合這類產品的特性，其適合用於為 擁有較多型號的 異構 磁碟陣列 並 承擔多 個 應用的 現有 IT 系統構建容災 平臺方案。

1.4.2. 主機資料複製技術 的 災備方案

採用基於主機複製 技術 的容災方案的示意圖如下：

 

圖1-1.  基於主機的容災方案示意圖

採用基於主機系統的資料 複製技術 的核心是利用主、備中心主機系統透過 IP 網路建立資料傳輸通道，透過主機資料管理軟體實現資料的遠端複製，當主資料中心的資料遭到破壞時，可以隨時從備份中心恢復應用或從備份中心恢復資料，從而給企業提供了應用系統容災的能力。

實現主機 層 資料複製的資料管理軟體有很多產品，如 Symantec 公司 的 Veritas Volume Replicator ( VVR ) 以及 Rose HA 公司 的 Rose Replicator 等， 這些方案 可實現基於主機的遠端資料複製，從而構建基於主機的容災系統。

採用基於主機的資料複製技術建設容災方案有以下優點：

Ø  基於主機的方案最主要的優點是隻和伺服器平臺和主機資料 管理 軟體相關 , 完全不依賴於底層儲存平臺，生產中心和災備中心可以採用不同的儲存平臺；

Ø  可 同時 對資料庫和 檔案系統提供 容災保護；

Ø  有很多不同的基於主機的方案，可以滿足使用者的不同資料保護要求，提供多種不同資料保護模式；

Ø  基於 IP 網路 , 沒有距離限制；

同時，採用主機的資料複製技術建設容災方案有以下侷限：

Ø  基於主機的方案需要主機平臺同構；

Ø  基於主機的資料複製方案由於生產主機既要處理生產請求，又要處理遠端資料複製，必須消耗生產主機的計算資源，對於主機的記憶體、 CPU 進行升級是非常昂貴的，因而對生產主機效能產生較大的影響，甚至是產生嚴重影響；

Ø  災備中心的資料一般不可用，如果使用者需要在遠端資料中心使用生產資料進行開發測試、 DW/BI 應用使用將非常困難；

Ø  利用主機資料複製軟體的方案比較複雜，尤其是和資料庫應用結合的時候需要很複雜的機制或多種軟體的結合，從而對生產系統的穩定性、可靠性、效能帶來較大影響；

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

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

主流產品 列表 ：

廠家名稱	產品型號	容災功能
賽門鐵克	Storage F oundation	映象 / 複製

構建 成本 ：

主機層卷複製容災產品，通常的報價方式是按照主機的 CPU 資料進行報價，主機數量越多， CPU 數量越多價格也越高，同樣也存在 MA 費用和實施費用。

  此類容災產品，相應的容災網路建設成本相對較低。

適用 場景：

目前，企業採用基於主機的資料複製技術建設容災方案的 案例 相對比較少，通常適合單一應用或系統在 I/O 規模不大的情況下區域性使用。在應用 I/O 負載比較大，需要災難保護的應用及應用型別比較多、主機環境複雜的時候，基於主機系統的方案並不適用。

1.4.3. 資料庫 的資料複製 技術 構建災備方案

基於 資料庫的資料複製技術大體上可 分為 兩類：資料庫自己提供的資料容災模組和第三方廠商提供的資料庫複製 技術 。 以 最常見的 Oracle 資料庫 為例，  Oracle 自己的資料 複製 技術有 Data Guard ， Streams ， Advanced Replication 和 Golden Gate 資料複製軟體。第三方廠商的資料複製技術有 Quest 公司的 Share Plex 和 DSG 的 RealSync 等。

1.4.3.1. 幾種 常見資料庫複製技術

  Data Guard 資料複製技術

Data Guard 是 Oracle 資料庫自帶的資料同步功能，基本原理是將日誌檔案從原資料庫傳輸到目標資料庫，然後在目標資料庫上應用（ Apply ）這些日誌檔案，從而使目標資料庫與源資料庫保持同步。 Data Guard 提供了三種日誌傳輸（ Redo Transport ）方式，分別是 ARCH 傳輸、 LGWR 同步傳輸和 LGWR 非同步傳輸。在上述三種日誌傳輸方式的基礎上，提供了三種資料保護模式，即最大效能（ Maximum Performance Mode ）、最大保護（ Maximum Protection Mode ）和最大可用（ Maximum Availability Mode ），其中最大保護模式和最大可用模式要求日誌傳輸必須用 LGWR 同步傳輸方式，最大效能模式下可用任何一種日誌傳輸方式。

最大效能模式：這種模式是預設的資料保護模式，在不影響源資料庫效能的條件下提供儘可能高的資料保護等級。在該種模式下，一旦日誌資料寫到源資料庫的聯機日誌檔案，事務即可提交，不必等待日誌寫到目標資料庫，如果網路頻寬充足，該種模式可提供類似於最大可用模式的資料保護等級。

最大保護模式：在這種模式下，日誌資料必須同時寫到源資料庫的聯機日誌檔案和至少一個目標庫的備用日誌檔案（ standby redo log ），事務才能提交。這種模式可確保資料零丟失，但代價是源資料庫的可用性，一旦日誌資料不能寫到至少一個目標庫的備用日誌檔案（ standby redo log ），源資料庫將會被關閉。這也是目前市場上唯一的一種可確保資料零丟失的資料庫同步解決方案。

最大可用模式：這種模式在不犧牲源資料庫可用性的條件下提供了儘可能高的資料保護等級。與最大保護模式一樣，日誌資料需同時寫到源資料庫的聯機日誌檔案和至少一個目標庫的備用日誌檔案（ standby redo log ），事務才能提交，與最大保護模式不同的是，如果日誌資料不能寫到至少一個目標庫的備用日誌檔案（ standby redo log ），源資料庫不會被關閉，而是執行在最大效能模式下，待故障解決並將延遲的日誌成功應用在目標庫上以後，源資料庫將會自動回到最大可用模式下。

根據在目標庫上日誌應用（ Log Apply ）方式的不同， Data Guard 可分為 Physical Standby （ Redo Apply ）和 Logical Standby （ SQL Apply ）兩種。

Physical Standby 資料庫，在這種方式下，目標庫透過介質恢復的方式保持與源資料庫同步，這種方式支援任何型別的資料物件和資料型別，一些對資料庫物理結構的操作如資料檔案的新增，刪除等也可支援。如果需要， Physical Standby 資料庫可以只讀方式開啟，用於報表查詢、資料校驗等操作，待這些操作完成後再將資料庫置於日誌應用模式下。

Logical Standby 資料庫，在這種方式下，目標庫處於開啟狀態，透過 LogMiner 挖掘從源資料庫傳輸過來的日誌，構造成 SQL 語句，然後在目標庫上執行這些 SQL ，使之與源資料庫保持同步。由於資料庫處於開啟狀態，因此可以在 SQL Apply 更新資料庫的同時將原來在源資料庫上執行的一些查詢、報表等操作放到目標庫上來執行，以減輕源資料庫的壓力，提高其效能。

Data Guard 資料同步技術有以下優勢：

1 ） Oracle 資料庫自身內建的功能，與每個 Oracle 新版本的新特性（如 ASM ）都完全相容，且不需要另外付費；

2 ） 配置管理較簡單，不需要熟悉其他第三方的軟體產品；

3 ） Physical Standby 資料庫支援任何型別的資料物件和資料型別；

4 ） Logical Standby 資料庫處於開啟狀態，可以在保持資料同步的同時執行查詢等操作；

5 ） 在最大保護模式下，可確保資料的零丟失；

Data Guard 資料同步技術的劣勢體現在以下幾個方面：

1 ） 由於傳輸整個日誌檔案，因此需要較高的網路傳輸頻寬；

2 ） Physical Standby 資料庫雖然可以只讀方式開啟，然後做些查詢、報表等操作，但需要停止應用日誌，這將使目標庫與源資料不能保持同步，如果在此期間源資料庫發生故障，將延長切換的時間；

3 ） Logical Standby 資料庫不能支援某些特定的資料物件和資料型別；

4 ） 不支援一對多複製，不支援雙向複製，因此無法應用於資訊整合的場合；

5 ） 只能複製整個資料庫，不能選擇某個 schema 或表空間進行單獨複製；

6 ） 不支援異構的系統環境，需要相同的作業系統版本和資料庫版本；

Data Guard 技術是 Oracle 推薦的用於高可用災難恢復環境的資料同步技術。

  Streams 資料複製技術

Streams 是從版本 Oracle 9i 才開始具有的資料同步功能，是為提高資料庫的高可用性和資料的分發和共享功能而設計的， Streams 利用高階佇列技術，透過用 LogMiner 挖掘日誌檔案生成變更的邏輯記錄，然後將這些變更應用到目標資料庫上，從而實現資料庫之間或一個資料庫內部的資料同步。

Streams 資料同步大致分如下幾個步驟：

1 ） Capture 程式分析日誌，生成邏輯記錄 LCR ，將其放入一個佇列中；

2 ） Propagation 程式將 LCR 傳送到另一個資料庫中，通常是目標資料庫；

3 ） 在目標資料庫中， Apply 程式將 LCR 應用到目標庫，實現資料的同步；

在簡單的 Streams 配置中， Capture 程式一般位於源資料庫，因此叫做 Local Capture Process ， Capture 程式在分析日誌後將生成的 LCR 放入佇列中，由 Propagation 程式將 LCR 傳送到目標庫中。這樣做的好處是不用在網路上傳送整個的日誌檔案，因此可提高網路傳輸的效率，但這一般會給源資料庫帶來較大的壓力，影響其效能。

另一種配置是 Capture 程式位於 Downstream 資料庫中，源資料庫只負責將日誌檔案傳送（日誌傳輸方式可為 ARCH 傳輸、 LGWR 同步傳輸和 LGWR 非同步傳輸中的任何一種）到 Downstream 資料庫中，所有的 Capture 操作都在 Downstream 資料庫上完成。這種配置的好處是可以大大降低源資料庫的壓力，缺點是需要傳輸整個日誌檔案，對網路頻寬要求較高。

Streams 資料同步技術有以下優勢：

1 ） 可支援一對多、多對一和雙向複製，可用於資料分發和共享，這是 Data Guard 所不具備的；

2 ） 可靈活配置複製資料庫中的一部分物件，如可按 Table 複製、 Schema 複製、表空間複製等，並可在複製過程中對資料進行過濾和轉換，使之滿足不同的需要；

3 ） 同 Data Guard 一樣，是 Oracle 內建功能，與每個 Oracle 新版本的新特性（如 ASM ）都完全相容，且不需要額外付費；

4 ） 可用於異構的作業系統和資料庫版本，但有一些限制；

5 ） 可支援非 Oracle 資料庫和 Oracle 資料庫之間的資料同步；

6 ） 目標資料庫處於開啟狀態，可以在保持資料同步的同時執行查詢等操作，分擔源資料庫的壓力；

Streams 資料同步技術有以下缺點：

1 ） 配置維護較複雜，需要較高的技術水平；

2 ） 在非 Downstream 複製中，對源資料庫壓力較大；如果使用 Downstream 複製，則增加了配置的複雜性且需要透過網路傳輸整個日誌檔案，對網路頻寬要求較高；

3 ） 不能支援某些特定的資料物件和資料型別；

4 ） 不能保證資料的零丟失；

Oracle 公司將 Streams 技術定位於資料的分發和共享，雖然也可用於高可用的災難恢復場合，但 Oracle 推薦使用的災難恢復技術是 Data Guard 。

  Advanced Replication 資料複製技術

Advanced Replication 配置管理較複雜，且對源資料庫效能影響較大，在以後的 Oracle 版本中將可能逐步被 Streams 技術所取代。

  Golden Gate 資料複製技術

Golden Gate 原來是一家獨立的軟體廠商的產品，現該產品已被 Oracle 公司收購， Oracle 將 Golden Gate 軟體整合到到其“融合（ Fusion ）”中介軟體中，預計以後該產品將與 Oracle 資料庫更緊密地整合。 Golden Gate 可以用於多種不同的作業系統平臺（ Unix 、 Linux 、 Windows ）和多種不同資料庫系統（如 DB2 、 Oracle 、 Infomix 、 MySQL 、 Sybase 等）之間的資料同步，是一款優秀的資料同步及資料分發產品。

GoldenGate 是一種基於軟體的資料複製方式，它從資料庫的日誌中解析資料的變化（資料量只有日誌的四分之一左右）， 並 將資料轉化為自己的格式，直接透過 TCP/IP 網路傳輸，無需依賴於資料庫自身的傳遞方式如 Oracle Net ，而且可以透過高達 9:1 的壓縮比率對資料進行壓縮，大大降低頻寬需求。在目標端， GoldenGate 可以透過交易重組 、 分批載入等技術大大加快資料投遞的速度和效率，降低目標系統的資源佔用，可以在秒一級實現大量資料的複製。

作為一種軟體方案， GoldenGate 可以採用非常靈活的方式加以配置，包括 單向 複製、雙向複製和多層次的資料複製。特別是其在雙向資料複製領域的 先進 技術，可以滿足使用者在本地或廣域網路環境中的各種複雜需求。

GoldenGate 資料庫複製 技術具有如下特性 ∶

本機資料改變捕捉 – 作為一個基於日誌的同步解決方案，將對源系統和網路的影響減少到最低。

靈活性 – 源和目的系統不需要有一樣的作業系統、資料庫及模板 ( 例如 ∶ 表，索引，等 ) 。 GoldenGate 能在同一個系統的多個資料庫例項之間實現資料複製，或把資料複製到區域網內的其它資料庫例項，或把資料複製到廣域網上的遠端資料庫例項。

無需當機時間的移植 –GoldenGate 能在不同版本的資料庫和作業系統之間同步資料。資料庫，作業系統或應用系統的更新可以在輔助系統裡進行。一旦更新後的輔助系統透過了完整的測試，所有的處理工作就可以切換到輔助系統，然後更新主系統。一旦主系統的更新完成了，主與輔助系統之間能夠再一次同步而無當機時間。

不依賴於硬體和資料庫 –GoldenGate 不依賴於作業系統，資料庫和硬體。資料可以在不同的環境之間移動，因而消除了客戶對任何拓撲結構的依賴性。

RPO 與 RTO 的目標 –GoldenGate 提供了立即恢復備份的裝備。這是因為源和備份系統可以配置或構架設計為雙向 ” 端到端 ” 的功能。

雙向複製 –GoldenGate 提供了兩個或兩個以上生產系統之間的資料複製功能。這些系統無須具有一樣的屬性或相同的作業系統，資料庫或資料庫版本。

資料一致性 – 備份資料庫支援讀一致性的查詢活動 ( 交易的一致性在任何時候都受到保護 ) 。

靈活的拓撲結構 – 在資料庫和表一級實現了多種相關資料的分部方式。例如 ∶ 支援一對多，多對一，多對多以及分層的配置。

對映與轉換功能 – 列轉換能夠適應特別的備份需要，包括檢視和執行儲存過程。

資料選擇 – 選擇性的複製資料而不是全部，例如表，行和列。

GoldenGate 是一種基於資料庫日誌的資料複製產品，可以利用極少的系統開支，實時複製資料庫，改善資料可用性。 GoldenGate 可以在資料移植、線上維護等場合應用，以減少或消除資料庫的停機時間。同時，它還可用於資料容災、負載均衡、資料集中、資料分佈等應用中。 GoldenGate 可確保在這些工作進行時，源系統的正常事務處理得以繼續進行，功能上不受影響。

  Share Plex 資料複製技術

Share Plex 是 Quest 公司開發的用於專門用於 Oracle 資料庫的資料同步軟體，可以執行在異構的作業系統平臺上和 Oracle 資料庫的不同版本之間。

Share Plex 的資料複製原理與 Golden Gate 類似，需要分別在源資料庫伺服器和目標資料庫伺服器上安裝 Share Plex 軟體。具體處理過程是： Capture 程式分析源資料庫的日誌檔案，抓取所需的資料變更操作，將其儲存在 Share Plex 自己專有的 queue 檔案中，放入到 Capture Queue ，然後由 Read 程式對 queue 檔案進行封裝處理，將其放入到 Export Queue 中，由 Export 程式將 queue 檔案透過網路傳送到目標伺服器上，目標伺服器上的 Import 程式接收這些 queue 檔案，將其放入到 Post Queue 中，最後由 Post 程式將這些 queue 檔案中的變更應用到目標資料庫中，其處理流程如下圖：

Share Plex 資料同步技術的優勢有：

Ø  支援異構的作業系統平臺，便於資料庫管理系統的版本升級及作業系統平臺切換；

Ø  跟 Data Guard 傳輸整個日誌檔案相比， Share Plex 傳輸的資料量大大降低，這點跟 Golden Gate 差不多；

Ø  目標資料庫處於開啟狀態，且支援一對多、多對一、雙向複製等配置，也可以選擇部分物件進行復制，可滿足資料分發和資料整合的需要，減輕源資料庫壓力，這方面也類似於 Golden Gate ；

Ø  所佔系統資源較少，通常在 10% 以下。

Share Plex 資料同步技術的劣勢體現在以下幾個方面：

Ø  需要支付額外的 Liscense 費用，通常是一筆不小的支出；

Ø  需要在資料庫軟體外安裝一套專門資料同步軟體，增加了管理維護的複雜程度；

Ø  由於資料複製操作獨立於資料庫管理系統，因此不能確保資料零丟失；

Ø  由於是第三方的軟體產品，在對某些特定的資料物件、資料型別和 Oracle 某些新特性如 ASM 的支援方面不如資料庫廠商自己的解決方案；另外，還有一種可能就是如果 Oracle 對自己的日誌格式做些改變或加密， Share Plex 將無能為力。

從上述分析可知， Share Plex 雖然專用於 Oracle 資料庫同步，但同 Golden Gate 相比並無明顯優勢， Golden Gate 對異構資料庫的支援更是 Share Plex 所不能比。

  DSG Real Sync 資料 複製技術

除了上述資料同步技術外，在國內市場上用於 Oracle 資料同步的產品還有 DSG 公司的 Real Sync 軟體， Real Sync 的實現原理及功能與 Share Plex 基本類似，也是隻支援 Oracle 資料庫，也可以跨越不同的作業系統平臺。值得一提的是 Real Sync 在目標資料庫的資料裝載方面，不是透過主鍵或唯一鍵來實現資料記錄的定位，而是自己維護一個源資料庫和目標資料庫的資料記錄的 rowid mapping 表，透過 rowid 來實現記錄的定為，因此在資料裝載效率方面有不小的提高。

1.4.3.2. 主流產品 列表

對比項	DataGuard	Stream	Advenced Replication	GoldenGate
原理	基於 日誌挖掘，透過傳播 執行緒 將歸檔日誌由源資料庫傳到目的資料庫	基於 日誌挖掘	基於觸發器（ trigger ） 所有複製物件結構（ DDL ）的改變，都必須透過 oracle 提供的複製包來實施	基於 日誌挖掘
主要 用途	災備 恢復、高可用性	資料 共享	資料 同步	高可用 與容災、 實時 資料整合
實現 簡易程度	實現 過程和管理簡單	實現 過程複雜，對 DBA的 要求非常高	配置 和管理複雜	配置 較簡單
安全性 與穩定性	較穩定 、可靠	穩定 、可靠	穩定 、一般	穩定 、可靠
對 源資料庫的效能影響	一般	一般	基於 觸發器原理，對主庫 影響 比較大，生產系統一般不 適用	亞 秒級複製，對源資料庫影響非常小 （獨立 的軟體，並且只是針對 re do 日誌 的掃描）
拓撲 結構	支援 一對多模式，standby 資料庫 最多為 9個	支援 一對一、一對多、多對一、雙向複製等多種拓撲結構	支援 一對多模式或者包含多個 Master Site	支援 一對一、一對多、多對一、雙向複製等多種拓撲結構
是否 支援作業系統異構	不支援	支援 ，但是有限制		支援
收費 情況	免費	免費	免費	收費

1.4.3.3. 構建 成本

Oracle 資料庫類應用容災產品，目前分為兩種型別：

Oracle 企業版自身提供的 DataGuard 功能模組，其模組是免費的。

商業版的如 GoldenGate ， SharePlex 等軟體，按照 CPU 的數量進行收費，主機的 CPU 數量越多，價格也越高，同樣也具有 MA 費用和實施費用。

下表為 Golden gate 的 list 價格：

Oracle產品元件	描述	license List 價格
Oracle GoldenGate	包括GoldenGate Capture, Deliver and Active DataGuard On oracle DB	$17500/CPU
Oracle GoldenGate Veridata	Add-on capability to validate date in replicated systems	$30000/CPU
Management Pack for GoldenGate	Add-on management pack	$3500/CPU

這類容災產品，如果 採用商業版本，軟體費用和實施服務費用也比較高 。

1.4.3.4. 適用 場景

資料庫類 應用容災產品， 採用 安裝在 主機 端的應用軟體實現容災，其最大的優勢是可為資料庫資料提供應用級別的保護，對網路頻寬要求較低， 容災 網路基於 IP 網路構建 ，成本較低； 其 劣勢是僅能對資料庫資料提供保護，並且 對源資料庫 都有或多或少的效能影響。

經過 對以上幾種資料庫複製技術的分析， DataGuard 、 Stream 、 Advenced Replication 是專為 Oracle 資料庫 開發的災備模組，適合於同構平臺的 Oracle 資料庫容災 ； Shareplex 適合於異構平臺 的 Oracle 資料庫 容災； GoldenGate 適合於 異構平臺和異構資料庫的容災與應急備份，消除計劃內停機、雙業務中心 、 資料倉儲實時供給、實時 報表 等應用場景需求。

1.5. 選擇 最優 的容災方案

1.5.1. 容災技術 選擇 原理

 

                             圖：   沙漏模型

1.5.2.

在構建 容災 系統時，首先考慮的是結合實際情況選擇合理的資料複製技術。 在 選擇合理的資料複製技術時主要考慮以下因素：

Ø  災難承受程度 ：明確計算機系統需要承受的災難型別，系統故障、通訊故障、長時間斷電、火災及地震等各種意外情況所採取的備份、保護方案不盡相同。

Ø  業務影響程度 ：必須明確當計算機系統發生意外無法工作時，導致業務停頓所造成的損失程度，也就是定義使用者對於計算機系統發生故障的最大容忍時間。這是設計備份方案的重要技術指標。

Ø  資料保護程度 ：是否要求資料庫恢復所有提交的交易 ， 並且要求實時同步 ，保證 資料的連續性和一致性， 這是 備份方案複雜程度的重要依據。

1.6. 專案容災模式及 技術 的選擇

1.6.1. 模式選擇

在災備模式選擇上，目前， XX 市 各委辦局 資訊中心資訊系統直接面向群眾提供服務，業務的連續性以及資料安全的保障是在選擇容災模式時首要考慮的兩個方面。既要在生產中心發生災難時，保證關鍵業務不中斷，又要保證在同城發生災難時，各委辦局所有關鍵資料儲存一份相對完整的備份。新建 的 XX 市雲端計算中心 作為 未來的主生產中心，未來各委辦局的業務系統會逐步遷移到該中心執行，承載當前 XX 市電子政務資訊系統的 主要 業務 ， 提供對內對外服務； 同城容災中心做為生產中心的容災備份，在生產環境發生災難不能運作的時候，將接管生產，暫時作為主資料中心執行，恢復各委辦局 關鍵業務 的應用執行。同城容災中心作為生產中心的區域內備份，不能防禦區域性災害。異地容災中心用於防範區域性災難，從 《 中國 地理雜誌》 釋出 的《 中國 地震帶 分佈 》 圖上可以看出， XX 位於中國第 4 大斷裂帶“郯廬斷裂帶”的 邊沿 上，有發生區域性災難的可能性。當發生區域性災難時，生產中心和同城容災中心都不可用，異地容災中心可以保證關鍵資料還有一份複製， 並且 核心 應用可以選擇在異地容災中心重新啟動 。因此，從整個容災體系來看，省廳容災模式應選擇 “兩地三中心”的方式。

1.6.2. 中心選址

1.6.2.1. 同城災備中心地址選擇

選擇該地點作為同城災備中心具有以下優勢：

Ø  具備完善的物業服務、市電供電、消防設施等，各種配套設施比較齊全。

Ø  該機房建設時已經充分考慮了承重、抗震、防雷、防水等內容，選擇該處可以大大降低建設成本和建設週期。

Ø  該機房內的裝置可以作為災備裝置使用，無需搬遷，降低搬遷費用和搬遷風險。

Ø  XX 市電子政務外網的光纖專線全部匯聚到該機房，在雲端計算中心建成後可以利用這些光纖專線作為 XX 市電子政務外網的備份線路。

1.6.2.2. 異地災備地址選擇

按照國家有關要求，電子政務災備中心須依託電子政務網路進行建設，達到共享災備基礎設施、降低昂貴的線路租賃費用等目的。 XX 市政府網站管理中心先期對國內知名的雲端計算中心進行考察並同國內部分城市的電子政務管理部門進行了溝通和交流，已經有廣州、成都、無錫等城市表達了願意同 XX 市等價交換機房、網路、安全、運維人員等方面資源的意願，形成互惠機制，最大限度的發揮雙方的優勢。

廣州、成都、無錫等城市均已經建成了雲端計算中心，南京的雲端計算中心也是高標準雲端計算中心。這些中心均具有良好的機房環境、網路設施和較強的運維能力，完全具備災備中心必須具備的硬體條件和技術服務能力。

災備中心除了需要考慮機房、網路和運維能力等因素以外，還需考慮距離、地震帶、地質結構、電網、江河流域、建築環境等各種因素。

目前， XX 市政府網站管理中心正在積極同其他城市聯絡，擬在初步設計階段同其他城市達成正式的合作協議，明確機房交換、網路設施使用、運維人員互用等事宜。

考慮到 CNGI 的建設情況，本專案擬在專案建議書階段選擇城市 A 或是 城市 B 作為異地災備城市，理由如下：

Ø  城市 A 和 城市 B 是 距離 XX 市較近的且 不在地震帶上的 CNGI 主節點城市，總頻寬為 2.5GB 。

Ø  中國移動遼寧分公司已在城市 A 建設了高標準機房，完全能夠滿足異地容災對機房環境的要求。

Ø  城市 B 市 已經 建設了高標準雲端計算 中心 ，完全能夠滿足異地容災對機房環境的要求。

CNGI主幹網拓撲圖如下：

 

1.6.3. 複製技術的選擇

在資料 複製技術的 選擇上，透過比較儲存層 、主機層以及資料庫層的資料複製技術 的優缺點後，以及 結合使用者的業務系統現狀， 我們認為，本專案採用支援 異構平臺的 基於資料庫層 和儲存層的資料複製技術 。

經過調研 發現，各委辦局的關鍵資料多為結構化的資料庫資料，儲存在 Oracle 、 SQL Server 等 異構資料庫平臺上，採用支援異構平臺的資料庫 層 資料複製技術，可以實現異構資料庫平臺的統一容災， 具有 良好的擴充套件性和開放性，同時具有較高階別的 RTO 和 RPO ，並且支援兩地三中心的架構。

使用者另一類 關鍵資料是 大量 的虛擬機器映象、文件等非結構化資料，這些資料也是分散儲存在多套異構磁碟陣列上 。因此 本方案採用基於儲存虛擬化功能的 異構 平臺儲存層資料複製技術， 該 技術 對 底層磁碟陣列沒有嚴格的限制， 可以 在同構盤陣和異構盤陣之間 實現 資料複製，具有同步、非同步多種工作模式，滿足不同級別 RPO 、 RTO 使用者 的要求 。同時 ， 儲存 虛擬化技術支援儲存裝置進行橫向和縱向的擴充套件，滿足 未來各委辦局 資料增長 的 需要，具有良好的擴充套件性。

資料 複製技術是用來解決 裝置 down 機 、機房斷電 、 自然災害等物理故障的技術，為了解決 人為 誤刪除、病毒感染等邏輯故障對生產系統的業務連續性影響，本方案 又 引進資料備份 這項 技術。

2. 推薦 方案概述

2.1. 技術 路線選擇

經過上述 現狀的綜合分析 ， 我們 計劃 基於 兩地 三中心災備模式構建 XX 電子政務 災備 方案 ，其中 以 新建 的 XX 市雲端計算中心作為各委辦局業務系統的主資料中心， XX 市網站管理中心作為同城 災備 中心， 可以 選用 成都 雲端計算中心作為異地災備中心 。

雲端計算 中心作為 主生產中心，負責日常的各委辦局所有業務系統的執行。 關鍵業務 的應用執行。 異地災備 中心完成各 委辦局 關鍵 資料的 保護，在發生地區級（ XX ）的災難時，保證各個業務系統的核心資料不丟失。

根據各委辦局 的 技術架構現狀與策略制定，結合容災技術的關鍵技術分析與最佳實踐，制定如下容災架構：

Ø  容災 模式為兩地三中心災備模式

Ø  容災 級別 為資料庫 系統實現應用 級別 容災，其他應用系統基於同城容災中心實現應用級容災，基於遠端容災中心實現資料級容災

Ø  結構化 資料複製採用 支援 異構平臺的基於資料庫層 的 GoldenGate 資料 複製 技術 ，虛擬機器 映象等這類關鍵 非結構化 資料複製 採用 基於 儲存層 的資料複製 技術

Ø  虛擬機器 之間的 系統 切換技術 以自動 切換方式為主，物理機之間以及物理機和虛擬機器之間的系統切換以手工切換方式為主，並配合 切換 指令碼 減少 系統切換時間

Ø  容災網路，建議 同城資料中心之間採用大二層的儲存網路架構，資料網路和儲存網路的物理連線採用 DWDM 裸光纖 高速網路連線， 本地 和異地資料中心之間採用 IP 網路 連線，網路頻寬要保證 系統切換的順暢和資料複製的頻寬需求

Ø  前端（客戶端 ） 網路切換 技術有手工切換、 DNS 重定向 和負載均衡器的健康路由注入幾種，本方案建議根據實際情況選擇以上切換技術的一種或幾種

Ø  容災 系統和生產系統之間的配對關係為降級配對，就是容災中心和生產中心之間的軟、硬體配置不遵循 1:1 比例 ， 容災 中心硬體配置的效能低於生產中心 ，容災 應用伺服器以虛擬機器平臺為主， 從而 進一步提升災備系統的投入產出比

2.2. 總體 方案架構

 

本 專案 兩地三中心災備專案的整體架構圖如上 所示。 從 容災層次上來說 ，本 方案 包括 備份和容災兩個層次 。

其中備份（ 主要是 資料備份） 是指 在專用的備份系統 中 儲存多個歷史點的 生產 資料， 當 生產資料因為人為誤操作、病毒感染等原因出現邏輯故障時，可以從 備份 系統中 選擇 合適歷史點的資料進行恢復， 備份 的資料型別可以是常見的資料庫這類結構化資料，也可以是作業系統、虛擬機器映象、檔案和應用程式等這類非結構化資料，由於備份視窗的原因，資料備份的 頻率 通常不會 很 頻繁，通常為 小時 、天甚至是周級別。

容災 是為了防止硬體故障、電力中斷、地震災難等 物理 故障對業務系統所 造成 的應用中斷， 其 最關鍵的技術就是資料複製技術。 本 方案資料 複製 分為結構化資料的複製和非結構化資料的複製兩部分，其中 結構化 資料複製由 支援 異構資料庫複製的 GoldenGate 實現，虛擬機器 映象等非結構化資料 的複製 由儲存層的技術實現。

一 、 基於資料庫複製 技術的結構化資料 容災 系統

資料庫系統的容災方案，本 方案 建議基於成熟 的商業版軟體 Golden Gate 實現，採用 Golden Gate 複製日誌記錄，實現各 委辦局多個資料庫在同城容災中心和異地容災中心的容災、以及本地兩個資料中心之間 資料庫的互備，保證結構化 資料 訪問的連續性。

Golden Gate 實現資料庫容災的技術手段成熟，管理維護相對容易， 沒有作業系統和資料庫版本的限制 （不過 Golden Gate 對 Oracle 9 i 及以下 版本 的 支援 有些 限制 ， 對 10g 及 以上版本支援 的 更好），具有更好的相容性 。對於 TB 級資料庫，其傳輸日誌的頻寬需求在 10M 一下，網路建設成本比較低。

二 、 基於儲存層 資料複製技術構建 非結構化 資料 容災 系統

對於 虛擬機器映象、應用程式等關鍵 非 結構化資料的保護 建議 採用 儲存 層次的 容災 方案， 該 方案建議基於 高效 的儲存層複製技術實現， 利用某公司高階 磁碟陣列 的 Metro Cluster 和 SnapMirror 資料映象和資料複製功能，可以實現 兩地 三中心 多套磁碟陣列 的互備， 保證 資料 訪問 的連續性。 同時 ， 可以 整合其他廠商的磁碟陣列，透過這種技術，可以實現異構 儲存 平臺之間的資料遷移和資料複製，是構建複雜異構 IT 系統容災 方案的理想平臺。

2.3. 資料庫 容災系統設計

對於 資料庫 這類 核心應用系統，建議 構建 高階別的 容災 方案。 綜合 分析現有業務 系統資料庫 應用情況，本方案建議採用 成熟 的商業版軟體 Golden Gate 構建 資料庫容災方案。

Golden Gate 的資料延遲為亞秒級，處理資料能力高。支援廣泛 的 異構資料庫 應用環境 ，源和目標資料庫端的作業系統和資料庫可以任意組合，支援一對一、一對多、多對一、雙向複製等多種靈活拓撲結構，並 且 有完整的技術支援方案，是建立異構平臺或異構資料庫的容災與應急備份方案 、 雙活 資料 中心的唯一 選擇。

結合容災 效能指標以及預算的情況，本方案建議在 同城 容災中心 和 遠端容災中心 各新增 1 套 （ 1 臺 或多臺） Standby 資料庫伺服器 ， 基於 Golden Gate 災備 技術實現多個委辦局異構資料庫平臺到 同城 容災中心 的 集中容災 ，同時實現同城災備 中心 資料庫 系統到 遠端 災備中心和資料庫 遠端 容災。

對於各委辦局 的 某一個 資料庫應用來說，當 某個生產庫 出現故障時 ：如果生產庫 和容災庫同構， 在 理想情況下（ 資料 完全同步且可用、 容災 鏈路頻寬充足、裝置執行良好） ， 可以在 分鐘 級別切換到 同城 容災資料庫 ； 如果生產庫和容災庫異構，那麼無法進行資料庫切換操作，只能透過方向複製的方法把容災庫的資料恢復到生產庫中。 如果同城 資料中心的資料庫系統同時出現故障， 可以利用 遠端容災庫進行生產庫資料的恢復，由於異地容災資料庫與生產庫的資料有一定的延遲，有可能會丟失部分資料。

Standby 資料庫 伺服器的資料和配置可以低於生產資料庫 伺服器 ， 採用 降級容災配置方案 ， 用於節省硬體平臺的投資預算 ；可以 先對幾個關鍵業務 實現 資料庫災備保護， 未來實現 全業務資料庫容災。

2.3.1. 原理

Golden Gate 軟體需要安裝在源資料庫伺服器和目標資料庫伺服器上，所需的作業系統資源在 10% 以下。 Golden Gate 資料同步的基本原理是由 Extract 程式讀取源資料庫的事物日誌（ Oracle 中是 redo log ），將其中的變更操作（ insert 、 update 、 delete 等）按事務執行的順序組合在一起，直接將其傳送到目標伺服器上，或者存放到 Trails 檔案中，然後由 Data Pump 程式將 Trails 檔案傳輸到目標伺服器上，在目標伺服器上 Collector 程式接收從源伺服器傳送過來的 Trails 檔案，最後由 Replicat 程式將 Trails 檔案中的資料裝載到目標資料庫中，其處理過程如下圖：

 

由於 Golden Gate 將資料儲存到自己的統一格式的 Trail 檔案中，因此可以將 Trail 檔案傳送到不同的作業系統，應用在不同的資料庫系統上，大大增強其靈活性。

另外，由於 Golden Gate 只收集必要的資料到 Trail 檔案中，且 Trail 檔案可以壓縮，因此大大減少透過網路傳輸的資料量，壓縮後傳輸的資料量通常是日誌量的 1/4 或更少。

Golden Gate 還可以分流查詢，如下圖所示：

 

Golden Gate 有以下優點：

Ø  支援異構的作業系統和資料庫管理系統，便於客戶在不同資料庫管理系統和作業系統平臺之間的資料同步，這是其核心優勢所在；

Ø  跟 Data Guard 傳輸整個日誌檔案相比， Golden Gate 傳輸的資料量大大降低，在沒有 LOB 等資料物件的情況下，通常是整個日誌檔案 1/4 或更少；

Ø  目標資料庫處於開啟狀態，且支援一對多、多對一，雙向複製等，也可以選擇部分物件進行復制，可滿足資料分發和資料整合的需要，減輕源資料庫壓力；

 

Ø  所佔系統資源較少，通常在 10% 以下；

Ø  Golden Gate 被 Oracle 公司收購後，對 Oracle 資料庫的支援方面做的更好。

2.3.2. 委辦局和同城容災中心之間的資料庫複製

為了能夠便於維護和管理、最少 化 投資， 個委辦局和同城容災中心之間採用 N+1 模式 的資料庫容災， 同時 ，為了提升同城容災中心資料庫系統的可靠性和效能，同城容災中心 建議 配置 2 臺 以上 X86 架構 的 高效能 多路伺服器組成 Oracle RAC 叢集 系統 。各委辦局 的多個 異構 Oracle 、 SQL Server 資料 庫系統 透過 GoldenGate 資料複製軟體實時備份到此 Oracle RAC 叢集 系統 ，從而達到了容災的目的。系統拓撲參考圖如下：

 

鑑於建立同城 容災中心的 的目的是為了應用 級別 容災，因此我們在同城 容災中心 為各 委辦局的多個核心應用 建立了不同資料庫使用者，將各 委辦局的 各核心 應用 資料庫資料複製到各自使用者下的表中，一旦生產中心處於計劃停機或非計劃停機狀態，同城 災備 中心將接管生產中心的服務，保障業務的持續進行。為了在叢集環境下實現節點間的負載均衡，我們可以 將生產中心的多個核心資料庫應用劃分為 N （ N = 同城容災中心 Oracle RAC 叢集節點 數量） 個小組 ，每個小組傳送過來的資料由 RAC 叢集 中的某個節點承擔， 從而實現 RAC 多節點共同工作完成所有委辦局資料的接收。

該 方案的應用特點：

N+1 災備模式

各委辦局 的多個業務的生產資料庫分佈在多套異構資料庫系統 中 ， 使用 GoldenGate 資料複製 技術 可以將多個 業務的 資料庫集中備份到一套資料庫備份系統，從而實現了 N+1 的備份模式，以較低的成本實現了容災。 GoldenGate N+1 模式區別於其它技術的特點在於其能夠實現多個資料庫資料向一個資料庫的邏輯集中，從而使得同城 災備 中心在一個庫中對各 委辦局相關 資料的進行查詢和統計，為今後建立資料倉儲和開展 BI 等業務創造了條件。

異構平臺支援

在本 方案中， 各 委辦局的生產資料庫系統是異構 的 ， GoldenGate 支援 異構 資料庫 系統之間的資料複製 。 GoldenGate 這種跨平臺複製的特性降低了 容災中心的硬體投資， 減少 了後期管理和維護的成本 。

支援 雙向複製

Golde Gate 支援 雙向資料複製 模式 ，透過該模式，可以將 各 委辦局的某些資料庫負載均衡到同城容災中心， 從而 提高同城容災中心的裝置利用率 ， 降低生產中心的負載。

 

雙向資料複製是基於單向資料複製原理之上，兩端互為源 / 目的資料複製物件，兩端生產系統同時保持 Active 狀態。在這種配置模式下， GoldenGate 採用必要的衝突處理機制來解決可能發生的衝突。

為了避免出現剛被複制進對端目的資料庫資料馬上又被捕捉程式複製回源端，陷入死迴圈的狀態。 GoldenGate 採用了相應的判別機制來保證對捕捉資料的識別，當應用程式和 GoldenGate 複製程式同時更新同一個表時 , 捕捉程式使用了一個跟蹤表機制。在配置雙向資料複製時 , 需要透過命令列向兩邊的資料庫中加入跟蹤表。當捕捉程式讀到一個交易中有針對跟蹤表的更新 , 捕捉程式就知道這個交易是由複製程式產生的並且把這筆交易忽略掉 . 如果沒有針對跟蹤表的更新 , 捕捉程式就知道這個交易是由應用程式產生的並且把這筆交易讀取出來 .

透過以上處理機制後，就可以很好的解決雙向資料複製中所擔心的重複捕捉變化資料的操作出現。

2.3.3. 容災中心和異地 容災 中心之間的資料庫複製

同城 容災中心和 異地 災備中心之間採用 1+1 模式 的資料庫容災， 本方案 建議 在 遠端容災中心 配置 1 臺 X86 架構 的 高效能 多路伺服器組成 Oracle 異地 容災資料庫系統 。同城容災 中心的 Oracle RAC 叢集 中 的資料透過 GoldenGate 資料複製軟體備份到遠端 容災中心 Oracle 資料庫 系統 ，從而達到了遠端容災的目的。系統拓撲參考圖如下：

 

為了 進一步節省投資，同城容災機房和異地容災機房之間的 同構 Oracle 資料庫 複製可以採用免費開源的 DataGuard 資料庫 複製 技術 實現。

2.4. 非 結構化資料容災系統設計

對於虛擬機器 映象、 應用 程式以及關鍵文件這類儲存在多臺異構磁碟陣列中的關鍵資料，本方案建議 基於 儲存層的資料複製技術構建容災方案。 儲存 層資料複製技術 支援 資料映象和資料複製技術， 與 上層應用 無關 ， 不佔用 上層應用伺服器的資源， 是 應用最廣、最成熟的資料複製技術，是構建異構 平臺 雙活資料中心、兩地三中心資料災備方案的理想選擇。

本 方案 建議 在主生產中心、同城容災資料中心 新增 一套 雙活 儲存系統， 每個 資料中心各放置一半的儲存 裝置 ， MetroCluster 是 一種基於同步資料映象技術 的 儲存高可用技術，上層應用的每一次 I/O 操作 會 在 兩個資料中心之間的 儲存 裝置之間 同步 ，任一擴充套件櫃或是控制器出現故障不會 影響 上層應用的正常訪問， 可以 實現資料近乎不丟失（ RPO=0 ） 。

同時在遠端 容災 中心 新增一套 磁碟陣列 ， 透過盤陣的 SnapMirror 資料 複製技術實現同城容災中心 關鍵 非結構化資料到遠端資料中心的容災， 由於 同城容災中心和遠端容災中心之間的距離較長， 網路 延遲較高，建議採用非同步資料複製模式 。 當本地 兩個 資料中心的儲存系統同時出現故障時，可以 從 遠端容災中心實現資料的快速恢復 （可能 會丟失部分資料）。

同步資料 映象模式對災備鏈路要求較高，建議本地兩個資料中心 之間 租用效能不低於 4Gb 的 裸光纖鏈路連線 ， 為了 提高 容災鏈路的利用率，建議配置 DWDM 裝置 ， 實現儲存層資料 複製鏈路和 上層 應用資料鏈路 的 複用， 從而 減少容災鏈路的投資 。非同步 資料複製模式對資料頻寬和延遲要求沒那麼嚴格，因此，同城 和 異地資料中心之間採用 IP 網路 連線即可。

為了 進一步節省成本， 遠端 容災磁碟陣列的配置可以適當低於生產磁碟陣列。

2.4.1. 同城 容災中心和生產中心之間的資料容災

本方案 同城容災中心需要基於儲存層的資料複製技術使用應用級容災，為了實現該災備目標，本方案 建議 對同城容災中心和各委辦局生產中心做適當的改造 ： 一、把 同城 容災中心和生產中心需要進行災備保護的關鍵非結構化資料如虛擬機器映象、關鍵文件 等 集中遷移 或 儲存到新增 磁碟陣列 中 ；二 、 首先對各 委辦局需要實現應用級容災的 物理 應用伺服器 進行 適當的改造 ， 把應用伺服器需要 修改 的資料集中儲存在 資料庫或是 盤陣中，不需要修改的資料可以儲存在本地 硬碟中 ， 然後 利用 VWware 的 P2V 工具 為這些物理應用伺服器做 虛擬機器 映象，並把映象資料儲存在新增 盤陣中。

 

改造 完成後， 利用 DS900 的 MetroCluster 功能實現 關鍵資料在同城容災中心和生產資料 中心 的互備， 構建 雙活儲存系統，系統架構圖如上所示 。

本 方案在 同城 容災中心和 生產 資料中心 各 部署 1 個 DS900 控制器 、 2 個 DS900 擴充套件櫃 、 2 套 24 埠 FC 交換機 （ 若現 、新大樓之間的距離少於 500 米 ，可以不用交換機） 、 2 套 DS900  FC-SAS 橋接器 ， 兩個中心 之間的 DS900 主機頭 和擴充套件櫃透過 FC 交換機和 橋接器 組成 高可靠的冗餘 儲存 網路； 兩個 資料中心 DS900 盤陣 裡的資料基於 MetroCluster 技術 實現實時 資料 同步 ， 兩個中心之間的 任一 主機頭或是擴充套件櫃出現故障，不影響前端應用的正常執行 ， 任一 中心 的 DS900 裝置全部故障，也 可以 確保在很短的時間內 將 儲存 自動 切換到 另一中心 。

同城容災 中心和生產資料中心之間透過 DWDM 裸光纖 實現 FC 儲存和 IP 資料鏈路 互通， DS900 同時 支援 FC 、 iSCSI 和 NAS 儲存 協議，這樣 基於 MetroCluster 技術 實現的雙活儲存系統本身就具備了統一儲存功能， 可以為 上層 各種 應用按需提供 儲存 服務。

同時， DS900 支援 異構儲存資源整合，後期使用者新購的 異構 磁碟陣列可以 透過 這套 DS900 主機頭 進行整合， 形成 統一儲存資源池，便於後期擴充套件、管理和使用，並有效的提高儲存資源率。

兩個 資料中心的 DS900 MetroCluster 雙活 架構 實現了儲存服務與資料的熱備（ 有 兩份實時同步副本） ， 同時為了預防資料誤刪除的恢復、檢視呼叫某個階段的原始資料，以及應對一些災難情況，本方案同時為 DS900 配置 SnapShot 功能 進行資料備份 。 SnapShot 基於時間點的指標型資料快照技術 ，結合 SnapRestore 快照資料恢復軟體可以 顯著節省備份時間和恢復時間 ， 同時節省備份空間 。 基於 快照 技術實現的備份資料 無需 恢復，可直接掛接到主機上進行驗證和分析。

考慮 到實際情況，這套 DS900 MetroCluster 雙活 儲存系統 初期 全部放置在同城容災中心，等生產資料中心完成建設後，再把 一半 的儲存系統遷移到 生產 資料中心。

Metro Cluster 工作 原理

MetroCluster 技術是結合了 的 資料映象功能、資料快照功能、陣列雙控制器雙活和故障切換保護功能 ， 並在這些功能遠距離實現（最遠 160 公里）的基礎上所實現的一項提供儲存系統高可靠性保證和資料訪問雙活架構的儲存功能 。

MetroCluster 技術把一套 DS900 標準的雙控制器配置的儲存系統分為兩部分，每部分包括各自的控制器和磁碟櫃，然後把兩部分分開部署，最長距離可以達到 160 公里。如果兩部分之間的距離不超過 5 米，則可以直接使用普通的 FC 和 SAS 連線線相互連線，如果兩部分之間的距離超過 5 米，則需要配置 4 套專用的 SAN 交換機 和 4 套 FC-SAS 橋接器 實現兩部分的互連。這樣一套 MetroCluster 儲存系統的兩部分可以部署在同一個機房中，也可以分開部署在使用者的兩個機房，而在邏輯上，這分開部署的兩部分組成的儲存系統仍舊是一套儲存系統，兩個控制器之間的負載均衡和故障切換功能和標準的本地雙控制器的儲存系統完全一致，一個部分的控制器失效，另外一個部分的控制器會自動接管其工作，且對前端應用系統透明。

MetroCluster 技術增強了 DS900 的 Sync Mirror 資料映象功能從而實現資料的遠距離映象，即資料在一套 MetroCluster 儲存系統分開部署的兩部分之間實現映象，只要映象的這兩份複製有一個有效，就可以保證資料的正常訪問。

結合上述兩點， MetroCluster 為使用者提供了一種比傳統的硬體冗餘保護架構更高階別的可靠性保證，就算組成 MetroCluster 儲存系統的兩部分中的某部分儲存部件完全失效，另外一部分的控制器可以利用映象過來的資料接管故障部件所承擔的工作，以保證使用者應用系統的持續性，且這個接管動作由儲存系統自動進行，對前端應用透明。

如果 MetroCluster 儲存系統的兩部分分開部署在兩個機房，則利用兩個機房互連的 SAN FC 網路和 NAS IP 網路，前端應用主機可以在任何一個機房訪問同一份資料，因此實現了資料訪問的雙活架構。使用者可以根據自己的實際情況把應用系統部署在 任意 一個機房甚至同時部署在兩個機房。

在 MetroCluster 儲存系統的任何一部分中所進行的資料快照，都會被自動的映象到另外一部分中進行儲存，因此實現了資料快照的映象保護，提升了資料快照對邏輯性錯誤和硬體錯誤的雙重抵禦能力。

2.4.2. 同城 容災中心和遠端容災中心的 資料 容災

為了進一步 提高資料保護的級別，可以 在 另外一個城市 建立 遠端 容災 中心 。在遠端 容災中心新增一套磁碟陣列， 基於 SnapMirror 技術 ， 實現 同城容災中心關鍵非結構化資料到遠端容災中心的複製，當本地 MetroCluster 雙活 儲存系統 都 出現故障後，可以 利用 遠端 盤陣 裡的資料實現資料恢復。 基於 以上措施構成的 完全 資料保護 方案 架構圖 如下 所示：

 

SnapMirror 技術 原理

SnapMirror 技術將資料映象到一個或多個網路 Filer 上。 SnapMirror 不斷地更新映象資料，以確保資料是最新的，並且能夠用於進行災難恢復、減少磁帶備份、釋出只讀資料、在非生產性 Filer 上進行測試、執行聯機資料遷移等等。 SnapMirror 可以將同一資料釋出到所有地點。透過自動更新這些資料，並支援對映象資料的本地訪問方式， SnapMirror 可以大大提高員工的工作效率 ， 提高資料保護級別。

SnapMirror 技術 優勢

Ø  SnapMirror 支援多種複製方式，用於適應不同的容災環境，包括：同步，準同步，非同步。非同步方式的複製對於距離沒有限制。

Ø  SnapMirror 支援多種網路環境，用於適應不同的容災環境，包括： IP 介面和 FC 介面。

Ø  SnapMirror 支援多種拓撲方式的複製，包括： 1 對多；多對 1 ；級聯複製等。

Ø  SnapMirror 支援對多種資料的複製，包括：基於卷的複製，基於 qtree 的複製，支援對 NAS / SAN /iSCSI 中的資料複製。

Ø  SnapMirror 只傳輸變化的資料塊，可以大大節省網路頻寬和減輕 Filer 的負載。

Ø  透過使用 SnapManager ，與 SQL 、 Oracle 、 Exchange 、 SharePoint 、 Virt 等實現了整合，從而簡化故障轉移和災難恢復。

由於 同城 容災 中心和遠端 容災 中心之間的距離相距較遠， 為了減少 容災鏈路頻寬投入，本方案建議 採用 SanpMirror 非同步 資料複製技術，容災鏈路採用 IP 網路 構建即可。

2.4.3. 應用級 容災幾種實現方式

基於 儲存複製技術實現應用級 容災 ，可有如下 幾種 方式：

Ø  受保護 和 容災的應用伺服器同為虛擬機器，那麼基於 DS900 MetroCluster 雙活 儲存系統， 利用 虛擬機器的 HA 技術 即可實現虛擬機器應用級別容災；

Ø  如果 受保護 的 應用伺服器為物理機，容災的 應用 伺服器為虛擬機器， 那麼利用 VMWare 的 P2V 技術 先對 物理機 做 一個 虛擬機器映象，並把該虛擬機器映象儲存在 DS900 雙活 儲存系統中， 物理 應用伺服器出現故障時，可以人為啟動該虛擬機器映象， 實現 應用級切換；

Ø  如果受 保護和容災的應用伺服器都需要是物理機，那麼 可以 利用 成熟 的雙機技術或是 物理 備機技術實現應用級容災，所謂物理備機就是 在 同城容災中心配置一套 相同 架構的物理伺服器， 並 配置成和應用伺服器相同的 軟體 環境， 當 生產應用伺服器出現故障時，管理員 手動 把這臺備機啟動，也可實現應用級容災。

2.5. 一體化 集中備份系統

考慮 到人為誤操作、病毒感染等 操作 所帶來的資料邏輯錯誤，建議對 各 委辦局以及本地兩個資料中心 的 關鍵資料 做 備份保護，結合以上 兩種 資料容災方案，形成完善的資料保護體系。

本 方案 需 配置 3 套 一體化備份系統， 其中 兩套 放置 在同城容災中心，一套放置在生產資料中心。 同城 容災中心的其中 1 套用於各委辦局關鍵資料在 同城 容災中心的集中備份， 另外 一套實現對 同城 容災中心 關鍵 資料的本地集中備份。 放置 在生產資料中心的 備份系統 實現對生產系統關鍵資料的本地集中備份。

如果 需要 把 關鍵資料在遠端也集中備份一份，那麼 需要在遠端的容災中心配置一臺容災伺服器和一個磁碟陣列，容災伺服器上配置備份系統的一個 Lan-Free 智慧客戶端模組，利用備份系統的 Datacopy 功能將本地備份的資料複製到遠端智慧客戶端所連線的磁碟陣列裡。備份網路需要租用運營商頻寬或建設專網，並要根據網路狀況和複製的資料量設定合適的時間點和策略。備份功能 架構圖如下所示。

 

備份 的資料可以是資料庫、虛擬機器映象，也可以是作業系統和 關鍵 檔案。 支援 LAN 備份 以及 Lan-Free 備份 模式。 對於 關鍵資料備份頻率可以 設定 為每週一次全備，每天做一次增量備份 或是 差異備份 ，本地區域網的頻寬較大，可適當加大備份的頻率。

如果各委辦局 或是本地 生產 資料 出現人為誤操作或是不可恢復的硬體故障所導致的資料邏輯錯誤時，可以利用本地 的 備份資料進行恢復， 取決於需要恢復的資料量 以及 容災鏈路頻寬 ， 一般恢復操作需要數小時甚至數天。 如果 本地的 備份 資料同樣出現 邏輯 故障，可以利用遠端的 備份 資料進行恢復 。

2.6. 容災網路 建設方案設計

容災通訊鏈路設計是容災系統建設非常重要的部分，也是容災方案設計的難點、要點之一，本章節對這一部分內容進行詳細描述。

不同的通訊鏈路有不同的要求，如距離限制、頻寬能力等；而不同的容災技術、不同的容災應用對通訊鏈路的要求不同；採用同步方式或採用非同步方式進行資料複製對通訊鏈路的要求也大不相同。

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

2.6.1.

根據其作用不同，網路系統分為計算網路、儲存網路和對外 服務 網路。其中計算網路用來實現伺服器裝置之間的通訊，根據對頻寬、延遲的不同要求，可以基於千兆、萬兆乙太網或是 Infiniband 、 Myrinet 等高效能網路構建；儲存網路用來實現伺服器和儲存裝置或是儲存裝置之間的資料通訊，通常基於 FC 、千兆和萬兆 IP 網路（ iSCSI 、 NFS 、 CIFS 等）或是 Infiniband 網路構建；服務網路用來為 網際網路或是區域網使用者提供服務， 對網路頻寬要求不高，通常採用百兆或是千兆乙太網路即可。

在設計網路系統的時候，計算、儲存和對外 服務 網路可以共用一套物理網路，但是為了提高系統可靠性，減少不同型別通訊之間的效能影響，建議這三套網路要實現物理隔離，各自構建自己的網路鏈路。另外，為了進一步提高 IT 系統可靠性和效能，計算網路和儲存網路一般採用雙網架構，雙網以主、備或是負載均衡模式工作。

 

 

 

 

經過以上分析，若要實現應用級的容災，那麼生產中心和容災中心之間通常需部署三種互聯鏈路，每種互聯鏈路所承載的資料不同，實現的功能不同，並且這三種鏈路在邏輯上相互隔離。

網路三層互聯。也稱為資料中心前端服務網路互聯，所謂 “前端服務網路”是指資料中心面向廣域網的出口。不同資料中心（主中心、災備中心）的前端網路透過 IP 技術實現互聯，客戶端透過前端網路訪問各資料中心。當主資料中心發生災難時，前端網路將實現快速收斂，客戶端透過訪問災備中心以保障業務連續性；

網路二層互聯。也稱為資料中心伺服器資料網路互聯。在不同的資料中心伺服器網路接入層，構建一個跨資料中心的大二層網路（ VLAN ），以滿足伺服器叢集或虛擬機器動態遷移等場景對二層網路接入的需求；

SAN 互聯。也稱為後端儲存網路互聯。藉助傳輸技術（裸光纖、 DWDM 、 FCIP 等）實現主中心和災備中心間磁碟陣列的資料複製。

2.6.2.

正常情況下，使用者、分支機構等都是連線到主資料中心，當主資料中心發生故障之後，使用者、分支機構等都應該能切換為與備份資料中心相連線，實現這種前端網路（客戶端）切換的技術主要有以下幾種：手工切換、 DNS 和 HTTP 重定向以及健康路由匯入等。

手工切換

手工切換的技術通常應用於異地災備中心或是同城容災中心。

例如：生產中心的 IP 子網為 A.B.0.0 ，正常情況下，使用者和分支機構都會透過這個網段來連線到生產中心，容災中心的子網也是設定為 A.B.0.0 ，但正常情況下容災中心的網段是關閉著的，當生產中心發生災難時，此時手動操作開啟容災中心的網段，使用者和分支機構不做任何修改便可以連線到容災中心。

這種方式操作最簡單，也不需要額外的裝置和技術支援，但是需要人工干預。

DNS 重定向

要實現 DNS 切換方式，在主資料中心和容災中心的部署中必須要有一個智慧的 DNS 裝置作為站點的域名解析 伺服器 ，當使用者需要訪問某一個應用伺服器時，系統首先會將請求傳送到資料中心的 DNS 伺服器 進行處理， DNS 裝置常具有應用感知功能，它可以監控資料中心 WEB 伺服器 、應用伺服器等的狀態。當主資料中心正常時， DNS 會將主資料中心伺服器的 IP 地址回給使用者，這時使用者就連線到主資料中心了。

當主資料中心發生災難時，主資料中心的 DNS 裝置檢測不到它的伺服器狀態，此時災備中心的 DNS 裝置便將備份資料中心伺服器的 IP 地址回給使用者，使用者連線到災備中心。

健康路由注入

健康路由匯入也是同城容災中心和雙活資料中心常使用的另一種網路切換技術。

要採用這種技術，生產中心和災備中心均需配置一套負載均衡裝置，資料中心的 負載均衡 裝置能探測資料中心後臺伺服器的健康狀況，如果探測到的伺服器狀況良好， 負載均衡 裝置便向 網路 中傳送一條與負載均衡裝置對應的資料中心伺服器的主機路由。對於生產中心和災備中心來說，它們發出的主機路由值不同，生產中心傳送低 Cost 值路由，災備中心傳送高 Cost 值路由。兩個資料中心都正常工作時，使用者傳送連線請求後會收到兩條 Cost 值不同的主機路由，通常情況下會選擇 Cost 值低的路由連線到生產中心。

當生產中心發生災難時，請求連線的使用者只能收到一條來自災備中心的高 Cost 值路由，使用者透過該路由連線到災備中心。

總結

以上幾種前端網路容災技術綜合比較如下：

對比項	手工切換	DNS方式	健康路由匯入
切換速度	分鐘	1分鐘	秒
客戶端軟體配置	不需要修改	不需要修改	不需要修改
增加裝置	不需要	增加DNS伺服器	增加負載均衡器
可擴充套件性 多中心，多伺服器	較低	高	高
分pei方法	靜態連線，使用者交易隨機傳送	可根據資料中心負載、使用者距離分配	只能在資料中心間平均分配

2.6.3.

在傳統的資料中心伺服器區網路設計中，通常將二層網路的範圍限制在網路匯聚層以下，透過配置跨匯聚交換機的 VLAN ，可以將二層網路擴充套件到多臺接入交換機，這種方案為伺服器網路接入層提供了靈活擴充套件能力。近年來，伺服器高可用叢集技術和虛擬伺服器動態遷移技術（如 VMotion ）在資料中心容災及計算資源調pei方面得以廣泛應用，這兩種技術不僅要求在資料中心內實現大二層網路接入，而且要求在資料中心間也實現大範圍二層網路擴充套件 (DCI: Data Center Interconnection) 。

EVI （ Ethernet Virtual Interconnection ，乙太網虛擬化互聯）是一種實現異構網路二層互聯的技術。 EVI 採用先進的 "MAC in IP" 技術，用於實現基於 IP 核心網路的 L2VPN 。透過 EVI 技術在站點的邊緣裝置上維護路由和轉發資訊，而無需改變站點內部和核心網路。

在 EVI 的組網方案中，不需要考慮資料中心之間的網路型別，只需要保證 EVI 邊緣裝置（ Edge Device ）之間 IP 可達就可以實現資料中心之間的二層互通。在 EVI 邊緣裝置之間建立 EVI 隧道，以太報文就可以透過該隧道到達另一個資料中心的二層域內，實現二層互聯互通。

EVI 技術可以結合 IRF 技術使用，從而保證邊緣裝置的 HA 效能和雙歸屬設計。另外，如果資料中心匯聚交換機也支援 IRF ，就可以有效提高邊緣裝置與資料中心匯聚交換機之間的鏈路頻寬利用率和 HA 效能。

EVI 組網方案的優點非常明顯：

支援 Overlay 網路，可以跨裸光纖、 MPLS 或是 IP 網路實現二層互聯；

EVI 配置簡單，只需要 6 條命令即可以啟動；

EVI 支援 IRF ，可以有效提高系統的 HA 效能。

2.6.4.

當前業界儲存網路容災方案的通訊鏈路有 “裸光纖直連交換機方式、透過 DWDM 裝置連線裸光纖方式、 IP 網路方式 ”等幾種，每種方式各有利弊，以下對不同通訊鏈路方式進行比較。

裸光纖直連

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

 

兩個中心儲存系統的容災埠透過光纖交換機和裸光纖進行連線，可以保證同步或非同步資料複製的效能。為保證高可用，通常採用冗餘連線鏈路設計。容災鏈路裸光纖可以和生產主機共享 SAN 交換機，也可以獨立 SAN 交換機（也需要冗餘）。通常為避免容災鏈路通訊和主機訪問儲存的相互干擾，採用獨立的 SAN 來連線容災通訊鏈路的方式採用較多。

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

CWDM/DWDM 直連裸光纖

採用密集波長分波多工技術，可以載入多協議，例如 FC 協議、 IP 協議，如下圖所示：

 

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

IP 網路連線

遠端容災中心儲存網路通常基於 IP 網路構建。採用 “基於儲存或基於虛擬儲存”的容災技術將需要進行 FC 協議到 IP 協議的轉換，從而將 FC 載入在 IP 網路中傳輸。此方案採用國際流行的 IP 網路協議和鏈路，透過 FC/IP 轉換裝置，將 FC 通道協議打包在 IP 資料包內，透過 IP 鏈路傳輸，理論上沒有距離的限制，適用於遠端非同步資料複製，是價效比很好的選擇。連線示意圖如下：

 

1.1. 解決好資料庫系統資料複製

各委辦局的業務系統普遍使用 Oracle 兩種資料庫，資料庫的資料包括資料檔案和日誌檔案，從原理上來說，資料庫複製包括資料檔案和日誌檔案的傳輸。

Oracle 資料庫複製，通常是在兩地部署資料庫系統，將主站點的資料庫全備份在備份站點恢復，此後即時傳輸變化的日誌檔案即可。對兩地容災的場景，日誌傳輸採用非同步的方式，不會影響主站點資料庫效能。目前容災系統上常用的 DataGuard 、 GoldenGate 、 SharePlex 等都是這種實現機制。

1.2. “現實”的切換策略

容災規劃中關於切換策略的制定，必須基於委辦局各業務系統的特點，預先制定並定期演練，以便確保容災系統有效執行。

切換方式分為兩種，即手工方式和自動方式．

手工方式

手工方式是對於複雜的應用系統進行容災切換的主要方式，手工方式需在備份中心按照對故障的判斷，啟動預先編寫的業務系統切換指令碼完成應用系統的切換過程．手工方式容災切換過程需要人為介入，因此，容災備份系統安全性以確保人員的安全以及對系統的訪問能力為基礎。

自動方式

自動方式可以實現應用系統的自動切換功能；保證當突發性災難發生時，即使在無人值守的情況下，也能夠實現系統的正常切換，確保業務系統能夠實現全天候的正常執行。但是由於應用系統的複雜性，自動方式要求能夠對使用者選擇的某類或某些業務種類的資料平臺、業務平臺和接入平臺按照正確的關係完整切換。更重要的是，自動方式需要對複雜的系統環境中的各種故障作出正確分析判斷，以根據事先定義的策略，觸發相應切換流程。這樣需要高度客戶化、智慧化的自動容災切換系統，目前沒有產品化技術可供選擇。

切換

當主生產中心發生的故障或災難影響到業務系統的正常執行時，應首先對業務系統的受影響程度進行檢查，儘可能快速定位業務系統的故障部位。分別對機房受損程度、機房電源、計算機網路、系統硬體、作業系統、資料庫、應用系統等進行檢查，評估恢復時間，然後由相應人員決策是否進行系統切換，應考慮以下因素和原則：

一 、 故障影響程度可以分為兩大類：

Ø  業務停頓，但故障範圍明確，並且可在可忍受的時間內修復，不需要異地切換。例如：電源發生故障、軟硬體故障、消防系統和空調系統等機房環境告警、人為因素誤操作的情況，應用系統應建立相應的本地高可用性系統、備份策略，管理流程，採用專業服務支援、基礎設施的防護等措施，來預防和避免故障對業務系統連續性執行的影響。

Ø  資料中心繫統在可以忍受的時間內無法恢復或徹底破壞，必須進行容災切換

二 、 優先選擇本地恢復原則

當無法判定主中心的業務系統修復所需時間時，應在繼續恢復主中心的系統的同時，在備份中心開始進行切換的準備工作。只要主中心的業務系統在可容忍時間內有恢復的可能，就應優先選擇本地恢復。

三 、 優先恢復關鍵性業務原則

對於應用系統的各個子系統，根據停機時間所造成的影響和損失的大小的不同，優先恢復關鍵性核心業務。當備份中心的主機、網路等資源不足時，優先提供給關鍵性核心業務使用。

回切

當主生產中心的系統恢復以後，就應將業務系統由容災中心回切到主生產中心。回切過程中要保證兩中心的資料的一致性。

一 、 業務影響最小原則

系統回切不同於系統切換，由於災難發生的隨機性和不確定性，系統切換都是在被動的情況下發生的，有可能造成業務資料的丟失和切換時間較長，對業務的正常進行會造成嚴重影響。而系統的回切是可以按照事先的計劃來實現的，因此在系統回切計劃中，應選擇業務量較小的時候，採用最簡化的步驟回切；

二 、 及時性原則

業務系統由主資料中心切換到容災中心後，核心資料不再有容災保護，因此應儘快恢復主資料中心，並將業務系統回切到主中心，使核心資料重新得到容災保護；

三 、 資料一致性原則

系統回切前需將資料由容災中心複製到主中心，並保持嚴格的一致性。

---

---

About Me

........................................................................................................................ ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub（ http://blog.itpub.net/26736162 ）、部落格園（ http://www.cnblogs.com/lhrbest ）和個人weixin公眾號（ xiaomaimiaolhr ）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162 ● 本文部落格園地址： http://www.cnblogs.com/lhrbest ● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址： ........................................................................................................................ ● QQ群號： 230161599 （滿） 、618766405 ● weixin群：可加我weixin，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友 （ 646634621 ） ，註明新增緣由 ● 於 2018-10-01 06:00 ~ 2018-10-31 24:00 在魔都完成 ● 最新修改時間：2018-10-01 06:00 ~ 2018-10-31 24:00 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ........................................................................................................................ ● 小麥苗的微店 ： ● 小麥苗出版的資料庫類叢書 ： http://blog.itpub.net/26736162/viewspace-2142121/ ● 小麥苗OCP、OCM、高可用網路班 ： http://blog.itpub.net/26736162/viewspace-2148098/ ● 小麥苗騰訊課堂主頁 ： https://lhr.ke.qq.com/ ........................................................................................................................ 使用 weixin客戶端 掃描下面的二維碼來關注小麥苗的weixin公眾號（ xiaomaimiaolhr ）及QQ群（DBA寶典）、新增小麥苗weixin， 學習最實用的資料庫技術。 ........................................................................................................................