メッセージストアの保守手順を実行する

この節では、メッセージストアの保守タスクと回復タスクを実行するのに使用するユーティリティーについて説明します。サーバーから送信される警告のためのポストマスターメールを常に読む必要があります。また、サーバーの実行状況に関する情報を記録したログファイルを監視する必要もあります。ログファイルの詳細については、第 21 章「ログの管理」を参照してください。

この節では次の内容について説明します。

• 「メールボックスを管理するには」

• 「制限容量を監視するには」

• 「ディスク容量を監視するには」

• 「stored ユーティリティーを使用する」

• 「同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする」

メッセージストアへの物理ディスクの追加

Messaging Server メッセージストアには、特定の Messaging Server インスタンス用のユーザーメールボックスが格納されています。メッセージストアのサイズは、メールボックス、フォルダ、およびログファイルの数が増えるに従って増大していきます。

システムにユーザーを追加していくに従い、ディスクストレージ要件も増えていきます。サーバーがサポートするユーザー数によって、メッセージストアに必要な物理ディスクが 1 つであるか、複数であるかが決まります。Messaging Server では、必要に応じてストアを追加できます。ストアを追加するための 1 つの方法は、ストレージ機器を使用することです。Messaging Server で Network Appliance ストレージ機器を設定する方法については、『』を参照してください。

メールボックスを管理するには

この節では、メールボックスの管理および監視を行う次のユーティリティーについて説明します。 mboxutil、hashdir、readership。

mboxutil ユーティリティー

メールボックスの一般的な保守タスクを実行する場合は、mboxutil コマンドを使用します。mboxutil で実行できるタスクは次のとおりです。

• メールボックスの一覧表示

• 孤立メールボックスおよび非アクティブメールボックスの一覧表示と削除

• メールボックスの作成

• メールボックスの名前変更

• パーティション間のメールボックスの移動

• 孤立したメールボックスおよび非アクティブのメールボックスの削除

• また、mboxutil コマンドを使用して制限容量に関する情報を表示することもできます。詳細については、「制限容量を監視するには」を参照してください。

mboxutil プロセスを実行途中で強制終了しないでください。SIGKILL (kill -9) で強制終了すると、各サーバーを再起動し、回復処理を行わなければならないことがあります。

表 18–11 に、mboxutil コマンドの一覧を示します。構文や使用要件の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

mboxutil コマンドで POSIX 正規表現を使用できます。

メールボックスのネーミングルール

メールボックス名は、次のフォーマットで指定します。user/userid/mailbox。ここで、userid はメールボックスを所有するユーザー、mailbox はメールボックスの名前を表します。ホストしているドメインでは、userid は uid@domain となります。

たとえば次のコマンドでは、ユーザーID が crowe であるユーザーの、INBOX という名前のメールボックスが作成されます。INBOX は、ユーザー crowe に配信されたメール用のデフォルトのメールボックスとなります。

mboxutil -c user/crowe/INBOX

重要: INBOX という名前は、各ユーザーのデフォルトのメールボックス用に確保してある名前です。INBOX は、大文字と小文字が区別されない唯一のフォルダ名です。ほかのフォルダ名はすべて大文字と小文字が区別されます。

例

全ユーザーの全メールボックスを一覧表示するには、次のように入力します。

mboxutil -l

すべてのメールボックスを、パスと ACL の情報とともに一覧表示するには、次のように入力します。

mboxutil -l -x

ユーザー daphne に対し、INBOX というデフォルトのメールボックスを作成するには、次のように入力します。

mboxutil -c user/daphne/INBOX

ユーザー delilah に対し、projx という名前のメールフォルダを削除するには、次のように入力します。

mboxutil -d user/delilah/projx

ユーザー druscilla について、INBOX というデフォルトのメールボックスとすべてのメールフォルダを削除するには、次のように入力します。

mboxutil -d user/druscilla/INBOX

ユーザー desdemona の memos というメールフォルダの名前を、memos-april という名前に変更するには、次のように入力します。

mboxutil -r user/desdemona/memos user/desdemona/memos-april

ユーザー dimitria のメールアカウントを新しいパーティションに移動するには、次のように入力します。

mboxutil -r user/dimitria/INBOX user/dimitria/INBOX partition

この場合、partition には新しいパーティションの名前を指定します。

ユーザー dimitria のメールフォルダ personal を新しいパーティションに移動するには、次のように入力します。

mboxutil -r user/dimitria/personal user/dimitria/personal partition

孤立アカウントを削除するには

孤立アカウント (対応するエントリが LDAP にないメールボックス) を検索するには、次のコマンドを使用します。

