容災(zāi)項目方案設(shè)計說明

1、 . . . 1 / 82容災(zāi)項目方案設(shè)計 . . . 2 / 82目 錄第第 1 1 章容災(zāi)技術(shù)規(guī)章容災(zāi)技術(shù)規(guī) .6 61.1 容災(zāi)的總體規(guī)劃 .61.1.1 技術(shù)指標(biāo) RPO、RTO .61.1.2 國際標(biāo)準(zhǔn) SHARE 78 .71.1.2.1Tier 0.81.1.2.2Tier 1.91.1.2.3Tier 2.91.1.2.4Tier 3.101.1.2.5Tier 4.101.1.2.6Tier 5.101.1.2.7Tier 6.111.1.3 界定災(zāi)備系統(tǒng)的適用圍 .111.1.4 界定災(zāi)備建設(shè)的目標(biāo) .121.1.5 界定災(zāi)備系統(tǒng)的總體架構(gòu) .12第第 2 2 章主流容災(zāi)技

2、術(shù)說明章主流容災(zāi)技術(shù)說明 .14142.1 數(shù)據(jù)備份 .142.2 實時數(shù)據(jù)保護 .142.2.1 數(shù)據(jù)鏡像（Mirroring） .152.2.2 數(shù)據(jù)復(fù)制（Replication） .152.2.2.1 軟件復(fù)制（卷復(fù)制） .152.2.2.2 硬件復(fù)制 .162.2.2.3 數(shù)據(jù)庫復(fù)制 .192.2.2.4IBM SVC.202.3 應(yīng)用系統(tǒng)恢復(fù) .202.4 網(wǎng)絡(luò)系統(tǒng)恢復(fù) .202.5 容災(zāi)切換過程 .212.6 消防演習(xí) .21第第 3 3 章主流容災(zāi)技術(shù)分析與對比章主流容災(zāi)技術(shù)分析與對比 .22223.1 數(shù)據(jù)備份 .223.2 實時數(shù)據(jù)保護 .233.2.1 數(shù)據(jù)鏡像（Mirro

3、ring） .233.2.1.1 硬件鏡像 .233.2.1.2 軟件鏡像 .243.2.1.3 鏡像技術(shù)在容災(zāi)中的利用 .243.2.2 數(shù)據(jù)復(fù)制（Replication） .243.2.2.1 軟件復(fù)制（卷復(fù)制） .253.2.2.2 硬件復(fù)制 .273.2.2.3 數(shù)據(jù)庫復(fù)制 .283.2.2.4 數(shù)據(jù)庫雙活 .29 . . . 3 / 823.2.3 瞬間快照(Instant Snapshot) .303.3 應(yīng)用系統(tǒng)恢復(fù) .313.4 網(wǎng)絡(luò)系統(tǒng)恢復(fù) .323.5 容災(zāi)切換過程 .333.6 消防演習(xí) .33第第 4 4 章某容災(zāi)方案主要技術(shù)介紹章某容災(zāi)方案主要技術(shù)介紹 .33334.

4、1 某 NETBACKUP數(shù)據(jù)備份技術(shù).344.1.1 無限可伸縮性 .344.1.2 平臺獨立性 .344.1.3 基于策略的集中式管理 .344.1.4 無與倫比的性能 .344.1.5 透明的不間斷備份 .344.1.6 支持最新存儲硬件 .344.1.7 可伸縮三/四層體系架構(gòu) .354.1.7.1NetBackup Master Server.364.1.7.2NetBackup Media Server.364.1.7.3NetBackup Client.364.1.7.4 全球管理與實時報告：NOM .364.1.7.5 先進報表：NetBackup Advanced Repor

5、ter .374.1.7.6 數(shù)據(jù)庫在線備份：Database Agent .384.1.7.7 數(shù)據(jù)庫歸檔：NetBackup Database Archiver .384.1.7.8 塊級增量備份：Block-Level Incremental Backup .394.1.7.9 系統(tǒng)災(zāi)難恢復(fù)：Bare Metal Restore .394.1.7.10 高速閃備份：NetBackup FlashBackup .414.1.7.11 打開文件備份：Open Transaction Manager .424.1.7.12 磁帶庫動態(tài)共享：Shared Storage Option .424.

6、1.7.13 無主機備份：NetBackup ServerFree Agent .434.1.7.14 磁帶容災(zāi)和管理：NetBackup Vault .434.1.7.15 網(wǎng)絡(luò)存儲備份：NetBackup for NDMP .444.1.7.16 備份數(shù)據(jù)加密：Client Encryption Option .454.1.7.17 磁帶庫驅(qū)動：Tape Library Support .454.1.7.18 其它功能 .454.2 某 STORAGE FOUNDATION.464.2.1 某 Volume Manager.474.2.1.1 更高的系統(tǒng)與應(yīng)用性能 .474.2.1.2 數(shù)

7、據(jù)完整性提高，停機時間縮短 .474.2.1.3 硬件與軟件投資保護 .474.2.2 某 File System.484.2.2.1 用戶與管理員工作效率提高 .484.2.2.2 可靠的系統(tǒng)數(shù)據(jù)帶來可靠的業(yè)務(wù)解決方案 .484.2.2.3 簡單而強大的系統(tǒng)管理功能 .484.2.3 某 Storage Foundation 解決方案說明 .484.2.3.1 性能、可用性與安全性 .494.2.3.2 可擴展性 .504.2.3.3 集中式管理 .51 . . . 4 / 824.2.3.4 異類環(huán)境支持 .524.2.3.5 優(yōu)異的集成性能 .524.2.4 邏輯卷快照 .534.2.5

8、snapshot 快速重鏡像(FastResync) .534.2.6 動態(tài)拆分和重組（Dynamic split and Join） .544.2.7 邏輯卷快照技術(shù)的特點 .544.2.8Snapshot 如何工作 .544.2.9 瞬間快照(Instant Snapshot) .564.3 領(lǐng)先的企業(yè)級高可用性應(yīng)用軟件解決方案 .564.3.1 某 Cluster Server 特征 .574.3.2 領(lǐng)先的異構(gòu)平臺 HA 解決方案 .574.3.3 可伸縮性 .584.3.4 可定制 .584.3.5 補充保護 .584.3.6 災(zāi)難恢復(fù)解決方案的重要組成成分 .584.3.7 某 C

9、luster Server 特性優(yōu)勢 .594.3.7.1 全面的高可用性特性 .594.3.7.2 最廣泛的應(yīng)用支持 .594.3.7.3 異構(gòu)平臺和存儲器支持 .594.3.7.4 行業(yè)最具伸縮性的解決方案 .604.3.7.5 多種存儲支持 .604.3.7.6 用于集群管理，基于 JAVA 的直覺圖形用戶界面（GUI） .604.3.7.7 通用原子廣播機（GAB） .604.3.7.8 自動集群傳播 .614.4 集群的集群 .614.4.1Global Cluster Option 的特點 .614.4.2Global Cluster Option 運作過程 .62第第 5 5 章

10、系統(tǒng)詳細(xì)設(shè)計方案章系統(tǒng)詳細(xì)設(shè)計方案 .64645.1 第一步，深化數(shù)據(jù)備份系統(tǒng) .645.2 第二步，存儲、應(yīng)用整合 .655.2.1 存儲整合 .655.2.2 應(yīng)用整合 .655.3 第三步，實現(xiàn)遠(yuǎn)程實時數(shù)據(jù)卷保護 .665.4 第四步，建立遠(yuǎn)程切換消防演習(xí)機制 .665.5 第五步，建立遠(yuǎn)程切換機制 .675.6ORACLE 數(shù)據(jù)庫切換詳解 .67第第 6 6 章數(shù)據(jù)容災(zāi)的性能分析章數(shù)據(jù)容災(zāi)的性能分析 .69696.1 同步數(shù)據(jù)容災(zāi)的性能分析 .696.1.1 帶寬696.1.2 距離696.1.3 中間鏈路設(shè)備和協(xié)議轉(zhuǎn)換的時延 .706.2 異步數(shù)據(jù)容災(zāi)的性能分析 .72 . . .

