初めてのホームラボ向けストレージ構成：起動ドライブ、アプリデータ、大容量ストレージ

初めてのホームラボでは、ホストの再インストール、アプリの再構築、容量の拡張のたびにすべてのデータセットを一度に移動せずに済むよう、ストレージの役割を分ける必要があります。

ブートドライブ、永続的なアプリケーションの状態、大容量ストレージでは、障害、レイテンシ、増加のパターンが異なります。それらを区別のない1台のディスクとして扱うのが便利なのは、更新でルートファイルシステムがいっぱいになる、データベースとメディアファイルが容量を奪い合う、または容量の拡張にOSの移行が必要になるまでです。明確なトポロジーがあれば、各層をほかの層の再定義なしに変更できます。

ドライブ容量を選ぶ前にストレージの役割を割り当てる

ハードウェアの呼び名ではなく、データの特性から始めましょう。システム層には、オペレーティングシステム、パッケージの状態、コンテナエンジン、ホスト構成が含まれます。アプリデータ層には、データベース、設定、シークレット、インデックスなど、永続化が必要な状態が含まれます。大容量データ層には、メディア、アーカイブ、バックアップ、ISO、プロジェクトファイル、家族で共有するデータが含まれます。キャッシュと一時ファイルは、4つ目の破棄可能な役割です。

Puget Systemsは、独立した復元や再インストールが重要な場合、オペレーティングシステムとアプリケーションをプライマリドライブに置き、プロジェクトのアセットを分離することを推奨しています。この役割に基づくストレージの分離は、動画編集以外のワークロードでもホームラボにそのまま応用できます。

予定しているサービスごとに、各パスがどの役割に属するか、誰が所有するか、再生成できるか、どのくらいの速さで増えるか、どの復元操作で元に戻せるかを記録します。このマップで容量とレイテンシの要件を把握してから、ドライブを選びましょう。

ブートドライブは交換可能な状態に保ち、容量を適切に制限する

ブートドライブには、オペレーティングシステム、ログ、パッケージ更新、コンテナイメージ、および管理された量の作業データを保存できる十分な容量が必要です。インストール時に最も簡単だったという理由だけで、データベース、家族のファイル、VMイメージ、アプリケーションのアップロード先がブートドライブだけにならないようにしましょう。

LinuxBlogのファイルシステム階層ガイドでは、ファイルシステムを分けることで、あるデータ領域がルートファイルシステムをいっぱいにし、サーバーの他の部分に影響を及ぼすのを防げると説明しています。このルートファイルシステムへの影響を封じ込める原則が、永続的に増えるデータをブート層の外に置く主な理由です。

ホスト構成、パッケージまたは compose の定義、ネットワーク設定、外部データのマウント先を記録します。大量のデータを復元したり、アプリケーションの状態がどこに保存されていたかを推測したりすることなく再インストールできるなら、ブートドライブは交換可能性テストに合格です。

永続的なアプリデータは、低レイテンシーの専用パスに配置する

データベース、インデックス、アカウント情報、設定、頻繁に更新される小さなファイルは、大容量のメディアアーカイブとは性質が異なります。必要な容量は少なくても、レイテンシーが高かったり、バックアップに一貫性がなかったりすると、アプリケーションの動作が遅くなったり、復旧できなくなったりするおそれがあります。SSDベースの専用パスを使えば、こうした状態データを確認しやすく、使い捨てのコンテナレイヤーからも独立させられます。

Better Stackによると、Dockerボリュームを使うことで、永続データのライフサイクルを、それを使用するコンテナのライフサイクルから切り離せます。このアプリケーションとデータのライフサイクルの境界は、ホームラボで名前付きボリュームの代わりにバインドマウントを使う場合にも不可欠です。

/srv/appdata/photo-serviceや/srv/appdata/database-nameのように、用途がわかりやすいパスを使いましょう。必要に応じて、アプリケーションと整合性の取れた方法でデータベースをバックアップし、認証情報、スキーマのバージョン、証明書などの依存関係も記録してください。同じアプリが生成したものだからといって、キャッシュをこのパスに混在させないでください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

容量重視でレイテンシーの影響が小さいデータにはバルクストレージを使う

メディアライブラリ、アーカイブ、デバイスのバックアップ、ISOファイル、大容量のプロジェクトデータなど、主に容量が求められるデータセットには、バルクストレージが適しています。大容量のシーケンシャル読み書きでは、すべてのデータをフラッシュストレージに保存するコストに見合わない場合もあるため、ここではHDDが今も有用です。

TechTargetによるSSDとHDDの比較では、SSDはレイテンシーが低く、HDDは引き続き大容量ストレージのニーズに経済的に応えると説明されています。このレイテンシーと容量の違いを踏まえると、アプリの状態データにはSSDを使い、大容量で置き換え可能なデータやシーケンシャルデータにはHDDを使うトポロジーが適しています。

媒体自体がトポロジーなのではありません。重要なのは、アプリケーションからはロールベースのパスが安定して見える一方で、管理者は後からそのパスの物理ストレージを置き換えられることです。

