メインコンテンツにスキップ ナビゲーションにスキップ フッターにスキップ
期間限定:デザインパートナープログラム — BUSINESSプランを永久利用

自動起動と回復

自動起動の仕組み、ブート後に停止したリポジトリを回復する定期リコンサイラー、および回復状態の確認方法。

自動起動と回復

このページでは、リポジトリが起動時に自動的にマウントおよび開始される仕組みと、サーバーがすでに稼働している状態でリポジトリが停止した場合に定期リコンサイラーが復旧させる仕組みを説明します。

リポジトリの自動起動を有効または無効にする方法については、サービス: 起動時の自動起動 を参照してください。

自動起動の仕組み

リポジトリの自動起動を有効にすると、Rediaccは256バイトのランダムなLUKSキーファイルを生成し、暗号化ボリュームのLUKSスロット1に追加します。キーファイルは以下の場所に保存されます:

{datastore}/.credentials/keys/{guid}.key

これにより、マシンはパスフレーズの入力なしにリポジトリをマウントできます。LUKSスロット0(パスフレーズ)は変更されません。

起動時に、rediacc-autostart.serviceという名前のワンショットsystemdサービスが自動起動有効なリポジトリのリストを読み込み、それぞれのキーファイルを使用してマウントし、リポジトリごとのDockerデーモンを起動して、RediaccfileのフックをRediaccfileのup()フックを実行します。シャットダウン時には、サービスがdown()を実行し、Dockerを停止して、LUKSボリュームを閉じます。

セキュリティに関する注意: キーファイルはパスフレーズなしにリポジトリへのルートレベルのアクセスを許可します。サーバーへのルートアクセス権を持つ者は誰でも、自動起動が有効なリポジトリをマウントできます。機密性の高いリポジトリで自動起動を有効にする前に、脅威モデルに照らして評価してください。

回復のギャップ

起動時の自動起動は起動ごとに一度だけ実行されます。その後継続的に実行されるルーターウォッチドッグは、稼働中のDockerデーモンを持つ、すでに実行中のリポジトリ内のコンテナのみを再起動できます。LUKSボリュームの再マウントや、停止したリポジトリごとのDockerデーモンの再起動はできません。

つまり、サーバー起動後にリポジトリのLUKSボリュームがアンマウントされたり、Dockerデーモンが停止したりした場合、起動サービスもウォッチドッグもそれを回復できません。リコンサイラーが存在する前は、この状態のリポジトリはオペレーターが介入するまで停止したままでした。

定期リコンサイラー

rediacc-autostart-reconcile.timerというsystemdタイマーがおよそ3分ごとに起動し、renet repository reconcileを実行します。自動起動が有効な各リポジトリについて、リコンサイラーは3つのことを確認します:

  1. LUKSボリュームはマウントされているか?
  2. リポジトリごとのDockerデーモンは稼働しているか?
  3. リポジトリのサービスは起動しているか?

いずれかのチェックが失敗した場合、リコンサイラーはキーファイルを使用してリポジトリを回復します:ボリュームをマウントし、Dockerデーモンを起動して、up()を実行します。パスフレーズは不要です。

正常なリポジトリ、現在コールドバックアップ実行が所有しているリポジトリ、またはバックオフウィンドウ内のリポジトリはスキップされます。

バックオフと永続的な失敗マーカー

回復に失敗したリポジトリは、毎回のティックで即座に再試行されるわけではありません。リコンサイラーは指数バックオフを使用します:

失敗回数次の試行までの待機時間
11分
22分
35分
415分
5回以上30分、その後60分

5回連続して失敗すると、リコンサイラーは以下の場所に永続的なマーカーファイルを書き込みます:

/var/lib/rediacc/reconcile/failed/{guid}

このファイルはログローテーションを経ても残ります。このファイルが存在する場合、リポジトリにはオペレーターの対応が必要です。リコンサイラーはエラーレベルで失敗をログに記録し、マーカーがクリアされるまでそのリポジトリの自動回復を停止します。

永続的な回復失敗の一般的な原因:

  • 信頼されていないまたは期限切れのリポジトリライセンス: ライセンスチェックはup()の前に実行されます。
  • キーファイルの欠落: {datastore}/.credentials/keys/{guid}.keyのキーファイルが削除された場合、リコンサイラーはパスフレーズなしにボリュームをマウントできません。
  • 壊れたRediaccfile: 構文エラーや、常にゼロ以外で終了するup()フック。

ルーターウォッチドッグとの関係

リコンサイラーとルーターウォッチドッグは異なるレベルの障害を処理し、相互補完的に設計されています:

レイヤー処理内容
ルーターウォッチドッグ稼働中でマウントされたリポジトリ内の、ライブなDockerデーモンを持つコンテナレベルの再起動
リコンサイラー(rediacc-autostart-reconcile.timerリポジトリレベルの回復:LUKSの再マウント、Dockerデーモンの再起動、up()の再実行

単一のコンテナが正常なリポジトリ内でクラッシュした場合、ウォッチドッグが処理します。リポジトリ全体のデーモンが停止した場合、リコンサイラーが処理します。

回復状態の確認

タイマーとサービスのステータス

systemctl status rediacc-autostart-reconcile.timer
systemctl list-timers rediacc-autostart-reconcile.timer

リコンサイラーのログ

journalctl -u rediacc-autostart-reconcile.service
journalctl -u rediacc-autostart-reconcile.service --since "1 hour ago"

永続的な失敗マーカー

永続的な失敗マーカーを持つリポジトリを一覧表示します:

ls /var/lib/rediacc/reconcile/failed/

各ファイル名はリポジトリのGUIDです。rdc config repository listと照合してGUIDをリポジトリ名にマッピングしてください。

根本的な問題を解決した後にマーカーをクリアするには、ファイルを削除します:

rm /var/lib/rediacc/reconcile/failed/{guid}

リコンサイラーは次のタイマーティックで回復を試みます。

関連ページ