SYMANTEC容災項目方案設(shè)計

1、 容災工程方案設(shè)計賽門鐵克軟件北京廣州分公司目 錄第第 1 1 章章容災技術(shù)標準容災技術(shù)標準 .6 6容災的總體規(guī)劃.6技術(shù)指標 RPO、RTO .6國際標準 SHARE 78 .7Tier 0 .8Tier 1 .9Tier 2 .9Tier 3 .10Tier 4 .10Tier 5 .10Tier 6 .11界定災備系統(tǒng)的適用范圍 .11界定災備建設(shè)的目標 .12界定災備系統(tǒng)的總體架構(gòu) .12第第 2 2 章章主流容災技術(shù)說明主流容災技術(shù)說明 .1414數(shù)據(jù)備份.14實時數(shù)據(jù)保護.14數(shù)據(jù)鏡像Mirroring .15數(shù)據(jù)復制Replication .15軟件復制卷復制.15硬件復制.1

2、6數(shù)據(jù)庫復制.19IBM SVC .20應用系統(tǒng)恢復.20網(wǎng)絡(luò)系統(tǒng)恢復.20容災切換過程.21消防演習.21第第 3 3 章章主流容災技術(shù)分析與比照主流容災技術(shù)分析與比照 .2222數(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瞬間快照(Instant Snapshot) .30應用系統(tǒng)恢復.31網(wǎng)絡(luò)系統(tǒng)恢復.32容災切換過程.33消防演習.33第第 4 4 章章SYMANTECSYMANTEC 容災方案主要技術(shù)介紹

3、容災方案主要技術(shù)介紹 .3333SYMANTEC NETBACKUP數(shù)據(jù)備份技術(shù) .34無限可伸縮性 .34平臺獨立性 .34基于策略的集中式管理 .34無與倫比的性能 .34透明的不間斷備份 .34支持最新存儲硬件 .34可伸縮三/四層體系架構(gòu) .35NetBackup Master Server .36NetBackup Media Server .36NetBackup Client .36全球管理與實時報告：NOM.36先進報表：NetBackup Advanced Reporter.37數(shù)據(jù)庫在線備份：Database Agent.38數(shù)據(jù)庫歸檔：NetBackup Database

4、 Archiver.38塊級增量備份：Block-Level Incremental Backup.39系統(tǒng)災難恢復：Bare Metal Restore.39高速閃備份：NetBackup FlashBackup.41翻開文件備份：Open Transaction Manager.42磁帶庫動態(tài)共享：Shared Storage Option.42無主機備份：NetBackup ServerFree Agent.43磁帶容災和管理：NetBackup Vault.43網(wǎng)絡(luò)存儲藏份：NetBackup for NDMP.44備份數(shù)據(jù)加密：Client Encryption Option.45磁

5、帶庫驅(qū)動：Tape Library Support.45其它功能.45SYMANTEC STORAGE FOUNDATION.46Symantec Volume Manager.47更高的系統(tǒng)與應用性能.47數(shù)據(jù)完整性提高，停機時間縮短.47硬件與軟件投資保護.47Symantec File System.48用戶與管理員工作效率提高.48可靠的系統(tǒng)數(shù)據(jù)帶來可靠的業(yè)務解決方案.48簡單而強大的系統(tǒng)管理功能.48Symantec Storage Foundation 解決方案說明 .48性能、可用性與平安性.49可擴展性.50集中式管理.51異類環(huán)境支持.52優(yōu)異的集成性能.52邏輯卷快照 .5

6、3snapshot 快速重鏡像(FastResync) .53動態(tài)拆分和重組Dynamic split and Join .54邏輯卷快照技術(shù)的特點 .54Snapshot 如何工作.54瞬間快照(Instant Snapshot) .56領(lǐng)先的企業(yè)級高可用性應用軟件解決方案.56Symantec Cluster Server 特征 .57領(lǐng)先的異構(gòu)平臺 HA 解決方案 .57可伸縮性 .58可定制 .58補充保護 .58災難恢復解決方案的重要組成成分 .58Symantec Cluster Server 特性優(yōu)勢 .59全面的高可用性特性.59最廣泛的應用支持.59異構(gòu)平臺和存儲器支持.59

7、行業(yè)最具伸縮性的解決方案.60多種存儲支持.60用于集群管理，基于 JAVA 的直覺圖形用戶界面GUI.60通用原子播送機GAB.60自動集群傳播.61集群的集群.61Global Cluster Option 的特點 .61Global Cluster Option 運作過程 .62第第 5 5 章章系統(tǒng)詳細設(shè)計方案系統(tǒng)詳細設(shè)計方案 .6464第一步，深化數(shù)據(jù)備份系統(tǒng).64第二步，存儲、應用整合.65存儲整合 .65應用整合 .65第三步，實現(xiàn)遠程實時數(shù)據(jù)卷保護.66第四步，建立遠程切換消防演習機制.66第五步，建立遠程切換機制.67ORACLE 數(shù)據(jù)庫切換詳解.67第第 6 6 章章數(shù)據(jù)容

8、災的性能分析數(shù)據(jù)容災的性能分析 .6969同步數(shù)據(jù)容災的性能分析.69帶寬 .69距離 .69中間鏈路設(shè)備和協(xié)議轉(zhuǎn)換的時延 .70異步數(shù)據(jù)容災的性能分析.72有關(guān)半同步.77容災技術(shù)對照.78第第 7 7 章章系統(tǒng)預算系統(tǒng)預算 .7979第第 8 8 章章主要技術(shù)的應用實例主要技術(shù)的應用實例 .8080中國聯(lián)通.80ICON CLINICAL.80BLUESTAR.81第第 9 9 章章應急預案的編制應急預案的編制 .8282SYMANTEC技術(shù)力量.82SYMANTEC工程組成員名單.83第第 1010 章章定期災難性恢復測試方案及檢驗定期災難性恢復測試方案及檢驗.8484第第 1111 章

9、章售后效勞方式、方法售后效勞方式、方法.8484SYMANTEC中國技術(shù)支持效勞中心 .84技術(shù)支持效勞介紹.84提供支持的流程：.85SYMANTEC公司向用戶提供如下支持效勞： .85第第 1 1 章章 容災技術(shù)容災技術(shù)標準標準作為風險防范系統(tǒng)，災備系統(tǒng)建設(shè)本身在總體規(guī)劃、方案選擇和投產(chǎn)實施后的管理運行，以及真正面對災難時的切換操作等方面也存在著潛在的風險。 計算機信息系統(tǒng)實現(xiàn)數(shù)據(jù)大集、應用大集中后，系統(tǒng)的運行平安成為風險控制的焦點。目前，已經(jīng)有多系統(tǒng)開始或準備進行災備系統(tǒng)的建設(shè)，災備系統(tǒng)建設(shè)的目標是減災容災，使計算機信息系統(tǒng)和數(shù)據(jù)能夠最大限度地防范和化解各種意外和災害所帶來的風險。然而，

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

11、有等級觀念的，級別不同，災備系統(tǒng)所采用的技術(shù)和到達的功能是不同的，在系統(tǒng)建設(shè)資金投入方面的差距也很巨大。所以，對用戶來說，明確災備系統(tǒng)建設(shè)的總體規(guī)劃十分必要。1.1.1 1.1.1 技術(shù)指標技術(shù)指標 RPORPO、RTORTO衡量容災技術(shù)的兩個技術(shù)指標 RPO、RTORPO(Recovery Point Objective): 以數(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 根本為異步傳輸

12、數(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(Recovery Time Objective):以應用為出發(fā)點，即應用的恢復時間目標，主要指的是所能容忍的應用停止效勞的最長時間，也就是從災難發(fā)生到業(yè)務系統(tǒng)恢復效勞功能所需要的最短時間周期。是反映業(yè)務恢復及時性的指標，表示業(yè)務從中斷到恢復正常所需的時間。RTO 值越小，代表容災系統(tǒng)的數(shù)據(jù)恢復能力越強。各種容災解決方案的 RTO 有較大差異，基于光通道技

13、術(shù)的同步數(shù)據(jù)復制，配合異地備用的業(yè)務系統(tǒng)和跨業(yè)務中心與備份中心的高可用管理，這種容災解決方案具有最小的RTO。容災系統(tǒng)為獲得最小的 RTO，需要投入大量資金。不同容災方案的 RTO 和 RPO 是不相同的。1.1.2 1.1.2 國際標準國際標準 SHARESHARE 7878要建設(shè)容災系統(tǒng)，就必須提出相應 的設(shè)計指標，以此作為衡量和選擇容災解決方案的參數(shù)。目前，國際上通用的容災系統(tǒng)的評審標準為 SHARE 78，主要包括以下內(nèi)容。備份/恢復的范圍災難恢復方案的狀態(tài)業(yè)務中心與容災中心之間的距離業(yè)務中心與容災中心之間如何連接數(shù)據(jù)是怎樣在兩個中心之間傳送的允許有多少數(shù)據(jù)喪失保證更新的數(shù)據(jù)在容災中心

14、被更新容災中心可以開始容災進程的能力SHARE 78 是建立容災系統(tǒng)的一種評審標準。建立容災系統(tǒng)的最終目的，是為了在災難發(fā)生后能夠以最快速度恢復數(shù)據(jù)效勞，主要表達在 RTO Objective)和 RPO 上。SHARE 78, M028 報告中定義的災備的七個級別和與其對應的數(shù)據(jù)喪失量與恢復時間情況詳見下表： 災難備份等級與業(yè)務恢復情況對照表等級描述PRORTO企業(yè)百分比0 級無災備方案-48 小時0.1%2 級車輛運送熱備份2448 小時24 小時90%3 級電子傳送24 小時24 小時6%4 級活動狀態(tài)備份中心秒級24 小時0.5%5 級兩中心、兩階段確認秒級2 小時0.1%6 級零數(shù)據(jù)

15、喪失零喪失2 小時3%1.1.2.1Tier 0 Tier 0 - 無異地數(shù)據(jù)備份(No off-site Data)Tier 0 被定義為沒有信息存儲的需求，沒有建立備份硬件平臺的需求，也沒有開展應急方案的需求，數(shù)據(jù)僅在本地進行備份恢復， 沒有數(shù)據(jù)送往異地。這種方式是最為低本錢的災難備份解決方案，但事實上這種災難備份并沒有真正災難備份的能力，因為它的數(shù)據(jù)并沒有被送往遠離本地的地方，而數(shù)據(jù)的恢復也僅是利用本地的記錄。 1.1.2.2Tier 1Tier 1- PTAM 車輛轉(zhuǎn)送方式( Pickup Truck Access Method)作為 Tier 1 的災難備份方案需要設(shè)計一個應急方案，

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

17、要一定的時間，同時依賴于什么時候硬件平臺能夠被提供準備好。1.1.2.3Tier 2Tier 2 - PTAM 卡車轉(zhuǎn)送方式+熱備份中心 (PTAM+Hot Site)Tier 2 相當于是 Tier 1 再加上具有熱備份能力中心的災難備份。熱備份中心擁有足夠的硬件和網(wǎng)絡(luò)設(shè)備去支持關(guān)鍵應用的安裝需求。對于十分關(guān)鍵的應用，在災難發(fā)生的同時，必須在異地有正運行著的硬件平臺提供支持。這種災難備份的方式依賴于用 PTAM 的方法去將日常數(shù)據(jù)放在異地存儲，當災難發(fā)生的時候，數(shù)據(jù)再被移動到一個熱備份的中心。雖然移動數(shù)據(jù)到一個熱備份中心增加了本錢，但卻明顯降低了災難備份的時間。1.1.2.4Tier 3Ti

18、er 3 - 電子傳送(Electronic Vaulting)Tier 3 是在 Tier 2 的根底上用電子鏈路取代了車輛進行數(shù)據(jù)傳送的災難備份。接收方的硬件平臺必須與生產(chǎn)中心物理地相別離，在災難發(fā)生后，存儲的數(shù)據(jù)用于災難備份。由于熱備份中心要保持持續(xù)運行，因此增加了本錢。但確實是消除了運送工具的需要，提高了災難備份的速度。1.1.2.5Tier 4Tier 4 - 活動狀態(tài)的備份中心 (Active Secondary Site)Tier 4 這種災難備份要求兩個中心同時處于活動狀態(tài)并管理彼此的備份數(shù)據(jù)，允許備份行動在任何一個方向發(fā)生。接收方硬件平臺必須保證與另一方平臺物理地相別離，在這

19、種情況下，工作負載可以在兩個中心之間被分擔，兩個中心之間之間彼此備份。在兩個中心之間，彼此的在線關(guān)鍵數(shù)據(jù)的拷貝不停地相互傳送著。在災難發(fā)生時，需要的關(guān)鍵數(shù)據(jù)通過網(wǎng)絡(luò)可迅速恢復，通過網(wǎng)絡(luò)的切換，關(guān)鍵應用的恢復時間也可降低到了小時級。1.1.2.6Tier 5Tier 5 - 兩中心兩階段確認 (Two-Site Two-Phase Commit)Tier 5 是在 Tier 4 的根底上在鏡像狀態(tài)上管理著被選擇的數(shù)據(jù) (根據(jù)單一commit 范圍，在本地和遠程數(shù)據(jù)庫中同時更新著數(shù)據(jù))，也就是說，在更新請求被認為是滿意之前，Tier 5 需要生產(chǎn)中心與備份中心的數(shù)據(jù)都被更新。我們可以想象這樣一種情

20、景，數(shù)據(jù)在兩個中心之間相互映像，由遠程 two-phase commit 來同步，因為關(guān)鍵應用使用了雙重在線存儲，所以在災難發(fā)生時，僅僅傳送中的數(shù)據(jù)被喪失，恢復的時間被降低到了小時級。1.1.2.7Tier 6Tier 6 - 零數(shù)據(jù)喪失 (Zero Data Loss)Tier 6 可以實現(xiàn)零數(shù)據(jù)喪失率，同時保證數(shù)據(jù)立即自動地被傳輸?shù)絺浞葜行?。Tier 6 被認為是災難備份的最高的級別，在本地和遠程的所有數(shù)據(jù)被更新的同時，利用了雙重在線存儲和完全的網(wǎng)絡(luò)切換能力。Tier 6 是災難備份中最昂貴的方式，也是速度最快的恢復方式，恢復的時間被降低到了分鐘級。對于 Tier 6 的災難備份解決方案，

21、可以應用兩種遠程拷貝技術(shù)來實現(xiàn)，即 PPRC 同步遠程拷貝和 XRC 異步遠程拷貝。 因此，企業(yè)需要根據(jù)其計算機處理系統(tǒng)中數(shù)據(jù)的重要性，以及需要恢復的速度和程度，來進行災備系統(tǒng)建設(shè)的整體考慮和不同災難對業(yè)務沖擊的分析，并最終確定災備系統(tǒng)建設(shè)的總體規(guī)劃。災備系統(tǒng)建設(shè)的總體規(guī)劃應包括以下幾個方面： 1.1.3 1.1.3 界定災備系統(tǒng)的適用范圍界定災備系統(tǒng)的適用范圍分析不同的應用系統(tǒng)，確定災備系統(tǒng)是一個覆蓋整個計算機系統(tǒng)的工程，根據(jù)業(yè)務的重要性，對不同的系統(tǒng)采用不同級別的容災方案，如針對關(guān)鍵的業(yè)務應用子系統(tǒng)，實施高級別的容災工程；對低級別的業(yè)務系統(tǒng)，實施低級別的容災工程。總之要建立一個綜合性的整體

22、災備建設(shè)工程。 1.1.4 1.1.4 界定災備建設(shè)的目標界定災備建設(shè)的目標 生產(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)絡(luò)切換等全部時間?？傮w規(guī)劃中應為災備系統(tǒng)設(shè)定明確的RPO 和 RTO 指標。 但是設(shè)計容災系統(tǒng)不能只看 RTO 和 RPO，對于不同的業(yè)務系統(tǒng)和用戶特殊的要求，其它一些指標有可能成為選擇容災解決方案的主

23、要因素。例如，某些地區(qū)為了防范一些特定自然災害的風險，要求容災備份中心與業(yè)務中心保持足夠的距離，在這種情況下，容災備份中心與業(yè)務中心的距離要求就是容災系統(tǒng)的重要指標。通信網(wǎng)絡(luò)是容災系統(tǒng)的組成局部，通信線路的質(zhì)量也是容災系統(tǒng)的性能指標之一，其中包括網(wǎng)絡(luò)的數(shù)據(jù)傳輸帶寬、網(wǎng)絡(luò)傳輸通道的冗余和網(wǎng)絡(luò)效勞商的效勞水平網(wǎng)絡(luò)年中斷率。如果容災系統(tǒng)使用的通信網(wǎng)絡(luò)是確定的，為了比擬不同容災解決方案，可以用單位存儲容量的數(shù)據(jù)庫在同一通信網(wǎng)絡(luò)上的數(shù)據(jù)完全恢復時間作為一項設(shè)計指標。大局部業(yè)務系統(tǒng)都是數(shù)據(jù)庫應用結(jié)構(gòu)，但業(yè)務系統(tǒng)容災并不等于是數(shù)據(jù)庫容災，還包括訪問數(shù)據(jù)庫的應用程序和相關(guān)配置信息。實現(xiàn)數(shù)據(jù)庫容災是容災的根底，

24、在保數(shù)據(jù)庫數(shù)據(jù)一致的前提下，還要實現(xiàn)應用程序和配置信息的一致性；實現(xiàn)應用系統(tǒng)的高可用性、應用程序在容災中心與生產(chǎn)中心接管和切回的過程，因此，還要考慮應用的模式是 C/S、B/S，兩層、三層、多層次的應用結(jié)構(gòu)等等。1.1.5 1.1.5 界定災備系統(tǒng)的總體架構(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)絡(luò)技術(shù)，

25、以及備份中心計算機系統(tǒng)的處理能力和網(wǎng)絡(luò)接管所需的具體架構(gòu)是否與生產(chǎn)中心采用完全同等數(shù)量、容量和性能的計算機、存儲設(shè)備和網(wǎng)絡(luò)體系結(jié)構(gòu)。 第第 2 2 章章 主流容災技術(shù)說明主流容災技術(shù)說明根據(jù) SHARE 78 評審標準，容災技術(shù)必需涵蓋了如下內(nèi)容：2.1 數(shù)據(jù)備份數(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)，不能被立刻訪問，必須通過相應操作,如恢復等方式

26、使用備份數(shù)據(jù)。這也解決了高端容災實時數(shù)據(jù)保護不能解決的問題：人為誤操作、惡意性操作等，這類操作，計算機系統(tǒng)是不能區(qū)分的，一旦執(zhí)行，將造成數(shù)據(jù)中心、災備中心同時修改；對于數(shù)據(jù)庫系統(tǒng)，在日志方式下，可以通過回滾方式修改，對于文件系統(tǒng)、操作系統(tǒng)等其他配置信息是不能回滾的，將造成消滅性的結(jié)果。因此在建設(shè)高端容災系統(tǒng)的前提，一定要做好本地系統(tǒng)的備份，這是容災技術(shù)的起點。目前成熟的備份軟件有 Symantec NetBackup、EMC Legato，IBM TSM，HP Protect Server 等等。2.2 實時數(shù)據(jù)保護實時數(shù)據(jù)保護 實時數(shù)據(jù)保護，就是在多塊磁盤上、多個陣列、多臺效勞器、多個數(shù)據(jù)中

27、心實時的保存同一份數(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ù)復制。2.2.1 2.2.1 數(shù)據(jù)鏡像數(shù)據(jù)鏡像MirroringMirroring數(shù)據(jù)鏡像Mirroring是冗余的一種類型，一個磁盤上的數(shù)據(jù)在另一個磁盤上存在一個完全相同的副本即為鏡像。分軟件鏡像與硬件鏡像，

28、它們的的區(qū)別就在于實現(xiàn)鏡像所需的 CPU 周期所處的位置。最終，都是根據(jù)程序的指令，為硬件磁盤，以及磁盤上存儲的數(shù)據(jù)制作一個鏡像副本。鏡像可以保證兩份數(shù)據(jù)完全一樣。鏡像軟件有 Symantec Volume Manager；各硬件廠商都有基于自己陣列的硬件鏡像方式。2.2.2 2.2.2 數(shù)據(jù)復制數(shù)據(jù)復制ReplicationReplication數(shù)據(jù)復制Replication是將一個原數(shù)據(jù)的及其改動，通過后續(xù)機制拷貝到另外一處，可以是另一個磁盤、另一個陣列、另一個效勞器、另一個數(shù)據(jù)中心。由于實現(xiàn)的機制不同，又分為同步復制和異步復制兩種方式。同步復制，能夠確保兩份數(shù)據(jù)完全一致，但對系統(tǒng)的影響較

29、大，一般不會采用；異步復制，通過后續(xù)機制，確保將本地改動的數(shù)據(jù)復制的異地，對系統(tǒng)的影響較小，但數(shù)據(jù)同步有延遲，是目前實現(xiàn)遠程數(shù)據(jù)同步的主要方法。根據(jù)實現(xiàn)機制，數(shù)據(jù)復制分為軟件方式和硬件方式；硬件方式往往又被稱為遠程鏡像。軟件復制有 Symantec Volume Replicator；硬件復制有 EMC SRDF、HDS TrueCopy 等。2.2.2.1軟軟件件復復制制 卷卷復復制制 Symantec Volume Replicator(簡稱 VVR)負責遠程數(shù)據(jù)復制。VVR 復制基于Volume 進行。復制的數(shù)據(jù)可以是數(shù)據(jù)庫中的數(shù)據(jù)文件方式或裸設(shè)備方式，數(shù)據(jù)庫日志，復制的數(shù)據(jù)也可以是各種

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

31、下一個 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ù)塊SITE A應用數(shù)據(jù)庫操作系統(tǒng)控制器物理磁盤SITE BIO LogSQL/Log交易2.2.2.3數(shù)數(shù)據(jù)據(jù)

