40TBサーバー構成の健全性チェック

私はコンピューティングで40年を過ごしましたが、このようなサーバーを構築する必要はなかったので、これはn00bの質問かもしれません。

ダウンロード用に超高解像度の音楽ファイルを提供するクライアントがあります。この場合、FLACで圧縮された24 / 192Khz =〜10GB /アルバムを意味します。（いいえ、製品の望ましさについて議論したくはありません。サーバーの構成だけです。）カタログは、約3,000枚のアルバムで、超高低バージョン（iPodの場合）の両方で、約35〜40 TB程度のプライマリデータ。

これは非常に特殊な製品であるため、市場規模は比較的小さく（オーディオシステムに2万ドル以上を費やす人々）、ほとんどの場合、サーバーは100％アイドル（またはそれに近い状態）になります。ColocationAmericaが提供する1 Gbps接続と帯域幅約$ 20 / TBの優れたコロケーションオファーのようなものがあるので、今は商品を配達するための箱を作る必要があります。

データアクセスのユースケースは、1回書き込み/複数読み取りなので、ドライブのペアにソフトウェアRAID 1を使用することを考えています。これは私を許可します（私は思うことにより、いくつかのシステム管理者がシステム（彼らは無料のスワップアウトを行う）に赤色光を気づく前に、2番目のドライブの再構築を開始することができるという、オンザフライで失敗したもののために再構成スペアドライブに）。ほとんどのドライブが必要ない場合、ほとんどのドライブをスリープ/スピンダウンできるようになれば、それは素晴らしいことです。

計算能力の面ではあまり必要ありません-これはパイプに脂肪質のオブジェクトを押し込むだけです。したがって、この数のドライブをサポートできる限り、CPU /マザーボードはかなり控えめになります。

現在、次の構成を検討しています。

Chasis: Supermicro CSE-847E26-RJBOD1
Drives: 30 4TB SAS drives (Seagate ST4000NM0023 ?)
MB: SUPERMICRO MBD-X10SAE-O w/ 8GB
CPU: Xeon E3-1220V3 3.1GHz LGA 1150 80W Quad-Core Server

だから、私は正しい方向に進んでいますか、またはこれは問題にアプローチする完全にn00b /恐竜の方法ですか？

更新して、いくつかのポイントを明確にします。

1. 私が所有した最後のSun製品は80年代後半に戻っていたため、ZFSの経験はありません。それが正しいかどうかを確認するために、少しRTFMingを行います。
2. ファイル名は単純なUUIDになり、オブジェクトはドライブ全体でバランスがとられるため（大規模なキャッシュシステムのように）、ファイルシステムが目を見張るようなことをする必要はありません。だから、私はこれらを40の独立したファイルシステムと本当に考えていたので、RAID 1が適切に聞こえるようになりました（ただし、ここでは無知を認めます）。
3. 私たちの現在の期待は、一度に数ダース以上のファイルをダウンロードする可能性は低いことであり、ほとんどの場合、特定のファイルをダウンロードするのは1人だけであるため、大量のメモリが必要かどうかはわかりませんバッファ用。8GBは少し軽いかもしれませんが、128GBがエネルギーを消費する以上のことをするとは思いません。
4. ここには記載されていない2つの個別のマシンがあります。現在のWebストア、およびすべての認証、新製品の取り込み管理、ポリシーの施行（結局、これは RIAAの遊び場）、一時URLの作成（および場合によってはトラフィックが予想を超える場合、これらの複数の獣にダウンロードを渡す）、使用状況の追跡、レポートの生成。つまり、このマシンは、Qualudesでスナネズミを使用してほぼ構築できるということです。

ZFS？利点はどこですか？

わかりました、複数のZFSガイド、FAQなどを読み進めています。ばかげたことを許してくれますが、N RAID1ペアという以前の概念よりもZFSを使用する利点を本当に理解しようとしています。この上のベストプラクティス（2006年）のページ、彼らもお勧めではない 48のデバイスのZFSをやってますが、24 2-デバイスミラー-種類の私がやって話していたもののように聞こえます。他のページでは、1つの（1つの）ZFSブロックを配信するためにアクセスする必要のあるデバイスの数について言及しています。また、オブジェクトあたり10GB、ディスク使用率80％で、4TBドライブあたり合計320個のファイルを保存していることを忘れないでください。ドライブ障害が発生した場合のN RAID 1での再構築時間は、あるデバイスから別のデバイスへの4TBの書き込みです。ZFSはこれをどのように改善しますか？

私は恐竜であることを認めますが、ディスクは安価であり、RAID 1は理解しています。ファイル管理のニーズはささいなものであり、Linux上のZFS（私の好みのOS）はまだ若いです。たぶん私は保守的すぎるかもしれませんが、私は本番システムを見ているとき、それは私がロールバックする方法です。

