2023 年から、Operator として Proxmox VE、Proxmox Backup Server（PBS）、GPU server、On-prem infrastructure の設計と運用を担当しています。この環境では internal services と AI runtime workload を動かしており、全体の backup strategy も私の担当です。

この記事はインストール手順ではありません。中小規模のオンプレミス環境で私が重視している設計原則と、実際に遭遇して blog に記録した問題をまとめたものです（リンク先の記事は繁体字中国語です）。ホスト名、IP アドレス、ネットワーク構成、セキュリティの詳細は含めていません。設定に関する内容は一般的な指針であり、正確な情報は Proxmox の公式ドキュメントを参照してください。

背景と要件

オンプレミスの要件はたいてい現実的です。internal services を長期間安定して動かし、AI workload には GPU が必要で、データはバックアップでき、復元できなければなりません。予算も人手も限られているため、少人数で保守できるプラットフォームであることが重要です。

Proxmox VE はこうした状況に合っています。VM と LXC container を同じ画面で管理でき、クラスタ、ストレージ、バックアップにも標準の仕組みがあり、PBS を組み合わせれば incremental かつ deduplicated なバックアップが取れます。私にとって大事なのは機能の多さではなく、障害時にすばやく調査し、復旧できるかどうかです。

この領域での主な担当業務は次のとおりです。

  • Proxmox VE cluster、virtualization、storage、VM lifecycle の設計と運用。
  • Proxmox Backup Server の構築と、backup、restore、disaster recovery のプロセス設計。
  • NVIDIA GPU server、driver / runtime、inference environment の管理とシステムチューニング。
  • Dell、HP、Supermicro の server hardware と GPU server の仕様を評価し、調達・運用できる技術仕様にまとめること。
  • 社内外のデータセンター、site-to-site backup、high availability の経路設計と、LibreNMS による network / server monitoring。

設計のポイント：クラスタ、ストレージ、ネットワーク

クラスタ

クラスタには集中管理と VM 移動というメリットがありますが、quorum の問題もついてきます。Proxmox VE 公式ドキュメントによると、High Availability を使うには信頼できる quorum のために最低 3 ノードが必要です。2 ノード構成の場合は QDevice で 3 票目を補えます。

ほかに早い段階で確認していることがあります。

  • ノードのバージョンをそろえる：公式ドキュメントでは全ノードを同じバージョンに保つことが推奨されています。アップグレードは計画を立てて 1 台ずつ進めます。
  • CPU の互換性：online migration が保証されるのは同じ CPU ベンダー間のみです。ハードウェアが混在する場合は VM の CPU model を保守的に選ばないと、live migration が失敗することがあります。
  • ノードのライフサイクル：ノードの追加、入れ替え、削除は決まった手順で行い、その場の判断に頼らないようにします。

ストレージ

原則は「増えていくものをシステムから切り離す」ことです。VM disk、ISO / template、バックアップデータにはそれぞれ適した置き場所があります。特にバックアップデータはハイパーバイザーのシステムディスクと同じ領域に置かないようにします。どちらかが急に増えると、もう一方にも影響が出るからです。

VM の disk も増えていく前提で考えます。Proxmox 上でのディスク拡張自体は簡単ですが、ハイパーバイザー側で resize したあと、ゲスト OS 内の partition、LVM、filesystem も調整する必要があります。この手順は blog に Ubuntu 22.04 VM の場合の手順としてまとめています。

ネットワーク

クラスタ通信には Corosync が使われます。帯域はあまり必要としませんが、遅延には敏感です。公式ドキュメントでは、cluster traffic 専用の物理 NIC を用意し、別の物理ネットワーク上に 2 本目の link を冗長化として用意することが推奨されています。VM やバックアップの通信が Corosync を圧迫しないようにするためです。

一般的な原則として、管理、クラスタ、VM、バックアップの通信は分けて設計し、アドレス設計は最初に決めておくべきです。あとからクラスタの通信アドレスを変えるのは、想像以上に手間がかかります（後述の「運用でつまずいた点」を参照）。

GPU Server と AI Workload

