醫院災備建設選型分析

李 征

（寧波市第九醫院，浙江 寧波 315020）

醫院災備建設選型分析

李 征

（寧波市第九醫院，浙江 寧波 315020）

筆者根據醫院核心系統HIS的災備選型和分析，闡述當前業界的主流的容災模型的優缺點，然后根據筆者醫院的信息化規劃和醫院的后續業務需要進行容災架構選型。

醫院；HIS；容災模型；容災架構

寧波第九人民醫院經過幾年的發展，已經建設為現代化的綜合性醫院，為實現醫院管理的科學化、現代化、數字化，與國際、國內信息化建設的新技術接軌，適應現代化醫院的醫療、科研、教育和管理要求，醫院建立起的信息系統（HIS）主要以一體化的臨床系統、LIS系統、PACS系統、EIS系統、PIS系統等為基礎，實現數據全面共享，共同形成全面的醫院信息管理系統。龐大的系統必然產生海量數據，對于軟件系統而言數據就是根本，任何操作、分析、結算等等都從數據庫中提取。從某種意義上說，數據安全成為現代醫院信息系統安全的重中之重。一旦數據丟失，對任何一家醫院來說都會產生重大影響。

1　數據安全影響

根據長期的一線運維經驗，對應用和數據安全的影響主要有以下幾種情況。

1.1系統硬件故障

如系統磁盤或數據盤的損壞將導致數據不能訪問，進而可能導致應用進程終止或系統停機，甚至系統不能重啟動。網卡的損壞會使終端用戶無法訪問系統服務。CPU或內存的失效則會導致系統死機。

1.2應用程序或操作系統出錯

由于操作系統或應用程序中存在BUG，當碰到某種事件符合BUG的激發條件時，應用程序會非正常終止或系統崩潰。

1.3人為錯誤

一些人工的誤操作，如刪除系統或應用文件，終止系統或應用服務進程，升級覆蓋安裝等，也會導致數據丟失或系統服務無法訪問。

1.4電腦病毒/黑客入侵

由于目前大多數計算機系統均連接在網絡上，若缺少有效的防范機制，很容易遭受病毒感染或黑客入侵，輕者數據被損壞，重者系統癱瘓。

1.5自然災害

由于一些意外的不可抗拒的因素，如雷擊、火災、洪災等導致的計算機系統破壞，會使一般系統的恢復非常困難且耗時，導致業務系統長時間中斷（通過容災系統來解決）。

2　主流災備方案分析

筆者根據本院的實際情況，考察了以下幾種災備模式，同時根據本院實際的業務情況、工程師配置情況和醫院后續發展的需求等綜合進行總結和歸納。

2.1基于SAN網絡的數據容災

基于SAN網絡的容災當前最常用的方式是存儲虛擬化與遠程復制相結合的災備架構，在前端應用服務器與后端存儲系統之間的存儲區域網絡（SAN），加入一層存儲網關，前端連接服務器主機，后端連接存儲設備。它的角色就好像是存儲網絡中的跨海大橋，所有的數據和I/O都交由它來控制管理、分發。當然，現在的存儲網關即可進行帶內控制，也兼具out-bound控制方式，對于I/O流量進行旁路監控和分流，實現本異地數據復制。由于數據復制是通過存儲網關來執行，應用服務器只需執行代理程序，相對于基于主機層的技術，它的性能影響更低。另外，通過存儲網關的虛擬化技術，可整合前端異構平臺的服務器和后端不同品牌的存儲設備，本地端和災備端的設備無須成對配置，用戶可根據RTO和RPO，在遠端建立完整的熱備份中心。

測試缺點：災備的數據如果要求是同步復制的，那么不同存儲間的性能影響較大，會按照差的性能的存儲運行，對ISCSI等網絡存儲整合較差。災備的數據無法實時可查看，對災備數據的完整性和安全性無法進行考究，只有在拉起的時候才能進行數據驗證，操作較為復雜，同時，邏輯錯誤發生后，部分情況下恢復模式恢復的數據恢復丟失量較大，如單表誤刪等，均需要全盤恢復。另外，現場測試對維護人員的技術要求和運維規范性要求極高。

2.2基于主機的容災技術

