パート II 管理タスク

• 第 3 章「ブローカとクライアントの起動」

• 第 4 章「ブローカの設定」

• 第 5 章「ブローカの管理」

• 第 6 章「物理的送信先の管理」

• 第 7 章「セキュリティーの管理」

• 第 8 章「管理対象オブジェクトの管理」

• 第 9 章「ブローカクラスタを使用した作業」

• 第 10 章「ブローカの監視」

• 第 11 章「メッセージサービスの分析と調整」

• 第 12 章「問題のトラブルシューティング」

第 3 章 ブローカとクライアントの起動

Sun Java System^TM Message Queue^TM をインストールし、いくつかの準備手順を実行したあと、ブローカとクライアントを起動できます。ブローカの設定は、設定ファイルセットと、ブローカユーティリティー (imqbrokerd) に渡されるコマンド行オプションによって決まります。詳細については、第 4 章「ブローカの設定」を参照してください。

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

• 「システムリソースの準備」

• 「ブローカの起動」

• 「ブローカの削除」

• 「クライアントの起動」

システムリソースの準備

ブローカを起動する前に、2 つの予備的なシステムレベルのタスク、すなわちシステムクロックの同期と、Solaris または Linux プラットフォームの場合のファイル記述子の制限の設定を行います。次の節では、これらのタスクについて説明します。

システムクロックの同期

ブローカまたはクライアントを起動する前に、Message Queue システムと対話するすべてのホスト上のクロックを同期する必要があります。メッセージの有効期限 (生存期間) を使用する場合には、同期は特に重要です。同期されていないクロックのタイムスタンプは、メッセージの有効期限が予想どおりに機能するのを阻害し、メッセージの配信を阻害します。同期はブローカクラスタにとっても重要です。

システムを設定し、Simple Network Time Protocol (SNTP) などの時間同期プロトコルを実行するようにします。時間同期は一般に、Solaris と Linux の場合は xntpd デーモンで、Windows の場合は W32Time サービスでサポートされます。このサービスの設定に関する詳細は、オペレーティングシステムのマニュアルを参照してください。ブローカを実行したあと、システムクロックが逆戻り設定されるのを防いでください。

ファイル記述子制限の設定

Solaris および Linux プラットフォームでは、クライアントやブローカが実行されるシェルによって、プロセスで使用できるファイル記述子の数に対する弱い制限値があります。Message Queue では、クライアントが行う接続、あるいはブローカが受け付ける接続はすべて、これらのファイル記述子のいずれかを使用します。持続メッセージを持つ物理的な送信先もすべて、ファイル記述子を使用します。

その結果、ファイル記述子の制限によって、ブローカまたはクライアントの接続数が制限されます。デフォルトで最大の接続数は Solaris で 256、Linux で 1024 です。実際には、持続性のためにファイル記述子を使用することから、接続数の制限はこの値より小さくなります。これ以上の接続を必要とする場合は、クライアントまたはブローカが実行する各シェルのファイル記述子制限を拡大する必要があります。この方法については、ulimit マニュアルページを参照してください。

ブローカの起動

Message Queue コマンド行ユーティリティーまたは Windows の「スタート」メニューを使用して、ブローカをインタラクティブに起動できます。または、システムの起動時に自動的に起動するように調整できます。次の節で、この方法について説明します。

ブローカのインタラクティブな起動

ブローカユーティリティー (imqbrokerd) を使用すると、コマンド行からブローカをインタラクティブに起動できます。Windows の場合は「スタート」メニューからブローカを起動できます。ブローカの起動に管理コンソール (imqadmin) やコマンドユーティリティー (imqcmd) を使用することはできません。これらのツールを使用する前に、ブローカが実行されている必要があります。

Solaris と Linux プラットフォームでは、ブローカインスタンスは必ずブローカを最初に起動したユーザーと同一のユーザーが起動します。各ブローカインスタンスは、固有の設定プロファイルとファイルベースのメッセージストアを保有します。ブローカインスタンスを最初に起動するとき、Message Queue はユーザーのファイル作成モードマスク (umask) を使用して、ブローカインスタンスの設定情報と持続データを格納するディレクトリに、アクセス権を設定します。

ブローカインスタンスには、デフォルトでインスタンス名 imqbroker が割り当てられます。この名前とデフォルト設定を使用してコマンド行からブローカを起動するには、次のコマンドを使用します。

imqbrokerd

このコマンドにより、デフォルトポート 7676 のポートマッパーを持つローカルマシン上にある、ブローカのインスタンス (imqbroker) が起動されます (「ポートマッパー」を参照)。

デフォルト以外のインスタンス名を指定する場合は、imqbrokerd コマンドに - name オプションを使用します。次のコマンドは、インスタンス名 myBroker を持つブローカを起動します。

imqbrokerd -name myBroker

imqbrokerd コマンド行では、ブローカの操作のさまざまな面を制御するその他のオプションも使用できます。次の例では、-tty オプションを使用してコマンドウィンドウにエラーと警告を送信します (標準出力)。

imqbrokerd -name myBroker -tty

コマンド行で -D オプションを使用しても、ブローカのインスタンス設定ファイル (config.properties) で指定されたプロパティーの値を上書きすることができます。この例では、imq.jms.max_threads プロパティーを設定して、jms 接続サービスが利用できる最大スレッド数を 2000 に上げています。

imqbrokerd -name myBroker -Dimq.jms.max_threads=2000

imqbrokerd コマンドの構文、サブコマンド、オプションの詳細は、「ブローカユーティリティー」を参照してください。この情報の簡単な概要については、次のコマンドで確認します。

imqbrokerd -help

Sun Java System Message Queue Platform Edition ライセンスを保有している場合は、imqbrokerd コマンドの - license オプションを使用して、Enterprise Edition の試用ライセンスをアクティブにして、Enterprise Edition の機能を 90 日間試用できます。ライセンス名に try を指定します。

imqbrokerd -license try

ブローカを起動するたびにこのオプションを使用する必要があります。使用しない場合、デフォルトで Platform Edition の標準ライセンスに戻ります。

ブローカの自動起動

コマンド行からブローカを明示的に起動する代わりに、システムの起動時に自動的にブローカが起動するように設定できます。この方法は、ブローカを実行するプラットフォーム (Solaris、Linux、または Windows) により異なります。

Solaris と Linux での自動起動

Solaris と Linux システムの場合、自動起動を有効にするスクリプトを Message Queue のインストール時に /etc/rc* ディレクトリツリーに配置します。このスクリプトの使用を有効にする場合、設定ファイル /etc/imq/imqbrokerd.conf (Solaris) または /etc/opt/sun/mq/imqbrokerd.conf (Linux) を次のように編集します。

• システムの起動時に自動的にブローカを起動させるには、AUTOSTART プロパティーを YES に設定します。

• 異常終了の後、ブローカを自動的に再起動させるには、RESTART プロパティーを YES に設定します。

• ブローカの起動コマンド行引数を設定するには、ARGS プロパティーに 1 つ以上の値を指定します。

Windows での自動起動

Windows システムの起動時にブローカを自動的に起動させるには、ブローカをWindows サービスとして定義する必要があります。そうすることで、ブローカはシステムの起動時に起動し、システムがシャットダウンされるまで、バックグランドで実行されます。したがって、別のインスタンスを起動する必要がないかぎり、ブローカを起動するのに imqbrokerd コマンドを使用することはありません。

システムで Windows サービスとして実行できるブローカは 1 つのみです。タスクマネージャーには、そうしたブローカが 2 つの実行可能プロセスとして表示されます。

• Windows のネイティブサービスラッパー、imqbrokersvc.exe

• ブローカを実行中の Java ランタイム

Windows システムで Message Queue をインストールしている場合、ブローカをサービスとしてインストールできます。インストール後、サービス管理ユーティリティー imqsvcadmin を使用して、次の操作を実行します。

• Windows のサービスとしてブローカを追加

• ブローカサービスの起動オプションを決定

• Windows サービスとして実行中のブローカを削除

ブローカに起動オプションを渡すには、imqsvcadmin コマンドに -args 引数を使用します。これは 「ブローカの起動」で説明するように、imqbrokerd コマンドの -D オプションと同じように機能します。ブローカの動作を通常どおり制御するには、コマンドユーティリティー (imqcmd) を使用します。

imqsvcadmin コマンドの構文、サブコマンド、オプションの詳細は、「サービス管理ユーティリティー」を参照してください。

ブローカサービスの再設定

Windows サービスとしてインストールしたブローカを再設定する手順は次のとおりです。

Windows サービスとして実行中のブローカを再設定する

1. サービスを停止します。

   1. Windows の「スタート」メニューのサブメニュー「設定」から、「コントロール パネル」を選択します。

   2. 「管理ツール」コントロールパネルを開きます。

   3. 「サービス」ツールのアイコンを選択し、「ファイル」メニューから「開く」、またはポップアップコンテキストメニューから選択するか、単にアイコンをダブルクリックして、サービスツールを実行します。

   4. 「サービス (ローカル)」の下の「Message Queue Broker」サービスを選択し、「操作」メニューから「プロパティ」を選択します。

      または、「Message Queue Broker」を右クリックし、ポップアップコンテキストメニューから「プロパティ」を選択するか、単に「Message Queue Broker」をダブルクリックします。どちらの場合も「Message Queue Broker のプロパティ」ダイアログボックスが表示されます。

   5. 「Message Queue Broker のプロパティ」ダイアログの「全般」タブで、「停止」をクリックして、ブローカサービスを停止します。

2. サービスを削除します。

   コマンド行で、次のコマンドを入力します。

   imqsvcadmin remove

3. サービスを再インストールし、異なるブローカ起動オプション -args、または異なる Java バージョン引数、-vmargs オプションを指定します。

   たとえば、サービスのホスト名とポート番号を broker1 と 7878 に変更する場合、次のコマンドを使用します。

   imqsvcadmin install -args "-name broker1 -port 7878"

代替 Java ランタイムの使用

代替の Java ランタイムの場所を指定する場合、imqsvcadmin コマンドの -javahome オプションまたは -jrehome オプションのどちらかを使用することができます。これらのオプションは、サービスの「プロパティ」ダイアログウィンドウの「全般」タブの「開始パラメータ」フィールドに指定することもできます。

「開始パラメータ」フィールドでは、円記号 (\\ ) がエスケープ文字として処理されるため、パスの区切り文字として使用する場合、次のように円記号を 2 つ入力してください。

-javahome c:\\\\j2sdk1.4.0

ブローカサービス起動オプションの表示

ブローカサービスの起動オプションを指定するには、例 3–1 に示すように、imqsvcadmin コマンドに query オプションを指定します。

例 3–1 ブローカサービス起動オプションの表示

imqsvcadmin query

Service Message Queue Broker is installed.
Display Name: Message Queue Broker
Start Type: Automatic
Binary location: C:\\Sun\\MessageQueue\\bin\\imqbrokersvc.exe
JavaHome: c:\\j2sdk1.4.0
Broker Args: -name broker1 -port 7878

サービス開始時の問題のトラブルシューティング

ブローカを Windows サービスとして開始しようとしたときにエラーが発生する場合、記録されているエラーイベントを確認できます。

記録されているサービスのエラーイベントを表示する

1. Windows の「管理ツール」コントロールパネルを開きます。

2. 「イベントビューア」ツールを起動します。

3. 「アプリケーション」イベントログを選択します。

4. 「操作」メニューから「最新の情報に更新」を選択して、エラーイベントを表示します。

ブローカの削除

ブローカを削除する手順もプラットフォームによって異なります。次の節で説明します。

Solaris または Linux でのブローカの削除

Solaris または Linux プラットフォームでブローカインスタンスを削除するには、imqbrokerd コマンドに -remove オプションを指定して実行します。このコマンドの形式は次のようになります。

imqbrokerd [options…] -remove instance

たとえば、ブローカの名前が myBroker の場合、コマンドは次のようになります。

imqbrokerd -name myBroker -remove instance

このコマンドは、指定されたブローカのインスタンスディレクトリ全体を削除します。

システムの起動時に自動起動するようにブローカが設定されている場合、設定ファイル /etc/imq/imqbrokerd.conf (Solaris) または /etc/opt/sun/mq/imqbrokerd.conf (Linux) を編集し、AUTOSTART プロパティーを NO に設定します。

imqbrokerd コマンドの構文、サブコマンド、オプションの詳細は、「ブローカユーティリティー」を参照してください。この情報の簡単な概要については、次のコマンドで確認します。

Windows ブローカサービスの削除

Windows サービスとして実行中のブローカを削除するには、次のコマンドを使用して、

imqcmd shutdown bkr

ブローカをシャットダウンし、続けて次のコマンドを使用して、

imqsvcadmin remove

サービスを削除します。

または、管理ツールコントロールパネルから到達できる Windows サービスツールを使用して、ブローカサービスを停止し、削除することもできます。

ブローカサービスを削除したら、コンピュータを再起動します。

クライアントの起動

クライアントアプリケーションを起動する前に、アプリケーション開発者からシステムの設定方法に関する情報を入手します。Java クライアントアプリケーションを起動する場合、CLASSPATH 変数を適切に設定し、正しい .jar ファイルがインストールされていることを確認します。システムの設定の一般的な手順については、『Message Queue Developer's Guide for Java Clients』で説明していますが、開発者が追加情報を提供する場合があります。

Java クライアントアプリケーションを起動するには、次のコマンド行形式を使用します。

java clientAppName

C クライアントアプリケーションを起動するには、アプリケーション開発者が提供した形式を使用します。

アプリケーションのマニュアルには、アプリケーションで設定される属性値に関する情報が提供されています。これらの属性値をコマンド行から上書きできます。また、JNDI (Java Naming and Directory Interface) 検索により接続ファクトリを検索する Java クライアントに対して、コマンド行で属性を指定することもできます。検索でアプリケーションよりも古い接続ファクトリが戻される場合、その接続ファクトリは最新の属性をサポートしない可能性があります。そのような場合、Message Queue はこれらの属性にデフォルト値を設定します。必要に応じて、コマンド行を使用して、これらのデフォルト値を上書きできます。

コマンド行から、Java アプリケーションの属性値を指定するには、次の構文を使用します。

java [[-Dattribute=value]
…] clientAppName

attribute の値は、第 16 章「管理対象オブジェクト属性のリファレンス」で説明するように、接続ファクトリの管理対象オブジェクトの属性になる必要があります。値にスペースが入る場合は、コマンド行の attribute= value 部分を引用符で囲みます。

次の例は、MyMQClient というクライアントアプリケーションを起動し、ホスト OtherHost のポート 7677 のブローカに接続します。

java -DimqAddressList=mq://OtherHost:7677/jms MyMQClient

コマンド行で指定したホスト名およびポートによって、アプリケーション自体で設定された属性値が上書きされます。

場合によっては、コマンド行で属性値を指定できません。管理者は読み取りアクセス専用を許可するように管理対象オブジェクトを設定できます。または、アプリケーション開発者が、クライアントアプリケーションに読み取り専用を許可するようにコーディングできます。アプリケーション開発者との通信は、クライアントプログラムの起動の最適な方法を理解するのに必要です。

第 4 章 ブローカの設定

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

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

• 「ブローカサービス」

• 「ブローカのプロパティーの設定」

• 「持続データストアの設定」

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

ブローカサービス

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

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

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

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

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

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

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

接続サービス

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

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

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

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

ブローカの 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™ (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアにブローカを接続します。ファイルベースの持続は一般に JDBC ベースより高速ですが、JDBC 互換ストアによって実現される冗長性や管理者による制御を好むユーザーもいます。ブローカ設定プロパティー imq.persist.store (表 14–4 を参照) は 2 つの持続形式のどちらを使用するかを指定します。

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

ファイルベースの持続

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

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

…/instances/instanceName
/fs350/

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

持続データストアには機密事項を扱うメッセージや財産的価値のあるメッセージが含まれることがあるため、…/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) リポジトリに接続できます。

• 単層型ファイルリポジトリを選択した場合は、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 に示します。管理サービスを設定するブローカプロパティーを、「監視のプロパティー」に示します。

図 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』を参照してください。

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

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

• メッセージのタイプ

• メッセージを送信したブローカのアドレス (ホスト名とポート番号)

• メトリックスサンプルを採取した時間

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

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

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

• ブローカの設定ファイルを編集する

• コマンド行から直接プロパティー値を入力する

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

設定ファイル

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

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

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

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

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

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

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

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

…/instances/ instanceName/props/config.properties

instances ディレクトリの場所については、付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照してください。ファイルが存在しない場合、ブローカの起動時に -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 つの持続形式のどちらを使用するかを指定します。

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

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

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

• 「持続データの保護」

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

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

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

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

JDBC ベースのストアの設定

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

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

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

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 Queue^TM データの場所」を参照)。

…/instances/ instanceName/fs350/

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

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

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

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

JDBC ベースのストアの保護

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

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

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

第 5 章 ブローカの管理

この章では、imqcmd ユーティリティーを使用して、ブローカおよびそのサービスを管理する方法について説明します。この章では、次の節について説明します。

• 「前提条件」

• 「imqcmd ユーティリティーの使用」

• 「ブローカ情報の表示」

• 「ブローカのプロパティーの更新」

• 「ブローカの停止および再開」

• 「ブローカのシャットダウンと再起動」

• 「ブローカのメトリックスの表示」

• 「接続サービスの管理」

• 「接続情報の入手」

• 「永続サブスクリプションの管理」

• 「トランザクションの管理」

この章ではブローカの管理に関連したすべてのトピックは扱いません。その他のトピックは、次の章で個別に扱っています。

• ブローカでの物理的送信先の管理。物理的送信先の作成、表示、更新、破棄の方法、およびデッドメッセージキューの使い方といったトピックの詳細は、第 6 章「物理的送信先の管理」を参照してください。

• ブローカのセキュリティー設定。ユーザー認証、アクセス制御、暗号化、パスワードファイル、監査ロギングなどのトピックの詳細は、第 7 章「セキュリティーの管理」を参照してください。

前提条件

ブローカの管理には、imqcmd および imqusermgr コマンド行ユーティリティーを使用します。ブローカを管理する前に、次の作業が必要です。

• imqbrokerd ユーティリティーコマンドを使用して、ブローカを起動します。ブローカを実行するまで、ほかのコマンド行ユーティリティーは使用できません。

• Message Queue^TM 管理ユーザーを設定するか、デフォルトアカウントを使用するかを決定します。管理コマンドを使用する場合、ユーザー名とパスワードを指定する必要があります。

  Message Queue をインストールすると、デフォルトの単層ファイルのユーザーリポジトリがインストールされます。リポジトリは 2 つのデフォルトエントリと一緒に出荷されます (管理ユーザーとゲストユーザー)。Message Queue をテストする場合、デフォルトのユーザー名とパスワード (admin/admin) を使用して、imqcmd ユーティリティーを実行できます。

  本稼動システムをセットアップする場合は、管理ユーザーの認証および認可を設定する必要があります。ファイルベースのユーザーリポジトリの設定、または LDAP ディレクトリサーバーを使用する設定の詳細は、第 7 章「セキュリティーの管理」を参照してください。本稼働環境では、セキュリティー上の理由によりデフォルト以外のユーザー名とパスワードを使用することをお勧めします。

• ブローカとの安全な接続を使用する場合、ターゲットブローカインスタンスで ssladmin サービスを設定し有効化します。詳細は、「メッセージの暗号化」を参照してください。

imqcmd ユーティリティーの使用

imqcmd ユーティリティーを使用すると、ブローカとブローカのサービスを管理できます。

imqcmd コマンドの構文、サブコマンド、オプションの詳細は、第 13 章「コマンド行のリファレンス」を参照してください。物理的送信先の管理の詳細は、第 15 章「物理的送信先のプロパティーのリファレンス」で個別に扱っています。

ヘルプの表示

imqcmd ユーティリティーでヘルプを表示するには、-h オプションまたは -H オプションを使用し、サブコマンドは使用しません。特定のサブコマンドのヘルプは表示されません。

たとえば、次のコマンドは imqcmd に関するヘルプを表示します。

imqcmd -H

サブコマンドまたはその他のオプションに加えて、-h オプションまたは -H オプションを指定してコマンド行を入力した場合、imqcmd ユーティリティーは -h オプションまたは -H オプションのみを処理します。コマンド行のほかのすべての項目は無視されます。

製品のバージョンの表示

Message Queue の製品のバージョンを表示するには、-v オプションを使用します。たとえば、次のように指定します。

imqcmd -v

サブコマンドまたはその他のオプションに加えて、-v オプションを指定してコマンド行を入力した場合、imqcmd ユーティリティーは -v オプションのみを処理します。コマンド行のほかのすべての項目は無視されます。

ユーザー名とパスワードの指定

それぞれの imqcmd サブコマンドはユーザーリポジトリに対して認証されるため、ユーザー名とパスワードが必要になります。ただし、ヘルプを表示するための -h または -H オプションを使用するコマンド、および製品のバージョンを表示するための -v オプションを使用するコマンドには必要ありません。

ユーザー名を指定する

管理ユーザー名を指定する場合は、-u オプションを使用します。ユーザー名を省略すると、コマンドから入力が要求されます。たとえば、次のコマンドはデフォルトのブローカに関する情報を表示します。

imqcmd query bkr -u admin

この章の例を読みやすくするために、デフォルトのユーザー名 admin は -u オプションの引数として示しています。本稼動環境では、カスタムユーザー名を使用します。

パスワードを指定する

パスワードは次のいずれかの方法で指定します。

• パスワードファイル (passfile) を作成し、そのファイルにパスワードを入力します。コマンド行で、-passfile オプションを使用してパスワードファイルの名前を指定します。

• コマンドからパスワードの入力が要求されるようにします。

これまでのバージョンの Message Queue では、-p オプションを使用して imqcmd コマンド行にパスワードを指定できました。このオプションは廃止される可能性があり、最終的には削除される予定です。

ブローカ名とポートの指定

imqcmd のデフォルトブローカは、ローカルホストで実行中のブローカであり、デフォルトポートは 7676 です。

リモートホストで実行中のブローカまたはデフォルト以外のポートで待機中のブローカ、あるいはその両方にコマンドを発行する場合、-b オプションを使用してブローカのホストとポートを指定する必要があります。

例

この節の例は、imqcmd の使い方を表しています。

最初の例では、localhost のポート 7676 で実行中のブローカのプロパティーを一覧表示しているため、-b オプションは不要です。このコマンドはデフォルトの管理ユーザー名 (admin) を使用してパスワードを省略しています。したがってコマンドで入力が要求されています。

imqcmd query bkr -u admin

次の例では、ホスト myserver のポート 1564 で実行中のブローカのプロパティーを一覧表示しています。ユーザー名は aladdin です。このコマンドが機能するためには、ユーザーリポジトリを更新して、aladdin を admin グループに追加する必要がある場合があります。

imqcmd query bkr -b myserver:1564 -u aladdin

次の例では、localhost のポート 7676 で実行中のブローカのプロパティーを一覧表示しています。このコマンドの最初のタイムアウトは 20 秒に設定され、タイムアウト後の再試行回数が 7 回に設定されています。ユーザーのパスワードは、コマンドを呼び出したときに現在のディレクトリにある myPassfile と呼ばれるパスワードファイル内に格納されています。

imqcmd query bkr -u admin -passfile myPassfile -rtm 20 -rtr 7

ブローカとの安全な接続を確立するために、これらの例では -secure オプションを指定することもできます。ssladmin サービスが設定および起動されていれば、imqcmd は -secure オプションを指定したときに ssladmin サービスを使用します。

ブローカ情報の表示

シングルブローカに関する情報のクエリーと表示を行うには、query bkr サブコマンドを使用します。

次に示すのは、query bkr サブコマンドの構文です。

imqcmd query bkr -b hostName:
portNumber

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカの現在のプロパティーの設定を一覧表示します。また、特定のブローカに接続している実行中のブローカ (マルチブローカクラスタ内のブローカ) のリストも表示されます。

たとえば、次のように指定します。

imqcmd query bkr -u admin

パスワードの入力を要求した後、コマンドは次のような出力を生成します。

Version                                              3.6
Instance Name                                        imqbroker
Primary Port                                         7676
                                                   
Current Number of Messages in System                 0
Current Total Message Bytes in System                0

Current Number of Messages in Dead Message Queue     0
Current Total Message Bytes in Dead Message Queue    0

Log Dead Messages                                    true
Truncate Message Body in Dead Message Queue          false
                                                   
Max Number of Messages in System                     unlimited (-1)
Max Total Message Bytes in System                    unlimited (-1)
Max Message Size                                     70m
                                                   
Auto Create Queues                                   true
Auto Create Topics                                   true
Auto Created Queue Max Number of Active Consumers    1
Auto Created Queue Max Number of Backup Consumers    0
                                                   
Cluster Broker List (active)                         
Cluster Broker List (configured)                     
Cluster Master Broker                                
Cluster URL                                          
                                                   
Log Level                                            INFO
Log Rollover Interval (seconds)                      604800
Log Rollover Size (bytes)                            unlimited (-1)

ブローカのプロパティーの更新

次のブローカのプロパティーを更新する場合は、update bkr サブコマンドを使用します。

• imq.autocreate.queue

• imq.autocreate.topic

• imq.autocreate.queue.maxNumActiveConsumers

• imq.autocreate.queue.maxNumBackupConsumers

• imq.cluster.url

• imq.destination.DMQ.truncateBody

• imq.destination.logDeadMsgs

• imq.log.level

• imq.log.file.rolloversecs

• imq.log.file.rolloverbytes

• imq.system.max_count

• imq.system.max_size

• imq.message.max_size

• imq.portmapper.port

次に示すのは、update bkr サブコマンドの構文です。

imqcmd update bkr [-b hostName:
portNumb er]-o attribute=value
 [[-o attribute=value1]
…]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカに対して、指定した属性を変更します。たとえば、次のコマンドはキュー送信先の自動作成を無効にします。

imqcmd update bkr -o "imq.autocreate.queue=false" -u admin

プロパティーは、第 14 章「ブローカのプロパティーのリファレンス」で説明しています。

ブローカの停止および再開

ブローカの起動後に、imqcmd のサブコマンドを使用して、ブローカの状態を制御できます。

ブローカの停止

ブローカを停止すると、ブローカの接続サービススレッドが中断されるため、ブローカは接続ポートでの待機を止めます。その結果、ブローカはそれ以上、新しい接続の受け入れ、メッセージの受信、メッセージのディスパッチは行いません。

ただし、ブローカを停止しても admin 接続サービスは中断されないため、ブローカへのメッセージを制限するために必要な管理タスクは実行できます。ブローカを停止しても、cluster 接続サービスは継続されます。ただし、クラスタ内のメッセージ配信は、クラスタ内のブローカによって実行される配信機能によって異なります。そのため、クラスタ内のブローカを停止すると、一部のメッセージトラフィックが遅くなる可能性があります。

次に示すのは、pause bkr サブコマンドの構文です。

imqcmd pause bkr [-b hostName:
portNumber]

このコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカを停止します。

次のコマンドでは、myhost のポート 1588 で実行しているブローカが停止されます。

imqcmd pause bkr -b myhost:1588 -u admin

個々の接続サービス、および個々の物理的送信先も停止できます。詳細は、「接続サービスの停止および再開」 と、「物理的送信先の停止と再開」を参照してください。

ブローカの再開

ブローカを再開すると、ブローカのサービススレッドが再び有効になり、ブローカはポートでの待機を再開します。

次に示すのは、resume bkr サブコマンドの構文です。

imqcmd resume bkr [-b hostName:
portNumber]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカを再開します。

次のコマンドでは、localhost のポート 7676 で実行していたブローカが再開されます。

imqcmd resume bkr -u admin

ブローカのシャットダウンと再起動

ブローカをシャットダウンすると、正常にブローカプロセスを終了することができます。ブローカは新しい接続やメッセージを受け入れるのを止めて、既存のメッセージの配信を完了し、ブローカプロセスを終了します。

次に示すのは、shutdown bkr サブコマンドの構文です。

imqcmd shutdown bkr [-b hostName:
portNumber]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカをシャットダウンします。

次のコマンドでは、ctrlsrv のポート 1572 で実行していたブローカがシャットダウンされます。

imqcmd shutdown bkr -b ctrlsrv:1572 -u admin

restart bkr サブコマンドを使用して、ブローカをシャットダウンし、再起動します。次に示すのは、restart bkr サブコマンドの構文です。

imqcmd restart bkr [-b hostName:
portNumber]

このサブコマンドは、最初にブローカを起動したときに指定されたオプションを使用して、デフォルトのブローカ、または指定されたホストとポートのブローカをシャットダウンし、再起動します。別のオプションを選択する場合は、必要なオプションを指定して、ブローカをシャットダウンしてから再起動します。

ブローカのメトリックスの表示

ブローカに関するメトリックス情報を表示するには、metrics bkr サブコマンドを使用します。

次に示すのは、metrics bkr サブコマンドの構文です。

imqcmd metrics bkr [-b hostName:
portNumber]
       [-m metricType] [-int interval] [-msp 
numSamples]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカに対して、ブローカのメトリックスを表示します。

表示するメトリックスのタイプを次の中から指定するには、-m オプションを使用します。

• ttl ブローカとの間で入出力されているメッセージとパケットのフローに関するメトリックスを表示します (デフォルトのメトリックスタイプ)。

• rts ブローカとの間で入出力されているメッセージとパケットの 1 秒あたりのフローレートに関するメトリックスを表示します。

• cxn 接続、仮想メモリーヒープ、およびスレッドを表示します。

