test

Sun Java System Messaging Server 6 2005Q4 管理ガイド

ユーザーメールボックスの移行

この節では、ユーザーメールボックスを Messaging Server から 別の Messaging Server に移行する方法について説明します。この節では、主に Messaging Server 5.2 から Messaging Server 6 2005Q4 システムへの移行について説明しますが、オンラインでの移行手順は 5.2 以降のどの Messaging Server にも適用できます。オンラインでの移行が最も便利ですが、他の移行方法についても説明します。

Messaging Server 5.2 から Messaging Server 6 にアップグレードする場合で、メッセージストアデータベース全体をアップグレードするときは、これらの移行手順を行う必要はありません。前の節で説明した make_mboxlistdb_changes.sh スクリプトを使用して、より効率よくデータベースをアップグレードできます。

これらの手順は次の場合に実行する必要があります。

これらの手順を使ってメールボックスを移行する場合は、パーティションパスを Messaging Server 5.2 パーティションにマップしないでください。また、make_mboxlist_changes.sh スクリプトを実行しないでください。

アップグレードスクリプトで生成される make_configutil_changes.sh スクリプトによって、Messaging Server 5.2 パーティションにマップするパーティションパスが自動的に設定されます。これは手動で変更する必要があります。また、do_the_upgrade.sh スクリプトから make_mboxlistdb_changes.sh スクリプトの呼び出しを削除する必要があります。

ユーザーメールボックスのデータを Messaging Server 5.2 から Messaging Server の現在のバージョンにオンラインで移動するには、この節で説明する次の手順に従ってください。データの移動中に Messaging Server を停止する必要はありません。

次に示す手順について説明しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オンラインの移行の概要

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

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

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

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

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

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

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

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

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

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

Procedureユーザーメールボックスを Messaging Server から 別の Messaging Server にオンラインのままで移行するには

始める前に

このタイプの移行の要件は次のとおりです。

注 –

メッセージングサーバーを以前のバージョンから新しいバージョンにアップグレードする場合にだけ当てはまる手順もあります。メールボックスをメッセージストアから別のメッセージストアに移行するだけの場合は、それらの手順は適用されない可能性があります。システム全体の移行に適用される手順には、その旨が示されています。

手順

  1. 移行元システムで、backup-groups.conf ファイルを使用して、移動するユーザーエントリを均等なバックアップグループに分けます。

    ここで、手順のあとの方の手順 8 で実行するメールボックスの移行に備えます。詳細については、「バックアップグループを作成するには」を参照してください。

    ユーザー名をファイルに入れ、imsbackup コマンドで -u オプションを使用する方法もあります。

  2. 移動するユーザーに対し、移動が完了するまでメールボックスにアクセスできないことを通知します。

    データを移動する前に、移動するユーザーがメールシステムからログアウトしていることを確認します。(「ユーザーアクセスを監視する」参照。)

  3. バックエンドメッセージストアおよび MMP システムで認証キャッシュのタイムアウトを 0 に設定し、MTA で ALIAS_ENTRY_CACHE_TIMEOUT オプションを 0 に設定します。

    1. 移動するメールボックスを含むバックエンドメッセージストアで、認証キャッシュのタイムアウトを 0 に設定します。


      configutil -o service.authcachettl -v 0

      この手順と手順 7 (mailUserStatus を hold に変更) を実行するとすぐに、ユーザーは移行中にメールボックスにアクセスできなくなります。

    2. すべての MMP で、認証キャッシュのタイムアウトを 0 に設定します。

      ImpProxyAService.cfg と PopProxyAService.cfg の LdapCacheTTL を 0 に設定します。

    3. 移動するメールボックスにメッセージを挿入する MTA をホストするすべての Messaging Server で、ALIAS_ENTRY_CACHE_TIMEOUT オプションを 0 に設定します。

      移動するメールボックスにメッセージを挿入する MTA をホストする Messaging Server は、通常、バックエンドメッセージストアになります。ただし、システムが LMTP を使用している場合は、そのシステムが着信 MTA になります。設定をチェックして確認してください。

      /msg_svr_base/config/option.dat の ALIAS_ENTRY_CACHE_TIMEOUT をリセットすると、MTA はキャッシュをバイパスして LDAP エントリを直接参照します。これは、中間チャネルキュー (たとえば、conversion チャネルや reprocess チャネル) に対して、移動中のユーザーの古いキャッシュ情報ではなく新しい mailUserStatus (hold) を提示するためです。ALIAS_ENTRY_CACHE_TIMEOUT は option.dat にあります。

    4. キャッシュをリセットしたシステムを再起動します。

      これまでの変更を有効にするには、システムの再起動が必要です。手順については、「サービスを起動および停止する」を参照してください。

  4. 移行元 Messaging Server と移行先 Messaging Server の両方が起動して実行されていることを確認します。

    移行元 Messaging Server で、着信メッセージを新しい移行先サーバーにルーティングできるようにする必要があります。

  5. メールボックスを移動するすべてのユーザーエントリについて、LDAP 属性 mailUserStatus を active から hold に変更します。

    この属性変更によって着信メッセージが hold キューに保留され、IMAP、POP、および HTTP 経由でメールボックスにアクセスできなくなります。通常、ユーザーはグループに分けて移動します。1 つのドメインのすべてのメールボックスを移動する場合は、mailDomainStatus 属性を使用できます。

    mailUserStatus の詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』の「mailUserStatus」を参照してください。

  6. 移動するメールボックス宛のメッセージが ims-ms チャネルキューまたは tcp_lmtp* チャネルキュー (LMTP 配備済みの場合) 内に滞留しないようにします。

    次のコマンドを使用して、移動するユーザー宛のメッセージがチャネルキューのディレクトリツリーに存在し、held 状態になっている (.HELD ファイルを参照する) かどうか調べます。


    imsimta qm directory -to=<user_address_to_be_migrated> -directory_tree

imsimta qm directory -to=<user_address_to_be_migrated> -held -directory_tree

    キューにメッセージがある場合は、これらのコマンドをあとで実行して MTA がそれらのメッセージをキューから取り出したかどうか確認します。キューから取り出されていないメッセージがある場合は、移行の前にこの問題を解決する必要があります。このような状況はまれですが、受取人のメールボックスが制限容量を超えている、おそらくユーザーがログインしてメッセージを移動中であるためにメールボックスがロックされている、LMTP バックエンドサーバーが応答しない、ネットワークまたはネームサーバーに問題がある、などの状況が原因として考えられます。

  7. 移動するユーザーエントリ、およびすべてのメールグループエントリにある LDAP 属性 mailHost を変更します*。

    ldapmodify コマンドを使用して、エントリを新しいメールサーバーに変更します。Messaging Server または Directory Server に付属している ldapmodify を使用してください。Solaris OS の ldapmodify コマンドは使用しないでください。

    * メールグループエントリの mailHost 属性を変更する必要があるのは、古いメールホストがシャットダウンされているときだけです。この属性を新しいメールホスト名に変更するか、属性全体を省いてしまってもかまいません。メールグループの mailHost の指定はオプションです。mailHost の指定は、そのホストだけがグループ拡張を行えることを意味し、mailHost の省略 (こちらの方が一般的) は、すべての MTA でグループ拡張を行えることを意味します。メールグループエントリには移行対象となるメールボックスはなく、通常は mailhost 属性さえ指定されません。

    mailhost の詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』の「mailHost」を参照してください。

  8. メールボックスデータを移行元 Messaging Server のメッセージストアから移行先 Messaging Server のメッセージストアに移動し、起動した時刻を記録します。

    imsbackup ユーティリティーを使用してメールボックスをバックアップし、imsrestore ユーティリティーを使用して新しい Messaging Server にメールボックスを復元します。たとえば、oldmail.siroe.com という Messaging Server 5.2 システムから newmail.siroe.com にメールボックスを移行するには、oldmail.siroe.com で次のコマンドを実行します。


    /server-root/bin/msg/store/bin/imsbackup -f- /instance/group     \