32、庫庫復復制制數(shù)據(jù)庫復制，如 Oracle 的 Data Guard、Quest SharePlex、DSG RealSync 等，通過分析數(shù)據(jù)庫 Redo Log 和 Archive Log 實現(xiàn)日志的復制，將分析結(jié)果直接或轉(zhuǎn)化為 SQL 語句傳到容災中心，在容災中通過心 Aply 數(shù)據(jù)庫日志或?qū)⑷罩巨D(zhuǎn)化的 SQL語句重做，來保證數(shù)據(jù)庫數(shù)據(jù)的一致性。數(shù)據(jù)庫復制實際上是應用復制的數(shù)據(jù)庫實現(xiàn)，復制方式通過異步完成。卷復制如上 Symantec Volume Replicator。控制器復制，如上 EMC 的復制過程。2.2.2.4IBM SVC實際上還有一種新的復制方式，稱為基于 SAN 網(wǎng)絡(luò)的卷

33、復制，如 IBM 的 SVC。它是通過特殊的設(shè)備 SAN 控制器，建立基于 SAN 控制器的卷，通過這種與主機應用無關(guān)，但與 SAN 控制器直接相關(guān)的卷實現(xiàn)復制。由于技術(shù)較新，且只有 IBM 一家推出，未得到其他硬件廠商支持，非主流技術(shù)，以下不再闡述。2.3 應用系統(tǒng)恢復應用系統(tǒng)恢復正如前所述，數(shù)據(jù)復制是容災的手段，不是目的，容災的目的是數(shù)據(jù)的訪問。正如前所述，數(shù)據(jù)復制是容災的手段，不是目的，容災的目的是數(shù)據(jù)的訪問。因此應用的恢復和以下的網(wǎng)絡(luò)的恢復也是容災的關(guān)鍵。因此應用的恢復和以下的網(wǎng)絡(luò)的恢復也是容災的關(guān)鍵。應用系統(tǒng)恢復，這和系統(tǒng)的應用模式直接相關(guān)。需要考慮應用系統(tǒng)的應用架構(gòu)。是 Clien

