25.クラスタリングで運用しよう
メールサーバーがとまってしまったら？
普段は空気のように動いているのが当たり前のメールサーバーだが、いざ障害等で停止してしまってメールが使えなくて困ったような経験はないだろうか？
最近では、各企業がメールを使ってDM発行や、メルマガ発行など当たり前に行われている。メールを受ける側でも、スパムメールやウイルスメールといった受け取りたくないメールも大量に届くようになった。
メールサーバーにかかる負担は、思った以上に大きくなっているのが実情だ。停止してしまわなくても、配送遅延が発生したりするケースもある。また、ここ数年、特に災害が発生した場合の対策も考慮に入れなくてはならなくなった。バックアップは当たり前だが、仮にバックアップをしっかり取っていても、サーバの復旧には手間と時間がかかるものだ。
仮に、メール量もしれており使用頻度が高くないから大丈夫、などと思っていても、ある日突然、サーバーのHDDクラッシュでまったく使えなくなるケースだって起こりうる。届いたメールの内容や設定情報も諦めなくてはいけなくなるような状況が発生した場合は、損害は大きくなり、復旧にかかる時間と手間は膨大になる。
ここでは、停止しないメールシステムを効果的に実現する、いわゆる“メールサーバーの冗長化”をする方法として、E-Post Mail Serverシリーズを使ったメールサーバーのクラスタリングを設定してみることにする。
※ここで取り上げるクラスタリングの方式は、「E-Post方式クラスタ」を利用しています。Windows Serverに装備されている「MSFC（Microsoft フェイルオーバークラスタ）方式」を使って設定する場合は、別途『MSFC方式クラスタリングメールサーバ構築ガイド』という名称のドキュメントを用意していますのでお問い合わせください。
メールサーバーのフェールオーバーの概念
E-Post Mail Serverシリーズに付属する死活監視サービスプログラムである IPWCS.EXE（E-Post IP Watcher サービス）を導入することにより、相手のノードマシンがアクティブか否かを監視する設定を行う。
ここでのクラスタリング構成は次のような考え方になる。相手のノードがダウンしている場合は、割り当てられていた仮想IPアドレスを引き受け、メールサーバーとしての制御を継続する。それによって、クライアント側からはメールサーバーマシンの長期ダウンを感じさせない環境の構築が可能となる。
いわゆるアクティブ−スタンバイ方式による「フェールオーバー」対策である。
（※）サービスプログラムである IPWCS.EXE はIPv4環境のみ有効である。IPv6には対応していない。また、IPWCS.EXE は、IPアドレスがDHCPで自動で割り当てられているマシン上では使用すべきではない。サーバー構築では常識だが、静的にIPアドレスを設定しているマシンで導入してほしい。
メールサーバーノード１の実IPアドレス 192.168.0.101
メールサーバーノード２の実IPアドレス 192.168.0.102
メールサーバー(test-sample.jp)にする仮想IPアドレス 192.168.0.103
E-Post IP Watcher サービスの導入（メールサーバーノード１・２共通）
1.コマンドプロンプトを開く
コマンドプロンプトを開き、E-Post Mail Serverシリーズのインストール先フォルダをカレントフォルダ（カレントディレクトリ）にする。
（32bitOSでは C:\Program Files\EPOST\MS がデフォルト）
（64bitOSでは C:\Program Files (x86)\EPOST\MS がデフォルト）
|
cd "c:\program files\epost\ms\ <CR> |
2.監視用テーブルの作成
コマンドプロンプト内で、以下の"ipwcs -entry"コマンドを実行。対話式に答え、相手となるマシン情報を設定する。
|
ipwcs -entry <CR> 監視テーブルの作成 [0:新規, 1:追加] = 0 ペアとなるコンピュータ名 (例. \\SV01) = \\SV02 ←UNC名を指定 監視するＩＰアドレス (例. 192.168.0.2) = 192.168.0.103 ←仮想IPを指定 ネットーワーク構成名 (例. "ローカル エリア接続") =ローカル エリア接続 設定してよろしいですか？ [y/n] = y |
3.動作確認
コマンドプロンプト内で、以下のコマンド"ipwcs -debug"を実行。相手のマシンの監視が問題なく行えるか動作を確認する。
|
ipwcs -debug <CR> Debugging E-POST IP Watcher. [15/Nov/2010:13:58:09] E-POST IP Watcher (1.1x) Mon, 15 Nov 2010 13:58:09 +0900 [15/Nov/2010:13:58:09] IP released all. [15/Nov/2010:13:58:09] C:\PROGRA~1\EPOST\MS\ipwatch.dat [15/Nov/2010:13:58:09] C:\PROGRA~1\EPOST\MS\ipwatch.dat open is success. [15/Nov/2010:13:58:09] -c=\\SV02 -i=192.168.0.103 -f=ローカル エリア接続 [15/Nov/2010:13:58:09] [0012f018] -c=\\SV02 ↑相手先ノード監視開始ステータス [15/Nov/2010:13:58:09] \\SV02 [15/Nov/2010:13:58:09] p = [0012f018] [15/Nov/2010:13:58:09] [0012f028] -i=192.168.0.103 [15/Nov/2010:13:58:09] 192.168.0.103 [15/Nov/2010:13:58:09] p = [0012f028] [15/Nov/2010:13:58:09] [00000000] -f=ローカル エリア接続 [15/Nov/2010:13:58:09] ローカル エリア接続 [15/Nov/2010:13:58:09] p = [00000000] [15/Nov/2010:13:58:09] GetOption() end. [15/Nov/2010:13:58:09] Delete address "ローカル エリア接続" 192.168.0.103. [15/Nov/2010:13:58:09] netsh interface ip delete address "ローカル エリア接続" addr=192.168.0.103 インターフェイスにはこの IP アドレスがありません。 ←仮想IPはまだ取得されていないが正常 [15/Nov/2010:13:58:09] end code is 0 [15/Nov/2010:13:58:09] ConnectNamedPipe(hPipe = 000003c0) [15/Nov/2010:13:58:09] C:\PROGRA~1\EPOST\MS\ipwatch.dat [15/Nov/2010:13:58:09] C:\PROGRA~1\EPOST\MS\ipwatch.dat open is success. [15/Nov/2010:13:58:09] -c=\\SV02 -i=192.168.0.103 -f=ローカル エリア接続 [15/Nov/2010:13:58:09] [0012f018] -c=\\SV02 ↑相手先ノード監視開始ステータス [15/Nov/2010:13:58:09] \\SV02 [15/Nov/2010:13:58:09] p = [0012f018] [15/Nov/2010:13:58:09] [0012f028] -i=192.168.0.103 [15/Nov/2010:13:58:09] 192.168.0.103 [15/Nov/2010:13:58:09] p = [0012f028] [15/Nov/2010:13:58:09] [00000000] -f=ローカル エリア接続 [15/Nov/2010:13:58:09] ローカル エリア接続 [15/Nov/2010:13:58:09] p = [00000000] [15/Nov/2010:13:58:09] GetOption() end. [15/Nov/2010:13:58:09] GetOption end. [15/Nov/2010:13:58:09] Check IP addrr 192.168.0.103 [15/Nov/2010:13:58:09] ipcheck 192.168.0.103 ←監視インターバルに入る（一時停止状態） −−[Ctrl]＋[C]キーを押してデバッグモードを停止させる−− SERVICE_CONTROL_STOP in debug mode. Stopping E-POST IP Watcher. [15/Nov/2010:13:58:31] Service Stoped. [15/Nov/2010:13:58:31] dwWait = 0 / bServiceTerminating = 0 −−（中略）−− [15/Nov/2010:13:58:31] cleanup [15/Nov/2010:13:58:31] CloseHandle(hPipe = 000003c0) [15/Nov/2010:13:58:31] CloseHandle(hServerStopEvent = 000003c8) [15/Nov/2010:13:58:31] CloseHandle(hEvents[1] = 000003c4) [15/Nov/2010:13:58:31] free(pSD = 00360758) |
4.サービスとして登録
コマンドプロンプト内で、以下のコマンド"ipwcs -install"を実行。IPWatcherサービスプログラム本体の"IPWCS.EXE"をサービスとして登録する。
|
ipwcs -install <CR> ↓ローカルのAdministratorアカウントを入力 ログインアカウント (例. sv01\\Administrator) =.\Administrator ログインパスワード=********* ←パスワードを入力 E-POST IP Watcher installed. |
5.サービスとして開始
登録したサービスをコマンドプロンプトもしくは「コンピュータの管理」−「サービス」から開始させる。
正しく設定されていれば、以下のとおり開始メッセージが表示される。
|
net start "E-POST IP Watcher" <CR> E-POST IP Watcher サービスを開始します。 E-POST IP Watcher サービスは正常に開始されました。 |
E-Post IP Watcher サービスの設定（メールサーバーノード１・２共通）
6.レジストリ値でマスタサーバーかスレーブサーバーかを設定する
登録した IPWCS サービスを制御するために設定されるレジストリ値は、以下のとおり。
レジストリエディタで目的に応じて調整することができるが、マスタサーバー側は、Balance値として'0'（インストール時のデフォルト値）になっているか確認する。
また、スレーブ（待機）サーバーとなる側には、Balance値を'1'に変更する。
こうすることで、マスタサーバー側がダウンするなどして、仮想（論理）IPアドレスへの接続ができなくなると、スレーブサーバー側が、仮想（論理）IPアドレスを取得し、メールサーバー機能を引き続き継続する。
マスタサーバー側が回復した場合は、その後、スレーブサーバー側が自動的に仮想（論理）IPアドレスを開放する動きになる。
-
IPWCS サービスに設定されるレジストリ値
HKEY_LOCAL_MACHINE
→ SOFTWARE
→ (Wow6432Node) ※
→ EPOST
→ IPWCS
→ LogEnabled (DWORD)
→ Interval (DWORD)
→ Balance (DWORD)
→ ReleaseTime (DWORD)
→ PingTimeout (DWORD)
（上のキーから順に）
・動作ログの採取 0:しない, 1:する
・仮想IP監視間隔（秒） デフォルト 30秒
・定期的に仮想IPを開放する
0:しない(Master Server), 1:する(Slave Server)
・仮想IP開放サイクル デフォルト 60回毎
(60回×Interval値(30) = 約1800秒毎)
・監視先マシンの無応答タイムアウト時間（秒） デフォルト 3秒
（※）Windows Server 2008 R2など64bit版OSのときは、キーの場所が HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\EPOST\IPWCS となるので注意。32bit版OSのときには関係ない。
E-Post Mail Server の設定（メールサーバーノード１／２）
各サービス（EPSTRS,EPSTDS,EPSTPOP3S,EPSTIMAP4S）のサービス開始権限のログインアカウントは、デフォルトの LocalSystem でなく、アカウントを指定し Administrator で登録し直す作業が必要となる。
設定したアカウントに対するパスワードを間違えるとサービスが開始されない。うまく行かない場合は、Windowsの「管理ツール」−「サービス」からサービスを開始するアカウントとパスワードを設定してみる。Mail Controlでパスワードを再設定するには、サービスをいったん「削除」すると「登録」ボタンが表示される。ボタンをクリックすると、サービスを開始するアカウントとパスワードを設定できるようになる。
以下の３項目について、それぞれのノードマシンから、参照可能でかつ読み書き可能なネットワーク共有フォルダをUNC名で設定する。
- 「メール作業フォルダ」 例）\\cmp01\mail\
- 「メールボックスフォルダ」 例）\\cmp01\mail\inbox\%USERNAME%
- 「アカウントフォルダ」 例）\\cmp01\mail\db\
上記の設定以外に、アカウントが自動転送機能を利用している場合、転送先を指定するファイルが利用されているときには、各ノードマシンより参照可能な共有フォルダに割り当て直すことが必要になる。具体的には次のようなケースだ。
次に、[E-Post Mail Control]の[サービス制御]タブを開き、登録済みの各サービス（EPSTRS/EPSPOP3S/IMAP4S）について、[詳細設定]ボタンをクリックし、詳細設定を行う。
[IP Address] 欄には、「一覧のアドレスに応答する」を選択したら、応答するポート番号とIPアドレスの指定を「*.*.*.*」のように、ワイルドカードで設定する。
[ドメイン] 詳細ダイアログボックスについては、ノードマシン１／２とも、設定する[IPアドレス]欄に通常、取得される "仮想IPアドレス" を設定する。実IPアドレスは指定しないので要注意だ。なお、アクティブ／スタンバイの区別は、前述したIP Watcherのレジストリ設定に従うことになる。
さらに、自律的に動作する仕組みのEPSTDSサービスについて、設定を行う。EPSTDSサービスについて、各ノードマシンが仮想IPアドレス取得時のみ動作させるようにする場合は、以下のようにレジストリ値を作成し、仮想IPアドレス（192.168.0.103）の値を設定しておく必要がある。
この設定をしていないと、EPSTDSサービスが仮想IPアドレスを取得していない状況、たとえば待機している状況でも、EPSTDSは自律的に動作するため、メールキューであるincomingフォルダに置かれたメールデータを配送しようとする。
-
EPSTDS サービスに設定するLogicalIPのレジストリ値
HKEY_LOCAL_MACHINE
→ SOFTWARE
→ (Wow6432Node) ※
→ EPOST
→ EPSTDS
→ LogicalIP (文字列) 192.168.0.103を設定
（※）Windows Server 2008 R2など64bit版OSのときは、キーの場所が HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\EPOST\IPWCS となるので注意。32bit版OSのときには関係ない。
ここまでの設定で、各ノードマシンに設定した実IPアドレスへ接続したとき、実際には受領も完了しないし、正しく動作することはないものの、サービスが応答を返す状態になっている。
セキュリティを強化するためにも、実IPアドレスへ接続したときに、このサービスが応答も返さないようにしておこう。
セッションに対する応答を禁止させるためには、プログラムインストールフォルダ内に、プロトコル単位で hidden*.dat と名付けたテキストファイルを作成する。このファイル内に実IPアドレスを記入することで、応答禁止の設定を行う。
SMTP用IP禁止ファイル : hiddensmtpip.dat
POP3用IP禁止ファイル : hiddenpopip.dat
IMAP4用IP禁止ファイル : hiddenimapip.dat
以上の設定が完了したら、各サービスを開始する。
LAN内環境でのメールサーバーの負荷分散設定例
メールサーバーとメールクライアントとの間に、ロードバランサー（負荷分散装置）を中間に置くことにより、負荷分散、フェールオーバーを実現できるが、このような装置が入手できない場合は、以下のような設定方法で擬似的に接続の負荷分散、フェールオーバーを実施することも可能だ。
手順1. DNSサーバーへの設定
メールサーバーの名前解決可能なようにクライアントが利用しているDNSサーバーのAレコードに設置した複数の「E-Post Mail Server Enterprise」の各ＩＰアドレスを登録し、DNSからの名前解決にてラウンドロビンでの回答を可能にする。
設定例）メールサーバー名 -> test-sample.jp とした場合
-
DNS Aレコードの設定
test-sample.jp. IN A 192.168.0.101 ← E-Post Mail Server 1
A 192.168.0.102 ← E-Post Mail Server 2
手順2. Windowsクライアントマシンの設定
2-1. DNSキャッシュ機能を無効にしてIPアドレスの切り替えを確認
Windowsクライアント側のDNSキャッシュ機能を無効にするために、コマンドプロンプトを開き、以下のコマンドを実行。
net stop dnscache <CR>
正常終了したら、ping test-sample.jp を何回か実行し、IPアドレスが変化することを確認する。
2-2 メールクライアント設定
メールクライアント側で設定している各プロトコルで接続するサーバーについて、IPアドレスで設定していた内容をドメイン名称（例：test-sample.jpなど）に変更する。以上で設定が完了する。
メールクライアント側で設定しているログインIDについて、＠以降のドメイン名を付けたアカウントに変更する。
例)ログインID が abc の場合 → user1@test-sample.jp 等と変更する。
上記のような環境を設定すると、メールクライアント側からの送受信が通常接続する毎に（セッション毎に）、接続先IPアドレスが切り替わり、送受信の負荷分散が擬似的に実現する。
なお、片方のメールサーバーが落ちた場合は、本設定では、１回おきにエラーが発生することになるが、送受信が完全に不能になることはなくなる。事実上のフェールオーバーと言える。
上記設定で動作が確認されたメールクライアントの例
基本的には、次に試してみた通り、接続サーバーをFQDNで指定できるメールクライアントでは、上記の設定で、問題なく運用することが可能だ。
|
Becky! 2.x Edmax Winbiff2.x ALMail32 Microsoft Outlook |
○ ○ ○ ○ △ Outlookは接続したIPアドレスをキャッシュして しまうため、再接続の際は、いったん終了してOutlookを 再起動しないと接続IPが切り替わらないようである。 |
負荷分散例（スパムやウイルス、一般メールの大量受信対策）
以下の設定方法では、接続の負荷分散を行う例を紹介する。メールの大量受信対策に活用する方法だ。
NAT/ルーターを経由し、各ノードマシンのIPアドレスとして、ノードマシンA には 192.168.0.101、ノードマシンB には 192.168.0.102 の実IPアドレスが割り当てられているものとする。
管理ドメイン名は、”test-sample.jp“ （複数の場合も設定は同じ）である。
使用する共有DISKには、 処理性能を向上させるために、デュアルホスト(Dual-Host)で接続できる共有ストレージ装置（DASなど）を利用する。
しかし、処理性能を問わなければ、NASのようなネットワーク上に配置可能なファイルサーバー（例 “\\Cmp01\C$”）でも可能だ。その際、各マシンから常時参照できている状態でなければならない。
DNSのMXレコードやラウンドロビンでの設定で「マシンA」「マシンＢ」に接続が分散されるように設定する。
セッション毎に切換え可能なロードバランサーを導入するといった方法もある。
なお、ここでもサービスのログオンは、Localsystemでなく、Administratorで登録する。
管理ドメイン名は、マシンAとマシンBで同じ名前を使い、設定するIPアドレスは、サーバ毎に割り当てられた実IPアドレスを指定することになる。
注意）設定したアカウントに対するパスワードを間違えるとサービスがうまく起動できない。うまく行かない場合は、「コンピュータの管理」−「サービス」から、ログインIDとパスワードを設定し直すか、Mail Controlからやり直すには、いったんサービスを「削除」し「登録」をクリックすれば再度の設定が可能だ。
以下の３項目について、各ノードマシンより参照可能でなおかつ読み書き可能な共有フォルダ名を UNC名（\\Cmp01\C$）で割り当てる。
「メール作業フォルダ」「メールボックスフォルダ」「アカウントフォルダ」
メルマガ等大量メール発送例
メルマガなどメール大量配送システムの構成例である。
NAT内/ルーターを経由し、各ノードマシンのIPアドレスとして、ノードマシンA には 192.168.0.101、ノードマシンB には 192.168.0.102 の実IPアドレスが割り当てられているものとする。
管理ドメインは、”test-sample.jp“ （複数の場合も設定は同じ）である。
使用する共有DISKには、 処理性能を向上させるために、デュアルホスト(Dual-Host)で接続できる共有ストレージ装置（DASなど）を利用する。
しかし、処理性能を問わなければ、NASのようなネットワーク上に配置可能なファイルサーバー（例 “\\Cmp01\C$”）でも可能だ。その際、各マシンから常時参照できている状態でなければならない。
マシン毎に異なるプロバイダ回線と接続することにより、配送負荷が分散され、スムーズにメール配送が行える。
遠隔地間のクラスタ構成メールシステム例
これは、災害を受けても被害を最小限にするため、将来的に必要でないかと思われる遠隔地間でのクラスタ構成例である。
※動作確認をしているわけではないが、理論上は可能と思われるので記載してみた。
遠隔地同士をVPNで接続し、同一セグメントで構成する。
各ノードマシンのIPアドレスとして、ノードマシンA には 192.168.0.101、ノードマシンB には 192.168.0.102 の実IPアドレスが割り当てられているものとする。
管理ドメインは名、”test-sample.jp“ （複数の場合も設定は同じ）である。
使用する共有DISKは、両ノードマシンと同一セグメント内にあり、常時参照できることが必要だ。
メールサーバーとなるノードマシンA、ノードマシンB、および共有DISKは、互いに遠隔地に設置し、VPNや専用線で接続する。仮にマシンAの地域で災害が発生し使用不能となっても、マシンBを経由してメールの送受信が停止することなく運用可能となる。
ただし、この場合、共有DISKを設置する場所が課題になりうる。共有DISKはいかなる場合でも利用できることが前提だからだ。また、パフォーマンスもやや低下すると思われるので、思案のしどころである。
（※クラスタリング構成で実際の構築作業を行うには、上記の記事はポイントだけですので、説明や手順が不足している個所があります。よりくわしく知りたいときは、下記のドキュメントをご参照ください。）
《技術資料ドキュメント》
■テクニカルホワイトペーパー『〔E-Post方式〕クラスタリングメールサーバ構築ガイド』（PDF）
■テクニカルホワイトペーパー『MSCS方式クラスタリングメールサーバ構築ガイド』（PDF）
■テクニカルホワイトペーパー『MSFC方式クラスタリングメールサーバ構築ガイド』（PDF）※要問い合わせ
