容災系統在公共圖書館業務中的應用——以深圳圖書館為例

成 星（深圳圖書館）

1 引言

隨著深圳“圖書館之城統一技術平臺”（簡稱：平臺）應用的不斷推廣，深圳圖書館（簡稱：深圖）的大集中DILAS數據庫模式替代了原有的各區多中心、應用數據分散存儲和處理的方式，這種新模式為深圳市公共圖書館的共建共享、互聯互通以及讀者無障礙享受全市公共圖書館服務提供了可行、可靠的技術基礎。然而，當全市的數據和業務都集中在深圖的中心機房后，數據的安全和讀者業務連續性的問題隨之而來。一旦網絡中心發生災難，受到影響的將是全市幾乎所有的圖書館業務，這必將對讀者造成巨大的損失。如何維持業務連續運作和保證數據的安全，成為能否為讀者提供更優越服務的關鍵所在。

異地熱備是目前解決數據安全最優的技術，它可以確保數據零丟失和業務零停頓，因此建立異地容災系統是深圖IT建設的重要任務。通過對業務數據和應用需求的詳細分析，深圖的容災系統將被規劃為“兩地互備”容災中心，即采用“雙中心”容災模式。該系統的投入將達到如下效果：數據實時備份且異地存儲，數據安全級別高；業務故障啟用遠程接管，讀者服務不間斷；數據恢復速度快，數據丟失量RPO〈=5分鐘、恢復業務時間RTO〈=30分鐘；全面防護各種類型的災難，做到硬件與系統災難同時防護。

2 容災系統的可用性

整合全市數據庫后，深圖網絡中心網絡數據交換量和服務器業務請求量明顯增大，來自硬件和系統的故障發生率也隨之增高，這些都嚴重威脅著為讀者服務的質量。為提高讀者服務質量，我們必須保證業務的不間斷和數據的安全，因此建設容災系統非常之必要，且在建設中，如何將原有的本地熱備、本地存儲以及業務應用系統很好地融合到容災系統，為“平臺”構建一個新型的強大容災體系，都是需要認真面對的問題。

2.1 網絡環境現狀

深圖的核心服務器都采用雙機熱備，并通過IP-SAN連接大型存儲設備。就數據量而言，核心數據庫和“平臺”數據庫的數據總量大約在200G，日均變化在2G，IO負載中等；業務系統而言，60個應用，出口帶寬需要50M左右。應用服務器和存儲架構如圖1所示。

2.2 系統的設計目標

基于深圖現有的主機存儲結構和“平臺”業務的需求，我們擬搭建異地容災系統，最終的目標是構建一個安全、穩定的數據應用環境，為公共圖書館的長遠規劃提供一個可持續發展的IT架構。系統完成后將實現如下功能：

圖1 深圖服務器與存儲架構圖

（1）業務發生故障，遠端備份系統瞬間接管業務且實現最小的數據丟失；

（2）系統支持多平臺、多操作系統、多種應用混合建設，便于實施和管理；

（3）為了防止各種邏輯災難，系統可制作多個歷史版本作為備份，并且歷史版本與業務系統的數據格式相同，做到瞬時恢復；為了提高恢復的準確率，可提前驗證這些備份；

（4）對于站點級別的災難，RPO和RTO都不高于10分鐘；

（5）考慮到“平臺”業務的重要性，系統應在數據庫或應用打開的情況下做初始數據同步，這樣大大縮短停機時間；

（6）從業務端到容災端的數據復制有一致性保證機制，使得容災端的數據可用，接管業務時可以瞬間打開數據庫或應用系統；

（7）系統具有斷點續傳的功能，保證網絡在較長時間中斷的情況下不丟包，恢復網絡后進行增量傳輸；

（8）系統具有擴展性和開放性，兼容所有第三方主流存儲以及前端應用主機的操作系統。

3 容災的關鍵技術

