【2026年】Proxmox クラスターHA構成ガイド｜高可用性仮想化基盤

はじめに：高可用性仮想化基盤の必要性

現代の情報システムにおいて、サーバーダウンが許容される時間は極めて短くなっています。2026 年時点では、クラウドネイティブなアプローチに加え、オンプレミス環境でも「高可用性（High Availability: HA）」の確保が必須要件となっています。本記事では、オープンソースの仮想化プラットフォームである Proxmox VE を用いたクラスター HA 構成について、初心者から中級者向けに詳細なガイドを提供します。特に、3 ノード構成における障害耐性とフェイルオーバー能力を最大化する設定方法に焦点を当てています。

2025 年以降のデータセンター環境では、単なる冗長化を超えた「自己修復機能」が求められます。Proxmox VE は、Linux ベースの仮想管理基盤として、コンテナ（LXC）と仮想マシン（KVM）の両方をサポートしており、柔軟な構成が可能です。しかし、クラスタ設定や分散ストレージの構築には専門知識が必要となります。本ガイドでは、具体的なハードウェア選定からネットワーク設計、そして運用監視まで一貫したフローを解説します。

読者が実際に環境を構築する際、トラブルシューティングに必要な基礎知識も併記しています。例えば、Corosync の通信経路が分断された際の「スプリットブレイン」現象の防止や、Ceph ストレージの OS D 構成によるパフォーマンス特性など、実務で直面する課題に対する解決策を提示します。2026 年の最新技術動向を踏まえつつ、安定した運用基盤を構築するための具体的なステップを以下の項目で順を追って解説していきます。

Proxmox VE クラスター HA の基本概念とアーキテクチャ

Proxmox VE（Virtual Environment）におけるクラスター構成は、複数の物理サーバー（ノード）を論理的なグループとして統合し、単一の管理インターフェースから操作可能にする仕組みです。これにより、リソースのプール化が可能となり、特定のノードに負荷が集中するのを防ぎます。HA（High Availability）機能は、あるノードで障害が発生した際に、その上で動作していた仮想マシンを自動的に他の正常なノードへ移行させる機能を指します。2026 年現在の最新バージョンである Proxmox VE 8.x では、このフェイルオーバープロセスの最適化が図られており、ダウンタイムは数秒単位に抑えられています。

クラスター内のノード間通信には Corosync が使用され、パケルメー（Pacemaker）がリソース管理を担当します。Corosync はノード間のクラスタリング情報を同期し、クォラム（過半数のノードが存在すること）を維持するための投票機構を提供します。3 ノード構成の場合、2 つ以上のノードで通信が成立していればクラスターは機能し続けます。ただし、100% の可用性を保証するためには、障害検知メカニズムとフェンシング機能が不可欠です。これらを正しく設定しないと、ネットワークの断絶時にデータ破損やサービス停止を招く可能性があります。

HA 構成における重要な概念として、リソースグループがあります。仮想マシンは単体で管理されるのではなく、依存関係にあるストレージやネットワークリソースと共にグループ化されます。これにより、移行時の順序制御が可能となり、ディスクが接続されない状態で VM が起動するといったエラーを防ぎます。また、優先順位の設定も重要であり、特定のノードをプライマリとして固定したり、コストに基づいて動的に配置変更を行ったりできます。2025 年以降のハイブリッドクラウド環境では、オンプレミス上の Proxmox クラスターがエッジコンピューティングと連携するケースが増加しており、この基本アーキテクチャの理解が基盤となります。

ハードウェア選定と構成例（Minisforum vs 自作 AM5）

高可用性クラスターの構築において、ハードウェアの信頼性は最優先事項です。本ガイドでは、2026 年時点での現実的な選択肢として、商用ミニ PC の活用と、サーバー用途に特化した自作マザーボードの採用を比較します。前者はスペース効率に優れ、後者は拡張性と EEE（ECC）メモリによるデータ整合性で有利です。具体的な構成例として、Minisforum MS-01 を 3 台用意する場合と、AMD Ryzen 9 9950X を搭載した自作サーバーを 3 台構築する場合の性能差を分析します。

Minisforum MS-01 の構成では、Intel Core i9-13900H プロセッサが採用されています。このチップは最大 24 コア（8 パフォーマンスコア + 16 エフィシエンシーコア）を持ち、マルチスレッド処理に強みがあります。メモリは DDR5-4800 を搭載し、標準で 64GB が確保可能です。ストレージには NVMe SSD を 2 台搭載し、RAID 構成やミラーリングが可能です。ネットワークインターフェースとしては、2.5GbE が 2 ポートと 10GbE SFP+ が 1 ポート用意されており、Ceph の高速トラフィック処理に適しています。しかし、消費電力が比較的高く、連続稼働時の発熱対策が必要です。

一方、自作サーバー構成では AMD Ryzen 9 9950X と ASRock Rack X870D4U の組み合わせが推奨されます。Ryzen 9 9950X は Zen 5 アーキテクチャを採用し、2026 年時点でも最強クラスのデスクトップ CPU と見なされています。128GB の ECC DDR5 メモリを搭載することで、メモリエラーによるデータ破損リスクを劇的に低減できます。ストレージには NVMe SSD を 4 台（各 2TB）配置可能で、Ceph の OSD オブジェクトとして活用可能です。ネットワークは SFP+ スロットを複数搭載しており、Ubiquiti のスイッチと連携した高帯域環境が構築しやすくなります。以下の表に、両構成の主要スペックを比較して示します。

上記の比較表からもわかるように、自作サーバーはメモリ容量とストレージ拡張性で優位に立ちます。特に Ceph を使用する場合、OSD の数が多いほどパフォーマンスが向上するため、4 ドライブ構成の方が有利です。また、ECC メモリはデータセンター環境では標準仕様であり、2026 年の最新規格でも必須と考えられています。ただし、スペースと消費電力を重視する場合はミニ PC が有効です。いずれのハードウェアを選んでも、クラスター設計においては「同種機器を揃える」ことが安定稼働の秘訣となります。

ネットワーク設計と物理接続の要点

クラスター HA 構成において、ネットワークは神経系のような役割を果たします。Proxmox クラスター内では、管理トラフィック（Corosync）、仮想マシントラフィック、そしてストレージトラフィック（Ceph）が混在するため、物理的な分離または論理 VLAN の運用が不可欠です。2025 年以降の標準構成では、10GbE SFP+ を使用して Ceph のバックエンドトラフィックを独立させることが推奨されます。これにより、仮想マシンの転送帯域とストレージの同期負荷が干渉せず、全体のレイテンシーを低減できます。

管理ネットワークは、クラスター内のノード間通信や Web UI へのアクセスに使用されます。2.5GbE イーサネットポートで十分なケースが多いですが、安定性を高めるために redundant な構成にします。具体的には、各ノードの 1 つ目の LAN ポートを管理用とし、2 つ目のポートをストレージ用に割り当てます。スイッチには Ubiquiti USW-Enterprise-24-PoE を使用し、すべての 10GbE ポートが SFP+ スロットとして機能するように設定します。このスイッチは PoE（Power over Ethernet）に対応しており、AP や IP カメラとの接続も可能なため、小規模データセンター環境でコスト効率よく運用できます。

ネットワーク構成の具体例を以下に示します。物理的な配線と VLAN 割り当てを明確化することで、トラブル発生時の特定が容易になります。また、MTU（Maximum Transmission Unit）の設定も重要です。Jumbo フレーム（MTU 9000）に対応した NIC とスイッチであれば、Ceph の内部通信で大きなパケットサイズを扱い、CPU オーバーヘッドを削減できます。ただし、すべての機器が Jumbo フレームをサポートしているか確認する必要があります。以下の表に、推奨されるネットワーク割り当ての例を示します。

この構成では、管理トラフィックが Ceph の重負荷の影響を受けずに済み、クラスターの健全性を維持できます。また、物理ループを避けるために Spanning Tree Protocol（STP）を適切に設定することも忘れません。2026 年時点のネットワーク標準では、Rapid STP や Multiple STP が主流ですが、Proxmox のクラスタリング環境では単純な構成ほど安定する傾向があります。特に Corosync は低遅延通信を要求するため、スイッチ側の QoS（Quality of Service）設定で優先度を上げることで、パケットロスによるフェイルオーバー誤作動を防ぎます。

Proxmox VE の基本インストールとクラスタ設定

実際の構築プロセスは、まず各ノードへの OS インストールから始まります。Proxmox VE 8.x の ISO イメージを USB メディアに書き込み、BIOS/UEFI ブート設定で起動します。インストール中、ネットワークインターフェースの IP アドレス、サブネットマスク、ゲートウェイを設定し、DNS サーバーも指定します。この時点では、各ノードを個別のインスタンスとして扱いますが、後でクラスタに統合するために「パブリック IP」ではなく、管理用サブネット内の固定 IP を割り当てます。2025 年以降のインストール手順では、CLI インストーラーが廃止され、Web インターフェースからの設定サポートが強化されています。

3 つ目のノードまでインストールが終わったら、クラスタの作成を行います。これは最初のノード（プライマリ）で行い、残りのノードは加入させる形式です。コマンドラインで pvecm create clustername を実行し、クラスター名を定義します。この際、パスワードを生成し、それを記憶する必要があります。次に、他の 2 つのノードから pvecm add <IP address> を実行してクラスターに参加させます。これにより、Corosync の設定ファイルが自動的に生成され、ノード間の通信パスが確立されます。ただし、この段階ではまだ Ceph や HA リソースは定義されていません。

クラスタ化された後、Web UI にアクセスできることを確認します。通常、https://<IP of first node>:8006 でアクセス可能です。ここで、SSL 証明書の問題が発生することがありますが、2026 年時点では自己署名証明書の警告を無視して進めるか、Let's Encrypt の連携で解決できます。また、クラスタの状態を確認するには pvecm status コマンドを使用し、すべてのノードが「Active」状態にあることを確認します。もしフェイルオーバーが発生した際にも復旧可能なよう、各ノードのシリアルコンソールや IPMI へのアクセス権限も事前に確保しておきます。

Ceph 分散ストレージの実装と管理

HA クラスターの肝となるのが、共有ストレージです。Proxmox では Ceph を標準サポートしており、それぞれのノードにあるローカルディスクを結合して、論理的なプールとして機能させます。Ceph の構成要素には、モニタリング（ceph-mon）、マネージャ（ceph-mgr）、オブジェクトスロージ（OSD）などがあります。2026 年時点では、Ceph Reef または Cuttlefish バージョンが推奨され、RBD（RADOS Block Device）や CephFS のサポートが強化されています。OSD の設定には SSD を使用し、キャッシュ層として NVMe を活用することで、IOPS とスループットのバランスを最適化します。

Ceph の構築手順は、各ノードのディスクをパーティション化し、OSD として登録することから始まります。ceph-deploy osd create コマンドや、Web UI から GUI で設定する形式が利用可能です。例えば、各ノードに 2TB NVMe が 4 枚ある場合、そのすべてのディスクを OSD に割り当てます。Ceph はデータ分散とレプリケーション機能を持っており、3 ノード構成であれば、データのレプリカは 3 つ保持されます。つまり、1 つのノードが故障しても、他の 2 ノードにコピーが残っているためデータ消失を防げます。この設定は「replica=3」として定義され、各オブジェクトの書き込み後に他のノードへ同期されます。

以下の表に、Ceph の構成項目と推奨値を示します。これらを適切に調整することで、ストレージのパフォーマンスを最大化できます。また、Ceph のモニタリング機能により、ディスクの空き容量や I/O 遅延をリアルタイムで確認可能です。2025 年以降は、AI を活用したストレージ最適化ツールも登場していますが、まずは基本設定を固めることが重要です。

Ceph の設定後、Proxmox からそのプールをマウントします。ストレージタイプとして「RBD」を選択し、作成したプール ID を指定します。これにより、仮想マシンやコンテナが Ceph ストレージ上のイメージを直接読み書きできます。ただし、ネットワーク帯域幅がボトルネックになる可能性があるため、管理用とストレージ用を分けた設計（前述の通り）が不可欠です。2026 年の環境では、Ceph のデータ再均衡機能により、ディスク交換時やノード追加時に自動的にデータ移動が行われるようになっています。

HA リソース定義とフェイルオーバー戦略

クラスター内のリソース管理には、HA（高可用性）の概念が深く関わります。HA を有効化するには、プロパティ設定とルール定義が必要です。具体的には、特定の仮想マシンやコンテナを「HA グループ」に登録し、障害発生時の挙動を定義します。これにより、正常なノードへ自動的に移行されます。HA の重要パラメータとして、「優先度（Priority）」があります。これは、フェイルオーバー時にどの VM を優先的に起動するかを示す値です。例えば、重要な DB サーバーには高い優先度を割り当て、テスト環境には低い優先度を設定します。

2026 年時点の HA マネージャー機能では、リソースの依存関係も考慮できます。仮想マシンが Ceph ストレージに依存している場合、ストレージへのアクセス権限が確保された後に VM が起動するよう自動制御されます。また、VM の起動順序を定義することで、アプリケーション階層ごとの順序性を保つことも可能です。例えば、データベースサーバーが仮想マシンの先に立ち上げる必要がある場合、後者の起動は前者の完了を待つようになります。この設定は ha-manager を通じて行われ、CLI コマンドや Web UI の HA タブから設定可能です。

フェイルオーバー戦略には、「手動」と「自動」があります。初期段階では手動確認が安全ですが、完全な HA 環境では自動実行を前提とします。ただし、自動フェイルオーバーはネットワークの断絶時にも発動するため、スプリットブレイン（2 つのクラスターに分裂する状態）への対策が必要です。これにはフェンシング機能が必要となりますが、まずはリソースグループの定義を正しく行うことが先決です。以下の表に、HA リソース設定の例を示します。

この設定により、障害時に DB サーバーが最優先で起動し、システム全体を復旧させます。また、リソースの CPU やメモリ制限を HA グループレベルで定義することで、特定の VM が他の VM のリソースを喰らうのを防ぎます。2025 年以降は、AI を活用したプロビジョニング機能により、負荷状況に応じて動的にリソースを再配分する「ハイパーコンバージド」な動きも期待されていますが、基本的には静的な HA ポリシーが依然として堅牢です。

フェンシング（Fencing）の設定と障害検知の厳密化

フェンシングは、ノードが故障してクラスターから切り離された際、そのノードが「生きている」と勘違いしてデータを書き込もうとするのを防ぐ機能です。これを STONITH（Shoot The Other Node In The Head）と呼びます。2026 年の標準構成では、IPMI や iDRAC、Redfish を利用した電源制御が主流です。つまり、クラスターが「ノード A が障害を起こして通信不能」と判断した場合、物理的な電源をオフにするコマンドを実行します。これにより、データ整合性が保たれ、フェイルオーバー後の再起動も安全に行われます。

具体的な設定では、fence_ipmilan や fence_ssh などのデバイスが使用されます。IPMI を利用する場合、各ノードに IPMI アドレスとユーザー情報を登録します。Proxmox の Web UI から「HA Fencing」セクションで設定可能です。これにより、クラスター内のすべてのノードに対するフェンシングプロファイルが定義されます。もしフェンシングが失敗した場合、HA マネージャーはリソースを停止し、データ破損を防ぎます。ただし、フェンシング機能に依存すると、ネットワークの問題が検知されずに電源オフが誤って発動する「誤作動」のリスクもあります。

障害検知の厳密化には、Corosync の設定ファイル（corosync.conf）を調整します。例えば、ring0delay や link_timeout などのパラメータを調整して、ネットワーク遅延に対する許容範囲を狭めます。これにより、一時的な通信不安定を誤って障害と判定するのを防ぎます。また、ウォッチドッグ（Watchdog）デバイスを各ノードに搭載し、OS のフリーズを検知する仕組みも有効です。2025 年以降のサーバーでは、ハードウェアレベルのウォッチドッグが標準装備されるケースが増えています。以下の表に、フェンシングの設定パラメータをまとめます。

この設定により、ノードが物理的に故障した場合でも、クラスター全体としてのデータ整合性が保たれます。また、バックアップ戦略と連携させることで、フェイルオーバー後のデータ復旧もスムーズに行えます。2026 年の運用においては、このフェンシング機能のログを監視システムに統合し、異常検知を自動化することが推奨されます。

プロキシマックスバックアップサーバーとの連携

HA クラスターを構築しても、バックアップがなければ災害時の復旧は困難です。Proxmox VE では、専用のバックアップサーバーである Proxmox Backup Server（PBS）と連携可能です。PBS をクラスターの外部に配置し、増分バックアップや暗号化をサポートします。2025 年以降の標準運用では、各ノードから PBS へ定期的にデータを送信するタスクを設定します。これにより、仮想マシンの状態が保存され、フェイルオーバー先のノードでもすぐに復旧可能です。

PBS の設定は、クラスター内の各ノードでバックアップリポジトリを指定することで行います。ネットワーク接続は高速であることが必須です。例えば、10GbE ネットワークを使用して PBS サーバーと接続します。バックアップの頻度は、「毎日」または「毎時間」に設定可能です。また、増分バックアップ機能により、変更されたブロックのみが転送されるため、帯域幅の使用量が大幅に削減されます。2026 年時点では、AES-256 暗号化によるデータ保護も標準オプションとなっています。

以下の表に、PBS との連携設定の例を示します。これを実行することで、クラスター全体を安全にバックアップできます。また、バックアップの保存期間（リテンション）を設定し、古いデータを自動削除してストレージ容量を確保します。

この連携により、クラスターが物理的に破壊された場合でも、PBS からデータを復元してシステムを再起動できます。また、PBS は Proxmox VE の Web UI から直接管理できるため、運用負荷も低減されます。2026 年の運用標準では、バックアップの検証機能も強化されており、定期的なリストアテストが推奨されています。

よくある質問（FAQ）

Q1. クラスターを構成する際、3 ノード以外でも可能ですか？ A1. はい、可能です。しかし、クォラム（過半数投票権）の観点から奇数ノードが推奨されます。2 ノードでは、ネットワーク断絶時にスプリットブレインが発生しやすく、データ破損リスクが高まります。そのため、安定運用のためには 3 ノード以上を標準としてください。

Q2. Ceph のパフォーマンス低下を防ぐ方法はありますか？ A2. まず、OSD に SSD または NVMe を使用してください。HDD はキャッシュ用途に限ります。また、ネットワーク帯域幅の確保と MTU の設定（Jumbo フレーム）が重要です。さらに、Ceph の CRUSH マップを最適化し、データの分散バランスを調整することで I/O 負荷を均等化できます。

Q3. フェンシング機能は必須ですか？ A3. 高い可用性を求める環境では必須です。フェンシングがない場合、ノードが故障していても他のノードからデータを書き込もうとして破損する可能性があります。ただし、初期テスト段階では無効にして動作確認を行うことを推奨します。

Q4. ハードウェアの組み合わせは統一するべきですか？ A4. 基本は統一すべきです。異なる CPU やメモリ構成のノードを混ぜると、HA の実行時にリソース不足や互換性エラーが発生する可能性があります。特に ECC メモリの有無は重要であり、同一クラスター内では統一してください。

Q5. 2026 年以降の OS は何を選ぶべきですか？ A5. Proxmox VE は Debian ベースです。最新バージョンである 8.x を使用し、定期的なセキュリティアップデートを適用します。Debian のサポート期間が切れた場合でも、Proxmox のパッケージ更新で対応可能です。

Q6. バックアップの保存期間はどう設定すればよいですか？ A6. 重要なデータは「7 日間」または「30 日間」に設定し、ローテーションルールを適用します。また、オフラインストレージへのエクスポートも検討してください。2025 年以降は、クラウドストレージとの連携オプションも提供されています。

Q7. クラスターの管理 UI はどれを使いますか？ A7. Web ブラウザからアクセスする標準の Web UI が推奨されます。CLI コマンドは高度な設定に使用しますが、日常運用では GUI で十分です。HTTPS 接続が必須であり、SSL 証明書の有効性も確認してください。

Q8. ノードを 1 つ増やすことはできますか？ A8. はい、可能です。ただし、クラスターメンバーとして参加させる必要があります。Ceph のリバランス処理が行われるため、時間がかかる場合があります。また、新しいノードの性能が既存ノードと同等であることを確認してください。

まとめ

本記事では、2026 年時点での最新技術を反映させた Proxmox クラスターの HA 構成ガイドを提供しました。読み進めることで、以下の重要なポイントが明確になったはずです。

• ハードウェア選定: Minisforum MS-01 と自作 AM5 サーバーを比較し、ECC メモリと拡張性の重要性を確認しました。
• ネットワーク設計: 管理トラフィックとストレージトラフィックの分離、および Jumbo フレームの活用がパフォーマンス向上に寄与します。
• Ceph ストレージ: OSD の構成と CRUSH マップの設定により、高可用性で高速な分散ファイルシステムを構築できます。
• HA リソース管理: 優先度設定と依存関係定義により、障害時の適切な起動順序を保証します。
• フェンシング機能: STONITH を使用することで、データ破損を防ぎ、システムの完全性を維持します。
• バックアップ戦略: Proxmox Backup Server との連携により、災害復旧能力を高めることができます。

2025 年以降の情報システム運用において、これらの要素は不可欠です。各項目を慎重に設定し、定期的なテストと監視を行うことで、安定した高可用性基盤を実現してください。本ガイドが、読者のサーバー構築プロジェクトの成功の一助となることを願っています。