アプリケーションのVMwareパフォーマンス要件をVMware管理者に説明するにはどうすればよいですか？

Question

多くの場合、オンサイトの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で表された予約と制限を指定できますが、 1つのESXホスト上の512MHzは、別のESXホスト上の512MHzとまったく同じですか、おそらく完全に異なるESXクラスター内ですか？

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

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

たとえば、 16GB RAM、これは頻繁に設定されますが、バルーンのため、実際には4GBしか取得できず、驚いたことに、アプリケーションのパフォーマンスは低下します。

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

また、簡単に共有RAMが存在する可能性があるため、RSSを一緒に追加するだけでは無効です。コピーオンライトメモリなので、512MB + 512MBは必ずしも1GBを意味するわけではありませんが、それより少ないことを意味する可能性があります。したがって、すべてのプロセスからRSSを単純に減算して、RAMを解放し、それによって確実にバルーニングを検出する必要があるかどうかを測定することはできません。バルーニングのいくつかのケースを検出できますが、他の場合もあります。バルーニングは有効ですが、この方法では検出できません。

ディスクI/O

時間の経過とともに、ディスクの読み取りと書き込みの数、読み取りと書き込みのバイト数、およびIO待機％）をグラフ化できると思います。しかし、これにより、ディスクI /の正確な状況がわかります。 O？ビットコインマイナーが別のVMすべてのCPUを使用して実行されている場合、基盤となる場合でも、IO待機％が増加しますSANは、CPUリソースが低下したため、まったく同じパフォーマンスを提供します。したがって、IO待機（％）が上昇します。

つまり、要約すると、たとえば、 VMware管理者は、ポータブルで測定可能な方法で、どのようなパフォーマンスが必要ですか？

ewwhite · Accepted Answer

真剣に、ほとんどのVMware管理者はこれが得意ではありません：リソース管理の理解が不十分で、Linuxの知識がない（役に立たない）場合が多く、時間帯域幅が不足しています。ほとんどの社内管理者は、仮想化に関する深い知識を維持するのに苦労しています。
幸いなことに読むことができる本があります！
ほとんどのVMware環境は適切ではありません：クラスター設計が不十分、悪いリソース計画、標準以下のストレージ（つまりSynology NAS）、HAの設定ミス、監視またはパッチ適用なし。
組織としてのVMwareは失敗する：彼らは特に、最新の情報を広め、ベストプラクティスを促進することに長けています。プロセスと設計が時間とともに変化したという事実にもかかわらず、一般的な質問の基本的な検索は、VMwareの2009年以前のリビジョンから結果を生成します。

これらのすべてはあなたに対して機能します。

ソリューションの実際の要件を決定する必要があります。アプライアンスが必要とすることを正確に述べることができること：2 vCPU、8GB RAM and 500 IOPs storage performanceは行くでしょう私のような人への長い道のり。

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

特定のデプロイメントの問題について説明しました。問題とボトルネックは何でしたか？

適切なサイズのVMの例：

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

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

数GBのRAMとvCPUを再利用できますが、これは効率的なVMです。
理想的な条件下でアプリケーションのこのタイプの監視を取得することをお勧めします。

VMリソース監視の例。

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

悪い：

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