test

Sun Java System Message Queue 3.7 UR1 管理ガイド

第 4 章 ブローカの設定

ブローカの設定は、一連の設定ファイルおよび起動時に imqbrokerd コマンドに渡されるオプションにより制御されます。この章では、使用可能な設定プロパティーと、それらを使用してブローカを設定する方法について説明します。

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

ブローカ設定プロパティーの参照情報については、第 14 章「ブローカのプロパティーのリファレンス」を参照してください。

ブローカサービス

ブローカ設定プロパティーは、影響を受けるサービスやブローカコンポーネントに応じて、いくつかのカテゴリに分類できます。

次の節では、これらの各サービスおよび、特定のニーズに合わせてサービスをカスタマイズするために使用できるプロパティーについて説明します。

接続サービス

メッセージブローカは、さまざまなトランスポートプロトコルを使用して、アプリケーションと管理クライアントの両方をサポートするさまざまな接続サービスを提供できます。接続サービスに関連するブローカ設定プロパティーについては、「接続のプロパティー」に示しています。

表 4–1 に使用できる接続サービスを示します。それらは次の 2 つの特性によって識別されます。

表 4–1 Message Queue 接続サービス

サービス名 

サービスタイプ 

プロトコルタイプ

jms

NORMAL

TCP

ssljms (Enterprise Edition)

NORMAL

TLS (SSL ベースセキュリティー)

httpjms (Enterprise Edition)

NORMAL

HTTP

httpsjms (Enterprise Edition)

NORMAL

HTTPS (SSL ベースセキュリティー)

admin

ADMIN

TCP 

ssladmin

ADMIN

TLS (SSL ベースセキュリティー) 

ブローカの imq.service.activelist プロパティーを設定することで、これらの接続サービスの一部、またはすべてを実行することができます。このプロパティーの値は、ブローカの起動時にアクティブにする接続サービスのリストであり、このプロパティーを明示的に指定しないと、jms および admin サービスがデフォルトでアクティブにされます。

各接続サービスは、特定の認証および承認機能もサポートします。詳細については 「セキュリティーサービス」を参照してください。

ポートマッパー

各接続サービスは、ホスト名 (または IP アドレス) とポート番号によって指定された特定のポートで使用できます。サービスには、静的なポートを明示的に指定するか、またはブローカのポートマッパーによって動的にポートを割り当てることができます。ポートマッパー自体は、通常、標準ポート番号 7676 にあるブローカのプライマリポートに常駐します。必要に応じて、ブローカの設定プロパティー imq.portmapper.port を使用して、このポートを別のポート番号で上書きできます。デフォルトで、各接続サービスは、起動時に自身をポートマッパーに登録します。クライアントがブローカとの接続を作成すると、Message Queue クライアントランタイムはまずポートマッパーに接続し、目的の接続サービスのポート番号を要求します。

または、ポートマッパーを上書きし、imq. serviceName.protocolType. port 設定プロパティー (この場合 serviceName と protocolType は 表 4–1に示すように、特定の接続サービスを示す) を使用して、接続サービスに静的ポート番号を明示的に割り当てることができます。この方法で設定できるのは、jms、ssljms、admin、および ssladmin 接続サービスのみです。httpjms および httpsjms サービスでは、付録 C 「HTTP/HTTPS のサポート」に説明するように、異なる設定プロパティーが使用されます。ただし、静的ポートは、一般に、ファイアウォールを介した接続 (「ファイアウォールを介した接続」を参照) を作成する場合などの特定の状況でのみ使用し、一般的な使用にはお勧めしません。

注 –

複数のホストを使用できる場合 (コンピュータに複数のネットワークカードがインストールされている場合など)、ブローカプロパティーを使用して、接続サービスのバインド先にするホストを指定できます。imq.hostname プロパティーは、すべての接続サービス用の単一のデフォルトのホストを指定し、必要に応じて、imq. serviceName. protocolType.hostname (jms、ssljms、admin、または ssl 管理サービス) または imq.portmapper.hostname (ポートマッパー自体) で、上書きできます。

複数のポートマッパー要求が同時に受け取られた場合、それらはアクションの待機中に、オペレーティングシステムのバックログに保存されます。imq.portmapper.backlog プロパティーは、そうしたバックログされた要求の最大数を指定します。この制限を超えると、バックログが縮小するまで、その後の要求が拒否されます。

スレッドプール管理

各接続サービスは、複数の接続をサポートするマルチスレッドです。これらの接続に必要なスレッドは、ブローカによって、サービスごとに個別のスレッドプールに保存されます。接続にスレッドが必要なときは、その接続をサポートするサービスのスレッドプールにスレッドが追加されます。

選択するスレッドモデルは、スレッドが 1 つの接続専用であるか、複数の接続で共有するかどうかを指定します。

ブローカの imq.serviceName. threadpool_model プロパティーは、特定の接続サービスに 2 つのうちどちらのモデルを使用するかを指定します。このプロパティーは、dedicated または shared の文字列値のどちらかになります。プロパティーを明示的に設定しない場合は、デフォルトで dedicated が使用されます。

ブローカプロパティー imq.serviceName. min_threads および imq.serviceName. max_threads を設定して、サービスのスレッドプール内のスレッドの最小数と最大数を指定することもできます。使用可能なスレッド数が、指定された最小のしきい値より少なくなると、Message Queue は、再び最小値に達するまで、スレッドをシャットダウンして、スレッドを解放します。これによって、メモリーのリソースが節約されます。負荷が重い場合、スレッドの数がプールの最大数まで増加する可能性があります。最大数に達すると、スレッドが利用できるようになるまで、新しい接続は拒否されます。

共有スレッドモデルでは、ディストリビュータスレッドを使用して、スレッドをアクティブな接続に割り当てます。ブローカプロパティー imq.shared.connectionMonitor_limit は、1 つのディストリビュータスレッドで監視できる接続の最大数を指定します。このプロパティーの値を小さくするほど、接続にスレッドを割り当てる速度が向上します。imq.ping.interval プロパティーは、時間間隔を秒単位で指定します。ブローカが定期的に接続をテスト ("ping") して、接続がまだアクティブであるか確認することによって、メッセージ送信に失敗する前に、事前に接続の障害を検出できます。

ルーティングサービス

クライアントがブローカに接続したら、メッセージのルーティングおよび配信を処理できるようになります。この段階では、ブローカはさまざまな種類の物理的送信先の作成および管理を担当し、メッセージのスムーズなフローを確保し、リソースを効率的に使用します。「ルーティングのプロパティー」で説明するブローカ設定プロパティーを使用して、それぞれのアプリケーションのニーズに合わせて、これらのタスクを管理できます。

ブローカのパフォーマンスと安定性は、使用できるメモリーなどのシステムリソースとリソースの使用効率によって異なります。設定プロパティーを設定して、受信メッセージによるブローカの過負荷やメモリー不足を防止することができます。これらのプロパティーは、リソースが不十分になってもメッセージサービスの動作を維持できるように 3 つのレベルで機能します。

こうしたシステムメモリーのしきい値がトリガーされることは、システム全体および送信先のメッセージ制限の設定が高すぎることを示しています。メモリーしきい値によって、潜在するメモリーの過負荷を必ずしもタイミングよく検出できるとは限らないため、メモリー利用率を制御するためにそれらに依存することは避け、メモリーリソースを最大限に活用できるように、システム全体および送信先の制限を再設定する必要があります。

持続サービス

障害が発生したブローカを復元するには、メッセージの配信処理の状態を作成し直す必要があります。この操作を行うには、ブローカが持続データストアに状態情報を保存する必要があります。ブローカの再起動時、ブローカは保存されたデータを使用して、送信先と永続サブスクリプションを再作成し、持続メッセージを復元して、開いているトランザクションをロールバックし、配信されていないメッセージのルーティングテーブルを再構築します。このあとに、メッセージの配信を再開できます。