メトリックスを表示する間隔を秒単位で指定するには、-int オプションを使用します。デフォルトは 5 秒です。

出力で表示するサンプル数を指定するには、-msp オプションを使用します。デフォルトは無制限です (無限)。

たとえば、ブローカに入力するメッセージフローとブローカから出力されるメッセージのフローレートを10 秒間隔で取得するには、次のコマンドを使用します。

imqcmd metrics bkr -m rts -int 10 -u admin

このコマンドでは、次のような情報が出力されます。

--------------------------------------------------------
 Msgs/sec   Msg Bytes/sec   Pkts/sec    Pkt Bytes/sec   
 In   Out     In      Out     In   Out     In      Out  
--------------------------------------------------------
 0     0      27      56      0     0      38      66   
 10    0     7365     56      10    10    7457    1132  
 0     0      27      56      0     0      38      73   
 0     10     27     7402     10    20    1400    8459  
 0     0      27      56      0     0      38      73

ブローカによって収集され、レポートされるデータの詳細については、「ブローカ全体のメトリックス」を参照してください。

接続サービスの管理

imqcmd ユーティリティーには、次の接続サービス管理タスクを実行するために使用できるサブコマンドが含まれています。

• 「接続サービスの一覧表示」

• 「接続サービス情報の表示」

• 「接続サービスのプロパティーの更新」

• 「接続サービスのメトリックスの表示」

• 「接続サービスの停止および再開」

ブローカは、アプリケーションクライアントと管理クライアントの両方からの通信をサポートしています。Message Queue のブローカで現在使用できる接続サービスを、表 5–1 に示します。表が示すように、各サービスは使用するサービスタイプ (アプリ ケーションクライアントの場合は NORMAL 、管理クライアントの場合は ADMIN) と基礎となるトランスポートプロトコルに関連付けられます。

imqcmd サブコマンドを使用して、接続サービス全体を管理するか、または特定の接続サービスを管理することができます。サブコマンドの対象が特定のサービスの場合は、-n オプションを使用して、表 5–1の「サービス名」列に示されたいずれかの名前を指定します。

接続サービスの一覧表示

ブローカで使用できる接続サービスを一覧表示するには、list svc サブコマンドを使用します。

次に示すのは、list svc サブコマンドの構文です。

imqcmd list svc [-b hostName:
portNumber]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカの接続サービスをすべて一覧表示します。

次のコマンドでは、localhost のポート 7676 で実行しているブローカのすべてのサービスが一覧表示されます。

imqcmd list svc -u admin

このコマンドでは、次のような情報が出力されます。

------------------------------------------------
Service Name    Port Number        Service State
------------------------------------------------
admin           41844 (dynamic)    RUNNING
httpjms         -                  UNKNOWN
httpsjms        -                  UNKNOWN
jms             41843 (dynamic)    RUNNING
ssladmin        dynamic            UNKNOWN
ssljms          dynamic            UNKNOWN

接続サービス情報の表示

シングルサービスに関する情報のクエリーと表示を行うには、query サブコマンドを使用します。

次に示すのは、query svc サブコマンドの構文です。

imqcmd query svc -n serviceName [-b 
hostName:portNumber]

query svc サブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカで実行している特定のサービスに関する情報を一覧表示します。

たとえば、次のように指定します。

imqcmd query svc -n jms -u admin

パスワードの入力を要求した後、コマンドは次のような出力を生成します。

Service Name                           jms
Service State                          RUNNING
Port Number                            60920 (dynamic)
                                     
Current Number of Allocated Threads    0
Current Number of Connections          0
                                     
Min Number of Threads                  10
Max Number of Threads                  1000

接続サービスのプロパティーの更新

表 5–2 に示す 1 つ以上のサービスのプロパティーの値を変更するには、update サブコマンドを使用します。

次に示すのは、update サブコマンドの構文です。

imqcmd update svc -n serviceName [-b 
hostName:portNumber] 
         -o attribute=value [-o 
attribute=value1]…

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカで実行している特定のサービスの特定の属性を更新します。サービスの属性については、「接続のプロパティー」を参照してください。

次のコマンドでは、jms サービスに割り当てられたスレッドの最小数が 20 に変更されます。

imqcmd update svc -n jms -o “minThreads=20” -u admin

接続サービスのメトリックスの表示

シングルサービスに関するメトリックス情報を表示するには、metrics サブコマンドを使用します。

次に示すのは、metrics サブコマンドの構文です。

imqcmd metrics svc -n serviceName [-b 
hostName:portNumber] [-m metricType
]
     [-int interval] [-msp numSamples]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカで実行している特定のサービスのメトリックスを表示します。

表示するメトリックスのタイプを次の中から指定するには、-m オプションを使用します。

• ttl 指定した接続サービスを使ってブローカとの間で入出力されているメッセージとパケットのフローに関するメトリックスを表示します (デフォルトのメトリックスタイプ)。

• rts 指定した接続サービスを使ってブローカとの間で入出力されているメッセージとパケットのフローレート (1 秒あたり) に関するメトリックスを表示します。

• cxn 接続、仮想メモリーヒープ、およびスレッドを表示します。

メトリックスを表示する間隔を秒単位で指定するには、-int オプションを使用します。デフォルトは 5 秒です。

出力で表示するサンプル数を指定するには、-msp オプションを使用します。デフォルトは無制限です (無限)。

たとえば、jms 接続サービスによって処理されたメッセージとパケットの累計数を取得するには、次のコマンドを使用します。

imqcmd metrics svc -n jms -m ttl -u admin

パスワードの入力を要求した後、コマンドは次のような出力を生成します。

-------------------------------------------------
  Msgs      Msg Bytes      Pkts      Pkt Bytes   
In   Out    In     Out   In   Out    In     Out  
-------------------------------------------------
164  100  120704  73600  282  383  135967  102127
657  100  483552  73600  775  876  498815  149948

imqcmd を使用して接続サービスのメトリックスをレポートする方法の詳細は、「接続サービスのメトリックス」を参照してください。

接続サービスの停止および再開

管理サービス (停止することが禁止されているサービス) 以外のサービスを停止するには、pause svc サブコマンドと resume svc サブコマンドを使用します。

次に示すのは、pause svc サブコマンドの構文です。

imqcmd pause svc -n serviceName [-b 
hostName:portNumber]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカで実行している特定のサービスを停止します。たとえば、次のコマンドは、デフォルトのブローカで実行している httpjms サービスを停止します。

imqcmd pause svc -n httpjms -u admin

サービスを停止すると、次のような結果になります。

• ブローカは、停止したサービスでの新たなクライアント接続の受け入れを止めます。Message Queue クライアントが新しい接続を開こうとすると、例外が発生します。

• 停止したサービスの既存の接続はすべて維持されますが、ブローカはサービスが再開されるまでこれらの接続のすべてのメッセージ処理を中断します。たとえば、クライアントがメッセージを送信しようとしても、サービスが再開されるまでは、send メソッドがそれを阻止します。

• すでにブローカが受信済みのメッセージのメッセージ配信状態は維持されます。たとえば、トランザクションは中断されず、サービスが再開された時点でメッセージ配信も再開されます。

サービスを再開するには、resume svc サブコマンドを使用します。

次に示すのは、resume svc サブコマンドの構文です。

imqcmd resume svc -n serviceName[-b 
hostName:portNumber]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカで実行している特定のサービスを再開します。

接続情報の入手

imqcmd ユーティリティーには、接続に関する情報を一覧表示し取得するために使用できるサブコマンドが含まれています。

list cxn サブコマンドは、指定されたサービス名のすべての接続を一覧表示します。次に示すのは、list cxn サブコマンドの構文です。

imqcmd list cxn [-svn serviceName] [-b 
hostName:portNumber]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカの指定したサービス名の接続をすべて一覧表示します。サービス名を指定しない場合は、すべての接続が一覧表示されます。

たとえば、次のコマンドはデフォルトのブローカのすべての接続を表示します。

imqcmd list cxn -u admin

パスワードの入力を要求した後、コマンドは次のような出力を生成します。

Listing all the connections on the broker specified by:
-----------------------------------
Host                   Primary Port
------------------------------------
localhost              7676

---------------------------------------------------------------------------
Connection ID         User    Service   Producers  Consumers    Host
---------------------------------------------------------------------------
1964412264455443200   guest   jms       0          1            127.0.0.1
1964412264493829311   admin   admin     1          1            127.0.0.1

Successfully listed connections.

シングル接続サービスに関する情報のクエリーと表示を行うには、query サブコマンドを使用します。

query cxn -n connectionID [-b 
hostName:portNumber]

このサブコマンドは、デフォルトのブローカ、または指定したホストとポートのブローカの指定した接続に関する情報を表示します。

たとえば、次のように指定します。

imqcmd query cxn -n 421085509902214374 -u admin

パスワードの入力を要求した後、コマンドは次のような出力を生成します。

Connection ID      421085509902214374
User               guest
Service            jms
Producers          0
Consumers          1
Host               111.22.333.444
Port               60953
Client ID          
Client Platform    

永続サブスクリプションの管理

imqcmd サブコマンドを使用して、次のような操作を実行して、ブローカの永続サブスクリプションを管理できます。

• 永続サブスクリプションを一覧表示する

• 永続サブスクリプションのすべてのメッセージを消去する

• 永続サブスクリプションを破棄する

永続サブスクリプションとは、クライアントによって、永続的であると登録されたトピックのサブスクリプションのことです。このサブスクリプションには固有の識別情報があり、コンシューマがアクティブになっていないときでも、サブスクリプションのメッセージを保持するブローカが必要となります。通常、ブローカはメッセージの有効期限が切れたときだけ、保持していた永続サブスクライバのメッセージを削除します。

指定された物理的送信先の永続サブスクリプションを一覧表示するには、list dur サブコマンドを使用します。次に示すのは、list dur サブコマンドの構文です。

imqcmd list dur -d destName

たとえば、次のコマンドはローカルホストのデフォルトポートのブローカを使用する、トピック SPQuotes のすべての永続サブスクリプションを一覧表示します。

imqcmd list dur -d SPQuotes

list dur サブコマンドでは、トピックの永続サブスクリプションごとに、永続サブスクリプションの名前、ユーザーのクライアント ID、このトピックのキューに入っているメッセージの数、および永続サブスクリプションの状態 (アクティブまたは非アクティブ) を返します。たとえば、次のように指定します。

Name        Client ID       Number of   Durable Sub
                            Messages      State
----------------------------------------------------------------
myDurable   myClientID       1           INACTIVE

list dur サブコマンドから返される情報を使用して、破棄する必要がある永続サブスクリプションやメッセージを消去する必要がある永続サブスクリプションを識別することができます。

purge dur サブコマンドは、指定されたクライアント識別子を持つ特定の永続サブスクリプションのすべてのメッセージを消去します。次に示すのは、purge dur サブコマンドの構文です。

imqcmd purge dur -n subscrName -c 
clientID

destroy dur サブコマンドは、指定されたクライアント識別子を持つ特定の永続サブスクリプションを破棄します。次に示すのは、destroy dur サブコマンドの構文です。

imqcmd destroy dur -n subscrName -c 
clientID

たとえば、次のコマンドは、永続サブスクリプション myDurable と clientID myClientID を破棄します。

imqcmd destroy dur -n myDurable -c myClientID

トランザクションの管理

クライアントアプリケーションによって開始されたトランザクションはすべてブローカによって記録されます。これらは、分散トランザクション (XA リソース) マネージャーによって管理される Message Queue の単純なトランザクション、または分散トランザクションです。

各トランザクションには、Message Queue トランザクション ID が付けられています。これは、ブローカのトランザクションを一意に識別するための 64 ビットの数字です。また、分散トランザクションには、分散トランザクションマネージャーによって割り当てられる最大 128 バイトの分散トランザクション ID (XID) が付けられます。Message Queue は、Message Queue トランザクション ID と XID の関連付けを保持します。

分散トランザクションの場合、障害が発生すると、トランザクションがコミットされずに PREPARED 状態のままになる可能性があります。このため、管理者は監視を行い、PREPARED 状態のトランザクションをロールバックするか、またはコミットする必要があります。

ブローカが追跡するすべてのトランザクションを一覧表示するには、list txn コマンドを使用します。次に示すのは、list tx サブコマンドの構文です。

imqcmd list txn

たとえば、次のコマンドでは、ブローカのすべてのトランザクションが一覧表示されます。

imqcmd list txn

トランザクションごとに、list サブコマンドは、トランザクション ID、状態、ユーザー名、メッセージまたは通知の数、および作成時間を返します。たとえば、次のように指定します。

---------------------------------------------------------------
Transaction ID  State    User name   # Msgs/   Creation time
                                     # Acks
---------------------------------------------------------------

64248349708800  PREPARED  guest      4/0      1/30/02 10:08:31 AM
64248371287808  PREPARED  guest      0/4      1/30/02 10:09:55 AM

このコマンドを使用すると、ブローカ内のローカルと分散の両方のトランザクションがすべて表示されます。PREPARED 状態のトランザクションだけをコミット、またはロールバックすることができます。これを実行するのは、障害の発生でトランザクションが PREPARED 状態になり、分散トランザクションマネージャーによってコミットされるプロセスになっていないことがわかっている場合だけです。

たとえば、ブローカの自動ロールバックプロパティーを false に設定した場合 (表 14–2 を参照)、ブローカの起動時に、PREPARED 状態のトランザクションを手動でコミット、またはロールバックする必要があります。

