通信容災項目方案設計-賽門鐵克

容災工程方案設計賽門鐵克軟件〔北京〕廣州分公司2007年目錄TOC\o"1-4"\h\z\u第1章 容災技術(shù)標準 6 容災的總體規(guī)劃 6 技術(shù)指標RPO、RTO 6 國際標準SHARE

78 7 Tier0 8 Tier1 9 Tier2 9 Tier3 10 Tier4 10 Tier5 10 Tier6 11 界定災備系統(tǒng)的適用范圍 11 界定災備建設的目標 12 界定災備系統(tǒng)的總體架構(gòu) 12第2章 主流容災技術(shù)說明 14 數(shù)據(jù)備份 14 實時數(shù)據(jù)保護 14 數(shù)據(jù)鏡像〔Mirroring〕 15 數(shù)據(jù)復制〔Replication〕 15 軟件復制〔卷復制〕 15 硬件復制 16 數(shù)據(jù)庫復制 19 IBMSVC 20 應用系統(tǒng)恢復 20 網(wǎng)絡系統(tǒng)恢復 20 容災切換過程 21 消防演習 21第3章 主流容災技術(shù)分析與比照 22 數(shù)據(jù)備份 22 實時數(shù)據(jù)保護 23 數(shù)據(jù)鏡像〔Mirroring〕 23 硬件鏡像 23 軟件鏡像 24 鏡像技術(shù)在容災中的利用 24 數(shù)據(jù)復制〔Replication〕 24 軟件復制〔卷復制〕 25 硬件復制 27 數(shù)據(jù)庫復制 28 數(shù)據(jù)庫雙活 29 瞬間快照(InstantSnapshot) 30 應用系統(tǒng)恢復 31 網(wǎng)絡系統(tǒng)恢復 32 容災切換過程 33 消防演習 33第4章 Symantec容災方案主要技術(shù)介紹 33 SymantecNetBackup數(shù)據(jù)備份技術(shù) 34 無限可伸縮性 34 平臺獨立性 34 基于策略的集中式管理 34 無與倫比的性能 34 透明的不間斷備份 34 支持最新存儲硬件 34 可伸縮三/四層體系架構(gòu) 35 NetBackupMasterServer 36 NetBackupMediaServer 36 NetBackupClient 36 全球管理與實時報告：NOM 36 先進報表：NetBackupAdvancedReporter? 37 數(shù)據(jù)庫在線備份：DatabaseAgent 38 數(shù)據(jù)庫歸檔：NetBackupDatabaseArchiver 38 塊級增量備份：Block-LevelIncrementalBackup 39 系統(tǒng)災難恢復：BareMetalRestore 39 高速閃備份：NetBackupFlashBackup? 41 翻開文件備份：OpenTransactionManager 42 磁帶庫動態(tài)共享：SharedStorageOption? 42 無主機備份：NetBackupServer－FreeAgent 43 磁帶容災和管理：NetBackupVault 43 網(wǎng)絡存儲藏份：NetBackup?forNDMP 44 備份數(shù)據(jù)加密：ClientEncryptionOption 45 磁帶庫驅(qū)動：TapeLibrarySupport 45 其它功能 45 SymantecStorageFoundation 46 SymantecVolumeManager? 47 更高的系統(tǒng)與應用性能 47 數(shù)據(jù)完整性提高，停機時間縮短 47 硬件與軟件投資保護 47 SymantecFileSystem? 48 用戶與管理員工作效率提高 48 可靠的系統(tǒng)數(shù)據(jù)帶來可靠的業(yè)務解決方案 48 簡單而強大的系統(tǒng)管理功能 48 SymantecStorageFoundation解決方案說明 48 性能、可用性與平安性 49 可擴展性 50 集中式管理 51 異類環(huán)境支持 52 優(yōu)異的集成性能 52 邏輯卷快照 53 snapshot快速重鏡像(FastResync) 53 動態(tài)拆分和重組〔DynamicsplitandJoin〕 54 邏輯卷快照技術(shù)的特點 54 Snapshot如何工作 54 瞬間快照(InstantSnapshot) 56 領先的企業(yè)級高可用性應用軟件解決方案 56 SymantecClusterServer特征 57 領先的異構(gòu)平臺HA解決方案 57 可伸縮性 58 可定制 58 補充保護 58 災難恢復解決方案的重要組成成分 58 SymantecClusterServer特性優(yōu)勢 59 全面的高可用性特性 59 最廣泛的應用支持 59 異構(gòu)平臺和存儲器支持 59 行業(yè)最具伸縮性的解決方案 60 多種存儲支持 60 用于集群管理，基于JAVA的直覺圖形用戶界面〔GUI〕 60 通用原子播送機〔GAB〕 60 自動集群傳播 61 集群的集群 61 GlobalClusterOption的特點 61 GlobalClusterOption運作過程 62第5章 系統(tǒng)詳細設計方案 64 第一步，深化數(shù)據(jù)備份系統(tǒng) 64 第二步，存儲、應用整合 65 存儲整合 65 應用整合 65 第三步，實現(xiàn)遠程實時數(shù)據(jù)卷保護 66 第四步，建立遠程切換消防演習機制 66 第五步，建立遠程切換機制 67 Oracle數(shù)據(jù)庫切換詳解 67第6章 數(shù)據(jù)容災的性能分析 69 同步數(shù)據(jù)容災的性能分析 69 帶寬 69 距離 69 中間鏈路設備和協(xié)議轉(zhuǎn)換的時延 70 異步數(shù)據(jù)容災的性能分析 72 有關(guān)半同步 77 容災技術(shù)對照 78第7章 系統(tǒng)預算 79第8章 主要技術(shù)的應用實例 80 中國聯(lián)通 80 ICONClinical 80 BlueStar 81第9章 應急預案的編制 82 Symantec技術(shù)力量 82 Symantec工程組成員名單 83第10章 定期災難性恢復測試方案及檢驗 84第11章 售后效勞方式、方法 84 Symantec中國技術(shù)支持效勞中心 84 技術(shù)支持效勞介紹 84 提供支持的流程： 85 Symantec公司向用戶提供如下支持效勞： 85

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

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

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

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

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

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

