數(shù)據(jù)中心整合的吸引力和挑戰(zhàn)

繁重的數(shù)據(jù)處理工作量可能會給數(shù)據(jù)中心帶來巨大壓力。考慮到大數(shù)據(jù)項目可能需要數(shù)百甚至數(shù)千臺服務(wù)器的計算能力,才能處理數(shù)兆字節(jié)甚至數(shù)PB的存儲數(shù)據(jù)來完成可能只需要幾個小時才能完成的任務(wù)。

數(shù)據(jù)中心整合一直是數(shù)據(jù)中心增長和管理的關(guān)鍵因素。能夠100%使用和共享每臺服務(wù)器,有助于控制硬件、電源、冷卻和物理數(shù)據(jù)中心空間的螺旋式上升的成本。

鞏固的鐘擺只能搖擺到現(xiàn)在。有價值,但是在某些情況下,企業(yè)可能需要重新考慮整合,并考慮只有更多硬件才能提供的好處。

將資源和服務(wù)放置在主要數(shù)據(jù)中心之外是對網(wǎng)絡(luò)局限性,規(guī)模和冗余性對于組織至關(guān)重要的情況的合理響應(yīng)。重要的是要分別考慮每種情況及其備選方案,并做出最適合業(yè)務(wù)的選擇。

整合的吸引力和挑戰(zhàn)

服務(wù)器虛擬化與管理程序軟件的結(jié)合提供了擴展的處理器命令集,以從底層計算硬件中提取應(yīng)用程序。

將物理計算資源轉(zhuǎn)換為邏輯等效項后,工作負(fù)載就可以使用比以往更多的可用資源,并以通過在裸機上安裝應(yīng)用程序所無法實現(xiàn)的方式共享這些資源。

自從引入服務(wù)器整合以來,虛擬化已發(fā)展為擴展并支持其他資源的整合,包括I/O和網(wǎng)絡(luò)元素,并允許更多共享有限數(shù)據(jù)中心容量。

隨著虛擬化和整合縮小公司數(shù)據(jù)中心的規(guī)模,企業(yè)可能會意識到,整合并非總是追求單一目標(biāo)。

整合已成為某些組織必不可少的好處,但是數(shù)據(jù)中心整合最終會遇到以下物理限制的嚴(yán)峻現(xiàn)實:

服務(wù)器內(nèi)部存在物理限制??缁A(chǔ)架構(gòu)共享的內(nèi)存和CPU周期數(shù)量有限。虛擬化可以在一定程度上共享那些有限的資源,但并非沒有VM的性能下降風(fēng)險。

跨網(wǎng)絡(luò)存在物理限制。管理員可以共享可用帶寬,但是總網(wǎng)絡(luò)帶寬是有限的。在可接受的時間范圍內(nèi)跨全球距離交換數(shù)據(jù)需要足夠的帶寬,并引入了不希望的延遲物理限制。

操作可靠性存在物理限制。服務(wù)器、存儲和網(wǎng)絡(luò)設(shè)備最終會失效。其后果可能會影響重要的數(shù)據(jù)中心基礎(chǔ)設(shè)施和系統(tǒng)上的所有虛擬機。在傳統(tǒng)的物理服務(wù)器部署中,服務(wù)器故障僅影響托管應(yīng)用程序。在運行8個或10個虛擬機的整合服務(wù)器中,相同的服務(wù)器故障將影響所有這些虛擬機。

被數(shù)據(jù)中心整合阻礙的用例

業(yè)務(wù)和IT領(lǐng)導(dǎo)者可以在幾個關(guān)鍵使用案例中提出令人信服的反對整合的理由,這些案例取決于基礎(chǔ)設(shè)施的恢復(fù)能力、距離、規(guī)模和隔離程度。

彈性

冗余工作負(fù)載部署是提高工作負(fù)載吞吐量的常見做法。這有效地使應(yīng)用程序使用負(fù)載平衡器執(zhí)行跨重要實例的流量集中化的重要工作。盡管重復(fù)實例的數(shù)量提高了冗余性,但是選擇部署位置(物理服務(wù)器)定義了應(yīng)用程序的彈性。

如果企業(yè)的策略是提高工作負(fù)載吞吐量,則重復(fù)的實例可能會位于同一臺整合服務(wù)器上。但是,這通常被認(rèn)為是不好的做法,因為潛在的系統(tǒng)故障可能會停止這些額外的工作負(fù)載實例。

當(dāng)目標(biāo)包含應(yīng)用程序彈性時,最佳實踐表明組織切勿在同一硬件設(shè)置上找到重復(fù)的VM實例。相反,每個冗余工作負(fù)載實例應(yīng)位于不同的服務(wù)器上。

