快照引起虛擬化業務中斷的思考

李守龍

(蘇州市立醫院北區,江蘇蘇州 215031)

0 引言

隨著各行各業對信息化的依賴程度越來越高,同時也對信息化服務的可靠性、安全性、便捷性提出了更高的要求[1]。虛擬化技術能夠在整合資源的同時提高可靠性和安全性,因此在醫療行業得到了廣泛的發展。我院也利用VMware vSphere虛擬化技術搭建了非核心業務平臺,經過一段時間的使用,虛擬化平臺總體穩定、可靠,但是也存在著一些風險因素。

1 我院虛擬化平臺基礎架構

我院虛擬化平臺采用VMware vSphere產品構建,并與微分段分布式防火墻結合增強虛擬化平臺安全防護措施。底層架構中各虛擬化主機基于FC SAN存儲交換機與存儲連接,存儲設備自身采用雙活架構的方式與虛擬化平臺結合,保證底層存儲和上層虛擬機的高可用性。服務器端的管理與業務網絡基于低延遲的萬兆光交換機接入,保證了整體網絡環境的帶寬傳輸性能與效率。服務器操作系統使用ESXi 6.7,使用VCSA 6.7集中管理主機與集群。虛擬化集群啟用故障轉移功能當某一個節點出現故障,系統遵循對應的規則轉移失效節點的業務虛擬機,以免節點失效對業務運行帶來影響[2]。為了更進一步加強虛擬化平臺的數據保護,采用專業虛擬機和數據庫備份平臺對虛擬機和數據庫進行定時備份。拓撲結構如圖1所示:

圖1 拓撲結構圖Fig.1 Topological structure diagram

2 事件回顧

某日凌晨4點接到影像系統故障報修,報錯信息提示為數據庫連接錯誤。登錄數據庫服務器發現有意外斷電事件,手工啟動ORACLE服務。PACS系統可以正常登陸,但無法調取患者影像。初步懷疑網絡或存儲問題,針對性的進行虛擬服務器、光纖交換機和影像存儲的排查,除了操作系統有意外重啟事件外,沒有其他明顯異常。通過虛擬化管理平臺(VMware vCenter)發現有物理服務器未響應情況,而且有大批量的虛擬服務器自動遷移記錄,并且每隔20分鐘就有一臺物理主機發生未響應情況,最終集群中所有物理主機均發生未響應情況,包括虛擬化管理平臺在內的所有業務中斷,啟動應急預案。

進入機房查看硬件設備,發現物理主機處于宕機狀態,立即逐一進行重啟操作,業務逐個得到恢復。密切關注虛擬化管理平臺動態,物理主機未響應情況再次出現,每隔一定時間就有幾個業務系統受到影響。最終通過不斷的觀察和分析發現是因為物理主機CPU資源耗盡而導致了宕機。故障發生后故障轉移機制發揮作用,把宕機的物理主機上的虛擬服務器自動遷移到集群中的其他主機,進而引起其他主機的CUP資源的耗盡,直至集群中所有主機宕機。經討論決定同時開啟所有物理主機,鎖定第1臺宕機的物理主機,分析運行在其上的虛擬服務器,逐一關閉這些虛擬服務器,找出有嫌疑的虛擬機。經過驗證發現承載體檢業務的虛擬服務器有重大嫌疑,立刻將體檢系統劃分到一個新的集群中,同其他業務分開,獨享一個集群資源,并對資源進行閾值限定,等同于對該虛擬服務器進行隔離,該集群中的故障不會轉移到其他集群。

至此其他集群中的主機未再出現宕機情況,除Pacs系統外的其他業務均得到了恢復。Pacs系統虛擬服務器因發生自動遷移導致注冊和授權信息不一致,應用程序無法啟動提供服務,緊急聯系廠商進行總部授權,耗費約3小時,雖然啟動了應急預案,但是未達到滿意的預期。

體檢集群中物理主機仍然循環宕機,體檢業務系統無法使用,著手新建虛擬服務器并搭建軟件運行環境及數據恢復,預計耗時5小時。同時仍然不放棄問題的排查,基本排除病毒、木馬、網絡問題等原因,重點進行虛擬化平臺和虛擬服務器的檢查,通過對比分析區別于其他虛擬服務器的是該虛擬機上存在快照。快照是虛擬服務器的備份文件,用于虛擬服務器出現故障時快速還原到快照建立的時間點。為了盡快排查到問題將快照刪除,刪除后集群中主機未再發生宕機,故障得到修復,解除所有應急預案,組織科室人員進行應急期間的數據處理。

之后所有業務運行正常,信息科對快照事件進行追溯。事件發生前一日在日常巡檢中發現體檢系統虛擬服務器磁盤空間需要擴容,向服務提供商提出進行磁盤擴容。工程師在當日夜間23時進行磁盤空間的擴容,擴容完成后為確保安全對虛擬服務器建立了快照,次日凌晨出現本次事件。

事件發生一周后在測試環境中無論是對克隆的體檢業務虛擬服務器,還是對新建的虛擬服務器進行磁盤擴容和建立快照,均未能復現當時的故障。總結本次事件原因為:虛擬服務器磁盤空間擴容后建立了快照,快照的存在引發了虛擬化軟件的某項BUG。未在相關文獻中查到類似問題,定性本次事件是快照引起的偶發意外事件,未對相關公司、人員進行追責。