list サブコマンドは、トランザクションで生成されたメッセージの数とトランザクションで通知されたメッセージの数 (#Msgs/#Acks) も表示します。トランザクションがコミットされるまで、これらのメッセージは配信されず、通知は処理されません。

query サブコマンドを使用すると、同じ情報のほかに、多数の追加された値を確認できます。たとえばクライアント ID、接続識別子、分散トランザクション ID (XID) などです。次に示すのは、query txn サブコマンドの構文です。

imqcmd query txn -n transactionID

たとえば、次の例では以下のような出力が生成されます。

imqcmd query txn -n 64248349708800

Client ID
Connection                 guest@192.18.116.219:62209->jms:62195
Creation time              1/30/02 10:08:31 AM
Number of acknowledgments 0
Number of messages         4
State                      PREPARED
Transaction ID             64248349708800
User name                  guest
XID
6469706F6C7369646577696E6465723130313234313431313030373230

分散トランザクションをコミット、またはロールバックするには、commit サブコマンドと rollback サブコマンドを使用します。前述したように、PREPARED 状態のトランザクションだけをコミット、またはロールバックできます。

次に示すのは、commit サブコマンドの構文です。

imqcmd commit txn -n transactionID

たとえば、次のように指定します。

imqcmd commit txn -n 64248349708800

次に示すのは、rollback サブコマンドの構文です。

imqcmd rollback txn -n transactionID

詳細は、表 14–2 の imq.transaction.autorollback プロパティーを参照してください。

ブローカの起動時に、PREPARED 状態のトランザクションが自動的にロールバックされるように、ブローカを設定することも可能です。

第 6 章 物理的送信先の管理

この章では、imqcmd ユーティリティーを使用して、物理的送信先を管理する方法を説明します。Message Queue^TM メッセージは、ブローカ上の物理的送信先によりコンシューマクライアントにルーティングされます。ブローカは物理的送信先に関連したメモリーと持続ストレージを管理し、その動作を設定します。

クラスタで、1 つのブローカ上に物理的送信先を作成すると、クラスタはその物理的送信先をほかのすべてのブローカに伝えます。アプリケーションクライアントは、トピックにサブスクライブするか、クラスタ内の任意のブローカにあるキューから消費できます。こればブローカが共同作業でクラスタ間のメッセージをルーティングするためです。ただし、最初にメッセージが生成されたブローカだけは、そのメッセージの持続性と通知を管理します。

この章では、次のトピックについて説明します。

• 「コマンドユーティリティーの使用」

• 「物理的送信先の作成」

• 「物理的送信先の一覧表示」

• 「物理的送信先の情報の表示」

• 「物理的送信先のプロパティーの更新」

• 「物理的送信先の停止と再開」

• 「物理的送信先の消去」

• 「物理的送信先の破棄」

• 「物理的送信先の圧縮」

• 「デッドメッセージキューの使用の設定」

表 13–5 に、物理的送信先を管理し、そのタスクを実行するための imqcmd サブコマンドに関する詳細を示します。

物理的送信先の概要については、『Message Queue 技術の概要』を参照してください。

クライアントアプリケーションは、物理的送信先と対話する場合は常に Destination オブジェクトを使用します。プロバイダへの非依存性と移植性のために、クライアントは通常は管理者が作成した送信先オブジェクトを使用し、これは送信先管理対象オブジェクトと呼ばれます。第 8 章「管理対象オブジェクトの管理」で説明するように、管理対象オブジェクトはクライアントアプリケーションで使用できるように設定できます。

コマンドユーティリティーの使用

Message Queue コマンドユーティリティー (imqcmd) を使用して、物理的送信先を管理します。imqcmd コマンドの構文は、ほかのブローカサービスの管理に使用する場合と同じです。

imqcmd とそのサブコマンド、オプションについての詳細は、第 13 章「コマンド行のリファレンス」で説明しています。

サブコマンド

表 6–1 には imqcmd サブコマンドが掲載されています。この章では、その使用法について説明します。これらのサブコマンドの詳細は、「物理的送信先管理」を参照してください。

物理的送信先の作成

物理的送信先を作成するには、imqcmd create サブコマンドを使用します。次に示すのは、create サブコマンドの構文です。

create dst -t destType -n 
destName [-o property=value
] [-o property=value1]
…

たとえば、キューの送信先を作成するには、次のようなコマンドを入力します。

imqcmd create dst -n myQueue -t q -o “maxNumActiveConsumers=5”

トピックの送信先を作成するには、次のようなコマンドを入力します。

imqcmd create dst -n myTopic -t t -o “maxBytesPerMsg=5000”

物理的送信先を作成するときには、次の情報を指定する必要があります。

• 物理的送信先のタイプ。t (トピック)、または q (キュー) のいずれか。

• 物理的送信先名。次のような命名規則があります。

  • 名前には英数字のみを使用する。スペースは使用できない。

  • 名前は英字、下線文字 (_)、ドル記号 ($) のいずれかで始める。文字列「mq」で開始することはできない。

  物理的送信先のプロパティーには、デフォルト以外の値を指定する。

また、物理的送信先を更新する場合、プロパティーも設定できます。

物理的送信先の多くのプロパティーが、ブローカのメモリーリソースおよびメッセージフローに影響します。たとえば、物理的送信先に送信できるプロデューサの数、送信可能なメッセージの数とサイズ、および物理的送信先の制限に達したときにブローカが行う応答を指定できます。この制限は、ブローカの設定プロパティーによって制御されるブローカ全体の制限に似ています。

次のプロパティーは、キューの送信先とトピックの送信先のいずれにも使用します。

• maxNumMsgs。物理的送信先で許容されるコンシューマ配信されないメッセージの最大数を指定します。

• maxTotalMsgBytes。物理的送信先でコンシューマ配信されないメッセージ用として許容されるメモリーの最大量をバイト単位で指定します。

• limitBehavior。メモリー制限のしきい値に達したときのブローカの応答方法を指定します。

• maxBytesPerMsg。物理的送信先で許容されるシングルメッセージの最大サイズをバイト単位で指定します。

• maxNumProducers。物理的送信先のプロデューサの最大数を指定します。

• consumerFlowLimit。1 つのバッチでコンシューマに配信されるメッセージの最大数を指定します。

• isLocalOnly。ブローカクラスタに対してのみ適用します。物理的送信先がそのほかのブローカに複製されないように指定します。つまり、メッセージの配信をローカルコンシューマ (物理的送信先の作成元にあるブローカに接続されたコンシューマ) だけに制限します。

• useDMQ。物理的送信先のデッドメッセージを破棄するか、デッドメッセージのキューに配置するかを指定します。

次のプロパティーは、キューの送信先にのみ使用します。

• maxNumActiveConsumers。ロードバランスされたキュー送信先からの配信でアクティブにできるコンシューマの最大数を指定します。

• maxNumBackupConsumers。キュー送信先からのロードバランスされた配信で障害が生じた場合に、アクティブコンシューマに代わることができるバックアップコンシューマの最大数を指定します。

• localDeliveryPreferred。ブローカクラスタ内のロードバランスされたキュー配信にのみ適用します。ローカルブローカ上にコンシューマが存在しない場合にだけ、メッセージがリモートコンシューマに配信されるように指定します。

物理的送信先のプロパティーについての詳細は、第 15 章「物理的送信先のプロパティーのリファレンス」を参照してください。

自動作成される送信先の場合は、ブローカのインスタンス設定ファイルにデフォルトのプロパティー値を設定します。自動作成されるプロパティーの詳細を、表 14–3 に示しています。

物理的送信先の一覧表示

物理的送信先の現在のプロパティー値、物理的送信先に関連付けられているプロデューサまたはコンシューマの数、物理的送信先内のメッセージの数とサイズなどのメッセージングメトリックスに関する情報を取得できます。

情報を入手する物理的送信先を探す場合は、list dst サブコマンドを使用して、ブローカのすべての物理的送信先を一覧表示します。次に示すのは、list dst サブコマンドの構文です。

list dst [-t destType] [-tmp]

このコマンドは、指定されたタイプの物理的送信先を一覧表示します。送信先のタイプ (-t) オプションの値は、q (キュー) または t (トピック) のいずれかになります。

送信先のタイプを指定しない場合は、すべてのタイプの物理的送信先が一覧表示されます。

list dst サブコマンドを使用すると、任意で、一覧表示する送信先のタイプを指定したり、一時的送信先を含めたりすることができます (-tmp オプションを使用)。一時的送信先はクライアントによって作成され、通常は、そのほかのクライアントへ送信されたメッセージへの返信を受信することを目的としています。

たとえば、myHost のポート 4545 上で実行しているブローカ上の物理的送信先すべてのリストを取得するには次のコマンドを入力します。

imqcmd list dst -b myHost:4545

送信先のタイプ t でトピックのみを指定している場合を除き、デッドメッセージキューの情報 mq.sys.dmq がほかの物理的送信先と一緒に常に表示されます。

物理的送信先の情報の表示

物理的送信先の現在のプロパティーに関する情報を入手するには、query dst サブコマンドを使用します。次に示すのは、query dst サブコマンドの構文です。

query dst -t destType -n 
destName

このコマンドは、特定のタイプと名前の送信先に関する情報を一覧表示します。たとえば、次のコマンドはキューの送信先 XQueue に関する情報を表示します。

imqcmd query dst -t q -n XQueue -u admin

このコマンドでは、次のような情報が出力されます。

------------------------------------
Destination Name    Destination Type
------------------------------------
XQueue              Queue

On the broker specified by:

-------------------------
Host         Primary Port
-------------------------
localhost    7676

Destination Name                      XQueue
Destination Type                      Queue
Destination State                     RUNNING
Created Administratively              true

Current Number of Messages            0
Current Total Message Bytes           0
Current Number of Producers           0
Current Number of Active Consumers    0
Current Number of Backup Consumers    0

Max Number of Messages                unlimited (-1)
Max Total Message Bytes               unlimited (-1)
Max Bytes per Message                 unlimited (-1)
Max Number of Producers               100
Max Number of Active Consumers        1
Max Number of Backup Consumers        0

Limit Behavior                        REJECT_NEWEST
Consumer Flow Limit                   1000
Is Local Destination                  false
Local Delivery is Preferred           false
Use Dead Message Queue                true

また、出力は送信先に関連付けられたプロデューサとコンシューマの数を示しています。キューの送信先について、数字にはアクティブなコンシューマとバックアップコンシューマが含まれます。

update dst サブコマンドを使用すると、1 つ以上のプロパティーの値を変更できます (「物理的送信先のプロパティーの更新」を参照)。

物理的送信先のプロパティーの更新

物理的送信先のプロパティーを変更するには、update dst サブコマンドと -o オプションを使用して、更新するプロパティーを指定します。次に示すのは、update dst サブコマンドの構文です。

update dst -t destType -n 
destName -o property=value [[-o 
property=value1]…]

このコマンドは、指定した送信先の特定のプロパティー値を更新します。プロパティー名は、表 15–1 で説明しているいずれかのプロパティーになります。

複数の -o オプションを使用すると、複数のプロパティーを何度も更新できます。たとえば、次のコマンドでは maxBytesPerMsg プロパティーが 1000 に、MaxNumMsgs プロパティーが 2000 にそれぞれ変更されます。

imqcmd update dst -t q -n myQueue -o “maxBytesPerMsg=1000”
              -o “maxNumMsgs=2000” -u admin

更新が可能なプロパティーについては、第 15 章「物理的送信先のプロパティーのリファレンス」を参照してください。

物理的送信先の type や isLocalOnly プロパティーを更新する場合、update dst サブコマンドは使用できません。

デッドメッセージキューは、特殊な物理的送信先であり、プロパティーがその他の送信先のプロパティーと多少異なります。詳細は、「デッドメッセージキューの使用の設定」を参照してください。

物理的送信先の停止と再開

プロデューサから送信先、送信先からコンシューマ、またはその両方のメッセージの配信を制御するために、物理的送信先を停止できます。特に、メッセージの生成が消費よりかなり高速な場合に、送信先がメッセージによって過負荷にならないように、送信先へのメッセージフローを停止できます。圧縮する前に物理的送信先を停止する必要があります。

物理的送信先との間で配信されるメッセージを停止するには、pause dst サブコマンドを使用します。次に示すのは、 pause dst サブコマンドの構文です。

pause dst [-t destType -n 
destName] [-pst pauseType]

このサブコマンドは、特定のタイプと名前の送信先について、コンシューマへのメッセージ (-pst CONSUMERS)、プロデューサからのメッセージ (-pst PRODUCERS)、またはその両方 (-pst ALL) を停止します。送信先のタイプと名前が指定されない場合、すべての物理的送信先が停止します。デフォルト値は ALL です。

例:

imqcmd pause dst -n myQueue -t q -pst PRODUCERS -u admin
imqcmd pause dst -n myTopic -t t -pst CONSUMERS -u admin

停止した送信先への配信を再開するには、resume dst サブコマンドを使用します。次に示すのは、resume dst サブコマンドの構文です。

resume dst [-t destType -n 
destName]

このサブコマンドは、特定のタイプと名前の停止された送信先についてメッセージの配信を再開します。送信先のタイプと名前が指定されていない場合は、すべての送信先が再開されます。

例:

imqcmd resume dst -n myQueue -t q

ブローカクラスタでは、物理的送信先のインスタンスはクラスタ内の各ブローカに常駐します。各インスタンスを個別に停止する必要があります。

物理的送信先の消去

物理的送信先のキューに現在入っているメッセージは、すべて消去することが可能です。物理的送信先を消去すると、送信先に保存されているすべてのメッセージが削除されます。

累積されたメッセージによって、システムのリソースが大幅に消費される場合に、これらのメッセージを消去することができます。これは、登録済みのコンシューマクライアントがキューに入っていない場合やキューが多数のメッセージを受信する場合に発生する可能性があります。また、トピックの永続サブスクライバが、アクティブにならない場合にも発生する可能性があります。どちらの場合も、メッセージが必要以上に保持されます。

物理的送信先でメッセージを消去するには、purge dst サブコマンドを使用します。次に示すのは、purge dst サブコマンドの構文です。

purge dst -t destType -n 
destName

このサブコマンドは、指定されたタイプと名前の物理的送信先のメッセージを消去します。

例:

imqcmd purge dst -n myQueue -t q -u admin
imqcmd purge dst -n myTopic -t t -u admin

ブローカをシャットダウンしたあと、再起動するときに、古いメッセージを配信する必要がない場合は、-reset messages オプションを使用して、古いメッセージを消去します。たとえば、次のとおりです。

imqbrokerd -reset messages -u admin

これで、ブローカを再起動すると、送信先の消去に関する問題が解消されます。

ブローカクラスタでは、物理的送信先のインスタンスはクラスタ内の各ブローカに常駐します。これらの送信先はそれぞれ個別に消去する必要があります。

物理的送信先の破棄

物理的送信先を破棄するには、destroy dst サブコマンドを使用します。次に示すのは、destroy dst サブコマンドの構文です。

destroy dst -t destType -n 
destName

このサブコマンドは、指定されたタイプと名前の物理的送信先のメッセージを破棄します。

例:

imqcmd destroy dst -t q -n myQueue -u admin

物理的送信先を破棄すると、その送信先のすべてのメッセージが消去され、ブローカからその送信先がなくなるため、操作を元に戻すことはできません。

デッドメッセージキューを破棄することはできません。

物理的送信先の圧縮

メッセージの持続ストアとして、ファイルベースのデータストアを使用している場合は、ディスク利用率を監視し、必要に応じてディスクを圧縮できます。

ファイルベースのメッセージストアは、保持される物理的送信先に応じてメッセージがディレクトリに格納されるように構成されています。各物理的送信先のディレクトリでは、大半のメッセージが可変長のレコードから成る 1 つのファイル、つまり可変長のレコードファイルに格納されます。断片化を減らすため、サイズが設定可能なしきい値を超えているメッセージは専用の個別のファイルに格納されます。

可変サイズのメッセージが保持されていて、その後レコードファイルから削除された場合、空きレコードが再利用されていないファイルに空白ができることがあります。

未使用の空きレコードを管理するために、コマンドユーティリティーには、物理的送信先ごとにディスク利用率を監視したり、利用率の低下時に空きディスク容量を再利用したりするためのサブコマンドが含まれています。

物理的送信先のディスク利用率の監視

物理的送信先のディスク利用率を監視するには、次のようなコマンドを使用します。

imqcmd metrics dst -t q -n myQueue -m dsk -u admin

このコマンドでは、次のような情報が出力されます。

--------------------------------------
Reserved   Used      Utilization Ratio
--------------------------------------
806400     804096    99
1793024    1793024   100
2544640    2518272   98

サブコマンド出力の各列の意味は次のとおりです。

未使用の物理的送信先ディスク容量の再利用

ディスク利用率のパターンは、特定の物理的送信先を使用しているメッセージングアプリケーションの特性によって異なります。また、物理的送信先との間でやり取りされる相対的なメッセージフローとメッセージの相対的なサイズに応じて、時間の経過とともに予約済みディスク容量が拡大することがあります。

メッセージの生成レートがメッセージの消費レートを上回る場合は、一般に、空きレコードが再利用され利用率が高くなります。ただし、メッセージの生成レートがメッセージの消費レートと同程度かそれより低い場合は、利用率は低いと予測できます。

一般に、予約済みディスク容量は安定化させ、利用率は高いまま維持させる必要があります。一般的に、システムが安定して、予約済みディスク容量がほぼ一定になり利用率が高い (75% を超える) 状態に達した場合には、未使用のディスク容量を再利用する必要はありません。システムが安定した状態になったが利用率が低い (50% を下回る) 場合は、ディスクを圧縮し、空きレコードが占有しているディスク容量を再利用できます。

データストアを圧縮する場合は、compact dst サブコマンドを使用します。次に示すのは、compact dst サブコマンドの構文です。

compact dst [-t destType -n 
destName]

このサブコマンドは、特定のタイプと名前の物理的送信先に対応するファイルベースのデータストアを圧縮します。送信先のタイプと名前が指定されていない場合は、すべての送信先が圧縮されます。圧縮する前に、物理的送信先を停止する必要があります。

予約済みのディスク容量が時間の経過とともに増え続けている場合は、送信先メモリーの制限プロパティーと制限動作を設定して送信先のメモリー管理を設定し直す必要があります (表 15–1 を参照)。

未使用の物理的送信先ディスク容量を再利用する

1. 送信先を停止します。

   imqcmd pause dst -t q -n myQueue -u admin

2. ディスクを圧縮します。

   imqcmd compact dst -t q -n myQueue -u admin

3. 物理的送信先を再開します。

   imqcmd resume dst -t q -n myQueue -u admin

   送信先のタイプと名前が指定されなかった場合、これらの操作はすべての物理的送信先に対して実行されます。

デッドメッセージキューの使用の設定

デッドメッセージキュー mq.sys.dmq は、ブローカとブローカのその他の物理的送信先のデッドメッセージを保持する、システムで生成された物理的送信先です。デッドメッセージキューは、監視、システムの効率性の調整、トラブルシューティングに使用するツールです。「デッドメッセージ」の定義と、デッドメッセージキューの概要については、『 Message Queue 技術の概要』を参照してください。

ブローカは起動時に自動的にデッドメッセージキューを作成します。ブローカは処理できないメッセージ、または生存期間を過ぎたメッセージを、キューに配置します。さらに、その他の物理的送信先が廃棄したメッセージの保持にデッドメッセージキューを使用することもあります。デッドメッセージキューを使用することで、システムのトラブルシューティングに役立つ情報を得ることができます。

デッドメッセージキューの使用の設定

デフォルトでは、物理的送信先は、デッドメッセージキューを有効に設定しています。物理的送信先がデッドメッセージキューを使用しないように設定できます。あるいは物理的送信先プロパティー useDMQ を設定して有効にすることもできます。

次の例では、デフォルトでデッドメッセージキューを使用する、myDist と呼ばれるキューが作成されます。

imqcmd create dst -n myDist -t q

次の例では、同じキューに対してデッドメッセージキューの使用が無効になります。

imqcmd update dst -n myDist -t q -o useDMQ=false

ブローカ上の自動作成されたすべての物理的送信先で、デッドメッセージキューの使用を有効にしたり、imq.autocreate.destination.useDMQ ブローカプロパティーを設定して、デッドメッセージキューの使用を無効にしたりできます。

デッドメッセージキューの管理

Message Queue コマンドユーティリティー (imqcmd) を使用して、デッドメッセージキューをほかのキューと同じように管理できますが、いくつかの相違点があります。たとえば、デッドメッセージキューはシステムで生成されるため、作成、停止、破棄の操作は行えません。さらに、表 6–3 に示すように、デッドメッセージキューのデフォルト値は通常のキューと異なる場合があります。

デッドメッセージキューのプロパティー

デッドメッセージキューは、ほかのキューの設定と同様に設定しますが、特定の物理的送信先のプロパティーは適用されません。あるいは別のデフォルト値が指定されます。表 6–3 にデッドメッセージキューが独自の方法で処理するキュープロパティーを一覧表示しています。

メッセージの内容

ブローカはメッセージ全体をデッドメッセージキューに配置できます。あるいはヘッダーとプロパティーデータのみを残して、メッセージ本体の内容を破棄できます。デフォルトでは、デッドメッセージキューはメッセージ全体を格納します。

デッドメッセージキューのサイズを減らし、デッドメッセージを復元する予定がない場合は、imq.destination.DMQ.truncateBody ブローカプロパティーを true に設定することを検討してください。

imqcmd update bkr -o imq.destination.DMQ.truncateBody=true

これにより、メッセージ本文が破棄され、ヘッダーとプロパティーデータのみが残されます。

デッドメッセージのロギングの有効化

デッドメッセージのロギングは、デフォルトでは無効になっています。デッドメッセージのロギングを有効にすると、ブローカが次のイベントを記録するようになります。

• ブローカがデッドメッセージキューにメッセージを移動する

• ブローカがデッドメッセージキューとデッドメッセージキューを使用していない物理的送信先からメッセージを破棄する

• 物理的送信先が制限に達する

次のコマンドでは、デッドメッセージのロギングを有効にしています。

imqcmd update bkr -o imq.destination.logDeadMsgs=true

デッドメッセージのロギングは、デッドメッセージキューを使用するすべての物理的送信先に適用されます。物理的送信先の個々については、ロギングを有効または無効に設定できません。

第 7 章 セキュリティーの管理

ユーザーの認証、アクセス制御の定義、クライアントブローカ間の通信を暗号化する SSL (Secure Socket Layer) 接続サービスの設定、ブローカ起動時に使用するパスワードファイルの設定のためのユーザーリポジトリの設定によって、セキュリティーを管理します。

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

• 「ユーザー認証」

• 「ユーザー承認: アクセス制御プロパティーファイル」

• 「メッセージの暗号化」

• 「パスワードファイル」

• 「監査ロギング」

ユーザー認証

ユーザーがブローカへの接続を試みると、ブローカは提供された名前とパスワードを調べて、ユーザーを認証します。ブローカは、その名前とパスワードが、それぞれ参照するように設定されているブローカ固有のユーザーリポジトリにある名前とパスワードに一致した場合に、接続を許可します。

管理者は、ユーザー、ユーザーグループ、およびパスワードのリストをユーザーリポジトリに保持しておく責任があります。ブローカインスタンスごとに異なるユーザーリポジトリを使用できます。この節では、リポジトリの作成、設定、および管理の方法を説明します。

リポジトリは次のいずれかのタイプになります。

• Message Queue^TM に付属している単層型ファイルリポジトリ

  このタイプのユーザーリポジトリは、非常に簡単に扱えます。ユーザーマネージャーユーティリティー (imqusermgr) を使用してリポジトリを設定および管理します。認証を有効にするには、ユーザーリポジトリにユーザー名、パスワード、およびユーザーグループの名前を設定します。

  ユーザーリポジトリの設定と管理の詳細については、「単層型ファイルユーザーリポジトリの使用」を参照してください。

• LDAP サーバー

  このリポジトリは、LDAP v2 または v3 プロトコルを使用する既存または新規の LDAP ディレクトリサーバーです。単層型ファイルリポジトリほど使用方法は簡単ではありませんが、よりスケーラブルなため、本稼動環境に適しています。

  LDAP ユーザーリポジトリを使用している場合、LDAP ベンダーから提供されているツールを使用して、ユーザーリポジトリを設定、管理します。詳細は、「ユーザーリポジトリでの LDAP サーバーの使用」を参照してください。

単層型ファイルユーザーリポジトリの使用

Message Queue には、単層型ファイルユーザーリポジトリ、コマンド行ツール、および単層型ファイルユーザーリポジトリの設定と管理ができるユーザーマネージャーユーティリティー (imqusermgr) が用意されています。次の節では、単層型ファイルユーザーリポジトリと、そのリポジトリを設定し管理するユーザーマネージャーユーティリティーの使用方法について説明します。

ユーザーリポジトリの作成

単層型ファイルユーザーリポジトリは、インスタンス固有です。起動するブローカインスタンスごとに、passwd という名前のデフォルトのユーザーリポジトリが自動的に作成されます。このユーザーリポジトリは、そのリポジトリが関連付けられているブローカインスタンスの名前によって識別されたディレクトリに置かれます (付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照)。

   …/instances/instanceName/etc/passwd

リポジトリは 2 つのエントリから構成されます。表 7–1 の各行にエントリを示します。

これらの初期エントリにより、管理者が介入しなくても、インストール後直ちに Message Queue ブローカを使用できます。

• 初期設定された guest ユーザーエントリを使って、クライアントはデフォルトの guest ユーザー名とパスワードでブローカインスタンスに接続できます。

• 初期設定された admin ユーザーエントリでは、デフォルトの admin ユーザー名とパスワードで、imqcmd コマンドを使用してブローカを管理できます。この初期エントリを更新して、パスワードを変更する必要があります (「デフォルトの管理者パスワードの変更」を参照)。

次の節では、単層型ユーザーリポジトリの設定、および管理方法について説明します。

ユーザーマネージャーユーティリティー

Message Queue ユーザーマネージャーユーティリティー (imqusermgr) を使って、単層型ファイルユーザーリポジトリを編集したり設定したりできます。この節では、ユーザーマネージャーユーティリティーについて説明します。後続の節では、imqusermgr サブコマンドを使用して、特定のタスクを実行する方法について説明します。

imqusermgr コマンドの詳細は、第 13 章「コマンド行のリファレンス」を参照してください。

ユーザーマネージャーの使用に先立ち、次の点に留意してください。

• ブローカ固有のユーザーリポジトリが存在していない場合は、それを作成するために該当するブローカインスタンスを起動する必要があります。

• imqusermgr コマンドは、ブローカがインストールされているホスト上で実行する必要があります。

• リポジトリへの書き込みに関する適切なアクセス権を持つ必要があります。たとえば、Solaris と Linux の場合、root ユーザーまたはブローカインスタンスを最初に作成したユーザーになる必要があります。

次の節の例は、デフォルトのブローカインスタンスを前提としています。

サブコマンド

imqusermgr コマンドには、add、delete、list、update といったサブコマンドがあります。

• add サブコマンドは、ユーザーとそのパスワードを指定した、またはデフォルトのブローカインスタンスリポジトリに追加し、オプションでユーザーグループを指定します。このサブコマンドの構文は次のようになります。

  add [-i instanceName] -u userName -p passwd [-g group] [ -s]

• delete サブコマンドは、指定したユーザーを、指定した、またはデフォルトのブローカインスタンスリポジトリから削除します。このサブコマンドの構文は次のようになります。

  delete [-i instanceName] -u userName [ -s] [-f]

• list サブコマンドは、指定した、またはデフォルトのブローカインスタンスリポジトリの指定したユーザーまたはすべてのユーザーに関する情報を表示します。このサブコマンドの構文は次のようになります。

  list [ -i instanceName] [-u userName]

• update サブコマンドは、指定した、またはデフォルトのブローカインスタンスリポジトリの指定ユーザーのパスワードまたは状態、もしくは両方を更新します。このサブコマンドの構文は次のようになります。

  update [ -i instanceName] -u userName -p passwd [ -a state] [-s] [ -f]

  update [-i instanceName] -u userName -a state [-p passwd] [-s] [-f]

コマンドオプション

表 7–2 に imqusermgr コマンドのオプションを一覧表示します。

グループ

ブローカインスタンスのユーザーリポジトリにユーザーエントリを追加する場合、事前に定義された 3 つのグループである admin、user、anonymous のいずれかを指定できます。グループが指定されない場合、デフォルトのグループ user が割り当てられます。グループが次のように割り当てられるはずです。

• admin グループ: ブローカの管理者用です。このグループに割り当てられたユーザーは、デフォルトでブローカを設定および管理できるようになっています。管理者は、複数のユーザーを admin グループに割り当てることができます。

• user グループ: 管理ユーザーでない通常の Message Queue クライアントユーザー用です。ほとんどのクライアントユーザーは user グループに所属します。デフォルトでは、このグループのユーザーはすべてのトピックとキューへのメッセージを生成し、すべてのトピックとキューからのメッセージを消費し、すべてのキューのメッセージを検索することができます。

• anonymous グループ: ブローカに認識されているユーザー名を使用しない Message Queue クライアント用です。クライアントアプリケーションが実際に使用するユーザー名を認識していないなどの理由がある場合に使います。このアカウントは、多くの FTP サーバーにある匿名アカウントに似ています。一度に anonymous グループに割り当てられるのは、1 人のユーザーだけです。このグループのアクセス権限を user グループよりも制限したり、配置時にグループからユーザーを削除する必要があります。

ユーザーが属するグループを変更するには、そのユーザーのエントリを削除してから、そのユーザーの別のエントリを追加し、新しいグループを指定します。

このようなシステムで生成されたグループの名前の変更や削除、および新しいグループの作成は行えません。ただし、そのグループのメンバーがどの操作を実行するかを定義するアクセス規則を指定できます。詳細は、「ユーザー承認: アクセス制御プロパティーファイル」を参照してください。

ユーザーの状態

ユーザーをリポジトリに追加した場合、デフォルトのユーザーの状態はアクティブです。ユーザーを非アクティブに変更するには、更新コマンドを使用する必要があります。たとえば、次のコマンドでは、ユーザーの JoeD が非アクティブになります。

imqusermgr update -u JoeD -a false

非アクティブになったユーザーのエントリは、リポジトリに保持されますが、非アクティブのユーザーは、新規接続を開くことはできません。ユーザーが非アクティブのときに、同じ名前を持つ別のユーザーを追加すると、操作に障害が発生します。非アクティブなユーザーのエントリを削除するか、新しいユーザーのユーザー名を変更するか、あるいは新しいユーザーに別のユーザー名を使用する必要があります。このようにして、重複するユーザー名が追加されるのを防ぎます。

ユーザー名とパスワードの形式

ユーザー名とパスワードは、次の規則に従う必要があります。

• ユーザー名にアスタリスク (*)、コンマ (,)、コロン (:)、改行やキャリッジリターン文字を使用することはできません。

• ユーザー名やパスワードは、1 文字以上であることが必要です。

• ユーザー名やパスワードに空白を入れる場合は、ユーザー名やパスワード全体を引用符で囲みます。

• コマンド行で入力可能な最大文字数で、コマンドシェルにより制限されない限り、パスワードやユーザー名の長さに制限はありません。

ユーザーリポジトリの設定と管理

add サブコマンドを使用して、ユーザーをリポジトリに追加します。たとえば、次のコマンドでは、sesame というパスワードを持つ Katharine というユーザーがデフォルトのブローカインスタンスユーザーリポジトリに追加されます。

imqusermgr add -u Katharine -p sesame -g user

delete サブコマンドを使用して、ユーザーをリポジトリから削除します。たとえば、次のコマンドでは Bob というユーザーが削除されます。

imqusermgr delete -u Bob

update サブコマンドを使用して、ユーザーのパスワードまたは状態を変更します。たとえば、次のコマンドでは、Katharine のパスワードが aladdin に変更されます。

imqusermgr update -u Katharine -p aladdin

1 人またはすべてのユーザーに関する情報を一覧表示するには、list コマンドを使用します。次のコマンドでは、isa という名前のユーザーに関する情報が表示されます。

imqusermgr list -u isa

% imqusermgr list -u isa

User repository for broker instance: imqbroker
----------------------------------
User Name    Group    Active State
----------------------------------
isa          admin    true

次のコマンドでは、すべてのユーザーに関する情報が表示されます。

imqusermgr list

% imqusermgr list

User repository for broker instance: imqbroker
--------------------------------------
User Name    Group        Active State
--------------------------------------
admin        admin        true
guest        anonymous    true
isa          admin        true
testuser1    user         true
testuser2    user         true
testuser3    user         true
testuser4    user         false
testuser5    user         false

デフォルトの管理者パスワードの変更

セキュリティーのために、admin のデフォルトパスワードを自分だけが知っているパスワードに変更する必要があります。次のコマンドは、mybroker ブローカインスタンスのデフォルトの管理者パスワードを admin から grandpoobah に変更します。

imqusermgr update mybroker -u admin -p grandpoobah

ブローカインスタンスの実行中に任意のコマンド行ツールを実行すれば、この変更が反映されていることをすぐに確認できます。たとえば、次のコマンドはパスワードの入力が要求されます。

imqcmd list svc mybroker -u admin

新しいパスワード (grandpoobah) は入力可能であり、古いパスワードでは失敗します。

パスワードを変更したあとは、管理コンソールなどのあらゆる Message Queue 管理ツールを使用するときに、新しいパスワードを使用してください。

ユーザーリポジトリでの LDAP サーバーの使用

ユーザーリポジトリに LDAP サーバーを使用する場合、次の作業を実行します。

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

• 管理者のアクセス制御の設定

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

ブローカでディレクトリサーバーを使用する場合、ブローカインスタンス設定ファイル config.properties で特定のプロパティーの値を設定します。これらのプロパティーを使用すると、ユーザーがブローカインスタンスへの接続を試みているか、メッセージング操作を実行しようとしている場合に、ブローカインスタンスが LDAP サーバーに対して、ユーザーやグループに関する情報をクエリーできるようになります。

インスタンス設定ファイルは、ブローカインスタンスディレクトリのディレクトリ内にあります。パスは次のような形式です。

…/instances/instanceName

/props/config.properties

オペレーティングシステム別のインスタンスディレクトリの場所については、付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照してください。

設定ファイルを編集して、LDAP サーバーを使用する

1. 次のプロパティーを設定して、LDAP ユーザーリポジトリの使用を指定します。

   imq.authentication.basic.user_repository=ldap

2. imq.authentication.type プロパティーを設定して、クライアントからブローカへのパスワードの受け渡しに、base64 (basic) 符号化方式を使用するか、MD5 (digest) 符号化方式を使用するかを決定します。LDAP ディレクトリサーバーをユーザーリポジトリに使用する場合、認証タイプに basic を設定する必要があります。たとえば、次のように指定します。

   imq.authentication.type=basic

3. LDAP へのアクセスを制御するブローカプロパティーを設定する必要もあります。このプロパティーは、ブローカインスタンス設定ファイル内にあります。プロパティーについては、「セキュリティーサービス」で説明し、「セキュリティーのプロパティー」にまとめています。

   Message Queue は JNDI API を使用して、LDAP ディレクトリサーバーと対話します。このプロパティーで使用されている構文と用語の詳細については JNDI のドキュメントを参照してください。Message Queue は、Sun JNDI LDAP プロバイダと簡単な認証を使用しています。

   Message Queue は LDAP 認証のフェイルオーバーをサポートします。認証が試みられる LDAP ディレクトリサーバーのリストを指定できます (imq.user.repos.ldap.server プロパティーの詳細を参照)。

   LDAP ユーザーリポジトリに関連したプロパティーの設定方法の例については、ブローカの config.properties ファイルを参照してください。

4. 必要に応じて、アクセス制御プロパティーファイルにあるユーザーまたはグループ、および規則を編集する必要があります。アクセス制御プロパティーファイルの使用に関する詳細は、「ユーザー承認: アクセス制御プロパティーファイル」を参照してください。

5. 接続の認証やグループ検索の間、ブローカに SSL を使用して LDAP ディレクトリとの通信を行わせる場合、LDAP サーバーの SSL をアクティブにし、ブローカ設定ファイルで次のプロパティーを設定します。

   • LDAP サーバーが SSL 通信に使用するポートを指定します。たとえば、次のように指定します。

     imq.user_repository.ldap.server=myhost:7878

   • ブローカプロパティーの imq.user_repository.ldap.ssl.enabled を true に設定します。

     複数の LDAP ディレクトリサーバーを使用している場合は、ldap:// を使用して、追加の各ディレクトリサーバーを指定します。たとえば、次のように指定します。

     imq.user_repository.ldap.server = myHost:7878 ldap:// otherHost:7878 …

     追加の各ディレクトリサーバーはスペースで区切ります。リスト内のすべてのディレクトリサーバーは、LDAP 関連プロパティーに同じ値を使用する必要があります。

管理者のアクセス制御の設定

管理ユーザーを作成するには、アクセス制御プロパティーファイルで、ADMIN 接続を作成できるユーザーとグループを指定します。これらのユーザーとグループは、LDAP ディレクトリで事前に定義されている必要があります。

ADMIN 接続を作成できるユーザーまたはグループは、管理コマンドを発行できます。

管理ユーザーを設定する

1. アクセス制御ファイルの使用を有効にするには、ブローカプロパティー imq.accesscontrol.enabled を、デフォルト値である true に設定します。

   imq.accesscontrol.enabled プロパティーにより、アクセス制御ファイルの使用が有効になります。

2. アクセス制御ファイル accesscontrol.properties を開きます。このファイルの場所については、付録 A 「プラットフォームごとの Message Queue^TM データの場所」の一覧を参照してください。

   このファイルには、次のようなエントリが収められています。

   サービス接続アクセス制御##################################connection.NORMAL.allow.user=*connection.ADMIN.allow.group=admin

   上記のエントリは一例です。admin グループはファイルベースのユーザーリポジトリに存在しますが、デフォルトでは LDAP ディレクトリに存在しないことに注意してください。LDAP ディレクトリで定義される、Message Queue 管理者権限を付与するグループの名前は変更する必要があります。

3. Message Queue 管理者権限をユーザーに付与するには、ユーザー名を次のように入力します。

   connection.ADMIN.allow.user= userName[[,userName2] …]

4. Message Queue 管理者権限をグループに付与するには、グループ名を次のように入力します。

   connection.ADMIN.allow.group= groupName[[,groupName2] …]

ユーザー承認: アクセス制御プロパティーファイル

アクセス制御プロパティーファイル (ACL ファイル) には、ユーザーおよびユーザーグループがどの操作を実行できるかを指定する規則が収められています。ACL ファイルを編集して、操作を特定のユーザーやグループに制限します。ブローカインスタンスごとに異なる ACL ファイルを使用できます。

ユーザー情報が単層型ファイルのユーザーリポジトリにある場合でも LDAP ユーザーリポジトリにある場合でも、ACL ファイルが使用されます。ブローカは、クライアントアプリケーションが次の操作のいずれかを実行するときに ACL ファイルをチェックします。

• 接続の作成

• プロデューサの作成

• コンシューマの作成

• キューの検索

ブローカは ACL ファイルをチェックして、要求を生成したユーザーまたはユーザーが所属するグループに対して、操作の実行を許可するかどうかを決定します。

ACL ファイルを編集する場合、次にブローカがファイルをチェックして認証を検証するまで、新しい設定は有効になりません。ファイルの編集後、ブローカを再起動する必要はありません。

アクセス制御プロパティーファイルの作成

ACL ファイルはインスタンス固有です。ブローカインスタンスを起動する場合は常に、インスタンスディレクトリでデフォルトファイル accesscontrol.properties が作成されます。ファイルのパスは次のような形式です (付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照)。

…/instances/brokerInstanceName/etc/accesscontrol.properties

ACL ファイルは、Java プロパティーファイルのような形式になっています。ACL ファイルは、ファイルのバージョンを指定すると起動し、次の 3 つのセクションのアクセス制御規則を指定します。

• 接続のアクセス制御

• 物理的送信先のアクセス制御

• 物理的送信先の自動作成アクセス制御

version プロパティーでは、ACL プロパティーファイルのバージョンが定義されるので、このエントリを変更しないでください。

version=JMQFileAccessControlModel/100

アクセス制御を指定する ACL ファイルの 3 つのセクションについては、アクセス規則の基本構文およびアクセス権の計算方法に続いて、説明します。

アクセス規則の構文

ACL プロパティーファイルでは、アクセス制御は、特定のユーザーやグループが物理的送信先や接続サービスといった保護されたリソースに対してどのアクセスを持っているのかを定義します。アクセス制御は、それぞれ Java プロパティーとして提示されている規則、または規則のセットで表現されます。

これらの規則の基本的な構文は次のとおりです。

resourceType.resourceVariant

.operation.access.
principalType=principals

表 7–3 に構文規則の各要素を示します。

ここで、アクセス規則の例をいくつか紹介します。

• 次の規則では、あらゆるユーザーがメッセージを ql という名前のキューに送信します。

  queue.q1.produce.allow.user=*

• 次の規則では、あらゆるユーザーがあらゆるキューにメッセージを送信します。

  queue.*.produce.allow.user=*

ASCII でないユーザー、グループ、または送信先の名前を指定するには、Unicode エスケープ (\\uXXXX) の表記法を使用します。ASCII コードではない名前を含む ACL ファイルを編集して保存した場合、Java native2ascii ツールを使用して、ファイルを ASCII に変換できます。詳細は、次を参照してください。

http://java.sun.com/j2se/1.4/docs/guide/intl/faq.html

権限の計算方法

ファイル内に複数のアクセス規則が存在する場合、権限を次のように計算します。

• 特定のアクセス規則は、一般的なアクセス規則に優先します。次の 2 つの規則が適用されると、ユーザーはだれでもすべてのキューに送信できますが、Bob は tq1 に送信できません。

  queue.*.produce.allow.user=*
  queue.tq1.produce.deny.user=Bob

• 明示的な principal に指定されたアクセスは、* principal に指定されたアクセスに優先します。次の規則で、Bob は tq1 へのメッセージを生成できませんが、その他のユーザーはメッセージを生成できます。

  queue.tq1.produce.allow.user=*
  queue.tq1.produce.deny.user=Bob

• ユーザーの * principal 規則は、グループの対応する * principal 規則に優先します。たとえば、次の 2 つの規則では、すべての認証済みユーザーがメッセージを tq1 に送信できます。

  queue.tq1.produce.allow.user=*
  queue.tq1.produce.deny.group=*

• ユーザーに許可されたアクセスは、ユーザーのグループに許可されたアクセスに優先します。次の例では、Bob が User のメンバーである場合でも、tq1 へのメッセージは生成できません。User のその他のメンバーはすべて、メッセージを生成できます。

  queue.tq1.produce.allow.group=User
  queue.tq1.produce.deny.user=Bob

• アクセスを介して明示的に指定されていないアクセス権は、暗黙的に拒否されます。たとえば、ACL ファイルにアクセス規則がない場合、すべてのユーザーはすべての操作を実行できません。

• 同じユーザーまたはグループにアクセス権の拒否と許可を行うと、すべてが取り消されます。たとえば、次の 2 つの規則が適用されると、Bob は q1 を検索できなくなります。

  queue.q1.browse.allow.user=Bob
  queue.q1.browse.deny.user=Bob

  次の 2 つの規則は、グループ User が q5 でメッセージを消費するのを禁止します。

  queue.q5.consume.allow.group=User
  queue.q5.consume.deny.group=User

• 同じ左側の規則が複数ある場合、最後のエントリが有効になります。

接続サービスのアクセス制御

ACL プロパティーファイルの接続アクセス制御のセクションには、ブローカの接続サービスのアクセス制御規則が含まれます。接続アクセス制御規則の構文は次のとおりです。

connection.resourceVariant.
access.principalType=
principals

resourceVariant には 2 つの値が定義されています: NORMAL と ADMIN。これらの定義済みの値は、アクセス権を付与できる唯一のタイプの接続サービスです。

デフォルトの ACL プロパティーファイルは、すべてのユーザーに NORMAL 接続サービスへのアクセス権を付与し、グループ admin のユーザーに ADMIN 接続サービスへのアクセス権を付与します。

connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admin

ファイルベースのユーザーリポジトリを使用している場合、ユーザーマネージャーユーティリティーによりデフォルトのグループ admin が作成されます。LDAP ユーザーリポジトリを使用している場合、次のいずれかを実行して、デフォルトの ACL プロパティーファイルを使用します。

• LDAP ディレクトリでグループ admin を定義します。

• ACL プロパティーファイルの名前 admin を、LDAP ディレクトリで定義される 1 つ以上のグループの名前と置換します。

接続アクセス権限を制限できます。たとえば、次の規則では Bob が NORMAL にアクセスすることは拒否されますが、ほかのユーザーはすべてアクセスが許可されます。

connection.NORMAL.deny.user=Bob
connection.NORMAL.allow.user=*

アスタリスク (*) 文字を使用して、すべての認証済みユーザーまたはグループを指定できます。

ACL プロパティーファイルを使用して ADMIN 接続へのアクセスを付与する方法は、次のように、ファイルベースのユーザーリポジトリと LDAP ユーザーリポジトリでは異なります。

• ファイルベースのユーザーリポジトリ

  • アクセス制御が無効に設定されている場合、グループ admin には ADMIN 接続権限が割り当てられます。

  • アクセス制御が有効な場合、ACL ファイルを編集します。ユーザーまたはグループに、ADMIN 接続サービスへのアクセス権を明示的に付与します。

• LDAP ユーザーリポジトリ。LDAP ユーザーリポジトリを使用している場合、次のいずれかを実行します。

  • アクセス制御を有効にします。

  • ACL ファイルを編集して、ADMIN 接続を作成できるユーザーまたはグループの名前を指定します。LDAP ディレクトリサーバーで定義されるユーザーまたはグループを指定します。

物理的な送信先のアクセス制御

アクセス制御プロパティーファイルの送信先アクセス制御セクションには、物理的送信先ベースのアクセス制御規則が含まれます。これらの規則では、だれ (ユーザーまたはグループ) が何 (操作) をどこ (物理的送信先) に行うかが決定されます。これらの規則で統制されるアクセスのタイプには、キューへのメッセージの送信、トピックへのメッセージの発行、キューからのメッセージの受信、トピックへのサブスクライブ、キューでのメッセージの検索が含まれます。

デフォルトでは、あらゆるユーザーまたはグループが、任意の物理的送信先に対してあらゆるタイプのアクセス権を保持できます。さらに詳細な送信先アクセス規則を追加したり、デフォルトの規則を編集したりできます。この節の残りの部分では、自分自身の規則を記述するために理解しておく必要のある物理的送信先アクセス規則の構文について説明します。

送信先規則の構文は次のとおりです。

resourceType.resourceVariant.operation.access.principalType=principals

表 7–4 にこれらの要素の説明を示します。

アクセス権は、1 人以上のユーザーまたは 1 つ以上のグループ、あるいはその両方に対して指定できます。

次の例では、さまざまな種類の物理的送信先のアクセス制御規則を示します。

• すべてのユーザーが、あらゆるキュー送信先に対してメッセージを送信できます。

  queue.*.produce.allow.user=*

• user グループのメンバーがトピック Admissions にサブスクライブする機能を拒否します。

  topic.Admissions.consume.deny.group=user

自動作成された物理的送信先のアクセス制御

ACL プロパティーファイルの最後のセクションには、どのユーザーおよびグループに対してブローカが物理的送信先を自動作成するのかを指定するアクセス規則が含まれます。

まだ存在していない物理的送信先でユーザーがプロデューサまたはコンシューマを作成すると、ブローカの自動作成プロパティーが有効になっている場合、ブローカは送信先を作成します。

デフォルトでは、任意のユーザーやグループは、ブローカに物理的送信先を自動作成させる権限を持っています。この権限は、次の規則で指定されます。

queue.create.allow.user=*
topic.create.allow.user=*

ACL ファイルを編集して、このタイプのアクセスを制限できます。

物理的送信先の自動作成アクセス規則の一般的な構文は、次のとおりです。

resourceType.create.access.principalType=principals

resourceType の部分には、queue か topic が表示されます。

たとえば次の規則により、ブローカは Snoopy 以外の全員に対してトピック送信先を自動作成できます。

topic.create.allow.user=*
topic.create.deny.user=Snoopy

物理的送信先の自動作成規則の結果は、物理的送信先のアクセス規則の影響と一致している必要があります。たとえば、1) 送信先アクセス規則を変更して、どのユーザーも送信先にメッセージを送信できないようにしてから、2) 送信先の自動作成を有効にすると、ブローカは物理的送信先が存在しない場合、物理的送信先を作成しますが、メッセージの配信は行いません。

