企業信息系統容災方法與實踐

摘要:在信息系統成為企業核心業務的主要支撐系統之一時，對信息系統的可靠性提出了很高的要求，容災系統就是針對信息系統發生災難的小概率事件而設計的。通過對業務影響分析，選擇合適的設備、技術和開發DRP，從技術、流程、人力三個方面保證容災系統在關鍵的時刻發揮作用。寧波港通過自身的實踐，建立了適合企業特點的集裝箱生產作業系統的容災體系。

關鍵詞:信息系統;容災;寧波港

中圖分類號:TP309.2文獻標識碼:A文章編號:1009-3044(2009)27-7807-03

隨著企業信息化程度的不斷提高，信息已經成為企業重要的組成部分和財富，信息系統作為企業管理、生產、經營和決策的重要手段，是保證業務連續性的關鍵因素之一。信息系統在運行過程中，會遭到來自不同層面的威脅，存在不同等級的風險，從而導致信息系統的故障或災難。信息系統故障和災難的發生對企業的影響巨大，有時帶來的甚至是毀滅性的打擊。作為嚴重影響企業信息系統運行的突發事件——災難，它可能由于自然災害、設備故障、社會災難或人為因素等所造成。所謂容災，就是面對災難，按照其種類和等級，有針對性地找出解決方案，將信息系統從災難造成的故障或癱瘓狀態恢復到可正常運行狀態，并將其支持的業務功能從災難造成的不正常狀態恢復到可接受狀態，而設計的活動和流程。

1 容災的需求和關鍵因素

災難，尤如達摩克利斯之劍，高懸在企業頭上，無法預知什么時候就會掉下來。災難可以分為自然災難、設備故障、社會災難和人為災難，自然災難的火災、水災和地震等，設備災難的電力系統故障、IT設備故障、通信設備故障等，社會災難的恐怖襲擊、戰爭等以及人為災難的IT系統管理人員誤操作、計算機病毒、木馬和來自網絡的惡意攻擊等，無不對信息系統造成不可挽回的損失，從而對企業業務連續性產生嚴重影響，以至影響到企業的生存。美國“9.11”事件是社會災難的一個典型例子，災難發生后，企業是否建立了容災體系，直接影響到了企業的生存，一些沒有任何容災措施的企業，由于核心業務數據受破壞而最終破產，而另一些采取了容災措施的企業，由于數據的恢復而得以生存。據Gartner Group的統計報告，2/5的企業在經歷大災難后再也不能恢復運作，另外1/3在2年內也接著倒閉，美國勞工局發布的統計顯示，93%的企業在遭受嚴重的數據丟失后5年內倒閉，由此可看出，對信息的容災會直接影響到企業的生存。面對災難，企業為保證業務連續性，就必須采取一定的方式，如人員、設備、信息等，在一定的時間內恢復所必須的關鍵業務。對信息系統來說，容災是一個必然的選擇。

根據國務院信息化工作辦公室《重要信息系統災難恢復規劃指南》中對容災的定義，容災是將信息系統從災難造成的故障或癱瘓狀態恢復到可正常運行狀態，并將其支持的業務功能從災難造成的不正常狀態恢復到可接受狀態，而設計的活動和流程。容災按所保護的對象、對數據丟失的要求，從最低的只做本地數據備份，沒有數據送往異地方式到最高的零數據丟失，保證數據和應用的變更會立即自動地被傳輸到遠地的容災中心，共分為7級。不僅建立容災中心的本身需要費用，而且日常管理、容災演練，都是需要成本的，因此，需要對業務連續性要求、直接收入損失、生產力損失、信譽損失以及財務業績損失等作一個總體的評估后，選擇一個合適的等級，根據所選擇的等級，從技術、流程和人力三個方面設計出容災系統。容災系統的切換和回切過程如圖1所示。