11、5 / 826.3 有關(guān)半同步 .776.4 容災(zāi)技術(shù)對照 .78第第 7 7 章系統(tǒng)預(yù)算章系統(tǒng)預(yù)算 .7979第第 8 8 章主要技術(shù)的應(yīng)用實例章主要技術(shù)的應(yīng)用實例 .80808.1 中國聯(lián)通 .808.2ICON CLINICAL.808.3BLUESTAR.81第第 9 9 章應(yīng)急預(yù)案的編制章應(yīng)急預(yù)案的編制 .82829.1 某技術(shù)力量 .829.2 某項目組成員 .83第第 1010 章定期災(zāi)難性恢復(fù)測試計劃與檢驗章定期災(zāi)難性恢復(fù)測試計劃與檢驗 .8484第第 1111 章售后服務(wù)方式、方法章售后服務(wù)方式、方法 .848411.1 某中國技術(shù)支持服務(wù)中心 .8411.2 技術(shù)支持服務(wù)介

12、紹 .8411.3 提供支持的流程： .8511.4 某公司向用戶提供如下支持服務(wù)： .85第第 1 1 章章 容災(zāi)技術(shù)容災(zāi)技術(shù)規(guī)規(guī)作為風(fēng)險防系統(tǒng)，災(zāi)備系統(tǒng)建設(shè)本身在總體規(guī)劃、方案選擇和投產(chǎn)實施后的管理運行，以與真正面對災(zāi)難時的切換操作等方面也存在著潛在的風(fēng)險。 計算機信息系統(tǒng)實現(xiàn)數(shù)據(jù)大集、應(yīng)用大集中后，系統(tǒng)的運行安全成為風(fēng)險控制的焦點。目前，已經(jīng)有多系統(tǒng)開始或準(zhǔn)備進行災(zāi)備系統(tǒng)的建設(shè)，災(zāi)備系統(tǒng)建設(shè)的目標(biāo)是減災(zāi)容災(zāi)，使計算機信息系統(tǒng)和數(shù)據(jù)能夠最大限度地防和化解各種意外和災(zāi)害所帶來的風(fēng)險。然而，與大多數(shù)工程一樣，災(zāi)備系統(tǒng)建設(shè)本身在總體規(guī)劃、方案選擇和投產(chǎn)實施后的管理運行，以與真正面對災(zāi)難時的切換操

13、作等方面也存在著潛在的風(fēng)險。 . . . 6 / 82可以說，風(fēng)險防系統(tǒng)本身也存在風(fēng)險點，需要小心應(yīng)對。 災(zāi)備系統(tǒng)建設(shè)中所涉與的潛在風(fēng)險大致可分為技術(shù)風(fēng)險、管理風(fēng)險和投資風(fēng)險，其中尤以技術(shù)選擇風(fēng)險最大，技術(shù)方案選擇優(yōu)越，可以規(guī)避一定的管理風(fēng)險和投資風(fēng)險。而這三者也存在在的相互關(guān)聯(lián)，不同災(zāi)備級別對應(yīng)的建設(shè)投資規(guī)模、所采用的技術(shù)以與實施和管理的復(fù)雜度也不同，應(yīng)考慮保護計算機系統(tǒng)的原有投資并提高災(zāi)備系統(tǒng)建設(shè)投資的利用率。 1.1 1.1 容災(zāi)的總體規(guī)劃容災(zāi)的總體規(guī)劃真正的容災(zāi)是數(shù)據(jù)被不間斷的一致性訪問！在災(zāi)難備份的世界里，是有等級觀念的，級別不同，災(zāi)備系統(tǒng)所采用的技術(shù)和達到的功能是不同的，在系統(tǒng)建設(shè)

14、資金投入方面的差距也很巨大。所以，對用戶來說，明確災(zāi)備系統(tǒng)建設(shè)的總體規(guī)劃十分必要。1.1.1 1.1.1 技術(shù)指標(biāo)技術(shù)指標(biāo) RPORPO、RTORTO衡量容災(zāi)技術(shù)的兩個技術(shù)指標(biāo) RPO、RTORPO(Recovery Point Objective): 以數(shù)據(jù)為出發(fā)點，主要指的是業(yè)務(wù)系統(tǒng)所能容忍的數(shù)據(jù)丟失量。與在發(fā)生災(zāi)難，容災(zāi)系統(tǒng)接替原生產(chǎn)系統(tǒng)運行時，容災(zāi)系統(tǒng)與原生產(chǎn)中心不一至的數(shù)據(jù)量。RPO 是反映恢復(fù)數(shù)據(jù)完整性的指標(biāo)，在同步數(shù)據(jù)復(fù)制方式下，RPO 等于數(shù)據(jù)傳輸時延的時間；在異步數(shù)據(jù)復(fù)制方式下，RPO 基本為異步傳輸數(shù)據(jù)排隊的時間。在實際應(yīng)用中，考慮到數(shù)據(jù)傳輸因素，業(yè)務(wù)數(shù)據(jù)庫與容災(zāi)備份數(shù)據(jù)庫

15、的一致性（SCN）是不一樣的，RPO 表示業(yè)務(wù)數(shù)據(jù)與容災(zāi)備份數(shù)據(jù)的 SCN 的時間差。發(fā)生災(zāi)難后，啟動容災(zāi)系統(tǒng)完成數(shù)據(jù)恢復(fù)，RPO 就是新恢復(fù)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)損失量。RTO(Recovery Time Objective):以應(yīng)用為出發(fā)點，即應(yīng)用的恢復(fù)時間目標(biāo)，主 . . . 7 / 82要指的是所能容忍的應(yīng)用停止服務(wù)的最長時間，也就是從災(zāi)難發(fā)生到業(yè)務(wù)系統(tǒng)恢復(fù)服務(wù)功能所需要的最短時間周期。是反映業(yè)務(wù)恢復(fù)與時性的指標(biāo)，表示業(yè)務(wù)從中斷到恢復(fù)正常所需的時間。RTO 值越小，代表容災(zāi)系統(tǒng)的數(shù)據(jù)恢復(fù)能力越強。各種容災(zāi)解決方案的 RTO 有較大差別，基于光通道技術(shù)的同步數(shù)據(jù)復(fù)制，配合異地備用的業(yè)務(wù)系統(tǒng)和跨業(yè)

16、務(wù)中心與備份中心的高可用管理，這種容災(zāi)解決方案具有最小的RTO。容災(zāi)系統(tǒng)為獲得最小的 RTO，需要投入大量資金。不同容災(zāi)方案的 RTO 和 RPO 是不一樣的。1.1.2 1.1.2 國際標(biāo)準(zhǔn)國際標(biāo)準(zhǔn) SHARESHARE 7878要建設(shè)容災(zāi)系統(tǒng)，就必須提出相應(yīng) 的設(shè)計指標(biāo)，以此作為衡量和選擇容災(zāi)解決方案的參數(shù)。目前，國際上通用的容災(zāi)系統(tǒng)的評審標(biāo)準(zhǔn)為 SHARE 78，主要包括以下容。備份/恢復(fù)的圍災(zāi)難恢復(fù)計劃的狀態(tài)業(yè)務(wù)中心與容災(zāi)中心之間的距離業(yè)務(wù)中心與容災(zāi)中心之間如何連接數(shù)據(jù)是怎樣在兩個中心之間傳送的允許有多少數(shù)據(jù)丟失保證更新的數(shù)據(jù)在容災(zāi)中心被更新容災(zāi)中心可以開始容災(zāi)進程的能力 . . .

17、8 / 82SHARE 78 是建立容災(zāi)系統(tǒng)的一種評審標(biāo)準(zhǔn)。建立容災(zāi)系統(tǒng)的最終目的，是為了在災(zāi)難發(fā)生后能夠以最快速度恢復(fù)數(shù)據(jù)服務(wù)，主要體現(xiàn)在 RTO Objective)和 RPO 上。SHARE 78, M028 報告中定義的災(zāi)備的七個級別和與其對應(yīng)的數(shù)據(jù)丟失量與恢復(fù)時間情況詳見下表： 災(zāi)難備份等級與業(yè)務(wù)恢復(fù)情況對照表等級描述PRORTO企業(yè)百分比0 級無災(zāi)備計劃-48 小時0.1%2 級車輛運送熱備份2448 小時24 小時90%3 級電子傳送24 小時24 小時6%4 級活動狀態(tài)備份中心秒級24 小時0.5%5 級兩中心、兩階段確認(rèn)秒級2 小時0.1%6 級零數(shù)據(jù)丟失零丟失2 小時3%1

