WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

組み込みグローバル・キャッシュ

再利用するデータを格納するには、WebSphere® Message Broker から提供されるグローバル・キャッシュを使用します。

グローバル・キャッシュはブローカーに組み込まれます。 デフォルトでは、キャッシュは使用不可です。キャッシュを使用するために、適切なキャッシュ・ポリシーを選択します。 デフォルトのキャッシュ・ポリシーによって、単一ブローカーでのキャッシュ・コンポーネントのデフォルト・トポロジーが作成されます。 このデフォルト・トポロジーの代わりに、ポリシーを使用しないという方法があります。この場合、実行グループでキャッシュ・プロパティーを設定することによって独自のトポロジーを制御できます。他にも、XML ポリシー・ファイルを使用して複数のブローカーにわたってキャッシュを使用可能にするという方法もあります。

デフォルト・トポロジー

デフォルトでは、ブローカー内の 1 つの実行グループがカタログ・サーバーのホストとなります。 カタログ・サーバーはデータの配置を制御し、コンテナー・サーバーの正常性をモニターします。 その実行グループ以外に、そのブローカー内で最大 3 つの実行グループがコンテナー・サーバーのホストとなります。 コンテナー・サーバーは、キャッシュ・データのサブセットを保持する、実行グループに組み込まれるコンポーネントです。 カタログ・サーバーとコンテナー・サーバーは、ブローカーの開始時に実行グループに動的に配置されます。 すべての実行グループは、カタログ・サーバーのホストであるか、コンテナー・サーバーのホストであるか (またはどちらでもないか) に関わらず、グローバル・キャッシュと通信できます。 それぞれの実行グループにはキャッシュ・マネージャーがあり、それによって、その実行グループに組み込まれたキャッシュ・コンポーネントが管理されます。 キャッシュ・コンポーネントの説明については、データ・キャッシュの用語を参照してください。

ブローカーの再始動時にはカタログ・サーバーの配置がリセットされます。 使用するポートの範囲は、デフォルトでブローカーにより設定されますが、特定のポート範囲を指定することも可能です。 カタログ・サーバーが配置された実行グループを停止すると、グローバル・キャッシュは使用できなくなります。 コンテナー・サーバーのホストとなっている実行グループを停止して再開すると、コンテナー・サーバーは動的に再び割り当てられます。 既存のキャッシュ・データは保持されて自動的に再バランス化されます (すべてのコンテナー・サーバーを停止した場合を除く)。 実行グループは、以下の順序で構成されます。
  • 最初に開始する実行グループは、カタログ・サーバーおよびコンテナー・サーバーです。 この実行グループは範囲内の最初の 4 つのポートを使用します。
  • 2 番目に開始する実行グループは、コンテナー・サーバーのみです。これは範囲に含まれる 3 つのポートを使用します (ポート 5 から 7)。
  • 3 番目と 4 番目に開始する実行グループは、それぞれコンテナー・サーバーのみです。範囲内のポート 8 と 10 および 11 と 13 を使用します。
  • さらに他の実行グループが開始される場合、それらはグローバル・キャッシュ・コンポーネントのホストとなりません。 ただし、すべての実行グループはクライアントとしてグローバル・キャッシュと通信できます。
  • カタログ・サーバーが配置された実行グループを停止すると、グローバル・キャッシュは使用できなくなります。
  • 2 番目、3 番目、または 4 番目の実行グループを停止した場合、停止した実行グループのコンテナー・サーバーは、次に開始する実行グループに割り当てられます。
カタログ・サーバーをホストする実行グループを再開すると、他の実行グループに属するコンテナー・サーバーと通信できなくなります。 これらのコンテナー・サーバーは引き続き実行されますが、キャッシュの一部ではなくなり、データは失われます。 そのため、コンテナー・サーバーをホストする実行グループも再開する必要があります。 あるいは、ブローカーを再始動して、すべてのキャッシュ・コンポーネントをリセットします。

デフォルト・トポロジーを使用する場合、個々の実行グループのキャッシュ・プロパティーは読み取り専用になります。これらを変更しようとするとエラーが発生します。 デフォルト・トポロジーを使用する場合、キャッシュ・マネージャーが使用するポートの範囲、およびキャッシュ・コンポーネントによって使用されるリスナー・ホストを指定できます。 コンピューターに複数のホスト名がある場合、リスナー・ホストを設定して、キャッシュ・コンポーネントが正しいホスト名を使用するようにします。 実行グループの特定のプロパティーを設定するには、まずキャッシュ・ポリシー・プロパティーを none に変更する必要があります。 ブローカー・レベルのポリシーによって最後に設定された実行グループ・プロパティーが、カスタマイズの開始点として保持されます。

複数ブローカーのキャッシュ・トポロジー

ブローカー全体でデータを共用するには、またはキャッシュの可用性を拡張するには、ポリシー・ファイルを作成する必要があります。ポリシー・ファイルは、複数ブローカーのキャッシュを接続するためにキャッシュ・マネージャーが使用する XML ファイルです。 キャッシュ・ポリシーにポリシー・ファイルの完全修飾名を設定します。 ポリシー・ファイルを使用して、キャッシュ・データを共用するブローカーの名前、各ブローカーに属するカタログ・サーバーの数、および各ブローカーが使用するポート範囲とリスナー・ホストを指定します。 いくつかのサンプル・ポリシー・ファイルが、インストール・ディレクトリーに用意されています。 これらのポリシー・ファイルをコピーして、独自のシステム用にカスタマイズできます。 サンプル XML ファイルでは、以下の構成を記述しています。
  • 2 つのカタログ・サーバーをホストする単一のブローカー。一方のカタログ・サーバーが失敗すると、グローバル・キャッシュが他方のカタログ・サーバーに切り替えます。
  • 最初のブローカーによってホストされるカタログ・サーバーを共用する 2 つのブローカー。
  • カタログ・サーバーをそれぞれホストする 2 つのブローカー。一方のカタログ・サーバーが失敗すると、グローバル・キャッシュが他方のブローカーのカタログ・サーバーに切り替えます。