從技術上看，衡量容災系統有兩個主要指標:恢復點目標RPO(Recovery Point Objective)和恢復時間目標RTO(Recovery Time Objective)，實際上，RPO代表了最大可容許數據丟失量，而RTO則代表了最大可容許恢復時間。RPO與RTO越小，系統的可用性就越高，對業務連續性的支持就越強，當然用戶需要的投資也越大。除了這二大指標外，根據實際的需求，會對容災系統提出其他的要求，如性能要求、目標端(容災系統)數據實時可讀性等。

在流程上看，容災系統根據設計，每一個周期會對數據或應用進行備份，當發生災難時，會丟失當前與上一個備份周期之間產生的新的數據和應用變更內容，這就是RPO，信息系統進入了不可用狀態，通過切換流程后，系統進入臨時環境，這就是RTO，臨時運行狀態以滿足業務連續性為目標，性能等方面與正式環境有一定的差距，當正式環境完成修復后，進行系統回切，回切過程中，也有一個系統不可用過程，回切后，系統重新進入正常運行。

實現信息系統容災，要從信息系統對業務的影響開始，通過對業務、財務、客戶關系、員工、企業形象等多方面的影響分析，評估業務對于信息系統的依賴程度和災難性停機造成的損失，確定總體目標。根據確定的總體目標，選擇合適的技術，開發相適應的DRP，以實現容災系統。

2 容災的技術選擇

按信息系統的架構，實現容災的技術涉及多個方面，主要包括主機、網絡、數據和應用幾個方面。前二個是基礎，提供物理層面的保障，任何容災系統都需要，后者是真正的目標，數據恢復是最基本的要求，應用系統的恢復有多種選擇，對變更頻繁的應用系統，可采用自動同步技術實現變更的定期同步，對變更不頻繁的應用系統，可采取手工同步或采取一定的發布策略，實現應用的恢復。采用不同的技術，實現不同的RTO與RPO，直接關系到投入的費用，因此，需要在評估業務連續性要求及信息系統實際情況后，再選擇合適的技術。容災技術實現如圖2所示。

容災主機的技術選擇，首先考慮的是同構系統，然而，在實際需求中，會存在多個主機、多個系統、多個數據庫統一容災到一個主機系統上，會出現異構系統和選擇低性能的主機等情況，因此主機的選擇上，建議采用業界的主流機型，采用主流的操作系統、數據庫和中間件，并可考慮通過主機分區技術，盡可能做到每個分區分別運行不同的系統。

網絡的技術選擇，目前的網絡基本都是基于IP協議的，技術上的除了產品的選擇外，主要的難度在于實現，總的原則是新建一套網絡，獨立于原網絡系統，防止災難發生時，原網絡受到破壞而造成整個容災系統的失效。首先是主干，要考慮新建一條鏈路，專門用于容災，平時作為數據復制的鏈路，災難發生時，用戶通過這一鏈路訪問容災中心的主機;其次，原網絡中考慮第二個匯聚點，把終端用戶同時接入備份網絡，保證在原網絡出現故障后，可切快速換到備份網絡，繼續工作。網絡的實現，要對原網絡的配置要作大量的調整，采取適當的解決方案，達到高性價比。

數據和應用同步技術，是最關鍵的技術，主要有四種方式:一是存儲復制技術，分為基于陣列和基于SAN的存儲復制，此類的典型方案有EMC遠程磁盤復制技術、EMCRecoverPoint、HP EVA磁盤陣列、HP的SAN-Equation;二是主機復制技術，主機同時將數據分別寫到本地和遠程的磁盤設備上，實現業務數據的遠程復制，此類的典型方案有HP-UX MirrorDisk/UX，Veritas Volume Replicator;三是數據遠程復制技術，此類的典型方案有IDVData Busniess Guard、DSG RealSync、Oracle 11g活動數據衛士、Quest Shareplex;四是基于應用同步，對現有應用進行修改，把數據同時寫入運行環境和容災環境，這種方式對現有應用影響很大，實施難度大、風險大，一般不會采用。前三種方式的優缺點如表1。

同步技術的選擇，需結合主機技術的選擇，在應用層面上考慮容災中心的數據是否需要做增值服務，是需要實時使用，還是定時可使用，或者在正常情況下，不需要使用，只有出現災難時才使用。從技術的發展來看，越來越多地采用軟件的方式實現數據遠程復制。

3 容災恢復計劃的設計

單從技術上實現容災系統，是無法保證出現災難時，能夠快速有效地切換到容災平臺的，必須有與之相配套的容災恢復計劃(DRP Disaster Recovery Planning)，DRP是一系列用以保證災難處理過程中各種操作連續性和關鍵資源可用性的計劃文檔集合，明確定義了流程、組織、場景等，從而保證在災難發生后能及時采用一定的策略、遵循一定的過程和使用一定的技術迅速恢復信息系統和數據。DRP主要工作內容和目標為:

定義DRP適用范圍，說明能夠解決的問題和無法解決的問題;

設計完善高效的災難應急和指揮組織架構，明確日常災難恢復計劃的管理機構和管理方法;明確災難發生前、過程中和災備后不同角色的分工和責權;

定義呼叫樹，列述災難恢復相關人員和組織的聯絡方式;

定義容災級別，并確定應對不同災難場景的啟動恢復策略;

定義和描述技術恢復方法手段和步驟，包括回切;

定義后勤保障資源需求;

定義DRP的維護策略和流程，包括災難恢復計劃的周期性測試和演練等;

定義DRP相關的變更管理流程、日常巡檢管理;

形成DRP文檔，明確規定容災恢復時必須遵守的流程和操作。

在DRP實現過程中，涉及緊急響應、決策、技術恢復、收尾四個階段，每個階段都包括了需要解決的內容和操作的步驟，從發生事件的響應，對事件的判斷，評級并上報開始，到人員召集，詳細分析，決策，再到技術恢復、測試以及切換到容災平臺，再到完成后的評估和運行。整個流程是非常嚴密、環環相扣的，在執行過程中，還需要進行用戶協調和后勤保障。DRP流程如圖3所示。

對所有DRP流程包括的內容，都在DRP文檔中得以體現。最終形成的DRP文檔，是指導容災系統日常運維、檢查，出現故障時判斷、響應、評估、應急切換等的操作文檔，綜合了管理、技術、人員三個方面的內容，必須明確到每一步操作，并通過桌面演練、模擬演練、分項目技術演練、正式演練等方式，切實達到DRP文檔的可用性和準確性。DRP文檔至少需要有以下幾部分:

容災恢復預案管理總則，分容災中心和運行環境二部分;

容災中心環境檢查和測試手冊;

系統切換技術總綱;

正切技術手冊，根據不同場景需要采取的不同技術方案，如全系統切換和各單系統切換，包括主機切換操作手冊、網絡切換操作手冊、應用切換操作手冊;

回切技術手冊，與正切對應，包括主機、網絡、應用操作手冊;

用于進行容災現場的管理文檔;

各系統密碼表;

日常定期檢查和修改計劃。

在DRP設計時，用戶協調和后勤保障也是十分重要的部分，用戶協調直接關系到企業形象、法律、名譽、業務、財務、客戶關系等方面，在災難發生時統一對外發布信息;后勤保障也關系到DRP能否有效的執行，在人員到應急操作中心(EOC)的車輛保障、技術人員的食宿保障等方面起到關鍵作用。

4 容災的實踐

寧波港股份有限公司(以下簡稱“寧波港”)是國內第二大港，信息系統已成為寧波港生產經營的核心組成部分，特別是集裝箱碼頭，信息系統是支撐碼頭生產、控制作業流程的主要手段之一，24小時的業務連續性要求，對信息系統的可靠性提出了很高的要求。在此背景下，寧波港決定建立集裝箱生產系統的容災系統，并以集裝箱應急系統立項。寧波港集裝箱應急系統的主要目標是:

建立應用級容災系統;

建立一個統一的容災中心，為多個集裝箱碼頭提供容災保障;

RPO:數據同步達到秒級的，應用同步為一天，全系統切換的RTO為4小時，其中技術部分為1.5小時，單系統切換為1小時;

容災中心的數據庫處于打開狀態，可為其他應用提供實時的查詢、報表和ETL抽取等功能，實現業務分擔，減少對運行環境系統性能的影響;

開發高效的DRP，構建有效的容災機制。

以下以一個公司為例，展示寧波港的容災實現全貌，基于保密性，有關公司名稱和設備及系統等為粗線條描述。公司A的網絡數據中心設在公司管理樓，網絡匯聚到網絡數據中心，連接有線網絡和用于碼頭生產作業的2.4G和400M無線網絡，主機系統采用HP8600系列主機，集裝箱生產管理的主要系統有部署在HP8600主機上Oracle和WebSphere，基于WebSphere的CTOS、在Windows平臺上的Sparcs、Amtrix和MQ。容災中心與公司A相距約5公里，有廣域網相連。

最主要的場景是公司A的主機房出現故障，主機、網絡處于癱瘓狀態后，整個系統需要由容災中心接管信息系統，并保證碼頭繼續進行作業。技術選擇上分為主機、網絡、數據同步三塊。主機方面，容災中心選擇與公司A相同的主機系列HP8600，平時用于多個碼頭的數據和應用備份，當公司A出現故障、容災中心HP8600接管后，HP8600的CPU及內存資源進行動態調整，以滿足公司A的生產要求;基于Windows的應用，使用刀片服務器，安裝相對應的軟件和應用系統。網絡方面，對公司A的網絡進行改造，在公司A建立第二匯聚點，接入網絡數據中心的接入層交換機，也通過光纖接入第二匯聚點，平時，在這些交換機的端口上關閉與第二匯聚點的連通，容災系統開始后再開啟。第二匯聚再點單獨與容災中心通過光纖鏈路相聯，這條光纖平時用于數據和應用的同步，當公司A出現故障時，作為連接碼頭與容災中心的網絡。容災中心的主機、服務器及網絡設備與公司A的網絡數據中心規劃為同一IP網段。數據和應用同步分別采用DSG公司的Realsync和Filelsync二個產品完成，RealSync是邏輯級的數據復制技術，與硬件平臺無關，在運行環境和容災中心分別安裝Data Source端和Data Target端的Agent進程，源端的Agent進程對數據庫的日志進行監控，發現改變實時通過網絡傳送到目標端，完成對目標數據庫進行更新。Filesync通過定時比對源端和目標端的文件變化情況，完成文件同步。在設計中，容災中心的設備分成多個分區，以為不同公司的信息系統提供數據和應用的容災。容災系統的拓撲圖如圖4所示。

在技術上實現容災體系的同時，十分注重DRP開發，形成了容災中心和公司A對應的應急預案恢復總則、技術指揮綱要、分場景技術指揮總綱、網絡、系統、應用切換技術手冊等文檔，根據DRP的要求，組建了應急恢復管理團隊(DRMT)，明確EOC。在DRP中，詳細定義了應急恢復的總體流程和技術指揮總綱。總體流程明確了事件發生時故障分析及上報，總指揮召集技術經理初步評估災難損失，制定事件處理策略，技術經理通知DRMT到EOC、進行技術和環境檢查、分發DRP文檔、執行技術恢復、技術經理向總指揮匯報、總指揮宣告應急恢復成功、DRP歸檔及DRMT解散，恢復后的總結。技術指揮總綱詳細定義了每一步操作，圖5是其中一個場景的技術指揮總綱(保密性原因，以小圖表示)。

完成了DRP開發后，寧波港對DRP進行了多次的演練，從桌面演練到模擬演練再到正式演練，從淺及深，步步深入，通過演練不斷完善DRP及技術