18、 1. .1 1. .2 2. .1 1 T Ti ie er r 0 0Tier 0 - 無異地數(shù)據(jù)備份(No off-site Data)Tier 0 被定義為沒有信息存儲的需求，沒有建立備份硬件平臺的需求，也沒有發(fā)展應(yīng)急計劃的需求，數(shù)據(jù)僅在本地進行備份恢復(fù)， 沒有數(shù)據(jù)送往異地。這種方式是最為低成本的災(zāi)難備份解決方案，但事實上這種災(zāi)難備份并沒有真正災(zāi)難備份的能力，因為它的數(shù)據(jù)并沒有被送往遠(yuǎn)離本地的地方，而數(shù)據(jù)的恢復(fù)也僅是利用本地的記錄。 1 1. .1 1. .2 2. .2 2 T Ti ie er r 1 1Tier 1- PTAM 車輛轉(zhuǎn)送方式( Pickup Truck Acces

19、s Method)作為 Tier 1 的災(zāi)難備份方案需要設(shè)計一個應(yīng)急方案，能夠備份所需要的信息并將它存儲在異地，然后根據(jù)災(zāi)難備份的具體需求，有選擇地建立備份平臺， 但事 . . . 9 / 82先并不提供數(shù)據(jù)處理的硬件平臺。 PTAM 是一種用于許多中心備份的標(biāo)準(zhǔn)方式，數(shù)據(jù)在完成寫操作之后，將會被送到遠(yuǎn)離本地的地方，同時具備有數(shù)據(jù)恢復(fù)的程序。在災(zāi)難發(fā)生后，一整套系統(tǒng)和應(yīng)用安裝動作需要在一臺未啟動的計算機上重新完成。系統(tǒng)和數(shù)據(jù)將被恢復(fù)并重新與網(wǎng)絡(luò)相連。這種災(zāi)難備份方案相對來說成本較低(僅僅需要傳輸工具的消耗以與存儲設(shè)備的消耗)。 但同時有難于管理的問題，即很難知道什么樣的數(shù)據(jù)在什么樣的地方。一旦

20、系統(tǒng)可以工作，標(biāo)準(zhǔn)的做法是首先恢復(fù)關(guān)鍵應(yīng)用，其余的應(yīng)用根據(jù)需要恢復(fù)。這樣的情況下，恢復(fù)是可能的，但需要一定的時間，同時依賴于什么時候硬件平臺能夠被提供準(zhǔn)備好。1 1. .1 1. .2 2. .3 3 T Ti ie er r 2 2Tier 2 - PTAM 卡車轉(zhuǎn)送方式+熱備份中心 (PTAM+Hot Site)Tier 2 相當(dāng)于是 Tier 1 再加上具有熱備份能力中心的災(zāi)難備份。熱備份中心擁有足夠的硬件和網(wǎng)絡(luò)設(shè)備去支持關(guān)鍵應(yīng)用的安裝需求。對于十分關(guān)鍵的應(yīng)用，在災(zāi)難發(fā)生的同時，必須在異地有正運行著的硬件平臺提供支持。這種災(zāi)難備份的方式依賴于用 PTAM 的方法去將日常數(shù)據(jù)放在異地存儲，

21、當(dāng)災(zāi)難發(fā)生的時候，數(shù)據(jù)再被移動到一個熱備份的中心。雖然移動數(shù)據(jù)到一個熱備份中心增加了成本，但卻明顯降低了災(zāi)難備份的時間。1 1. .1 1. .2 2. .4 4 T Ti ie er r 3 3Tier 3 - 電子傳送(Electronic Vaulting)Tier 3 是在 Tier 2 的基礎(chǔ)上用電子鏈路取代了車輛進行數(shù)據(jù)傳送的災(zāi)難備份。接收方的硬件平臺必須與生產(chǎn)中心物理地相分離，在災(zāi)難發(fā)生后，存儲的數(shù)據(jù)用于災(zāi)難備份。由于熱備份中心要保持持續(xù)運行，因此增加了成本。但確實是消除了運送工具的需要，提高了災(zāi)難備份的速度。 . . . 10 / 821 1. .1 1. .2 2. .5 5

22、 T Ti ie er r 4 4Tier 4 - 活動狀態(tài)的備份中心 (Active Secondary Site)Tier 4 這種災(zāi)難備份要求兩個中心同時處于活動狀態(tài)并管理彼此的備份數(shù)據(jù)，允許備份行動在任何一個方向發(fā)生。接收方硬件平臺必須保證與另一方平臺物理地相分離，在這種情況下，工作負(fù)載可以在兩個中心之間被分擔(dān)，兩個中心之間之間彼此備份。在兩個中心之間，彼此的在線關(guān)鍵數(shù)據(jù)的拷貝不停地相互傳送著。在災(zāi)難發(fā)生時，需要的關(guān)鍵數(shù)據(jù)通過網(wǎng)絡(luò)可迅速恢復(fù)，通過網(wǎng)絡(luò)的切換，關(guān)鍵應(yīng)用的恢復(fù)時間也可降低到了小時級。1 1. .1 1. .2 2. .6 6 T Ti ie er r 5 5Tier 5 -

23、 兩中心兩階段確認(rèn) (Two-Site Two-Phase Commit)Tier 5 是在 Tier 4 的基礎(chǔ)上在鏡像狀態(tài)上管理著被選擇的數(shù)據(jù) (根據(jù)單一commit 圍，在本地和遠(yuǎn)程數(shù)據(jù)庫中同時更新著數(shù)據(jù))，也就是說，在更新請求被認(rèn)為是滿意之前，Tier 5 需要生產(chǎn)中心與備份中心的數(shù)據(jù)都被更新。我們可以想象這樣一種情景，數(shù)據(jù)在兩個中心之間相互映像，由遠(yuǎn)程 two-phase commit 來同步，因為關(guān)鍵應(yīng)用使用了雙重在線存儲，所以在災(zāi)難發(fā)生時，僅僅傳送中的數(shù)據(jù)被丟失，恢復(fù)的時間被降低到了小時級。1 1. .1 1. .2 2. .7 7 T Ti ie er r 6 6Tier 6

24、- 零數(shù)據(jù)丟失 (Zero Data Loss)Tier 6 可以實現(xiàn)零數(shù)據(jù)丟失率，同時保證數(shù)據(jù)立即自動地被傳輸?shù)絺浞葜行?。Tier 6 被認(rèn)為是災(zāi)難備份的最高的級別，在本地和遠(yuǎn)程的所有數(shù)據(jù)被更新的同時，利用了雙重在線存儲和完全的網(wǎng)絡(luò)切換能力。Tier 6 是災(zāi)難備份中最昂貴的方式， . . . 11 / 82也是速度最快的恢復(fù)方式，恢復(fù)的時間被降低到了分鐘級。對于 Tier 6 的災(zāi)難備份解決方案，可以應(yīng)用兩種遠(yuǎn)程拷貝技術(shù)來實現(xiàn)，即 PPRC 同步遠(yuǎn)程拷貝和 XRC 異步遠(yuǎn)程拷貝。 因此，企業(yè)需要根據(jù)其計算機處理系統(tǒng)中數(shù)據(jù)的重要性，以與需要恢復(fù)的速度和程度，來進行災(zāi)備系統(tǒng)建設(shè)的整體考慮和不同

25、災(zāi)難對業(yè)務(wù)沖擊的分析，并最終確定災(zāi)備系統(tǒng)建設(shè)的總體規(guī)劃。災(zāi)備系統(tǒng)建設(shè)的總體規(guī)劃應(yīng)包括以下幾個方面： 1.1.3 1.1.3 界定災(zāi)備系統(tǒng)的適用圍界定災(zāi)備系統(tǒng)的適用圍分析不同的應(yīng)用系統(tǒng)，確定災(zāi)備系統(tǒng)是一個覆蓋整個計算機系統(tǒng)的工程，根據(jù)業(yè)務(wù)的重要性，對不同的系統(tǒng)采用不同級別的容災(zāi)方案，如針對關(guān)鍵的業(yè)務(wù)應(yīng)用子系統(tǒng)，實施高級別的容災(zāi)工程；對低級別的業(yè)務(wù)系統(tǒng)，實施低級別的容災(zāi)工程。總之要建立一個綜合性的整體災(zāi)備建設(shè)工程。 1.1.4 1.1.4 界定災(zāi)備建設(shè)的目標(biāo)界定災(zāi)備建設(shè)的目標(biāo)生產(chǎn)系統(tǒng)在單位時間的數(shù)據(jù)處理能力或 IO 流量確定的情況下，RPO 實際上成為一個反映災(zāi)備恢復(fù)過程中的數(shù)據(jù)丟失量的指標(biāo)。而

26、RTO 則是指從災(zāi)難發(fā)生到備份系統(tǒng)可以接管原有生產(chǎn)系統(tǒng)所需要花費的時間，這不僅要考慮數(shù)據(jù)的恢復(fù)時間，還應(yīng)該考慮恢復(fù)后數(shù)據(jù)的完整性、一致性的修復(fù)和確認(rèn)、備份中心計算機處理系統(tǒng)的啟動和備份中心的網(wǎng)絡(luò)切換等全部時間?？傮w規(guī)劃中應(yīng)為災(zāi)備系統(tǒng)設(shè)定明確的 RPO 和RTO 指標(biāo)。 但是設(shè)計容災(zāi)系統(tǒng)不能只看 RTO 和 RPO，對于不同的業(yè)務(wù)系統(tǒng)和用戶特殊的要求，其它一些指標(biāo)有可能成為選擇容災(zāi)解決方案的主要因素。例如，某些地區(qū)為了防一些特定自然災(zāi)害的風(fēng)險，要求容災(zāi)備份中心與業(yè)務(wù)中心保持足夠的距離，在這種情況下，容災(zāi)備份中心與業(yè)務(wù)中心的距離要求就是容災(zāi)系統(tǒng)的重要指標(biāo)。 . . . 12 / 82通信網(wǎng)絡(luò)是容災(zāi)

27、系統(tǒng)的組成部分，通信線路的質(zhì)量也是容災(zāi)系統(tǒng)的性能指標(biāo)之一，其中包括網(wǎng)絡(luò)的數(shù)據(jù)傳輸帶寬、網(wǎng)絡(luò)傳輸通道的冗余和網(wǎng)絡(luò)服務(wù)商的服務(wù)水平（網(wǎng)絡(luò)年中斷率）。如果容災(zāi)系統(tǒng)使用的通信網(wǎng)絡(luò)是確定的，為了比較不同容災(zāi)解決方案，可以用單位存儲容量的數(shù)據(jù)庫在同一通信網(wǎng)絡(luò)上的數(shù)據(jù)完全恢復(fù)時間作為一項設(shè)計指標(biāo)。大部分業(yè)務(wù)系統(tǒng)都是數(shù)據(jù)庫應(yīng)用結(jié)構(gòu)，但業(yè)務(wù)系統(tǒng)容災(zāi)并不等于是數(shù)據(jù)庫容災(zāi)，還包括訪問數(shù)據(jù)庫的應(yīng)用程序和相關(guān)配置信息。實現(xiàn)數(shù)據(jù)庫容災(zāi)是容災(zāi)的基礎(chǔ)，在保數(shù)據(jù)庫數(shù)據(jù)一致的前提下，還要實現(xiàn)應(yīng)用程序和配置信息的一致性；實現(xiàn)應(yīng)用系統(tǒng)的高可用性、應(yīng)用程序在容災(zāi)中心與生產(chǎn)中心接管和切回的過程，因此，還要考慮應(yīng)用的模式是 C/S、B/S

28、，兩層、三層、多層次的應(yīng)用結(jié)構(gòu)等等。1.1.5 1.1.5 界定災(zāi)備系統(tǒng)的總體架構(gòu)界定災(zāi)備系統(tǒng)的總體架構(gòu)根據(jù)實際需求、現(xiàn)有技術(shù)、所在地域、計劃防的災(zāi)難種類和預(yù)算投入的資金量等實際情況，確定災(zāi)備系統(tǒng)預(yù)期達到的級別，并以此來確定災(zāi)備系統(tǒng)與生產(chǎn)運行系統(tǒng)在地理位置上的距離（同城還是異地或兩者兼?zhèn)浔竟?jié)點），備份數(shù)據(jù)存儲所在的介質(zhì)（磁盤還是磁帶或兩者兼?zhèn)洌?，備份?shù)據(jù)在生產(chǎn)中心與備份中心傳輸?shù)姆绞剑ㄟ@就涉與到了具體的計算機存儲與網(wǎng)絡(luò)技術(shù)），以與備份中心計算機系統(tǒng)的處理能力和網(wǎng)絡(luò)接管所需的具體架構(gòu)（是否與生產(chǎn)中心采用完全同等數(shù)量、容量和性能的計算機、存儲設(shè)備和網(wǎng)絡(luò)體系結(jié)構(gòu)）。 . . . 13 / 82第第

29、 2 2 章章 主流容災(zāi)技術(shù)說明主流容災(zāi)技術(shù)說明根據(jù) SHARE 78 評審標(biāo)準(zhǔn)，容災(zāi)技術(shù)必需涵蓋了如下容：2.1 2.1 數(shù)據(jù)備份數(shù)據(jù)備份數(shù)據(jù)備份是系統(tǒng)、數(shù)據(jù)容災(zāi)的基礎(chǔ)，也是低端容災(zāi)的實現(xiàn)，是高端容災(zāi)（實時數(shù)據(jù)保護）的有力保障。目前備份技術(shù)主要有快照備份、離線備份、異地存儲備份。備份系統(tǒng)通過備份策略，對計算機信息系統(tǒng)的操作系統(tǒng)、文件系統(tǒng)、應(yīng)用程序、數(shù)據(jù)庫系統(tǒng)等數(shù)據(jù)集，實現(xiàn)某一時間點的完整拷貝，拷貝的數(shù)據(jù)處在非在線狀態(tài)，不能被立刻訪問，必須通過相應(yīng)操作,如恢復(fù)等方式使用備份數(shù)據(jù)。這也解決了高端容災(zāi)（實時數(shù)據(jù)保護）不能解決的問題：人為誤操作、惡意性操作等，這類操作，計算機系統(tǒng)是不能區(qū)分的，一旦執(zhí)

30、行，將造成數(shù)據(jù)中心、災(zāi)備中心同時修改；對于數(shù)據(jù)庫系統(tǒng)，在日志方式下，可以通過回滾方式修改，對于文件系統(tǒng)、操作系統(tǒng)等其他配置信息是不能回滾的，將造成毀滅性的結(jié)果。因此在建設(shè)高端容災(zāi)系統(tǒng)的前提，一定要做好本地系統(tǒng)的備份，這是容災(zāi)技術(shù)的起點。目前成熟的備份軟件有某 NetBackup、EMC Legato，IBM TSM，HP Protect Server 等等。2.2 2.2 實時數(shù)據(jù)保護實時數(shù)據(jù)保護實時數(shù)據(jù)保護，就是在多塊磁盤上、多個陣列、多臺服務(wù)器、多個數(shù)據(jù)中心實時的保存同一份數(shù)據(jù)的多份存儲，目的是為了避免物理故障，數(shù)據(jù)不會因為一塊磁盤、一個陣列、一臺服務(wù)器、一個數(shù)據(jù)中心的故障，而不能訪問。注

31、意，實時數(shù)據(jù)保護需要以數(shù)據(jù)備份作為前提，它不能防人為誤操作和惡性操作。這里我們要強調(diào)容災(zāi)的目的是讓數(shù)據(jù)在災(zāi)難發(fā)生時，還能被訪問，通過實時數(shù)據(jù)保護，保證數(shù)據(jù)的完整性；因此實時數(shù)據(jù)保護是容災(zāi)手段，而不是目的。 . . . 14 / 82目前實時數(shù)據(jù)保護的技術(shù)主要有兩種：數(shù)據(jù)鏡像和數(shù)據(jù)復(fù)制。2.2.1 2.2.1 數(shù)據(jù)鏡像（數(shù)據(jù)鏡像（MirroringMirroring）數(shù)據(jù)鏡像（Mirroring）是冗余的一種類型，一個磁盤上的數(shù)據(jù)在另一個磁盤上存在一個完全一樣的副本即為鏡像。分軟件鏡像與硬件鏡像，它們的的區(qū)別就在于實現(xiàn)鏡像所需的 CPU 周期所處的位置。最終，都是根據(jù)程序的指令，為硬件（磁盤，以

32、與磁盤上存儲的數(shù)據(jù)）制作一個鏡像副本。鏡像可以保證兩份數(shù)據(jù)完全一樣。鏡像軟件有某 Volume Manager；各硬件廠商都有基于自己陣列的硬件鏡像方式。2.2.2 2.2.2 數(shù)據(jù)復(fù)制（數(shù)據(jù)復(fù)制（ReplicationReplication）數(shù)據(jù)復(fù)制（Replication）是將一個原數(shù)據(jù)的與其改動，通過后續(xù)機制拷貝到另外一處，可以是另一個磁盤、另一個陣列、另一個服務(wù)器、另一個數(shù)據(jù)中心。由于實現(xiàn)的機制不同，又分為同步復(fù)制和異步復(fù)制兩種方式。同步復(fù)制，能夠確保兩份數(shù)據(jù)完全一致，但對系統(tǒng)的影響較大，一般不會采用；異步復(fù)制，通過后續(xù)機制，確保將本地改動的數(shù)據(jù)復(fù)制的異地，對系統(tǒng)的影響較小，但數(shù)據(jù)同步

33、有延遲，是目前實現(xiàn)遠(yuǎn)程數(shù)據(jù)同步的主要方法。根據(jù)實現(xiàn)機制，數(shù)據(jù)復(fù)制分為軟件方式和硬件方式；硬件方式往往又被稱為遠(yuǎn)程鏡像。軟件復(fù)制有某 Volume Replicator；硬件復(fù)制有 EMC SRDF、HDSTrueCopy等。2 2. .2 2. .2 2. .1 1 軟軟件件復(fù)復(fù)制制（卷卷復(fù)復(fù)制制）某 Volume Replicator(簡稱 VVR)負(fù)責(zé)遠(yuǎn)程數(shù)據(jù)復(fù)制。VVR 復(fù)制基于 Volume 進行。復(fù)制的數(shù)據(jù)可以是數(shù)據(jù)庫中的數(shù)據(jù)（文件方式或裸設(shè)備方式），數(shù)據(jù)庫日志，復(fù)制的數(shù)據(jù)也可以是各種文件，如應(yīng)用和數(shù)據(jù)庫配置文件，應(yīng)用程序，庫文件，等等。復(fù)制的示意圖見圖四。 . . . 15 / 8

34、2VVR 與 VxVM 完全集成在一起。用 VxVM 管理界面和命令統(tǒng)一配置管理；由于 VVR僅僅將 Volume 上每次 I/O 的實際數(shù)據(jù)實時復(fù)制到遠(yuǎn)程節(jié)點，所以在網(wǎng)絡(luò)線路上傳輸?shù)臄?shù)據(jù)量很少，對帶寬的需求也很小，因此也與應(yīng)用無關(guān)，只要是在定義的復(fù)制卷上的仍和操作，都會被復(fù)制到異地。2 2. .2 2. .2 2. .2 2 硬硬件件復(fù)復(fù)制制以 EMC 的 SRDF 為例，如下圖：1系統(tǒng)定期檢測磁盤物理數(shù)據(jù)塊的改變狀況。 . . . 16 / 82如果發(fā)現(xiàn)有數(shù)據(jù)塊改動，將會被系統(tǒng)記錄，并一次性將改動過的數(shù)據(jù)塊考到復(fù)制緩存，這一動作被稱為 Switch?？截惖骄彺嬷械臄?shù)據(jù)塊，在下一個 Swit

35、ch 來臨之前，被復(fù)制到異地相應(yīng)的陣列緩存中。 . . . 17 / 82在下一個 Switch 時，本地數(shù)據(jù)塊被復(fù)制到本地存中，而異地緩存中上一次被改動過的數(shù)據(jù)塊才被復(fù)制到容災(zāi)系統(tǒng)中。根據(jù)實應(yīng)用圍，數(shù)據(jù)復(fù)制分為應(yīng)用復(fù)制、數(shù)據(jù)庫復(fù)制、卷復(fù)制、控制器復(fù)制。應(yīng)用復(fù)制，是指通過應(yīng)用系統(tǒng)直接向原生產(chǎn)中心和容災(zāi)中心同時發(fā)交易，生產(chǎn)中心和容災(zāi)中心都處理成功，該筆交易才算成功；只要有一邊應(yīng)用處理失敗，該筆 . . . 18 / 82交易就算失敗。由于交易的延遲性較大、健壯性較差，應(yīng)用復(fù)制一般不會考慮。應(yīng)用數(shù)據(jù)庫操作系統(tǒng)控制器物理磁盤數(shù)據(jù)塊SITE A應(yīng)用數(shù)據(jù)庫操作系統(tǒng)控制器物理磁盤SITE BIO LogS

36、QL/Log交易2 2. .2 2. .2 2. .3 3 數(shù)數(shù)據(jù)據(jù)庫庫復(fù)復(fù)制制數(shù)據(jù)庫復(fù)制，如 Oracle 的 Data Guard、Quest SharePlex、DSG RealSync 等，通過分析數(shù)據(jù)庫 Redo Log 和 Archive Log 實現(xiàn)日志的復(fù)制，將分析結(jié)果直接或轉(zhuǎn)化為 SQL 語句傳到容災(zāi)中心，在容災(zāi)過心 Aply 數(shù)據(jù)庫日志或?qū)⑷罩巨D(zhuǎn)化的 SQL 語句重做，來保證數(shù)據(jù)庫數(shù)據(jù)的一致性。數(shù)據(jù)庫復(fù)制實際上是應(yīng)用復(fù)制的數(shù)據(jù)庫實現(xiàn)，復(fù)制方式通過異步完成。卷復(fù)制如上某 Volume Replicator?？刂破鲝?fù)制，如上 EMC 的復(fù)制過程。 . . . 19 / 822

37、2. .2 2. .2 2. .4 4 I IB BM M S SV VC C實際上還有一種新的復(fù)制方式，稱為基于 SAN 網(wǎng)絡(luò)的卷復(fù)制，如 IBM 的 SVC。它是通過特殊的設(shè)備 SAN 控制器，建立基于 SAN 控制器的卷，通過這種與主機應(yīng)用無關(guān)，但與 SAN 控制器直接相關(guān)的卷實現(xiàn)復(fù)制。由于技術(shù)較新，且只有 IBM 一家推出，未得到其他硬件廠商支持，非主流技術(shù)，以下不再闡述。2.3 2.3 應(yīng)用系統(tǒng)恢復(fù)應(yīng)用系統(tǒng)恢復(fù)正如前所述，數(shù)據(jù)復(fù)制是容災(zāi)的手段，不是目的，容災(zāi)的目的是數(shù)據(jù)的訪問。正如前所述，數(shù)據(jù)復(fù)制是容災(zāi)的手段，不是目的，容災(zāi)的目的是數(shù)據(jù)的訪問。因此應(yīng)用的恢復(fù)和以下的網(wǎng)絡(luò)的恢復(fù)也是容災(zāi)

