Posted inVMware

vCenter Server High Availability（vCenter HA）の設定：vSphere環境のSingle Point of Failureを排除する

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

デモ中にvCenterがダウンし、データセンター全体の集中管理が45分間失われた経験から、二度と同じ状況を繰り返さないと決意しました。vCenter HAは、インシデントが発生してからではなく、最初から設定すべきものでした。

この記事は、VCSA 8.0.2を使った本番環境でのvCenter HA導入経験をもとに書いています。6ヶ月の実運用を経て—夜中の2時に予期せぬフェイルオーバーが発生したケースも含めて—得た知見をまとめました。

クイックスタート — 5分でvCenter HAを有効化する

理論に入る前に、まずお使いの環境が要件を満たしているか確認する最速の方法を紹介します。

前提条件の確認

  • vCenter Server Appliance（VCSA）6.5以降 — Windows版vCenterは非対応
  • vSphere Enterprise PlusまたはvSphere+ライセンス
  • HAの3ノードを別々のホストに分散させるため、最低3台のESXiホストが必要
  • 管理ネットワークとは分離した、HA専用のIPレンジ

設定手順（簡易版）

  1. vSphere Clientにログイン → インベントリからvCenter Serverをクリック
  2. Configure → vCenter HA に移動
  3. Set Up vCenter HA をクリック
  4. Basic を選択 — ウィザードがPassiveノードとWitnessノードを自動作成
  5. HAネットワーク、PassiveノードおよびWitnessノードのIPを入力
  6. Finish をクリック — クローンと同期に約30〜45分かかります

基本的なセットアップはこれで完了です。ただし、内部で何が起きているのか、そしてなぜ本番投入前にフェイルオーバーテストを行うべきなのかを理解したい方は、読み続けてください。

vCenter HAのアーキテクチャ

vCenter HAは、既存のVCSAから3ノードのクラスターを構成します：

  • Activeノード：現行のVCSA。vSphere管理の全ワークロードを処理
  • Passiveノード：Activeのクローン。HAネットワーク経由でリアルタイムにデータストリームを受信し、常に切り替え可能な状態を維持
  • Witnessノード：軽量な「仲裁者」ノード（2 vCPU、8GB RAM）。スプリットブレイン発生時のタイブレーク専用

Activeに障害が発生すると、Passiveが自動的に新しいActiveに昇格します—通常4〜8分以内で、手動操作は不要です。vCenterのVIP（仮想IP）がPassiveに切り替わり、すべてのクライアントは通常通り再接続できます。

HAネットワーク — 最も見落とされがちなポイント

多くの方が間違える部分がネットワーク設定です。vCenter HAには2つの独立したネットワークが必要です：

  • 管理ネットワーク：既存の通常ネットワーク
  • HAネットワーク：レプリケーションとハートビート専用の専用ネットワーク — 高帯域、低遅延が必要

同じネットワークを共有してもVCHAは動作しますが、障害検知が遅くなり、管理ネットワークが混雑するとレプリケーションに影響が出る可能性があります。分離することで、はるかに安定した動作が得られます。

3ノードのリソース割り当て

ActiveとPassiveはクローンのため同じスペックになります。Witnessははるかに軽量です：

# Witnessノードのデフォルトスペック
vCPU: 2
RAM: 8 GB
Disk: ~10 GB (メタデータのみ保存、実データは保存しない)

推奨構成として、3ノードをそれぞれ異なる物理ESXiホストに配置し、理想的には異なるラックまたは独立した電源系統に分散させることをお勧めします。クラスター全体が同じラックにあり、そのラックで停電が発生した場合、HAでも対処できません。

高度な設定

Advancedモード：ノード配置を手動で制御する

Basicの代わりにAdvancedを選択すべきケース：

  • PassiveとWitnessを特定のホストに手動で指定する場合（DRSによる自動移動を防ぐため）
  • ノードごとに異なるデータストアを使用する場合
  • 組織の既存サブネットに合わせてIPを手動設定する場合

APIでVCHAの状態を確認する

# セッショントークンを取得
SESSION=$(curl -sk -X POST \
  -u [email protected]:YourPassword \
  https://vcenter.lab.local/api/session \
  -H "Content-Type: application/json" | tr -d '"')

# VCHAクラスターのヘルス状態を確認
curl -sk \
  https://vcenter.lab.local/api/vcenter/vcha/cluster \
  -H "vmware-api-session-id: $SESSION" | python3 -m json.tool

