自從基于服務器的計算出現以來，容量管理作為一門運營學科已經存在多年了，其甚至可追溯到大型主機時代。而鑒于每一代的服務器平臺都會創造自己獨特的要求，這使得支持這一學科的相關商業工具也已經存在30多年了。伴隨著數據中心從大型主機發展到中端計算，又從客戶端服務器向虛擬化方向發展，使得數據中心業界對于容量管理工具的需求也在逐步發展。

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

傳統的平臺不足以應付現代數據中心實時的運營操作

中央指數分析迫使傳統的容量管理解決方案需要批量執行，使得這些解決方案無法適應不斷變化的應用程序需求。

傳統的容量管理解決方案完全依賴于歷史數據，因此無法應對不可預測的應用程序的需求模式。

這些傳統的容量管理解決方案所給出的生產的建議甚至往往在被執行之前就已經被淘汰了。

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

傳統平臺僅側重于基礎設施，同時還忽略了應用程序的性能

這些傳統的容量管理解決方案使用不適合的分析算法，專注于基礎設施利用率，而不考慮應用程序性能。

傳統的容量管理解決方案沒有將工作負載需求與基礎設施供應相關聯的語義來確保應用程序的性能。

確保現代數據中心的應用程序性能需要一款能夠解決智能工作負載管理問題的實時控制系統。但伴隨著虛擬化技術興起而出現的軟件定義的數據中心的設計并不包括這個系統。

數據中心容量管理的定義

市場調研機構Gartner公司對容量管理工具做出了如下的定義：

“IT基礎架構-容量管理工具可以生成與基礎架構 -容量相關的報告，并能夠執行歷史數據分析和容量相關分析，同時具備IT和業務場景規劃的能力。這些工具的特點在于它們能夠廣泛的與來自各個不同領域的專用工具(例如實時性能監視工具)的數據充分集成整合在一起的卓越功能;能夠為各種各樣的基礎設施組件提供預測、咨詢和自動化;能夠對影響基礎設施性能績效的潛在因素進行深入的分析;以及他們對假設情景及其與在線分析處理(OLAP)業務報告工具的集成的支持。

容量管理工具的目標是為了解答以下問題：

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

改變我所在企業的數據中心的基礎架構的容量或配置將會產生什么影響?

在各種操作環境之間遷移工作負載的最佳方式是什么?

關于容量管理歷史的簡單回顧

容量管理工具最初是為支持IBM的大型主機而開發的。彼時，主要的驅動因素是大型主機的硬件成本過于昂貴，因此，業界花費了大量的精力以便準確地確定究竟需要多少硬件。

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

接下來，從中端UNIX系統到基于Wintel平臺的客戶端-服務器系統的轉變，再次改變了格局。服務器的價格開始下滑，且大多數服務器仍然是單一的應用程序。這繼續削弱了容量管理工具的價值。

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

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

容量管理與工作負載管理

伴隨著虛擬化技術的出現，盡管多款應用程序可以在單臺服務器上同時執行，但這些應用程序并不是在單款操作系統實例中執行的。管理程序處理的是資源的共享而不是操作系統。這使得問題的范圍從計算資源擴展到了包括存儲和網絡資源。

此外，確保應用程序性能所需的智能工作負載管理功能被排除在管理程序層之外。雖然容量管理仍然是一種有用的規劃工作，但對于確保性能的管理程序來說，這并不是一個充分的補充。

在現代數據中心確保應用程序的性能

任何數據中心運營團隊的主要目標都是確保其應用程序的性能，同時最大限度地利用所需的基礎架構資源。在現代數據中心運營中所進行的每項活動(包括配置、監控、容量管理和自動化)都是為了支持這一主要目標。

雖然有人聲稱，通過自動化補充的容量管理可以解決智能工作負載管理問題，但這是不正確的。的確，容量管理對于確定未來的容量需求和規劃遷移是相當有用的，但是，事后考慮增加自動化并不能為確保應用程序的性能提供適當的平臺。其并不能填補虛擬機管理程序層之外的智能工作負載管理的空白差距。采用這種方法的解決方案會帶來以下方面的不足：

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

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

3、這些解決方案的強力分析迫使他們需要批量執行分析，并定期自動化，從而妨礙了這些解決方案對不斷變化的需求做出反應。

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

