Proxmox HA クラスタの構築と運用: 可用性を最大化する

ミッションクリティカルなワークロードを運用する上で、単一障害点の排除は最優先事項です。Proxmox VE は、組み込みの HA（High Availability）機能により、ノード障害時にも VM やコンテナを自動的に別ノードへフェイルオーバーさせ、サービスのダウンタイムを最小限に抑えます。本記事では、Proxmox HA クラスタの構築から運用までを詳細に解説します。

Kubernetes ワークロードの高可用性を求めるなら、Kubo On-Premise が最適です。Proxmox HA とフルマネージド K8s を組み合わせることで、インフラからアプリケーションまで一貫した可用性を実現できます。

HA クラスタの前提条件

Proxmox 公式 HA ドキュメントに基づき、以下の前提条件を満たす必要があります。

ハードウェア要件

• 最低 3 ノード: クォーラム（多数決）メカニズムに必要。2 ノード構成は Corosync QDevice で補完可能
• 共有ストレージ: 全ノードからアクセス可能なストレージ（Ceph、NFS、iSCSI、FC）
• 冗長ネットワーク: Corosync 通信用の専用ネットワーク（10 GbE 推奨）
• OOBM（Out-of-Band Management）: IPMI、Dell iDRAC、HPE iLO 等のリモート管理インターフェース
• ハードウェア Watchdog: iTCO_wdt（Intel）などのハードウェアタイマー

クラスタの構築

Proxmox クラスタの作成

最初のノードでクラスタを作成し、他のノードを順次参加させます:

# ノード 1 でクラスタを作成
pvecm create my-ha-cluster

# ノード 2, 3 をクラスタに参加させる（各ノードで実行）
pvecm add 192.168.1.10  # ノード 1 の IP

# クラスタの状態確認
pvecm status

Corosync ネットワークの設定

Corosync はクラスタの心臓部であり、ノード間の通信と状態同期を担います。信頼性の高い低遅延ネットワークが不可欠です。パケットロスや高ジッターは、ノードの誤排除やクラスタの不安定化を招きます。

専用のボンディングリンクを Corosync に割り当てることが強く推奨されます:

# Corosync の設定確認
cat /etc/pve/corosync.conf

# ネットワークインターフェースの冗長化（ボンディング）
# /etc/network/interfaces に追加
auto bond0
iface bond0 inet static
    address 10.10.10.1/24
    bond-slaves eno3 eno4
    bond-mode 802.3ad
    bond-miimon 100

Corosync のリンク設定は Web UI の Datacenter → Cluster から管理できます。本番環境では必ず 2 つ以上のリンク（リング）を設定し、単一障害点を排除してください。

共有ストレージの設定

HA リソースは全ノードからアクセス可能な共有ストレージ上に配置する必要があります。Ceph はハイパーコンバージド構成で最も推奨されるオプションです:

# Ceph のインストール（各ノードで実行）
pveceph install

# モニターの作成（各ノードで実行）
pveceph mon create

# OSD の追加
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# Ceph プールの作成
pveceph pool create vm-pool

Kubo では、このような分散ストレージの複雑な設定を自動化し、Kubernetes 向けに最適化された永続ボリュームを提供します。

フェンシングの設定

フェンシングは HA クラスタの最も重要な安全機構です。フェンシングは、障害を起こしたノードが共有ストレージに書き込みを続ける「スプリットブレイン」シナリオを防止します。応答しなくなったノードが実際にはまだ動作しており、共有ディスクに書き込んでいる状態で別のノードが同じ VM を起動すると、データ破損が発生します。

Watchdog の設定

ハードウェア Watchdog は定期的なタイマーリセットが行われない場合にノードを自動リブートします:

# Watchdog モジュールの設定
# /etc/default/pve-ha-manager
WATCHDOG_MODULE=iTCO_wdt

# Watchdog の動作確認
wdctl

# Watchdog が利用できない場合は softdog にフォールバック
modprobe softdog

IPMI フェンシング

IPMI ベースのフェンシングは、ネットワーク経由でノードの電源を強制的にオフにできます:

# IPMI 経由でノードの電源状態を確認
ipmitool -I lanplus -H 192.168.1.200 -U admin -P password chassis power status

# 強制電源オフ
ipmitool -I lanplus -H 192.168.1.200 -U admin -P password chassis power off

重要: OOBM（帯域外管理）は HA クラスタでは贅沢品ではなく、信頼性の高いフェンシングのための必須要件です。

HA リソースの管理

HA の有効化

VM やコンテナを HA 管理下に置きます:

# VM 100 を HA に登録
ha-manager add vm:100 --state started --max-restart 2 --max-relocate 2

# HA リソースの一覧確認
ha-manager status

# HA リソースの設定変更
ha-manager set vm:100 --group prefer-node1

ノードアフィニティルール

Proxmox VE 9.0 以降、ノードアフィニティルールが HA グループに代わる推奨設定となっています:

• ノードアフィニティ: リソースを特定のノードに優先配置
• リソースアフィニティ: リソース同士を同一ノード（正）または別ノード（負）に配置
• Strict モード: 対象ノードが利用不可の場合、停止中のリソースを起動しない

フェイルオーバーポリシー

リソースには復旧戦略を設定できます:

メンテナンスと監視

メンテナンスモード

ノードのメンテナンス時は、HA サービスを安全に移行してから作業します:

# メンテナンスモードの有効化
ha-manager crm-command node-maintenance enable pve-node1

# ノード上のすべての HA サービスが移行されるまで待機
# 移行完了後にメンテナンス作業を実施

# メンテナンスモードの解除
ha-manager crm-command node-maintenance disable pve-node1

ローリングアップデート

クラスタのアップデートは1 ノードずつ順番に実施します。全ノードを同時にアップデートすることは絶対に避けてください:

1. ノードをメンテナンスモードに設定
2. HA サービスの移行を確認
3. apt update && apt full-upgrade -y を実行
4. 再起動し、クラスタへの復帰を確認
5. 次のノードに移る

フェイルオーバーテスト

本番運用前に必ずフェイルオーバーテストを実施してください:

# シミュレーターでテスト
apt install pve-ha-simulator
pve-ha-simulator

# 手動フェイルオーバー（VM を別ノードに移行）
ha-manager migrate vm:100 pve-node2

# HA 状態の監視
ha-manager status

Proxmox フォーラムでは、HA 構成のベストプラクティスに関する活発な議論が行われています。

まとめ

Proxmox HA クラスタは、適切な設計と構成により、エンタープライズグレードの可用性を実現します。Corosync の冗長ネットワーク、フェンシングによる安全なノード隔離、共有ストレージの信頼性確保が鍵となります。

Kubernetes ワークロードの HA を含めた統合的なインフラ管理には、Kubo On-Premise をご検討ください。Proxmox HA の上にフルマネージド K8s を展開し、ノード障害時も Kubernetes ワークロードの自動復旧を保証します。

HA クラスタの設計・構築に関するご相談は、お問い合わせからお気軽にご連絡ください。

関連リンク:

• Proxmox HA 公式ドキュメント
• Proxmox クラスタマネージャー
• Ceph ハイパーコンバージドガイド
• Corosync プロジェクト
• Proxmox フォーラム
• Kubo ブログ