前言

　　醫(yī)療信息化具有數(shù)據(jù)量龐大、數(shù)據(jù)安全等級(jí)高、高可靠性等特點(diǎn)。SDN通過(guò)集中面板來(lái)控制復(fù)雜網(wǎng)絡(luò)拓?fù)渲械木W(wǎng)絡(luò)流量，提供了全面自動(dòng)化服務(wù)、中央策略控制功能下發(fā)和內(nèi)建安全性，比以往更輕松地?cái)U(kuò)展和增強(qiáng)數(shù)據(jù)中心能力，將超融合基礎(chǔ)架構(gòu)中的網(wǎng)絡(luò)功能虛擬化，幫助超融合系統(tǒng)連接或管理內(nèi)部流量、數(shù)據(jù)中心通信和數(shù)據(jù)中心外的網(wǎng)絡(luò)，實(shí)現(xiàn)基于SDN的跨數(shù)據(jù)中心超融合雙活數(shù)據(jù)中心，該方案可以更小顆粒度進(jìn)行橫向擴(kuò)展。通過(guò)該架構(gòu)系統(tǒng)的實(shí)際搭建與實(shí)施應(yīng)用，驗(yàn)證了技術(shù)可行性和成熟度。

　　硬件架構(gòu)發(fā)展歷程

　　近10年間，醫(yī)療信息化與其他行業(yè)信息化的發(fā)展類似，大致經(jīng)歷了四個(gè)階段：分散式架構(gòu)、整合式架構(gòu)、虛擬化架構(gòu)以及超融合架構(gòu)。隨著用戶對(duì)應(yīng)用的可用性、存儲(chǔ)性能、存儲(chǔ)容量等要求的提高，高度整合式的數(shù)據(jù)中心架構(gòu)逐漸變成主流，數(shù)據(jù)中心的存儲(chǔ)設(shè)備由直連存儲(chǔ)演變?yōu)榧惺降墓蚕泶鎯?chǔ)模式，服務(wù)器通過(guò)HBA卡、SAN交換機(jī)、FC線纜與存儲(chǔ)設(shè)備連接，這種架構(gòu)的推出，有效地提高了存儲(chǔ)可用性、利用率、存儲(chǔ)設(shè)備的可管理性。

　　四種硬件架構(gòu)中，分散式架構(gòu)基本已被淘汰，整合式架構(gòu)目前仍用于運(yùn)算性能要求高的業(yè)務(wù)場(chǎng)景中，例如HIS系統(tǒng)。本文接下來(lái)主要對(duì)傳統(tǒng)SAN架構(gòu)虛擬化與超融合架構(gòu)虛擬化進(jìn)行對(duì)比分析。

圖1 醫(yī)療信息化硬件架構(gòu)

　　傳統(tǒng)SAN架構(gòu)虛擬化與HCI超融合架構(gòu)的對(duì)比

　　隨著虛擬化技術(shù)的發(fā)展使用，數(shù)據(jù)中心內(nèi)的服務(wù)器體量規(guī)模逐漸減少，物理空間占用率高等問(wèn)題得到緩解，但隨之而來(lái)的是虛擬機(jī)數(shù)量的急劇膨脹與參數(shù)超配。消耗巨大存儲(chǔ)空間的同時(shí)，也使得整個(gè)虛擬化架構(gòu)看上去不協(xié)調(diào)，存儲(chǔ)架構(gòu)臃腫。傳統(tǒng)存儲(chǔ)虛擬化架構(gòu)中SAN存儲(chǔ)陣列型號(hào)必須在存儲(chǔ)網(wǎng)關(guān)兼容性列表內(nèi)，同時(shí)隨著使用年限的增加，運(yùn)算、存儲(chǔ)品牌型號(hào)繁多，造成的維保與運(yùn)維壓力逐年遞增。傳統(tǒng)存儲(chǔ)設(shè)備受限于其架構(gòu)，在縱向及橫向擴(kuò)展能力方面缺乏靈活性。

