第 4 章ブローカの設定

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

ブローカサービス

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

接続サービスはブローカとそのクライアント間の物理的な接続を管理し、送受信メッセージの転送を行います。

ルーティングサービスは JMS ペイロードメッセージをルーティングし、配信するほか、メッセージサービスによって使用されるメッセージを制御し、信頼性の高い配信をサポートします。

持続サービスは持続ストレージへのデータの書き込みと、持続ストレージからのデータの取得を管理します。

セキュリティーサービスはブローカに接続するユーザーを認証し、ユーザーの操作を承認します。

監視サービスはブローカのパフォーマンスに関するメトリックスと診断情報を生成します。

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

接続サービス

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

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

service type は、JMS メッセージ配信サービス (NORMAL)、または Message Queue 管理サービス (ADMIN) のどちらを提供するのかを指定します。

プロトコルタイプは基礎となるトランスポートプロトコルを指定します。

表 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 つの接続専用であるか、複数の接続で共有するかどうかを指定します。

専用モデルでは、ブローカへの接続ごとに受信メッセージ用と出力メッセージ用の 2 つのスレッドが必要です。これによって、サポート可能な接続数が制限されますが、パフォーマンスは向上します。

共有モデルでは、メッセージが送信または受信されると、接続が共有スレッドによって処理されます。接続ごとに専用スレッドが必要ないため、このモデルでは使用可能な接続数が増加しますが、それと引き換えに、スレッド管理に追加のオーバーヘッドが必要なため、パフォーマンスが低下します。

ブローカの 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 つのレベルで機能します。

システム全体のメッセージ制限は、システム上のすべての物理的送信先にまとめて適用されます。これらには、ブローカが保持するメッセージの最大数 (imq.system.max_count) やそれらのメッセージが占有する最大合計バイト数 (imq.system.max_size) などがあります。これらのいずれかの制限に達した場合、ブローカは、保留メッセージが制限以下になるまで、新しいメッセージを拒否します。各メッセージの最大サイズ (imq.message.max_size) や期限切れメッセージの再利用の間隔 (imq.message.expiration.interval) にも制限があります。

個々の送信先の制限は特定の物理的送信先へのメッセージを制限します。これらの制限を制御する設定プロパティーについては、第 15 章「物理的送信先のプロパティーのリファレンス」で説明しています。たとえば、送信先で保持するメッセージの数とサイズ、作成可能なメッセージのプロデューサとコンシューマの数、送信先にバッチ配信できるメッセージの数の制限などがあります。

送信先は、メッセージプロデューサによるメッセージの配信速度を遅くするか、新しい受信メッセージを拒否するか、もっとも古いか優先度がもっとも低い既存のメッセージを破棄するかによって、メモリー制限に対処するように設定できます。この方法で送信先から削除されるメッセージは、完全に削除するのではなく、オプションでデッドメッセージキューに移動できます。ブローカプロパティー imq.destination.DMQ.truncateBody が、デッドメッセージキューにメッセージ本体全体を保存するのか、ヘッダーとプロパティーデータのみを保存するのかを制御します。

アプリケーションの開発とテスト時の利便性のため、メッセージプロデューサまたはコンシューマが存在しない送信先にアクセスしようとした場合に、新しい物理的送信先を自動的に作成するように、メッセージブローカを設定できます。表 14-3 にまとめられているブローカプロパティーは、ここで説明したプロパティーとほとんど同じですが、管理者によって作成される送信先ではなく、自動的に作成される送信先に適用されます。

システムメモリーのしきい値は、ブローカがメモリーの過負荷を防ぐために段階的に重大なアクションをとるメモリー使用率のレベルを定義します。それらの利用率のレベルが 4 つ定義されています。

Green: 使用可能なメモリーが十分にあります。

Yellow: ブローカメモリーが不足し始めています。

Orange: ブローカのメモリーが不十分です。

Red: ブローカのメモリーが不足しています。

これらのレベルを定義するメモリー利用率は、ブローカプロパティー imq.green.threshold、imq.yellow.threshold、imq.orange.threshold、および imq.red.threshold でそれぞれ指定します。green のデフォルト値は 0%、yellow のデフォルト値は 80%、orange のデフォルト値は 90%、red のデフォルト値は 98% です。

