1つの大容量プールにする前のコンテナサーバー用ストレージチェックリスト

データセット、クォータ、バックアップ範囲、アプリケーションの整合性、復元順序を内部で分離できる場合にのみ、1つの大きなプールを使用してください。そうでなければ、最もリスクの高い役割を分離します。

永続データと使い捨てデータを棚卸しする

データベース、アップロードファイル、アプリケーション設定、シークレット、ログ、サムネイル、トランスコード、一時的なビルドキャッシュ、取得したイメージを一覧にします。それぞれを、代替不可能、復元可能、再構築可能に分類します。

優れたDockerバックアップ戦略では、コンテナイメージをアプリケーションそのものと見なすのではなく、Compose定義、永続ボリューム、シークレット参照を分離します。

• まずデータベースとユーザーのアップロードを保護します。
• Composeとデプロイ定義をバージョン管理します。
• ログ、キャッシュ、サムネイル、イメージレイヤーの容量を制限します。
• 復旧キーと手順はホストの外部に保管します。

データセットとクォータの境界を作成する

1つのプールにすることは、1つのファイルシステムや容量無制限の1つのディレクトリにすることを意味しません。データベース、アップロード、ログ、キャッシュには、それぞれ別のデータセット、ボリューム、またはサブボリュームを割り当て、スナップショット、クォータ、圧縮、権限を個別に設定できるようにします。

再構築可能なデータの増加には、固定上限またはアラートを設定します。制御不能になったログやサムネイル処理によって、データベースとファイルシステムのメンテナンスに必要な空き容量が消費される前に、処理を停止できるようにします。

空き容量を明示的に確保します。プールは通常時だけでなく、スナップショットの作成、データベースのメンテナンス、復元の実行中も運用可能な状態を維持する必要があります。

ストレージの動作をワークロードに合わせる

ブート、アプリ、メディア、バックアップを分離するストレージ構成により、競合するジョブが1つのプールを見分けのつかない塊に変えてしまうのを防げます。このホームラボのストレージ役割マップでも、同じ役割優先の考え方を示しています。

唯一のバックアップデータセットをライブデータの隣に置き、それを保護済みと見なしてはいけません。プールのインポート失敗、管理者のミス、または筐体の損失によって、両方が影響を受ける可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

アプリケーション整合性のあるバックアップを計画する

ファイルシステムのスナップショットでは、複数のサービスを異なるトランザクション時点で取得する可能性があります。データベースでは、ネイティブダンプまたは静止状態でのスナップショットを使用し、データの解釈に必要なアプリケーションのバージョンも保持します。

復元順序を文書化します。ストレージのマウント、シークレット、データベース、アプリケーション、リバースプロキシ、クライアント検証の順です。本番環境を上書きせず、1つのサービスを一時的な名前空間に復元してテストします。

データの役割ごとに保持期間を設定します。データベースの高頻度バックアップには、短期のローカル保持と、より長期の独立したコピーが必要になる場合があります。一方、取得したイメージは破棄できます。

1つのプールを選ぶ判断基準を設ける

データセットによって増加を分離でき、スナップショットがデータの役割に適合し、バックアップがホストの外部に保存され、1つのプールの停止が許容できるダウンタイムに収まる場合は、1つのプールで運用します。これにより、運用上の管理を崩さずに容量の柔軟性を得られます。

データベースのレイテンシが大量書き込みの影響を受けやすい場合、バックアップ処理がプライマリプールの障害後も継続する必要がある場合、または実験的なワークロードに同じ容量境界を任せられない場合は、プールまたはデバイスを分離します。ホームサーバーOS選択ガイドを使えば、これらの管理項目をプラットフォームに対応付けられます。

保持期間、クォータ、復元ルールの不足を解決するために、容量を増やしてはいけません。これらは設計上の問題であり、より大きなプールでは先送りにしかなりません。

まとめ

実際の部屋とネットワークで、すべての必須要件を満たした場合にのみ購入してください。そうでなければ、待つか、設計を絞り込むか、よりシンプルなプラットフォームを選びます。