數據和應用的容災是容災系統的核心。本地業務的開展產生大量數據表格，為確保數據的存儲安全，這些數據被實時傳輸到異地存儲中心，形成一個數據副本，該過程為數據容災。其目的在于當本地數據被破壞，可以調用異地數據拷貝，從而將損失降到最低。數據的時效性要視具體業務的特點來定義時間復制策略，不是全部副本都要做到絕對同步，但所有的數據一定要可靠可用。數據容災涉及到的技術包括數據復制、數據備份以及數據管理等；應用容災是在異地搭建同樣的業務應用系統，隨時監聽著本地應用的心跳，一旦發現本地業務無響應，異地系統將及時接管本地服務。它涉及到的技術包括災難檢測技術、系統遷移技術等。下面將就本系統在設計過程中涉及到的幾項關鍵技術加以描述。

3.1 數據備份技術

為保證安全高速的數據讀寫，深圖本地關鍵業務數據的存儲采用IPSAN網絡架構，同時考慮到將來虛擬機存儲的特點，數據備份系統也建立在該網絡基礎上。系統運行時，數據通過IPSAN存儲交換機進行交換，而不占用業務系統的網絡開銷。相對獨立的數據吞吐環境拉近了業務平臺和存儲介質之間的距離，這種存儲架構是實施異地容災系統的基礎。而異地容災系統是按照備份策略，將數據通過城域網傳輸到遠端存儲介質上，即應用與存儲在空間上被隔開，這種備份方式構成了異地數據災備。遠程數據備份必須考慮傳輸速度，因此具體的備份策略需視業務情況而定，小數據流可以直接采用同步備份，而大數據流則可采用異步傳輸。同時為確保數據的高可用性，系統將建立日常預恢復機制，在網絡及服務器空閑時段進行備份恢復測試。

3.2 數據復制技術

在異地容災系統中，數據復制是指將本地業務產生的數據拷貝到遠端存儲器中，遠端的應用服務器將啟用這些備份數據并在線待機。一旦發生災難，遠端備份應用系統將加掛最新數據庫接管主業務。按照兩地備份數據是否同步，數據復制可分為同步和異步數據復制。根據系統的設計要求，我們將采用異步傳輸機制，即采用日志復制功能將主業務系統中的數據傳遞到遠端，而遠端應用系統根據日志內容執行應用，并生產出可用的備份數據，實現兩端的數據一致。

3.3 災難檢測技術

對容災系統而言，第一時間發現主業務端的災難信號，將主業務數據及時遷移到遠端并接管主業務系統，都可以減少災難帶來的損失。在日常巡檢中，人為因素可避免少許故障，但無法預知突發災難。容災系統通過心跳檢測系統，及時監控業務系統的心跳信號，當無法接收到該信號時，系統則視主業務系統發生災難并啟動應急策略，開始對數據進行遷移并瞬間接管主業務。該技術的關鍵參數是心跳檢測時間和頻率，如頻率太高，則會影響到主業務的運行；如頻率過低，則無法及時發現災難。本系統中，根據讀者業務的忙閑時段，自動調整檢測周期，確保業務正常運轉。

3.4 系統遷移技術

災難發生后，讀者業務將快速透明地遷移到遠端備份系統，由遠端系統接管主業務，確保對外讀者服務的連續性。對實時性要求不高的業務如CNKI數據庫服務和短信平臺服務等，可修改網絡參數指向遠端；對實時性要求高的業務，如DILAS系統，則需將主業務應用透明遷移到遠端備用系統上，實現完全接管。

4 容災系統的工作原理

首先，容災系統執行數據復制策略。系統可以自定義不同的策略來控制遠程數據復制的過程，利用本地服務器內建的快照引擎和遠端服務器的接收機制，將數據從業務端復制到容災端的存儲介質中，確保復制進程能夠在短時間內完成，從而獲得高可用的數據。系統具有各類可供選擇和調整的復制策略，因而遠程復制具有可調整性和優化策略的能力。

其次，系統采用自動連續快照技術將需要備份的數據加工處理。該技術利用快照緩存，提取變化后數據塊的前一時間點數據進行保存。其根本作用是能在故障發生的瞬間，系統根據需要會退回到某一時間點，提取該時間點數據的指針，并對提取到的數據映射自動恢復，達到業務快速連接的效果，解決傳統備份中非精細時間恢復的缺點。這種技術不但能夠應對硬件錯誤，同時也具備對軟件錯誤的防范及糾錯功能，對系統的正常運轉提供有力保障。該技術能夠使深圖的業務系統實現精確時間點的保存，為容災系統提供每個應用卷多達255個自動快照點的水準，確保每個應用卷每天都有間隔為5分鐘的完全映像。高頻率的映像可保證將系統的數據丟失量降到最低，當發生任故障時，系統都可以找到最新一個時間點進行數據還原。

再次，系統采用微單元傳輸技術，將傳輸的最小數據單元縮小到512字節，占用小帶寬傳輸大數據到異地進行備份。在傳輸過程中，系統采用了讀寫優化技術，業務數據先順序地寫入到高速磁盤設備中，然后按照讀寫優化策略，將緩存中的數據再隨機寫入到后端存儲中；同時系統采用虛擬化存儲技術，將后端存儲設備進行抽象化統一管理，向服務器層屏蔽存儲設備硬件的特性，而只保留其統一的邏輯特性。微傳輸和讀寫優化的結合為數據備份提供了高可用性。

最后，當災難發生時，容災系統利用時間標記將歷史點數據瞬間提取并進行校對，從而將數據恢復。由于數據庫系統未能實時刷新到磁盤中，數據的寫入存在滯后，因此數據恢復過程中關鍵之二是感知數據庫技術，即根據最新日志對指定復制點和快照點的數據庫進行刷新，從而確保數據庫日志與數據文件的一致性。這種感知技術使得容災與應用數據庫體系真正結合起來，實現了應用容災。

5 容災系統的設計與實現

5.1 容災系統的架構設計

在現有網絡中心的基礎上，深圖將在20公里外的深圖調劑書庫建立一個備份機房，實現異地容災，為“平臺”提供高可用的數據保護和業務支持。其基本架構見圖2。

圖2 深圖容災系統架構圖

5.2 容災系統的架構描述

（1）在深圖中心機房即業務端部署3臺數據恢復服務器，其中兩臺用于本地業務數據保護，一臺用于承接容災端的容災數據。

（2）容災端部署一臺數據恢復服務器，通過FC協議進行本地數據保護，通過WAN網進行服務器系統管理。保護數據的方法是將業務數據鏡像到數據恢復服務器中。

（3）在業務端，將原核心數據存儲HPXP12000下掛至數據恢復服務器，它采用旁路的方式接入到SAN網絡中并下掛存儲，不會增加現有網絡負載。

（4）對于AIX主機，數據以同步鏡像的方式備份到數據恢復服務器中（圖中A-〉B的過程），不影響正常的生產數據。

（5）對于Linux/Windows主機，數據以異步鏡像的方式備份到數據恢復服務器中（圖中A-〉B的過程），也不影響正常的生產數據。

（6）同樣在容災端，數據恢復服務器采用旁路的方式接入到局域網中，數據以鏡像的方式同步到數據恢復服務器中（圖中D-〉E的過程）。

（7）當開始備份時，業務端系統將鏡像過來的數據復制到容災端系統中（圖中B-〉C的過程）。容災端系統服務器配置255份快照，實現多點的保護，同時業務端進行無服務器歸檔備份。

（8）當災難發生時，容災端系統將鏡像過來的數據復制到業務端系統中（圖中E〉F的過程）。業務端系統服務器同樣配置255份快照，這樣在兩端各有255份歷史快照，對歷史數據的安全進行了雙重保護。

（9）遠程復制采用TCP/IP協議，復制策略根據實際的業務數據量靈活制定。利用數據恢復精簡復制技術，可以實現連續傳輸的模式，將數據丟失量降到最低。另外還包括基于時間或數據增量的間隔復制模式。

5.3 容災系統的恢復

當不同類型的災難發生時，容災系統將如何運作，即系統對“平臺”環境中的主機（包括數據庫和應用系統集群）如何進行接管和恢復，下面將詳細說明。