38、的關(guān)鍵。因此應(yīng)用的恢復(fù)和以下的網(wǎng)絡(luò)的恢復(fù)也是容災(zāi)的關(guān)鍵。應(yīng)用系統(tǒng)恢復(fù)，這和系統(tǒng)的應(yīng)用模式直接相關(guān)。需要考慮應(yīng)用系統(tǒng)的應(yīng)用架構(gòu)。是 Client/Server 架構(gòu)，還是 Broswer/Server 架構(gòu)；是 2 層架構(gòu)、還是 3 層架構(gòu)、還是多層架構(gòu)。兩層架構(gòu)，表示容災(zāi)中心的應(yīng)用只要啟動數(shù)據(jù)庫就可以服務(wù)了。如果是三層架構(gòu)，就意味著應(yīng)用系統(tǒng)除數(shù)據(jù)庫以外，還有網(wǎng)絡(luò)服務(wù)程序，如中間件Tuxedo、CICS、WebLogic、WebSphere、9iAS、SAP 等等。在容災(zāi)應(yīng)用切換時，能夠手工或自動化的將這些服務(wù)一一啟動。2.4 2.4 網(wǎng)絡(luò)系統(tǒng)恢復(fù)網(wǎng)絡(luò)系統(tǒng)恢復(fù)在災(zāi)難發(fā)生后，應(yīng)用切換到災(zāi)備中心了，

39、本地的應(yīng)用前端需要重新訪問容災(zāi)節(jié)點的服務(wù)，帶來另外一個問題，網(wǎng)絡(luò)如何切換？是建立新的網(wǎng)絡(luò)，還是使用動態(tài)路由，還是有其它辦法？實際上最簡單的辦法，就是通過外部 DNS 服務(wù)器，改變服務(wù)器名和 IP 的映射關(guān)系，將原服務(wù)器名映射到新的 IP 地址上，就可以利用容災(zāi)網(wǎng)絡(luò)，實現(xiàn)前端對容災(zāi)中心服務(wù)器數(shù)據(jù)的訪問。 . . . 20 / 822.5 2.5 容災(zāi)切換過程容災(zāi)切換過程就是在災(zāi)難發(fā)生后，數(shù)據(jù)庫切換、應(yīng)用重新啟動、網(wǎng)絡(luò)實現(xiàn)切換等等,容災(zāi)中心接管原生產(chǎn)中心的整個過程；同時還包含了在原數(shù)據(jù)中心修復(fù)后，數(shù)據(jù)庫、應(yīng)用、網(wǎng)絡(luò)需要重新切會來的整個過程。這些過程，可以通過手工切換、也可以通過自動化過程完成。2.

40、6 2.6 消防演習(xí)消防演習(xí)大部分的容災(zāi)方案，在項目實施后，很難有機會來實現(xiàn)預(yù)演，因為對于大部分方案來說，這種預(yù)演活動，需要耗費大量的人力財力。但是消防預(yù)演是必不可少的，它是實時測試目前的容災(zāi)方案的漏洞，保證容災(zāi)方案在災(zāi)難發(fā)生時，能夠真正生效。第第 3 3 章章 主流容災(zāi)技術(shù)分析與對比主流容災(zāi)技術(shù)分析與對比沒有一種技術(shù)可以解決所有得 IT 問題，因此，也沒有一個解決方案是完美無缺 . . . 21 / 82得，依據(jù)現(xiàn)狀、技術(shù)要求、和未來的拓展，我們在此討論的是最合適容災(zāi)技術(shù)的解決方案。3.1 3.1 數(shù)據(jù)備份數(shù)據(jù)備份SHARE 78 評審標(biāo)準(zhǔn)中，Tier 0、Tier 1、Tier2 級別容災(zāi)

41、要解決的問題。如前面所闡述的，數(shù)據(jù)備份是容災(zāi)系統(tǒng)的起點，是最低端的容災(zāi)方案。不是說有了高端的實時容災(zāi)方案，就可以不要備份系統(tǒng)了，因為實時容災(zāi)不能解決惡性操作、誤操作等故障，而備份系統(tǒng)可以解決。在此我們要討論的是，如何利用現(xiàn)有的備份系統(tǒng)，是容災(zāi)方案更加完備。正如 Veritas 的備份軟件 NetBackup, 對目前所有的操作系統(tǒng)AIX、Solaris、HPUnix、Windows、數(shù)據(jù)庫 Oracle、SQL Server、DB2、SybaseASE 等，Veritas NetBackup 除了可以很好的備份相關(guān)的文件系統(tǒng)數(shù)據(jù)、數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)外，同時通過 BMR(Bare Metal Res

42、tore:裸金屬恢復(fù))模塊，可以對 AIX、Solaris、HPUnix、Windows、Linux 操作系統(tǒng)實現(xiàn)備份，備份這些操作系統(tǒng)的相關(guān)補丁、外設(shè)驅(qū)動程序、相關(guān)的文件系統(tǒng)配置信息、相關(guān)的卷配置信息、核參數(shù)等。在災(zāi)難修復(fù)時，可以通過恢復(fù)的方式快速恢復(fù)相關(guān)操作系統(tǒng)。實際經(jīng)驗，操作系統(tǒng)安裝、打補丁，安裝相關(guān)驅(qū)動程序、恢復(fù)核參數(shù)、恢復(fù)文件系統(tǒng)配置、恢復(fù)卷管理系統(tǒng)配置等整個過程，可以縮短在 1 小時完成，并且降低了人為錯誤操作過程。這樣大大提高了原生產(chǎn)中心容災(zāi)恢復(fù)的能力。而其他備份產(chǎn)品，或沒有類似與 BMR 的模塊；或是不能支持AIX、Solaris、HPUnix、Windows、Linux 全部

43、操作系統(tǒng)，也就是說，不能實現(xiàn)統(tǒng)一的容災(zāi)應(yīng)對策略，反而會增加容災(zāi)的復(fù)雜度。Veritas NetBackup 還有另外一個叫 Vault 的模塊，可以實現(xiàn)對備份數(shù)據(jù)的自動拷貝，并實現(xiàn)異地存放和管理。Share 78 中 Tier 1 、Tier 2 級別容災(zāi)。 . . . 22 / 82Veritas NetBackup 還能構(gòu)實現(xiàn)快照備份，就是備份時對原盤做磁盤級快照。Veritas NetBackup 可以和 Veritas Volume Snapshot、EMC TimeFinder 等業(yè)界主流的快照工具做整合，實現(xiàn) Server-Free (OFF-Host)的備份，既備份時，原應(yīng)用服務(wù)

44、器不參與的備份，大大提供了備份系統(tǒng)的能力。Veritas NetBackup 針對 AIX、Solaris、HPUnix、Windows、Linux 的備份，無論選擇何種平臺作為主控服務(wù)器、無論如何調(diào)整，都是通過同一 Java GUI 和 Web GUI 實現(xiàn)管理，簡單易用，用戶容易掌握。3.2 3.2 實時數(shù)據(jù)保護實時數(shù)據(jù)保護SHARE 78 評審標(biāo)準(zhǔn)中，Tier 3 級別容災(zāi)。3.2.1 3.2.1 數(shù)據(jù)鏡像（數(shù)據(jù)鏡像（MirroringMirroring）數(shù)據(jù)鏡像分軟件鏡像與硬件鏡像。3 3. .2 2. .1 1. .1 1 硬硬件件鏡鏡像像通過硬件級別的 Raid-1 實現(xiàn)，其實現(xiàn)過

45、程簡單，但要求嚴(yán)格。只能基于同一廠商、同一陣列、同樣容量大小的兩塊磁盤來實現(xiàn)。3 3. .2 2. .1 1. .2 2 軟軟件件鏡鏡像像Veritas Volume Manager 實現(xiàn)邏輯卷級鏡像，對存儲空間要求較低，只要有空間且至少兩塊磁盤就行。不要求同一廠商、同一陣列、同樣容量大小的兩塊磁盤，Veritas Volume Manager 能夠?qū)崿F(xiàn)跨廠商、跨陣列的鏡像，在磁盤空間不均時，能夠?qū)崿F(xiàn) 1 塊磁盤對多塊磁盤、N 塊磁盤對 M 塊磁盤的鏡像。 . . . 23 / 823 3. .2 2. .1 1. .3 3 鏡鏡像像技技術(shù)術(shù)在在容容災(zāi)災(zāi)中中的的利利用用在通過 SAN 的支持，

