容災項目方案設計容災項目設計方案目錄TOC\o"1-4"\h\z\u第1章 容災技術規范 41.1 容災的總體規劃 41.1.1 技術指標RPO、RTO 41.1.2 國際標準SHARE

78 5 Tier0 6 Tier1 7 Tier2 7 Tier3 8 Tier4 8 Tier5 8 Tier6 91.1.3 界定災備系統的適用范圍 91.1.4 界定災備建設的目標 91.1.5 界定災備系統的總體架構 10第2章 主流容災技術說明 122.1 數據備份 122.2 實時數據保護 122.2.1 數據鏡像（Mirroring） 132.2.2 數據復制（Replication） 13 軟件復制 13 硬件復制 15 數據庫復制 18 DatacoreSDS 192.3 應用系統恢復 192.4 網絡系統恢復 192.5 容災切換過程 202.6 消防演習 20第3章 主流容災技術分析與對比 213.1 數據備份 213.2 實時數據保護 223.2.1 數據鏡像（Mirroring） 22 硬件鏡像 22 軟件鏡像 22 軟件智能存儲鏡像 23 鏡像技術在容災中的利用 233.2.2 數據復制（Replication） 23 軟件復制（卷復制） 24 硬件復制 24 基于軟件控制器的復制 25 數據庫復制 253.3 應用系統恢復 273.4 網絡系統恢復 29第4章 容災系統設計步驟 294.1 第一步，深化數據備份系統 304.2 第二步，存儲、應用整合 314.2.1 存儲整合 314.2.2 應用整合 314.3 第三步，實現遠程實時數據卷保護 314.4 第四步，建立遠程切換消防演習機制 324.5 第五步，建立遠程切換機制 32第5章 數據容災的性能分析 325.1 同步數據容災的性能分析 325.1.1 帶寬 335.1.2 距離 335.1.3 中間鏈路設備和協議轉換的時延 345.2 異步數據容災的性能分析 36

容災技術規范作為風險防范系統，災備系統建設本身在總體規劃、方案選擇和投產實施后的管理運行，以及真正面對災難時的切換操作等方面也存在著潛在的風險。

計算機信息系統實現數據大集、應用大集中后，系統的運行安全成為風險控制的焦點。目前，已經有多系統開始或準備進行災備系統的建設，災備系統建設的目標是減災容災，使計算機信息系統和數據能夠最大限度地防范和化解各種意外和災害所帶來的風險。然而，與大多數工程一樣，災備系統建設本身在總體規劃、方案選擇和投產實施后的管理運行，以及真正面對災難時的切換操作等方面也存在著潛在的風險。

可以說，風險防范系統本身也存在風險點，需要小心應對。

災備系統建設中所涉及的潛在風險大致可分為技術風險、管理風險和投資風險，其中尤以技術選擇風險最大，技術方案選擇優越，可以規避一定的管理風險和投資風險。而這三者也存在內在的相互關聯，不同災備級別對應的建設投資規模、所采用的技術以及實施和管理的復雜度也不同，應考慮保護計算機系統的原有投資并提高災備系統建設投資的利用率。容災的總體規劃

真正的容災是數據被不間斷的一致性訪問！在災難備份的世界里，是有等級觀念的，級別不同，災備系統所采用的技術和達到的功能是不同的，在系統建設資金投入方面的差距也很巨大。所以，對用戶來說，明確災備系統建設的總體規劃十分必要。技術指標RPO、RTO衡量容災技術的兩個技術指標RPO、RTORPO(RecoveryPointObjective):以數據為出發點，主要指的是業務系統所能容忍的數據丟失量。及在發生災難，容災系統接替原生產系統運行時，容災系統與原生產中心不一致的數據量。RPO是反映恢復數據完整性的指標，在同步數據復制方式下，RPO等于數據傳輸時延的時間；在異步數據復制方式下，RPO基本為異步傳輸數據排隊的時間。在實際應用中，考慮到數據傳輸因素，業務數據庫與容災備份數據庫的一致性（SCN）是不相同的，RPO表示業務數據與容災備份數據的SCN的時間差。發生災難后，啟動容災系統完成數據恢復，RPO就是新恢復業務系統的數據損失量。RTO(RecoveryTimeObjective):以應用為出發點，即應用的恢復時間目標，主要指的是所能容忍的應用停止服務的最長時間，也就是從災難發生到業務系統恢復服務功能所需要的最短時間周期。是反映業務恢復及時性的指標，表示業務從中斷到恢復正常所需的時間。RTO值越小，代表容災系統的數據恢復能力越強。各種容災解決方案的RTO有較大差別，基于光通道技術的同步數據復制，配合異地備用的業務系統和跨業務中心與備份中心的高可用管理，這種容災解決方案具有最小的RTO。容災系統為獲得最小的RTO，需要投入大量資金。不同容災方案的RTO和RPO是不相同的。國際標準SHARE

78要建設容災系統，就必須提出相應的設計指標，以此作為衡量和選擇容災解決方案的參數。目前，國際上通用的容災系統的評審標準為SHARE78，主要包括以下內容。

●備份/恢復的范圍

●災難恢復計劃的狀態

●業務中心與容災中心之間的距離

●業務中心與容災中心之間如何連接

●數據是怎樣在兩個中心之間傳送的

●允許有多少數據丟失

●保證更新的數據在容災中心被更新

●容災中心可以開始容災進程的能力

SHARE78是建立容災系統的一種評審標準。建立容災系統的最終目的，是為了在災難發生后能夠以最快速度恢復數據服務，主要體現在RTOObjective)和RPO上。SHARE

78,

M028報告中定義的災備的七個級別和與其對應的數據丟失量與恢復時間情況詳見下表：

