StorageReview.com

予算の TrueNAS CORE システム対決

Enterprise  ◇  小型NAS

数か月前、私たちは800ドルをかけたTrueNAS構築コンテストを開始しました。簡単に言うと、ブライアン、ベン、ケビンの3人が800ドルを元手に、TrueNAS COREをOSとして活用した独自のNASシステムを構築しました。Western Digitalのおかげで、ストレージに関しては心配する必要はありませんでした。WDは、彼らが選べる豊富なSSDとHDDのオプションを提供してくれたからです。私たちは、各チームがそれぞれ異なるシステムを構築してどのような成果を上げられるか、そしてそれらのシステムがどのように比較できるかを知りたかったのです。彼らは資金を使い、互いに意見を交わし、システムをテストしました。さあ、その結果を見ていきましょう。

これまでご覧になっていない方のために、私たちのちょっとしたコンテストについての動画を作成しました。この動画はここに埋め込まれているか、私たちのYouTubeページでご覧いただけます。

予算の TrueNAS CORE システム

インターン生のベンが作ったPCは、おそらく最もDIY精神に溢れたものだったでしょう。彼はシンシナティ・コンピュータ・コーポラティブとマイクロセンターに行き、すべてのパーツを個別に購入して自分で組み立てました。使用したパーツは、OCZ GSX600電源ユニット、ASRock B550マザーボード、G.Skill Ripjaws V 64GB(32GB×2)DDR4-3600 RAM、Ryzen 5 3600、Chelsio 111-00603+A0ケース、そしてLian Li Liancool 205 PCケースです。余ったわずかなお金で、彼はLEDストリップを取り付けました。

バジェットトレナスコア

ケビンは、XeonプロセッサとECCメモリを搭載したHPE MicroServer Gen10 Plusを活用しました。さらに、他の構成よりも優位に立つため、100GbE対応のMellanox ConnectX-5カードを追加し、ネットワーク構成も容易にしました。他の構成ではデュアルポートNICを使用していますが、ケビンは100GbEインターフェースを1つ構成するだけで済みます。

Western Digital ドライブを搭載した Kevin の NAS

ブライアンの構成は、他の2つの構成の中間くらいです。彼は、AMD EPYC 3201 SoCプロセッサと4つの1GbEポートを備えたSupermicro M11SDV-8CT-LN4Fマザーボードから始めましたが、予算を大幅に圧迫しました。RAMには、SK hynix PC4-2400T-RD1-11 DDR4 ECC 8GB DRAMモジュールを2枚使用しました。また、Thermaltake 500W電源と10GbEカードもインストールしました。これらすべてをFractal Design Node 304エンクロージャーに収めました。ブライアンが見つけた10GbEカードは破格の値段でしたが、最終的にはTrueNASソフトウェアで認識されず、動作しなかったため、予備のラボ用Emulex NICに戻さざるを得ませんでした。中国製の中古DRAMも問題があり、交換する必要がありました。

TrueNAS CORE AMD EPYC 前面

予算 TrueNAS CORE システム – パフォーマンス

皆さんがここにいる本当の理由に移りましょう。3つのうちどれが一番良いのでしょうか? 3つのDIYビルドに加えて、偶然にもTrueNAS Miniをプレゼントします。 iXsystemビルドは5つのHDDが付属していたため、RAIDZ2を使用しています。 iXsystems TrueNAS Mini X+プラットフォームは、シャーシサイズとドライブサポートの最高のバランスを提供します。5つの3.5インチHDDをサポートし、SSD用の2つの2.5インチベイも備えています。では、これをベースラインとしてテストしないのはなぜでしょうか? 簡単です。Mini X+はパフォーマンスではなく、最大限のデータ回復力に合わせて調整されています。他の3つはこの対決で最速になるように調整されていますが、それにはいくつかのリスクが伴います。 iXsystemsが競合他社を打ち負かしたいのであれば、ビルドで完全に打ち負かすことができます。

iXsystems TrueNAS ミニベイ

