アプリケーションのVMwareパフォーマンス要件をVMware管理者に説明する方法

多くの場合、オンサイトのdebian-stableベースのアプリケーションのインストールは、仮想マシン（通常はVMware ESXi）で実行されます。一般的なケースでは、仮想化環境に対する可視性や影響力はなく、VMware vCenterクライアントや同等のものへのアクセスもありません。ここではVMwareに焦点を当てます。これは、私たちが目にする最も一般的な方法だからです。

私たちがしたいこと：

• お客様のVMware管理者に伝える：パフォーマンス基準X、Y、Zを満たしている限り、VMware ESX環境などでアプリケーションを実行できます。
• 実行中のシステムであっても、基準X、Y、Zが実際に継続的に満たされているかどうかを判断できます（たとえば、現在も）（アプリケーションを停止してベンチマークを実行することはできません。仮想環境は時間とともに変化します）。
• 基準X、Y、およびZが満たされた場合、十分なパフォーマンスでアプリケーションを実行するための適切な仮想HWリソースがあることを確信してください。

X、Y、Zとは何ですか？

パフォーマンスの問題がある場合、問題はアプリケーションではなく、仮想化環境にあることが何度もあります。たとえば、別の仮想マシンが大量のCPU、メモリ、またはディスクが実際に格納されているSANを使用している場合、アプリケーション以外のものが頻繁に使用します。現在、それを証明または反証する方法はありません。

理論的には、アプリケーションが遅い場合もあります... ;-)

パフォーマンスの問題の根本的な原因（仮想環境またはアプリケーション）をどのように判断しますか？

通常、CPU、メモリ、およびディスクI / Oのパフォーマンスの問題には3つの領域があります。

CPU

たとえばVMwareでは、管理者はMHzで表される予約と制限を指定できますが、たとえば、あるESXホストの512MHzは別のESXホストの512MHzとまったく同じです。

そして、私たちが実際にそれを得るかどうかをどのように測定しますか？アプリケーションの実行中に、おそらく4つのCPUで212％のCPU使用率になっていることがわかります。私たちのアプリケーションが多くのことをしているからか、同じホスト上の別のVMがCPUを集中的に使用してすべてのCPUを使用しているからでしょうか？

メモリー（バルーニング？）

たとえば16GB RAMを要求すると、多くの場合構成されますが、バルーニングのために、実際には4GBしか得られず、驚くことに、アプリケーションのパフォーマンスが低下します。

VMwareツールに現在のバルーニングについて尋ねることができますが、それはしばしば嘘をつく（または少なくとも不正確である）ことがわかりました。OSが合計16GBのRAMがあり、すべてのプロセスの常駐メモリ（RSS）の合計が4GBのRAMであると考える例を見てきましたが、VMwareツールからバルーンが0であると通知された場合でも2GBのRAMしかありません： -（

また、コピーオンライトメモリなどの共有RAMが簡単に存在する可能性があるため、RSSを一緒に追加するだけでは有効ではありません。そのため、すべてのプロセスからRSSを単純に差し引いて、RAMの空き容量を測定し、バルーニングを確実に検出することはできません。バルーニングのいくつかのケースを検出できますが、バルーニングが有効であるが、この方法では検出できない他のケースがあります。

ディスクI / O

ディスクの読み取りと書き込みの数、読み取りと書き込みのバイト数、およびIO待機％を経時的にグラフ化できると思います。しかし、それはディスクI / Oの正確な状況を教えてくれますか？すべてのCPUを使用する別のVMでビットコインマイナーが実行されている場合、CPUリソースが低下し、IO待機（％で測定されます）上がります。

要約すると、VMware管理者などに、どの言語を使用してどのようなパフォーマンスが必要かを、ポータブルで測定可能な方法で説明できますか？

• 真剣に、ほとんどのVMware管理者はこれが得意ではありません。リソース管理の理解が不十分で、多くの場合Linuxの知識がなく（役立つ）、時間帯域幅が不足しています。ほとんどの社内管理者は、仮想化に関する深い知識を維持するのに苦労しています。

• 幸いなことに、あなたが読むことができる本があります！

• ほとんどのVMware環境は、優れたものではありません。不適切なクラスター設計、不適切なリソース計画、標準以下のストレージ（Synology NASなど）、HAの構成ミス、監視やパッチ適用なし。

• 組織としてのVMwareは私たちを失敗させます。彼らは最新の情報を広め、ベストプラクティスを促進するのが特に苦手です。一般的な質問の基本的な検索では、プロセスと設計が時間とともに変化したという事実にもかかわらず、2009年およびVMwareの古いリビジョンから結果が生成されます。

これらはすべてあなたに反するでしょう。

ソリューションの実際の要件を決定する必要があります。アプライアンスが必要とすることを正確に述べることができる：2 vCPU、8GB RAM、および500 IOPのストレージパフォーマンスは、私のような人にとっては大いに役立つでしょう。

もう1つのアプローチは、健全な環境または理想的な環境を観察し、そこからメトリックを推定することです。

特定の展開に関する問題を説明しました。問題とボトルネックは何でしたか？

適切なサイズのVMの例：

300ユーザー組織のExchangeサーバー。

• 6週間のワークロード/ストレスヒートマップがあります。
• 6個のvCPUにより、スパイク用のバッファルームが確保され、ストレスゾーンを上回っています。
• 32GB RAMは、ストレス値を上回る値を維持しますが、実際に必要な値を超える不当な量ではありません。

• 数GBのRAMとvCPUを再利用できましたが、すべてが効率的なVMです。
• 理想的な条件下でアプリケーションのこのタイプの監視を取得するのが賢明でしょう。

VMリソースの監視の例。

Good-ish：-VMは適切なサイズです。-クラスタ全体でCPUがオーバーコミットされていますが、競合は発生していません。

悪いような：

• VMは、設定されているすべてのRAMを取得することはありません。
• VMはすでにRAMをスワップしています。
• CPUが過剰に構成されています。