メールスプールサーバのデータ移行作業

須藤 千恵
情報社会基盤研究センター

概要
平成 25 年 5 月末から 8 月末にかけてメールスプールサーバ上のデータ移行作業を行いました。一連の作業
手順、遭遇した問題について簡単にまとめます。

1

作業背景
平成 25 年 3 月末に、全ユーザのデータを一度に移行する作業を試みました。しかし、サーバのパラメータ調整不足、ユーザのメールデータのフラグ情報の移行漏れ、安定サービス継続不可等が判明し、データ移行作業は一旦中止となりました。その後、一括データ移行開始直後のサーバへの過負荷による不安定稼動の懸念もあり、新旧のスプールサーバを並行稼動させ、徐々にユーザを新スプールサーバに移行する形で作業を行うことにしました。

2

データ移行作業中のサーバ構成
移行作業により、利用者のメールソフト等の設定変更の負担が極力生じないような形でデータ移行作業を行うために、データ移行期間中は、以下のようなシステム構成で運用していました。

図1
2.1

データ移行期間中のシステム構成

POP/IMAP/メール配送プロキシサーバ（以下、プロキシサーバ）

移行対象ユーザ宛のメールを新サーバへ配送・移行作業中の一時的停止機能等を postfix のルックアップ
テーブル・仮想エイリアス、POP/IMAP サービスのプロキシ機能は perdition を使用しました。
2.2

メールデータ同期サーバ（以下、同期サーバ）

旧スプールサーバのデータを新スプールサーバに同期させるためのサーバです。同期プログラムはセンターの宇多先生が作成した perl プログラムを使用しました。当初、フリーの同期ツールを用いて作業したところ、メッセージフラグ情報の移行ができなかった（管理者権限のあるユーザではなく、通常の一般ユーザでアクセスしていたため、ユーザの付与したフラグ情報が取得できなかった）、またデータ移行に非常に時間がかかった経緯があります。

2.3

新旧スプールサーバ

2.4

ldap サーバ

ユーザのアカウント情報（パスワード、メールスプールサーバの情報や移行期間中のメール配送先）を保持しています。

3

データ移行作業中のメール配送経路
旧スプールサーバは、Sun Java Messaging Server を使用していました。メール送受信サーバは、学内ユーザ宛のメールを受信すると、ldap サーバを参照し、該当アドレスの mailHost に書かれているスプールサーバにメールを配送する仕組みとなっています。
＜例＞mailDeliveryOption: mailbox
mailHost: mailstore1
データ移行作業中は、＜例＞mailDeliveryOption: forward
mailForwardingAddress: uid@mail2013.jaist.ac.jp
mailSieveRuleSource: 削除（メール転送情報を記載）という形に変更することで、移行完了したユーザのメールはメール送受信サーバとプロキシサーバを経由して新スプールサーバに配送されます。
mailDeliveryOption: forward を設定することで、mailForwardingAddress にメール転送される仕様でしたが、mailSieveRuleSource の内容も参照して動作する（新旧 2 箇所でメール転送が動作してしまう）ことが判明したため、移行作業時にこの属性は削除することになりました。

4

データ移行作業中の POP/IMAP サーバ
POP/IMAP サービスは旧サーバのプロキシサーバからデータ移行用の POP/IMAP プロキシサーバに切り替えました。
WebMail サービスは同様の方法での実現は難しいため、移行が終わったユーザに旧スプールサーバのメールデータ(Inbox)を差し替え、移行作業が完了している旨（新しいサーバに接続することを促す）を伝える形にしました。

5

データ移行対象
今回の作業で以下のデータを移行しました。
ユーザ情報
1.

メールデータ

2.

WebMail アドレス帳
3.

同期プログラムを用いてデータ移行を実施

保存形式、項目が同一ではなかったため、可能な範囲でのデータ移行

フィルタ情報

どちらも Sieve スクリプトでしたが、そのままの移行はできない(if 文の記述方法、elsif の使用は非推奨とされた)ため、移行先の推奨形式に合致する形に変更しました。

メーリングリスト情報
1.

メーリングリストアドレス

62.

メンバアドレス

3.

管理者

4.

送信制限

データ移行作業

6.1

移行手順

以下のような手順でデータ移行作業を行いました。
1.

該当ユーザの WebMail アドレス帳、フィルタ情報の移行、メールデータの事前同期作業

2.

該当ユーザのメールサービスの一時停止処理
A)

データ移行用プロキシサーバ上で該当ユーザのアドレス宛(uid@mail2013.jaist.ac.jp)のメールを一時エラー状態にさせてスプールサーバへの配送を停止させる

B)

ldap サーバ上の該当ユーザのパスワードを一時的に変更し、メールサービス利用不可状態にする

C)

データ移行用プロキシサーバ上で該当ユーザの POP/IMAP サービス利用不可状態にするD)

