自從基于服務(wù)器的計(jì)算出現(xiàn)以來，容量管理作為一門運(yùn)營學(xué)科已經(jīng)存在多年了，其甚至可追溯到大型主機(jī)時(shí)代。而鑒于每一代的服務(wù)器平臺(tái)都會(huì)創(chuàng)造自己獨(dú)特的要求，這使得支持這一學(xué)科的相關(guān)商業(yè)工具也已經(jīng)存在30多年了。伴隨著數(shù)據(jù)中心從大型主機(jī)發(fā)展到中端計(jì)算，又從客戶端服務(wù)器向虛擬化方向發(fā)展，使得數(shù)據(jù)中心業(yè)界對(duì)于容量管理工具的需求也在逐步發(fā)展。

虛擬化技術(shù)的普及采用尤其帶來了智能工作負(fù)載管理(IWM)的問題，使得容量管理不再是確保應(yīng)用程序性能的充分解決方案了。特別是當(dāng)將傳統(tǒng)的容量管理解決方案用于現(xiàn)代數(shù)據(jù)中心時(shí)，會(huì)面臨以下一系列的根本缺陷：

傳統(tǒng)的平臺(tái)不足以應(yīng)付現(xiàn)代數(shù)據(jù)中心實(shí)時(shí)的運(yùn)營操作

中央指數(shù)分析迫使傳統(tǒng)的容量管理解決方案需要批量執(zhí)行，使得這些解決方案無法適應(yīng)不斷變化的應(yīng)用程序需求。

傳統(tǒng)的容量管理解決方案完全依賴于歷史數(shù)據(jù)，因此無法應(yīng)對(duì)不可預(yù)測的應(yīng)用程序的需求模式。

這些傳統(tǒng)的容量管理解決方案所給出的生產(chǎn)的建議甚至往往在被執(zhí)行之前就已經(jīng)被淘汰了。

這些傳統(tǒng)的容量管理解決方案依賴于歷史數(shù)據(jù)，故而不適用于云原生(cloud-native)應(yīng)用程序工作負(fù)載。

傳統(tǒng)平臺(tái)僅側(cè)重于基礎(chǔ)設(shè)施，同時(shí)還忽略了應(yīng)用程序的性能

這些傳統(tǒng)的容量管理解決方案使用不適合的分析算法，專注于基礎(chǔ)設(shè)施利用率，而不考慮應(yīng)用程序性能。

傳統(tǒng)的容量管理解決方案沒有將工作負(fù)載需求與基礎(chǔ)設(shè)施供應(yīng)相關(guān)聯(lián)的語義來確保應(yīng)用程序的性能。

確?，F(xiàn)代數(shù)據(jù)中心的應(yīng)用程序性能需要一款能夠解決智能工作負(fù)載管理問題的實(shí)時(shí)控制系統(tǒng)。但伴隨著虛擬化技術(shù)興起而出現(xiàn)的軟件定義的數(shù)據(jù)中心的設(shè)計(jì)并不包括這個(gè)系統(tǒng)。

數(shù)據(jù)中心容量管理的定義

市場調(diào)研機(jī)構(gòu)Gartner公司對(duì)容量管理工具做出了如下的定義：

“IT基礎(chǔ)架構(gòu)-容量管理工具可以生成與基礎(chǔ)架構(gòu) -容量相關(guān)的報(bào)告，并能夠執(zhí)行歷史數(shù)據(jù)分析和容量相關(guān)分析，同時(shí)具備IT和業(yè)務(wù)場景規(guī)劃的能力。這些工具的特點(diǎn)在于它們能夠廣泛的與來自各個(gè)不同領(lǐng)域的專用工具(例如實(shí)時(shí)性能監(jiān)視工具)的數(shù)據(jù)充分集成整合在一起的卓越功能;能夠?yàn)楦鞣N各樣的基礎(chǔ)設(shè)施組件提供預(yù)測、咨詢和自動(dòng)化;能夠?qū)τ绊懟A(chǔ)設(shè)施性能績效的潛在因素進(jìn)行深入的分析;以及他們對(duì)假設(shè)情景及其與在線分析處理(OLAP)業(yè)務(wù)報(bào)告工具的集成的支持。

