web-dev-qa-db-ja.com

big NASを実装するためのCephまたはGluster

NASソリューションの構築を計画しています。このソリューションは、主にNFSおよびCIFSを介して使用され、さまざまなアーカイブアプリケーションからより「リアルタイムの処理」に至るまでのワークロードに使用されます。 NASは仮想マシンのブロックストレージとして使用されないため、アクセスは常にファイル指向になります。

主に2つのデザインを検討しており、ご意見、ご意見、洞察、経験をお寄せください。

どちらの設計も、「ある程度の分散ストレージソフトウェア」を利用しています。どちらの設計もコモディティサーバーから構築され、成長に合わせて拡張する必要があります。どちらの設計にも、NFSおよびCIFSプロトコルを提供する「アクセス仮想マシン」をインスタンス化するための仮想化が含まれます。この意味で、アクセスレイヤーはデータレイヤー自体から切り離されています。

最初の設計は、GlusterやCephFSなどの分散ファイルシステムに基づいています。これらのコモディティサーバーにこのソフトウェアを展開し、結果のファイルシステムを「アクセス仮想マシン」にマウントし、NFS/CIFSを介してマウントされたファイルシステムを提供します。

2番目の設計は、CEPHを使用した分散ブロックストレージに基づいています。したがって、これらのコモディティサーバーに分散ブロックストレージを構築し、仮想化（OpenStack Cinderなど）を介して、ブロックストレージをアクセスVMに割り当てます。アクセスVMの内部では、ブロックストレージを単一のファイルシステムに集約するZFSを展開します。そして、このファイルシステムは、まったく同じVMからNFS/CIFSを介して提供されます。

アドバイスや洞察は高く評価されています。見たところ単純なアーキテクチャ（ファイルシステムレイヤーではなくブロックレイヤーでのデータ分散）のため、内部では「モンスターVM」アプローチに傾いているとも言えます。

乾杯、プレマ

storageglusterfsarchitectureceph
2
prema

最初のデザイン：

Gluster +（NFS [〜＃〜] or [〜＃〜] GaneshaNFS）クラスター

アクセスVMがありません。この場合、GlusterのアーキテクチャはCephFSよりも単純です。 Glusterには、ノードと容量の追加に関するいくつかのルールがあります。大丈夫です。最初から計画してください。

2番目の設計：

目標がシングルアクセスVMでNFS/CIFSを提供することである場合、LinuxはCephをブロックデバイスとしてマウントできます。したがって、次のようなスタックがあります。

LinuxのNFS/CIFS-Ceph RBD

アクセスVMにHAが必要な場合は、HAクラスターを追加します。

Linux HAクラスターのNFS/CIFS-Ceph RBD

または、Ceph RBDの代わりにCeph iSCSIゲートウェイを使用できます。

考慮すべき事柄：

  1. スケールアップする
  2. データ保護：2つまたは3つのコピー、消去/シャーディング
  3. まともなパフォーマンスには、エンタープライズSATAおよびSSDディスクを使用してください
  4. オンライン/オフラインのアップグレード
  5. 他のソリューション：例DRBD
1
dario