WebLogic JMS のコンフィグレーションと管理
|
 |
 |
|
以下の節では、クラス化環境で WebLogic JMS リソースをコンフィグレーションする方法について説明します。
WebLogic Server のクラスタはドメイン内のサーバ群で、より強力で信頼性のあるアプリケーション プラットフォームを提供します。クラスタはそのクライアントにとって単一のサーバに見えますが、実際には、一体で機能するサーバ群です。
注意 : JMS クライアントがクラスタにアクセスするには、ユニークな WebLogic Server 名が必要です (WebLogic Server が異なるドメインに存在する場合でも)。このため、JMS クライアントがアクセスするすべての WebLogic Server インスタンスの名前はユニークでなければなりません。
管理者は、複数の JMS サーバをコンフィグレーションし、それらを定義済みの WebLogic Server に割り当てることで、クラスタ内の複数のサーバにわたる送り先のロード バランシングを確立できます。各 JMS サーバは、厳密に 1 つの WebLogic Server インスタンスにデプロイされ、送り先の集合に対するリクエストを処理します。
注意 : ロード バランシングは動的ではありません。コンフィグレーションの段階で、システム管理者が JMS サーバの対象を指定してロード バランシングを定義します。
管理者は、クラスタ内の各サーバ インスタンスのデフォルト接続ファクトリを使用するか、1 つまたは複数の接続ファクトリをコンフィグレーションしてクラスタ内の 1 つまたは複数のサーバ インスタンスまたはクラスタ全体を対象とすることで、クラスタ内のあらゆるサーバから送り先へのクラスタワイドで透過的なアクセスを確立できます。これにより、各接続ファクトリを複数の WebLogic Server インスタンスにデプロイできます。接続ファクトリについては、「接続ファクトリ リソース」を参照してください。
WebLogic Server はサーバ レベル (サーバ インスタンス) での移行をサポートします。WebLogic Server がホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「Server Migration」を参照してください。
また、「必ず 1 回」のサービスとして、WebLogic JMS はクラスタ化された環境のために WebLogic Server に実装されている移行フレームワークを活用します。これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への対応としての移行も含まれます。詳細については、「JMS サーバの移行可能な対象のコンフィグレーション」を参照してください。
クラスタ用にコンフィグレーションしたロード バランシング アルゴリズム (ラウンドロビン アフィニティ、重みベース アフィニティ、またはランダム アフィニティ) は、JMS クライアント接続のためのサーバ アフィニティを提供します。JMS アプリケーションから指定したサーバ インスタンスに接続できる場合、JMS は同じサーバ インスタンスとの新しい JMS 接続を確立しようとします。サーバ アフィニティの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでのロード バランシング」を参照してください。
WebLogic Server クラスタの機能とメリットについては、『WebLogic Server クラスタ ユーザーズ ガイド』の「Understanding WebLogic Server Clustering」を参照してください。
JMS クラスタ化を実装するには、クラスタ化された有効な JMS ライセンスが必要です。このライセンスにより、接続ファクトリや送り先を別の WebLogic Server インスタンスに配置することが可能になります。また、クラスタ化された JMS ライセンスは、以下のものを使用するために必要になります。
クラスタ化された有効な JMS ライセンスを取得していない場合は、BEA の販売代理店までお問い合わせください。
管理者は、クラスタ内の各サーバ インスタンスのデフォルト接続ファクトリを使用するか、1 つまたは複数の接続ファクトリをコンフィグレーションしてクラスタ内の 1 つまたは複数のサーバ インスタンスまたはクラスタ全体を対象とすることで、クラスタ内のあらゆるサーバから JMS 送り先へのクラスタワイドで透過的なアクセスを確立できます。これにより、各接続ファクトリを複数の WebLogic Server にデプロイできます。接続ファクトリのデプロイメントとコンフィグレーションの詳細については、「接続ファクトリの作成」を参照してください。
アプリケーションでは、Java Naming and Directory Interface (JNDI) を使用して接続ファクトリをルックアップし、JMS サーバとの通信を確立するための接続を作成します。各 JMS サーバでは、複数の送り先に対するリクエストが処理されます。送り先へのリクエストが送信される WebLogic Server インスタンスが、接続ファクトリのホストであって、JMS サーバまたは送り先のホストではない場合、リクエストは接続ファクトリによって、JMS サーバと送り先のホストになっている適切な WebLogic Server インスタンスに転送されます。
管理者は、クラスタ内のさまざまなサーバ上の複数の JMS サーバにユニークな名前が付けられているかぎり、それらの JMS サーバをコンフィグレーションして、JMS キューまたはトピック リソースを割り当てることができます。アプリケーションでは、Java Naming and Directory Interface (JNDI) を使用して接続ファクトリをルックアップし、JMS サーバとの通信を確立するための接続を作成します。各 JMS サーバでは、複数の送り先に対するリクエストが処理されます。JMS サーバで処理されない送り先へのリクエストは、適切な WebLogic Server インスタンスに転送されます。JMS サーバのデプロイメントとコンフィグレーションの詳細については、「JMS サーバのコンフィグレーション」を参照してください。
単一の WebLogic ドメイン環境または複数ドメイン環境で JMS オブジェクトおよびリソース (JMS サーバ、JMS モジュール、JMS リソースなど) がクラスタ化環境で動作するようにコンフィグレーションする際には、いくつかのネーミング要件があります。詳細については、「JMS コンフィグレーションのネーミング要件」を参照してください。
分散送り先リソースは、単一の論理的な送り先としてクライアントからアクセス可能な 1 つの送り先セット (キューまたはトピック) です (たとえば分散トピックは独自の JNDI 名を持ちます)。この単位のメンバーは通常、クラスタ内の複数のサーバに分散されており、各メンバーは個々の JMS サーバに属しています。分散送り先を使用するアプリケーションは、単純な送り先を使用するアプリケーションより可用性が高くなります。WebLogic Server は、クラスタ内の分散送り先のメンバーのためのロード バランシングとフェイルオーバの機能を備えているからです。詳細については、「分散送り先のコンフィグレーション」を参照してください。
WebLogic JMS は、サーバによってホストされるすべてのサービスを別のマシンに移行するためのサーバ移行に組み込まれるのに加え、JMS サーバとそのすべての送り先をクラスタ内の別の WebLogic Server に移行するためのサービス移行フレームワークにも組み込まれます。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への対応としての移行も含まれます。JMS サーバの移行の詳細については、「JMS サーバの移行可能な対象のコンフィグレーション」を参照してください。
クラスタ環境で WebLogic JMS を使用する場合は、以下のガイドラインに従います。
接続ファクトリのコンフィグレーション属性の詳細については、「接続ファクトリ リソース」を参照してください。
JMS サーバの移行可能な対象の詳細については、「JMS サーバの移行可能な対象のコンフィグレーション」を参照してください。JMS サーバのコンフィグレーション属性の詳細については、「JMS サーバのコンフィグレーション」を参照してください。
注意 : 同じ送り先を複数の JMS サーバにデプロイすることはできません。また、1 つの JMS サーバを複数の WebLogic Server にデプロイすることもできません。
このリリースの WebLogic Server は、サーバ レベル (サーバ インスタンス) での移行をサポートします。WebLogic Server がホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「Server Migration」を参照してください。
クラスタ化環境では、分散送り先をコンフィグレーションすることによって 1 つのサーバで障害が発生した場合でもサービスを継続できます。分散送り先のキューおよびトピック メンバーは通常、クラスタ内の複数のサーバに分散され、各メンバーは個々の JMS サーバに属します。さらに、移行可能サービスの機能を実装すると、JMS のような「必ず 1 回」のサービスによって、クラスタ内の依存するアプリケーションに対するシングル ポイント障害が発生しなくなります。
また、高可用性クラスタ化ソフトウェア (VERITASTM Cluster Server など) を実装することをお勧めします。これにより、BEA WebLogic Server ベースのアプリケーションに、統合された使いやすいソリューションがもたらされます。推奨される高可用性ソフトウェア ソリューションには、上記の他にも、SunCluster や IBM HACMP などがあります。
手動フェイルオーバの実行の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic Server の障害からの回復」を参照してください。
注意 : このリリースの WebLogic Server は、サーバ レベル (サーバ インスタンス) での移行もサポートします。WebLogic Server がホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「Server Migration」を参照してください。
シングルトン サービスとしての JMS は、クラスタ内のすべてのサーバでアクティブというわけではありません。代わりに、データの一貫性を保持するためにクラスタ内の単一サーバに固定されます。JMS や JTA トランザクション回復サービスのようなシングルトン サービスによってクラスタ内の依存するアプリケーションに対してシングル ポイント障害が発生しないように、シングルトン サービスを、移行できる対象リストに属する任意のサーバ インスタンスに移行できます。
WebLogic JMS は、この移行フレームワークを活用して、管理者が Administration Console で JMS サーバの移行可能対象を指定できるようにします。いったん適切にコンフィグレーションすると、JMS サーバとそのすべての送り先をクラスタ内の別の WebLogic Server へ移行できます。これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。移行には、スケジューリング済み移行のほかに、クラスタ内の WebLogic Server の障害に対応して行われる手動移行が含まれます。
シングルトン サービスの移行の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「Service Migration」を参照してください。
クラスタ環境で JMS サーバを移行可能なサービスにするには、以下の作業が必要です。
注意 : 移行された JMS サーバをホストすることになる移行可能対象サーバのインスタンスには、ユニークなリスン アドレス値を設定する必要があります。ユニークな値を設定しない場合、移行は失敗します。
注意 : 移行可能な対象サーバが起動すると、クラスタ内のユーザが選んだサーバ上で、JMS サーバも自動的に起動します。
注意 : 対象サーバ インスタンスが既に JMS サーバとその分散送り先メンバーをホストしているときでも、JMS サーバの分散送り先メンバーはクラスタ内の別のサーバ インスタンスへ移行できます。分散送り先のフェイルオーバの詳細については、「分散送り先のフェイルオーバ」を参照してください。
JMS サーバは、「フェイルオーバの場合」で説明したように、サーバ レベル移行機能の一部として、または「JMS サービス移行のコンフィグレーション手順」で説明したように、JMS や JTA トランザクション回復サービスのような移行可能サービスを対象としたサービス レベル移行の一部として移行できます。しかし、データの整合性を保持するために、クラスタ内の移行可能な対象サーバで使用できる共有ディスクで、ファイルベースの永続ストア (デフォルトまたはカスタム) をコンフィグレーションする必要があります。
永続ストアの高可用性の詳細については、『WebLogic Server 環境のコンフィグレーション』の「WebLogic 永続ストアの使い方」を参照してください。
WebLogic Server パス サービスは、分散キュー メンバーまたはストア アンド フォワード パスにメッセージを固定することによってメッセージ順序単位内のメッセージ グループとメッセージング リソースの間のマッピングを格納するための永続マップです。メッセージ順序単位の詳細については、『WebLogic JMS プログラマーズ ガイド』の「Using Message Unit-of-Order」を参照してください。
パス サービスのコンフィグレーションについては、Administration Console オンライン ヘルプの「パス サービスのコンフィグレーション」を参照してください。
メッセージ順序単位とパス サービス ベースのルーティングを実装する際には、以下のことに留意してください。
JMSOrderException を送出します。この例外が送出されるのは、JMS メッセージ システムが必要なサービス品質を満たすことができないからです。特定の順序単位に対しては、1 つの分散送り先メンバーだけがメッセージを消費できます。 JMSOrderException が送出される場合があります。
WebLogic JMS では、外部 (サードパーティ) JMS プロバイダをローカル WebLogic Server JNDI ツリー内で参照できます。外部サーバ リソースを使用することで、外部の JMS プロバイダを即座にマップして、関連付けられた接続ファクトリと送り先をローカル JMS オブジェクトのように WebLogic JNDI ツリーに表示できます。また、別のクラスタまたはドメインにある WebLogic Server のリモート インスタンスをローカル WebLogic JNDI ツリー内で参照することもできます。
注意 : 外部プロバイダ機能を使用して WebLogic Server のクラスタやドメインを参照するには、クラスタ化された JMS ライセンスが必要です。このライセンスにより、接続ファクトリや送り先を別のサーバ インスタンスに配置することが可能になります。クラスタ化された有効な JMS ライセンスを取得していない場合は、BEA の販売代理店までお問い合わせください。
リモートおよび外部 JMS プロバイダの統合については、『WebLogic JMS プログラマーズ ガイド』の「Enhanced 2EE Support for Using WebLogic JMS With EJBs and Servlets」を参照してください。
以下の節では、外部サーバの機能と、リモート MQSeries JNDI プロバイダにアクセスするためのサンプル コンフィグレーションについて説明します。
外部 JMS サーバがデプロイされると、WebLogic Server JNDI にローカルの接続ファクトリと送り先のオブジェクトが作成されます。外部接続ファクトリまたは送り先のオブジェクトがローカル サーバでルックアップされると、そのオブジェクトはリモート JNDI ディレクトリで実際のルックアップを実行し、そのディレクトリから外部オブジェクトが返されます。
この方法を使用すると、複数の WebLogic メッセージング ブリッジ送り先のコンフィグレーションが簡単になります。外部サーバが、JNDI 初期コンテキスト ファクトリおよび接続 URL のコンフィグレーションの詳細をメッセージング ブリッジ送り先のコンフィグレーションの外側に移すからです。外部接続ファクトリおよび送り先 JNDI 名をオブジェクトごとに指定するだけで済みます。
メッセージ ブリッジのコンフィグレーションの詳細については、「WebLogic メッセージング ブリッジのコンフィグレーションと管理」を参照してください。
また、このコンフィグレーションの簡素化は、WebLogic JMS での WebLogic サーブレット、EJB、およびメッセージ駆動型 Bean (MDB) のコンフィグレーションにも当てはまります。たとえば、MDB の weblogic-ejb-jar.xml ファイルではローカル JNDI 名を指定でき、外部 JMS サーバを使用して MDB がメッセージを受け取る場所を制御できます。具体的には、ある JMS 送り先およびサーバと通信するためにある環境で MDB をデプロイし、同じ weblogic-ejb-jar.xml ファイルを別のサーバにデプロイして、それを別の JMS 送り先と通信させることができます。その際、weblogic-ejb-jar.xml ファイルを復元して編集する必要はありません。
外部サーバは、WebLogic JMS サーバの外部の JNDI プロバイダです。外部サーバには、ローカル WebLogic Server インスタンスがリモート JNDI プロバイダにアクセスするための情報が保持されています。これにより、1 つの JNDI ディレクトリに対して複数の外部接続ファクトリと送り先のオブジェクトを定義できます。
WebLogic Server Administration Console を使用すると、システム モジュール内の外部サーバ リソースをコンフィグレーション、変更、対象指定、および削除できます。外部サーバに関するタスクの詳細については、Administration Console オンライン ヘルプの「外部サーバのコンフィグレーション」を参照してください。
一部の外部サーバ オプションは、動的にコンフィグレーションできます。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての外部サーバ オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「ForeignServerBean」を参照してください。
外部サーバを定義したら、接続ファクトリおよび送り先のオブジェクトをコンフィグレーションできます。各外部サーバに対して、1 つまたは複数の接続ファクトリおよび送り先 (キューまたはトピック) をコンフィグレーションできます。
外部接続ファクトリには、リモート JNDI プロバイダの接続ファクトリの JNDI 名、ローカル WebLogic Server JNDI ツリー内でその接続ファクトリにマップされる JNDI 名、およびユーザ名とパスワード (省略可能) が定義されます。
外部接続ファクトリは、親の外部サーバの割り当て先となる各 WebLogic Server インスタンスに対してレプリケートされていない JNDI オブジェクトを作成します (クラスタ内の各ノードに JNDI オブジェクトを作成するには、クラスタに外部サーバを割り当てます)。
外部送り先は、キューまたはトピックを表します。外部送り先には、外部 JNDI プロバイダでルックアップされる送り先の JNDI 名、およびローカル WebLogic Server で送り先がマップされる JNDI 名が保持されます。外部送り先がローカル サーバでルックアップされる場合、ルックアップはリモート JNDI ディレクトリで実行され、そのディレクトリから送り先オブジェクトが返されます。
次の表に、リモート MQSeries JNDI プロバイダにアクセスする場合のサンプル コンフィグレーションを示します。
分散送り先リソースは、単一の論理的な送り先としてクライアントからアクセス可能な 1 つの送り先セット (キューまたはトピック) です (たとえば分散トピックは独自の JNDI 名を持ちます)。この単位のメンバーは通常、クラスタ内の複数のサーバに分散されており、各メンバーは個々の JMS サーバに属しています。分散送り先を使用するアプリケーションは、単純な送り先を使用するアプリケーションより可用性が高くなります。WebLogic JMS は、クラスタ内の分散送り先のメンバーのためのロード バランシングとフェイルオーバの機能を備えているからです。
注意 : 分散送り先機能を使用するには、クラスタ化 JMS ライセンスが必要です。このライセンスにより、送り先メンバーを複数の WebLogic Server インスタンスに配置できるようになります。クラスタ化された有効な JMS ライセンスを取得していない場合は、BEA の販売代理店までお問い合わせください。
以降の節では、分散送り先の作成、モニタ、およびロード バランシングを行う方法について説明します。
このリリースでは、新しいタイプの分散送り先である共通分散送り先 (UDD) が追加されました。これによって、分散送り先アプリケーションの管理とデプロイメントが大幅に簡素化されます。旧リリースでは、分散送り先を作成するには、多くの場合、物理的な送り先が分散送り先のメンバーとして機能するように手動でコンフィグレーションする必要がありました。この方法は、追加のメッセージ負荷または容量を持つメンバーを作成できるといった柔軟性を備えていました。しかし、このような重み設定された分散送り先はクラスタ内で一貫してデプロイされなかったため、管理上およびアプリケーション上の問題が発生しました。このタイプの分散送り先を、今後は「重み設定された分散送り先」 (WDD) と呼びます。
共通分散送り先を使用すると、送り先のメンバーを作成したり指定したりする必要がなくなります。代わりに、WebLogic Server によって、JMS モジュールが割り当てられる JMS サーバ上に必要なメンバーが均等に作成されます。この機能によって、すべての分散送り先のパラメータ (重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ) を一貫してコンフィグレーションできます。
分散送り先メンバーを手動で調整する場合は、従来の重み設定された分散送り先の機能も依然として使用できます。ただし、クラスタ内で一貫してデプロイされていない重み設定された分散送り先に起因して起こり得る管理上およびアプリケーションの問題を回避するため、共通分散送り先をコンフィグレーションすることをお勧めします。
アプリケーションと一緒に分散送り先を使用する方法の詳細については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先の使用」を参照してください。
WebLogic Server Administration Console を使用すると、システム モジュール内の UDD リソースをコンフィグレーション、変更、対象指定、および削除できます。[メンバーの均等割り当て] チェック ボックスをチェックされた状態のままにしておくと、選択した JMS サーバ、対象サーバ上のすべての JMS サーバ、またはクラスタ上で、自動的に送り先メンバーが均等に作成されます。
共通分散送り先に関するタスクの詳細については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
共通分散送り先オプションの中には、動的にコンフィグレーションできるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての共通分散送り先オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の以下の項目を参照してください。
注意 : エラー送り先は関連付けられている送り先と同じ JMS サーバの対象でなければならないため、分散送り先と一緒に使用することはできません。分散送り先のメンバーは、複数の JMS サーバの対象として指定されるからです。
ドメイン内の特定の JMS サーバのみにデプロイできるスタンドアロンのキューとトピックとは異なり、UDD は 1 つまたは複数の JMS サーバ、1 つまたは複数の WebLogic Server インスタンス、または 1 つのクラスタの対象として指定できます。UDD の目的は、そのメンバーをドメイン内の複数の JMS サーバに分散することだからです。たとえば、UDD をクラスタの対象として指定した場合、そのクラスタ内の各 JMS サーバでメンバーが均等にコンフィグレーションされます。
警告 : UDD の対象を変更すると、メンバー送り先が削除され、メッセージが失われてしまう可能性があります。
また、UDD をコンフィグレーションするときにサブデプロイメント グループを使用して、特定のリソースを分散メンバーにリンクできます。たとえば、jmssysmod-jms.xml というシステム モジュールが、コンフィグレーション済みの JMS サーバを持つ wlserver1、wlserver2、wlserver3 という 3 つの WebLogic Server インスタンスの対象として指定されている場合に、1 つの共通分散キューと接続ファクトリを各サーバ インスタンスの対象として指定するとします。この場合、共通分散キューと接続ファクトリを 1 つのサブデプロイメント、servergroup としてグループ化すれば、これらのリソースは常にこれらのサーバ インスタンスにリンクされます。
次に、サブデプロイメント リソース servergroup を jmssysmod-jms.xml でどのように指定するのかを示します。
<weblogic-jms xmlns="http://www.bea.com/ns/weblogic/90">
<connection-factory name="connfactory">
<sub-deployment-name>servergroup</sub-deployment-name>
<jndi-name>jms.connectionfactory.CF</jndi-name>
</connection-factory>
<uniform-distributed-queue name="UniformDistributedQueue">
<sub-deployment-name>servergroup</sub-deployment-name>
<jndi-name>jms.queue.UDQ</jndi-name>
<forward-delay>10</forward-delay>
</uniform-distributed-queue>
</weblogic-jms>
次に、ドメインのコンフィグレーション ファイルでサブデプロイメント servergroup をどのように対象指定するかを示します。
<jms-system-resource>
<name>jmssysmod-jms</name>
<target>cluster1,</target>
<sub-deployment>
<name>servergroup</name>
<target>wlserver1,wlserver2,wlserver3</target>
</sub-deployment>
<descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
</jms-system-resource>
共通分散送り先でのメッセージの生成、挿入、および消費処理は、プログラム的に (JMX と実行時 MBean API を使用)、または管理的に (Administration Console を使用) 休止または再開できます。外部リソースに障害が発生したとき、JMS サブシステムがメッセージの受け付けと配信 (および再配信) を継続すると、システムに過度の負荷がかかることがあります。しかし、メッセージ処理を休止 (および再開) することで、外部リソースの障害発生時の JMS サブシステムの動作を制御できます。
休止と再開の機能の詳細については、「送り先でのメッセージ処理の休止と再開」を参照してください。
共通分散送り先メンバーの実行時統計は、Administration Console を使用してモニタできます。詳細については、「JMS 統計のモニタ」を参照してください。
WebLogic Server Administration Console を使用すると、システム モジュール内の WDD リソースをコンフィグレーション、変更、対象指定、および削除できます。分散トピックまたはキューをコンフィグレーションする場合、[メンバーの均等割り当て] チェック ボックスのチェックをはずすことによって、既存のキューとトピックを手動で選択して分散送り先に追加し、分散送り先メンバーの重みを調整できます。
重み設定された分散送り先に関するタスクの詳細については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
重み設定された分散送り先オプションの中には、動的にコンフィグレーションできるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての重み設定された分散送り先オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の以下の項目を参照してください。
UDD とは異なり、WDD メンバーは Administration Console または実行時 MBean でモニタできません。また、WDD メンバーはドメイン内の JMS サーバまたは WebLogic Server インスタンスに均等に割り当てることはできません。代わりに、これらのインスタンス上で新しい WDD メンバーを手動でコンフィグレーションし、手動で WDD に追加する必要があります。
JMS は分散送り先を使用して、複数の送り先にメッセージの負荷を分散し、バランスを取ることができます。これによって、リソースがさらに効率的に利用され、応答時間が改善されます。JMS のロード バランシング アルゴリズムでは、メッセージの送信先となる物理的送り先に加えて、コンシューマの割り当て先の物理的送り先も決定されます。
WebLogic JMS は、任意の分散送り先セットに含まれている複数の物理的送り先間でメッセージのロード バランシングを行うための 2 種類のアルゴリズムをサポートしています。これらのロード バランシング オプションのどちらかを選択するには、Adminstration Console で分散トピックまたは分散キューをコンフィグレーションします。
ラウンドロビン アルゴリズムでは、WebLogic JMS は分散送り先内の物理的送り先の序列を管理します。メッセージの負荷は、WebLogic Server コンフィグレーション (config.xml) ファイルに定義されている順番で、一度に 1 つずつ物理的送り先に分散されます。各 WebLogic Server は、同一の序列を維持しますが、その序列内の位置は異なります。特定の分散送り先を使用して単一のサーバ内で複数のスレッドを実行すると、スレッドからメッセージが生成されるたびに、メンバーが割り当てられている物理的送り先に関連して、これらのスレッドが互いに影響し合うことになります。ラウンドロビンはデフォルトのアルゴリズムで、コンフィグレーションの必要はありません。
重み設定された分散送り先のみの場合、セット内の物理的送り先のいずれかに重みが割り当てられている場合、それらの物理的送り先は序列内に複数回発生します。
ランダム分散アルゴリズムでは、物理的送り先に割り当てられている重みを使用して、一連の物理的送り先の重み付き送り先を計算します。メッセージの負荷は、疑似ランダム的に送り先にアクセスすることで、物理的送り先に分散されます。短期的には、負荷は重みには直接比例しません。長期的には、極限に近い分散が行われます。純粋なランダム分散は、重みすべてに同じ値を設定することで達成できます。この値は通常 1 です。
メンバーが追加または削除された (管理者が行うか、WebLogic Server がシャットダウンまたは再起動した結果発生したもの) 場合は、分散を再計算する必要があります。ただし、このようなイベントは頻繁に発生せず、計算は通常単純で、O(n) 時間で実行されます。
アプリケーションがコンシューマを作成するときは、送り先を指定する必要があります。その送り先が分散送り先を表す場合、WebLogic JMS ではコンシューマのメッセージ受信元となる物理的送り先を見つける必要があります。どの送り先メンバーを使用するかは、「ロード バランシング オプション」に説明されているロード バランシング アルゴリズムのいずれかを用いて選択します。選択は一度だけ、つまりコンシューマが作成されたときに行います。その後、コンシューマはそのメンバーのみからメッセージを受信するようになります。
プロデューサがメッセージを送信するとき、WebLogic JMS はメッセージが送信される送り先を確認します。送り先が分散送り先である場合は、メッセージの送信先が WebLogic JMS によって決定されます。つまり、プロデューサは「ロード バランシング オプション」で説明されているロード バランシング アルゴリズムのいずれかに従って、送り先のメンバーのいずれかに送信します。
プロデューサはメッセージを送信するたびにこのような決定を行います。ただし、コンシューマとプロデューサ間の序列の保証が脅かされることはありません。コンシューマのロード バランシングがいったん行われると、コンシューマは単一の送り先メンバーに固定されるためです。
注意 : プロデューサが永続メッセージを分散送り先に送信しようとした場合、永続ストアを利用している分散メンバーにまずメッセージが転送されるよう、あらゆる努力をします。ただし、分散メンバーがいずれも永続ストアを利用していない場合でも、メッセージは選択されているロードバランシング アルゴリズムに従って、メンバーのいずれかに送信されます。
「ロード バランシング オプション」に説明されているアルゴリズムに加えて、WebLogic JMS では送り先のインスタンスを選択するときに次のヒューリスティックが使用されます。
トランザクション セッション内で複数のメッセージを作成するときは、作成されたメッセージすべてを同じ WebLogic Server に送信しようとします。つまり、セッションが単一の分散送り先に複数のメッセージを送信した場合は、すべてのメッセージが同じ物理的送り先に転送されます。セッションによって複数のメッセージが複数の異なる分散送り先に送信された場合は、同じ WebLogic Server がサービスを提供する一連の物理的送り先が選択されるようになります。
接続ファクトリの [サーバ アフィニティを有効化] パラメータでは、分散送り先内にある複数のメンバー送り先の間でコンシューマまたはプロデューサをロード バランシングしている WebLogic Server が、同じ WebLogic Server 上で実行されている他のローカル送り先メンバーの間でロード バランシングを最初に試みるかどうかを定義します。
注意 : [サーバ アフィニティを有効化] 属性は、キュー ブラウザには影響しません。したがって、[サーバ アフィニティを有効化] が有効になっている場合でも、分散キューに作成されたキュー ブラウザをリモート分散キュー メンバーに固定できます。
接続ファクトリでサーバ アフィニティを無効化するには、次の手順に従います。
[サーバ アフィニティを有効化] の設定が分散送り先のメンバー間のロードバランシングにどのように影響するかについては、「サーバ アフィニティを有効化した場合の分散送り先ロード バランシングへの影響」を参照してください。
複数のリモートの物理的キュー間でコンシューマのロード バランシングを行う場合、1 つまたは複数のキューにコンシューマがないとき、それらのキューだけがロード バランシングの対象となります。セット内の物理的キューすべてに少なくとも 1 つのコンシューマが含まれるようになると、標準のアルゴリズムが適用されます。
また、プロデューサがメッセージを送信するとき、コンシューマのないキューはメッセージ作成の対象にはなりません。ただし、任意のキューのインスタンスのいずれにもコンシューマが含まれていない場合を除きます。
分散送り先でメッセージの生成または挿入が休止された場合、それらはメッセージ生成の対象とは見なされません。同様に、分散送り先でメッセージの消費が休止された場合、それらはメッセージ生成の対象とは見なされません。
送り先でのメッセージ処理の休止については、「送り先でのメッセージ処理の休止と再開」を参照してください。
アプリケーションは、個別の物理的送り先に直接アクセスすることで、ロード バランシングを回避できます。つまり、物理的送り先に JNDI 名がない場合でも、createQueue() メソッドまたは createTopic() メソッドを使用して参照することができます。
共通および重み設定された分散送り先に直接アクセスする方法の詳細については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先メンバーへのアクセス」を参照してください。
アプリケーションにおいて、分散送り先を使用して、複数の物理的送り先間でプロデューサやコンシューマを分散、つまりバランスさせることは行っても、メッセージが作成されるたびにロード バランシングの決定を行いたくない場合は、[ロード バランスを有効化] パラメータを無効化した状態で接続ファクトリを使用します。分散送り先においてメッセージの負荷が適正に分散されるようにするには、プロデューサによって使用される初期の物理的な送り先 (キューまたはトピック) が、物理的な送り先メンバーによって常にランダムに選択される必要があります。
接続ファクトリでのロード バランシングを無効化するには、次の手順に従います。
注意 : 実装によっては、[サーバ アフィニティを有効化] 属性の設定が分散送り先のロード バランシングの環境設定に影響することがあります。詳細については、「サーバ アフィニティを有効化した場合の分散送り先ロード バランシングへの影響」を参照してください。
匿名プロデューサ (作成時に送り先を指定しないプロデューサ) は、送り先を切り替えるたびにロード バランシングされます。同じ送り先を使用し続けると、匿名でないプロデューサと同じ法則 (前述) が適用されます。
表 4-2 では、JMS 接続ファクトリの [サーバ アフィニティを有効化] パラメータの設定が、分散送り先メンバーのロード バランシングの優先権に与える影響について説明します。優先順位は、操作のタイプ、および恒久サブスクリプションまたは永続メッセージが含まれているかどうかによって異なります。
分散送り先の [サーバ アフィニティを有効化] パラメータは、ClusterMBean の [デフォルトのロード バランス アルゴリズム] 属性によって提供されるサーバ アフィニティとは異なります。後者は、JMS 接続ファクトリでクライアント接続用の初期コンテキスト アフィニティを作成するためにも使用されます。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「EJB と RMI オブジェクトのロード バランシング」および「クライアント接続の初期コンテキスト アフィニティとサーバ アフィニティ」を参照してください。
|
|
||
|
|
サービス移行機能を利用するクラスタ化された JMS 実装では、JMS サーバとその分散送り先メンバーを、クラスタ内の別の WebLogic Server インスタンスに手動で移行できます。サービスの移行は、定期的なシステム保守の際や、クラスタ内のサーバに障害が発生した際に実施できます。
ただし、移行先の WebLogic Server に物理的送り先すべてを持つ JMS サーバが既にホストされている場合もあります。そのような場合には、同じ WebLogic Server インスタンスが単一の分散送り先について 2 つの物理的送り先をホストするような状況が生じます。WebLogic Server インスタンスはその分散送り先に対して複数の物理的送り先をホストできるため、これは短期的には許容できますが、このような状況でのロード バランシングは効果が半減します。
このような状況では、移行先の WebLogic Server インスタンス上の JMS サーバは独立して動作します。これは、2 つの送り先インスタンスの結合や、1 つのインスタンスの無効化を避けるためです。このようなことが発生すると、メッセージが長時間使用できなくなる場合があります。ただし、長期的な目的は、移行された JMS サーバをクラスタ内のさらに別の WebLogic Server インスタンスに最終的に再移行することにあります。
JMS の移行可能な対象の詳細については、「JMS サーバの移行可能な対象のコンフィグレーション」を参照してください。
JMS プロデューサおよび JMS コンシューマの JMS 接続をホストしているサーバ インスタンスに障害が発生した場合、これらの接続を使用しているすべてのプロデューサとコンシューマが閉じられ、クラスタ内の別のサーバ インスタンスでは再作成されません。また、JMS 送り先をホストしているサーバ インスタンスに障害が発生した場合、その送り先のすべての JMS コンシューマが閉じられ、クラスタ内の別のサーバ インスタンスでは再作成されません。
キュー プロデューサが作成された分散キュー メンバーに障害が発生したが、プロデューサの JMS 接続が存在する WebLogic Server インスタンスがまだ実行されている場合、プロデューサは閉じられず、WebLogic JMS はロード バランシング オプションが有効になっているかどうかに関係なく別の分散キュー メンバーにフェイルオーバします。
WebLogic Server の障害から回復するための手順については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic Server の障害からの回復」を参照してください。
|
|
|