連續性業務系統中容災備份系統的建設

摘要：對于業務連續性要求較高的系統，采用容災系統實現數據保護和信息系統業務連續性保護已顯得越來越重要。文章介紹了杭州市勞動信息系統的業務連續性特點以及建設容災備份系統的背景；提出了容災備份系統建設的具體目標；通過對當前有關容災備份系統建設的技術分析，提出了杭州市勞動信息系統容災備份系統建設方案；分析了方案的局限性，并對系統進一步發揮作用提出了建議。

關鍵詞：業務連續性；容災系統；RTO(Recovery Time Object)；RPO(Recovery Point Object)

0 引言

信息系統在當今生產、生活中起著越來越重要的作用。如何保護信息系統的正常健康地運行是每一個有效運行的信息系統都要面對的重大課題。尤其對每天24小時、每周7個自然日、每年365天連續不間斷實時運行的系統，更需要有措施來應對災難性事件對信息系統特別是數據信息的毀滅性破壞，必須認真考慮和提出信息數據的保護方法和保持信息系統業務連續性工作的切實可行的解決方案。對于實時性要求不高的信息系統，主要是進行數據保護如數據備份與異地保存；對于業務連續性要求較高的系統，要采用容災系統進行業務連續性保護。在勞動保障行業，隨著信息化深入到社會保障業務經辦、勞動就業、行政審批等各個方面，信息系統成為支撐生產、管理正常進行的基礎。醫療保險業務更是對信息系統的實時性、可靠性提出了非常高的要求。杭州市社會保障管理信息系統是勞動保障信息系統的核心子系統，關系到所有市民的切身利益，是實時準金融系統，對數據安全和業務連續都有很高的要求。為此我們提出建設一個杭州市社會保障管理信息系統應用級容災系統以減小災難和重大事故造成的數據損失和業務影響，切實提高應對突發災難的能力。下面結合杭州市勞動保障容災系統建設，談談容災系統建設的目標確定、系統建設的具體方案和項目建設中的一些體會。

1 容災系統建設的目標

首先，確定容災系統建設的目標是項目建設的關鍵步驟，容災系統的建設目標對系統方案的確定和具體的技術實現方式以及項目建成后的管理、維護都起決定性的作用，系統建設初期一定要充分論證。從技術上看，衡量容災系統有兩個主要指標：RPO(Recovery Point Object)和RTO(Recovery TimeObject)，其中RPO代表了當災難發生時允許丟失的數據量，而RTO則代表了系統恢復的時間。RPO與RTO越小，系統的可用性就越高，當然用戶需要的投資也越大。各種應用對RTO要求不同。業務繁忙的關鍵業務需要較小的RTO，如果系統恢復時間過長就會影響到業務運行；而許多業務系統的RTO較長，如果一些較小災難發生在非業務運行時間，那么對業務連續性幾乎不會造成任何影響。因此，應當根據項目資金的投入，業務特點與業務性質，確定恰當的RPO和RTO目標。災難備份本身可分為數據級備份與應用級備份兩大類。數據級備份就是數據的遠程容災，當主站點發生災難時，備份站點仍然保存著數據的副本，從而達到保護數據的目的。應用級備份則是為了實現完全的應用容災，一旦主站點發生災難，將由備份站點接管整個應用系統，繼續對外提供服務，它不僅僅保存數據，還要保證業務系統的連續運行即業務連續性。應用級容災系統涉及的技術和管理問題很復雜，一般來說，資金投入也較大。只有業務需求迫切，系統規模較大，其他技術手段無法保證業務連續性時才需要采用。由于勞動保障業務數據記錄市民的養老、醫療、就業信息，數據涉及市民切身利益，業務數據量大，生產、變更極為頻繁，在任何條件下都不允許數據的丟失。勞動保障業務系統是7×24不間斷系統，長時間的系統中斷將引起較大的社會問題。通過對社會影響、業務影響、資金投入、技術方案的比較，確定杭州市勞動保障容災備份系統建設的目標是：為勞動保障局信息系統的社會保障業務提供應用級災備，當社會保障業務的生產系統發生導致應用系統中斷的重大災難時，系統能夠在半小時之內迅速切換到災備系統運行，保持社會保障業務的連續進行。整個切換過程，需保障應用系統數據只有少量或者“零”丟失，從生產中心切換到災備系統的時間不能大于30分鐘；當生產中心恢復正常，完成了生產系統所有軟硬件的安裝、配置和數據同步后，以相同的數據與技術指標恢復運行，即RPO為“零”，RTO為30分鐘切換回生產系統。

2 應用級容災系統建設技術分析

應用級容災系統對應于生產系統一般由數據復制與存儲系統、應用系統和網絡系統組成。系統結構如圖1所示。

