醫(yī)療行業(yè)超融合方案設(shè)計

1、 醫(yī)療行業(yè)超融合方案設(shè)計 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66559365 醫(yī)療行業(yè)超融合方案設(shè)計 PAGEREF _Toc66559365 h 1 HYPERLINK l _Toc66559366 1 設(shè)計概要 PAGEREF _Toc66559366 h 3 HYPERLINK l _Toc66559367 2 設(shè)計原則 PAGEREF _Toc66559367 h 4 HYPERLINK l _Toc66559368 3 超融合架構(gòu)總體設(shè)計 PAGEREF _Toc66559368 h 5 HYPERLINK l _Toc66559369 4 超融

2、合架構(gòu)業(yè)務(wù)設(shè)計 PAGEREF _Toc66559369 h 7 HYPERLINK l _Toc66559370 5 超融合架構(gòu)物理資源規(guī)劃 PAGEREF _Toc66559370 h 9 HYPERLINK l _Toc66559371 6 云管理平臺設(shè)計 PAGEREF _Toc66559371 h 19 HYPERLINK l _Toc66559372 7 超融合架構(gòu)建設(shè)難點分析 PAGEREF _Toc66559372 h 211 設(shè)計概要綜合需求分析篇（注：本文前篇為醫(yī)療行業(yè)超融合架構(gòu)解決方案需求分析篇，即今日推送的第二條，也可到本文后所附地址中閱讀），結(jié)合目前醫(yī)療行業(yè)數(shù)據(jù)中心的

3、演進方法論及最佳實踐，建議采用分步分批的建設(shè)方式，使用擴展能力強，功能豐富的超融合基礎(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è)計思路。數(shù)據(jù)中心第一期建設(shè)，需要對現(xiàn)有業(yè)務(wù)系統(tǒng)進行深入調(diào)研，分析各個業(yè)務(wù)系統(tǒng)的需求和特點，將適合部署到超融合的系統(tǒng)進行統(tǒng)一梳理資源需求，建設(shè)基于超融合架構(gòu)的數(shù)據(jù)中心，然后對業(yè)務(wù)系統(tǒng)資源進行整合。整合后的資源要求能通過超融合系統(tǒng)自帶的管理軟件，結(jié)合醫(yī)院現(xiàn)有云管理平臺進行統(tǒng)一管理，實現(xiàn)在一個界面完成對全院所有資源的管理、分配和運維分析等操作。數(shù)據(jù)中

4、心第二期建設(shè)，在管理上，需要實現(xiàn)高度自動化的業(yè)務(wù)部署和運維。在建設(shè)上，可以開展網(wǎng)絡(luò)SDN和NFV等系統(tǒng)的建設(shè)，這些也都是超融合系統(tǒng)建設(shè)的一部分。即使用通用的硬件服務(wù)器+軟件就可以實現(xiàn)數(shù)據(jù)中心需要的大部分IT功能，不需要額外再采購專用設(shè)備。SDN可以讓網(wǎng)絡(luò)具有可編程能力，包括能力開放、控制面和數(shù)據(jù)面解耦，以及集中控制等。NFV就是網(wǎng)絡(luò)功能的虛擬化，利用通用的硬件平臺和虛擬化技術(shù)，取代現(xiàn)在的專用網(wǎng)絡(luò)設(shè)備，例如負(fù)載和路由等傳統(tǒng)網(wǎng)絡(luò)設(shè)備。SDN和NFV是兩個關(guān)系密切，但又相對獨立，都可以讓超融合系統(tǒng)的網(wǎng)絡(luò)變得更加開放、敏捷和聰明。通過超融合系統(tǒng)的建設(shè)，最終可以實現(xiàn)全軟件定義的數(shù)據(jù)中心。有效整合服務(wù)器、

5、存儲和網(wǎng)絡(luò)等資源，最大效率的利用硬件設(shè)備，滿足新的醫(yī)療信息系統(tǒng)各項業(yè)務(wù)的性能需要。同時還可以對數(shù)據(jù)中心硬件設(shè)備進行有效管理和監(jiān)控，降低運維和管理成本。2 設(shè)計原則在方案設(shè)計中我們將遵循以下總體原則：1、以醫(yī)院業(yè)務(wù)需求為導(dǎo)向超融合架構(gòu)最終還是要為醫(yī)療業(yè)務(wù)服務(wù)的，因此在架構(gòu)設(shè)計上一定要以醫(yī)療業(yè)務(wù)的需求為導(dǎo)向，充分考慮非功能需求，例如系統(tǒng)的重要程度、安全要求、業(yè)務(wù)連續(xù)性等。2、遵循醫(yī)療行業(yè)標(biāo)準(zhǔn)醫(yī)院大部分業(yè)務(wù)系統(tǒng)都是面向社會和公眾的，在醫(yī)院基礎(chǔ)架構(gòu)建設(shè)時，應(yīng)符合國際、國家、醫(yī)療衛(wèi)生行業(yè)標(biāo)準(zhǔn)、規(guī)范和醫(yī)院自身的發(fā)展規(guī)劃。3、提高資源利用率現(xiàn)已經(jīng)部署了大量的服務(wù)器，資源使用率低是較突出的一個問題。要充分發(fā)揮

6、超融合架構(gòu)的這一最大的特點，在保證性能的前提下進行合理設(shè)計。在同一設(shè)備中合理分配計算、存儲和網(wǎng)絡(luò)等虛擬化資源，最大程度的提高服務(wù)器設(shè)備的利用率。4、系統(tǒng)擴展性在超融合架構(gòu)中，可以進行橫向靈活擴展，使醫(yī)院的IT基礎(chǔ)架構(gòu)成為一個動態(tài)、靈活、具有彈性的IT基礎(chǔ)架構(gòu)。要考慮在醫(yī)療業(yè)務(wù)系統(tǒng)實時運行過程中，計算資源和存儲資源的同時動態(tài)調(diào)整和擴展的問題，避免對現(xiàn)有生產(chǎn)系統(tǒng)產(chǎn)生影響。5、安全可用性業(yè)務(wù)系統(tǒng)的高可用性和安全性是醫(yī)院業(yè)務(wù)得以持續(xù)運行的保障。在超融合架構(gòu)設(shè)計中，應(yīng)該以軟件定義技術(shù)為主，結(jié)構(gòu)超融合的分布式架構(gòu)的特點，解決系統(tǒng)單點故障問題和性能瓶頸等問題，在滿足業(yè)務(wù)系統(tǒng)可用性的同時保證醫(yī)院系統(tǒng)運行安全和