メッセージの暗号化

この節では、SSL (Secure Socket Layer) 規格に基づいた接続サービスの設定方法を説明します。これにより、クライアントとブローカ間で、暗号化されたメッセージが送信されます。Message Queue は、次の SSL ベースの接続サービスをサポートしています。

• ssljms サービスは、TCP/IP トランスポートプロトコルを使用して、クライアントとブローカ間で、安全な、暗号化されたメッセージを配信します。

• ssladmin サービスは、TCP/IP トランスポートプロトコルを使用して、Message Queue コマンドユーティリティー (imqcmd) とブローカ間に安全な暗号化接続を作成します。暗号化接続は、管理コンソール (imqadmin) ではサポートされていません。

• cluster サービスは、TCP/IP トランスポートプロトコルを使用して、クラスタ内のブローカ間に、安全な、暗号化された通信を提供します。

• httpsjms サービスは、HTTP トランスポートプロトコルを使用する HTTPS トンネルサーブレットを使用して、クライアントとブローカ間で、安全な、暗号化されたメッセージを配信します。

この節の後半では、ssljms、ssladmin、および cluster 接続サービスを使用して、TCP/IP 経由で安全な接続を確立する方法について説明します。httpsjms サービスを使用した、HTTP 経由の安全な接続の確立の詳細は、付録 C 「HTTP/HTTPS のサポート」を参照してください。

自己署名付き証明書の使用

TCP/IP を介して SSL ベースの接続サービスを使用するには、キーツールユーティリティー (imqkeytool) を使用して、公開鍵と非公開鍵のペアを生成します。このユーティリティーは、ブローカへの接続を要求しているクライアントに渡される自己署名付き証明書に公開鍵を埋め込み、クライアントはこの証明書を使用して、接続を暗号化します。この節では、このような自己署名付き証明書を使用した SSL ベースのサービスの設定方法を説明します。

認証を強力なものにするために、認証局が検証する署名付き証明書を使用できます。署名付き証明書を使用するには、自己署名付き証明書に必要な手順のほかに、いくつかの追加手順を実行する必要があります。まず、この節で説明されている手順を実行し、次に、「署名付き証明書の使用」の追加手順に従う必要があります。

Message Queue の自己署名付き証明書による SSL のサポートは、クライアントが既知の信頼されたサーバーと通信することを前提に、ネットワーク上のデータを保護することを目的としています。以降に、SSL ベースの接続サービスを設定して、自己署名付き証明書を使用するために必要な手順を示します。手順に続く項では、これらの各手順についてより詳しく説明しています。

自己署名付き証明書を使用して SSL ベースの接続サービスを設定する

1. 自己署名付き証明書を生成します。

2. ブローカで ssljms、ssladmin、cluster のいずれかの接続サービスを有効にします。

3. ブローカを起動します。

4. クライアントを設定し実行します。

   この手順は、ssljms 接続サービスにのみ適用されます。ssladmin または cluster には適用されません。

自己署名付き証明書の生成

キーツールユーティリティー (imqkeytool) を実行し、ブローカの自己署名付き証明書を生成します。UNIX® システムでは、キーストアを作成するアクセス権を取得するために、スーパーユーザー (root) としてユーティリティーを実行する必要があります。ssljms、ssladmin、cluster の接続サービスに対して、同じ証明書を使用できます。

コマンドプロンプトで次のとおり入力します。

imqkeytool -broker

キーツールユーティリティーによりキーストアのパスワードの入力が要求されます。

   Generating keystore for the broker ...
   Enter keystore password:

次に、ユーティリティーにより、この証明書の所有者であるブローカを識別する情報の入力が要求されます。指定する情報は、X.500 識別名になります。表 7–5 に、プロンプトと、それぞれに指定する値を示します。値は大文字と小文字を区別し、空白を使用できます。

情報を入力し終えたら、キーツールユーティリティーにより確認の画面が表示されます。たとえば、次のように指定します。

   Is CN=mqserver.sun.com, OU=purchasing, ON=My Company, Inc.,
   L=San Francisco, ST=California, C=US correct?

現在の値でよければ、先に進み、yes を入力します。値を再入力する場合は、デフォルトを使用するか no を入力します。確認後、ユーティリティーが鍵ペアを生成する間、このユーティリティーは停止します。

次に、ユーティリティーから鍵ペアをロックするためのパスワードの入力が要求されます (キーパスワード)。このプロンプトに対して Return キーを押し、キーパスワードおよびキーストアパスワードと同じパスワードを使用します。

指定したパスワードは覚えておいてください。ブローカの起動時にこのパスワードを指定し、ブローカがキーストアを開けるようにする必要があります。キーストアパスワードはパスワードファイルに保存できます (「パスワードファイル」を参照)。

キーツールユーティリティーは、自己署名付き証明書を生成し、Message Queue のキーストアに配置します。キーストアは、付録 A 「プラットフォームごとの Message Queue^TM データの場所」に記載されているとおり、オペレーティングシステムに応じたディレクトリにあります。

次に示すのは、SSL ベースの接続サービスの場合の、Message Queue キーストアの設定可能なプロパティーです。

• imq.keystore.file.dirpath: キーストアファイルが配置されているディレクトリへのパスです。デフォルト値については、付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照してください。

• imq.keystore.file.name: キーストアファイル名です。

• imq.keystore.password: キーストアのパスワードです。

状況によっては、特定の問題を解決するために、鍵ペアを生成し直す必要があります。たとえば、キーストアのパスワードを忘れてしまった場合や、ブローカの起動時に次の例外が発生し、SSL ベースのサービスの初期化に失敗した場合などです。

java.security.UnrecoverableKeyException:Cannot recover key

この例外は、自己署名付き証明書を生成したときに、キーストアのパスワードと違ったものをキーのパスワードに設定した場合に発生する可能性があります。

鍵ペアを生成し直す

1. 付録 A 「プラットフォームごとの Message Queue^TM データの場所」に示すとおり、ブローカのキーストアを削除します。

2. 上記の説明に従って、imqkeytool をもう一度実行し、新しい鍵ペアを生成します。

SSL ベースの接続サービスを有効にする

ブローカでの SSL ベースの接続サービスを有効にするには、ssljms (または、ssladmin) を imq.service.activelist プロパティーに追加する必要があります。

ブローカで SSL ベースのサービスを有効にする

1. ブローカのインスタンス設定ファイルを開きます。

   インスタンス設定ファイルは、その設定ファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに書き込まれます (付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照)。

      .../instances/instanceName/props/config.properties
   

2. 存在していない場合は、imq.service.activelist プロパティーのエントリを追加し、希望する SSL ベースのサービスをリストに含めます。

   デフォルトでは、プロパティーには jms 接続サービスと admin 接続サービスが含まれます。SSL ベースのサービス、またはアクティブ化するサービス (ssljms か ssladmin、またはその両方) を追加します。

   imq.service.activelist=jms,admin,ssljms,ssladmin
   

   ---

   注 –

   SSL ベースの cluster 接続サービスは、imq.service.activelist プロパティーではなく imq.cluster.transport プロパティーを使用して有効化されます。「ブローカの接続」を参照してください。

   ---

3. インスタンス設定ファイルを保存して閉じます。

ブローカを起動する

キーストアパスワードを入力して、ブローカを起動します。パスワードの入力は、次の 2 つのいずれかの方法で行います。

• ブローカの起動時にパスワードを要求するように許可します。

     imqbrokerd
     Please enter Keystore password:

• 「パスワードファイル」の説明に従って、パスワードをパスワードファイルに格納します。次に、プロパティー imq.passfile.enabled = true を設定し、次のいずれかを実行します。

  • imqbrokerd コマンドにパスワードファイルの場所を渡します。

    imqbrokerd -passfile /passfileDirectory/passfileName
    

  • -passfile オプションを使用せず、次の 2 つのブローカ設定プロパティーを使用するパスワードファイルの場所を指定して、ブローカを起動します。

    imq.passfile.dirpath=/passfileDirectory
    
    imq.passfile.name=passfileName
    

SSL を使用してブローカまたはクライアントを起動するときに、CPU の使用率が、数秒間急上昇します。これは、Message Queue が乱数を生成するために使用する JSSE (Java Secure Socket Extension) メソッド java.security.SecureRandom が、最初の乱数シードを作成するのにかなりの時間がかかるためです。シードが作成されると、CPU の使用率は通常に戻ります。

SSL ベースのクライアントを設定して実行する

SSL ベースの接続サービスを使用するようにクライアントを設定する手順は、クライアントが、アプリケーションクライアント (ssljms 接続サービスを使用) であるか、imqcmd などの Message Queue 管理クライアント (ssladmin 接続サービスを使用) であるかによって異なります。

アプリケーションクライアント

アプリケーションクライアントの場合、クライアントが、次の .jar ファイルを CLASSPATH 変数に指定していることを確認する必要があります。

imq.jar




jms.jar

J2SDK (Java 2 Software Development Kit) の 1.4 よりも古いバージョンを使用している場合は、次の JSSE (Java Secure Socket Extension) および JNDI (Java Naming and Directory Interface) の .jar ファイルも含める必要があります。

jsse.jar




jnet.jar




jcert.jar




jndi.jar

JSSE と JNDI のサポートが組み込まれている J2SDK 1.4 以降を使用している場合は、これらのファイルを含める必要はありません。

CLASSPATH ファイルを適切に指定したら、クライアントを起動し、ブローカの ssljms 接続サービスに接続する方法の 1 つとして、次のようなコマンドを入力します。

java -DimqConnectionType=TLS clientAppName

これにより、接続に SSL ベースの接続サービスを使用するよう指示が出されます。

管理クライアント

管理クライアントの場合、imqcmd コマンドを呼び出すときに、-secure オプションを指定すると、安全な接続を確立できます。たとえば、次のように指定します。

imqcmd list svc -b hostName:portNumber -u adminName -secure

adminName には Message Queue ユーザーリポジトリの有効なエントリが入ります。コマンドからパスワードの入力が要求されます。単層型ファイルリポジトリを使用している場合は、「デフォルトの管理者パスワードの変更」を参照してください。

接続サービスを一覧表示すると、次の出力のように、ssladmin サービスが実行中で、安全な管理接続が問題なく確立されたことが確認できます。

Listing all the services on the broker specified by:

Host                 Primary Port
localhost            7676

Service Name     Port Number       Service State
admin            33984 (dynamic)   RUNNING
httpjms          -                 UNKNOWN
httpsjms         -                 UNKNOWN
jms              33983 (dynamic)   RUNNING
ssladmin         35988 (dynamic)   RUNNING
ssljms           dynamic           UNKNOWN

Successfully listed services.

署名付き証明書の使用

署名付き証明書は、自己署名付き証明書よりも強力なサーバー認証をもたらします。署名付き証明書はクライアントとブローカ間でのみ実装可能で、クラスタ内の複数のブローカ間に実装できません。署名付き証明書を実装するには、前に説明した自己署名付き証明書の設定の手順に加えて、次の追加の手順を実行する必要があります。これらの手順については、以降の節でより詳しく説明します。

署名付き証明書を使用する

1. 証明書をキーストアにインストールします。

2. ブローカへの SSL ベースの接続を確立するときに、署名付き証明書を要求するように Message Queue クライアントを設定します。

署名付き証明書の取得とインストール

次の手順は、署名付き証明書を取得して、インストールする方法について説明しています。

署名付き証明書を取得する

1. J2SE keytool コマンドを使用して、前節で作成した自己署名付き証明書の CSR (certificate signing request) を生成します。

   keytool コマンドについての情報は、次のサイトを参照してください。

   http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html

   次に例を示します。

   keytool -certreq -keyalg RSA -alias imq -file certreq.csr -keystore /etc/imq/keystore -storepass myStorePassword

   これにより、指定したファイル (この例では certreq.csr) に証明書を含む CSR が生成されます。

2. CSR を使用して、署名付き証明書を生成または要求します。

   次のいずれかの方法で、これを行うことができます。

   • Thawte や Verisign などの非常に著名な認証局 (CA) から、証明書に署名してもらいます。この方法の詳細については、CA のマニュアルを参照してください。

   • SSL 署名ソフトウェアパッケージを使用して、証明書に自己署名を行います。

     最終的な署名付き証明書は、 ASCII 文字列が連続したものになります。CA から署名付き証明書を受け取る場合、電子メールの添付またはテキスト形式のメッセージとして届きます。

3. 署名付き証明書をファイルに保存します。

   次の手順では、ブローカの証明書に broker.cer という名前が使用されています。

署名付き証明書をインストールする

1. J2SE が、使用中の認証局をデフォルトでサポートしているかどうかを確認します。

   次のコマンドは、システムキーストアの root CA を一覧表示します。

   keytool -v -list -keystore $JAVA_HOME/lib/security/cacerts
   

   使用中の CA がリスト内に見つかったら、次の手順は省略してください。

2. 使用中の認証局が J2SE でサポートされていない場合、CA のルート証明書を Message Queue キーストアにインポートします。

   次に例を示します。

   keytool -import -alias ca -file ca.cer -noprompt -trustcacerts
           -keystore /etc/imq/keystore -storepass myStorePassword
   

   ca.cer は、CA から取得したルート証明書を含むファイルです。

   CA テスト証明書を使用している場合、Test CA Root 証明書をインポートする必要があるかもしれません。CA には、コピーの入手方法に関する手順が示されているはずです。

3. 署名付き証明書をキーストアにインポートし、オリジナルの自己署名付き証明書と置き換えます。

   次に例を示します。

   keytool -import -alias imq -file broker.cer -noprompt -trustcacerts
           -keystore /etc/imq/keystore -storepass myStorePassword
   

   broker.cer は、CA から受け取った署名付き証明書を含むファイルです。

   Message Queue キーストアに、SSL 接続に使用できる署名付き証明書が格納されました。

署名付き証明書を要求する Message Queue クライアントランタイムの設定

次に、署名付き証明書を要求するように Message Queue クライアントランタイムを設定し、証明書に署名した認証局を信頼していることを確認する必要があります。

署名付き証明書を要求するようにクライアントランタイムを設定する

1. 接続ファクトリの imqSSLIsHostTrusted 属性を false に設定します。

   デフォルトでは、クライアントがブローカ接続の確立に使用する接続ファクトリオブジェクトの imqSSLIsHostTrusted 属性は true に設定されています。これは、クライアントランタイムが、提示されたすべての証明書を受け入れることを意味しています。この値を false に変更して、クライアントランタイムが、提示されたすべての証明書の検証を試みるようにする必要があります。証明書の署名者がクライアントのトラストストアに含まれていない場合、検証は失敗します。

2. 署名機関がクライアントのトラストストアに登録されているかどうかを確認します。

   クライアントが、使用している認証局によって署名された証明書を受け入れるかどうかをテストするには、「SSL ベースのクライアントを設定して実行する」の説明に従って、SSL 接続の確立を試みます。CA が、クライアントのトラストストアに含まれている場合は、接続は成功します。この場合、次の手順は省略してもかまいません。接続が証明書の有効性検証エラーにより失敗した場合、次の手順を実行します。

3. クライアントのトラストストアに、署名 CA のルート証明書をインストールします。

   クライアントは、デフォルトで、キーストアファイル cacerts と jssecacerts を検索するため、これらのいずれかに証明書をインストールする場合は、これ以降の設定は不要です。次の例では、testrootca.cer というファイルから、デフォルトのシステムの証明書ファイル cacerts に、Verisign 認証局からの test root 証明書をインストールしています。この例は、J2SE がディレクトリ $JAVA_HOME/usr/j2se にインストールされていることを前提としています。

   keytool -import -keystore /usr/j2se/jre/lib/security/cacerts
           -alias VerisignTestCA -file testrootca.cer -noprompt
           -trustcacerts -storepass myStorePassword
   

   もう 1 つの選択肢 (推奨) として、ルート証明書を、別のシステムの証明書ファイル jssecacerts にインストールする方法があります。

   keytool -import -keystore /usr/j2se/jre/lib/security/jssecacerts
           -alias VerisignTestCA -file testrootca.cer -noprompt
           -trustcacerts -storepass myStorePassword
   

   3 つ目は、ルート証明書をその他のキーストアファイルにインストールして、それをトラストストアとして使用するようにクライアントを設定する方法です。次の例では、ファイル /home/smith/.keystore にインストールしています。

   keytool -import -keystore /home/smith/.keystore
           -alias VerisignTestCA -file testrootca.cer -noprompt
           -trustcacerts -storepass myStorePassword
   

   クライアントはデフォルトでこのキーストアを検索しないため、トラストストアとして使用するように、その場所をクライアントに明示的に知らせる必要があります。これを行うには、クライアントの実行後に、Java システムプロパティー javax.net.ssl.trustStore を次のように設定します。

   javax.net.ssl.trustStore=/home/smith/.keystore
   

パスワードファイル

コマンドにはパスワードを必要とするものがいくつかあります。表 7–6 では、最初の列にパスワードを必要とするコマンド、2 番目の列にパスワードが必要な理由を一覧表示しています。

パスワードファイルでこれらのパスワードを指定し、-passfile オプションを使用してファイル名を指定します。次に示すのは、-passfile オプションの形式です。

imqbrokerd -passfile myPassfile

以前のリリースでは、-p、-password 、-dbpassword、-ldappassword のオプションを使用してコマンド行でパスワードを指定できました。これらのオプションには異論が多く、今後のリリースでは削除される予定です。現在のリリースでは、これらのオプションのいずれかのコマンド行の値は、パスワードファイルの対応する値よりも優先されます。

セキュリティー上の問題

プロンプトに応じて、パスワードをインタラクティブに指定するのは、ほかのユーザーにモニタリングが表示されていなければ、もっとも安全なパスワード指定の方法です。またコマンド行でパスワードファイルも指定できます。ただし、コマンドをインタラクティブではない方法で使用する場合、パスワードファイルを使用する必要があります。

パスワードファイルは暗号化されず、このため不正なアクセスから保護するためにパスファイルにアクセス権を設定する必要があります。ファイルを表示できるユーザーを制限するが、ブローカを起動するユーザーに読み取りアクセスを許可するようにアクセス権を設定します。

パスワードファイルの内容

パスワードファイルは、一連のプロパティーと値を収めた簡単なテキストファイルです。それぞれの値はコマンドで使用されるパスワードです。

パスワードファイルには、表 7–7 に示すパスワードを含めることができます。

imq.keystore.password

imq.persist.jdbc.password

imqbrokerd
imdbmgr

imq.user_repository.ldap.password

imqbrokerd

サンプルパスワードファイルは、Message Queue 製品に組み込まれています。サンプルファイルの場所については、付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照してください。

ファイアウォールを介した接続

クライアントアプリケーションが、ファイアウォールによってブローカから隔てられている場合は、接続を確立するために特別な手段が必要です。1 つの手段として、ファイアウォールを「トンネリング」できる httpjms または httpsjms 接続サービスを使用する方法があります。詳細については、付録 C 「HTTP/HTTPS のサポート」を参照してください。ただし、HTTP 接続は、ほかの接続サービスよりも低速です。より高速な別の手段として、Message Queue ポートマッパーをバイパスし、目的の接続サービスに静的ポートアドレスを明示的に割り当ててから、ファイアウォールでその特定のポートを開く方法があります。この方法を使用することで、jms または ssljms 接続サービス (例外的な場合は admin もしくは ssladmin) を使用して、ファイアウォールを介して接続できます。

ファイアウォールを介したブローカの接続を有効にする

1. 使用する接続サービスに、静的ポートアドレスを割り当てます。

   ポートマッパーをバイパスし、接続サービスに静的ポート番号を直接割り当てるには、ブローカ設定プロパティー imq.serviceName. protocolType.port を設定します。serviceName は接続サービスの名前で、protocolType はそのプロトコルタイプです (表 7–8 を参照)。すべてのブローカ設定プロパティーと同様に、このプロパティーは、ブローカのインスタンス設定ファイルで指定するか、またはブローカの起動時にコマンド行から指定することができます。たとえば、jms 接続サービスにポート番号 10234 を割り当てるには、次の行を設定ファイルに含めるか、

      imq.jms.tcp.port=10234
   

   または、次のコマンドを使用してブローカを起動します。

      
   imqbrokerd  -name myBroker  -Dimq.jms.tcp.port=10234
   

2. 接続サービスに割り当てたポート番号への接続を許可するように、ファイアウォールを設定します。

   Message Queue のポートマッパーのポートへの、ファイアウォールを介した接続も許可する必要があります。このポートは、ポートマッパーをその他のポートに再割り当てしていない限り、通常は 7676 です。たとえば、上記の例では、ポート 10234 および 7676 のファイアウォールを開く必要があります。

監査ロギング

Message Queue は Enterprise Edition でのみ監査ロギングをサポートします。監査ロギングを有効にすると、Message Queue は次のタイプのイベントに対してレコードを生成します。

• ブローカインスタンスの起動、シャットダウン、再起動、削除

• ユーザーの認証と承認

• 持続ストアのリセット

• 物理的送信先の作成、消去、破棄

• 永続的サブスクライバの管理上の破棄

Message Queue ブローカログファイルにレコードの監査レコードのログを作成するには、imq.audit.enabled ブローカプロパティーを true に設定します。ログ内のすべての監査レコードには、キーワード AUDIT が含まれています。

第 8 章 管理対象オブジェクトの管理

管理対象オブジェクトでは、プロバイダ固有の設定およびネーミング情報をカプセル化することにより、JMS プロバイダ間で移植可能なクライアントアプリケーションを開発できます。Message Queue^TM の管理者は、通常、クライアントアプリケーションがメッセージの送受信のためのブローカ接続を取得する際に使用する管理対象オブジェクトを作成します。

この章では、オブジェクトマネージャーユーティリティー (imqobjmgr ) を使用して、管理対象オブジェクトを作成および管理する方法について説明します。この章は、次の節から構成されています。

• 「オブジェクトストア」

• 「管理対象オブジェクトの属性」

• 「オブジェクトマネージャーユーティリティーの使用」

• 「管理対象オブジェクトの追加」

• 「管理対象オブジェクトの一覧表示」

• 「管理対象オブジェクトの情報の表示」

• 「管理対象オブジェクトの属性の変更」

オブジェクトストア

管理対象オブジェクトは、即時に使用可能なオブジェクトストアに配置されます。クライアントアプリケーションは、JNDI (Java Naming and Directory Interface) を介して、このオブジェクトストアに配置された管理対象オブジェクトにアクセスします。使用できるオブジェクトストアには、次の 2 種類があります。標準 LDAP (Lightweight Directory Access Protocol) ディレクトリサーバーとローカルファイルシステムのディレクトリです。

LDAP サーバーオブジェクトストア

LDAP サーバーは、本稼動メッセージングシステム用のオブジェクトストアとしてお勧めします。LDAP サーバーは、分散システムでの使用を考慮した設計になっており、本稼動環境で役立つセキュリティー機能を備えています。

LDAP 実装は、多数のベンダーによってサポートされています。Message Queue の管理ツールで LDAP サーバー上のオブジェクトストアを管理するには、最初に、Java オブジェクトを格納して JNDI 検索を実行するようにサーバーを設定する必要がある場合があります。詳細については、使用する LDAP 実装に付属のマニュアルを参照してください。

LDAP サーバーをオブジェクトストアとして使用するには、表 8–1 に示す属性を指定する必要があります。これらの属性は、次のように分類されます。

• 初期コンテキスト: java.naming.factory.initial 属性は、サーバーでの JNDI 検索の初期コンテキストを指定します。LDAP オブジェクトストアの場合、この属性の値は固定です。

• 場所:java.naming.provider.url 属性は、LDAP サーバーの URL とディレクトリパスを指定します。指定したパスが存在することを確認する必要があります。

• セキュリティー:java.naming.security.principal、java.naming.security.credentials、および java.naming.security.authentication 属性は、オブジェクトストアにアクセスを試みる呼び出し元の認証を制御します。これらの属性の正確な形式と値は、LDAP サービスプロバイダによって異なります。詳細について、およびセキュリティー情報がすべての操作に対して必要か、または格納されたデータを変更する操作に対してのみ必要かについては、使用する LDAP 実装に付属のマニュアルを参照してください。

ファイルシステムオブジェクトストア

Message Queue では、管理対象オブジェクトのオブジェクトストアとしてローカルファイルシステムのディレクトリを使用することもサポートされています。この方法は、本稼動システムにはお勧めしませんが、開発環境で非常に簡単に扱えるという利点があります。ただし、複数のコンピュータノードに配備されているクライアントに対して、一元化されたオブジェクトストアとしてディレクトリを使用する場合は、それらすべてのクライアントがディレクトリへのアクセス権を持っている必要があります。また、ディレクトリへのアクセス権を持つユーザーはすべて、Message Queue の管理ツールを使用して管理対象オブジェクトを作成および管理できます。

ファイルシステムのディレクトリをオブジェクトストアとして使用するには、表 8–2 に示す属性を指定する必要があります。これらの属性の意味は、前述の LDAP オブジェクトストアの場合とほとんど同じですが、java.naming.provider.url 属性では、オブジェクトストアを格納するディレクトリのディレクトリパスを指定します。このディレクトリが存在していて、Message Queue の管理ツールのユーザーと、ストアにアクセスするクライアントアプリケーションのユーザーが、適切なアクセス権を持っている必要があります。

java.naming.factory.initial

java.naming.provider.url

管理対象オブジェクトの属性

Message Queue の管理対象オブジェクトには、2 つの基本的な種類があります。

• 接続ファクトリ。ブローカへの接続を作成するために、クライアントアプリケーションが使用します。

• 送信先。クライアントアプリケーションがメッセージを交換 (送受信) するブローカ上の場所を表します。

SOAP メッセージングでは、特殊な SOAP 終端管理対象オブジェクトが使用されます。詳細は、『Message Queue Developer's Guide for Java Clients』を参照してください。

各種類の管理対象オブジェクトは、オブジェクトのプロパティーと動作を決める特定の属性を持ちます。この節では、コマンド行ユーティリティーであるオブジェクトマネージャー (imqobjmgr) を使用してこれらの属性を設定する方法について説明します。また、「管理対象オブジェクトの操作」で説明したように、GUI 管理コンソールで属性を設定することもできます。

接続ファクトリの属性

クライアントアプリケーションは、接続ファクトリ管理対象オブジェクトを使用して、ブローカとメッセージを交換するための接続を作成します。接続ファクトリの属性は、その接続ファクトリが作成するすべての接続のプロパティーを定義します。接続が作成されたあとは、そのプロパティーを変更できません。つまり、接続のプロパティーを設定するには、その作成に使用される接続ファクトリの属性を設定する必要があります。

Message Queue では、2 つのクラスの接続ファクトリオブジェクトが定義されています。

• ConnectionFactory オブジェクト。通常のメッセージングおよび分散していないトランザクションをサポートします。

• XAConnectionFactory オブジェクト。分散トランザクションをサポートします。

どちらのクラスも同じ設定属性を持ち、それらを使用して、リソース、パフォーマンス、およびメッセージスループットを最適化できます。これらの属性のリストと詳細な説明については、第 16 章「管理対象オブジェクト属性のリファレンス」を参照してください。次の節では、これらの属性について取り上げます。

• 「接続の処理」

• 「クライアントの識別」

• 「信頼性およびフロー制御」

• 「キューブラウザとサーバーセッション」

• 「標準メッセージプロパティー」

• 「メッセージヘッダーの上書き」

接続の処理

接続処理の属性では、接続先のブローカのアドレス、および必要に応じて、接続障害の検出方法と再接続の試行方法を指定します。これらの要約については、表 16–1を参照してください。

ブローカのアドレスリスト

もっとも重要な接続処理の属性は、接続の確立先となる 1 つ以上のブローカを指定する imqAddressList です。この属性の値は、ブローカのアドレスを 1 つ含む文字列、またはブローカクラスタの場合はコンマ区切りで複数含む文字列です。ブローカのアドレスには、使用する接続サービス (「接続サービス」を参照) と接続の確立方法に応じて、さまざまなアドレススキーマを使用できます。

• mq。jms または ssljms 接続サービスで、ブローカのポートマッパーを使用してポートを動的に割り当てます。

• mqtcp。jms 接続サービスを使用し、ポートマッパーをバイパスして、指定されたポートに直接接続します。

• mqssl。ssljms 接続サービスを使用し、指定されたポートへの SSL (Secure Socket Layer) 接続を作成します。

• http。httpjms 接続サービスを使用し、指定された URL の Message Queue トンネルサーブレットへの HTTP (Hypertext Transport Protocol) 接続を作成します。

• https。httpsjms 接続サービスを使用し、指定された URL の Message Queue トンネルサーブレットへの HTTPS (Secure Hypertext Transport Protocol) 接続を作成します。

これらのアドレススキーマの要約については、表 16–2を参照してください。

各ブローカアドレスの一般的な形式は、次のようになります。

scheme://address

scheme は、前述のアドレススキーマのいずれかで、address は、ブローカのアドレス自体を示します。アドレスを指定するための正確な構文は、表 16–2の最後の列に示すように、アドレススキーマによって異なります。表 16–3 に、さまざまなアドレス形式の例を示します。

複数のブローカによるクラスタ環境では、アドレスリストに複数のブローカアドレスを含めることができます。最初の接続試行に失敗すると、Message Queue クライアントランタイムは、リスト内の別のアドレスに接続を試行し、成功するまでリスト内のすべてのアドレスに順に接続を試みます。2 つの追加の接続ファクトリ属性によって、この方法を制御します。

• imqAddressListBehavior。指定したアドレスへの試行順序を指定します。この属性を文字列 PRIORITY に設定すると、アドレスリストに表示されている順序でアドレスが試行されます。属性値を RANDOM にすると、ランダムな順序でアドレスが試行されます。これは、たとえば、多数の Message Queue クライアントが同じ接続ファクトリオブジェクトを共有しているときに、すべてのクライアントが同じブローカアドレスに接続を試行するのを避けるためなどに便利です。

• imqAddressListIterations。試行を中止して失敗を報告するまでの、リストの繰り返し回数を指定します。値 -1 は、繰り返し回数が無制限であることを示します。つまり、クライアントランタイムは、接続の確立に成功するか時間切れになるまで試行を続けます。

自動再接続

接続ファクトリの imqReconnectEnabled 属性を true に設定すると、接続に障害が発生した場合にクライアントがブローカに自動的に再接続するように設定できます。imqReconnectAttempts 属性では、特定のブローカアドレスに再接続を試行する回数を制御します。imqReconnectInterval 属性では、試行の間隔をミリ秒単位で指定します。

ブローカのアドレスリスト (imqAddressList) で複数のアドレスを指定するブローカクラスタでは、障害の発生した接続を、元のブローカだけでなく、クラスタ内の別のブローカでも復元できます。元のブローカへの再接続に失敗すると、クライアントランタイムは、リスト内のほかのアドレスを試行します。前述のとおり、imqAddressListBehavior および imqAddressListIterations 属性で、アドレスの試行順序とリストの繰り返し回数を制御します。各アドレスは、imqReconnectInterval ミリ秒の間隔で、imqReconnectAttempts を最大回数として、繰り返し試行されます。

自動再接続では、メッセージの消費に関するすべてのクライアント通知モードがサポートされます。接続が再確立されると、ブローカは、以前に配信した未通知メッセージをすべて再配信し、それらに Redeliver フラグを付けます。アプリケーションコードでは、このフラグを使用して、特定のメッセージが消費されたが未通知であるかどうかを判断できます。ただし、永続的でないサブスクライバの場合、ブローカは、接続が閉じられたあとはメッセージを保持しません。そのため、接続がダウンしている間にそれらのサブスクライバに対して生成されたメッセージは、再接続後に配信できず、失われることになります。自動再接続中は、メッセージ生成がブロックされます。メッセージプロデューサは、接続の再確立が完了するまで、ブローカにメッセージを送信できません。

自動再接続は、接続のフェイルオーバーを提供しますが、データのフェイルオーバーは実行しません。障害の発生したブローカまたは切断されたブローカが保持する持続メッセージ、その他の状態情報は、クライアントが別のブローカインスタンスに再接続すると失われることがあります。接続の再確立の試行中、Message Queue によって、クライアントランタイムが提供したオブジェクト (セッション、メッセージコンシューマ、メッセージプロデューサなど) は維持されます。一時的送信先も、接続に障害が発生したときは、クライアントがそれらの送信先に再接続して再度アクセスする可能性があるため、当面は維持されます。再接続してそれらの送信先を使用するための時間をクライアントに与えたあとで、ブローカはそれらを削除します。再接続時にブローカでクライアント側の状態を完全に復元できない場合 (たとえば、接続の間のみ存在する処理済セッションを使用している場合など) は、自動再接続は行われず、代わりに接続の例外ハンドラが呼び出されます。その後の例外のキャッチ、再接続、および状態の復元は、アプリケーションコードに任されます。

接続の定期的なテスト (ping)

Message Queue クライアントランタイムは、接続を定期的にテストする、つまり「ping」を実行するように設定できます。これにより、メッセージ転送に失敗する前に、予防的に接続の障害を検出できます。メッセージを消費するだけで生成しないクライアントアプリケーションでは、接続の障害を検出する手段がほかにないため、このようなテストが特に重要です。メッセージをたまに生成するだけのクライアントでも、この機能が役立ちます。

接続ファクトリ属性 imqPingInterval では、接続で ping を実行する頻度を秒単位で指定します。デフォルトでは、この間隔は 30 秒に設定されます。値 -1 を指定すると、ping の実行が無効になります。

失敗した ping への対応は、オペレーションシステムのプラットフォームによって異なります。一部のオペレーティングシステムでは、ただちに、クライアントアプリケーションの例外リスナーに例外がスローされます。クライアントに例外リスナーがない場合は、その接続を使用するための次回の試行に失敗します。また、オペレーティングシステムによっては、ブローカへの接続の確立を試行し続け、ping が成功するかバッファーがオーバーフローするまで、一連の ping をバッファリングするものもあります。

クライアントの識別

表 16–4 に示されている接続ファクトリ属性は、クライアント認証と、永続サブスクライバのクライアント識別子の設定をサポートしています。

クライアント認証

ブローカへのすべての接続試行は、ユーザー名とパスワードによって、メッセージサービスが管理するユーザーリポジトリに対して認証される必要があります。接続ファクトリ属性 imqDefaultUsername および imqDefaultPassword では、クライアントが接続の作成時にユーザー名とパスワードを明示的に提供しなかった場合に使用するデフォルトのユーザー名とパスワードを指定します。

開発者がアプリケーションの開発およびテストの際にユーザーリポジトリを設定する手間を省くことができるように、Message Queue には、ユーザー名とパスワードがどちらも guest に設定されたゲストユーザーアカウントが用意されています。これは、imqDefaultUsername および imqDefaultPassword 属性のデフォルト値でもあるため、これらが明示的に指定されていない場合、クライアントは常にゲストアカウントで接続を取得できます。本稼動環境では、ブローカ接続へのアクセスは、ユーザーリポジトリに明示的に登録されているユーザーのみに制限するべきです。

クライアント識別子

『Java Message Service 仕様書』では、ブローカがクライアントに代わって持続状態を維持する必要があるときは常に、接続で一意のクライアント識別子を提供することが要求されています。Message Queue は、このクライアント識別子を使用して、トピック送信先への永続サブスクライバを追跡します。永続サブスクライバが非アクティブになると、ブローカは、そのトピックのすべての受信メッセージを保持し、サブスクライバが再度アクティブになったときにそれらを配信します。ブローカは、クライアント識別子によってサブスクライバを識別します。

クライアントアプリケーションが接続オブジェクトの setClientID メソッドを使用してプログラムによって独自のクライアント識別子を設定することは可能ですが、この場合、クライアント識別子が互いに一意になるように調整するのが難しくなります。一般的には、Message Queue が、クライアントに代わって接続を作成するときに一意の識別子を自動的に割り当てるようにすることをお勧めします。このためには、接続ファクトリの imqConfiguredClientID 属性を、次の形式の値に設定します。

${u}factoryID

この属性値の先頭の 4 文字は必ず、${u} になります。括弧内に u 以外の文字があると、接続の作成時に例外がスローされます。先頭以外の位置では、これらの文字は特別な意味を持たず、プレーンテキストとして扱われます。factoryID の値は、この接続ファクトリオブジェクトに一意に関連付ける文字列です。

特定のクライアントの接続を作成するときに、Message Queue は、文字列 $\ を u:userName に置き換えることによってクライアント識別子を生成します。userName は、接続で認証されたユーザー名です。これにより、特定の接続ファクトリによって作成された接続がそれぞれ、ほかのすべての面で同一であっても、一意のクライアント識別子を持つことが保証されます。たとえば、ユーザー名が Calvin で、接続ファクトリの imqConfiguredClientID 属性に指定された文字列が ${u}Hobbes である場合、割り当てられるクライアント識別子は u:CalvinHobbes になります。

2 つのクライアントがデフォルトユーザー名 guest を使用して接続を取得しようとした場合、それぞれが同じ ${u} 要素を含むクライアント識別子を持つことになるため、このスキーマは動作しません。この場合は、先に接続を要求したクライアントだけが接続を取得します。Message Queue は同じクライアント識別子を持つ 2 つの接続を作成できないため、あとのクライアントの接続試行は失敗します。

imqConfiguredClientID を使用してクライアント識別子を指定する場合でも、クライアントアプリケーションは、接続メソッド setClientID を使用してこの設定を上書きできます。接続ファクトリの imqDisableSetClientID 属性を true に設定することで、これを避けることができます。永続サブスクライバを使用するアプリケーションでは、クライアント識別子を必ず設定する必要があります。その方法は、管理のために imqConfiguredClientID を使用するか、プログラムによって setClientID を使用するかのいずれかです。

信頼性およびフロー制御

クライアントが送受信する「ペイロード」メッセージと Message Queue 自体が使用する制御メッセージ (ブローカ通知など) は、クライアントとブローカ間の同じ接続でやり取りされるため、ペイロードのトラフィックが過剰になると、制御メッセージの配信が妨げられる可能性があります。この問題を軽減するために、表 16–5 に示されている接続ファクトリ属性を使用して、2 種類のメッセージの相対的なフローを管理できます。これらの属性は、4 つのカテゴリに分類されます。

• 通知タイムアウト: 例外をスローするまでのブローカ通知の最大待ち時間 (imqAckTimeout) を指定します。

• 接続フロー測定: ペイロードメッセージの転送を、指定したサイズ (imqConnectionFlowCount) のバッチに制限します。これにより、累積された制御メッセージを配信する機会が定期的に得られます。

• 接続フロー制御: 特定の接続で、消費を待って保留状態になるペイロードメッセージの数 (imqConnectionFlowLimit) を制限します。制限に達すると、消費待ちのメッセージの数が制限を下回るまで、その接続へのペイロードメッセージの配信が一時停止されます。この機能の使用は、ブール型のフラグ (imqConnectionFlowLimitEnabled) によって制御します。

• コンシューマフロー制御: 単一のコンシューマに対して、消費を待って保留状態になるペイロードメッセージの数 (imqConsumerFlowLimit) を制限します。この制限は、特定のキュー送信先のプロパティー (consumerFlowLimit) として指定することもできます。制限に達すると、消費待ちのメッセージの数が、imqConsumerFlowLimit に対する割合として imqConsumerFlowThreshold 属性で指定した制限を下回るまで、そのコンシューマへのペイロードメッセージの配信が一時停止されます。同じ接続上で 1 つのコンシューマがほかのコンシューマの通信を妨げるのを回避することによって、複数のコンシューマ間のロードバランスを向上させるのに役立ちます。

これらのフロー制御技術のいずれを使用する場合でも、信頼性とスループットの兼ね合いを考慮する必要があります。詳細は、「クライアントランタイムのメッセージフローの調整」を参照してください。

キューブラウザとサーバーセッション

表 16–6に、クライアントのキュー検索とサーバーセッションに関する接続ファクトリ属性が示されています。imqQueueBrowserMaxMessagesPerRetrieve 属性では、キュー送信先の内容の検索時に一度に取得するメッセージの最大数を指定します。imqQueueBrowserRetrieveTimeout 属性では、メッセージ取得の最大待ち時間を指定します。imqQueueBrowserMaxMessagesPerRetrieve は、検索されるメッセージの総数には影響せず、クライアントランタイムに配信するためにチャンクされる方法だけに影響します。つまり、サイズの大きいチャンクを少数にするか、サイズの小さいチャンクを多数にするか、です。クライアントアプリケーションは、常にキュー内のすべてのメッセージを受信します。属性の値の変更は、パフォーマンスに影響することがありますが、受信するデータの総量には影響しません。ブール型の imqLoadMaxToServerSession 属性では、アプリケーションサーバーセッションでの接続コンシューマの動作を制御します。この属性の値が true の場合、クライアントは、1 回のサーバーセッションで最大数までのメッセージを読み込みます。false の場合は、一度に 1 つのメッセージだけを読み込みます。

標準メッセージプロパティー

『Java Message Service 仕様書』では、Message Queue などの JMS プロバイダが任意でサポートできる、いくつかの標準メッセージプロパティーを定義しています。規定によって、これらの標準プロパティーの名前はすべて、JMSX という文字列で始まります。表 16–7 control whether the Message Queue に示されている接続ファクトリ属性では、クライアントランタイムがこれらいずれかの標準プロパティーを設定するかどうかを制御します。生成されたメッセージについては、次のプロパティーがあります。

• JMSXUserID メッセージを送信するユーザーの識別情報

• JMSXAppID メッセージを送信するアプリケーションの識別情報

• JMSXProducerTXID メッセージが生成されたトランザクションのトランザクション識別子

消費されたメッセージについては、次のものがあります。

• JMSXConsumerTXID メッセージが消費されたトランザクションのトランザクション識別子

• JMSXRcvTimestamp コンシューマにメッセージが配信された時刻

メッセージヘッダーの上書き

表 16–8に示されている接続ファクトリ属性を使用して、クライアントが特定の JMS メッセージヘッダーフィールドに設定した値を上書きできます。指定した設定は、その接続ファクトリから取得された接続が生成するすべてのメッセージに使用されます。この方法で上書きできるヘッダーフィールドには次のものがあります。

• JMSDeliveryMode 配信モード (持続的または持続性なし)

• JMSExpiration 有効期限

• JMSPriority 優先度のレベル

これらのフィールドにはそれぞれ、2 つの属性があります。フィールドが上書き可能であるかどうかを制御するブールの属性と、フィールドの値を指定する属性です。たとえば、優先度のレベルを設定するための属性は、imqOverrideJMSPriority と imqJMSPriority です。さらに、上書きの値を一時送信先に適用するかどうかを制御する imqOverrideJMSHeadersToTemporaryDestinations 属性もあります。

メッセージヘッダーを上書きすると、特定のアプリケーションの要件に支障を及ぼす可能性があるため、これらの属性は、必ずアプリケーションの設計者またはユーザーに相談した上で使用することをお勧めします。

送信先の属性

物理的なキューまたはトピック送信先を識別する送信先管理対象オブジェクトには、表 16–9 に示されている 2 つの属性だけがあります。重要な属性である imqDestinationName では、この管理対象オブジェクトが表す物理的送信先の名前を指定します。これは、その物理的送信先を作成した imqcmd create dst コマンドの -n オプションで指定された名前です。送信先管理対象オブジェクトとそれらが表す物理的送信先との間が 1 対 1 の関係である必要はありません。1 つの物理的送信先は、複数の管理対象オブジェクトによって参照されることも、まったく参照されないこともあります。オプションの説明文字列である imqDestinationDescription もあります。これを使用して、送信先オブジェクトを識別しやすくしたり、作成済みのほかの送信先オブジェクトと区別しやすくしたりできます。

オブジェクトマネージャーユーティリティーの使用

Message Queue のオブジェクトマネージャーユーティリティー (imqobjmgr) を使用して、管理対象オブジェクトを作成および管理できます。imqobjmgr コマンドには、管理対象オブジェクトに対してさまざまな操作を実行するための、次のサブコマンドが用意されています。

add

管理対象オブジェクトをオブジェクトストアに追加します

delete

管理対象オブジェクトをオブジェクトストアから削除します

list

オブジェクトストア内の既存の管理対象オブジェクトを一覧表示します

query

管理対象オブジェクトに関する情報を表示します

update

管理対象オブジェクトの属性を変更します

imqobjmgr コマンドの構文、サブコマンド、およびオプションに関する参照情報については、「オブジェクトマネージャーユーティリティー」を参照してください。

オブジェクトマネージャーのほとんどの操作で、imqobjmgr コマンドのオプションとして次の情報を指定する必要があります。

• 管理対象オブジェクトの JNDI 検索名 (-l)

  これは、クライアントアプリケーションが Java Naming and Directory Interface を使ってオブジェクトストア内の管理対象オブジェクトを検索するときに使用する論理名です。

• JNDI オブジェクトストアの属性 (-j)

  使用可能な属性とそれらの値については、「オブジェクトストア」を参照してください。

• 管理対象オブジェクトのタイプ (-t)

  使用可能なタイプには次のものがあります。

  q

  キュー送信先

  t

  トピック送信先

  cf

  接続ファクトリ

  qf

  キュー接続ファクトリ

  tf

  トピック接続ファクトリ

  xcf

  分散トランザクションの接続ファクトリ

  xqf

  分散トランザクションのキュー接続ファクトリ

  xtf

  分散トランザクションのトピック接続ファクトリ

  e

  SOAP の端点

• 管理対象オブジェクトの属性 (-o)

  使用可能な属性とそれらの値については、「管理対象オブジェクトの属性」を参照してください。

管理対象オブジェクトの追加

imqobjmgr コマンドの add サブコマンドでは、接続ファクトリおよびトピックまたはキュー送信先管理対象オブジェクトをオブジェクトストアに追加します。LDAP オブジェクトストアに格納する管理対象オブジェクトには、接頭辞 cn= で始まる検索名を割り当てる必要があります。ファイルシステムオブジェクトストアでは、検索名を特定の接頭辞で始める必要はありませんが、スラッシュ文字 (/) を含めてはいけません。

オブジェクトマネージャーは、Message Queue 管理対象オブジェクトだけを一覧表示します。オブジェクトストアに、追加したい管理対象オブジェクトと同じ検索名の Message Queue 以外のオブジェクトが含まれている場合は、追加操作を実行するとエラーが表示されます。

接続ファクトリの追加

クライアントアプリケーションがブローカ接続を作成できるようにするには、作成される接続のタイプに応じた接続ファクトリ管理対象オブジェクトを追加します。つまり、キュー接続ファクトリまたはトピック接続ファクトリです。例 8–1に、キュー接続ファクトリ (管理対象オブジェクトのタイプ qf) を LDAP オブジェクトストアに追加するコマンドを示します。このオブジェクトは、検索名が cn=myQCF で、ホスト myHost のポート番号 7272 で実行するブローカに、jms 接続サービスを使用して接続します。

例 8–1 接続ファクトリの追加

imqobjmgr add
   -l "cn=myQCF"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t qf
   -o "imqAddressList=mq://myHost:7272/jms"

送信先の追加

送信先を表す管理対象オブジェクトを作成するときは、最初に物理的送信先を作成してから、管理対象オブジェクトをオブジェクトストアに追加することをお勧めします。物理的送信先を作成するには、「物理的送信先の作成」で説明しているように、コマンドユーティリティー (imqcmd) を使用します。

例 8–2に示すコマンドでは、トピック送信先を表す管理対象オブジェクトを LDAP オブジェクトストアに追加しています。検索名は myTopic で、物理的送信先の名前は physTopic です。キュー送信先を追加するためのコマンドも同様になりますが、管理対象オブジェクトのタイプ (-t オプション) を、トピック (topic) 送信先を示す t の代わりに、キュー (queue) 送信先を示す q にします。

例 8–2 LDAP オブジェクトストアへの送信先の追加

imqobjmgr add
   -l "cn=myTopic"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t t
   -o "imqDestinationName=physTopic"

例 8–3に、同じコマンドで、LDAP サーバーではなく Solaris ファイルシステムに管理対象オブジェクトを格納する場合の例を示します。

例 8–3 ファイルシステムオブジェクトストアへの送信先の追加

imqobjmgr add
   -l "cn=myTopic"
   -j "java.naming.factory.initial=
           com.sun.jndi.fscontext.RefFSContextFactory"
   -j "java.naming.provider.url=file:///home/foo/imq_admin_objects"
   -t t
   -o "imqDestinationName=physTopic"

管理対象オブジェクトの削除

管理対象オブジェクトをオブジェクトストアから削除するには、imqobjmgr コマンドの delete サブコマンドを使用して、削除するオブジェクトの検索名、タイプ、および場所を指定します。例 8–4に示すコマンドでは、前述の「送信先の追加」で追加したオブジェクトを削除しています。

例 8–4 管理対象オブジェクトの削除

imqobjmgr delete
   -l "cn=myTopic"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t t

管理対象オブジェクトの一覧表示

オブジェクトマネージャーの list サブコマンドを使用して、オブジェクトストア内のすべての管理対象オブジェクトまたは特定のタイプの管理対象オブジェクトを一覧表示できます。例 8–5 に、LDAP サーバー上のすべての管理対象オブジェクトを一覧表示する例を示します。

例 8–5 すべての管理対象オブジェクトの一覧表示

imqobjmgr list
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"

例 8–6 では、すべてのキュー送信先 (タイプ q) を一覧表示しています。

例 8–6 特定のタイプの管理対象オブジェクトの一覧表示

imqobjmgr list
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t q

管理対象オブジェクトの情報の表示

query サブコマンドでは、検索名および格納先のオブジェクトストアの属性によって指定した管理対象オブジェクトに関する情報が表示されます。例 8–7 では、検索名が cn=myTopic であるオブジェクトの情報を表示しています。

例 8–7 管理対象オブジェクトの情報の表示

imqobjmgr query
   -l "cn=myTopic"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"

管理対象オブジェクトの属性の変更

管理対象オブジェクトの属性を変更するには、imqobjmgr update サブコマンドを使用します。オブジェクトの検索名と場所を指定し、-o オプションを使用して新しい属性値を指定します。

「管理対象オブジェクトの属性の変更」では、例 8–8 でオブジェクトストアに追加したキュー接続ファクトリの imqReconnectAttempts 属性の値を変更しています。

例 8–8 管理対象オブジェクトの属性の変更

imqobjmgr update
   -l "cn=myQCF"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t qf
   -o "imqReconnectAttempts=3"

コマンドファイルの使用

imqobjmgr コマンドの -i オプションでは、Java プロパティーファイルの構文を使用してサブコマンド節の全部または一部を示したコマンドファイルの名前を指定できます。この機能は特に、通常は多くの入力が必要で、imqobjmgr を何度も呼び出す場合はたいてい同じになる、オブジェクトストアの属性を指定するときに便利です。また、コマンドファイルを使用すると、コマンド行で許可されている最大文字数を超えてしまうのを避けることもできます。

例 8–9 に、オブジェクトマネージャーコマンドファイルの一般的な構文を示します。version プロパティーはコマンド行オプションではありません。これは、コマンドファイル自体のバージョン (Message Queue 製品のバージョンではない) を示し、値を 2.0 に設定する必要があります。

例 8–9 オブジェクトマネージャーコマンドファイルの構文

version=2.0
cmdtype=[ add | delete | list | query | update ]
obj.lookupName=lookup name
objstore.attrs.objStoreAttrName1=value1
objstore.attrs.objStoreAttrName2=value2
   . . .
objstore.attrs.objStoreAttrNameN=valueN
obj.type=[ q | t | cf | qf | tf | xcf | xqf | xtf | e ]
obj.attrs.objAttrName1=value1
obj.attrs.objAttrName2=value2
   . . .
obj.attrs.objAttrNameN=valueN

前述の例 8–1 で示した、LDAP オブジェクトストアにキュー接続ファクトリを追加するオブジェクトマネージャーコマンドを例として考えてみます。このコマンドは、例 8–10 に示すようにコマンドファイルでカプセル化できます。コマンドファイルの名前を MyCmdFile とした場合、次のコマンド行でコマンドを実行できます。

imqobjmgr -i MyCmdFile

例 8–10 コマンドファイルの例

version=2.0
cmdtype=add
obj.lookupName=cn=myQCF
objstore.attrs.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
objstore.attrs.java.naming.provider.url=ldap://mydomain.com:389/o=imq
objstore.attrs.java.naming.security.principal=\\
                                       uid=homerSimpson,ou=People,o=imq
objstore.attrs.java.naming.security.credentials=doh
objstore.attrs.java.naming.security.authentication=simple
obj.type=qf
obj.attrs.imqAddressList=mq://myHost:7272/jms

コマンドファイルを使用して、imqobjmgr サブコマンド節の一部だけを指定し、残りの部分はコマンド行で明示的に指定することもできます。たとえば、例 8–11 に示すコマンドファイルでは、LDAP オブジェクトストアの属性値だけを指定しています。

例 8–11 部分的なコマンドファイル

version=2.0
objstore.attrs.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
objstore.attrs.java.naming.provider.url=ldap://mydomain.com:389/o=imq
objstore.attrs.java.naming.security.principal=\\
                                       uid=homerSimpson,ou=People,o=imq
objstore.attrs.java.naming.security.credentials=doh
objstore.attrs.java.naming.security.authentication=simple

次に、例 8–12 に示すように、このコマンドファイルを使用して imqobjmgr コマンドでオブジェクトストアを指定し、残りのオプションを明示的に指定できます。

例 8–12 部分的なコマンドファイルの使用

imqobjmgr add
   -l "cn=myQCF"
   -i MyCmdFile
   -t qf
   -o "imqAddressList=mq://myHost:7272/jms"

コマンドファイルのその他の例は、プラットフォームに応じて次の場所で参照できます。

Solaris:/usr/demo/imq/imqobjmgr Linux:/opt/sun/mq/examples/imqobjmgr Windows:IMQ_HOME/demo/imqobjmgr

第 9 章 ブローカクラスタを使用した作業

Message Queue^TM ではブローカクラスタの使用がサポートされています。ブローカクラスタでは、ブローカのグループの連動により、メッセージ配信サービスがクライアントに提供されます。メッセージサービスでは、クラスタにより、複数のブローカ間でクライアント接続を分散し、メッセージトラフィックのボリュームで処理を拡張できます。クラスタとその動作方法の概要については、『Message Queue 技術の概要』を参照してください。

この章では、ブローカクラスタを管理する方法、ブローカをブローカクラスタに接続する方法、ブローカクラスタを設定する方法について説明します。この章は、次の節から構成されています。

• 「クラスタ設定プロパティー」

• 「クラスタ管理」

• 「マスターブローカ」

クラスタ設定プロパティー

クラスタを定義するには、メンバーブローカごとにクラスタ設定プロパティーを指定します。このプロパティーは、クラスタのブローカごとに個別に設定できますが、このプロパティーを中央のクラスタ設定ファイルに集めて、すべてのブローカに参照させる方が一般的に便利です。このようにすると、設定の不一致を防止し、クラスタのすべてのブローカで同一の一貫した設定情報を共有できます。

クラスタ設定プロパティーについては、表 14–9 で詳しく説明します。クラスタ設定プロパティーには次のものが含まれます。

• imq.cluster.brokerlist では、クラスタに属しているすべてのブローカのホスト名とポート番号を指定します。

• imq.cluster.masterbroker では、どのブローカをマスターブローカにするかを必要に応じて指定します。マスターブローカでは状態変更を追跡します。

• imq.cluster.url では、必要に応じてクラスタ設定ファイルの場所を指定します。

