Greene表示，就像許多人一樣，自己在冠狀病毒疫情期間只能在家遠程工作。其帶領的IT團隊在融合的VMware環境中進行數據庫云容量管理。他表示，公共云提供商面臨的容量管理問題與Greeneideas公司正在解決的問題類似。因此，其IT團隊成員參加了各種在線供應商會議，并接受了在線培訓，以了解在云計算世界中是否也遇到了類似的問題，以及可以學到什么技術和經驗來改進分析和流程。

Greene在了解云計算提供商對其客戶的看法之后，并結合其豐富的工作經驗，開始確定容量管理的挑戰。因此，組織采用私有云可能被人們認為在特定計算機上的容量不足，也可能被認為公共云環境中的成本攀升。

Greene為云計算環境中的容量管理提供的關鍵主題是：

需要建立所有利益相關者都能從自己的角度理解的容量模型。

采用應用程序團隊在配置容量時可能并不真正知道他們需要什么。

要求比較苛刻的應用程序必須以不同的方式處理。

清理不是自然發生的，并將會浪費容量。

對于IaaS、PaaS和其他應用程序真正提供的內容，有許多不同的觀點。

以下將深入了解這些關鍵主題：

容量模型

第一個關鍵主題是需要建立一種所有利益相關者都可以理解的容量模型。無論是財務人員還是應用程序系統管理員，都需要提供150個服務器或200個容器的列表以進行使用情況檢查，通常不會產生有效的結果。這是為什么?相信很少有人能理解主機名或容器名稱(或是服務實例)。經過嘗試，Greene帶領的IT 團隊增強了從服務器和容器列表驅動的容量模型，并合并了配置管理數據庫(CMDB)、數據庫和操作系統監視工具中的數據。IT團隊到處獲取信息，這些信息會將網絡上的資源用于需要查看容量使用情況。因此，在與應用程序團隊交流時，它有助于確定這些服務器上的數據庫，所用數據庫的版本(以便他們可以查看哪些數據庫是為了滿足風險要求而遷移出的原有數據庫)，與涉及成本的人員溝通時，首先要使用生成賬單的資源(磁盤、CPU、內存等)，然后將其映射到所涉及的各個應用程序團隊以及所使用的版本。

在這些情況下，組織IT團隊都可以看到他們關心的問題，并將其映射到應用程序或用戶社區，這有助于他們評估是否仍然需要，并了解他們可能需要在哪里進行更改，例如從原有版本的Windows 2000遷移。基本上，它可以歸結為一種模型，該模型能夠提供一組量身定制的報告來幫助他們了解自己所擁有的東西，而不是逐項列出的賬單說明所用資源。

評估需求

Greene表示，他們發現的下一個主題是，應用程序團隊在首次遷移到云環境或構建新應用程序時可能不知道他們真正想要什么。他們通常具有可以打動用戶的出色功能和構想，但是詢問采用多少個CPU和多少內存等問題時，他們通常會詢問供應商，并希望更好地運行他們的產品，而基礎設施部門面臨節省成本并提高利用率的壓力，但最終會選擇采用云計算服務。他們面臨的挑戰是，關于應用程序的接受程度以及下一步可能會想到的功能，存在很多假設甚至猜測。這通常會導致這樣一種情況：必須遷移到不同的運營環境以滿足他們的性能需求，這需要應用程序團隊和基礎設施團隊花費大量時間和精力進行處理。

許多團隊做出的一個假設是，可以構建適合所有應用程序的一種架構，但大多數大型公司都有廣泛的投資組合，通常遵循80/20或90/10規則。通常情況下，只有少數應用程序能夠推動業務發展、擁有龐大的用戶群或需要更高的性能。因此，雖然大多數應用程序都能適應為用戶設計的經濟高效、高密度的環境，但重要的是需要更高性能的環境或可用的選擇，而不是采用一種滿足所有需求的解決方案。

清理不是自然發生的

另一個主題是清理不是自然發生的，并將會浪費容量。在公共云中，這通常是增加成本，而在私有云中，這通常表現為容量不足或意外增長。在大多數情況下，允許開發人員通過自動化的方式為他們的任務配置系統，但是當不再需要容量時，沒有人進行清理。因此，當他們完成一個需要資源的特殊開發項目時，或者當他們遷移到數據庫、Web服務器或操作系統的下一個版本以滿足架構或風險方面的標準時，沒有人愿意放棄原有資源(也許他們想了解新資源是否真的有效)。如果不注意這一點，則隨著組織在云平臺中運營更長的時間，將會積累更多的無用數據。這里的關鍵是向負責支付賬單的人員展示，或者證明他們使用私有云資源的正當性，以及他們所使用的與之相關的內容，以便他們能夠做出正確的決策。

處理要求苛刻的應用程序

最后，許多組織開始遷移到云端，他們了解原有數據中心的利用率有多低，以及效率低下的IT設備帶來的浪費。對這一點敏感的是，本地云計算供應商已經找到了將同一資源(CPU、內存或IO帶寬)同時承諾給多個應用程序或虛擬機的方法。人們認為，共享這些資源的應用程序不太可能同時使用這些資源。

在通常情況下，對于Web服務器之類的事情來說，這是一個很好的選擇，用戶可以在一天之內快速響應Web發送的請求。但是，這對于數據庫服務器而言可能并不好，因為數據庫服務器可能需要幾秒鐘的時間來處理一些查詢，并且數據庫中的應用程序使用量往往會出現一些高峰。這里面臨的挑戰在于，如果每個人都對系統提出CPU或內存需求，那么系統就會進行交換，在交換過程中，系統會花費所有的時間將進程移入或移出內存，或者將系統堆疊到無法滿足要求的程度。因此，在這個例子中，可以分析每個應用程序或產品(例如，數據庫通常在啟動時分配大量內存區域，而不釋放它們，如果過度提交，則可能進行交換)，并為這一應用程序做出正確的決策，而不是根據供應商的實驗室環境使用通用的指導原則。

IaaS、PaaS和XaaS到底提供了什么?

最后一個主題是，人們對于IaaS、PaaS和XaaS的真正含義有很多不同的看法。應用程序團隊可以閱讀許多關于云計算可以做什么的文章，并且他們假設遷移到云端時，以某種方式獲得了更多的功能和服務。Greene表示，組織將會得到在系統中構建和設計的東西。從滿足組織要求的備份，到故障切換自動化，再到防火墻安全性，所有這些都需要使用適當的供應商工具進行規劃和實施，因為它們不是一成不變的。大多數云計算提供商為操作系統、磁盤速度、支持的應用程序甚至設置提供了很多選擇和可能性。組織面臨的挑戰是大量的選擇，并將它們轉換為滿足組織的需求并能與供應商的環境良好配合的配置列表。

結論

從容量的角度來看，這些是在公共云和私有云應用的一些主題。相信每個運營環境都需要進行研究和建模，以使組織能夠運行分析以查看容量問題所在。需要注意的是，容量問題實際上有兩種：第一個是性能，組織會發現給定應用程序對于其當前位置而言太多了(需要遷移到更好的運營環境)。第二個是總體容量管理(這將確保組織可以為給定的容器或虛擬機提供足夠的資源)。這將成為永無止境的分析，因為一旦解決了一個問題，就有另一個問題需要解決。該模型幫助組織確定問題，然后可以使用環境中的工具(移動容器、遷移到新容器或可能移動到新架構)來確保運營環境為未來發展做好準備。
編輯：hfy