2ノード構成の問題点：なぜ仲裁役が必要なのか
多くの人は、高可用性（HA）クラスターを構築するには、少なくとも3台の高価なサーバーが必要だと考えがちです。技術的には正しいのですが、予算面では厳しいのが現実です。この要件は「クォーラム（定足数）」、つまりクラスターが意思決定を行うために必要な最小投票数に起因します。標準的なProxmoxの設定では、各ノードが1票を持ちます。
2ノード構成で1台のノードがオフラインになると、生き残ったノードは50%の票しか保持できません。Proxmoxは厳格な過半数（>50%）を必要とするため、生き残ったノードはクォーラムを失います。その結果、すべての仮想マシンをフリーズさせ、HAサービスを停止します。この安全策は、両方のノードが同じストレージに書き込みを行ってデータを破損させる「スプリットブレイン」シナリオを防ぐためのものです。
この問題は、3台目のフルサイズサーバーを購入しなくても解決できます。クォーラムデバイス（QDevice）が、軽量な仲裁役（タイブレーカー）として機能します。私はこのセットアップをラボで6ヶ月以上運用していますが、3回の停電と2回の計画的なカーネルアップデートを、1分もダウンタイムを出すことなく乗り越えています。
前提条件と環境のセットアップ
Raspberry Piに高い処理能力は必要ありません。古いRaspberry Pi 3Bや、15ドルのRaspberry Pi Zero 2 Wでも十分です。投票のために、わずか64バイトの小さなネットワークパケットを処理するだけだからです。開始する前に、以下が準備されていることを確認してください。
- 稼働中の2ノードProxmox VEクラスター（例：
pve-01とpve-02） - Raspberry Pi OSまたはDebianがクリーンインストールされたRaspberry Pi
- 接続断を防ぐための、すべてのデバイスへの固定IPアドレスの割り当て
- rootまたはsudo権限を持つSSHアクセス
この構成では、Piはcorosync-qnetdサーバーを実行します。一方、Proxmoxノードは、Piと通信するためのcorosync-qdeviceエージェントを実行します。
ステップ1：Raspberry Piの準備（QNetdサーバー）
Raspberry Piはcorosync-qnetdデーモンをホストします。このサービスはバックグラウンドで待機し、Proxmoxノードからの投票要求に応答します。通常時のPiのCPU使用率は1%未満です。
Piにログインし、パッケージリストを更新します。
sudo apt update
sudo apt install corosync-qnetd -yサービスが正しく動作しているか確認します：
systemctl status corosync-qnetdこれでPi側の準備は完了です。設定ファイルを編集する必要はありません。Proxmoxノード側からハンドシェイクを行う際に、必要な処理が自動的に行われます。
ステップ2：Proxmoxノードの準備
次に、Proxmoxノード側の作業に移ります。pve-01とpve-02の両方にエージェントをインストールする必要があります。このパッケージにより、サーバーがPiの投票サービスと通信できるようになります。
両方のProxmoxサーバーで以下のコマンドを実行します：
apt update
apt install corosync-qdevice -yここで重要なのはバージョンの整合性です。Piが非常に古いバージョンのDebianを実行している場合、SSHハンドシェイクに失敗することがあります。最善の結果を得るには、Debian 11や12などのモダンなバージョンを使用してください。
ステップ3：QDeviceリンクの設定
ここからが本番です。このコマンドは、いずれか1台のProxmoxノードから実行するだけで済みます。設定は自動的にクラスター内の他のノードへ同期されます。
pve-01からセットアップコマンドを実行します。IPアドレスはRaspberry Piのものに置き換えてください：
pvecm qdevice setup 192.168.1.50バックグラウンドでは以下の処理が行われています：
- ノードがネットワーク経由でPiに到達可能か確認します。
- セキュアなSSH証明書を交換するため、Piのrootパスワードを求められます。
- クラスター設定を更新し、Piを投票メンバーとして追加します。
- クラスター全体のCorosyncサービスを再起動します。
もし「SSH host key verification」エラーが出ても、慌てる必要はありません。Proxmoxのターミナルから一度手動でPiにSSH接続してキーを受け入れ、その後にもう一度試してください。
検証：計算が合っているか確認する
クラスターが3つの票を認識しているか確認しましょう。任意のProxmoxノードで以下を実行します：
pvecm statusQuorum informationセクションを確認してください。出力は以下のようになっているはずです：
Quorum information (クォーラム情報)
------------------
Nodes (ノード数): 2
Quorum (クォーラム数): 2
Votes (現在の票数): 3
Total votes (総投票数): 3Total votesに注目してください。サーバーは2台しかありませんが、票数は3票になっています。もしpve-02がダウンしても、pve-01は3票中2票（66%）を保持し続けます。66%は過半数であるため、仮想マシンは稼働を続けます。
長期安定運用のための教訓
QDeviceの運用は基本的に「設定したらあとは放置」で済みますが、いくつかの落とし穴を避ける必要があります。半年間の本番運用で学んだことを共有します。
1. 有線LAN（Ethernet）は必須
QDeviceに Wi-Fiを使用してはいけません。試してみたことがありますが、電子レンジを使うたびにレイテンシが急上昇しました。このスパイクにより、クラスターはPiが消失したと誤認してしまいます。安定した投票には、1〜2msのレイテンシを維持できる安価なLANケーブルが不可欠です。
2. 独立した電源の確保
PiをProxmoxサーバーのUSBポートから給電しないでください。そのサーバーが再起動すると、Piも一緒に再起動してしまいます。すると同時に2票を失うことになり、クラスター全体がクラッシュします。専用の電源アダプターか、UPSに接続されたPoEハットを使用してください。
3. メンテナンスは安全
両方のProxmoxノードが正常であれば、いつでもRaspberry Piをアップデートしたり再起動したりできます。クラスターは一時的に3票中2票の状態になりますが、2票あれば過半数なので、仮想マシンは影響を受けません。
4. ストレージを忘れずに
QDeviceは「投票」の問題を解決するだけで、データを魔法のように同期させるわけではありません。仮想マシンをノード間で即座に移動させるには、NAS（NFS/iSCSI）などの共有ストレージや、複製されたZFSプールが依然として必要です。QDeviceはあくまで、その移動をいつ行うべきかを判断する「脳」を提供するものです。
Raspberry Pi QDeviceは、基本的なホームラボを堅牢な環境に変えるための最もコスト効率の高い方法です。スプリットブレインの不安を取り除き、夜も安心して眠れるようになります。
