醫(yī)院災(zāi)備建設(shè)選型分析

李 征

（寧波市第九醫(yī)院，浙江 寧波 315020）

醫(yī)院災(zāi)備建設(shè)選型分析

李 征

（寧波市第九醫(yī)院，浙江 寧波 315020）

筆者根據(jù)醫(yī)院核心系統(tǒng)HIS的災(zāi)備選型和分析，闡述當(dāng)前業(yè)界的主流的容災(zāi)模型的優(yōu)缺點(diǎn)，然后根據(jù)筆者醫(yī)院的信息化規(guī)劃和醫(yī)院的后續(xù)業(yè)務(wù)需要進(jìn)行容災(zāi)架構(gòu)選型。

醫(yī)院；HIS；容災(zāi)模型；容災(zāi)架構(gòu)

寧波第九人民醫(yī)院經(jīng)過(guò)幾年的發(fā)展，已經(jīng)建設(shè)為現(xiàn)代化的綜合性醫(yī)院，為實(shí)現(xiàn)醫(yī)院管理的科學(xué)化、現(xiàn)代化、數(shù)字化，與國(guó)際、國(guó)內(nèi)信息化建設(shè)的新技術(shù)接軌，適應(yīng)現(xiàn)代化醫(yī)院的醫(yī)療、科研、教育和管理要求，醫(yī)院建立起的信息系統(tǒng)（HIS）主要以一體化的臨床系統(tǒng)、LIS系統(tǒng)、PACS系統(tǒng)、EIS系統(tǒng)、PIS系統(tǒng)等為基礎(chǔ)，實(shí)現(xiàn)數(shù)據(jù)全面共享，共同形成全面的醫(yī)院信息管理系統(tǒng)。龐大的系統(tǒng)必然產(chǎn)生海量數(shù)據(jù)，對(duì)于軟件系統(tǒng)而言數(shù)據(jù)就是根本，任何操作、分析、結(jié)算等等都從數(shù)據(jù)庫(kù)中提取。從某種意義上說(shuō)，數(shù)據(jù)安全成為現(xiàn)代醫(yī)院信息系統(tǒng)安全的重中之重。一旦數(shù)據(jù)丟失，對(duì)任何一家醫(yī)院來(lái)說(shuō)都會(huì)產(chǎn)生重大影響。

1　數(shù)據(jù)安全影響

根據(jù)長(zhǎng)期的一線運(yùn)維經(jīng)驗(yàn)，對(duì)應(yīng)用和數(shù)據(jù)安全的影響主要有以下幾種情況。

1.1系統(tǒng)硬件故障

如系統(tǒng)磁盤或數(shù)據(jù)盤的損壞將導(dǎo)致數(shù)據(jù)不能訪問(wèn)，進(jìn)而可能導(dǎo)致應(yīng)用進(jìn)程終止或系統(tǒng)停機(jī)，甚至系統(tǒng)不能重啟動(dòng)。網(wǎng)卡的損壞會(huì)使終端用戶無(wú)法訪問(wèn)系統(tǒng)服務(wù)。CPU或內(nèi)存的失效則會(huì)導(dǎo)致系統(tǒng)死機(jī)。

1.2應(yīng)用程序或操作系統(tǒng)出錯(cuò)

由于操作系統(tǒng)或應(yīng)用程序中存在BUG，當(dāng)碰到某種事件符合BUG的激發(fā)條件時(shí)，應(yīng)用程序會(huì)非正常終止或系統(tǒng)崩潰。

1.3人為錯(cuò)誤

一些人工的誤操作，如刪除系統(tǒng)或應(yīng)用文件，終止系統(tǒng)或應(yīng)用服務(wù)進(jìn)程，升級(jí)覆蓋安裝等，也會(huì)導(dǎo)致數(shù)據(jù)丟失或系統(tǒng)服務(wù)無(wú)法訪問(wèn)。

1.4電腦病毒/黑客入侵

