吳光珍, 嚴躍寧, 曾梅芳
(第九〇九醫院(廈門大學附屬東南醫院), 福建, 漳州 363000)
第九〇九醫院(廈門大學附屬東南醫院)作為漳州市三級甲等綜合性醫院之一,每日平均門診量達4000余人次。醫院信息系統(HIS)數據庫伴隨著醫院醫療信息化建設的快速發展,圍繞其建設的系統和應用規模也在不斷增加。統一支付、預約掛號、微醫療、醫聯體、異地醫保等[1]系統的上線更是讓HIS系統支撐范圍由院內保障逐漸延伸到院外成為了整個醫院信息系統的心臟。但是在平時數據庫運維管理過程中難免需要對生產數據庫進行測試、調試或大規模查詢等操作,極易造成數據庫運行不穩定,臨床業務隨之出現波動進而導致業務陷入癱瘓。信息科為此制定了非常嚴格的數據庫運維管理準則和步驟,仍無法避免對生產數據庫形成干擾,數據庫宕機時有發生,勒索病毒肆虐更是讓數據庫險象環生。如何有力保障數據庫高可用性成為擺在信息管理人員面前的一道難題。
醫院數據庫是一套版本為10.2.0.5的4個節點ORACLE RAC集群數據庫,平均分布在2個機房2套刀片服務器上,通過SAN網絡連接到EMC VNX5500存儲上,2套存儲通過底層的MIRRORVIEW技術實現2個機房間的LUN級數據實時同步。數據庫架構如圖1所示。

圖1 連續性數據保護(CDP)實施前本院數據庫架構圖
1.2.1 測試庫的不足之處
為了保障生產數據庫的穩定,避免非必要動作對生產數據庫造成影響,現有架構一般是通過搭建測試數據庫來分流的[2]。當下得到一套測試數據庫主要的方案有以下幾種。
系統層:通過ORACLE自帶RMAN技術來恢復數據庫,作為數據庫傳統備份手段而被大量采用。但從備份數據恢復成測試庫,存在恢復時間長、技術難度高、異步等特點[3]。
網絡層:DataGuard是甲骨文推出的一種高可用性數據保護方案,在節點與備用節點間通過日志同步來保證數據的同步,實現數據庫快速切換和災難性恢復[4]。但是受制于版本(10.2.0.5)的原因,僅能作為數據庫備份的補充手段。
存儲層:HIS數據庫生產數據存儲卷通過底層MIRRORVIEW技術鏡像同步到同型號的存儲上,在需要時可以將同步手動斷開,將備份端存儲數據卷掛載到額外的服務器進行讀取。操作難度系數大、風險高。一般只適用于生產業務的數據應急恢復。
1.2.2 生產庫大規模統計查詢
數據庫管理實踐中對生產數據庫進行大規模的數據統計查詢是常見的,例如醫保檢查、藥品耗材統計、醫務統計等。時間急、任務趕、數據準確、耗時長是它的基本特色。該行為勢必造成生產數據庫的卡機,是生產數據庫最為忌諱的。
1.2.3 生產庫數據庫導入導出
醫院在運行過程中經常接收到來自不同單位的數據導入導出需求,特別是醫保全國統一編碼、績效考核、字典庫、病案ICD編碼、數據上報等。直接在生產庫進行極有可能對HIS數據庫正常運行造成影響。
1.2.4 生產庫意外宕機
目前比較主流的生產意外宕機接管方案是Oracle數據庫衛士DataGuard。這種方案在實踐中經常遇到生產庫與DataGurad之間數據不同步,導致無法完成接管動作。同時接管動作需要專業人員進行操作才能完成,稍不留神就會造成部分數據丟失,給數據庫帶來難以挽回損失的同時必然伴隨著造成業務的長時間停機。
1.2.5 勒索病毒
勒索病毒一旦加密生產數據庫后只能通過支付高昂的解密費用來恢復正常使用。傳統的備份方案諸如Rman、備份軟件產生的數據都在病毒侵襲的范圍之內,難逃病毒的魔掌。傳統解決思路是選擇異地異機備份來躲避病毒的攻擊,這些備份的弊端是都無法保持與主庫的實時同步。通過備份來恢復生產數據庫需要耗費大量的資源和人力才能完成,也勢必丟失一部分數據。長時間中斷勢必給醫院形象帶來極為不利的影響[5]。
通過對以上問題的綜合分析,在平時的工作中始終避不開對生產數據庫的訪問。生產數據庫是源頭,也是數據來源,需求和操作都圍繞其才能順利完成。導致生產數據庫不穩定的因素是多方面的。創建測試庫是一種辦法,但測試庫終究是生產數據庫過去某一時刻的形態,數據無法時刻與生產數據庫保持一致。加之測試庫隨著測試行為的發生,數據庫已經無法保證其準確性。為了保證統計查詢的準確性,信息科就必須重新生成測試庫來應對檢查。如此反復,工作量極為繁重。因此在生產庫出現意外宕機時寄希望于測試庫來挽救無異于天方夜譚。其自身的局限性導致對勒索病毒的應對也無從談起。亟須可替換方案來解決這個難題。
針對現有架構在實踐中出現的問題進行整理分析,實現HIS數據庫高可用性,有以下幾個方面的需求。
采用非傳統手段建立一套HIS生產數據庫鏡像庫。該系統能實時與HIS數據庫生產環境保持一致。必要時可以回滾到過去一段時間內任意時刻,滿足數據庫持續性保護的需求。
數據庫作為醫療業務流程運轉的核心,需要具有連續穩定的運行能力。作為一家三甲醫院,每天需要面對數以千計的患者,數據庫不穩定導致醫療業務長時間卡頓,影響患者的就診體驗,降低了醫院的公眾形象。
數據庫異機備份恢復或者存儲掛載都需要復雜冗長的操作步驟,甚至需要專業技術人員配合才能完成。即使有詳細操作步驟和豐富經驗在面臨緊急情況時也會捉襟見肘。為此形成一套簡單易得的穩定測試庫方案是當務之急[6]。將數據庫統計、測試、導出等操作分流到測試庫上,盡量減少對生產庫的干擾。
在管理過程中經常接到大規模查詢的需求,又都需要在短時間內完成。在白天正常工作時間進行此類動作勢必造成數據庫大面積的死鎖,造成大面積的業務卡頓。通過測試庫查詢面臨著數據不一致的問題。因此,快速有效且能與生產庫保持數據同步的測試庫是十分必要的。
在生產數據庫出現意外宕機且短時間又無法恢復的情況下,DBA既要保證生產環境的故障有利于后期分析和恢復又要保持全院業務持續進行。擁有與生產庫同等的計算存儲資源的容災端來臨時接管是最為快速有效合理的選擇。在生產環境得到恢復后又自動切換回原來的角色達到戰平兩用,使容災端存儲和計算資源都得到更為合理的利用。
為了滿足數據庫高可用性的需求,必須根據自身業務的特點、模式和未來的趨勢來規劃數據庫架構。鑒于醫院IT系統的特點,即采用的數據集中存放、集中處理的大集中模式存在一定弊端,如果一旦生產中心核心系統和集中存儲等重要系統或設備發生故障,將會影響HIS數據庫高可用性進而導致全院業務中斷。基于前期對數據庫穩定運行需求,在最大程度保留數據庫原有環境的條件下,形成一套召之即來戰平兩用的新型數據高可用架構[7],為此經過專家論證選型采用了易安信廠家(EMC)的VPLEX+RecoverPoint的組合。架構圖如圖2所示。