出力には現在のモード（ENABLED/DISABLED/MAINTENANCE）、ActiveノードのIP、ヘルス状態が含まれます。クラスターがHEALTHY状態でない場合にアラートを発報するよう、Nagiosと連携しています。

能動的なフェイルオーバーテスト — 本番投入前に必須

セットアップ完了後、引き渡し前に必ず実施するステップです：

# vSphere ClientからフェイルオーバーをトリガーUTF-8する手順：
# Configure → vCenter HA → Initiate Failover

# またはActiveノード上のVCHA CLI経由（VCSAにSSHで接続）
/usr/lib/vmware-vcha/bin/vcha-vmafd-util --mode FAILOVER

初めてテストした際、PassiveとWitness間でポート8182がファイアウォールにブロックされていることが発覚しました。これはセットアップ時ではなく、実際にフェイルオーバーをトリガーしたときにのみ現れる問題です。事前にテストしていなければ、最も必要なタイミングで発見することになっていたでしょう。

6ヶ月の本番運用から得た実践的なヒント

1. VCHAヘルスの自動監視スクリプト

#!/bin/bash
# VCHAヘルスを監視するため、cronで5分ごとに実行
VCENTER="vcenter.lab.local"
SESSION=$(curl -sk -X POST -u admin:pass \
  https://$VCENTER/api/session \
  -H "Content-Type: application/json" | tr -d '"')

STATUS=$(curl -sk \
  https://$VCENTER/api/vcenter/vcha/cluster \
  -H "vmware-api-session-id: $SESSION" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('health_state','UNKNOWN'))")

if [ "$STATUS" != "HEALTHY" ]; then
  echo "ALERT: vCenter HA status is $STATUS" | \
    mail -s "[CRITICAL] vCHA Alert" [email protected]
fi

2. 正しいアップデート手順

vCenterにパッチを適用する際は、手順を正確に守ってください。順序を誤ると、数時間のリストア作業が必要になります：

  1. Configure → vCenter HA → Enter Maintenance Mode に移動
  2. VAMI経由でActiveノードをアップデート（https://vcenter:5480）
  3. アップデート後に正常動作することを確認
  4. Maintenance Modeを終了 — VCHAが自動的にPassiveを同期

ENABLEDモードのままアップデートしてVCSAが途中でリスタートすると、スプリットブレインが発生するリスクがあります。実際にこのケースに遭遇し、クラスター状態の復旧に2時間を要しました。

3. HAネットワークの実際の帯域使用量

約200台のVMがある環境では、レプリケーショントラフィックはアイドル時に50〜100 Mbps程度で、大量のVM一括デプロイや同時vMotionなど大きな変更後は300〜400 Mbpsまで急増することがあります。HAネットワークは最低1 Gbps、大規模環境では10 Gbpsを確保することをお勧めします。

4. VCSAバックアップは並行して必要

vCenter HAはホスト障害から保護しますが、バックアップの代替にはなりません。VCSAのデータベースが破損した場合、リアルタイム同期しているためActiveもPassiveも同様に破損します。定期バックアップのスケジュール設定は引き続き必要です：

# VCSA VAMIからバックアップを設定
https://vcenter.lab.local:5480
# → Backup → Schedule Backup
# 対応プロトコル: FTP, FTPS, HTTP, HTTPS, SCP

5. 個人ラボをProxmoxに移行した際の比較

ライセンスコスト削減のためVMwareからProxmoxへ個人ラボを移行した際、興味深い気づきがありました。ProxmoxはハイパーバイザーレイヤーでCluster Quorum（Corosync）を使用していますが、管理レイヤーであるProxmox VE Manager自体は、独自にHAを構成しない限りSingle Point of Failureのままです。この比較を通じて、VMwareが管理レイヤーのHAを標準で統合している理由が明確にわかりました。vCenterが30分でもダウンすることをSLAが許容しないエンタープライズ環境では、それが真に必要なものだからです。

vCenter HAが不要なケース

すべての環境に必要なわけではありません：

  • SLAの定めがない小規模ラボや開発・テスト環境
  • ESXiホストが1〜2台しかなく、3ノードを安全に分散できない場合
  • Enterprise Plusライセンスの予算が確保できない場合

そのような場合は、許容できるRTOを持つ完全なVCSAバックアップ—バックアップからのリストアに1〜2時間—が現実的な解決策です。ただし、SLA 99.9%以上のデータセンターを運用しているなら、vCenter HAはインシデント発生後ではなく、最初から投資すべきものです。

Share:
Tags: