Proxmoxを2台でクラスタ化する：VMマイグレーションでパッチ適用を楽にする

投稿日 2026-06-13 編集日 2026-06-15

この記事で実現すること

今回の記事では、2台のProxmoxノードでクラスタを構成します。

Proxmoxは1台構成でも十分に利用できます。しかし、ファイアウォール、認証サーバー、監視サーバーなど、自宅の基盤となるVMを動かすようになると、ホストOSのパッチ適用や再起動のたびにサービスを止めることが課題になります。

そこで今回は、2台のProxmoxノードをクラスタ化し、VMマイグレーションとZFSレプリケーションを使える状態にします。

ただし、2台構成にはquorumの課題があります。片方のノードが停止した場合や、ノード間の通信が切断された場合、残った1台だけではクラスタとして正常に判断できない場面が出てきます。

そのため、最終的にはqdeviceを追加して、2台構成の弱点を補う予定です。qdeviceは後から追加できるため、今回はまず2台クラスタを作成し、VMマイグレーションとZFSレプリケーションを使ったメンテナンス性の向上を目指します。

今回の構成

名称	pve1	pve2	quory
役割	メインノード	セカンダリノード	監視 / QDevice予定 / automation
CPU	AMD Ryzen 9 7900 (12C/24T)	AMD Ryzen 5 5600G (6C/12T)	軽量構成
メモリ	64GB DDR5-4800	48GB DDR4-3200	軽量構成
ストレージ	NVMe 2TB ×2（ZFS mirror）	NVMe 1TB（ZFS single）	OS用
NIC	Intel X710 10GbE ×4	Intel X710 10GbE ×4	1GbE
OS	Debian 13 + Proxmox VE 9.1.9	Debian 13 + Proxmox VE 9.1.9	Ubuntu Server 26.04

※今回の記事ではqdeviceの概要だけ触れ、具体的なセットアップ手順は次回の記事で扱います。
※名称は私が名付けたホスト名です。特に記載する必要もありませんが文中で引用する時にわかりやすくするためですのでご理解ください。

クラスタ構成では、できればCPUの種類は同じメーカーで揃えておいた方が安全です。完全に同じハードウェア構成にできれば理想ですが、家庭内のホームラボでは必ずしもそうはいきません。

今回の構成でも、pve1はRyzen 9 7900、pve2はRyzen 5 5600Gで、世代も性能も異なります。そのため、VMのCPU設定では互換性を意識する必要があります。

ネットワークについては、VMマイグレーションや将来的なフェイルオーバーを考えると、各ノードで同じ構成にしておくべきです。構成が揃っていれば、VMが別ノードへ移動した場合でも、どのネットワークを利用すべきかが明確になります。

Proxmoxクラスタで何が良くなるのか

Proxmoxをクラスタ化して一番ありがたいのは、パッチ適用やハードウェアメンテナンスが楽になることです。

1台構成の場合、ホストOSを再起動すると、その上で動いているVMもまとめて停止します。検証用のVMだけであれば大きな問題にならないかもしれませんが、ファイアウォール、Wi-Fi認証、監視サーバーなどを動かしている場合、ホスト再起動の影響は大きくなります。

クラスタ構成にしておけば、VMをもう1台のProxmoxノードへマイグレーションしてから、片方ずつメンテナンスできます。これにより、ホストをリブートしてもサービス影響をかなり小さくできます。

私の場合、主な対象はFirewall、Wi-Fi認証（WPA3 Enterprise）、ネットワーク基盤の監視です。これらは自宅環境であっても、停止すると家族のインターネット利用や検証環境に影響します。

また、Proxmoxでは比較的頻繁にアップデートが行われます。多くのホームユーザーはEnterprise Repositoryではなく、No-Subscription Repositoryを利用していると思います。この構成では、アップデート内容を確認しながら、まず片方のノードに適用し、問題がなければもう片方にも適用する、という段階的な運用ができます。

仮に最初の1台で問題が出たとしても、VMをもう片方のノードへ退避していれば、サービス影響を抑えながら復旧作業ができます。もちろん、VMバックアップやZFSレプリケーションが正常に取れていることが前提です。

