Message Queue 4.1 では、高可用性 (データおよびサービスの可用性) ブローカクラスタ、JAAS サポート、およびその他のさまざまな小機能が導入されています。この節では、これらの機能について説明し、参考資料も示します。
Message Queue 4.1 では、データの可用性とサービスの可用性を提供する高可用性クラスタが導入されています。クライアントが高可用性ブローカへの接続を失った場合は、自動的にクラスタ内の別のブローカに再接続されます。新しい接続を提供するブローカは、障害が発生したブローカの持続データと持続状態を継承し、障害が発生したブローカのクライアントに中断することなくサービスの提供を続けます。高可用性ブローカは、セキュリティー保護された接続を介して実行できます。
高可用性ブローカでは、高可用性データベース (HADB) を使用する必要があります。そのようなデータベースがない場合、またはデータの可用性が重要でない場合は、自動再接続とサービスの可用性を提供する従来のクラスタを引き続き使用できます。
高可用性ブローカの設定は簡単です。クラスタ内のブローカごとに次の種類のブローカプロパティーを指定します。
クラスタメンバーシッププロパティー。ブローカが高可用性クラスタの一部であることと、クラスタの ID およびブローカの ID を指定します。
高可用性データベース (HADB) プロパティー。持続メッセージ (JDBC) のモデル、HADB ベンダーの名前、およびベンダー固有のデータベースの設定プロパティーを指定します。
障害検出および継承プロパティー。ブローカ障害の検出と処理の方法を指定します。
この機能を使用するには、次の操作を実行する必要があります。
高可用性データベースをインストールします。
JDBC ドライバの .jar ファイルをインストールします。
高可用性持続ストア用のデータベーススキーマを作成します。
クラスタ内のブローカごとに、高可用性に関連したプロパティーを設定します。
クラスタ内の各ブローカを起動します。
高可用性の概念に関する説明、および従来のクラスタとの比較については、『Sun Java System Message Queue 4.1 Technical Overview』の第 4 章「Broker Clusters」を参照してください。高可用性の手続きおよび参照に関する情報については、『Sun Java System Message Queue 4.1 Administration Guide』の第 8 章「Broker Clusters」および 『Sun Java System Message Queue 4.1 Administration Guide』の「Cluster Configuration Properties」を参照してください。
Message Queue version 4.0 で HADB データベースを使用していた場合、高可用性クラスタを使用するには、dbmgr ユーティリティーを使用して共有 HADB ストアにアップグレードできます。詳細は、「ブローカクラスタ」を参照してください。
Message Queue では、ファイルベースおよび LDAP ベースの組み込み認証機構に加えて、JAAS (Java Authentication and Authorization Service) もサポートしています。JAAS を使用すると、さまざまなサービスをブローカに接続して Message Queue クライアントを認証できます。この節では、ブローカによって JAAS 準拠の認証サービスで利用可能になる情報について説明し、それらのサービスを使用するようにブローカを設定する方法についても説明します。
JAAS API についての説明は、このマニュアルの対象範囲ではありません。詳細を知る必要がある場合は、次の資料を参照してください。
JAAS API の詳細は、『Java Authentication and Authorization Service (JAAS) Reference Guide』を参照してください。
http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASRefGuide.html
LoginModule の記述については、『Java Authentication and Authorization Service (JAAS) LoginModule Developer's Guide』を参照してください。
http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASLMDevGuide.html
JAAS API は J2SE のコア API であるため、Message Queue の実行環境の必須部分です。JAAS は、アプリケーションと認証機構の間の抽象化層を定義し、アプリケーションコードを変更せずに目的の機構をプラグインできるようにします。Message Queue サービスの場合、抽象化層はブローカ (アプリケーション) と認証プロバイダの間にあります。いくつかのブローカプロパティーを設定することで、JAAS 準拠の任意の認証サービスに接続して、ブローカコードを中断または変更せずにそのサービスをアップグレードできます。
JAAS 準拠の認証を使用している場合は、JMX クライアントを使用してブローカを管理できますが、ブローカを起動する前に手動で JAAS サポートを設定する必要があります (JAAS 関連のブローカプロパティーを設定することで行う)。JMX API を使用してこれらのプロパティーを変更することはできません。
図 1–1 に、JAAS の基本要素である JAAS クライアント、JAAS 準拠の認証サービス、および JAAS 設定ファイルを示します。
JAAS クライアントは、JAAS 準拠の認証サービスを使用して認証を実行しようとするアプリケーションです。JAAS クライアントは、LoginModule を使用してこのサービスと通信し、LoginModule がユーザー名、パスワード、およびその他の関連情報を取得するために呼び出すことができるコールバックハンドラの提供を担当します。
JAAS 準拠の認証サービスは、1 つ以上の LoginModule と、必要な認証を実行するロジックで構成されます。LoginModule には認証ロジックが含まれる場合があります。また、LoginModule は、プライベートプロトコルまたは API を使用して、認証ロジックを提供するモジュールと通信する場合があります。
JAAS 設定ファイルは、JAAS 準拠のサービスとの通信に必要な LoginModule を検出するために JAAS クライアントが使用するテキストファイルです。
次の節では、Message Queue サービスがこれらの要素を使用して JAAS 準拠の認証を提供する方法について説明します。
次の図に、Message Queue ブローカが JAAS を使用する方法を示します。この図は、前の図に示した JAAS モデルのより複雑な実装を示しています。
簡単な方の事例に示されているように、認証サービス層はブローカとは別になっています。認証サービスは、1 つ以上のログインモジュール (LoginModule) と、必要に応じて追加する認証モジュールで構成されます。ログインモジュールは、ブローカと同じ Java 仮想マシンで実行されます。Message Queue ブローカは、ログインモジュールに対して LogInContext として表現され、ブローカ実行時コードの一部である CallBackHandler によってログインモジュールと通信します。
認証サービスは、ログインモジュールのエントリを含む JAAS 設定ファイルも提供します。設定ファイルは、モジュールを使用する順序、およびモジュールの使用に関する一部の条件を指定します。ブローカが起動すると、JAAS は Java システムプロパティー java.security.auth.login.config または Java セキュリティープロパティーファイルによって設定ファイルを検出します。次に、JAAS は、ブローカプロパティー imq.user_repository.jaas.name の値に応じて、JAAS 設定ファイル内のエントリを選択します。そのエントリは、認証に使用するログインモジュールを指定します。図に示すように、ブローカは複数のログインモジュールを使用できます。(設定ファイル、ログインモジュール、およびブローカの関係は、図 1–3 に示されています。)
ブローカが JAAS プラグイン認証サービスを使用するという事実は、Message Queue クライアントに対して完全に透明なままです。クライアントは引き続き以前と同じようにブローカに接続し、ユーザー名とパスワードを渡します。同様に、ブローカはコールバックハンドラを使用してこの情報を認証サービスに渡し、認証サービスはその情報を使用してユーザーを認証し、結果を返します。認証に成功した場合、ブローカは接続を許可します。認証に失敗した場合、クライアントランタイムはクライアントが処理する必要のある JMS セキュリティー例外を返します。
Message Queue クライアントの認証後に、さらに行うべき承認がある場合、ブローカは通常どおり続行されます。ブローカはアクセス制御ファイルを参照し、認証されたクライアントが引き受けるアクションを実行することを承認するかどうかを決定します。それらのアクションには、送信先へのアクセス、メッセージの消費、キューの表示などがあります。
JAAS 準拠の認証の設定には、ブローカおよびシステムプロパティーを設定して、このタイプの認証を選択し、設定ファイルの場所を指定し、使用するログインモジュールのエントリを指定することが関係します。
この節では、JAAS クライアント、ログインモジュール、および JAAS 設定ファイルの関係を図で示し、次に JAAS 準拠の認証の設定に必要なプロセスについて説明します。次の図に、設定ファイル、ログインモジュール、およびブローカの関係を示します。
図に示すように、JAAS 設定ファイル MyJAASCFile.config には、エントリポイントにグループ化されたいくつかのログインモジュールへの参照が含まれています。ブローカは、Java システムプロパティー java.security.auth.login.config または Java セキュリティープロパティーファイルを参照することで、設定ファイルを検出します。使用するログインモジュールは、ブローカプロパティー imq.user_repository.jaas.name を参照することで決定されます。このブローカプロパティーは、設定ファイル内の目的のエントリを指定します。これらのモジュールのためのクラスは、lib/ext ディレクトリにあります。
Message Queue 用の JAAS サポートを設定するには、次の手順を完了する必要があります。(開発環境では、これらの手順はすべて開発者が実行する場合があります。本稼働環境では、管理者がこれらのタスクの一部を引き継ぐことになります。)
認証サービスを実装する 1 つ以上のログインモジュールクラスを作成します。ブローカがサポートする JAAS コールバックのタイプを下に一覧表示します。
ブローカはこのコールバックを使用して、ブローカが動作しているロケールを認証サービスに渡します。この値は、ローカリゼーションに使用できます。
ブローカはこのコールバックを使用して、接続の要求時に Message Queue クライアントによって指定されたユーザー名を認証サービスに渡します。
ブローカはこのコールバックを使用して、TextInputCallback.getPrompt() が imq.authentication.type のときに、imq.authentication.type の値を認証サービスに指定します。現在、このフィールドで唯一可能な値は basic です。これは Base-64 パスワードエンコーディングを示しています。
ブローカはこのコールバックを使用して、接続の要求時に Message Queue クライアントによって指定されたパスワードを認証サービスに渡します。
ブローカはこのコールバックを使用して、テキスト出力をブローカのログファイルに記録することで、認証サービスにログサービスを提供します。コールバックの MessageType ERROR、INFORMATION、WARNING はそれぞれ、ブローカログレベル ERROR、INFO、および WARNING にマップされます。
ログインモジュールクラスを参照するエントリを持つ JAAS 設定ファイルを作成し、このファイルの場所を Message Queue 管理者に指定します。(このファイルはリモートから検出でき、その場所を URL で指定できます。)
JAAS 設定ファイル内のエントリ (ログイン実装クラスを参照する) の名前を書き留めます。
ログインモジュールを実装するクラスを jar ファイルに保存し、その jar ファイルを Message Queue の lib/ext ディレクトリに配置します。
JAAS サポートに関連したブローカプロパティーを設定します。この点については、表 1–2 で説明しています。
次のシステムプロパティーを設定して、JAAS 設定ファイルの場所を指定します。
java.security.auth.login.config= JAAS_Config_File_Location
たとえば、ブローカを起動するときに設定ファイルを指定できます。
imqbrokerd -Djava.security.auth.login.config=JAAS_Config_File_Location
JAAS 設定ファイルの場所を指定する方法はほかにもあります。追加の情報については、次を参照してください。
http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/tutorials/LoginConfigFile.html
次の表に、JAAS サポートの設定に必要なブローカプロパティーの一覧を示します。
表 1–2 JAAS サポートのためのブローカプロパティー
プロパティー |
説明 |
---|---|
imq.authentication.type |
basic に設定して、Base-64 パスワードエンコーディングを指定します。これは、JAAS 認証用に許可される唯一の値です。 |
imq.authentication.basic.user_repository |
jaas に設定して、JAAS 認証を指定します。 |
imq.accesscontrol.type |
file に設定します。 |
imq.user_repository.jaas.name |
認証機構として使用するログインモジュールを参照する目的のエントリ (JAAS 設定ファイル内) の名前に設定します。これは、手順 3 で書き留めた名前です。 |
imq.user_repository.jaas.userPrincipalClass |
Message Queue のアクセス制御で使用されるこのプロパティーは、Message Queue のアクセス制御ファイルでユーザーエンティティーを表現する主体名の抽出にブローカが使用するログインモジュールで java.security.Principal 実装クラスを指定します。このプロパティーが指定されていない場合は、接続の要求をしたときに Message Queue クライアントから渡されたユーザー名が代わりに使用されます。 |
imq.user_repository.jaas.groupPrincipalClass |
Message Queue のアクセス制御で使用されるこのプロパティーは、Message Queue のアクセス制御ファイルでグループエンティティーを表現する主体名の抽出にブローカが使用するログインモジュールで java.security.Principal 実装クラスを指定します。このプロパティーが指定されていない場合は、Message Queue のアクセス制御ファイル内のグループ規則 (存在する場合) は無視されます。 |
Message Queue の Version 4.1 では、JDBC ストアは高可用性をサポートするように変更されています。この理由で、JDBC ストアのバージョンは 410 に増えています。JDBC ストアのバージョン 350、370、および 400 は、自動的に 410 バージョンの形式に移行されます。
ファイルベースの持続ストアのバージョンは、何も変更がないので、370 のままです。
プロパティー IMQ_DEFAULT_EXT_JARS が imqenv.conf ファイルに追加されました。このプロパティーを設定して、ブローカが起動するときに CLASSPATH に含まれる外部 .jar ファイルのパス名を指定できます。このプロパティーを使用して外部 .jar ファイルの場所を指定した場合は、これらのファイルを lib/ext ディレクトリにコピーする必要はなくなります。外部 jar は、JDBC ドライバまたは JAAS ログインモジュールを参照できます。次のサンプルコマンドは、JDBC ドライバの場所を指定します。
IMQ_DEFAULT_EXT_JARS=/opt/SUNWhadb4/lib/hadbjdbc4.jar:/opt/SUNWjavadb/derby.jar
Message Queue は、Sun Java Enterprise System (JES) Monitoring Framework をサポートしています。この Monitoring Framework は、一般的なグラフィカルインタフェースを使用して Java Enterprise System コンポーネントを監視できるようにします。このインタフェースは、Sun Java System Monitoring Console と呼ばれる Web ベースのコンソールによって実装されます。ほかの JES コンポーネントと一緒に Message Queue を実行している場合は、1 つのインタフェースを使用してこれらすべてのコンポーネントを管理するほうが便利なことがあります。
JES Monitoring Framework は、すべての JES コンポーネント製品で使用する共通データモデル (CMM) を定義します。このモデルにより、すべての JES コンポーネントを集中管理の単一形式で表示できます。Message Queue は、次のオブジェクトを JES Monitoring Framework に明示します。
インストールされている製品
ブローカのインスタンス名
ブローカのポートマッパー
各接続サービス
物理的な各送信先
持続ストア
ユーザーリポジトリ
これらの各オブジェクトは CMM オブジェクトにマップされ、その属性は JES 監視コンソールを使用して監視できます。管理者は、実行時にコンソールを使用してパフォーマンス統計を表示したり、自動的に監視する規則を作成したり、アラームを確認したりできます。Message Queue オブジェクトから CMM オブジェクトへのマッピングの詳細は、『Sun Java Enterprise System 監視ガイド』を参照してください。
JES 監視を有効にするには、次の操作を実行する必要があります。
『 Sun Java Enterprise System インストールガイド』に記載されている手順に従って、配備中のすべてのコンポーネント (Message Queue およびその他のコンポーネント) をインストールおよび設定します。
『Sun Java Enterprise System 監視ガイド』の説明に従って、監視対象のすべてのコンポーネントに対して Monitoring Framework を有効にして設定します。
『Sun Java Enterprise System 監視ガイド』の説明に従って、別のホストに Monitoring Console をインストールし、マスターエージェントを起動してから、Web サーバーを起動します。
JES Monitoring Framework を使用しても、ブローカのパフォーマンスには影響しません。メトリックスの収集作業はすべて Monitoring Framework によって行われ、データはブローカの既存の監視データインフラストラクチャーから取得されるためです。
以前は、管理上、PREPARED 状態のトランザクションだけをロールバックすることができました。つまり、分散トランザクションの一部であるセッションが正常に終了しなかった場合、そのトランザクションは、ブローカ管理者がクリーンアップできない状態のままになりました。Message Queue 4.1 では、imqcmd ユーティリティーを使用して、STARTED、 FAILED、INCOMPLETE、COMPLETE、 PREPARED の状態にあるトランザクションをクリーンアップ (ロールバック) できます。
特定のトランザクションがロールバックできるかどうか (特に、PREPARED 状態でない場合) の判別に役立つように、imqcmd ユーティリティーは、追加のデータを imqcmd query txn 出力の一部として提供します。このデータは、そのトランザクションを開始した接続のコネクション ID を提供し、トランザクションが作成された時間を示します。管理者は、この情報を使用して、トランザクションをロールバックする必要があるかどうかを決定できます。一般に、管理者は早計にトランザクションをロールバックすることを避けるとよいでしょう。
C クライアントは、MQ_SERVICE_PORT_PROPERTY 接続プロパティーを使用して、接続先の固定ポートを指定できます。これは、ファイアウォールを通過しようとしている場合、またはブローカのポートマッパーサービス (動的にポートを割り当てる) をバイパスする必要がある場合に便利なことがあります。
ブローカ側でも JMS サービスポートを設定する必要があることを忘れないでください。たとえば、ssljms を介してクライアントをポート 1756 に接続する場合は、次のように操作します。
クライアント側: MQ_SERVICE_PORT_PROPERTY を 1756 に設定し、MQ_CONNECTION_TYPE_PROPERTY を SSL に設定します。
ブローカ側: 次のようにして、imq.serviceNameType.protocol .port プロパティーを 1756 に設定します。
imq.ssljms.ssl.port=1756
MQ_SERVICE_PORT_PROPERTY 接続プロパティーは、Message Queue の version 3.7 Update 2 で導入されました。