李立

(泰興市人民醫(yī)院，江蘇泰興 225400)

隨著醫(yī)院信息化建設(shè)需求的不斷提高以及相關(guān)醫(yī)療信息化技術(shù)的創(chuàng)新發(fā)展，云計(jì)算、大數(shù)據(jù)BI、AI 等信息技術(shù)在醫(yī)療行業(yè)得到廣泛應(yīng)用[1]?，F(xiàn)今，醫(yī)學(xué)數(shù)據(jù)呈現(xiàn)出了龐大的大數(shù)據(jù)特征，數(shù)據(jù)稀疏、維度提高的數(shù)據(jù)應(yīng)該如何科學(xué)地進(jìn)行高效計(jì)算、分類存儲(chǔ)、深度挖掘等將成為尚待研究的新興課題。

1 研究背景

我院于2014 年開始開展虛擬化平臺(tái)項(xiàng)目，使用的是兩套IBM Flex 刀箱，配合兩套EMC VPLEX做了兩地METRO 部署。隨著業(yè)務(wù)的不斷擴(kuò)展，同時(shí)考慮到信息集成平臺(tái)項(xiàng)目盡快落地，2018 年開始陸續(xù)進(jìn)行超融合部署，10 臺(tái)DELL EMC 機(jī)架式服務(wù)器，其中3 個(gè)全閃節(jié)點(diǎn)加7 個(gè)混閃節(jié)點(diǎn)。2019 年，我院信息集成項(xiàng)目正式啟動(dòng)，集成平臺(tái)和數(shù)據(jù)中心相繼成功部署落地。然而，信息集成平臺(tái)內(nèi)的數(shù)據(jù)中心采集工作剛剛開始不足2 個(gè)月，VSAN 平臺(tái)即出現(xiàn)了一次報(bào)警。超融合平臺(tái)一共90T 的可用空間，在不足2 個(gè)月的時(shí)間就已經(jīng)用去近80%，剩余空間甚至不能支撐BI 運(yùn)營平臺(tái)的數(shù)據(jù)抽取與分析，頻頻報(bào)錯(cuò)。經(jīng)過仔細(xì)探討與分析，我們逐漸發(fā)現(xiàn)端倪，超融合架構(gòu)與Hadoop 集群的結(jié)合，利弊共存。

2 分析

2.1 超融合

2.1.1 關(guān)于超融合

超融合架構(gòu)(Hyper-converged Infrastructure)是指我們在同一套信息設(shè)備單元中含有存儲(chǔ)、計(jì)算、網(wǎng)絡(luò)和虛擬池化等技術(shù)，包括數(shù)據(jù)備份、緩存加速、數(shù)據(jù)消重、數(shù)據(jù)壓縮與業(yè)務(wù)連續(xù)性無縫對接保護(hù)等因素，多個(gè)業(yè)務(wù)節(jié)點(diǎn)通過網(wǎng)絡(luò)重組得以實(shí)現(xiàn)高可用性的橫向擴(kuò)展，逐步形成了統(tǒng)一資源池的架構(gòu)[2]。對于醫(yī)院細(xì)節(jié)方面繁瑣的控制要求較為突出，因?yàn)槌诤霞軜?gòu)的所有資源都是池化處理的，某一節(jié)點(diǎn)出現(xiàn)問題的情況下，超融合的機(jī)制可以十分有效地避免業(yè)務(wù)中斷，當(dāng)業(yè)務(wù)系統(tǒng)建立的同時(shí)也建立了業(yè)務(wù)系統(tǒng)鏡像，因此，在提高系統(tǒng)容災(zāi)、冗余方面有著顯著的作用，其工作架構(gòu)拓?fù)湟妶D1。

圖1 超融合架構(gòu)拓?fù)鋱D

2.1.2 關(guān)于副本

首先，允許的故障數(shù)(FTT)定義了虛擬機(jī)對象允許的主機(jī)和設(shè)備故障數(shù)量。如果FTT 為n，則創(chuàng)建的虛擬機(jī)對象副本數(shù)為n+1，見證對象的個(gè)數(shù)為n，這樣所需的用于存儲(chǔ)的主機(jī)數(shù)為副本數(shù)+見證數(shù)=n+1+n=2n+1。如果我們此次設(shè)置的副本數(shù)為2，表示的就是最多允許1 臺(tái)主機(jī)出故障，也即FTT 值為1，此時(shí)主機(jī)數(shù)最少為3。虛擬機(jī)存儲(chǔ)策略允許的故障數(shù)，如果已配置故障域，則需要2n+1 個(gè)故障域，且這些故障域中具有可提供容量的主機(jī)[3]。