7、數(shù)據(jù)安全。3 超融合架構(gòu)總體設(shè)計超融合架構(gòu)在數(shù)據(jù)中心，以軟件定義為解決方案，使用通用的X86服務(wù)器+虛擬化軟件建設(shè)計算、分布式存儲和網(wǎng)絡(luò)等資源池，極大地簡化了數(shù)據(jù)中心的基礎(chǔ)架構(gòu)。而且通過軟件定義資源池為分布式架構(gòu)，可以實現(xiàn)無單點故障、無單點瓶頸、橫向自動彈性擴展、性能線性增長等能力。在物理層，可以選擇通用的X86服務(wù)器和交換機。在軟件定義層，可以根據(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)品，不要

8、輕易嘗試新出的和不成熟的開源虛擬化產(chǎn)品。在管理層，大多數(shù)商業(yè)的超融合產(chǎn)品都會提供一套通過簡單、方便的管理界面，實現(xiàn)對數(shù)據(jù)中心基礎(chǔ)設(shè)施資源的管理。但是數(shù)據(jù)中心如果已經(jīng)有一套云管理平臺，要考慮新采購的超融合系統(tǒng)和已有云管理平臺的對接問題。盡可能使用一套云管理平臺，必要時需要進行二次開發(fā)，避免出現(xiàn)多套管理系統(tǒng)，多個云管理平臺。使用一套云管界面對整個數(shù)據(jù)中心進行統(tǒng)一的監(jiān)控、管理和運維。超融合架構(gòu)總體設(shè)計如下圖：具體設(shè)計如下：一、搭建超融合系統(tǒng)平臺。在數(shù)據(jù)中心機房新建一套超融合系統(tǒng)集群，并對醫(yī)院現(xiàn)有的業(yè)務(wù)系統(tǒng)進行評估，按照評估結(jié)果，將適合的業(yè)務(wù)系統(tǒng)和數(shù)據(jù)遷移至超融合平臺，打破原有豎井式的縱向擴展架構(gòu)。H

9、IS/PACS等核心業(yè)務(wù)數(shù)據(jù)庫系統(tǒng)不建議做遷移，由于其對物理機性能要求比較高，而且有數(shù)據(jù)一致性要求。而目前市場上各個廠商的超融合系統(tǒng)的分布式存儲對數(shù)據(jù)庫支持能力不同，為了保證HIS/PACS等核心業(yè)務(wù)數(shù)據(jù)庫的性能和數(shù)據(jù)的實時性，需要對選定的超融合系統(tǒng)做更詳細(xì)的POC測試，確定滿足條件后再進行遷移。二、對原有設(shè)備進行淘汰和利舊整合。建議淘汰的設(shè)備：服役超過5年以上的服務(wù)器，不建議繼續(xù)使用，可以進行淘汰處理，避免潛在的安全隱患，同時還可以降低整體能耗成本。利舊整合的設(shè)備：可以利舊整合的服務(wù)器主要有兩種解決方案。首先，可以用于開發(fā)測試，但是需要注意的是，對于這部分資源最好單獨建設(shè)一個資源分區(qū)，不要和

10、生產(chǎn)資源混合在一個資源池里，做好安全隔離，避免互相影響。其次，可以選擇部分性能比較好，未過保修期（通常服務(wù)器保修年限為三年）且具有整合價值的服務(wù)器，然后部署超融合系統(tǒng)，加入到超融合系統(tǒng)群集當(dāng)中。但是仍然建議單獨設(shè)計一個資源池，不要與新采購的超融合系統(tǒng)混用一個資源池，同樣做好安全隔離。因為老舊的服務(wù)器，即使部署了相同超融合系統(tǒng)軟件，由于其CPU型號比較舊，而且型號不統(tǒng)一，很難和新采購的超融合系統(tǒng)設(shè)備相互兼容，不建議部署在一個資源池。三、建立統(tǒng)一的云管理平臺。云管理平臺主要負(fù)責(zé)對資源的管理、彈性調(diào)度以及操作維護等綜合管理功能，是云平臺管理的核心，在同一個web界面提供云資源管理、云運維管理和云服務(wù)

11、管理的功能。在采購新的超融合系統(tǒng)以后，要求必須能夠和現(xiàn)有的云管理平臺兼容，能夠進行二次開發(fā)和對接?；蛘咧苯硬捎贸诤舷到y(tǒng)的云管理整合原有的虛擬化資源，但是絕不能同時出現(xiàn)多個云管理平臺，這樣非常不利于資源的統(tǒng)一管理和調(diào)配，給醫(yī)院的信息化管理帶來很大的困難。云資源管理負(fù)責(zé)云平臺資源虛擬化和資源分配，將物理資源(計算、存儲、網(wǎng)絡(luò)等)轉(zhuǎn)換成可動態(tài)調(diào)整的虛擬資源，供虛擬機使用，提供高可用性的彈性虛擬機，保障業(yè)務(wù)系統(tǒng)的連續(xù)性與虛擬機的安全隔離。云運維管理可以實現(xiàn)物理設(shè)備、虛擬設(shè)備、應(yīng)用系統(tǒng)的集中監(jiān)控、管理維護自動化與動態(tài)化。云服務(wù)管理對外的主要工作是實現(xiàn)用戶管理、集群管理、業(yè)務(wù)模板管理、虛擬機管理、虛擬機

12、發(fā)放、統(tǒng)一硬件管理、告警、監(jiān)控等功能。4 超融合架構(gòu)業(yè)務(wù)設(shè)計醫(yī)院業(yè)務(wù)系統(tǒng)分析主要是對現(xiàn)有醫(yī)院業(yè)務(wù)系統(tǒng)進行梳理，對醫(yī)院的業(yè)務(wù)系統(tǒng)進行評估和分類，選擇適合部署在超融合系統(tǒng)之上的系統(tǒng)。主要包括以下幾個方面的工作：1、對業(yè)務(wù)系統(tǒng)進行分析，選擇適合遷移到超融合架構(gòu)的應(yīng)用。建議優(yōu)先從非核心的系統(tǒng)開始嘗試部署，然后逐漸擴展到其他核心業(yè)務(wù)系統(tǒng)。2、評估并計算系統(tǒng)資源的使用量，包括計算、存儲、網(wǎng)絡(luò)和安全資源等。3、根據(jù)分析出的需要遷移的業(yè)務(wù)系統(tǒng)資源量，評估現(xiàn)有機房的物理環(huán)境和網(wǎng)絡(luò)環(huán)境，是否能夠滿足遷移后的超融合系統(tǒng)部署需要。4、針對超融合系統(tǒng)的性能需求和擴展能力的需求進行設(shè)計，為選擇適合的超融合架構(gòu)梳理依據(jù)。4

13、.1 業(yè)務(wù)遷移分析醫(yī)院業(yè)務(wù)系統(tǒng)主要分為四大類，分別是：1、行政管理系統(tǒng)。包括人事管理系統(tǒng)，財務(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)計系統(tǒng)，血庫管理系統(tǒng)等。3、決策支持系統(tǒng)。包括醫(yī)療質(zhì)量評價系統(tǒng)，醫(yī)療質(zhì)量控制系統(tǒng)等。4、各種輔助系統(tǒng)。如醫(yī)療情報檢索系統(tǒng)，醫(yī)療數(shù)據(jù)庫系統(tǒng)等。以上業(yè)務(wù)系統(tǒng)，除了核心HIS和PACS數(shù)據(jù)庫外，其實大部分系統(tǒng)都適合遷移至超融合系統(tǒng)，對于業(yè)務(wù)系統(tǒng)的最終選擇，還是需要分析其運行和使用的現(xiàn)狀，可

14、以按照以下情況進行判斷。1、原有業(yè)務(wù)系統(tǒng)運行在物理機上，且物理機的資源利用率非常低。建議盡快遷移到超融合架構(gòu)上，可以最大程度提高醫(yī)院信息系統(tǒng)的靈活性和設(shè)備使用率。遷移成功的前提是，原有業(yè)務(wù)系統(tǒng)的開發(fā)商需要能夠提供必要的支持，否則遷移部署和驗證可能會有些困難。2、原有業(yè)務(wù)系統(tǒng)運行在物理機上，且物理機的資源利用率非常高。通常核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫屬于這一類的應(yīng)用，不建議遷移到超融合平臺之上，否則性能問題會是個極大的挑戰(zhàn)。3、原有業(yè)務(wù)系統(tǒng)運行在虛擬機上，且虛擬機軟件的類別、版本和預(yù)期采購超融合系統(tǒng)基本保持一致。對于這類應(yīng)用，遷移是非常容易的，只需要將虛擬機直接遷移到超融合平臺上就好，不會存在太多的障礙

15、，可以完全加入到遷移的名單中。4、原有業(yè)務(wù)系統(tǒng)運行在虛擬機上，且虛擬機軟件的類別、版本和預(yù)期采購超融合系統(tǒng)完全不一致。對于這類應(yīng)用，遷移可能會有些麻煩，要看是否能夠找到合適的V2V遷移轉(zhuǎn)換工作。否則就需要在超融合系統(tǒng)上重新部署，然后再遷移數(shù)據(jù)。如果要將這類應(yīng)用加入到遷移名單中，需要提前做好POC測試工作。4.2 業(yè)務(wù)資源分析在超融合平臺實施前，必須根據(jù)現(xiàn)有需要遷移的業(yè)務(wù)進行資源分析，確定超融合系統(tǒng)設(shè)備的資源使用量。主要分析的內(nèi)容是對現(xiàn)有業(yè)務(wù)系統(tǒng)的計算、存儲等性能進行分析。最終得出超融合系統(tǒng)的規(guī)劃配置內(nèi)容，包括超融合集群數(shù)量、容量規(guī)劃、性能、應(yīng)用需求等，可以指導(dǎo)超融合系統(tǒng)實施策略和實施路線規(guī)劃。

16、分析的主要內(nèi)容可以參考下表的示例進行統(tǒng)計：通過最終的超融合系統(tǒng)資源需求統(tǒng)計，可以得出超融合系統(tǒng)的CPU、內(nèi)存和存儲容量，然后選擇合適的超融合節(jié)點數(shù)量和群集規(guī)模。CPU的數(shù)量通常決定了超融合系統(tǒng)的節(jié)點數(shù)量和群集規(guī)模。超融合系統(tǒng)通常都是一臺2U高的X86服務(wù)器。高密度的X86服務(wù)器，每臺可以提供2-4個Node(節(jié)點)的資源。每個節(jié)點通常為1-2顆CPU+可選容量的內(nèi)存（CPU核心數(shù)量和內(nèi)存容量可以根據(jù)需求來進行選擇）。從技術(shù)上講，有些廠商的超融合系統(tǒng)是不限制單個群集的節(jié)點規(guī)模數(shù)量的，但是最佳實踐是一般單個群集不建議超過64個節(jié)點，比較方便管理，性能上也比較可靠。存儲容量的配置需要根據(jù)原有業(yè)務(wù)的容

17、量進行定量分析后得出。例如：原有存儲配置100TB SATA磁盤，那么超融合架構(gòu)也需要配置同樣的資源，避免浪費。為了保證數(shù)據(jù)的冗余性和可靠性，通常分布式存儲都是多副本的，而且以3副本最為常見，所以在配置物理容量時，需要將實際數(shù)據(jù)融量至少乘以3倍，而且大部分分布式存儲系統(tǒng)都是以SSD磁盤作為緩存使用，這部分SSD的存儲容量是不能計算在內(nèi)的。現(xiàn)有虛擬化系統(tǒng)環(huán)境類型決定了超融合產(chǎn)品的實施策略和實施路線，因為不是所有的超融合產(chǎn)品都支持全部的虛擬化層軟件。例如VMware就不支持KVM，無法直接進行遷移。如果采用支持KVM的超融合系統(tǒng)，那么原有的VMware虛擬機就需要進行遷移轉(zhuǎn)換后，才可以在基于KVM

18、的超融合系統(tǒng)上運行。在物理網(wǎng)絡(luò)資源的定量分析上，也需要考慮新的超融合系統(tǒng)的網(wǎng)卡性能和數(shù)量，如果原有系統(tǒng)環(huán)境全部為雙鏈路萬兆網(wǎng)絡(luò)，那么新組建的超融合網(wǎng)絡(luò)也必須是雙鏈路萬兆網(wǎng)絡(luò)。而且網(wǎng)段數(shù)量至少要增加兩個，一個內(nèi)部通訊網(wǎng)絡(luò)和一個管理網(wǎng)絡(luò)。網(wǎng)卡同時也需要增加兩塊。5 超融合架構(gòu)物理資源規(guī)劃5.1 物理架構(gòu)圖圖：超融合架構(gòu)物理架構(gòu)方案物理架構(gòu)圖描述：基于超融合架構(gòu)的數(shù)據(jù)中心，在網(wǎng)絡(luò)上采用扁平化二層網(wǎng)絡(luò)架構(gòu)（核心層、接入層），使用網(wǎng)絡(luò)虛擬化技術(shù)，核心交換機承擔(dān)著核心層和匯聚層的雙重任務(wù)。扁平化方式降低了網(wǎng)絡(luò)復(fù)雜度，簡化了網(wǎng)絡(luò)拓?fù)洌岣吡宿D(zhuǎn)發(fā)效率。二層網(wǎng)絡(luò)架構(gòu)中，采用虛擬集群和堆疊技術(shù)，解決鏈路環(huán)路問題，