• imq.cluster.hostname では、cluster 接続サービスのホスト名か IP アドレスを指定します。複数のホストを使用できる場合、この設定は便利です。たとえば、複数のネットワークインタフェースカードが 1 台のコンピュータに含まれる場合に便利です。

• imq.cluster.port では、cluster 接続サービスのポート番号を指定します。

• imq.cluster.transport では、tcp や ssl など、cluster cluster 接続サービスで使用するトランスポートプロトコルを指定します。

hostname プロパティーと port プロパティーはブローカごとに個別に設定できますが、brokerlist、masterbroker、url、transport は、クラスタのすべてのブローカで同一の値にする必要があります。

次の節では、クラスタのブローカごとに個別に、またはクラスタ設定ファイルを使用して中央で、ブローカのクラスタ設定プロパティーを設定する方法について説明します。

ブローカごとのクラスタプロパティーの設定

ブローカのクラスタ設定プロパティーは、インスタンス設定ファイルで、またはブローカの起動時にコマンド行で設定できます。たとえば、host1 のポート 9876、host2 のポート 5000、ctrlhost のデフォルトポート 7676 のブローカから構成されるクラスタを作成するには、3 つすべてのブローカのインスタンス設定ファイルに次のプロパティーを含めます。

imq.cluster.brokerlist=host1:9876,host2:5000,ctrlhost

この手法では、クラスタ設定を変更する必要がある場合、クラスタのブローカごとにインスタンス設定ファイルを更新する必要があることに注意してください。

クラスタ設定ファイルの使用

一貫性を保って保守しやすくするため、ブローカごとに共有クラスタ設定プロパティーを設定する代わりに、すべての共有クラスタ設定プロパティーを 1 つのクラスタ設定ファイルに集めることをお勧めします。この手法では、それぞれのブローカのインスタンス設定ファイルで imq.cluster.url プロパティーを設定し、クラスタ設定ファイルの場所を指定する必要があります。たとえば、次のように指定します。

imq.cluster.url=file:/home/cluster.properties

クラスタ設定ファイルでは、接続するブローカのリスト (imq.cluster.brokerlist)、cluster 接続サービスに使用するトランスポートプロトコル (imq.cluster.transport )、任意でマスターブローカのアドレス (imq.cluster.masterbroker) など、クラスタに属しているすべてのブローカの共有設定プロパティーを定義します。次のコードでは、前の例と同じクラスタが定義され、ctrlhost で動作するブローカがマスターブローカになります。

imq.cluster.brokerlist=host1:9876,host2:5000,ctrlhost
imq.cluster.masterbroker=ctrlhost

クラスタ管理

この節では、ブローカのセットを接続してクラスタを形成する方法、既存クラスタに新しいブローカを追加する方法、クラスタからブローカを削除する方法について説明します。

ブローカの接続

一般的にブローカを接続してクラスタを形成する方法は、2 つあります。コマンド行から行う方法 (-cluster オプションを使用) と、クラスタ設定ファイルで imq.cluster.brokerlist プロパティーを設定する方法です。どちらの方法を使用しても、起動するそれぞれのブローカは、5 秒ごとにその他のブローカとの接続を試み、設定されている場合はマスターブローカが起動すると接続されます。マスターブローカの前にクラスタのブローカを起動すると、マスターブローカが起動するまで、そのブローカは保留状態になり、クライアント接続を拒否します。マスターブローカが起動すると、保留状態のブローカは自動的に完全に機能するようになります。

ブローカクラスタをコマンド行から設定するには、それぞれのブローカの起動時に、imqbrokerd コマンドの -cluster オプションを使用して、クラスタのブローカの完全なリストを指定します。たとえば次のコマンドでは、新しいブローカが起動し、host1 のデフォルトポート 7676、host2 のポート 5000、デフォルトホスト localhost のポート 9876 で動作しているブローカに接続されます。

imqbrokerd -cluster host1,host2:5000,:9876

本稼動システムに適した別の方法として、クラスタ設定ファイルを作成し、imq.cluster.brokerlist プロパティーを使用して、接続するブローカのリストを指定する方法があります。クラスタのそれぞれのブローカでは、独自の imq.cluster.url プロパティーを設定し、このクラスタ設定ファイルの場所を指定する必要があります。

いずれの方法であれ、クラスタ内のブローカで、ネットワーク ループバック IP アドレス (127.0.0.1) に解決するアドレスが指定されていないことを確認する必要があります。このアドレスで設定されたブローカは、クラスタ内のほかのブローカに接続できなくなります。

一部の Linux インストーラでは、localhost エントリが、ネットワークループバックアドレスに自動的に設定されます。このようなシステムでは、クラスタのすべてのブローカでアドレスを適切にするように、システムの IP アドレスを変更する必要があります。

クラスタに加わるすべての Linux システムでは、クラスタ設定の一環として /etc/hosts ファイルをチェックしてください。システムで固定 IP アドレスを使用している場合は、/etc/hosts ファイルを編集し、localhost の正しいアドレスを指定します。アドレスがドメインネームサービス (DNS) に登録されている場合は、/etc/nsswitch.conf ファイルを編集してエントリの順序を変更し、システムが DNS 検索を実行してから、ローカルの hosts ファイルを参照するように設定します。/etc/nsswitch.conf ファイルの行は次のようになります。

hosts:dns files

安全で暗号化されたメッセージ配信がクラスタのブローカ間で必要である場合は、SSL ベースのトランスポートプロトコルを使用するように cluster 接続サービスを設定します。「メッセージの暗号化」で説明するように、クラスタのブローカごとに、SSL ベースの接続サービスを設定します。次にそれぞれのブローカの imq.cluster.transport プロパティーを、クラスタ設定ファイルでまとめて、またはブローカごとに個別に、ssl に設定します。

クラスタへのブローカの追加

新しいブローカをクラスタに追加する手順は、クラスタでクラスタ設定ファイルを使用しているかどうかによって決まります。

クラスタ設定ファイルを使用して新しいブローカをクラスタに追加する

1. クラスタ設定ファイルにある imq.cluster.brokerlist プロパティーに、新しいブローカを追加します。

2. クラスタ内の任意のブローカに次のコマンドを実行します。

   imqcmd reload cls

   それぞれのブローカでクラスタ設定が再読み込みされ、クラスタに属しているブローカのすべての一貫した情報が最新になります。このコマンドをクラスタ内の各ブローカに対して実行する必要はありません。いずれかのブローカに対して実行すれば、すべてのブローカでクラスタ設定が再ロードされます。

3. (任意指定) ブローカの config.properties ファイルで imq.cluster.url プロパティーの値をクラスタ設定ファイルの場所に設定します。

4. 新しいブローカを起動します。

   「クラスタへのブローカの追加」を実行しなかった場合は、imqbrokerd コマンド行で -D オプションを使用し、imq.cluster.url の値を設定します。

クラスタ設定ファイルを使用せずに新しいブローカをクラスタに追加する

config.properties ファイルを編集するか、imqbrokerd コマンド行で -D オプションを使用し、次のプロパティー値を設定します。

• imq.cluster.brokerlist

• imq.cluster.masterbroker (必要に応じて)

• imq.cluster.transport (安全な cluster 接続サービスを使用している場合)

クラスタからのブローカの削除

クラスタからブローカを削除する方法は、最初にコマンド行でクラスタを作成したか、中央のクラスタ設定ファイルによって作成したかによって決まります。

コマンド行を使用したブローカの削除

コマンド行から imqbrokerd コマンドを使用してブローカをクラスタに接続した場合は、それぞれのブローカを停止してから、コマンド行に新しいクラスタメンバーセットを指定してブローカを再起動する必要があります。その手順は次のとおりです。

コマンド行を使用してクラスタからブローカを削除する

1. imqcmd コマンドを使用し、クラスタのそれぞれのブローカを停止します。

2. imqbrokerd コマンドの -cluster オプションを使用し、クラスタに残すブローカのみを指定してそれらのブローカを再起動します。

   たとえば、次のコマンドを使用して、A、B、 C というそれぞれのブローカを起動し、その 3 つのブローカから構成されるクラスタを最初に作成したとします。

   imqbrokerd -cluster A,B, C

   ブローカ A をクラスタから削除するには、次のコマンドを使用してブローカ B と C を再起動します。

   imqbrokerd -cluster B,C

クラスタ設定ファイルを使用したブローカの削除

中央のクラスタ設定ファイルの imq.cluster.brokerlist プロパティーでメンバーブローカを指定してクラスタを最初に作成した場合、ブローカを停止してメンバーのうち 1 つのブローカを削除する必要はありません。単純に設定ファイルを編集して削除したいブローカを除外し、残りのクラスタメンバーにクラスタ設定を再読み込みさせます。除外するブローカは、同じクラスタ設定ファイルの場所を指定しないように再設定します。手順は次のとおりです。

クラスタ設定ファイルを使用してクラスタからブローカを削除する

1. クラスタ設定ファイルを編集し、imq.cluster.brokerlist プロパティーに指定しているリストから除外対象ブローカを削除します。

2. クラスタ内の残りのブローカに次のコマンドを実行します。

   imqcmd reload cls

   ブローカがクラスタ設定を再読み込みします。

3. クラスタから削除するブローカを停止します。

4. そのブローカの config.properties ファイルを編集し、imq.cluster.url プロパティーを削除するか、別の値を指定します。

マスターブローカ

クラスタには、1 つのマスターブローカを任意に含めることができます。マスターブローカでは設定変更レコードが維持され、クラスタの持続的な状態の変更が追跡されます。マスターブローカは、クラスタ設定ファイル、またはそれぞれのブローカのインスタンス設定ファイルで、imq.cluster.masterbroker 設定プロパティーによって識別されます。

設定変更レコードには、永続サブスクリプション、および管理者が作成した物理的送信先など、クラスタに関連する持続エンティティーの変更に関する情報が含まれます。クラスタのすべてのブローカは、起動中にマスターブローカを参照し、この持続エンティティーに関する情報を更新します。このような同期は、マスターブローカの障害によって不可能になります。詳細は、「マスターブローカを使用できない場合」を参照してください。

設定変更レコードの管理

設定変更レコードには重要な情報が含まれるので、定期的にバックアップして、障害が発生した場合に復元できるようにすることが重要です。バックアップから復元しても、バックアップ以降に発生したクラスタの持続的な状態の変更は失われますが、頻繁にバックアップすれば、情報喪失の可能性を最小限に抑えることができます。バックアップ操作と復元操作には、時間の経過とともに増大していく可能性がある設定変更レコード内の変更履歴を、圧縮して最適化するという肯定的な効果もあります。

設定変更レコードをバックアップする

imqbrokerd コマンドの -backup オプションを使用し、バックアップファイルの名前を指定します。たとえば、次のように指定します。

imqbrokerd -backup mybackuplog

設定変更レコードを復元する

1. クラスタにあるすべてのブローカをシャットダウンします。

2. 次のコマンドを使用し、マスターブローカの設定変更レコードをバックアップファイルから復元します。

   imqbrokerd -restore mybackuplog

3. 新しい名前やポート番号をマスターブローカに割り当てる場合は、クラスタ設定ファイルの imq.cluster.brokerlist プロパティーと imq.cluster.masterbroker プロパティーをそれぞれ更新します。

4. クラスタにあるすべてのブローカを再起動します。

マスターブローカを使用できない場合

クラスタのすべてのブローカでは、持続的な操作を実行するためにマスターブローカが必要になるので、マスターブローカを使用できない場合、クラスタのすべてのブローカでは次の imqcmd サブコマンドがエラーになります。

• create dst

• destroy dst

• update dst

• destroy dur

自動作成の物理的送信先および一時的送信先は影響されません。

マスターブローカがない場合、永続サブスクライバを作成したり、永続サブスクリプションから登録解除しようとするすべてのクライアントアプリケーションではエラーが発生します。ただしクライアントは、既存の永続サブスクリプションを指定したり、既存の永続サブスクリプションとやり取りしたりすることはできます。

第 10 章 ブローカの監視

この章では、ブローカの監視に使用できるツール、およびメトリックスデータの取得方法について説明します。この章では、次の節について説明します。

• 「監視ツールの概要」

• 「ブローカロギングの設定と使用」

• 「メトリックスの対話型表示」

• 「ブローカを監視するアプリケーションの作成」

特定メトリックスの詳細については、第 18 章「メトリックスのリファレンス」を参照してください。

監視ツールの概要

Message Queue^TM 情報の監視インタフェースには、ログファイル、対話型コマンド、メトリックスを取得できるクライアント API の 3 つがあります。それぞれのツールには、次のような長所と短所があります。

• ログファイルでは、メトリックスデータの長期間の記録が提供されますが、簡単には解析できません。

• コマンドでは、ニーズに合った情報を迅速にサンプル抽出できますが、履歴情報を調べたり、プログラムでデータを操作したりすることはできません。

• クライアント API では、情報の抽出、処理、データの操作、グラフ表示、警告の送信を行うことができます。ただし、クライアント API を使用するには、カスタムアプリケーションを作成して、データの取得と分析を行う必要があります。

表 10–1 は、さまざまなツールの比較です。

この表に掲載されている違いに加えて、それぞれのツールでは、ブローカによって生成されたメトリックス情報の、多少異なるサブセットが収集されます。どの監視ツールがどのメトリックスデータを収集するかについては、第 18 章「メトリックスのリファレンス」を参照してください。

ブローカロギングの設定と使用

Message Queue ロガーでは、ブローカコード、デバッガ、メトリックスジェネレータによって生成された情報が取得され、その情報が、標準出力 (コンソール)、ログファイル、Solaris™ オペレーティングシステムの syslog デーモンプロセスなど、多くの出力チャネルに書き込まれます。

ロガーが収集する情報のタイプと、各出力チャネルに書き込む情報のタイプを指定できます。特に、メトリックス情報のログファイルへの書き込みを指定できます。

この節では、ブローカのデフォルトロギング設定、代替出力チャネルにログ情報をリダイレクトする方法、ログファイルロールオーバー基準の変更方法、メトリックスデータをログファイルに送信する方法について説明します。

デフォルトのロギングの設定

ブローカは、ローリングログファイルのセットにログ出力を保存するように自動的に設定されます。ログファイルは、関連付けられたブローカのインスタンス名によって識別されるディレクトリに配置されます (付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照)。

…/instances/instanceName/log

ライフサイクルがアプリケーションサーバーによって制御されるブローカでは、ログファイルはブローカが起動されたドメインのドメインディレクトリのサブディレクトリに配置されます。

…/appServer_domainName_dir/imq/instances/imqbroker/log

ログファイルは、簡単なテキストファイルです。ログファイルは、次のように順番に名前が付けられています。

log.txt
log_1.txt
log_2.txt
…log_9.txt

デフォルトでは、ログファイルは週に 1 回ロールオーバーされ、システムは 9 つのバックアップファイルを保持します。

• ログファイルが保管されるディレクトリを変更するには、imq.log.file.dirpath プロパティーを希望するパスに設定します。

• ログファイルのルート名を log から別の名前に変更するには、imq.log.file.filename プロパティーを設定します。

ブローカでは、ERROR、WARNING 、INFO という、3 つのログレベルがサポートされます。表 10–2 では、それぞれのレベルについて説明します。

ロギングレベルを設定すると、そのレベル以上のメッセージが収集されます。デフォルトのログレベルは INFO なので、ERROR メッセージ、WARNING メッセージ、INFO メッセージはすべてデフォルトで記録されます。

ログメッセージの書式設定

ログメッセージは、タイムスタンプ、メッセージコード、メッセージ自体から構成されます。情報量は、設定したログレベルにより異なります。INFO メッセージの例を次に示します。

[13/Sep/2000:16:13:36 PDT] [B1004]: Starting the broker service using tcp 
[25374,100] with min threads 50 and max threads of 500

タイムスタンプのタイムゾーンを変更するには、表 14–8 に示す imq.log.timezone プロパティーに関する情報を参照してください。

ロガー設定の変更

ログ関連のプロパティーについては、表 14–8 を参照してください。

ブローカのロガー設定を変更する

1. ログレベルを設定します。

2. 1 つまたはそれ以上のロギングカテゴリの出力チャネル (ファイル、コンソール、またはその両方) を設定します。

3. 出力をファイルに記録する場合、ファイルのロールオーバー基準を設定します。

   ロガープロパティーを設定すると、手順は完了します。ロガープロパティーの設定は、次のどちらかの方法で行います。

   • ブローカを起動する前に、ブローカの config.properties ファイルでロガープロパティーを変更または追加します。

   • ブローカを起動する imqbrokerd コマンドでロガーコマンド行オプションを指定します。また、オプション -D を使用して、ロガープロパティーまたは 任意のブローカプロパティーを変更できます。

   コマンド行で渡されたオプションは、ブローカインスタンス設定ファイルで指定されたプロパティーを上書きします。次の imqbrokerd オプションは、ロギングに影響します。

   -metrics interval

   ブローカメトリックスのロギング間隔 (秒単位)

   -loglevel level

   ロギングレベル (ERROR、WARNING、 INFO、または NONE)

   -silent

   サイレントモード (ロギングはコンソールに表示されない)

   -tty

   コンソールにすべてのメッセージをログ出力します

   続いて、デフォルトの設定を変更して、次のことを実行する方法を説明します。

   • ログメッセージの送信先である、出力チャネルの変更

   • ロールオーバー基準の変更

出力チャネルの変更

デフォルトでは、エラーメッセージと警告メッセージは、ログファイルに記録されると同時に、端末に表示されます。Solaris では、エラーメッセージはシステムの syslog デーモンにも書き込まれます。

次の方法で、ログメッセージの出力チャネルを変更できます。

• 指定したレベルのすべてのログカテゴリを画面に表示するには、imqbrokerd コマンドの -tty オプションを使用します。

• ログ出力を画面に表示しないようにするには、imqbrokerd コマンドの -silent オプションを使用します。

• imq.log.file.output プロパティーを使用して、ログファイルに書き込むロギング情報のカテゴリを指定します。たとえば、次のように指定します。

  imq.log.file.output=ERROR

• imq.log.console.output プロパティーを使用して、コンソールに書き込むロギング情報のカテゴリを指定します。たとえば、次のように指定します。

  imq.log.console.output=INFO

• Solaris の場合、imq.log.syslog.output プロパティーを使用して、Solaris syslog に書き込むロギング情報のカテゴリを指定します。たとえば、次のように指定します。

  imq.log.syslog.output=NONE

ロガー出力チャネルを変更する前に、出力チャネルにマッピングされた情報をサポートするレベルにロギングが設定されていることを確認する必要があります。たとえば、ログレベルを ERROR に設定し、imq.log.console.output プロパティーを WARNING に設定すると、WARNING メッセージのロギングが有効になっていないため、どのメッセージも記録されません。

ログファイルのロールオーバー基準の変更

ログファイルのロールオーバーには、時間とサイズの 2 つの基準があります。デフォルトでは時間の基準が使用され、7 日ごとにファイルがロールオーバーされます。

• 時間の間隔を変更するには、imq.log.file.rolloversecs プロパティーを変更する必要があります。たとえば、次のようにプロパティーを定義すると、間隔が 10 日に変更されます。

  imq.log.file.rolloversecs=864000

• ファイルサイズに従ってロールオーバーするように基準を変更するには、imq.log.file.rolloverbytes プロパティーを設定する必要があります。たとえば、次のように定義すると、500,000 バイトの制限に達したあと、ブローカはファイルをロールオーバーするように指示されます。

  imq.log.file.rolloverbytes=500000

時間に関連するロールオーバープロパティーとサイズに関連するロールオーバープロパティーの両方が設定されている場合は、どちらかの制限に最初に達したときにロールオーバーが実行されます。前の節でも説明したように、ブローカでは 9 つのロールオーバーファイルが保持されます。

ログファイルのロールオーバープロパティーの設定や変更は、ブローカの動作時に実行できます。このプロパティーを設定するには、imqcmd update bkr コマンドを使用します。

ログファイルへのメトリックスデータの送信

この節では、ブローカログファイルを使用してメトリックス情報を報告するための手順を説明します。ロガーの設定方法については、「ブローカロギングの設定と使用」を参照してください。

ログファイルを使用してメトリックス情報を報告する

1. ブローカのメトリックス生成機能を設定します。

   1. imq.metrics.enabled=true に設定されていることを確認します。

      デフォルトでは、ロギング用のメトリックスの生成は有効になっています。

   2. メトリックスの生成間隔を適切な秒数に設定します。

      imq.metrics.interval=interval

      この値は、config.properties ファイル内で設定するか、またはブローカの起動時に -metrics interval コマンド行オプションを使用して設定できます。

2. ロガーがメトリックス情報を収集していることを確認します。

   imq.log.level=INFO

   これはデフォルト値です。この値は、config.properties ファイル内で設定するか、またはブローカの起動時に -loglevel level コマンド行オプションを使用して設定できます。

3. ロガーが、メトリックス情報をログファイルへ書き込むように設定されていることを確認します。

   imq.log.file.output=INFO

   これはデフォルト値です。config.properties ファイル内で設定できます。

4. ブローカを起動します。

   ログファイルに出力されたブローカメトリックスの例を次に示します。

   [21/Jul/2004:11:21:18 PDT] Connections: 0 JVM Heap: 8323072 bytes (7226576 free) Threads: 0 (14-1010) In: 0 msgs (0bytes) 0 pkts (0 bytes) Out: 0 msgs (0bytes) 0 pkts (0 bytes) Rate In: 0 msgs/sec (0 bytes/sec) 0 pkts/sec (0 bytes/sec) Rate Out: 0 msgs/sec (0 bytes/sec) 0 pkts/sec (0 bytes/sec)

   メトリックスデータの詳細については、第 18 章「メトリックスのリファレンス」を参照してください。

デッドメッセージのロギング

ブローカのデッドメッセージロギングを有効にすると、物理的送信先を監視できます。デッドメッセージキューを使用しているかどうかに関係なく、デッドメッセージを記録できます。

デッドメッセージロギングを有効にすると、次のタイプのイベントが、ブローカによって記録されます。

• 物理的送信先が最大サイズを超えた。

• 次のような理由により、ブローカが物理的送信先からメッセージを削除した。

  • 送信先サイズが制限に達した。

  • メッセージの生存時間が満了した。

  • メッセージが長すぎる。

  • ブローカがメッセージを処理しようとしたときにエラーが発生した。

デッドメッセージキューを使用している場合、ロギングには次のタイプのイベントも含まれます。

• ブローカがデッドメッセージキューにメッセージを移動した。

• ブローカがデッドメッセージキューからメッセージを削除して破棄した。

デッドメッセージのログ形式の例を次に示します。

[29/Mar/2006:15:35:39 PST] [B1147]: Message 8-129.145.180.87(e7:6b:dd:5d:98:aa)-
35251-1143675279400 from destination Q:q0 has been placed on the DMQ because 
[B0053]: Message on destination Q:q0 Expired: expiration time 1143675279402, 
arrival time 1143675279401, JMSTimestamp 1143675279400

デッドメッセージのロギングは、デフォルトでは無効になっています。有効にするには、ブローカ属性 imq.destination.logDeadMsgs を設定します。

メトリックスの対話型表示

Message Queue ブローカでは、次のタイプのメトリックスが報告されます。

• Java 仮想マシン (JVM) メトリックス: JVM ヒープサイズに関する情報です。

• ブローカ全体のメトリックス: ブローカに保存されているメッセージ、ブローカで入出力されるメッセージ、メモリー使用に関する情報です。メッセージは、メッセージ数とバイト数の点で追跡されます。

• 接続サービスのメトリックス: 接続と接続スレッドのリソースに関する情報、および特定の接続サービスのメッセージフローに関する情報です。

• 送信先メトリックス: 特定の物理的送信先との間のメッセージフロー、物理的送信先のコンシューマ、メモリーとディスクスペースの使用率に関する情報です。

imqcmd コマンドでは、ブローカ全体、それぞれの接続サービス、それぞれの物理的送信先のメトリックス情報を取得できます。メトリックスデータを取得するには、一般に、imqcmd の metrics サブコマンドを使用します。メトリックスデータは、指定した間隔で、または指定した回数だけ、コンソール画面に表示されます。

query サブコマンドを使用し、設定情報も含む、同様のデータを表示することもできます。詳細については、「imqcmd query」を参照してください。

imqcmd metrics

imqcmd metrics の構文とオプションを、それぞれ表 10–3 と表 10–4 に示します。

metrics bkr
   [-b hostName:portNumber]
   [-m metricType]
   [-int interval]
   [-msp numSamples]

metrics svc -n serviceName
   [-b hostName:portNumber]
   [-m metricType]
   [-int interval]
   [-msp numSamples]

metrics dst -t destType
   -n destName
   [-b hostName:portNumber]
   [-m metricType]
   [-int interval]
   [-msp numSamples]

-b hostName: portNumber

-int interval

-m metricType

-msp numSamples

-n destName

-n serviceName

-t destType

metrics サブコマンドを使用したメトリックスデータの表示

この節では、metrics サブコマンドを使用してメトリックス情報を報告するための手順を説明します。

metrics サブコマンドを使用する

1. メトリックス情報が必要なブローカを起動します。

   「ブローカの起動」を参照してください。

2. 表 10–3 と表 10–4 に示すオプションを指定して、適切な imqcmd metrics サブコマンドを実行します。

メトリックスの出力: imqcmd metrics

この節には、imqcmd metrics サブコマンドの出力例が含まれています。この例では、ブローカ全体のメトリックス、接続サービスのメトリックス、物理的送信先のメトリックスが示されています。

ブローカ全体のメトリックス

ブローカとの間のメッセージとパケットのフローレートを 10 秒間隔で取得するには、metrics bkr サブコマンドを使用します。

imqcmd metrics bkr -m rts -int 10 -u admin

このコマンドは、次のような出力を生成します (表 18–2 のデータの説明を参照)。

--------------------------------------------------------
 Msgs/sec   Msg Bytes/sec   Pkts/sec    Pkt Bytes/sec   
 In   Out     In      Out     In   Out     In      Out  
--------------------------------------------------------
 0     0      27      56      0     0      38      66   
 10    0     7365     56      10    10    7457    1132  
 0     0      27      56      0     0      38      73   
 0     10     27     7402     10    20    1400    8459  
 0     0      27      56      0     0      38      73   

接続サービスのメトリックス

jms 接続サービスが処理したメッセージとパケットの累計を取得するには、metrics svc サブコマンドを使用します。

imqcmd metrics svc -n jms -m ttl -u admin

このコマンドは、次のような出力を生成します (表 18–3) のデータの説明を参照)。

-------------------------------------------------
  Msgs      Msg Bytes      Pkts      Pkt Bytes     
In   Out    In     Out   In   Out    In     Out  
-------------------------------------------------
164  100  120704  73600  282  383  135967  102127
657  100  483552  73600  775  876  498815  149948

物理的送信先のメトリックス

物理的送信先に関するメトリックス情報を表示するには、metrics dst サブコマンドを使用します。

imqcmd metrics dst -t q -n XQueue -m ttl -u admin

このコマンドは、次のような出力を生成します (表 18–4 のデータの説明を参照)。

-----------------------------------------------------------------------------
  Msgs      Msg Bytes         Msg Count         Total Msg Bytes (k)     Largest
In   Out    In     Out    Current  Peak  Avg  Current  Peak     Avg    Msg (k)
-----------------------------------------------------------------------------
200  200  147200  147200     0     200    0      0      143      71        0  
300  200  220800  147200    100    200   10     71      143      64        0  
300  300  220800  220800     0     200    0      0      143      59        0  

物理的送信先のコンシューマに関する情報を取得するには、次の metrics dst サブコマンドを使用します。

imqcmd metrics dst -t q -n SimpleQueue -m con -u admin

このコマンドは、次のような出力を生成します (表 18–4 のデータの説明を参照)。

------------------------------------------------------------------
  Active Consumers         Backup Consumers         Msg Count
Current  Peak  Avg      Current  Peak    Avg    Current  Peak  Avg
------------------------------------------------------------------
   1       1      0        0       0      0       944    1000  525

imqcmd query

imqcmd query の構文とオプションを、コマンドによって提供されるメトリックスデータの説明とともに表 10–5 に示します。

query bkr
   [-b hostName: portNumber]

query svc -n serviceName
  [-b  hostName:portNumber]

query dst -t destType
  -n destName
  [-b hostName:portNumber]

imqcmd query は限定されたメトリックスデータを提供するため、このツールは、第 18 章「メトリックスのリファレンス」の表には記載されていません。

ブローカを監視するアプリケーションの作成

Message Queue には、ブローカがメトリックスデータを JMS メッセージへ書き込み、そのメッセージに含まれるメトリックス情報のタイプに応じて、そのメッセージを多数のメトリックストピック送信先のどれかに送信する際に使用できるメトリックス監視機能が用意されています。

メトリックストピックを送信先へサブスクライブし、これらの送信先のメッセージを消費し、メッセージに含まれるメトリックス情報を処理するクライアントアプリケーションをプログラミングすることで、このメトリックス情報にアクセスできます。

5 つのメトリックストピック送信先があります。それらの名前と、各送信先へ配信されるメトリックスメッセージのタイプを表 10–6 に示します。

メッセージベースの監視の設定

この節では、メッセージベースの監視機能を使用してメトリックス情報を収集するための手順を説明します。手順には、クライアント開発タスクと管理タスクの両方が含まれます。

メッセージベースの監視を設定する