34、t/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)絡(luò)效勞程序，如中間件Tuxedo、CICS、WebLogic、WebSphere、9iAS、SAP 等等。在容災應用切換時，能夠手工或自動化的將這些效勞一一啟動。2.4 網(wǎng)絡(luò)系統(tǒng)恢復網(wǎng)絡(luò)系統(tǒng)恢復 在災難發(fā)生后，應用切換到災備中心了，本地的應用前端需要重新訪問容災節(jié)點的效勞，帶來另外一個問題，網(wǎng)絡(luò)如何切換？是建立新的網(wǎng)絡(luò)，還是使用動態(tài)路由，還是有其它方法？實際上最簡單的方法，就

35、是通過外部 DNS 效勞器，改變效勞器名和 IP 的映射關(guān)系，將原效勞器名映射到新的 IP 地址上，就可以利用容災網(wǎng)絡(luò)，實現(xiàn)前端對容災中心效勞器數(shù)據(jù)的訪問。2.5 容災切換過程容災切換過程 就是在災難發(fā)生后，數(shù)據(jù)庫切換、應用重新啟動、網(wǎng)絡(luò)實現(xiàn)切換等等,容災中心接管原生產(chǎn)中心的整個過程；同時還包含了在原數(shù)據(jù)中心修復后，數(shù)據(jù)庫、應用、網(wǎng)絡(luò)需要重新切會來的整個過程。這些過程，可以通過手工切換、也可以通過自動化過程完成。2.6 消防演習消防演習大局部的容災方案，在工程實施后，很難有時機來實現(xiàn)預演，因為對于大局部方案來說，這種預演活動，需要消耗大量的人力財力。但是消防預演是必不可少的，它是實時測試目前的