AI runtime は GPU、driver、CUDA、kernel のバージョンに敏感です。そのため GPU server の運用で目指すのは「たまたま動いているマシン」ではなく、「再構築できる環境」です。

Proxmox で GPU を使う一般的な方法は PCI(e) passthrough です。公式ドキュメントでは、事前に考えておくべきトレードオフがいくつか挙げられています。

  • ハードウェアと BIOS / UEFI が IOMMU に対応し、有効になっている必要があります。
  • GPU を VM に passthrough すると、ホストや他の VM からはそのカードを使えなくなります。
  • passthrough した PCI デバイスを持つ VM は現時点では live migration できないため、ノードのメンテナンスには計画的な停止時間が必要です。

こうした制約があるため、GPU workload はマシン単位で計画するのが向いています。どのサービスが GPU を専有するか、driver と runtime をどうバージョン管理するか、ホストのメンテナンス時にサービスをどう止めてどう戻すか、といった点です。

GPU 運用で最もよく起きるのは driver の問題です。blog には nvidia-smi で No devices were found と表示される問題への対処や、Ubuntu 24.04 の Secure Boot 環境で NVIDIA ドライバーが読み込まれない問題の解決方法を記録しています。共通する教訓は、再インストールを繰り返すのではなく、まず kernel、driver、Secure Boot、ビルド環境の関係を確認してから対処を決めることです。

Proxmox Backup Server のバックアップ戦略

バックアップ戦略は、バックアップ、保持、クリーンアップ、検証の 4 つに分けて考え、そのうえで復元訓練を加えています。

Prune と Garbage Collection は別物

PBS で最も誤解されやすい点です。PBS 公式ドキュメントによると、次のとおりです。

  • Prune が削除するのは snapshot の metadata（manifest や index など）だけで、実データを持つ chunk はすぐには消えません。
  • どの snapshot からも参照されなくなった chunk を実際に削除するのは Garbage Collection（GC） です。GC は mark と sweep の 2 段階で動き、猶予期間（デフォルトで約 24 時間 5 分）があるため、prune 直後に GC を実行しても、すぐに容量が空くとは限りません。

そのため、保持ポリシー（keep-last、keep-daily、keep-weekly など）と GC のスケジュールはセットで設計する必要があります。prune だけ設定して GC をスケジュールしなければ使用量は増え続けますし、GC を回していても保持ポリシーが緩すぎれば、やはり容量は足りなくなります。

100% になる前に余裕を確保する

blog には PBS のディスク使用率が 100% になったときの対処を記録しています。厄介だったのは、GC を実行するにも多少の空き容量が必要なのに、それがまったく残っていなかったことです。最終的には、90 日以上前の古い task log を削除してわずかな空きを作り、そのうえで GC を手動実行しました。

この経験から、次の点をより重視するようになりました。

  • monitoring で datastore の使用率を監視し、書き込めなくなる前の余裕があるうちに対処する。
  • datastore と PBS システム自体の領域はできるだけ分け、バックアップデータでシステムが埋まらないようにする。
  • prune と GC のジョブが実際に動いているか、失敗していないかを定期的に確認する。

検証と復元訓練

バックアップが成功したからといって、復元できるとは限りません。PBS 公式ドキュメントでは verify job を設定し、少なくとも月に 1 回はすべてのバックアップを再検証することが推奨されています。ディスクの経年劣化によって、正常だったバックアップが徐々に壊れること（bit rot）があるためです。新しいバックアップを頻繁に検証する verify job と、週次または月次の全体再検証を組み合わせるのがよい方法です。

検証に加えて、実際の復元訓練も必要です。定期的にいくつかの VM や container をテスト環境に復元し、起動すること、サービスが動くこと、データが想定どおりのバージョンであることを確認します。Proxmox VE には live-restore や single file restore もあるので、訓練の際にあわせて手順を確認しておくとよいでしょう。

オフサイトと disaster recovery

同じデータセンターにバックアップが 1 つあるだけでは、拠点全体に問題が起きたときに対応できません。PBS は remote と sync job を使って別の PBS にバックアップを同期でき、site-to-site backup の土台になります。大事なのは、データを置いておくだけでなく、別拠点のバックアップを「どこに、どう復元するか」まで disaster recovery の手順に書いておくことです。

運用でつまずいた点

以下はいずれも blog で公開して記録した問題です。ここでは要点と学んだことだけをまとめます。

クラスタ通信 IP の変更

Proxmox VE Cluster IP の更新と設定の同期の手順を blog に記録しています。ポイントは、単一ノード上の /etc/corosync/corosync.conf ではなく、クラスタで共有される /etc/pve/corosync.conf を編集することです。事前にバックアップを取り、編集時には config_version を増やし、各ノードのネットワーク設定と /etc/hosts も更新し、最後に pvecm status で設定が反映されたことを確認します。quorum に影響する高リスクな変更なので、メンテナンス時間帯に行うべき作業です。

クラスタからのノード削除

ノード入れ替えのときの手順として、Proxmox VE クラスタからノードを安全に削除する方法を blog にまとめています。対象ノードの VM と container をバックアップまたは移行し、シャットダウンして自動で起動しないことを確認してから pvecm delnode で削除し、最後に残ったノードディレクトリと SSH key の情報を削除します。公式ドキュメントでも、削除したノードを元の設定のまま同じクラスタネットワークに戻すとクラスタが壊れるおそれがあると強調されています。

NIC の firmware エラー

ある Proxmox VE ホストで Intel X550 が ixgbe FWSM firmware error を出し続けた件を blog に記録しています。パケットのカウンターは正常に見え、kernel を更新しても解決せず、最終的に NIC の NVM を更新して本当の power cycle を行うことでエラーが消えました。学んだのは、ハードウェアから読み取った firmware の警告をログのフィルタリングで片付けないことです。firmware を書き換える前には inventory を取り、バージョンの対応を確認し、BMC / IPMI または物理コンソールを用意しておきます。

VM と container の修復

  • 起動しない Windows VM：PVE 上の Windows VM を WinPE で修復する方法を blog に記録しています。WinPE には VirtIO ドライバーが含まれていないことがあるため、まず drvload で読み込んでシステムディスクを認識させ、そのうえでオフライン DISM で修復します。
  • LXC での IPv6：PVE 上の LXC container で IPv6 を使うには、ホスト側の accept_ra 設定を調整する必要があったことを記録しています。
  • Web UI の証明書の入れ間違い：PVE で Connection error 596 が出た件を記録しています。誤った証明書を入れたことが原因で、SSH でログインして pveproxy の証明書ファイルを正しいものに戻して解決しました。

古いハードウェアとハードウェア監視

HP ProLiant DL380 G6 に PVE や PBS をインストールすると画面に縞模様が出る問題の対処法や、iLO からホストの状態を読めるようにするための Proxmox への HPE Agentless Management のインストールも blog に記録しています。古いハードウェアも延命はできますが、インストーラーや監視ツールのサポートは徐々に減っていくので、入れ替え計画は早めに立てておく必要があります。

アップグレード前の確認

blog では Proxmox VE 9.2 の重要な新機能として、HA の disarm / arm、CRS の動的負荷分散、Custom CPU Models GUI などを取り上げました。どのバージョンであっても、本番環境をアップグレードする前には、バックアップがそろっているか、kernel / driver の互換性、HA と migration の挙動、ネットワーク設定への影響を確認し、まずテスト環境や重要度の低いノードで検証するようにしています。

学んだこと

  • バックアップは「復元できるか」で判断する：prune、GC、検証、復元訓練のどれも欠かせません。バックアップジョブの成功だけでは不十分です。
  • 容量は早めに監視する：PBS が 100% になると、クリーンアップのツールすら動かしにくくなります。余裕を確保しておくほうが、事後の火消しよりはるかに安上がりです。
  • クラスタの変更はすべて高リスク作業：IP の変更、ノードの削除、アップグレードは、設定をバックアップし、ドキュメントの手順に従い、メンテナンス時間帯に行います。
  • つまずいたことは書き残す：上の問題はどれも、次に遭遇したとき自分の記録を見ればすぐ確認できます。これが blog を書き続けている理由です。