【文章內(nèi)容簡介】 兩個中心之間之間彼此備份。在兩個中心之間，彼此的在線關鍵數(shù)據(jù)的拷貝不停地相互傳送著。在災難發(fā)生時，需要的關鍵數(shù)據(jù)通過網(wǎng)絡可迅速恢復，通過網(wǎng)絡的切換，關鍵應用的恢復時間也可降低到了小時級。 Tier 5Tier 5 兩中心兩階段確認 (TwoSite TwoPhase Commit)Tier 5 是在 Tier 4 的基礎上在鏡像狀態(tài)上管理著被選擇的數(shù)據(jù) (根據(jù)單一mit 范圍，在本地和遠程數(shù)據(jù)庫中同時更新著數(shù)據(jù))，也就是說，在更新請求被容災項目方案設計認為是滿意之前，Tier 5 需要生產(chǎn)中心與備份中心的數(shù)據(jù)都被更新。我們可以想象這樣一種情景，數(shù)據(jù)在兩個中心之間相互映像，由遠程 twophase mit 來同步，因為關鍵應用使用了雙重在線存儲，所以在災難發(fā)生時，僅僅傳送中的數(shù)據(jù)被丟失，恢復的時間被降低到了小時級。 Tier 6Tier 6 零數(shù)據(jù)丟失 (Zero Data Loss)Tier 6 可以實現(xiàn)零數(shù)據(jù)丟失率，同時保證數(shù)據(jù)立即自動地被傳輸?shù)絺浞葜行?。Tier 6 被認為是災難備份的最高的級別，在本地和遠程的所有數(shù)據(jù)被更新的同時，利用了雙重在線存儲和完全的網(wǎng)絡切換能力。Tier 6 是災難備份中最昂貴的方式，也是速度最快的恢復方式，恢復的時間被降低到了分鐘級。對于 Tier 6 的災難備份解決方案，可以應用兩種遠程拷貝技術來實現(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)采用不同級別的容災方案，如針對關鍵的業(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ù)庫應用結構，但業(yè)務系統(tǒng)容災并不等于是數(shù)據(jù)庫容災，還包括訪問數(shù)據(jù)庫的應用程序和相關配置信息。實現(xiàn)數(shù)據(jù)庫容災是容災的基礎，在保數(shù)據(jù)庫數(shù)據(jù)一致的前提下，還要實現(xiàn)應用程序和配置信息的一致性；實現(xiàn)應用系統(tǒng)的高可用性、應用程序在容災中心與生產(chǎn)中心接管和切回的過程，因此，還要考慮應用的模式是 C/S、B/S，兩層、三層、多層次的應用結構等等。 界定災備系統(tǒng)的總體架構 　　根據(jù)實際需求、現(xiàn)有技術、所在地域、計劃防范的災難種類和預算投入的資金量等實際情況，確定災備系統(tǒng)預期達到的級別，并以此來確定災備系統(tǒng)與生產(chǎn)運行系統(tǒng)在地理位置上的距離（同城還是異地或兩者兼?zhèn)洌竟?jié)點），備份數(shù)據(jù)存儲所在的介質(zhì)（磁盤還是磁帶或兩者兼?zhèn)洌?，備份?shù)據(jù)在生產(chǎn)中心與備份中心傳輸?shù)娜轂捻椖糠桨冈O計方式（這就涉及到了具體的計算機存儲與網(wǎng)絡技術），以及備份中心計算機系統(tǒng)的處理能力和網(wǎng)絡接管所需的具體架構（是否與生產(chǎn)中心采用完全同等數(shù)量、容量和性能的計算機、存儲設備和網(wǎng)絡體系結構）。 容災項目方案設計第 2 章 主流容災技術說明根據(jù) SHARE 78 評審標準，容災技術必需涵蓋了如下內(nèi)容： 數(shù)據(jù)備份 數(shù)據(jù)備份是系統(tǒng)、數(shù)據(jù)容災的基礎，也是低端容災的實現(xiàn)，是高端容災（實時數(shù)據(jù)保護）的有力保障。目前備份技術主要有快照備份、離線備份、異地存儲備份。備份系統(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)等其他配置信息是不能回滾的，將造成毀滅性的結果。因此在建設高端容災系統(tǒng)的前提，一定要做好本地系統(tǒng)的備份，這是容災技術的起點。目前成熟的備份軟件有某 NetBackup、EMC Legato，IBM TSM，HP Protect Server 等等。 實時數(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ù)據(jù)鏡像和數(shù)據(jù)復制。 數(shù)據(jù)鏡像（Mirroring）數(shù)據(jù)鏡像（Mirroring）是冗余的一種類型，一個磁盤上的數(shù)據(jù)在另一個磁盤上存在一個完全相同的副本即為鏡像。分軟件鏡像與硬件鏡像，它們的的區(qū)別就在于實現(xiàn)鏡像所需的 CPU 周期所處的位置。最終，都是根據(jù)程序的指令，為硬件（磁盤，以及磁盤上存儲的數(shù)據(jù)）制作一個鏡像副本。鏡像可以保證兩份數(shù)據(jù)完全一樣。鏡像軟件有某 Volume Manager；各硬件廠商都有基于自己陣列的硬件鏡像方式。 數(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ù)復制分為軟件方式和硬件方式；硬件方式往往又被稱為遠程鏡像。軟件復制有某 Volume Replicator；硬件復制有 EMC SRDF、HDS TrueCopy等。 軟 件 復 制 （ 卷 復 制 ）某 Volume Replicator(簡稱 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ù)量很少，對帶寬的需求也很小，因此也與應用無關，只要是在定義的復制卷上的仍和操作，都會被復制到異地。 硬 件 復 制以 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ù)塊SITE A應用數(shù)據(jù)庫操作系統(tǒng)控制器物理磁盤SITE BIO LogSQL/Log交易 數(shù) 據(jù) 庫 復 制數(shù)據(jù)庫復制，如 Oracle 的 Data Guard、Quest SharePlex、DSG RealSync 等，通過分析數(shù)據(jù)庫 Redo Log 和 Archive Log 實現(xiàn)日志的復制，將分析結果直接或轉化為 SQL 語句傳到容災中心，在容災中通過心 Aply 數(shù)據(jù)庫日志或將日志轉化的 SQL語句重做，來保證數(shù)據(jù)庫數(shù)據(jù)的一致性。數(shù)據(jù)庫復制實際上是應用復制的數(shù)據(jù)庫實現(xiàn)，復制方式通過異步完成。卷復制如上某 Volume Replicator?？刂破鲝椭疲缟?EMC 的復制過程。容災項目方案設計 IBM SVC實際上還有一種新的復制方式，稱為基于 SAN 網(wǎng)絡的卷復制，如 IBM 的 SVC。它是通過特殊的設備 SAN 控制器，建立基于 SAN 控制器的卷，通過這種與主機應用無關，但與 SAN 控制器直接相關的卷實現(xiàn)復制。由于技術較新，且只有 IBM 一家推出，未得到其他硬件廠商支持，非主流技術，以下不再闡述。 應用系統(tǒng)恢復正如前所述，數(shù)據(jù)復制是容災的手段，不是目的，容災的目的是數(shù)據(jù)的訪問。因此應用的恢復和以下的網(wǎng)絡的恢復也是容災的關鍵。應用系統(tǒng)恢復，這和系統(tǒng)的應用模式直接相關。需要考慮應用系統(tǒng)的應用架構。是 Client/Server 架構，還是 Broswer/Server 架構；是 2 層架構、還是 3 層架構、還是多層架構。兩層架構，表示容災中心的應用只要啟動數(shù)據(jù)庫就可以服務了。如果是三層架構，就意味著應用系統(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 的映射關系，將原服務器名映射到新的 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ā)生時，能夠真正生效。容災項目方案設計第 3 章 主流容災技術分析與對比沒有一種技術可以解決所有得 IT 問題，因此，也沒有一個解決方案是完美無缺得，依據(jù)現(xiàn)狀、技術要求、和未來的拓展，我們在此討論的是最合適容災技術的解決方案。 數(shù)據(jù)備份 SHARE 78 評審標準中，Tier 0、Tier 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、SQL Server、DBSybaseASE 等，Veritas NetBackup 除了可以很好的備份相關的文件系統(tǒng)數(shù)據(jù)、數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)外，同時通過 BMR(Bare Metal Restore:裸金屬恢復)模塊，可以對 AIX、Solaris、HP－Unix、Windows、Linux 操作系統(tǒng)實現(xiàn)備份，備份這些操作系統(tǒng)的相關補丁、外設驅動程序、相關的文件系統(tǒng)配置信息、相關的卷配置信息、內(nèi)核參數(shù)等。在災難修復時，可以通過恢復的方式快速恢復相關操作系統(tǒng)。實際經(jīng)驗，操作系統(tǒng)安裝、打補丁，安裝相關驅動程序、恢復內(nèi)核參數(shù)、恢復文件系統(tǒng)配置、恢復卷管理系統(tǒng)配置等整個過程，可以縮短在 1 小時內(nèi)完成，并且降低了人為錯誤操作過程。這樣大大提高了原生產(chǎn)中