5、這些解決方案依賴于歷史數據，故而并不適用于云原生應用程序工作負載。

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

然而，在所有情況下，這種容量管理工具所使用的分析集中在提高基礎設施利用率，而不是確保應用程序的性能。這是非常有問題的，因為重新配置基礎架構以實現效率，而不考慮性能可能會導致嚴重的應用程序性能問題。

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

1、無法實時執行

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

這種方法的核心問題是，其根本無法確保應用程序的性能，因為只有實時自動化可以通過不斷配置基礎設施資源來滿足當前應用程序的需求，進而應對波動的應用程序需求。

2、無法處理不可預測的需求

鑒于分析是批量定期運行的，它們只是基于歷史數據，因此只有當未來的需求是緊密反映了歷史需求時，那么這些數據才是準確的。

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

例如，虛擬桌面工作負載并沒有一致的歷史數據。即使傳統的交易處理應用程序也會遇到不可預測的需求峰值，正是這些情況對業務流程產生了負面影響。為了使分析引擎能夠確保應用程序的性能，其必須充分考慮到歷史和當前的實時工作負載的需求。

此外，由于自動化操作(如安置決策)只能定期執行，并且無法解決不可預測的需求，因此他們必須依靠凈空分配(headroom allocation)來允許足夠的備用容量來處理意外的需求峰值。這種凈空分配實際上降低了底層基礎設施的有效使用，并不是解決波動需求的充分解決方案。使用凈空方法，企業數據中心必須選擇留下足夠的未使用容量來處理任何預期的需求高峰或風險的性能問題。適當的解決方案能夠實時響應波動的需求，消除過度配置和或將帶來性能風險之間的困難選擇。

3、無法規模化的擴展縮放

由于bin-packing算法是NP-hard，其添加了多個維度，所以不容易實現規模化的擴展縮放。事實上，在基礎架構領域，隨著算法擴展到不僅僅考慮計算，而且需要考慮存儲、網絡和應用程序，執行分析所需的時間和資源也在呈指數級的增長。因此，不僅算法不規模化擴展縮放，其也不能實時轉換為執行，因此無法保證應用程序的性能。最后，跨越多個領域擴展是非常困難的——不僅僅是計算，而且好包括網絡、存儲和應用程序。

4、自動化屬于事后的想法

傳統的容量管理工具的出現早于軟件定義的數據中心，故而其最初并沒有考慮自動化的因素。因此，執行分析，操作計劃的制定及執行是獨立執行的階段。通常情況下，自動化是通過腳本或第三方業務流程來實現的，這使得解決方案的部署、配置和維護大大復雜化了。另外，因為自動化只能在完成分析之后發生，所以不能實時執行。

5、操作執行計劃不可靠

由容量管理工具所制定的操作執行計劃會遭受到一些致命的困擾——這些操作執行計劃可能而且通常是不可用的。因為分析是基于歷史數據而批量運行的，所以由這些數據所生成的所有操作執行計劃都是基于這樣的假設前提：當執行操作時，環境處于與數據捕獲分析時相同的狀態。因此，如果環境在數據捕獲的時間與執行動作的時間之間發生了任何方式額變化，則這些操作將是無效的。

此外，因為所有操作是相互依賴的，所以單個更改(例如一臺遷移的虛擬機)可能會使得整個操作計劃無效。這種變化可能會發生在(由于算法的計算密度，通常需要花費幾個小時)分析正在執行時，甚至在行動計劃本身正在執行的過程中。事實上，如果在嘗試執行行動計劃之前沒有辦法確定是否發生了任何無效的變更，這種狀況將進一步加劇。 因此，在動態變化的基礎設施中執行操作行動計劃的任何嘗試都是不可靠的。

6、不適用于云原生工作負載

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

結論

正如我們所看到的，容量管理工具并不適合確保應用程序的性能，因為它們無法實時執行、無法處理不可預測的需求、不能規模化擴展縮放、生成的操作執行計劃也根本不可靠，并且完全不適用于云原生工作負載。

確保現代數據中心應用程序性能所需要的是一款實時的控制系統，其可以解決隨著虛擬化技術的出現，軟件定義的數據中心的設計被被排除在外的智能工作負載的管理問題。