安全資訊

1 設計概要

結合目前醫療行業(yè)數據中心的演進(jìn)方法論及最佳實(shí)踐，建議采用分步分批的建設方式，使用擴展能力強，功能豐富的超融合基礎架構方案，來(lái)滿(mǎn)足醫院業(yè)務(wù)系統高可靠性、高可用性、業(yè)務(wù)連續性、數據安全、數據備份、數據及應用容災的需求。

建議未開(kāi)始基于超融合架構建設數據中心的醫院，采用分期建設的方法和設計思路。

數據中心第一期建設，需要對現有業(yè)務(wù)系統進(jìn)行深入調研，分析各個(gè)業(yè)務(wù)系統的需求和特點(diǎn)，將適合部署到超融合的系統進(jìn)行統一梳理資源需求，建設基于超融合架構的數據中心，然后對業(yè)務(wù)系統資源進(jìn)行整合。整合后的資源要求能通過(guò)超融合系統自帶的管理軟件，結合醫院現有云管理平臺進(jìn)行統一管理，實(shí)現在一個(gè)界面完成對全院所有資源的管理、分配和運維分析等操作。

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

通過(guò)超融合系統的建設，最終可以實(shí)現全軟件定義的數據中心。有效整合服務(wù)器、存儲和網(wǎng)絡(luò )等資源，最大效率的利用硬件設備，滿(mǎn)足新的醫療信息系統各項業(yè)務(wù)的性能需要。同時(shí)還可以對數據中心硬件設備進(jìn)行有效管理和監控，降低運維和管理成本。

2 設計原則

在方案設計中我們將遵循以下總體原則：

1、以醫院業(yè)務(wù)需求為導向

超融合架構最終還是要為醫療業(yè)務(wù)服務(wù)的，因此在架構設計上一定要以醫療業(yè)務(wù)的需求為導向，充分考慮非功能需求，例如系統的重要程度、安全要求、業(yè)務(wù)連續性等。

2、遵循醫療行業(yè)標準

醫院大部分業(yè)務(wù)系統都是面向社會(huì )和公眾的，在醫院基礎架構建設時(shí)，應符合國際、國家、醫療衛生行業(yè)標準、規范和醫院自身的發(fā)展規劃。

3、提高資源利用率

現已經(jīng)部署了大量的服務(wù)器，資源使用率低是較突出的一個(gè)問(wèn)題。要充分發(fā)揮超融合架構的這一最大的特點(diǎn)，在保證性能的前提下進(jìn)行合理設計。在同一設備中合理分配計算、存儲和網(wǎng)絡(luò )等虛擬化資源，最大程度的提高服務(wù)器設備的利用率。

4、系統擴展性

在超融合架構中，可以進(jìn)行橫向靈活擴展，使醫院的IT基礎架構成為一個(gè)動(dòng)態(tài)、靈活、具有彈性的IT基礎架構。要考慮在醫療業(yè)務(wù)系統實(shí)時(shí)運行過(guò)程中，計算資源和存儲資源的同時(shí)動(dòng)態(tài)調整和擴展的問(wèn)題，避免對現有生產(chǎn)系統產(chǎn)生影響。

5、安全可用性

業(yè)務(wù)系統的高可用性和安全性是醫院業(yè)務(wù)得以持續運行的保障。在超融合架構設計中，應該以軟件定義技術(shù)為主，結構超融合的分布式架構的特點(diǎn)，解決系統單點(diǎn)故障問(wèn)題和性能瓶頸等問(wèn)題，在滿(mǎn)足業(yè)務(wù)系統可用性的同時(shí)保證醫院系統運行安全和數據安全。

3 超融合架構總體設計

超融合架構在數據中心，以軟件定義為解決方案，使用通用的X86服務(wù)器+虛擬化軟件建設計算、分布式存儲和網(wǎng)絡(luò )等資源池，極大地簡(jiǎn)化了數據中心的基礎架構。而且通過(guò)軟件定義資源池為分布式架構，可以實(shí)現無(wú)單點(diǎn)故障、無(wú)單點(diǎn)瓶頸、橫向自動(dòng)彈性擴展、性能線(xiàn)性增長(cháng)等能力。

在物理層，可以選擇通用的X86服務(wù)器和交換機。在軟件定義層，可以根據現有數據中心虛擬化的使用情況，結合未來(lái)數據中心的發(fā)展技術(shù)路線(xiàn)和方向，選擇合適的虛擬化軟件，例如VMware vSphere、KVM或Hyper-v等，盡量和生產(chǎn)中心保持一致，方便業(yè)務(wù)的轉換和遷移。如果選擇開(kāi)源類(lèi)產(chǎn)品路線(xiàn)，盡量選擇穩定可靠的產(chǎn)品，不要輕易嘗試新出的和不成熟的開(kāi)源虛擬化產(chǎn)品。

在管理層，大多數商業(yè)的超融合產(chǎn)品都會(huì )提供一套通過(guò)簡(jiǎn)單、方便的管理界面，實(shí)現對數據中心基礎設施資源的管理。但是數據中心如果已經(jīng)有一套云管理平臺，要考慮新采購的超融合系統和已有云管理平臺的對接問(wèn)題。盡可能使用一套云管理平臺，必要時(shí)需要進(jìn)行二次開(kāi)發(fā)，避免出現多套管理系統，多個(gè)云管理平臺。使用一套云管界面對整個(gè)數據中心進(jìn)行統一的監控、管理和運維。

具體設計如下：

一、搭建超融合系統平臺。

在數據中心機房新建一套超融合系統集群，并對醫院現有的業(yè)務(wù)系統進(jìn)行評估，按照評估結果，將適合的業(yè)務(wù)系統和數據遷移至超融合平臺，打破原有豎井式的縱向擴展架構。

HIS/PACS等核心業(yè)務(wù)數據庫系統不建議做遷移，由于其對物理機性能要求比較高，而且有數據一致性要求。而目前市場(chǎng)上各個(gè)廠(chǎng)商的超融合系統的分布式存儲對數據庫支持能力不同，為了保證HIS/PACS等核心業(yè)務(wù)數據庫的性能和數據的實(shí)時(shí)性，需要對選定的超融合系統做更詳細的POC測試，確定滿(mǎn)足條件后再進(jìn)行遷移。

二、對原有設備進(jìn)行淘汰和利舊整合。

建議淘汰的設備：服役超過(guò)5年以上的服務(wù)器，不建議繼續使用，可以進(jìn)行淘汰處理，避免潛在的安全隱患，同時(shí)還可以降低整體能耗成本。

利舊整合的設備：可以利舊整合的服務(wù)器主要有兩種解決方案。

首先，可以用于開(kāi)發(fā)測試，但是需要注意的是，對于這部分資源最好單獨建設一個(gè)資源分區，不要和生產(chǎn)資源混合在一個(gè)資源池里，做好安全隔離，避免互相影響。其次，可以選擇部分性能比較好，未過(guò)保修期（通常服務(wù)器保修年限為三年）且具有整合價(jià)值的服務(wù)器，然后部署超融合系統，加入到超融合系統群集當中。但是仍然建議單獨設計一個(gè)資源池，不要與新采購的超融合系統混用一個(gè)資源池，同樣做好安全隔離。因為老舊的服務(wù)器，即使部署了相同超融合系統軟件，由于其CPU型號比較舊，而且型號不統一，很難和新采購的超融合系統設備相互兼容，不建議部署在一個(gè)資源池。

三、建立統一的云管理平臺。

云管理平臺主要負責對資源的管理、彈性調度以及操作維護等綜合管理功能，是云平臺管理的核心，在同一個(gè)web界面提供云資源管理、云運維管理和云服務(wù)管理的功能。在采購新的超融合系統以后，要求必須能夠和現有的云管理平臺兼容，能夠進(jìn)行二次開(kāi)發(fā)和對接?；蛘咧苯硬捎贸诤舷到y的云管理整合原有的虛擬化資源，但是絕不能同時(shí)出現多個(gè)云管理平臺，這樣非常不利于資源的統一管理和調配，給醫院的信息化管理帶來(lái)很大的困難。

云資源管理負責云平臺資源虛擬化和資源分配，將物理資源(計算、存儲、網(wǎng)絡(luò )等)轉換成可動(dòng)態(tài)調整的虛擬資源，供虛擬機使用，提供高可用性的彈性虛擬機，保障業(yè)務(wù)系統的連續性與虛擬機的安全隔離。

云運維管理可以實(shí)現物理設備、虛擬設備、應用系統的集中監控、管理維護自動(dòng)化與動(dòng)態(tài)化。

云服務(wù)管理對外的主要工作是實(shí)現用戶(hù)管理、集群管理、業(yè)務(wù)模板管理、虛擬機管理、虛擬機發(fā)放、統一硬件管理、告警、監控等功能。

4 超融合架構業(yè)務(wù)設計

醫院業(yè)務(wù)系統分析主要是對現有醫院業(yè)務(wù)系統進(jìn)行梳理，對醫院的業(yè)務(wù)系統進(jìn)行評估和分類(lèi)，選擇適合部署在超融合系統之上的系統。主要包括以下幾個(gè)方面的工作：

1、對業(yè)務(wù)系統進(jìn)行分析，選擇適合遷移到超融合架構的應用。建議優(yōu)先從非核心的系統開(kāi)始嘗試部署，然后逐漸擴展到其他核心業(yè)務(wù)系統。

2、評估并計算系統資源的使用量，包括計算、存儲、網(wǎng)絡(luò )和安全資源等。

3、根據分析出的需要遷移的業(yè)務(wù)系統資源量，評估現有機房的物理環(huán)境和網(wǎng)絡(luò )環(huán)境，是否能夠滿(mǎn)足遷移后的超融合系統部署需要。

4、針對超融合系統的性能需求和擴展能力的需求進(jìn)行設計，為選擇適合的超融合架構梳理依據。

4.1 業(yè)務(wù)遷移分析

醫院業(yè)務(wù)系統主要分為四大類(lèi)，分別是：

1、行政管理系統。包括人事管理系統，財務(wù)管理系統，后勤管理系統，藥庫管理系統，醫療設備管理系統，門(mén)診、手術(shù)及住院預約系統，病人住院管理系統等。

2、醫療管理系統。也是核心業(yè)務(wù)系統，主要包括門(mén)診、急診管理系統（HIS），影像文件系統（PCAS）、病案管理系統，醫療統計系統，血庫管理系統等。

3、決策支持系統。包括醫療質(zhì)量評價(jià)系統，醫療質(zhì)量控制系統等。

4、各種輔助系統。如醫療情報檢索系統，醫療數據庫系統等。

以上業(yè)務(wù)系統，除了核心HIS和PACS數據庫外，其實(shí)大部分系統都適合遷移至超融合系統，對于業(yè)務(wù)系統的最終選擇，還是需要分析其運行和使用的現狀，可以按照以下情況進(jìn)行判斷。

1、原有業(yè)務(wù)系統運行在物理機上，且物理機的資源利用率非常低。

建議盡快遷移到超融合架構上，可以最大程度提高醫院信息系統的靈活性和設備使用率。遷移成功的前提是，原有業(yè)務(wù)系統的開(kāi)發(fā)商需要能夠提供必要的支持，否則遷移部署和驗證可能會(huì )有些困難。

2、原有業(yè)務(wù)系統運行在物理機上，且物理機的資源利用率非常高。

通常核心業(yè)務(wù)系統的數據庫屬于這一類(lèi)的應用，不建議遷移到超融合平臺之上，否則性能問(wèn)題會(huì )是個(gè)極大的挑戰。

3、原有業(yè)務(wù)系統運行在虛擬機上，且虛擬機軟件的類(lèi)別、版本和預期采購超融合系統基本保持一致。

對于這類(lèi)應用，遷移是非常容易的，只需要將虛擬機直接遷移到超融合平臺上就好，不會(huì )存在太多的障礙，可以完全加入到遷移的名單中。

4、原有業(yè)務(wù)系統運行在虛擬機上，且虛擬機軟件的類(lèi)別、版本和預期采購超融合系統完全不一致。

對于這類(lèi)應用，遷移可能會(huì )有些麻煩，要看是否能夠找到合適的V2V遷移轉換工作。否則就需要在超融合系統上重新部署，然后再遷移數據。如果要將這類(lèi)應用加入到遷移名單中，需要提前做好POC測試工作。

4.2 業(yè)務(wù)資源分析

在超融合平臺實(shí)施前，必須根據現有需要遷移的業(yè)務(wù)進(jìn)行資源分析，確定超融合系統設備的資源使用量。

主要分析的內容是對現有業(yè)務(wù)系統的計算、存儲等性能進(jìn)行分析。最終得出超融合系統的規劃配置內容，包括超融合集群數量、容量規劃、性能、應用需求等，可以指導超融合系統實(shí)施策略和實(shí)施路線(xiàn)規劃。

通過(guò)最終的超融合系統資源需求統計，可以得出超融合系統的CPU、內存和存儲容量，然后選擇合適的超融合節點(diǎn)數量和群集規模。

CPU的數量通常決定了超融合系統的節點(diǎn)數量和群集規模。超融合系統通常都是一臺2U高的X86服務(wù)器。高密度的X86服務(wù)器，每臺可以提供2-4個(gè)Node(節點(diǎn))的資源。每個(gè)節點(diǎn)通常為1-2顆CPU+可選容量的內存（CPU核心數量和內存容量可以根據需求來(lái)進(jìn)行選擇）。從技術(shù)上講，有些廠(chǎng)商的超融合系統是不限制單個(gè)群集的節點(diǎn)規模數量的，但是最佳實(shí)踐是一般單個(gè)群集不建議超過(guò)64個(gè)節點(diǎn)，比較方便管理，性能上也比較可靠。

存儲容量的配置需要根據原有業(yè)務(wù)的容量進(jìn)行定量分析后得出。例如：原有存儲配置100TB SATA磁盤(pán)，那么超融合架構也需要配置同樣的資源，避免浪費。為了保證數據的冗余性和可靠性，通常分布式存儲都是多副本的，而且以3副本最為常見(jiàn)，所以在配置物理容量時(shí)，需要將實(shí)際數據融量至少乘以3倍，而且大部分分布式存儲系統都是以SSD磁盤(pán)作為緩存使用，這部分SSD的存儲容量是不能計算在內的。

現有虛擬化系統環(huán)境類(lèi)型決定了超融合產(chǎn)品的實(shí)施策略和實(shí)施路線(xiàn)，因為不是所有的超融合產(chǎn)品都支持全部的虛擬化層軟件。例如VMware就不支持KVM，無(wú)法直接進(jìn)行遷移。如果采用支持KVM的超融合系統，那么原有的VMware虛擬機就需要進(jìn)行遷移轉換后，才可以在基于KVM的超融合系統上運行。

在物理網(wǎng)絡(luò )資源的定量分析上，也需要考慮新的超融合系統的網(wǎng)卡性能和數量，如果原有系統環(huán)境全部為雙鏈路萬(wàn)兆網(wǎng)絡(luò )，那么新組建的超融合網(wǎng)絡(luò )也必須是雙鏈路萬(wàn)兆網(wǎng)絡(luò )。而且網(wǎng)段數量至少要增加兩個(gè)，一個(gè)內部通訊網(wǎng)絡(luò )和一個(gè)管理網(wǎng)絡(luò )。網(wǎng)卡同時(shí)也需要增加兩塊。

5 超融合架構物理資源規劃

5.1 物理架構圖

物理架構圖描述：

基于超融合架構的數據中心，在網(wǎng)絡(luò )上采用扁平化二層網(wǎng)絡(luò )架構（核心層、接入層），使用網(wǎng)絡(luò )虛擬化技術(shù)，核心交換機承擔著(zhù)核心層和匯聚層的雙重任務(wù)。

扁平化方式降低了網(wǎng)絡(luò )復雜度，簡(jiǎn)化了網(wǎng)絡(luò )拓撲，提高了轉發(fā)效率。二層網(wǎng)絡(luò )架構中，采用虛擬集群和堆疊技術(shù)，解決鏈路環(huán)路問(wèn)題，提高了網(wǎng)絡(luò )可靠性。核心交換機設置VLAN的IP地址，接入交換機劃分VLAN，做二層轉發(fā)。

在邏輯上，超融合架構不改變原有醫院生產(chǎn)中心網(wǎng)絡(luò )架構。原有設備網(wǎng)絡(luò )、服務(wù)器、存儲和安全等設備可以繼續利舊使用。

針對新購買(mǎi)的超融合設備，需要單獨設立二個(gè)安全域，分別為超融合系統安全區和超融合系統利舊資源區，分別部署新采購的和利舊的超融合服務(wù)器設備。為了保證傳統業(yè)務(wù)的可靠的運行，需要與傳統架構區的設備進(jìn)行安全隔離，但是都處于內網(wǎng)，是可以互相訪(fǎng)問(wèn)的，不影響系統的正常訪(fǎng)問(wèn)和運行。為了保障內網(wǎng)的數據安全和網(wǎng)絡(luò )安全，外網(wǎng)用戶(hù)訪(fǎng)問(wèn)仍需要通過(guò)VPN授權才可以訪(fǎng)問(wèn)內網(wǎng)數據，通過(guò)DMZ區訪(fǎng)問(wèn)web服務(wù)。

超融合架構物理機一般為機架服務(wù)器。同時(shí)融合計算和存儲資源，提供虛擬化資源。每臺服務(wù)器配置1塊2端口的10GE網(wǎng)卡。通過(guò)萬(wàn)兆接入交換機和核心交換機進(jìn)行連接。配置2個(gè)千兆網(wǎng)絡(luò )，一個(gè)連接生產(chǎn)網(wǎng)絡(luò )，一個(gè)連接管理網(wǎng)絡(luò )。

超融合架構物理機存儲系統采用分布式架構，通常配置有SSD+HDD或者全閃存磁盤(pán)的模式?？梢愿鶕祿鎯π枰M(jìn)行配置。對于超融合系統的存儲，要求支持多副本存儲、數據本地化、熱點(diǎn)數據自動(dòng)分層。另外，可以根據需求選擇在線(xiàn)重刪、壓縮、快照、克隆、同/異步備份和跨地域遠程數據容災等高級功能。

5.2 計算資源規劃

計算資源是通過(guò)對x86服務(wù)器CPU虛擬化來(lái)實(shí)現的，根據現有虛擬化環(huán)境，可選擇VMware vSphere、MicroSoft Hyper-v或KVM等Hypervisor，通過(guò)虛擬化技術(shù)組建計算資源池，為業(yè)務(wù)系統的虛擬機提供不同的服務(wù)質(zhì)量和能力。以VMware為例，可提供HA高可用、FT容錯、vMotion在線(xiàn)遷移和DRS資源動(dòng)態(tài)負載均衡等能力。

計算資源的規劃需要根據歷史業(yè)務(wù)對資源的需求推導出需要新采購的超融合服務(wù)器的數量。包括遷移場(chǎng)景需要的服務(wù)器數量和新建場(chǎng)景需要的服務(wù)器數量。如果沒(méi)有可供利舊的服務(wù)器，那么這兩個(gè)部分相加，就是全部的計算資源總量。

遷移場(chǎng)景和新建場(chǎng)景由于維度不一樣，統計出的服務(wù)器數量可能也會(huì )有所偏差，通常需要綜合進(jìn)行考量評估，建議以服務(wù)器數量多的數值做為參考。

5.2.1 遷移場(chǎng)景服務(wù)器數量規劃

這里借鑒并提供華為的服務(wù)器數量估算方法論做為參考，為簡(jiǎn)化計算過(guò)程，所有管理、計算和存儲虛擬化軟件節點(diǎn)的CPU資源開(kāi)銷(xiāo)按照10%進(jìn)行計算，內存資源開(kāi)銷(xiāo)按照每臺物理機100GB進(jìn)行估算。

注：CPU和內存的開(kāi)銷(xiāo)需要按照預計采購的超融合系統進(jìn)行修正。

5.2.1.1 從計算服務(wù)器CPU維度進(jìn)行估算

使用SPECint2006 Rate進(jìn)行折算。

單服務(wù)器需要計算能力=物理服務(wù)器的SPECCPU使用率/（1-CPU冗余度）

（1）現有舊物理服務(wù)器計算能力折算方法：

所有n臺原服務(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）部署虛擬化平臺的物理服務(wù)器的CPU能力計算方法：

假設部署虛擬化平臺的單個(gè)物理服務(wù)器的SPEC值為y，單物理服務(wù)器的總邏輯核數為z。

虛擬化服務(wù)器的數量 N = x/(y90%),結果向上取其整數即可。如果數量≤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(s) 8.00GB的服務(wù)器的實(shí)際平均CPU使用率為30%。

獲取其SPEC值為118。假定虛擬化后的目標CPU能力冗余度30%。

x = 40（11830%/（1-30%））=2022.857

若最終選擇Intel Xeon E5-4610 ，得到其SPEC值為883。服務(wù)器共48邏輯核，部署所有管理、計算和存儲虛擬化軟件節點(diǎn)的CPU資源開(kāi)銷(xiāo)為10%。

虛擬化服務(wù)器的數量N=2022.857/(88390%)=2.545，虛擬化服務(wù)器的數量為3臺。

5.2.1.2 從計算服務(wù)器內存維度進(jìn)行估算

直接使用內存使用量進(jìn)行計算。

單計算服務(wù)器實(shí)際需要的內存（虛擬化后）=現有物理服務(wù)器的內存內存使用率/（1-內存冗余度）

（1）現有物理服務(wù)器內存折算方法：

所有n臺原服務(wù)器內存折算值 x = 現有服務(wù)器1的內存值內存使用率1/(1-內存冗余度)

+現有服務(wù)器2的內存值內存使用率2/(1-內存冗余度)

+ …..

+現有服務(wù)器n的內存值內存使用率n/(1-內存冗余度)

（2）所需虛擬化服務(wù)器的內存計算方法：

假設虛擬化后的單個(gè)服務(wù)器的內存值為 z。部署所有管理、計算和存儲虛擬化軟件節點(diǎn)的內存資源開(kāi)銷(xiāo)為100GB。虛擬化后的服務(wù)器實(shí)際能給虛擬機用的內存y=z-100GB，每臺至少配置100GB以上，建議配置256GB。

虛擬化服務(wù)器的數量 N = x/y，結果向上取其整數即可。如果數量≤3，那么至少配置3臺。如果數量太多，請增加單臺服務(wù)器的內存容量。

舉例：

假定原服務(wù)器的內存大小為8G，內存使用率為20%，共40臺。虛擬化后的目標內存冗余度為40%

x =40（ 820%/（1-40%））=106.7GB

假定Intel Xeon E5-4610配置256GB內存（要求必須大于100GB），則實(shí)際可用的內存為：

y=z-100GB

=256GB-100GB

=156GB

從內存容量上看，需要純計算節點(diǎn)的個(gè)數：

虛擬化服務(wù)器的數量 N = x/y=106.7GB/156GB=0.684，虛擬化服務(wù)器的數量為3臺。

5.2.2 新建場(chǎng)景服務(wù)器數量規劃

這里借鑒并提供華為的服務(wù)器數量估算方法論做為參考，為簡(jiǎn)化計算過(guò)程，所有管理、計算和存儲虛擬化軟件節點(diǎn)的CPU資源開(kāi)銷(xiāo)按照10%進(jìn)行計算，內存資源開(kāi)銷(xiāo)按照每臺物理機100GB進(jìn)行估算。

注：CPU和內存的開(kāi)銷(xiāo)需要按照預計采購的超融合系統進(jìn)行修正。

5.2.2.1 根據CPU資源需求維度估算

適用于對虛擬化后使用虛擬機規格（CPU、內存、磁盤(pán)、網(wǎng)卡）、虛擬機的數量都有清晰認識的場(chǎng)景，能夠規劃出各類(lèi)虛擬機的規格和所需的數量：

總vCPU數=預計部署的每臺VM虛擬機的vCPU數量的總和

注：vCPU是衡量一臺虛擬機計算能力的主要指標，類(lèi)似物理服務(wù)器的CPU。vCPU核數類(lèi)似服務(wù)器CPU的核數（core）。一個(gè)利用率100％的vCPU的處理能力等于物理CPU一個(gè)超線(xiàn)程的處理能力。

1、根據計算能力總需求估算

CPU總物理核數=roundup（總vCPU數/單核超線(xiàn)程數/CPU利用率）

2、估算所需的服務(wù)器數量

物理服務(wù)器數量=roundup{[(CPU總物理核數/(服務(wù)器CPU個(gè)數CPU物理核數）90%]（1+服務(wù)器冗余率）}

結果向上取其整數即可。如果數量≤3，那么至少配置3臺。

舉例：

假定總vCPU的數量為100，服務(wù)器冗余率設定為30%，CPU利用率不超過(guò)70%，部署所有管理、計算和存儲虛擬化軟件節點(diǎn)的CPU資源開(kāi)銷(xiāo)為10%，擬定選擇的超融合服務(wù)器為2顆12核心處理器2線(xiàn)程處理器。那么：

CPU總物理核數=roundup（總vCPU數/單核超線(xiàn)程數/CPU利用率）

= roundup（100/2/0.7）

=72

物理服務(wù)器數量為=roundup{[(72/(212）90%]（1+30%）}

= roundup{4.3}

物理服務(wù)器數量：需要5臺。

5.2.2.2 根據內存資源需求維度估算

1、內存總需求

總內存=預計部署的每臺VM虛擬機的內存數量的總和

注：內存大小是指虛擬機內存的最大規格值。

2、根據內存總需求估算

根據內存資源需求估算的服務(wù)器數量= roundup[(總內存/（單服務(wù)器內存容量-100GB）（1+服務(wù)器冗余率）]

結果向上取其整數即可。如果數量≤3，那么至少配置3臺。如果數量太多，請增加單臺服務(wù)器的內存容量。

舉例：

假定總內存的數量為360GB，服務(wù)器冗余率設定為30%，部署所有管理、計算和存儲虛擬化軟件節點(diǎn)的內存資源開(kāi)銷(xiāo)為100GB，擬定選擇的超融合服務(wù)器為256GB內存（至少100GB以上）。

物理服務(wù)器數量=roundup[(總內存/（單服務(wù)器內存容量-100GB）（1+服務(wù)器冗余率）]

=roundup[(360GB/（256GB-100GB）*（1+30%）]

=roundup[3]

物理服務(wù)器數量：需要3臺

5.3 存儲資源規劃

超融合系統架構提供的存儲資源，都是基于分布式的文件系統，可以將一組集群內的節點(diǎn)組成一個(gè)統一的分布式存儲平臺。對于業(yè)務(wù)系統來(lái)說(shuō)，就是一個(gè)集中的共享式存儲，與任何其他集中式存儲陣列一樣工作，由超融合存儲系統管理模塊對分布式存儲進(jìn)行管理。

超融合分布式存儲系統的配置規劃，需要根據歷史業(yè)務(wù)對資源的需求推導出需要新采購的超融合服務(wù)器的硬盤(pán)數量。包括遷移場(chǎng)景需要的硬盤(pán)數量和新建場(chǎng)景需要的硬盤(pán)數量。如果沒(méi)有可供利舊的服務(wù)器，那么這兩個(gè)部分相加，就是全部的計算資源總量。為了減小不必要要的服務(wù)器數量，單盤(pán)盡量選擇1.2TB或1.8TB產(chǎn)品。當然，為了使用更多的硬盤(pán)提升分布式存儲性能，還需要綜合考量。

以上除了需要提前確認好數據容量以外，還需要注意以下幾點(diǎn)：

1、分布式存儲架構以可以提供傳統集中式存儲的能力，包括塊存儲、文件存儲和對象存儲等。但并不是所有的超融合系統都能提供以上的存儲能力。由于分布式存儲的數據一致性不是很好，所以有些超融合系統提供的塊存儲服務(wù)是不能夠安裝ORACLE這類(lèi)數據庫應用的，即使能安裝，效果也不會(huì )很好，性能會(huì )比較低。需要官方給出可安裝的測試報告或者兼容性測試報告。

2、是否需要超融合存儲系統提供快照、克隆、壓縮和重復數據刪除等傳統集中式存儲的特性。由于超融合系統也是近幾年剛剛興起，對于這類(lèi)高級特性不如傳統集中式存儲支持的好，如果需要某種高級特性，需要提前對超融合廠(chǎng)商的相關(guān)存儲產(chǎn)品進(jìn)行調研，做好POC測試。

3、分布式存儲資源池的組成通常為SSD+HDD的架構，SSD作為緩存盤(pán)，提升整個(gè)系統的性能。而且有的廠(chǎng)商要求嚴格的資源配比，以VSAN為例，需要1塊SSD+最多6塊HDD為一個(gè)邏輯磁盤(pán)組（VMware計劃增加到最多7塊）。而且1臺物理主機最多只能有5個(gè)磁盤(pán)組。所以物理磁盤(pán)不能隨意配置，需要根據超融合廠(chǎng)商的技術(shù)要求進(jìn)行合理配置，避免資源浪費。當然也有的超融合廠(chǎng)商支持全閃存的架構，甚至可以使用PCI-E的SSD緩存卡進(jìn)行加速，只是在成本上比較貴。

4、超融合的節點(diǎn)的硬盤(pán)數量會(huì )影響整個(gè)分布式存儲系統的性能。如果超融合系統只有最少的3個(gè)節點(diǎn)，那么分布式存儲系統的性能上基本上是無(wú)法超越傳統集中式架構存儲的，只有盡可能多的配置節點(diǎn)數量和硬盤(pán)數量，才有可能達到甚至超越傳統集中式存儲的性能。

5.3.1 遷移場(chǎng)景存儲容量規劃

這里借鑒并提供華為的存儲容量估算方法論做為參考。由于IOPS不太容易評估，為簡(jiǎn)化計算過(guò)程，只考慮容量的計算。對于分布式存儲的性能規劃，建議通過(guò)POC測試進(jìn)行，理論和實(shí)際往往差距較大。

容量計算：

基礎數據：總的有效容量=x，磁盤(pán)標稱(chēng)容量=z，磁盤(pán)空間利用率=q，副本數=k
總的硬盤(pán)數量=roundup[總的有效容量/(zq)k]（向上取整）

舉例：

假定現有需要遷移的數據，總計20000GB，預計購買(mǎi)的超融合服務(wù)器每臺的磁盤(pán)標稱(chēng)容量z=1200GB，磁盤(pán)空間利用率q=0.95，副本數k=3.

按容量計算，硬盤(pán)數量為：

則利用上述公式：

總的硬盤(pán)數量= roundup[20000/(1200GB0.95)3]

總的硬盤(pán)數量= roundup[20000/(1140)*3] 

總的硬盤(pán)數量= roundup[52.633] 

總的硬盤(pán)數量為53塊硬盤(pán)，每塊盤(pán)容量至少為1200GB。

如果要加入SSD固態(tài)硬盤(pán)做熱點(diǎn)遷移和自動(dòng)分層，需要按照超融合系統要求的比例，購買(mǎi)SSD固態(tài)硬盤(pán)。

5.3.2 新建場(chǎng)景存儲容量規劃

這里借鑒并提供華為的存儲容量估算方法論做為參考。由于IOPS不太容易評估，為簡(jiǎn)化計算過(guò)程，只考慮容量的計算。對于分布式存儲的性能規劃，建議通過(guò)POC測試進(jìn)行，理論和實(shí)際往往差距較大。

1、存儲總容量需求

類(lèi)型i系統盤(pán)容量=系統盤(pán)空間×VM數量；

系統盤(pán)總容量=∑類(lèi)型i系統盤(pán)容量

類(lèi)型i數據盤(pán)容量=數據盤(pán)空間×VM數量；

數據盤(pán)總容量=∑類(lèi)型i數據盤(pán)容量

2、根據存儲總需求估算

根據存儲空間計算所需的硬盤(pán)數量：

總的硬盤(pán)數量=roundup[(系統盤(pán)總容量+數據盤(pán)總容量）副本數k/單盤(pán)容量z/磁盤(pán)容量利用率q]

舉例：

假定現有虛擬機VM數量為100個(gè)，每個(gè)操作系統占用30GB空間，每個(gè)虛擬機數據盤(pán)空間需求為50GB。預計購買(mǎi)的超融合服務(wù)器每臺的磁盤(pán)標稱(chēng)容量z=1200GB，磁盤(pán)空間利用率q=0.95，副本數k=3.

系統盤(pán)總容量=30GB100=30000GB

數據盤(pán)總容量=50GB100=50000GB

按容量計算，硬盤(pán)數量為：

總的硬盤(pán)數量=roundup[(30TB+50TB）3/1.2TB/0.95]

= roundup[80tb*3/1.2TB/0.95]

= roundup[210.53]

總的硬盤(pán)數量為211塊硬盤(pán)，每塊盤(pán)容量至少為1200GB。

如果要加入SSD固態(tài)硬盤(pán)做熱點(diǎn)遷移和自動(dòng)分層，需要按照超融合系統要求的比例，購買(mǎi)SSD固態(tài)硬盤(pán)。

5.4 網(wǎng)絡(luò )資源規劃

5.4.1 組網(wǎng)策略

在超融合的架構中，多臺虛擬機之間是共享網(wǎng)絡(luò )的，為了方便管理，一般采用虛擬交換機來(lái)配置和管理網(wǎng)絡(luò )，虛擬交換機可在數據中心級別提供集中和聚合的虛擬網(wǎng)絡(luò )，從而簡(jiǎn)化并增強虛擬機網(wǎng)絡(luò )。在虛擬交換機的網(wǎng)絡(luò )劃分上，仍然可以采用VLAN的方式劃分不同的子網(wǎng)，實(shí)現不同子網(wǎng)段的安全和隔離。

除了虛擬交換機，還可以通過(guò)Overlay的方式來(lái)構建大二層和實(shí)現業(yè)務(wù)系統之間的租戶(hù)隔離，通過(guò)NFV實(shí)現網(wǎng)絡(luò )中的所需各類(lèi)網(wǎng)絡(luò )功能資源（包括基礎的路由交換、安全以及應用交付等）按需分配和靈活調度，從而實(shí)現超融合架構中的網(wǎng)絡(luò )虛擬化。這類(lèi)功能同時(shí)需要客戶(hù)的物理交換機支持SDN的管理方式，如果是一些老舊設備，可能無(wú)法實(shí)現，需要購置新的交換機設置。

5.4.2 網(wǎng)絡(luò )拓撲

在每個(gè)單節點(diǎn)的物理機上，需要提供以下網(wǎng)絡(luò )端口：

萬(wàn)兆光口：至少1個(gè)

千兆電口：至少2個(gè)

在每個(gè)超融合物理節點(diǎn)上有多種網(wǎng)絡(luò )需求，包括生產(chǎn)網(wǎng)絡(luò )、數據交換網(wǎng)絡(luò )、管理網(wǎng)絡(luò )、生產(chǎn)網(wǎng)絡(luò )等，因此每個(gè)物理節點(diǎn)建議配置多塊網(wǎng)卡，并保證每個(gè)節點(diǎn)通過(guò)兩條萬(wàn)兆或千兆鏈路分別連接兩臺交換機，保證網(wǎng)絡(luò )設備和鏈路的冗余度。

網(wǎng)絡(luò )設計建議如下：

1、生產(chǎn)網(wǎng)絡(luò )（原有生產(chǎn)網(wǎng)絡(luò )，同時(shí)也是客戶(hù)機和虛擬化服務(wù)器之間的網(wǎng)絡(luò )通訊）

可采用雙鏈路千兆以太網(wǎng)絡(luò )，如果原有雙鏈路萬(wàn)兆網(wǎng)絡(luò )，那么可以繼續延用。當用戶(hù)的客戶(hù)機訪(fǎng)問(wèn)虛擬服務(wù)器時(shí)，通過(guò)生產(chǎn)網(wǎng)絡(luò )可分流后端存儲流量并且進(jìn)行隔離。

2、數據交換網(wǎng)（X86物理服務(wù)器之間的內部通訊網(wǎng)絡(luò )）

至少采用雙鏈路萬(wàn)兆光纖網(wǎng)絡(luò )，由于分布式存儲數據交換和虛擬機之間的通訊都需要占用大量的網(wǎng)絡(luò )帶寬，當發(fā)生密集的寫(xiě)IO時(shí)，萬(wàn)兆網(wǎng)絡(luò )能保證提供足夠帶寬滿(mǎn)足節點(diǎn)之間的IO同步流量。建議單獨配置1塊萬(wàn)兆網(wǎng)卡。

3、管理網(wǎng)絡(luò )（管理X86物理服務(wù)器節點(diǎn)）

可采用雙鏈路千兆以太網(wǎng)絡(luò )，主要用于節點(diǎn)管理。建議單獨配置1塊千兆網(wǎng)卡，實(shí)現管理網(wǎng)絡(luò )與業(yè)務(wù)網(wǎng)絡(luò )、存儲網(wǎng)絡(luò )分離?？梢宰畲笙薅缺ＷC管理的靈活性和安全性。

5.5 安全和備份規劃

超融合系統的設計還需要考慮安全設計。

首先，在物理安全上，建議將超融合節點(diǎn)分別部署到3個(gè)不同的機柜中，每個(gè)機柜部署1個(gè)節點(diǎn)，最大化做到故障域的隔離。每個(gè)機柜雙路供電，實(shí)現真正的供電冗余。

其次，要考慮滿(mǎn)足國家等保的要求還有醫療客戶(hù)自身的安全需求。在安全產(chǎn)品的部署上，可以延用原有的安全設備，也可以選擇支持安全虛擬化的超融合產(chǎn)品。例如深信服超融合產(chǎn)品，可以集成集成分布式防火墻、4-7層虛擬防火墻、虛擬數據庫審計等虛擬安全組件，并結合深信服安全產(chǎn)品，幫助客戶(hù)構建從邊界安全、平臺安全、數據安全到應用安全的全方位安全防護體系，并利用安全可視化，對安全事件全過(guò)程進(jìn)行安全保障：事前漏洞評估，事中全方位防護，事后持續威脅檢測。

超融合架構可以提供跨數據中心的容災及應用級高可用解決方案。超融合架構具備面向數據的備份及恢復機制，以更經(jīng)濟的方式實(shí)現數據的安全存儲和管理，并結合負載均衡、虛擬化軟件層高可用機制，提供了應用層面的跨數據中心業(yè)務(wù)連續性訪(fǎng)問(wèn)能力。

大部分超融合系統都可以提供基于虛擬機快照的方式將更新數據異步復制到遠端的超融合系統集群中。如果有容災建設的需求，需要提前規劃好容災復制模式，選擇合適的雙向復制、一對多復制或者多對一的數據復制模式。

傳統的備份方式通過(guò)網(wǎng)絡(luò )傳輸備份數據，需要特定的備份窗口以免影響業(yè)務(wù)正常運行。超融合產(chǎn)品備份可以與傳統的備份策略互補，既能保證對于重要的虛擬機進(jìn)行高頻次備份又不會(huì )占用額外的網(wǎng)絡(luò )帶寬。

例如：對于普通虛擬機可以使用傳統的備份方式每周進(jìn)行全備，將備份數據備份到外部存儲中，同時(shí)使用超融合自帶的備份管理系統進(jìn)行每天甚至每12小時(shí)的備份，數據直接保留在存儲上以便快速恢復。對于比較重要的虛擬機可以使用傳統備份每周全備、每天增量的方式，將備份數據備份到外部存儲中，同時(shí)使用超融合自帶的備份管理系統進(jìn)行每2小時(shí)甚至每小時(shí)的備份，數據直接保留在存儲上以便快速恢復。

6 云管理平臺設計

基于超融合架構的云計算并不簡(jiǎn)單等同于傳統架構的虛擬化，而是綜合運用虛擬化、標準化和自動(dòng)化等一系列技術(shù)對醫院的信息化進(jìn)行全面優(yōu)化。因此搭建面統一的云管理平臺還是非常有必要的。

在一些最佳實(shí)踐中，醫院信息中心已經(jīng)從一個(gè)成本中心變成一個(gè)可以交付有形價(jià)值和差異化能力的核心部門(mén)。在這場(chǎng)IT價(jià)值的變革中，云計算的作用至關(guān)重要，可以讓醫院降低對IT的一次性投入的同時(shí)，還可以根據業(yè)務(wù)變化動(dòng)態(tài)調整資源，以快速響應業(yè)務(wù)需求。

如果已經(jīng)有了云管理平臺，那么需要考入如何將超融合系統整合到云平臺中，可以利用超融合廠(chǎng)商的工具與現有云管進(jìn)行集成或者邀請原有云管廠(chǎng)商進(jìn)行二次開(kāi)發(fā)集成。這些是需要在選擇超融合架構之前必須要考慮的一個(gè)問(wèn)題，否則后期管理起來(lái)非常困難，還會(huì )增加很多的管理成本。

6.1 主要功能

云管理平臺是面向云計算領(lǐng)域的通用云管理環(huán)境，在動(dòng)態(tài)數據中心構建及運維過(guò)程中提供全方位、多層次的管理及監控能力，基于云環(huán)境實(shí)現應用的快速部署及資源的彈性供應，通過(guò)簡(jiǎn)化管理極大地降低成本、提高效益。通過(guò)集中式的資源管理模式整合虛擬化數據中心的計算、存儲和網(wǎng)絡(luò )資源，并通過(guò)自助式門(mén)戶(hù)以隨需即取的方式提供用戶(hù)申請、配置和使用。

云計算管理平臺可以根據超融合系統資源構建統一的資源池，并能實(shí)現對資源池的創(chuàng )建、修改、刪除等管理功能。

云管理平臺要求能夠屏蔽虛擬化平臺異構性。因為原有數據中心的虛擬化系統很有可能是異構的，或者新采購的超融合系統虛擬化也有可能與原有虛擬化系統不同，所以要求云管理平臺能夠支持主流的虛擬化平臺包括VMware、Xen、KVM、XenServer、RHEV，PowerVM等，簡(jiǎn)化管控復雜度，提供集中式監管多虛擬化平臺資源，對資源進(jìn)行精細化管理、自動(dòng)化運維，提供集中、統一監控運維管理平臺，降低數據中心運維成本。

云計算管理平臺主要功能如下：

門(mén)戶(hù)管理、資源管理、資源申請審批管理、資源調度和分配管理、運維與監控管理、故障告警管理、權限管理、用戶(hù)管理、計費管理、安全管理、能耗管理、接口管理、統計報表和系統管理。

6.2 資源使用與管理

超融合系統在建設完成后，其資源主要由云管理平臺進(jìn)行統一管理。

建議采用以下兩種模式，進(jìn)行資源的使用與管理。

模式一：部門(mén)具備一定的信息化能力（如：醫院信息中心及分院信息管理部門(mén)等）。一次性申請批量資源，由云管理平臺管理部門(mén)經(jīng)過(guò)審批分析后，批準并分配資源，之后，使用者在部門(mén)內部進(jìn)行個(gè)人資源申請、審批，具備了“自治管理”能力；而通過(guò)流程控制和資源監控，達到“集中管控”的效果。

模式二：部門(mén)不具備信息化能力（如：醫院骨科、眼科等業(yè)務(wù)科室），如果有資源需求，就會(huì )向云管理平臺管理部門(mén)提交申請，經(jīng)過(guò)審批分析后，批準或駁回申請，動(dòng)態(tài)分配及收回資源。

7 超融合架構建設難點(diǎn)分析

7.1 信息孤島治理

7.1.1 產(chǎn)生背景和原因

在醫療行業(yè)傳統數據中心，每個(gè)業(yè)務(wù)系統建設都是一套硬件設備對應一套應用的建設模式，因此產(chǎn)生了越來(lái)越多的“信息孤島”。隨著(zhù)系統逐步增加，這種煙囪式IT架構的問(wèn)題逐漸暴露出來(lái)，如分散式管理復雜、機房設備多、利用率低等。

超融合平臺項目建設的初衷是把這些系統的數據業(yè)務(wù)打通，在底層形成計算和存儲的資源池，針對不同的業(yè)務(wù)動(dòng)態(tài)提供按需劃分的能力。但是，實(shí)際上的情況是，醫療用戶(hù)在部署了超融合系統以后，會(huì )出現更多的“信息孤島”。

在數據中心層面：所有的超融合方案都是分布式存儲，也必須是分布式存儲，不會(huì )支持數據中心中原有傳統的集中式存儲，而且大多數醫療用戶(hù)也不可能在短期內更換原有的服務(wù)器和存儲等設備，最終的結果就是，數據中心被分裂成兩個(gè)彼此獨立分散的“信息孤島”。

在業(yè)務(wù)應用層面：目前超融合系統通常僅支持一種或多種虛擬化環(huán)境，例如VMware超融合架構僅支持VMware vSphere，不支持KVM。而華為和H3C等超融合方案基本都不支持Hyper-V虛擬化。每種虛擬化環(huán)境都有各自的優(yōu)勢，很多情況下用戶(hù)可能要部署多套超融合環(huán)境。還有一點(diǎn)就是不同超融合平臺之間無(wú)法整合和互操作，舉個(gè)例子：如果一個(gè)醫院買(mǎi)了DELLEMC的VxRail超融合平臺，那么以后擴容不能再買(mǎi)其他超融合產(chǎn)品進(jìn)行擴容，只能繼續選擇VxRail超融合產(chǎn)品，如果選擇其他超融合產(chǎn)品進(jìn)行擴容，結果就是又多了幾個(gè)新的“信息孤島”。

7.1.2 解決方案

在醫療行業(yè)客戶(hù)考慮轉向超融合架構之前，必須充分的認識到新架構的變化帶來(lái)的諸多問(wèn)題。由于超融合架構是一種全新的架構，短期內不可能完全替代傳統的數據中心，所以信息孤島問(wèn)題是必然存在的，需要在管理上提升認識，充分考慮現有業(yè)務(wù)的需求，進(jìn)行平衡考量，對現有數據中心的老舊設備和新的超融合設備進(jìn)行統一管理，綜合運維。在超融合產(chǎn)品的選擇上，要結合現有的業(yè)務(wù)部署環(huán)境、虛擬化環(huán)境并結合數據中心的未來(lái)發(fā)展進(jìn)行認真考量，不能有以往采購硬件設備時(shí)那種以?xún)r(jià)格優(yōu)先的選擇方法。必須充分對現有業(yè)務(wù)系統進(jìn)行調研，需要哪種虛擬化平臺，盡量選擇支持異構虛擬化的超融合產(chǎn)品，而且超融合產(chǎn)品的選型決定了未來(lái)數據中心的發(fā)展方向，是走商業(yè)化產(chǎn)品路線(xiàn)還是開(kāi)源產(chǎn)品路線(xiàn)，都需要考慮清楚。如果僅以?xún)r(jià)格便宜作為優(yōu)先考慮方案，那么可能會(huì )導致適用性差，擴展受限等問(wèn)題，而且日后可能還會(huì )產(chǎn)生更多的信息孤島。

7.2 超融合系統性能優(yōu)化和節點(diǎn)管理

7.2.1 產(chǎn)生背景和原因

超融合架構的優(yōu)點(diǎn)是易于擴展和部署，按需擴容。通常采用X86硬件平臺+軟件定義技術(shù)實(shí)現計算、存儲、網(wǎng)絡(luò )等功能的統一。軟件定義屏蔽了以往異構設備的復雜性，實(shí)現完全分布式，去中心化，系統不存在任意單點(diǎn)故障。超融合通常3節點(diǎn)起配，并且可以擴容到數十節點(diǎn)。超融合節點(diǎn)中的計算能力、存儲性能和容量是同步擴容的，但是卻無(wú)法滿(mǎn)足現實(shí)中單項能力的擴展。

在計算性能方面，大部分超融合產(chǎn)品都是基于2U的X86服務(wù)器，CPU數量通常為1-2顆，單個(gè)虛擬機的性能最大只能達到單個(gè)節點(diǎn)的70%（超融合系統本身和分布式存儲要占用30%的計算性能），而且不能像超算那樣，利用所有節點(diǎn)進(jìn)行統一計算。在這條件下，高性能應用可能不太適合部署，而且性能會(huì )受限于單臺節點(diǎn)的性能。

在存儲性能方面，在傳統存儲集中式系統中，由于其物理I/O路徑較短，通常為機頭控制器后端再掛載磁盤(pán)組。而且采用Raid等數據保護算法比基于分布式存儲的副本數據保護模式，在計算開(kāi)銷(xiāo)上小很多。在分布式存儲中，至少由3臺服務(wù)器組成，通常使用3副本模式。一個(gè)I/O通過(guò)網(wǎng)絡(luò )，需要在多個(gè)副本服務(wù)器上進(jìn)行處理，而且每個(gè)副本都有數據一致性檢查算法，這些操作都將增加I/O的時(shí)延。分布式存儲系統的數據一致性會(huì )引發(fā)另外一個(gè)性能問(wèn)題。數據一致性可以理解為應用程序運行的數據狀態(tài)與最終寫(xiě)入到磁盤(pán)中的數據狀態(tài)是否一致。在數據庫等OLTP高并發(fā)業(yè)務(wù)場(chǎng)景下，數據一致性的保障可大大提高系統的可靠性和容錯性，避免數據出錯。傳統存儲是集中式緩存管理，集群中所有節點(diǎn)均不維護本地緩存，而是所有節點(diǎn)共享訪(fǎng)問(wèn)一個(gè)集中存放的緩存，數據在緩存中只有一份副本，不會(huì )出現多份副本，具有天然的緩存一致性。分布式存儲因為每個(gè)節點(diǎn)都有自己獨享的緩存，存在多個(gè)副本，需要一個(gè)特殊過(guò)程來(lái)維護緩存一致性。通常需要采用低時(shí)延的高速網(wǎng)絡(luò )來(lái)實(shí)現緩存協(xié)議流量，最終實(shí)現任意關(guān)聯(lián)分布式緩存一致性。帶來(lái)的問(wèn)題是副本之間的強一致特性導致只要有一個(gè)副本響應稍慢，整個(gè)I/O的時(shí)延將增加，導致性能下降。

為了提升超融合平臺的性能，需要不斷的增加節點(diǎn)數量。但是節點(diǎn)數量的增加又會(huì )導致管理上的問(wèn)題。集群達到一定規模后，其復雜性就會(huì )非線(xiàn)性增加，在管理上變的更加困難，硬件故障率也會(huì )大幅度增加，所以并不是超融合系統的群集越大越好。如果為了性能而不斷增加群集規模，還會(huì )產(chǎn)生均衡問(wèn)題。因為超融合架構所有的計算和存儲資源都是均衡分布的，在擴容或者是節點(diǎn)設備故障時(shí)，都會(huì )發(fā)生計算和存儲資源的均衡遷移，雖然這個(gè)過(guò)程可以設定為非繁忙時(shí)段靜默完成，但是如果變動(dòng)很大，那么均衡的過(guò)程會(huì )非常漫長(cháng)，在沒(méi)有足夠調整資源的情況下，會(huì )觸發(fā)強制均衡，對正常的業(yè)務(wù)產(chǎn)生影響。

7.2.2 解決方案

在計算性能方面，在進(jìn)行超融合產(chǎn)品部署前，需要根據醫院自身業(yè)務(wù)的性能需求，選擇合適的部署方案。例如：對于性能要求較高的大型OLTP數據庫服務(wù)器，可以考慮單獨部署在4路或8路的物理服務(wù)器上，不要部署在超融合系統中。超融合系統僅適合部署小型的或者對性能要求不高的數據庫。

在存儲性能方面，如果需要將傳統的集中式存儲數據遷移到超融合的分布式存儲中，要考慮性能問(wèn)題。提前做好I/O性能測試，避免性能不足。通常來(lái)講，如果一臺中高端存儲設備，遷移到超融合系統中，要獲取相同性能，至少要有10個(gè)以上的節點(diǎn)，而且要配置SSD閃存。在考慮數據遷移之前，傳統存儲的自動(dòng)精簡(jiǎn)配置、快照、克隆、重復數據刪除、數據加密和數據壓縮等高級特性也需要考慮進(jìn)去，這些通常是超融合架構的分布式存儲所不具備的。

在管理方面，超融合雖然架構簡(jiǎn)化了IT架構，但是如果不考慮實(shí)際需求，盲目擴展，反而會(huì )增加數據中心的復雜性。從超融合產(chǎn)品的角度講，其內部技術(shù)和鏈接配置更加復雜，為了性能不斷的增加節點(diǎn)數量，如果出現故障，問(wèn)題的跟蹤調試和分析診斷也變得更加困難。建議在進(jìn)行超融合架構規劃時(shí)，不要只設定一個(gè)超融合群集，而是要根據業(yè)務(wù)類(lèi)型或者性能分別創(chuàng )建不同的超融合群集，而且盡可能的控制單個(gè)群集的規模數量。