vSphere 仮想環境で CPU、メモリ、ストレージをオーバーサブスクライブするためのベストプラクティス

仮想化の強力な機能の 1 つは、単一のホスト サーバー上で複数の異なるワークロードを実行し、そのホスト サーバーの使用率を最大化できることです。これにより、組織は最新のデータ センターを再構築できるようになります。 10 年前のデータ センターは一般的にサーバー中心でしたが、現代のデータ センターはビジネス アプリケーションのニーズを中心に展開し、それらのアプリケーションの高可用性とホスト サーバーの障害に対する耐性を確保しています。

実際、仮想化は他の多くの点でもデータセンターのダイナミクスに革命をもたらしました。以前はワークロードは最初にインストールされたハードウェアに限定されていましたが、現代のデータセンターのワークロードは絶えず変化しています。管理者が定義したルール セットとホスト環境の変更に基づいて、ホスト間でフローが行われます。現代のデータ センターの絶え間ない変化により、リソースの割り当てに新たな課題が生じており、長年にわたり、管理者のリソース計画を支援するさまざまな無料および有料のツールが市場に登場してきました。

[[227174]]

仮想化の台頭により、10 年前には想像もできなかった方法でハードウェアを使用できるようになっています。当時、管理者が購入したサーバーは、単一のアプリケーションのピーク需要をサポートできるサイズにする必要があり、サイズ設定プロセスでは、サーバー ハードウェアのライフサイクル全体にわたってアプリケーションが必要とするリソースの量を見積もる必要がありました。多くのサーバーでは単一のアプリケーションのみが展開されるため、リソース計画は比較的簡単です。高度に仮想化された最新のデータ センター環境では、単一のハードウェア上に多数の I/O パターンが存在するため、リソース計画は新たな複雑さに直面します。管理者は、各アプリケーションが環境内の他のアプリケーションとどのように対話するかを深く理解する必要があります。

高度に仮想化された環境では、混合モード I/O によってデータ センターの効率も大幅に向上します。これまで、管理者は通常、個々のアプリケーションのニーズに基づいて個々のサーバーのサイズを決定していました。現在、仮想環境の混合 I/O パターンにより、さまざまなピーク需要間でリソースを共有できます。その結果、管理者はさまざまなアプリケーション間でホスト リソースを非常に効率的に共有できるようになります。

また、仮想化を使用していても、管理者がピーク時の需要を満たすためにリソースを過剰にプロビジョニングし、個々の仮想マシンのサイズを調整する場合があることに注意してください。これにより、仮想マシンに未使用のリソースが残ることがよくあります。 vSphere には、アイドル状態のリソースを他の実行中のワークロードと共有できる強力な方法が多数用意されています。実際、アイドル リソースを共有できることに加えて、管理者はホスト上の物理リソースをオーバーサブスクライブして、単一のホストで可能な限り多くのワークロードを実行することもできます。つまり、管理者は、ホスト上で実際に使用可能なリソースよりも多くのリソースを仮想マシンに割り当てることができます。たとえば、ホストに 96 GB の物理 RAM があるとします。適切な場合、管理者はそのホスト上で実行されているすべての仮想マシンに 128 GB の RAM を割り当てることができます。

しかし、オーバーブッキングの制限は何ですか?実際には、制限はいくつかの要因によって異なります。このホワイト ペーパーでは、オーバープロビジョニングの概要、オーバープロビジョニングの長所と短所の詳細、およびオーバープロビジョニングの制限事項について説明します。

リソース管理とオーバーブッキング:

vSphere におけるオーバーサブスクリプションとは、さまざまな方法を通じて、物理ホストでサポートされている仮想サーバーに、そのホストで使用可能なリソースよりも多くのリソースを割り当てるプロセスを指します。通常、管理者は仮想マシン内の CPU、メモリ、およびストレージ リソースをオーバーサブスクライブできます。物理リソースのオーバーサブスクリプションについては、管理者によって意見が異なります。多くの管理者は、実行中のすべてのワークロードをサポートするために物理的に利用可能なリソースのみを割り当てることを好みます。これは最も安全なオプションであり、通常、実行中のすべての仮想マシンに必要なリソースが常に確保されることが保証されます。しかし、物理サーバーの再利用中に、物理サーバーがすべてのリソースを十分に活用していないことが判明しました。 CPU の観点から見ると、使用率は平均でわずか 5% ～ 15% であり、成長の余地が十分にあることを意味します。仮想マシンは、一般的に、従来の物理マシンよりも適切にサイズ設定できますが、特に特定のワークロードがアイドル状態のときは、まだ拡張の余地が残っています。多くの管理者は、単一のホスト上でより多くの仮想マシンを実行することで、これらのアイドル リソースを活用します。オーバーサブスクリプションにより、管理者はホスト上で実際に使用可能なリソースよりも多くのリソースを仮想マシンに割り当てることができます。つまり、すべての仮想マシンが割り当てられたすべてのリソースへのアクセスを突然要求した場合、ホストにはその要求を満たすのに十分なリソースがありません。リソースのオーバーサブスクリプションにより VM 密度は増加しますが、いくつかのリスクが伴います。特定のリソースが最終的に使い果たされると、そのリソースが過剰にサブスクライブされると、安定性の問題が発生し、ホスト サーバーで実行されているすべてのワークロードに影響を与える重大なパフォーマンスの問題が発生する可能性があります。

オーバーサブスクリプションについて詳しく説明する前に、vSphere に組み込まれているリソース管理機能を理解することが重要です。

CPU リソース管理:

vSphere では、管理者は個々の仮想マシンのワークロード要求をサポートするために、仮想マシンに CPU を割り当てることに慣れています。これらの仮想 CPU リソースは、ホストの使用可能な物理 CPU から提供されます。ホスト内の物理 CPU の数は、いくつかの要因によって異なります。物理 CPU と仮想 CPU の管理について基本的な理解を得るには、vSphere では物理 CPU (多くの場合 pCPU と略される) が以下を指すことを理解する必要があります。

· ハイパースレッディングが存在しないか有効になっていない場合: 単一の物理 CPU コア。

ハイパースレッディングが存在し、有効になっている場合: 単一の論理 CPU コア。

以下にいくつか例を挙げます。

• ホストに 8 コア CPU が 2 つあるが、ハイパースレッディングがサポートされていないか有効になっていない場合、ホストには 16 個の物理 CPU (8 コア x 2 CPU) があることになります。
• ホストに 8 コア CPU が 2 つあり、ハイパースレッディングが有効になっている場合、ホストには 32 個の物理 CPU (8 コア x 2 CPU x コアあたり 2 スレッド) があることになります。
• vSphere ホスト上で物理リソースがどのように表現されるかがわかったので、これらの CPU リソースを仮想マシンに提供する方法を見てみましょう。

仮想マシンでは、CPU は仮想 CPU (vCPU) と呼ばれます。管理者が仮想マシンに vCPU を追加すると、各 vCPU は pCPU に割り当てられますが、実際の pCPU は常に同じであるとは限りません。単一の仮想マシンに割り当てられた vCPU の数をサポートするには、十分な pCPU が必要です。そうでない場合、仮想マシンは起動に失敗します。

ただし、これは管理者がホスト内の pCPU の数に制限されることを意味するものではありません。仮想マシンに割り当てられた vCPU の数とホスト内の物理 CPU の数の間には 1:1 の比率はありません。実際、vSphere 5.0 以降では、各物理コアは最大 25 個の vCPU をサポートし、管理者はホスト上の仮想マシンに最大 2048 個の vCPU を割り当てることができます。

メモリリソース管理:

vSphere は、仮想環境での RAM の使用を最大化するためにいくつかの手法を使用します。以下に、テクノロジのリストと、それぞれの機能の簡単な説明を示します。