1. メトリックス監視クライアントを作成します。

   メトリックストピック送信先へサブスクライブし、メトリックスメッセージを消費し、これらのメッセージからメトリックスデータを抽出するクライアントをプログラミングする手順については、『Message Queue Developer's Guide for Java Clients 』を参照してください。

2. config.properties ファイルにブローカプロパティー値を設定して、ブローカのメトリックスメッセージプロデューサを設定します。

   1. メトリックスメッセージの生成を有効にします。

      imq.metrics.topic.enabled=true と設定します。

      デフォルト値は true です。

   2. メトリックスメッセージを生成する間隔を、秒単位で指定します。

      imq.metrics.topic.interval=interval と設定します。

      デフォルトは 60 秒です。

   3. メトリックスメッセージを持続的にするかどうか、つまり、ブローカ障害時にもそのまま保持するかどうかを指定します。

      imq.metrics.topic.persist を設定します。

      デフォルト値は false です。

   4. 各送信先で、メトリックスメッセージを削除するまでに保持しておく期間を指定します。

      imq.metrics.topic.timetolive を設定します。

      デフォルト値は 300 秒です。

3. メトリックストピック送信先に必要なアクセス制御を設定します。

   設定については次の 「セキュリティーとアクセスで考慮すること」を参照してください。

4. メトリックス監視クライアントを起動します。

   コンシューマがメトリックストピックをサブスクライブすると、メトリックストピック送信先が自動的に作成されます。メトリックストピックが作成されると、ブローカのメトリックスメッセージプロデューサがメトリックスメッセージをメトリックストピックへ送信し始めます。

セキュリティーとアクセスで考慮すること

メトリックストピック送信先へのアクセスを制限する理由は 2 つあります。

• メトリックスデータにブローカとそのリソースに関する機密情報が含まれることがある。

• メトリックストピック送信先へのサブスクリプション数が過剰になると、ブローカのオーバーヘッドが増加し、パフォーマンスに悪影響を及ぼすことがある。

これらの点を考慮して、メトリックストピック送信先へのアクセスは制御することをお勧めします。

監視クライアントは、そのほかのクライアントと同じ認証制御と権限を前提にしています。ブローカへの接続が許可されるのは、Message Queue ユーザーリポジトリに登録されているユーザーだけです。

「ユーザー承認: アクセス制御プロパティーファイル」に説明されているとおり、アクセス制御プロパティーファイルを使用して特定のメトリックストピック送信先へのアクセスを制限することで、さらに保護を強化できます。

たとえば、accesscontrol.properties ファイル内の次のエントリは、user1 と user2 を除き、すべてのユーザーについて mq.metrics.broker メトリックストピックへのアクセスを拒否します。

topic.mq.metrics.broker.consume.deny.user=*
topic.mq.metrics.broker.consume.allow.user=user1,user2

次のエントリは、ユーザー user3 だけにトピック t1 の監視を許可します。

topic.mq.metrics.destination.topic.t1.consume.deny.user=*
topic.mq.metrics.destination.topic.t1.consume.allow.user=user3

メトリックスデータの機密性に応じて、暗号化された接続を使用してメトリックス監視クライアントをブローカへ接続することもできます。暗号化された接続の使用方法については、「メッセージの暗号化」を参照してください。

メトリックスの出力: メトリックスメッセージ

メッセージベースの監視 API を使用して取得したメトリックスデータ出力は、プログラミングしたメトリックス監視クライアントによって異なります。出力されるデータは、ブローカ内のメトリックスジェネレータによって提供されるデータだけに限定されます。このデータの完全なリストは、第 18 章「メトリックスのリファレンス」を参照してください。

第 11 章 メッセージサービスの分析と調整

この章では、Message Queue^TM サービスの分析と調整を行い、メッセージングアプリケーションのパフォーマンスを最適化する方法に関連するさまざまなトピックを取り上げます。次のトピックが含まれます。

• 「パフォーマンス関連」

• 「パフォーマンスに影響する要因」

• 「パフォーマンスを改善するための設定の調整」

パフォーマンス関連

この節では、パフォーマンス調整の背景について説明します。

パフォーマンス調整プロセス

メッセージングアプリケーションのパフォーマンスは、アプリケーションと Message Queue サービスの相互関係に左右されます。そのため、パフォーマンスを最大化するには、アプリケーション開発者と管理者が協力し合う必要があります。

パフォーマンスを最適化するプロセスは、アプリケーションの設計から始まります。アプリケーションが配備されたあとも、継続してメッセージサービスの調整を行います。パフォーマンス調整プロセスには、次の段階があります。

• アプリケーションのパフォーマンス要件を定義します。

• 特に信頼性とパフォーマンスの兼ね合いなど、パフォーマンスに影響する要因を考慮してアプリケーションを設計します。

• パフォーマンスの基準を設けます。

• パフォーマンスを最適化するためにメッセージサービスを調整または再設定します。

通常は、上記に概略したプロセスを繰り返し実行します。アプリケーションの配備時に、Message Queue 管理者は、メッセージサービスの適合性を評価し、アプリケーションの全般的なパフォーマンス要件を満たしているかどうかを判断します。ベンチマークテストがこれらの要件を満たす場合は、この章で説明するとおり、管理者はシステムの調整段階に入ることができます。一方、ベンチマークテストがパフォーマンス要件を満たしていない場合は、アプリケーションの再設計や配備アーキテクチャーの変更が必要となる場合があります。

パフォーマンスのさまざまな側面

一般に、パフォーマンスの基準は、メッセージサービスがプロデューサからコンシューマへメッセージを配信するときの速度と効率です。ただし、パフォーマンスには、ニーズに応じて重要度が変わるさまざまな側面があります。

接続の負荷:

メッセージプロデューサまたはメッセージコンシューマの数、もしくは、システムがサポート可能な同時接続の数です。

メッセージのスループット:

メッセージングシステムが 1 秒間に扱えるメッセージ数、またはメッセージのバイト数です。

遅延:

特定のメッセージがメッセージプロデューサからメッセージコンシューマへ配信されるまでに要する時間です。

安定性:

メッセージサービス全体の可用性、つまり過負荷や障害による影響をどれだけ抑えられるかです。

効率:

メッセージ配信の効率。使用するコンピュータリソースに関係する、メッセージスループットの評価です。

パフォーマンスのこれらの異なる評価基準は、一般に相互に関連しています。メッセージスループットが高い場合、メッセージがブローカへバックログされることは、ほとんどありません。その結果、遅延も短くなり、シングルメッセージはすぐに配信されます。ただし、遅延はさまざまな要因に左右されます。そのような要因の例としては、通信リンクの速度、ブローカの処理速度、クライアントの処理速度などがあります。

どのような場合でも、パフォーマンスには複数の異なる側面があります。一般に、その中でどれがもっとも重要となるかは、特定のアプリケーションの要件によって決まります。

ベンチマーク

ベンチマークとは、使用中のメッセージングアプリケーション用のテスト群を作成し、このテスト群を用いてメッセージスループットや、そのほかの観点からパフォーマンスを評価するプロセスです。

たとえば、複数のプロデューシングクライアントを対象に、複数の、接続、セッション、メッセージプロデューサを使用し、標準サイズの持続メッセージまたは持続性のないメッセージを一部のキューやトピック (すべてメッセージングアプリケーションの設計に依存) へ一定レートで送信するテスト群を作成できます。同様に、特定の通知モードでテスト群の物理的送信先においてメッセージを消費する複数の接続、セッション、および特定タイプのメッセージコンシューマを使用し、複数のコンシューミングクライアントをテスト群に含められます。

標準のテスト群を使用することで、メッセージが生成されてから消費されるまでに要する時間やメッセージの平均スループットレートを測定したり、システムを監視して、接続スレッド使用率、メッセージストレージデータ、メッセージフローデータ、そのほかの関連するメトリックスを監視したりできます。その後、パフォーマンスに悪影響が出る上限まで、メッセージの生成レート、メッセージプロデューサの数、その他の変数を増加させることができます。実現可能な最大スループットが、メッセージサービス設定のベンチマークになります。

このベンチマークを基に、テスト群の特性の一部を変更できます。パフォーマンスに影響しそうな要因すべてを慎重に制御すれば (「パフォーマンスに影響するアプリケーション設計の要因」を参照)、これらの要因の変化によるベンチマークへの影響を理解できます。たとえば、接続数またはメッセージ数を 5 倍もしくは 10 倍に増やし、パフォーマンスに与える影響を調べることができます。

逆に、アプリケーションベースの要因を一定に保ち、たとえば、接続プロパティー、スレッドプールプロパティー、JVM メモリー制限、制限の動作、ファイルベースの持続と JDBC ベースの持続などを変更するといった、制御方法でブローカ設定を変更して、これらの変更がパフォーマンスに及ぼす影響を判断することもできます。

アプリケーションのこのようなベンチマークから、メッセージサービスを調整して配置済みのアプリケーションのパフォーマンスを向上させたいときに有用な情報を得られます。ベンチマークによって、1 か所の変更や一連の変更による影響を正確に予測できます。

原則として、ベンチマークは、管理されたテスト環境で、メッセージサービスを安定させるため長期間実施する必要があります。Java コードをマシンコードに変換する JIT コンパイルによる起動時には、パフォーマンスに悪影響が及びます。

基準になる使用パターン

メッセージングアプリケーションが配置され稼働されたあとは、基準になる使用パターンを確立することが重要となります。要求のピークがいつ発生するか把握し、その要求の定量化を図ります。たとえば、通常、要求はエンドユーザー数、アクティビティーレベル、時間帯、またはこれらすべてによって左右されます。

基準になる使用パターンを確立するには、メッセージサービスを一定期間監視して、次のようなデータを調べる必要があります。

• 接続数

• ブローカ、または特定の物理的送信先に保存されたメッセージ数

• ブローカ、または特定の物理的送信先で送受信されるメッセージフロー

• アクティブコンシューマの数

また、メトリックスデータにより提供される平均値とピーク値を使用することもできます。

これらの基準になるメトリックスを設計時の期待値と比較することが重要です。それによって、クライアントコードが正常に動作していることを確認します。たとえば、接続が開いたままになっていないか、または、消費されたメッセージが未通知のままになっていないかを確認できます。これらのコーディングエラーはブローカのリソースを消費し、パフォーマンスに大きな影響を及ぼします。

基準になる使用パターンは、最適なパフォーマンスを得るためにシステムを調整する方法を決定する上で役立ちます。たとえば、次のように指定します。

• 1 つの物理的送信先がそのほかの物理的送信先に比べ頻繁に使用されている場合は、その物理的送信先のメッセージメモリー制限をそのほかの送信先より高く設定したり、使用率に応じて制限の動作を調整したりできます。

• 必要な接続数が最大スレッドプールサイズによる許容値を大きく上回る場合は、スレッドプールサイズを増やすか、共有スレッドモデルを採用することができます。

• ピーク時のメッセージフローが平均フローより多い場合は、メモリーが不足したときに使用する制限の動作に影響することがあります。

一般に、使用パターンをより綿密に理解しているほど、より適切に、使用パターンに応じてシステムを調整し、将来ニーズに合わせてプランニングすることができます。

パフォーマンスに影響する要因

メッセージの遅延とメッセージのスループットは、2 つの主要なパフォーマンスの評価基準です。これらは一般に、標準的なメッセージがメッセージ配信プロセスの各手順を完了するまでに要する時間に依存します。メッセージを持続的で信頼できる方法で配信する場合の各手順は次のとおりです。各手順を以下で図示します。

図 11–1 Message Queue サービスを使用したメッセージの配信

メッセージ配信の手順

1. メッセージはプロデューシングクライアントからブローカへ配信されます。

2. ブローカはメッセージの内容を読み取ります。

3. メッセージは、信頼性を維持するために持続ストレージに配置されます。

4. ブローカは、信頼性を維持するためにメッセージの受信確認を発行します。

5. ブローカは、メッセージのルーティングを決定します。

6. ブローカはメッセージを書き込みます。

7. メッセージはブローカからコンシューミングクライアントへ配信されます。

8. コンシューミングクライアントは、信頼性を維持するためにメッセージの受信確認を発行します。

9. ブローカは、信頼性を維持するために、クライアントの通知を処理します。

10. ブローカは、クライアントの通知が処理されたことを通知します。

    これらの手順は順次実行されるため、プロデューシングクライアントからコンシューミングクライアントへメッセージを配信する際には、どの手順もボトルネックとなる恐れがあります。これらの手順の大半は、メッセージングシステムの物理的な特性に依存しています。物理的な特性には、ネットワーク帯域幅、コンピュータの処理速度、メッセージサービスのアーキテクチャーなどが含まれます。ただし、一部の手順は、メッセージングアプリケーションの特性と必要とされる信頼性のレベルにも依存しています。

    次の節では、アプリケーション設計の要因とメッセージングシステムの要因の両方がパフォーマンスに及ぼす影響について説明します。アプリケーション設計の要因とメッセージングシステムの要因はメッセージの配信に密接に関係しますが、各カテゴリは個別に考慮します。

パフォーマンスに影響するアプリケーション設計の要因

アプリケーション設計の決定は、メッセージングのパフォーマンス全体に大きく影響することがあります。

パフォーマンスに影響するもっとも重要な要因は、メッセージ配信の信頼性に影響を及ぼす要因です。これには、次のものがあります。

• 「配信モード (持続的/持続性のないメッセージ)」

• 「トランザクションの使用」

• 「通知モード」

• 「永続サブスクリプションと永続的でないサブスクリプション」

そのほかに、パフォーマンスに影響するアプリケーション設計の要因には、次のものがあります。

• 「セレクタの使用 (メッセージのフィルタリング)」

• 「メッセージのサイズ」

• 「メッセージ本文のタイプ」

以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。原則として、パフォーマンスと信頼性は相反しています。つまり、信頼性が高くなるとパフォーマンスは低下します。

表 11–1 は、さまざまなアプリケーション設計の要因が一般にどのようにメッセージングパフォーマンスに影響するかを示しています。表には、信頼性が高くパフォーマンスが低いシナリオと、パフォーマンスが高く信頼性の低いシナリオの 2 つのシナリオと、それぞれを特徴付ける主要なアプリケーション設計の要因を示します。これらの極端なシナリオの間には、信頼性とパフォーマンスの両方に影響する、多数の選択肢と兼ね合いがあります。

配信モード (持続的/持続性のないメッセージ)

持続メッセージはブローカの障害時にもメッセージの配信を保証します。すべての対象のコンシューマが、メッセージを消費したことを通知するまで、ブローカはメッセージを持続ストアに格納します。

持続メッセージのブローカの処理速度は、次の理由から、持続性のないメッセージの場合より低速です。

• ブローカに障害が生じても持続メッセージが失われないように、ブローカは信頼できる方法で持続メッセージを格納する必要があります。

• ブローカは受信した持続メッセージごとに、受信確認をする必要があります。メッセージを生成するメソッドが例外を返さなければ、ブローカへの配信は保証されます。

• クライアントの通知モードによっては、クライアントからの持続メッセージの受信通知が消費されたことを、ブローカが確認しなければならない場合があります。

キューへ配信した場合と、永続サブスクライバを使用しているトピックへ配信した場合の両方で、パフォーマンスは、持続性のないメッセージが 40% 上回りました。これらは、10K バイトのメッセージと AUTO_ACKNOWLEDGE モードを使用した場合の結果です。

トランザクションの使用

トランザクションとは、処理済みセッションで生成されたすべてのメッセージと処理済みセッションで消費されたすべてのメッセージが、一体として処理されるか、または一体として処理されない、つまりロールバックされることを保証するものです。

Message Queue では、ローカルと分散の両方のトランザクションがサポートされます。

処理済みセッションでのメッセージの生成または通知の処理速度は、次の理由から、処理済みでないセッションの場合より低速です。

• 生成されたメッセージごとに追加情報を格納する必要があります。

• 状況によっては、通常は格納されないトランザクション内のメッセージを格納する場合があります。たとえば、サブスクリプションを使用しないトピック送信先へ配信された持続メッセージは、通常削除されますが、トランザクションの開始時にサブスクリプションに関する情報が使用できなくなります。

• トランザクションでのメッセージの消費と通知に関する情報は、トランザクションがコミットされた時点で格納し処理する必要があります。

通知モード

JMS メッセージの配信の信頼性を保証する手段の 1 つは、Message Queue ブローカによってクライアントへ配信されたメッセージの消費をクライアントに通知するという方法です。

クライアントがメッセージを通知することなくセッションが閉じられた場合や、通知が処理される前にブローカに障害が生じた場合には、ブローカはメッセージを再配信して JMSRedelivered フラグをセットします。

処理済みでないセッションの場合、クライアントは、それぞれ固有のパフォーマンス特性をもつ 3 つの通知モードの中から 1 つを選択できます。

• AUTO_ACKNOWLEDGE。コンシューマがメッセージを処理したあと、システムは自動的にメッセージを通知します。このモードでは、プロバイダで障害が生じたあとは、多くても 1 つのメッセージの再配信を保証するだけです。

• CLIENT_ACKNOWLEDGE。アプリケーションは、メッセージが通知されるポイントを制御します。直前の通知以降にそのセッションで処理されたすべてのメッセージが通知されます。一連の通知の処理中にブローカに障害が生じた場合は、そのグループ内の複数のメッセージが再配信されることがあります。

• DUPS_OK_ACKNOWLEDGE。このモードは、時間をかけてメッセージを通知するようにシステムに指示します。プロバイダに障害が生じたあとでも、複数のメッセージを再配信できます。

CLIENT_ACKNOWLEDGE モードの使い方はトランザクションの使い方に似ています。ただし、処理中にプロバイダに障害が生じた場合に、すべての通知が一括して処理されることを保証していない点を除きます。

次の理由により、通知モードはパフォーマンスに影響します。

• AUTO_ACKNOWLEDGE モードと CLIENT_ACKNOWLEDGE モードでは、ブローカとクライアント間で特別な制御メッセージが必要です。追加の制御メッセージは、処理オーバーヘッドを高め、JMS ペイロードメッセージに干渉して処理遅延を引き起こすことがあります。

• AUTO_ACKNOWLEDGE モードと CLIENT_ACKNOWLEDGE モードでは、ブローカがクライアントの通知を処理したことを確認するまで、クライアントは待機する必要があります。その後、クライアントは追加メッセージを消費できるようになります。このブローカの確認によって、何らかの理由でブローカがこれらのメッセージを再配信しないように保証します。

• Message Queue 持続ストアは、コンシューマが受信したすべての持続メッセージに関する通知情報を使って更新する必要があります。そのため、パフォーマンスは低下します。

永続サブスクリプションと永続的でないサブスクリプション

トピック送信先へのサブスクライバは、永続サブスクリプションをもつものと、永続的でないサブスクリプションをもつものの 2 つのカテゴリに分かれます。

永続サブスクリプションでは、次の理由により、信頼性が高まりますが、スループットが遅くなります。

• Message Queue メッセージサービスは、ブローカに障害が生じた場合でも回復後にリストを使用できるように、各永続サブスクリプションに割り当てられたメッセージのリストを持続的に格納する必要があります。

• ブローカに障害が生じた場合でも、回復後に、対応するコンシューマがアクティブになったときに、メッセージを引き続き配信できるように、永続サブスクリプションの持続メッセージは持続ストアに格納されます。対照的に、永続的でないサブスクリプションの持続メッセージは持続ストアには格納されません。したがって、ブローカに障害が生じると、対応するコンシューマ接続は失われ、メッセージは配信されません。

10K バイトの持続メッセージと持続性のないメッセージの 2 とおりのケースで、永続サブスクライバと永続的でないサブスクライバのパフォーマンスを比較しました。どちらの場合も AUTO_ACKNOWLEDGE 通知モードを使用しています。その結果、持続メッセージの場合にのみパフォーマンスに影響が見られ、永続サブスクライバの方が約 30% 低速でした。

セレクタの使用 (メッセージのフィルタリング)

アプリケーション開発者は、通常、特定のコンシューマへの一連のメッセージを対象にしています。それは、一意の物理的送信先への一連のメッセージごとを対象とするか、単一の物理的送信先を使用しコンシューマごとに複数のセレクタを登録することで実現できます。

セレクタは文字列であり、この文字列に一致するプロパティー値を持ったメッセージだけを特定のコンシューマに配信します。たとえば、セレクタ NumberOfOrders >1 は、NumberOfOrders プロパティー値が 2 以上のメッセージだけを配信します。

セレクタを使用してコンシューマを作成すると、各メッセージを取り扱うために追加処理が必要となり、複数の物理的送信先を使用する場合に比べ、パフォーマンスは低下します。以降のメッセージを比較する際にも構文解析できるセレクタを使用する必要があります。さらに、各メッセージがルーティングされるたびに、各メッセージのメッセージプロパティーを読み取り、比較する必要があります。ただし、セレクタを使用すると、メッセージングアプリケーションの柔軟性が向上します。

メッセージのサイズ

メッセージのサイズはパフォーマンスに影響します。プロデューシングクライアントからブローカへ、さらにブローカからコンシューミングクライアントへは、より多くのデータを渡す必要があり、持続メッセージの場合はサイズの大きいメッセージを格納する必要があるからです。

ただし、複数のサイズの小さいメッセージを 1 つのメッセージにまとめることで、個々のメッセージの転送と処理を最小限に抑え、パフォーマンス全体を向上させることができます。この場合、個々のメッセージの状態に関する情報は失われてしまいます。

AUTO_ACKNOWLEDGE 通知モードを使用して、キュー送信先へ 1K、10K、および 100K バイトのメッセージを送信した場合のスループットを、1 秒あたりの K バイト数で比較したテストにより、持続性のないメッセージングの方が、1K バイトのメッセージで約 50%、10K バイトのメッセージで約 20%、および 100K バイトのメッセージで約 5% 高速であることが分かりました。メッセージのサイズは、持続メッセージと持続性のないメッセージの両方のパフォーマンスに大きく影響します。100K バイトのメッセージは 10K バイトのメッセージよりも 10 倍高速であり、10K バイトのメッセージは 1K バイトのメッセージよりも 5 倍高速です。

メッセージ本文のタイプ

JMS がサポートするメッセージ本文のタイプ 5 種類の概要を複雑な順に次に示します。

• BytesMessage は、一連のバイトデータを含み、形式はアプリケーションによって決まります。

• TextMessage は、単純な Java 文字列です。

• StreamMessage は、Java プリミティブ値によるストリームを含みます。

• MapMessage には、一連の名前と値のペアが含まれます。

• ObjectMessage には、Java のシリアライズされたオブジェクトが含まれます。

一般に、メッセージのタイプはアプリケーションのニーズによって決定され、MapMessage や ObjectMessage などのより複雑なタイプほどパフォーマンスは低下します。データのシリアライズとデシリアライズがパフォーマンスを低下させます。パフォーマンスは、データがどの程度単純か、またはどの程度複雑かによって異なります。

パフォーマンスに影響するメッセージサービスの要因

メッセージングアプリケーションのパフォーマンスは、アプリケーション設計だけでなく、メッセージのルーティングと配信を実行するメッセージサービスによっても影響を受けます。

次の節では、パフォーマンスに影響することのあるさまざまなメッセージサービスの要因について説明します。これらの要因の影響を理解しておくことは、メッセージサービスの内容を変更したり、配置済みのアプリケーションで発生することのあるパフォーマンスボトルネックを診断し解決したりする上で重要となります。

Message Queue サービスのパフォーマンスに影響するもっとも重要な要因は、次のとおりです。

• 「ハードウェア」

• 「オペレーティングシステム」

• 「Java 仮想マシン (JVM)」

• 「接続」

• 「ブローカの制限と動作」

• 「メッセージサービスのアーキテクチャー」

• 「データストアのパフォーマンス」

• 「クライアントランタイムの設定」

以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。

ハードウェア

Message Queue ブローカとクライアントアプリケーションのどちらの場合も、CPU の処理速度と使用可能なメモリーはメッセージサービスのパフォーマンスを決定する主要な要因となります。処理性能を強化して、多数のソフトウェア制限をなくす一方で、メモリーを追加して処理速度と能力を増加させることができます。ただし、一般に、単にハードウェアをアップグレードするだけでボトルネックを解消すると多額の費用がかかります。

オペレーティングシステム

同じハードウェアプラットフォームを前提とした場合でも、異なるオペレーティングシステムの効率によって、パフォーマンスも変わってきます。たとえば、オペレーティングシステムが採用しているスレッドモデルが、ブローカがサポート可能な同時接続数に大きく影響することがあります。一般に、すべてのハードウェアが同じであれば、Solaris は通常 Linux より高速で、Linux は Windows より高速です。

Java 仮想マシン (JVM)

ブローカは、ホスト JVM 内で実行され、ホスト JVM によってサポートされる Java プロセスです。そのため、JVM 処理は、ブローカがメッセージをいかに早く効率良くルーティングし配信できるかを決定する重要な要因となります。

特に、JVM のメモリーリソースの管理が不可欠となる場合があります。増加し続けるメモリーの負荷に対応するには、JVM に十分なメモリーを割り当てる必要があります。さらに、JVM は定期的に未使用のメモリーを再利用します。このメモリー再利用がメッセージの処理を遅らせることがあります。JVM のメモリーヒープが大きくなるほど、メモリー再利用時に経験することのある、潜在する遅延も長くなります。

接続

クライアントとブローカ間の接続の数と速度は、メッセージサービスが処理可能なメッセージ数とメッセージ配信速度に影響することがあります。

ブローカの接続の制限

ブローカへのアクセスはすべて、接続経由で行われます。同時接続数の制限によって、ブローカを同時に使用できるプロデューシングクライアントまたはコンシューミングクライアントの数が左右されることがあります。

ブローカへの接続の数は、一般に、使用可能なスレッド数によって制限されます。Message Queue は、専用スレッドモデルまたは共有スレッドモデルのどちらかをサポートするように設定できます (「スレッドプール管理」を参照)。

専用スレッドモデルは、各接続が専用のスレッドを持つため非常に高速ですが、接続の数は使用可能なスレッド数によって制限されます。この場合、接続ごとに、入力スレッドと出力スレッドが 1 つずつ必要です。共有スレッドモデルには、接続数の制限はありませんが、多数の接続でスレッドを共有するため、オーバーヘッドが増え、スループットが悪化します。これは、多くの接続が使用中のとき特に顕著になります。

トランスポートプロトコル

Message Queue ソフトウェアを使うと、クライアントは各種の低レベルのトランスポートプロトコルを使用してブローカと通信できます。Message Queue は、「接続サービス」で説明されている接続サービスとそれに対応するプロトコルをサポートします。

暗号化、ファイアウォールを介したアクセスなどのプロトコルは、アプリケーション要件に基づいて選択されますが、選択結果はパフォーマンス全体に影響を及ぼします。

図 11–2 トランスポートプロトコルの速度

テストでは、2 つのケースでの TCP と SSL のスループットを比較しました。2 つのケースとは、1K バイトの持続メッセージを、永続サブスクリプションとAUTO_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信する高信頼性シナリオと、1K バイトの持続性のないメッセージを、永続サブスクリプションと DUPS_OK_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信するハイパフォーマンスシナリオです。

通常、高信頼性ケースの方がプロトコルによる影響は少ないことが分かりました。これは、高信頼性のケースで必要な持続メッセージのためのオーバーヘッドの方が、プロトコルの速度より、スループットを制限する重要な要因となるからです。そのほかの特性は次のとおりです。

• TCP は、ブローカと通信する最速の方法を提供します。

• SSL は、メッセージの送信と受信に関しては、TCP より 50 〜 70% 低速です。持続メッセージの場合は 50%、持続性のないメッセージの場合は約 70% です。さらに、初期接続の確立は、SSL を使用した場合の方が低速で数秒かかります。これは、クライアントとブローカ、または HTTPS の場合は Web Server で、送信するデータの暗号化に使う非公開鍵の作成が必要なためです。低レベルの各 TCP パケットの暗号化と復号化に必要な追加処理によって、パフォーマンスの低下が引き起こされます。

• HTTP は、TCP または SSL より低速です。HTTP ではクライアントとブローカ間のプロキシとして、Web サーバー上で実行しているサーブレットを使用します。パケットを HTTP 要求へカプセル化する必要がある点と、メッセージがブローカへ到達するには、クライアントからサーブレットへ、サーブレットからブローカへという 2 つの段階が必要である点から、パフォーマンスへのオーバーヘッドが発生します。

• HTTPS は HTTP より低速です。これは、クライアントとサーブレット間、およびサーブレットとブローカ間でパケットを暗号化するためにオーバーヘッドが必須となるからです。

メッセージサービスのアーキテクチャー

Message Queue メッセージサービスは、シングルブローカ、または複数の連結されたブローカインスタンスで構成されたクラスタとして実装できます。

ブローカに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカは最終的に、ファイル記述子、スレッド、メモリーの制限などのリソースの限界を超えてしまいます。増え続ける負荷に対処するための 1 つの方法は、Message Queue メッセージサービスにブローカインスタンスを追加して、クライアントの接続とメッセージのルーティングおよび配信を複数のブローカに分散することです。

一般に、ブローカインスタンスの追加は、クライアント、特にメッセージプロデューシングクライアントがクラスタ間で均等に分散されている場合に最適に動作します。クラスタ内のブローカ間でのメッセージ配信にはオーバーヘッドが伴うため、接続数とメッセージ配信レートが制限されているクラスタでは、シングルブローカよりパフォーマンスが低くなります。

また、ブローカクラスタを使用してネットワークの帯域幅を最適化することもできます。たとえば、クラスタ内の一連のリモートブローカ間で、速度の遅い、長距離のネットワークリンクを使用する一方で、個々のブローカインスタンスへのクライアントの接続に、高速なリンクを使用することができます。