容量管理工具的目標(biāo)是為了解答以下問題：

我所在企業(yè)的數(shù)據(jù)中心是否具備足夠的基礎(chǔ)設(shè)施容量能力來支持企業(yè)當(dāng)前和未來的工作負(fù)荷?如果沒有，那么，我企業(yè)何時(shí)必須獲得額外的容量;及什么類型的容量?

改變我所在企業(yè)的數(shù)據(jù)中心的基礎(chǔ)架構(gòu)的容量或配置將會(huì)產(chǎn)生什么影響?

在各種操作環(huán)境之間遷移工作負(fù)載的最佳方式是什么?

關(guān)于容量管理歷史的簡單回顧

容量管理工具最初是為支持IBM的大型主機(jī)而開發(fā)的。彼時(shí)，主要的驅(qū)動(dòng)因素是大型主機(jī)的硬件成本過于昂貴，因此，業(yè)界花費(fèi)了大量的精力以便準(zhǔn)確地確定究竟需要多少硬件。

伴隨著中檔服務(wù)器的出現(xiàn)，容量管理的問題開始不再被業(yè)界突出強(qiáng)調(diào)。盡管確定具體應(yīng)該采購多少硬件的問題仍然非常的重要，但是兩大趨勢使得這方面的問題不再是業(yè)界的突出重點(diǎn)難題了。首先，硬件的成本變得不那么昂貴，因此使得企業(yè)客戶具體需要采購多少容量的精度變得不那么重要。第二，雖然主機(jī)在單臺(tái)服務(wù)器上運(yùn)行了多款應(yīng)用程序，但中端系統(tǒng)往往是每臺(tái)服務(wù)器上只運(yùn)行單款應(yīng)用程序。這簡化了規(guī)劃的過程，同時(shí)還減少了對(duì)復(fù)雜工具的需求。

接下來，從中端UNIX系統(tǒng)到基于Wintel平臺(tái)的客戶端-服務(wù)器系統(tǒng)的轉(zhuǎn)變，再次改變了格局。服務(wù)器的價(jià)格開始下滑，且大多數(shù)服務(wù)器仍然是單一的應(yīng)用程序。這繼續(xù)削弱了容量管理工具的價(jià)值。

隨著虛擬化技術(shù)的出現(xiàn)，容量管理問題開始看起來更像是大型主機(jī)的問題。借助虛擬化技術(shù)，使得企業(yè)客戶在同一臺(tái)服務(wù)器上運(yùn)行多款應(yīng)用程序再次成為常態(tài)。另外，雖然單臺(tái)服務(wù)器的成本持續(xù)下降，但服務(wù)器的數(shù)量卻大幅增加了。

根據(jù)Gartner公司在2014年的市場調(diào)研顯示，僅不到5%的企業(yè)正在使用IT基礎(chǔ)設(shè)施容量管理工具。他們進(jìn)一步估計(jì)，到2018年，只有30%的企業(yè)將采用這些工具——年復(fù)合增長率只有5%。鑒于這一工具類別已然成熟，那么，一個(gè)顯而易見的問題便是：“為什么數(shù)據(jù)中心業(yè)界對(duì)于該工具的普及采用率如此之低呢?”而由此引發(fā)的進(jìn)一步思考是：“鑒于其在數(shù)據(jù)中心業(yè)界的普及采用率如此之低，為什么其普及采用的增長還如此緩慢呢?”

容量管理與工作負(fù)載管理