由于目前大多數(shù)計(jì)算機(jī)系統(tǒng)均連接在網(wǎng)絡(luò)上，若缺少有效的防范機(jī)制，很容易遭受病毒感染或黑客入侵，輕者數(shù)據(jù)被損壞，重者系統(tǒng)癱瘓。

1.5自然災(zāi)害

由于一些意外的不可抗拒的因素，如雷擊、火災(zāi)、洪災(zāi)等導(dǎo)致的計(jì)算機(jī)系統(tǒng)破壞，會(huì)使一般系統(tǒng)的恢復(fù)非常困難且耗時(shí)，導(dǎo)致業(yè)務(wù)系統(tǒng)長(zhǎng)時(shí)間中斷（通過(guò)容災(zāi)系統(tǒng)來(lái)解決）。

2　主流災(zāi)備方案分析

筆者根據(jù)本院的實(shí)際情況，考察了以下幾種災(zāi)備模式，同時(shí)根據(jù)本院實(shí)際的業(yè)務(wù)情況、工程師配置情況和醫(yī)院后續(xù)發(fā)展的需求等綜合進(jìn)行總結(jié)和歸納。

2.1基于SAN網(wǎng)絡(luò)的數(shù)據(jù)容災(zāi)

基于SAN網(wǎng)絡(luò)的容災(zāi)當(dāng)前最常用的方式是存儲(chǔ)虛擬化與遠(yuǎn)程復(fù)制相結(jié)合的災(zāi)備架構(gòu)，在前端應(yīng)用服務(wù)器與后端存儲(chǔ)系統(tǒng)之間的存儲(chǔ)區(qū)域網(wǎng)絡(luò)（SAN），加入一層存儲(chǔ)網(wǎng)關(guān)，前端連接服務(wù)器主機(jī)，后端連接存儲(chǔ)設(shè)備。它的角色就好像是存儲(chǔ)網(wǎng)絡(luò)中的跨海大橋，所有的數(shù)據(jù)和I/O都交由它來(lái)控制管理、分發(fā)。當(dāng)然，現(xiàn)在的存儲(chǔ)網(wǎng)關(guān)即可進(jìn)行帶內(nèi)控制，也兼具out-bound控制方式，對(duì)于I/O流量進(jìn)行旁路監(jiān)控和分流，實(shí)現(xiàn)本異地?cái)?shù)據(jù)復(fù)制。由于數(shù)據(jù)復(fù)制是通過(guò)存儲(chǔ)網(wǎng)關(guān)來(lái)執(zhí)行，應(yīng)用服務(wù)器只需執(zhí)行代理程序，相對(duì)于基于主機(jī)層的技術(shù)，它的性能影響更低。另外，通過(guò)存儲(chǔ)網(wǎng)關(guān)的虛擬化技術(shù)，可整合前端異構(gòu)平臺(tái)的服務(wù)器和后端不同品牌的存儲(chǔ)設(shè)備，本地端和災(zāi)備端的設(shè)備無(wú)須成對(duì)配置，用戶可根據(jù)RTO和RPO，在遠(yuǎn)端建立完整的熱備份中心。

測(cè)試缺點(diǎn)：災(zāi)備的數(shù)據(jù)如果要求是同步復(fù)制的，那么不同存儲(chǔ)間的性能影響較大，會(huì)按照差的性能的存儲(chǔ)運(yùn)行，對(duì)ISCSI等網(wǎng)絡(luò)存儲(chǔ)整合較差。災(zāi)備的數(shù)據(jù)無(wú)法實(shí)時(shí)可查看，對(duì)災(zāi)備數(shù)據(jù)的完整性和安全性無(wú)法進(jìn)行考究，只有在拉起的時(shí)候才能進(jìn)行數(shù)據(jù)驗(yàn)證，操作較為復(fù)雜，同時(shí)，邏輯錯(cuò)誤發(fā)生后，部分情況下恢復(fù)模式恢復(fù)的數(shù)據(jù)恢復(fù)丟失量較大，如單表誤刪等，均需要全盤恢復(fù)。另外，現(xiàn)場(chǎng)測(cè)試對(duì)維護(hù)人員的技術(shù)要求和運(yùn)維規(guī)范性要求極高。

