あなたが達成したい結果、そしてあなたがそれを行うことを決めた方法は、非常に異なるものです。率直に言って、あなたが実装したいものは悪い考えであり、どうにかしてそれを機能させることができれば、それは非常に長い間（または非常にうまく）機能しません。
この質問に答えるのが難しいのは、あなたが実装にまっすぐに飛びついており、あなたの環境や実際に達成しようとしていることについて有用なことを何も説明していないということです。それをしないでください、「あなたの仕事を見せて」ください、あなたはここでより良い結果を得るでしょう。
ただし、可能性、実用性、および有用性を理解するために、いくつかのシナリオを想定してみましょう。
- メールが失われないようにする：（これはあなたが参照するドキュメントが適切にカバーしているので、これはあなたが必要とするものではないと思います）ここで欲しいのは、メール配信と管理インフラストラクチャがどれだけの期間ダウンしているかに関係なく、メールをバウンスし、配信のタイミングを制御できます。このために、「単純な」オフサイトバックアップMXが適切に機能します。バックアップに大量のデータを複製する必要があるため、「シンプル」と言います（すべてのスパム対策ロジック、有効なユーザー/エイリアス情報なので、SMTP時に無効なメールを適切にバウンスできます）。 、自動化可能で、少し注意してかなり簡単に実装できます。すべてのメールをキューに入れるのに十分なディスクがある限り、
- メールシステムの完全な可用性の確保：これはあなたが望むもののように思えますが、単純でもきれいでもありません。基本的に、完全なサイト障害が発生した場合に、ユーザーベースに「フル」メールサービスを提供できるようにする必要があります。レプリケーションは瞬間的ではないため、原則としてこれは実際には不可能ですが、少なくとも妥当なレベルの信頼性を得ることができます。ただし、難しい部分はMTAではありません。メールストア自体です。すべてのメールストレージ操作（新しいメール配信、メッセージ状態の変更、削除）をほぼリアルタイムで2番目のサイトに複製する方法を理解する必要があります。 。定期的なrsyncの安価なオプションを使用できます（最後のrsyncが永久になくなってから何もしないというリスクがあります）フェイルオーバーが必要な場合）、またはさまざまなファイルレベルまたはブロックレベルのレプリケーション手法を使用して、ほぼリアルタイムで同期を維持しようとします（非常に複雑な構成と操作と引き換えにデータ損失の量を減らします） 。一部のメールシステムは、組み込みのレプリケーションをサポートしているため、作業が楽になります。その後、フェールオーバーの問題があり、それをどのように実行しますか？それからフェイルバックしますが、これは再び難しくなり、最後に定期的にテストする必要があります。何かを壊す...
基本的に、後者のオプションは苦痛で迷惑です。私の個人的な好みは、あなたがそれを逃れることができるなら（そしてあなたがどれくらいの頻度でできるか驚かれることでしょう）、本当に良い、頑丈なバスケットを持っていることを確認した後、すべての卵を1つのバスケットに入れることです（適切なシステムエンジニアリング）、バスケットパッチとツールの在庫を手元に置いて（高回復性に焦点を当てる）、時々、いくつかの卵が壊れる可能性があることを人々に知らせることで、本当に申し訳ありませんが、人生は完璧ではありません（合理的でないSLA保証を行わないでください）。
超高可用性が必要な場合があり、それを保証するシステムを構築しましたが、それらは単純ではなく、多くの場合、費用対効果が高くありません。これが私たちの目的です。はい、HAはクールでセクシーで、複雑な巨大な怪物を構築するオタクの信用を得ていますが、私たちはエゴを打つためにここにいるわけではありません。私たちはビジネス価値を提供するためにここにいます。申し訳ありませんが、Rube Goldbergの高可用性マルチサイトメールクラスターは、シンプルで堅牢なメールサービスほどの価値を提供することはないでしょう。メールが停止して申し訳ありません。1時間以内にシステムが復旧します。コーヒーとマフィンをお持ちください。