如何向 VMware 管理員描述我們的應用程序的 VMware 性能要求？
通常，我們現場安裝的基於 debian-stable 的應用程序在虛擬機中執行 - 通常在 VMware ESXi 中。在一般情況下，我們無法查看或影響他們的虛擬化環境，也無法訪問例如 VMware vCenter 客戶端或同等產品。我在這裡專注於 VMware，因為這是迄今為止我們看到的最常見的。
我們想：
- 告訴客戶的 VMware 管理員：您可以在例如您的 VMware ESX 環境中執行我們的應用程序，只要它滿足性能標準 X、Y 和 Z。
- 能夠確定標準 X、Y 和 Z 實際上是否連續滿足（例如現在也是），即使在正在執行的系統上也是如此（我們不能停止我們的應用程序並執行基準測試，並且初始基準測試是不夠的，因為性能虛擬環境隨時間變化）。
- 有信心，如果滿足標準 X、Y 和 Z，我們將有足夠的虛擬硬體資源來執行我們的應用程序並具有令人滿意的性能。
現在什麼是 X、Y 和 Z？
我們一次又一次地看到，當出現性能問題時，問題不在於我們的應用程序，而在於虛擬化環境。例如，另一台虛擬機使用大量 CPU、記憶體或實際儲存磁碟的 SAN 被我們的應用程序以外的其他東西大量使用。我們目前無法證明或反駁這一點。
從理論上講，有時我們的應用程序也可能很慢…… ;-)
如何確定我們的性能問題的根本原因：虛擬環境還是我們的應用程序？
性能問題通常有 3 個區域 CPU、記憶體和磁碟 I/O。
中央處理器
例如，在 VMware 中，管理員可以指定預留和限制，以 MHz 表示，但例如，一台 ESX 主機上的 512MHz 與另一台 ESX 主機上的 512MHz 完全相同，可能在完全不同的 ESX 集群中？
以及如何衡量我們是否真的得到了這一點？當我們的應用程序執行時，我們可能會看到我們在 4 個 CPU 上的 CPU 使用率為 212%。這是因為我們的應用程序正在做很多事情，還是因為同一主機上的另一個 VM 正在執行 CPU 密集型任務並使用所有 CPU？
記憶（氣球？）
如果我們要求例如 16GB 的 RAM，這通常是配置的，但由於膨脹，我們實際上只得到 4GB，而且令人驚訝的是，我們的應用程序性能很差。
可以向 VMware 工具詢問目前的膨脹，但我們發現它經常是謊言（或者至少是不准確的）。我們已經看到作業系統認為總 RAM 為 16GB 的範例，所有程序的駐留記憶體 (RSS) 總和為 4GB RAM，但只有 2GB 可用 RAM，即使 VMware 工具告訴我們有 0 個氣球： -(
此外，僅將 RSS 相加是無效的，因為可能很容易共享 RAM，例如寫時複製記憶體，因此 512MB + 512MB 不一定意味著 1GB，但可能意味著更少。因此，不能簡單地從所有程序中減去 RSS 來衡量應該有多少 RAM 可用，從而可靠地檢測膨脹。人們可以檢測到一些氣球的情況，但在其他情況下氣球是有效的，但這種方法無法檢測到。
磁碟 I/O
我想我們可以隨時間繪製磁碟讀寫次數、讀寫字節數以及 IO 等待百分比。但這會給我們提供磁碟 I/O 的準確圖景嗎？我想如果有一個比特幣礦工在另一個使用所有 CPU 的 VM 中執行，我們的 IO 等待百分比會上升，即使底層 SAN 提供完全相同的性能，僅僅是因為我們的 CPU 資源下降，因此 IO 等待（以 % 衡量）上升。
總而言之，我們可以使用什麼語言來描述例如 VMware 管理員，我們需要什麼樣的性能，以可移植和可測量的方式？
- **說真的，大多數 VMware 管理員並不擅長這一點：**對資源管理了解不足，通常沒有 Linux 知識（這很有幫助），並且缺乏時間頻寬。我發現大多數內部管理員很難保持深入的虛擬化知識。
- 幸運的是，有一本書你可以讀！
- **大多數 VMware 環境都不是很好：**糟糕的集群設計、糟糕的資源規劃、不合標準的儲存（即 Synology NAS）、錯誤配置的 HA、沒有監控或修補。
- **VMware 作為一個組織讓我們失望：**他們在傳播最新資訊和推廣最佳實踐方面特別糟糕。儘管流程和設計隨著時間的推移發生了變化，但對常見問題的基本搜尋會從 2009 年及更早的 VMware 版本中生成結果。
所有這些事情都會對你不利。
您應該確定解決方案的真正要求。能夠準確地說明您的設備需要：2 個 vCPU、8GB RAM 和 500 IOPS 儲存性能對於像我這樣的人來說會有很長的路要走。
另一種方法是觀察健康或理想的環境並從那裡推斷出指標。
您已經描述了某些部署的問題。有哪些問題和瓶頸？
大小合適的 VM 範例：
用於 300 個使用者的組織的 Exchange 伺服器。
- 我們有 6 週的工作量/壓力熱圖與時間的關係。
- 6 個 vCPU 使我們保持在壓力區之上，並為峰值提供緩衝空間。
- 32GB RAM 讓我們保持在壓力值之上，但並不是超出真正需要的不合理數量。
- 我可以回收幾 GB 的 RAM 和一個 vCPU，但總的來說，這是一個高效的 VM。
- 在理想條件下對您的應用程序進行這種類型的監控是明智的。
虛擬機資源監控範例。
Good-ish： - 虛擬機大小合適。- CPU 在整個集群中被過度使用，但我們沒有遇到爭用。
壞的：
- VM 永遠不會獲得它配置的所有 RAM。
- VM 已經在交換 RAM。
- CPU配置過度。