旧スプールサーバ上の WebMail サービスの利用状況確認

E)ldap サ ー バ 上 で uid@mail2013.jaist.ac.jp へ メ ー ル 転 送 す る 設 定 を 追 加 、
mailSieveRuleSource を削除

3.

データ同期用サーバ上でメールデータの最終データ移行（同期）作業4.

新スプールサーバへの切り替え
A)

メール配送先の切り替え

B)

データ移行用プロキシサーバ上で該当ユーザの POP/IMAP サーバ接続先切り替えC)

ldap サーバ上のパスワード情報を元に戻す

D)

新スプールサーバ上のユーザのパスワード参照先情報（移行用の特別なユーザのパスワードを参照するように設定）の解除

6.2

5.

メーリングリスト情報の移行6.

データ移行用プロキシサーバの取り外し＋メール配送先切り替え

移行スケジュール

移行対象ユーザは約 3,500 人、1 グループ 35 人程度のグループをメールスプールサーバ（旧）、身分毎に100 グループ作成しました。
まずはセンター関係のユーザを先行して移行作業（6 月中旬）を行い、移行作業の手順の最終確認と新スプールサーバの安定稼動の確認を行いました。
上記 1 の作業は実際のデータ移行作業前日までに完了させておく形とし、2 から 4 までの作業をグループ毎に繰り返し作業することにしました。（ユーザ一人あたりのメールサービス停止時間：30 分から 1 時間）
移行作業日数を 2 週間程度とし、作業開始直後は、1 時間あたり 1 グループのみ移行する作業を数日行い、その後グループ数を増やし、最大で 1 時間当たり 140 人（4 グループ）の移行作業をする計画としました。
移行対象ユーザの全員の移行作業が完了した後、残りの 5 と 6 の作業を実施しました。

7

移行作業中に発生した問題
移行作業中に発生した問題と対処した内容です。

7.1

メールデータ移行作業後メールサービスが利用できないメールデータ移行作業後の後半の作業（4．B）の作業漏れが原因でした。先行移行（作業手順の最終確認、作業時間の計測）の段階でしたので、それほど大きな影響はなかったものの、あってはいけないミスでした。
実際の移行作業時は、2 人よる移行作業（作業者、確認者）、作業手順リストの作成、実行結果確認スクリプトの作成を行い、作業ミスがないように配慮しました。
7.2

メールデータの同期処理されない/IMAP サービスが利用できない

クライアントからの IMAP サービス接続セッション数がサーバに設定していた接続可能セッション数の値を超えたことが原因でした。サービス開始前に事前に IMAP サービス利用者数（＝セッション数）という形で設定していましたが、実際の 1 ユーザ辺りの接続数は、メールソフトの設定による（Thunderbird は、デフォルト 5）ため、不足してしまいました。
適正な接続可能セッション数に設定変更しました。
7.3

データ移行用プロキシサーバを経由しないユーザが存在する

移行期間中、POP/IMAP サーバの IP アドレスの変更を行い、全ユーザがデータ移行用プロキシサーバを経由したサービスに切り替わっているはずでした。しかし、直接旧サーバに接続しているユーザがいることをメールサーバのアクセスログから確認されました。
調査の結果、ldap サーバの hosts 情報の変更が行われていなかった（DNS サーバのみ変更済み）ことが判明し、修正しました。
7.4

メーリングリスト配送エラー

6 の作業を行った後、メールの配送状況を確認していたところ、メーリングリスト宛のメールのいくつかにおいて配送エラーになっていることが判明しました。
調査の結果、特定のメーリングリストに設定した送信制限がそのメーリングリストのメンバとして含まれる下位のメーリングリストにも送信制限が引き継がれることが判明し、この仕様はシステムの標準機能でした。また、旧サーバで設定されている内容と全く同じ設定を行うことができないことも判明しました。
送信制限が設定されているメーリングリストを洗い出し、利用用途に合わせて設定内容を見直し、再設定を行いました。
7.5

一部メールソフトの IMAP 接続エラー

6 の作業を行った後、Apple Mail 5 以降の IMAP サーバ接続エラーが発生していることが判明しました。新サーバ上でサービス開始時から発生していた現象でしたが、移行期間中はプロキシサーバを経由していたため、問題の発見が遅れました。

8まとめ
様々な問題が発生し、一時作業を中断した時期もありましたが、原因の特定と対応策の検討・実施を行いながら、8 月末に作業を無事に終えることができました。
移行作業前は、Java の FullGC が頻発し、スプールサーバの安定サービスが提供できない期間が続きました。そのため、安定サービスが継続できるかどうか非常に不安でしたが、ver.up 作業および FullGC の原因も特定できたこともあり、移行作業後は安定したサービスを提供している状態が続いています。
今回のこの移行作業は、センターの宇多先生ならびに技術職員の皆さんの多大な協力を得て無事に終了できました。ここで改めて感謝申し上げます。