2.2基于主機(jī)的容災(zāi)技術(shù)

一般是通過(guò)復(fù)制主機(jī)邏輯卷的方式實(shí)現(xiàn)。災(zāi)備管理軟件將主機(jī)端系統(tǒng)卷上每次I/O的操作數(shù)據(jù)發(fā)生變化的數(shù)據(jù)塊實(shí)時(shí)（或者準(zhǔn)實(shí)時(shí)、或者延時(shí)）復(fù)制到災(zāi)備節(jié)點(diǎn)的相應(yīng)位置上，實(shí)現(xiàn)遠(yuǎn)程兩個(gè)卷之間的數(shù)據(jù)同步（或準(zhǔn)同步）。主、備節(jié)點(diǎn)之間通常需要配置相應(yīng)的IP通道。根據(jù)數(shù)據(jù)的更新頻度、帶寬條件和質(zhì)量等因素，可將數(shù)據(jù)復(fù)制設(shè)置成同步、準(zhǔn)同步或者定期同步等方式（或自動(dòng)適應(yīng)）。另外，有一些基于主機(jī)的復(fù)制軟件只能夠?qū)崿F(xiàn)文件級(jí)別的復(fù)制，雖然缺乏對(duì)裸設(shè)備卷的支持，但是融入了CDP的功能。遠(yuǎn)端災(zāi)備主機(jī)不但能夠?qū)崿F(xiàn)容災(zāi)切換，而且可支持將生產(chǎn)系統(tǒng)恢復(fù)到任意的歷史事件點(diǎn)，相對(duì)的對(duì)大文件的復(fù)制效率較低。

基于主機(jī)的遠(yuǎn)程數(shù)據(jù)復(fù)制會(huì)增加各節(jié)點(diǎn)主機(jī)的一些處理性能需求，在主機(jī)性能和通信帶寬的要求得到滿足時(shí)，遠(yuǎn)程復(fù)制效率和數(shù)據(jù)一致性可得到保證?；谥鳈C(jī)的遠(yuǎn)程數(shù)據(jù)復(fù)制一般與數(shù)據(jù)類型、物理存儲(chǔ)系統(tǒng)設(shè)備無(wú)關(guān)，與操作系統(tǒng)結(jié)合緊密，有較好的可管理性，也便于主、備系統(tǒng)的擴(kuò)充和發(fā)展；同時(shí)，也可方便地做到多對(duì)一或者一對(duì)多的遠(yuǎn)程復(fù)制；對(duì)存儲(chǔ)硬件設(shè)備的選擇也比較靈活。

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

2.3基于數(shù)據(jù)庫(kù)的數(shù)據(jù)容災(zāi)

大部分的數(shù)據(jù)庫(kù)軟件廠商提供了基于數(shù)據(jù)庫(kù)復(fù)制事務(wù)日志的容災(zāi)技術(shù)，基于數(shù)據(jù)庫(kù)的復(fù)制技術(shù)傳輸?shù)氖荢QL指令或重作日志文件，在新數(shù)據(jù)沒(méi)有被業(yè)務(wù)系統(tǒng)寫入存儲(chǔ)子系統(tǒng)前，就被指定發(fā)送到異地災(zāi)備中心的數(shù)據(jù)庫(kù)進(jìn)行相關(guān)交易處理。數(shù)據(jù)庫(kù)復(fù)制技術(shù)采用的是異步傳輸方式，通過(guò)IP網(wǎng)絡(luò)傳輸，支持一個(gè)生產(chǎn)系統(tǒng)向多個(gè)備份系統(tǒng)的數(shù)據(jù)庫(kù)進(jìn)行復(fù)制的要求，或多個(gè)生產(chǎn)系統(tǒng)向一個(gè)備份系統(tǒng)復(fù)制的要求。

