ストレージ専用NAS vs アプリ搭載NAS：どちらの障害ドメインのほうが復旧しやすい？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Storage-Only NAS vs NAS With Apps: Which Failure Domain Is Easier to Recover? - Zima Store Online

ストレージ専用NASは通常、より明確な復旧境界を作れます。一方、アプリを実行するNASでも、アプリケーションの状態を分離して再構築可能にすれば、小規模な家庭では扱いやすくなります。

本当の比較対象は、1台か2台かではありません。失敗したアップデート、容量がいっぱいになったボリューム、壊れたデータベース、ネットワーク障害、またはホストの交換が、1つの役割だけに影響するのか、それとも同じマシンに依存するすべてのサービスを停止させるのかという点です。

台数を決める前に依存関係を整理する

ファイル共有、データベース、メディアインデックス、フォトライブラリ、ダウンロードクライアント、リバースプロキシ、DNS、バックアップジョブを一覧にします。別のサービスが起動する前に利用可能でなければならないサービスを図にします。

ホームラボの障害は、隠れたDNS、ストレージ、認証の依存関係を通じて広がることがよくあります。専用NASにしても依存関係がなくなるわけではありません。ストレージへの依存を明確にし、安定させられるのです。

NASでDNSや、NAS自身の管理インターフェースへのアクセスに使うリバースプロキシも実行している場合、復旧が循環的になることがあります。ストレージホストの診断やアクセスに必要なサービスは分離してください。

アップグレード時の影響範囲を比較する

ストレージ専用NASでは、アプリケーションのアップデートは別の場所で行われます。そのため、失敗したコンテナイメージやデータベースの移行が、すべてのクライアントにサービスを提供するファイルシステムを直接圧迫することはありません。NASのアップグレードも重要ですが、変更範囲はより限定されます。

アプリをホストするNASでは、1回のメンテナンス時間にOS、ストレージスタック、コンテナエンジン、データベース、アプリケーションを更新することがあります。統合が効率的なのは、これらのレイヤーを個別にロールバックまたは復元できる場合に限られます。

アプリが少数でリスクが低く、ダウンタイムを許容でき、バックアップと監視を1つの環境で管理できるメリットが大きい場合は、統合が有利になります。

コンピュートを統合しても状態は分離する

アプリを実行するNASは、各アプリに名前付きの永続データセット、データベースのバックアップ、設定のエクスポート、ストレージ上限を用意すると復旧可能になります。イメージとキャッシュは破棄可能な状態にしておくべきです。

唯一のバックアップを、稼働中のデータと同じプール、ホスト、管理者境界内に保存しないでください。統合しても、この要件は変わりません。

状態の役割	ストレージ専用NAS	アプリを実行するNAS
ユーザーファイル	主な役割	主な役割
アプリのデータベース	外部コンピュートまたは専用データセット	専用データセットまたはボリューム
キャッシュとサムネイル	通常は外部	上限を設けた再構築可能なデータセット
バックアップ	独立した保存先が必要	独立した保存先が必要
復旧ツール	アプリなしで利用可能	アプリが失敗してもアクセス可能である必要がある

-15% OFF

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

Single board computer zimaboard2

2つの障害シーケンスをテストする

ストレージ専用構成では、権限を維持したままコンピュートホストを交換し、ストレージをインポートまたは再マウントできるかテストします。アプリをホストする構成では、ホストOSを再インストールし、ユーザーファイルのデータセットを書き換えずに1つのアプリケーションを復元できるかテストします。

具体的なブートドライブの復旧事例では、役割が識別可能であれば、分離されたストレージプールがホストの起動障害を乗り越えられることが示されています。重要なのは、インポートと復元に必要な情報を障害が発生したホストの外部に保存することです。

正常なスナップショット画面からではなく、何もない交換用システムからの復旧時間を測定します。DNS、認証情報、暗号化キー、マウント、データベース、クライアント側の検証を含めてください。

より小さく、復旧可能な障害ドメインを選ぶ

NASが複数のコンピュートノードにサービスを提供する場合、アプリのメンテナンス中も家族がアクセスできる必要がある場合、または1つの暴走したワークロードが重要なデータに影響する可能性がある場合は、ストレージ専用を選びます。ネットワーク経路を依存関係として受け入れ、安定したアドレス設定と電源によって保護してください。

環境が小規模で、アプリの状態が専用データセットに保存され、リソースが限られており、許容できるダウンタイム内にホスト全体を復元できる場合は、アプリを実行するNASを選びます。ホームサーバーOS選択ガイドは、その復旧モデルをプラットフォームに適合させるのに役立ちます。

アプリに特権デバイスアクセス、不定量のメモリ、負荷の高い一時書き込み、またはストレージとは異なるアップグレード頻度が必要な場合は、統合をやめます。ネットワークとIDのレイヤーによって、分離で減らせる手順以上に復旧手順が増える場合は、分離をやめます。