3 事件思考

(1)信息系統難免發生故障,為了第一時間能作出高效、有序應急響應,各單位都會制定自己的應急預案。應急預案是緊急情況下的行動指南,對醫療秩序的維持發揮著至關重要的作用。因此應急預案的制定要有多部門的參與,并充分考慮各種情況,有依有據、切實可行。預案完成后要進行相應的培訓和多部門演練,根據演練情況不斷改善和改進流程,才能在災難發生時從容應對,最大程度的減少對患者和醫護人員的影響,保障正常的就醫秩序。一旦應急預案啟動各部門要執行預案,不得以系統故障為由,推辭患者,損害患者就醫權利。

(2)在虛擬化建中要從各個方面整體、充分考慮安全性。我們在建設中多注重對硬件故障的保障,忽視了軟件層面的問題。通常情況下,網絡安全設備和審計系統均部署于物理服務器的外部,無法過濾物理主機上各虛擬服務器的外部,無法過濾物理主機上各虛擬服務器之間的通信數據,這樣就會產生安全隱患[3]。需要考慮和虛擬化相結合、針對性的軟硬件安全產品。虛擬化平臺本身是高級服務器管理軟件,是軟件一定存在漏洞,如近期發現的VMware vSphere Server遠程代碼執行漏洞,同操作系統一樣要定期升級版本和更新補丁,保障虛擬化本身的安全性和穩定性。

(3)虛擬化的管理不能完全依賴服務提供商,培養日常運維的隊伍尤其重要。只有日常的運維加上服務商的定期專業化巡檢才能最大程度的保障平臺安全。同時虛擬化平臺權限要細化,不同人員按級別分配不同的管理權限,一定程度上可以減少誤操作的發生。內、外部運維要通過堡壘機進行實施,所有實施都要有電子化的記錄,便于事件追溯和事后分析。虛擬化平臺是一個整體性的平臺,日常運維和升級都可能影響到業務系統的使用,因此可能影響業務系統運行的操作要審批、備案,經科室同意并在有回退方案和應急預案的情況下,方能進行相應的調整。

(4)機房中虛擬化相關的(交換、存儲、服務器)設備標識要準確、簡明扼要,并張貼在設備顯著位置,一旦監測到虛擬化設備故障可以快速定位。可以把虛擬化拓撲結構張貼在運維區域,也可以把物理主機上運行的虛擬服務器標識在主機上,定期進行相關信息的更新,做到對虛擬資產的掌控,運維也更加的便捷。

(5)所有資源劃分在一個集群中,在抵抗硬件故障上優勢明顯,理論上在N-1臺服務器同時故障的情況下依然可以保障服務的可用性,但在特殊情況下可能會引起整個虛擬化平臺的不穩定。通過本次事件我們重新審視資源的分配問題,根據業務系統劃分不同的集群。集群劃分時盡量選擇同品牌型號的物理主機,可以在一定程度上避免虛擬服務器故障轉移中出現業務系統授權信息不一致導致的不可用問題。每個集群中要有4臺以上的物理主機,要有緊急程度不一的信息系統,盡量避免兩個及以上重要業務系統在同一個集群中,避免主備虛擬服務器在同一個集群中。

(6)虛擬化的技術越來越成熟完善,在故障發生時會按照一定策略進行故障的轉移,保障虛擬服務器的可用性。虛擬服務器的可用不意味著業務的持續。不同的廠商在部署應用時均有自己的加密機制,發生故障轉移后,物理主機的不同可能會導致軟件廠商識別到未授權的部署,從而導致系統無法提供服務。重新授權往往耗費時間長,對醫療業務的影響大。可以通過測試環境手動遷移虛擬服務器進行授權問題檢查,如果出現相應問題需要和廠商一起制定一套備用授權機制,以備緊急情況下的臨時使用。

(7)及時更新操作系統補丁可以增強安全性,避免漏洞被惡意利用。本次事件中有10臺以上運行Windows Server 2008 R2操作系統的虛擬服務器無法引導進入操作系統,為當日事件雪上加霜。原因均為未進行補丁測試就進行了補丁的更新,并在更新后未進行重啟操作。吸取本次教訓,更正補丁策略,不再集中進行補丁的更新。劃分各種版本操作系統虛擬服務器,專用于補丁更新測試。測試通過后制定更新計劃,分批分類進行更新,更新后制定重啟計劃,逐臺進行重啟驗證。新建虛擬服務器不再使用官方已停止更新的版本,有計劃的對正在使用的老舊操作系統進升級,保障操作系統的安全性和可靠性。

4 結語

隨著醫院的信息化程度越來越高,臨床業務也越來越依賴信息系統,信息系統的安全和穩定關系民生。一旦發生安全事件,經濟損失事小,給患者和社會帶來的負面影響事大。虛擬化平臺相比傳統的服務器模式有著安全優勢,作為醫療信息行業的從業者,我們不能麻痹大意,要從各種事件中吸取教訓,優化各種安全策略,保障安全事件不發生或發生后有快速的應急或恢復措施。