前言

　　醫療信息化具有數據量龐大、數據安全等級高、高可靠性等特點。SDN通過集中面板來控制復雜網絡拓撲中的網絡流量，提供了全面自動化服務、中央策略控制功能下發和內建安全性，比以往更輕松地擴展和增強數據中心能力，將超融合基礎架構中的網絡功能虛擬化，幫助超融合系統連接或管理內部流量、數據中心通信和數據中心外的網絡，實現基于SDN的跨數據中心超融合雙活數據中心，該方案可以更小顆粒度進行橫向擴展。通過該架構系統的實際搭建與實施應用，驗證了技術可行性和成熟度。

　　硬件架構發展歷程

　　近10年間，醫療信息化與其他行業信息化的發展類似，大致經歷了四個階段：分散式架構、整合式架構、虛擬化架構以及超融合架構。隨著用戶對應用的可用性、存儲性能、存儲容量等要求的提高，高度整合式的數據中心架構逐漸變成主流，數據中心的存儲設備由直連存儲演變為集中式的共享存儲模式，服務器通過HBA卡、SAN交換機、FC線纜與存儲設備連接，這種架構的推出，有效地提高了存儲可用性、利用率、存儲設備的可管理性。

　　四種硬件架構中，分散式架構基本已被淘汰，整合式架構目前仍用于運算性能要求高的業務場景中，例如HIS系統。本文接下來主要對傳統SAN架構虛擬化與超融合架構虛擬化進行對比分析。

圖1 醫療信息化硬件架構

　　傳統SAN架構虛擬化與HCI超融合架構的對比

　　隨著虛擬化技術的發展使用，數據中心內的服務器體量規模逐漸減少，物理空間占用率高等問題得到緩解，但隨之而來的是虛擬機數量的急劇膨脹與參數超配。消耗巨大存儲空間的同時，也使得整個虛擬化架構看上去不協調，存儲架構臃腫。傳統存儲虛擬化架構中SAN存儲陣列型號必須在存儲網關兼容性列表內，同時隨著使用年限的增加，運算、存儲品牌型號繁多，造成的維保與運維壓力逐年遞增。傳統存儲設備受限于其架構，在縱向及橫向擴展能力方面缺乏靈活性。

表1 傳統SAN架構虛擬化與超融合架構的區別

圖2 傳統SAN架構虛擬化與HCI超融合內部架構對比

　　基于SDN實現HCI超融合架構雙活方案

　　通過跨數據中心的SDN技術構建滿足核心系統雙活要求的大二層網絡，為醫院構建雙活數據中心建立堅實基礎。下圖為醫院的數據中心SDN網絡邏輯架構圖：

圖3 基于SDN網絡的HCI超融合架構圖

　　對于承載醫院核心系統的超融合平臺而言，要滿足跨數據中心的業務連續性的技術要求，需要底層網絡具備足夠的靈活性、可靠性，同時能夠保障在站點級別故障發生時，可以快速恢復業務系統，在保障業務連續性的同時，滿足醫療行業政策監管需求。

　　構建醫院超融合架構雙活數據中心，主要參考了如下醫療行業規范和標準。

　　《醫院信息互聯互通標準化成熟度測評方案》

　　《電子病歷系統應用水平分級評價標準(試行)》(2018版)

　　《醫院智慧服務分級評估標準體系(試行)》(2019版)

　　《網絡安全等級保護測評高風險判定指引》

　　傳統虛擬化與超融合架構結合具體應用場景的對比

　　本次性能對比測試方案為：選取兩家國內排名相近、門診量/住院量相仿的醫院中，運行同類業務的Oracle虛擬化服務器進行對比，出于安全方面考慮，兩家醫院以醫院A與醫院B代指，其中醫院A使用的是HCI超融合集群，醫院B使用的傳統SAN架構虛擬化，測試機器為一臺辦理同類業務的Oracle(NO RAC)服務器，分別導出24小時內的AWR(Automatic Workload Repository)報告進行性能分析，報告截圖如下：