詳しくは、複数のブローカーのグローバル・キャッシュの構成を参照してください。

組み込みトポロジーのカスタマイズ

実行グループごとにプロパティーを明示的に設定できます。 例えば、ブローカーのパフォーマンスを調整できるように、特定の実行グループを指定して、カタログ・サーバーおよびコンテナー・サーバーをホストするとします。 キャッシュ・ポリシーを none に設定した場合、自分で設定した値が各実行グループのキャッシュ・マネージャーで使用されます。 ブローカー・レベルのポリシーによって最後に設定された実行グループ・プロパティーが、カスタマイズの開始点として保持されます。

カタログ・サーバーが配置された実行グループを停止すると、キャッシュは使用できなくなり、キャッシュのデータは失われます。 このため、デフォルト・トポロジーをオフに切り替える場合、カタログ・サーバーを適切な場所に配置してください。 カタログ・サーバーをホストする実行グループを再開すると、他の実行グループに属するコンテナー・サーバーと通信できなくなります。 これらのコンテナー・サーバーは引き続き実行されますが、キャッシュの一部ではなくなり、データは失われます。 そのため、コンテナー・サーバーをホストする実行グループも再開する必要があります。 あるいは、ブローカーを再始動して、すべてのキャッシュ・コンポーネントをリセットします。

複数のカタログ・サーバーを使用する場合は、以下のステップを実行すると、パフォーマンスを向上させることができます。
  • カタログ・サーバーとコンテナー・サーバーの両方をホストする実行グループのみでなく、コンテナー・サーバーのみをホストするその他の実行グループを用意します。
  • mqsistart コマンドまたは mqsistop コマンドを使用してすべての実行グループを一度に開始または停止するのではなく、実行グループを順に開始および停止します。例えば、コンテナー・サーバーのみをホストする実行グループを開始する前に、カタログ・サーバーをホストする実行グループを開始します。

複数のブローカーにまたがるグローバル・キャッシュを使用する場合は、1 つの組み込みグリッドにクラスター化されているすべての WebSphere eXtreme Scale サーバーが、同じドメイン・ネームを使用するようにしてください。 同じドメイン・ネームを持つサーバーのみが、同じグリッドに参加できます。WebSphere eXtreme Scale クライアントは、ドメイン・ネームを使用して、組み込みグリッドを識別し、区別します。実行グループまたはブローカー・レベルのポリシー・ファイルにドメイン・ネームを指定しなかった場合は、ブローカーによって、カタログ・サーバーのサーバー名に基づいた名前が作成されます。

デフォルトでは、各サーバーは、ブローカーによって派生したドメイン・ネームから始まります。従来のバージョンの WebSphere Message Broker では、すべての組み込みキャッシュ内のすべてのサーバーのドメイン・ネームが空ストリングでした。別のドメイン内のサーバーを同じグリッドで連携させることはできません。それで、複数のブローカーにまたがるキャッシュについては、それらのブローカーを同時にマイグレーションしてください。

グローバル・キャッシュは、WebSphere Message Broker コマンド、WebSphere Message Broker Explorer、または メッセージ・ブローカー API を使用して構成できます。 詳しくは、組み込みグローバル・キャッシュの構成を参照してください。

キャッシュ・ポリシー・プロパティーを disabled に設定することによって、ブローカー内のすべてのキャッシュ・コンポーネントを使用不可にすることができます。 デフォルトでは、キャッシュ・ポリシーは disabled に設定されています。

グローバル・キャッシュとの対話

JavaCompute ノードを使用して、グローバル・キャッシュ内のマップにあるデータを保管または取得することができます。 外部グリッドからグローバル・マップを取得すると、グリッドへの接続がない場合は、getGlobalMap メソッドによってグリッドへの接続が確立されます。詳しくは、JavaCompute ノードを使用したグローバル・キャッシュへのアクセスを参照してください。

MbGlobalMap オブジェクトを取得するとき、データをグローバル・キャッシュに保持した後に自動的に削除するまでの時間の長さも指定できます。 この時間は存続時間 と呼ばれ、マップ項目の最終更新日時からのカウントです。 この値は、メッセージ・フローの同一のインスタンス内でその MbGlobalMap オブジェクトを使用して作成されたすべてのキャッシュ項目に適用されます。 指定したマップ内に既にあるデータや、別の MbGlobalMap オブジェクトによって作成されたデータは、存続時間値による影響は受けません。 複数の MbGlobalMap オブジェクトを複数の異なるフロー、実行グループ、またはブローカーに作成し、グローバル・キャッシュ内の同一マップにそれらすべてが解決されるようにした上で、それぞれに異なる存続時間値を設定することもできます。

デフォルトでは存続時間はゼロに設定され、データはいつまでも削除されません。 特定の存続時間を設定するには、MbGlobalMap オブジェクトから参照可能なセッション・ポリシーを作成します。 詳細な指示については、グローバル・キャッシュからのデータの削除を参照してください。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:48:38


概念トピック概念トピック | バージョン 8.0.0.5 | bc23789_