一般是通過復制主機邏輯卷的方式實現。災備管理軟件將主機端系統卷上每次I/O的操作數據發生變化的數據塊實時（或者準實時、或者延時）復制到災備節點的相應位置上，實現遠程兩個卷之間的數據同步（或準同步）。主、備節點之間通常需要配置相應的IP通道。根據數據的更新頻度、帶寬條件和質量等因素，可將數據復制設置成同步、準同步或者定期同步等方式（或自動適應）。另外，有一些基于主機的復制軟件只能夠實現文件級別的復制，雖然缺乏對裸設備卷的支持，但是融入了CDP的功能。遠端災備主機不但能夠實現容災切換，而且可支持將生產系統恢復到任意的歷史事件點，相對的對大文件的復制效率較低。

基于主機的遠程數據復制會增加各節點主機的一些處理性能需求，在主機性能和通信帶寬的要求得到滿足時，遠程復制效率和數據一致性可得到保證。基于主機的遠程數據復制一般與數據類型、物理存儲系統設備無關，與操作系統結合緊密，有較好的可管理性，也便于主、備系統的擴充和發展；同時，也可方便地做到多對一或者一對多的遠程復制；對存儲硬件設備的選擇也比較靈活。

測試缺點：當I/O或需要復制的文件變化量過大時，會在源端生成較大的緩存空間，部分軟件無緩存空間限定的時候會直接寫滿空間，直接導致源端宕機。如重建數據庫縮影，數據庫日志收縮等環境下。無法斷點續傳或者斷點續傳條件苛刻，由于CDP等卷復制無法校驗數據復制的具體情況，當主機端重啟、網絡中斷、災備端重啟或Agent重啟等情況下，無法進行數據的斷點續傳，要么需要進行全數據校驗，要么需要進行重新全同步，對業務的影響較大。卷復制等技術同樣存在著備機無法查詢的情況，需要對備機數據和應用可用性進行校驗時，必須要中斷復制，而中斷復制重啟災備系統后又需要進行全量同步，故而災備的可用性較低，適合用于實時備份恢復。最大的缺點是絕大多數的CDP復制軟件都無法支持Oracle RAC的同步復制，在Oracle環境中無法適用。

2.3基于數據庫的數據容災

大部分的數據庫軟件廠商提供了基于數據庫復制事務日志的容災技術，基于數據庫的復制技術傳輸的是SQL指令或重作日志文件，在新數據沒有被業務系統寫入存儲子系統前，就被指定發送到異地災備中心的數據庫進行相關交易處理。數據庫復制技術采用的是異步傳輸方式，通過IP網絡傳輸，支持一個生產系統向多個備份系統的數據庫進行復制的要求，或多個生產系統向一個備份系統復制的要求。

這里由于本院的信息系統核心數據庫為Oracle數據庫，所以在這里以Oracle數據的復制技術為例，Oracle數據庫層面的數據復制，業界大部分以Data Guard的機制做的，還有一部分是按照Streams模式做的。

2.4Data Guard模式的容災過程

Data Guard主要提供兩種服務，分別為Redo傳輸服務和Redo應用服務。傳輸服務即把Primay端的Redo日志傳輸到一個或多個Standby目的地；應用服務即在Standby端應用從Primay端傳輸過來的Redo日志。

Data Guard的日志傳輸模式有同步和異步等多種模式，異步模式采用的是使用ARCn傳輸Redo日志：Primay段ARC0一旦完成日志切換，ARC1就將新生成的歸檔日志傳輸到Standby端；Standby端由RFS進程接受日志，如果配置了Standby Redo Log，記錄至Standby Redo Log，等Standby Redo Log做Log Switch形成歸檔日志，再應用歸檔日志做恢復；如果沒有配置Standby Redo Log，RFS進程接收到日志后，放到Standby端歸檔目錄下，Standby再應用歸檔日志做恢復。

同步或準同步模式采用LGWR傳輸Redo日志：一旦Primary有Redo日志產生，LGWR將觸發LNSn進程傳輸Redo只Standby Redo Log；網絡傳輸模式可選擇Sync或Async，Sync是指當Primary提交時，必須得等Redo傳輸至Standby成功后，才能返回。Async是指Primary提交是否成功和日志是否傳輸成功沒有關系，這樣對Primary的性能影響最小；Standby端的RFS進程把Redo寫入Standby Redo Log，如果開啟了實時應用，就將Redo應用至Standby數據庫，如果沒有開啟實時應用，等Standby Redo Log歸檔后再應用到Standby數據庫。

