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