mboxutil -o

コマンド出力が次のように続きます。

  mboxutil: Start checking for orphaned mailboxes
  user/annie/INBOX
  user/oliver/INBOX
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

次のコマンドで作成したファイルは、孤立メールボックスを削除するスクリプトファイルにすることができます。この例では、ファイル名は orphans.cmd です。

mboxutil -o -w orphans.cmd

コマンド出力は次のとおりです。

  mboxutil: Start checking for orphaned mailboxes
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

次のコマンドを使用して孤立したファイルを削除します。

mboxutil -d -f orphans.cmd

hashdir ユーティリティー

メッセージストア内のメールボックスは、高速で検索できるようにハッシュ構造で保存されています。したがって、特定のユーザーのメールボックスを格納するディレクトリを検索するには、hashdir ユーティリティーを使用します。

このユーティリティーは、特定のアカウントのメッセージストアを含むディレクトリを識別します。また、メッセージストアへの相対パス (d1/a7/ など) をレポートします。このパスは、ユーザー ID に基づくディレクトリの 1 つ上のディレクトリレベルを基準にしたものです。このユーティリティーによってパス情報が標準出力に送られます。

たとえば、ユーザー crowe のメールボックスへの相対パスを検索する場合は次のようになります。

hashdir crowe

readership ユーティリティー

readership ユーティリティーは、メールボックスの所有者以外に、何人のユーザーが共有 IMAP フォルダ内のメッセージを読んだかを報告するユーティリティーです。

IMAP フォルダの所有者は、フォルダ内のメールを読む権限をほかのユーザーに与えることができます。ほかのユーザーにアクセス権が与えられたフォルダは、「共有フォルダ」と呼ばれます。管理者は readership ユーティリティーを使用して、所有者以外に何人のユーザーが共有フォルダにアクセスしたかを表示することができます。

このユーティリティーは、すべてのメールボックスをスキャンして、各共有フォルダにつき 1 行ずつ、アクセスしたユーザー数とメールボックスの名前を表示させます。ユーザー数とメールボックスの名前の間にはスペースが挿入されます。

アクセスしたユーザーとは、過去の指定した日数内に共有フォルダを選択した、個別の認証を受けたユーザーのことです。自分の個人用メールボックスを読んだユーザーは、数には含められません。個人用メールボックスは、フォルダの所有者以外に購読者がいない場合は報告されません。

たとえば次のコマンドでは、最近の 15 日以内に共有の IMAP フォルダを選択したユーザーをすべてカウントします。

readership -d 15

制限容量を監視するには

imqutoacheckユーティリティーを使って、制限容量の使用状況と制限を監視します。このユーティリティーは、定義された制限容量を一覧表示し、制限容量の使用状況に関する情報を提供するレポートを生成します。制限容量と使用状況に関する数値は、K バイトでレポートされます。また、このユーティリティーでメールボックスのサイズとユーザーに割り当てられた制限容量を比較することもできます。オプションとして、制限容量に対し一定の割合を超えたユーザーに対し、電子メールによる通知を送信することができます。

imquotacheck のいくつかの機能が変更されました。Messaging Server 6.x では、quotacheck ユーティリティーが imquotacheck に替わりました。Messaging Server 5.x では、ユーザーのリストを取得するために quotacheck ユーティリティーを使用すると、quotacheck はローカル mboxlist データベースを検索しました。この機能は、mboxutil ユーティリティーの検索機能と重複します。

Messaging Server 6.x では、この重複機能が imquotacheck ユーティリティーから削除されました。imquotacheck でユーザーの検索を実行する場合、検索はローカルの mboxlist データベースではなく、LDAP ディレクトリに対して行われます。ローカル mboxlist データベースからユーザーのリストを取得するには、mboxutil ユーティリティーを使用します。

制限容量がルールファイルの最小しきい値を超えるすべてのユーザーの使用状況を一覧表示するには、次のように入力します。

imquotacheck

ドメイン siroe.com の制限容量に関する情報を一覧表示します。

imquotacheck -d siroe.com

デフォルトのルールファイルにしたがって、すべてのユーザーに通知を送信するには、次のように入力します。

imquotacheck -n

指定したルールファイル myrulefile と指定したメールテンプレートファイル mytemplate.file にしたがって、すべてのユーザーに通知を送信するには、次のように入力します (詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imquotacheck」を参照)。

imquotacheck -n -r myrulefile -t mytemplate.file

ルールファイルを無視して、すべてのユーザーの使用状況を一覧表示するには、次のように入力します。

imquotacheck -i

