Proxmox VEとProxmox Backup Serverの概要

VMware代替オプションとしての検証、および導入時の留意点について

この二年あまり、ブロードコム（Broadcom）によるVMwareライセンスの更新通知を見ては、ため息をついていたシステム管理者に朗報です。Proxmox VEが信頼に足るプラットフォームであることが確定しました。正確には、もうとうに確定していました。公式の記録によると、142か国で150万以上のホストにインストールされており、すでに世界中の本番環境で十分に活躍できることが実証されています。Proxmoxには、数年前までは懐疑的な声もちらほらあったのですが、近年の技術的な発展と仮想化サービス市場の変遷によって形勢が逆転し、Proxmox VEは今や引っ張りだこともいえる状態になっています。

本稿では、Proxmox VEおよびProxmox Backup Serverをどのように活用できるのか、何がそこまで改善されたのか、本番環境にデプロイする前に気をつけることは何か、に焦点を当てて解説していきたいと思います。

Proxmox VEとは？

Proxmox Virtual Environment（VE）は、小規模のテスト環境からエンタープライズデータセンターまで、あらゆる環境でサーバーの仮想化を管理できるオープンソースの仮想化プラットフォームです。完全な仮想化ソリューションとしてKVM（カーネルベースの仮想マシン）と、軽量のコンテナアプリケーションとしてLXC（Linuxコンテナ）を組み合わせ、以下の機能を提供しています。

● KVMは、専用のCPU、メモリ、ストレージリソースをVM 単位で確保するハードウェアレベルの仮想化ソリューションで、各VMの隔離とOSサポートを提供し、Windows、Linux、BSDゲストと互換性があります。

● LXCコンテナは、ホストカーネルを共有するので、数秒で起動できて、完全なVMが必要とするリソースのごく一部だけの消費で機能します。DNS、DHCP、リバースプロキシ、モニタリングエージェント、コンテナなどのサービスに優れた効果を発揮します。

実践的には、たとえば、Active Directory用にWindows Server VMを実行し、同じホストでLXCコンテナを活用してNGINXを実行したりできます。これを同じインターフェースから管理でき、ワークロードのタイプごとに別のインフラストラクチャを設定する必要がありません。

Proxmoxへの関心が高まっている理由

実際、Proxmoxへの関心は、この二年間で急速に高まりました。AIマーケティングのAhrefsの調査によると、“ESXi to Proxmox migration”（ESXiからProxmoxへの移行）という検索フレーズは2024年以降4倍に増えているそうです。主な要因はブロードコムによるVMwareライセンスの改訂ですが、それだけではありません。数年前にProxmoxを検証して、エンタープライズグレードの機能不足を理由に導入を見送った組織も、今はProxmoxを再評価し、信頼感を深めています。

他のオプションとProxmoxの比較

	Proxmox VE	VMware vSphere	Nutanix AHV
ライセンス	オープンソース、任意の有料サポート	コア単位のサブスクリプション（必須）	ハイブリッドサブスクリプション
5年間のTCO（総保有コスト）	低	高（ブロードコム後）	高
ストレージ	ネイティブZFS、Ceph、NFS、iSCSI、LVM	vSAN（アドオン費用あり）	ネイティブHCI
管理インターフェース	ビルトインウェブGUI（別サーバー不要）	vCenter（必須、別ライセンス）	Prism
バックアップ	ネイティブPBS統合	サードパーティ（Veeamなど）	統合サービス
ネイティブコンテナサポート	LXC（ネイティブ）	vSphere Pod（制限あり）	なし（VMのみ）
マルチクラスタ管理	PDM（2026年以降）	vCenter	Prism Central

2025～2026年に何が変わったのか？

Proxmoxを検証したのが数年前に遡る場合、最近の新機能を見逃している可能性があります。Proxmoxの最新機能について、以下にいくつか紹介しておきます。

Proxmox Datacenter Manager（PDM）

大規模環境でのマルチクラスタ管理は、かつてProxmoxの課題だと考えられていました。個々のクラスタが独自のウェブインターフェースを持ち、サイト全体の統一的なビューがない点も問題視されていました。これが、PDMによって改善され、ロケーションの異なる複数のクラスタがすべて単一のユーザーインターフェースで管理できるようになり、パッチのロールアウトなども一括更新できるようになりました。

PDMには、PVE 8.4以降とPBS 3.4以降が必要となります。PDMは、クラスタとパブリックAPI経由でのみ連携し、それ自体はPVEノード上で実行されず、別個のマネジメントアプライアンスとして機能します。機能は独立していても、サブスクリプションキーは単体ではなく、エンタープライズサポートライセンスに付属します。

VMwareマイグレーションウィザードの改良

