- - PR -
メールサーバーのクラスタリング
1
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-04-16 12:23
現在、メールサーバー1台で運用しています。
これを2台構成にしたいと考えています。 メールサーバーに障害が起こってももう一方のメールサーバーで運用を続けたいという趣旨です。 負荷分散までできれば、とてもハッピーです。 そこで、LVSとkeepalivedで構築しようと考えています。 現在運用しているメールサーバーは、Maildir形式で/homeはNFSの共有ディスクをマウントしています。 追加するメールサーバーも同じ構成にして単体での稼動確認まで取れました（/homeは同じ共有ディスクをマウントしています）。 これをLVSで負荷分散し、keepalivedで死活監視すれば、完成なのでしょうか？ spoolも共有すべきでしょうか？ 他に忘れていること、気をつけるべきことはないでしょうか？ よろしくお願いいたします。 | ||||||||
|
投稿日時: 2007-04-16 12:29
こんにちわ．
何をどこまでやりたいのか？によると思いますよ． で，NFS server は冗長化されているのでしょうか？ | ||||||||
|
投稿日時: 2007-04-16 15:31
コメントありがとうございます。
実は、kaz様からのコメントを期待していました。 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=20555&forum=10&6 このあたり、読んだもので。 ■何をどこまでやりたいか 1. 2台構成のうち1台に障害が起こってももう一方で運用を続けたい：keepalived 2. spoolディレクトリも共有したいが、構成が複雑になるようであれば、 障害時の復旧は手動でもよい（そもそも共有すべきかわからない） 3. 負荷分散：LVS このくらいだと思っていますが、考慮漏れがないか知りたいです。 逆に何をどこまでやるべきか、松・竹・梅ぐらいで知りたいです。 ちなみにサーバーソフトは、Postfix 2.2.10とDovecot 0.99.11です。 OSはCentOS 4です。 NFSサーバー（＆DBサーバー）は、DRBDで構築しようと考えております。 この件については、別途質問したいことが出てくるかもしれませんが、 本件とは切り離して問題ないかなと思っています。 | ||||||||
|
投稿日時: 2007-04-16 22:25
こんばんわ．
spool の格納場所を共有するのでなければ， 後で書かれている drbd などが必要でしょう．
ちゃんと考えた方がよいと思いますよ． 目的は冗長化なのですか？負荷分散なのですか？ 「松・竹・梅ぐらいで知りたい」前にまず， どんなことが望まれているか，要件をちゃんと纏めましょうよ． 「とりあえず全部教えて」ではなく． 複雑なことやらないのであれば，２台のメールサーバを用意して， 一方のメールサーバからもう一方に NFS して spool を共有してしまえば とりあえずなんとかなってしまいます． NFS の部分を drbd に置き換えれば共有するのではなく block device として同期できるのでもっと安全に共有できるでしょう． ただ，ここに負荷分散が入ってくると調整が難しい気がします． ※単に双方向で複製しても安全か？という理由で． DNS で MX record を２つ設けて，重み付けしている場合も 「どちらから spool が落ちてくるかわからない」ので同じようなモノかと． ということで，目的が冗長化なのか？負荷分散なのか？は 実は構成を考慮する上で重要だと思います． | ||||||||
|
投稿日時: 2007-04-17 22:54
一応、私なりにちゃんと考えているつもりなのですが．．．
考える材料が欲しいという感じでしょうか。 別に今すぐユーザーから何かを望まれていると書いたつもりも なく、実際に障害に対してはわりと緩かったりとします。 ただ今後、ユーザーに提案するにあたって、松・竹・梅ぐらい わかっていれば、気の利いた提案もできるのかなと思っての 質問です。決して、いい加減にやっているわけではないという ことはご理解いただきたく．．．うんぬんかんぬん。 目的は冗長化（フェイルオーバー）です。 でも、障害時以外休ませておくのももったいないので、 できれば負荷分散もやりたいです。 どうやら、アクティブ・アクティブでspool ディレクトリを 共有するのは、テクニカルっぽいので、 負荷分散をやるかやらないかが鍵ってことになりますかね。 この時点で、「おいおい、ぜんぜん違うよ」という雰囲気で もないので、あながちはずしていないのかなと安心しており ます。 ご意見、たいへん参考になりました。 ありがとうございました。 | ||||||||
|
投稿日時: 2007-04-18 00:00
こんばんわ．
ここがもっとも「考える必要がある」箇所だと思います． おそらく「もったいない」が大前提として 「あれをやるけどこれも」という発想が生まれます． 余力があれば良いですが，様々な理由から「どっちつかず」で 「最初の目的は？」な状況に陥ります． なので，
そこを見失わないように考えを進めて行かれることをお奨めします． 「負荷を分散する必要がある」のではなく， 「冗長化が本論であって負荷分散は過程で取り入れられれば」 くらいからはじめるとよろしいかと． ちなみに「素早く backup を採取する」のも， 冗長化の前の段階で考慮した方がよいかも知れません． ※以前その意見に傾いたお客さんもいました． clustering すると「運用が大変になる」ということから， 「では短い間隔で snapshot を取って，ある程度割り切ってしまったらどうか？」 ということで，「簡単に元戻せるけど，わずかながら data は損失してしまうよ」 という構成で組んだことがあります． 「障害に対してわりと緩い」のであれば， その考え方のほうが match することもあります． 以上，ご参考までに． | ||||||||
|
投稿日時: 2007-04-18 00:35
負荷分散=SLBと思っていませんか？ この構成でActive-Activeを組むなら node1: SMTP node2: POP or IMAP てなのが一般的では？ 分散したいのは負荷なんですから。 _________________ 桃李不言 下自成蹊 | ||||||||
|
投稿日時: 2007-04-18 01:25
皆様、ご意見ありがとうございます。
目的を見失わず、余計な要件は切り捨てる勇気を持ち、 優先度を付けて作業を進めたいと思います。 課題に対するアプローチとして、技術的に解決するのか、 運用面で解決するのかについての話も理解できます。 提案としては、それもアリですね。 anights様のおっしゃる送信プロトコルと受信プロトコル で負荷を分散するというのも納得しました。 これは好みの話なのですが、今回は、機能を分散すること より、全く同じ構成の2台で分散することを考えています。 そうすれば、3台、4台と増えたとき楽かなと思っています。 ただ、負荷分散の手法として機能を分散するという方法も あることについての助言はありがたく思います。 もちろん、提案の1つとしてラインナップするに値します。 たいへん幅が広がった気がします。 重ね重ね、ありがとうございました。 | ||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。