RAID 構成について簡単に説明します。TrueNAS は、ビルドに応じていくつかをサポートします。根本的に異なるビルドを使用したため、RAID 構成も異なります。 Ben と Kevin のビルドは 4 台の SSD で RAIDZ を使用し、Brian のビルドは 4 台の HDD でミラーを使用します。

この対決では、SMB ファイル共有プロトコルのみに注目しました。言及すべき興味深い要素の 3.5 つは、マザーボードとシャーシの構成がどれほど重要であるかということです。 Ben のデスクトップ プラットフォームはおそらく最もクールに見えますが、XNUMX インチ ドライブ ベイが XNUMX つしかなく、ケースもこれまでで最大です。

ブライアンのケースは、冷却に配慮して最大 3.5 つの XNUMX インチ ドライブ ベイをサポートしていますが、彼のマザーボードにはオンボード SATA ポートが XNUMX つしかありません。 Kevin の HPE Microserver ビルドにはストック ビルドとして XNUMX つのベイと XNUMX つのポートがありますが、それはプラットフォームの設計方法にすぎません。

ストレージ構成もモデルによって若干異なります。ブライアンのシステムでは、10TBのWD Red HDDが4台搭載されていましたが、残念ながらM.2 NVMeポートは期待通りに動作しませんでした。ベンとケビンのシステムでは、どちらも4TBのWD Red SSDが4台搭載されていました。

パフォーマンスのセクションでは、ドライブの選択そのものを超えて、RAID 構成がパフォーマンスの測定方法に大きな役割を果たしていることに注意することが重要です。 RAIDZ のオーバーヘッドは RAIDZ2 よりも少なく、Mirror のオーバーヘッドは RAIDZ よりもさらに少なくなります。そうは言っても、RAID セットアップでは、最終的なエンド アプリケーションが何であるか、必要な容量はどれくらいか、ビルドにどの程度の耐障害性が必要かを考慮する必要があります。結局のところ、これらの結果は、どの NAS が高速であるかを示すことを目的としたものではなく、異なる RAID 構成で同じドライブを使用している同様のビルド間で TrueNAS 構成がどのように動作するかを示すものです。

エンタープライズ総合ワークロード分析

当社のエンタープライズ共有ストレージとハードドライブのベンチマーク プロセスでは、スレッドごとに 16 の未解決のキューを備えた 16 スレッドの高負荷下でデバイスをテストするのと同じワークロードで各ドライブを定常状態にする前提条件を設定し、その後、設定された間隔で複数回テストします。スレッド/キューの深さプロファイルを使用して、軽い使用状況と重い使用状況でのパフォーマンスを示します。 NAS ソリューションは定格パフォーマンス レベルに非常に早く到達するため、各テストの主要なセクションのみをグラフ化します。

プレコンディショニングおよび一次定常状態テスト:

  • スループット (読み取り+書き込み IOPS 合計)
  • 平均レイテンシ (読み取りと書き込みのレイテンシを合わせて平均)
  • 最大遅延 (ピーク読み取りまたは書き込み遅延)
  • レイテンシの標準偏差 (読み取りと書き込みの標準偏差を合わせて平均)

当社のエンタープライズ合成ワークロード分析には、実際のタスクに基づいた 4 つのプロファイルが含まれています。これらのプロファイルは、過去のベンチマークや、最大 8K の読み取り/書き込み速度やエンタープライズ ドライブで一般的に使用される 70K 30/XNUMX などの広く公開されている値との比較を容易にするために開発されました。

  • 4K
    • 100% 読み取りまたは 100% 書き込み
    • 100% 4
  • 8K 70/30
    • 70% 読み取り、30% 書き込み
    • 100% 8
  • 8K(シーケンシャル)
    • 100% 読み取りまたは 100% 書き込み
    • 100% 8
  • 128K(シーケンシャル)
    • 100% 読み取りまたは 100% 書き込み
    • 100% 128

まずは 4K 読み取り/書き込みスループット テストです。読み取りに関しては、Ben の 14,865 IOPS が最高のパフォーマンスを発揮しました。ケビンは11,476で595位となった。ブライアンは 3,868 IOPS で 2,517 位になりました。書き込みに関しては、Kevin が 923 IOPS でトップの座を獲得しました。 Ben は XNUMX IOPS で XNUMX 位になりました。 Brian は XNUMX IOPS で XNUMX 位を維持しました。

