test

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

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 ユーティリティー」を参照)。