1. 技術背景

1.1.? 災備評價指標

業界普遍數據丟失量和系統恢復時間作為標準，對某個容災系統進行評價，公認的評價標準是RPO和RTO。
　　RPO（RecoveryPointObjective）：恢復點目標，以時間為單位，即在災難發生時，系統和數據必須恢復到的時間點要求。RPO標志系統能夠容忍的最大數據丟失量，系統容忍丟失的數據量越小，RPO的值越小。
　　RTO(RecoveryTimeObjective)：恢復時間目標，以時間為單位，即在災難發生后，信息系統或業務功能從停止到必須恢復的時間要求。RTO標志系統能夠容忍的服務停止的最長時間。系統服務的緊迫性要求越高，RTO的值越小。
　　RPO針對的是數據丟失，RTO針對的是服務丟失，兩者沒有必然的聯系，并且兩者的確必須在進行風險分析和業務影響分析之后根據業務的需求來確定。

?

1.2.? 災難恢復能力等級

要建設容災系統，就必須提出相應的設計指標，以此作為衡量和選擇容災解決方案的參數。目前，國際上通用的容災系統的評審標準為SHARE 78，主要包括以下內容。
　　●備份/恢復的范圍
　　●災難恢復計劃的狀態
　　●業務中心與容災中心之間的距離
　　●業務中心與容災中心之間如何連接
　　●數據是怎樣在兩個中心之間傳送的
　　●允許有多少數據丟失
　　●保證更新的數據在容災中心被更新
　　●容災中心可以開始容災進程的能力
　　SHARE 78是建立容災系統的一種評審標準。建立容災系統的最終目的，是為了在災難發生后能夠以最快速度恢復數據服務，主要體現在RTO和RPO上。在SHARE?78的基礎上，國家質量監督檢驗檢疫總局和國家標準化管理委員會聯合制定規范了適合我國國情的RTO/RPO與災難恢復能力等級的關系。

RTO/RPO與災難恢復能力等級的關系表：

等級	RPO	RTO	備注
1級	2天以上	1天至7天	<0.1%
2級	24小時以上	1天至7天	90%
3級	12小時以上	數小時至1天	6%
4級	數小時至2天	數小時至1天	<0.5%
5級	數分鐘至2天	0至30分鐘	<0.1%
6級	數分鐘	0	3%

?

1.3.? 容災的分類

由于容災包含的內容比較廣泛，對容災的分類也可以從多個方面進行。總的來講，可以從容災的范圍和容災的內容來區分。

從容災的范圍講，容災可以分成本地容災，近距離（同城）容災和遠距離（異地）容災。這三種容災能容的災難是不相同的，采用的容災技術也是不同的。

從容災的層次講，容災又可以分成數據容災和應用容災，數據容災是應用容災的基礎，沒有數據的一致性，就沒有應用的連續性，應用容災也是無法保證的。數據容災是指建立一個備用的數據系統，該備用系統對生產系統的關鍵數據進行備份。

應用容災則是在數據容災之上，建立一套與生產系統相當的備份應用系統。在災難發生后，將應用迅速切換到備用系統，備份系統承擔生產系統的業務運行。

?

1.4.? 主流數據容災技術

1.4.1.?? 數據備份

數據備份是系統、數據容災的基礎，也是低端容災的實現，是高端容災（實時數據保護）的有力保障。目前備份技術主要有快照備份、離線備份、異地存儲備份。備份系統通過備份策略，對計算機信息系統的操作系統、文件系統、應用程序、數據庫系統等數據集，實現某一時間點的完整拷貝，拷貝的數據處在非在線狀態，不能被立刻訪問，必須通過相應操作，如恢復等方式使用備份數據。這也解決了高端容災（實時數據保護）不能解決的問題：人為誤操作、惡意性操作等，這類操作，計算機系統是不能區分的，一旦執行，將造成數據中心、災備中心同時修改；對于數據庫系統，在日志方式下，可以通過回滾方式修改，對于文件系統、操作系統等其他配置信息是不能回滾的，將造成毀滅性的結果。因此在建設高端容災系統的前提，一定要做好本地系統的備份，這是容災技術的起點。

目前成熟的備份軟件有Symantec NetBackup、EMC Legato，IBM TSM，HP Protect Server等等。

?

1.4.2.?? 實時數據保護

實時數據保護，就是在多塊磁盤上、多個陣列、多臺服務器、多個數據中心實時的保存同一份數據的多份存儲，目的是為了避免物理故障，數據不會因為一塊磁盤、一個陣列、一臺服務器、一個數據中心的故障，而不能訪問。

實時數據保護需要以數據備份作為前提，它不能防范人為誤操作和惡性操作。這里我們要強調容災的目的是讓數據在災難發生時，還能被訪問，通過實時數據保護，保證數據的完整性；因此實時數據保護是容災手段，而不是目的。目前實時數據保護的技術主要有兩種：數據鏡像和數據復制。

?

1.4.2.1.??? 數據鏡像（Mirroring）

數據鏡像（Mirroring）是冗余的一種類型，一個磁盤上的數據在另一個磁盤上存在一個完全相同的副本即為鏡像。數據鏡像分為軟件鏡像與硬件鏡像，鏡像軟件有Symantec Volume Manager；各硬件廠商都有基于自己陣列的硬件鏡像方式。

在通過SAN的支持，DWDM的拓展，光纖網絡可以擴展到100公里或更遠，鏡像可以在較遠的兩個數據中心的磁盤上建立。但由于鏡像系統是以同步方式實現的，受到距離、光纖協議、和相關協議轉換的影響，同步方式會影響本地服務器的性能，所以，一般建議在<20公里的同城容災中使用，在遠程容災中可作為一種加強方案與遠程容災方案整合。

基于SAN的鏡像支持所有的類型數據同步，包括文件數據、數據庫數據、裸設備、應用配置文件、應用程序、庫函數等，因而支持各類應用系統容災，包括數據庫、中間件、客戶自己開發的應用，適用于2層架構、3層或多層應用架構。

?

1.4.2.2.??? 數據復制（Replication）

數據復制（Replication）是將一個原數據的及其改動，通過后續機制拷貝到另外一處，可以是另一個磁盤、另一個陣列、另一個服務器、另一個數據中心。由于實現的機制不同，又分為同步復制和異步復制兩種方式。同步復制，能夠確保兩份數據完全一致，但對系統的影響較大，一般不會采用；異步復制，通過后續機制，確保將本地改動的數據復制的異地，對系統的影響較小，但數據同步有延遲，是目前實現遠程數據同步的主要方法。

根據實現機制，數據復制分為軟件方式和硬件方式；硬件方式往往又被稱為遠程鏡像。此外還有數據庫復制和基于SAN的卷復制。

軟件復制有Symantec Volume Replicator(簡稱VVR)、Datacore 等，軟件復制可以跨硬件平臺，可以實現多廠商集成，其中VVR是基于卷的復制，復制的數據可以是數據庫中的數據（文件方式或裸設備方式），數據庫日志，復制的數據也可以是各種文件，如應用和數據庫配置文件，應用程序，庫文件，等等。Datacore是基于block的復制，類似于硬件的復制，處于卷的更底層，與基于卷的復制不同的是，他具有應用操作系統的獨立性，數據的遠程復制與操作系統無關，并且不需要遠端主機應用系統的運行，支持異步和同步的方式，并且與硬件存儲子系統不同的是，Datacore可以實現異構存儲子系統的集中管理，打破了單一廠商選擇的限制，對于磁盤子系統的選擇更加靈活。

硬件復制一般是相同品牌之間的磁盤子系統的操作。具有一定的限制性，純硬件復制有HDS TrueCopy、EMC SRDF等。硬件復制通過基于硬件的遠程磁盤鏡像實現，其實現要求嚴格。只能基于同一廠商、同樣容量大小的兩個陣列來實現。受光纖線路影響、復制數據量大，在使用間歇性復制時，數據延遲大，磁盤容量要求4倍于源數據，并且在極端情況下，不能保證數據一致性。廠商一般建議使用間歇性復制。遠程磁盤鏡像（復制），在容災實現中，支持所有的類型數據同步，包括文件數據、數據庫數據、裸設備、應用配置文件、應用程序、庫函數等，支持各類應用系統容災，包括數據庫、中間件、客戶自己開發的應用，適用于2層架構、3層或多層應用架構。