圖4 醫院A的AWR報告截圖

圖5 醫院B的AWR報告截圖

　　首先我們可以直觀地看到，兩家醫院的Host服務器的硬件配置差距明顯，從CPU和內存配置來看，采用HCI超融合方案的醫院A優于傳統虛擬化架構的醫院B。接下來我們從Oracle運行情況來看。

　　(1)redo size

　　redo size主要是用了衡量數據庫記錄變更的頻繁程度，醫院A和醫院B的transactions基本一致的情況下，醫院A的redo size為106683.6(bytes)，醫院B為130927.1(bytes)，該數值越大，往往會產生對LGWR寫日志以及和Arch歸檔，上述兩種情形會對I/O造成壓力，從數值上看，醫院B在規模相當負載下的運行狀況顯得比較繁忙。

　　(2)DB Time

　　醫院A為16核心CPU，Elapsed總共為1439.89*16=23038.24(mins)，DB Time為990.96(mins)，指CPU花費990.96分鐘在處理Oracle非空閑等待和運算上(比方邏輯讀)，DB Time與Elapsed的比值為0.043。同理，醫院B該比值為0.185，該數值代表Oracle數據庫的繁忙程度，數值越高說明數據庫越繁忙，從該數值看出醫院A數據庫的資源更充足，在應對業務高峰和突發高峰時運行更平穩一些。

　　(3)DB CPU占比及log file sync(日志文件同步)單次平均等待時間

　　醫院A的DB CPU占比為57%，log file sync單次平均等待時間為2.64ms，醫院B的DB CPU占比為70.4%，log file sync單次等待時間為3.94ms，從以上數據能看出，醫院A的CPU消耗指數及日志文件同步單次平均等待時間都優于醫院B。

　　(4)Db file sequential read、db file scattered read 單次平均等待時間

　　醫院A 較醫院B在db file sequential read、db file scattered read 等指標上有很大的下降，db file sequential read總的等待時間從6482s下降為3844s，db file scattered read總的等待時間從1521s下降為383s，從以上數據能看出，醫院A的較大數據量的讀帶寬要遠優于醫院B。

　　通過對HCI超融合架構及傳統SAN架構虛擬化運行的相同業務的Oracle虛擬服務器的性能對比后能清晰直觀地看出超融合在底層IO、CPU性能調用等方面的優勢。

　　小結

　　超融合架構在數據中心承擔著計算資源池和分布式存儲資源池的作用，極大地簡化了數據中心的基礎架構，而且通過軟件定義的計算資源虛擬化和分布式存儲架構實現無單點故障、無單點瓶頸、彈性擴展、性能線性增長等能力，同時簡化了數據中心雙活實現的復雜度，運維側的壓力得到大幅降低，業務系統的連續性得到更好的保障。

　　另外，超融合平臺支持豐富的數據服務，包括塊存儲服務、NAS存儲服務等，同時具備重復數據刪除和壓縮功能，可以實現很好的存儲效率。

　　對于關鍵業務數據庫的管理，可以通過數據庫引擎實現一鍵式部署常用的數據庫高可用，如Oracle RAC，SQL Server Alwayson等，并基于超融合自身的存儲技術實現關鍵業務數據庫的持續數據保護，一鍵式數據庫配置和數據副本管理服務，管理員能夠隨時配置、克隆、刷新、備份和恢復數據庫，使用自動化服務取代耗時且復雜的數據庫操作，可以將資源更多的聚焦于核心業務，免除DBA工作的各種煩惱，期待將來能更多的利用創新技術，輔助信息化的支撐和建設。

　　作者簡介

　　曹凱，山東大學齊魯醫院信息網絡中心，Nutanix NCP認證工程師，CISP注冊信息安全工程師，山東省醫學會醫學信息學分會委員。