はい。高速ティアに、再取得可能なアプリケーションファイル、バックアップ済みの永続状態、データベース、サムネイル、インデックスを置き、大容量メディアやバックアップを別の場所に保存するなら、コンテナとメタデータにはNVMeスロット1基で十分な場合があります。ただし、NVMeの障害によって重要なサービスを停止させてはいけない場合、1台のドライブでは必要な容量や耐久性を満たせない場合、またはデータベースを頻繁に書き換えられるキャッシュやログから分離したい場合は、答えが変わります。決め手になるのはスロット数だけではなく、どの程度の復旧時間を許容できるかです。
まずアプリ状態用ストレージと大容量ストレージを分ける
高速ドライブは、役割を限定したときに最も効果を発揮します。コンテナイメージ、データベース、アプリケーション設定、サムネイル、インデックス、頻繁にアクセスするメタデータは低レイテンシーの恩恵を受けます。一方、映画ライブラリ、写真のオリジナル、ダウンロード、バックアップリポジトリなどは、通常、より大容量のストレージ層に置くべきです。
Dockerのストレージは、1つの整然としたフォルダーではなく、複数のオブジェクトに分散しています。Dockerのディスク使用量に関する最新のガイドでは、イメージ、コンテナ、ローカルボリューム、ビルドキャッシュを分けて確認しています。NVMeデバイス1台が本当に小容量なのかを判断する前に、まず確認すべき項目です。
ZimaSpaceのブートとアプリデータの分離に関するガイドでは、所有範囲を分ける考え方も紹介しています。OSファイル、アプリケーション状態、大容量のユーザーデータに異なる役割を持たせると、復旧が容易になります。
提案しているNVMeが、単に便利だからという理由で大容量ファイルの保存先になっていて満杯なら、2つ目のスロットを追加することが最初の解決策ではありません。容量を重視するデータをHDDまたはより大きなストレージプールへ移し、本当に低レイテンシーアクセスが必要なファイルを基準に高速ティアの容量を再計算してください。
コンテナイメージよりも永続ボリュームが重要
コンテナイメージは、通常は再ダウンロードできます。一方、永続ボリュームには、データベース、ユーザー設定、認証状態、アプリケーション設定、サービスが以前の状態から再開するために必要なメタデータが含まれることがあります。
Dockerボリュームのガイドでは、ボリュームは個々のコンテナを置き換えても保持され、使い捨てのコンテナファイルシステムの外部に状態を保存すると説明しています。そのため、NVMeスロット1基だけが高速なアプリケーション層である場合、最初に保護すべきデータクラスは永続ボリュームです。
各ボリュームを、再構築可能なキャッシュ、復旧可能なアプリケーション状態、代替不可能なユーザーデータに分類してください。サムネイルは再生成できることが多い一方、写真アプリケーションのデータベース、自動化の履歴、パスワード保管庫の状態などは、シングルドライブ構成を受け入れる前に、テスト済みのバックアップが必要になる場合があります。
デバイスを失っても恒久的なデータ損失ではなく、計画的な復元で対応できるなら、NVMeスロット1基で十分です。重要な各ボリュームをどのように復元するか把握できていないなら、SSD自体が大容量かつ高速であっても、ストレージ設計は不完全です。
ログやキャッシュでNVMeスロット数を決めない
頻繁に書き換えられるデータがあると、実際のアプリケーション状態が容量を超えるよりずっと前に、NVMeが小さすぎるように見えることがあります。コンテナログ、トランスコード用キャッシュ、アップデートのダウンロード、一時的なエクスポート、ビルドキャッシュは急速に増加する可能性がありますが、ミラーリングする価値のあるデータになるとは限りません。
コンテナログの保持に関するBetter Stackのガイドは、ログに明確なストレージ設計とローテーション設定が必要な理由を示しています。無制限に増えるログを制御せずに2台目のNVMeを追加しても、同じ問題により多くの余地を与えるだけです。
ZimaSpaceのDockerログによるホストストレージの圧迫に関するトラブルシューティングガイドは、実践的な確認に役立ちます。容量不足をハードウェアスロットの問題と考える前に、データが増加する経路を特定してください。
一時的なキャッシュには、クォータ、ローテーション、分離したパスを使用してください。NVMeの容量は、低レイテンシーの恩恵を受けるデータベースやメタデータのために確保しましょう。2つ目のスロットは、制御されていない一時ファイルを受け止めるだけでなく、意図的な障害境界を作るときに、より大きな価値を発揮します。
スロット1基は、ストレージだけでなくダウンタイムに関する判断でもある
NVMeスロットが1基だけの場合、その上に保存されたすべてのデータが、1台のデバイス障害点に集約されます。だからといって、設計が自動的に誤りになるわけではありません。SSDが故障した場合、交換用ドライブを取り付けて状態を復元するまでアプリケーションが停止する可能性を、所有者が受け入れるということです。
独立したNVMeストレージプールに関するStorageReviewの解説は、独立した高速ボリュームとキャッシュまたはティアリングを区別している点で有用です。NVMeが実際のアプリケーションボリュームになるなら、独自の保護と復旧計画を持つプライマリーストレージとして扱う必要があります。
NVMeデバイスを2台ミラーリングすると、一方のデバイスが故障してもプールを直ちにオフラインにせずに済むため、可用性が向上します。一方、HDDや別のサーバーへのバックアップは、復旧可能性を守るものです。これは異なるメリットです。ミラーは中断を減らし、バックアップは以前の状態の復元に役立ちます。
家族がアプリケーションの1時間または一晩程度の停止を許容できるなら、テスト済みのバックアップを用意したNVMeスロット1基構成は合理的です。同じデバイスでホームオートメーション、認証、データベース、常時利用が必要なサービスを動かすなら、2台の高速デバイス、または別の可用性設計を選ぶ理由が強くなります。
1つしかない拡張スロットは、最も重要な制約に使う
コンパクトサーバーでは、1本のPCIeまたはM.2経路を、高速ストレージ、ネットワーク、AIアクセラレーター、その他の拡張デバイスのいずれかに使う必要があるため、トレードオフが生じます。最適な用途は、想定するワークロードの実際のボトルネックを解消するものです。
独立したZimaBoard 2のレビューでは、1基のPCIeスロットが柔軟に使える一方、用途を慎重に選ぶ必要があることを具体的に指摘しています。これはコンパクトなホームサーバーを選ぶ際の正しい考え方です。拡張経路はチェックリストではなく、限られた予算なのです。
ZimaBoard 2には、デュアルSATAに加えてPCIe 3.0拡張スロットが1基あります。そのため、別のNIC、アクセラレーター、GPUを追加するよりも低レイテンシーのアプリケーション状態が重要な場合に、NVMeアダプターの利用が最も妥当です。SSDのベンチマーク結果が魅力的だからという理由だけで、そのスロットをNVMeに使わないでください。
同じサーバーでNVMeのミラーリング、複数のSSDティア、高速ネットワーク、アクセラレーターが必要なら、コンパクトなプラットフォームは重要なことを示しています。つまり、そのワークロードは1スロットの拡張モデルを超えているのです。その段階では、1つのコネクターにアダプターを積み重ねるより、標準でより多くのストレージ経路を備えたシステムを購入するほうが、すっきりした選択になります。
復元時間を許容できるならNVMe 1基、許容できないなら複数の経路を選ぶ
小規模なホームアプリケーションスタックでは、コンテナの状態をバックアップし、データベースを復旧計画に含め、大容量のユーザーデータを冗長化または独立してバックアップされたストレージに保存するなら、容量を適切に選んだNVMe 1基は優れた設計になり得ます。これにより高速ティアをシンプルに保ち、家庭で不要かもしれないミラーリング容量への支出を避けられます。
サービスの即時継続性が重要な場合、データベースの書き込み負荷と頻繁に書き換えられるキャッシュを分離したい場合、または必要なアプリケーションプールがすでに十分大きく、1台のデバイスでは容量や耐久性の妥協が生じる場合は、2つ目のNVMe経路を使用してください。
冗長性ではなくアプリケーションの増加が購入の理由なら、プラットフォームを変更する前に容量計算を見直してください。関連するZimaSpaceのNVMeアプリケーションプール容量に関するガイドでは、イメージ、ボリューム、データベース、ログ、スナップショット、空き容量の予備を分けて考え、実際のデータに基づいてスロットを判断できるようにしています。
したがって、必要なレイテンシーを確保でき、障害が発生しても復旧可能なダウンタイムで済むなら、NVMeスロット1基で十分です。可用性、分離された障害ドメイン、複数の高速ストレージ用途が必須なら、1基では不十分です。
購入ガイド
もっと読む

CPU、RAM、IOPSのスペックをPlexのパフォーマンスにどう換算するか
Plexの負荷測定値を、買いすぎを防ぎながら必要最小限のCPU、RAM、ストレージ、ネットワーク要件に変換するための購入ガイド。

重み付け基準を使ってPlex向けホームサーバーを絞り込む方法
購入前に不確実性を明らかにし、必須条件と希望条件を分けた、再現可能なPlex購入マトリックス。

Plexサーバーはどのようなサポートとアップグレードライフサイクルを提供すべきか?
Plexサーバーのサポート、アップデート履歴、互換性、修理のしやすさ、コスト、移行準備状況を合否判定する購入フレームワーク。