這里由于本院的信息系統(tǒng)核心數(shù)據(jù)庫(kù)為Oracle數(shù)據(jù)庫(kù)，所以在這里以O(shè)racle數(shù)據(jù)的復(fù)制技術(shù)為例，Oracle數(shù)據(jù)庫(kù)層面的數(shù)據(jù)復(fù)制，業(yè)界大部分以Data Guard的機(jī)制做的，還有一部分是按照Streams模式做的。

2.4Data Guard模式的容災(zāi)過(guò)程

Data Guard主要提供兩種服務(wù)，分別為Redo傳輸服務(wù)和Redo應(yīng)用服務(wù)。傳輸服務(wù)即把Primay端的Redo日志傳輸?shù)揭粋€(gè)或多個(gè)Standby目的地；應(yīng)用服務(wù)即在Standby端應(yīng)用從Primay端傳輸過(guò)來(lái)的Redo日志。

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

同步或準(zhǔn)同步模式采用LGWR傳輸Redo日志：一旦Primary有Redo日志產(chǎn)生，LGWR將觸發(fā)LNSn進(jìn)程傳輸Redo只Standby Redo Log；網(wǎng)絡(luò)傳輸模式可選擇Sync或Async，Sync是指當(dāng)Primary提交時(shí)，必須得等Redo傳輸至Standby成功后，才能返回。Async是指Primary提交是否成功和日志是否傳輸成功沒(méi)有關(guān)系，這樣對(duì)Primary的性能影響最?。籗tandby端的RFS進(jìn)程把Redo寫入Standby Redo Log，如果開(kāi)啟了實(shí)時(shí)應(yīng)用，就將Redo應(yīng)用至Standby數(shù)據(jù)庫(kù)，如果沒(méi)有開(kāi)啟實(shí)時(shí)應(yīng)用，等Standby Redo Log歸檔后再應(yīng)用到Standby數(shù)據(jù)庫(kù)。

從以上可看出在Data Guard容災(zāi)過(guò)程中，備份中心的數(shù)據(jù)庫(kù)是否處于打開(kāi)狀態(tài)跟Redo日志的同步模式有關(guān)，筆者測(cè)試了2種類型的產(chǎn)品，各有優(yōu)缺點(diǎn)，準(zhǔn)實(shí)時(shí)同步的情況下均存在有幾秒數(shù)據(jù)延遲情況，對(duì)邏輯錯(cuò)誤的防護(hù)能力較低，測(cè)試時(shí)主機(jī)端邏輯錯(cuò)誤導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法啟動(dòng)，災(zāi)備端數(shù)據(jù)庫(kù)也無(wú)法啟動(dòng)。

2.5Streams模式的容災(zāi)過(guò)程

Streams災(zāi)備系統(tǒng)通過(guò)分析Oracle Redo Log獲得實(shí)時(shí)交易信息，完成Schema或Table級(jí)別的數(shù)據(jù)復(fù)制。區(qū)別于早期的日志分析技術(shù)，Streams對(duì)日志的整合和傳輸以交易為單位，在擁有高性能的同時(shí)還能更好的保證數(shù)據(jù)傳輸?shù)囊恢滦院屯暾浴?duì)生產(chǎn)數(shù)據(jù)庫(kù)也不會(huì)增加負(fù)載。

Streams從Oracle Redo Logs里面獲取所有的數(shù)據(jù)庫(kù)改變信息。通過(guò)對(duì)信息的分析整合，Streams將完整的交易信息復(fù)制到目的端。

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

Streams的機(jī)制需要打開(kāi)數(shù)據(jù)庫(kù)的Supplemental Logging 和Force Logging參數(shù)以便Streams能獲取完整的數(shù)據(jù)信息。

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

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

Streams支持兩種級(jí)別的復(fù)制，用戶（Schema）級(jí)復(fù)制和表級(jí)復(fù)制。用戶級(jí)復(fù)制表示源端數(shù)據(jù)庫(kù)指定用戶（Schema）下的所有表、視圖、索引、過(guò)程、函數(shù)、包、序列等數(shù)據(jù)對(duì)象全部復(fù)制到目標(biāo)端數(shù)據(jù)庫(kù)指定的用戶下；表級(jí)復(fù)制表示源端數(shù)據(jù)庫(kù)指定用戶（Schema）下的單個(gè)表復(fù)制到目標(biāo)端數(shù)據(jù)庫(kù)指定用戶下的單個(gè)表。