表1 傳統(tǒng)SAN架構(gòu)虛擬化與超融合架構(gòu)的區(qū)別

圖2 傳統(tǒng)SAN架構(gòu)虛擬化與HCI超融合內(nèi)部架構(gòu)對(duì)比

　　基于SDN實(shí)現(xiàn)HCI超融合架構(gòu)雙活方案

　　通過(guò)跨數(shù)據(jù)中心的SDN技術(shù)構(gòu)建滿足核心系統(tǒng)雙活要求的大二層網(wǎng)絡(luò)，為醫(yī)院構(gòu)建雙活數(shù)據(jù)中心建立堅(jiān)實(shí)基礎(chǔ)。下圖為醫(yī)院的數(shù)據(jù)中心SDN網(wǎng)絡(luò)邏輯架構(gòu)圖：

圖3 基于SDN網(wǎng)絡(luò)的HCI超融合架構(gòu)圖

　　對(duì)于承載醫(yī)院核心系統(tǒng)的超融合平臺(tái)而言，要滿足跨數(shù)據(jù)中心的業(yè)務(wù)連續(xù)性的技術(shù)要求，需要底層網(wǎng)絡(luò)具備足夠的靈活性、可靠性，同時(shí)能夠保障在站點(diǎn)級(jí)別故障發(fā)生時(shí)，可以快速恢復(fù)業(yè)務(wù)系統(tǒng)，在保障業(yè)務(wù)連續(xù)性的同時(shí)，滿足醫(yī)療行業(yè)政策監(jiān)管需求。

　　構(gòu)建醫(yī)院超融合架構(gòu)雙活數(shù)據(jù)中心，主要參考了如下醫(yī)療行業(yè)規(guī)范和標(biāo)準(zhǔn)。

　　《醫(yī)院信息互聯(lián)互通標(biāo)準(zhǔn)化成熟度測(cè)評(píng)方案》

　　《電子病歷系統(tǒng)應(yīng)用水平分級(jí)評(píng)價(jià)標(biāo)準(zhǔn)(試行)》(2018版)

　　《醫(yī)院智慧服務(wù)分級(jí)評(píng)估標(biāo)準(zhǔn)體系(試行)》(2019版)

　　《網(wǎng)絡(luò)安全等級(jí)保護(hù)測(cè)評(píng)高風(fēng)險(xiǎn)判定指引》

　　傳統(tǒng)虛擬化與超融合架構(gòu)結(jié)合具體應(yīng)用場(chǎng)景的對(duì)比

　　本次性能對(duì)比測(cè)試方案為：選取兩家國(guó)內(nèi)排名相近、門(mén)診量/住院量相仿的醫(yī)院中，運(yùn)行同類業(yè)務(wù)的Oracle虛擬化服務(wù)器進(jìn)行對(duì)比，出于安全方面考慮，兩家醫(yī)院以醫(yī)院A與醫(yī)院B代指，其中醫(yī)院A使用的是HCI超融合集群，醫(yī)院B使用的傳統(tǒng)SAN架構(gòu)虛擬化，測(cè)試機(jī)器為一臺(tái)辦理同類業(yè)務(wù)的Oracle(NO RAC)服務(wù)器，分別導(dǎo)出24小時(shí)內(nèi)的AWR(Automatic Workload Repository)報(bào)告進(jìn)行性能分析，報(bào)告截圖如下：

圖4 醫(yī)院A的AWR報(bào)告截圖

圖5 醫(yī)院B的AWR報(bào)告截圖

　　首先我們可以直觀地看到，兩家醫(yī)院的Host服務(wù)器的硬件配置差距明顯，從CPU和內(nèi)存配置來(lái)看，采用HCI超融合方案的醫(yī)院A優(yōu)于傳統(tǒng)虛擬化架構(gòu)的醫(yī)院B。接下來(lái)我們從Oracle運(yùn)行情況來(lái)看。

