UPS復旧後、ホームサーバーは依存関係の順序に従ってサービスを再開できますか？

はい。ただし、依存関係のグラフが明示されている場合に限ります。UPS復旧後にサーバーを自動的に起動できても、ストレージ、DNS、データベース、ネットワークの準備が整っていないために、アプリケーションが失敗することがあります。

プロセスの起動順序とサービスの準備完了は同じではありません。ホストレベルのリソースにはsystemdの依存関係を使用し、コンテナとアプリケーションにはヘルスチェックを使用します。この違いによって、安全な設定、検証方法、ロールバックポイントが決まります。

自動化する前に依存関係のグラフを書く

電源とネットワークから、暗号化ディスク、NASマウント、コンテナランタイム、データベース、アプリケーションサービス、リバースプロキシまでの連鎖を一覧にします。各依存関係がローカルにあるのか、別のサーバー上にあるのかを明記します。

状態を持つ各依存関係に、準備完了を示すシグナルを設定します。マウント済みパス、データベースクエリ、DNSルックアップ、アプリケーションのヘルスエンドポイントなどです。正常でないシャットダウン後は復旧時間が変わるため、固定スリープは避けてください。

NASが見つからない場合に、アプリケーションが空のローカルディレクトリへ書き込まないよう、上限時間を設けた失敗状態を定義します。

各制御レイヤーを連携させる

ホストサービスとリモートマウントには、systemdの`After=`および`RequiresMountsFor=`の関係を使用します。コンテナスタックのユニットは、Dockerと必要なマウントユニットに依存するようにします。

Compose内では実際のヘルスチェックを追加し、対応している場合は`condition: service_healthy`を指定した`depends_on`を使用します。ただし、依存関係は起動後に失敗する可能性があるため、アプリケーション側でもデータベース接続を再試行する必要があります。

以下の表を使用して、各依存関係を実際に監視できるレイヤーに割り当てます。

2台のサーバーにまたがる復旧を設計する

まずストレージまたはインフラストラクチャ用サーバーを起動し、2台目のホストでアプリケーションサービスを開始する前に、共有リソースとデータベースが正常になるまで待機します。UPSソフトウェアで両方のホストを同時に起動するだけにしてはいけません。

ZimaSpaceのUPSシグナルと仮想マシンに関する記事では、制御チェーンがなぜ複数のレイヤーにまたがるのかを説明しています。

独立したsystemdとComposeのガイドでは、起動およびシャットダウン順序の競合について説明しています。

自動化がヘルスゲートの失敗で停止した場合に備えて、手動のコールドスタート手順書を用意しておきます。各サービスについて、チェック項目、想定タイムアウト、安全な再試行方法、担当者を記載します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

UPS復旧全体をテストする

バッテリー駆動中に制御されたシャットダウンを実施し、AC電源の復旧後に、ホストの起動、マウントの準備完了、データベースの正常性、アプリケーションの正常性、プロキシの利用可能性の各時刻を記録します。

NASを遅延させた場合や、通常よりデータベースの復旧に時間がかかる場合も繰り返しテストします。サービスは待機するか、欠落した状態を前提に起動するのではなく、明確に失敗する必要があります。

通常の復旧と遅延した復旧の両方で、順序とデータパスが維持されることを確認してから進めます。再起動ポリシーが準備完了を無視する場合、アプリケーションがフォールバックディレクトリに書き込む場合、または依存関係に測定可能なヘルスシグナルがない場合は停止してください。