虛擬化獲得成功往往取決于對底層硬件基礎(chǔ)設(shè)施進(jìn)行良好的管理。這聽起來可能像是一個簡單的前提，但當(dāng)數(shù)據(jù)中心混合了各類廠商及各種型號的設(shè)備時，實現(xiàn)該目標(biāo)可能會變得越來越困難，最終受限于各類系統(tǒng)管理工具所能提供的能見度。融合基礎(chǔ)設(shè)施(CI)集成了各類服務(wù)器、存儲及網(wǎng)絡(luò)設(shè)備，充分利用各類資源并使用統(tǒng)一的管理工具對這些設(shè)備進(jìn)行管理，承諾能夠解決某些問題。但CI并不一定適合各種情況，IT專業(yè)人員必須理解CI的元素、CI如何與遺留系統(tǒng)進(jìn)行交互以及CI的最佳部署場景。

在CI中有哪些元素，什么是真正的虛擬化?

CI的目標(biāo)是使用高度集成并經(jīng)過優(yōu)化的硬件套件包括服務(wù)器、存儲以及網(wǎng)絡(luò)設(shè)備取代異構(gòu)的數(shù)據(jù)中心設(shè)備。虛擬化應(yīng)用于服務(wù)器、存儲以及網(wǎng)絡(luò)這三大領(lǐng)域，允許IT專業(yè)人員在眾多虛擬機之間快速池化并部署存儲及網(wǎng)絡(luò)資源，每種資源都能夠輕松地在本地以及遠(yuǎn)程硬件之間遷移。

CI部署中實現(xiàn)的高級虛擬化及靈活性為部署私有云或者是某些類型的軟件定義數(shù)據(jù)中心提供了前提。

CI平臺可以從頭開始構(gòu)建，比如采用IBM的Flex System。IBM的Flex System包括一個IBM Flex System企業(yè)機箱，一些x86或Power服務(wù)器，PCIe擴(kuò)展設(shè)備，IBM Flex System V7000或者Storwise V7000存儲單元以及可選擇的網(wǎng)絡(luò)設(shè)施包括以太網(wǎng)以及IBM Flex System fabric。勾選的硬件都通過單一的管理框架進(jìn)行管理，比如IBM Flex System Manager。

Cisco UCS是另一種選擇。例如，Cisco UCS C系列機架服務(wù)器以及用于UCS機架服務(wù)器的Cisco Nexus Fabric Extender能夠在部署CI時一同使用，同時還可以訪問現(xiàn)有的SAN網(wǎng)絡(luò)。通過UCS Manager或者UCS Director軟件可以管理Cisco UCS。

CI平臺還可以集成多家廠商的設(shè)備。例如，NetApp的FlexPod在經(jīng)過驗證的CI產(chǎn)品中整合了NetApp存儲系統(tǒng)、Cisco UCS服務(wù)器以及Cisco Nexus fabric。Cisco的UCS Director能夠通過單個統(tǒng)一的管理工具對FlexPod的組件進(jìn)行自動化管理。幾乎所有的hypervisor包括Hyper-V或vSphere都能夠提供虛擬化功能。

融合基礎(chǔ)設(shè)施如何與現(xiàn)有的非CI系統(tǒng)進(jìn)行交互?

對于融合基礎(chǔ)設(shè)施環(huán)境來說，異構(gòu)問題一直面臨挑戰(zhàn)。一般來說，CI能夠與非CI設(shè)備(無論虛擬化與否)進(jìn)行交互。例如，不同廠商的服務(wù)器無法添加到現(xiàn)有CI平臺的交換機端口中并非技術(shù)原因。然而，這往往會導(dǎo)致部署CI的意圖以失敗而告終。

請記住融合基礎(chǔ)設(shè)施總的出發(fā)點是使用綜合的管理工具提供單個統(tǒng)一的軟硬件框架。所有的一切都經(jīng)過了調(diào)試并可以協(xié)同工作。當(dāng)外部設(shè)備與CI連接時，新異構(gòu)環(huán)境可能會帶來性能、管理問題或者是其他互操作性問題。傳統(tǒng)異構(gòu)企業(yè)環(huán)境的上述問題為眾人所知，但引入CI后卻不希望發(fā)生這些問題。

現(xiàn)有數(shù)據(jù)中心環(huán)境加入CI，尤其是作為私有云平臺時，通常會使用獨特的管理工具管理CI，而通常按照原有的方式使用其他的管理工具對現(xiàn)有的基礎(chǔ)設(shè)施進(jìn)行管理，對IT員工來說，支持兩種不同的環(huán)境需要做大量不同的工作。

考慮融合基礎(chǔ)設(shè)施時，在做出采購決策前進(jìn)行深入的PoC測試并考慮CI廠商對異構(gòu)或遺留環(huán)境的支持程度是非常重要的。通過測試可以準(zhǔn)確獲知CI如何與現(xiàn)有數(shù)據(jù)中心內(nèi)的異構(gòu)設(shè)備進(jìn)行交互。

如果已經(jīng)有了一個虛擬數(shù)據(jù)中心，有必要遷移到融合基礎(chǔ)設(shè)施嗎?

融合基礎(chǔ)設(shè)施已經(jīng)證明了自己是現(xiàn)代數(shù)據(jù)中心一個很不錯的選擇。和典型的異構(gòu)數(shù)據(jù)中心相比，CI能夠提供一個更加穩(wěn)定、靈活及更易于管理的高性能虛擬基礎(chǔ)設(shè)施。但CI僅僅是一個用于處理企業(yè)計算任務(wù)的工具，和其他工具一樣，理解什么時候以及如何最高效地使用CI是很重要的。

CI bundle(服務(wù)器、存儲以及網(wǎng)絡(luò))在本質(zhì)上取代了現(xiàn)有的數(shù)據(jù)中心基礎(chǔ)設(shè)施以及在基礎(chǔ)設(shè)施、軟件許可以及服務(wù)協(xié)議上的投資。很少有組織希望丟掉在現(xiàn)有數(shù)據(jù)中心中的投資，轉(zhuǎn)而使用一個全新的平臺，這恰恰是CI未獲得廣泛認(rèn)可的原因所在。在很多情況下，只有更新技術(shù)或者啟用新數(shù)據(jù)中心時才會考慮采用CI，管理員應(yīng)該尋找部署CI平臺后重新利用舊基礎(chǔ)設(shè)施的方式。

CI可能會給廠商帶來挑戰(zhàn)。雖然CI平臺設(shè)計實現(xiàn)了高可擴(kuò)展性，但意識到與CI bundle兼容的產(chǎn)品非常有限是非常重要的。有限的產(chǎn)品選擇(以及對CI廠商產(chǎn)品生命周期及發(fā)展藍(lán)圖的依賴)往往會轉(zhuǎn)化為更高的產(chǎn)品成本而且在今后可能會在產(chǎn)品生命周期上面臨挑戰(zhàn)。

組織的計算需求以不可預(yù)知的方式增長在產(chǎn)品升級時可能會面臨成本挑戰(zhàn)。這與傳統(tǒng)的異構(gòu)數(shù)據(jù)中心差異很大，在傳統(tǒng)數(shù)據(jù)中心中可以使用任一x86服務(wù)器或者以太網(wǎng)交換機。

其他基礎(chǔ)設(shè)施模式比如主機托管以及提供高效計算資源及所有必要支持的公有云服務(wù)商(只需要支付月租費而沒有采購成本)同樣會延緩CI的部署進(jìn)程。當(dāng)組織尋求更好地控制IT支出時，將CAPEX轉(zhuǎn)換為OPEX變得越來越有吸引力。

融合基礎(chǔ)設(shè)施平臺能夠大大提升IT運維及系統(tǒng)管理的效率，但該技術(shù)可能無法與現(xiàn)有的數(shù)據(jù)中心進(jìn)行充分的交互。采用投資回報率分析以及徹底的PoC測試應(yīng)該能夠清晰地證明CI部署的合理性。此外，基于可預(yù)見的計算需求評估CI廠商的產(chǎn)品路線圖組織能夠減少今后技術(shù)分裂的可能性。如果CI勢單力薄，那么組織應(yīng)該繼續(xù)采用更為傳統(tǒng)的數(shù)據(jù)中心模式。