ユーザーメールボックスを別の Messaging Server にオンラインのままで移行

この手順を使用して、メッセージストアを Messaging Server の古いバージョンから新しいバージョンに移行したり、メールボックスを Sun Messaging Server メッセージストアから別の Sun Messaging Server メッセージストアに移動したりすることができます。この手順は、iPlanet Messaging Server 5.0 以降で動作します。それより前のバージョンの Messaging Server や Sun Microsystems 以外のメッセージストアからメッセージを移動する場合には使用できません。

この手順を使用してメールボックスを移動すると、次のような利点があります。

• 古い移行元システムから新しい移行先システムへのメールボックスの移動はシステム管理者が行い、ユーザーは何もしなくてよい。

• メールボックスを移動する手順のうち、この手順が最も速い。

• パーティション全体を移動する場合は再リンク操作が不要。

• 両方の Messaging Server システムがアクティブでオンラインのままに保たれる。

• メッセージストアのすべてのメールボックスを移行することも、メッセージの一部を移行することもできる。したがって、段階的な移行が可能。

この手順を使用したメールボックスの移動には、次のような欠点があります。

• Sun 以外のメッセージングサーバーでは動作しない。

• 移行中のユーザーは、自分のメールボックスの移行が完了するまでメールボックスにアクセスできない。

• 複雑で時間のかかる方法になる可能性がある。

段階的なメールボックスの移行

段階的な移行には、メッセージストアを異なるシステムに移動したり、新しいシステムにアップグレードしたりする作業を安全で効果的に行う面で数多くの利点があります。段階的な移行によって、古いバックエンドメッセージストアを残しつつ、新しいバックエンドメッセージストアシステムを構築することができます。その後、新しいシステムをテストし、都合のよいユーザーを数人移行して、新しいシステムを再度テストできます。新しいシステムと設定で快適に動作し、この移行手順がうまくいくとわかったら、実際の商用ユーザーの移行を開始できます。それらのユーザーを別個のバックアップグループに分割すると、移行中にオフラインになるのが特定グループのメンバーだけになり、オフライン時間も短くすることができます。

オンラインの段階的な移行の別の利点は、アップグレードが失敗した場合に備えてシステム全体のバックオフを計画する必要がないということです。バックオフとは、システムを元の動作可能状態に戻すために、システムに加えた変更を取り消す手順のことです。移行を行う場合は失敗に備えなければなりません。つまり、移行中の 1 つ 1 つの手順について、システムを以前の動作可能状態に戻すための計画が必要です。

オフラインの移行では、すべての移行手順を完了してサービスをオンに切り替えるまで移行作業が成功したかどうかわからない、という点が問題です。システムが動作せず迅速な修正もできない場合には、実行したすべての手順のバックオフ手順が必要になります。これはストレスが溜まり時間もかかる作業です。その間、ユーザーはオフラインにされたままです。

オンラインの段階的な移行で実行する基本的な手順は次のとおりです。

1. 古いシステムを残しつつ新しいシステムを構築し、両方のシステムが独立して動作できるようにします。

2. 新しいシステムと共存できるように古いシステムを設定します。

3. 都合のよいユーザーのグループを移行し、新しいシステムの動作、および古いシステムとの共存状態をテストします。

4. 古いシステム上のユーザーをグループに分け、必要に応じてグループごとに新しいシステムに移行します。

5. 古いシステムを解体します。

両方のシステムが共存するので、移行する前に新しいシステムをテストおよび調整するための時間を十分に取ることができます。万一、バックオフ手順を実行する必要が生じた場合でも、手順 2 および 4 について計画するだけですみます。手順 2 は、ユーザーのデータを一切操作しないので元に戻すのが容易です。手順 4 のバックオフでは、ユーザーの状態をアクティブに戻し、そのメールホスト属性を古いホストに戻すことになります。システム全体のバックオフは必要ありません。

オンラインの移行の概要

オンラインのままメールボックスを移行するプロセスは単純です。複雑になるのは、メールボックスに転送中 (MTA チャネルキュー内にあって配信待ち) のメッセージが移行プロセス中に失われないことを保証しようとする場合です。1 つの解決法は、移行プロセス中に送信されるメッセージを held 状態に保ち、さまざまなチャネルキューにあるメッセージが配信されるまで待つことです。ただし、システムに問題が生じたり特定のユーザーが制限容量を超えたりしたために、メッセージがキューに滞留することもあり得ます。そのような場合は、メールボックスを移行する前にその状況を解決する必要があります。

メッセージが失われる可能性を減らし、メッセージがチャネルキューに滞留していないことを確かめる方法はいろいろありますが、手順が複雑になるという短所があります。

手順中の個々の操作の順序および必要性は、実際の配備状況、およびどのメールボックス宛のどのメッセージも失われてはならないのかどうかによって異なります。この節では、それらの手順の背後にある理論と概念について説明します。各手順を理解し、実行する手順とその順序を実際の配備状況に応じて決定するのは、個々の管理者の責任です。次に示すのはメールボックスの移動プロセスの概要です。実際の配備によってはプロセスが異なってくる可能性があります。

1. 移動するメールボックスへのユーザーアクセスを禁止します。

2. 移動するメールボックス宛のメッセージを一時保留にします。

3. メッセージがチャネルキューに滞留していないことを確認します。

4. ユーザーのメールホスト属性を新しいメールボックスの場所に変更します。

5. メールボックスを新しい場所に移動します。

6. 保留メールを解放して新しいメールボックスへの配信を開始し、着信メッセージを移行済みのメールボックスに配信可能にします。

7. 移行後に古いメッセージストアに配信されたメッセージがないかどうか確認します。