資料庫雲容量管理

導讀	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表示，組織將會得到在系統中構建和設計的東西。從滿足組織要求的備份，到故障切換自動化，再到防火牆安全性，所有這些都需要使用適當的供應商工具進行規劃和實施，因為它們不是一成不變的。大多數雲端計算提供商為作業系統、磁碟速度、支援的應用程式甚至設定提供了很多選擇和可能性。組織面臨的挑戰是大量的選擇，並將它們轉換為滿足組織的需求並能與供應商的環境良好配合的配置列表。

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