VPNサーバーのディスク増加はどこから来るのか、どう上限を設けるか

トンネルが接続を受け付けなくなり、サービスが二度再起動し、その後ログには何も現れません。その沈黙が手がかりです。ディスクを埋めたのはログであり、デーモンには待っているエラーを書く場所がないからです。長時間動き続けるサービスはどれもこの状態に達し得ますし、logs というディレクトリを削除してもほとんど直りません。恒久的な解決は、どの保管領域が増えたのか、その保持方針は誰のものか、書き手が本当に容量を手放したのかを知ることです。

増えた保管領域と、その増加率を見つける

忘れやすい二つの数字から始めます。空きブロックと空き inode です。ファイルシステムは十分な空きを報告しながら、inode が残っていないために書き込みを拒否することがあります。これはサービスがセッションごとに一つのファイルを作るときに起こります。同じボリュームで両方を確認してください。答えは同じ午後でも食い違うことがあります。ホストが健全なうちに行えば、数字は障害ではなく通常運転を表します。

df -h /var
df -i /var

次に、増加を所有者に帰属させます。journal 自身の使用量は journal だけを対象にし、設定ファイルのパスに書くデーモンを決して見ることはありません。

journalctl --disk-usage

時間をかけた増加は、一度の測定より多くを語ります。入れっぱなしのデバッグレベル、試行のたびに記録する再試行ループ、誰も止めなかったキャプチャファイル。どれも、ある瞬間にはありふれて見え、一時間後には不安なものに見えます。一回測り、混雑する時間帯を待って、もう一度測り、その間隔で割ってください。口にできる増加率は、容量を火事ではなく判断に変えます。

ローテーションが開いたファイルに何をするか

ログファイルは inode を指す名前であり、容量は最後の開いたハンドルが閉じたときにだけ戻ります。ファイルの名前を変えても、書き手は同じ inode を埋め続けます。削除しても、書き手は名前のない inode を埋め続けます。「ファイルを消したのにディスクが満杯のまま」という状態がファイル記述子の話であって、壊れたファイルシステムの話ではないのはこのためです。書き手を再起動するか、ファイルを開き直すローテーション方式を選ぶことが、実際にブロックを取り戻します。

lsof +L1 | head

ポリシーはファイルを書く側のコンポーネントに属します。journal は設定ファイルから独自の保存上限を適用し、ファイルベースのサービスは通常 logrotate に頼ります。作成ルールと再オープン信号を使うか、書き手が開き直せない場合はその場で切り詰める方式です。まず何も変えずに判断を確認してください:

logrotate -d /etc/logrotate.conf

上限はどこに置き、どれくらいの大きさにするか

上限は書き手が設定されている場所に置き、マウントポイントには置きません。ボリューム全体のクォータはホストを守りますが、どのサービスが先に落ちるかは語りません。また、全体の掃除スクリプトは次の障害に必要な証拠を消しがちです。journal の上限、最大サイズ付きのローテーション回数、アプリケーション側の保持は、それぞれ一人の生産者を縛ります。合わせれば全体を縛りますが、単独ではどれも推測です。

上限は、空き容量ではなく、説明できる保持期間から決めてください。レビューに一週間分の接続試行が必要なら、journal は最も混むと見込まれる頻度で一週間分を保持しなければなりません。その頻度は先に測った数字です。

デバッグログは開始時刻を記録した一時的なモードであり、保存計画ではありません。プライバシーの問いは同じ判断の中に置いてください。接続ログはアドレスと識別子を運ぶからです。長い保持はデータの扱い方の選択でもあり、二つの制約を両方知る人が決めるべきです。

再起動後に上限を確認する

次の再起動までしか続かない保持の変更は、変更ではありません。書き手を再起動し、新しい上限が効いていることを確認し、その後もローテーションが動くことを確かめてください。journal なら、再起動一回と使用量の測定一回で二つの問いに答えます:

systemctl restart systemd-journald
journalctl --disk-usage

ファイルベースのサービスなら、ローテーションの処理を一度手で実行し、ファイルが置き換わり記述子が開き直されたことを確認します。古いハンドルを握ったままの書き手は表面的な確認を通り、次にボリュームが満杯になったときに失敗します。試験中は空き容量を見てください。ファイルが小さくなったのに容量が戻っていないなら、古い inode がまだ掴まれています。

次の測定をこれと比べる

一週間後に戻り、増加率を記録した値と比べてください。一致していれば上限が効いて負荷も安定しています。倍になっていれば何かが変わり、有用な問いは「何が」です。まずログの中身を読み、同じ失敗が繰り返されていないか見てください。再試行ループは症状であり原因でもあるからです。次に、新しく有効になったものを確認します。障害時にオンにして切らなかったデバッグレベルも含みます。

バックアップは同じボリュームの外に置くか、ディスクが一杯になればバックアップも一緒に失われると受け入れてください。守っているホスト自身に書いたコピーは復旧計画ではありません。その保持にも独自の答えが必要です。

何を、どこに、どれだけの期間保持し、誰が削除するのかを書き留めてください。その一文が成果物であり、次の再起動を生き延びるこの作業の唯一の部分です。