TrueNAS Scale vs Unraid: 両方を 1 か月間実行しましたが、勝者は予想していたものとは異なりました

私は、TrueNAS Scale と Unraid のテストに、それがどのように終わるかについてかなり強い想定を持って臨みました。 TrueNAS Scale には、私がホームラボ サーバーに通常求めているほとんどすべてが含まれていました。 Unraid の方が便利そうに見えましたが、その便利さには妥協が伴い、最終的には煩わしいと感じることになると予想していました。

その後、実際に両方を1か月間使用してみました。私は Unraid の無料トライアルに十分な時間を費やして、最初の印象を乗り越え、通常ホーム サーバーで処理できると期待される用途にそれを使用しました。最終的には Unraid に傾きましたが、これは開始時に予想していた結論ではありませんでした。その理由は、どのプラットフォームがより優れたストレージ テクノロジーを搭載しているかということとは驚くほどほとんど関係がありませんでした。

TrueNAS Scale は期待していたストレージ エクスペリエンスを提供してくれました

私が TrueNAS を選ぶ理由は今でも ZFS です

最大の違いは、ストレージの使用を開始するとすぐに明らかになりました。 TrueNAS Scale は OpenZFS を中心に構築されているため、スナップショット、チェックサム、圧縮、レプリケーションがすべてエクスペリエンスの中心となります。ストレージの整合性と管理が主な優先事項となるサーバーが必要な場合、それは非常に魅力的な基盤となります。

Unraid の従来のアレイはパリティを使用して障害が発生したディスクを再構築しますが、ZFS はチェックサムを通じて保存されたデータを検証し、冗長データが利用可能な場合には破損を修復できます。 Unraid はキャッシュやその他のストレージ用の ZFS プールをサポートするようになったため、ギャップはかつてほど単純ではなくなりましたが、メイン アレイは依然として異なるストレージ設計のままです。

TrueNAS では、RAIDZ 拡張により、既存の RAIDZ vdev にディスクを追加できます。そのため、ZFS プールは永久に固定されたままでなければならないという古い批判は不正確になりますが、それでも、Unraid アレイに別の独立したディスクを単に追加するだけではなく、より多くの計画が必要です。その差は以前よりも小さくなりました。

私がそれでも TrueNAS を選ぶのはそこです。データ保護、ストレージ アーキテクチャ、ZFS プールの長期管理について主に考えているとき、TrueNAS は実際に必要なツールを提供してくれますが、問題は、ホームラボが単なるストレージ システムではないことです。

サービスを実行し始めると、Unraid がより意味をなすようになりました

Docker と仮想マシンは方程式を変えました

最大の驚きは、両方のシステムをストレージ アプライアンスとして扱うのではなく、日常のワークロードに使用したことです。 Unraid の Docker 管理により、サービスのデプロイ、構成の変更、実行内容の追跡が簡単になります。 Web インターフェイスからイメージ、ポート、環境変数、ストレージ パスを設定し、他の作業に戻ることができます。コミュニティ アプリケーション エコシステムにより、共通サービスの検出と展開も簡単になります。

TrueNAS Scale は、ここでのギャップをある程度埋めました。 TrueNAS は、Apps バックエンドを Kubernetes から Docker に移行し、インターフェイスまたは Compose YAML を介して Docker イメージをデプロイするためのサポートを追加しました。これは、以前の SCALE アプリ エクスペリエンスからの大きな変更であり、古い Kubernetes ベースのシステムに基づく比較はすでに時代遅れであることを意味します。

その変更があっても、自宅サーバーとしては Unraid の方が便利だと思いました。違いは、Docker が機能するかどうかではなく、プラットフォームの実行中にどれだけ注意を払わなければならないかです。仮想マシンにも同じことが当てはまります。仮想化を別個のプロジェクトのように感じさせることなく、Linux VM をコンテナーやストレージ サービスと並行して実行できます。Homelab サーバーは一度に複数のジョブを実行することが多いため、これは通常のユーザーにとって重要です。

数週間後、私はどのプラットフォームが特定のワークロードを技術的にサポートしているかについて考えるのをやめました。どちらも私が懸念していたワークロードを処理できました。私はどちらがマシンを使いやすくするかに注目し始め、そこで Unraid が私に代わって前進し始めました。

Unraid のハードウェアの柔軟性は依然として無視できません

ランダム ドライブの追加はまさにホームラボで頻繁に必要となるものです

実際にストレージをどのように購入するかを考えたときに、実際的な違いが最も明確に現れました。 ZFS では、プールのアーキテクチャが重要です。 RAIDZ の拡張により、容量の追加が容易になりましたが、vdev と、新しいディスクを既存のプールにどのように適合させるかをまだ考慮する必要があります。ストレージ システムを意図的に構築する場合、この計画は価値があります。

Unraid は、ホームラボで発生するようなハードウェアの蓄積にはるかに慣れています。 4 TB ドライブ、2 つの 8 TB ドライブ、1 つの 12 TB ドライブを用意し、パリティ要件が満たされていれば、後でさらに大きなディスクを追加できます (パリティ ディスクは少なくとも最大のデータ ディスクと同じ大きさである必要があります)。

ただし、トレードオフがあり、これらのシステム間の比較が誤解を招きやすいのはこの点だと思います。 Unraid のメイン アレイは、パリティがボルトオンされた ZFS プールではありません。そのパフォーマンス特性は異なります。パリティ保護された書き込みには追加の読み取りおよび書き込み操作が含まれますが、メイン アレイは、総合的なパフォーマンスを確保するためにディスク全体にデータをストライピングするのではなく、個々のディスクを中心に設計されています。キャッシュ プールは書き込み負荷の高いワークロードを引き継ぎ、Btrfs または ZFS を使用できるため、Unraid は古い「XFS ディスクとパリティ」よりも大幅に柔軟になります。

そのキャッシュ アーキテクチャは、私にとって予想以上に意味のあるものになりました。高速 SSD または NVMe ストレージは Docker コンテナと VM を処理でき、より大きなアレイは大容量ストレージを提供します。既存のハードウェアを中心にサーバーを構築し、徐々に拡張することができました。これは、サーバーが完全に計画された 1 つのシステムとして購入されるのではなく (特にインフレを考慮した場合)、数年かけて進化する場合に非常に実用的な利点です。

1か月後にはおそらくUnraidの料金を支払うことになるでしょう

思った以上に利便性が高くなりました

この実験の面白い点は、私が Unraid の無料トライアルを必要としていないことを証明することを期待して開始したことです。その代わりに、人々がなぜ喜んでお金を払うのかを理解するために十分な時間を費やしました。ライセンス供与もその決定の一部だ。 Unraid の現在のライセンス階層では、接続されるストレージ デバイスの数が異なる方法で制限されるため、サーバーが小規模なドライブの集合を超えて拡大する場合には、ライセンスが関連します。

Unraid が Fedora に移行したら、購入を検討するかもしれません。ライセンスを締結する前に、特にプラットフォームのテストに 1 か月を費やした後、その移行がどのように行われるかを確認したいと考えています。私が Unraid を却下するだろうと予想していたところから、Unraid の購入を真剣に検討するようになったという事実は、おそらくどのベンチマークよりもその経験について多くを物語っているでしょう。

どちらがあなたにとってより理にかなっていますか?

最終的には、ストレージ システム自体に重点を置くか、それとも主な仕事の 1 つとしてストレージを提供する、より汎用的なサーバーを使用するかによって選択が決まります。ストレージ、コンテナ、仮想マシン、および徐々に拡張するハードウェアを組み合わせてホームラボを構築している場合は、Unraid を最初に試すことをお勧めします。