前述超融合能提供可靠的冗余方案，述及關(guān)于副本。此次數(shù)據(jù)中心部署的環(huán)境為7 臺(tái)混閃節(jié)點(diǎn)，考慮到安全冗余度和性能實(shí)際使用率，因?yàn)槌诤霞簝?nèi)有7 臺(tái)主機(jī)，我們最多能允許有3 臺(tái)主機(jī)同時(shí)發(fā)生故障而數(shù)據(jù)不丟失,所以，此次我們設(shè)置的副本數(shù)為2，即雙副本機(jī)制。

2.2 Hadoop 技術(shù)

2.2.1 關(guān)于Hadoop

我院信息集成平臺(tái)和數(shù)據(jù)中心建設(shè)采用了Hadoop 2.0 版本的技術(shù)架構(gòu)，該基礎(chǔ)技術(shù)架構(gòu)屬相對主流的云計(jì)算及大數(shù)據(jù)技術(shù)框架，該架構(gòu)的核心技術(shù)是由HD FS 文件系統(tǒng)和MapReduce 的計(jì)算框架所組成，數(shù)據(jù)庫方面是由數(shù)據(jù)倉庫工具Hive 和分布式數(shù)據(jù)庫Hbase 為核心所組成[4]。使用該框架解決了海量數(shù)據(jù)計(jì)算和大規(guī)模存儲(chǔ)帶來的問題，使用MongoDB 來進(jìn)行存儲(chǔ)，經(jīng)過分詞、索引后的數(shù)據(jù)，為前端的業(yè)務(wù)應(yīng)用提供數(shù)據(jù)支撐。

2.2.2 關(guān)于副本

HDFS (Hadoop Distributed File System)格式即為Hadoop 分布式文件系統(tǒng)。HDFS 有很多特點(diǎn)：①保存了多份副本文件，并且提供豐富的容錯(cuò)機(jī)制，如副本丟失或宕機(jī)系統(tǒng)會(huì)自動(dòng)恢復(fù)，默認(rèn)存3 份副本。②運(yùn)行在廉價(jià)的機(jī)器上。③適合海量數(shù)據(jù)的處理分析。

與集成平臺(tái)廠商確認(rèn)過后，我們得到了3 份副本的配置機(jī)制。我們分別查看了Hadoop 集群內(nèi)的4臺(tái)主機(jī)，存儲(chǔ)占用情況只有1TB 不到，那為什么我們的超融合平臺(tái)內(nèi)查看的存儲(chǔ)占用總共近80TB？是哪里的數(shù)據(jù)會(huì)占用這么大的空間？

2.3 真因

從圖2 和圖3 我們可以清楚地看到，正如此前所分析的，超融合技術(shù)我們設(shè)置的是雙副本機(jī)制，Hadoop 集群我們默認(rèn)設(shè)置的是三副本機(jī)制，仔細(xì)觀察不難找出問題的真因所在，即：每一份數(shù)據(jù)都有6 個(gè)備份，且Hadoop 的數(shù)據(jù)寫入與刪除機(jī)制默認(rèn)會(huì)存在空間不可釋放性[5]，導(dǎo)致了超融合平臺(tái)存儲(chǔ)占用率如此之高。

3 重構(gòu)

基于存儲(chǔ)空間不足，可以深刻認(rèn)識(shí)到此前的集群部署極其不合理。但2 個(gè)月的數(shù)據(jù)中心的數(shù)據(jù)抽取與核對分析已經(jīng)完成，并且有了很好的展示效果，是否該把整個(gè)集群重新部署？如何保證此前的數(shù)據(jù)不丟失并且進(jìn)行集群的無縫重構(gòu)？這是我們急需面對的問題。

3.1 容量與副本

考慮到之前超融合平臺(tái)分配給每一臺(tái)Hadoop主機(jī)的磁盤容量為10TB，縱觀整個(gè)超融合平臺(tái)存儲(chǔ)磁盤總體容量與配比，此次部署Hadoop 集群內(nèi)的磁盤容量縮減至6TB，且Hadoop 集群的副本數(shù)調(diào)整為2 副本，加上超融合機(jī)制的雙副本，每份數(shù)據(jù)縮減至了4 個(gè)備份，保證數(shù)據(jù)安全的前提下，大大縮減了磁盤空間。

圖2 HDFS 按照Master 和Slave 的結(jié)構(gòu)分布

圖3 HDFS 按默認(rèn)配置Rack1,Rack2,Rack3

3.2 數(shù)據(jù)遷移

為了保證數(shù)據(jù)的完整性，我們通過超融合平臺(tái)為原先Hadoop 集群中的一臺(tái)Hadoop04 掛載一塊500G 的硬盤，將原先10TB 磁盤中的1 個(gè)副本（所有數(shù)據(jù)都在內(nèi)）復(fù)制到500G 的新磁盤內(nèi)，復(fù)制完成后隨即刪除10TB 磁盤，重新分配1 個(gè)6TB 磁盤并掛載，并將500G 磁盤內(nèi)的副本鏡像再復(fù)制回6TB 磁盤中，完成之后隨即再刪除這塊500G 的臨時(shí)中轉(zhuǎn)磁盤。同理，再選擇另外一臺(tái)Hadoop03 的主機(jī)，重復(fù)以上操作。

在完成了兩臺(tái)Hadoop 集群內(nèi)主機(jī)的磁盤重新部署之后，整個(gè)超融合平臺(tái)的存儲(chǔ)空間大幅度釋放開來，Hadoop 集群內(nèi)的另外兩臺(tái)Hadoop01 和Hadoop02 主機(jī)則不需要通過掛載臨時(shí)中轉(zhuǎn)磁盤進(jìn)行數(shù)據(jù)遷移，直接分配并掛載6TB 磁盤，副本復(fù)制即完成數(shù)據(jù)重新安全部署，如圖4 所示。

3.3 分析

通過對Hadoop 集群內(nèi)主機(jī)的重新調(diào)整和數(shù)據(jù)遷移，整體存儲(chǔ)磁盤進(jìn)行了重構(gòu)，既保證了數(shù)據(jù)的完整性和安全性，又使得超融合平臺(tái)內(nèi)的存儲(chǔ)空間得到大大釋放，使得復(fù)雜且異構(gòu)化的數(shù)據(jù)存儲(chǔ)在統(tǒng)一平臺(tái)實(shí)現(xiàn)了數(shù)據(jù)統(tǒng)一管理[6]。

圖4 調(diào)整后的Hadoop01 配置

4 討論

新一代的醫(yī)院信息集成平臺(tái)和數(shù)據(jù)中心建設(shè)需有大規(guī)模、高可用的數(shù)據(jù)管理系統(tǒng)做支撐，要求對聯(lián)機(jī)事物處理的支持能力相對強(qiáng)大，才能確保系統(tǒng)具有安全性、可擴(kuò)充性、可移植性、高效性和可靠性，必須能適應(yīng)不同的軟硬件架構(gòu)平臺(tái)[7]。醫(yī)院信息集成平臺(tái)和數(shù)據(jù)中心建設(shè)的系統(tǒng)架構(gòu)要盡可能采用高性能的服務(wù)器集群，且要擁有強(qiáng)大的容災(zāi)能力和負(fù)載均衡性能。

本次所分享的案例，是超融合平臺(tái)和Hadoop集群的一次不經(jīng)意間的嘗試，雖然仍然有來自于醫(yī)院同行和專業(yè)廠家技術(shù)大咖的強(qiáng)烈建議：Hadoop是Apache 開源的分布式數(shù)據(jù)計(jì)算框架，一般可以使用在廉價(jià)的硬件設(shè)備組成的服務(wù)器集群上運(yùn)行的應(yīng)用[8]，也就是說，Hadoop 集群正常應(yīng)該與傳統(tǒng)存儲(chǔ)結(jié)合使用，將其跑在超融合平臺(tái)上確實(shí)是有點(diǎn)奢侈，且從存儲(chǔ)磁盤利用率上來講不太劃算，但是考慮到超融合強(qiáng)大的計(jì)算資源、存儲(chǔ)資源和網(wǎng)絡(luò)資源整合池化能力所帶來的I/O 讀寫吞吐的大幅提升能力，以及從兩平臺(tái)互補(bǔ)的數(shù)據(jù)副本安全性角度來看，我們認(rèn)為融合平臺(tái)和Hadoop 集群的“聯(lián)姻”未嘗不可。