災難備份等級與業務恢復情況對照表等級描述RPORTO企業百分比0級無災備計劃--<0.3%1級車輛運送方式24~48小時>48小時<0.1%2級車輛運送＋熱備份24~48小時24小時90%3級電子傳送<24小時<24小時6%4級活動狀態備份中心秒級<24小時<0.5%5級兩中心、兩階段確認秒級<2小時<0.1%6級零數據丟失零丟失<2小時3%Tier0Tier0-無異地數據備份(Nooff-siteData)Tier0被定義為沒有信息存儲的需求，沒有建立備份硬件平臺的需求，也沒有發展應急計劃的需求，數據僅在本地進行備份恢復，沒有數據送往異地。這種方式是最為低成本的災難備份解決方案，但事實上這種災難備份并沒有真正災難備份的能力，因為它的數據并沒有被送往遠離本地的地方，而數據的恢復也僅是利用本地的記錄。Tier1Tier1-PTAM車輛轉送方式(PickupTruckAccessMethod)作為Tier1的災難備份方案需要設計一個應急方案，能夠備份所需要的信息并將它存儲在異地，然后根據災難備份的具體需求，有選擇地建立備份平臺，但事先并不提供數據處理的硬件平臺。PTAM是一種用于許多中心備份的標準方式，數據在完成寫操作之后，將會被送到遠離本地的地方，同時具備有數據恢復的程序。在災難發生后，一整套系統和應用安裝動作需要在一臺未啟動的計算機上重新完成。系統和數據將被恢復并重新與網絡相連。這種災難備份方案相對來說成本較低(僅僅需要傳輸工具的消耗以及存儲設備的消耗)。但同時有難于管理的問題，即很難知道什么樣的數據在什么樣的地方。一旦系統可以工作，標準的做法是首先恢復關鍵應用，其余的應用根據需要恢復。這樣的情況下，恢復是可能的，但需要一定的時間，同時依賴于什么時候硬件平臺能夠被提供準備好。Tier2Tier2-PTAM卡車轉送方式+熱備份中心(PTAM+HotSite)Tier2相當于是Tier1再加上具有熱備份能力中心的災難備份。熱備份中心擁有足夠的硬件和網絡設備去支持關鍵應用的安裝需求。對于十分關鍵的應用，在災難發生的同時，必須在異地有正運行著的硬件平臺提供支持。這種災難備份的方式依賴于用PTAM的方法去將日常數據放在異地存儲，當災難發生的時候，數據再被移動到一個熱備份的中心。雖然移動數據到一個熱備份中心增加了成本，但卻明顯降低了災難備份的時間。Tier3Tier3-電子傳送(ElectronicVaulting)Tier3是在Tier2的基礎上用電子鏈路取代了車輛進行數據傳送的災難備份。接收方的硬件平臺必須與生產中心物理地相分離，在災難發生后，存儲的數據用于災難備份。由于熱備份中心要保持持續運行，因此增加了成本。但確實是消除了運送工具的需要，提高了災難備份的速度。Tier4Tier4-活動狀態的備份中心(ActiveSecondarySite)Tier4這種災難備份要求兩個中心同時處于活動狀態并管理彼此的備份數據，允許備份行動在任何一個方向發生。接收方硬件平臺必須保證與另一方平臺物理地相分離，在這種情況下，工作負載可以在兩個中心之間被分擔，兩個中心之間之間彼此備份。在兩個中心之間，彼此的在線關鍵數據的拷貝不停地相互傳送著。在災難發生時，需要的關鍵數據通過網絡可迅速恢復，通過網絡的切換，關鍵應用的恢復時間也可降低到了小時級。Tier5Tier5-兩中心兩階段確認(Two-SiteTwo-PhaseCommit)Tier5是在Tier4的基礎上在鏡像狀態上管理著被選擇的數據(根據單一commit范圍，在本地和遠程數據庫中同時更新著數據)，也就是說，在更新請求被認為是滿意之前，Tier5需要生產中心與備份中心的數據都被更新。我們可以想象這樣一種情景，數據在兩個中心之間相互映像，由遠程two-phasecommit來同步，因為關鍵應用使用了雙重在線存儲，所以在災難發生時，僅僅傳送中的數據被丟失，恢復的時間被降低到了小時級。Tier6Tier6-零數據丟失(ZeroDataLoss)Tier6可以實現零數據丟失率，同時保證數據立即自動地被傳輸到備份中心。Tier6被認為是災難備份的最高的級別，在本地和遠程的所有數據被更新的同時，利用了雙重在線存儲和完全的網絡切換能力。Tier6是災難備份中最昂貴的方式，也是速度最快的恢復方式，恢復的時間被降低到了分鐘級。對于Tier6的災難備份解決方案，可以應用兩種遠程拷貝技術來實現，即PPRC同步遠程拷貝和XRC異步遠程拷貝。因此，企業需要根據其計算機處理系統中數據的重要性，以及需要恢復的速度和程度，來進行災備系統建設的整體考慮和不同災難對業務沖擊的分析，并最終確定災備系統建設的總體規劃。災備系統建設的總體規劃應包括以下幾個方面：界定災備系統的適用范圍分析不同的應用系統，確定災備系統是一個覆蓋整個計算機系統的工程，根據業務的重要性，對不同的系統采用不同級別的容災方案，如針對關鍵的業務應用子系統，實施高級別的容災工程；對低級別的業務系統，實施低級別的容災工程。總之要建立一個綜合性的整體災備建設工程。界定災備建設的目標

生產系統在單位時間內的數據處理能力或IO流量確定的情況下，RPO實際上成為一個反映災備恢復過程中的數據丟失量的指標。而RTO則是指從災難發生到備份系統可以接管原有生產系統所需要花費的時間，這不僅要考慮數據的恢復時間，還應該考慮恢復后數據的完整性、一致性的修復和確認、備份中心計算機處理系統的啟動和備份中心的網絡切換等全部時間。總體規劃中應為災備系統設定明確的RPO和RTO指標。但是設計容災系統不能只看RTO和RPO，對于不同的業務系統和用戶特殊的要求，其它一些指標有可能成為選擇容災解決方案的主要因素。例如，某些地區為了防范一些特定自然災害的風險，要求容災備份中心與業務中心保持足夠的距離，在這種情況下，容災備份中心與業務中心的距離要求就是容災系統的重要指標。通信網絡是容災系統的組成部分，通信線路的質量也是容災系統的性能指標之一，其中包括網絡的數據傳輸帶寬、網絡傳輸通道的冗余和網絡服務商的服務水平（網絡年中斷率）。如果容災系統使用的通信網絡是確定的，為了比較不同容災解決方案，可以用單位存儲容量的數據庫在同一通信網絡上的數據完全恢復時間作為一項設計指標。大部分業務系統都是數據庫應用結構，但業務系統容災并不等于是數據庫容災，還包括訪問數據庫的應用程序和相關配置信息。實現數據庫容災是容災的基礎，在保障數據庫數據一致的前提下，還要實現應用程序和配置信息的一致性；實現應用系統的高可用性、應用程序在容災中心與生產中心接管和切回的過程，因此，還要考慮應用的模式是C/S、B/S，兩層、三層、多層次的應用結構等等。界定災備系統的總體架構

根據實際需求、現有技術、所在地域、計劃防范的災難種類和預算投入的資金量等實際情況，確定災備系統預期達到的級別，并以此來確定災備系統與生產運行系統在地理位置上的距離（同城還是異地或兩者兼備－堡壘節點），備份數據存儲所在的介質（磁盤還是磁帶或兩者兼備），備份數據在生產中心與備份中心傳輸的方式（這就涉及到了具體的計算機存儲與網絡技術），以及備份中心計算機系統的處理能力和網絡接管所需的具體架構（是否與生產中心采用完全同等數量、容量和性能的計算機、存儲設備和網絡體系結構）。主流容災技術說明數據備份數據備份是系統、數據容災的基礎，也是低端容災的實現，是高端容災（實時數據保護）的有力保障。目前備份技術主要有快照備份、離線備份、異地存儲備份。備份系統通過備份策略，對計算機信息系統的操作系統、文件系統、應用程序、數據庫系統等數據集，實現某一時間點的完整拷貝，拷貝的數據處在非在線狀態，不能被立刻訪問，必須通過相應操作,如恢復等方式使用備份數據。這也解決了高端容災（實時數據保護）不能解決的問題：人為誤操作、惡意性操作等，這類操作，計算機系統是不能區分的，一旦執行，將造成數據中心、災備中心同時修改；對于數據庫系統，在日志方式下，可以通過回滾方式修改，對于文件系統、操作系統等其他配置信息是不能回滾的，將造成毀滅性的結果。因此在建設高端容災系統的前提，一定要做好本地系統的備份，這是容災技術的起點。目前成熟的備份軟件有SymantecNetBackup、EMCLegato，IBMTSM，HPProtectServer等等。實時數據保護實時數據保護，就是在多塊磁盤上、多個陣列、多臺服務器、多個數據中心實時的保存同一份數據的多份存儲，目的是為了避免物理故障，數據不會因為一塊磁盤、一個陣列、一臺服務器、一個數據中心的故障，而不能訪問。注意，實時數據保護需要以數據備份作為前提，它不能防范人為誤操作和惡性操作。這里我們要強調容災的目的是讓數據在災難發生時，還能被訪問，通過實時數據保護，保證數據的完整性；因此實時數據保護是容災手段，而不是目的。目前實時數據保護的技術主要有兩種：數據鏡像和數據復制。數據鏡像（Mirroring）數據鏡像（Mirroring）是冗余的一種類型，一個磁盤上的數據在另一個磁盤上存在一個完全相同的副本即為鏡像。分軟件鏡像與硬件鏡像，它們的的區別就在于實現鏡像所需的CPU周期所處的位置。最終，都是根據程序的指令，為硬件（磁盤，以及磁盤上存儲的數據）制作一個鏡像副本。鏡像可以保證兩份數據完全一樣。鏡像軟件有SymantecVolumeManager；各硬件廠商都有基于自己陣列的硬件鏡像方式。數據復制（Replication）數據復制（Replication）是將一個原數據的及其改動，通過后續機制拷貝到另外一處，可以是另一個磁盤、另一個陣列、另一個服務器、另一個數據中心。由于實現的機制不同，又分為同步復制和異步復制兩種方式。同步復制，能夠確保兩份數據完全一致，但對系統的影響較大，一般不會采用；異步復制，通過后續機制，確保將本地改動的數據復制的異地，對系統的影響較小，但數據同步有延遲，是目前實現遠程數據同步的主要方法。根據實現機制，數據復制分為軟件方式和硬件方式；硬件方式往往又被稱為遠程鏡像。軟件復制有SymantecVolumeReplicator；Datacore等；其中Symantec是基于卷的復制，Datacore是基于block的復制，類似于硬件的復制，純硬件復制有HDSTrueCopy、EMCSRDF等。其中軟件復制是可以跨硬件平臺，可以實現多廠商集成，一般硬件復制則是相同品牌之間的磁盤子系統的操作。具有一定的限制性。軟件復制SymantecVolumeReplicator(簡稱VVR)負責遠程數據復制。VVR復制基于Volume進行。復制的數據可以是數據庫中的數據（文件方式或裸設備方式），數據庫日志，復制的數據也可以是各種文件，如應用和數據庫配置文件，應用程序，庫文件，等等。復制的示意圖見圖四。VVR與VxVM完全集成在一起。用VxVM管理界面和命令統一配置管理；由于VVR僅僅將Volume上每次I/O的實際數據實時復制到遠程節點，所以在網絡線路上傳輸的數據量很少，對帶寬的需求也很小，因此也與應用無關，只要是在定義的復制卷上的任何操作，都會被復制到異地。 Datacore則是基于軟件的塊設備復制，處于卷的更底層，屬于塊設備的遠程復制，與基于卷的復制不同的是，他具有應用操作系統的獨立性，數據的遠程復制與操作系統無關，并且不需要遠端主機應用系統的運行，支持異步和同步的方式，并且與硬件存儲子系統不同的是，Datacore可以實現異構存儲子系統的集中管理，打破了單一廠商選擇的限制，對于磁盤子系統的選擇更加靈活。其復制示意圖如下：通過整合原有存儲子系統以及新購的存儲子系統，將數據的改動記錄在Datacore的SDS設備當中，采用存儲轉發的傳輸機制，利用cache的技術和buffer的技術，記錄數據的改變，然后通過傳輸機制將所有應用的數據傳輸到對端，該軟件支持一對多的遠程復制。類似于硬件復制，但是可以不受品牌限制。硬件復制以EMC的SRDF為例，如下圖：1．系統定期檢測磁盤物理數據塊的改變狀況。如果發現有數據塊改動，將會被系統記錄，并一次性將改動過的數據塊考到復制緩存，這一動作被稱為Switch。拷貝到緩存中的數據塊，在下一個Switch來臨之前，被復制到異地相應的陣列緩存中。在下一個Switch時，本地數據塊被復制到本地存中，而異地緩存中上一次被改動過的數據塊才被復制到容災系統中。根據實應用范圍，數據復制分為應用復制、數據庫復制、卷復制、控制器復制。應用復制，是指通過應用系統直接向原生產中心和容災中心同時發交易，生產中心和容災中心都處理成功，該筆交易才算成功；只要有一邊應用處理失敗，該筆交易就算失敗。由于交易的延遲性較大、健壯性較差，應用復制一般不會考慮。應用應用數據庫操作系統控制器物理磁盤數據塊SITEA應用數據庫操作系統控制器物理磁盤SITEBIOLogSQL/Log交易數據庫復制數據庫復制，如Oracle的DataGuard、QuestSharePlex、DSGRealSync等，通過分析數據庫RedoLog和ArchiveLog實現日志的復制，將分析結果直接或轉化為SQL語句傳到容災中心，在容災中通過心Aply數據庫日志或將日志轉化的SQL語句重做，來保證數據庫數據的一致性。數據庫復制實際上是應用復制的數據庫實現，復制方式通過異步完成。卷復制如上SymantecVolumeReplicator。控制器復制，如上EMC的復制過程。DatacoreSDS實際上還有一種新的復制方式，稱為基于SAN網絡的卷復制，如Datacore的SDS。它是通過特殊的運行于操作系統上的SDSSAN控制器，實際是將低端的無智能存儲變為高端的智能存儲，使得他們得以建立基于智能SAN控制器的卷，通過這種與主機應用無關，但與SDS控制器直接相關的卷實現復制。此種技術較新，目前具有多家廠商均向此方向發展，其中Datacore是較早的研發廠商，當中還有IBM的SVC和HDS的USP系列也是采用此種技術。應用系統恢復正如前所述，數據復制是容災的手段，不是目的，容災的目的是數據的訪問。因此應用的恢復和以下的網絡的恢復也是容災的關鍵。應用系統恢復，這和系統的應用模式直接相關。需要考慮應用系統的應用架構。是Client/Server架構，還是Broswer/Server架構；是2層架構、還是3層架構、還是多層架構。兩層架構，表示容災中心的應用只要啟動數據庫就可以服務了。如果是三層架構，就意味著應用系統除數據庫以外，還有網絡服務程序，如中間件Tuxedo、CICS、WebLogic、WebSphere、9iAS、SAP等等。在容災應用切換時，能夠手工或自動化的將這些服務一一啟動。網絡系統恢復在災難發生后，應用切換到災備中心了，本地的應用前端需要重新訪問容災節點的服務，帶來另外一個問題，網絡如何切換？是建立新的網絡，還是使用動態路由，還是有其它辦法？實際上最簡單的辦法，就是通過外部DNS服務器，改變服務器名和IP的映射關系，將原服務器名映射到新的IP地址上，就可以利用容災網絡，實現前端對容災中心服務器數據的訪問。容災切換過程就是在災難發生后，數據庫切換、應用重新啟動、網絡實現切換等等,容災中心接管原生產中心的整個過程；同時還包含了在原數據中心修復后，數據庫、應用、網絡需要重新切會來的整個過程。這些過程，可以通過手工切換、也可以通過自動化過程完成。消防演習大部分的容災方案，在項目實施后，很難有機會來實現預演，因為對于大部分方案來說，這種預演活動，需要耗費大量的人力財力。但是消防預演是必不可少的，它是實時測試目前的容災方案的漏洞，保證容災方案在災難發生時，能夠真正生效。主流容災技術分析與對比沒有一種技術可以解決所有得IT問題，因此，也沒有一個解決方案是完美無缺得，依據現狀、技術要求、和未來的拓展，我們在此討論的是最合適容災技術的解決方案。數據備份SHARE78評審標準中，Tier0、Tier1、Tier2級別容災要解決的問題。如前面所闡述的，數據備份是容災系統的起點，是最低端的容災方案。不是說有了高端的實時容災方案，就可以不要備份系統了，因為實時容災不能解決惡性操作、誤操作等故障，而備份系統可以解決。在此我們要討論的是，如何利用現有的備份系統，是容災方案更加完備。備份軟件必須具備跨平臺能力,對目前所有的操作系統AIX、Solaris、HP－Unix、Windows、數據庫Oracle、SQLServer、DB2、SybaseASE等，備份軟件除了要可以很好的備份相關的文件系統數據、數據庫系統數據外，同時必須要滿足系統的裸機快速恢復功能，減少系統重建時間，可以對AIX、Solaris、HP－Unix、Windows、Linux操作系統實現備份，備份這些操作系統的相關補丁、外設驅動程序、相關的文件系統配置信息、相關的卷配置信息、內核參數等。在災難修復時，可以通過恢復的方式快速恢復相關操作系統。實際經驗，操作系統安裝、打補丁，安裝相關驅動程序、恢復內核參數、恢復文件系統配置、恢復卷管理系統配置等整個過程，可以縮短在1小時內完成，并且降低了人為錯誤操作過程。這樣大大提高了原生產中心容災恢復的能力。目前市場上的備份產品，Veritas是市場占有率最高，功能相對較全的產品，其他備份產品，或沒有類似與BMR的模塊；或是不能支持AIX、Solaris、HP－Unix、Windows、Linux全部操作系統，這些用戶可以根據實際情況來選擇。備份軟件還必須對遠程磁帶具有管理功能，可以實現對備份數據的自動拷貝，并實現異地存放和管理。－Share78中Tier1、Tier2級別容災。實時數據保護SHARE78評審標準中，Tier3級別容災。數據鏡像（Mirroring）數據鏡像分軟件鏡像與硬件鏡像。硬件鏡像通過硬件級別的Raid-1實現，其實現過程簡單，但要求嚴格。只能基于同一廠商、同一陣列、同樣容量大小的兩塊磁盤來實現。基本上硬件的磁盤子系統供應商都提供能夠實現此種功能的設備，但一般價格較高，投入大，并且只能限定在同一廠商品牌。軟件鏡像軟件鏡像可以實現邏輯卷級鏡像，對存儲空間要求較低，只要有空間且至少兩塊磁盤就行。不要求同一廠商、同一陣列、同樣容量大小的兩塊磁盤，軟件鏡像能夠實現跨廠商、跨陣列的鏡像，在磁盤空間不均時，能夠實現1塊磁盤對多塊磁盤、N塊磁盤對M塊磁盤的鏡像。軟件鏡像的產品有Symantec的Storagefoundation，這種軟件通常安裝在主機上，通過主機的線程對鏡像進行控制。軟件智能存儲鏡像目前新興的虛擬存儲技術，使得讓原來非智能的存儲可以實現智能化，改變了原來只有高端存儲才具有的智能功能的局面，這種智能的控制器軟件可以實現存儲間的鏡像和存儲內部的硬盤鏡像，同時，此種軟件的可以實現跨廠商的磁盤子系統設備的鏡像。鏡像技術在容災中的利用在通過SAN的支持，DWDM的拓展，光纖網絡可以擴展到100公里或更遠，鏡像可以在較遠的兩個數據中心的磁盤上建立。但由于鏡像系統是以同步方式實現的，受到距離、光纖協議、和相關協議轉換的影響，同步方式會影響本地服務器的性能，所以，一般建議在<20公里的同城容災中使用，在遠程容災中可作為一種加強方案與遠程容災方案整合，將在我們的詳細方案中描述。常說的基于硬件的遠程磁盤鏡像，實際上是遠程磁盤復制，不是真正意義上的鏡像。我們將在后續文章描述。基于SAN的鏡像，在容災實現中，使用范圍較小，如上說述，適用于同城容災，但支持所有的類型數據同步，包括文件數據、數據庫數據、裸設備、應用配置文件、應用程序、庫函數等，因而支持各類應用系統容災，包括數據庫、中間件、客戶自己開發的應用，適用于2層架構、3層或多層應用架構。數據復制（Replication）數據復制是運程容災實現的基礎。軟件復制（卷復制）卷復制軟件負責遠程數據復制。復制基于卷進行，將數據特別是需要進行遠程復制的相關文件系統、數據庫、裸設備、應用程序等，存放在復制卷組中，系統便能自動同步本地和異地相應的復制卷組。卷復制軟件與卷管理軟件完全集成在一起。由于卷復制軟件僅僅將卷上每次I/O的操作復制到遠程節點，復制的信息是卷的日志，所以在網絡線路上傳輸的數據量很少，對帶寬的需求也較小。；基于卷的日志（SRL：先進先出）保正了再極端情況下，如容災網絡中斷、數據復制不能正常進行，容災中心數據于生產中心數據有延遲，在一切故障排除后，能夠嚴格保證所以I/O的寫順序，這類似于數據庫數據塊和數據庫日志的關系，通過帶時間戳的數據塊和順序日志，保證數據的一致性。基于軟件的遠程復制，在容災實現中，使用范圍最廣，支持所有的類型數據同步，包括文件數據、數據庫數據、裸設備、應用配置文件、應用程序、庫函數等，支持各類應用系統容災，包括數據庫、中間件、客戶自己開發的應用，適用于2層架構、3層或多層應用架構。硬件復制通過基于硬件的遠程磁盤鏡像實現，其實現要求嚴格。只能基于同一廠商、同型號陣列、同樣容量大小的兩個陣列來實現。廠商一般建議使用間歇性復制。遠程磁盤鏡像（復制），在容災實現中，支持所有的類型數據同步，包括文件數據、數據庫數據、裸設備、應用配置文件、應用程序、庫函數等，支持各類應用系統容災，包括數據庫、中間件、客戶自己開發的應用，適用于2層架構、3層或多層應用架構。與應用無關，但與磁盤陣列直接相關。只能基于同一廠商、同樣容量大小的兩個陣列來實現。受光纖線路影響、復制數據量大，在使用間歇性復制時，數據延遲大，磁盤容量要求4倍于源數據，并且在極端情況下，不能保證數據一致性。硬件復制的過程，在上文已經描述。下面我們將描述極端情況。磁盤復制在生產中心和容災中心復制的是改動過的物理數據塊，而物理數據塊的寫是無序的。為了保證數據的一致性，通過帶時間戳的數據塊，改善了一定的數據塊的無序性，但仍然不能解決。我們看到，數據庫是通過帶時間戳的數據塊和聯機日志一起來解決，如果一個數據文件中的數據塊的時間戳不一致，數據庫需要日志來修正，日志中記錄的是一些有序的數據庫操作，通過Recover的動作，將不一致的數據文件，前滾或后滾到某一特定時間點。帶時間戳的數據文件和有序的日志，二者缺一不可，否則不能保證數據的一致性。在磁盤復制中，唯獨少了至關重要的磁盤寫日志（不可能有）。更有甚，如果這種磁盤塊的無序寫，發生在數據庫的聯機日志上，那將對數據庫數據的一致性造成破壞。基于軟件控制器的復制基于軟件控制器的復制，打破了基于硬件的復制的單廠商設備的限制，并且具有更大的靈活性，通過建立虛擬磁盤卷的鏡像關系，真正可以建立數據的鏡像，其與軟件復制的不同之處又在于其對應用的無關性，這點又與基于硬件的復制相同。在前面我們提到基于塊設備復制的應用無關性，但是也具有對數據庫的數據一致性的問題，所幸的是這種基于軟件控制器的復制可以具有比基于純硬件復制更多的定制功能，可以對數據庫的數據一致性提供支持，其實現的方式是在數據庫的運行主機上安裝agent或者是編寫腳本的方式實現，并且腳本與軟件控制器想結合，從而保證數據庫的數據復制一致性，防止在極端情況下的數據損失。我們可以認為基于軟件控制器的數據復制是一種介于卷復制和硬件控制器復制之間的數據復制方式。并且解決了單一硬件廠商平臺的限制，是未來的主流發展方向。數據庫復制數據庫復制，如Oracle的DataGuard、QuestSharePlex、DSGRealSync等，通過分析數據庫RedoLog和ArchiveLog實現日志的復制，將分析結果直接或轉化為SQL語句傳到容災中心，在容災中通過心Aply數據庫日志或將日志轉化的SQL語句重做，來保證容災中心數據與生產中心數據一致。數據庫復制也存在一定的限制，在簡單的環境中，實現兩個較小的數據庫數據同步，可以說是一個簡化的解決方案。對于容災環境，其部分限制如下。數據庫復制，是專門針對相應數據庫的，只能實現單一的數據庫復制。現有的數據庫就有Oracle,SQLServer，DB2，SybaseASE。在容災系統中，如果使用數據庫復制方式，管理員將要維護Oracle一套、SQLServer一套、DB2一套、等相互各不相同的數據庫復制技術，管理和維護工作根本不能保證其能夠正常運行。下面我們就以Oracle為例，雖然有眾多廠商、技術方案支持的數據庫復制，仍然有不可逾越的技術障礙。Oracle數據庫的容災復制被稱為StandbyDatabase,其產生于Oracle7.3，在Oracle9i后，改稱為DataGuard。StandbyDatabase又分為PhysicalStandby，和LogicalStandby。PhysicalStandby方式是將生產中心產生的數據庫redolog和archivelog，不停復制到容災中心，不停的applylog，來實現容災中心的數據庫與生產中心一致。LogicalStandby，是通過解析redolog和archivelog，產生相關的SQL語句，把這些語句傳到容災中心重做。QuestSharePlex和DSG的Realsync類似與DataGuard的LogicalStandby，復制SQL語句。1．容災的目的是使數據能夠被正常訪問，業務能夠正常運行。數據庫復制技術，不是一個完整的容災解決方案，只能有限的復制數據庫數據，不能復制其他的應用程序，配置文件，就是Oracle自己的tnsnames.ora,listner.ora，initSID.ora,*.ctl也不能復制，一旦這些文件改動過，將需要管員人為操作或者需要其他軟件的管理，保證容災中心與生產中心同步應用、程序、配置文件同步。2．由于DataGuard是通過日志來實現的，這要求數據庫必須運行在歸檔日志模式下。但我們知道，并不是所有的數據庫操作都寫日志：oracle的DML（DataManipulationLanguage）或DDL（DataDictionaryLanguage）語句是不能被復制的，如createindex、table，altertable等等；觸發器、存儲過程操作不能被復制；系統升級、patchs更新不能被復制。3．與備份軟件的沖突。如前所述，對于核心應用系統，數據備份必不可少。對于數據庫的備份，也要求數據庫在歸檔模式下運行。備份系統在備份作用發起時，需要備份數據文件、controlfile、歸檔日志、甚至需要數據庫實現強制歸檔，來備份歸檔日志，備份作業成功后，由備份系統自動刪除備份過的歸檔日志，應為當數據庫運行在歸檔日志模式下時，歸檔日志往往因數據庫繁忙而快速大量產生，需要備份軟件自動清除維護，否則當歸檔日志空間占滿后，聯機日志不能歸檔時，生產數據庫不在運作，則所有應用業務不能操作，釀成生產事故。為了不影響生產環境，問題一，在備份作業發起，強制歸檔；備份完成后，刪除歸檔日志后，數據庫復制軟件，該如何操作，將嚴重造成生產中心和容災中心數據不一致。如果備份作用不刪除歸檔日志，系統管理員將不定時的來維護歸檔目錄，他必須知道本地歸檔目錄中，哪一個歸檔日志已經被備份，通過檢查容災中心數據庫中哪一個歸檔日志已經被apply，這將是一個惡夢一樣的維護工作。4．極限情況下的危害。當生產中心和容災中心的復制鏈路一定時期內不能恢復時，同樣需要在生產主機中保留所有的歸檔日志，這又需要管理員大量的維護工作。應用系統恢復對于核心的應用環境，在實現容災前，一般都要求在本地實現高可用性，通過集群軟件，保證應用、數據訪問在服務器級故障，如網卡、IP、操作系統、磁盤、其他相關應用的故障時，能夠自動切換到另外一臺可用的服務器上，能夠被用戶繼續訪問。容災應用切換，就是把這種高可用性的應用，拓展到廣域網上。也就是說通過HA軟件實現生產中心的高可用、實現容災中心應用的自動啟動、實現生產中心在災難修復后應用的回切過程。目前主流的高可用方案主要有SymantecVCS、IBMHACMP、HPMC/ServiceGuard、SunCluster、WindowsCCS等。各廠商軟件的名字上，我們就可以看到他們的不足。只能支持自己的平臺。也就是意味著如果使用他們的解決方案，得分別熟悉AIX、HP－Unix、Solaris、Windows，得在分別熟悉IBMHACMP、HPMC/ServiceGuard、SunCluster、WindowsCCS軟件，并且這些軟件大部分只提供命令行管理、調試方式，這在管理上又是一大難題。SymantecVCS則是目前市場上主流的跨平臺集群軟件之一，擁有70％的高端應用市場。通過統一得圖形化JAVAGUI或WebGUI，提供對AIX、HP－Unix、Solaris、Windows、Linux所有操作系統平臺、所有數據庫Oracle、OracleRAC、SQLServer、Sybase、DB2、所有中間件：Weblogic、WebSphere、9iAs、Tuxedo，甚至是用戶自己寫得應用程序，實現得集中統一的集群管理和監控。并且能夠定義這些服務啟動、切換得先后順序，以確保數據能夠快速正常訪問。例如在WebLogicServer啟動之前，必須先啟動Oracle,因為在WebLogicServer啟動是會建立數據庫得連接池，如果數據庫未啟動，WebLogicServer啟動將失敗。在災難發生時，VCS將根據這些服務組之間得關系，先后依次啟動各個服務組。大大提供容災中心服務得接管速度。網絡系統恢復在災難發生后，本地應用訪問路徑如何由指向原生產中心改為指向容災中心。在災難修復后，又需要指向原生產中心。我們提到，最簡單得方法就是更改外部DNS服務器得IP映射關系。在災難發生前，IP映射為生產中心服務器；在災難發生后，IP由映射為容災中心得服務器；在災難修復后，IP又映射為生產中心得服務器。當然，在一些中間件軟件中，支持多服務器、多IP得配置，那也是可以考慮的。容災系統設計步驟如上圖，對于容災系統的建立，我們建議通過分步實施，逐漸建立一套完善的系統容災解決方案。第一步，深化數據備份系統；第二步，存儲、應用整合；第三步，實現遠程實時數據保護；第四步，建立遠程切換消防演習機制；第五步，建立遠程切換機制。第一步，深化數據備份系統通過相應的備份軟件，對目前所有的計算機系統，做好完善的數據備份，特別是做好操作系統備份、文件系統備份、數據庫系統文件備份、數據庫數據文件備份、相關的核心應用程序備份；建立好完善的備份/恢復機制和遠程磁帶保管機制。這也是下一步實現遠程數據復制容災的基礎，容災中心與生產中心的數據初始化同步，都是通過磁帶備份恢復方式，實現一個同步起點。第二步，存儲、應用整合存儲整合通過相關的產品選擇，將各服務器的數據、或應用，通過基于一定的管理及后續，實現數據的快照、鏡像等技術，遷移到外置基于SAN的陣列庫中，通過唯一的管理接口，實現統一管理，屏蔽不同廠商陣列的差異。應用整合通過相應的應用集群管理軟件，管理所有的應用系統狀態。對現有的數據庫系統Oracle、SQLServer、DB2、Sybase、中間件等應用，實現雙機、多機或是單機集群管理。操作系統平臺相同的，可以整合在一起，實現多機集群，不同的數據庫實例，只是作為一個“數據庫服務組”，運行在多機或雙機中的某一臺服務器上，為中間件、其他應用建立“應用服務組”，也納入到集群軟件的管理；并且動過集權軟件建立“應用服務組”與“數據庫服務組”或其他“應用服務組”的依賴關系，實現對應用啟動、關閉的有序管理。如果是OracleRAC的應用，則需要集權軟件支持，因此在選擇集權管理軟件時要納入考慮因素，通過RAC的支持使得數據庫的RAC應用也在集群軟件的管理之下。第三步，實現遠程實時數據卷保護通過第二步的存儲和應用整合，使得所有需要容災的核心系統，全部納入到一個統一的管理平臺之下，我們將規劃好應用數據的存放方式、數據文件的存放地點、日志的存放地點，然后統一為這些數據指定一定的存儲策略，實現遠程數據復制。第四步，建立遠程切換消防演習機制在數據庫復制初始化完成，相關應用復制完成，就可以實現相關應用的消防演習了。這是保證容災系統正常唯一的、最有效的手段，整個過程生產中心應用在線。對數據庫實現快照；啟動數據庫；啟動相關的應用；通過壓力程序或測試程序驗證應用。第五步，建立遠程切換機制確定外部DNS服務器對本地服務器與容災中心服務器IP地址的對應關系，確定GCO對DNS更新的內容。數據容災的性能分析同步數據容災的性能分析利用同步傳輸方式建立異地數據容災，可以保證在本地系統出現災難時，異地存在一份與本地數據完全一致的數據備份。但利用同步傳輸方式建立這樣一個系統，必須考慮“性能”這個因素。采用同步數據傳輸方式時，從前面的描述來看，本地系統必須等到數據成功的寫到異地系統，才能進行下一個I/O操作。一個I/O通過遠程鏈路寫到異地系統，涉及到3個技術參數：帶寬、距離和中間設備及協議轉換的時延。 帶寬本地I/O的帶寬是100MB/秒，在I/O流量很大的情況下，如果與遠程的I/O帶寬相對“100MB/秒==800Mbit/秒”窄得多的話，如E1：2Mbit/秒；E3：45Mbit/秒，將會明顯拖慢生產系統的I/O，從而影響系統性能。距離光和電波在線路上傳輸的速度是30萬公里/秒，當距離很長時，這種線路上的延時將會變得很明顯。例如：一個異地容災系統的距離是1000KM，其數據庫寫盤的數據塊大小是10KB（一次I/O的數據量），那么：本地I/O時（100米距離內）：光電在線路上的延時 =0.1km/300,000km*2次/一個來回 =0.67*10-6秒1秒鐘內允許I/O次 =1/（0.67*10-6）=1.5*10-6次1秒鐘允許的I/O量 =10KB*1.5*10-6=15GB此數字遠遠超過光纖通道帶寬本身，也就是說，光電在100米距離的線路上的延時對性能的影響可以忽略不計。異地I/O的（1000公里）：光電在線路上的延時 =1000km/300,000km*2次 =1/150秒1秒鐘內允許I/O次 =1/（1/150）=150次1秒鐘允許的I/O量 =10KB*150=1.5MB此數據表明，在1000公里距離上，允許的最大I/O量在不存在帶寬限制時，已經遠遠低于本地I/O的能力。（注：上面分析還未考慮中間設備及協議轉換的延時）。中間鏈路設備和協議轉換的時延中間鏈路設備和協議轉換的方式的不同，時延不同，對性能的影響也不同。在對性能影響的分析中，這個因數也應計算在內。目前不同異地數據復制技術所依賴的介質和協議不同，我們將介質、協議和大概時延例表如下，這里提供的數據只精確到數量級，僅供參考，實際數據應該像設備供應上索取。鏈路設備和協議帶寬支持的距離設備和協議轉換時延租用線路任意不受限制約1ms（1毫秒）ESCON136Mbit66公里<100us(100微秒)LAN1000Mbit10公里<100usATM655Mbit不受限制<100usIPoverFC800Mbit60公里<100usFC800Mbit60公里<10us下面是一個線路時延分析對照表，供參考。距離1000KM100KM10KM線路時延/次I/O6ms600us60us支持的鏈路和協議租用線路ATM租用線路ATM租用線路ATMESCONLANIPoverFCFC本地磁盤I/O能力10MB/每個磁盤*秒=10KB/ms本地CacheI/O能力50ns在1000公里和100公里距離上，采用租用線路和ATM，允許的最大I/O能力（假定帶寬足夠，數據塊大小以10KB為例）：1000公里100公里租用線路ATM租用線路ATM線路時延/次I/O6ms6ms600us600us設備和協議時延>1ms<100us>1ms<100us寫單個盤/寫Cache(即本地寫響應時間)1ms/50ns1ms/50ns1ms/50ns1ms/50nsI/O次數，次/秒125~140140~160380~600590~1400I/O能力，MB/秒1.2~1.41.4~1.63.8~65.9~14每個I/O響應時間>8ms>7ms>2.6ms1.7ms不適合用同步傳輸方式I/O流量（MB/秒）32KB塊/寫Cache4.55.32045備注不適合用同步傳輸在10公里距離上，采用各種傳輸協議允許的最大I/O能力，數據塊大小以10KB為例（假定帶寬足夠）：10公里租用線路ATMLANESCONIPoverFCFC線路時延/次60us60us60us60us設備協議時延>1ms<100us<100us<10us寫單盤/寫Cache1ms/50ns1ms/50ns1ms/50ns1ms/50nsI/O次數/秒485-930900-5800900-5800900-12500I/OMB/秒4.8-9.39-589-589-125備注適合用同步傳輸異步數據容災的性能分析從前面的分析來看，同步數據容災一般只能在較短距離內部署（10KM-100KM），大于這個距離，就沒有實際應用價值了。因為即使在1000KM距離上，4.5MB的速率足夠將數據復制到異地，每個I/O的響應時間也會超過10ms，這種響應速度太慢。異步數據容災主要是針對“線路帶寬和距離能保證完成數據復制過程，同時，希望異地數據復制不影響生產系統的性能”這樣的要求下提出來的。考慮異步數據容災，應該注意到以下幾個技術條件和事實。帶寬必須能保證將本地生產數據基本上完全復制到異地容災端，還要考慮距離對傳輸能力的影響。按照前面的估算：在1000公里范圍內，一條帶寬足夠的線路能支持的I/O流量最大為（數據塊大小10KM）：1.4MB×3600秒×24小時=120GB/天異地容災端數據雖然落后,但必須保證該數據庫內在的數據完整性（一致性）、可用性，否則，這種數據復制就沒有應用價值了。異地容災端數據會比本地生產端數據落后一定時間,這個時間隨采用的技術，帶寬、距離、數據流特點的不同而不同。異步容災基本不影響本地系統性能。與同步傳輸方式相比，異步傳輸方式對帶寬和距離的要求低很多，它只要求在某個時間段內能將數據全部復制到異地即可，同時異步傳輸方式也不會明顯影響應用系統的性能。其缺點是在本地生產數據發生災難時，異地系統上的數據可能是幾分鐘以前的數據，即最近幾分鐘內的交易會丟失。（注：一個經過仔細計算和規劃的系統，才能保證其數據丟失只有幾分鐘。）通過異步傳輸模式進行異地數據復制的技術，包括：基于主機邏輯卷的數據復制方式基于磁盤系統I/O控制器的數據復制方式基于軟件控制器的數據復制方式基于主機邏輯卷（Volume），由于采用Log技術作技術保障的數據復制方式，其數據具有較高的完整性保障，而基于磁盤系統I/O控制器的數據復制方式，不能滿足前面提到的技術條件二，也即不能保證異地容災端數據（庫）的完整性，所以，這種方式對于基于數據庫的應用具有一定的局限性。基于軟件控制器的復制由于采用了腳本和控制器的聯動，可以支持數據庫的文件的一致，但是必須調動腳本的運行時間，在兩個腳本運行時間之間的數據會存在不一致的可能性。基于單片機和DSP的卷繞控制器數據采集和通訊設計基于MSP430單片機的柴油發電機監控器的設計基于CPLD/FPGA和單片機的爆速儀設計基于單片機控制的晶閘管中頻感應電源的研制基于十六位單片機的電力設備故障在線監測裝置的設計與算法研究基于SPCE061A單片機的語音識別系統的研究基于PIC單片機的生物機能實驗裝置的研究基于MotorolaMC68HC08系列單片機演示系統的設計與實現基于TCP/IP協議的單片機與INTERNET互連的設計與實現基于嵌入式實時操作系統和TCP/IP協議的單片機測控系統AVR8位嵌入式單片機在車載全球定位系統顯示終端中的應用基于AVR單片機的250WHID燈電子鎮流器的研究基于單片機的TCP/IP技術研究及應用基于P87C591單片機的CAN總線應用層協議的研究基于單片機實現對二級倒立擺的控制C8051FXXX系列單片機仿真器的研制HYP