vSphere教育-RAMが多すぎるVMを構成することのマイナス面は何ですか？

VMwareのメモリ管理は、バランスをとるのが難しいようです。クラスターRAM、リソースプール、VMwareの管理手法（TPS、バルーニング、ホストスワッピング）、ゲスト内RAM使用率、スワッピング、予約、共有、制限には、多くの変数があります。

クライアントが専用のvSphereクラスターリソースを使用している状況にいます。ただし、仮想マシンを物理ハードウェア上にあるかのように構成しています。つまり、これは、標準のVMビルドに4つのvCPUと16GB以上のRAMがあることを意味します。私は小規模（1 vCPU、最小限のRAM）から始め、実際の使用状況をチェックし、必要に応じて調整する学校から来ました。残念ながら、多くのベンダー要件と仮想化に不慣れな人々は、必要以上のリソースを要求しています...この決定の影響を定量化することに興味があります。

「問題」クラスターからのいくつかの例。

リソースプールの概要-ほぼ4：1のオーバーコミットに見えます。大量のバルーンRAMに注意してください。

リソースの割り当て-最悪の場合の割り当て列は、これらのVMが、制約された条件下で構成されたRAMの50％未満にアクセスすることを示しています。

上記のリストのトップVMのリアルタイムメモリ使用率グラフ。4つのvCPUと64GB RAMが割り当てられています。平均9GB未満の使用です。

同じVMの概要

• vSphere環境でリソース（特にRAM）をオーバーコミットおよびオーバー構成することのマイナス面は何ですか？

• VMがより少ないRAMで実行できると仮定すると、仮想マシンを実際に必要とするよりも多くのRAMで構成するためのオーバーヘッドがあると言ってもいいでしょうか？

• 反論をどうされています。「VMが割り当てられたRAMの16ギガバイトを持っているが、唯一の4ギガバイトを使用している場合、問題は何でしょうか？」？たとえば、VMは物理ハードウェアと同じではないという教育を受ける必要がありますか？

• RAM使用量を測定するために使用する特定のメトリック。「アクティブ」対時間のピークを追跡しますか？「消費」を見ていますか？

更新：vCenter Operations Managerを使用してこの環境のプロファイルを作成し、上記のクラスター統計の詳細を取得しました。物事は間違いなく過剰にコミットされていますが、実際にはVMは不要なRAMで過剰に構成されているため、実際の（小さな）メモリフットプリントはクラスタ/ホストレベルでメモリ競合を示しません...

私の要点は、OSレベルのキャッシュ用に少しのバッファーを備えたVMを実際に適切なサイズにする必要があるということです。無知やベンダーの「要件」から過剰にコミットすると、ここに示される状況になります。メモリバルーニングは、パフォーマンスへの影響があるため、どの場合でも悪いようです。そのため、適切なサイズ設定でこれを防ぐことができます。

更新2： これらのVMの一部は、次のものでクラッシュし始めています：

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMwareは、これを大量のメモリのオーバーコミットメントの症状として説明しています。質問に答えていると思います。

vCops「特大仮想マシン」レポート...

vCopsの「回収可能な廃棄物」グラフ...

vSphereのメモリ管理はかなりまともですが、使用される用語はしばしば多くの混乱を引き起こします。

一般に、メモリのオーバーコミットは、まさにこのタイプの問題を引き起こすため、避けるべきです。ただし、回避できない場合もあるため、事前に注意してください。

vSphere環境でのリソース（具体的にはRAM）のオーバーコミットとオーバー構成のマイナス面は何ですか？

リソースのオーバーコミットの主な欠点は、競合が発生した場合、必要なRAMを各VMに提供するために、ホストがバックグラウンドでバルーニング、スワップ、またはインテリジェントなスケジュール/重複排除を強制されることです。

バルーニングの場合、vSphereは選択されたVM内のRAMの「バルーン」を膨らませ、それを必要とするゲストにそのバルーミングされたRAMを提供します。これは実際には「悪い」わけではありません-VMはお互いのRAMを盗んでいるので、ディスクスワッピングは行われません-しかし、これらがVMのRAM使用量の分析に依存している場合、RAMが勝つため、アラートの誤発火やメトリックのスキューにつながる可能性があります「バルーン」としてマークされるのではなく、OSによって「使用中」であるというだけです。

