平繁無忙（Hirashige Mubou）のBlog

タグ: クラスター

  • Proxmoxをアップグレードしてみた

    Debian １３が正式に公開されましたが、DebianベースのProxmoxは一足先に新バージョンである９．０が公開されていました。そんなんいいんですかね。

    自宅のネットワークでは、ProxmoxのクラスターをミニPC３台で構築していますので、アップグレードする対象も３つになります。元のバージョンは8.4.9で、すでにapt update済です。

    アップグレードのレポートは、Linuxやサーバに詳しい諸兄が、すでにQiitaやZennやnoteで書かれていますので、それらも参考にしましたが、ちょくちょくややこしいこともあるみたいですので、具体的な方法は、Google AI StudioにてGemini ２．５ Proさんにお聞きしました。

    人それぞれ異なる環境によって、アップグレード前の準備と実際の手順は多少異なるはずですが、概ね
    ・バージョン8.4.*までアップデートする
    ・VMやLXC及びホストのバックアップを取る
    ・VMとLXCをシャットダウンもしくはマイグレーションで移動する
    ・pbs8to9 –full で事前にチェックして、エラーと警告の項目に対応する
    ・APTリポジトリをtrixieに変更する
    ・apt dist-upgrade でアップグレードする
    ・再起動する
    ・アップグレード後にVMとLXCを復帰させる
    といった流れです。CephやHAについては使っていないので分かりません。使っている人ならご自身で調べてなんとかするでしょうけれど。

    多分、面倒なのは事前チェックで出てきたエラー・警告への対応でしょう。私の場合は、3つのホストで以下のような表示が出てきました（1つのホストでしか出ていないものと、重複しているものがあります）。

    WARN: systemd-boot meta-package installed but the system does not seem to use it for booting. … Consider removing ‘systemd-boot’
    WARN: The matching CPU microcode package ‘intel-microcode’ could not be found! … apt install intel-microcode
    WARN: dkms modules found, this might cause issues during upgrade.
    WARN: Deprecated config ‘/etc/sysctl.conf’ contains settings – move them to a dedicated file in ‘/etc/sysctl.d/’.
    WARN: The matching CPU microcode package ‘amd64-microcode’ could not be found! … apt install amd64-microcode

    どれくらい個人差があるか分かりませんが、intelやAMDのmicrocodeの問題ってここで初めて対応することになるのが、「なんでやねん」という感じもしますけれど。

    なんやかんやエラーとかありましたけれど、その都度Geminiに聞きながらなんとかホスト３つともアップグレードに成功し、9.0.3になりました。

    Proxmoxだけ利用しているのであればここで終了なのですが、私の場合は別PCでProxmox Backup Serverも動かしていますので、こちらもアップグレードしないといけません。PVEを９にアップしたら、PBSも４にしないと不具合が起きるらしいです。

    ということで、PBSのアップグレード方法をGeminiに聞きつつ実行していきます。ちなみにPBSでの事前チェックコマンドは
    pbs3to4 –full
    です。

    こちらもほとんどやることはPVEのときと変わりませんが、事前準備でデータストアのドライブは、オプションからメンテナンスモード（リードオンリー）にしておくべきなんだそうです。アップグレード中にバックアップデータをいじったらヤバそうなのは素人目にも分かります。

    PBSのアップグレードもなんだかんだエラーとかありましたが、ここでもその都度Geminiに聞いていくと全部解決して無事、アップグレードできました。現時点での最新バージョンは4.0.12ですね。

    Proxmoxは2年毎のバージョンアップグレードが行われるようですが、移行猶予期間みたいなものとして1年プラスされるので、今回のPVE9とPBS4はおそらく2028年8月までサポートされるはずです。まあ、次のバージョンが出たら出たですぐに飛びついてしまうとは思いますけど。

  • Mergerfs＆Snapraid導入、いくつかのサービス停止、k3sクラスターなど、サーバ構成を色々変更しました

    Proxmox3台＋ゲートウェイPCという構成でしたが、これにバックアップ用のシンクライアントを購入したと前のエントリで書きました。Proxmox3台の中でも、USB接続HDDを各サーバ（NextCloudやJellyfinなど）にそれぞれ接続していましたが、それらの外部ストレージをOpenMediaVaultに一括してまとめ、Mergerfs＆Snapraidを使って、擬似的に1つのストレージにして、かつ擬似的なRAID構成にして、NextCloudやJellyfinがそれにアクセスするような形にしました。

    また、ほとんど使っていなかった、
    Memos
    ChangeDetection
    ArchiveBox
    も停止しました。LXCコンテナの削除までは行っていませんので、また使いたくなったら有効にします。

    あと、サーバ監視として、少し前はWindowsで動かせるPRTGのフリー版を使っていて、その後、UptimeKumaをコンテナに入れて運用していましたけれど、結局のところ手の届くところにあるサーバで、ゲートウェイPC以外はProxmoxの管理画面で確認出来るのだから、サーバ監視サービスも要らないと言えば要らないですね。こちらも停止させてました。

    合計で4つのコンテナを使わなくなったことで、かなりリソースに余裕が出てきました。こうなると逆に貧乏性のためか、余っているのがもったいなく感じてきます。

    ということで、興味はあったけれど全く理解出来ないKubernetesに手を出してみることにしました。今のハードウェア的なリソースでは、フル環境のK8sはかなり重めになってしまい、他のサーバを停止させかねないので、軽量なK3sを導入してみます。

    K3sは1つのノードからでも実行出来ますが、せっかくなので各Proxmoxのホストに分けて、マスターノードとワーカーノード2つを構築しました。

    ということで、結局のところ、今の動かしているサーバ構成は以下のようになりました。

    ゲートウェイ（Zimaboard）
    CPU：Intel Celeron N3450（4コア4スレッド）
    メモリ：2GB
    ストレージ：eMMC 32GB
    OS：Ubuntuserver24.04
    サーバ内容：ファイアウォール（UFW）、VPN（WireGuard）、広告ブロック（Pi-hole）

    バックアップサーバ（T520）
    CPU：AMD/GX-212JC
    メモリ：4GB
    ストレージ：M.2 SATA SSD 16GB
    OS：Proxmox Backup Server
    サーバ内容：Proxmox Backup Server

    PVE（Wyse5070）
    CPU：Intel　CeleronJ4105（4コア4スレッド）
    メモリ：DDR4　16GB
    ストレージ：SATA接続SSD 480GB
    OS：ProxmoxVE
    サーバ内容：
    RSSリーダーのLXCコンテナ（CPU1コア、メモリ1GB、スワップ1GB、ストレージ10GB）、
    Apt-cacher-ngのLXCコンテナ（CPU1コア、メモリ2GB、スワップ512MB、ストレージ100GB）、
    OpenMediaVaultのVM（CPU2コア、メモリ4GB、ストレージ10GB、USB接続HDD2TBｘ2台、USB接続HDD1TBｘ3台）
    K3sのワーカーノードのVM（CPU2コア、メモリ2GB、ストレージ20GB）

    PVE2（N100）
    CPU：Intel　N100（4コア4スレッド）
    メモリ：DDR4　16GB
    ストレージ：SATA接続SSD 240GB
    OS：ProxmoxVE
    サーバ内容：
    JellyfinのVM（CPU2コア、メモリ4GB、ストレージ32GB）、
    K3sのワーカーノードのVM（CPU2コア、メモリ2GB、ストレージ20GB）

    PVE3（3550H）
    CPU：AMD Ryzen5 3550H（4コア8スレッド）
    メモリ：DDR4　16GB
    SSD：NVMe接続SSD 512GB
    OS：ProxmoxVE
    サーバ内容：
    WordPressのLXCコンテナ（CPU2コア、メモリ4GB、スワップ1GB、ストレージ10GB）、
    Nginx Proxy ManagerのLXCコンテナ（CPU1コア、メモリ1GB、スワップ1GB、ストレージ8GB）、
    NextCloudのVM（CPU4コア、メモリ8GB、ストレージ50GB）
    K3sマスターノードのVM（CPU2コア、メモリ4GB、ストレージ20GB）

    K3sの各ノードは、上記にあるようなスペックよりも少な目でも動くようですけれど、せっかくなので多目にリソースを配分しています。

    ただ、Kubernetesのクラスターを作ったは良いものの、ここからの勉強が大変ですね。
    ゆくゆくは、現在コンテナやVM内のDockerで構築している各サーバを、K3s上に移行させたいですが、学びつつやっていくのは時間がかかりそう・・・。

  • サーバ死活監視を導入したら即、役に立った話

    先日書いた自宅のネットワークとサーバの構成の投稿の最後に、
    PRTGのフリー版を各種サーバ・PCの死活監視に導入した
    ということを書きました。

    その時は、
    「言うてもそうそうサーバもPCも変にならんだろう」
    と高をくくっていたのですが、サーバ群の配置・配線を少し変えるために一旦、Proxmoxが入っているPC3台とも、全てのノードを停止して電源を落としたのですが、
    配置・配線を変えてから再起動させると、メインPCのブラウザでProxmoxが表示されません。

    壊れるにしても3台まとめてハードウェア的あるいはソフトウェア的に壊れるわけもないと思い、早速導入したばかりのPRTGを見てみると、3台ともPingは通っていることが分かりました。これにより、ネットワークが途切れているわけではない（ケーブル破損やIPアドレスのもんだいではない）と判明。

    PCが起動したら勝手にProxmoxも起動して、ノードも自動起動するはずなのに？とハテナマークを抱えながら、サブモニターとPCをHDMIケーブルでつないでみると、クラスター構成の3台（pve、pve2、pve3）のうち、pve3は起動していました。

    今度はpve2をモニターで見てみると、USB接続SSDやHDDが自動でマウント出来ないエラーにより、Proxmoxが起動できずに止まっていました。

    nano /etc/fstab

    でマウントしている行に # を付けてコメントアウトして保存、再起動すると無事、Proxmoxが自動で起動しました。

    オプションで「ブート時に起動」するようにしていたLXCコンテナやVMも、当然ながら自動で起動していますが、一時的にマウントされなくなっているUSB接続のストレージも、改めてマウントして設定し直し。

    ちなみに、VMやLXCコンテナでマウントする場合、USBパススルーでProxmoxホストを飛ばして各ノードでマウントさせる方法と、ホストでマウントしてから各ノードで共有する方法があります。汎用性があってスマートなのは後者なのでしょうけれど、素人のLinux・サーバユーザにとっては、USBパススルーを利用して、1台のストレージを1個のノードに紐付ける方が手っ取り早くて簡単ですね。

    ともかく、サーバの死活監視って個人レベルでも役に立つことがあるのですね。早速そのメリットを実感した次第です。