19、提高了網(wǎng)絡(luò)可靠性。核心交換機設(shè)置VLAN的IP地址，接入交換機劃分VLAN，做二層轉(zhuǎn)發(fā)。在邏輯上，超融合架構(gòu)不改變原有醫(yī)院生產(chǎn)中心網(wǎng)絡(luò)架構(gòu)。原有設(shè)備網(wǎng)絡(luò)、服務(wù)器、存儲和安全等設(shè)備可以繼續(xù)利舊使用。針對新購買的超融合設(shè)備，需要單獨設(shè)立二個安全域，分別為超融合系統(tǒng)安全區(qū)和超融合系統(tǒng)利舊資源區(qū)，分別部署新采購的和利舊的超融合服務(wù)器設(shè)備。為了保證傳統(tǒng)業(yè)務(wù)的可靠的運行，需要與傳統(tǒng)架構(gòu)區(qū)的設(shè)備進行安全隔離，但是都處于內(nèi)網(wǎng)，是可以互相訪問的，不影響系統(tǒng)的正常訪問和運行。為了保障內(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)物理機一般為機架

20、服務(wù)器。同時融合計算和存儲資源，提供虛擬化資源。每臺服務(wù)器配置1塊2端口的10GE網(wǎng)卡。通過萬兆接入交換機和核心交換機進行連接。配置2個千兆網(wǎng)絡(luò)，一個連接生產(chǎn)網(wǎng)絡(luò)，一個連接管理網(wǎng)絡(luò)。超融合架構(gòu)物理機存儲系統(tǒng)采用分布式架構(gòu)，通常配置有SSD+HDD或者全閃存磁盤的模式?？梢愿鶕?jù)數(shù)據(jù)存儲需要進行配置。對于超融合系統(tǒng)的存儲，要求支持多副本存儲、數(shù)據(jù)本地化、熱點數(shù)據(jù)自動分層。另外，可以根據(jù)需求選擇在線重刪、壓縮、快照、克隆、同/異步備份和跨地域遠(yuǎn)程數(shù)據(jù)容災(zāi)等高級功能。5.2 計算資源規(guī)劃計算資源是通過對x86服務(wù)器CPU虛擬化來實現(xiàn)的，根據(jù)現(xiàn)有虛擬化環(huán)境，可選擇VMware vSphere、Micro

21、Soft Hyper-v或KVM等Hypervisor，通過虛擬化技術(shù)組建計算資源池，為業(yè)務(wù)系統(tǒng)的虛擬機提供不同的服務(wù)質(zhì)量和能力。以VMware為例，可提供HA高可用、FT容錯、vMotion在線遷移和DRS資源動態(tài)負(fù)載均衡等能力。計算資源的規(guī)劃需要根據(jù)歷史業(yè)務(wù)對資源的需求推導(dǎo)出需要新采購的超融合服務(wù)器的數(shù)量。包括遷移場景需要的服務(wù)器數(shù)量和新建場景需要的服務(wù)器數(shù)量。如果沒有可供利舊的服務(wù)器，那么這兩個部分相加，就是全部的計算資源總量。遷移場景和新建場景由于維度不一樣，統(tǒng)計出的服務(wù)器數(shù)量可能也會有所偏差，通常需要綜合進行考量評估，建議以服務(wù)器數(shù)量多的數(shù)值做為參考。5.2.1 遷移場景服務(wù)器數(shù)量規(guī)

22、劃這里借鑒并提供華為的服務(wù)器數(shù)量估算方法論做為參考，為簡化計算過程，所有管理、計算和存儲虛擬化軟件節(jié)點的CPU資源開銷按照10%進行計算，內(nèi)存資源開銷按照每臺物理機100GB進行估算。注：CPU和內(nèi)存的開銷需要按照預(yù)計采購的超融合系統(tǒng)進行修正。 從計算服務(wù)器CPU維度進行估算使用SPECint2006 Rate進行折算，SPEC值可在/cgi-bin/osgresults查到。單服務(wù)器需要計算能力=物理服務(wù)器的SPECCPU使用率/（1-CPU冗余度）（1）現(xiàn)有舊物理服務(wù)器計算能力折算方法：所有n臺原服務(wù)器CPU能力折算值x=服務(wù)器1的SPEC值CPU使用率1/(1-CPU冗余度)+ 服務(wù)器2

23、的SPEC值CPU使用率2/(1-CPU冗余度)+ .+ 服務(wù)器n的SPEC值CPU使用率n/(1-CPU冗余度)（2）部署虛擬化平臺的物理服務(wù)器的CPU能力計算方法：假設(shè)部署虛擬化平臺的單個物理服務(wù)器的SPEC值為y，單物理服務(wù)器的總邏輯核數(shù)為z。虛擬化服務(wù)器的數(shù)量 N = x/(y90%),結(jié)果向上取其整數(shù)即可。如果數(shù)量3，那么至少配置3臺。舉例：比如40臺型號為：Dell Inc. PowerEdge 2950 x64-based PC Intel(R) Xeon(R) CPU E5420 2.50GHz, 2493 Mhz, 4 Core(s), 4 Logical Processor

24、(s) 8.00GB的服務(wù)器的實際平均CPU使用率為30%。查表/cgi-bin/osgresults獲取其SPEC值為118。假定虛擬化后的目標(biāo)CPU能力冗余度30%。x = 40（11830%/（1-30%）=2022.857若最終選擇Intel Xeon E5-4610，同樣查/cgi-bin/osgresults ，得到其SPEC值為883。服務(wù)器共48邏輯核，部署所有管理、計算和存儲虛擬化軟件節(jié)點的CPU資源開銷為10%。虛擬化服務(wù)器的數(shù)量N=2022.857/(88390%)=2.545，虛擬化服務(wù)器的數(shù)量為3臺。 從計算服務(wù)器內(nèi)存維度進行估算直接使用內(nèi)存使用量進行計算。單計算服務(wù)