從以上可看出在Data Guard容災過程中，備份中心的數據庫是否處于打開狀態跟Redo日志的同步模式有關，筆者測試了2種類型的產品，各有優缺點，準實時同步的情況下均存在有幾秒數據延遲情況，對邏輯錯誤的防護能力較低，測試時主機端邏輯錯誤導致數據庫無法啟動，災備端數據庫也無法啟動。

2.5Streams模式的容災過程

Streams災備系統通過分析Oracle Redo Log獲得實時交易信息，完成Schema或Table級別的數據復制。區別于早期的日志分析技術，Streams對日志的整合和傳輸以交易為單位，在擁有高性能的同時還能更好的保證數據傳輸的一致性和完整性。對生產數據庫也不會增加負載。

Streams從Oracle Redo Logs里面獲取所有的數據庫改變信息。通過對信息的分析整合，Streams將完整的交易信息復制到目的端。

Streams不是等待Oracle Redo Log文件寫滿之后再處理，而是隨時讀取其數據塊內容，間隔時間可用參數指定，一般是秒級。Streams也不會復制Oracle Redo Log的全部內容到目的端數據庫，除指定復制對象（數據表）相關的DML/DDL操作之外，其他的信息將丟棄處理。

Streams的機制需要打開數據庫的Supplemental Logging 和Force Logging參數以便Streams能獲取完整的數據信息。

置于裸設備或文件系統中的Oracle Redo Log均可被Streams正常讀取。如果將Redo Log保存在ASM（一種新的Oracle存儲格式）中，則需要在裸設備或文件系統上手動創建一組與原有日志同步的Redo Log Member，供Streams復制使用。

Oracle有兩種類型的日志：在線日志和歸檔日志。一般情況下，Streams從一組在線日志讀取信息，因此，不要求Oracle數據庫必須打開歸檔日志。但在某些特殊情況下，Online Redo Log沒來得及分析就被覆蓋，此時，如果Oracle是歸檔模式，則Streams將從歸檔日志讀取需要的信息。

Streams支持兩種級別的復制，用戶（Schema）級復制和表級復制。用戶級復制表示源端數據庫指定用戶（Schema）下的所有表、視圖、索引、過程、函數、包、序列等數據對象全部復制到目標端數據庫指定的用戶下；表級復制表示源端數據庫指定用戶（Schema）下的單個表復制到目標端數據庫指定用戶下的單個表。

在使用Streams時，用戶通過編輯配置文件指定源端和目的端復制對象的映射關系，包括源端對象名，目的端對象名，目的主機編號等。源端和目的端對象名稱可不同，但結構必須一致。軟件運行過程中，復制對象的映射參數會駐留內存，Streams通過日志分析過濾，只處理指定復制對象有關的交易，其他用戶或表的操作信息則被丟棄。

因此，Streams數據庫容災技術屬于熱容災方式，主備機均在線可用。Streams數據庫容災技術與存儲子系統的類型、業務系統服務器的平臺無關，與數據庫的版本有一定關系，Streams數據庫容災解決方案有較好的靈活性。可實現跨操作系統平臺數據復制、跨數據庫平臺數據復制，同時可提供上層BI數據分析使用。

由于復制的目的端數據庫始終處于打開狀態，因此，當生產數據庫遇到計劃內或非計劃停機時，Streams的災備端能夠支持前端應用程序快速、無縫的切換到災備數據庫。與其他基于磁盤或文件系統的物理復制技術相比，不但省略了漫長的數據庫Recovery和啟動時間，而且能夠保證100%的切換成功率。

測試缺點：缺少全系統備份模塊，業務恢復需要手動搭建業務系統，搭建好后才能進行數據反向同步復制來恢復。

3　結 語

根據系統的測試，最后選擇了基于Oracle Streams架構的災備系統作為HIS數據安全的建設平臺。當然，數據庫容災技術只能作為數據庫應用的容災解決方案，如果需要其他非結構數據的容災，還需要其他容災技術作為補充。如CDP復制、事務日志復制等災備平臺和普通備份平臺多維解決方案于一體的綜合應用安全架構體系，充分保障了數據和業務的分級災備和存儲，全方位保障了結構化數據和非結構化數據的安全。

10.3969/j.issn.1673 - 0194.2015.20.120

TP309.3

A

1673-0194（2015）20-0154-02

2015-08-27