| rsh newmail.siroe.com /opt/SUNWmsgsr/lib/msg/imsrestore.sh   \
-f- -cy -v1

    バックアップと復元のセッションを同時に複数 (グループごとに 1 つ) 実行すると、新しいメッセージストアへの転送速度を最適化できます。imsbackup ユーティリティーと imsrestore ユーティリティーの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Command Descriptions」および 「メッセージストアのバックアップと復元を行う」を参照してください。

    注 –

    あとで配信の検証を行うときのために imsbackup の実行時のタイムスタンプを記録しておいてください。

  9. (システムアップグレード用の条件付き手順) メールボックスの移行が、Messaging Server を以前のバージョンから現在のバージョンにアップグレードするプロセスの一部である場合は、この現在のバージョンの Messaging Server がシステムの新しいデフォルトの Messaging Server になるように設定します。

    newmail.siroe.com (以前 oldmail.siroe.com によってホストされていたドメインを管理するサーバー) をポイントするように、oldmail.siroe.com の DNS A レコードを変更します。

  10. 新しいメッセージストアへのユーザーアクセスを有効にします。

    状況に応じて、 LDAP 属性 mailUserStatus または mailDomainStatus を、hold に変更される前の値 (たとえば、active) に設定します。

  11. すべての移行元 Messaging Server にある held 状態のメッセージを解放します。

    着信メッセージを保留している可能性のあるすべてのシステムで、次のコマンドを実行してすべてのユーザーメッセージを解放する必要があります。


    imsimta qm release -channel=hold -scope

    scope に all を指定するとすべてのメッセージが解放されます。user を指定すると対象がユーザー ID、domain を指定すると対象がユーザーが存在するドメインになります。

  12. 認証キャッシュのタイムアウトおよび ALIAS_ENTRY_CACHE_TIMEOUT オプションをデフォルトまたは特定の値にリセットし、システムを再起動します。

    これで、移行が必要なすべてのユーザーメールボックスの移行が完了しました。次に進む前に、古いシステムを mailhost とする LDAP 新規エントリが作成されていないことを確認してください。そのようなエントリが見つかった場合は、それらを移行します。プロビジョニングシステムの変更によっても、そのようなエントリが作成できないことを確認してください。

    preferredmailhost 属性を新しいメールホストの名前に変更することもお勧めします。

    バックエンドメッセージストアでは、認証キャッシュのタイムアウトを次のように設定します。


    configutil -o service.authcachettl -v 900

    MMP では、ImpProxyAService.cfg および PopProxyAService.cfg で LdapCacheTTL オプションを 0 に設定します。

    MTA では、ALIAS_ENTRY_CACHE_TIMEOUT オプションを 600 に設定します。ALIAS_ENTRY_CACHE_TIMEOUT は option.dat にあります。

    これまでの変更を有効にするには、システムの再起動が必要です。手順については、「サービスを起動および停止する」を参照してください。

  13. ユーザークライアントで新しいメールサーバーが指定されていることを確認します。

    アップグレードが終了したら、ユーザーに、メールクライアントプログラムから新しいメールサーバーをポイントしてもらいます (この例では、oldmail.siroe.com から newmail.siroe.com をポイントしてもらう)。

    別の方法として、メッセージングマルチプレクサ (MMP) の使用があります。MMP を使用すると、ユーザーのクライアントから新しいメールサーバーを直接ポイントしてもらう必要がなくなります。MMP は、LDAP ユーザーエントリに保存されている mailHost 属性から必要な情報を取得し、クライアントを新しいサーバーに自動的にリダイレクトします。

  14. すべてが正常に動作したら、移行後、古いメッセージストアに配信されたメッセージがないことを確認します。

    古いメッセージストアに移動し、mboxutil -l を実行してメールボックスの一覧を表示します。最新のメッセージ配信タイムスタンプをチェックします。移行のタイムスタンプ (imsbackup コマンド実行時のタイムスタンプ) よりあとに配信されたメッセージがある場合は、バックアップおよび復元のコマンドを使ってそれらのメッセージを移行します。これまでの手順で十分に準備しているので、移行後に配信されたメッセージが見つかることはまず考えられません。

    理論的には、notices チャネルキーワードで指定された日数または時間数の間、メッセージがキューに滞留することはあり得ます (「通知メッセージの配信間隔を設定するには」を参照)。

  15. 新しいメッセージストアで重複しているメッセージを削除し、relinker コマンドを実行します。

    このコマンドによって、新しいメッセージストアのディスクの空き容量が増える可能性があります。詳細については、「同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする」を参照してください。

  16. 移行元のストアから古いメッセージを削除し、古いストア上のデータベースからユーザーを削除します。

    mboxutil -d コマンドを実行します。(「mboxutil ユーティリティー」を参照)。

ProcedureIMAP クライアントを使用してメールボックスを移動するには

メッセージングサーバーから別のメッセージングサーバーにメッセージを移行する必要がある場合は、いつでもこの手順を使用できます。この方法を使用してメールボックスを移動する前に、利点と欠点を考慮してください。

IMAP クライアントを使用してメールボックスを移動すると、次のような利点があります。

IMAP クライアントを使用してメールボックスを移動すると、次のような欠点があります。

手順

  1. 新しい Messaging Server をインストールして設定します。

  2. local.store.relinker を有効に設定します。

    同じメッセージが重複して保存されたために新しいシステムのメッセージストアのサイズが増加した場合は、この設定によって減少します。詳細については、「同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする」を参照してください。

  3. 新しい Messaging Server のユーザーをプロビジョニングします。

    これには Delegated Administrator を使用できます。新しいシステムでユーザーをプロビジョニングした直後から、新たに届くメールは新しい INBOX に配信されるようになります。

  4. ユーザーに指示して、新旧両方の Messaging Server のメールボックスを表示するようにメールクライアントを設定してもらいます。

    そのためには、クライアントに新しい電子メールアカウントを設定する必要がある場合があります。詳細については、メールクライアントのマニュアルを参照してください。

  5. 古い Messaging Server から新しい Messaging Server にフォルダをドラッグするよう、ユーザーに指示します。

  6. すべてのメールボックスを新しいシステムに移行したことをユーザーに確認してから、古いシステムのユーザーアカウントを停止します。