46、DWDM 的拓展，光纖網(wǎng)絡(luò)可以擴展到 100 公里或更遠(yuǎn)，鏡像可以在較遠(yuǎn)的兩個數(shù)據(jù)中心的磁盤上建立。但由于鏡像系統(tǒng)是以同步方式實現(xiàn)的，受到距離、光纖協(xié)議、和相關(guān)協(xié)議轉(zhuǎn)換的影響，同步方式會影響本地服務(wù)器的性能，所以，一般建議在20 公里的同城容災(zāi)中使用，在遠(yuǎn)程容災(zāi)中可作為一種加強方案與遠(yuǎn)程容災(zāi)方案整合，將在我們的詳細(xì)方案中描述。常說的遠(yuǎn)程磁盤鏡像，實際上是遠(yuǎn)程磁盤復(fù)制，不是真正意義上的鏡像。我們將在后續(xù)文章描述?；?SAN 的鏡像，在容災(zāi)實現(xiàn)中，使用圍較小，如上說述，適用于同城容災(zāi)，但支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設(shè)備、應(yīng)用配置文件、應(yīng)用程序、庫函數(shù)等，因而支持各類應(yīng)用系

47、統(tǒng)容災(zāi)，包括數(shù)據(jù)庫、中間件、客戶自己開發(fā)的應(yīng)用，適用于 2 層架構(gòu)、3 層或多層應(yīng)用架構(gòu)。3.2.2 3.2.2 數(shù)據(jù)復(fù)制（數(shù)據(jù)復(fù)制（ReplicationReplication）數(shù)據(jù)復(fù)制是運程容災(zāi)實現(xiàn)的基礎(chǔ)。3 3. .2 2. .2 2. .1 1 軟軟件件復(fù)復(fù)制制（卷卷復(fù)復(fù)制制）VERITAS Volume Replicator(簡稱 VVR)負(fù)責(zé)遠(yuǎn)程數(shù)據(jù)復(fù)制。VVR 復(fù)制基于Volume 進行，將數(shù)據(jù)特別是需要進行遠(yuǎn)程復(fù)制的相關(guān)文件系統(tǒng)、數(shù)據(jù)庫、裸設(shè)備、應(yīng)用程序等，存放在復(fù)制卷組中，系統(tǒng)便能自動同步本地和異地相應(yīng)的復(fù)制卷組。 . . . 24 / 82復(fù)制的示意圖見圖四。VVR 與 V

48、xVM 完全集成在一起。用 VxVM 管理 GUI 界面和命令統(tǒng)一配置管理；由于VVR 僅僅將 Volume 上每次 I/O 的操作復(fù)制到遠(yuǎn)程節(jié)點，復(fù)制的信息是卷的日志，所以在網(wǎng)絡(luò)線路上傳輸?shù)臄?shù)據(jù)量很少，對帶寬的需求也較小。；Storage Replicator Log(簡稱 SRL)是 VVR 中的重要部件。需要復(fù)制的 I/O 操作，首先要寫入 SRL，然后傳到異地。VVR 通過 SRL 保證數(shù)據(jù)復(fù)制嚴(yán)格按照寫順序進行，這在異步工作方式下非常重要。當(dāng)網(wǎng)絡(luò)中斷或異地系統(tǒng)出現(xiàn)故障時，本地數(shù)據(jù)將記錄在 SRL 中，當(dāng) SRL 滿后，VVR 將使用 DCM(Data Change Map)記錄變化的

49、數(shù)據(jù)塊的塊號，等系統(tǒng)恢復(fù)正常時再將 SRL 中的數(shù)據(jù)按照先進先出的順序傳送到異地，最后再將 DCM 中記錄的塊傳送到異地。 VVR 數(shù)據(jù)流程見圖五： . . . 25 / 82 圖五數(shù)據(jù)復(fù)制的工作模式缺省為同步/異步自適應(yīng)，即在網(wǎng)絡(luò)延時情況較好、數(shù)據(jù)能夠與時復(fù)制時，工作在同步方式，完全保證兩邊數(shù)據(jù)的一致性；當(dāng)網(wǎng)絡(luò)延時情況較差、數(shù)據(jù)不能與時復(fù)制時，工作在異步方式下，保證主節(jié)點的 I/O 性能。數(shù)據(jù)復(fù)制根據(jù)實際情況，自行在兩種工作模式之間切換。并且基于卷的日志（SRL：先進先出）保正了再極端情況下，如容災(zāi)網(wǎng)絡(luò)中斷、數(shù)據(jù)復(fù)制不能正常進行，容災(zāi)中心數(shù)據(jù)于生產(chǎn)中心數(shù)據(jù)有延遲，在一切故障排除后，能夠嚴(yán)格保

50、證所以 I/O 的寫順序，這類似于數(shù)據(jù)庫數(shù)據(jù)塊和數(shù)據(jù)庫日志的關(guān)系，通過帶時間戳的數(shù)據(jù)塊和順序日志，保證數(shù)據(jù)的一致性?；谲浖倪h(yuǎn)程復(fù)制，在容災(zāi)實現(xiàn)中，使用圍最廣，支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設(shè)備、應(yīng)用配置文件、應(yīng)用程序、庫函數(shù)等，支持各類應(yīng)用系統(tǒng)容災(zāi)，包括數(shù)據(jù)庫、中間件、客戶自己開發(fā)的應(yīng)用，適用于 2 層架構(gòu)、3 層或多層應(yīng)用架構(gòu)。 . . . 26 / 823 3. .2 2. .2 2. .2 2 硬硬件件復(fù)復(fù)制制通過所謂的遠(yuǎn)程磁盤鏡像實現(xiàn)，其實現(xiàn)要求嚴(yán)格。只能基于同一廠商、同型號陣列、同樣容量大小的兩個陣列來實現(xiàn)。廠商一般建議使用間歇性復(fù)制。遠(yuǎn)程磁盤鏡像（復(fù)制），

51、在容災(zāi)實現(xiàn)中，支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設(shè)備、應(yīng)用配置文件、應(yīng)用程序、庫函數(shù)等，支持各類應(yīng)用系統(tǒng)容災(zāi)，包括數(shù)據(jù)庫、中間件、客戶自己開發(fā)的應(yīng)用，適用于 2 層架構(gòu)、3 層或多層應(yīng)用架構(gòu)。與應(yīng)用無關(guān)，但與磁盤陣列直接相關(guān)。只能基于同一廠商、同樣容量大小的兩個陣列來實現(xiàn)。受光纖線路影響、復(fù)制數(shù)據(jù)量大，在使用間歇性復(fù)制時，數(shù)據(jù)延遲大，磁盤容量要求 4 倍于源數(shù)據(jù)，并且在極端情況下，不能保證數(shù)據(jù)一致性。硬件復(fù)制的過程，在上文已經(jīng)描述。下面我們將描述極端情況。磁盤復(fù)制在生產(chǎn)中心和容災(zāi)中心復(fù)制的是改動過的物理數(shù)據(jù)塊，而物理數(shù)據(jù)塊的寫是無序的。為了保證數(shù)據(jù)的一致性，通過帶時間戳的數(shù)據(jù)

52、塊，改善了一定的數(shù)據(jù)塊的無序性，但仍然不能解決。我們看到，數(shù)據(jù)庫是通過帶時間戳的數(shù)據(jù)塊和聯(lián)機日志一起來解決，如果一個數(shù)據(jù)文件中的數(shù)據(jù)塊的時間戳不一致，數(shù)據(jù)庫需要日志來修正，日志中記錄的是一些有序的數(shù)據(jù)庫操作，通過 Recover 的動作，將不一致的數(shù)據(jù)文件，前滾或后滾到某一特定時間點。帶時間戳的數(shù)據(jù)文件和有序的日志，二者缺一不可，否則不能保證數(shù)據(jù)的一致性。在磁盤復(fù)制中，唯獨少了至關(guān)重要的磁盤寫日志（不可能有）。更有甚，如果這種磁盤塊的無序?qū)?，發(fā)生在數(shù)據(jù)庫的聯(lián)機日志上，那將對數(shù)據(jù)庫數(shù)據(jù)的一致性造成破壞。3 3. .2 2. .2 2. .3 3 數(shù)數(shù)據(jù)據(jù)庫庫復(fù)復(fù)制制數(shù)據(jù)庫復(fù)制，如 Oracle

53、的 Data Guard、Quest SharePlex、DSG RealSync 等，通過分析數(shù)據(jù)庫 Redo Log 和 Archive Log 實現(xiàn)日志的復(fù)制，將分析結(jié)果直接或轉(zhuǎn) . . . 27 / 82化為 SQL 語句傳到容災(zāi)中心，在容災(zāi)過心 Aply 數(shù)據(jù)庫日志或?qū)⑷罩巨D(zhuǎn)化的 SQL 語句重做，來保證容災(zāi)中心數(shù)據(jù)與生產(chǎn)中心數(shù)據(jù)一致。數(shù)據(jù)庫復(fù)制，在簡單的環(huán)境中，實現(xiàn)兩個較小的數(shù)據(jù)庫數(shù)據(jù)同步，可以說是一個簡化的解決方案。對于容災(zāi)環(huán)境，我們認(rèn)為大大不合適，原因如下。數(shù)據(jù)庫復(fù)制，是專門針對相應(yīng)數(shù)據(jù)庫的，只能實現(xiàn)單一的數(shù)據(jù)庫復(fù)制?，F(xiàn)有的數(shù)據(jù)庫就有 Oracle ,SQL Server，DB

54、2，Sybase ASE。在容災(zāi)系統(tǒng)中，如果使用數(shù)據(jù)庫復(fù)制方式，管理員將要維護 Oracle 一套、SQL Server 一套、DB2 一套、等相互各不一樣的數(shù)據(jù)庫復(fù)制技術(shù)，管理和維護工作根本不能保證其能夠正常運行。下面我們就以 Oracle 為例，雖然有眾多廠商、技術(shù)方案支持的數(shù)據(jù)庫復(fù)制，仍然有不可逾越的技術(shù)障礙。Oracle 數(shù)據(jù)庫的容災(zāi)復(fù)制被稱為 Standby Database, 其產(chǎn)生于 Oracle 7.3，在 Oracle 9i 后，改稱為 Data Guard。Standby Database 又分為 Physical Standby，和 Logical Standby。Phy

55、sical Standby 方式是將生產(chǎn)中心產(chǎn)生的數(shù)據(jù)庫redo log 和 archive log，不停復(fù)制到容災(zāi)中心，不停的 apply log，來實現(xiàn)容災(zāi)中心的數(shù)據(jù)庫與生產(chǎn)中心一致。Logical Standby，是通過解析 redo log 和archive log，產(chǎn)生相關(guān)的 SQL 語句，把這些語句傳到容災(zāi)中心重做。Quest SharePlex 和 DSG 的 Realsync 類似與 Data Guard 的 Logical Stand by，復(fù)制 SQL語句。1容災(zāi)的目的是使數(shù)據(jù)能夠被正常訪問，業(yè)務(wù)能夠正常運行。數(shù)據(jù)庫復(fù)制技術(shù)，不是一個完整的容災(zāi)解決方案，只能有限的復(fù)制數(shù)據(jù)庫

56、數(shù)據(jù)，不能復(fù)制其他的應(yīng)用程序，配置文件，就是 Oracle 自己的 tnsnames.ora, listner.ora，initSID.ora, *.ctl 也不能復(fù)制，一旦這些文件改動過，將需要管員人為操作或者需要其他軟件的管理，保證容災(zāi)中心與生產(chǎn)中心同步應(yīng)用、程序、配置文件同步。2由于 Data Guard 是通過日志來實現(xiàn)的，這要求數(shù)據(jù)庫必須運行在歸檔日志 . . . 28 / 82模式下。但我們知道，并不是所有的數(shù)據(jù)庫操作都寫日志：oracle 的 DML（Data Manipulation Language）或 DDL（Data Dictionary Language）語句是不能被復(fù)

57、制的，如 create index、table，alter table 等等；觸發(fā)器、存儲過程操作不能被復(fù)制；系統(tǒng)升級、patchs 更新不能被復(fù)制。3與備份軟件的沖突。如前所述，對于核心應(yīng)用系統(tǒng)，數(shù)據(jù)備份必不可少。對于數(shù)據(jù)庫的備份，也要求數(shù)據(jù)庫在歸檔模式下運行。備份系統(tǒng)在備份作用發(fā)起時，需要備份數(shù)據(jù)文件、control file、歸檔日志、甚至需要數(shù)據(jù)庫實現(xiàn)強制歸檔，來備份歸檔日志，備份作業(yè)成功后，由備份系統(tǒng)自動刪除備份過的歸檔日志，應(yīng)為當(dāng)數(shù)據(jù)庫運行在歸檔日志模式下時，歸檔日志往往因數(shù)據(jù)庫繁忙而快速大量產(chǎn)生，需要備份軟件自動清除維護，否則當(dāng)歸檔日志空間占滿后，聯(lián)機日志不能歸檔時，生產(chǎn)數(shù)據(jù)庫不

58、在運作，則所有應(yīng)用業(yè)務(wù)不能操作，釀成生產(chǎn)事故。為了不影響生產(chǎn)環(huán)境，問題一，在備份作業(yè)發(fā)起，強制歸檔；備份完成后，刪除歸檔日志后，數(shù)據(jù)庫復(fù)制軟件，該如何操作，將嚴(yán)重造成生產(chǎn)中心和容災(zāi)中心數(shù)據(jù)不一致。如果備份作用不刪除歸檔日志，系統(tǒng)管理員將不定時的來維護歸檔目錄，他必須知道本地歸檔目錄中，哪一個歸檔日志已經(jīng)被備份，通過檢查容災(zāi)中心數(shù)據(jù)庫中哪一個歸檔日志已經(jīng)被 apply，這將是一個惡夢一樣的維護工作。4極限情況下的危害。當(dāng)生產(chǎn)中心和容災(zāi)中心的復(fù)制鏈路一定時期不能恢復(fù)時，同樣需要在生產(chǎn)主機中保留所有的歸檔日志，這又需要管理員大量的維護工作。3 3. .2 2. .2 2. .4 4 數(shù)數(shù)據(jù)據(jù)庫庫雙雙

59、活活在 Data Guard 中 PhysicalStandby 模式下，數(shù)據(jù)庫可以通過 read-only 方式打開。正如前面所述，Physical Standby 通過 apply 數(shù)據(jù)日志，實現(xiàn)數(shù)據(jù)庫復(fù)制。但數(shù)據(jù)庫被以 read-only 方式打開時，新的日志將不能被追加，必須將數(shù)據(jù)庫重新切換到 recover 模式下，才能繼續(xù) apply 日志。也就是說數(shù)據(jù)庫是被間歇式打開，影響數(shù)據(jù)庫日志的追加不說，試問，什么應(yīng)用對數(shù)據(jù)庫的操作是間歇式，應(yīng)用程序也要間歇式的啟動和停止。并且在 read-only 方式下，一切在數(shù)據(jù)庫中又修改、增加的操作，都會被以錯誤方式返回，什么應(yīng)用不寫數(shù)據(jù)庫？ .

60、. . 29 / 82Data Guard 中 Logical Standby 模式下（Quest SharePlex、DSG Realsync 類似）數(shù)據(jù)庫可以被正常打開和操作。這也是需要大量的系統(tǒng)維護工作作為保障的，如前面描述的日志的維護問題。是的，該功能有一定的應(yīng)用場所，但也是需要高量的管理和維護來保證。因為在這種模式下，生產(chǎn)中心和容災(zāi)中心實際上是兩個獨立的數(shù)據(jù)庫，兩個數(shù)據(jù)庫的數(shù)據(jù)有可能出現(xiàn)不一致的情況。因此，如何確定兩個數(shù)據(jù)庫的一致性，又將是一個技術(shù)難題，如果不一致，又將以誰為準(zhǔn)？容災(zāi)中心的數(shù)據(jù)庫數(shù)據(jù)是生產(chǎn)中心的備份，數(shù)據(jù)應(yīng)完全一致，這是容災(zāi)的宗旨，為此，我們花費了大量的人力、物力和財