これの大部分は、導入されている RAID タイプに依存しますが、Kevin の Microserver と Ben の DIY ビルドでは、IOPS の違いが各ビルドの CPU の速度に影響します。

次に4Kの平均遅延です。ここでは、上記と同じ配置が見られます。読み取りでは、ベンが 17.2 ミリ秒で勝利し、ケビンが 22.31 ミリ秒で 429.2 位となり、ブライアンが 66.21 ミリ秒で大きく遅れをとりました。書き込みに切り替えると、ケビンが 101.66 ミリ秒でトップの座をつかみ、ベンが 276.89 ミリ秒で XNUMX 位となり、ブライアンが XNUMX ミリ秒で少し迫って XNUMX 位になりました。

4K 最大遅延では、配置に少し大きな変化が見られました。読み取りでは、ベンが 263.96 ミリ秒でトップの座を獲得し、ケビンが 273.44 ミリ秒でそのすぐ後ろにあり、ブライアンが 1,091.3 ミリ秒で 1,195 位でした。書き込みでは、ケビンが 2,092.5 ミリ秒で 2,431.7 位となり、ブライアンが XNUMX ミリ秒で XNUMX 位となり、ベンが XNUMX ミリ秒で XNUMX 位に後退しました。

最後の 4K テストは標準偏差です。読み取りでは、ベンが 5.94 ミリ秒でトップとなり、ケビンが 7.11 ミリ秒で僅差となり、ブライアンが 171.75 ミリ秒でケビンに大きく遅れました。書き込みでは、ケビンが 117.02 ミリ秒でトップの座を獲得し、ベンは 201.58 ミリ秒でそれほど差はなく、ブライアンも 271.13 ミリ秒でそれにそれほど差はありませんでした。

次のベンチマークでは、100T8Q 負荷で 16% の読み取り操作と 16% の書き込み操作で 100% の 100K シーケンシャル スループットを測定します。 Ben のビルドは 47,699 IOPS で読み取りでリードし、Kevin は 44,848 IOPS で僅差で、Brian は 29,767 IOPS でした。書き込みでは、Ben が 83,866 IOPS で再びトップの座を獲得し、Kevin が 51,020 IOPS で 33,448 位を維持し、Brian が XNUMX IOPS で XNUMX 位を維持しました。

16% 16K 書き込みテストで実行した固定の 100 スレッド、4 キューの最大ワークロードと比較して、混合ワークロード プロファイルは、幅広いスレッド/キューの組み合わせにわたってパフォーマンスを拡張します。これらのテストでは、ワークロード強度を 2 スレッド/2 キューから最大 16 スレッド/16 キューまで広げます。ここでは、ドライブのタイプと RAID 構成が大きな役割を果たします。ドライブ障害をサポートするために追加されたパリティは、パフォーマンスに影響を与えます。スループットでは、Ben は最高のスタートを切り、17,317 IOPS で最高のピークを獲得しましたが、最後の近くでビルドが若干低下しました。ブライアンの体格はケビンよりも高くスタートしましたが、ケビンは彼を上回ってXNUMX位になりました。

平均的な遅延では、15.8 つの StorageReview ビルドはすべてミリ秒未満の遅延で開始されました。両者はかなり近い距離を走っていましたが、ベンの体格が徐々にケビンの体格を引き離し、両者ともブレインの体格から引き離されていることがわかります。ベンは 18.3 ミリ秒、ケビンは 31.2 ミリ秒、ブライアンは XNUMX ミリ秒で終了しました。

最大レイテンシーに関しては、ケビンが最高のスタートを切り、彼とベンが 221 位を行き来しました。最終的に、Kevin のビルドは 285 ミリ秒、Ben のビルドは XNUMX ミリ秒になりました。ブライアンは終始XNUMX位に大きく遅れをとっていた。

標準偏差は、ベンが全体を通して先を行っていることを明らかに示していました。ケビンの遅延は約 3 倍、ブライアンの遅延は約 4 倍でした。

