はじめに
テクノロジー愛好家の皆さん、こんにちは。今回は Proxmox を用いて私のホームラボを再構築した最近の経験をご紹介したいと思います。予期せぬ課題、貴重な教訓、そして達成感に満ちた成功、といった、山あり谷ありの取り組みでしたが、最新の仮想化およびストレージ技術を活用することで、当初の期待を上回る堅牢かつ効率的な環境を構築することができました。
ラボのセットアップ
ホームラボをレベルアップするために、優れた高可用性 (HA)、フェイルオーバー、バックアップ機能を備えた Proxmox を選択しました。これに対応するため、各サーバーのローカルアレイ間でレプリケーションを行うように ZFS を設定し、追加のストレージ層として NFS も統合しました。当初の計画では、フェイルオーバーのシナリオを手動でテストする予定でしたが、思いがけない出来事により、Proxmox の堅牢性を実地で試すこととなりました。
予期しなかったフェイルオーバーテスト
再利用した古いハードウェア (HPe DL360 Gen9) を使用していたことが予期しない課題を突き付けました。10GBe ネットワークカードのポートに不具合があり、Linux のボンディングに不安定さが生じたことで、実際のフェイルオーバーが発生しました。Proxmox は見事に対応し、影響を受けた VM をわずか3秒で別のホストに自動的に移行しました。VM は再起動し、WhatsUp Gold のサービスは40秒以内に復旧しました。
興味深い点として、ZFS のレプリケーションが NFS ストレージよりも先に利用可能になったことが挙げられます。これは、おそらくネットワーク速度の違い (10GBe 対 2GBe) によるものです。環境が自動的に復旧し、シームレスに稼働を続ける様子は、Proxmox の堅牢な設計を証明するものでした。
GenAI を活用したセットアップと管理
セットアップの効率化を図るため、GenAI を活用してクラスタの構成、ハードウェアに合わせた最適化、HA とレプリケーションの設定を行いました。さらに、Proxmox API を利用して、すべてのホストとゲストの詳細情報を取得する PowerShell スクリプトを作成しました。このデータは WhatsUp Gold に統合され、監視に活用されています。加えて、WhatsUp Gold が Proxmox ホスト上の重要なサービスを SNMP 経由で監視できるように、Proxmox デバイステンプレートの作成も開始しました。
高可用性の検証
この取り組みの中で重要なマイルストーンの一つは、Proxmox の高可用性 (HA) 機能を実際に検証できたことでした。カーネルパニックの根本原因の特定、ログメッセージの検証、正確なタイムスタンプの追跡は、非常に役立ちました。GenAI は、トラブルシューティングと特定のログメッセージの特定に極めて重要な役割を果たし、HA 構成の有効性を証明することができました。この成果は、新しいアーキテクチャの堅牢性と信頼性を裏付けるものでした。
NFS ストレージ障害: 厳しい現実の警鐘
ある金曜日の早朝、Progress WhatsUp Gold 360 からコネクタに到達できないというアラートを受け取りました。本番環境のウェブサイト (https://wug.ninja) もオフラインになっていることに気づきました。調査を進めた結果、NFS ストレージ上にホストされていたすべてのVM (WhatsUp Gold のプライマリサーバーを含む) にアクセスできなくなっていることが判明しました。さらに調査を進めると、NFS ストレージでホストされているすべての VM (プライマリ WhatsUp Gold サーバーを含む) にアクセスできないことがわかりました。幸いにも、WhatsUp Gold 360 のインターネット接続監視機能が、インフラの大部分がアクセス不能であるにもかかわらず、問題を通知してくれました。
NFS システムは完全にフリーズ/停止しており、ネットワーク経由での ping 応答もなく、SSH や HTTPS などの手段でもログインできない状態でした。ストレージシステムは完全に応答不能でした。この出来事は、堅牢なバックアップと復旧計画の重要性を痛感させる厳しい警鐘となりました。
バックアップからの復旧: レジリエンスの試練
他に選択肢がなかったので、NFS ストレージシステムを強制的に再起動しました。復旧に時間がかかることは承知の上でした。ダウンタイムを最小限に抑えるため、ストレージシステムに接続された USB ディスクからバックアップを復元しました。このプロセスでも、GenAI が大きな助けとなり、段階的な復旧手順をガイドしてくれました。
Linux VM については、コマンドラインから新しい VM を作成し、WinSCP を使ってファイルをコピーし、qemu-img で変換するという手順で復旧を行いました。この方法は、Alma Linux および Ubuntu サーバーでは問題なく機能しましたが、Windows VM ではうまくいきませんでした。Windows VM を起動しようとすると失敗し、リカバリ ISO を使ったトラブルシューティングでも進展はありませんでした。そこで、別のアプローチを模索せざるを得ませんでした。
その中で見つけたのが guestmount というツールです。これは仮想ディスクをマウントして中身を確認できるツールで、これを使って Windows の NTFS パーティションを Proxmox ホストの1台にマウントし、WinSCP で接続してデータベースの生ファイル (MDF と LDF) をダウンロードしました。そして、それらのファイルを、その間も稼働し続けていた ZFS WhatsUp Gold テストサーバーにドロップしました。この方法は一般的ではありませんが、「本当に動作するのか？」「どうすれば動作させられるか？」という好奇心から試してみました。通常の復旧手順では、SQL Server が生成する .bak ファイルを使用するのが望ましい方法です。
得られた教訓と今後の計画
今回の経験を通じて、冗長性、フェイルオーバー、そしてバックアップ計画の重要性について多くの貴重な教訓を得ることができました。ZFS 上の VM は、これらのトラブルの中でも一切影響を受けなかったことから、その信頼性の高さが改めて証明されました。この知見をもとに、すべての本番用 VM に対して ZFS とレプリケーションを優先するようにアーキテクチャを再設計しました。NFS システムが安定した後、VM を移行し、NFS はスケジュールされたバックアップ用として再利用することにしました。復旧した VM は削除し、移行した VM を使用することで、外部デバイスのバックアップが週次であったにもかかわらず、データ損失を最小限に抑えることができました。
バックアップ計画をさらに強化するために、Proxmox 内で複数のバックアップジョブを構成しました。そのうちの一つは、ミラー構成の内部 ZFS ストレージへのコピーです。もう一つは、NFS システムへのコピーで、週次1件と日次3件のバックアップを保持しています。NFS システムから Windows PC へバックアップをコピーし、それを OneDrive と同期する WinSCP スクリプトも作成しました。これは、3つのディスクセットとクラウドを活用した多層的なバックアップ戦略であり、ハードウェア障害や予期せぬ事態からデータを保護します。
まとめ
この取り組みは、課題、学び、そして成功が入り混じったものでした。Proxmox への移行により、私のホームラボは、現実のシナリオにも対応できる堅牢で効率的な環境へと変貌しました。得られた知見に感謝しつつ、今後も最適化と改善を続けていきたいと思います。
機会があれば、また私のホームラボに関連する新たな取り組みを紹介してみたいと思います。お付き合いいただき、どうもありがとうございました。皆さんの技術的な挑戦も実り多いものとなりますように！