- - PR -
メールサーバの構成について
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2006-03-20 05:25
現在、メールサーバを１台で運用しています。
これからセカンダリメールサーバの追加を検討しています。 プライマリが復帰するまで受信できないのも不便だ・・・ など色々考えていると、 どんな構成が一般的なんだろう？ 他のサイトはどうしてるんだろう？ と思い今回書き込みさせて頂きました。 環境はLinux（RHEL3）、qmail、vpopmailです。 用途は中小規模コンテンツのサポートメールといった感じです。 流通量は日に数百通ぐらいでしょうか。 ぱっと思いついた構成はこんな感じです。 1)セカンダリメールサーバでバックアップ プライマリ復帰までの受信不可なのがネック。 サーバ追加のみで対応可能なので導入は楽。 2)共有ディスク（NFS,NAS）でクラスタ化 一番実績がありそうな感じ。 しっかり組むとそれなりにコストかかりそうなイメージ。 3)DRBD+HeartBeatでクラスタ化 WEB上でクラスタ化の話はよく見ますが、実績などの話は聞いた事がないです。 運用もそれなりのノウハウが必要そう。 4)ロードバランサでクラスタ化 機材が高価でうちの規模では導入が難しい。 ロードバランサがSPOFにならないよう組むとさらにコストアップ。 「ウチはこうしてるよ」「こんな構成もあるよ」といったご意見が聞ければと思っています。 宜しくお願いします。 | ||||
|
投稿日時: 2006-03-23 13:49
回答が付きませんね。メールサーバを二重化している企業は少ないのでは？
と思われます。 以下は相談者の環境がわかりませんので、一般的な企業のメール環境に関する コメントです。 メールサーバのフォールトトレランス向上施策はサーバの二重化だけでなく、 アクセス回線の二重化の方が有効です。 自社内のメールサーバがダウンしてもISPの中継サーバは生きていますので、 迅速に代替サーバを立ち上げれば、業務への影響は最小限で済みます。 → セカンダリメールサーバの追加を検討されるなら、再セットアップ可能な 代替サーバを1台確保しておく程度で十分ではないでしょうか？ ウチの流通量はもう少し多い（約1,000通/日）程度ですが、上記対応のみです。 | ||||
|
投稿日時: 2006-03-23 20:49
BackDoorさん回答ありがとうございます。
> メールサーバのフォールトトレランス向上施策はサーバの二重化だけでなく、 > アクセス回線の二重化の方が有効です。 なるほど参考になりました。 回線の二重化は頭に入ってませんでした。 サーバはIDCにあるため復旧までに多少タイムラグが発生します。 その間はセカンダリメールサーバで代理受信させ、事前に用意しておいた 代替サーバで復旧させる。 そんな感じにしようかなぁと思っています。 引き続きご意見宜しくお願いします。 | ||||
|
投稿日時: 2006-03-23 23:07
こんばんわ．
「絶対に停めてはいけない」という条件を緩和するなら， 「復旧時間を圧縮する」という案もあるのでは？ 以前，Hot Imaging Tool で system backup を採取して， data area も定期的かつ差分で Hot Imaging していました． 経路上は二重化して，spool のところは 「１時間以内に復旧，作業は現地作業員が手順書を見て」という仕組みを作りました． それはそれで有効は無いかと． 以上，ご参考までに． | ||||
|
投稿日時: 2006-03-23 23:26
1)は、どういう構成なのか分からないのでパス。
2)だと、NFSサーバを二重化するのかとかストレージは高可用性があるという 前提でよいのか、とかいろいろと。 流量だけから判断すると、これでも大げさすぎるような... 3)についてはあまり知りませんのでパス。 4)は、やはり大げさすぎる。 可用性を高めたいなら、SCSI接続のストレージを共有するクラスターを 組む案ですかね。（共有といっても、Active-Standbyで排他制御を行う） それでも大げさすぎる気がしますが。 | ||||
|
投稿日時: 2006-03-24 09:28
エレガントさは無視して．．．
まず、DNSのMXレコードでプライマリとセカンダリのメールサーバを定義しておき 優先度をプライマリ優先としておく。 でもって、メールサーバをプライマリとセカンダリを構築しておき、それぞれのメール サーバで同じアカウントが使えるようにしておく。 プライマリとセンダンリサーバでは、自身が受け取ったメールは全て自身宛てとして ローカルに保存する。 次にクライアントでは、マルチアカウント対応のメールクライアントを使う。（例えば Thunderbird とかね） メールクライアントの設定でプライマリ、セカンダリのメールサーバのメール読む様に設定を行っておく。 こうしておく事で、通常はプライマリのメール届く。 プライマリに障害が発生した場合には、MXによってセカンダリにメールが届くようになる。 メールクライアントでは、通常はプライマリに来るメールを読むが、障害時にはセカンダリに届いたメールを読むことになる。 アカウントはどちらも同じ設定である限り（LDAPとか使うと幸せかも）送信・受信とも問題なく行える。 --- というのは如何？ 初期コストはあまり必要ないと思います。 但し、アカウント管理などに一工夫が必要ですね。 あと、あくまでメールサーバの冗長化なので、回線（回線やルータなど）側に対する障害には無力です。 | ||||
|
投稿日時: 2006-03-25 09:07
ふむふむ、色々ご意見ありがとうございます！
＞kazさん 「絶対に停めてはいけない」というよりは、外部からのメールを取り逃しない体制にしたい。といった感じで考えていました。 これだけならBackDoorさんが書かれたように、ISPの中継サーバが再送してくれてセカンダリは不要なんでしょうか？ 「復旧時間を圧縮する」といった案についても検討しなければと考えているところです。 ＞ぽんすさん 規模に応じた構成といった所でこれは大袈裟？など考えてしまい判断に悩んでます。 メールサーバに限らずこういった構成について学べる資料があるといいんですけどね。 ＞非武装エリアさん 書いて頂いた案も一応考えていました。 ただ、↓のスレッドを見て同じ状況になったら困るな・・・と思い今回の候補に書きませんでした。 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=27795&forum=10 こういった問題がクリアになれば両サーバにメールボックスを持たせるものアリかなと思います。 | ||||
|
投稿日時: 2006-03-25 10:24
状況説明を頂いたおかげで、他の識者からのアドバイスも入り始めました。 （良かったですね） tommy様のセカンダリメールサーバへの思い入れはよく理解できますし、 可用性向上施策としても間違っているとは思えません。 以下、直接回答ではありませんので、気分を害さぬよう願います。 ネットワークインフラの運営・維持にはそれなりに多大なコストが必要です。 当初の相談内容に記載された（1）〜（4）案はいずれもメールサーバ自体の 障害時の対策にすぎません。 相談冒頭の課題 > （プライマリが復帰するまで）受信できないのも不便だ・・・ に対する対策としてはあまりにも局所的過ぎるように思えます。 → メールが送受信できなくなる要因は他にも多く存在すること、運営・維 持費用は有限であることを考慮すると、総合的に何処に優先投資が必要 かを見極める必要があるはずです。 抽象的でわかりにくいので、ウチの実例を少し紹介します。 最近の10年間でE-mailが使用できない障害は2回発生しています。 1.メールサーバのDISK障害 → 前のコメントの方法で復旧（回復までの所要時間：約2時間） 2.ファイアウォール（nameサーバ、VPNサーバ兼用機）のマザーボード故障 → 2台の代替機（LINUXサーバ）でファイアウォール他を立上げ （回復までの所要時間：約7時間、障害発生が早朝だったため業務 時間への影響は約3時間） IDCにメールサーバがあるとのことですが、IDCまでの距離によって対応は 異なります。 近い場合は代替機を持って交換に行く、遠い場合でコロケーション契約なら 代替機の事前設置＆障害時の切替マニュアルをIDCに渡しておき、切替オペ レーションを実施してもらう等の対応でも良さそうに思えます。 個人的には「監視サーバによるノード（通信回線および既設サーバ）の24時間 監視」「バックアップ回線の確保」に投資する方が現実的かと思います。 → 監視サーバの障害通知は運用メンバー数名のケータイへメール発信する 設定にしています。運用メンバーはRAS接続で運用監視サーバのアラートを 確認後、状況に応じた対応を迅速に行ないます。 → バックアップ回線としてはコストパフォーマンスの高いBフレッツがお勧め です。また、バックアップ回線は回線障害時だけに必要なのではありません。 1つのシステムの稼動中に別のシステムの要件でネットワーク変更を行う際 に一時的な迂回路で使用するケースがありました。 普段はメイン回線のサポート回線（トラフィック上昇時の迂回路）としての 設定を入れるようにすれば、決済も下りやすくなるはずです。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。