醫(yī)療行業(yè)超融合架構(gòu)解決方案
1 設(shè)計(jì)概要
結(jié)合目前醫(yī)療行業(yè)數(shù)據(jù)中心的演進(jìn)方法論及最佳實(shí)踐,建議采用分步分批的建設(shè)方式,使用擴(kuò)展能力強(qiáng),功能豐富的超融合基礎(chǔ)架構(gòu)方案,來滿足醫(yī)院業(yè)務(wù)系統(tǒng)高可靠性、高可用性、業(yè)務(wù)連續(xù)性、數(shù)據(jù)安全、數(shù)據(jù)備份、數(shù)據(jù)及應(yīng)用容災(zāi)的需求。
建議未開始基于超融合架構(gòu)建設(shè)數(shù)據(jù)中心的醫(yī)院,采用分期建設(shè)的方法和設(shè)計(jì)思路。
數(shù)據(jù)中心第一期建設(shè),需要對(duì)現(xiàn)有業(yè)務(wù)系統(tǒng)進(jìn)行深入調(diào)研,分析各個(gè)業(yè)務(wù)系統(tǒng)的需求和特點(diǎn),將適合部署到超融合的系統(tǒng)進(jìn)行統(tǒng)一梳理資源需求,建設(shè)基于超融合架構(gòu)的數(shù)據(jù)中心,然后對(duì)業(yè)務(wù)系統(tǒng)資源進(jìn)行整合。整合后的資源要求能通過超融合系統(tǒng)自帶的管理軟件,結(jié)合醫(yī)院現(xiàn)有云管理平臺(tái)進(jìn)行統(tǒng)一管理,實(shí)現(xiàn)在一個(gè)界面完成對(duì)全院所有資源的管理、分配和運(yùn)維分析等操作。
數(shù)據(jù)中心第二期建設(shè),在管理上,需要實(shí)現(xiàn)高度自動(dòng)化的業(yè)務(wù)部署和運(yùn)維。在建設(shè)上,可以開展網(wǎng)絡(luò)SDN和NFV等系統(tǒng)的建設(shè),這些也都是超融合系統(tǒng)建設(shè)的一部分。即使用通用的硬件服務(wù)器+軟件就可以實(shí)現(xiàn)數(shù)據(jù)中心需要的大部分IT功能,不需要額外再采購專用設(shè)備。SDN可以讓網(wǎng)絡(luò)具有可編程能力,包括能力開放、控制面和數(shù)據(jù)面解耦,以及集中控制等。NFV就是網(wǎng)絡(luò)功能的虛擬化,利用通用的硬件平臺(tái)和虛擬化技術(shù),取代現(xiàn)在的專用網(wǎng)絡(luò)設(shè)備,例如負(fù)載和路由等傳統(tǒng)網(wǎng)絡(luò)設(shè)備。SDN和NFV是兩個(gè)關(guān)系密切,但又相對(duì)獨(dú)立,都可以讓超融合系統(tǒng)的網(wǎng)絡(luò)變得更加開放、敏捷和聰明。
通過超融合系統(tǒng)的建設(shè),最終可以實(shí)現(xiàn)全軟件定義的數(shù)據(jù)中心。有效整合服務(wù)器、存儲(chǔ)和網(wǎng)絡(luò)等資源,最大效率的利用硬件設(shè)備,滿足新的醫(yī)療信息系統(tǒng)各項(xiàng)業(yè)務(wù)的性能需要。同時(shí)還可以對(duì)數(shù)據(jù)中心硬件設(shè)備進(jìn)行有效管理和監(jiān)控,降低運(yùn)維和管理成本。
2 設(shè)計(jì)原則
在方案設(shè)計(jì)中我們將遵循以下總體原則:
1、以醫(yī)院業(yè)務(wù)需求為導(dǎo)向
超融合架構(gòu)最終還是要為醫(yī)療業(yè)務(wù)服務(wù)的,因此在架構(gòu)設(shè)計(jì)上一定要以醫(yī)療業(yè)務(wù)的需求為導(dǎo)向,充分考慮非功能需求,例如系統(tǒng)的重要程度、安全要求、業(yè)務(wù)連續(xù)性等。
2、遵循醫(yī)療行業(yè)標(biāo)準(zhǔn)
醫(yī)院大部分業(yè)務(wù)系統(tǒng)都是面向社會(huì)和公眾的,在醫(yī)院基礎(chǔ)架構(gòu)建設(shè)時(shí),應(yīng)符合國際、國家、醫(yī)療衛(wèi)生行業(yè)標(biāo)準(zhǔn)、規(guī)范和醫(yī)院自身的發(fā)展規(guī)劃。
3、提高資源利用率
現(xiàn)已經(jīng)部署了大量的服務(wù)器,資源使用率低是較突出的一個(gè)問題。要充分發(fā)揮超融合架構(gòu)的這一最大的特點(diǎn),在保證性能的前提下進(jìn)行合理設(shè)計(jì)。在同一設(shè)備中合理分配計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)等虛擬化資源,最大程度的提高服務(wù)器設(shè)備的利用率。
4、系統(tǒng)擴(kuò)展性
在超融合架構(gòu)中,可以進(jìn)行橫向靈活擴(kuò)展,使醫(yī)院的IT基礎(chǔ)架構(gòu)成為一個(gè)動(dòng)態(tài)、靈活、具有彈性的IT基礎(chǔ)架構(gòu)。要考慮在醫(yī)療業(yè)務(wù)系統(tǒng)實(shí)時(shí)運(yùn)行過程中,計(jì)算資源和存儲(chǔ)資源的同時(shí)動(dòng)態(tài)調(diào)整和擴(kuò)展的問題,避免對(duì)現(xiàn)有生產(chǎn)系統(tǒng)產(chǎn)生影響。
5、安全可用性
業(yè)務(wù)系統(tǒng)的高可用性和安全性是醫(yī)院業(yè)務(wù)得以持續(xù)運(yùn)行的保障。在超融合架構(gòu)設(shè)計(jì)中,應(yīng)該以軟件定義技術(shù)為主,結(jié)構(gòu)超融合的分布式架構(gòu)的特點(diǎn),解決系統(tǒng)單點(diǎn)故障問題和性能瓶頸等問題,在滿足業(yè)務(wù)系統(tǒng)可用性的同時(shí)保證醫(yī)院系統(tǒng)運(yùn)行安全和數(shù)據(jù)安全。
3 超融合架構(gòu)總體設(shè)計(jì)
超融合架構(gòu)在數(shù)據(jù)中心,以軟件定義為解決方案,使用通用的X86服務(wù)器+虛擬化軟件建設(shè)計(jì)算、分布式存儲(chǔ)和網(wǎng)絡(luò)等資源池,極大地簡(jiǎn)化了數(shù)據(jù)中心的基礎(chǔ)架構(gòu)。而且通過軟件定義資源池為分布式架構(gòu),可以實(shí)現(xiàn)無單點(diǎn)故障、無單點(diǎn)瓶頸、橫向自動(dòng)彈性擴(kuò)展、性能線性增長(zhǎng)等能力。
在物理層,可以選擇通用的X86服務(wù)器和交換機(jī)。在軟件定義層,可以根據(jù)現(xiàn)有數(shù)據(jù)中心虛擬化的使用情況,結(jié)合未來數(shù)據(jù)中心的發(fā)展技術(shù)路線和方向,選擇合適的虛擬化軟件,例如VMware vSphere、KVM或Hyper-v等,盡量和生產(chǎn)中心保持一致,方便業(yè)務(wù)的轉(zhuǎn)換和遷移。如果選擇開源類產(chǎn)品路線,盡量選擇穩(wěn)定可靠的產(chǎn)品,不要輕易嘗試新出的和不成熟的開源虛擬化產(chǎn)品。
在管理層,大多數(shù)商業(yè)的超融合產(chǎn)品都會(huì)提供一套通過簡(jiǎn)單、方便的管理界面,實(shí)現(xiàn)對(duì)數(shù)據(jù)中心基礎(chǔ)設(shè)施資源的管理。但是數(shù)據(jù)中心如果已經(jīng)有一套云管理平臺(tái),要考慮新采購的超融合系統(tǒng)和已有云管理平臺(tái)的對(duì)接問題。盡可能使用一套云管理平臺(tái),必要時(shí)需要進(jìn)行二次開發(fā),避免出現(xiàn)多套管理系統(tǒng),多個(gè)云管理平臺(tái)。使用一套云管界面對(duì)整個(gè)數(shù)據(jù)中心進(jìn)行統(tǒng)一的監(jiān)控、管理和運(yùn)維。
具體設(shè)計(jì)如下:
一、搭建超融合系統(tǒng)平臺(tái)。
在數(shù)據(jù)中心機(jī)房新建一套超融合系統(tǒng)集群,并對(duì)醫(yī)院現(xiàn)有的業(yè)務(wù)系統(tǒng)進(jìn)行評(píng)估,按照評(píng)估結(jié)果,將適合的業(yè)務(wù)系統(tǒng)和數(shù)據(jù)遷移至超融合平臺(tái),打破原有豎井式的縱向擴(kuò)展架構(gòu)。
HIS/PACS等核心業(yè)務(wù)數(shù)據(jù)庫系統(tǒng)不建議做遷移,由于其對(duì)物理機(jī)性能要求比較高,而且有數(shù)據(jù)一致性要求。而目前市場(chǎng)上各個(gè)廠商的超融合系統(tǒng)的分布式存儲(chǔ)對(duì)數(shù)據(jù)庫支持能力不同,為了保證HIS/PACS等核心業(yè)務(wù)數(shù)據(jù)庫的性能和數(shù)據(jù)的實(shí)時(shí)性,需要對(duì)選定的超融合系統(tǒng)做更詳細(xì)的POC測(cè)試,確定滿足條件后再進(jìn)行遷移。
二、對(duì)原有設(shè)備進(jìn)行淘汰和利舊整合。
建議淘汰的設(shè)備:服役超過5年以上的服務(wù)器,不建議繼續(xù)使用,可以進(jìn)行淘汰處理,避免潛在的安全隱患,同時(shí)還可以降低整體能耗成本。
利舊整合的設(shè)備:可以利舊整合的服務(wù)器主要有兩種解決方案。
首先,可以用于開發(fā)測(cè)試,但是需要注意的是,對(duì)于這部分資源最好單獨(dú)建設(shè)一個(gè)資源分區(qū),不要和生產(chǎn)資源混合在一個(gè)資源池里,做好安全隔離,避免互相影響。其次,可以選擇部分性能比較好,未過保修期(通常服務(wù)器保修年限為三年)且具有整合價(jià)值的服務(wù)器,然后部署超融合系統(tǒng),加入到超融合系統(tǒng)群集當(dāng)中。但是仍然建議單獨(dú)設(shè)計(jì)一個(gè)資源池,不要與新采購的超融合系統(tǒng)混用一個(gè)資源池,同樣做好安全隔離。因?yàn)槔吓f的服務(wù)器,即使部署了相同超融合系統(tǒng)軟件,由于其CPU型號(hào)比較舊,而且型號(hào)不統(tǒng)一,很難和新采購的超融合系統(tǒng)設(shè)備相互兼容,不建議部署在一個(gè)資源池。
三、建立統(tǒng)一的云管理平臺(tái)。
云管理平臺(tái)主要負(fù)責(zé)對(duì)資源的管理、彈性調(diào)度以及操作維護(hù)等綜合管理功能,是云平臺(tái)管理的核心,在同一個(gè)web界面提供云資源管理、云運(yùn)維管理和云服務(wù)管理的功能。在采購新的超融合系統(tǒng)以后,要求必須能夠和現(xiàn)有的云管理平臺(tái)兼容,能夠進(jìn)行二次開發(fā)和對(duì)接?;蛘咧苯硬捎贸诤舷到y(tǒng)的云管理整合原有的虛擬化資源,但是絕不能同時(shí)出現(xiàn)多個(gè)云管理平臺(tái),這樣非常不利于資源的統(tǒng)一管理和調(diào)配,給醫(yī)院的信息化管理帶來很大的困難。
云資源管理負(fù)責(zé)云平臺(tái)資源虛擬化和資源分配,將物理資源(計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等)轉(zhuǎn)換成可動(dòng)態(tài)調(diào)整的虛擬資源,供虛擬機(jī)使用,提供高可用性的彈性虛擬機(jī),保障業(yè)務(wù)系統(tǒng)的連續(xù)性與虛擬機(jī)的安全隔離。
云運(yùn)維管理可以實(shí)現(xiàn)物理設(shè)備、虛擬設(shè)備、應(yīng)用系統(tǒng)的集中監(jiān)控、管理維護(hù)自動(dòng)化與動(dòng)態(tài)化。
云服務(wù)管理對(duì)外的主要工作是實(shí)現(xiàn)用戶管理、集群管理、業(yè)務(wù)模板管理、虛擬機(jī)管理、虛擬機(jī)發(fā)放、統(tǒng)一硬件管理、告警、監(jiān)控等功能。
4 超融合架構(gòu)業(yè)務(wù)設(shè)計(jì)
醫(yī)院業(yè)務(wù)系統(tǒng)分析主要是對(duì)現(xiàn)有醫(yī)院業(yè)務(wù)系統(tǒng)進(jìn)行梳理,對(duì)醫(yī)院的業(yè)務(wù)系統(tǒng)進(jìn)行評(píng)估和分類,選擇適合部署在超融合系統(tǒng)之上的系統(tǒng)。主要包括以下幾個(gè)方面的工作:
1、對(duì)業(yè)務(wù)系統(tǒng)進(jìn)行分析,選擇適合遷移到超融合架構(gòu)的應(yīng)用。建議優(yōu)先從非核心的系統(tǒng)開始嘗試部署,然后逐漸擴(kuò)展到其他核心業(yè)務(wù)系統(tǒng)。
2、評(píng)估并計(jì)算系統(tǒng)資源的使用量,包括計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)和安全資源等。
3、根據(jù)分析出的需要遷移的業(yè)務(wù)系統(tǒng)資源量,評(píng)估現(xiàn)有機(jī)房的物理環(huán)境和網(wǎng)絡(luò)環(huán)境,是否能夠滿足遷移后的超融合系統(tǒng)部署需要。
4、針對(duì)超融合系統(tǒng)的性能需求和擴(kuò)展能力的需求進(jìn)行設(shè)計(jì),為選擇適合的超融合架構(gòu)梳理依據(jù)。
4.1 業(yè)務(wù)遷移分析
醫(yī)院業(yè)務(wù)系統(tǒng)主要分為四大類,分別是:
1、行政管理系統(tǒng)。包括人事管理系統(tǒng),財(cái)務(wù)管理系統(tǒng),后勤管理系統(tǒng),藥庫管理系統(tǒng),醫(yī)療設(shè)備管理系統(tǒng),門診、手術(shù)及住院預(yù)約系統(tǒng),病人住院管理系統(tǒng)等。
2、醫(yī)療管理系統(tǒng)。也是核心業(yè)務(wù)系統(tǒng),主要包括門診、急診管理系統(tǒng)(HIS),影像文件系統(tǒng)(PCAS)、病案管理系統(tǒng),醫(yī)療統(tǒng)計(jì)系統(tǒng),血庫管理系統(tǒng)等。
3、決策支持系統(tǒng)。包括醫(yī)療質(zhì)量評(píng)價(jià)系統(tǒng),醫(yī)療質(zhì)量控制系統(tǒng)等。
4、各種輔助系統(tǒng)。如醫(yī)療情報(bào)檢索系統(tǒng),醫(yī)療數(shù)據(jù)庫系統(tǒng)等。
以上業(yè)務(wù)系統(tǒng),除了核心HIS和PACS數(shù)據(jù)庫外,其實(shí)大部分系統(tǒng)都適合遷移至超融合系統(tǒng),對(duì)于業(yè)務(wù)系統(tǒng)的最終選擇,還是需要分析其運(yùn)行和使用的現(xiàn)狀,可以按照以下情況進(jìn)行判斷。
1、原有業(yè)務(wù)系統(tǒng)運(yùn)行在物理機(jī)上,且物理機(jī)的資源利用率非常低。
建議盡快遷移到超融合架構(gòu)上,可以最大程度提高醫(yī)院信息系統(tǒng)的靈活性和設(shè)備使用率。遷移成功的前提是,原有業(yè)務(wù)系統(tǒng)的開發(fā)商需要能夠提供必要的支持,否則遷移部署和驗(yàn)證可能會(huì)有些困難。
2、原有業(yè)務(wù)系統(tǒng)運(yùn)行在物理機(jī)上,且物理機(jī)的資源利用率非常高。
通常核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫屬于這一類的應(yīng)用,不建議遷移到超融合平臺(tái)之上,否則性能問題會(huì)是個(gè)極大的挑戰(zhàn)。
3、原有業(yè)務(wù)系統(tǒng)運(yùn)行在虛擬機(jī)上,且虛擬機(jī)軟件的類別、版本和預(yù)期采購超融合系統(tǒng)基本保持一致。
對(duì)于這類應(yīng)用,遷移是非常容易的,只需要將虛擬機(jī)直接遷移到超融合平臺(tái)上就好,不會(huì)存在太多的障礙,可以完全加入到遷移的名單中。
4、原有業(yè)務(wù)系統(tǒng)運(yùn)行在虛擬機(jī)上,且虛擬機(jī)軟件的類別、版本和預(yù)期采購超融合系統(tǒng)完全不一致。
對(duì)于這類應(yīng)用,遷移可能會(huì)有些麻煩,要看是否能夠找到合適的V2V遷移轉(zhuǎn)換工作。否則就需要在超融合系統(tǒng)上重新部署,然后再遷移數(shù)據(jù)。如果要將這類應(yīng)用加入到遷移名單中,需要提前做好POC測(cè)試工作。
4.2 業(yè)務(wù)資源分析
在超融合平臺(tái)實(shí)施前,必須根據(jù)現(xiàn)有需要遷移的業(yè)務(wù)進(jìn)行資源分析,確定超融合系統(tǒng)設(shè)備的資源使用量。
主要分析的內(nèi)容是對(duì)現(xiàn)有業(yè)務(wù)系統(tǒng)的計(jì)算、存儲(chǔ)等性能進(jìn)行分析。最終得出超融合系統(tǒng)的規(guī)劃配置內(nèi)容,包括超融合集群數(shù)量、容量規(guī)劃、性能、應(yīng)用需求等,可以指導(dǎo)超融合系統(tǒng)實(shí)施策略和實(shí)施路線規(guī)劃。
通過最終的超融合系統(tǒng)資源需求統(tǒng)計(jì),可以得出超融合系統(tǒng)的CPU、內(nèi)存和存儲(chǔ)容量,然后選擇合適的超融合節(jié)點(diǎn)數(shù)量和群集規(guī)模。
CPU的數(shù)量通常決定了超融合系統(tǒng)的節(jié)點(diǎn)數(shù)量和群集規(guī)模。超融合系統(tǒng)通常都是一臺(tái)2U高的X86服務(wù)器。高密度的X86服務(wù)器,每臺(tái)可以提供2-4個(gè)Node(節(jié)點(diǎn))的資源。每個(gè)節(jié)點(diǎn)通常為1-2顆CPU+可選容量的內(nèi)存(CPU核心數(shù)量和內(nèi)存容量可以根據(jù)需求來進(jìn)行選擇)。從技術(shù)上講,有些廠商的超融合系統(tǒng)是不限制單個(gè)群集的節(jié)點(diǎn)規(guī)模數(shù)量的,但是最佳實(shí)踐是一般單個(gè)群集不建議超過64個(gè)節(jié)點(diǎn),比較方便管理,性能上也比較可靠。
存儲(chǔ)容量的配置需要根據(jù)原有業(yè)務(wù)的容量進(jìn)行定量分析后得出。例如:原有存儲(chǔ)配置100TB SATA磁盤,那么超融合架構(gòu)也需要配置同樣的資源,避免浪費(fèi)。為了保證數(shù)據(jù)的冗余性和可靠性,通常分布式存儲(chǔ)都是多副本的,而且以3副本最為常見,所以在配置物理容量時(shí),需要將實(shí)際數(shù)據(jù)融量至少乘以3倍,而且大部分分布式存儲(chǔ)系統(tǒng)都是以SSD磁盤作為緩存使用,這部分SSD的存儲(chǔ)容量是不能計(jì)算在內(nèi)的。
現(xiàn)有虛擬化系統(tǒng)環(huán)境類型決定了超融合產(chǎn)品的實(shí)施策略和實(shí)施路線,因?yàn)椴皇撬械某诤袭a(chǎn)品都支持全部的虛擬化層軟件。例如VMware就不支持KVM,無法直接進(jìn)行遷移。如果采用支持KVM的超融合系統(tǒng),那么原有的VMware虛擬機(jī)就需要進(jìn)行遷移轉(zhuǎn)換后,才可以在基于KVM的超融合系統(tǒng)上運(yùn)行。
在物理網(wǎng)絡(luò)資源的定量分析上,也需要考慮新的超融合系統(tǒng)的網(wǎng)卡性能和數(shù)量,如果原有系統(tǒng)環(huán)境全部為雙鏈路萬兆網(wǎng)絡(luò),那么新組建的超融合網(wǎng)絡(luò)也必須是雙鏈路萬兆網(wǎng)絡(luò)。而且網(wǎng)段數(shù)量至少要增加兩個(gè),一個(gè)內(nèi)部通訊網(wǎng)絡(luò)和一個(gè)管理網(wǎng)絡(luò)。網(wǎng)卡同時(shí)也需要增加兩塊。
5 超融合架構(gòu)物理資源規(guī)劃
5.1 物理架構(gòu)圖
物理架構(gòu)圖描述:
基于超融合架構(gòu)的數(shù)據(jù)中心,在網(wǎng)絡(luò)上采用扁平化二層網(wǎng)絡(luò)架構(gòu)(核心層、接入層),使用網(wǎng)絡(luò)虛擬化技術(shù),核心交換機(jī)承擔(dān)著核心層和匯聚層的雙重任務(wù)。
扁平化方式降低了網(wǎng)絡(luò)復(fù)雜度,簡(jiǎn)化了網(wǎng)絡(luò)拓?fù)?,提高了轉(zhuǎn)發(fā)效率。二層網(wǎng)絡(luò)架構(gòu)中,采用虛擬集群和堆疊技術(shù),解決鏈路環(huán)路問題,提高了網(wǎng)絡(luò)可靠性。核心交換機(jī)設(shè)置VLAN的IP地址,接入交換機(jī)劃分VLAN,做二層轉(zhuǎn)發(fā)。
在邏輯上,超融合架構(gòu)不改變?cè)嗅t(yī)院生產(chǎn)中心網(wǎng)絡(luò)架構(gòu)。原有設(shè)備網(wǎng)絡(luò)、服務(wù)器、存儲(chǔ)和安全等設(shè)備可以繼續(xù)利舊使用。
針對(duì)新購買的超融合設(shè)備,需要單獨(dú)設(shè)立二個(gè)安全域,分別為超融合系統(tǒng)安全區(qū)和超融合系統(tǒng)利舊資源區(qū),分別部署新采購的和利舊的超融合服務(wù)器設(shè)備。為了保證傳統(tǒng)業(yè)務(wù)的可靠的運(yùn)行,需要與傳統(tǒng)架構(gòu)區(qū)的設(shè)備進(jìn)行安全隔離,但是都處于內(nèi)網(wǎng),是可以互相訪問的,不影響系統(tǒng)的正常訪問和運(yùn)行。為了保障內(nèi)網(wǎng)的數(shù)據(jù)安全和網(wǎng)絡(luò)安全,外網(wǎng)用戶訪問仍需要通過VPN授權(quán)才可以訪問內(nèi)網(wǎng)數(shù)據(jù),通過DMZ區(qū)訪問web服務(wù)。
超融合架構(gòu)物理機(jī)一般為機(jī)架服務(wù)器。同時(shí)融合計(jì)算和存儲(chǔ)資源,提供虛擬化資源。每臺(tái)服務(wù)器配置1塊2端口的10GE網(wǎng)卡。通過萬兆接入交換機(jī)和核心交換機(jī)進(jìn)行連接。配置2個(gè)千兆網(wǎng)絡(luò),一個(gè)連接生產(chǎn)網(wǎng)絡(luò),一個(gè)連接管理網(wǎng)絡(luò)。
超融合架構(gòu)物理機(jī)存儲(chǔ)系統(tǒng)采用分布式架構(gòu),通常配置有SSD+HDD或者全閃存磁盤的模式??梢愿鶕?jù)數(shù)據(jù)存儲(chǔ)需要進(jìn)行配置。對(duì)于超融合系統(tǒng)的存儲(chǔ),要求支持多副本存儲(chǔ)、數(shù)據(jù)本地化、熱點(diǎn)數(shù)據(jù)自動(dòng)分層。另外,可以根據(jù)需求選擇在線重刪、壓縮、快照、克隆、同/異步備份和跨地域遠(yuǎn)程數(shù)據(jù)容災(zāi)等高級(jí)功能。
5.2 計(jì)算資源規(guī)劃
計(jì)算資源是通過對(duì)x86服務(wù)器CPU虛擬化來實(shí)現(xiàn)的,根據(jù)現(xiàn)有虛擬化環(huán)境,可選擇VMware vSphere、MicroSoft Hyper-v或KVM等Hypervisor,通過虛擬化技術(shù)組建計(jì)算資源池,為業(yè)務(wù)系統(tǒng)的虛擬機(jī)提供不同的服務(wù)質(zhì)量和能力。以VMware為例,可提供HA高可用、FT容錯(cuò)、vMotion在線遷移和DRS資源動(dòng)態(tài)負(fù)載均衡等能力。
計(jì)算資源的規(guī)劃需要根據(jù)歷史業(yè)務(wù)對(duì)資源的需求推導(dǎo)出需要新采購的超融合服務(wù)器的數(shù)量。包括遷移場(chǎng)景需要的服務(wù)器數(shù)量和新建場(chǎng)景需要的服務(wù)器數(shù)量。如果沒有可供利舊的服務(wù)器,那么這兩個(gè)部分相加,就是全部的計(jì)算資源總量。
遷移場(chǎng)景和新建場(chǎng)景由于維度不一樣,統(tǒng)計(jì)出的服務(wù)器數(shù)量可能也會(huì)有所偏差,通常需要綜合進(jìn)行考量評(píng)估,建議以服務(wù)器數(shù)量多的數(shù)值做為參考。
5.2.1 遷移場(chǎng)景服務(wù)器數(shù)量規(guī)劃
這里借鑒并提供華為的服務(wù)器數(shù)量估算方法論做為參考,為簡(jiǎn)化計(jì)算過程,所有管理、計(jì)算和存儲(chǔ)虛擬化軟件節(jié)點(diǎn)的CPU資源開銷按照10%進(jìn)行計(jì)算,內(nèi)存資源開銷按照每臺(tái)物理機(jī)100GB進(jìn)行估算。
注:CPU和內(nèi)存的開銷需要按照預(yù)計(jì)采購的超融合系統(tǒng)進(jìn)行修正。
5.2.1.1 從計(jì)算服務(wù)器CPU維度進(jìn)行估算
使用SPECint2006 Rate進(jìn)行折算。
單服務(wù)器需要計(jì)算能力=物理服務(wù)器的SPECCPU使用率/(1-CPU冗余度)
(1)現(xiàn)有舊物理服務(wù)器計(jì)算能力折算方法:
所有n臺(tái)原服務(wù)器CPU能力折算值x=服務(wù)器1的SPEC值CPU使用率1/(1-CPU冗余度)
+ 服務(wù)器2的SPEC值CPU使用率2/(1-CPU冗余度)
+ …..
+ 服務(wù)器n的SPEC值CPU使用率n/(1-CPU冗余度)
(2)部署虛擬化平臺(tái)的物理服務(wù)器的CPU能力計(jì)算方法:
假設(shè)部署虛擬化平臺(tái)的單個(gè)物理服務(wù)器的SPEC值為y,單物理服務(wù)器的總邏輯核數(shù)為z。
虛擬化服務(wù)器的數(shù)量 N = x/(y90%),結(jié)果向上取其整數(shù)即可。如果數(shù)量≤3,那么至少配置3臺(tái)。
舉例:
比如40臺(tái)型號(hào)為:Dell Inc. PowerEdge 2950 x64-based PC Intel(R) Xeon(R) CPU E5420 @2.50GHz, 2493 Mhz, 4 Core(s), 4 Logical Processor(s) 8.00GB的服務(wù)器的實(shí)際平均CPU使用率為30%。
獲取其SPEC值為118。假定虛擬化后的目標(biāo)CPU能力冗余度30%。
x = 40(11830%/(1-30%))=2022.857
若最終選擇Intel Xeon E5-4610 ,得到其SPEC值為883。服務(wù)器共48邏輯核,部署所有管理、計(jì)算和存儲(chǔ)虛擬化軟件節(jié)點(diǎn)的CPU資源開銷為10%。
虛擬化服務(wù)器的數(shù)量N=2022.857/(88390%)=2.545,虛擬化服務(wù)器的數(shù)量為3臺(tái)。
5.2.1.2 從計(jì)算服務(wù)器內(nèi)存維度進(jìn)行估算
直接使用內(nèi)存使用量進(jìn)行計(jì)算。
單計(jì)算服務(wù)器實(shí)際需要的內(nèi)存(虛擬化后)=現(xiàn)有物理服務(wù)器的內(nèi)存內(nèi)存使用率/(1-內(nèi)存冗余度)
(1)現(xiàn)有物理服務(wù)器內(nèi)存折算方法:
所有n臺(tái)原服務(wù)器內(nèi)存折算值 x = 現(xiàn)有服務(wù)器1的內(nèi)存值內(nèi)存使用率1/(1-內(nèi)存冗余度)
+現(xiàn)有服務(wù)器2的內(nèi)存值內(nèi)存使用率2/(1-內(nèi)存冗余度)
+ …..
+現(xiàn)有服務(wù)器n的內(nèi)存值內(nèi)存使用率n/(1-內(nèi)存冗余度)
(2)所需虛擬化服務(wù)器的內(nèi)存計(jì)算方法:
假設(shè)虛擬化后的單個(gè)服務(wù)器的內(nèi)存值為 z。部署所有管理、計(jì)算和存儲(chǔ)虛擬化軟件節(jié)點(diǎn)的內(nèi)存資源開銷為100GB。虛擬化后的服務(wù)器實(shí)際能給虛擬機(jī)用的內(nèi)存y=z-100GB,每臺(tái)至少配置100GB以上,建議配置256GB。
虛擬化服務(wù)器的數(shù)量 N = x/y,結(jié)果向上取其整數(shù)即可。如果數(shù)量≤3,那么至少配置3臺(tái)。如果數(shù)量太多,請(qǐng)?jiān)黾訂闻_(tái)服務(wù)器的內(nèi)存容量。
舉例:
假定原服務(wù)器的內(nèi)存大小為8G,內(nèi)存使用率為20%,共40臺(tái)。虛擬化后的目標(biāo)內(nèi)存冗余度為40%
x =40( 820%/(1-40%))=106.7GB
假定Intel Xeon E5-4610配置256GB內(nèi)存(要求必須大于100GB),則實(shí)際可用的內(nèi)存為:
y=z-100GB
=256GB-100GB
=156GB
從內(nèi)存容量上看,需要純計(jì)算節(jié)點(diǎn)的個(gè)數(shù):
虛擬化服務(wù)器的數(shù)量 N = x/y=106.7GB/156GB=0.684,虛擬化服務(wù)器的數(shù)量為3臺(tái)。
5.2.2 新建場(chǎng)景服務(wù)器數(shù)量規(guī)劃
這里借鑒并提供華為的服務(wù)器數(shù)量估算方法論做為參考,為簡(jiǎn)化計(jì)算過程,所有管理、計(jì)算和存儲(chǔ)虛擬化軟件節(jié)點(diǎn)的CPU資源開銷按照10%進(jìn)行計(jì)算,內(nèi)存資源開銷按照每臺(tái)物理機(jī)100GB進(jìn)行估算。
注:CPU和內(nèi)存的開銷需要按照預(yù)計(jì)采購的超融合系統(tǒng)進(jìn)行修正。
5.2.2.1 根據(jù)CPU資源需求維度估算
適用于對(duì)虛擬化后使用虛擬機(jī)規(guī)格(CPU、內(nèi)存、磁盤、網(wǎng)卡)、虛擬機(jī)的數(shù)量都有清晰認(rèn)識(shí)的場(chǎng)景,能夠規(guī)劃出各類虛擬機(jī)的規(guī)格和所需的數(shù)量:
總vCPU數(shù)=預(yù)計(jì)部署的每臺(tái)VM虛擬機(jī)的vCPU數(shù)量的總和
注:vCPU是衡量一臺(tái)虛擬機(jī)計(jì)算能力的主要指標(biāo),類似物理服務(wù)器的CPU。vCPU核數(shù)類似服務(wù)器CPU的核數(shù)(core)。一個(gè)利用率100%的vCPU的處理能力等于物理CPU一個(gè)超線程的處理能力。
1、根據(jù)計(jì)算能力總需求估算
CPU總物理核數(shù)=roundup(總vCPU數(shù)/單核超線程數(shù)/CPU利用率)
2、估算所需的服務(wù)器數(shù)量
物理服務(wù)器數(shù)量=roundup{[(CPU總物理核數(shù)/(服務(wù)器CPU個(gè)數(shù)CPU物理核數(shù))90%](1+服務(wù)器冗余率)}
結(jié)果向上取其整數(shù)即可。如果數(shù)量≤3,那么至少配置3臺(tái)。
舉例:
假定總vCPU的數(shù)量為100,服務(wù)器冗余率設(shè)定為30%,CPU利用率不超過70%,部署所有管理、計(jì)算和存儲(chǔ)虛擬化軟件節(jié)點(diǎn)的CPU資源開銷為10%,擬定選擇的超融合服務(wù)器為2顆12核心處理器2線程處理器。那么:
CPU總物理核數(shù)=roundup(總vCPU數(shù)/單核超線程數(shù)/CPU利用率)
= roundup(100/2/0.7)
=72
物理服務(wù)器數(shù)量為=roundup{[(72/(212)90%](1+30%)}
= roundup{4.3}
物理服務(wù)器數(shù)量:需要5臺(tái)。
5.2.2.2 根據(jù)內(nèi)存資源需求維度估算
1、內(nèi)存總需求
總內(nèi)存=預(yù)計(jì)部署的每臺(tái)VM虛擬機(jī)的內(nèi)存數(shù)量的總和
注:內(nèi)存大小是指虛擬機(jī)內(nèi)存的最大規(guī)格值。
2、根據(jù)內(nèi)存總需求估算
根據(jù)內(nèi)存資源需求估算的服務(wù)器數(shù)量= roundup[(總內(nèi)存/(單服務(wù)器內(nèi)存容量-100GB)(1+服務(wù)器冗余率)]
結(jié)果向上取其整數(shù)即可。如果數(shù)量≤3,那么至少配置3臺(tái)。如果數(shù)量太多,請(qǐng)?jiān)黾訂闻_(tái)服務(wù)器的內(nèi)存容量。
舉例:
假定總內(nèi)存的數(shù)量為360GB,服務(wù)器冗余率設(shè)定為30%,部署所有管理、計(jì)算和存儲(chǔ)虛擬化軟件節(jié)點(diǎn)的內(nèi)存資源開銷為100GB,擬定選擇的超融合服務(wù)器為256GB內(nèi)存(至少100GB以上)。
物理服務(wù)器數(shù)量=roundup[(總內(nèi)存/(單服務(wù)器內(nèi)存容量-100GB)(1+服務(wù)器冗余率)]
=roundup[(360GB/(256GB-100GB)*(1+30%)]
=roundup[3]
物理服務(wù)器數(shù)量:需要3臺(tái)
5.3 存儲(chǔ)資源規(guī)劃
超融合系統(tǒng)架構(gòu)提供的存儲(chǔ)資源,都是基于分布式的文件系統(tǒng),可以將一組集群內(nèi)的節(jié)點(diǎn)組成一個(gè)統(tǒng)一的分布式存儲(chǔ)平臺(tái)。對(duì)于業(yè)務(wù)系統(tǒng)來說,就是一個(gè)集中的共享式存儲(chǔ),與任何其他集中式存儲(chǔ)陣列一樣工作,由超融合存儲(chǔ)系統(tǒng)管理模塊對(duì)分布式存儲(chǔ)進(jìn)行管理。
超融合分布式存儲(chǔ)系統(tǒng)的配置規(guī)劃,需要根據(jù)歷史業(yè)務(wù)對(duì)資源的需求推導(dǎo)出需要新采購的超融合服務(wù)器的硬盤數(shù)量。包括遷移場(chǎng)景需要的硬盤數(shù)量和新建場(chǎng)景需要的硬盤數(shù)量。如果沒有可供利舊的服務(wù)器,那么這兩個(gè)部分相加,就是全部的計(jì)算資源總量。為了減小不必要要的服務(wù)器數(shù)量,單盤盡量選擇1.2TB或1.8TB產(chǎn)品。當(dāng)然,為了使用更多的硬盤提升分布式存儲(chǔ)性能,還需要綜合考量。
以上除了需要提前確認(rèn)好數(shù)據(jù)容量以外,還需要注意以下幾點(diǎn):
1、分布式存儲(chǔ)架構(gòu)以可以提供傳統(tǒng)集中式存儲(chǔ)的能力,包括塊存儲(chǔ)、文件存儲(chǔ)和對(duì)象存儲(chǔ)等。但并不是所有的超融合系統(tǒng)都能提供以上的存儲(chǔ)能力。由于分布式存儲(chǔ)的數(shù)據(jù)一致性不是很好,所以有些超融合系統(tǒng)提供的塊存儲(chǔ)服務(wù)是不能夠安裝ORACLE這類數(shù)據(jù)庫應(yīng)用的,即使能安裝,效果也不會(huì)很好,性能會(huì)比較低。需要官方給出可安裝的測(cè)試報(bào)告或者兼容性測(cè)試報(bào)告。
2、是否需要超融合存儲(chǔ)系統(tǒng)提供快照、克隆、壓縮和重復(fù)數(shù)據(jù)刪除等傳統(tǒng)集中式存儲(chǔ)的特性。由于超融合系統(tǒng)也是近幾年剛剛興起,對(duì)于這類高級(jí)特性不如傳統(tǒng)集中式存儲(chǔ)支持的好,如果需要某種高級(jí)特性,需要提前對(duì)超融合廠商的相關(guān)存儲(chǔ)產(chǎn)品進(jìn)行調(diào)研,做好POC測(cè)試。
3、分布式存儲(chǔ)資源池的組成通常為SSD+HDD的架構(gòu),SSD作為緩存盤,提升整個(gè)系統(tǒng)的性能。而且有的廠商要求嚴(yán)格的資源配比,以VSAN為例,需要1塊SSD+最多6塊HDD為一個(gè)邏輯磁盤組(VMware計(jì)劃增加到最多7塊)。而且1臺(tái)物理主機(jī)最多只能有5個(gè)磁盤組。所以物理磁盤不能隨意配置,需要根據(jù)超融合廠商的技術(shù)要求進(jìn)行合理配置,避免資源浪費(fèi)。當(dāng)然也有的超融合廠商支持全閃存的架構(gòu),甚至可以使用PCI-E的SSD緩存卡進(jìn)行加速,只是在成本上比較貴。
4、超融合的節(jié)點(diǎn)的硬盤數(shù)量會(huì)影響整個(gè)分布式存儲(chǔ)系統(tǒng)的性能。如果超融合系統(tǒng)只有最少的3個(gè)節(jié)點(diǎn),那么分布式存儲(chǔ)系統(tǒng)的性能上基本上是無法超越傳統(tǒng)集中式架構(gòu)存儲(chǔ)的,只有盡可能多的配置節(jié)點(diǎn)數(shù)量和硬盤數(shù)量,才有可能達(dá)到甚至超越傳統(tǒng)集中式存儲(chǔ)的性能。
5.3.1 遷移場(chǎng)景存儲(chǔ)容量規(guī)劃
這里借鑒并提供華為的存儲(chǔ)容量估算方法論做為參考。由于IOPS不太容易評(píng)估,為簡(jiǎn)化計(jì)算過程,只考慮容量的計(jì)算。對(duì)于分布式存儲(chǔ)的性能規(guī)劃,建議通過POC測(cè)試進(jìn)行,理論和實(shí)際往往差距較大。
容量計(jì)算:
基礎(chǔ)數(shù)據(jù):總的有效容量=x,磁盤標(biāo)稱容量=z,磁盤空間利用率=q,副本數(shù)=k
總的硬盤數(shù)量=roundup[總的有效容量/(zq)k](向上取整)
舉例:
假定現(xiàn)有需要遷移的數(shù)據(jù),總計(jì)20000GB,預(yù)計(jì)購買的超融合服務(wù)器每臺(tái)的磁盤標(biāo)稱容量z=1200GB,磁盤空間利用率q=0.95,副本數(shù)k=3.
按容量計(jì)算,硬盤數(shù)量為:
則利用上述公式:
總的硬盤數(shù)量= roundup[20000/(1200GB0.95)3]
總的硬盤數(shù)量= roundup[20000/(1140)*3]
總的硬盤數(shù)量= roundup[52.633]
總的硬盤數(shù)量為53塊硬盤,每塊盤容量至少為1200GB。
如果要加入SSD固態(tài)硬盤做熱點(diǎn)遷移和自動(dòng)分層,需要按照超融合系統(tǒng)要求的比例,購買SSD固態(tài)硬盤。
5.3.2 新建場(chǎng)景存儲(chǔ)容量規(guī)劃
這里借鑒并提供華為的存儲(chǔ)容量估算方法論做為參考。由于IOPS不太容易評(píng)估,為簡(jiǎn)化計(jì)算過程,只考慮容量的計(jì)算。對(duì)于分布式存儲(chǔ)的性能規(guī)劃,建議通過POC測(cè)試進(jìn)行,理論和實(shí)際往往差距較大。
1、存儲(chǔ)總?cè)萘啃枨?
類型i系統(tǒng)盤容量=系統(tǒng)盤空間×VM數(shù)量;
系統(tǒng)盤總?cè)萘?∑類型i系統(tǒng)盤容量
類型i數(shù)據(jù)盤容量=數(shù)據(jù)盤空間×VM數(shù)量;
數(shù)據(jù)盤總?cè)萘?∑類型i數(shù)據(jù)盤容量
2、根據(jù)存儲(chǔ)總需求估算
根據(jù)存儲(chǔ)空間計(jì)算所需的硬盤數(shù)量:
總的硬盤數(shù)量=roundup[(系統(tǒng)盤總?cè)萘?數(shù)據(jù)盤總?cè)萘浚└北緮?shù)k/單盤容量z/磁盤容量利用率q]
舉例:
假定現(xiàn)有虛擬機(jī)VM數(shù)量為100個(gè),每個(gè)操作系統(tǒng)占用30GB空間,每個(gè)虛擬機(jī)數(shù)據(jù)盤空間需求為50GB。預(yù)計(jì)購買的超融合服務(wù)器每臺(tái)的磁盤標(biāo)稱容量z=1200GB,磁盤空間利用率q=0.95,副本數(shù)k=3.
系統(tǒng)盤總?cè)萘?30GB100=30000GB
數(shù)據(jù)盤總?cè)萘?50GB100=50000GB
按容量計(jì)算,硬盤數(shù)量為:
總的硬盤數(shù)量=roundup[(30TB+50TB)3/1.2TB/0.95]
= roundup[80tb*3/1.2TB/0.95]
= roundup[210.53]
總的硬盤數(shù)量為211塊硬盤,每塊盤容量至少為1200GB。
如果要加入SSD固態(tài)硬盤做熱點(diǎn)遷移和自動(dòng)分層,需要按照超融合系統(tǒng)要求的比例,購買SSD固態(tài)硬盤。
5.4 網(wǎng)絡(luò)資源規(guī)劃
5.4.1 組網(wǎng)策略
在超融合的架構(gòu)中,多臺(tái)虛擬機(jī)之間是共享網(wǎng)絡(luò)的,為了方便管理,一般采用虛擬交換機(jī)來配置和管理網(wǎng)絡(luò),虛擬交換機(jī)可在數(shù)據(jù)中心級(jí)別提供集中和聚合的虛擬網(wǎng)絡(luò),從而簡(jiǎn)化并增強(qiáng)虛擬機(jī)網(wǎng)絡(luò)。在虛擬交換機(jī)的網(wǎng)絡(luò)劃分上,仍然可以采用VLAN的方式劃分不同的子網(wǎng),實(shí)現(xiàn)不同子網(wǎng)段的安全和隔離。
除了虛擬交換機(jī),還可以通過Overlay的方式來構(gòu)建大二層和實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)之間的租戶隔離,通過NFV實(shí)現(xiàn)網(wǎng)絡(luò)中的所需各類網(wǎng)絡(luò)功能資源(包括基礎(chǔ)的路由交換、安全以及應(yīng)用交付等)按需分配和靈活調(diào)度,從而實(shí)現(xiàn)超融合架構(gòu)中的網(wǎng)絡(luò)虛擬化。這類功能同時(shí)需要客戶的物理交換機(jī)支持SDN的管理方式,如果是一些老舊設(shè)備,可能無法實(shí)現(xiàn),需要購置新的交換機(jī)設(shè)置。
5.4.2 網(wǎng)絡(luò)拓?fù)?
在每個(gè)單節(jié)點(diǎn)的物理機(jī)上,需要提供以下網(wǎng)絡(luò)端口:
萬兆光口:至少1個(gè)
千兆電口:至少2個(gè)
在每個(gè)超融合物理節(jié)點(diǎn)上有多種網(wǎng)絡(luò)需求,包括生產(chǎn)網(wǎng)絡(luò)、數(shù)據(jù)交換網(wǎng)絡(luò)、管理網(wǎng)絡(luò)、生產(chǎn)網(wǎng)絡(luò)等,因此每個(gè)物理節(jié)點(diǎn)建議配置多塊網(wǎng)卡,并保證每個(gè)節(jié)點(diǎn)通過兩條萬兆或千兆鏈路分別連接兩臺(tái)交換機(jī),保證網(wǎng)絡(luò)設(shè)備和鏈路的冗余度。
網(wǎng)絡(luò)設(shè)計(jì)建議如下:
1、生產(chǎn)網(wǎng)絡(luò)(原有生產(chǎn)網(wǎng)絡(luò),同時(shí)也是客戶機(jī)和虛擬化服務(wù)器之間的網(wǎng)絡(luò)通訊)
可采用雙鏈路千兆以太網(wǎng)絡(luò),如果原有雙鏈路萬兆網(wǎng)絡(luò),那么可以繼續(xù)延用。當(dāng)用戶的客戶機(jī)訪問虛擬服務(wù)器時(shí),通過生產(chǎn)網(wǎng)絡(luò)可分流后端存儲(chǔ)流量并且進(jìn)行隔離。
2、數(shù)據(jù)交換網(wǎng)(X86物理服務(wù)器之間的內(nèi)部通訊網(wǎng)絡(luò))
至少采用雙鏈路萬兆光纖網(wǎng)絡(luò),由于分布式存儲(chǔ)數(shù)據(jù)交換和虛擬機(jī)之間的通訊都需要占用大量的網(wǎng)絡(luò)帶寬,當(dāng)發(fā)生密集的寫IO時(shí),萬兆網(wǎng)絡(luò)能保證提供足夠帶寬滿足節(jié)點(diǎn)之間的IO同步流量。建議單獨(dú)配置1塊萬兆網(wǎng)卡。
3、管理網(wǎng)絡(luò)(管理X86物理服務(wù)器節(jié)點(diǎn))
可采用雙鏈路千兆以太網(wǎng)絡(luò),主要用于節(jié)點(diǎn)管理。建議單獨(dú)配置1塊千兆網(wǎng)卡,實(shí)現(xiàn)管理網(wǎng)絡(luò)與業(yè)務(wù)網(wǎng)絡(luò)、存儲(chǔ)網(wǎng)絡(luò)分離??梢宰畲笙薅缺WC管理的靈活性和安全性。
5.5 安全和備份規(guī)劃
超融合系統(tǒng)的設(shè)計(jì)還需要考慮安全設(shè)計(jì)。
首先,在物理安全上,建議將超融合節(jié)點(diǎn)分別部署到3個(gè)不同的機(jī)柜中,每個(gè)機(jī)柜部署1個(gè)節(jié)點(diǎn),最大化做到故障域的隔離。每個(gè)機(jī)柜雙路供電,實(shí)現(xiàn)真正的供電冗余。
其次,要考慮滿足國家等保的要求還有醫(yī)療客戶自身的安全需求。在安全產(chǎn)品的部署上,可以延用原有的安全設(shè)備,也可以選擇支持安全虛擬化的超融合產(chǎn)品。例如深信服超融合產(chǎn)品,可以集成集成分布式防火墻、4-7層虛擬防火墻、虛擬數(shù)據(jù)庫審計(jì)等虛擬安全組件,并結(jié)合深信服安全產(chǎn)品,幫助客戶構(gòu)建從邊界安全、平臺(tái)安全、數(shù)據(jù)安全到應(yīng)用安全的全方位安全防護(hù)體系,并利用安全可視化,對(duì)安全事件全過程進(jìn)行安全保障:事前漏洞評(píng)估,事中全方位防護(hù),事后持續(xù)威脅檢測(cè)。
超融合架構(gòu)可以提供跨數(shù)據(jù)中心的容災(zāi)及應(yīng)用級(jí)高可用解決方案。超融合架構(gòu)具備面向數(shù)據(jù)的備份及恢復(fù)機(jī)制,以更經(jīng)濟(jì)的方式實(shí)現(xiàn)數(shù)據(jù)的安全存儲(chǔ)和管理,并結(jié)合負(fù)載均衡、虛擬化軟件層高可用機(jī)制,提供了應(yīng)用層面的跨數(shù)據(jù)中心業(yè)務(wù)連續(xù)性訪問能力。
大部分超融合系統(tǒng)都可以提供基于虛擬機(jī)快照的方式將更新數(shù)據(jù)異步復(fù)制到遠(yuǎn)端的超融合系統(tǒng)集群中。如果有容災(zāi)建設(shè)的需求,需要提前規(guī)劃好容災(zāi)復(fù)制模式,選擇合適的雙向復(fù)制、一對(duì)多復(fù)制或者多對(duì)一的數(shù)據(jù)復(fù)制模式。
傳統(tǒng)的備份方式通過網(wǎng)絡(luò)傳輸備份數(shù)據(jù),需要特定的備份窗口以免影響業(yè)務(wù)正常運(yùn)行。超融合產(chǎn)品備份可以與傳統(tǒng)的備份策略互補(bǔ),既能保證對(duì)于重要的虛擬機(jī)進(jìn)行高頻次備份又不會(huì)占用額外的網(wǎng)絡(luò)帶寬。
例如:對(duì)于普通虛擬機(jī)可以使用傳統(tǒng)的備份方式每周進(jìn)行全備,將備份數(shù)據(jù)備份到外部存儲(chǔ)中,同時(shí)使用超融合自帶的備份管理系統(tǒng)進(jìn)行每天甚至每12小時(shí)的備份,數(shù)據(jù)直接保留在存儲(chǔ)上以便快速恢復(fù)。對(duì)于比較重要的虛擬機(jī)可以使用傳統(tǒng)備份每周全備、每天增量的方式,將備份數(shù)據(jù)備份到外部存儲(chǔ)中,同時(shí)使用超融合自帶的備份管理系統(tǒng)進(jìn)行每2小時(shí)甚至每小時(shí)的備份,數(shù)據(jù)直接保留在存儲(chǔ)上以便快速恢復(fù)。
6 云管理平臺(tái)設(shè)計(jì)
基于超融合架構(gòu)的云計(jì)算并不簡(jiǎn)單等同于傳統(tǒng)架構(gòu)的虛擬化,而是綜合運(yùn)用虛擬化、標(biāo)準(zhǔn)化和自動(dòng)化等一系列技術(shù)對(duì)醫(yī)院的信息化進(jìn)行全面優(yōu)化。因此搭建面統(tǒng)一的云管理平臺(tái)還是非常有必要的。
在一些最佳實(shí)踐中,醫(yī)院信息中心已經(jīng)從一個(gè)成本中心變成一個(gè)可以交付有形價(jià)值和差異化能力的核心部門。在這場(chǎng)IT價(jià)值的變革中,云計(jì)算的作用至關(guān)重要,可以讓醫(yī)院降低對(duì)IT的一次性投入的同時(shí),還可以根據(jù)業(yè)務(wù)變化動(dòng)態(tài)調(diào)整資源,以快速響應(yīng)業(yè)務(wù)需求。
如果已經(jīng)有了云管理平臺(tái),那么需要考入如何將超融合系統(tǒng)整合到云平臺(tái)中,可以利用超融合廠商的工具與現(xiàn)有云管進(jìn)行集成或者邀請(qǐng)?jiān)性乒軓S商進(jìn)行二次開發(fā)集成。這些是需要在選擇超融合架構(gòu)之前必須要考慮的一個(gè)問題,否則后期管理起來非常困難,還會(huì)增加很多的管理成本。
6.1 主要功能
云管理平臺(tái)是面向云計(jì)算領(lǐng)域的通用云管理環(huán)境,在動(dòng)態(tài)數(shù)據(jù)中心構(gòu)建及運(yùn)維過程中提供全方位、多層次的管理及監(jiān)控能力,基于云環(huán)境實(shí)現(xiàn)應(yīng)用的快速部署及資源的彈性供應(yīng),通過簡(jiǎn)化管理極大地降低成本、提高效益。通過集中式的資源管理模式整合虛擬化數(shù)據(jù)中心的計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源,并通過自助式門戶以隨需即取的方式提供用戶申請(qǐng)、配置和使用。
云計(jì)算管理平臺(tái)可以根據(jù)超融合系統(tǒng)資源構(gòu)建統(tǒng)一的資源池,并能實(shí)現(xiàn)對(duì)資源池的創(chuàng)建、修改、刪除等管理功能。
云管理平臺(tái)要求能夠屏蔽虛擬化平臺(tái)異構(gòu)性。因?yàn)樵袛?shù)據(jù)中心的虛擬化系統(tǒng)很有可能是異構(gòu)的,或者新采購的超融合系統(tǒng)虛擬化也有可能與原有虛擬化系統(tǒng)不同,所以要求云管理平臺(tái)能夠支持主流的虛擬化平臺(tái)包括VMware、Xen、KVM、XenServer、RHEV,PowerVM等,簡(jiǎn)化管控復(fù)雜度,提供集中式監(jiān)管多虛擬化平臺(tái)資源,對(duì)資源進(jìn)行精細(xì)化管理、自動(dòng)化運(yùn)維,提供集中、統(tǒng)一監(jiān)控運(yùn)維管理平臺(tái),降低數(shù)據(jù)中心運(yùn)維成本。
云計(jì)算管理平臺(tái)主要功能如下:
門戶管理、資源管理、資源申請(qǐng)審批管理、資源調(diào)度和分配管理、運(yùn)維與監(jiān)控管理、故障告警管理、權(quán)限管理、用戶管理、計(jì)費(fèi)管理、安全管理、能耗管理、接口管理、統(tǒng)計(jì)報(bào)表和系統(tǒng)管理。
6.2 資源使用與管理
超融合系統(tǒng)在建設(shè)完成后,其資源主要由云管理平臺(tái)進(jìn)行統(tǒng)一管理。
建議采用以下兩種模式,進(jìn)行資源的使用與管理。
模式一:部門具備一定的信息化能力(如:醫(yī)院信息中心及分院信息管理部門等)。一次性申請(qǐng)批量資源,由云管理平臺(tái)管理部門經(jīng)過審批分析后,批準(zhǔn)并分配資源,之后,使用者在部門內(nèi)部進(jìn)行個(gè)人資源申請(qǐng)、審批,具備了“自治管理”能力;而通過流程控制和資源監(jiān)控,達(dá)到“集中管控”的效果。
模式二:部門不具備信息化能力(如:醫(yī)院骨科、眼科等業(yè)務(wù)科室),如果有資源需求,就會(huì)向云管理平臺(tái)管理部門提交申請(qǐng),經(jīng)過審批分析后,批準(zhǔn)或駁回申請(qǐng),動(dòng)態(tài)分配及收回資源。
7 超融合架構(gòu)建設(shè)難點(diǎn)分析
7.1 信息孤島治理
7.1.1 產(chǎn)生背景和原因
在醫(yī)療行業(yè)傳統(tǒng)數(shù)據(jù)中心,每個(gè)業(yè)務(wù)系統(tǒng)建設(shè)都是一套硬件設(shè)備對(duì)應(yīng)一套應(yīng)用的建設(shè)模式,因此產(chǎn)生了越來越多的“信息孤島”。隨著系統(tǒng)逐步增加,這種煙囪式IT架構(gòu)的問題逐漸暴露出來,如分散式管理復(fù)雜、機(jī)房設(shè)備多、利用率低等。
超融合平臺(tái)項(xiàng)目建設(shè)的初衷是把這些系統(tǒng)的數(shù)據(jù)業(yè)務(wù)打通,在底層形成計(jì)算和存儲(chǔ)的資源池,針對(duì)不同的業(yè)務(wù)動(dòng)態(tài)提供按需劃分的能力。但是,實(shí)際上的情況是,醫(yī)療用戶在部署了超融合系統(tǒng)以后,會(huì)出現(xiàn)更多的“信息孤島”。
在數(shù)據(jù)中心層面:所有的超融合方案都是分布式存儲(chǔ),也必須是分布式存儲(chǔ),不會(huì)支持?jǐn)?shù)據(jù)中心中原有傳統(tǒng)的集中式存儲(chǔ),而且大多數(shù)醫(yī)療用戶也不可能在短期內(nèi)更換原有的服務(wù)器和存儲(chǔ)等設(shè)備,最終的結(jié)果就是,數(shù)據(jù)中心被分裂成兩個(gè)彼此獨(dú)立分散的“信息孤島”。
在業(yè)務(wù)應(yīng)用層面:目前超融合系統(tǒng)通常僅支持一種或多種虛擬化環(huán)境,例如VMware超融合架構(gòu)僅支持VMware vSphere,不支持KVM。而華為和H3C等超融合方案基本都不支持Hyper-V虛擬化。每種虛擬化環(huán)境都有各自的優(yōu)勢(shì),很多情況下用戶可能要部署多套超融合環(huán)境。還有一點(diǎn)就是不同超融合平臺(tái)之間無法整合和互操作,舉個(gè)例子:如果一個(gè)醫(yī)院買了DELLEMC的VxRail超融合平臺(tái),那么以后擴(kuò)容不能再買其他超融合產(chǎn)品進(jìn)行擴(kuò)容,只能繼續(xù)選擇VxRail超融合產(chǎn)品,如果選擇其他超融合產(chǎn)品進(jìn)行擴(kuò)容,結(jié)果就是又多了幾個(gè)新的“信息孤島”。
7.1.2 解決方案
在醫(yī)療行業(yè)客戶考慮轉(zhuǎn)向超融合架構(gòu)之前,必須充分的認(rèn)識(shí)到新架構(gòu)的變化帶來的諸多問題。由于超融合架構(gòu)是一種全新的架構(gòu),短期內(nèi)不可能完全替代傳統(tǒng)的數(shù)據(jù)中心,所以信息孤島問題是必然存在的,需要在管理上提升認(rèn)識(shí),充分考慮現(xiàn)有業(yè)務(wù)的需求,進(jìn)行平衡考量,對(duì)現(xiàn)有數(shù)據(jù)中心的老舊設(shè)備和新的超融合設(shè)備進(jìn)行統(tǒng)一管理,綜合運(yùn)維。在超融合產(chǎn)品的選擇上,要結(jié)合現(xiàn)有的業(yè)務(wù)部署環(huán)境、虛擬化環(huán)境并結(jié)合數(shù)據(jù)中心的未來發(fā)展進(jìn)行認(rèn)真考量,不能有以往采購硬件設(shè)備時(shí)那種以價(jià)格優(yōu)先的選擇方法。必須充分對(duì)現(xiàn)有業(yè)務(wù)系統(tǒng)進(jìn)行調(diào)研,需要哪種虛擬化平臺(tái),盡量選擇支持異構(gòu)虛擬化的超融合產(chǎn)品,而且超融合產(chǎn)品的選型決定了未來數(shù)據(jù)中心的發(fā)展方向,是走商業(yè)化產(chǎn)品路線還是開源產(chǎn)品路線,都需要考慮清楚。如果僅以價(jià)格便宜作為優(yōu)先考慮方案,那么可能會(huì)導(dǎo)致適用性差,擴(kuò)展受限等問題,而且日后可能還會(huì)產(chǎn)生更多的信息孤島。
7.2 超融合系統(tǒng)性能優(yōu)化和節(jié)點(diǎn)管理
7.2.1 產(chǎn)生背景和原因
超融合架構(gòu)的優(yōu)點(diǎn)是易于擴(kuò)展和部署,按需擴(kuò)容。通常采用X86硬件平臺(tái)+軟件定義技術(shù)實(shí)現(xiàn)計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等功能的統(tǒng)一。軟件定義屏蔽了以往異構(gòu)設(shè)備的復(fù)雜性,實(shí)現(xiàn)完全分布式,去中心化,系統(tǒng)不存在任意單點(diǎn)故障。超融合通常3節(jié)點(diǎn)起配,并且可以擴(kuò)容到數(shù)十節(jié)點(diǎn)。超融合節(jié)點(diǎn)中的計(jì)算能力、存儲(chǔ)性能和容量是同步擴(kuò)容的,但是卻無法滿足現(xiàn)實(shí)中單項(xiàng)能力的擴(kuò)展。
在計(jì)算性能方面,大部分超融合產(chǎn)品都是基于2U的X86服務(wù)器,CPU數(shù)量通常為1-2顆,單個(gè)虛擬機(jī)的性能最大只能達(dá)到單個(gè)節(jié)點(diǎn)的70%(超融合系統(tǒng)本身和分布式存儲(chǔ)要占用30%的計(jì)算性能),而且不能像超算那樣,利用所有節(jié)點(diǎn)進(jìn)行統(tǒng)一計(jì)算。在這條件下,高性能應(yīng)用可能不太適合部署,而且性能會(huì)受限于單臺(tái)節(jié)點(diǎn)的性能。
在存儲(chǔ)性能方面,在傳統(tǒng)存儲(chǔ)集中式系統(tǒng)中,由于其物理I/O路徑較短,通常為機(jī)頭控制器后端再掛載磁盤組。而且采用Raid等數(shù)據(jù)保護(hù)算法比基于分布式存儲(chǔ)的副本數(shù)據(jù)保護(hù)模式,在計(jì)算開銷上小很多。在分布式存儲(chǔ)中,至少由3臺(tái)服務(wù)器組成,通常使用3副本模式。一個(gè)I/O通過網(wǎng)絡(luò),需要在多個(gè)副本服務(wù)器上進(jìn)行處理,而且每個(gè)副本都有數(shù)據(jù)一致性檢查算法,這些操作都將增加I/O的時(shí)延。分布式存儲(chǔ)系統(tǒng)的數(shù)據(jù)一致性會(huì)引發(fā)另外一個(gè)性能問題。數(shù)據(jù)一致性可以理解為應(yīng)用程序運(yùn)行的數(shù)據(jù)狀態(tài)與最終寫入到磁盤中的數(shù)據(jù)狀態(tài)是否一致。在數(shù)據(jù)庫等OLTP高并發(fā)業(yè)務(wù)場(chǎng)景下,數(shù)據(jù)一致性的保障可大大提高系統(tǒng)的可靠性和容錯(cuò)性,避免數(shù)據(jù)出錯(cuò)。傳統(tǒng)存儲(chǔ)是集中式緩存管理,集群中所有節(jié)點(diǎn)均不維護(hù)本地緩存,而是所有節(jié)點(diǎn)共享訪問一個(gè)集中存放的緩存,數(shù)據(jù)在緩存中只有一份副本,不會(huì)出現(xiàn)多份副本,具有天然的緩存一致性。分布式存儲(chǔ)因?yàn)槊總€(gè)節(jié)點(diǎn)都有自己獨(dú)享的緩存,存在多個(gè)副本,需要一個(gè)特殊過程來維護(hù)緩存一致性。通常需要采用低時(shí)延的高速網(wǎng)絡(luò)來實(shí)現(xiàn)緩存協(xié)議流量,最終實(shí)現(xiàn)任意關(guān)聯(lián)分布式緩存一致性。帶來的問題是副本之間的強(qiáng)一致特性導(dǎo)致只要有一個(gè)副本響應(yīng)稍慢,整個(gè)I/O的時(shí)延將增加,導(dǎo)致性能下降。
為了提升超融合平臺(tái)的性能,需要不斷的增加節(jié)點(diǎn)數(shù)量。但是節(jié)點(diǎn)數(shù)量的增加又會(huì)導(dǎo)致管理上的問題。集群達(dá)到一定規(guī)模后,其復(fù)雜性就會(huì)非線性增加,在管理上變的更加困難,硬件故障率也會(huì)大幅度增加,所以并不是超融合系統(tǒng)的群集越大越好。如果為了性能而不斷增加群集規(guī)模,還會(huì)產(chǎn)生均衡問題。因?yàn)槌诤霞軜?gòu)所有的計(jì)算和存儲(chǔ)資源都是均衡分布的,在擴(kuò)容或者是節(jié)點(diǎn)設(shè)備故障時(shí),都會(huì)發(fā)生計(jì)算和存儲(chǔ)資源的均衡遷移,雖然這個(gè)過程可以設(shè)定為非繁忙時(shí)段靜默完成,但是如果變動(dòng)很大,那么均衡的過程會(huì)非常漫長(zhǎng),在沒有足夠調(diào)整資源的情況下,會(huì)觸發(fā)強(qiáng)制均衡,對(duì)正常的業(yè)務(wù)產(chǎn)生影響。
7.2.2 解決方案
在計(jì)算性能方面,在進(jìn)行超融合產(chǎn)品部署前,需要根據(jù)醫(yī)院自身業(yè)務(wù)的性能需求,選擇合適的部署方案。例如:對(duì)于性能要求較高的大型OLTP數(shù)據(jù)庫服務(wù)器,可以考慮單獨(dú)部署在4路或8路的物理服務(wù)器上,不要部署在超融合系統(tǒng)中。超融合系統(tǒng)僅適合部署小型的或者對(duì)性能要求不高的數(shù)據(jù)庫。
在存儲(chǔ)性能方面,如果需要將傳統(tǒng)的集中式存儲(chǔ)數(shù)據(jù)遷移到超融合的分布式存儲(chǔ)中,要考慮性能問題。提前做好I/O性能測(cè)試,避免性能不足。通常來講,如果一臺(tái)中高端存儲(chǔ)設(shè)備,遷移到超融合系統(tǒng)中,要獲取相同性能,至少要有10個(gè)以上的節(jié)點(diǎn),而且要配置SSD閃存。在考慮數(shù)據(jù)遷移之前,傳統(tǒng)存儲(chǔ)的自動(dòng)精簡(jiǎn)配置、快照、克隆、重復(fù)數(shù)據(jù)刪除、數(shù)據(jù)加密和數(shù)據(jù)壓縮等高級(jí)特性也需要考慮進(jìn)去,這些通常是超融合架構(gòu)的分布式存儲(chǔ)所不具備的。
在管理方面,超融合雖然架構(gòu)簡(jiǎn)化了IT架構(gòu),但是如果不考慮實(shí)際需求,盲目擴(kuò)展,反而會(huì)增加數(shù)據(jù)中心的復(fù)雜性。從超融合產(chǎn)品的角度講,其內(nèi)部技術(shù)和鏈接配置更加復(fù)雜,為了性能不斷的增加節(jié)點(diǎn)數(shù)量,如果出現(xiàn)故障,問題的跟蹤調(diào)試和分析診斷也變得更加困難。建議在進(jìn)行超融合架構(gòu)規(guī)劃時(shí),不要只設(shè)定一個(gè)超融合群集,而是要根據(jù)業(yè)務(wù)類型或者性能分別創(chuàng)建不同的超融合群集,而且盡可能的控制單個(gè)群集的規(guī)模數(shù)量。