クラスタの詳細については、第 9 章「ブローカクラスタを使用した作業」を参照してください。

ブローカの制限と動作

メッセージを処理するためにブローカに要求されるメッセージスループットは、ブローカがサポートするメッセージングアプリケーションの使用パターンによって異なります。ただし、ブローカでは、メモリーや CPU サイクルなどのリソースに制限があります。リソースの制限により、ブローカは、過負荷となり、無応答または不安定となるポイントに達してしまうことがあります。

Message Queue メッセージブローカには、メモリーリソースを管理し、ブローカのメモリー不足を防ぐためのメカニズムが組み込まれています。これらのメカニズムに含まれるのは、ブローカまたは個々の物理的送信先が保持できるメッセージ数またはメッセージのバイト数についての設定可能な制限と、物理的送信先の制限に達したときに起動できる一連の動作です。

これらの設定可能なメカニズムを使用して、システムが過負荷にならないように、メッセージの受信と送信のバランスを取ることができますが、これには注意深い監視と調整が必要です。これらのメカニズムは、オーバーヘッドを増加させ、メッセージのスループットを制限することがありますが、それでも動作の完全性を維持します。

データストアのパフォーマンス

Message Queue は、ファイルベースの持続モジュールと JDBC ベースの持続モジュールの両方をサポートしています。ファイルベースの持続モジュールでは、持続データを格納するために個別のファイルを使用します。JDBC ベースの持続では、JDBC™ (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアを必要とします。一般的に、ファイルベースの持続は、JDBC ベースの持続よりも高速です。ただし、JDBC 互換のストアによって提供される冗長性や管理機能を好むユーザーもいます。

ファイルベースの持続の場合は、持続的な操作によりメモリー内の状態とデータストアとを同期化するように指定することで、信頼性を高められます。この同期化は、システム破壊によるデータの損失をなくす上で役立ちますが、パフォーマンスが犠牲になります。

クライアントランタイムの設定

Message Queue クライアントランタイムは、クライアントアプリケーションに Message Queue メッセージサービスへのインタフェースを提供します。クライアントランタイムでは、物理的送信先にメッセージを送信し、物理的送信先からメッセージを受信する場合に、クライアントに必要なすべての処理をサポートします。クライアントランタイムは、接続ファクトリ属性値を使って設定可能で、パフォーマンスとメッセージスループットを向上させるように、接続フロー測定、コンシューマフローの制限、接続フロー制御などのプロパティーと動作を設定できます。これらの機能とそれを設定するために使用される属性の詳細は、「クライアントランタイムのメッセージフローの調整」を参照してください。

パフォーマンスを改善するための設定の調整

次の節では、設定の調整がどのようにパフォーマンスに影響するかを説明します。

システムの調整

次の節では、オペレーティングシステム、JVM、および通信プロトコルで実行できる調整について説明します。

Solaris での調整: CPU 使用率、ページング/スワッピング/ディスク I/O

オペレーティングシステムの調整については、システムのマニュアルを参照してください。

Java 仮想マシン (JVM) の調整

デフォルトでは、ブローカは 192M バイトの JVM ヒープサイズを使用します。通常、大量のメッセージ負荷がある場合はこのサイズでは小さ過ぎるため、大きくする必要があります。

Java オブジェクトが使用する JVM のヒープ容量を使い果たしそうになると、ブローカは、フロー制御やメッセージスワップなどのさまざまな技術を使用して、メモリーを解放します。極端な状況のもとでは、メモリーを解放し、メッセージの流入を減少させるために、クライアント接続を閉じることもあります。このような状況を避けるため、最大 JVM ヒープ容量を十分に高く設定するようお勧めします。

ただし、Java の最大ヒープ容量がシステムの物理メモリーに対して高くしすぎた場合、ブローカは Java ヒープ容量を増加し続け、システム全体のメモリーを使い果たしてしまうことがあります。これは、パフォーマンスの低下、予期しないブローカのクラッシュにつながり、そのシステムで実行されているほかのアプリケーションやサービスの動作にも影響を与える場合があります。一般に、オペレーティングシステムとそのほかのアプリケーションをマシン上で実行させるために十分な物理メモリーを使用させる必要があります。

一般に、通常時とピーク時のシステムメモリーフットプリントを評価して、十分なパフォーマンスを得られて、しかもシステムメモリーに問題を生じさせるほどではない大きさに Java ヒープサイズを設定するのが良い方法です。

ブローカの最小ヒープサイズと最大ヒープサイズを変更するには、ブローカの起動時に -vmargs コマンド行オプションを使用します。たとえば、次のように指定します。

/usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"

このコマンドは、起動時の Java ヒープサイズを 256M バイトに、最大 Java ヒープサイズを 1G バイトに設定します。

• Solaris や Linux では、/etc/rc*、つまり /etc/init.d/imq を介してブローカを起動する場合には、/etc/imq/imqbrokerd.conf (Solaris) ファイルまたは /etc/opt/sun/mq/imqbrokerd.conf (Linux) ファイルにブローカコマンド行引数を指定します。詳細については、そのファイルのコメントを参照してください。

• Windows では、ブローカを Windows のサービスとして起動する場合には、imqsvcadmin install コマンドに -vmargs オプションを使用して JVM 引数を指定します。第 13 章「コマンド行のリファレンス」、「サービス管理ユーティリティー」を参照してください。

どのような場合でも、ブローカのログファイルを確認するか、imqcmd metrics bkr -m cxn コマンドを使用して設定を検証します。

トランスポートプロトコルの調整

アプリケーションのニーズを満たすプロトコルが選択されたら、選択されたプロトコルに基づいて調整を加えることでパフォーマンスを改善できます。

プロトコルのパフォーマンスは、次の 3 つのブローカプロパティーを使用して修正できます。

• imq.protocol.protocolType .nodelay

• imq.protocol.protocolType .inbufsz

• imq.protocol.protocolType .outbufsz

TCP と SSL プロトコルの場合、これらのプロパティーがクライアントとブローカ間のメッセージ配信の速度に影響します。HTTP プロトコルと HTTPS プロトコルの場合は、これらのプロパティーが、Web サーバー上で実行している Message Queue トンネルサーブレットとブローカ間のメッセージ配信の速度に影響します。HTTP/HTTPS プロトコルの場合、そのほかにもパフォーマンスに影響することのあるプロパティーがあります (「HTTP/HTTPS の調整」を参照)。

プロトコルを調整するためのプロパティーについては、次の節で説明します。

nodelay

nodelay プロパティーは、特定のプロトコルの Nagle のアルゴリズム、つまり TCP/IP 上の TCP_NODELAY ソケットレベルのオプションの値に影響します。Nagle のアルゴリズムは、広域ネットワーク (WAN) などの低速接続を使用しているシステム上で TCP パフォーマンスを改善するために使用されます。

このアルゴリズムが使用されている場合、TCP は、データをサイズの大きいパケットにバンドルすることで、複数の小さいデータの塊がリモートシステムへ送信されるのを防ぎます。ソケットに書き込まれたデータが必要なバッファーサイズを満たしていない場合、プロトコルは、バッファーが満たされるか、一定の遅延時間が経過するまで、パケットの送信を遅らせます。バッファーがいっぱいになるか、タイムアウトが発生すると、パケットが送信されます。

大半のメッセージングアプリケーションでは、パケットの送信に遅延がない、つまり Nagle のアルゴリズムが無効な場合にパフォーマンスは最適となります。これは、クライアントとブローカ間の大半の対話が、要求/ 応答型の対話だからです。つまり、クライアントはデータのパケットをブローカへ送信し、その応答を待ちます。たとえば、典型的な対話には次のものがあります。

• 接続の作成

• プロデューサまたはコンシューマの作成

• 持続メッセージの送信。ブローカはメッセージの受信を確認します

• AUTO_ACKNOWLEDGE セッションまたは CLIENT_ACKNOWLEDGE セッションでのクライアント通知の送信。ブローカは通知の処理を確認します

これらの対話では、大半のパケットがバッファーサイズより小さいサイズです。つまり、Nagle のアルゴリズムが使用されている場合は、ブローカは数ミリ秒遅れて、コンシューマに応答を送信します。

ただし、Nagle のアルゴリズムは、接続が低速でブローカの応答が必要ない状況で、パフォーマンスを改善することができます。これは、クライアントが持続性のないメッセージを送信する場合や、クライアント通知がブローカによって確認されない場合 (DUPS_OK_ACKNOWLEDGE セッション) です。

inbufsz/outbufsz

inbufsz プロパティーは、ソケットからのデータを読み取る入力ストリームのバッファーサイズを設定します。同様に、outbufsz は、ブローカがデータをソケットに書き込むために使用する出力ストリームのバッファーサイズを設定します。

一般に、どちらのパラメータも受信パケットまたは送信パケットの平均サイズより多少大きい値に設定する必要があります。経験上、これらのプロパティーはパケットの平均サイズに 1K バイトを足した値 (K バイト単位で四捨五入) に設定すると良いでしょう。たとえば、本文が 1K バイトのパケットをブローカで受信している場合、パケット全体のサイズ (メッセージ本文 + ヘッダー + プロパティー) は約 1200 バイトです。inbufsz を 2K バイト (2048 バイト) にすると、妥当なパフォーマンスが得られます。inbufsz または outbufsz をそのサイズより大きくすると多少パフォーマンスは改善しますが、接続ごとに必要なメモリーも増えます。

HTTP/HTTPS の調整

前の 2 つの節で説明した一般的なプロパティーに加え、HTTP/HTTPS のパフォーマンスは、Message Queue トンネルサーブレットをホスティングする Web サーバーへの HTTP 要求をクライアントが作成する速度によっても制限されます。

Web サーバーは、シングルソケットで複数の要求を処理するように最適化する必要があります。JDK バージョン 1.4 以降では、Web サーバーが複数の HTTP 要求を処理する際に使用するリソースを最小限にするために、Web サーバーへの HTTP 接続 (Web サーバーへのソケット) は開かれたままになっています。JDK 1.4 を使用しているクライアントアプリケーションのパフォーマンスが JDK の旧リリースで稼働している同じアプリケーションより低速な場合は、パフォーマンスを改善するために Web サーバーのキープアライブ設定パラメータの調整が必要となることがあります。

このような Web サーバーの調整に加え、クライアントが Web サーバーをポーリングする頻度を調整することもできます。HTTP は要求ベースのプロトコルです。つまり、HTTP ベースのプロトコルを使用しているクライアントは、メッセージが待機中かどうかを判断するたに Web サーバーを定期的に確認する必要があります。imq.httpjms.http.pullPeriod ブローカプロパティーとそれに対応する imq.httpsjms.https.pullPeriod プロパティーは、Message Queue クライアントランタイムが Web サーバーをポーリングする頻度を指定します。

pullPeriod 値が -1 (デフォルト値) の場合、クライアントランタイムは直前の要求が戻るとすぐにサーバーをポーリングし、個々のクライアントのパフォーマンスを最大化します。その結果、各クライアント接続が Web サーバー内の要求スレッドを 1 つずつ占有するため、Web サーバーのリソースにかなりの負荷がかかる場合があります。

pullPeriod 値が正の数字である場合、クライアントランタイムは要求を定期的に Web サーバーへ送信し、データが保留されているかどうかを確認します。この場合、クライアントは Web サーバーの要求スレッドを占有しません。したがって、多数のクライアントが Web サーバーを使用している場合は、pullPeriod を正の値に設定することで Web サーバーのリソースを節約できます。

ファイルベースの持続ストアの調整

ファイルベースの持続ストアの調整については、「持続サービス」を参照してください。

ブローカの調整

次の節では、パフォーマンスを改善するためにブローカのプロパティーに対して実行できる調整について説明します。

メモリー管理: 負荷のある状態でブローカの安定性を高める

メモリー管理は、送信先単位で、またはシステム全体に対してすべての送信先を一括で、設定できます。

物理的送信先の制限の使い方

物理的送信先の制限については、第 6 章「物理的送信先の管理」を参照してください。

システム全体の制限の使い方

メッセージプロデューサの処理速度がメッセージコンシューマの処理速度を上回る傾向がある場合には、メッセージをブローカに蓄積できます。ブローカにはメモリーが不足した場合に、プロデューサの処理速度を低下させ、アクティブメモリーからメッセージをスワップさせるメカニズムが組み込まれていますが、ブローカが保持可能なメッセージの合計数とメッセージのバイトの合計数に厳密な制限を設定した方が賢明です。

imq.system.max_count ブローカプロパティーと imq.system.max_size ブローカプロパティーを設定して、これらの制限を制御します。

たとえば、次のように指定します。

imq.system.max_count=5000

上記で定義された値は、ブローカが未配信/未通知のメッセージを最大 5000 までしか保持しないことを示しています。それ以上のメッセージが送信されると、メッセージはブローカによって拒否されます。メッセージが持続的な場合は、プロデューサがメッセージを送信しようとすると例外を受け取ります。メッセージが持続的でない場合は、ブローカは暗黙のうちにメッセージを廃棄します。

メッセージの送信時に例外が戻った場合、クライアントは一時停止してから、送信を再試行します。この例外は、メッセージ受信に関するブローカの障害が原因ではありません。発生した例外は、送信側のクライアントだけが検出します。

複数のコンシューマキューのパフォーマンス

複数のキューコンシューマがキュー送信先でメッセージを処理する能率は、次の設定可能キュー送信先属性によって決まります。

• アクティブなコンシューマの数 (maxNumActiveConsumers)

• 単一のバッチでコンシューマに配信できるメッセージの最大数 (consumerFlowLimit)

最適なメッセージスループットを実現するには、十分な数のアクティブコンシューマがキューでのメッセージの生成に遅れずに対応し、消費する割合を最大にするような方法で、キュー内のメッセージをルーティングし、アクティブコンシューマへ配信しなければなりません。メッセージ配信を複数のコンシューマに分散させる一般的なメカニズムについては、『 Sun Java System^TM Message Queue 技術の概要』で説明されています。

メッセージがキューに蓄積している場合、メッセージ負荷を処理するアクティブコンシューマの数が不十分であることが考えられます。また、複数のメッセージがバッチサイズでコンシューマに配信されるため、メッセージがコンシューマ上でバックアップされていることも考えられます。たとえば、バッチサイズ (consumerFlowLimit) が大き過ぎる場合は、あるコンシューマがキュー内のすべてのメッセージを受信し、そのほかのコンシューマは何も受信していないことがあります。コンシューマが非常に高速であれば、これは問題にはなりません。

ただし、コンシューマが比較的低速で、メッセージをコンシューマに均等に分散させたい場合は、バッチサイズを小さくする必要があります。バッチサイズが小さいほど、メッセージをコンシューマへ配信するのに必要なオーバーヘッドは増加します。それでも、低速なコンシューマの場合は、一般に、小さいバッチサイズを使用した方がパフォーマンスは向上します。

クライアントランタイムのメッセージフローの調整

この節では、パフォーマンスに影響するフロー制御の動作について説明します (「クライアントランタイムの設定」を参照)。これらの動作は、接続ファクトリの管理対象オブジェクトの属性として設定されます。接続ファクトリ属性の設定方法については、第 8 章「管理対象オブジェクトの管理」を参照してください。

メッセージフロー測定

クライアントによって送受信されるメッセージ (ペイロードメッセージ) と Message Queue 制御メッセージは、同じクライアントとブローカ間の接続を使って伝送されます。ブローカ通知などの制御メッセージの配信における遅延は、ペイロードメッセージの配信によって制御メッセージが保留された場合の結果として生じます。このようなネットワークの輻輳を防止するため、Message Queue は接続全体のペイロードメッセージのフローを測定します。

ペイロードメッセージは、接続ファクトリ属性 imqConnectionFlowCount の指定に従い、設定した数のみが配信されるようにバッチされます。バッチが配信されたあと、ペイロードメッセージの配信は中断され、保留中の制御メッセージのみが配信されます。ペイロードメッセージの追加のバッチが配信されるときも、このサイクルが繰り返され、保留中の制御メッセージが続きます。

クライアントが、ブローカからの多数の応答を必要とする操作を実行している場合、たとえば、クライアントが CLIENT_ACKNOWLEDGE または AUTO_ACKNOWLEDGE モード、持続メッセージ、トランザクション、キューブラウザを使用している場合や、クライアントがコンシューマを追加または削除している場合などには、imqConnectionFlowCount の値を小さいままにしておく必要があります。一方、クライアントが DUPS_OK_ACKNOWLEDGE モードを使用しており、接続上に単純なコンシューマしかいない場合は、パフォーマンスを犠牲にすることなく imqConnectionFlowCount の値を増やすことができます。

メッセージフロー制限

Message Queue クライアントランタイムがメモリーなどのローカルリソースの上限に達する前に処理可能なペイロードメッセージの数には制限があります。この数に達すると、パフォーマンスに悪影響が出ます。したがって、Message Queue では、コンシューマあたりのメッセージ数または接続あたりのメッセージ数を制限できます。この制限は、接続を介して配信し、クライアントランタイムにバッファリングし、消費を待機できるメッセージの数を示しています。

コンシューマフローの制限

クライアントランタイムへ配信されたペイロードメッセージの数が、いずれかのコンシューマの imqConsumerFlowLimit 値を超えた場合、そのコンシューマへのメッセージ配信は停止します。そのコンシューマの消費されないメッセージの数が、 imqConsumerFlowThreshold で設定された値を下回った場合にだけ、配信処理が再開されます。

次の例は、これらの制限の使い方を示しています。トピックコンシューマのデフォルト設定値を前提としています。

imqConsumerFlowLimit=1000
imqConsumerFlowThreshold=50

コンシューマが作成され、1000 のメッセージがあれば、ブローカはこれらのメッセージを最初のバッチとしてコンシューマに配信します。このとき一時停止はありません。1000 メッセージの送信後、ブローカはクライアントランタイムが追加のメッセージを要求するまで、配信を停止します。アプリケーションがこれらのメッセージを処理するまで、クライアントランタイムはそれらを保持します。その後、クライアントランタイムは、アプリケーションがメッセージバッファー容量の 50% (imqConsumerFlowThreshold) つまり 500 メッセージ以上を消費するのを待ってから、ブローカに次のバッチを送信するように要求します。

同じ状況で、しきい値が 10% の場合、クライアントランタイムは、アプリケーションが少なくとも 900 メッセージを消費してから、次のバッチを要求します。

次のバッチサイズの計算方法:

imqConsumerFlowLimit - (現在、バッファーに保留中のメッセージ数
)

そのため、imqConsumerFlowThreshold が 50% の場合、次のバッチサイズは、アプリケーションがメッセージを処理する速度に応じて 500 〜 1000 の間になります。

imqConsumerFlowThreshold がかなり高く (100% 近くに) 設定された場合、ブローカは比較的小さいサイズのバッチを送信するため、メッセージのスループットは低下することがあります。値が低過ぎる (0% に近い) 場合は、クライアントは次のセットを配信する前に残りのバッファリングされたメッセージの処理を完了してしまい、やはりメッセージスループットを低下させることがあります。一般に、パフォーマンスや信頼性に特定の問題がないかぎり、imqConsumerFlowThreshold 属性のデフォルト値を変更する必要はありません。

コンシューマベースのフロー制御、特に、imqConsumerFlowLimit は、クライアントランタイム内のメモリーを管理する最適な手段です。一般に、クライアントアプリケーションに応じて、接続でサポートする必要のあるコンシューマの数、メッセージのサイズ、クライアントランタイムで使用可能なメモリー総量がわかります。

接続フローの制限

一部のクライアントアプリケーションでは、エンドユーザーの選択によって、コンシューマの数が不確定な場合があります。そのような場合は、引き続き、接続レベルのフロー制限を使用してメモリーを管理できます。

接続レベルのフロー制御は、接続上のすべてのコンシューマについてバッファリングされたメッセージの合計数を制限します。この数が imqConnectionFlowLimit の値を超えると、合計数が接続の制限を下回るまで、接続経由のメッセージの配信は停止します。imqConnectionFlowLimit 属性は、imqConnectionFlowLimitEnabled を true に設定した場合にだけ使用できます。

1 つのセッションでキューに入るメッセージの数は、そのセッションを使用するメッセージコンシューマの数と、各コンシューマのメッセージ負荷によって決まります。クライアント側のメッセージの生成またはメッセージの消費に遅延が発生する場合は、通常は、アプリケーションを再設計し、より多くのセッションにメッセージプロデューサとメッセージコンシューマを分散し、またはより多くの接続にセッションを分散してパフォーマンスを改善できます。

第 12 章 問題のトラブルシューティング

この章では、次の問題を把握して解決する方法について説明します。

• 「クライアントが接続を確立できない」

• 「接続スループットが遅すぎる」

• 「クライアントがメッセージプロデューサを作成できない」

• 「メッセージの生成が遅れるまたは低速である」

• 「メッセージがバックログされる」

• 「ブローカのスループットが散発的である」

• 「メッセージがコンシューマに到達しない」

• 「デッドメッセージキューにメッセージが含まれる」

問題が発生したら、インストールしている Message Queue^TM ソフトウェアのバージョン番号を調べてください。そのバージョン番号により、ソフトウェアバージョンと一致するバージョンのマニュアルを使用していることを確認します。Sun に問題を報告するときにも、そのバージョン番号が必要になります。バージョン番号を調べるには、次のコマンドを実行します。

imqcmd -v

クライアントが接続を確立できない

症状:

• クライアントが新しい接続を確立できない。

• クライアントが障害の生じた接続を自動的に再接続できない。

考えられる原因:

• クライアントアプリケーションが接続を閉じていないため、接続数がリソース制限を超えてしまった。

• ブローカが実行されていないか、ネットワーク接続の問題が存在している。

• 接続サービスが非アクティブであるか停止している。

• 必要な接続数に対して使用可能なスレッドが少なすぎる。

• Solaris または Linux プラットフォーム上で必要な接続数に対してファイル記述子が少なすぎる。

• TCP バックログにより、確立可能な新しい同時接続要求の数が制限される。

• オペレーティングシステムによって同時接続の数が制限される。

• ユーザーの認証に失敗するか権限が与えられない。

考えられる原因: クライアントアプリケーションが接続を閉じていないため、接続数がリソース制限を超えてしまった。

この問題の原因を確認するには:ブローカへの接続をすべて一覧表示します。

imqcmd list cxn

出力にはすべての接続と各接続の確立元のホストが一覧表示されます。異常な数の接続が開かれている特定のクライアントがわかります。

問題を解決するには: 原因となっているクライアントが未使用の接続を閉じるようにプログラムし直します。

考えられる原因: ブローカが実行されていないか、ネットワーク接続の問題が存在している。

この問題の原因を確認するには:

• ブローカのプライマリポートへ telnet で接続し、ブローカがポートマッパー出力を返すか確認します。プライマリポートのデフォルトは 7676 です。

• ブローカプロセスがホスト上で実行されていることを確認します。

問題を解決するには:

• ブローカを起動します。

• ネットワーク接続の問題を修復します。

考えられる原因: 接続サービスが非アクティブであるか停止している。

この問題の原因を確認するには: すべての接続サービスのステータスを確認します。

imqcmd list svc

接続サービスのステータスが unknown または paused と表示された場合、クライアントはそのサービスを使用する接続を確立できません。

問題を解決するには:

• 接続サービスのステータスが unknown と表示された場合、そのサービスはアクティブサービスリスト (imq.service.active ) に含まれていません。SSL ベースのサービスの場合は、サービスが不適切に設定されているため、ブローカがブローカログに次のエントリを作成する可能性があります。

  ERROR [B3009]: Unable to start service ssljms: [B4001]: Unable to open protocol tls for ssljms service...

  例外の根本的な原因の説明が続きます。

  SSL サービスを適切に設定する方法については、「メッセージの暗号化」を参照してください。

• 接続サービスのステータスが paused と表示された場合は、サービスを再開します (「接続サービスの停止および再開」を参照)。

考えられる原因: 必要な接続数に対して使用可能なスレッドが少なすぎる。

この問題の原因を確認するには: ブローカログの次のエントリを確認します。

WARNING [B3004]: No threads are available to process a new connection on service ... Closing the new connection.

また、次の形式のうちいずれかを使用し、接続サービスの接続数と現在使用中のスレッド数を確認します。

imqcmd query svc -n serviceName imqcmd metrics svc -n serviceName -m cxn

接続ごとに 2 つのスレッドが必要です。1 つは受信メッセージ用、もう 1 つは出力メッセージ用です (「スレッドプール管理」を参照)。

問題を解決するには:

• 専用スレッドプールモデル (imq. serviceName.threadpool_model= dedicated) を使用している場合、接続の最大数は、スレッドプールにあるスレッドの最大数の半分です。そのため、接続数を増やすには、スレッドプール (imq. serviceName.max_threads) のサイズを拡大するか、共有スレッドプールモデルに切り換えます。

• 共有スレッドプールモデル (imq. serviceName.threadpool_model=shared) を使用している場合、接続の最大数は、接続監視制限 (imq.serviceName.connectionMonitor_limit ) とスレッドの最大数 (imq. serviceName.max_threads) の 2 つのプロパティーの結果の半分です。そのため、接続数を増やすには、スレッドプールのサイズを拡大するか、接続監視制限の値を大きくします。

• 最終的に、サポート可能な接続の数または接続のスループットが入力/出力制限に達してしまいます。このような場合は、マルチブローカクラスタを使用して、クラスタ内のブローカインスタンス間で接続を分散します。

考えられる原因: Solaris または Linux プラットフォーム上で必要な接続数に対してファイル記述子が少なすぎる。

この問題については、「ファイル記述子制限の設定」を参照してください。

この問題の原因を確認するには:次のようなブローカログのエントリを確認します。

Too many open files

問題を解決するには: ulimit のマニュアルで説明しているとおり、ファイル記述子の制限を増やします。

考えられる原因: TCP バックログにより、確立可能な新しい同時接続要求の数が制限される。

TCP バックログにより、ポートマッパーが追加の要求を拒否するまでにシステムバックログ (imq.portmapper.backlog)) に格納可能な同時接続要求の数が制限されます。Windows プラットフォームでは、Windows デスクトップで 5、Windows サーバーで 200 というバックログ制限がハードコードされています。

通常、バックログ制限が原因の要求拒否は過渡的な現象であり、非常に多数の同時接続要求があると発生します。

この問題の原因を確認するには: ブローカログを調べます。最初に、ブローカが、その他の接続を拒否している期間に接続を受け入れているかどうかを確認します。次に、拒否された接続について説明するメッセージを確認します。このようなメッセージがある場合、TCP バックログが問題ではないと思われます。ブローカは、TCP バックログによる接続拒否をログしないからです。正常接続がログされ、接続拒否がログされない場合は、TCP バックログが問題と思われます。

問題を解決するには:

• クライアントが確立しようとする接続の再試行を短い間隔で行うようにプログラミングします。この問題の過渡的な性質上、このようにプログラミングしても正常に動作します。

• imq.portmapper.backlog の値を大きくします。

• クライアントが接続を閉じずに、多くの接続を開いていないか確認します。

考えられる原因: オペレーティングシステムによって同時接続の数が制限される。

Windows オペレーティングシステムのライセンスは、サポートされる同時リモート接続の数を制限します。

この問題の原因を確認するには: imqcmd query svc を使用して、接続用のスレッドが十分にあることを調べ、さらに Windows ライセンス契約書の条項を確認します。ローカルクライアントからは接続を確立できるが、リモートクライアントからは確立できない場合は、オペレーティングシステムの制限が問題の原因と考えられます。

問題を解決するには:

• より多くの接続が許可されるように Windows ライセンスをアップグレードします。

• マルチブローカクラスタを設定して、多数のブローカインスタンスに接続を分散します。

考えられる原因: ユーザーの認証に失敗するか権限が与えられない。

認証は、次のいずれかの理由で失敗する場合があります。

• 不正なパスワード

• ユーザーリポジトリにユーザーのエントリがない

• ユーザーが接続サービスへのアクセス許可を持っていない

この問題の原因を確認するには: ブローカログのエントリで Forbidden エラーメッセージを確認します。このメッセージは、認証エラーを示しているだけで、その理由は示していません。

• ファイルベースのユーザーリポジトリを使用している場合は、次のコマンドを入力します。

  imqusermgr list -i instanceName -u userName

  出力にユーザーが表示された場合は、不正なパスワードの入力が原因と考えられます。出力に次のエラーが表示された場合は、ユーザーリポジトリにユーザーのエントリがありません。

  Error [B3048]: User does not exist in the password file

• LDAP サーバーのユーザーリポジトリを使用している場合は、適切なツールを使用して、ユーザーのエントリがあるかどうかを確認します。

• アクセス制御プロパティーファイルで、接続サービスへのアクセスが制限されていないかどうかを確認します。

問題を解決するには:

• 不正なパスワードが使用された場合は、正しいパスワードを入力し直します。

• ユーザーリポジトリにユーザーのエントリがない場合は追加します (「ユーザーリポジトリの設定と管理」を参照)。

• ユーザーが接続サービスへのアクセス許可を持っていない場合は、アクセス制御プロパティーファイルを編集し、アクセス許可を与えます (「接続サービスのアクセス制御」を参照)。

接続スループットが遅すぎる

症状:

• メッセージスループットが期待どおりでない。

• サポートされるブローカへの接続数が、「クライアントが接続を確立できない」で説明されている原因によってではなく、メッセージの入力/ 出力レートによって制限されている。