超融合架構下部署Hadoop 集群的嘗試與思考

李立

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

隨著醫院信息化建設需求的不斷提高以及相關醫療信息化技術的創新發展，云計算、大數據BI、AI 等信息技術在醫療行業得到廣泛應用[1]。現今，醫學數據呈現出了龐大的大數據特征，數據稀疏、維度提高的數據應該如何科學地進行高效計算、分類存儲、深度挖掘等將成為尚待研究的新興課題。

1 研究背景

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

2 分析

2.1 超融合

2.1.1 關于超融合

超融合架構(Hyper-converged Infrastructure)是指我們在同一套信息設備單元中含有存儲、計算、網絡和虛擬池化等技術，包括數據備份、緩存加速、數據消重、數據壓縮與業務連續性無縫對接保護等因素，多個業務節點通過網絡重組得以實現高可用性的橫向擴展，逐步形成了統一資源池的架構[2]。對于醫院細節方面繁瑣的控制要求較為突出，因為超融合架構的所有資源都是池化處理的，某一節點出現問題的情況下，超融合的機制可以十分有效地避免業務中斷，當業務系統建立的同時也建立了業務系統鏡像，因此，在提高系統容災、冗余方面有著顯著的作用，其工作架構拓撲見圖1。

圖1 超融合架構拓撲圖

2.1.2 關于副本

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

前述超融合能提供可靠的冗余方案，述及關于副本。此次數據中心部署的環境為7 臺混閃節點，考慮到安全冗余度和性能實際使用率，因為超融合集群內有7 臺主機，我們最多能允許有3 臺主機同時發生故障而數據不丟失,所以，此次我們設置的副本數為2，即雙副本機制。

2.2 Hadoop 技術

2.2.1 關于Hadoop

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

2.2.2 關于副本

HDFS (Hadoop Distributed File System)格式即為Hadoop 分布式文件系統。HDFS 有很多特點：①保存了多份副本文件，并且提供豐富的容錯機制，如副本丟失或宕機系統會自動恢復，默認存3 份副本。②運行在廉價的機器上。③適合海量數據的處理分析。

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

2.3 真因

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

3 重構

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

3.1 容量與副本

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

圖2 HDFS 按照Master 和Slave 的結構分布

圖3 HDFS 按默認配置Rack1,Rack2,Rack3

3.2 數據遷移

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

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

3.3 分析

通過對Hadoop 集群內主機的重新調整和數據遷移，整體存儲磁盤進行了重構，既保證了數據的完整性和安全性，又使得超融合平臺內的存儲空間得到大大釋放，使得復雜且異構化的數據存儲在統一平臺實現了數據統一管理[6]。

圖4 調整后的Hadoop01 配置

4 討論

新一代的醫院信息集成平臺和數據中心建設需有大規模、高可用的數據管理系統做支撐，要求對聯機事物處理的支持能力相對強大，才能確保系統具有安全性、可擴充性、可移植性、高效性和可靠性，必須能適應不同的軟硬件架構平臺[7]。醫院信息集成平臺和數據中心建設的系統架構要盡可能采用高性能的服務器集群，且要擁有強大的容災能力和負載均衡性能。

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