VMwareやHyper-V環境からのAPI-to-API直接トランスファーがサポートされるようになりました。既存のvCenterまたはESXiホストをProxmoxから参照できるよう指定すれば、ディスク変換、ドライバ注入、ネットワークマッピングなど、大半のワークフローが自動化されます。特に大規模な移行においては、手動のOVFエクスポートやサードパーティツールに比べ、手間と時間が大幅に軽減されます。

注：コミュニティで共有された経験談によると、大規模マイグレーションにおける問題点を指摘する声もあります。たとえば、Windows VMは移行後にLSIロジックコントローラを必要とする場合があり、実際にはVirtIO SCSIが適用されるので、INACCESSIBLE_BOOT_DEVICEエラーが生じることが多いようです。この問題は、VMがVMwareで実行されている移行前の状態において、ストレージコントローラを変更しておくことで回避できます。また、スナップショットチェーンをともなうVMは、事前にスナップショットを統合しておく必要があります。複雑なスナップショットチェーンはインポートウィザードで処理されない場合があります。さらに、TPMによる仮想環境の暗号化はそのまま移行されないので、vTPMにもとづく暗号化は移行前に解除する必要があります。

ソフトウェア定義のネットワーキング（SDN）

SDN（Software-Defined Networking）がプレビュー機能からProxmoxスタックの中核機能へと昇格されました。SDNによって、マルチテナントのネットワーキングにおけるVXLANとEVPNがサポートされ、適切なネットワークセグメンテーションをともなうプライベートクラウドアーキテクチャでProxmoxを格段に利用しやすくなります。以前は、社内クラウドプラットフォームやマルチテナントインフラストラクチャを構築している企業にとっては、Proxmoxはネットワーキング面が不安視されていました。

本番環境へのデプロイメント

Proxmoxは、今や数多くの組織で本番環境にデプロイされ、数年間、特に問題なく稼働し続けています。しかし、デプロイメントが円滑に進むか否かは、ハードウェアとアーキテクチャの選択に依るところが大きいです。導入に際しては、以下の要件を考慮する必要があります。

ZFSメモリの要件

ZFS（ゼタバイトファイルシステム）のARC（Adaptive Replacement Cache）はRAMを使用して、頻繁にアクセスするデータブロックを迅速に読み取れるようにしています。このため、一般的には1 TBのストレージに対して1 GBのRAMが必要とされています。Proxmoxのバージョン8.1以降では、ARCの最大値がシステムRAM（最大16 GB）の10％にデフォルト設定されています。

実際には、ZFSはARCメモリをVMに対し、必要に応じて開放する仕組みになっているので、メモリ不足が生じることはありません。しかし、ARCが縮小するには、標準のLinuxページキャッシュより時間がかかる傾向があり、メモリ負荷が高い状態ではパフォーマンスを阻害する可能性は否めません。安全を期すには、ベースメモリ（OSとARC）に4 GB、追加で1 TBストレージごとに1 GB確保しておくことが推奨されます。

ネットワークの要件

現代のワークロードには、最低でも10 GbEが必要と考えられています。ハイパーコンバージドストレージにCephを運用している場合は、25 GbE割り当てたほうがいいかもしれません。ノードに障害が発生してディスクが再構築された場合、10 GbE程度は簡単に消費され、本番環境のレイテンシに影響する可能性があります。

ジャンボフレーム（MTU 9000）を構成するのも得策です。ただし、すべてのスイッチ、NIC、ボンドインターフェースを含むネットワークパス全体で一貫した構成が重要です。不統一なMTU構成はしばしばパフォーマンスに想定外の影響を及ぼしたり、Cephに「slow request」警告を生じさせたりします。

バックアップサーバーの配置

Proxmox Backup Server（PBS）を本番環境のVMと同じハードウェアに置くのは絶対やめたほうがいいです。PBSには、高密度実装のHDDストレージ（あるいは、予算が許すならSSD）の専用サーバーを個別ネットワークセグメントで運用するのが、障害復旧（DR）としての適正なアプローチです。

Proxmox Backup Server（PBS）の仕組み

PBSは、Proxmox VE環境のために特別に設計されたバックアップソリューションです。Proxmox VEとの直接統合により、ユーザーはProxmoxウェブインターフェースでバックアップジョブを構成でき、バックアップはPBSサーバーに保存されます。

PBSでは、コンテンツ識別による重複排除をアーキテクチャの中心に据え、すべてのバックアップの完全コピーを保存する代わりに、データを任意の長さのチャンクに分割して、個々のチャンクにハッシュ値を付け、固有のチャンクのみを保存します。たとえば、以前のバージョンとほぼ同じで10％だけ異なるVMバックアップは、その10％のみ保存されます。これは複数VMにまたがっても適用され、たとえば、完全一致する20件のWindows Server VMをバックアップする場合、共有されるOSブロックのみが1回だけ保存されます。