25、器實際需要的內(nèi)存（虛擬化后）=現(xiàn)有物理服務(wù)器的內(nèi)存內(nèi)存使用率/（1-內(nèi)存冗余度）（1）現(xiàn)有物理服務(wù)器內(nèi)存折算方法：所有n臺原服務(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)存計算方法：假設(shè)虛擬化后的單個服務(wù)器的內(nèi)存值為 z。部署所有管理、計算和存儲虛擬化軟件節(jié)點的內(nèi)存資源開銷為100GB。虛擬化后的服務(wù)器實際能給虛擬機用的內(nèi)存y=z-100GB，每臺至少配置100GB以上，建議配置256GB。虛擬化服務(wù)器的數(shù)量 N = x/y

26、，結(jié)果向上取其整數(shù)即可。如果數(shù)量3，那么至少配置3臺。如果數(shù)量太多，請增加單臺服務(wù)器的內(nèi)存容量。舉例：假定原服務(wù)器的內(nèi)存大小為8G，內(nèi)存使用率為20%，共40臺。虛擬化后的目標(biāo)內(nèi)存冗余度為40%x =40（ 820%/（1-40%）=106.7GB假定Intel Xeon E5-4610配置256GB內(nèi)存（要求必須大于100GB），則實際可用的內(nèi)存為：y=z-100GB=256GB-100GB=156GB從內(nèi)存容量上看，需要純計算節(jié)點的個數(shù)：虛擬化服務(wù)器的數(shù)量 N = x/y=106.7GB/156GB=0.684，虛擬化服務(wù)器的數(shù)量為3臺。5.2.2 新建場景服務(wù)器數(shù)量規(guī)劃這里借鑒并提供華為

27、的服務(wù)器數(shù)量估算方法論做為參考，為簡化計算過程，所有管理、計算和存儲虛擬化軟件節(jié)點的CPU資源開銷按照10%進行計算，內(nèi)存資源開銷按照每臺物理機100GB進行估算。注：CPU和內(nèi)存的開銷需要按照預(yù)計采購的超融合系統(tǒng)進行修正。 根據(jù)CPU資源需求維度估算適用于對虛擬化后使用虛擬機規(guī)格（CPU、內(nèi)存、磁盤、網(wǎng)卡）、虛擬機的數(shù)量都有清晰認(rèn)識的場景，能夠規(guī)劃出各類虛擬機的規(guī)格和所需的數(shù)量：總vCPU數(shù)=預(yù)計部署的每臺VM虛擬機的vCPU數(shù)量的總和注：vCPU是衡量一臺虛擬機計算能力的主要指標(biāo)，類似物理服務(wù)器的CPU。vCPU核數(shù)類似服務(wù)器CPU的核數(shù)（core）。一個利用率100的vCPU的處理能力等