在使用Streams時(shí)，用戶通過(guò)編輯配置文件指定源端和目的端復(fù)制對(duì)象的映射關(guān)系，包括源端對(duì)象名，目的端對(duì)象名，目的主機(jī)編號(hào)等。源端和目的端對(duì)象名稱可不同，但結(jié)構(gòu)必須一致。軟件運(yùn)行過(guò)程中，復(fù)制對(duì)象的映射參數(shù)會(huì)駐留內(nèi)存，Streams通過(guò)日志分析過(guò)濾，只處理指定復(fù)制對(duì)象有關(guān)的交易，其他用戶或表的操作信息則被丟棄。

因此，Streams數(shù)據(jù)庫(kù)容災(zāi)技術(shù)屬于熱容災(zāi)方式，主備機(jī)均在線可用。Streams數(shù)據(jù)庫(kù)容災(zāi)技術(shù)與存儲(chǔ)子系統(tǒng)的類型、業(yè)務(wù)系統(tǒng)服務(wù)器的平臺(tái)無(wú)關(guān)，與數(shù)據(jù)庫(kù)的版本有一定關(guān)系，Streams數(shù)據(jù)庫(kù)容災(zāi)解決方案有較好的靈活性。可實(shí)現(xiàn)跨操作系統(tǒng)平臺(tái)數(shù)據(jù)復(fù)制、跨數(shù)據(jù)庫(kù)平臺(tái)數(shù)據(jù)復(fù)制，同時(shí)可提供上層BI數(shù)據(jù)分析使用。

由于復(fù)制的目的端數(shù)據(jù)庫(kù)始終處于打開(kāi)狀態(tài)，因此，當(dāng)生產(chǎn)數(shù)據(jù)庫(kù)遇到計(jì)劃內(nèi)或非計(jì)劃停機(jī)時(shí)，Streams的災(zāi)備端能夠支持前端應(yīng)用程序快速、無(wú)縫的切換到災(zāi)備數(shù)據(jù)庫(kù)。與其他基于磁盤或文件系統(tǒng)的物理復(fù)制技術(shù)相比，不但省略了漫長(zhǎng)的數(shù)據(jù)庫(kù)Recovery和啟動(dòng)時(shí)間，而且能夠保證100%的切換成功率。

測(cè)試缺點(diǎn)：缺少全系統(tǒng)備份模塊，業(yè)務(wù)恢復(fù)需要手動(dòng)搭建業(yè)務(wù)系統(tǒng)，搭建好后才能進(jìn)行數(shù)據(jù)反向同步復(fù)制來(lái)恢復(fù)。

3　結(jié) 語(yǔ)

根據(jù)系統(tǒng)的測(cè)試，最后選擇了基于Oracle Streams架構(gòu)的災(zāi)備系統(tǒng)作為HIS數(shù)據(jù)安全的建設(shè)平臺(tái)。當(dāng)然，數(shù)據(jù)庫(kù)容災(zāi)技術(shù)只能作為數(shù)據(jù)庫(kù)應(yīng)用的容災(zāi)解決方案，如果需要其他非結(jié)構(gòu)數(shù)據(jù)的容災(zāi)，還需要其他容災(zāi)技術(shù)作為補(bǔ)充。如CDP復(fù)制、事務(wù)日志復(fù)制等災(zāi)備平臺(tái)和普通備份平臺(tái)多維解決方案于一體的綜合應(yīng)用安全架構(gòu)體系，充分保障了數(shù)據(jù)和業(yè)務(wù)的分級(jí)災(zāi)備和存儲(chǔ)，全方位保障了結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)的安全。

10.3969/j.issn.1673 - 0194.2015.20.120

TP309.3

A

1673-0194（2015）20-0154-02

2015-08-27