VMware vSphereにおけるVM-HostおよびVM-VM Anti-Affinityルールの設定:形骸化したHigh Availabilityの罠を防ぐ

VMware tutorial - IT technology blog
VMware tutorial - IT technology blog

High Availabilityの罠:2台の冗長化VMが同一物理サーバー上に同居するリスク

Load Balancerの配下で2台のWeb仮想マシン(VM)を並行稼働させているシステムがあるとします。理論上は、片方のノードがダウンしても、もう片方が通常通りトラフィックを処理し続けるため、一見すると標準的なHigh Availability(HA)構成が満たされているように思えます。

しかし、予期せぬ障害が発生します。あるESXiホストが電源ユニット(PSU)の故障により突然ダウンしました。その瞬間、Webサービス全体が停止してしまいます。vCenterを確認すると、冗長化していたはずの2台のVMが、ダウンしたまさにその1台の物理サーバー上に同居していたことが判明します。この原因は、自動負荷分散機能であるDRS(Distributed Resource Scheduler)にありました。DRSは当該ホストの空きRAMリソースに余裕があったため、リソース最適化を優先して両方のVMを同一ホストへ集約してしまっていたのです。

4〜16台のESXiホストで構成されるクラスター環境において、DRSは5分周期でCPUおよびRAMの消費状況のみを計算して配置を決定します。システム側は、どの仮想マシン同士が冗長構成ペアであるかを自動的に判断することはできません。このリスクを根本から解消するには、DRS Affinityルール(アフィニティルール)およびAnti-Affinityルール(非アフィニティルール)の設定が不可欠です。

正しい理解:AffinityルールとAnti-Affinityルールとは?

動作原理は非常にシンプルです:

  • Affinity(同居・引き寄せ): 指定したオブジェクト同士を同一ホスト上で稼働させる、または優先的に集約するルール。
  • Anti-Affinity(分離・反発): 指定したオブジェクト同士を異なるホストへ強制的に分散させ、同居を絶対に許可しないルール。

1. VM-VMルール(仮想マシン間の配置ルール)

  • Keep Virtual Machines Together (Affinity): 指定したVMグループを常に同一のESXiホスト上で稼働させます。代表的な例として、内部トラフィックが毎秒数千リクエストに達するAppサーバーとDatabaseサーバーのペアが挙げられます。同一ホスト上で稼働させることで、パケットはRAM上のvSwitchを経由して直接転送され、物理スイッチの帯域を消費することなく数十Gbpsのスループットを実現できます。
  • Separate Virtual Machines (Anti-Affinity): 指定したVMを必ず異なるホストへ分散配置します。これは2台のActive Directoryドメインコントローラー(DC)、SQL Server AlwaysOn構成のペア、負荷分散用のNGINXプロキシサーバーなどにとって極めて重要なルールです。

2. VM-Hostルール(仮想マシングループと物理ホストグループの関連付けルール)

この仕組みは、仮想マシングループ(VM DRS Group)と物理サーバーグループ(Host DRS Group)をマッピングします。制約の強度には以下の2つのレベルがあります:

  • Must run on / Must NOT run on(ハードルール – 100%強制): DRSおよびvSphere HAが完全に遵守すべき絶対的な制約です。グループ内のすべてのホストがダウンした場合、VMは停止したままとなり、HAは指定リスト外のホストでVMを起動することは決してありません。このレベルは主に、CPUコア単位で課金されるソフトウェアライセンス(Oracle DBやMS SQL Enterpriseなど)の制限や、専用ハードウェア(PCIeパススルー、GPU)を搭載したホストへの固定に用いられます。
  • Should run on / Should NOT run on(ソフトルール – 柔軟な優先設定): 通常時、DRSは指定されたホストグループ内にVMを維持します。しかし、ホスト障害やリソース枯渇が発生した場合、サービスのアップタイムを維持するために、vSphere HAが他のホスト上でVMをフェイルオーバー起動することが許可されます。

実践ガイド:vSphereでのルール設定手順

方法1:vSphere Clientを使用したVM-VM Anti-Affinityルールの設定

例:2台の仮想マシンVM-Web-01とVM-Web-02を異なるESXiホストに分散配置する。

  1. vSphere Client(HTML5クライアント)にログインします。
  2. 左側のインベントリツリーから対象のクラスターを選択します。
  3. 設定(Configure)タブ > VM/ホスト ルール(VM/Host Rules)を選択します。
  4. 追加(Add)をクリックして新規ルールを作成します。
  5. ルール名を入力します:Rule-AntiAffinity-WebTier
  6. ルールを有効化(Enable rule)にチェックを入れます。
  7. タイプ(Type)で仮想マシンの分離(Separate Virtual Machines)を選択します。
  8. 下部のリストで追加(Add)をクリックし、VM-Web-01とVM-Web-02を選択します。
  9. OKをクリックします。もしこれら2台のVMが同一の物理サーバー上で稼働している場合、DRSが即座にvMotionをトリガーし、片方のVMを別のホストへ自動移行します。

