web-dev-qa-db-ja.com

高可用性Postfixシステムを構築するには?

Postfixサーバーのリモートミラーをセットアップする必要があります(この場合、両方のメールサーバーのコンテンツは常に同じである必要があります)。

考えは、ある時点でメインサーバーがダウンした場合、ミラーサーバーが代わりになり、新しい受信メールを管理し、電子メールサーバーが再び起動すると、新しい電子メールで更新して戻るというものです。新しい受信メールを管理するためのコントロールです。

メールサーバーはさまざまな場所(つまり、maindomain.com、themirrorsite.com)でホストされます。

単純なバックアップサーバーを入手することはそれほど難しくはありません。

しかし、問題は、この構成ではバックアップサイトがメインメールサーバーの完全なミラーにならないことです(メインサーバーがダウンしているときに受信した電子メールのみが保持されます)。

必要な構成を実現する方法はありますか?

12
VanHackman

達成したい結果と、それを実行することに決めた方法は、まったく異なります。率直に言って、実装したいことは悪い考えであり、どうにかしてそれを機能させることができたとしても、それは非常に長く(または非常に)機能しません。

この質問の答えを難しくしているのは、実装にまっすぐ進み、環境について、または実際に達成しようとしていることについてanythingを説明していないことです。それを行わないでください。「動作を表示」すると、ここではるかに良い結果が得られます。

ただし、いくつかのシナリオを取り上げて、何が可能で、実用的で、何が便利かをお見せします。

  • メールが失われないようにする:(あなたが参照するドキュメントがそれを適切にカバーしているので、これはあなたが必要とするものではないと思います)あなたがしたいすべてメールの配信と管理のインフラストラクチャがダウンしている期間に関係なく、メールが返送されることはなく、いつ配信するかを制御できます。このため、「シンプルな」オフサイトバックアップMXが適切に機能します。多くのデータをバックアップに複製する必要があるため(すべてのスパム対策ロジック、SMTP時に無効なメールを適切にバウンスできるように、有効なユーザー/エイリアス情報など)、「単純」と言いますが、すべてスクリプト可能です、自動化可能であり、少し注意してかなり簡単に実装できます。すべてのメールをキューに入れるのに十分なディスクがある限り、プライマリサイトが戻ってバックアップMXをポークし、それがメールインフラストラクチャとユーザーにメールのメトリックバットロードをダンプするまで、数週間または数か月キューできます。 「aaaaaaahhh!」
  • メールシステムの完全な可用性の確保:これはあなたが望んでいることのように聞こえますが、単純でもきれいでもありません。基本的に、完全なサイト障害が発生した場合に、ユーザーベースに「完全な」メールサービスを提供できるようにしたいと考えています。レプリケーションは瞬時ではないため、原則としてこれは実際には不可能ですが、少なくとも妥当なレベルの信頼性を得ることができます。ただし、難しいのはMTAではありません。それはメールストアそのものです。すべてのメールストレージ操作(新着メールの配信、メッセージの状態の変更、削除)をほぼリアルタイムで2番目のサイトに複製する方法を理解する必要があります-ライブのサイトに応じて、両方の方法でそれを実行します。定期的なrsyncの安価なオプション(最後のrsync以降に何も行われないというリスクがありますforeverフェイルオーバーが必要な場合)、またはさまざまなファイルレベルまたはブロックレベルのレプリケーションを実行できますほぼリアルタイムで物事を同期させて維持する手法(大幅に複雑な構成と操作と引き換えに、データ損失の量を減らします)。一部のメールシステムは、ある種のレプリケーションをサポートしているため、作業が楽になります。次に、フェイルオーバーの全体的な問題とその方法、そして失敗するbackが再び困難になります。最後に、定期的にテストして、OSのアップグレードを確認する必要があります。しばらく前に何も壊さなかった...

基本的に、後者のオプションは苦痛で面倒です。私の個人的な好みは、あなたがそれをうまくやることができるなら(そしてあなたがどれほどの頻度で驚くことができるか)、本当に良い頑丈なバスケット(適切なシステムエンジニアリング)を持っていることを確認した後、すべての卵を1つのバスケットに入れることです)、手持ちのバスケットパッチとツールの在庫を維持し( (高い回復可能性 に焦点を当てて)、時々、数個の卵が壊れる可能性があることを人々に知ってもらい、あなたは本当に申し訳ありませんが、人生は完璧ではありません(SLAが妥当でないことを保証しないでください)。

超高可用性が必要な場合があります。私はそれを保証するシステムを構築しましたが、それらは単純ではなく、多くの場合、費用対効果が高くありません。それが私たちの目的です。はい、HAはクールでセクシーです。あなたは複雑さのそびえ立つ巨大な怪物を構築するためにオタクの信用を得ますが、私たちはエゴを撫でるためにここにいるわけではありません。私たちはビジネス価値を提供するためにここにいますが、申し訳ありませんが、Rube Goldbergの高可用性マルチサイトメールクラスターは、シンプルで堅牢なメールサービスや時折「私たちのメールが切れてすみません。システムは1時間後に元に戻ります。お気軽にコーヒーとマフィンをお届けします」と発表しました。

22
womble

dbmail を使用して同様のソリューションを実現しました。 dbmailはすべての電子メールをデータベースに格納します。データベースの複製を設定して、メールがリモートの場所にも保存されるようにすることができます。電子メールだけでなくデータベースも管理する必要があるため、メールシステムの管理が複雑になります。

1
Yavor Shahpasov

これは、MX DNSフェイルオーバー+データ複製システムによって実現できます。

MXフェイルオーバーの場合: 2つのメールサーバー、バックアップサーバーのDNS構成のヘルプが必要

データ複製の場合: http://www.drbd.org/docs/install/

-$

1
SparX

必要なのはPostfixレプリケーションです。Postfixがネイティブでサポートしているとは思いません。私が他の人が使用しているのを見たソリューションは、分散ファイルシステムを使用してサーバー間でPostfixデータファイルを複製することです。

0
Klox