在整個系統中，數據是整個應用的生命，數據保護是系統建設的根本目的，所以采用何種技術進行遠程數據復制是系統建設的重點，容災存儲系統建設以及如何處理它與生產存儲系統的關系是關鍵。各存儲設備生產廠家在其高端存儲服務器中提供了各自的容災解決方案，如IBM公司的PPRC、IIDS公司的True Copy、EMC公司的SRDF等，另外還有利用虛擬存儲等方式的異構存儲容災解決方案，VARITAS的軟件解決方案，以及利用數據庫功能(如ORACLE公司的DataGuard)實現容災備份的方案。具體的解決方案要根據生產系統的設備、應用、數據量、通訊、容災與生產系統的距離、RPO和RTO設定的目標等多個方面綜合考慮，并充分了解各產品及方案實現的技術細節才能確定。數據復制方案的不當選擇可能會導致項目無法實施或失敗。在我們的方案中除考慮上述幾個方面的因素外，還特別考慮到盡量降低項目風險，盡量減小項目建設對生產系統的影響和便于系統運維等因素，確定采用同構存儲系統的實時數據復制即在SAN環境下的I-IDS異步TrueCopy技術。在實施過程中還要充分考慮數據復制對生產系統的性能影響，復制鏈路故障對生產系統的影響等方面，細化與之相關的設備配置，避免因容災系統引起生產系統的故障或停頓。如在HDS的TrueCopy方案中有同步復制和異步復制兩種方式，分別采用bitmap(位圖)和timestamp(時間戳)兩種機制實現。異步復制對線路帶寬的要求低，從而可以實現遠距離傳輸，對生產系統的性能影響小，但可能有少量的數據丟失；而同步復制由于其“寫確認”機制對線路帶寬要求高，不利于遠距離傳輸，對生產系統性能影響大，但能保證數據的“零”丟失，即真正的RPO=0。另外，這兩種方式在數據庫支持上也存在區別。在系統平臺方面，我們采用同構系統，但采用了不同操作系統版本，這樣要求我們在版本兼容性方面做好充分的測試，對應用服務相關軟件進行重新編譯、測試，以確保應用切換的成功。

應用級容災的網絡系統也是項目建設中的重要部分，當災難發生時，我們要求網絡系統能根據業務要求，部分或完全接替生產系統運行，保證應用的連續性。網絡系統如圖2所示。 在網絡系統中怎樣進行快捷有效的網絡切換是網絡系統中的主要問題。在生產中心和容災中心的局域網絡中系統的切換必須解決服務器TP的切換或解析的問題。如果系統中建有完整的域名系統且所有應用都基于域名系統運行，可采用域名解析的方法實現應用服務IP切換的問題，否則可采用手工切換。在一些方案中采用群集技術進行IP切換，這種方法在實際的關鍵系統運行中可靠性和可控性有一定的問題。網絡系統的另一個問題是接入網路切換問題，在我們的系統中采用了BGP協議實現生產系統的主、備接入線路與災備接入線路的按序自動切換。同時，我們在制定災備網絡方案時，將生產網絡與災備網絡作為一個整體考慮，這有效地降低了網絡的復雜性并便于管理。

3 容災系統的局限性

容災系統在災難發生時能起到很大的作用，但根據采用的技術不同，也存在不同的局限性。如我們所采用的容災方式至少有如下兩點不足：第一，容災系統無法處理數據庫本身損壞或被人為破壞。由于生產數據被實時復制到容災系統，所以損壞后的數據庫數據也將立即存在于容災系統。第二，無法在所有情況下做到絕對的數據零丟失。當突發的災難和大面積設備故障發生時，在數據庫緩存中的數據還在服務器的內存中，并沒有寫入磁盤陣列，因而無法傳送至容災備份中心，將會導致數據丟失。因此，容災系統并不能代替傳統的數據備份，兩者在功能上具有互補性，另一方面，業務管理等非技術手段也是彌補技術局限的方法。在通常的容災系統建設中，災備系統的處理能力會小于生產系統，災難發生時，也不可能完全接管所有生產業務，只能保證其中重要業務的連續運行。

對于應用級容災系統，系統運維和定期的災備切換演練與系統建設同等重要，只有在良好的運維狀況下，才能保證容災系統隨時有效，只有制定正確的災備切換方案并定期進行切換演練，才能保證災難發生時能有條不紊地進行正確的切換，真正達到建設項目的目的。杭州市勞動保障信息系統容災備份系統在建成試運行兩個月后成功組織了災備切換演練，達到了演練的預期效果。

4 結束語

本文總結了容災備份系統建設中的一些經驗，闡述了系統規劃建設的方法，對系統建設中應該注意的問題和容災備份系統的局限性也進行了分析，希望為相關的系統建設提供有益的借鑒。