|
|
以下の節では、クラスタ化環境での分散送り先などの拡張 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 がホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細については、『クラスタの使用』の「サーバ全体の移行」を参照してください。
また、「必ず 1 回」のサービスとして、WebLogic JMS はクラスタ化された環境のために WebLogic Server に実装されている移行フレームワークを活用します。これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。移行には、予定されている手動移行のほかに、クラスタ内の WebLogic Server の障害に対応して行われる自動移行があります。詳細については、「JMS 関連サービスの移行」を参照してください。
クラスタ用にコンフィグレーションしたロード バランシング アルゴリズム (ラウンドロビン アフィニティ、重みベース アフィニティ、またはランダム アフィニティ) は、JMS クライアント接続のためのサーバ アフィニティを提供します。JMS アプリケーションから指定したサーバ インスタンスに接続できる場合、JMS は同じサーバ インスタンスとの新しい JMS 接続を確立しようとします。サーバ アフィニティの詳細については、『クラスタの使用』の「クラスタでのロード バランシング」を参照してください。
WebLogic クラスタの機能とメリットについては、『クラスタの使用』の「WebLogic Server のクラスタ化について」を参照してください。
管理者は、クラスタ内の各サーバ インスタンスのデフォルト接続ファクトリを使用するか、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 は、クラスタ内の分散送り先のメンバーのためのロード バランシングとフェイルオーバの機能を備えているからです。詳細については、「分散送り先リソースのコンフィグレーション」を参照してください。
JMS サービスは、サーバ全体の移行 (サーバでホストされるすべてのサービスを別のマシンに移行する場合) だけでなく、シングルトン サービスの移行フレームワークに組み込むこともできます。したがって、たとえばサーバの障害に対処する場合や定期的な保守を実施する場合に、JMS サーバとそのすべての送り先をクラスタ内の別の WebLogic Server に移行することも可能です。これには、予定されている手動移行のほかに自動移行も含まれます。JMS サービスの移行の詳細については、「JMS 関連サービスの移行」を参照してください。
クラスタ環境で WebLogic JMS を使用する場合は、以下のガイドラインに従います。
接続ファクトリのコンフィグレーション属性の詳細については、「接続ファクトリのコンフィグレーション」を参照してください。
移行可能な JMS サーバの対象指定の詳細については、「JMS 関連サービスの移行」を参照してください。JMS サーバのコンフィグレーション属性の詳細については、「JMS サーバのコンフィグレーション」を参照してください。
| 注意 : | 同じ送り先を複数の JMS サーバにデプロイすることはできません。また、1 つの JMS サーバを複数の WebLogic Server にデプロイすることもできません。 |
サーバまたはネットワークの障害が発生した場合、JMS メッセージ プロデューサおよびコンシューマ オブジェクトは (使用可能なものがあれば) 別のサーバ インスタンスに透過的にフェイルオーバを試みます。WebLogic Server リリース 9.1 以降では、既存のクライアント コードを手動でコンフィグレーションまたは変更しなくても、WebLogic JMS メッセージ プロデューサは、使用可能なサーバ インスタンスへ自動的に再接続しようとします。WebLogic Server リリース 9.2 では、Administration Console または WebLogic JMS API を利用して、使用可能なサーバ インスタンスに自動的に再接続を試行するように WebLogic JMS メッセージ コンシューマをコンフィグレーションできます。『WebLogic JMS プログラマーズ ガイド』の「JMS クライアントの自動フェイルオーバ」を参照してください。
| 注意 : | WebLogic Server リリース 90 より前の JMS クライアント アプリケーションについては、『WebLogic JMS プログラマーズ ガイド』の「WebLogic Server 9.0 以前のリリースでの障害に関するプログラミングの考慮事項」を参照してください。 |
さらに、サービスの自動移行機能を実装すると、JMS のような「必ず 1 回」のサービスによって、クラスタ内の依存するアプリケーションに対するシングル ポイント障害が発生しなくなります。詳細については、「JMS 関連サービスの移行」を参照してください。WebLogic Server では、サーバ レベルの移行、つまり、サーバ インスタンス全体の移行もサポートされています。また、サーバ インスタンスがホストするすべてのサービスを自動または手動で別のマシンに移行できます。『クラスタの使用』の「サーバ全体の移行」を参照してください。
クラスタ化環境では、分散送り先をコンフィグレーションすることによって 1 つのサーバで障害が発生した場合でもサービスを継続できます。分散送り先のキューおよびトピック メンバーは通常、クラスタ内の複数のサーバに分散され、各メンバーは個々の JMS サーバに属します。「クラスタ内での分散送り先」を参照してください。
また、高可用性クラスタ化ソフトウェア (VERITAS Cluster Server など) を実装することをお勧めします。これにより、WebLogic Server ベースのアプリケーションに、統合された使いやすいソリューションがもたらされます。推奨される高可用性ソフトウェア ソリューションには、上記の他にも IBM HACMP などがあります。
JMS 関連サービスはシングルトン サービスであるため、クラスタ内のすべてのサーバ インスタンスでアクティブになるわけではなく、データの一貫性を保持するためにクラスタ内の単一サーバに固定されます。シングルトン JMS サービスが原因で、クラスタ内の依存するアプリケーションに対するシングル ポイント障害が発生しないようにするため、JMS サービスを移行可能対象リスト内の任意のサーバ インスタンスに自動で移行できるように WebLogic Server をコンフィグレーションできます。ホスト サーバに障害が発生した場合は、移行可能な JMS サービスも手動で移行できます。また、定期的なサーバ メンテナンスを実施する前に、JMS サービスを手動で移行することも可能です。
移行可能対象を使用すると、高可用性のための JMS 関連サービスをコンフィグレーションできます。移行可能対象とは、クラスタ内のサーバから別のサーバに移行できる特別な対象です。つまり、移行可能対象を使用することで、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能対象を移行すると、その対象によってホストされているすべてのサービスが移行されます。
『クラスタの使用』の「サービスの移行フレームワークについて」を参照してください。
管理者は、ヘルス モニタ サブシステムを活用することで、障害が発生した現在のホスト サーバでホストされている JMS サービスが正常に動作しているサーバに自動的に移行するよう、移行可能な対象をコンフィグレーションできます。JMS 関連サービスの自動移行をコンフィグレーションする方法については、『クラスタの使用』の「JMS 関連サービスの自動移行をコンフィグレーションする手順」を参照してください。
ホスト サーバで障害が発生した場合や、サーバ メンテナンスを実施する前には、JMS 関連サービスを正常なサーバに手動で移行できます。JMS 関連サービスの手動移行をコンフィグレーションする方法については、『クラスタの使用』の「JMS 関連サービスの手動移行をコンフィグレーションする手順」を参照してください。
「フェイルオーバの場合」で説明したように、JMS サービス (カスタム永続ストアを含む) は、「サーバ全体」の移行機能の一部として移行したり、移行可能サービスを対象とした「サービス レベル」の移行の一部として移行したりできます。ただし、移行可能な JMS 関連サービスで、デフォルトの永続ファイル ストアを使用することはできません。したがって、カスタムのファイル ストアまたは JDBC ストアをコンフィグレーションし、関連付けた JMS サーバまたは SAF エージェントと同じ移行可能対象にそのストアを対象指定する必要があります (パス サービスの場合は、専用のカスタム ストアと移行可能対象を使用するのがベスト プラクティスです)。
移行可能なカスタム ファイル ストアは、クラスタ内の移行可能な対象サーバから使用できる共有ディスクにコンフィグレーションしたり、移行前/移行後スクリプトを使用してバックアップ サーバ対象に移行したりできます。永続ストアの移行の詳細については、『クラスタの使用』の「JMS サービスで使用できるカスタム ストア」を参照してください。
WebLogic Server パス サービスは、JMS メッセージ順序単位内のメッセージのグループから、クラスタ内のメッセージ リソースへの、マッピングの保持に使用できる永続マップです。サーブレットをホストするクラスタのメンバー、分散キュー メンバー、またはストア アンド フォワード エージェントにメッセージを固定することによって、順序付けを実現できます。パス サービスは、クラスタごとに 1 つずつコンフィグレーションします。メッセージ順序単位機能の詳細については、『WebLogic JMS プログラマーズ ガイド』の「メッセージ順序単位の使用」を参照してください。
クラスタ内でのパス サービスのコンフィグレーションについては、Administration Console オンライン ヘルプの「パス サービスのコンフィグレーション」を参照してください。
クラスタのパス サービスは、高可用性の確保を目的として、自動または手動によるサービス移行用の移行可能対象に対象指定できます。ただし、移行可能なパス サービスではデフォルト ストアを使用できないため、カスタム ストアをコンフィグレーションし、同じ移行可能対象に対象指定する必要があります。さらに、ベスト プラクティスとしては、その移行可能対象のユーザを、パス サービスとそのカスタム ストアに限定する必要があります。『クラスタの使用』の「サービスの移行フレームワークについて」を参照してください。
メッセージ順序単位とパス サービス ベースのルーティングを実装する際には、以下のことに留意してください。
JMSOrderException を送出する。この例外が送出されるのは、JMS メッセージ システムが必要なサービス品質を満たすことができないからです。特定の順序単位に対しては、1 つの分散送り先メンバーだけがメッセージを消費できます。
DXQ1 は、Q1 と Q2 というメンバーを持つ分散キューです。また DXQ1 は Fred という名前の順序単位を持ち、パス サービスによって Q2 メンバーにマップされています。
Fred という順序単位名のキュー Q3 が存在するとします。Q3 が DXQ1 に追加された場合、分散キューの中に同じ順序単位名の送り先が 2 つ存在することになります。Q3 と DXQ1 は同じ順序単位名 Fred を共有しますが、各キューのルートと送り先はユニークなので、サーバは送り先ごとに適切なメッセージ順序付けを行うことができます。
JMSOrderException が送出される場合があります。
WebLogic JMS では、サードパーティ JMS プロバイダをローカル WebLogic Server JNDI ツリー内で参照できます。JMS モジュール内で外部サーバ リソースを使用することで、外部の JMS プロバイダを即座にマップして、関連付けられた接続ファクトリと送り先をローカル JMS オブジェクトのように WebLogic JNDI ツリーに表示できます。また、別のクラスタまたはドメインにある WebLogic Server のリモート インスタンスをローカル WebLogic JNDI ツリー内で参照することもできます。
リモートおよび外部 JMS プロバイダの統合については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS を EJB やサーブレットと組み合わせて使用するために拡張されたサポート」を参照してください。
以下の節では、外部サーバの機能と、リモート 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 ファイルを復元して編集する必要はありません。
JMS モジュール内の外部サーバ リソースは、WebLogic JMS サーバの外部にある JNDI プロバイダを表しています。外部サーバには、ローカル WebLogic Server インスタンスがリモート JNDI プロバイダにアクセスするための情報が保持されています。これにより、1 つの JNDI ディレクトリに対して複数の外部接続ファクトリと送り先のオブジェクトを定義できます。
WebLogic Server Administration Console を使用すると、システム モジュール内の外部サーバ リソースをコンフィグレーション、変更、対象指定、および削除できます。外部サーバに関するタスクの詳細については、Administration Console オンライン ヘルプの「外部サーバのコンフィグレーション」を参照してください。
| 注意 : | エンタープライズ アプリケーションにおける JMS アプリケーション モジュールのコンフィグレーションとデプロイについては、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。 |
一部の外部サーバ オプションは、動的にコンフィグレーションできます。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての外部サーバ オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「ForeignServerBean」を参照してください。
外部サーバを定義したら、接続ファクトリおよび送り先のオブジェクトをコンフィグレーションできます。各外部サーバに対して、1 つまたは複数の接続ファクトリおよび送り先 (キューまたはトピック) をコンフィグレーションできます。
JMS モジュール内の外部接続ファクトリ リソースには、リモート JNDI プロバイダの接続ファクトリの JNDI 名、ローカル WebLogic Server JNDI ツリー内でその接続ファクトリにマップされる JNDI 名、およびユーザ名とパスワード (省略可能) が定義されます。
外部接続ファクトリは、親の外部サーバの割り当て先となる各 WebLogic Server インスタンスに対してレプリケートされていない JNDI オブジェクトを作成します (クラスタ内の各ノードに JNDI オブジェクトを作成するには、クラスタに外部サーバを割り当てます)。
JMS モジュール内の外部送り先リソースは、キューまたはトピックを表します。外部送り先には、外部 JNDI プロバイダでルックアップされる送り先の JNDI 名、およびローカル WebLogic Server で送り先がマップされる JNDI 名が保持されます。外部送り先がローカル サーバでルックアップされる場合、ルックアップはリモート JNDI ディレクトリで実行され、そのディレクトリから送り先オブジェクトが返されます。
次の表に、リモート MQSeries JNDI プロバイダにアクセスする場合のサンプル コンフィグレーションを示します。
JMS モジュール内の分散送り先リソースは、単一の論理的な送り先としてクライアントからアクセス可能な 1 つの送り先セット (キューまたはトピック) です (たとえば分散トピックは独自の JNDI 名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバに分散されており、各メンバーは別々の JMS サーバに属しています。分散送り先を使用するアプリケーションは、スタンドアロンの送り先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMS に、クラスタ内の分散送り先メンバーのためのロード バランシングおよびフェイルオーバ機能があるためです。
以降の節では、分散送り先の作成、モニタ、およびロード バランシングを行う方法について説明します。
WebLogic Server 9.0 以降には、共通分散送り先と重み設定された分散送り先という 2 種類の分散送り先が用意されています。WebLogic Server 9.0 より前のリリースでは、WebLogic 管理者が、物理送り先を分散送り先のメンバーとして機能するように手動で頻繁にコンフィグレーションする必要がありました。この方法は、追加のメッセージ負荷または容量に対応するメンバーを作成できるという柔軟性を備えていました。しかし、このような重み設定された分散送り先はクラスタ内で一貫してデプロイされなかったため、管理上およびアプリケーション上の問題が発生することもよくありました。このタイプの分散送り先は、公式には「重み設定された分散送り先」(WDD) と呼ばれます。
共通分散送り先 (UDD) は、分散送り先アプリケーションの管理と開発を大幅に簡略化します。共通分散送り先を使用すると、送り先のメンバーを作成したり指定したりする必要がなくなります。代わりに、WebLogic Server によって、JMS モジュールが割り当てられる JMS サーバ上に必要なメンバーが均等に作成されます。この機能によって、すべての分散送り先のパラメータ (重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ) を一貫してコンフィグレーションできます。
分散送り先メンバーを手動で調整する場合は、従来の重み設定された分散送り先の機能も依然として使用できます。ただし、クラスタ内で一貫してデプロイされていない重み設定された分散送り先に起因して起こり得る管理上およびアプリケーションの問題を回避するため、共通分散送り先をコンフィグレーションすることをお勧めします。
アプリケーションと一緒に分散送り先を使用する方法の詳細については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先の使用」を参照してください。
WebLogic Server Administration Console を使用すると、JMS システム モジュール内の UDD リソースをコンフィグレーション、変更、対象指定、および削除できます。[メンバーの均等割り当て] チェック ボックスをチェックされた状態のままにしておくと、選択した JMS サーバ、対象サーバ上のすべての JMS サーバ、またはクラスタ上で、自動的に送り先メンバーが均等に作成されます。
| 注意 : | エンタープライズ アプリケーションにおける JMS アプリケーション モジュールのコンフィグレーションとデプロイについては、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。 |
共通分散送り先に関するタスクの詳細については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
共通分散送り先オプションの中には、動的にコンフィグレーションできるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての共通分散送り先オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の以下の項目を参照してください。
ドメイン内の特定の 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/91">
<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 を使用すると、JMS システム モジュール内の 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 では、接続ファクトリの [サーバ アフィニティを有効化] パラメータの設定が、分散送り先メンバーのロード バランシングの優先権に与える影響について説明します。優先順位は、操作のタイプ、および恒久サブスクリプションまたは永続メッセージが含まれているかどうかによって異なります。
分散送り先の [サーバ アフィニティを有効化] パラメータは、ClusterMBean の [デフォルトのロード バランス アルゴリズム] 属性によって提供されるサーバ アフィニティとは異なります。後者は、JMS 接続ファクトリでクライアント接続用の初期コンテキスト アフィニティを作成するためにも使用されます。
詳細については、『クラスタの使用』の「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 プログラマーズ ガイド』の「サーバ障害からの回復」を参照してください。
  
|