Oracle® Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55547-01 |
|
![]() 戻る |
![]() 次へ |
以下の節では、クラスタ化環境での分散送り先などの拡張 WebLogic JMS リソースをコンフィグレーションする方法について説明します。
WebLogic Server のクラスタとはドメイン内で連携して動作するサーバのグループであり、単一のサーバよりもスケーラブルで信頼性のあるアプリケーション プラットフォームを提供します。クラスタはそのクライアントからは単一のサーバに見えますが、実際には一体で機能するサーバ群です。
注意 : JMS クライアントがクラスタに正常にアクセスするには、ユニークな WebLogic Server 名が必要です (WebLogic Server が別々のドメインに存在する場合にも必要)。このため、JMS クライアントがアクセスするすべての WebLogic Server の名前はユニークでなければなりません。 |
JMS クラスタ化には、以下のメリットがあります。
クラスタ内の複数のサーバにわたる送り先のロード バランシング
管理者は、複数の JMS サーバをコンフィグレーションし、それらを定義済みの WebLogic Server に割り当てることで、クラスタ内の複数のサーバにわたる送り先のロード バランシングを確立できます。各 JMS サーバは、厳密に 1 つの WebLogic Server インスタンスにデプロイされ、送り先の集合に対するリクエストを処理します。
注意 : ロード バランシングは動的ではありません。コンフィグレーションの段階で、システム管理者が JMS サーバの対象を指定してロード バランシングを定義します。 |
送り先の高可用性
分散送り先 - 分散送り先のキューおよびトピック メンバーは通常、クラスタ内の複数のサーバに分散され、各メンバーは個々の JMS サーバに属す。分散送り先を使用するアプリケーションは、単純な送り先を使用するアプリケーションより可用性が高くなります。WebLogic JMS は、クラスタ内の分散送り先のメンバーのためのロード バランシングとフェイルオーバの機能を備えているからです。分散送り先の詳細については、「分散送り先リソースのコンフィグレーション」を参照してください。
ストア アンド フォワード - JMS モジュールは、SAF サービスを利用して、ローカルの JMS メッセージ プロデューサがリモートのキューまたはトピックに確実にメッセージを送信できるようにする。ネットワークの問題やシステム障害が原因で、メッセージの送信時に送り先が使用不能になっている場合、メッセージはローカルのサーバ インスタンスに保存されて、リモートの送り先が使用可能になった時点で転送されます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ストア アンド フォワードのコンフィグレーションと管理』の「ストア アンド フォワード サービスについて」を参照してください。
自動フェイルオーバの場合、WebLogic Server はサーバ レベル (サーバ インスタンス) での移行をサポートする。WebLogic Server がホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サーバ全体の移行」を参照してください。
クラスタ内のあらゆるサーバからの、送り先へのクラスタワイドで透過的なアクセス
管理者は、クラスタ内の各サーバ インスタンスのデフォルト接続ファクトリを使用するか、1 つまたは複数の接続ファクトリをコンフィグレーションしてクラスタ内の 1 つまたは複数のサーバ インスタンスまたはクラスタ全体を対象とすることで、クラスタ内のあらゆるサーバから送り先へのクラスタワイドで透過的なアクセスを確立できます。これにより、各接続ファクトリを複数の WebLogic Server インスタンスにデプロイできます。接続ファクトリについては、「接続ファクトリのコンフィグレーション」を参照してください。
スケーラビリティ
前述した、クラスタ内の複数のサーバにわたる送り先のロード バランシング。
接続ファクトリを通じた、複数の JMS サーバでのアプリケーション負荷の分散。その結果として、個々の JMS サーバでの負荷が削減され、かつ接続先を特定のサーバに決めることでセッションの集中が可能となります。
マルチキャストのサポート (オプション)。JMS サーバで配信しなければならないメッセージの数が削減されます。JMS サーバでは、サブスクライブしているアプリケーションの数に関係なく、マルチキャスト IP アドレスと関連付けられている各ホスト グループに対してメッセージが 1 コピーだけ転送されます。
移行性
WebLogic Server はサーバ レベル (サーバ インスタンス) での移行をサポートします。WebLogic Server がホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サーバ全体の移行」を参照してください。
また、「必ず 1 回」のサービスとして、WebLogic JMS はクラスタ化された環境のために WebLogic Server に実装されている移行フレームワークを活用します。これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。移行には、予定されている手動移行のほかに、クラスタ内の WebLogic Server の障害に対応して行われる自動移行があります。詳細については、「JMS 関連サービスの移行」を参照してください。
JMS クライアントに対するサーバ アフィニティ
クラスタ用にコンフィグレーションしたロード バランシング アルゴリズム (ラウンドロビン アフィニティ、重みベース アフィニティ、またはランダム アフィニティ) は、JMS クライアント接続のためのサーバ アフィニティを提供します。JMS アプリケーションから指定したサーバ インスタンスに接続できる場合、JMS は同じサーバ インスタンスとの新しい JMS 接続を確立しようとします。サーバ アフィニティの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタでのロード バランシング」を参照してください。
WebLogic クラスタを使用した場合の機能と利点の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「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 を使用する場合は、以下のガイドラインに従います。
クラスタ化環境をコンフィグレーションします。『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「WebLogic クラスタの設定」を参照してください。
Administration Console を使用して、ユーザ定義の JMS 接続ファクトリの対象となるサーバを指定します。接続ファクトリでは、単一のサーバまたはクラスタを対象として指定できます。対象とは、クラスタ化をサポートするために接続ファクトリに関連付けられたサーバのインスタンスです。
接続ファクトリのコンフィグレーション属性の詳細については、「接続ファクトリのコンフィグレーション」を参照してください。
必要に応じて、Administration Console を使用して JMS サービス用の移行可能なサーバを指定します。たとえば、JMS サーバであれば、単一のサーバまたは移行可能なサーバを対象として指定できます。移行可能な対象とは、クラスタ内にあるサーバ インスタンスのセットで、クラスタ内で 1 台のサーバに障害が発生した場合に、JMS のような「必ず 1 回」のサービスをホストできるものです。
移行可能な JMS サーバ対象の詳細については、「JMS 関連サービスの移行」を参照してください。JMS サーバのコンフィグレーション属性の詳細については、「JMS サーバのコンフィグレーション」を参照してください。
注意 : 同じ送り先を複数の JMS サーバにデプロイすることはできません。また、1 つの JMS サーバを複数の WebLogic Server にデプロイすることもできません。 |
必要に応じて、クラスタ内に物理 JMS 送り先を仮想的な分散送り先セットの一部としてコンフィグレーションできます。詳細については、「クラスタ内での分散送り先」を参照してください。
サーバまたはネットワークの障害が発生した場合、JMS メッセージ プロデューサおよびコンシューマ オブジェクトは (使用可能なものがあれば) 別のサーバ インスタンスに透過的にフェイルオーバを試みます。WebLogic Server リリース 9.1 以降では、既存のクライアント コードを手動でコンフィグレーションまたは変更しなくても、WebLogic JMS メッセージ プロデューサは、使用可能なサーバ インスタンスへ自動的に再接続しようとします。WebLogic Server リリース 9.2 では、Administration Console または WebLogic JMS API を利用して、使用可能なサーバ インスタンスに自動的に再接続を試行するように WebLogic JMS メッセージ コンシューマをコンフィグレーションできます。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「JMS クライアントの自動フェイルオーバ」を参照してください。
注意 : WebLogic Server 9.0 以前の JMS クライアント アプリケーションについては、『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「WebLogic Server 9.0 以前のリリースでの障害に関するプログラミングの考慮事項」を参照してください。 |
さらに、サービスの自動移行機能を実装すると、JMS のような「必ず 1 回」のサービスによって、クラスタ内の依存するアプリケーションに対するシングル ポイント障害が発生しなくなります。「JMS 関連サービスの移行」を参照してください。WebLogic Server では、サーバ レベルでのデータの移行、つまり、サーバ インスタンス全体の移行もサポートされています。また、サーバ インスタンスがホストするすべてのサービスを自動または手動で別のマシンに移行できます。『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サーバ全体の移行」を参照してください。
クラスタ化環境では、分散送り先をコンフィグレーションすることによって 1 つのサーバで障害が発生した場合でもサービスを継続できます。分散送り先のキューおよびトピック メンバーは通常、クラスタ内の複数のサーバに分散され、各メンバーは個々の JMS サーバに属します。「クラスタ内での分散送り先」を参照してください。
また、高可用性クラスタ化ソフトウェアを実装することをお勧めします。これにより、WebLogic Server ベースのアプリケーションに、統合された使いやすいソリューションがもたらされます。
JMS 関連サービスはシングルトン サービスであるため、クラスタ内のすべてのサーバ インスタンスでアクティブになるわけではなく、データの一貫性を保持するためにクラスタ内の単一サーバに固定されます。シングルトン JMS サービスが原因で、クラスタ内の依存するアプリケーションに対するシングル ポイント障害が発生しないようにするため、JMS サービスを移行可能対象リスト内の任意のサーバ インスタンスに自動で移行できるように WebLogic Server をコンフィグレーションできます。ホスト サーバに障害が発生した場合は、移行可能な JMS サービスも手動で移行できます。また、定期的なサーバ メンテナンスを実施する前に、JMS サービスを手動で移行することも可能です。
移行可能な JMS 関連サービスには以下が含まれます。
JMS サーバ - 対象指定されている JMS モジュール内のキューおよびトピックの管理コンテナです。「JMS サーバのコンフィグレーション」を参照してください。
ストア アンド フォワード (SAF) サービス - メッセージが送信された時点でリモート エンドポイントが使用できない場合でも、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージをストア アンド フォワードするサービスです。移行できるのは、JMS SAF (送信機能のみ) 用にコンフィグレーションされた送信 SAF エージェントのみです。『Oracle Fusion Middleware Oracle WebLogic Server ストア アンド フォワードのコンフィグレーションと管理』の「ストア アンド フォワード サービスについて」を参照してください。
パス サービス - JMS メッセージ順序単位内のメッセージのグループからクラスタ内のメッセージ リソースへのマッピングの保持に使用できる永続マップです。パス サービスは、クラスタごとに 1 つずつコンフィグレーションします。「WebLogic パス サービスの使用」を参照してください。
カスタム永続ストア - ユーザが定義するディスク ベースのファイル ストアまたは JDBC 対応データベースです。JMS メッセージやストア アンド フォワード メッセージなどのサブシステム データを格納するために使用します。『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「WebLogic 永続ストアの使い方」を参照してください。
移行可能対象を使用すると、高可用性のための JMS 関連サービスをコンフィグレーションできます。移行可能対象とは、クラスタ内のサーバから別のサーバに移行できる特別な対象です。つまり、移行可能対象を使用することで、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能対象を移行すると、その対象によってホストされているすべてのサービスが移行されます。
『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行フレームワークについて」を参照してください。
管理者は、ヘルス モニタ サブシステムを活用することで、障害が発生した現在のホスト サーバでホストされている JMS サービスが正常に動作しているサーバに自動的に移行するよう、移行可能な対象をコンフィグレーションできます。JMS 関連サービスの自動移行のコンフィグレーションについては、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「JMS 関連サービスの自動移行をコンフィグレーションする手順」を参照してください。
ホスト サーバで障害が発生した場合や、サーバ メンテナンスを実施する前には、JMS 関連サービスを正常なサーバに手動で移行できます。JMS 関連サービスの手動移行のコンフィグレーションについては、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「JMS 関連サービスの手動移行をコンフィグレーションする手順」を参照してください。
「フェイルオーバの場合」で説明したように、カスタム永続ストアを含む JMS サービスは、「サーバ全体」の移行機能の一部として移行したり、移行可能な JMS 関連サービスを対象とした「サービス レベル」の移行の一部として移行したりできます。ただし、移行可能な JMS 関連サービスで、デフォルトの永続ファイル ストアを使用することはできません。したがって、カスタムのファイル ストアまたは JDBC ストアをコンフィグレーションし、関連付けた JMS サーバまたは SAF エージェントと同じ移行可能対象にそのストアを対象指定する必要があります (パス サービスの場合は、専用のカスタム ストアと移行可能対象を使用するのがベスト プラクティスです)。
移行可能なカスタム ファイル ストアは、クラスタ内の移行可能な対象サーバから使用できる共有ディスクにコンフィグレーションしたり、移行前/移行後スクリプトを使用してバックアップ サーバ対象に移行したりできます。永続ストアの移行の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「JMS サービスで使用できるカスタム ストア」を参照してください。
WebLogic Server パス サービスは、JMS メッセージ順序単位内のメッセージのグループから、クラスタ内のメッセージ リソースへの、マッピングの保持に使用できる永続マップです。サーブレットをホストするクラスタのメンバー、分散キュー メンバー、またはストア アンド フォワード エージェントにメッセージを固定することによって、順序付けを実現できます。パス サービスは、クラスタごとに 1 つずつコンフィグレーションします。メッセージ順序単位機能の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「メッセージ順序単位の使用」を参照してください。
クラスタにパス サービスをコンフィグレーションする方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「パス サービスのコンフィグレーション」を参照してください。
クラスタのパス サービスは、高可用性の確保を目的として、自動または手動によるサービス移行用の移行可能対象に対象指定できます。ただし、移行可能なパス サービスではデフォルト ストアを使用できないため、カスタム ストアをコンフィグレーションし、同じ移行可能対象に対象指定する必要があります。さらに、ベスト プラクティスとしては、その移行可能対象のユーザを、パス サービスとそのカスタム ストアに限定する必要があります。『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行フレームワークについて」を参照してください。
メッセージ順序単位とパス サービス ベースのルーティングを実装する際には、以下のことに留意してください。
各パス サービス マッピングは永続ストアに格納される。パス サービスをコンフィグレーションする場合、高可用性ソリューションを使用する永続ストアを選択します。「永続ストアの高可用性」を参照してください。
複数のプロデューサが同じ順序単位名を使用してメッセージを送信する場合、すべてのメッセージは同じパス エントリを共有し、同じメンバー キュー送り先を持つ。
順序単位名に必要なルートにアクセスできない場合、メッセージを送信したプロデューサは JMSOrderException
を送出する。この例外が送出されるのは、JMS メッセージ システムが必要なサービス品質を満たすことができないからです。特定の順序単位に対しては、1 つの分散送り先メンバーだけがメッセージを消費できます。
パス エントリは、最後のプロデューサと最後のメッセージ参照が削除されたときに自動的に削除される。
システムによっては、パス サービスを使用すると、パス エントリを作成、読み取り、および削除するためのリモート ディスク処理のため、システムのスループットが低下する場合がある。
分散キューとその個々のメンバーは、ユニークな送り先を表す。次に例を示します。
DXQ1 は、Q1 と Q2 というメンバーを持つ分散キューです。また DXQ1 は Fred という名前の順序単位を持ち、パス サービスによって Q2 メンバーにマップされています。
メッセージ M1 が DXQ1 に送信されると、パス サービスによって Q2 へのルートが定義される。
メッセージ M1 が直接 Q2 に送信される場合、パス サービスによるルーティングは行われない。これは、アプリケーションが直接 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 プロバイダの統合の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「WebLogic JMS を EJB やサーブレットと組み合わせて使用するために拡張されたサポート」を参照してください。
以下の節では、外部サーバの機能と、リモート MQSeries JNDI プロバイダにアクセスするためのサンプル コンフィグレーションについて説明します。
外部 JMS サーバがデプロイされると、WebLogic Server JNDI にローカルの接続ファクトリと送り先のオブジェクトが作成されます。外部接続ファクトリまたは送り先のオブジェクトがローカル サーバでルックアップされると、そのオブジェクトはリモート JNDI ディレクトリで実際のルックアップを実行し、そのディレクトリから外部オブジェクトが返されます。
この方法を使用すると、複数の WebLogic メッセージング ブリッジ送り先のコンフィグレーションが簡単になります。外部サーバが、JNDI 初期コンテキスト ファクトリおよび接続 URL のコンフィグレーションの詳細をメッセージング ブリッジ送り先のコンフィグレーションの外側に移すからです。外部接続ファクトリおよび送り先 JNDI 名をオブジェクトごとに指定するだけで済みます。
メッセージング ブリッジのコンフィグレーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server メッセージング ブリッジのコンフィグレーションと管理』を参照してください。
また、このコンフィグレーションの簡素化は、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 を使用すると、システム モジュール内の外部サーバ リソースをコンフィグレーション、変更、対象指定、および削除できます。外部サーバ タスクの手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「外部サーバのコンフィグレーション」を参照してください。
注意 : エンタープライズ アプリケーション内での JMS アプリケーション モジュールのコンフィグレーションとデプロイについては、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。 |
一部の外部サーバ オプションは、動的にコンフィグレーションできます。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての外部サーバ オプションのデフォルト値の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「ForeignServerBean」を参照してください。
外部サーバを定義したら、接続ファクトリおよび送り先のオブジェクトをコンフィグレーションできます。各外部サーバに対して、1 つまたは複数の接続ファクトリおよび送り先 (キューまたはトピック) をコンフィグレーションできます。
JMS モジュール内の外部接続ファクトリ リソースには、リモート JNDI プロバイダの接続ファクトリの JNDI 名、ローカル WebLogic Server JNDI ツリー内でその接続ファクトリにマップされる JNDI 名、およびユーザ名とパスワード (省略可能) が定義されます。
外部接続ファクトリは、親の外部サーバの割り当て先となる各 WebLogic Server インスタンスに対してレプリケートされていない JNDI オブジェクトを作成します (クラスタ内の各ノードに JNDI オブジェクトを作成するには、クラスタに外部サーバを割り当てます)。
JMS モジュール内の外部送り先リソースは、キューまたはトピックを表します。外部送り先には、外部 JNDI プロバイダでルックアップされる送り先の JNDI 名、およびローカル WebLogic Server で送り先がマップされる JNDI 名が保持されます。外部送り先がローカル サーバでルックアップされる場合、ルックアップはリモート JNDI ディレクトリで実行され、そのディレクトリから送り先オブジェクトが返されます。
次の表に、リモート MQSeries JNDI プロバイダにアクセスする場合のサンプル コンフィグレーションを示します。
表 4-1 MQSeries サンプル コンフィグレーション
外部 JMS オブジェクト | オプション名 | サンプル コンフィグレーション データ |
---|---|---|
外部サーバ |
[名前] [JNDI 初期コンテキスト ファクトリ] [JNDI 接続 URL] [JNDI プロパティ] |
MQJNDI com.sun.jndi.fscontext.RefFSContextFactory file:/MQJNDI/ (必要な場合、カンマ区切りの name=value プロパティ リストを入力する)。 |
外部 接続ファクトリ |
[名前] [ローカル JNDI 名] [リモート JNDI 名] [ユーザ名] [パスワード] |
MQ_QCF mqseries.QCF QCF weblogic_jms weblogic_jms |
外部 送り先 1 外部 送り先 2 |
[名前] [ローカル JNDI 名] [リモート JNDI 名] [名前] [ローカル JNDI 名] [リモート JNDI 名] |
MQ_QUEUE1 mqseries.QUEUE1 QUEUE_1 MQ_QUEUE2 mqseries.QUEUE2 QUEUE_2 |
JMS モジュール内の分散送り先リソースは、単一の論理的な送り先としてクライアントからアクセス可能な 1 つの送り先セット (キューまたはトピック) です (たとえば分散トピックは独自の JNDI 名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバに分散されており、各メンバーは別々の JMS サーバに属しています。分散送り先を使用するアプリケーションは、スタンドアロンの送り先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMS に、クラスタ内の分散送り先メンバーのためのロード バランシングおよびフェイルオーバ機能があるためです。
以降の節では、分散送り先の作成、モニタ、およびロード バランシングを行う方法について説明します。
WebLogic Server 9.0 以降には、共通分散送り先と重み設定された分散送り先という 2 種類の分散送り先が用意されています。WebLogic Server 9.0 より前のリリースでは、WebLogic 管理者が、物理送り先を分散送り先のメンバーとして機能するように手動で頻繁にコンフィグレーションする必要がありました。この方法は、追加のメッセージ負荷または容量に対応するメンバーを作成できるという柔軟性を備えていました。しかし、このような重み設定された分散送り先はクラスタ内で一貫してデプロイされなかったため、管理上およびアプリケーション上の問題が発生することもよくありました。このタイプの分散送り先は、公式には「重み設定された分散送り先」(WDD) と呼ばれます。
共通分散送り先 (UDD) は、分散送り先アプリケーションの管理と開発を大幅に簡略化します。共通分散送り先を使用すると、送り先のメンバーを作成したり指定したりする必要がなくなります。代わりに、WebLogic Server によって、JMS モジュールが割り当てられる JMS サーバ上に必要なメンバーが均等に作成されます。この機能によって、すべての分散送り先のパラメータ (重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ) を一貫してコンフィグレーションできます。
分散送り先メンバーを手動で調整する場合は、従来の重み設定された分散送り先の機能も依然として使用できます。ただし、クラスタ内で一貫してデプロイされていない重み設定された分散送り先に起因して起こり得る管理上およびアプリケーションの問題を回避するため、共通分散送り先をコンフィグレーションすることをお勧めします。
アプリケーションでの分散送り先の使用の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「分散送り先の使用」を参照してください。
WebLogic Server Administration Console を使用すると、JMS システム モジュール内の UDD リソースをコンフィグレーション、変更、対象指定、および削除できます。[メンバーの均等割り当て] チェック ボックスをチェックされた状態のままにしておくと、選択した JMS サーバ、対象サーバ上のすべての JMS サーバ、またはクラスタ上で、自動的に送り先メンバーが均等に作成されます。
注意 : エンタープライズ アプリケーション内での JMS アプリケーション モジュールのコンフィグレーションとデプロイについては、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。 |
共通分散送り先のタスクの手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
共通分散送り先オプションの中には、動的にコンフィグレーションできるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての共通分散送り先オプションのデフォルト値については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の以下の項目を参照してください。
ドメイン内の特定の 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://xmlns.oracle.com/weblogic/weblogic-jms"> <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 リソースをコンフィグレーション、変更、対象指定、および削除できます。分散トピックまたはキューをコンフィグレーションする場合、[メンバーの均等割り当て] チェック ボックスのチェックをはずすことによって、既存のキューとトピックを手動で選択して分散送り先に追加し、分散送り先メンバーの重みを調整できます。
重み設定された分散送り先のタスクの手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
重み設定された分散送り先オプションの中には、動的にコンフィグレーションできるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての重み設定された分散送り先オプションのデフォルト値については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の以下の項目を参照してください。
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 ではコンシューマのメッセージ受信元となる物理的送り先を見つける必要があります。使用する送り先メンバーの選択には、ロード バランシング アルゴリズム (「ロード バランシング オプション」を参照) のいずれかが使用されます。この選択は、コンシューマの作成時に 1 度だけ行われます。その後、コンシューマはそのメンバーのみからメッセージを受信するようになります。
プロデューサがメッセージを送信するとき、WebLogic JMS はメッセージが送信される送り先を確認します。送り先が分散送り先である場合は、メッセージの送信先が WebLogic JMS によって決定されます。つまり、プロデューサは「ロード バランシング オプション」で説明されているロード バランシング アルゴリズムのいずれかに従って、送り先のメンバーのいずれかに送信します。
プロデューサはメッセージを送信するたびにこのような決定を行います。ただし、コンシューマとプロデューサ間の序列の保証が脅かされることはありません。コンシューマのロード バランシングがいったん行われると、コンシューマは単一の送り先メンバーに固定されるためです。
注意 : プロデューサが永続メッセージを分散送り先に送信しようとする場合、永続ストアを利用している分散メンバーにまずメッセージが転送されるよう、あらゆる努力がなされます。ただし、分散メンバーがいずれも永続ストアを利用していない場合でも、メッセージは選択されているロードバランシング アルゴリズムに従って、メンバーのいずれかに送信されます。 |
「ロード バランシング オプション」に説明されているアルゴリズムに加えて、WebLogic JMS では送り先のインスタンスを選択するときに次のヒューリスティックが使用されます。
トランザクション セッション内で複数のメッセージを作成するときは、作成されたメッセージすべてを同じ WebLogic Server に送信しようとします。つまり、セッションが単一の分散送り先に複数のメッセージを送信した場合は、すべてのメッセージが同じ物理的送り先に転送されます。セッションによって複数のメッセージが複数の異なる分散送り先に送信された場合は、同じ WebLogic Server がサービスを提供する一連の物理的送り先が選択されるようになります。
接続ファクトリの [サーバ アフィニティを有効化] パラメータでは、分散送り先内にある複数のメンバー送り先の間でコンシューマまたはプロデューサをロード バランシングしている WebLogic Server が、同じ WebLogic Server 上で実行されている他のローカル送り先メンバーの間でロード バランシングを最初に試みるかどうかを定義します。
注意 : [サーバ アフィニティを有効化] 属性は、キュー ブラウザには影響しません。したがって、[サーバ アフィニティを有効化] が有効になっている場合でも、分散キューに作成されたキュー ブラウザをリモート分散キュー メンバーに固定できます。 |
接続ファクトリでサーバ アフィニティを無効化するには、次の手順に従います。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「接続ファクトリのロード バランシング パラメータのコンフィグレーション」の説明に従って、[JMS 接続ファクトリ|コンフィグレーション|全般] ページに移動します。
[サーバ アフィニティを有効化] フィールドを以下のように定義します。
[サーバ アフィニティを有効化] チェック ボックスを選択する (true とする)。この場合、分散送り先セット内にある複数の物理的送り先の間でコンシューマまたはプロデューサをロード バランシングしている WebLogic Server は、同じ WebLogic Server 上で実行されている他の物理的送り先の間でロード バランシングを最初に試みます。
JMS 接続ファクトリの [サーバ アフィニティを有効化] チェック ボックスのチェックをはずす (false とする)。この場合、分散送り先セット内の複数の物理的送り先にまたがってコンシューマまたはプロデューサのロード バランシングを実行するときに、同じ WebLogic Server で実行されている他の物理的送り先が無視されます。
[保存] をクリックします。
[サーバ アフィニティを有効化] の設定が分散送り先のメンバー間のロード バランシングにどのように影響するかについては、「サーバ アフィニティを有効化した場合の分散送り先ロード バランシングへの影響」を参照してください。
複数のリモートの物理的キュー間でコンシューマのロード バランシングを行う場合、1 つまたは複数のキューにコンシューマがないとき、それらのキューだけがロード バランシングの対象となります。セット内の物理的キューすべてに少なくとも 1 つのコンシューマが含まれるようになると、標準のアルゴリズムが適用されます。
また、プロデューサがメッセージを送信するとき、コンシューマのないキューはメッセージ作成の対象にはなりません。ただし、任意のキューのインスタンスのいずれにもコンシューマが含まれていない場合を除きます。
分散送り先でメッセージの生成または挿入が休止された場合、それらはメッセージ生成の対象とは見なされません。同様に、分散送り先でメッセージの消費が休止された場合、それらはメッセージ生成の対象とは見なされません。
送り先でのメッセージ処理の休止については、「送り先でのメッセージ処理の制御」を参照してください。
アプリケーションは、個別の物理的送り先に直接アクセスすることで、ロード バランシングを回避できます。つまり、物理的送り先に JNDI 名がない場合でも、createQueue()
メソッドまたは createTopic()
メソッドを使用して参照することができます。
共通分散送り先や重み設定された分散送り先のメンバーに直接アクセスする方法については、『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「分散送り先メンバーへのアクセス」を参照してください。
アプリケーションにおいて、分散送り先を使用して、複数の物理的送り先間でプロデューサやコンシューマを分散、つまりバランスさせることは行っても、メッセージが作成されるたびにロード バランシングの決定を行いたくない場合は、[ロード バランスを有効化] パラメータを無効化した状態で接続ファクトリを使用します。分散送り先においてメッセージの負荷が適正に分散されるようにするには、プロデューサによって使用される初期の物理的な送り先 (キューまたはトピック) が、物理的な送り先メンバーによって常にランダムに選択される必要があります。
接続ファクトリでのロード バランシングを無効化するには、次の手順に従います。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「接続ファクトリのロード バランシング パラメータのコンフィグレーション」の説明に従って、[JMS 接続ファクトリ|コンフィグレーション|全般] ページに移動します。
以下のガイドラインに従って、[ロード バランスを有効化] フィールドを設定します。
[ロード バランスを有効化] = True
Queue.sender.send()
メソッドでは、分散キュー メンバー間での呼び出しごとに、匿名でないプロデューサがロード バランシングされます。
TopicPublish.publish()
メソッドでは、[ロード バランシングを有効化] 設定にかかわりなく、匿名でないプロデューサが呼び出しごとに常に同じ物理的なトピックに固定されます。
[ロード バランスを有効化] = False
プロデューサは失敗するまで常に同じ物理的な送り先に対して生成します。失敗すると、新しい物理的送り先が選択されます。
[保存] をクリックします。
注意 : 実装によっては、[サーバ アフィニティを有効化] 属性の設定が分散送り先のロード バランシングの優先権に影響することがあります。詳細については、「サーバ アフィニティを有効化した場合の分散送り先ロード バランシングへの影響」を参照してください。 |
匿名プロデューサ (作成時に送り先を指定しないプロデューサ) は、送り先を切り替えるたびにロード バランシングされます。同じ送り先を使用し続けると、匿名でないプロデューサと同じ法則 (前述) が適用されます。
表 4-1 では、接続ファクトリの [サーバ アフィニティを有効化] パラメータの設定が、分散送り先メンバーのロード バランシングの優先権に与える影響について説明します。優先順位は、操作のタイプ、および恒久サブスクリプションまたは永続メッセージが含まれているかどうかによって異なります。
分散送り先の [サーバ アフィニティを有効化] パラメータは、ClusterMBean
の [デフォルトのロード バランス アルゴリズム] 属性によって提供されるサーバ アフィニティとは異なります。後者は、JMS 接続ファクトリでクライアント接続用の初期コンテキスト アフィニティを作成するためにも使用されます。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「EJB と RMI オブジェクトのロード バランシング」および「クライアント接続の初期コンテキスト アフィニティとサーバ アフィニティ」を参照してください。
表 4-2 サーバ アフィニティのロード バランシングの優先権
操作 | [サーバ アフィニティを有効化] の設定 | ロード バランシングの優先権 |
---|---|---|
|
True |
|
キューの |
False |
|
トピックの (注意 : 非永続サブスクライバ) |
true または false |
|
|
true または false |
JMS プロデューサ作成のロード バランシング用の独立した機能は存在しない。JMS プロデューサは、JMS 接続のロード バランシングまたは固定が行われるサーバで作成される。 詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「EJB と RMI オブジェクトのロード バランシング」および「クライアント接続の初期コンテキスト アフィニティとサーバ アフィニティ」を参照。 |
|
True |
|
|
False |
|
|
True |
|
非永続メッセージ
|
False |
|
セッション プール キューおよびトピックの |
true または false |
ローカル メンバーのみ 注意 : セッション プールは現在ほとんど使用されていない。理由は、J2EE 仕様の必須の部分ではないこと、JTA ユーザ トランザクションをサポートしていないこと、そして大部分がメッセージ駆動型 Bean (MDB) に取って代わられたことである。MDB の方が簡単で管理しやすく、高機能である。 |
サービス移行機能を利用するクラスタ化された 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 の障害から回復する手順については、『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「サーバ障害からの回復」を参照してください。