• 透過的なページ共有 (TPS) – ほとんどの仮想環境では、管理者は同じオペレーティング システムの複数のコピーを実行します。このような場合、ホスト メモリ内に重複したメモリ ページが多数存在します。透過的なページ共有は、基本的にメモリ重複排除の一種であり、vSphere は複数の同一メモリ ページを 1 つのページに結合し、残りのページを他の用途に解放します。パフォーマンスへの影響の観点から見ると、TPS はホストにほとんど影響を与えません。
• メモリバルーニング – VMware Tools がゲスト仮想マシンにインストールされると、メモリバルーン ドライバーが他のツール コンポーネントとともにインストールされます。ドライバーは Windows プロセスとして動作し、オペレーティング システムが通常のメモリ管理手法を使用して空き/未使用のメモリ ページを割り当てることができるようになります。次に、バルーン ドライバーはこれらのページを「ピン留め」し、ハイパーバイザーに報告します。ホストの物理メモリが不足すると、ゲストのメモリ ページがこのバルーン ドライバーに割り当てられます。割り当てが行われると、ホストはそれらのメモリ ページを再利用して、RAM を必要とする可能性のある他の仮想マシンのニーズを満たすことができます。このように、特定の仮想マシンに空き RAM がある場合、その RAM を同じホスト上の他の仮想マシンと透過的に共有できるため、ホストの仮想マシン密度が向上します。 TPS はメモリ重複排除テクノロジであり、バルーン プロセスは RAM のシン プロビジョニング機能を提供できます。バルーン プロセスには CPU オーバーヘッドが多少必要ですが、ゲストとホストの両方に対するパフォーマンスへの影響は最小限です。ただし、極端な場合には、バルーニングによってオペレーティング システム内でスワッピングが発生する可能性があります。
• メモリ圧縮 – vSphere 4.1 では、VMware はメモリ圧縮を導入しました。これは、場合によってはコストのかかるスワップ プロセスを置き換えることができるテクノロジです。このテクノロジーを使用すると、仮想マシンごとにメモリ ページをディスクにスワップする代わりに、メモリ ページを圧縮してディスク上の圧縮キャッシュに配置できます。スワップされたページを RAM に戻す必要がある場合は、このキャッシュから取得され、解凍されます。このプロセスはディスクへのスワップよりもコストがかかりませんが、パフォーマンスには多少影響します。
• ディスクへのスワッピング – ディスクへのスワッピングは、ホスト上で実行されているワークロードのニーズを満たすのに十分な物理 RAM を取得するためのハイパーバイザーの最後の手段です。 vSphere のその他のメモリ管理技術は非常に優れているため、スワッピングは通常、過度にオーバーコミットされたホストでのみ実行されますが、仮想マシンに構成されたリソース プールの制限やメモリの制限によってもスワッピングが発生することがあります。同様に、仮想マシンに VMware Tools がインストールされていないか実行されていない場合、システムはバルーン プロセスを完全にスキップし、スワップを直接実行します。スワッピングは、ハイパーバイザーが最も使用頻度の低いメモリ ページをディスクに移動するプロセスです。これらのメモリ ページは引き続きアクセス可能ですが、必要なときにディスクから取得する必要があります。パフォーマンスへの影響の観点から見ると、スワッピングは非常にコストがかかり、ホストの全体的なパフォーマンスが大幅に低下する可能性があります。

スワッピングと圧縮は、ホスト上でメモリ競合が発生した場合、または上記で説明したようにスワッピング状況が発生した場合にのみ実行されることに注意することが重要です。ほとんどの環境では、スワッピングや圧縮につながるメモリ競合の問題は回避する必要があります。この状況は、ホストの RAM が実質的に不足していることを意味するためです。

ストレージ リソース管理:

ストレージは vSphere 環境で 3 番目に重要なリソースであり、一般的なリソース割り当て手法を使用してオーバーサブスクライブすることもできます。

ストレージを過剰にプロビジョニングする最も一般的な方法は、シン プロビジョニング プロセスを使用することです。多くの場合、管理者は仮想マシンに絶対的に必要な量よりも多くのストレージを割り当てます。結局のところ、仮想マシンは時間の経過とともにさらに多くのディスク領域を必要とし続けることになります。シン プロビジョニングは次のように機能します。管理者が仮想マシンの合計ディスク領域をプロビジョニングすると、仮想マシンは割り当てられた領域全体にアクセスできるようになります。ただし、実際には、vSphere は仮想マシンが実際に使用するスペースのみを割り当てます。したがって、管理者が新しい VM に 200 GB のストレージを割り当てたが、その VM が 40 GB しか使用しない場合は、残りの 160 GB は他の VM に割り当てることができます。仮想マシンにさらに多くのスペースが必要な場合、vSphere は、元々割り当てられたディスクのサイズまで、仮想マシンに追加のブロックを提供します。