メモリー利用率が次のレベルに進むと、ブローカは漸進的に対応します。まず、メッセージをアクティブなメモリーから持続ストレージにスワップし、次に、持続的でないメッセージのプロデューサの処理速度を低下させ、最終的にブローカへのメッセージフローを止めます。これらのアクションはどちらもブローカのパフォーマンスを低下させます。メッセージの生成を徐々に減らすには、配信される各バッチのサイズを、プロパティー imq.resourceState.count によって指定されたメッセージ数に制限します。ここで、resourceState はそれぞれ green、yellow、orange、またはred です。



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

持続サービス

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

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

ファイルベースの持続

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

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


注	持続データストアには機密事項を扱うメッセージや財産的価値のあるメッセージが含まれることがあるため、.../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 を参照してください。

セキュリティーサービス

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


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

認証は、確認されたユーザーのみがブローカとの接続を確立できるようにします。

承認は、リソースにアクセスし、特定の操作を実行する権限を持つユーザーやグループを指定します。

暗号化は、接続によるメッセージの配信中の書き換えを防止します。

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

単層型ファイルリポジトリを選択した場合は、Message Queue ユーザーマネージャーユーティリティー (imqusermgr) を使用して、リポジトリを管理する必要があります。このオプションは組み込みであるため、簡単に使用できます。

既存の LDAP サーバーを使用する場合は、LDAP ベンダーから提供されているツールを使用して、ユーザーリポジトリを設定、管理します。さらに、ブローカがユーザーとグループに関する情報について LDAP サーバーをクエリーできるようにするため、ブローカのインスタンス設定ファイルにもプロパティーを設定する必要があります。

ブローカの 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 ブローカログファイルへの監査レコードのロギングを制御します。詳細については、「監査ログの作成」を参照してください。

監視サービス

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

データを生成するコンポーネント (イベントを記録するメトリックスジェネレータとブローカコード)

多数の出力チャネルに情報を書き込むロガーコンポーネント

メトリックス情報を含む JMS メッセージを、JMS 監視クライアントによって消費させるためにトピック送信先へ送るメトリックスメッセージプロデューサ

この仕組みの概略を、図 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 Queue データの場所」を参照してください。このディレクトリには、次のファイルが格納されています。

起動時に読み込まれるデフォルトの設定ファイル default.properties。このファイルは編集できませんが、デフォルトの設定を決定したり、変更するプロパティーの正確な名前を検索したりする場合、このファイルに目を通すといいでしょう。

Message Queue のインストール時に指定されたプロパティーを格納するインストール設定ファイル install.properties。このファイルはインストール後に編集できません。

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

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

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

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


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

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

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

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

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

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

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

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

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

持続データストアの設定

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

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

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

「JDBC ベースのストアの設定」

「持続データの保護」

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

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

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

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

JDBC ベースのストアの設定

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



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

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

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

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

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

/usr/share/lib/imq/ext/ (Solaris)
/opt/sun/mq/share/lib/ (Linux)
IMQ_VARHOME¥lib¥ext (Windows)

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

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

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

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

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

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

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

cd /usr/bin (Solaris)
cd /opt/sun/mq/bin (Linux)
cd IMQ_HOME¥bin (Windows)

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

imqdbmgr create all



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

持続データの保護

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

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

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

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

Solaris および Linux の場合、ディレクトリのアクセス権は、ブローカインスタンスを開始したユーザーのファイルモード作成マスク (umask) によって決定されます。したがって、ブローカインスタンスの開始および持続ファイルの読み取りを行うためのアクセス権は、マスクを適切に設定することによって制限できることになります。あるいは、スーパーユーザーである管理者は、instances ディレクトリのアクセス権を 700 に設定することによって、持続データを保護できます。

Windows の場合、ディレクトリのアクセス権は、Windows オペレーティングシステムが提供するメカニズムを使って設定できます。この操作では、通常そのディレクトリの「プロパティー」ダイアログを開きます。

JDBC ベースのストアの保護

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

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

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

前へ目次索引次へ
Sun Java System Message Queue 3 2005Q4 管理ガイド