36、容災方案的漏洞，保證容災方案在災難發(fā)生時，能夠真正生效。第第 3 3 章章 主流容災技術(shù)分析與比照主流容災技術(shù)分析與比照沒有一種技術(shù)可以解決所有得 IT 問題，因此，也沒有一個解決方案是完美無缺得，依據(jù)現(xiàn)狀、技術(shù)要求、和未來的拓展，我們在此討論的是最適宜容災技術(shù)的解決方案。3.1 數(shù)據(jù)備份數(shù)據(jù)備份 SHARE 78 評審標準中，Tier 0、Tier 1、Tier2 級別容災要解決的問題。如前面所闡述的，數(shù)據(jù)備份是容災系統(tǒng)的起點，是最低端的容災方案。不是說有了高端的實時容災方案，就可以不要備份系統(tǒng)了，因為實時容災不能解決惡性操作、誤操作等故障，而備份系統(tǒng)可以解決。在此我們要討論的是，如何利用現(xiàn)

37、有的備份系統(tǒng)，是容災方案更加完備。正如 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 Restore:裸金屬恢復)模塊，可以對 AIX、Solaris、HPUnix、Windows、Linux 操作系統(tǒng)實現(xiàn)備份，備份這些操作系統(tǒng)的相關(guān)補丁、外設(shè)驅(qū)動程序、相關(guān)的文件系統(tǒng)配置信息、相關(guān)的卷配置信息、內(nèi)核參數(shù)等。在災難