Proceduremoveuser コマンドを使用してメールボックスを移動するには

メッセージングサーバーから別のメッセージングサーバーにメッセージを移行する必要がある場合は、いつでもこの手順を使用できます。Sun 以外のメッセージングサーバーから Sun Java System Messaging Server に IMAP メールボックスを移行する場合に役立ちます。この方法を使用してメールボックスを移動する前に、利点と欠点を考慮してください。

moveuser コマンドを使用してメールボックスを移動すると、次のような利点があります。

moveuser コマンドを使用してメールボックスを移動すると、次のような欠点があります。

手順

  1. 新しい Messaging Server をインストールして設定します。

  2. local.store.relinker を有効に設定します。

    同じメッセージが重複して保存されたために新しいシステムのメッセージストアのサイズが増加した場合は、この設定によって減少します。詳細については、「同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする」を参照してください。

  3. メッセージングサーバーへの着信メールを停止します。

    ユーザー属性 mailUserStatus を hold に設定します。

  4. 必要に応じて、新しい Messaging Server のユーザーをプロビジョニングします。

    以前のバージョンのメッセージングサーバーから移行する場合は、同じ LDAP ディレクトリとサーバーを使用できます。moveuser は、各ユーザーエントリの mailhost 属性を変更します。

  5. moveuser コマンドを実行します。

    Directory Server siroe.com 内のアカウント情報に基づいて host1 から host2 にすべてのユーザーを移動するには、次のようにします。


    MoveUser -l \
"ldap://siroe.com:389/o=siroe.com???(mailhost=host1.domain.com)" \
-D "cn=Directory Manager" -w password -s host1 -x admin \
-p password -d host2 -a admin -v password

    moveuser コマンドの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「MoveUser」を参照してください。

  6. 新しいメッセージストアへのユーザーアクセスを有効にします。

    1. LDAP 属性 mailUserStatus を active に設定します。

    2. 次のコマンドを実行して認証キャッシュのタイムアウト値を 0 に設定し、メッセージストアにすぐにアクセスできるようにします。


      configutil -o service.authcachettl -v 0

  7. 古いシステムをシャットダウンします。

Procedureimsimport コマンドを使用してメールボックスを移動するには

この手順は、UNIX の /var/mail 形式のフォルダから Sun Java System Messaging Server メッセージストアにメールボックスを移動する場合のみ使用します。ただし、移行元のメッセージングサーバーで IMAP メッセージストアを UNIX の /var/mail 形式に変換できる場合は、imsimport コマンドを使用して Sun Java System Messaging Server にメッセージを移行できます。この方法を使用してメールボックスを移動する前に、利点と欠点を考慮してください。

imsimport コマンドを使用してメールボックスを移動すると、次のような利点があります。

imsimport コマンドを使用してメールボックスを移動すると、次のような欠点があります。

手順

  1. 新しい Messaging Server をインストールして設定します。

  2. local.store.relinker を有効に設定します。

    同じメッセージが重複して保存されたために新しいシステムのメッセージストアのサイズが増加した場合は、この設定によって減少します。詳細については、「同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする」を参照してください。

  3. 必要に応じて、新しい Messaging Server のユーザーをプロビジョニングします。

    これには Delegated Administrator を使用できます。まだ新しいシステムに切り替えないでください。

  4. 新旧両方のメッセージストアへのユーザーアクセスを無効にします。

    LDAP 属性 mailUserStatus を hold に設定します。ユーザーのメールは保留キューに送られ、IMAP、POP、および HTTP を介してメールボックスにアクセスすることはできなくなります。ストアサーバー上の MTA およびメッセージアクセスサーバーは、この要件を満たす必要があります。この設定によって、ほかの mailDeliveryOption の設定はすべて無効になります。

  5. 既存のメールサーバーのメールストアが /var/mail 形式になっていない場合は、メールストアを /var/mail ファイルに変換します。

    詳細については、サードパーティーのメールサーバーのマニュアルを参照してください。

  6. imsimport コマンドを実行します。

    次に例を示します。


    imsimport -s /var/mail/joe -d INBOX -u joe

    imsimport コマンドの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimport」を参照してください。

  7. メッセージストアへのユーザーアクセスを有効にします。

    1. LDAP 属性 mailUserStatus を active に設定します。

    2. 次のコマンドを実行して認証キャッシュのタイムアウト値を 0 に設定し、メッセージストアにすぐにアクセスできるようにします。


      configutil -o service.authcachettl -v 0

  8. 新旧両方のメッセージストアへのユーザーアクセスを有効にします。

  9. 古いシステムをシャットダウンします。