28、于物理CPU一個超線程的處理能力。1、根據(jù)計算能力總需求估算CPU總物理核數(shù)=roundup（總vCPU數(shù)/單核超線程數(shù)/CPU利用率）2、估算所需的服務(wù)器數(shù)量物理服務(wù)器數(shù)量=roundup(CPU總物理核數(shù)/(服務(wù)器CPU個數(shù)CPU物理核數(shù)）90%（1+服務(wù)器冗余率）結(jié)果向上取其整數(shù)即可。如果數(shù)量3，那么至少配置3臺。舉例：假定總vCPU的數(shù)量為100，服務(wù)器冗余率設(shè)定為30%，CPU利用率不超過70%，部署所有管理、計算和存儲虛擬化軟件節(jié)點的CPU資源開銷為10%，擬定選擇的超融合服務(wù)器為2顆12核心處理器2線程處理器。那么：CPU總物理核數(shù)=roundup（總vCPU數(shù)/單核超線程數(shù)/C

29、PU利用率）= roundup（100/2/0.7）=72物理服務(wù)器數(shù)量為=roundup(72/(212）90%（1+30%）= roundup4.3物理服務(wù)器數(shù)量：需要5臺。 根據(jù)內(nèi)存資源需求維度估算1、內(nèi)存總需求總內(nèi)存=預(yù)計部署的每臺VM虛擬機的內(nèi)存數(shù)量的總和注：內(nèi)存大小是指虛擬機內(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臺。如果數(shù)量太多，請增加單臺服務(wù)器的內(nèi)存容量。舉例：假定總內(nèi)存的數(shù)量為360GB，服務(wù)器冗余率設(shè)定為30%，部署

30、所有管理、計算和存儲虛擬化軟件節(jié)點的內(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%）=roundup3物理服務(wù)器數(shù)量：需要3臺5.3 存儲資源規(guī)劃超融合系統(tǒng)架構(gòu)提供的存儲資源，都是基于分布式的文件系統(tǒng)，可以將一組集群內(nèi)的節(jié)點組成一個統(tǒng)一的分布式存儲平臺。對于業(yè)務(wù)系統(tǒng)來說，就是一個集中的共享式存儲，與任何其他集中式存儲陣列一樣工作，由超融合存儲系統(tǒng)管理模塊對分布式存儲進行管理。超融合分布式存儲系

31、統(tǒng)的配置規(guī)劃，需要根據(jù)歷史業(yè)務(wù)對資源的需求推導(dǎo)出需要新采購的超融合服務(wù)器的硬盤數(shù)量。包括遷移場景需要的硬盤數(shù)量和新建場景需要的硬盤數(shù)量。如果沒有可供利舊的服務(wù)器，那么這兩個部分相加，就是全部的計算資源總量。為了減小不必要要的服務(wù)器數(shù)量，單盤盡量選擇1.2TB或1.8TB產(chǎn)品。當(dāng)然，為了使用更多的硬盤提升分布式存儲性能，還需要綜合考量。以上除了需要提前確認(rèn)好數(shù)據(jù)容量以外，還需要注意以下幾點：1、分布式存儲架構(gòu)以可以提供傳統(tǒng)集中式存儲的能力，包括塊存儲、文件存儲和對象存儲等。但并不是所有的超融合系統(tǒng)都能提供以上的存儲能力。由于分布式存儲的數(shù)據(jù)一致性不是很好，所以有些超融合系統(tǒng)提供的塊存儲服務(wù)是不能

32、夠安裝ORACLE這類數(shù)據(jù)庫應(yīng)用的，即使能安裝，效果也不會很好，性能會比較低。需要官方給出可安裝的測試報告或者兼容性測試報告。2、是否需要超融合存儲系統(tǒng)提供快照、克隆、壓縮和重復(fù)數(shù)據(jù)刪除等傳統(tǒng)集中式存儲的特性。由于超融合系統(tǒng)也是近幾年剛剛興起，對于這類高級特性不如傳統(tǒng)集中式存儲支持的好，如果需要某種高級特性，需要提前對超融合廠商的相關(guān)存儲產(chǎn)品進行調(diào)研，做好POC測試。3、分布式存儲資源池的組成通常為SSD+HDD的架構(gòu)，SSD作為緩存盤，提升整個系統(tǒng)的性能。而且有的廠商要求嚴(yán)格的資源配比，以VSAN為例，需要1塊SSD+最多6塊HDD為一個邏輯磁盤組（VMware計劃增加到最多7塊）。而且1臺

33、物理主機最多只能有5個磁盤組。所以物理磁盤不能隨意配置，需要根據(jù)超融合廠商的技術(shù)要求進行合理配置，避免資源浪費。當(dāng)然也有的超融合廠商支持全閃存的架構(gòu)，甚至可以使用PCI-E的SSD緩存卡進行加速，只是在成本上比較貴。4、超融合的節(jié)點的硬盤數(shù)量會影響整個分布式存儲系統(tǒng)的性能。如果超融合系統(tǒng)只有最少的3個節(jié)點，那么分布式存儲系統(tǒng)的性能上基本上是無法超越傳統(tǒng)集中式架構(gòu)存儲的，只有盡可能多的配置節(jié)點數(shù)量和硬盤數(shù)量，才有可能達(dá)到甚至超越傳統(tǒng)集中式存儲的性能。5.3.1 遷移場景存儲容量規(guī)劃這里借鑒并提供華為的存儲容量估算方法論做為參考。由于IOPS不太容易評估，為簡化計算過程，只考慮容量的計算。對于分布

34、式存儲的性能規(guī)劃，建議通過POC測試進行，理論和實際往往差距較大。容量計算：基礎(chǔ)數(shù)據(jù)：總的有效容量=x，磁盤標(biāo)稱容量=z，磁盤空間利用率=q，副本數(shù)=k總的硬盤數(shù)量=roundup總的有效容量/(zq)k（向上取整）舉例：假定現(xiàn)有需要遷移的數(shù)據(jù)，總計20000GB，預(yù)計購買的超融合服務(wù)器每臺的磁盤標(biāo)稱容量z=1200GB，磁盤空間利用率q=0.95，副本數(shù)k=3.按容量計算，硬盤數(shù)量為：則利用上述公式：總的硬盤數(shù)量= roundup20000/(1200GB0.95)3總的硬盤數(shù)量= roundup20000/(1140)*3總的硬盤數(shù)量= roundup52.633總的硬盤數(shù)量為53塊硬盤，

35、每塊盤容量至少為1200GB。如果要加入SSD固態(tài)硬盤做熱點遷移和自動分層，需要按照超融合系統(tǒng)要求的比例，購買SSD固態(tài)硬盤。5.3.2 新建場景存儲容量規(guī)劃這里借鑒并提供華為的存儲容量估算方法論做為參考。由于IOPS不太容易評估，為簡化計算過程，只考慮容量的計算。對于分布式存儲的性能規(guī)劃，建議通過POC測試進行，理論和實際往往差距較大。1、存儲總?cè)萘啃枨箢愋蚷系統(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ù)存儲總需求估算根據(jù)存儲空間計算所需的硬盤數(shù)量：總的硬盤數(shù)量=roundup(系統(tǒng)盤總?cè)萘?數(shù)據(jù)盤總

36、容量）副本數(shù)k/單盤容量z/磁盤容量利用率q舉例：假定現(xiàn)有虛擬機VM數(shù)量為100個，每個操作系統(tǒng)占用30GB空間，每個虛擬機數(shù)據(jù)盤空間需求為50GB。預(yù)計購買的超融合服務(wù)器每臺的磁盤標(biāo)稱容量z=1200GB，磁盤空間利用率q=0.95，副本數(shù)k=3.系統(tǒng)盤總?cè)萘?30GB100=30000GB數(shù)據(jù)盤總?cè)萘?50GB100=50000GB按容量計算，硬盤數(shù)量為：總的硬盤數(shù)量=roundup(30TB+50TB）3/1.2TB/0.95= roundup80tb*3/1.2TB/0.95= roundup210.53總的硬盤數(shù)量為211塊硬盤，每塊盤容量至少為1200GB。如果要加入SSD固態(tài)硬盤

37、做熱點遷移和自動分層，需要按照超融合系統(tǒng)要求的比例，購買SSD固態(tài)硬盤。5.4 網(wǎng)絡(luò)資源規(guī)劃5.4.1 組網(wǎng)策略在超融合的架構(gòu)中，多臺虛擬機之間是共享網(wǎng)絡(luò)的，為了方便管理，一般采用虛擬交換機來配置和管理網(wǎng)絡(luò)，虛擬交換機可在數(shù)據(jù)中心級別提供集中和聚合的虛擬網(wǎng)絡(luò)，從而簡化并增強虛擬機網(wǎng)絡(luò)。在虛擬交換機的網(wǎng)絡(luò)劃分上，仍然可以采用VLAN的方式劃分不同的子網(wǎng)，實現(xiàn)不同子網(wǎng)段的安全和隔離。除了虛擬交換機，還可以通過Overlay的方式來構(gòu)建大二層和實現(xiàn)業(yè)務(wù)系統(tǒng)之間的租戶隔離，通過NFV實現(xiàn)網(wǎng)絡(luò)中的所需各類網(wǎng)絡(luò)功能資源（包括基礎(chǔ)的路由交換、安全以及應(yīng)用交付等）按需分配和靈活調(diào)度，從而實現(xiàn)超融合架構(gòu)中的網(wǎng)絡(luò)

38、虛擬化。這類功能同時需要客戶的物理交換機支持SDN的管理方式，如果是一些老舊設(shè)備，可能無法實現(xiàn)，需要購置新的交換機設(shè)置。5.4.2 網(wǎng)絡(luò)拓?fù)湓诿總€單節(jié)點的物理機上，需要提供以下網(wǎng)絡(luò)端口：萬兆光口：至少1個千兆電口：至少2個下圖為推薦的網(wǎng)絡(luò)拓?fù)鋱D：圖：超融合架構(gòu)網(wǎng)絡(luò)拓?fù)湓诿總€超融合物理節(jié)點上有多種網(wǎng)絡(luò)需求，包括生產(chǎn)網(wǎng)絡(luò)、數(shù)據(jù)交換網(wǎng)絡(luò)、管理網(wǎng)絡(luò)、生產(chǎn)網(wǎng)絡(luò)等，因此每個物理節(jié)點建議配置多塊網(wǎng)卡，并保證每個節(jié)點通過兩條萬兆或千兆鏈路分別連接兩臺交換機，保證網(wǎng)絡(luò)設(shè)備和鏈路的冗余度。網(wǎng)絡(luò)設(shè)計建議如下：1、生產(chǎn)網(wǎng)絡(luò)（原有生產(chǎn)網(wǎng)絡(luò)，同時也是客戶機和虛擬化服務(wù)器之間的網(wǎng)絡(luò)通訊）可采用雙鏈路千兆以太網(wǎng)絡(luò)，如果原有雙

39、鏈路萬兆網(wǎng)絡(luò)，那么可以繼續(xù)延用。當(dāng)用戶的客戶機訪問虛擬服務(wù)器時，通過生產(chǎn)網(wǎng)絡(luò)可分流后端存儲流量并且進行隔離。2、數(shù)據(jù)交換網(wǎng)（X86物理服務(wù)器之間的內(nèi)部通訊網(wǎng)絡(luò)）至少采用雙鏈路萬兆光纖網(wǎng)絡(luò)，由于分布式存儲數(shù)據(jù)交換和虛擬機之間的通訊都需要占用大量的網(wǎng)絡(luò)帶寬，當(dāng)發(fā)生密集的寫IO時，萬兆網(wǎng)絡(luò)能保證提供足夠帶寬滿足節(jié)點之間的IO同步流量。建議單獨配置1塊萬兆網(wǎng)卡。3、管理網(wǎng)絡(luò)（管理X86物理服務(wù)器節(jié)點）可采用雙鏈路千兆以太網(wǎng)絡(luò)，主要用于節(jié)點管理。建議單獨配置1塊千兆網(wǎng)卡，實現(xiàn)管理網(wǎng)絡(luò)與業(yè)務(wù)網(wǎng)絡(luò)、存儲網(wǎng)絡(luò)分離。可以最大限度保證管理的靈活性和安全性。5.5 安全和備份規(guī)劃超融合系統(tǒng)的設(shè)計還需要考慮安全設(shè)計。

40、首先，在物理安全上，建議將超融合節(jié)點分別部署到3個不同的機柜中，每個機柜部署1個節(jié)點，最大化做到故障域的隔離。每個機柜雙路供電，實現(xiàn)真正的供電冗余。其次，要考慮滿足國家等保的要求還有醫(yī)療客戶自身的安全需求。在安全產(chǎn)品的部署上，可以延用原有的安全設(shè)備，也可以選擇支持安全虛擬化的超融合產(chǎn)品。例如深信服超融合產(chǎn)品，可以集成集成分布式防火墻、4-7層虛擬防火墻、虛擬數(shù)據(jù)庫審計等虛擬安全組件，并結(jié)合深信服安全產(chǎn)品，幫助客戶構(gòu)建從邊界安全、平臺安全、數(shù)據(jù)安全到應(yīng)用安全的全方位安全防護體系，并利用安全可視化，對安全事件全過程進行安全保障：事前漏洞評估，事中全方位防護，事后持續(xù)威脅檢測。超融合架構(gòu)可以提供跨數(shù)

41、據(jù)中心的容災(zāi)及應(yīng)用級高可用解決方案。超融合架構(gòu)具備面向數(shù)據(jù)的備份及恢復(fù)機制，以更經(jīng)濟的方式實現(xiàn)數(shù)據(jù)的安全存儲和管理，并結(jié)合負(fù)載均衡、虛擬化軟件層高可用機制，提供了應(yīng)用層面的跨數(shù)據(jù)中心業(yè)務(wù)連續(xù)性訪問能力。大部分超融合系統(tǒng)都可以提供基于虛擬機快照的方式將更新數(shù)據(jù)異步復(fù)制到遠(yuǎn)端的超融合系統(tǒng)集群中。如果有容災(zāi)建設(shè)的需求，需要提前規(guī)劃好容災(zāi)復(fù)制模式，選擇合適的雙向復(fù)制、一對多復(fù)制或者多對一的數(shù)據(jù)復(fù)制模式。傳統(tǒng)的備份方式通過網(wǎng)絡(luò)傳輸備份數(shù)據(jù)，需要特定的備份窗口以免影響業(yè)務(wù)正常運行。超融合產(chǎn)品備份可以與傳統(tǒng)的備份策略互補，既能保證對于重要的虛擬機進行高頻次備份又不會占用額外的網(wǎng)絡(luò)帶寬。例如：對于普通虛擬機可

42、以使用傳統(tǒng)的備份方式每周進行全備，將備份數(shù)據(jù)備份到外部存儲中，同時使用超融合自帶的備份管理系統(tǒng)進行每天甚至每12小時的備份，數(shù)據(jù)直接保留在存儲上以便快速恢復(fù)。對于比較重要的虛擬機可以使用傳統(tǒng)備份每周全備、每天增量的方式，將備份數(shù)據(jù)備份到外部存儲中，同時使用超融合自帶的備份管理系統(tǒng)進行每2小時甚至每小時的備份，數(shù)據(jù)直接保留在存儲上以便快速恢復(fù)。6 云管理平臺設(shè)計基于超融合架構(gòu)的云計算并不簡單等同于傳統(tǒng)架構(gòu)的虛擬化，而是綜合運用虛擬化、標(biāo)準(zhǔn)化和自動化等一系列技術(shù)對醫(yī)院的信息化進行全面優(yōu)化。因此搭建面統(tǒng)一的云管理平臺還是非常有必要的。在一些最佳實踐中，醫(yī)院信息中心已經(jīng)從一個成本中心變成一個可以交付有

43、形價值和差異化能力的核心部門。在這場IT價值的變革中，云計算的作用至關(guān)重要，可以讓醫(yī)院降低對IT的一次性投入的同時，還可以根據(jù)業(yè)務(wù)變化動態(tài)調(diào)整資源，以快速響應(yīng)業(yè)務(wù)需求。如果已經(jīng)有了云管理平臺，那么需要考入如何將超融合系統(tǒng)整合到云平臺中，可以利用超融合廠商的工具與現(xiàn)有云管進行集成或者邀請原有云管廠商進行二次開發(fā)集成。這些是需要在選擇超融合架構(gòu)之前必須要考慮的一個問題，否則后期管理起來非常困難，還會增加很多的管理成本。6.1 主要功能云管理平臺是面向云計算領(lǐng)域的通用云管理環(huán)境，在動態(tài)數(shù)據(jù)中心構(gòu)建及運維過程中提供全方位、多層次的管理及監(jiān)控能力，基于云環(huán)境實現(xiàn)應(yīng)用的快速部署及資源的彈性供應(yīng)，通過簡化管

44、理極大地降低成本、提高效益。通過集中式的資源管理模式整合虛擬化數(shù)據(jù)中心的計算、存儲和網(wǎng)絡(luò)資源，并通過自助式門戶以隨需即取的方式提供用戶申請、配置和使用。云計算管理平臺可以根據(jù)超融合系統(tǒng)資源構(gòu)建統(tǒng)一的資源池，并能實現(xiàn)對資源池的創(chuàng)建、修改、刪除等管理功能。云管理平臺要求能夠屏蔽虛擬化平臺異構(gòu)性。因為原有數(shù)據(jù)中心的虛擬化系統(tǒng)很有可能是異構(gòu)的，或者新采購的超融合系統(tǒng)虛擬化也有可能與原有虛擬化系統(tǒng)不同，所以要求云管理平臺能夠支持主流的虛擬化平臺包括VMware、Xen、KVM、XenServer、RHEV，PowerVM等，簡化管控復(fù)雜度，提供集中式監(jiān)管多虛擬化平臺資源，對資源進行精細(xì)化管理、自動化運維

45、，提供集中、統(tǒng)一監(jiān)控運維管理平臺，降低數(shù)據(jù)中心運維成本。云計算管理平臺主要功能如下：門戶管理、資源管理、資源申請審批管理、資源調(diào)度和分配管理、運維與監(jiān)控管理、故障告警管理、權(quán)限管理、用戶管理、計費管理、安全管理、能耗管理、接口管理、統(tǒng)計報表和系統(tǒng)管理。圖 云計算管理平臺功能架構(gòu)圖6.2 資源使用與管理超融合系統(tǒng)在建設(shè)完成后，其資源主要由云管理平臺進行統(tǒng)一管理。建議采用以下兩種模式，進行資源的使用與管理。模式一：部門具備一定的信息化能力（如：醫(yī)院信息中心及分院信息管理部門等）。一次性申請批量資源，由云管理平臺管理部門經(jīng)過審批分析后，批準(zhǔn)并分配資源，之后，使用者在部門內(nèi)部進行個人資源申請、審批，具

46、備了“自治管理”能力；而通過流程控制和資源監(jiān)控，達(dá)到“集中管控”的效果。模式二：部門不具備信息化能力（如：醫(yī)院骨科、眼科等業(yè)務(wù)科室），如果有資源需求，就會向云管理平臺管理部門提交申請，經(jīng)過審批分析后，批準(zhǔn)或駁回申請，動態(tài)分配及收回資源。7 超融合架構(gòu)建設(shè)難點分析7.1 信息孤島治理7.1.1 產(chǎn)生背景和原因在醫(yī)療行業(yè)傳統(tǒng)數(shù)據(jù)中心，每個業(yè)務(wù)系統(tǒng)建設(shè)都是一套硬件設(shè)備對應(yīng)一套應(yīng)用的建設(shè)模式，因此產(chǎn)生了越來越多的“信息孤島”。隨著系統(tǒng)逐步增加，這種煙囪式IT架構(gòu)的問題逐漸暴露出來，如分散式管理復(fù)雜、機房設(shè)備多、利用率低等。超融合平臺項目建設(shè)的初衷是把這些系統(tǒng)的數(shù)據(jù)業(yè)務(wù)打通，在底層形成計算和存儲的資源池

47、，針對不同的業(yè)務(wù)動態(tài)提供按需劃分的能力。但是，實際上的情況是，醫(yī)療用戶在部署了超融合系統(tǒng)以后，會出現(xiàn)更多的“信息孤島”。在數(shù)據(jù)中心層面：所有的超融合方案都是分布式存儲，也必須是分布式存儲，不會支持?jǐn)?shù)據(jù)中心中原有傳統(tǒng)的集中式存儲，而且大多數(shù)醫(yī)療用戶也不可能在短期內(nèi)更換原有的服務(wù)器和存儲等設(shè)備，最終的結(jié)果就是，數(shù)據(jù)中心被分裂成兩個彼此獨立分散的“信息孤島”。在業(yè)務(wù)應(yīng)用層面：目前超融合系統(tǒng)通常僅支持一種或多種虛擬化環(huán)境，例如VMware超融合架構(gòu)僅支持VMware vSphere，不支持KVM。而華為和H3C等超融合方案基本都不支持Hyper-V虛擬化。每種虛擬化環(huán)境都有各自的優(yōu)勢，很多情況下用戶可