　　(1)redo size

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

　　(2)DB Time

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

　　(3)DB CPU占比及l(fā)og file sync(日志文件同步)單次平均等待時(shí)間

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

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

　　醫(yī)院A 較醫(yī)院B在db file sequential read、db file scattered read 等指標(biāo)上有很大的下降，db file sequential read總的等待時(shí)間從6482s下降為3844s，db file scattered read總的等待時(shí)間從1521s下降為383s，從以上數(shù)據(jù)能看出，醫(yī)院A的較大數(shù)據(jù)量的讀帶寬要遠(yuǎn)優(yōu)于醫(yī)院B。

　　通過(guò)對(duì)HCI超融合架構(gòu)及傳統(tǒng)SAN架構(gòu)虛擬化運(yùn)行的相同業(yè)務(wù)的Oracle虛擬服務(wù)器的性能對(duì)比后能清晰直觀地看出超融合在底層IO、CPU性能調(diào)用等方面的優(yōu)勢(shì)。

　　小結(jié)

　　超融合架構(gòu)在數(shù)據(jù)中心承擔(dān)著計(jì)算資源池和分布式存儲(chǔ)資源池的作用，極大地簡(jiǎn)化了數(shù)據(jù)中心的基礎(chǔ)架構(gòu)，而且通過(guò)軟件定義的計(jì)算資源虛擬化和分布式存儲(chǔ)架構(gòu)實(shí)現(xiàn)無(wú)單點(diǎn)故障、無(wú)單點(diǎn)瓶頸、彈性擴(kuò)展、性能線性增長(zhǎng)等能力，同時(shí)簡(jiǎn)化了數(shù)據(jù)中心雙活實(shí)現(xiàn)的復(fù)雜度，運(yùn)維側(cè)的壓力得到大幅降低，業(yè)務(wù)系統(tǒng)的連續(xù)性得到更好的保障。

　　另外，超融合平臺(tái)支持豐富的數(shù)據(jù)服務(wù)，包括塊存儲(chǔ)服務(wù)、NAS存儲(chǔ)服務(wù)等，同時(shí)具備重復(fù)數(shù)據(jù)刪除和壓縮功能，可以實(shí)現(xiàn)很好的存儲(chǔ)效率。

　　對(duì)于關(guān)鍵業(yè)務(wù)數(shù)據(jù)庫(kù)的管理，可以通過(guò)數(shù)據(jù)庫(kù)引擎實(shí)現(xiàn)一鍵式部署常用的數(shù)據(jù)庫(kù)高可用，如Oracle RAC，SQL Server Alwayson等，并基于超融合自身的存儲(chǔ)技術(shù)實(shí)現(xiàn)關(guān)鍵業(yè)務(wù)數(shù)據(jù)庫(kù)的持續(xù)數(shù)據(jù)保護(hù)，一鍵式數(shù)據(jù)庫(kù)配置和數(shù)據(jù)副本管理服務(wù)，管理員能夠隨時(shí)配置、克隆、刷新、備份和恢復(fù)數(shù)據(jù)庫(kù)，使用自動(dòng)化服務(wù)取代耗時(shí)且復(fù)雜的數(shù)據(jù)庫(kù)操作，可以將資源更多的聚焦于核心業(yè)務(wù)，免除DBA工作的各種煩惱，期待將來(lái)能更多的利用創(chuàng)新技術(shù)，輔助信息化的支撐和建設(shè)。

　　作者簡(jiǎn)介

　　曹凱，山東大學(xué)齊魯醫(yī)院信息網(wǎng)絡(luò)中心，Nutanix NCP認(rèn)證工程師，CISP注冊(cè)信息安全工程師，山東省醫(yī)學(xué)會(huì)醫(yī)學(xué)信息學(xué)分會(huì)委員。