最後のエンタープライズ合成ワークロード ベンチマークは 128K テストです。これは、デバイスの最高のシーケンシャル転送速度を示す大規模ブロックのシーケンシャル テストです。読み取りでは、Kevin が 2.32GB/s でトップの座を獲得し、Ben が 1.81GB/s で彼のすぐ後ろに続き、Brian のビルドは 734MB/s でスタートピストルを逃したに違いありません。書き込みでは、Kevin が 2.77GB/s で再びトップの座を獲得し、Ben と Brian はそれぞれ 1.42GB/s と 1.41GB/s でほぼ同点でした。

ニーズに合わせて適切な構成を選択してください…

それで誰が勝ったの?それは実際の展開において何を最も重視するかによって異なります。 I/O パフォーマンスに関して最速のビルドには、2 つのドライブ ベイとコンシューマー CPU/RAM のみが搭載されていました。 ZFS では、ECC メモリなどのエンタープライズ コンポーネントが高度なデータ整合性スタックを利用できるようにする必要があるため、非実稼働環境以外のすべてのデプロイメントからはほとんど除外されます。

次に、Brian のビルドを見ていきます。これはハードウェア面で必要なものにはるかに近づき、シャーシ上のドライブ ベイが増加していますが、マザーボードがサポートしているハード ドライブは 4 台のみです。電源からの余分なケーブルもふちまで詰まっていました。結局のところ、中古の NIC と DRAM を eBay に買いに行こうという呼びかけは間違ったものであり、システム全体の安定性は明らかに「不安定」または「ジャンク」のカテゴリーに一歩半入っていました。

DIY 愛好家にとって、それは既製のマイクロサーバーを使用した Kevin のビルドに行き着きました。 Microserver は設置面積が小さく、エントリー価格が低くなります。また、すべてのエンタープライズ コンポーネントや帯域外管理用の iLo などもあります。ただし、システムにはストレージの上限があり、ベイはわずか 4 つで、すべて SATA であるため、高速性はありません。それでも、DIY 予算の TrueNAS CORE システムを導入する場合には、最も抵抗の少ない方法を提供します。

たぶんTrueNAS Miniでしょうか?

TrueNAS Mini X+は、この中でどのような位置づけになるのでしょうか?パフォーマンス面では、適していません。今回ご紹介する構成は、データ耐障害性を重視したものです。しかしながら、Mini X+には、オンボード10GbEなど、いくつかの優れた機能が搭載されています。また、Mini +は、合計7つのドライブベイを備え、ストレージ容量のサポートと柔軟性において、間違いなく最高レベルを誇ります。

このコンテストは、DIY システムをパフォーマンスの観点からランク付けするだけでなく、TrueNAS CORE OS と限られた予算内で何ができるかを明確に示します (この作業の一環として WD からストレージを入手したことはさておき)。ただし、ベンダーからの安心感 (サポート) を必要とする小規模企業にとっては、既製のユニットを入手することが常に最も安全な方法です。明らかに、DIY ルートに進むと、ビルドの一部に少し問題が発生しました。

ターンキー システムの価値は、これが運用環境のユースケースであれば、どれだけ強調してもしすぎることはありません。 iXsystems Mini + は価格が高くなりますが、DIY プラットフォームよりも 3 つの追加ディスクをサポートし、コンポーネント ドライバーのサポートも問題ありませんでした。もちろん、ハードウェアとソフトウェアに対するエンタープライズ サポートもあり、これは DIY ビルドでは提供できません。結局のところ、それはあなたが何を望むかによって決まります。 TrueNAS CORE は、ほぼすべてのハードウェアを処理できる柔軟性があります。

iXsystemsのご協力により、TrueNAS Miniをプレゼントいたします。登録方法の詳細はこちらをご覧ください。

以下のパフォーマンスハイライトビデオでハイライトをご覧ください。

TrueNAS リソース

StorageReview と連携する

ニュースレター| YouTube | ポッドキャスト(iTunes / Spotify) | Instagram | Twitter | TikTok | RSSフィード

アダムアームストロング

Adam は StorageReview.com のニュース編集長で、社内およびフリーランスのコンテンツ チームを管理しています。