シン プロビジョニングを使用すると、管理者は必要なディスク領域全体をすぐに割り当てることなく、長期的に必要となる仮想ディスク サイズで仮想マシンを作成できます。多くのテストでは、シン プロビジョニングによるパフォーマンスへの影響は最小限であり、ほとんど無視できることがテスト結果から示されています。したがって、シン プロビジョニングは、ストレージ容量を管理するための最良の方法として最も一般的かつ最も受け入れられている推奨方法です。

また、一部のストレージ デバイスの他の機能によって、他のオーバーサブスクリプション レベルが許可される場合があることにも注意してください。このような機能には、データ圧縮や重複排除などがあります。このホワイト ペーパーではハイパーバイザーに焦点を当てているため、シン プロビジョニングについてのみ説明します。

リソースの過剰使用:

vSphere 環境でリソースを管理する方法を理解したので、次にそれらのリソースをオーバーサブスクライブする方法を学習します。この論文では、オーバーブッキングは許容される慣行であると想定しています。リソースが過剰に割り当てられているかどうかを判断するには、監視ツールが必要です。このホワイト ペーパーでは、Dell の無料 vOPS Server Explorer ツールが使用されています。

このツールにはいくつかの組み込みユーティリティがあります。左側に表示されている環境エクスプローラーは、管理者が環境内のリソース使用状況の概要を取得できる vOPS サーバー エクスプローラーのユーティリティの 1 つです。図に示すように、実際の物理リソースのリソース使用率が表示されるため、Environment Explorer はリソースの過剰割り当ての問題を理解するのに非常に適しています。

CPU リソースのオーバーサブスクライブ:

前述したように、vSphere 5 では、各物理 CPU コアは最大 25 個の vCPU をサポートできます。ただし、vCPU と pCPU の比率が 1:1 を超えるその他のすべてのワークロードでは、vSphere ハイパーバイザーは CPU スケジューリングを呼び出して、必要な VM に CPU 時間を割り当てる必要があります。したがって、管理者が 5:1 の vCPU と pCPU の比率を作成すると、各 CPU は 5 つの vCPU をサポートします。

このホワイト ペーパーの一般的なガイダンスを確認すると、最適な vCPU と pCPU の比率についてはさまざまな意見があります。誰もが同意する 2 つの経験則は次のとおりです。

まず、仮想マシンごとに 1 つの vCPU を構成します。ほとんどの専門家は、新しい仮想マシンを作成するときに、管理者は 1 つの vCPU のみを構成し、需要に応じて仮想 vCPU を増やす必要があることに同意しています。 vCPU の数が増えると、仮想マシンはホストから CPU 時間を取得する必要があります。仮想マシンが操作を実行する必要がある場合、割り当てられた vCPU の数と同じ数の物理 CPU が準備完了になるまで待機する必要があります。したがって、管理者が仮想マシンに vCPU を追加すると、全体的なパフォーマンスは低下し続けます。

vCPU と pCPU の比率はワークロードによって異なります。 vCPU:pCPU = 1:1 の割り当てが推奨されますが、異なる比率を設定するのが一般的です。つまり、vSphere 5 は最大 25:1 の比率をサポートしますが、高い比率を実現できるかどうかは、サポートされるワークロードの種類に大きく依存します。ホストが多数の仮想マシンをサポートし、各仮想マシンの CPU 要件が小さい場合、vCPU と pCPU の比率が高くなる可能性があります。ただし、ホストが CPU を大量に使用するワークロードを実行している場合、この比率ははるかに小さくなる可能性があります。

監視する指標:

管理者がバランスの取れた vCPU と pCPU の比率を維持し、健全なワークロードを確保しながらリソースをより効率的に使用できるようにするために、いくつかの CPU 関連のメトリックを監視する必要があります。

• 仮想マシン内部

CPU 使用率 – このメトリックは、管理者が仮想マシンに vCPU を追加する必要があるタイミングを判断するのに役立ちます。平均 CPU 使用率が高いままの場合は、仮想マシンに vCPU を追加する時期です。

• ホスト上