數據庫復制，Oracle Data Guard、Oracle GoldenGate、Quest SharePlex、DSG RealSync等，通過分析數據庫Redo Log和Archive Log 實現日志的復制，將分析結果直接或轉化為SQL語句傳到容災中心，在容災中通過心Apply數據庫日志或將日志轉化的SQL語句重做，來保證容災中心數據與生產中心數據一致。但數據庫復制也存在如下限制：一是數據庫復制，是專門針對相應數據庫的，只能實現單一的數據庫復制。如果有ORACLE、SQLSERVER等多種數據庫，就必須采用相互各不相同的數據庫復制技術，管理和維護工作非常復雜；二是數據庫復制技術不是一個完整的容災解決方案，只能有限的復制數據庫數據，不能復制其他的應用程序，配置文件，就是Oracle自己的tnsnames.ora, listner.ora，initSID.ora, *.ctl也不能復制，一旦這些文件改動過，將需要管員人為操作或者需要其他軟件的管理，保證容災中心與生產中心同步應用、程序、配置文件同步。

基于SAN網絡的卷復制是一種新的復制方式，如Datacore的SDS。它是通過特殊的運行于操作系統上的SDS SAN 控制器，實際是將低端的無智能存儲變為高端的智能存儲，使得他們得以建立基于智能SAN 控制器的卷，通過這種與主機應用無關，但與SDS控制器直接相關的卷實現復制。此種技術較新，目前具有多家廠商均向此方向發展，其中Datacore是較早的研發廠商，當中還有IBM的SVC和HDS的USP系列以及飛康CDP也是采用此種技術。

?

1.5.? 應用和網絡容災

數據復制是容災的手段，不是目的，容災的目的是數據的訪問，因此應用的恢復和網絡的恢復也是容災的關鍵。

應用系統恢復，這和系統的應用模式直接相關。需要考慮應用系統的應用架構。是Client/Server架構，還是Broswer/Server架構；是2層架構、還是3層架構、還是多層架構。兩層架構，表示容災中心的應用只要啟動數據庫就可以服務了。如果是三層架構，就意味著應用系統除數據庫以外，還有網絡服務程序，如中間件WebLogic。在容災應用切換時，能夠手工或自動化的將這些服務一一啟動。

在災難發生后，應用切換到災備中心了，本地的應用前端需要重新訪問容災節點的服務，帶來另外一個問題，網絡如何切換。實際上最簡單的辦法，就是通過外部DNS服務器，

在災難發生后，本地應用訪問路徑如何由指向原生產中心改為指向容災中心。在災難修復后，又需要指向原生產中心。最簡單得方法就是更改外部DNS服務器得IP映射關系。在災難發生前，IP映射為生產中心服務器；在災難發生后，IP由映射為容災中心得服務器；在災難修復后，IP又映射為生產中心得服務器。

當然，在一些中間件軟件中，支持多服務器、多IP的配置，那也是可以考慮的。

?

1.6.? 容災切換

就是在災難發生后，數據庫切換、應用重新啟動、網絡實現切換等等，容災中心接管原生產中心的整個過程；同時還包含了在原數據中心修復后，數據庫、應用、網絡需要重新切回來的整個過程。這些過程，可以通過手工切換、也可以通過自動化過程完成。

?

1.7.? 容災演練

大部分的容災方案，在項目實施后，很難有機會來實現預演，因為對于大部分方案來說，這種預演活動，需要耗費大量的人力財力。

但是這種預演是必不可少的，它是實時測試目前的容災方案的漏洞，保證容災方案在災難發生時，能夠真正生效。

?

?

2. 災備系統建設

2.1.? 災備系統選型要素

容災技術的選擇，是一個以業務容災需求為核心，多種因素綜合權衡的過程。容災技術選擇所需考慮的因素
一、業務分析結果
　　容災系統建設應根據業務分析結果選擇合適的容災技術并確定具體的實現策略，以滿足業務恢復時相應的RTO、RPO指標。
二、業務關聯程度
　　在進行容災技術選擇時，需要考慮到核心業務系統各種業務之間的關聯關系。業務關聯緊密，數據的藕合程度高，可能會造成所有關聯的業務都要采用同一種容災技術，業務關聯松散，數據的藕合程度低，可能會針對不同的業務要求進行區分，分別采用不同的容災技術。
三、系統現狀
　　核心業務系統容災技術必須充分考慮與現有系統的配合。現有核心業務系統的應用分布、應用的實現方式、硬件設備平臺的種類、存儲數據量的大小、IO吞吐量的大小等，都會對容災技術的選擇產生影響。
四、技術成熟度
　　容災系統必須采用成熟可靠的技術，保證系統特續，穩定的運行。該技術應具有類似于電信業務運營支撐系統容災建設的成功案例，不能由于技術手段的不成熟或不穩定而增加核心業務系統新的風險。
五、容災系統環境
　　核心業務系統容災技術必須考慮生產中心與容災中心之間的距離，網絡環境等因素，不同的技術對距離，網絡帶寬的要求會有所不同。
六、管理維護難度
　　不同的容災技術對管理維護的要求各不相同，在同等條件下，應采用易于管理和維護的容災技術。
七、成本分析
　　不同的容災技術對軟硬件投資，實施維護成本的要求各不相同，在同等條件下，應采用總體成本最小的容災技術。

