| 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的真正含義有很多不同的看法。應用程序團隊可以閱讀許多關於雲計算可以做什麼的文章，並且他們假設遷移到雲端時，以某種方式獲得了更多的功能和服務。Greene表示，組織將會得到在系統中構建和設計的東西。從滿足組織要求的備份，到故障切換自動化，再到防火牆安全性，所有這些都需要使用適當的供應商工具進行規劃和實施，因爲它們不是一成不變的。大多數雲計算提供商爲操作系統、磁盤速度、支持的應用程序甚至設置提供了很多選擇和可能性。組織面臨的挑戰是大量的選擇，並將它們轉換爲滿足組織的需求並能與供應商的環境良好配合的配置列表。
從容量的角度來看，這些是在公共雲和私有云應用的一些主題。相信每個運營環境都需要進行研究和建模，以使組織能夠運行分析以查看容量問題所在。需要注意的是，容量問題實際上有兩種：第一個是性能，組織會發現給定應用程序對於其當前位置而言太多了(需要遷移到更好的運營環境)。第二個是總體容量管理(這將確保組織可以爲給定的容器或虛擬機提供足夠的資源)。這將成爲永無止境的分析，因爲一旦解決了一個問題，就有另一個問題需要解決。該模型幫助組織確定問題，然後可以使用環境中的工具(移動容器、遷移到新容器或可能移動到新架構)來確保運營環境爲未來發展做好準備。
本文地址：https://www.linuxprobe.com/database-cloud-capacity.html