- - PR -
メールスプールサーバの冗長化について
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-12-18 16:29
現在、1万人ほどをユーザ用にメールスプールサーバを構築しようとしてます。
冗長構成が必須と考えておりますが、POP3(S/Wは未定)の冗長化については、検索した限りでは情報がなく、困っている状態です。 OSはRedhat Enterprise Server Ver4となりますが、適切な冗長化のためのS/Wをご存知でしたらご教示のほどお願いいたします。 スプールサーバの機能としては、マルチドメイン、バーチャルアカウントが含まれます。 | ||||||||
|
投稿日時: 2005-12-19 23:14
こんばんわ.
S/W は software のことですよね? ※こういう言葉を惜しまないほうが良いと思いますよ. 何を実現したいのか良く分かりません. 例えば複数の MRA に NFS 経由で単一の e_mail spool を参照させたいとか, そういう意味のお話ですか? もう少し具体的に書かないと「何がしたいのだろう?」で終わってしまうと思います. 以上,ご参考までに. | ||||||||
|
投稿日時: 2005-12-20 09:29
ぱっと浮かぶのは、商用版のsendmail
http://www.sendmail.com/jp/ 1万人くらいなら楽勝と思いますが... | ||||||||
|
投稿日時: 2005-12-21 15:07
こんにちわ.
このお話は Sendmail Message Access Proxy のあたりのことでしょうか? imap/pop3 proxy から複数の message store に振り分けるのは面白いと思いますけど, これって冗長化なのでしょうか?負荷分散ではあるでしょうけど. 先ほど購入した Software *esign に brdb なるものが載ってました. apache で HA 構成をするためのもののようです. 斜め読みしただけですが,spool server の冗長構成もできそうな気がします. ※あくまでも「気がする」だけですが. どなたか運用されている人,いますかね? | ||||||||
|
投稿日時: 2005-12-21 17:55
まず、1万アカウント以上という事で、通常のmbox形式での管理でないメールサーバが良いかなと考えています。 ということで、商用のSendmailとか良さげに思われます。
(SUNの商用メールサーバも耐えられるような事を以前に読んだ気がしますが、気のせいかも知れません..。) SAMS(POP/IMAP)をSendmail Message Access Proxyで統合するように構成し、Sendmail Message Access ProxyをHA化(単一経路となっている部分はどんな構成や機材を使ってももそこに潜在的な弱点がありますね。)するという構成じゃないかと思われますが如何でしょうか? そうそう、SAMSで管理するデータは、SANとかNASとか使って共有アクセス可能にしておく形が宜しいかと思われます。 POPのロードバランサのような製品があるなら、Sendmail Message Access Proxyの代わりに使う事が可能なように見えますが、実際にはアカウント認証後のコネクションを維持し、かつ、障害時に別経路へスムーズに移行させる必要がある事から、結局はSendmailの場合にはSendmail Message Access Proxyを導入するのが現実的かも。 HA化はコストとの対費用効果のバランスが不可欠なので何が何でもHA化するか、ある程度は運用で逃げるかは検討が必要ですね。(HAパラノイアなら、エッジ部分まで含めてLANの冗長化までこだわる事になります。で、出来上がるのは同じシステムが2つと、コスト>2倍・障害発生率>2倍のシステムか? (-.-) ) パフォーマンスが出るならコスト的には、2台のメールサーバを共有ディスクを使うように構成して、クラスタリングとかで1台をスタンドバイ状態とする構成が安上がりかと思います。(SUNとかで4CPU-SMP×2マシン でいけるか>誰かフォローお願いします。 でも、この構成だと今度はネットワークにボトルネックが.... トランキングか?) この辺りは経験のあるSIerさんに相談するのが一番効率が良いと思いますよ。 (私はこの辺りはあまり経験ないので、本当はもっと良い方法(アイデア)があるんじゃないかな〜、とも思っています) | ||||||||
|
投稿日時: 2005-12-22 09:26
おはようございます.
スレ主さんお出ましになりませんね...
てっきり mbox かと思ってました. 商用版では database 使っているんですね. でも,ここを冗長化するには database を冗長かすることになるんでしょうか? それはそれで難しそうな気も...
SAMS の冗長化はともかく, その後方にある spool そのものを管理する部分が重要かと. 前述どおりですが,front-end を冗長化しても back-end が見えなければお話になりませんし. とすると,普通に database server 冗長化するようなノリでしょうかね? | ||||||||
|
投稿日時: 2005-12-22 09:44
drbd ですね。 | ||||||||
|
投稿日時: 2005-12-22 10:26
詳しいことはセンドメイル社に確認して貰う方が正確だと思いますが、商用Sendmailではデータ格納はMaildirライク(あくまでライク)な方式のようだった気がします。(勘違いかも知れないので気になるなら確認してください)
で、商用では、 1)メールを受信する部分(確かSwitch) 2)データを保存する部分(名前忘れました) 3)POP/IMAPをサービスする部分 4)管理ツール というように製品がセパレートされており、メッセージの規模や期待性能、または可用性に合わせて、それぞれの部分を自由に設計できるようになっていたと思います。 (勿論、単一のマシンですべても動かす事も可能たど思いますが、そのような構成で足りる程度のメッセージ量ならフリー版でも十分かもしれません) 例えば、2台以上のマシンで1)+2)をそれぞれ動かすようにすれば、受信については冗長性が保てると思われます。この場合、データはサーバマシンとは別のNASやSANなどを共有する形(当然NASやSANはRAID構成にして可用性を高めます)すれば、宜しいかと思います。 これで外部からのメールはDNSのMXレコードですべて同じ優先度にしておけば、まず受信できない事はないでしょう。 内部からのSMTPパケットを可用性ある形でサーバに渡す方法については...どうすれば良いでしょうか?... すいませんこれについては勉強不足です。運用が耐えられるならDNSラウンドロビンが一番簡単ですが、落ちているサーバにアクセスしたクライアントはTimeoutになってしまいますね。 何かロードバランサやproxyのようなものがあるかはセンドメイル社に確認して頂く方が良いでしょう。 内部用の1)をクラスタ等でHA化する手もありますが...クラスタは必ずしも可用性に対して万能な回答では無いですからね〜 (東証で夏頃に待機系を含めて半日ダウンした事件は記憶に新しいですね。 また、待機系に切り替わるにはそれなりの時間がかかりますね。) POPやIMAPに関しては先の説明通り、複数のサーバで構築してProxyをHA化するという形でしょうか。 または運用が耐えられるなら、メインと予備のProxyで別IPを振っておき、メインがこけたときに手動でIPエリアスで予備にメインと同じIPを割り振ることで逃げるって方法も有りかも知れません。(これとハートビートを組み合わせば、簡易クラスタの出来上がり?) 何にしても、冗長化設計はSEのスキルによって性能もコストも成果物も別物が出来上がる可能性が高いので、まずは信頼のあるSIerに相談する事をお勧めします。そして、どこを冗長化するか、どこを運用で逃げるかなどを良く見極める事が宜しいかと思います。 設計まで自分達だけでやるなら、そのためのコスト(や時間)は甘んじて受け入れる必要がありますし、かけたコストに見合う性能が出ない可能性もある事は考慮しておく必要がありますね。 これ以外に、冗長化すれば運用体制が軽減されるって訳でも無いので、実際には運用体制など色々と考える必要が出てきますけどね。 実は冗長化するって事は運用体制も冗長性が必要になってくる可能性が高いですね。 (え、24H/365Day運用なんて必要ないって(^^ でも、待機系に切り替わったら速やかにメイン系を復旧しないとならんしな〜) |