5.3.1 數據庫表級別的丟失或損壞

由于誤操作或病毒入侵等原因，數據庫會出現表記錄的丟失或損壞情況。面對這種災難，容災系統首先將在業務主機上掛載數據恢復服務器提供的歷史快照，該快照包含完整的記錄條目，然后使用數據庫命令將快照記錄導入到業務數據庫中即可恢復正常。

5.3.2 數據庫和應用系統的文件丟失或損壞

當出現邏輯錯誤，如數據庫文件丟失或損壞，容災系統可直接讀取歷史點快照并重建數據。首先容災系統找到最新的時間點，提取其快照并分配給業務服務器；其次服務器加載新鏡像后啟動數據庫并導出表或數據庫；最后將導出的數據庫重新導入原數據庫中。如情況緊急，數據恢復服務器的快照是可直接讀寫的，業務主機可直接使用快照磁盤來接管業務，保障業務的連續性。

5.3.3 應用和數據庫啟動失敗

當應用和數據庫系統無法啟動時，容災系統首先提取快照并進行主業務接管。方法是首先提取歷史快照，然后分配給業務服務器并掃描鏡像，最后直接啟動應用或數據庫。

5.3.4 業務存儲發生故障

當業務系統盤出現故障時，遠端業務鏡像盤會自動接管主業務，而數據庫系統不會感知到故障的發生，保證了讀者業務的連續性。當恢復正常時，主業務服務器將自動啟用，同時數據會自動同步。

5.3.5 站點級別的災難

對于容災系統而言，如果要實現站點級別的容災，需在容災端部署備份業務主機，數據來自于當地的數據恢復服務器。當業務端發生站點級別的災難時，容災系統自動啟用容災端的備份業務來接管。當業務端修復后，容災端的數據恢復服務器以增量的方式將數據同步回傳至業務端，實現無數據丟失故障恢復。

5.3.6 Windows操作系統恢復

圖3 Windows操作系統恢復工作原理

當發生操作系統故障，主業務服務器可通過容災策略直接調用遠端業務系統鏡像作為本地啟動盤。這些功能都能確保在最短時間內恢復業務，保證業務連續性。工作原理如圖3所示。

6 測試效果

經過長期論證、嚴謹設計、及時調整的歷程，深圖容災系統已完成實物測試，待調劑書庫建設完畢，系統將快速投入使用。屆時該系統將主要為深圖、各個區館以及24小時街道自助機服務。該系統可以保障所有業務數據安全、業務運行永不停止，測試結果已達到預期的目的。具體體現在如下幾點。

（1）高密度快照的實時備份為數據安全和業務連續提供了堅實基礎。

（2）通過災難檢測技術的應用，系統可實時監控業務系統運行狀況。

（3）災難恢復過程迅速，數據還原精確，業務運行平穩。

（4）可以恢復到任意時間點，且數據的可用性更高。

（5）面對不同的災難有不同的處理模式，確保業務的連續性。

7 結語

在公共圖書館業務不斷增多、數據不斷膨脹的今天，數據與應用的安全尤為重要。而容災系統其特有的災難檢測、系統遷移和任意時間點快照恢復等技術，完全可以保障數據與應用的安全。深圖容災系統已成功對多次突發故障實現了快速恢復，為全市圖書館業務的不間斷開展提供了安全保障。實踐證明，容災系統是公共圖書館長遠發展的堅強后盾。

1 張成武,金浩.圖書館容災系統的數據安全技術[J].圖書館工作與研究,2007(5):58～59

2 林平.基于數據分級的高校圖書館館際互助災備模式[J].情報探索,2010(8):44～46

3 楊雪媚,趙奎,李濤.一種服務容災系統的設計與實現[J].計算機應用研究,2010,27(7)：2647～2649,2653

4 Keith B.A Developer's Instroduction to ActiveDirectory Fe de-rationServices[J].MSDN Magazine,2006,21(12):76～80,83

5 Radha Telikepalli,JamesYan.Storage Area Network Extension Solutions and Their Performanee Assessment[J].IEEE Communieations Magazine.2004(4)