伴隨著虛擬化技術(shù)的出現(xiàn)，盡管多款應(yīng)用程序可以在單臺(tái)服務(wù)器上同時(shí)執(zhí)行，但這些應(yīng)用程序并不是在單款操作系統(tǒng)實(shí)例中執(zhí)行的。管理程序處理的是資源的共享而不是操作系統(tǒng)。這使得問題的范圍從計(jì)算資源擴(kuò)展到了包括存儲(chǔ)和網(wǎng)絡(luò)資源。

此外，確保應(yīng)用程序性能所需的智能工作負(fù)載管理功能被排除在管理程序?qū)又?。雖然容量管理仍然是一種有用的規(guī)劃工作，但對(duì)于確保性能的管理程序來說，這并不是一個(gè)充分的補(bǔ)充。

在現(xiàn)代數(shù)據(jù)中心確保應(yīng)用程序的性能

任何數(shù)據(jù)中心運(yùn)營團(tuán)隊(duì)的主要目標(biāo)都是確保其應(yīng)用程序的性能，同時(shí)最大限度地利用所需的基礎(chǔ)架構(gòu)資源。在現(xiàn)代數(shù)據(jù)中心運(yùn)營中所進(jìn)行的每項(xiàng)活動(dòng)(包括配置、監(jiān)控、容量管理和自動(dòng)化)都是為了支持這一主要目標(biāo)。

雖然有人聲稱，通過自動(dòng)化補(bǔ)充的容量管理可以解決智能工作負(fù)載管理問題，但這是不正確的。的確，容量管理對(duì)于確定未來的容量需求和規(guī)劃遷移是相當(dāng)有用的，但是，事后考慮增加自動(dòng)化并不能為確保應(yīng)用程序的性能提供適當(dāng)?shù)钠脚_(tái)。其并不能填補(bǔ)虛擬機(jī)管理程序?qū)又獾闹悄芄ぷ髫?fù)載管理的空白差距。采用這種方法的解決方案會(huì)帶來以下方面的不足：

1、這些解決方案使用不適合的分析算法，僅僅只專注于基礎(chǔ)設(shè)施的利用，而不考慮應(yīng)用程序的性能。

2、這些解決方案完全依賴于歷史數(shù)據(jù)，因此無法處理遇到不可預(yù)測的需求模式的應(yīng)用程序。

3、這些解決方案的強(qiáng)力分析迫使他們需要批量執(zhí)行分析，并定期自動(dòng)化，從而妨礙了這些解決方案對(duì)不斷變化的需求做出反應(yīng)。

4、這些解決方案所提出的建議往往在被執(zhí)行之前就已然被淘汰了。

5、這些解決方案依賴于歷史數(shù)據(jù)，故而并不適用于云原生應(yīng)用程序工作負(fù)載。

最近，一些容量管理工具增加了根據(jù)其分析生成建議的能力，在某些情況下，可以通過腳本或與外部業(yè)務(wù)流程系統(tǒng)集成來處理這些建議。

然而，在所有情況下，這種容量管理工具所使用的分析集中在提高基礎(chǔ)設(shè)施利用率，而不是確保應(yīng)用程序的性能。這是非常有問題的，因?yàn)橹匦屡渲没A(chǔ)架構(gòu)以實(shí)現(xiàn)效率，而不考慮性能可能會(huì)導(dǎo)致嚴(yán)重的應(yīng)用程序性能問題。

當(dāng)涉及到虛擬機(jī)的安置時(shí)，容量管理解決方案依賴于一種裝箱問題 (bin-packing)算法，其中利用率峰值與峰谷匹配，以便優(yōu)化所討論的基礎(chǔ)設(shè)施的密度。這種不復(fù)雜的方法有幾個(gè)基本問 題。

1、無法實(shí)時(shí)執(zhí)行