クラスタ化は、障害時の自動復旧だけのために行うものではありません。日常的なパッチ適用やメンテナンスを安全に進めるためにも、大きな意味があります。

1台構成、2台構成、2台＋qdevice、3台構成の比較

Proxmoxは1台構成でも十分に利用できます。特に、動かすVMが少ない場合や、多少のダウンタイムが許容できる環境であれば、無理にクラスタ化する必要はありません。

一方で、ファイアウォール、認証サーバー、監視サーバーなど、停止すると困るVMが増えてくると、ホストOSのパッチ適用やハードウェアメンテナンスのたびに影響が大きくなります。

ここでは、1台構成、2台構成、2台＋qdevice、3台構成をざっくり比較します。

構成	メリット	デメリット	向いている環境
1台構成	構成がシンプル。ハードウェアリソースが少なくて済む。管理が簡単。	ホスト停止時は、その上のVMもすべて停止する。パッチ適用や再起動のたびにサービス停止が発生する。	検証用途、動かすVMが少ない環境、ダウンタイムを許容できる環境
2台構成	VMを別ノードへマイグレーションできる。片方ずつパッチ適用しやすい。ハードウェア障害時の復旧選択肢が増える。	2ノードだけではquorumの課題が残る。片方のノード停止時や通信断時に、クラスタとしての判断が難しくなる場合がある。	ホームラボ、小規模環境、まずクラスタ化とVMマイグレーションを使いたい環境
2台＋qdevice	2台構成の運用しやすさを維持しつつ、qdeviceによりquorumの安定性を高められる。3台目のProxmoxノードを用意しなくてもよい。	qdevice用の軽量な外部サーバーが必要。qdeviceはバックアップやストレージ冗長化ではない。	ホームラボの実用構成、小規模ながら安定性を高めたい環境
3台構成	quorum構成として自然。複数VMを3台に分散配置しやすい。ノード障害時の余力を確保しやすい。	ハードウェアコスト、消費電力、設置場所、管理対象が増える。家庭内ではやや過剰になりやすい。	多数のVMを動かす環境、本格的な検証基盤、より高い可用性を求める環境

なぜ2台＋qdeviceを選んだのか

私の環境では、まず2台構成でクラスタを作成し、VMマイグレーションとZFSレプリケーションを使える状態にします。

この段階でも、パッチ適用時にVMを別ノードへ移動してから片方ずつメンテナンスできるため、1台構成よりかなり運用しやすくなります。

メインとなるpve1はSSDを二重化するなど、単体での故障対策も行っています。ただし、ホスト自体が停止した場合、qdeviceやHAを構成していなければ、VMが自動的にもう片方のノードで起動するわけではありません。

ZFSレプリケーションにより復旧の選択肢は増えますが、2台構成のままではquorumの課題が残ります。そのため、最終的にはqdeviceを追加し、2ノードクラスタの安定性を高める方針です。

3台構成は理想的ではありますが、家庭内ホームラボでは電力、設置場所、コスト、管理負荷が大きくなります。多数のVMを3台に分散して動かすような環境であれば有効ですが、私の用途では、2台＋qdeviceが現実的な落としどころだと考えています。

qdeviceとは何か：今回は概要のみ

qdeviceは、2ノードクラスタにおける投票を補助するための仕組みです。
Proxmoxノードをもう1台追加するのではなく、外部の軽量なサーバーを投票用の第三者として使います。

これにより、2台構成でもquorumを維持しやすくなります。ただし、qdeviceはVMを動かすサーバーではありません。バックアップでもなく、ストレージ冗長化でもありません。ストレージもネットワーク帯域も殆ど使いません。

常にpve1,pve2とポーリングを行い、どちらがダウンしたのか、どちらでサービス提供が行えるのかを判定するためのリソースです。

今回はqdeviceの概要だけ触れ、具体的なセットアップは次回の記事で扱います。

管理系とデータ転送系を分ける理由

私のProxmoxにおけるネットワーク構成は以下の通りです。

ブリッジ構成

Bridge	用途	物理NIC
vmbr0	管理 / corosync	nic0
vmbr1	Family / VLAN trunk	nic1
vmbr2	Server	nic2
vmbr3	WAN	nic3

VLAN / セグメント設計

Name	用途
Default	管理LAN / Proxmox / corosync
WAN	インターネット接続
Family	家庭内メインネットワーク
Server	NAS / Replication / Migration
Edge	IoT / プリンター
Guest	ゲストネットワーク

ネットワーク構成は環境によって大きく変わるため、上記はあくまで私の構成例です。

私の環境では、pve1 / pve2ともに4ポートのNICであるIntel X710を利用しています。たとえば2ポートのNICであれば、LAN用とWAN用で分ける構成もありますし、LAN側を家族向けネットワークとゲスト向けネットワークで分けるような考え方もあります。

Proxmoxのクラスタ構成では、クラスタノード間で定期的に通信が行われます。このクラスタ間通信を担っているのがcorosyncです。

corosyncの通信量自体は大きくありません。しかし、クラスタの状態判断に関わる重要な通信です。そのため、大量のデータ転送が発生する通信とは分けておいた方が安全です。

特にVMマイグレーションやZFSレプリケーションでは、ノード間で大きなデータ転送が発生します。VMマイグレーションでは稼働中VMのメモリ転送が発生しますし、構成によってはディスクデータの転送も発生します。ZFSレプリケーションでは、VMディスクの差分データがノード間で転送されます。

このような通信をcorosyncと同じネットワークに流すと、マイグレーションやレプリケーションの負荷が高いタイミングで、クラスタ間通信にも影響を与える可能性があります。

そのため、私の環境では以下のように役割を分けています。

ネットワーク	主な用途
Default	Proxmox管理画面 / 管理SSH / corosync
Server	NASバックアップ / ZFSレプリケーション / VMマイグレーション

この構成により、管理系の通信と、大量データ転送が発生する通信を分離できます。

完全にすべての通信が分離されるわけではありませんが、少なくともバックアップ、レプリケーション、マイグレーションの主なデータ転送をServerセグメント側に寄せることで、クラスタ管理系の通信に与える影響を小さくできます。

クラスタ作成の流れ

ここから、実際に2台のProxmoxノードでクラスタを作成します。

私の環境では、ノード1をpve1、ノード2をpve2としています。また、ドメイン名として .internalを利用していますが、この部分はそれぞれの環境に合わせて変更してください。

なお、私の環境では、クラスタに参加する側のpve2にはVMが存在しない状態で作業しています。既存VMやストレージ設定があるノードを後からクラスタへ参加させると、設定の扱いが複雑になります。そのため、クラスタ参加側のノードは、できるだけ空の状態にしておくことをおすすめします。

事前準備

まず、お互いの /etc/hostsを確認します。

1	cat /etc/hosts

お互いの登録がなければ、以下のように追記します。

ここでは例として、pve1を192.168.1.1、pve2を192.168.1.2としています。

pve1で実行します。

1	echo "192.168.1.2 pve2.internal pve2" >> /etc/hosts

pve2で実行します。

1	echo "192.168.1.1 pve1.internal pve1" >> /etc/hosts

追記したら、名前解決と疎通を確認します。

pve1から確認します。

ping pve2

pve2から確認します。

ping pve1

次に、時刻同期を確認します。

1	timedatectl status

確認ポイントは以下です。

1
2
3

System clock synchronized: yes
NTP service: active
Time zone: Asia/Tokyo (JST, +0900)

Proxmoxクラスタでは、ノード間の時刻同期が重要です。クラスタ作成前に、両ノードでNTP同期が有効になっていることを確認しておきます。

準備ができたら、最初のノードでクラスタを作成します。

今回はpve1で実行します。

1	pvecm create mycluster

この時点では、まだpve1だけの1ノードクラスタです。

次に、pve2をクラスタへ参加させます。

pve2側で以下を実行します。

1	pvecm add 192.168.1.1

ここでは192.168.1.1をpve1の管理IPアドレスとしています。実際には、自分の環境に合わせてpve1のIPアドレスを指定してください。

実行中に、pve1のrootパスワードを求められます。また、初回接続時には証明書のfingerprint確認が表示されるため、問題なければyesを入力します。

正常に完了すると、以下のようにpve2がクラスタへ追加されます。

 Login succeeded.
Request addition of this node
Join request OK, finishing setup locally
waiting for quorum...OK
successfully added node 'pve2' to cluster.

クラスタ参加後、どちらかのノードで状態を確認します。

1	pvecm status

Nodesにpve1とpve2が表示され、Quorate: Yesになっていれば、クラスタ作成は完了です。

GUIからもクラスタ作成や参加は可能ですが、コマンドでも比較的簡単に実行できます。クラスタ作成後は、ProxmoxのGUI上でも2台のノードが同じデータセンター配下に表示されるようになります。
なお、2ノードクラスタの状態では、片方のノード停止時にquorumの課題が残ります。今回はまずクラスタ作成とVMマイグレーションを使える状態にすることを目的とし、qdeviceの追加は次回の記事で行います。

マイグレーションネットワークの設定

前述したように、私の環境では管理系のネットワークと、マイグレーションやレプリケーションで利用するデータ転送系のネットワークを分けています。

通常、Proxmoxのクラスタ通信はcorosyncが利用する管理系ネットワークを使います。一方で、VMマイグレーションやZFSレプリケーションでは、ノード間で比較的大きなデータ転送が発生します。

そのため、私の環境ではマイグレーションとレプリケーションの主なデータ転送を、Serverセグメント側に流すように設定しています。

ProxmoxのGUIから設定する場合は、左ペインの「データセンター」から「オプション」を選択します。ここで「マイグレーションの設定」を編集し、利用するネットワークアドレスを指定できます。

コマンドで設定する場合は、以下のように実行します。

1	pvesh set /cluster/options -migration type=secure,network=192.168.x.0/24

上記では、ネットワークアドレスの第3オクテットをxとしています。実際には、自分の環境で利用しているマイグレーション用ネットワークを指定してください。

設定内容は以下のコマンドで確認できます。

1	pvesh get /cluster/options

設定されていれば、以下のように表示されます。

1 2	migration: network=192.168.x.0/24

同様に、レプリケーションネットワークも変更できます。

ここでいうマイグレーションとレプリケーションは、役割が少し異なります。

項目	内容
マイグレーション	VMを別ノードへ移動する処理
レプリケーション	ZFSの差分転送により、VMディスクを別ノードへ定期的にコピーしておく処理

レプリケーションは、VMを常に完全同期する仕組みではありません。指定したスケジュールに従って、ZFSの差分データを別ノードへ転送します。そのため、障害発生時には最後のレプリケーション以降の差分が失われる可能性があります。

レプリケーションネットワークを指定する場合は、/etc/pve/datacenter.cfgに以下のような設定を追加します。

1	replication: secure,network=192.168.x.0/24

datacenter.cfgの例です。

1 2	migration: type=secure,network=192.168.x.0/24 replication: secure,network=192.168.x.0/24

設定後は、以下のように確認します。

1 2	pvesh get /cluster/options cat /etc/pve/datacenter.cfg

なお、実際に確認してみると、レプリケーション時にも管理系ネットワーク側に制御系と思われるSSH通信は残りました。一方で、大きなデータ転送はServerセグメント側に流れていることを確認しています。

そのため、この設定は「すべての通信を完全に分離する」というよりも、「マイグレーションやレプリケーションの主なデータ転送を、管理系ネットワークから分離する」ための設定と考えるのが現実的です。

参考：
https://pve.proxmox.com/pve-docs/pvesr.1.html

ZFSレプリケーションの考え方

Proxmoxでは、ZFSストレージを利用している場合、VMディスクを別ノードへ定期的にレプリケーションできます。

これは共有ストレージを使う構成とは異なり、各ノードがローカルストレージを持ったまま、ZFSの差分転送によって相手ノードへVMディスクのコピーを持たせておく仕組みです。

従来のクラスタ構成では、複数ノードから同じ共有ディスクを参照する構成が一般的でした。しかし、自宅環境で共有ストレージを高信頼に作るのは、コストや構成の複雑さが大きくなります。