圖2 連續性數據保護(CDP)實施后本院數據庫環境結構圖
方案實施后利用EMC VPLEX來進行EMC存儲的數據雙活,即通過VPLEX Metro將兩套VNX5500組成一個鏡像組,從而保證兩套存儲之間互為備份,任何一臺存儲出現故障都不會導致業務停止或者數據丟失。
VPLEX提供存儲虛擬化、鏡像和拆封器的功能,快照、復制等特性由RecoverPoint實現。連續性數據保護持續抓取變化數據庫并將其保存到本地,保證了本地數據可以恢復到任何一個時間點而無數據丟失。CDP能夠在本地群集內的一個陣列或多個陣列中本地復制LUN。其流程如圖3所示,第一步應用服務器向LUN發送一個受RecoverPoint保護的寫請求;第二步VPLEX拆分器會截取這個寫請求,拆分器拆分了寫請求并將它同時發送到生產卷和RPA;當RPA收到寫請求時,第三步將確認信息發送回拆封器;第四步RPA將數據連同時間戳以及任何與該寫操作相應的應用、時間或用戶生成的標簽一起寫入本地日志卷;RPA成功地將數據存儲在日志卷之后,第五步再將他分發到CDP拷貝,在分發過程中保留原來的寫順序。

圖3 連續性數據保護(CDP)原理圖
CDP是一種連續捕捉和保護數據變化并將變化后的數據獨立于初始數據進行保護的方法,而且該方法可以實現過去任意一個時間點的數據恢復[8]。可以基于塊、文件或應用,并且為數量無限的可變恢復點提供精細的恢復對象。數據的改變受到連續的捕獲和跟蹤、所有的數據改變都存儲在異地機房、恢復點目標是任意的。恢復出來的數據可以支持修改或者寫入。
CDP技術是基于VPLEX+Recoverpoint的一種連續性數據保護解決方案,兩套EMC VNX5500分別存放于綜合樓和門診樓兩個機房,通過VPLEX Metro將存儲卷鏡像后形成分布式卷通過SAN交換機掛載生產數據庫使用,RecoverPoint(RPA)以旁路方式接入SAN網絡并注冊到VPLEX系統中(見圖4),將生產分布數據卷和備份存儲VNX5100的鏡像卷和日志卷(見圖5)同時掛載給RPA管理(見圖6),VPLEX通過自帶的拆封器(見圖7)將寫入IO拆封給分布式卷和RPA(見圖8),RPA通過實時監控并記錄整個業務系統的數據變換情況,將變換記錄捕獲拆分寫入I/O生產存儲VNX5500到第三套存儲VNX5100上。RecoverPoint對VPLEX拆分器發來的IO數據打上時間戳(見圖9)并記錄到IO日志卷中,根據IO日志生成任意時間點的數據。容災端服務器利用RecoverPoint提供的任意時間點的快照磁盤,將磁盤以映射的方式提供給容災端服務器使用,可以隨時按照任意時間戳提供一套跟生產數據庫完全一致的影子數據庫。在必要的時候可開啟容災服務器接管生產系統的業務,保障HIS數據庫的高可用性。