為實現(xiàn)彈性而設(shè)計的關(guān)鍵任務(wù)應(yīng)用程序需要至少兩個服務(wù)器,這些服務(wù)器要輕負(fù)載并配置為采用關(guān)聯(lián)性/反關(guān)聯(lián)性管理程序選項,以確保實時遷移或重新啟動不會無意中將實例定位在同一硬件上。

災(zāi)難恢復(fù)設(shè)置也出現(xiàn)了類似的反對整合的推動,其中重復(fù)的工作負(fù)載實例可能位于第二個/遠(yuǎn)程數(shù)據(jù)中心站點甚至公共云中的第二個服務(wù)器上。

邊緣計算和物聯(lián)網(wǎng)

組織正在擁抱越來越多的重要數(shù)據(jù),以制定關(guān)鍵的業(yè)務(wù)決策,進(jìn)行研究并運營關(guān)鍵任務(wù)設(shè)施。但是,就網(wǎng)絡(luò)延遲、帶寬和可靠性而言,數(shù)據(jù)存儲和處理給單個集中式數(shù)據(jù)中心帶來了嚴(yán)峻的挑戰(zhàn)。

考慮一個制造工廠。企業(yè)不太可能在制造工廠內(nèi)建立其數(shù)據(jù)中心。該設(shè)施產(chǎn)生的所有傳感器數(shù)據(jù),以及用于管理和操作該設(shè)施的一定水平的命令和控制信號,都必須通過WAN轉(zhuǎn)移到整合的數(shù)據(jù)中心。

較大的地理距離和龐大的網(wǎng)絡(luò)設(shè)備所導(dǎo)致的網(wǎng)絡(luò)延遲可能會使實時控制出現(xiàn)問題。同時,不可預(yù)見的WAN可用性中斷(例如Internet擁塞)可能使集中式數(shù)據(jù)收集和控制變得不穩(wěn)定。

在主數(shù)據(jù)中心之外并靠近實際設(shè)施,位置或任務(wù)的地方,一定級別的計算和存儲資源的部署有可能緩解網(wǎng)絡(luò)依賴性的挑戰(zhàn);這通常稱為邊緣計算。

大數(shù)據(jù)和規(guī)模

繁重的數(shù)據(jù)處理工作量可能會給數(shù)據(jù)中心帶來巨大壓力??紤]到大數(shù)據(jù)項目可能需要數(shù)百甚至數(shù)千臺服務(wù)器的計算能力,才能處理數(shù)兆字節(jié)甚至數(shù)PB的存儲數(shù)據(jù)來完成可能只需要幾個小時才能完成的任務(wù)。

當(dāng)然,可以在主數(shù)據(jù)中心內(nèi)部署物理服務(wù)器機架和部署一組虛擬機來處理此類要求苛刻的任務(wù)。除了大型企業(yè)外,支持大量服務(wù)器涌入的成本和基礎(chǔ)架構(gòu)可能是一項艱巨的任務(wù),這尤其令人望而卻步。

組織通常不會為建立大數(shù)據(jù)項目的主要數(shù)據(jù)中心進(jìn)行長期資本投資,而是經(jīng)常將替代計算和存儲資源(例如公共云)作為短期運營支出。該技術(shù)無需大量資金投入即可提供規(guī)模。

私有云和混合云

云計算的出現(xiàn)幾乎不僅限于AWS、Azure和Google。組織正在擁抱私有云,以反映不斷變化的業(yè)務(wù)需求。新的服務(wù)和自助服務(wù)功能使員工和業(yè)務(wù)合作伙伴可以將應(yīng)用程序和服務(wù)用作組織業(yè)務(wù)模型的一部分,而不必等待IT部門予以實施。

私有云甚至混合云的引入也面臨著在大數(shù)據(jù)用例中發(fā)現(xiàn)的規(guī)模挑戰(zhàn)。大多數(shù)數(shù)據(jù)中心都是實時部署,依賴于日常操作中的一致性、規(guī)律性和可控性。

企業(yè)不太可能將這些生產(chǎn)資源重新分配給私有云基礎(chǔ)架構(gòu),并且企業(yè)擁有多余的計算和存儲資源可用于從頭構(gòu)建可擴展的私有云的可能性更低。

一種選擇是在其他私有云基礎(chǔ)架構(gòu)上進(jìn)行資本投資,但是這種方法還有其他選擇。企業(yè)可以在主要數(shù)據(jù)中心之外使用各種私有云服務(wù)。

公共云提供商可以提供虛擬私有云服務(wù)。例如,企業(yè)可能使用Amazon或GoogleVirtualPrivateCloud等服務(wù)。除了主要的公共云提供商之外,組織還可以實施VMware、思科和IBM等第三方提供商提供的私有云即服務(wù)。

THEEND

最新評論(評論僅代表用戶觀點)

更多
暫無評論