マルチデバイス上のBtrfs上のNFS.vs。分散ボリュームのGlusterfs？
メール用のストレージを検討しています。このストレージシステムは私自身のプライベートクラウド（すでに複製されている）で実行されているので、複製については気にしません。
私は2つのオプションについて考えています：
1-いくつかの「ディスク」（クラウド上のボリューム）を作成し、マルチディスク上にBtrfsファイルシステムを作成します。ファイルシステムがいっぱいになったら、さらに「ディスク」を作成し、次の方法でbtrfsファイルシステムに追加します。
btrfs device add /dev/vdX /mnt
btrfs filesystem balance /mnt
このマウントポイント（/ mnt）はNFS経由で公開され、私のDovecotサーバーはこのエクスポートをマウントし、そこに電子メールを保存します。
2-いくつかの「ディスク」（クラウド上のボリューム）を作成し、これらのディスク全体にGlusterFS分散ボリュームを作成します。ファイルシステムがいっぱいになったら、さらに「ディスク」を作成し、新しい「ディスク」をGlusterFS分散ボリュームに追加して、バランスを取り直します。私のDovecoteは、glusterfs-clientを使用してこのボリュームをマウントし、そこにメールを保存します。
（繰り返し：私の「ディスク」、プライベートクラウド上のボリューム、複製されたアンダーフードのため、複製は必要ありません）
どのオプションの方が良いと思いますか：
- パフォーマンス？ （多くの小さな読み取り/書き込みI/O）
- 安定していますか？
- フレキシブル？
メールサーバーのI/Oパターンを考慮する必要があります。読み取り/書き込み多く小さなファイルをできるだけ速くします。両方のバリアントは、多数のクライアント、IMHOを処理する場合、これには本当に適していません。
どちらもFSは十分に高速ではなく、特にGlusterFSのロックオーバーヘッドが重要になると思います。次に、独自のオーバーヘッドを持つNFSで別のレイヤーを追加します。これの代わりに、メールストアを可能な限り小さなオーバーヘッドと高速なファイルシステムで接続します。通常、これは可能な限り物理ストレージに直接接続することを意味しますが、アーキテクチャを「プライベートクラウド」などのでたらめなビンゴ用語の背後に隠すため、何が可能かわからない。
試すことができる1つのアプローチは、iSCSI経由でストレージをメールサーバーにエクスポートしてから、FSを使用することです。これは、多くの小さなファイルで高速です。本当に重要な場合は、LVMを使用してそのFSに追加のiSCSIボリュームの形でスペースを簡単に追加します（これによりオーバーヘッドがいくらか追加されます）。
ただし、何をしようとしても：さまざまなバリアントのベンチマークを行い、必要なパフォーマンスが得られるかどうかを確認する必要があります。
上記の2つから1つを選択する必要がある場合は、NFSの方が望ましいと思います。
OpenStackボリュームは引き続き中央ストレージからマウントされるため、GlusterFSはセットアップ内の分散ファイルシステムとしてのすべての利点を失います。 NFSロックが単一サーバーで実行されている間は分散ファイルロックを考慮する必要があるため、安定性もスマート性も高くありません。
複数のデバイスのストレージを組み合わせるのが良い考えかどうかはわかりません。あるいは、高レベルのOpenStackボリュームサービスの機能をスキップして、ストレージを直接公開することを検討することもできます-NFSによってエクスポートされたフォーマット済みのLVM（/ ZFS/SAN）ボリューム。このようにすると、不要なiSCSIレベルが排除され、メインストレージに十分な空き領域がある限り、オンデマンドでメールストレージスペースを増やすことができます。