?

2.2.? 災難事件分析

我們擬通過災備系統實現如下災難事件的處理。

?

2.2.1.?? 數據庫邏輯損壞

由于誤操作等原因，數據庫會出現表的記錄丟失或損壞情況。面對這種災難，需要借助于快照技術將將丟失或損壞的記錄導入到生產數據庫中。

可采用ORACLE自身的機制或者CDP等快照技術事項，整個過程生產數據庫不停止。對于這種災難，可實現平臺RPO=0，RTO=0，但對相關業務有影響。

?

2.2.2.?? 存儲級故障

磁盤陣列故障是一種極為嚴重的威脅，對于業務系統具有致命的殺傷力。IDC機房存儲故障將直接導致核心數據庫宕機，導致相關業務系統的完全癱瘓。

這種情況下必須啟動本地災備系統實現數據庫的遷移，或者啟動異地災備系統，實現應用的遷移。

對于該故障，可以采用DATAGUARD、存儲級復制、CDP技術加以處理。其中采用ORACLE自身的DATAGUARD機制將有分鐘級別的數據丟失和服務中斷，使用存儲級復制和CDP技術可實現數據庫不中斷運行，而且數據丟失為零。

?

2.2.3.?? 核心網絡設備故障

這種情況下往往導致對外服務完全中斷或或者產能受嚴重影響，必須啟用異地災備中心。

?

2.2.4.?? 運營商災難

主要指運營商機房供電或者核心出口鏈路發生故障，導致業務系統全線中斷，在RTO時間內無法修復的建議需要切換到異地災備中心。

?

2.2.5.?? 地區性災難

地區性災難主要指城市級別的災難，比如地震、海嘯等不可抗力，這種情況下往往導致IDC機房對外服務完全中斷，必須啟用異地的災備中心。

?

2.3.? 理想的容災系統

容災系統的建立，通常需要通過分步實施，逐漸建立一套完善的系統容災解決方案。理想的容災系統有如下典型的特征：

一、擁有完備的本地數據備份

通過相應的備份軟件，對目前所有的計算機系統，做好完善的數據備份，特別是做好操作系統備份、文件系統備份、數據庫系統文件備份、數據庫數據文件備份、相關的核心應用程序備份；建立好完善的備份/恢復機制和遠程磁帶保管機制。

這也是實現遠程數據復制容災的基礎，容災中心與生產中心的數據初始化同步，一般都是通過磁帶備份恢復方式，實現一個同步起點。

二、存儲、應用整合

存儲整合是指通過相關的產品選擇，將各服務器的數據、或應用，通過基于一定的管理及后續，實現數據的快照、鏡像等技術，遷移到外置基于SAN的陣列庫中，通過唯一的管理接口，實現統一管理，屏蔽不同廠商陣列的差異。

三、異地實時數據同步

?????? 為了控制RTO，異地災備中心必須采用有效的數據同步機制和主生產進行實時的數據同步，確保災難發生時業務系統可以進行高效的切換，而對數據的丟失也控制在合理的水平。

四、擁有可靠的同城堡壘節點

同城災備中心主要是用于防范生產中心機房或樓宇發生的災難，異地災備中心用于防范大規模區域性災難。同城災備中心由于其與生產中心處于同一個城市，可采用較好的網絡線路如光纖與生產中心進行連接，因此數據復制和應用切換比較容易實現，可實現生產與災備中心之間數據的實時復制和應用的快速切換。

五、擁有可靠的異地容災節點

異地災備中心由于其與生產中心不在同一城市，災備端與生產端連接的網絡線路帶寬和質量存在一定的限制，一般適合于數據的異步復制，應用系統的切換也需要一定的時間，因此異地災備中心可以實現在業務限定的時間內進行恢復和可容忍丟失范圍內的數據恢復。

?

總結

以上是生活随笔為你收集整理的灾备理论-可靠的异地灾备的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。