方法2:データベースグループ向けVM-Hostルールの設定(ライセンスの最適化)

シナリオ:8台構成のクラスターで、Oracleライセンスをesxi-01とesxi-02の2台分のみ購入している場合。3台のDB仮想マシンをこの2台のホストに集約します。

  1. クラスターの設定(Configure)タブ > VM/ホスト グループ(VM/Host Groups)を選択します。
  2. VMグループを作成:名前をVMG-Oracle-DBsとし、3台のDB仮想マシンを選択します。
  3. ホストグループを作成:名前をHG-Oracle-Licensed-Hostsとし、esxi-01およびesxi-02を選択します。
  4. VM/ホスト ルール(VM/Host Rules)に移動し、追加(Add)をクリックします。
  5. タイプ(Type)で仮想マシンからホスト(Virtual Machines to Hosts)を選択します。
  6. VMグループ: VMG-Oracle-DBsを選択します。
  7. 関係性を選択:Should run on hosts in group(ホスト障害時にもVMを再起動できるようにする場合はShouldを使用)またはMust run on hosts in group(ライセンス監査のペナルティが極めて厳しい場合)。
  8. ホストグループ: HG-Oracle-Licensed-Hostsを選択し、OKをクリックします。

方法3:VMware PowerCLIによる自動化

数十のクラスターを管理している場合や、VMプロビジョニングのCI/CDパイプラインに組み込む場合は、PowerShellスクリプトを使用します:

# 1. vCenterへの接続
Connect-VIServer -Server vcenter.company.local -User "[email protected]" -Password "MatKhau@123"

# 2. パラメータの定義
$clusterName = "Production-Cluster"
$ruleName = "AntiAffinity-DomainControllers"
$vmList = Get-VM -Name "DC-01", "DC-02"

# 3. VM-VM Anti-Affinityルールの作成
$cluster = Get-Cluster -Name $clusterName
New-DrsRule -Cluster $cluster -Name $ruleName -KeepTogether $false -VM $vmList -Enabled $true

# 4. 有効化されているルール一覧の確認
Get-DrsRule -Cluster $cluster | Format-Table Name, Enabled, KeepTogether

VM-Hostルール(ソフトルール)を作成するスクリプト:

# VMグループおよびホストグループの作成
$vmGroup = New-DrsClusterGroup -Cluster $cluster -Name "VMG-AppServers" -VM (Get-VM -Name "App-01", "App-02")
$hostGroup = New-DrsClusterGroup -Cluster $cluster -Name "HG-Rack01" -VMHost (Get-VMHost -Name "esxi-01.local", "esxi-02.local")

# ソフトルール(ShouldRunOn)の作成
New-DrsRule -Cluster $cluster -Name "Rule-App-To-Rack01" -Type VmHostRule `
    -VMGroup $vmGroup -HostGroup $hostGroup -RuleType "ShouldRunOn" -Enabled $true

DRSルール適用時にシステム停止を招く3つの典型的な落とし穴

  • メンテナンスモード移行タスクが66%で停止する: ESXiホストをメンテナンスモードに移行する際、DRSは稼働中のすべての仮想マシンを別ホストへ退避させます。しかし、当該ホスト上にMust run onルールが適用されたVMが存在し、グループ内の他のホストに十分なRAM/CPUリソースがない場合、メンテナンスタスクは66%の進捗で無期限にハングします。
  • ルール間の競合(Conflicting Rules): 例えば、ルールAでVM-01とVM-02の同居を強制し、ルールBでVM-01とVM-02の同一ホスト配置を禁止した場合などに発生します。競合が発生すると、vCenterは黄色のアラート(Warning)を発行し、対象VMに対するDRSの自動負荷分散機能を完全に無効化します。
  • 「Should」ではなく「Must」ルールを乱用する: CPUライセンスなどの厳格なコンプライアンス要件がない限り、常にShould run onを優先して使用すべきです。Mustを選択することは、ハードウェア障害などの緊急時にvSphere HAによる自動復旧権限を奪うことを意味します。

まとめ

ハードウェアのスペックが高いだけでは、安定したインフラを構築することはできません。最も重要なのは仮想マシンの適切な配置戦略です。わずか5分を割いて重要なVMペアに対してAnti-Affinityルールを設定するだけで、「電源ユニット1台の故障でクラスタサービス全体が共倒れする」という致命的なリスクを完全に排除できます。

Share: