仮想マシン同士のリソースの「奪い合い」を防ぐには？
ESXiホストのCPU使用率に40%の余裕があるのに、中の仮想マシン（VM）がカクついたり遅延したりした経験はありませんか？仮想化管理者の最大の恐怖は、サーバーのダウンではなく、原因不明の「激重」状態でシステムが動作することです。多くの場合、問題はハードウェア不足ではなく、リソースの割り当て方が不適切であることに起因します。
個人のラボ環境から企業のvSphereクラスタ管理に転向したばかりの頃、私は「オーバープロビジョニング（Over-provisioning）」という典型的なミスを犯しました。vCPUを大量に割り当てればVMが強力になると勘違いしていたのです。その結果、CPU Ready Timeが15%を超えて急上昇し、VM同士でリソースの激しい奪い合いが発生、システム全体が停滞してしまいました。この記事では、同じ轍を踏まないよう、Shares、Reservations、Limitsの使い分けを徹底解説します。
背景：なぜデフォルト設定だけでは不十分なのか？
デフォルトでは、vSphereは「早い者勝ち」に近い形で、比較的公平にリソースを分配します。しかし、現実にはすべてのVMが同じ重要度であるわけではありません。数千人のユーザーを抱えるデータベースサーバーは、プリントサーバーやテスト用Webサーバーよりも優先されるべきです。
設定を疎かにすると、すぐに「Noisy Neighbor（うるさい隣人）」問題に直面します。CPUループに陥ったVMやDDoS攻撃を受けているVMが1つあるだけで、同じホスト上で稼働するすべてのVMのパフォーマンスを道連れにしてしまうのです。
強力な武器を有効化する：vSphere DRS
リソースを効率的に管理するには、vCenter ServerとESXiホストをクラスターにまとめる必要があります。特に、vSphere DRS (Distributed Resource Scheduler) を有効にしましょう。この機能により、vCenterは負荷の高いホストから余裕のあるホストへVMを自動的に移行（vMotion）してくれます。
- vSphere Clientにアクセスし、対象のクラスターを選択します。
- [設定] タブから [**vSphere DRS**] を選択します。
- [編集] をクリックし、ステータスを [**オン**] に切り替えます。
補足：無料版のESXiを使用している場合、個々のVMに対してSharesやLimitsを設定することは可能ですが、リソースプールによる自動負荷分散機能は利用できません。
3つの重要パラメーター：Shares、Reservations、Limitsを徹底解剖
これら3つのパラメーターの本質を理解することが、システムパフォーマンスをマスターする鍵となります。
1. Reservations（予約：最小保証リソース）
これは、ESXiがそのVMのために確保を約束するリソース量です。ホストにReservationで設定した分の空きメモリ（例：2GB RAM）がない場合、そのVMは起動すらできません。
アドバイス： SQL ServerやOracleなどの極めて繊細なアプリケーションにのみ設定してください。すべてのVMに設定すると、仮想化の最大の利点である「オーバーコミット」ができなくなります。
2. Limits（制限：最大リミット）
Limitsはハードリミットです。ホストが90%空いていても、VMはこの数値を超えてリソースを使うことは許可されません。
警告： RAMに対してLimitを設定することは極力避けてください。VMが RAMの上限に達すると、ESXiは強制的にディスクへのスワップを開始します。アクセス速度がナノ秒（RAM）からミリ秒（ディスク）へと低下し、VMはほぼフリーズ状態に陥ります。
3. Shares（シェア：相対的な優先度）
Sharesは、リソースの競合（Contention）が発生したときにのみ機能します。ホストが混雑している際、Sharesの値が高いVMが優先的に処理されます。
例えば、データベースVMを「高（High）」、Web VMを「通常（Normal）」に設定した場合、CPUが過負荷になるとデータベースにはWebの2倍のリソースが割り当てられます。システムが空いているときには無駄が発生しないため、最もスマートな調整方法です。
Storage I/O Control (SIOC) によるディスクI/Oの最適化
CPUやRAMだけに目を向けてはいけません。ディスクI/Oこそが、システム遅延の最も一般的なボトルネックです。1つのVMでウイルススキャンが走ると、ディスク帯域を独占し、レイテンシ（遅延）が50msを超え、他のVMがフリーズすることがあります。
この問題を解決するには、データストアで **Storage I/O Control (SIOC)** を有効にします：
- [データストア] 一覧から対象のデータストアを選択します。
- [設定] -> [**全般**] 開きます。
- [データストア機能] で、[**Storage I/O Control**] を有効にします。
有効化後、各VMのディスクSharesを調整します。DBサーバーには2000、サブサーバーには500や1000を設定するのが一般的です。
esxtopで「語る」指標を読み解く
設定が有効かどうかを確認するには、実際の数値を見る必要があります。ホストにSSHで接続し、`esxtop` コマンドを入力してください。
- **’c’** を押してCPUを表示：**%RDY** 列に注目してください。この数値が **10%** を超えている場合、VMは「順番待ち」が長すぎます。他のVMのvCPUを減らすか、そのVMのSharesを上げてください。
- **%MLMTD > 0** の場合：設定した *Limit* 自体によってVMが制限されています。VMが遅い場合は制限を緩和してください。
- **’m’** を押してRAMを表示：**SWCUR** 列を確認します。この数値が0より大きい場合、VMはディスクへのスワップを行っています。すぐにメモリを追加割り当てする必要があります。
PowerCLIによるクイックチェック
何百台ものVMを管理している場合、一つずつ手動でチェックするのは不可能です。このPowerCLIによるスクリプトを使えば、ハードリミットが設定されているVMを素早くリストアップできます：
Get-VM | Get-VMResourceConfiguration | Where-Object {$_.CPULimitMhz -ne -1 -or $_.MemLimitMB -ne -1} |
Select-Object VM, CPULimitMhz, MemLimitMB | Format-Table -AutoSize
実務経験から得た黄金律
長年の運用を経て、私はいくつかの重要な原則を導き出しました：
- vCPUは少ないほど良い： 負荷80%で動作する2つのvCPUを持つVMの方が、負荷10%で動作する8つのvCPUを持つVMよりもスムーズに動作することが多いです。これにより、CPUスケジューラーへの負荷を軽減できます。
- LimitsよりもSharesを優先： 固定の数値でシステムを縛り付けるのではなく、システムが柔軟に自己調整できるようにしましょう。
- ホストに「遊び」を持たせる： ホストのRAMを90%以上使い切らないようにしてください。少なくとも10%はESXiのシステムプロセス用に残しておきましょう。
これらの知見が、仮想化環境の最適化に役立つことを願っています。もし異常に高い %RDY 指標に遭遇し、対処法がわからない場合は、ぜひ下のコメント欄で質問してください！