バックアップはPVEホストから送信される前にクライアント側で暗号化されるので、バックアップデータを安全にリモートサイトなどにレプリケートできます。また、整合性検証ツールも備えられており、保存したチャンクのチェックサムを定期的に再確認して、バックアップになんらかの破損があれば、リストア前に発見できます。

PBSのパフォーマンス

PBSのパフォーマンスは基本的にCPUに依存し、ネットワークには左右されません。SHA-256チェックサム、zstd圧縮、チャンク検証はすべてCPU負荷の高いオペレーションです。コミュニティで共有された体験談によると、10 Gbps NICがほぼアイドル状態であるのにCPUがフル稼働してバックアップのスループットが80～90 MB/秒に限られた事例も報告されています。PBSでは、シングルスレッドのパフォーマンスがコア数よりも重要になります。

PBSデータストアのストレージには、ローカルのSSD（ZFS付きのRAID-10）かオールNVMeが最適です。PBSデータストアをネットワーク共有で運用するのは得策ではありません。重複排除オペレーションが小さなファイルを大量に処理して、NFS／SMBレイテンシに悪影響を及ぼします。検証プロセスのパフォーマンスをチューニングするには、default-verification-readersを16に、default-verification-workersを32に設定すると、スループットがデフォルトの～800 MB/秒から5 GB/秒以上にアップします。

また、QEMUゲストエージェントとダーティビットマップバックアップを有効にして、非構造化ディスクイメージをフルに読み取る代わりに変更ブロックのみを転送すると、バックアップの所要時間もストレージトラフィックも大幅に軽減されます。

導入前の再確認

ここまで述べてきたとおり、Proxmoxは非常に優れたプラットフォームであることに間違いないのですが、すべての組織がVMwareの代替オプションとしてすぐに導入できるわけではありません。現実的には、以下の点を考慮したうえで、慎重に導入を判断すべきです。

■ Linux管理者スキルの有無 ― ProxmoxはDebianを基盤とし、トラブルシューティングにはコマンドラインを使用する必要があります。VMwareのグラフィカルユーザーインターフェースでのみインフラストラクチャ管理を行ってきたチームは、慣れるまでに時間がかかるかもしれません。決して超えられないハードルではありませんが、ネットワーキング（ボンディング、ブリッジ、VLANなど）やストレージの設定（ZFS、Cephなど）に関してはある程度のトレーニングは不可欠になります。

■ エンタープライズサポートの制約 ― Proxmoxサポートはヨーロッパの営業時間内で提供され、グローバルな24時間体制ではありません。いつ何時発生するかわからないベンダーサポートを必要とする組織にとっては、VMwareやNutanixと比較した場合、Proxmoxサポートは心もとなく感じられるかもしれません。サードパーティサポート（Veeam、Zerto、国内ではクライム）の有効利用が鍵となります。

■ 大規模な高可用性（HA）への対応 ― Proxmox HAは小規模から中規模のクラスタで非常に効果的に機能します。しかし、2000を超えるVMでHAグループを管理したり、フェイルオーバーの優先順位を設定したりする場合、vSphere DRSと比べると、処理の複雑化が免れません。複数ホスト間での自動リソースバランシングは、やはりDRSが一歩抜けていると言わざるを得ません。。

■ 即時クローン機能の有無 ― 既存のVMと同一の新しいVMをテンプレートからすばやく立ち上げて利用する必要がある場合（VDIや開発環境によくあるケースですが）、Proxmoxにはそのような即時クローン機能がありません。クローンのリンク機能はありますが、まったく同じ働きではありません。

注：上記の課題はすべて、いかなる組織にとってもProxmoxの導入をやめるべき理由になるものではありません。あくまで、デプロイメント中に発見するのではなく事前に認識しておくべき留意事項です。

Proxmox導入の現状

Promoxの導入が他業種に先駆けて進んだのは教育機関や研究所などでした。予算が限られること、要件が比較的柔軟なこと、Linuxが普及していたこと、などがその要因です。その後は、中小企業での導入が拡大傾向にあります。特に、エンタープライズ機能を必要としながらもライセンス費用は抑えたい従業員50～500名程度の企業に、急速に広がっています。

組織内では、DevOpsチームが開発環境およびCI/CD環境でPromoxの導入に積極的です。コンテナとVMを同じ環境で運用できる点が、DevOpsチームのニーズに合致しています。また、一般的な仮想化サーバー（セカンダリープラットフォームではなく、プライマリーハイパーバイザー）として本番環境に導入する組織も徐々に増えています。

これらの導入事例には、チームにすでにLinuxスキルがあることや、ベンダー依存を避け、コストを抑えたいニーズをPromoxが満たす点が共通しています。つまり、柔軟性、経済性、透明性を重視する組織には、オープンソースのPromoxが強い味方になる可能性があり、VMwareからの移行オプションとしても検討する価値が大いにあります。