數(shù)據(jù)中心容量管理并不是什么新鮮事，但整個(gè)數(shù)據(jù)中心業(yè)界所采取的方式則是不斷發(fā)展?jié)u近式的。虛擬化技術(shù)正帶來下一個(gè)進(jìn)化步驟，隨之而來的則是下一波的容量管理工具。

現(xiàn)代數(shù)據(jù)中心正在經(jīng)歷一個(gè)新的問題。智能工作負(fù)載管理(IWM)問題意味著容量管理不再是確保應(yīng)用程序性能的充分解決方案了。

本文中，我們將幫助廣大讀者朋友們詳細(xì)了解當(dāng)傳統(tǒng)的容量管理無法奏效時(shí)，如何借助一款實(shí)時(shí)的控制系統(tǒng)來解決此問題。

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

虛擬化技術(shù)尤其帶來了智能工作負(fù)載管理(IWM)的問題，其中容量管理不再是確保應(yīng)用程序性能的充分解決方案。特別是：現(xiàn)代數(shù)據(jù)中心的傳統(tǒng)容量管理解決方案面臨著以下幾大根本缺點(diǎn)：

傳統(tǒng)平臺(tái)不適合實(shí)時(shí)操作

中央指數(shù)分析迫使傳統(tǒng)平臺(tái)批量執(zhí)行，因此無法適應(yīng)不斷變化的應(yīng)用程序需求。

傳統(tǒng)平臺(tái)完全依賴于歷史數(shù)據(jù)，因此無法應(yīng)對不可預(yù)測的應(yīng)用程序需求模式。

傳統(tǒng)平臺(tái)的生產(chǎn)建議在執(zhí)行之前經(jīng)常被淘汰。

傳統(tǒng)平臺(tái)依賴于歷史數(shù)據(jù)，但這不適用于云原生本機(jī)應(yīng)用程序工作負(fù)載。

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

傳統(tǒng)平臺(tái)使用不恰當(dāng)?shù)牡姆治鏊惴ǎ瑢Ｗ⒂诨A(chǔ)設(shè)施的利用率，而不考慮應(yīng)用程序的性能

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

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

定義容量管理

市場調(diào)研機(jī)構(gòu)Gartner所定義的容量管理工具如下：

IT基礎(chǔ)架構(gòu)—容量管理工具可以生成基礎(chǔ)架構(gòu)—容量相關(guān)的報(bào)告，能夠執(zhí)行歷史數(shù)據(jù)分析和容量相關(guān)分析，并具備IT和業(yè)務(wù)場景規(guī)劃能力。

這些工具的特點(diǎn)在于它們具備與來自各種領(lǐng)域的專用工具(例如實(shí)時(shí)性能監(jiān)控工具)的數(shù)據(jù)集成在一起的功能的廣泛性;能夠?yàn)楦鞣N不同類型的基礎(chǔ)設(shè)施組件提供預(yù)測、咨詢和自動(dòng)化;深入分析有助于基礎(chǔ)設(shè)施績效的潛在因素;并提供對于假設(shè)情景及其與在線分析處理(OLAP)業(yè)務(wù)報(bào)告工具的集成支持。

容量管理工具的目標(biāo)可以用來回答以下問題：

我所在的企業(yè)是否有足夠的基礎(chǔ)設(shè)施容量能力來支持我目前和將來的工作負(fù)載呢?如果沒有，那么我何時(shí)必須獲得額外的容量以及什么類型的容量?

改變我企業(yè)基礎(chǔ)設(shè)施的容量或配置將會(huì)產(chǎn)生什么影響?在不同環(huán)境之間遷移工作負(fù)載的最佳方式是什么?

容量管理簡史

容量管理工具最初是為了支持IBM大型主機(jī)而開發(fā)的。主要的驅(qū)動(dòng)因素是源于大型主機(jī)的硬件過于昂貴，因此需要消耗大量的精力用來確定需要多少硬件。

隨著中檔服務(wù)器的出現(xiàn)，容量管理開始不再被強(qiáng)調(diào)。雖然確定企業(yè)究竟應(yīng)該購買多少硬件仍然很重要，但是兩大趨勢使得這一點(diǎn)地重要性已經(jīng)不那么突顯了。首先，硬件設(shè)備變得越來越便宜，因此購買精確度的容量變得不那么重要。第二，雖然主機(jī)在單臺(tái)服務(wù)器上運(yùn)行了許多應(yīng)用程序，但是中檔系統(tǒng)往往是在每臺(tái)服務(wù)器運(yùn)行單個(gè)應(yīng)用程序。這簡化了規(guī)劃的過程，減少了對復(fù)雜工具的需求。

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

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

盡管如此，據(jù)Gartner的調(diào)研顯示，截至2014年，仍然只有不到5%的企業(yè)正在使用IT基礎(chǔ)架構(gòu)容量管理工具。他們進(jìn)一步估計(jì)，到2018年，只有30%的企業(yè)將采用這些工具——復(fù)合年增長率只有5%。鑒于該類別的工具是成熟的，顯而易見的問題是：“為什么該工具在當(dāng)今企業(yè)的采用普及率這么低呢?此外，鑒于這種低滲透普及率，為什么采用增長得如此緩慢呢?”

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

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

此外，需要確保應(yīng)用程序性能所需的智能工作負(fù)載管理功能不在管理程序?qū)又?。雖然容量管理仍然是有用的規(guī)劃工作，但對于績效保證的虛擬管理程序來說，這并不足夠。

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

任何運(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ù)載管理問題，但這是不準(zhǔn)確的。的確，容量管理是確定未來容量需求和規(guī)劃遷移的有用工具，但如果將增加自動(dòng)化作為事后考慮，并不能為保證應(yīng)用程序的性能提供適當(dāng)?shù)钠脚_(tái)。智能工作負(fù)載管理的缺陷不會(huì)超出管理程序?qū)?。采用這種方法的解決方案有以下缺陷：

1、他們使用專注于基礎(chǔ)設(shè)施利用的不恰當(dāng)?shù)姆治鏊惴?，而不考慮應(yīng)用程序的性能。

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

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

4、他們所提出的建議經(jīng)常在被執(zhí)行之前淘汰

5、它們依賴于歷史數(shù)據(jù)，這不適用于云原生本機(jī)應(yīng)用程序工作負(fù)載。

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

然而，在所有情況下，這種容量管理工具所使用的分析集中在提高基礎(chǔ)設(shè)施的利用率，而不是確保應(yīng)用程序的性能。這是非常有問題的，因?yàn)樵诓豢紤]性能的情況下，重新配置基礎(chǔ)架構(gòu)的效率可能會(huì)導(dǎo)致嚴(yán)重的應(yīng)用程序性能問題。

當(dāng)涉及到虛擬機(jī)的安置時(shí)，容量管理解決方案依賴于二進(jìn)制裝箱算法(bin-packing algorithm)，其中利用率峰值與峰谷相匹配，以便優(yōu)化所討論的基礎(chǔ)架構(gòu)的密度。采用這種不復(fù)雜的方法會(huì)有幾大根本性的問題。

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

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

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

不能處理不可預(yù)測的需求

因?yàn)榉治鍪桥慷ㄆ谶\(yùn)行的，所以它們只是基于歷史數(shù)據(jù)，因此只有未來的需求密切反映歷史需求，那么這些數(shù)據(jù)才是準(zhǔn)確的。

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

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

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

不能規(guī)?；s放

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

自動(dòng)化是事后的想法

傳統(tǒng)的容量管理工具早于軟件定義的數(shù)據(jù)中心誕生，最初并沒有考慮到自動(dòng)化。因此，執(zhí)行分析，制定行動(dòng)計(jì)劃以及執(zhí)行行動(dòng)計(jì)劃是獨(dú)立執(zhí)行的階段。通常情況下，通過腳本或第三方協(xié)調(diào)器實(shí)現(xiàn)自動(dòng)化，這使得解決方案的部署、配置和維護(hù)大大復(fù)雜化了。另外，由于自動(dòng)化只能在完成分析后發(fā)生，所以無法實(shí)時(shí)執(zhí)行。

不可靠的行動(dòng)計(jì)劃

容量管理工具所產(chǎn)生的操作計(jì)劃會(huì)遭致一個(gè)致命的錯(cuò)誤——它們可能而且往往是無法使用的。因?yàn)榉治鍪菑臍v史數(shù)據(jù)中批量運(yùn)行的，所以它們生成的所有操作都是基于這樣的假設(shè)：當(dāng)執(zhí)行操作時(shí)，環(huán)境處于與捕獲數(shù)據(jù)分析時(shí)相同的狀態(tài)。因此，如果環(huán)境在捕獲數(shù)據(jù)的時(shí)間與執(zhí)行操作的時(shí)間之間以任何方式發(fā)生了變化，則這些操作無效。

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

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

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

結(jié)論

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

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