Proxmox HA:ベッドから出ずに午前2時のシステム危機を救う究極の技

Virtualization tutorial - IT technology blog
Virtualization tutorial - IT technology blog

午前2時、Telegramの通知が鳴り止まない……

監視システムが悲鳴を上げています。会社の全注文データが入った本番用データベースが稼働するProxmoxノード1が「死んだ」のです。データセンターの停電か、あるいは単なるECC RAMのシングルビットエラーかもしれません。Proxmoxをスタンドアロンで運用している場合、できることは起き上がってiDRACをチェックするか、サーバーを救出するためにマシンルームへ直行することだけです。その間、上司とのチャットグループでは、Webサイトのダウンに対する顧客からの苦情で通知が飛び交い始めます。

これはシステム管理者にとって馴染みのある光景です。私も12台のVMでホームラボを構築したばかりの頃、同じような眠れない夜を過ごしました。その「痛みを伴う」経験から、本番環境でサービスを稼働させるなら、決して「卵を一つのカゴに盛ってはいけない」ということを学びました。

なぜ仮想マシンは自動的に「復活」しないのか?

多くの人が、2〜3台のProxmoxをクラスターとして接続するだけで十分だと誤解しています。実際には、クラスターは集中管理のためのグループ化のステップに過ぎません。仮想マシン(VM)が稼働している物理ノードの電源が落ちれば、その仮想マシンはそのノード自体のハードディスクの中で止まったままになります。

基本的に、高可用性(HA)を実現するには3つの障壁があります:

  • クォーラム(多数決)の欠如:クラスター内では、どのノードが生存しているかを判断するために投票が必要です。2ノードのクラスターで1台が死ぬと、残りのノードは50%の票しか持たず、意思決定に必要な過半数(50%+1)に達しません。その結果、システムは「スプリットブレイン」状態に陥り、データを保護するために動作を停止します。
  • データがローカルストレージにある:.qcow2ファイルがノード1の内部SSDにある場合、ノード1がダウンしたときにノード2はどうやってそれを動かすのでしょうか?
  • HAマネージャーにタスクを割り当てていない:Proxmoxには専用の ha-manager エンジンがあります。VMを監視リストに追加しなければ、障害発生時に何も行われません。

手動マイグレーションから完全自動化へ

1. ライブマイグレーション(メンテナンス時のみ使用)

ノードのメンテナンス予定が事前に分かっている場合は、サービスを停止させずに仮想マシンを別のノードに移動できます。しかし、ディスクにアクセスできなくなる突然のノードダウン時には役に立ちません。

2. バックアップからの復旧(時間がかかり、手間もかかる)

Proxmox Backup Server (PBS) を使用してVMを新しいサーバーにリストアします。この方法は安全ですが時間がかかります。500GB程度のデータベースの場合、リストア待ちに40分以上かかることもあり、即時のオンライン復旧が必要なシステムにとっては長すぎます。

3. クラスターと共有ストレージの組み合わせ

これは大きな進歩です。NAS (TrueNAS) や Ceph を使用して共有ストレージを作成します。ノード1が死んでも、ノード2はネットワーク経由でVMのディスクファイルを確認できます。ただし、依然としてWeb管理画面から手動で仮想マシンの「開始」をクリックする必要があります。

決定的な解決策:真のProxmox HAの構築

毎晩ぐっすり眠るためには、**クラスター(最低3ノード)**、**共有ストレージ**、そして **HAグループ** の3点セットが必要です。以下は、私がよく適用する実践的な手順です。

ステップ1:クラスターの設定とクォーラム問題の解決

本番環境で2ノードクラスターを運用しないでください。予算が限られている場合は、古い Raspberry Pi やミニPCを「QDevice」として活用し、3票目を作成しましょう。

メインノードのコマンドラインからクラスターを作成します:

pvecm create MY-CLUSTER

残りのノードを参加させます:

pvecm add [メインノードのIP]

pvecm status コマンドで確認します。Quorum information の行が Activity: ok と表示されていることを確認してください。

ステップ2:共有ストレージの設定

NFS、iSCSI、Cephのいずれを使用する場合でも、すべてのノードが同じストレージIDにマウントされていることを確認してください。私は通常、速度を最適化するために、RAID 10を構成した専用サーバーからのNFSを使用します。

データセンター > ストレージ > 追加 > NFS に移動します。リスト内のすべてのノードにチェックを入れるのを忘れないでください。

ステップ3:HAグループの設定

多くの人がこのステップを飛ばして、直接VMをHAに追加してしまいます。これは間違いです!HAグループを使用すると、VMが優先的にどこへ移動するかを制御できます。例えば、ノード1と2は強力な Xeon Gold CPU を使用し、ノード3はバックアップ用の古いサーバーである場合などです。

  1. データセンター > HA > グループ > 作成 に移動します。
  2. グループ名を Critical-Services に設定します。
  3. ノード1と2を選択し、Priority(優先度)をノード3よりも高く設定します。
  4. VMをこれらのノード上でのみ実行させたい場合は、Restricted にチェックを入れます。

ステップ4:仮想マシンのHAを有効にする

次に、仮想マシンを「マネージャー」に委ねます:

  1. データセンター > HA > リソース > 追加 に移動します。
  2. 重要なデータベースの VM ID を選択します。
  3. 先ほど作成した Group を選択します。
  4. Max Restart:1に設定します(フェイルオーバー前にその場で1回再起動を試みます)。

実機テスト:「電源引き抜き」シミュレーション

優れた技術者は理論だけを信じません。オフピーク時に、ノード1で直接 poweroff を実行してテストを行いましょう。

約60〜120秒後(タイムアウト設定による)、Proxmoxはノード1を dead とマークします。直ちに ha-manager がノード2にハードディスクの制御権を奪い、VMを起動するように命じます。以下のコマンドでステータスを確認してください:

ha-manager status

ステータスが started から fence に変わり、新しいノードで再び started に戻ります。これが、システムが自らを救った瞬間です。

重要な注意点(経験則):

  • Corosyncネットワーク:専用のネットワークカードまたはVLANを用意することをお勧めします。このネットワークに遅延が発生すると、クラスターはノードが死んだと誤認し、連続的な再起動(フェンシング)を引き起こす可能性があります。
  • フェンシング:Proxmoxはウォッチドッグ(Watchdog)機構を使用して、他のノードがVMを起動する前に、ダウンしたノードが確実に「停止」していることを確認します。これにより、2つのノードが同時に1つのファイルに書き込み、データが破損するのを防ぎます。

クォーラムと共有ストレージের 2 つの柱さえ理解していれば、HAの設定はそれほど難しくありません。このガイドが、皆さんが自信を持って企業の高可用性システムを構築する助けになれば幸いです。

Share: