150 TBと成長していますが、成長方法は？

私のグループには現在、2台の大型ストレージサーバーがあり、どちらもNASがdebian linuxを実行しています。1つ目は、数年前のオールインワン24ディスク（SATA）サーバーです。2つのハードウェアRAIDが設定されており、それらの上にLVMがあります。2番目のサーバーは、4つのエンクロージャーに分割された64個のディスクで、それぞれが外部SASを介して接続されたハードウェアRAID 6です。XFSとその上のLVMを使用して、100 TBの使用可能なストレージを作成します。これらはすべてうまく機能しますが、これらのシステムよりも成長しています。そのようなサーバーを2つ構築し、まだ成長しているので、将来の成長、バックアップオプション、ディスク障害下でより良い動作（より大きなファイルシステムのチェックには1日以上かかる）に関してより柔軟なものを構築できるようにしたい重度の並行環境で稼働します（小さなコンピュータークラスターを考えてください）。システム管理サポートはありませんが、

そのため、将来の成長と柔軟な構成を可能にする、比較的低コストで許容可能なパフォーマンスストレージソリューションを求めています（異なる動作特性を持つ異なるプールを備えたZFSを考えてください）。私たちはおそらく単一のNASの領域外にいるでしょう。ZFS（たとえばopenindiana）またはサーバーごとのbtrfsと、その上で実行するglusterfsの組み合わせについて考えてきました。私たちがそれに対して評価しているのは、単に弾丸をかみ、Isilonまたは3Parストレージソリューションに投資することです。

提案や経験は大歓迎です。

これが少し役立つと思います。私はそれがテキストの完全な壁にならないようにしました。:)

3Par / Isilon

SAN管理者の役割を担い、夜間の仕事の代わりに夜間睡眠で痛みのない生活を楽しみたい人に一定の工数を捧げることができ、そうするなら、これが私が行く方法です。

SANを使用すると、単一の「ストレージ」で制限されるすべてのことを実行できます（つまり、purestorageフラッシュアレイと3parの大きなsataモンスターを同じサーバーに接続します）。柔軟性を利用したい場合。

代替案

アンプリデータ

長所：スケールアウト、安価、優れたコンセプトと専用の読み取り/書き込みキャッシュレイヤーで設計されています。これは実際にはあなたにとって最高のものかもしれません。

RisingTideOS

彼らのターゲットソフトウェアは現在、ほぼすべてのLinuxストレージで使用されており、プレーンなLinux / Glusterのものよりも少し優れた管理を可能にしています。（Imho）商用版は一見の価値があるかもしれません。

Gluster / btrfs

PRO：スケールアウトと「ブリック」は、管理に非常に適した抽象化レイヤーを提供します。

CON：最初は、私にとっては合計PITAでした。堅牢ではなく、障害は1つのブリックに限定される場合もあれば、すべてを破壊する場合もあります。さて、コントロール内のRedHatでそれは実際に働くものになるかもしれないし、私も人会ったことができ、それは数年のために働くようにそれを飼いならすを。そして2つ目はまだ半分実験的です。通常、FSは「完了」してから実証済みで堅牢になるまで3〜4年かかります。データに関心がある場合、なぜこれを考慮するのでしょうか？実験的なCephの商用サポートについては、現在ほとんど公開されていませんが、「RBD」レイヤーに固執する必要があります。FSはまだ十分にテストされていません。Cephが長期的にははるかに魅力的であることを明確にします。:)

ZFS

Pro：他のもののcoに釘を確実に入れる機能。これらの機能は適切に設計されており（L2ARCについて）、圧縮/重複除去は楽しいです。より多くの「ストレージクラスター」があります。これは、1つの大きな統合ブームではなく、わずかな障害のみが発生していることを意味します。

短所：実際のストレージではなく、多くの小さなソフトウェアボックスを維持します。堅牢なセットアップを行うには、それらを統合して$$$時間を費やす必要があります。

XFS + LVMルートは、過去数年でスケールアウトされた純粋なLinuxストレージソリューションの最適な選択肢の1つです。すでにそこにいることをお勧めします。さらに成長する必要があるので、使用可能なオプションがいくつかあります。

ご存知のように、世界の大手ハードウェアベンダーには、ストレージ用のNASヘッドがあります。これにより、単一のベンダーがすべてを実現することができ、かなりうまく機能します。入るのは簡単なソリューションであり（DIYに比べて）、保守性は低くなります。しかし、彼らはかなりの費用がかかります。一方では、インフラストラクチャの問題ではなく、主な問題を解決するためのエンジニアリングリソースが増えます。一方で、あなたがほとんどの大学の学部のようなら、私は人事が物事のために現金を払うことに比べて本当に安いことを知っています。

DIYのルートに進むと、利用可能なDIYオプションを既に十分に理解しています。ZFS / BTRFSは、スケールアウトストレージ用のXFS + LVMからの明らかなアップグレードパスです。Linuxメインラインカーネルで「安定」と宣言されるまで、BTRFSを避けます。主要な無料のディストリビューションのいくつかがこれをデフォルトのファイルシステムとして使用しているので、すぐにそうなるはずです。ZFSの場合、OpenIndianaではなくBSDベースを使用することをお勧めします。それは単に、それがより長く、キンク（より多く）がうまく機能しているからです。

Glusterは、ここで説明するユースケース用に設計されています。レプリケーションを実行できるだけでなく、多数のストレージが接続された単一の仮想サーバーを提供できます。彼らの分散ボリュームは、彼らが宣言したボリューム上のすべてのストレージ・サーバ上のファイルを分散するので、あなたが探しているまさに聞こえます。個別のストレージサーバーを追加して、表示可能なボリュームを拡大し続けることができます。単一の名前空間！

Glusterの落とし穴は、クライアントがCIFSまたはNFSオプションではなくGluster Clientを使用してシステムにアクセスできる場合に最適です。小規模なクラスター計算クラスターを実行しているため、GlusterFSクライアントを利用できる場合があります。

あなたはここで正しい軌道に乗っています。

私が理解している限り、Linux SCST + FibreChannelまたはinfinibandに基づくSANソリューションを使用できますが、これは現在構築中のものです。LUNのベースとして、ハードウェアRAID上でLVMを使用し、ファイルシステムレベル以下のスナップショット/レプリケーション（例としてDRBDを使用）を処理できます。ファイルシステムとして、ノードの上にESXiを配置しているため、同時性の良い解決策を知りません。そのため、データストアはESXコンカレントFSによって管理されます。GFS2はその環境で動作するかもしれませんが、正確な要件を確認する必要があるため、100％確実ではありません。とにかく、ノードの下に堅牢なSANがあれば、簡単に作業を完了できます。