Message Queue は、ファイルベースの持続モジュールと JDBC ベースの持続モジュールの両方をサポートしています (図 4–1 を参照)。ファイルベースの持続は、持続データを保存するために個別のファイルを使用し、JDBC ベースの持続では、JDBC™ (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアにブローカを接続します。ファイルベースの持続は一般に JDBC ベースより高速ですが、JDBC 互換ストアによって実現される冗長性や管理者による制御を好むユーザーもいます。ブローカ設定プロパティー imq.persist.store (表 14–4 を参照) は 2 つの持続形式のどちらを使用するかを指定します。

図 4–1 持続データストレージ

図は持続サービスが単層型ファイルベースのデータストアを使用するか、または JDBC ベースのデータストアを使用するかを示しています。

ファイルベースの持続

デフォルトで、Message Queue はファイルベースの持続データストアを使用します。これは、メッセージ、送信先、永続サブスクリプション、およびトランザクションなどの持続データを個別のファイルに保存します。ファイルベースの持続に関連するブローカ設定プロパティーについては、「ファイルベースの持続」に示しています。

ファイルベースのストアは、そのデータストアが属するブローカインスタンスの名前 (instanceName) によって識別されるディレクトリに配置されます。

…/instances/instanceName
/fs350/

instances ディレクトリの場所については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照してください。ブローカの各送信先には、その送信先に配信されるメッセージを保持する個別のサブディレクトリがあります。

注 –

持続データストアには機密事項を扱うメッセージや財産的価値のあるメッセージが含まれることがあるため、…/instances/ instanceName/fs350/ ディレクトリは承認されていないアクセスから保護するようにしてください。「持続データの保護」を参照してください。

メッセージ以外の持続データは、すべて個別のファイルに格納されます。送信先、永続サブスクリプション、トランザクション状態情報のファイルがあります。大半のメッセージは、可変長レコードから構成されるシングルファイルに格納されます。可変長レコードファイルを圧縮し、メッセージが追加および削除されたときの断片化を緩和することができます (「物理的送信先の圧縮」を参照)。さらに、特定のしきい値を超えるサイズのメッセージは、可変長レコードファイルではなく、個別のファイルに格納されます。このしきい値のサイズは、ブローカプロパティー imq.persist.file.message.max_record_size で設定できます。

ブローカは、これらの各メッセージファイル用のファイルプールを維持します。ファイルは必要なくなった場合にも削除されず、送信先ディレクトリの空きファイルのプールに戻されるため、あとで別のメッセージに再利用できます。ブローカプロパティー imq.persist.file.destination.message.filepool.limit はプール内のファイルの最大数を指定します。送信先の各メッセージファイル数がこの制限を超えた場合、ファイルが不要になると、プールに戻されずに削除されます。

ファイルをファイルプールに戻すと、ブローカは前の内容を削除せずに、再利用可能なファイルとしてタグ付けすることにより、保存領域と引き換えに時間を節約できます。imq.persist.file.message.filepool.cleanratio ブローカプロパティーを使用して、単に再利用可能とマークするだけでなく、「クリーン」(空き) 状態で維持する必要がある各送信先のファイルプール内のファイルのパーセンテージを指定します。この値を大きくするほど、ファイルプールに必要な領域は少なくなりますが、ファイルをプールに戻す際にファイルの内容を空にするために必要なオーバーヘッドが大きくなります。ブローカの imq.persist.file.message.cleanup プロパティーが true の場合、ブローカのシャットダウン時にプール内のすべてのファイルが空にされ、クリーン状態のままにされるため、保存領域は節約できますが、シャットダウンの処理速度が遅くなります。

持続ストアへのデータの書き込みにおいて、オペレーティングシステムには、データを同時に書き込むか、または「レイジー」(非同期的) に書き込むかを選択できます。レイジーストレージでは、システムクラッシュの発生時に、ブローカが持続ストレージにデータが書き込まれていなくても書き込まれたものと考えた場合に、データが損失する可能性があります。パフォーマンスと引き換えに、完全な信頼性を確保するために、ブローカプロパティー imq.persist.file.sync.enabled を true に設定して、すべてのデータを同時に書き込むように要求できます。この場合、システムがクラッシュ後に回復した際に、データの利用が保証されるため、ブローカは確実に処理を再開できます。ただし、データは失われませんが、クラスタ構成のブローカでは現在データを共有していないため、クラスタ内のほかのブローカからは使用できません。

JDBC ベースの持続

ファイルベースの持続を使用する代わりに、JDBC 互換ドライバを介してアクセスが可能な任意のデータストアにアクセスするように、ブローカを設定できます。この作業には、該当する JDBC 関連のブローカ設定プロパティーの設定、データベースマネージャーユーティリティー (imqdbmgr) を使用した適切なスキーマでのデータストアの作成が含まれます。仕様については、「JDBC ベースのストアの設定」を参照してください。

JDBC データベースを使用するように、ブローカを設定するプロパティーについては、「JDBC ベースの持続」を参照してください。これらのプロパティーを指定するには、各ブローカインスタンスのインスタンス設定ファイル (config.properties) を使用するか、ブローカユーティリティー (imqbrokerd) またはデータベースマネージャーユーティリティー (imqdbmgr) に -D コマンド行オプションを使用します。

imq.persist.jdbc.driver プロパティーは、データベースへの接続に使用する JDBC ドライバの Java クラス名を指定します。既存のデータベースへの接続 (imq.persist.jdbc.opendburl)、新しいデータベースの作成 (imq.persist.jdbc.createdburl)、およびデータベース接続のクローズ (imq.persist.jdbc.closedburl) のための URL を指定するプロパティーもあります。

imq.persist.jdbc.user および imq.persist.jdbc.password プロパティーは、データベースにアクセスするためのユーザー名とパスワードを指定し、imq.persist.jdbc.needpassword はパスワードが必要かどうかを指定するブール型のフラグです。セキュリティー上の理由から、パスワードは、-passfile コマンド行オプションで指定するパスワードファイルにのみ指定する必要があります。そうしたパスワードファイルを指定しないと、imqbrokerd および imqdbmgr コマンドではインタラクティブにパスワードの入力が要求されます。同様に、imqbrokerd コマンドに -dbuser オプション、または imqdbmgr コマンドに -u オプションを使用して、コマンド行からユーザー名を指定できます。

複数のブローカインスタンスによって共有される JDBC データベースでは、設定プロパティー imq.persist.jdbc.brokerid は、データベーステーブル名に追加される各データベースの一意のインスタンス識別子を指定します。このプロパティーは、1 つのブローカインスタンスのデータのみを格納する組み込みデータベースでは、一般に必要ありません。その他の JDBC 関連の設定プロパティーは、データベーススキーマを作成する SQL コードをカスタマイズするために使用し、1 つのプロパティーが 1 つのデータベーステーブルに対応します。たとえば、imq.persist.jdbc.table.IMQSV35 プロパティーはバージョンテーブル、imq.persist.jdbc.table.IMQCCREC35 は設定変更レコードテーブル、imq.persist.jdbc.table.IMQDEST35 は送信先テーブルを作成するための SQL コマンドを指定します。すべてのリストについては、表 14–6 を参照してください。

注 –

データベースシステムによって、必要とされる正確な SQL 構文が異なるため、詳細についてはデータベースベンダーのマニュアルを参照してください。

セキュリティーサービス

Message Queue には、ユーザーアクセス制御 (認証と承認) および暗号化のためのセキュリティーサービスが用意されています。

Message Queue 管理者は、ユーザーを認証し、ユーザーの操作を承認するために必要な情報をブローカに設定する責任があります。セキュリティーサービスに属するブローカプロパティーを 「セキュリティーのプロパティー」に示します。ブール型のプロパティー imq.accesscontrol.enabled はアクセス制御をブローカ全体 に適用するかどうかを制御するマスタースイッチとして機能しますが、厳密に制御す る場合は、imq.serviceName .accesscontrol.enabled プロパティーを設定することによって、特定の接続サービスでこの設定を上書きできます。ここで serviceName は表 4–1 に示す接続サービスの名前で、たとえば imq.httpjms.accesscontrol.enabled などになります。

図 4–2 に、ブローカが認証サービスおよび承認サービスを提供するために必要なコンポーネントを示します。これらのサービスは、メッセージングシステムのユーザーに関する情報を格納するユーザーリポジトリを使用します。ユーザーに関する情報とは、名前、パスワード、およびグループメンバーシップです。さらに、ユーザーまたはグループの特定の操作を承認するため、ブローカは、ユーザーやグループが実行できる操作を指定したアクセス制御プロパティーファイルを参照します。ブローカ全体で 1 つのアクセス制御プロパティーファイルを指定する場合は、設定プロパティー imq.accesscontrol.file.filename を使用し、1 つの接続サービスでアクセス制御プロパティーファイルを指定する場合は、imq.serviceName. accesscontrol.file.filename を使用します。

図 4–2 セキュリティーのサポート

ブローカのセキュリティーサービスがユーザーリポジトリとアクセス制御プロパティーファイルを使用していることを示している図。

図 4–2 に示すように、Message Queue サービスによって提供された単層型ファイルユーザーリポジトリにユーザーデータを格納するか、または、既存の LDAP (Lightweight Directory Access Protocol) リポジトリに接続できます。

ブローカの imq.authentication.basic.user_repository プロパティーは、どちらの種類のリポジトリを使用するかを指定します。一般に、拡張性が重要な場合、またはブローカクラスタを使用するなど、さまざまなブローカでリポジトリを共有する必要がある場合は、LDAP リポジトリをお勧めします。単層型ファイルリポジトリまたは LDAP ユーザーリポジトリの設定の詳細については、「ユーザー認証」を参照してください。

認証

ブローカへの接続を要求するクライアントは、ユーザー名とパスワードを入力する必要があります。ブローカはそれらをユーザーリポジトリに保存されているユーザー名とパスワードと比較します。クライアントからブローカに送信されるパスワードは、Base-64 (単層型ファイルリポジトリの場合) か、メッセージダイジェスト (MD5) ハッシュ (LDAP リポジトリの場合) を使用して暗号化されます。この選択は、ブローカ全体としては imq.authentication.type プロパティーで、または特定の接続サービスに対しては imq.serviceName. authentication.type で制御します。imq.authentication.client.response.timeout プロパティーは、認証要求のタイムアウトの間隔を設定します。

「パスワードファイル」で説明するように、パスワードはインタラクティブに入力を求める代わりに、パスワードファイルに指定することができます。ブール型のブローカプロパティーimq.passfile.enabled によってこのオプションを制御します。このプロパティーが true の場合、imq.passfile.dirpath および imq.passfile.name プロパティーで、パスワードファイルのディレクトリパスとファイル名を指定します。imq.imqcmd.password プロパティー (パスワードファイルに埋め込み可能) は管理ユーザーが、ブローカ、接続サービス、接続、物理的送信先、永続サブスクリプション、トランザクションの管理にコマンドユーティリティー (imqcmd) を使用することを認証するためのパスワードを指定します。

LDAP ベースのユーザーリポジトリを使用する場合は、LDAP 検索のさまざまな側面を設定するために、あらゆる範囲のブローカプロパティーを使用できます。LDAP サーバー自体のアドレス (ホスト名とポート番号) はimq.user_repository.ldap.server で指定します。imq.user_repository.ldap.principal プロパティーは、LDAP リポジトリにバインドするための識別名を指定し、imq.user_repository.ldap.password は関連パスワードを指定します。その他のプロパティーは、個々のユーザーおよびグループ検索用のディレクトリベースとオプションの JNDI フィルタ、ユーザーおよびグループ名のプロバイダ固有の属性識別子などを指定します。詳細については、「セキュリティーのプロパティー」を参照してください。

承認

ユーザーは認証されると、さまざまな Message Queue 関連のアクティビティーを実行することを承認されます。Message Queue 管理者は、ユーザーグループを定義し、各ユーザーにグループのメンバーシップを割り当てることができます。デフォルトのアクセス制御プロパティーファイルは、admin という 1 つのグループだけを明示的に参照します (「グループ」を参照)。このグループのユーザーは、admin 接続サービスの接続アクセス権を持ち、送信先の作成、ブローカの監視と制御などの管理機能を実行できます。その他のグループに定義されたユーザーは、デフォルトでは admin サービスの接続アクセス権を取得できません。

ユーザーがある操作を実行しようとすると、ブローカが、ユーザーリポジトリ内のユーザー名とグループのメンバーシップを、アクセス制御プロパティーファイル内のその操作へのアクセスに指定されたユーザー名とグループのメンバーシップと照らし合わせます。アクセス制御プロパティーファイルでは、次の操作に対するユーザーまたはグループのアクセス権を指定します。

暗号化

クライアントとブローカ間で送信されるメッセージを暗号化するには、SSL (Secure Socket Layer) 標準に基づいた接続サービスを使用する必要があります。SSL は、SSL 対応のブローカとクライアント間で暗号化された接続を確立して、接続レベルのセキュリティーを提供します。

SSL ベースの Message Queue 接続サービスを使用するには、キーツールユーティリティー (imqkeytool) を使用して、非公開鍵と公開鍵のペアを生成します。このユーティリティーは、自己署名付き証明書に公開鍵を組み込んで、それを Message Queue のキーストアに配置します。キーストア自体は、パスワードによって保護されているため、起動時に、imq.keystore.password プロパティーに指定されたキーストアのパスワードを入力して、ロックを解除する必要があります。キーストアのロックが解除されると、ブローカは、接続を要求しているクライアントに証明書を渡すことができます。証明書を受け取ると、クライアントはその証明書を使用して暗号化されたブローカへの接続を設定します。

imq.audit.enabled ブローカプロパティーは、Message Queue ブローカログファイルへの監査レコードのロギングを制御します。詳細については、「監査ロギング」を参照してください。

監視サービス

ブローカには、アプリケーションおよびブローカのパフォーマンスを監視し、診断するためのコンポーネントが含まれます。次のコンポーネントがあります。

この仕組みの概略を、図 4–3 に示します。管理サービスを設定するブローカプロパティーを、「監視のプロパティー」に示します。

図 4–3 監視のサポート

図は、ロガーへの入力、エラーレベル、および出力チャネルを示しています。図は文字で説明されます。

メトリックスジェネレータ

メトリックスジェネレータは、ブローカとの間で入出力されるメッセージフロー、ブローカメモリー内のメッセージ数とそれらが消費するメモリー量、開かれている接続の数、使用中のスレッドの数など、ブローカのアクティビティーに関する情報を提供します。ブール型のブローカプロパティー imq.metrics.enabled はそれらの情報を記録するかどうかを制御し、imq.metrics.interval は記録する頻度を指定します。

ロガー

エラーの発生時に、ロガーで、ブローカコードおよびメトリックスジェネレータによって生成された情報が取得され、その情報が標準出力 (コンソール)、ログファイル、Solaris プラットフォーム、syslog デーモンプロセスに書き込まれます。使用するログファイルは imq.log.file.dirpath および imq.log.file.filename ブローカプロパティーで指定し、imq.log.console.stream はコンソールの出力を stdout または stderr のどちらに書き込むかを指定します。

imq.log.level プロパティーは、ロガーが収集するメトリックス情報のカテゴリを制御します。カテゴリは、ERROR、WARNING、または INFO です。各レベルにはそれ以上のレベルも含まれるため、たとえばロギングレベルとして WARNING を指定すると、エラーメッセージも記録されます。imq.log.console.output および imq.log.file.output プロパティーは、指定したカテゴリのどれをコンソールに書き込み、どれをログファイルに書き込むかを制御します。たとえば、エラーと警告の両方をログファイルに書き込み、情報メッセージをコンソールに書き込む場合は、明示的に imq.log.file.output を ERROR|WARNING に設定し、imq.log.console.output を INFO に設定する必要があります。Solaris プラットフォームでは、別のプロパティー imq.log.syslog.output で、syslog デーモンに書き込むメトリックス情報のカテゴリを指定します。デッドメッセージが破棄された場合、またはデッドメッセージキューに移動された場合にログに 記録するかどうかを指定するimq.destination.logDeadMsgs プロパティーもあります。

ログファイルの場合、ファイルを閉じて出力が新しいファイルにロールオーバーされる時点を指定できます。ログファイルが指定したサイズ (imq.log.file.rolloverbytes) または有効期間 (imq.log.file.rolloversecs) に達すると、保存されて新しいログファイルが作成されます。

ログに関連するその他のブローカプロパティーについては、「監視のプロパティー」を参照してください。また、ロガーの設定方法およびロガーを使用してパフォーマンス情報を取得する方法の詳細については、「ブローカロギングの設定と使用」を参照してください。

メトリックスメッセージプロデューサ (Enterprise Edition)

メトリックスメッセージプロデューサは、メトリックスジェネレータから定期的に情報を受け取り、メトリックスメッセージに情報を書き込みます。メトリックスメッセージは、メッセージに含まれるメッセージ情報のタイプに応じて、多数のメトリックストピック送信先のいずれかに送信されます (表 4–2 を参照)。これらのメトリックストピック送信先にサブスクライブされている Message Queue クライアントはメッセージを消費し、それらに含まれるメトリックスを処理できます。これにより、開発者はカスタム監視ツールを作成して、メッセージングアプリケーションをサポートできます。各タイプのメトリックスメッセージで報告されるメトリックス数の詳細は、『Message Queue Developer's Guide for Java Clients』を参照してください。

表 4–2 メトリックスのトピック送信先

トピック名 

メトリックス情報のタイプ

mq.metrics.broker

ブローカのメトリックス 

mq.metrics.jvm

Java 仮想マシンのメトリックス 

mq.metrics.destination_list

送信先とそれらのタイプのリスト 

mq.metrics.destination.queue.queueName

指定したキューの送信先メトリックス 

mq.metrics.destination.topic.topicName

指定したトピックの送信先メトリックス 

ブローカプロパティー imq.metrics.topic.enabled および imq.metrics.topic.interval はそれぞれ、メッセージをメトリックストピック送信先に送信するかどうかと、その頻度を制御します。imq.metrics.topic.timetolive および imq.metrics.topic.persist プロパティーは、それらのメッセージの有効期間とそれらが持続メッセージであるかどうかを指定します。

メトリックスメッセージの本文に含まれる情報以外に、各メッセージのヘッダーには次の追加情報を提供するプロパティーが含まれます。

これらのプロパティーは、異なる種類または異なるブローカからのメトリックスメッセージを処理するクライアントアプリケーションに有用です。

ブローカのプロパティーの設定

ブローカの設定プロパティーは、次のいずれかの方法で指定できます。

次の 2 つの節で、この 2 つのブローカの設定方法について説明します。

設定ファイル

ブローカ設定ファイルには、ブローカを設定するプロパティー設定が格納されます。それらのファイルは、オペレーティングシステムプラットフォームによって異なる場所のディレクトリに保存されます。詳細については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照してください。このディレクトリには、次のファイルが格納されています。

さらに、後述するように、ブローカインスタンスごとに個別のインスタンス設定ファイルがあります。クラスタでブローカインスタンスを接続する場合、クラスタ設定ファイルを使用して、クラスタの設定情報を指定する必要があります。詳細については、「クラスタ設定プロパティー」を参照してください。

起動時に、ブローカはさまざまな設定ファイルのプロパティー値をマージします。図 4–4 に示すように、ファイルは階層を形成し、インスタンス設定ファイルに指定された値によってインストール設定ファイルの値が上書きされ、さらに、これらの値によってデフォルトの設定ファイルの値が上書きされます。階層の最上部で、imqbrokerd コマンドにコマンド行オプションを使用して、設定ファイルに指定されている任意のプロパティー値を手動で上書きできます。

図 4–4 ブローカ設定ファイル

図は、コマンド行オプションが config.properties を上書きし、以下順に install.properties、default options を上書きする状況を示します。

インスタンス設定ファイルの編集

最初にブローカを実行したときに、その特定のブローカインスタンスの設定プロパティーを格納するインスタンス設定ファイルが作成されます。インスタンス設定ファイルは config.properties と呼ばれ、設定ファイルが属するブローカインスタンスの名前によって識別されるディレクトリに格納されます。

…/instances/ instanceName/props/config.properties

instances ディレクトリの場所については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照してください。ファイルが存在しない場合、ブローカの起動時に -name オプションを使用して (「ブローカユーティリティー」を参照)、Message Queue がファイルの作成に使用できるインスタンス名を指定する必要があります。

注 –

instances/instanceName ディレクトリとインスタンス設定ファイルは、対応するブローカインスタンスを作成したユーザーが所有します。ブローカインスタンスは、常に同じユーザーにより再起動されます。

インスタンス設定ファイルは、ブローカインスタンスによって管理され、Message Queue 管理ユーティリティーを使用して設定に変更を加えた場合に変更されます。また、インスタンス設定ファイルを手作業で編集して、ブローカの動作とリソースの使用をカスタマイズできます。手作業で編集するには、instances/ instanceName ディレクトリの所有権が必要です。所有権がなければ、root としてログインしてディレクトリのアクセス権限を変更する必要があります。

ブローカがインスタンス設定ファイルを読み込むのは起動時だけです。ブローカの設定の変更を確定するには、ブローカをシャットダウンして、ファイルを編集し、ブローカを再起動する必要があります。ファイル (または任意の設定ファイル) 内のプロパティーの定義では、次の構文が使われます。

propertyName=value [[,value1] …]

たとえば、次のエントリは、ブローカが追加メッセージを拒否するまでに、メモリーと持続ストレージに最大 50,000 メッセージを保持するように指定します。

imq.system.max_count=50000

次のエントリは、毎日、つまり 86,400 秒ごとに新しいログファイルを作成するように指定します。

imq.log.file.rolloversecs=86400

使用可能なブローカ設定プロパティーとそれらのデフォルト値については、「ブローカサービス」および 第 14 章「ブローカのプロパティーのリファレンス」を参照してください。

コマンド行からの設定オプションの設定

ブローカの起動時、または起動後に、コマンド行からブローカ設定オプションを入力できます。

起動時に、ブローカユーティリティー (imqbrokerd) を使用してブローカインスタンスを起動します。コマンドの -D オプションを使用すると、ブローカの設定プロパティーとその値を指定できます。詳細については、「ブローカの起動」および 「ブローカユーティリティー」を参照してください。サービス管理ユーティリティー (imqsvcadmin) を使用して、Windows サービスとしてブローカを起動している場合、-args オプションを使用して起動時設定プロパティーを指定します。「サービス管理ユーティリティー」を参照してください。

また、ブローカインスタンスの実行中に、特定のブローカプロパティーを変更できます。実行中のブローカの設定を変更するには、コマンドユーティリティーの imqcmd update bkr コマンドを使用します。「ブローカのプロパティーの更新」および 「ブローカ管理」を参照してください。

持続データストアの設定

ブローカの持続データストアには、物理的送信先、永続サブスクリプション、メッセージ、トランザクション、および通知に関する情報が格納されます。Message Queue ブローカはデフォルトで、ファイルベースの持続ストアを使用するように設定されますが、JDBC 互換ドライバからアクセス可能な任意のデータストアに接続するようにブローカを設定し直すことができます。 ブローカ設定プロパティー imq.persist.store (表 14–4 を参照) は 2 つの持続形式のどちらを使用するかを指定します。

この節では、持続ストアを使用するようにブローカを設定する方法を説明します。次のトピックが含まれます。

ファイルベースのストアの設定

ファイルベースのデータストアは、ブローカインスタンスの作成時に自動的に作成されます。このストアは、ブローカのインスタンスディレクトリに配置されます。正確 な場所については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照してください。

デフォルトでは、Message Queue はファイルベースのストアについて、ディスクへの非同期の書き込み操作を実行します。オペレーティングシステムは、このような操作をバッファリングし、パフォーマンスを高めることができます。ただし、不測のシステム障害が書き込み操作の間に発生した場合、メッセージは失われる可能性があります。信頼性を高めるために (パフォーマンスの低下と引き換えに)、データを同時に書き込むように、ブローカプロパティー imq.persist.file.sync を設定できます。このプロパティーの詳細な説明については、「ファイルベースの持続」および 表 14–5 を参照してください。

ブローカインスタンスを起動すると、imqbrokerd コマンドの -reset オプションを使用してファイルシステムストアを消去できます。このオプションおよびサブオプションの詳細は、「ブローカユーティリティー」を参照してください。

JDBC ベースのストアの設定

JDBC ベースの持続を使用するようにブローカを設定するには、ブローカインスタンス設定ファイルで JDBC 関連のプロパティーを設定し、適切なデータベーススキーマを作成します。Message Queue のデータベースマネージャーユーティリティー (imqdbmgr) は、JDBC ドライバとブローカ設定プロパティーを使用してデータベースを作成し、管理します。さらに、破損したテーブルをデータベースから削除する場合や別のデータベースをデータストアとして使用する場合に、データベースマネージャーを使用することもできます。詳細については、「データベースマネージャーユーティリティー」を参照してください。

注 –

Oracle および PointBase データベース製品の設定例を参照できます。これらのファイルの場所は、プラットフォームによって異なり、付録 A 「プラットフォームごとの Message QueueTM データの場所」 の関連する表内の「アプリケーションと設定の例」に記載されています。さらに、PointBase の組み込みバージョン、PointBase サーバーバージョン、および Oracle の例は、インスタンス設定ファイル config.properties 内でコメントアウトされた値として提供されています。

ProcedureJDBC ベースのデータストアを設定する

  1. ブローカの設定ファイルに、JDBC 関連のプロパティーを設定します。

    関連プロパティーについては、「JDBC ベースの持続」で説明し、表 14–6 に示しています。特に、ブローカの imq.persist.store プロパティーを jdbc に設定する必要があります (「持続のプロパティー」を参照)。

  2. 次の場所の JDBC ドライバの .jarファイルにコピーまたはシンボリックリンクを配置します。

    • Solaris の場合:


      /usr/share/lib/imq/ext/

    • Linux の場合:


      /opt/sun/mq/share/lib/

    • Windows の場合:


      IMQ_VARHOME\\lib\\ext

    たとえば、Solaris システムで PointBase を使用している場合、次のコマンドでドライバの .jar ファイルを適切な場所にコピーします。


    % cp j2eeSDKInstallDirectory/pointbase/lib/pointbase.jar /usr/share/lib/imq/ext

    次のコマンドはシンボリックリンクを作成します。


    % ln -s j2eeSDKID/lib/pointbase/pointbase.jar /usr/share/lib/imq/ext

  3. Message Queue の持続に必要なデータベーススキーマを作成します。

    組み込みデータベース用の imqdbmgr create all コマンドまたは外部データベース用の imqdbmgr create tbl コマンドを使用します。「データベースマネージャーユーティリティー」を参照してください。

    1. imqdbmgr がある場所にディレクトリを変更します。

      • Solaris の場合:


        cd /usr/bin

      • Linux の場合:


        cd /opt/sun/mq/bin

      • Windows の場合:


        cd IMQ_HOME\\bin

    2. imqdbmgr コマンドを入力します。

      imqdbmgr create all

      注 –

      組み込みデータベースを使用している場合、次のディレクトリ内に作成するのが最適です。

      … /instances/ instanceName/dbstore/ databaseName

      組み込みデータベースは、ユーザー名とパスワードで保護されていない場合、ファイルシステムのアクセス権によって保護される可能性があります。ブローカが確実にデータベースに対して読み取りと書き込みを実行できるようにするため、ブローカを実行するユーザーは、imqdbmgr コマンドを使用して組み込みデータベースを作成したユーザーと同一でなければなりません。

持続データの保護

持続ストアにはほかの情報とともに、一時的に保存されるメッセージファイルを保存できます。これらのメッセージには専有情報が保持されている場合があるため、認可されていないアクセスからデータストアを保護することをお勧めします。この節では、ファイルベースまたは JDBC ベースのデータストアでデータを保護する方法を説明します。

ファイルベースのストアの保護

ファイルベースの持続を使用するブローカは、プラットフォームにより場所が異なる単層型ファイルのデータストアに持続データを書き込みます (付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照)。

…/instances/ instanceName/fs350/

instanceName には、ブローカインスタンスを識別する名前が入ります。

instanceName/fs350/ ディレクトリは、ブローカインスタンスがはじめて開始されたときに作成されます。このディレクトリを保護するための手順は、ブローカを実行しているオペレーティングシステムプラットフォームによって異なります。

JDBC ベースのストアの保護

JDBC ベースの持続を使用するブローカは、JDBC 互換データベースに持続データを書き込みます。Oracle などのデータベースサーバーによって管理されるデータベースについては、Message Queue のデータベーステーブル (IMQ で始まる名前が付けられたテーブル) にアクセスするためのユーザー名とパスワードを作成することをお勧めします。データベースで個々のテーブルの保護ができない場合、Message Queue ブローカだけが使用する専用のデータベースを作成します。ユーザー名とパスワードのアクセス権を作成する方法については、データベースベンダーによって提供されているマニュアルを参照してください。

データベース接続を開くためにブローカが求めるユーザー名とパスワードは、ブローカ設定プロパティーとして与えることができます。ただし、imqbrokerd コマンドの -dbuser および -dbpassword オプションを使用して、ブローカの起動時にコマンド行オプションとして入力するほうがより安全です (「ブローカユーティリティー」を参照)。

データベースの JDBC ドライバを使用してブローカが直接アクセスする組み込みデータベースの場合、「ファイルベースのストアの保護」で説明したように、通常は持続データが格納されるディレクトリにファイルアクセス権を設定することでセキュリティーが確保されます。ただし、データベースをブローカとデータベースマネージャーユーティリティーの両方から読み取り可能および書き込み可能にするためには、いずれも同じユーザーにより実行される必要があります。