PT3録画サーバーのファン故障による熱暴走と主要コンテナの緊急退避
PT3を搭載し、長年録画サーバー兼各種サービスのホストとして運用してきたASRock Beeboxですが、経年劣化により冷却ファンから激しい異音が発生するようになりました。
これまではファン制御スクリプトを導入し、必要最低限の回転数に抑えることで延命を図っていました。
しかし、ついにファンが一切回転しなくなりました。小型筐体内部の熱を排出できなくなった結果、高負荷時や録画処理時にCPU温度が急上昇し、熱暴走によるカーネルパニックでシステム全体が突如フリーズ・強制再起動する現象が度々発生する事態に陥りました。
分解してファンの型番を確認したところ「BSB05505HP-SM（DC05V 0.40A）」でした。互換ファンを注文しましたが、配送完了までには日数を要します。
https://amzn.to/4gQpihFハードウェア依存機能の分離と遊休機への退避
交換用ファンが届くまでBeeboxをそのまま稼働させ続けると、熱によるマザーボードやPT3自体の恒久的な破損につながります。そこで、稼働中の全サービスを見直し、物理デバイスに依存する機能とそれ以外の汎用サービスを切り分けることにしました。
PT3による録画機能はハードウェアに直結しているためBeebox側に残し、常時稼働による発熱を極力抑える体制をとります。一方で、Webサーバー、n8n、DAViCal、Giteaといった日常業務やデータ同期に直結する重要コンテナ群は、別のハードウェアへ緊急退避させる判断を下しました。
退避先の機材には、以前Harvesterを導入したもののリソース不足により用途を失っていたSurface Pro 5を再利用しました。
Surface Pro 5を初期化してUbuntu26.04をインストールし、軽量なコンテナホストとして再登板させました。
クラウドHA構成とのVPN再接続とネットワーク再設計の課題
今回の移行では、単なるコンテナのコピーにとどまらず、複数のインフラ設計上の課題がありました。
第1に、家庭内LANの基盤停止リスクです。Beebox上で動作していたdnsmasq（DNS/DHCP）を停止させると家庭内LANの全端末が通信不能に陥るため、安全な切り離し手順が必要でした。
第2に、WireGuard VPNのトポロジ再構築です。Oracle Cloud Infrastructure（OCI）上のHA構成（MAINサーバーおよびSUBサーバー）から、オンプレミス側のBeeboxおよびSurfaceに対してそれぞれ個別に接続するトポロジを採用しています。クラウド各拠点からローカル各機へ独立してVPN接続を確立するため、計4つのキー（事前共有鍵2つ、公開鍵・秘密鍵）を正確に生成・配備する必要がありました。
第3に、DockerからPodman（podman-compose）への環境移行です。Beeboxと同一LAN上で起動するため、既存のdocker-compose.ymlで定義されていたIPアドレスの重複を避けつつ、ネットワーク設定を再構築する必要がありました。
サービス退避とPodman環境への移行
dnsmasqの停止とWi-FiルータDHCP機能への移行
Beeboxがクラッシュした際に家庭内LAN全体が巻き込まれるのを防ぐため、Beebox上のdnsmasqを停止し、Wi-Fiルータ標準のDHCP機能へ処理を戻しました。これにより、サーバーメンテナンス中も家庭内ネットワークの通信を維持しました。
WireGuardコンテナを活用した鍵生成とVPN開通
ホスト環境を汚さずにWireGuardの鍵ペアおよび共有鍵を生成するため、一時的にWireGuardコンテナをローカルマウント付きで立ち上げ、コンテナ内のツールを用いて鍵を一括生成しました。
# 一時コンテナ内で鍵を生成してローカルディレクトリに出力 podman run --rm -v $(pwd)/wireguard_keys:/keys:Z docker.io/linuxserver/wireguard sh -c "wg genkey > /keys/privatekey && wg pubkey < /keys/privatekey > /keys/publickey && wg genpsk > /keys/presharedkey_main && wg genpsk > /keys/presharedkey_sub"
生成した鍵を用いてSurface Pro 5側の設定ファイルを作成し、OCI-MAINおよびOCI-SUBとの独立したトンネルを開通させました。
[Interface] PrivateKey = [Surfaceの秘密鍵] Address = 10.x.x.x/24 # OCI-MAIN向け設定 [Peer] PublicKey = [OCI-MAINの公開鍵] PresharedKey = [presharedkey_main] Endpoint = [OCI-MAINのIP]:51820 AllowedIPs = 10.x.y.0/24 PersistentKeepalive = 25 # OCI-SUB向け設定 [Peer] PublicKey = [OCI-SUBの公開鍵] PresharedKey = [presharedkey_sub] Endpoint = [OCI-SUBのIP]:51820 AllowedIPs = 10.x.z.0/24 PersistentKeepalive = 25
rsyncによる設定とボリュームデータの同期
BeeboxからSurface Pro 5へ、対象サービスのコンテナ設定および永続ボリュームをrsyncで同期しました。
# 設定ファイルおよび永続ボリュームの転送 rsync -avz -e ssh /opt/services/ root@[SurfaceのIP]:/opt/services/
podman-composeによるコンテナ起動
Surface側ではrootユーザーでPodmanを実行しました。root権限で稼働させることで、特権ポートのバインドやファイルパーミッションに起因する権限エラーを回避し、作業を迅速化しました。
Beebox側のIPと重複しないよう各サービスのdocker-compose.yml内のIP定義を修正し、podman-composeで一括起動しました。
# 各サービスディレクトリでコンテナを起動 cd /opt/services/web-stack podman-compose up -d
サーバー負荷の極小化と安定稼働の実現
主要コンテナ（Web、n8n、DAViCal、Gitea）をSurface Pro 5へ退避させた結果、BeeboxのCPU負荷は極限まで低下し、ファンが停止した状態でも熱暴走によるカーネルパニックは完全に収まりました。
また、OCI上のHA構成サーバーとの通信も新しいWireGuardトンネル経由で正常に維持され、外部連携サービスも最小限のダウンタイムで復帰しました。遊休機だったSurface Pro 5を活用することで、AliExpressから交換用ファンが届くまでの間、安全に録画待機とサービス提供を両立できる環境が整いました。
なお、現在Beebox本体はCentOS 7という骨董品のようなレガシー環境で稼働し続けています。今回のファン交換作業によるハードウェア復旧に合わせて、OS環境も最新のUbuntu 26.04へ刷新する計画を進めています
https://amzn.to/3UUoXBXまとめ
ファン停止により熱暴走を起こしていたPT3録画機から、主要コンテナ群を遊休状態のSurface Pro 5へ緊急退避させました。家庭内LANの保全のためdnsmasqをルータへ戻し、一時コンテナで生成した鍵を用いてOCIとのWireGuardトンネルを再構築しました。root権限下のpodman-composeでIP重複を回避しつつWeb、n8n、DAViCal、Giteaを移行した結果、Beeboxの負荷が下がりカーネルパニックが解消され、交換用ファン到着までの安定運用体制を確立できました。