38、修復時，可以通過恢復的方式快速恢復相關(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、HPUnix、Windows、Linux 全部操作系統(tǒng)，也就是說，不能實現(xiàn)統(tǒng)一的容災應對策略，反而會增加容災的復雜度。Veritas NetBackup 還有另外一個叫 Vault 的模塊，可以實現(xiàn)對備份數(shù)據(jù)的自動拷貝，并實現(xiàn)異地存放和管理。Share 78 中

39、 Tier 1 、Tier 2 級別容災。Veritas NetBackup 還能構(gòu)實現(xiàn)快照備份，就是備份時對原盤做磁盤級快照。Veritas NetBackup 可以和 Veritas Volume Snapshot、EMC TimeFinder 等業(yè)界主流的快照工具做整合，實現(xiàn) Server-Free (OFF-Host)的備份，既備份時，原應用效勞器不參與的備份，大大提供了備份系統(tǒng)的能力。Veritas NetBackup 針對 AIX、Solaris、HPUnix、Windows、Linux 的備份，無論選擇何種平臺作為主控效勞器、無論如何調(diào)整，都是通過同一 Java GUI 和 We

40、b GUI 實現(xiàn)管理，簡單易用，用戶容易掌握。3.2 實時數(shù)據(jù)保護實時數(shù)據(jù)保護 SHARE 78 評審標準中，Tier 3 級別容災。3.2.1 3.2.1 數(shù)據(jù)鏡像數(shù)據(jù)鏡像MirroringMirroring數(shù)據(jù)鏡像分軟件鏡像與硬件鏡像。3.2.1.1硬硬件件鏡鏡像像通過硬件級別的 Raid-1 實現(xiàn)，其實現(xiàn)過程簡單，但要求嚴格。只能基于同一廠商、同一陣列、同樣容量大小的兩塊磁盤來實現(xiàn)。3.2.1.2軟軟件件鏡鏡像像Veritas Volume Manager 實現(xiàn)邏輯卷級鏡像，對存儲空間要求較低，只要有空間且至少兩塊磁盤就行。不要求同一廠商、同一陣列、同樣容量大小的兩塊磁盤，Veritas

41、 Volume Manager 能夠?qū)崿F(xiàn)跨廠商、跨陣列的鏡像，在磁盤空間不均時，能夠?qū)崿F(xiàn) 1 塊磁盤對多塊磁盤、N 塊磁盤對 M 塊磁盤的鏡像。3.2.1.3鏡鏡像像技技術(shù)術(shù)在在容容災災中中的的利利用用在通過 SAN 的支持，DWDM 的拓展，光纖網(wǎng)絡(luò)可以擴展到 100 公里或更遠，鏡像可以在較遠的兩個數(shù)據(jù)中心的磁盤上建立。但由于鏡像系統(tǒng)是以同步方式實現(xiàn)的，受到距離、光纖協(xié)議、和相關(guān)協(xié)議轉(zhuǎn)換的影響，同步方式會影響本地效勞器的性能，所以，一般建議在20 公里的同城容災中使用，在遠程容災中可作為一種加強方案與遠程容災方案整合，將在我們的詳細方案中描述。常說的遠程磁盤鏡像，實際上是遠程磁盤復制，不是

42、真正意義上的鏡像。我們將在后續(xù)文章描述?；?SAN 的鏡像，在容災實現(xiàn)中，使用范圍較小，如上說述，適用于同城容災，但支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設(shè)備、應用配置文件、應用程序、庫函數(shù)等，因而支持各類應用系統(tǒng)容災，包括數(shù)據(jù)庫、中間件、客戶自己開發(fā)的應用，適用于 2 層架構(gòu)、3 層或多層應用架構(gòu)。3.2.2 3.2.2 數(shù)據(jù)復制數(shù)據(jù)復制ReplicationReplication數(shù)據(jù)復制是運程容災實現(xiàn)的根底。3.2.2.1軟軟件件復復制制 卷卷復復制制 VERITAS Volume Replicator(簡稱 VVR)負責遠程數(shù)據(jù)復制。VVR 復制基于Volume 進行，將

43、數(shù)據(jù)特別是需要進行遠程復制的相關(guān)文件系統(tǒng)、數(shù)據(jù)庫、裸設(shè)備、應用程序等，存放在復制卷組中，系統(tǒng)便能自動同步本地和異地相應的復制卷組。復制的示意圖見圖四。 VVR 與 VxVM 完全集成在一起。用 VxVM 管理 GUI 界面和命令統(tǒng)一配置管理；由于VVR 僅僅將 Volume 上每次 I/O 的操作復制到遠程節(jié)點，復制的信息是卷的日志，所以在網(wǎng)絡(luò)線路上傳輸?shù)臄?shù)據(jù)量很少，對帶寬的需求也較小。；Storage Replicator Log(簡稱 SRL)是 VVR 中的重要部件。需要復制的 I/O 操作，首先要寫入 SRL，然后傳到異地。VVR 通過 SRL 保證數(shù)據(jù)復制嚴格按照寫順序進行，這在異步