圖4 RECOVERPOINT注冊到vplex

圖5 CDP日志卷

圖6 分布式卷和備份卷一一對應

圖7 VPLEX拆分器

圖8 VPLEX拆封器拆分IO給生產數據卷和RPA
圖10是RecoverPoint處于持續保護狀態下的示意圖,左邊HIS_CDP代表容災端,右邊HIS代表生產端,生產端的存儲卷經RPA實時同步到備份端存儲VNX5100上,實時復制機制使得容災存儲與生產存儲的數據保持一致性和可用性,完成容災接管的基本條件,并記錄時間戳和日志保存在日志卷上。
3.3.1 容災卷啟用(test copy)
在發生誤刪除或者誤操作導致文件丟失時通過在RecoverPoint界面簡單的幾步操作就可以讓容災端服務器取得存儲VNX5100存儲的讀寫權限。而且存儲數據可以根據實際需要快照回滾到任意時間點,交由容災端服務器讀取找到所需文件,并將復制到生產服務器中。這種模式下容災端就相當于生產數據庫某個時刻的影子,跟生產數據庫數據完全一致,且可讀可寫,非常適合大規模統計查詢和數據導入導出,即可以保證數據準確又能測試效果與生產庫完全一致,保證了測試有效性[9]。容災端隨時可以災難演練校驗,數據庫腳本校驗,保證備份數據的可用性,規避直接在生產庫進行可能發生的數據庫宕機。
3.3.2 全庫恢復
可以通過Recover Product實現生產庫的回滾回退,這些在平時需要專業人員耗費大量時間才能完成的操作在RecoverPoint上僅僅通過簡單的鼠標點擊就可以完成。
3.3.3 故障切換(failover)
容災端可以應急接管任意時間點的數據庫狀態。當生產庫服務器意外宕機,可以隨時failover到容災端且保持原有生產數據庫的數據,無縫銜接完成數據庫割接,保證數據庫高可用性。信息管理人員從容修復生產庫,不用擔心業務中斷。認真仔細梳理生產數據庫故障發生的原因,徹底完成修復工作以防止故障的再次發生[10]。當故障修復后再次進行角色互換回遷到原生產庫,由原生產庫繼續對外提供服務。角色自由切換、方便靈活、操作簡單。
市面上大部分CDP解決方案需要在生產數據庫安裝代理客戶端或者將備份卷掛載到生產數據庫實現連續性數據保護,兩者都需要對生產環境進行修改并消耗主機的資源來達到效果。這對于已經上線的數據庫是難以接受的,實施過程和運行中都可能會對生產環境造成干擾,不利于數據庫穩定運行。架構底層通過存儲網絡拆分方式完成,免代理、免安裝、免操作,真正意義上對生產數據庫架構實現了無感升級。
系統可以在保持生產數據庫正常運行的情況下通過容災備份服務器對數據鏡像卷進行手動進行數據庫不完全恢復。該數據庫可讀可寫,用戶可根據實際需求對任意時間點的數據進行掛載,恢復數據、日志校驗、文件驗證、服務驗證、數據庫腳本驗證,免于在生產數據庫運行時可能產生的風險[11]。
在生產數據庫出現故障的時候可以手動啟動容災備份服務器對同步數據卷進行掛載臨時接管生產數據庫業務對外提供服務,實現零數據丟失和故障期間業務持續性,信息科有充足的時間對生產數據庫進行故障分析和定位,避免因倉促行事造成不可挽回的損失。生產數據庫故障恢復后可通過數據回寫,由生產數據庫繼續提供服務。靈活機動給數據庫管理工作提供了更多的選擇。
HIS數據庫高可用性對信息管理人員提出了近乎苛刻的要求,醫院將CDP技術延伸到HIS數據庫高可用性應用中,通過與實際需求有效結合充分發揮CDP技術的長處全面提升了醫院業務信息系統的高可用性,極大地降低非必要動作對生產庫帶來的風險,使醫院信息系統能真正進入安全可靠的狀態中。該架構不足之處在于容災端在絕大多數時間處于待用狀態,形成了一定程度上的資源浪費。后續容災端將嘗試在待用狀態下直接用于統計查詢甚至支持生產和容災雙寫,推動整個架構的持續升級,提供更為完善的功能,推動醫院基礎信息化建設,為醫院信息化建設核心系統注入能量,使圍繞HIS展開的軟件系統得到穩定的信息支撐,推進線上線下、區域信息的互聯互通,為互聯網醫院平臺功能建設打好堅實的基礎條件,充分發揮互聯網醫院的價值。