user1 のフォルダ使用状況別に一覧表示するには (ルールファイルを無視)、次のように入力します。

imquotacheck -u user1 -e

ディスク容量を監視するには

システムがディスク容量やパーティションの使用状況を監視する頻度と、システムが警告を送信する環境条件を指定することができます。詳細については、「ディスク容量を監視する」を参照してください。

stored ユーティリティーを使用する

stored ユーティリティーは、以下の監視タスクと保守タスクをサーバーに対して実行します。

• バックグラウンドと日常のメッセージ処理タスク。

• デッドロックの検出とデッドロックしたデータベーストランザクションのロールバック。

• 起動時の一時ファイルのクリーンアップ。

• 存続期間決定ポリシーの実装。

• サーバーの状態、ディスク容量、サービスへの応答時間などの定期的監視 (「stored」を参照)。

• 必要に応じた警告の生成。

• 必要に応じたデータベース回復 (「メッセージストアの起動と回復」を参照)。

stored ユーティリティーは毎日午後 11 時に自動的にクリーンアップと (有効期限による) 失効の操作を行います。また、これ以外の時間にもクリーンアップと失効の操作を行うように選択することもできます。

表 18–12 に stored オプションの一部を示します。一般的な使用例についてはこの表に従ってください。構文や使用要件の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

状態を出力するには、次のように入力します。

stored -t -v

自動的なクリーンアップと失効の操作の時間を変更する場合は、次のように configutil ユーティリティーを使用します。

configutil -o store.expirestart -v 21

場合によっては、stored ユーティリティーを再起動する必要があります (メールボックスリストのデータベースが破損した場合など)。UNIX 上で stored を再起動するには、コマンド行で次のコマンドを使用します。

msg_svr_base/sbin/stop-msg store
msg_svr_base/sbin/start-msg store

サーバーのいずれかのデーモンがクラッシュした場合は、すべてのデーモンを停止させ、stored を含むすべてのデーモンを再起動しなくてはなりません。

同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする

1 つのメッセージが複数の受取人に送信されると、そのメッセージは各受取人のメールボックスに格納されます。一部のメッセージングシステムでは、同じメッセージのそれぞれのコピーを各受取人のメールボックスに格納します。それに対して、Sun Java System Messaging Server では、そのメッセージが格納されているメールボックスの数に関係なく、メッセージのコピーを 1 つだけ保持するよう努めます。このために、そのメッセージが含まれているメールボックス内にそのメッセージへのハードリンクを作成します。

ほかのメッセージングシステムが Sun Java Messaging Server に移行されると、移行プロセスによってメッセージの複数のメッセージコピーが作成されることがあります。メッセージストアが大きい場合、大量のメッセージが不必要に重複することになります。また、IMAP append 操作やほかのソースからなど、通常のサーバー操作で同じメッセージの複数のコピーが蓄積される可能性もあります。

Messaging Server には、余分のメッセージコピーを削除し、それらを 1 つのコピーへのハードリンクに置き換える relinker という新しいコマンドが用意されています。

Relinker の動作方式

再リンク機能は、コマンド行モードでもリアルタイムモードでも実行できます。relinker コマンドを実行すると、メッセージストアのパーティション全体がスキャンされ、MD5 メッセージダイジェストリポジトリがハードリンクとして作成または更新され、余分のメッセージファイルが削除されて、必要なハードリンクが作成されます。

ダイジェストリポジトリは、メッセージストアに格納されているメッセージへのハードリンクから構成されます。このリポジトリは、ディレクトリ階層 partition_path/=md5 に格納されます。このディレクトリは、ユーザーメールボックスの階層 partition_path /=user に対応しています (図 18–1 を参照)。ダイジェストリポジトリのメッセージは、その MD5 ダイジェストによって一意に識別されます。たとえば、fredb/00/1.msg のダイジェストが 4F92E5673E091B43415FFFA05D2E47 である場合、 partition/=user/hashdir/hashdir /=fredb/00/1.msg は partition/=md5/ hashdir/hashdir/4F92E5673E091B43415FFFA05D2E47EA.msg にリンクされます。別のメールボックスに同じメッセージ (partition_path /=user/hashdir/hashdir/gregk/00/17.msg など) があると、そのメッセージもまた partition_path/=md5/4F/92/4F92E5673E091B43415FFFA05D2E47EA.msg にハードリンクされます。図 18–5 はこのことを示しています。

図 18–5 メッセージストアのダイジェストリポジトリ

このメッセージの場合、リンクカウントは 3 になります。両方のメッセージが fredb および gregk というメールボックスから削除されると、リンクカウントは 1 になり、メッセージを消去できます。

relinker プロセスは、リアルタイムモードで実行しても同じように機能します。詳細については、「リアルタイムモードで relinker を使用する」を参照してください。

コマンド行モードで relinker を使用する

relinker は、メッセージストアのパーティション全体をスキャンし、MD5 メッセージリポジトリをハードリンクとして作成または更新して、余分のメッセージファイルを削除します。relinker がストアパーティションをスキャンし終わると、再リンク前後の一意のメッセージ数とパーティションのサイズに関する統計情報が出力されます。すでにハッシュされているストアを迅速に処理するために、relinker は =md5 にまだ存在しないメッセージのダイジェストだけを計算します。また、ダイジェストリポジトリ全体を消去することもできます (ユーザーメールボックスに影響しない場合)。

コマンドの構文は次のとおりです。

relinker [-p partitionname] [-d]

ここで、partitionname は処理されるパーティション (デフォルト: すべてのパーティション) を示し、-d はダイジェストリポジトリが削除されること示します。出力例を次に示します。

# relinker

Processing partition: primary
Scanning digest repository...
Processing user directories..............................
---------------------------------------------------------
Partition statistics           Before            After 
---------------------------------------------------------
Total messages                 4531898         4531898
Unique messages                4327531         3847029
Message digests in repository        0         3847029
Space used                       99210Mb         90481Mb
Space savings from single-copy    3911Mb         12640Mb
---------------------------------------------------------


# relinker -d 
Processing partition: primary
Purging digest repository...
---------------------------------------------------------
Partition statistics                 Before         After
---------------------------------------------------------
Message digests in repository       3847029             0
---------------------------------------------------------

relinker は、特にリポジトリにメッセージがまったく存在しない場合の最初の実行は、時間がかかることがあります。これは、すべてのメッセージのダイジェストを計算しなければならないためです (relinker 条件がすべてのメッセージを含めるように設定されている場合)。relinker 条件の設定については、「relinker を設定する」を参照してください。たとえば、100G バイトのメッセージストアを処理するのに 6 時間を要するとします。ただし、実行時再リンクが有効になっている (「リアルタイムモードで relinker を使用する」を参照) 場合は、relinker コマンドを実行する必要はありません。

relinker コマンド行モードが排他的に使用され、実行時オプションが有効でない場合は、ダイジェストリポジトリ (=md5) を消去する必要があります。そうしないと、ストア (=user) 内に消去されたメッセージがダイジェストリポジトリ内にリンクを持ち続ける (孤立する) ため、それらのディスク領域が解放されません。移行後などにストアの最適化を 1 回だけ行なっている場合は、relinker を一度実行してから、relinker -d でリポジトリ全体を削除できます。移行中に消去を何度も行なった場合は、実行するたびに期限切れや孤立したメッセージがリポジトリから消去されるので、relinker コマンドを繰り返し実行するだけで十分です。

異なるパーティションの各処理と並行して、relinker の複数のインスタンスを実行しておくと安全です (-p オプションを使用)。メッセージは同じパーティション内でのみ再リンクされます。

リアルタイムモードで relinker を使用する

リアルタイムモードで relinker 機能を有効にするには、configutil パラメータの local.store.relinker.enabled を yes に設定します。リアルタイムモードで relinker を使用すると、設定された relinker 条件 (「relinker を設定する」を参照) に一致する、配信された (または復元された、IMAP によって追加された、など) すべてメッセージのダイジェストが計算され、そのダイジェストがリポジトリにすでに存在するかどうかが確認されます。ダイジェストが存在する場合は、メッセージの新しいコピーを作成する代わりに、そのダイジェストへのリンクが宛先メールボックスに作成されます。ダイジェストが存在しない場合は、メッセージが作成され、あとでそのメッセージへのリンクがリポジトリに追加されます。

stored は、各パーティションのダイジェストリポジトリをスキャンし、リンクカウントが 1 か、relinker 条件に一致しないメッセージを消去します。スキャンは、設定可能な期間内に一度に 1 つのディレクトリで実行されます。これは、入出力負荷が均等に分散され、ほかのサーバー操作に著しい影響を及ぼさないようにするためです。デフォルトでは、消去サイクルは 24 時間です。これは、メッセージがストアから削除されるか、設定可能な最長保存期間を過ぎたあとも、24 時間までは存在するということを意味します。このタスクは、relinker のリアルタイムモードが有効になっている場合にのみ使用できます。

relinker を設定する

表 18–13 に、relinker 条件を設定するためのパラメータを示します。