48、能要部署多套超融合環(huán)境。還有一點就是不同超融合平臺之間無法整合和互操作，舉個例子：如果一個醫(yī)院買了DELLEMC的VxRail超融合平臺，那么以后擴容不能再買其他超融合產(chǎn)品進行擴容，只能繼續(xù)選擇VxRail超融合產(chǎn)品，如果選擇其他超融合產(chǎn)品進行擴容，結(jié)果就是又多了幾個新的“信息孤島”。7.1.2 解決方案在醫(yī)療行業(yè)客戶考慮轉(zhuǎn)向超融合架構(gòu)之前，必須充分的認(rèn)識到新架構(gòu)的變化帶來的諸多問題。由于超融合架構(gòu)是一種全新的架構(gòu)，短期內(nèi)不可能完全替代傳統(tǒng)的數(shù)據(jù)中心，所以信息孤島問題是必然存在的，需要在管理上提升認(rèn)識，充分考慮現(xiàn)有業(yè)務(wù)的需求，進行平衡考量，對現(xiàn)有數(shù)據(jù)中心的老舊設(shè)備和新的超融合設(shè)備進行統(tǒng)一管理，綜合運維。在超融合產(chǎn)品的選擇上，要結(jié)合現(xiàn)有的業(yè)務(wù)部署環(huán)境、虛擬化環(huán)境并結(jié)合數(shù)據(jù)中心的未來發(fā)展進行認(rèn)真考量，不能有以往采購硬件設(shè)備時那種以價格優(yōu)先的選擇方法。必須充分對現(xiàn)有業(yè)務(wù)系統(tǒng)進行調(diào)研，需要哪種虛擬化平臺，盡量選擇支持異構(gòu)虛擬化的超融合產(chǎn)品，而且超融合產(chǎn)品的選型決定了未來數(shù)據(jù)中心的發(fā)展方向，是走商業(yè)化產(chǎn)品路線還是開源產(chǎn)品路線，都需要考慮清楚。如果僅以價格便宜作為優(yōu)先考慮方案，那么可能會導(dǎo)致適用性差，擴展受限等問題，而且日后可能還會產(chǎn)生更多的信息孤島。7.2 超融合系統(tǒng)性能優(yōu)化和節(jié)點管理7.2.1 產(chǎn)生背景和原因超融