44、工作方式下非常重要。當網(wǎng)絡(luò)中斷或異地系統(tǒng)出現(xiàn)故障時，本地數(shù)據(jù)將記錄在 SRL 中，當 SRL 滿后，VVR 將使用 DCM(Data Change Map)記錄變化的數(shù)據(jù)塊的塊號，等系統(tǒng)恢復正常時再將 SRL 中的數(shù)據(jù)按照先進先出的順序傳送到異地，最后再將 DCM 中記錄的塊傳送到異地。 VVR 數(shù)據(jù)流程見圖五： 圖五 數(shù)據(jù)復制的工作模式缺省為同步/異步自適應，即在網(wǎng)絡(luò)延時情況較好、數(shù)據(jù)能夠及時復制時，工作在同步方式，完全保證兩邊數(shù)據(jù)的一致性；當網(wǎng)絡(luò)延時情況較差、數(shù)據(jù)不能及時復制時，工作在異步方式下，保證主節(jié)點的 I/O 性能。數(shù)據(jù)復制根據(jù)實際情況，自行在兩種工作模式之間切換。并且基于卷的日志

45、SRL：先進先出保正了再極端情況下，如容災網(wǎng)絡(luò)中斷、數(shù)據(jù)復制不能正常進行，容災中心數(shù)據(jù)于生產(chǎn)中心數(shù)據(jù)有延遲，在一切故障排除后，能夠嚴格保證所以 I/O 的寫順序，這類似于數(shù)據(jù)庫數(shù)據(jù)塊和數(shù)據(jù)庫日志的關(guān)系，通過帶時間戳的數(shù)據(jù)塊和順序日志，保證數(shù)據(jù)的一致性。 基于軟件的遠程復制，在容災實現(xiàn)中，使用范圍最廣，支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設(shè)備、應用配置文件、應用程序、庫函數(shù)等，支持各類應用系統(tǒng)容災，包括數(shù)據(jù)庫、中間件、客戶自己開發(fā)的應用，適用于 2 層架構(gòu)、3 層或多層應用架構(gòu)。3.2.2.2硬硬件件復復制制通過所謂的遠程磁盤鏡像實現(xiàn)，其實現(xiàn)要求嚴格。只能基于同一廠商、同型號陣列

46、、同樣容量大小的兩個陣列來實現(xiàn)。廠商一般建議使用間歇性復制。遠程磁盤鏡像復制，在容災實現(xiàn)中，支持所有的類型數(shù)據(jù)同步，包括文件數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)、裸設(shè)備、應用配置文件、應用程序、庫函數(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)中心和容災中心復制的是改動過的

47、物理數(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ū)?，發(fā)生在數(shù)據(jù)庫的聯(lián)機日志上，那將對數(shù)據(jù)庫數(shù)據(jù)的一致性造成破壞。3.2.2.3數(shù)數(shù)