●備份/恢復的范圍

●災難恢復方案的狀態(tài)

●業(yè)務中心與容災中心之間的距離

●業(yè)務中心與容災中心之間如何連接

●數(shù)據(jù)是怎樣在兩個中心之間傳送的

●允許有多少數(shù)據(jù)喪失

●保證更新的數(shù)據(jù)在容災中心被更新

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

SHARE78是建立容災系統(tǒng)的一種評審標準。建立容災系統(tǒng)的最終目的，是為了在災難發(fā)生后能夠以最快速度恢復數(shù)據(jù)效勞，主要表達在RTOObjective)和RPO上。SHARE

78,

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

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

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

根據(jù)實際需求、現(xiàn)有技術(shù)、所在地域、方案防范的災難種類和預算投入的資金量等實際情況，確定災備系統(tǒng)預期到達的級別，并以此來確定災備系統(tǒng)與生產(chǎn)運行系統(tǒng)在地理位置上的距離〔同城還是異地或兩者兼?zhèn)洌竟?jié)點〕，備份數(shù)據(jù)存儲所在的介質(zhì)〔磁盤還是磁帶或兩者兼?zhèn)洹?，備份?shù)據(jù)在生產(chǎn)中心與備份中心傳輸?shù)姆绞健策@就涉及到了具體的計算機存儲與網(wǎng)絡技術(shù)〕，以及備份中心計算機系統(tǒng)的處理能力和網(wǎng)絡接管所需的具體架構(gòu)〔是否與生產(chǎn)中心采用完全同等數(shù)量、容量和性能的計算機、存儲設備和網(wǎng)絡體系結(jié)構(gòu)〕。主流容災技術(shù)說明根據(jù)SHARE78評審標準，容災技術(shù)必需涵蓋了如下內(nèi)容：數(shù)據(jù)備份數(shù)據(jù)備份是系統(tǒng)、數(shù)據(jù)容災的根底，也是低端容災的實現(xiàn)，是高端容災〔實時數(shù)據(jù)保護〕的有力保障。目前備份技術(shù)主要有快照備份、離線備份、異地存儲藏份。備份系統(tǒng)通過備份策略，對計算機信息系統(tǒng)的操作系統(tǒng)、文件系統(tǒng)、應用程序、數(shù)據(jù)庫系統(tǒng)等數(shù)據(jù)集，實現(xiàn)某一時間點的完整拷貝，拷貝的數(shù)據(jù)處在非在線狀態(tài)，不能被立刻訪問，必須通過相應操作,如恢復等方式使用備份數(shù)據(jù)。這也解決了高端容災〔實時數(shù)據(jù)保護〕不能解決的問題：人為誤操作、惡意性操作等，這類操作，計算機系統(tǒng)是不能區(qū)分的，一旦執(zhí)行，將造成數(shù)據(jù)中心、災備中心同時修改；對于數(shù)據(jù)庫系統(tǒng)，在日志方式下，可以通過回滾方式修改，對于文件系統(tǒng)、操作系統(tǒng)等其他配置信息是不能回滾的，將造成消滅性的結(jié)果。因此在建設高端容災系統(tǒng)的前提，一定要做好本地系統(tǒng)的備份，這是容災技術(shù)的起點。目前成熟的備份軟件有SymantecNetBackup、EMCLegato，IBMTSM，HPProtectServer等等。實時數(shù)據(jù)保護實時數(shù)據(jù)保護，就是在多塊磁盤上、多個陣列、多臺效勞器、多個數(shù)據(jù)中心實時的保存同一份數(shù)據(jù)的多份存儲，目的是為了防止物理故障，數(shù)據(jù)不會因為一塊磁盤、一個陣列、一臺效勞器、一個數(shù)據(jù)中心的故障，而不能訪問。注意，實時數(shù)據(jù)保護需要以數(shù)據(jù)備份作為前提，它不能防范人為誤操作和惡性操作。這里我們要強調(diào)容災的目的是讓數(shù)據(jù)在災難發(fā)生時，還能被訪問，通過實時數(shù)據(jù)保護，保證數(shù)據(jù)的完整性；因此實時數(shù)據(jù)保護是容災手段，而不是目的。目前實時數(shù)據(jù)保護的技術(shù)主要有兩種：數(shù)據(jù)鏡像和數(shù)據(jù)復制。數(shù)據(jù)鏡像〔Mirroring〕數(shù)據(jù)鏡像〔Mirroring〕是冗余的一種類型，一個磁盤上的數(shù)據(jù)在另一個磁盤上存在一個完全相同的副本即為鏡像。分軟件鏡像與硬件鏡像，它們的的區(qū)別就在于實現(xiàn)鏡像所需的CPU周期所處的位置。最終，都是根據(jù)程序的指令，為硬件〔磁盤，以及磁盤上存儲的數(shù)據(jù)〕制作一個鏡像副本。鏡像可以保證兩份數(shù)據(jù)完全一樣。鏡像軟件有SymantecVolumeManager；各硬件廠商都有基于自己陣列的硬件鏡像方式。數(shù)據(jù)復制〔Replication〕數(shù)據(jù)復制〔Replication〕是將一個原數(shù)據(jù)的及其改動，通過后續(xù)機制拷貝到另外一處，可以是另一個磁盤、另一個陣列、另一個效勞器、另一個數(shù)據(jù)中心。由于實現(xiàn)的機制不同，又分為同步復制和異步復制兩種方式。同步復制，能夠確保兩份數(shù)據(jù)完全一致，但對系統(tǒng)的影響較大，一般不會采用；異步復制，通過后續(xù)機制，確保將本地改動的數(shù)據(jù)復制的異地，對系統(tǒng)的影響較小，但數(shù)據(jù)同步有延遲，是目前實現(xiàn)遠程數(shù)據(jù)同步的主要方法。根據(jù)實現(xiàn)機制，數(shù)據(jù)復制分為軟件方式和硬件方式；硬件方式往往又被稱為遠程鏡像。軟件復制有SymantecVolumeReplicator；硬件復制有EMCSRDF、HDSTrueCopy等。軟件復制〔卷復制〕SymantecVolumeReplicator(簡稱VVR)負責遠程數(shù)據(jù)復制。VVR復制基于Volume進行。復制的數(shù)據(jù)可以是數(shù)據(jù)庫中的數(shù)據(jù)〔文件方式或裸設備方式〕，數(shù)據(jù)庫日志，復制的數(shù)據(jù)也可以是各種文件，如應用和數(shù)據(jù)庫配置文件，應用程序，庫文件，等等。復制的示意圖見圖四。VVR與VxVM完全集成在一起。用VxVM管理界面和命令統(tǒng)一配置管理；由于VVR僅僅將Volume上每次I/O的實際數(shù)據(jù)實時復制到遠程節(jié)點，所以在網(wǎng)絡線路上傳輸?shù)臄?shù)據(jù)量很少，對帶寬的需求也很小，因此也與應用無關(guān)，只要是在定義的復制卷上的仍和操作，都會被復制到異地。硬件復制以EMC的SRDF為例，如以下圖：1．系統(tǒng)定期檢測磁盤物理數(shù)據(jù)塊的改變狀況。如果發(fā)現(xiàn)有數(shù)據(jù)塊改動，將會被系統(tǒng)記錄，并一次性將改動過的數(shù)據(jù)塊考到復制緩存，這一動作被稱為Switch?？截惖骄彺嬷械臄?shù)據(jù)塊，在下一個Switch來臨之前，被復制到異地相應的陣列緩存中。在下一個Switch時，本地數(shù)據(jù)塊被復制到本地存中，而異地緩存中上一次被改動過的數(shù)據(jù)塊才被復制到容災系統(tǒng)中。根據(jù)實應用范圍，數(shù)據(jù)復制分為應用復制、數(shù)據(jù)庫復制、卷復制、控制器復制。應用復制，是指通過應用系統(tǒng)直接向原生產(chǎn)中心和容災中心同時發(fā)交易，生產(chǎn)中心和容災中心都處理成功，該筆交易才算成功；只要有一邊應用處理失敗，該筆交易就算失敗。由于交易的延遲性較大、健壯性較差，應用復制一般不會考慮。應用應用數(shù)據(jù)庫操作系統(tǒng)控制器物理磁盤數(shù)據(jù)塊SITEA應用數(shù)據(jù)庫操作系統(tǒng)控制器物理磁盤SITEBIOLogSQL/Log交易數(shù)據(jù)庫復制數(shù)據(jù)庫復制，如Oracle的DataGuard、QuestSharePlex、DSGRealSync等，通過分析數(shù)據(jù)庫RedoLog和ArchiveLog實現(xiàn)日志的復制，將分析結(jié)果直接或轉(zhuǎn)化為SQL語句傳到容災中心，在容災中通過心Aply數(shù)據(jù)庫日志或?qū)⑷罩巨D(zhuǎn)化的SQL語句重做，來保證數(shù)據(jù)庫數(shù)據(jù)的一致性。數(shù)據(jù)庫復制實際上是應用復制的數(shù)據(jù)庫實現(xiàn)，復制方式通過異步完成。卷復制如上SymantecVolumeReplicator?？刂破鲝椭疲缟螮MC的復制過程。IBMSVC實際上還有一種新的復制方式，稱為基于SAN網(wǎng)絡的卷復制，如IBM的SVC。它是通過特殊的設備SAN控制器，建立基于SAN控制器的卷，通過這種與主機應用無關(guān)，但與SAN控制器直接相關(guān)的卷實現(xiàn)復制。由于技術(shù)較新，且只有IBM一家推出，未得到其他硬件廠商支持，非主流技術(shù)，以下不再闡述。應用系統(tǒng)恢復正如前所述，數(shù)據(jù)復制是容災的手段，不是目的，容災的目的是數(shù)據(jù)的訪問。因此應用的恢復和以下的網(wǎng)絡的恢復也是容災的關(guān)鍵。應用系統(tǒng)恢復，這和系統(tǒng)的應用模式直接相關(guān)。需要考慮應用系統(tǒng)的應用架構(gòu)。是Client/Server架構(gòu)，還是Broswer/Server架構(gòu)；是2層架構(gòu)、還是3層架構(gòu)、還是多層架構(gòu)。兩層架構(gòu)，表示容災中心的應用只要啟動數(shù)據(jù)庫就可以效勞了。如果是三層架構(gòu)，就意味著應用系統(tǒng)除數(shù)據(jù)庫以外，還有網(wǎng)絡效勞程序，如中間件Tuxedo、CICS、WebLogic、WebSphere、9iAS、SAP等等。在容災應用切換時，能夠手工或自動化的將這些效勞一一啟動。網(wǎng)絡系統(tǒng)恢復在災難發(fā)生后，應用切換到災備中心了，本地的應用前端需要重新訪問容災節(jié)點的效勞，帶來另外一個問題，網(wǎng)絡如何切換？是建立新的網(wǎng)絡，還是使用動態(tài)路由，還是有其它方法？實際上最簡單的方法，就是通過外部DNS效勞器，改變效勞器名和IP的映射關(guān)系，將原效勞器名映射到新的IP地址上，就可以利用容災網(wǎng)絡，實現(xiàn)前端對容災中心效勞器數(shù)據(jù)的訪問。容災切換過程就是在災難發(fā)生后，數(shù)據(jù)庫切換、應用重新啟動、網(wǎng)絡實現(xiàn)切換等等,容災中心接管原生產(chǎn)中心的整個過程；同時還包含了在原數(shù)據(jù)中心修復后，數(shù)據(jù)庫、應用、網(wǎng)絡需要重新切會來的整個過程。這些過程，可以通過手工切換、也可以通過自動化過程完成。消防演習大局部的容災方案，在工程實施后，很難有時機來實現(xiàn)預演，因為對于大局部方案來說，這種預演活動，需要消耗大量的人力財力。但是消防預演是必不可少的，它是實時測試目前的容災方案的漏洞，保證容災方案在災難發(fā)生時，能夠真正生效。