その点、ProxmoxとZFSレプリケーションを組み合わせると、ローカルNVMeを使いながら、別ノードにもVMディスクのコピーを保持できます。ホームラボではかなり現実的な構成だと思います。

ただし、ZFSレプリケーションは同期レプリケーションではありません。指定したスケジュールに従って、一定間隔で差分を転送する非同期レプリケーションです。

そのため、ノード障害が発生した場合、最後のレプリケーション以降に書き込まれたデータは失われる可能性があります。

たとえば、1分ごとにレプリケーションしていれば、理論上は最大で約1分の差分が失われる可能性があります。15分ごとであれば、最大で約15分の差分が対象になります。

もちろん、障害時に失われる可能性のある差分は少ない方が好ましいのですが、実際には5分〜60分などの間隔をもって実行することが多いと思います。そのため、現時点では15分間隔でレプリケーションを行っています。

私の環境では、主にFirewallやFreeRADIUSなど、VM内部に大量の更新データを持たないサービスを対象にしています。これは意識的に、状態を多く持つサービスをHA対象にしないようにしているためです。

この構成であれば、通常時はローカルNVMeの性能を活かしつつ、別ノードにもVMディスクのコピーを保持できます。さらに、VMマイグレーションや障害時の復旧に備えることができます。

ただし、これはバックアップの代わりではありません。

レプリケーションは、別ノードへVMディスクのコピーを持たせるための仕組みです。誤操作、ファイル削除、VM内部の破損、ランサムウェアのような論理障害まで守るものではありません。

レプリケーション間隔	メリット	注意点
1分	障害時に失われる可能性のある差分が少ない	負荷が高くなりやすい
5分	データ保護と負荷のバランスが良い	更新の多いVMでは負荷に注意
15分	ホームラボでは扱いやすい	最大15分程度の差分喪失を許容する必要がある
60分	負荷が少ない	障害時に失われる差分が大きくなる

そのため、ZFSレプリケーションとは別に、通常のVMバックアップも必要です。

VMマイグレーション

VMマイグレーションには、停止しているVMを別ノードへ移動する通常のマイグレーションと、稼働中のVMを別ノードへ移動するライブマイグレーションがあります。

今回の記事の段階では、qdeviceやHAの設定までは行っていません。そのため、障害時にVMが自動的に別ノードで起動する構成ではありません。あくまで、管理者が手動でVMを別ノードへ移動する構成です。

それでも、パッチ適用やハードウェアメンテナンスの場面では、手動マイグレーションだけでも大きな効果があります。

ZFSレプリケーションを組み合わせた環境では、VMディスクの差分があらかじめ別ノードへ転送されています。そのため、ライブマイグレーション時の転送量を抑えやすく、環境によってはかなり短い停止時間でノード間を移動できます。

私の環境では、10GbpsのNICを利用しており、Firewall VMのライブマイグレーション時にProxmoxのログ上では100ms前後の短い停止時間で切り替わることを確認できました。もちろん、この時間はVMの負荷、メモリ容量、ストレージ構成、ネットワーク帯域によって変わります。

特に面白かったのは、Firewall VMをライブマイグレーションしても、Proxmoxの管理画面が操作不能にならなかったことです。

私の環境では、FamilyセグメントからFirewall VMを経由して、Proxmoxの管理画面に到達しています。つまり、Firewall VMが完全に停止すると、Proxmoxの管理画面にも到達できなくなります。

しかし、この状態でFirewall VMをライブマイグレーションしても、管理画面が無応答になったり、操作エラーが発生したりすることはありませんでした。

このログではマイグレーションのダウンタイムは74msとあります。Firewall経由でのProxmox操作でも影響ありません。ただし、ちょうど切り替わったタイミングあたりのログの時刻を見ていると、3秒程度の画面表示のタイムラグはあるように見受けられます。これはProxmoxのノードの切り替わりみならず、幾つもの条件をクリアしなければなりません。