48、據(jù)據(jù)庫庫復復制制數(shù)據(jù)庫復制，如 Oracle 的 Data Guard、Quest SharePlex、DSG RealSync 等，通過分析數(shù)據(jù)庫 Redo Log 和 Archive Log 實現(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 ,SQL

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

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

51、，不能復制其他的應用程序，配置文件，就是 Oracle 自己的，initSID.ora, *.ctl 也不能復制，一旦這些文件改動過，將需要管員人為操作或者需要其他軟件的管理，保證容災中心與生產(chǎn)中心同步應用、程序、配置文件同步。2由于 Data Guard 是通過日志來實現(xiàn)的，這要求數(shù)據(jù)庫必須運行在歸檔日志模式下。但我們知道，并不是所有的數(shù)據(jù)庫操作都寫日志：oracle 的 DMLData Manipulation Language或 DDLData Dictionary Language語句是不能被復制的，如 create index、table，alter table 等等；觸發(fā)器、存儲過

52、程操作不能被復制；系統(tǒng)升級、patchs 更新不能被復制。3與備份軟件的沖突。如前所述，對于核心應用系統(tǒng)，數(shù)據(jù)備份必不可少。對于數(shù)據(jù)庫的備份，也要求數(shù)據(jù)庫在歸檔模式下運行。備份系統(tǒng)在備份作用發(fā)起時，需要備份數(shù)據(jù)文件、control file、歸檔日志、甚至需要數(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ā)起

53、，強制歸檔；備份完成后，刪除歸檔日志后，數(shù)據(jù)庫復制軟件，該如何操作，將嚴重造成生產(chǎn)中心和容災中心數(shù)據(jù)不一致。如果備份作用不刪除歸檔日志，系統(tǒng)管理員將不定時的來維護歸檔目錄，他必須知道本地歸檔目錄中，哪一個歸檔日志已經(jīng)被備份，通過檢查容災中心數(shù)據(jù)庫中哪一個歸檔日志已經(jīng)被 apply，這將是一個惡夢一樣的維護工作。4極限情況下的危害。當生產(chǎn)中心和容災中心的復制鏈路一定時期內(nèi)不能恢復時，同樣需要在生產(chǎn)主機中保存所有的歸檔日志，這又需要管理員大量的維護工作。3.2.2.4數(shù)數(shù)據(jù)據(jù)庫庫雙雙活活在 Data Guard 中 Physical Standby 模式下，數(shù)據(jù)庫可以通過 read-only 方式

54、翻開。正如前面所述，Physical Standby 通過 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ù)庫？Data Guard 中 Logical Standby 模式下Quest SharePlex、DSG Realsync

55、 類似數(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ù)挖掘、或是一些測試，有很多其他一些成熟的解決方案。卷快照采用 Volume Manager 的鏡

56、像功能創(chuàng)立邏輯卷的某時間點拷貝。原數(shù)據(jù)(Primary)卷和卷快照都可以包含多個邏輯設(shè)備，如數(shù)據(jù)庫數(shù)據(jù)文件、redo log、archive log 目錄。對于 Oracle 數(shù)據(jù)庫，通過將數(shù)據(jù)庫置于 backup 模式以到達靜默；或者是使相關(guān)的表空間，置于 backup 模式以到達靜默。然后對整個instance 或某個表空間實現(xiàn)快照。由于 Oracle 的容錯能力，很多情況下，應用不靜默而直接對數(shù)據(jù)庫的數(shù)據(jù)卷照相，再由 Oracle log 機制恢復到一致性狀態(tài), 從而可以創(chuàng)立一個與生產(chǎn)中心完全相同數(shù)據(jù)的數(shù)據(jù)庫實例，可以用于生成報表、實現(xiàn)數(shù)據(jù)挖掘、或是一些測試。3.2.3 3.2.3 瞬間

57、快照瞬間快照(Instant(Instant Snapshot)Snapshot) 瞬間快照有三種方式，instant full snapshot，instant space-optimized snapshot 和 instant plex-breakoff snapshot。與傳統(tǒng)快照方式相比，瞬間快照的特點有以下幾點：plex 或者 snapshot 卷在進行 snapshot 前不需要鏡像同步，極大節(jié)省了創(chuàng)立snapshot 的時間。snapshot 瞬間可用。space-optimized snapshot即空間優(yōu)化 snapshot只要使用很少的空間就可以創(chuàng)立 snapshot。通

58、過快照，可以快速激活數(shù)據(jù)庫，該數(shù)據(jù)庫與生產(chǎn)環(huán)境的數(shù)據(jù)庫在快照時間點保持完全一致性，該數(shù)據(jù)庫可以以讀寫方式下翻開，提供查詢、備份、報表、數(shù)據(jù)挖掘，應用測試等等功能。在下一個 snapshot，該數(shù)據(jù)庫與生產(chǎn)環(huán)境的數(shù)據(jù)庫在快照時間點保持完全一致性。3.3 應用系統(tǒng)恢復應用系統(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)中心的高可用、

59、實現(xiàn)容災中心應用的自動啟動、實現(xiàn)生產(chǎn)中心在災難修復后應用的回切過程。目前主流的高可用方案主要有 Symantec VCS、IBM HACMP、HP MC/Service Guard、Sun Cluster、Windows CCS 等。各廠商軟件的名字上，我們就可以看到他們的缺乏。只能支持自己的平臺。也就是意味著如果使用他們的解決方案，得分別熟悉AIX、HPUnix、Solaris、Windows，得在分別熟悉 IBM HACMP、HP MC/Service Guard、Sun Cluster、Windows CCS 軟件，并且這些軟件大局部只提供命令行管理、調(diào)試方式，這在管理上又是一大難題。S

60、ymantec VCS 通過統(tǒng)一得圖形化 JAVA GUI 或 Web GUI，提供對AIX、HPUnix、Solaris、Windows、Linux 所有操作系統(tǒng)平臺、所有數(shù)據(jù)庫Oracle、Oracle RAC、SQL Server、Sybase、DB2、所有中間件：Weblogic、WebSphere、9iAs、Tuxedo，甚至是用戶自己寫得應用程序，實現(xiàn)得集中統(tǒng)一的集群管理和監(jiān)控。并且能夠定義這些效勞啟動、切換得先后順序，以確保數(shù)據(jù)能夠快速正常訪問。例如在 WebLogic Server 啟動之前，必須先啟動 Oracle,因為在 WebLogic Server 啟動是會建立數(shù)據(jù)庫得