主流容災技術(shù)分析與比照沒有一種技術(shù)可以解決所有得IT問題，因此，也沒有一個解決方案是完美無缺得，依據(jù)現(xiàn)狀、技術(shù)要求、和未來的拓展，我們在此討論的是最適宜容災技術(shù)的解決方案。數(shù)據(jù)備份SHARE78評審標準中，Tier0、Tier1、Tier2級別容災要解決的問題。如前面所闡述的，數(shù)據(jù)備份是容災系統(tǒng)的起點，是最低端的容災方案。不是說有了高端的實時容災方案，就可以不要備份系統(tǒng)了，因為實時容災不能解決惡性操作、誤操作等故障，而備份系統(tǒng)可以解決。在此我們要討論的是，如何利用現(xiàn)有的備份系統(tǒng)，是容災方案更加完備。正如Veritas的備份軟件NetBackup,對目前所有的操作系統(tǒng)AIX、Solaris、HP－Unix、Windows、數(shù)據(jù)庫Oracle、SQLServer、DB2、SybaseASE等，VeritasNetBackup除了可以很好的備份相關(guān)的文件系統(tǒng)數(shù)據(jù)、數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)外，同時通過BMR(BareMetalRestore:裸金屬恢復)模塊，可以對AIX、Solaris、HP－Unix、Windows、Linux操作系統(tǒng)實現(xiàn)備份，備份這些操作系統(tǒng)的相關(guān)補丁、外設驅(qū)動程序、相關(guān)的文件系統(tǒng)配置信息、相關(guān)的卷配置信息、內(nèi)核參數(shù)等。在災難修復時，可以通過恢復的方式快速恢復相關(guān)操作系統(tǒng)。實際經(jīng)驗，操作系統(tǒng)安裝、打補丁，安裝相關(guān)驅(qū)動程序、恢復內(nèi)核參數(shù)、恢復文件系統(tǒng)配置、恢復卷管理系統(tǒng)配置等整個過程，可以縮短在1小時內(nèi)完成，并且降低了人為錯誤操作過程。這樣大大提高了原生產(chǎn)中心容災恢復的能力。而其他備份產(chǎn)品，或沒有類似與BMR的模塊；或是不能支持AIX、Solaris、HP－Unix、Windows、Linux全部操作系統(tǒng)，也就是說，不能實現(xiàn)統(tǒng)一的容災應對策略，反而會增加容災的復雜度。VeritasNetBackup還有另外一個叫Vault的模塊，可以實現(xiàn)對備份數(shù)據(jù)的自動拷貝，并實現(xiàn)異地存放和管理。－Share78中Tier1、Tier2級別容災。VeritasNetBackup還能構(gòu)實現(xiàn)快照備份，就是備份時對原盤做磁盤級快照。VeritasNetBackup可以和VeritasVolumeSnapshot、EMCTimeFinder等業(yè)界主流的快照工具做整合，實現(xiàn)Server-Free(OFF-Host)的備份，既備份時，原應用效勞器不參與的備份，大大提供了備份系統(tǒng)的能力。VeritasNetBackup針對AIX、Solaris、HP－Unix、Windows、Linux的備份，無論選擇何種平臺作為主控效勞器、無論如何調(diào)整，都是通過同一JavaGUI和WebGUI實現(xiàn)管理，簡單易用，用戶容易掌握。實時數(shù)據(jù)保護SHARE78評審標準中，Tier3級別容災。數(shù)據(jù)鏡像〔Mirroring〕數(shù)據(jù)鏡像分軟件鏡像與硬件鏡像。硬件鏡像通過硬件級別的Raid-1實現(xiàn)，其實現(xiàn)過程簡單，但要求嚴格。只能基于同一廠商、同一陣列、同樣容量大小的兩塊磁盤來實現(xiàn)。軟件鏡像VeritasVolumeManager實現(xiàn)邏輯卷級鏡像，對存儲空間要求較低，只要有空間且至少兩塊磁盤就行。不要求同一廠商、同一陣列、同樣容量大小的兩塊磁盤，VeritasVolumeManager能夠?qū)崿F(xiàn)跨廠商、跨陣列的鏡像，在磁盤空間不均時，能夠?qū)崿F(xiàn)1塊磁盤對多塊磁盤、N塊磁盤對M塊磁盤的鏡像。鏡像技術(shù)在容災中的利用在通過SAN的支持，DWDM的拓展，光纖網(wǎng)絡可以擴展到100公里或更遠，鏡像可以在較遠的兩個數(shù)據(jù)中心的磁盤上建立。但由于鏡像系統(tǒng)是以同步方式實現(xiàn)的，受到距離、光纖協(xié)議、和相關(guān)協(xié)議轉(zhuǎn)換的影響，同步方式會影響本地效勞器的性能，所以，一般建議在<20公里的同城容災中使用，在遠程容災中可作為一種加強方案與遠程容災方案整合，將在我們的詳細方案中描述。常說的遠程磁盤鏡像，實際上是遠程磁盤復制，不是真正意義上的鏡像。我們將在后續(xù)文章描述?；赟AN的鏡像，在容災實現(xiàn)中，使用范圍較小，如上說述，適用于同城容災，但支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設備、應用配置文件、應用程序、庫函數(shù)等，因而支持各類應用系統(tǒng)容災，包括數(shù)據(jù)庫、中間件、客戶自己開發(fā)的應用，適用于2層架構(gòu)、3層或多層應用架構(gòu)。數(shù)據(jù)復制〔Replication〕數(shù)據(jù)復制是運程容災實現(xiàn)的根底。軟件復制〔卷復制〕VERITASVolumeReplicator(簡稱VVR)負責遠程數(shù)據(jù)復制。VVR復制基于Volume進行，將數(shù)據(jù)特別是需要進行遠程復制的相關(guān)文件系統(tǒng)、數(shù)據(jù)庫、裸設備、應用程序等，存放在復制卷組中，系統(tǒng)便能自動同步本地和異地相應的復制卷組。復制的示意圖見圖四。VVR與VxVM完全集成在一起。用VxVM管理GUI界面和命令統(tǒng)一配置管理；由于VVR僅僅將Volume上每次I/O的操作復制到遠程節(jié)點，復制的信息是卷的日志，所以在網(wǎng)絡線路上傳輸?shù)臄?shù)據(jù)量很少，對帶寬的需求也較小。；StorageReplicatorLog(簡稱SRL)是VVR中的重要部件。需要復制的I/O操作，首先要寫入SRL，然后傳到異地。VVR通過SRL保證數(shù)據(jù)復制嚴格按照寫順序進行，這在異步工作方式下非常重要。當網(wǎng)絡中斷或異地系統(tǒng)出現(xiàn)故障時，本地數(shù)據(jù)將記錄在SRL中，當SRL滿后，VVR將使用DCM(DataChangeMap)記錄變化的數(shù)據(jù)塊的塊號，等系統(tǒng)恢復正常時再將SRL中的數(shù)據(jù)按照先進先出的順序傳送到異地，最后再將DCM中記錄的塊傳送到異地。VVR數(shù)據(jù)流程見圖五：圖五數(shù)據(jù)復制的工作模式缺省為同步/異步自適應，即在網(wǎng)絡延時情況較好、數(shù)據(jù)能夠及時復制時，工作在同步方式，完全保證兩邊數(shù)據(jù)的一致性；當網(wǎng)絡延時情況較差、數(shù)據(jù)不能及時復制時，工作在異步方式下，保證主節(jié)點的I/O性能。數(shù)據(jù)復制根據(jù)實際情況，自行在兩種工作模式之間切換。并且基于卷的日志〔SRL：先進先出〕保正了再極端情況下，如容災網(wǎng)絡中斷、數(shù)據(jù)復制不能正常進行，容災中心數(shù)據(jù)于生產(chǎn)中心數(shù)據(jù)有延遲，在一切故障排除后，能夠嚴格保證所以I/O的寫順序，這類似于數(shù)據(jù)庫數(shù)據(jù)塊和數(shù)據(jù)庫日志的關(guān)系，通過帶時間戳的數(shù)據(jù)塊和順序日志，保證數(shù)據(jù)的一致性?；谲浖倪h程復制，在容災實現(xiàn)中，使用范圍最廣，支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設備、應用配置文件、應用程序、庫函數(shù)等，支持各類應用系統(tǒng)容災，包括數(shù)據(jù)庫、中間件、客戶自己開發(fā)的應用，適用于2層架構(gòu)、3層或多層應用架構(gòu)。硬件復制通過所謂的遠程磁盤鏡像實現(xiàn)，其實現(xiàn)要求嚴格。只能基于同一廠商、同型號陣列、同樣容量大小的兩個陣列來實現(xiàn)。廠商一般建議使用間歇性復制。遠程磁盤鏡像〔復制〕，在容災實現(xiàn)中，支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設備、應用配置文件、應用程序、庫函數(shù)等，支持各類應用系統(tǒng)容災，包括數(shù)據(jù)庫、中間件、客戶自己開發(fā)的應用，適用于2層架構(gòu)、3層或多層應用架構(gòu)。與應用無關(guān)，但與磁盤陣列直接相關(guān)。只能基于同一廠商、同樣容量大小的兩個陣列來實現(xiàn)。受光纖線路影響、復制數(shù)據(jù)量大，在使用間歇性復制時，數(shù)據(jù)延遲大，磁盤容量要求4倍于源數(shù)據(jù)，并且在極端情況下，不能保證數(shù)據(jù)一致性。硬件復制的過程，在上文已經(jīng)描述。下面我們將描述極端情況。磁盤復制在生產(chǎn)中心和容災中心復制的是改動過的物理數(shù)據(jù)塊，而物理數(shù)據(jù)塊的寫是無序的。為了保證數(shù)據(jù)的一致性，通過帶時間戳的數(shù)據(jù)塊，改善了一定的數(shù)據(jù)塊的無序性，但仍然不能解決。我們看到，數(shù)據(jù)庫是通過帶時間戳的數(shù)據(jù)塊和聯(lián)機日志一起來解決，如果一個數(shù)據(jù)文件中的數(shù)據(jù)塊的時間戳不一致，數(shù)據(jù)庫需要日志來修正，日志中記錄的是一些有序的數(shù)據(jù)庫操作，通過Recover的動作，將不一致的數(shù)據(jù)文件，前滾或后滾到某一特定時間點。帶時間戳的數(shù)據(jù)文件和有序的日志，二者缺一不可，否那么不能保證數(shù)據(jù)的一致性。在磁盤復制中，唯獨少了至關(guān)重要的磁盤寫日志〔不可能有〕。更有甚，如果這種磁盤塊的無序?qū)懀l(fā)生在數(shù)據(jù)庫的聯(lián)機日志上，那將對數(shù)據(jù)庫數(shù)據(jù)的一致性造成破壞。數(shù)據(jù)庫復制數(shù)據(jù)庫復制，如Oracle的DataGuard、QuestSharePlex、DSGRealSync等，通過分析數(shù)據(jù)庫RedoLog和ArchiveLog實現(xiàn)日志的復制，將分析結(jié)果直接或轉(zhuǎn)化為SQL語句傳到容災中心，在容災中通過心Aply數(shù)據(jù)庫日志或?qū)⑷罩巨D(zhuǎn)化的SQL語句重做，來保證容災中心數(shù)據(jù)與生產(chǎn)中心數(shù)據(jù)一致。數(shù)據(jù)庫復制，在簡單的環(huán)境中，實現(xiàn)兩個較小的數(shù)據(jù)庫數(shù)據(jù)同步，可以說是一個簡化的解決方案。對于容災環(huán)境，我們認為大大不適宜，原因如下。數(shù)據(jù)庫復制，是專門針對相應數(shù)據(jù)庫的，只能實現(xiàn)單一的數(shù)據(jù)庫復制?，F(xiàn)有的數(shù)據(jù)庫就有Oracle,SQLServer，DB2，SybaseASE。在容災系統(tǒng)中，如果使用數(shù)據(jù)庫復制方式，管理員將要維護Oracle一套、SQLServer一套、DB2一套、等相互各不相同的數(shù)據(jù)庫復制技術(shù)，管理和維護工作根本不能保證其能夠正常運行。下面我們就以Oracle為例，雖然有眾多廠商、技術(shù)方案支持的數(shù)據(jù)庫復制，仍然有不可逾越的技術(shù)障礙。Oracle數(shù)據(jù)庫的容災復制被稱為StandbyDatabase,其產(chǎn)生于，在Oracle9i后，改稱為DataGuard。StandbyDatabase又分為PhysicalStandby，和LogicalStandby。PhysicalStandby方式是將生產(chǎn)中心產(chǎn)生的數(shù)據(jù)庫redolog和archivelog，不停復制到容災中心，不停的applylog，來實現(xiàn)容災中心的數(shù)據(jù)庫與生產(chǎn)中心一致。LogicalStandby，是通過解析redolog和archivelog，產(chǎn)生相關(guān)的SQL語句，把這些語句傳到容災中心重做。QuestSharePlex和DSG的Realsync類似與DataGuard的LogicalStandby，復制SQL語句。1．容災的目的是使數(shù)據(jù)能夠被正常訪問，業(yè)務能夠正常運行。數(shù)據(jù)庫復制技術(shù)，不是一個完整的容災解決方案，只能有限的復制數(shù)據(jù)庫數(shù)據(jù)，不能復制其他的應用程序，配置文件，就是Oracle自己的，initSID.ora,*.ctl也不能復制，一旦這些文件改動過，將需要管員人為操作或者需要其他軟件的管理，保證容災中心與生產(chǎn)中心同步應用、程序、配置文件同步。2．由于DataGuard是通過日志來實現(xiàn)的，這要求數(shù)據(jù)庫必須運行在歸檔日志模式下。但我們知道，并不是所有的數(shù)據(jù)庫操作都寫日志：oracle的DML〔DataManipulationLanguage〕或DDL〔DataDictionaryLanguage〕語句是不能被復制的，如createindex、table，altertable等等；觸發(fā)器、存儲過程操作不能被復制；系統(tǒng)升級、patchs更新不能被復制。3．與備份軟件的沖突。如前所述，對于核心應用系統(tǒng)，數(shù)據(jù)備份必不可少。對于數(shù)據(jù)庫的備份，也要求數(shù)據(jù)庫在歸檔模式下運行。備份系統(tǒng)在備份作用發(fā)起時，需要備份數(shù)據(jù)文件、controlfile、歸檔日志、甚至需要數(shù)據(jù)庫實現(xiàn)強制歸檔，來備份歸檔日志，備份作業(yè)成功后，由備份系統(tǒng)自動刪除備份過的歸檔日志，應為當數(shù)據(jù)庫運行在歸檔日志模式下時，歸檔日志往往因數(shù)據(jù)庫繁忙而快速大量產(chǎn)生，需要備份軟件自動去除維護，否那么當歸檔日志空間占滿后，聯(lián)機日志不能歸檔時，生產(chǎn)數(shù)據(jù)庫不在運作，那么所有應用業(yè)務不能操作，釀成生產(chǎn)事故。為了不影響生產(chǎn)環(huán)境，問題一，在備份作業(yè)發(fā)起，強制歸檔；備份完成后，刪除歸檔日志后，數(shù)據(jù)庫復制軟件，該如何操作，將嚴重造成生產(chǎn)中心和容災中心數(shù)據(jù)不一致。如果備份作用不刪除歸檔日志，系統(tǒng)管理員將不定時的來維護歸檔目錄，他必須知道本地歸檔目錄中，哪一個歸檔日志已經(jīng)被備份，通過檢查容災中心數(shù)據(jù)庫中哪一個歸檔日志已經(jīng)被apply，這將是一個惡夢一樣的維護工作。4．極限情況下的危害。當生產(chǎn)中心和容災中心的復制鏈路一定時期內(nèi)不能恢復時，同樣需要在生產(chǎn)主機中保存所有的歸檔日志，這又需要管理員大量的維護工作。數(shù)據(jù)庫雙活在DataGuard中PhysicalStandby模式下，數(shù)據(jù)庫可以通過read-only方式翻開。正如前面所述，PhysicalStandby通過apply數(shù)據(jù)日志，實現(xiàn)數(shù)據(jù)庫復制。但數(shù)據(jù)庫被以read-only方式翻開時，新的日志將不能被追加，必須將數(shù)據(jù)庫重新切換到recover模式下，才能繼續(xù)apply日志。也就是說數(shù)據(jù)庫是被間歇式翻開，影響數(shù)據(jù)庫日志的追加不說，試問，什么應用對數(shù)據(jù)庫的操作是間歇式，應用程序也要間歇式的啟動和停止。并且在read-only方式下，一切在數(shù)據(jù)庫中又修改、增加的操作，都會被以錯誤方式返回，什么應用不寫數(shù)據(jù)庫？DataGuard中LogicalStandby模式下〔QuestSharePlex、DSGRealsync類似〕數(shù)據(jù)庫可以被正常翻開和操作。這也是需要大量的系統(tǒng)維護工作作為保障的，如前面描述的日志的維護問題。是的，該功能有一定的應用場所，但也是需要高量的管理和維護來保證。因為在這種模式下，生產(chǎn)中心和容災中心實際上是兩個獨立的數(shù)據(jù)庫，兩個數(shù)據(jù)庫的數(shù)據(jù)有可能出現(xiàn)不一致的情況。因此，如何確定兩個數(shù)據(jù)庫的一致性，又將是一個技術(shù)難題，如果不一致，又將以誰為準？容災中心的數(shù)據(jù)庫數(shù)據(jù)是生產(chǎn)中心的備份，數(shù)據(jù)應完全一致，這是容災的宗旨，為此，我們花費了大量的人力、物力和財力，如果我們僅僅是想要翻開數(shù)據(jù)庫生成報表、實現(xiàn)數(shù)據(jù)挖掘、或是一些測試，有很多其他一些成熟的解決方案。卷快照采用VolumeManager的鏡像功能創(chuàng)立邏輯卷的某時間點拷貝。原數(shù)據(jù)(Primary)卷和卷快照都可以包含多個邏輯設備，如數(shù)據(jù)庫數(shù)據(jù)文件、redolog、archivelog目錄。對于Oracle數(shù)據(jù)庫，通過將數(shù)據(jù)庫置于backup模式以到達靜默；或者是使相關(guān)的表空間，置于backup模式以到達靜默。然后對整個instance或某個表空間實現(xiàn)快照。由于Oracle的容錯能力，很多情況下，應用不靜默而直接對數(shù)據(jù)庫的數(shù)據(jù)卷照相，再由Oraclelog機制恢復到一致性狀態(tài),從而可以創(chuàng)立一個與生產(chǎn)中心完全相同數(shù)據(jù)的數(shù)據(jù)庫實例，可以用于生成報表、實現(xiàn)數(shù)據(jù)挖掘、或是一些測試。瞬間快照(InstantSnapshot)瞬間快照有三種方式，instantfullsnapshot，instantspace-optimizedsnapshot和instantplex-breakoffsnapshot。與傳統(tǒng)快照方式相比，瞬間快照的特點有以下幾點：plex或者snapshot卷在進行snapshot前不需要鏡像同步，極大節(jié)省了創(chuàng)立snapshot的時間。snapshot瞬間可用。space-optimizedsnapshot〔即空間優(yōu)化snapshot〕只要使用很少的空間就可以創(chuàng)立snapshot。通過快照，可以快速激活數(shù)據(jù)庫，該數(shù)據(jù)庫與生產(chǎn)環(huán)境的數(shù)據(jù)庫在快照時間點保持完全一致性，該數(shù)據(jù)庫可以以讀寫方式下翻開，提供查詢、備份、報表、數(shù)據(jù)挖掘，應用測試等等功能。在下一個snapshot，該數(shù)據(jù)庫與生產(chǎn)環(huán)境的數(shù)據(jù)庫在快照時間點保持完全一致性。應用系統(tǒng)恢復對于核心的應用環(huán)境，在實現(xiàn)容災前，一般都要求在本地實現(xiàn)高可用性，通過集群軟件，保證應用、數(shù)據(jù)訪問在效勞器級故障，如網(wǎng)卡、IP、操作系統(tǒng)、磁盤、其他相關(guān)應用的故障時，能夠自動切換到另外一臺可用的效勞器上，能夠被用戶繼續(xù)訪問。容災應用切換，就是把這種高可用性的應用，拓展到廣域網(wǎng)上。也就是說通過HA軟件實現(xiàn)生產(chǎn)中心的高可用、實現(xiàn)容災中心應用的自動啟動、實現(xiàn)生產(chǎn)中心在災難修復后應用的回切過程。目前主流的高可用方案主要有SymantecVCS、IBMHACMP、HPMC/ServiceGuard、SunCluster、WindowsCCS等。各廠商軟件的名字上，我們就可以看到他們的缺乏。只能支持自己的平臺。也就是意味著如果使用他們的解決方案，得分別熟悉AIX、HP－Unix、Solaris、Windows，得在分別熟悉IBMHACMP、HPMC/ServiceGuard、SunCluster、WindowsCCS軟件，并且這些軟件大局部只提供命令行管理、調(diào)試方式，這在管理上又是一大難題。SymantecVCS通過統(tǒng)一得圖形化JAVAGUI或WebGUI，提供對AIX、HP－Unix、Solaris、Windows、Linux所有操作系統(tǒng)平臺、所有數(shù)據(jù)庫Oracle、OracleRAC、SQLServer、Sybase、DB2、所有中間件：Weblogic、WebSphere、9iAs、Tuxedo，甚至是用戶自己寫得應用程序，實現(xiàn)得集中統(tǒng)一的集群管理和監(jiān)控。并且能夠定義這些效勞啟動、切換得先后順序，以確保數(shù)據(jù)能夠快速正常訪問。例如在WebLogicServer啟動之前，必須先啟動Oracle,因為在WebLogicServer啟動是會建立數(shù)據(jù)庫得連接池，如果數(shù)據(jù)庫未啟動，WebLogicServer啟動將失敗。在災難發(fā)生時，VCS將根據(jù)這些效勞組之間得關(guān)系，先后依次啟動各個效勞組。大大提供容災中心效勞得接管速度。網(wǎng)絡系統(tǒng)恢復在災難發(fā)生后，本地應用訪問路徑如何由指向原生產(chǎn)中心改為指向容災中心。在災難修復后，又需要指向原生產(chǎn)中心。我們提到，最簡單得方法就是更改外部DNS效勞器得IP映射關(guān)系。在災難發(fā)生前，IP映射為生產(chǎn)中心效勞器；在災難發(fā)生后，IP由映射為容災中心得效勞器；在災難修復后，IP又映射為生產(chǎn)中心得效勞器。當然，在一些中間件軟件中，支持多效勞器、多IP得配置，那也是可以考慮的。而通過SymantecGlobalClusterOption能夠?qū)崿F(xiàn)對外部DNS效勞器IP映射的自動改動。容災切換過程就是在災難發(fā)生后，數(shù)據(jù)庫切換、應用重新啟動、網(wǎng)絡實現(xiàn)切換等等,容災中心接管原生產(chǎn)中心的整個過程；同時還包含了在原數(shù)據(jù)中心修復后，數(shù)據(jù)庫、應用、網(wǎng)絡需要重新切會來的整個過程。這些過程，可以通過手工命令行、腳本方式切換、也可以通過SymantecGlobalClusterOption自動化完成，或是通過SymantecGlobalClusterOptionGUI，以點擊一次鼠標完成。消防演習通過SymantecGlobalClusterOption和VCS的聯(lián)合操作來實現(xiàn)。實現(xiàn)的過程是在原生產(chǎn)中心建立一個或一組測試效勞組，改效勞組，依賴于原有系統(tǒng)，可以有數(shù)據(jù)庫效勞、應用效勞，通過GCO和VCS來控制該效勞在生產(chǎn)中心和容災中心的自由切換，并測試其可訪問的能力，從而檢驗整個容災方案的可靠性。Symantec容災方案主要技術(shù)介紹SymantecNetBackup數(shù)據(jù)備份技術(shù)無限可伸縮性集中式管理與控制、高性能技術(shù)以及靈活的多層體系架構(gòu)，使NetBackupEnterprise能夠適應現(xiàn)代數(shù)據(jù)中心與日俱增的需求。平臺獨立性保護幾乎所有的主流平臺,其中包括所有主要UNIX派生平臺,WindowsNT/XP/2000、NetWare、Macintosh、Linux以及其它許多平臺，為UNIX、Linux或Windows效勞器的備份設備提供主機托管，以實現(xiàn)最正確性能。無論是哪種平臺，都能實現(xiàn)相同的性能和功能?；诓呗缘募惺焦芾碇醒肟刂婆_通過一個直觀界面，提供單一管理點，允許備份管理員以更有效的方式，管理大量的效勞器。能夠跨越許多效勞器，為數(shù)以千記的用戶實現(xiàn)企業(yè)備份操作自動化，同時加強所有存儲設備的管理力度。無與倫比的性能采用多路傳輸方式，把多達32個不同數(shù)據(jù)流發(fā)送至單一磁帶驅(qū)動器，為客戶硬件實現(xiàn)最大化額定吞吐量。還利用并行機制，向許多磁帶設備發(fā)送許多數(shù)據(jù)流，或通過單一備份作業(yè)，自動生成許多數(shù)據(jù)流。透明的不間斷備份數(shù)據(jù)庫識別代理技術(shù)為關(guān)鍵任務數(shù)據(jù)庫，提供平安可靠的保護，而且不影響應用可用性。高度有效的設計大大提升了CPU在備份操作期間的使用率。由于和基于硬件的分鏡像及快照技術(shù)或SymantecNetBackupFlashbackup?相集成，能夠提供完全透明的備份操作。支持最新存儲硬件NetBackupEnterprise支持領先供給商廣泛系列的磁帶庫、磁帶驅(qū)動器和存儲區(qū)域網(wǎng)〔SAN〕互連技術(shù)。通過SCSI或SAN，以動態(tài)方式共享各種磁帶驅(qū)動器，或使用可選NetBackupNDMP協(xié)議，保護流行連網(wǎng)存儲器〔NAS〕系統(tǒng)或大型存儲設備。NetBackupEnterprise使用網(wǎng)絡數(shù)據(jù)管理協(xié)議〔NDMP〕，為支持NDMP的NAS系統(tǒng)啟動和控制備份與恢復活動?？缮炜s三/四層體系架構(gòu)現(xiàn)有數(shù)百種產(chǎn)品可以為開放系統(tǒng)環(huán)境執(zhí)行備份與恢復，但為處理現(xiàn)代數(shù)據(jù)中心的大量數(shù)據(jù)而專門設計的卻少之又少。NetBackupEnterprise擁有一個核心三層體系架構(gòu)。它整合了尖端介質(zhì)管理功能和高性能，能夠適應最大規(guī)模數(shù)據(jù)中心的需求。NetBackupEnterprise?的三層體系結(jié)構(gòu)包含三類主要的組件，即MasterServer〔主效勞器〕，MediaServers〔介質(zhì)效勞器〕，Clients〔客戶端〕。典型的NetBackupEnterprise的備份管理系統(tǒng)是由一個MasterServer，一個或多個MediaServers，以及多個Clients組成；這樣的一個備份管理系統(tǒng)就構(gòu)成一個NetBackup的存儲藏份域〔NetBackupStorageDomain〕。比擬大