在計(jì)算理論中，裝箱算法被歸類為一種組合的NP-hard(非確定性多項(xiàng)式，non-deterministic polynomial)問題。這意味著找到該問題的解決方案是屬于非常計(jì)算密集型的，由此導(dǎo)致的結(jié)果是，依賴于裝箱算法的分析必須以批量的方式連續(xù)地實(shí)時(shí)運(yùn)行。因此，由分析產(chǎn)生的自動(dòng)化操作是周期性的而不是持續(xù)執(zhí)行的。這類似于在文件系統(tǒng)本身內(nèi)置寫入優(yōu)化之前磁盤碎片整理是如何發(fā)生的。

這種方法的核心問題是，其根本無法確保應(yīng)用程序的性能，因?yàn)橹挥袑?shí)時(shí)自動(dòng)化可以通過不斷配置基礎(chǔ)設(shè)施資源來滿足當(dāng)前應(yīng)用程序的需求，進(jìn)而應(yīng)對(duì)波動(dòng)的應(yīng)用程序需求。

2、無法處理不可預(yù)測的需求

鑒于分析是批量定期運(yùn)行的，它們只是基于歷史數(shù)據(jù)，因此只有當(dāng)未來的需求是緊密反映了歷史需求時(shí)，那么這些數(shù)據(jù)才是準(zhǔn)確的。

雖然這種方法對(duì)于定期的容量管理可能是已經(jīng)足夠了，但是卻完全不適合實(shí)時(shí)應(yīng)用程序的性能控制。許多現(xiàn)代應(yīng)用程序具有不可預(yù)測的需求模式，故而僅僅依賴于歷史數(shù)據(jù)分析是不足的。

例如，虛擬桌面工作負(fù)載并沒有一致的歷史數(shù)據(jù)。即使傳統(tǒng)的交易處理應(yīng)用程序也會(huì)遇到不可預(yù)測的需求峰值，正是這些情況對(duì)業(yè)務(wù)流程產(chǎn)生了負(fù)面影響。為了使分析引擎能夠確保應(yīng)用程序的性能，其必須充分考慮到歷史和當(dāng)前的實(shí)時(shí)工作負(fù)載的需求。

此外，由于自動(dòng)化操作(如安置決策)只能定期執(zhí)行，并且無法解決不可預(yù)測的需求，因此他們必須依靠凈空分配(headroom allocation)來允許足夠的備用容量來處理意外的需求峰值。這種凈空分配實(shí)際上降低了底層基礎(chǔ)設(shè)施的有效使用，并不是解決波動(dòng)需求的充分解決方案。使用凈空方法，企業(yè)數(shù)據(jù)中心必須選擇留下足夠的未使用容量來處理任何預(yù)期的需求高峰或風(fēng)險(xiǎn)的性能問題。適當(dāng)?shù)慕鉀Q方案能夠?qū)崟r(shí)響應(yīng)波動(dòng)的需求，消除過度配置和或?qū)硇阅茱L(fēng)險(xiǎn)之間的困難選擇。

3、無法規(guī)?；臄U(kuò)展縮放

由于bin-packing算法是NP-hard，其添加了多個(gè)維度，所以不容易實(shí)現(xiàn)規(guī)?；臄U(kuò)展縮放。事實(shí)上，在基礎(chǔ)架構(gòu)領(lǐng)域，隨著算法擴(kuò)展到不僅僅考慮計(jì)算，而且需要考慮存儲(chǔ)、網(wǎng)絡(luò)和應(yīng)用程序，執(zhí)行分析所需的時(shí)間和資源也在呈指數(shù)級(jí)的增長。因此，不僅算法不規(guī)?；瘮U(kuò)展縮放，其也不能實(shí)時(shí)轉(zhuǎn)換為執(zhí)行，因此無法保證應(yīng)用程序的性能。最后，跨越多個(gè)領(lǐng)域擴(kuò)展是非常困難的——不僅僅是計(jì)算，而且好包括網(wǎng)絡(luò)、存儲(chǔ)和應(yīng)用程序。

4、自動(dòng)化屬于事后的想法

