web-dev-qa-db-ja.com

40TBサーバー構成のサニティチェック

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

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

これは非常に特殊な製品であるため、市場規模は比較的小さく（たとえば、オーディオシステムに20,000ドル以上を費やしている人）、ほとんどの場合、サーバーは100％アイドル状態（またはそれに近い状態）になります。 1Gbpsの接続と約20/TBの帯域幅を備えたColocationAmericaからの優れたコロケーションオファーのように見えるので、商品を配送するためのボックスを作成する必要があります。

データアクセスのユースケースは、1回限りの書き込み/多くの読み取りなので、ドライブのペアにソフトウェアRAID 1を使用することを考えています。これにより、（I think）障害のあるドライブのスペアドライブをオンザフライで再構成できるため、一部のシステム管理者がシステムの赤信号に気付く前に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の経験がありません。それが正しいかどうかを確認するために、少しRTFMを行います。
  2. ファイル名は単純なUUIDになり、オブジェクトはドライブ間でバランスが取られるため（大規模なキャッシュシステムのようなもの）、ファイルシステムが見事なことをする必要はありません。だから私は本当にこれらを40の別々のファイルシステムとして考えていました、そしてそれはRAID 1をほぼ正しいように聞こえさせました（しかし私はここで無知を認めます）。
  3. 私たちの現在の予想では、一度に数十を超えるファイルをダウンロードする可能性は低く、ほとんどの場合、特定のファイルをダウンロードするのは1人だけであるため、大量のメモリが必要かどうかはわかりません。バッファ用。たぶん8GBは少し軽いかもしれませんが、128GBはエネルギーを消費する以上のことはしないと思います。
  4. ここで言及されていない2つの別個のマシンがあります。それらの現在のWebストアと、すべての認証、新製品の取り込み管理、ポリシーの適用を処理するほぼ完全に分離されたダウンロードマスター（結局のところ、これはis RIAAの遊び場です） 、一時的なURLの作成（およびトラフィックが予想を超える場合は、これらの獣の複数にダウンロードを渡す可能性があります）、使用状況の追跡、およびレポートの生成。つまり、thisマシンは、Quaaludesでスナネズミを使用してほぼ構築できるということです。

ZFS？メリットはどこにありますか？

OK、私は複数のZFSガイドやFAQなどを読んでいます。愚かに聞こえることを許してください、しかし私は本当に理解しようとしています利点 NRAID1の私の前衛的な概念よりもZFSを使用することのペア。この ベストプラクティス ページ（2006年から）では、not 48デバイスのZFSを実行することも提案されていますが、24の2デバイスミラー-は私がそうであったように聞こえますすることについて話します。他のページには、1つのZFSブロックを配信するためにアクセスする必要のあるデバイスの数が記載されています。また、オブジェクトあたり10 GB、ディスク使用率が80％の場合、合計320ファイルを保存することを覚えておいてください4 TBドライブあたり。 N RAID 1での再構築時間は、特定のドライブ障害の場合、あるデバイスから別のデバイスへの4TBの書き込みです。 ZFSはこれをどのように改善しますか？

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

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

zfssoftware-raidsas
21
Peter Rowell

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

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

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

明らかにラウンドRAM要件は下がるのではなく上になり、けちなことはありません：数学で5GBのRAMサーバーに8GBをロードしないでください-16GBまでステップアップ。

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

このアドバイスを超えて、私があなたに与えることができる最良の提案は、すでに十分にカバーされています キャパシティプランニングの一連の質問 -基本的に「負荷テスト、負荷テスト、 負荷テスト "。

12
voretaq7

私はマルチTBサーバーにZFSを使用していますが、それは堅実です。私はOpenIndianaを使って始め、FreeNASに移動しました。必要なことを行うためです。

SASエクスパンダー（SuperMicroケースは一体型SASエクスパンダーで注文できます）と一緒にLSI HBAカード（9211-8iが良いベースカードです）を使用することをお勧めしますLSIファームウェアはFreeNASとFreeBSDでサポートされています。適切なバージョンを確認してください（V16はFreeBSD V9.xに適しています）。

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

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

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

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

私はZFSシステムの信頼性が本当に好きです。また、ハードウェアに依存しないという点も気に入っています。ドライブを認識できるすべてのシステムがプールをインポートできます。ハードウェアレイドで発生する可能性のあるファームウェアの依存関係などはありません（より優れたカードの問題ではありませんが、HBAカードよりも高価であり、ドライバーなどが必要です。

この投稿が古いことを考えると、おそらく解決策があります。もしそうなら、あなたが作ったものを教えてくれませんか？

乾杯、

2
Scharbag