FirewallがTCPセッションを引き継ぎ、別ノードで稼働すること
Proxmoxは対象VM（Firewall）の仮想Macアドレスをもう1台のノードに引き継ぐこと
ノードの切り替わりを検出したネットワークスイッチは自身の対象macアドレステーブルと物理Portの組み合わせを更新すること
他のネットワークスイッチへmacアドレス情報を反映すること
ProxmoxおよびネットワークカードはFirewallが送受信したパケットのリカバリーを行うこと
　新しいノードのNICからすれば、いきなりFirewallからの途中のデータを受信する、また外部から仮想Macアドレス宛の中途半端なデータを受信することになります。仮想環境とNIC側それぞれの腕の見せ所です。
クライアント側のTCPレイヤのリカバリ。ロストしたパケットを再送要求すること
　クライアント、サーバー共にTCPの実装のおかげでセッション継続が可能となります。

さらに言えば、この操作はMacBookからWi-Fi経由で操作しているので、そこも含めてスムーズな切り替わりが行えていることになります。そしてこの画面はpve1にブラウザで接続して操作しているので、pve2の稼働VMの状態はpve1を経由して把握していることになります。もっと厳密な言い方をすると、クライアントからはpve2のFirewallを経由してpve1のWebコンソールに接続し、pve2のProxmoxの状態を確認できているということです。
この挙動を見ると、ProxmoxとZFSレプリケーションの組み合わせは、ホームラボにおける大きなメリットだと感じます。共有ストレージを用意しなくても、ローカルNVMeの性能を活かしながら、別ノードへの移動や復旧に備えられるためです。

パッチ適用が楽になる

Proxmoxは比較的頻繁にアップデートが行われます。誤解を恐れずに言うと、私の環境では2週間に1度程度、何らかのパッチ情報が更新されている印象です。

1台構成の場合、Proxmoxホストにパッチを適用して再起動すると、その上で動いているVMもまとめて停止します。検証用のVMだけであれば問題になりませんが、Firewall、認証サーバー、監視サーバーなどを動かしている場合は、再起動の影響が大きくなります。

2台クラスタ構成であれば、まずVMをもう片方のノードへ移動してから、片方ずつパッチ適用できます。

仮に1台目のパッチ適用で問題が発生しても、VMを退避していれば、もう1台のノードで運用を継続できます。Proxmoxが1台しかなければ、こうはいきません。

片系ずつメンテナンスできる

パッチ適用だけでなく、ハードウェアメンテナンスでもクラスタ構成は有効です。

VMを別ノードへ移動しておけば、もう片方のノードを落ち着いてメンテナンスできます。たとえば、ネットワークカードのファームウェア更新、BIOS設定の変更、メモリ増設、内部清掃なども、サービス影響を抑えながら実施しやすくなります。

もちろん、すべての作業が無停止でできるわけではありません。しかし、1台構成と比べると、作業前にVMを逃がせるというだけで、運用上の安心感はかなり違います。

Ansible化するとさらに楽

今回は詳細を紹介しませんが、パッチ適用をAnsibleで定期タスク化すると、さらに運用が楽になります。

私の環境では、金曜日の夕方にパッチ情報を収集し、ChatGPT Codexでパッチ内容を整理しています。そのうえで、優先度や重要度を分類して通知し、土曜日にパッチ適用を行う運用にしています。

軽微なパッチであれば自動適用し、注意が必要なものは手動確認に回します。

クラスタ化によって片系ずつメンテナンスできるようになると、このような自動化とも相性が良くなります。

まとめ

今回は、2台のProxmoxノードをクラスタ化し、VMマイグレーションとZFSレプリケーションを使える状態にしました。

この状態でも、パッチ適用時にVMを別ノードへ移動できるため、1台構成よりもかなり運用しやすくなります。

特に、Firewall、Wi-Fi認証、監視サーバーなど、自宅の基盤となるVMを動かしている場合、ホストOSの再起動やハードウェアメンテナンスの影響を小さくできることは大きなメリットです。

一方で、2台構成のままではquorumの課題が残ります。また、今回の構成はHAによる自動フェイルオーバーまでは行っていません。

次回はqdeviceを追加し、2ノードクラスタの安定性を高めていきます。