CPU 準備完了 – これは、ホストの全体的な CPU の健全性の観点から、最も重要なメトリックです。 CPU 準備完了メトリックは、仮想マシンの要求を満たすのに十分な物理 CPU が確保されるまで仮想マシンが待機する時間を決定します。 VM に 4 つの vCPU が割り当てられている場合、このメトリックは、対応する 4 つの pCPU すべてが同時に使用可能になるまで VM が待機する時間を示します。

CPU 使用率 – ホスト サーバーの全体的な CPU 使用率も重要です。これは、管理者がホスト サーバーのワークロードを理解するのに役立ちます。

実際の環境:

• 仮想リソース
• 4 つの vCPU – 実際のコア数の 200%
• 3GB RAM – 物理メモリの37%
• 26.6 GB のストレージ – プロビジョニングされたストレージの 13%

さまざまなフォーラムで、ユーザーから、実際の環境で許容される vCPU と pCPU の比率はどの程度かという質問が寄せられています。一部のユーザーは 1:1 の比率を主張し続けています。しかし、純粋な密度の観点から見ると、1:1 は最悪のシナリオです。左側のグラフでは、この特定の実験シナリオでは現在 2:1 の比率が使用されていることに注意してください。

一部のユーザーは、vCPU と pCPU の比率が 1.5:1 を超えないように指導されたと述べていますが、業界の専門家は、vSphere の「実際の」比率は 10:1 から 15:1 の範囲であるべきだとアドバイスしています。一部のユーザーは、VMware では実際の環境に対して 6:1 ～ 8:1 の比率範囲を推奨していると述べています。

この Dell ホワイト ペーパーでは、vCPU:pCPU のガイドラインは次のとおりです。

• 1:1から3:1まで問題なく
• 3:1から5:1ではパフォーマンスが低下する可能性があります
• 6:1以上だと問題が発生することが多い

その他のガイダンスでは、「CPU 準備完了」メトリックを 5% 以下に保つことがベスト プラクティスであると示されています。特定の環境で達成可能な実際の比率は、いくつかの要因によって異なります。

• vSphere リリース – vSphere CPU スケジューラは引き続き改善されています。 vSphere のバージョンが高ければ高いほど、統合は強力になります。
• CPU の年齢 – 新しい CPU は古い CPU よりもはるかに強力であり、新しい CPU を使用することで、組織はより高い CPU 比率を達成できます。
• ワークロード タイプ - ホスト上のワークロードのタイプによって比率が異なります。

vScope Explorer は、vOPS Server Explorer 内の別のユーティリティであり、CPU Ready などのホストおよび VM レベルでのパフォーマンスの問題を理解し、vCPU と pCPU の比率が高すぎるかどうかを判断するのに役立ちます。

さらに、環境探索では、ホスト CPU リソースが過剰に割り当てられている場所を特定し、管理者が追加の分析を実行して、過剰割り当てが現在のパフォーマンスの問題を引き起こしているかどうかを判断するようにガイドします。実際のコア % メトリックが 500% を超え始めたら、管理者は CPU の準備状況と一般的なワークロード パフォーマンスをより厳密に監視し、ビジネス ニーズが満たされていることを確認する必要があります。

メモリ リソースのオーバーサブスクライブ:

RAM のオーバーサブスクリプションは、多くのリソース オーバーサブスクリプション スキームの中でおそらく最も議論の多いものです。 CPU とストレージ リソースは通常はオーバーコミットされますが、RAM のオーバーコミットは依然として控えめです。

監視する指標

ホスト サーバーでは、管理者は仮想マシンが実際に使用している RAM の量を監視する必要があります。実際の RAM 使用率が 100% に近づくと、サーバーの RAM を増やすか、使用可能な RAM が多いホストにワークロードを移行する必要があります。

実際の環境

• 仮想リソース
• 4 つの vCPU – 実際のコア数の 200%
• 3GB RAM – 物理メモリの37%
• 26.6GB のストレージ – プロビジョニングされたストレージの 13%

Environment Explorer では、vSphere のさまざまなメモリ管理手法が使用されている場合、RAM 使用量 (物理メモリ % メトリック) には、仮想マシンによって使用される実際の RAM 量ではなく、各仮想マシンにプロビジョニングされた実際の RAM 量が表示されます。環境の健全性を確保しながら仮想マシンの密度を最大化するには、実際のメモリ使用率を監視することが重要です。

オーバーコミットメントのレベルは、ホスト上で複数の類似のワークロードを実行するときに達成できるメモリの重み付け軽減という 1 つの主要な要因によって決まります。実行中のワークロード間の多様性のレベルが高くなるほど、メモリ統合は少なくなり、達成できる密度は低くなります。

メモリのオーバーコミットメントに関して他の人が行ったことや提案を調べたところ、次のことがわかりました。

• 多くの管理者は、RAM のオーバーサブスクライブを一切拒否します。
• 管理者の中には、このメトリックを超えると許容できないリスクが生じると考え、物理メモリの 125% を超えないようにすることを好まない人もいます。
• サーバー上のすべてのワークロードが同一である場合、非常に高いオーバーコミットメント レベルが発生する可能性があります。
• 他の多くの管理者は、オーバーコミット レベルを定期的に確認するのではなく、ホストのメモリ使用量をスポットチェックするだけです。

ストレージ リソースのオーバーサブスクライブ:

ストレージ リソースをオーバーサブスクライブするには、シン プロビジョニングを使用するのが一般的です。オーバーブッキングには多くの利点と欠点があることは間違いありません。主な利点は、管理者が組織のストレージ容量を最大限に活用できることです。さらに、シン プロビジョニングを使用すると、管理者は、さらにスペースが必要かどうかを常に監視することなく、仮想マシンに必要なすべてのストレージを割り当てることができます。シンプロビジョニングにより、IT チーム内の摩擦も軽減されます。アプリケーション所有者は必要なストレージをすべて要求することができ、ストレージ管理者はこの要求が過剰であることを理解していますが、過剰に要求されたストレージが無駄になることを心配することなく、要求を承認するだけです。

シン プロビジョニングには、日常的なタスクが簡単になる一方で複雑さが増すという課題も伴います。まず第一に、管理者が注意を怠ると、重大なユーザビリティの問題が発生する可能性があります。ストレージのオーバーサブスクリプションによってストレージ ボリュームの容量が不足した場合、仮想マシンは使用可能なディスク容量があると判断しますが、実際には使用可能なディスク容量はありません。注意深く監視しないと、重大な障害、データ損失、コストのかかる復旧操作が必要になる可能性があります。

監視する指標

この問題を軽減するには、シン プロビジョニングを使用する管理者は、データストアの空き領域の量を注意深く監視する必要があります。データストアのスペースが不足している場合、管理者はデータストアのスペースを積極的に増やすか、Storage vMotion を使用して仮想マシンの 1 つをワークロードのニーズを満たすのに十分な空き容量がある別のデータストアに移動する必要があります。

実際の環境:

• 仮想リソース
• 4 つの vCPU – 実際のコア数の 200%
• 3GB RAM – 物理メモリの37%
• 26.6GB のストレージ – プロビジョニングされたストレージの 13%

環境エクスプローラーでは集計結果のみが表示されますが、シンプロビジョニングは完全に反映されます。このホワイト ペーパーの例では、仮想マシンで使用可能なストレージは 195 GB ですが、現在使用されているのは 26.8 GB のみです。実際には、電源がオンになっている 3 台の仮想マシンにプロビジョニングされるストレージは、これよりもはるかに大きくなります。管理者が環境エクスプローラーを表示するときに、プロビジョニングされたストレージ % メトリックが 100% に近づく場合は、追加の物理リソースが利用可能であることを確認するように注意する必要があります。

結論は：

仮想化により、柔軟性が大幅に向上し、オーバープロビジョニングとオーバーサブスクリプションを通じてホスト サーバーのリソース使用率を最大化できます。このホワイト ペーパーで説明されているさまざまな方法論と実際のシナリオは、CPU、メモリ、ストレージをオーバーサブスクライブして仮想環境でのパフォーマンスを確保しながら使用率を最大化するためのベスト プラクティスを管理者に提供します。

このホワイト ペーパーでは、仮想環境のオーバーサブスクリプションとパフォーマンス監視に関する情報を提供する Dell の無料 vOPS ServerExplorer ツールについても説明します。