vSphereで使用できる他の機能は、透過的なページ共有（TPS）です。これは、本質的にRAMの重複排除です。vSphereは、割り当てられたすべてのRAMを定期的にスキャンし、重複ページを探します。見つかると、重複したページを重複排除して解放します。

より詳細な説明が必要な場合は、vSphereのメモリ管理ホワイトペーパー（PDF）、特に「ESXiでのメモリ再生」（ページ8）をご覧ください。

VMがより少ないRAMで実行できると仮定した場合、必要以上のRAMを搭載した仮想マシンの構成にはオーバーヘッドがあると言ってもいいでしょうか？

目に見えるオーバーヘッドはありません-16 GBのホストに100 GBのRAMを割り当てることができます（ただし、上記の理由により、そうすべきではありません）。

すべてのVMで使用されている合計メモリは、グラフに表示される「アクティブ」曲線です。もちろん、オーバーコミットしたい量を計算するときにその数字だけに頼るべきではありませんが、過去のメトリックを持っている場合は、実際の使用状況に基づいて分析し、解決することができます。

「アクティブ」RAMと「消費」RAMの違いについては、このVMWareコミュニティスレッドで説明しています。

：に反論は何である「VMが問題何、割り当てられたRAMの16ギガバイトを持っているが、唯一の4ギガバイトを使用している場合??」？例えば、顧客は教育を受ける必要がありますか？

これに対する簡単な答えは「はい」です。顧客は、使用するツールに関係なく、常にベストプラクティスについて教育を受ける必要があります。

お客様は、彼らがどのように応じて大きさに彼らのVMを教育されるべきで使うむしろ、彼らが何よりも、したいです。多くの場合、人々は毎日2 GBのメモリを使用していても、16 GBのRAM が必要になる可能性があるため、VMを過剰に指定します。vSphere管理者は、それらに挑戦し、割り当てられたRAMが実際に必要かどうかを尋ねる知識、メトリック、パワーを持っています。

とはいえ、vSphereのメモリ管理と入念に制御されたオーバーコミット制限を組み合わせれば、実際にはほとんど問題が発生しないはずです。長期間にわたってRAMが不足する可能性は比較的低いです。

これに加えて、自動化されたvMotion（VMwareによる分散リソーススケジューリングと呼ばれます）は基本的にVMのロードバランサーです。単一のVMがリソースを大量に消費する場合、DRSはクラスターのリソースを最大限に活用するためにVMを移行する必要があります。

RAM使用量を測定するために使用する特定のメトリック。「アクティブ」対時間のピークを追跡しますか？

主に上記で説明しました-特定の比率に達するとオーバーコミットしきい値を慎重に定義する必要がありますが、主な懸念は「アクティブな」RAM使用量である必要があります（これはまともな例ですが、少し時代遅れかもしれません）。通常、私は確かにクラスタRAMの合計の120％以内にとどまりますが、どの比率で快適かを決めるのはあなた次第です。

メモリのオーバーコミットに関するいくつかの良い記事/議論：

• 本番環境でのメモリのオーバーコミット？はいはいはい
• vSphere-メモリのオーバーコミット？
• vSphereのメモリオーバーコミット

クレイグ・ワトソンからの素晴らしい答えに加えて、私は以下を加えたいと思います：

VMwareのメモリのオーバーコミットは、意図的に行うべきものではありません。通常、お客様またはお客様のいずれかがハードウェアをオーバーサブスクライブしていることを示しています。

オーバーコミットが唯一の選択肢である場合、優先ルールを施行することを強くお勧めします。重要ではないVMに4GBしか必要としない16GBのvRamを提供したい場合-少なくともそのVMを低リソースプールに配置するか、優先度を低くします。本当に重要な本番データベースをハイパーバイザーによって交換したくないのです。パフォーマンスが低下するだけでなく、バ​​ックエンドストレージに対するI / Oキューも使い果たします。

非常に高速なストレージ（FusionIO、Violin、ローカルSSDなど）で実行している場合、スワッピングは大きな懸念ではないかもしれませんが、従来のSANストレージでは、同じアレイ/コントローラーに接続されたすべてのVMとホストに最終的に影響を及ぼします。