このことについて考えさせてくれたあなたのコメントに感謝します。私はまだ完全には決まっていないので、戻ってきてさらにn00bの質問をする必要があるかもしれません。

問題の説明に基づくと、問題はサーバーほどストレージではありません。ZFSの
ような信頼性が高く堅牢なファイルシステムが必要です。このシステムは、大容量のストレージを適切に処理するように設計されており、システムの終わりを管理しやすくする管理機能が組み込まれています。

コメントで言及されたように、ストレージプールにはZFSを使用します（おそらくFreeBSDでは、そのオペレーティングシステムに最も精通しており、ZFSで安定したパフォーマンスの長い実績のある実績があるため、2番目の選択肢です） OS も十分にテストされたZFSのサポートによりIllumosになります）。

ファイルを提供する限り、私は同意します。ネットワークポートからデータをプッシュするだけで、ハードウェアに関してはあまり必要ありません。CPU / RAMの主なドライバーは、ファイルシステム（ZFS）のニーズになります。
一般的な経験則では、ZFSは1GBのRAMに加えて、管理するディスク容量の10TBごとに1GBを必要とします（したがって、40TBの場合、ZFSには5GBのRAMが必要になります）-関係は直線的ではありませんZFSに関する優れた書籍/チュートリアル/ドキュメントは、環境の見積もりを立てるのに役立ちます）。
重複排除のようなZFSの機能を追加するには、より多くのRAMが必要になることに注意してください。

明らかにRAMの要件を切り詰めるのではなく切り上げ、けちくさにしないでください：5GBのRAMが必要と計算された場合、サーバーに8GBをロードしないでください-最大16GBまでステップアップします。

次に、ストレージボックスでサーバーを直接実行するか（サーバープロセスをサポートするためにそのボックスにさらに多くのRAMが必要になることを意味します）、またはストレージを「フロントエンド」サーバーにリモートマウントします。実際にクライアントのリクエストを処理します。
（前者は最初は安価であり、後者は長期的に優れています）。

このアドバイスに加えて、私が提供できる最良の提案は、キャパシティプランニングの一連の質問（基本的に「負荷テスト、負荷テスト、負荷テスト」）で既に十分に説明されています。

マルチTBサーバーにZFSを使用していますが、これは非常に堅牢です。OpenIndianaを使用して開始しましたが、FreeNASが必要な処理を行うため、FreeNASに移行しました。

SASエクスパンダを搭載したLSI HBAカード（9211-8iは良いベースカード）を使用することをお勧めします（LSIチップセットに基づいた統合SASエクスパンダを搭載したSuperMicroケースを注文できます）。LSIファームウェアは、FreeNASおよびFreeBSDでサポートされています。適切なバージョンを確認します（FreeBSD V9.xではV16が適しています）。

書き込みがシステムの多くの性質を読み取った場合、ZFS Z2トポロジを使用します（このサイズのドライブでRAID-5とZ1を使用しないでください）。4TBのディスクを使用している場合、プールがいっぱいになると、大きな単一のvDevアレイの再構築（再構築）時間は長くなります。再構築に時間がかかるのを避けるため、vDevを6または10のグループに分けてプールを作成します（FreeNASのドキュメントからの推奨事項）。3台の6ドライブvDev（4TBドライブを想定）で構成されるプールは、〜48TBの使用可能な容量を持ち、良好なレベルのフォールトトレランスを提供します（RAIDはバックアップに置き換わらないので、バックアップする必要があることを思い出してください）。

一般的にアクセスされるファイルの速度を上げるために、L2ARC用のSSDをいくつか投入できます（アプリケーションには必要ないかもしれませんが、120GB SSDにはかなり安いです）。

また、述べたように、大量のRAMを使用します。システム内の他のハードウェアを考えれば、64GBはそれほど高価ではありません。残念ながら、より小さいXEONは32GB以上を使用できません。あなたはそれを試すことができましたが、ZFSの文献によると、RAMが多いほど良いと思います（32GBのRAMと24TBの容量のZ2アレイで言及したXEONを使用し、正常に動作します）。

ZFSのもう1つの利点は、定期的なスナップショットを設定できることです。これにより、以前のバージョンを簡単に復元でき、スナップショットのスペース効率が非常に高くなります。さらに、スナップショットを別のデータセット（ローカルまたはリモート）に複製できます。これは、セキュリティのためにSSH経由で実行できます。

ZFSシステムの信頼性は本当に好きです。また、ハードウェアに依存しないという事実も気に入っています!! ドライブを表示できるシステムであれば、プールをインポートできます。ハードウェアRAIDで発生する可能性のあるファームウェアの依存関係などはありません（より良いカードの問題ではありませんが、HBAカードよりも高価であり、ドライバーなどが必要です-これまでに少しずつ）。

この投稿が古いことを考えると、おそらく解決策があるでしょう。もしそうなら、あなたが作ったものを教えてください？

乾杯、