「Noisy Neighbor（うるさい隣人）」によるネットワーク停止の懸念
ERPプロジェクトのvSphereクラスタを半年以上運用して学んだ教訓があります。帯域幅が10Gbpsや25Gbpsあっても、適切に制御しなければ、重要な仮想マシン（VM）はいずれバックグラウンドタスクに圧倒されてしまいます。
私が経験した事例では、深夜2時にバックアップ（Veeam）が開始されると、トラフィックがアップリンクの95%を占有してしまいました。その結果、データベースがタイムアウトし、関連サービスがフリーズしました。これが典型的なNoisy Neighbor現象です。物理NICを追加購入せずにこの問題を根本的に解決するには、Network I/O Control (NIOC)が最も効果的なツールです。
物理的な分離か、ソフトウェアによる制御か？
多くの管理者が、ネットワークパフォーマンスを確保するために、以下の2つのアプローチのどちらを選ぶべきか悩んでいます。
1. 従来の手法：物理的な分離（Physical Isolation）
各トラフィックタイプ（vMotion、Management、Storage）を個別の物理ネットワークカード（NIC）に割り当てます。
- メリット：完全に隔離されるため、リソースの競合が発生しません。
- デメリット：スイッチのポートを多く消費し、配線が複雑になります。NICが故障した場合、冗長化の構成が非常に煩雑になり、システムがアイドル状態のときのリソースが無駄になります。
2. モダンなトレンド：NIOCの活用
このメカニズムは、単一の高速回線上で帯域幅をインテリジェントに分割します。
- メリット：ハードウェアを節約でき、vCenterを通じて柔軟に管理できます。アプリケーションの重要度に応じてトラフィックに優先順位を付けることが可能です。
- デメリット：vSphere Distributed Switch (vDS) が必須であり、Enterprise Plusライセンスが必要です。
現在のデータセンターでは、以前のように1GbpsのNICを8〜10枚挿すのではなく、25GbpsのNICペアとNIOCを組み合わせる構成が主流になりつつあります。
NIOC v3の「リソース配分」メカニズムを解明する
NIOCバージョン3は、明確に区別すべき2つの重要な概念に基づいて動作します。
ネットワークリソースプール（Resource Pools）
vSphereはトラフィックを自動的にManagement、vMotion、NFS、iSCSI、およびVirtual Machine Trafficのグループに分類します。また、データベースやWebフロントエンドなど、特定のVMをグループ化するためのカスタムリソースプールを作成することもできます。
3つの要素：Shares、Reservation và Limit
- Shares（シェア）：輻輳が発生した際の優先度。例えば、本番環境のVMを「High (100)」、vMotionを「Low (25)」に設定した場合、帯域が100%に達すると、本番環境にはvMotionの4倍の帯域幅が優先的に割り当てられます。
- Reservation（予約）：保証される最小帯域幅。vSphereはそのトラフィックのために常にリソースを確保します。ただし、使用していない時もリソースを占有するため、使いすぎには注意が必要です。
- Limit（制限）：帯域幅の上限。私はバックアップトラフィックに対して、システム全体の帯域を食いつぶさないよう、よく2Gbpsの制限を設定します。
Distributed Switch (vDS) でのNIOCの実装手順
注意：この機能は標準スイッチ（Standard Switch）ではサポートされていません。実行前にvDSに移行する必要があります。
ステップ1：NIOCの有効化
- vCenterを開き、[ネットワーク]タブに移動します。
- vDSを右クリックし、[設定] -> [サマリの編集]を選択します。
- [ネットワーク I/O コントロール]セクションで、[有効]を選択します。
ステップ2：システムリソースの割り当て
vDSの[設定]タブで、[リソースの割り当て] -> [システムトラフィック]を選択します。ここで「ルール」を設定します。
実務におけるShares設定の経験則：
- Virtual machine traffic: High (100) – 常に最優先。
- vMotion traffic: Low (25) – VMの移行がユーザーに影響を与えないようにします。
- Management traffic: Normal (50) – vCenterの操作権限を確保します。
- iSCSI/NFS traffic: High (100) – ネットワーク経由のストレージを使用している場合。
ステップ3：データベースサーバー専用の優先設定
DBサーバーに「専用レーン」を用意したい場合は、カスタムプールを作成します：
- [ネットワークリソースプール]で、[追加]をクリックします。
- 名前を「
DB_Critical_Pool」にします。 - 絶対的な最低速度を保証する必要がある場合は、[予約]を1000 Mbps程度に設定します。
ステップ4：ポートグループへの適用
最後に、VMが含まれるポートグループにプールを割り当てます：
- [分散ポートグループ]を右クリックし、[設定の編集]を選択します。
- [全般]セクションの[ネットワークリソースプール]で、
DB_Critical_Poolを選択します。
PowerCLIによるクイックチェック
手動でクリックする代わりに、スクリプトを使用してシステム全体の構成を管理しています。以下のコードは、各トラフィックタイプのSharesステータスを素早く一覧表示します：
$vDSName = "vDS-Production"
$vDS = Get-VDSwitch -Name $vDSName
# システムトラフィックのNIOC構成を確認する
Get-VDNetworkAdapterService -VDSwitch $vDS | Select-Object NetworkQueuingPolicy, @{N="TrafficType";E={$_.Key}}, Shares, Limit, Reservation | Format-Table -AutoSize
このスクリプトは、Reservationを高く設定しすぎてリソースを浪費している箇所を特定するのに役立ちます。
教科書には載っていない3つの「実戦的」注意点
- NIOCは輻輳時にのみ機能する： 帯域に余裕がある場合、NIOCは介入しません。低負荷時に速度の変化が見られなくても心配しないでください。
- 75%ルール： 1つのホスト上の予約（Reservation）の合計は、物理NICの帯域幅の75%を超えてはいけません。設定しすぎると、ネットワークリソース不足エラーで仮想マシンをパワーオンできなくなります。
- vDSの重要性： 標準スイッチを使用している限り、レイヤー2のトラフィックフローを完全に把握することはできません。できるだけ早くvDSへの移行を計画しましょう。
NIOCのマスターは難しくありません。重要なのは、アプリケーションのトラフィック特性を理解することです。この記事が、たとえ「うるさい隣人」がいたとしても、システムの円滑な運用に役立つことを願っています。
