電子メールストレージサーバーをスケールアップ/スケールアウトするために使用される一般的な方法は何ですか？
私が試したこと：
- 私は2つの電子メールストレージアーキテクチャを持っています。古いものと新しいもの。
古い：
- いくつか（18以上）の1TBストレージサーバー上のcourier-imapds。
- それらの1つがディスク容量不足の兆候を示している場合は、いくつかの電子メールアカウントを別のサーバーに移行します。
- サーバーにはレプリカがありません。バックアップもありません。
新着：
- 単一のdovecot2 巨大 16TB（SATA）ストレージといくつかのSSDを備えたサーバー
- sSDに新しいメールを保存し、doveadmパージを実行して、1日より古いメールをSATAディスクに移動します
- プライマリサーバーから最大15分経過したrsyncバックアップを持つ同一のサーバーがあります
- サーバーあたりのSSDのコストを最小限に抑えるために、上級管理職はサーバーごとにできるだけ多くのストレージを詰め込みたいと考えていました。
- glusterFSがその高いsmall/random-IOの下でうまく複製されなかったため、rsyncが実行されます。
- スケールアウトは、別のペアそのような巨大サーバーをプロビジョニングすることで行われると予想されていました
- 古いアーキテクチャのようにディスククランチの問題に直面した場合、電子メールアカウントの手動移動が行われます。
懸念/疑問：
- 同期的に複製されたファイルシステムのアイデアが、重いランダム/小さなIOに適しているとは確信していません。 GlusterFSはまだ機能していません。このユースケース用に、別のファイルシステムがあるかどうかはわかりません。アイデアは、同一のペアを維持し、電子メール配信とIMAP/POP3アクセスにDNSラウンドロビンを使用することでした。また、いずれかのサーバーが何らかの理由（計画的/計画外）でダウンした場合、IPをペアのもう一方のサーバーに移動します。
- Lustreのようなファイルシステムでは、単一の名前空間を利用できるため、アカウントを手動で移行したり、MAILHOMEパスやその他のメタデータ/データを更新したりする必要がありません。
質問：
- 従来のソフトウェア（courier-imapd/dovecot）でスケールアップ/スケールアウトするために使用される典型的な方法は何ですか？
- ローカルにマウントされたファイルシステムに保存する従来のソフトウェアは、最小限の「問題」でスケールアウトするための障害となりますか？ OpenStackオブジェクトストレージなど、ある種のオブジェクトストレージで動作するようにこれら（の一部）を書き直す必要がありますか？
中規模から大規模の企業で私が見たのは、NetAppやEMCなどの冗長ストレージデバイスです。実際、私は少し前に電子メールストレージについてEMCの担当者と話していましたが、彼は巨大な電子メールサーバーが彼らにとって非常に一般的な販売であると述べました。
基本的に、それらはすべてのストレージの問題をアプリケーションから取り除きます。 SSDまたはバッテリバックアップ式メモリキャッシュを使用すると、多くの短いランダム読み取りのパフォーマンスが実現されます。すべてのストレージが1つの場所にあり、冗長サーバーモジュールへの複数のパスがあるため、レプリケーションの待ち時間はありません。
アプリケーションサーバーは、柔軟性が低いNFSまたはiSCSIを使用してストレージにアクセスしますが、NFSで適切に動作しないアプリケーションで必要になる場合があります。これにより、ストレージを高速イーサネット経由で任意の数のサーバーで共有できるため、ストレージボックスの最大I/Oパフォーマンスに拡張して、必要に応じて拡張できます。
アプリケーションサーバーの冗長性に関しては、最も安価なのはソフトウェアクラスタリングパッケージです。ネットワークレベルでそれを処理し、OSに依存しないBig-IPのようなアプライアンスもあります。アプリケーションが他のインスタンスと並行してNFS上で確実に動作できるかどうかは大きく異なります。
私は大きな鉄のアプローチに少し警戒しています-スケーリングが難しいことが多く、人々はフェイルオーバーソリューションを構築し、停止が発生したときにそれが機能することを期待するアプローチを採用する傾向があります。ほとんどの人はずっと前にこのアプローチをディスクやネットワークカードなどのコンポーネントに適用することをやめましたが、サーバーに適用するのは少し難しいです。 LDAPを介してユーザーを分割することでデータをシャーディングできますが、これはレプリケーションの問題を直接解決しますが、たとえば8ペアの負荷分散サーバーで実行すると、競合が大幅に少なくなる可能性があります。確かに、glusterFS IMHOは、トランザクションの多いシステムではうまく機能しません。また、ニアライン型システム（AFSなど）も良い考えではないと思います。問題は、すべてのミラーで同期的に実行する必要のある小さな変更がたくさんあることです。実際、これは一貫性を維持するためにアプリケーションレベルで行うのが最適です。
Dovecotは、共有ストレージ上の複数のサーバーで動作することを目的としていますが、NFS/iSCSIタイプのアプローチは、負荷分散ではなく、SPOFまたはフェイルオーバータイプのアプローチを意味します。トランザクションワークロード用のGFS2について多くの良い点を聞いています。そして、より小さなシステムに縮小することで、これをDRBD上で実行すると、必要なレプリケーションが得られます。ただし、メインネットワークのノイズを維持するために、専用スイッチでペアを分離する（またはクロスオーバーイーサネット接続を使用する）ようにしてください。
つまり、申し訳ありませんが、このタイプの操作では、dovecotは宅配便よりもはるかに優れていますが、新しいアーキテクチャは一歩後退していると思います。
（mboxではなくmaildirを使用していると思います）
ユーザーのクラスターへのマッピングの固定セットを持つことは少しオーバーヘッドであり、利用可能なリソースの最も効率的な使用法ではないことに同意します-おそらく最良の妥協点はGFS2上のLVSである可能性がありますSANそしてSANにレプリケーション関連のものを処理させる。これは多くの推測作業であり、調査/テストが必要になるが、より安価なソリューションの場合、おそらくFuseファイルシステムをデータベースバックエンド-およびデータベースレプリケーション機能（例：mysqlfs）の使用
実行しているバックエンド作業に加えて、Nginxのimapプロキシを調査することをお勧めします。これは、ユーザー接続を特定のバックエンドサーバーにルーティングできるように設計されています。これは、トラフィックとIO負荷のバランスを取るために、ユーザーのデータを移行しようとするよりも簡単な場合があります。