傳統(tǒng)的容量管理工具的出現(xiàn)早于軟件定義的數(shù)據(jù)中心，故而其最初并沒有考慮自動(dòng)化的因素。因此，執(zhí)行分析，操作計(jì)劃的制定及執(zhí)行是獨(dú)立執(zhí)行的階段。通常情況下，自動(dòng)化是通過腳本或第三方業(yè)務(wù)流程來實(shí)現(xiàn)的，這使得解決方案的部署、配置和維護(hù)大大復(fù)雜化了。另外，因?yàn)樽詣?dòng)化只能在完成分析之后發(fā)生，所以不能實(shí)時(shí)執(zhí)行。

5、操作執(zhí)行計(jì)劃不可靠

由容量管理工具所制定的操作執(zhí)行計(jì)劃會(huì)遭受到一些致命的困擾——這些操作執(zhí)行計(jì)劃可能而且通常是不可用的。因?yàn)榉治鍪腔跉v史數(shù)據(jù)而批量運(yùn)行的，所以由這些數(shù)據(jù)所生成的所有操作執(zhí)行計(jì)劃都是基于這樣的假設(shè)前提：當(dāng)執(zhí)行操作時(shí)，環(huán)境處于與數(shù)據(jù)捕獲分析時(shí)相同的狀態(tài)。因此，如果環(huán)境在數(shù)據(jù)捕獲的時(shí)間與執(zhí)行動(dòng)作的時(shí)間之間發(fā)生了任何方式額變化，則這些操作將是無效的。

此外，因?yàn)樗胁僮魇窍嗷ヒ蕾嚨模詥蝹€(gè)更改(例如一臺(tái)遷移的虛擬機(jī))可能會(huì)使得整個(gè)操作計(jì)劃無效。這種變化可能會(huì)發(fā)生在(由于算法的計(jì)算密度，通常需要花費(fèi)幾個(gè)小時(shí))分析正在執(zhí)行時(shí)，甚至在行動(dòng)計(jì)劃本身正在執(zhí)行的過程中。事實(shí)上，如果在嘗試執(zhí)行行動(dòng)計(jì)劃之前沒有辦法確定是否發(fā)生了任何無效的變更，這種狀況將進(jìn)一步加劇。 因此，在動(dòng)態(tài)變化的基礎(chǔ)設(shè)施中執(zhí)行操作行動(dòng)計(jì)劃的任何嘗試都是不可靠的。

6、不適用于云原生工作負(fù)載

最后，基于歷史分析的批量的容量管理完全不適用于云原生工作負(fù)載。越來越多的應(yīng)用程序正在通過使用部署在容器(container)中的微服務(wù)來水平擴(kuò)展。這些基于容器的微服務(wù)器將根據(jù)應(yīng)用程序的需求而不斷創(chuàng)建和實(shí)時(shí)銷毀。因此，歷史數(shù)據(jù)不足以執(zhí)行批量容量分 析。傳統(tǒng)的批量容量管理解決方案完全不適用于云原生工作負(fù)載，這意味著在不久的將來它們將面臨淘汰。事實(shí)上，云原生工作負(fù)載只能由實(shí)時(shí)控制系統(tǒng)管理。

結(jié)論

正如我們所看到的，容量管理工具并不適合確保應(yīng)用程序的性能，因?yàn)樗鼈儫o法實(shí)時(shí)執(zhí)行、無法處理不可預(yù)測的需求、不能規(guī)?；瘮U(kuò)展縮放、生成的操作執(zhí)行計(jì)劃也根本不可靠，并且完全不適用于云原生工作負(fù)載。

確?，F(xiàn)代數(shù)據(jù)中心應(yīng)用程序性能所需要的是一款實(shí)時(shí)的控制系統(tǒng)，其可以解決隨著虛擬化技術(shù)的出現(xiàn)，軟件定義的數(shù)據(jù)中心的設(shè)計(jì)被被排除在外的智能工作負(fù)載的管理問題。