マウントポイントとサービスの起動順序を安定させる

データドライブのマウントが不安定だと、アプリケーションがブートディスク上の空のディレクトリに書き込むことがあります。サービスは正常に見える一方で、誤ったファイルシステムの容量がいっぱいになる可能性があります。安定した識別子と起動時の依存関係を設定すれば、このように気付きにくい構成上の障害を防げます。

LinuxBlogのディスクパーティションガイドでは、デバイス名だけに頼らず、ファイルシステムのUUIDとマウントポイントを確認する方法を紹介しています。この永続的なマウントの確認手順により、再起動、コントローラーの変更、ドライブの追加後もパスを安定させることができます。

依存するコンテナやサービスを起動する前に、大容量データ用とアプリデータ用のファイルシステムをマウントします。使い捨てのデータを使って、2回の再起動と1回の計画的なストレージ切断をテストします。マウントできない場合は、ルートファイルシステムに書き込み先を切り替えるのではなく、ワークロードを停止するか、アラートを発生させます。

復旧単位に応じてアプリの状態と大容量データをバックアップする

アプリケーションの状態を復旧するには、多くの場合、設定、データベースの整合性、シークレット、バージョンの互換性が必要です。一方、大容量データはファイルやディレクトリとして復元できることがあります。単一のファイルシステムのスナップショットは役立ちますが、依存関係が別の場所にある場合、完全なアプリケーション復旧が自動的に実現するわけではありません。

N2WSによると、データベースの復旧には、1つのディレクトリをコピーするだけでなく、データ、スキーマ、設定の詳細、ログ、バックアップのメタデータが関わる場合があります。この複数要素から成るアプリケーション復旧モデルにより、アプリの状態と大容量ファイルに別々のバックアップポリシーを適用できます。

サービスで許容できるデータ損失の範囲を満たせる頻度で、アプリの定義と整合性のある状態をバックアップします。大容量ファイルは、スナップショットやバージョン管理に加えて、独立したコピーでも保護します。キャッシュの再構築によって許容できないダウンタイムが生じる場合を除き、キャッシュはバックアップ対象から除外します。復旧用コピーを少なくとも1つ、稼働中のストレージプールの外部に保管し、ファイルの復元とアプリ全体の再構築をそれぞれテストします。

すべての階層を移動せずに容量の増加を計画する

ブートドライブは、パッケージ、ログ、イメージ、アップデートによって増えていきます。アプリデータは、データベース、インデックス、ユーザー状態によって増えていきます。大容量ストレージは、メディア、バックアップ、アーカイブによって増えていきます。これらの増加率はそれぞれ異なるため、各階層に独自の警告しきい値と拡張手順が必要です。

TechTargetでは、階層型ストレージを、価格、性能、容量、可用性が異なるストレージクラスにデータを対応付ける仕組みと定義しています。このポリシーベースの階層化の考え方により、容量の問題がすべてサーバー全体の移行につながるのを防げます。

ルートファイルシステム、アプリデータ、大容量プールの使用量について、それぞれ個別にアラートを設定してください。可能であれば、運用上の予備容量を15～20％確保してください。同じマウントパスのまま、大容量層に容量を追加するか、既存の容量を置き換えて拡張します。アプリの状態を移動するのは、レイテンシー、保護、容量の測定結果から必要性が裏付けられた場合だけにしてください。新しいドライブを取り付けたというだけで移動する必要はありません。

復旧時の境界を明確に保てる、最小限のトポロジーを選ぶ

ごく小規模なホームラボなら、ディレクトリを明確に分け、バックアップを取り、使用量を制限すれば、起動とアプリデータの役割を1台のSSDにまとめられます。それでも大容量ファイルは別の容量領域に保存してください。より堅牢な構成は、起動用SSD、保護されたアプリデータ用SSD層、複数ドライブの大容量プールを組み合わせます。ただし、デバイスを増やすのは、障害発生時と復旧時の境界を明確にできる場合に限ります。

ServeTheHomeのコンパクトサーバープロジェクトでは、ラック規模のプラットフォームを必要とせず、メモリ、ストレージ、ネットワークを明確に組み合わせた小型専用ノードの設計方法が紹介されています。この用途を絞ったコンパクトなサーバーモデルは、測定に基づく必要性もないままストレージ層を増やすより、最初のホームラボの参考例として適しています。

ZimaSpaceの連携する3つのサービスを軸に最初のサーバーを構築するガイドは、初期のアプリデータの役割を特定するのに役立ちます。ZimaBoard 2 ミニホームサーバーは、起動層とアプリ層をSATAまたはPCIe接続のストレージに直接接続してまとめる、コンパクトなトポロジーに適しています。大容量層に、複数ドライブの一体型容量、長期保存、同時アクセス、ストレージを優先した復旧が必要なら、ZimaCube 2 AI NASのほうが明確な基盤となります。

起動ドライブの交換、アプリの再構築、または大容量領域の拡張を行っても変更されるのが1つの層だけで、ほかのストレージの役割が分かりやすいままであれば、そのトポロジーはうまく機能しています。