JMSサーバーと永続ストアを構成する前に、次の内容を検討します。
宛先、接続ファクトリ、およびその他のJMSリソースが、そのホストJMSサーバーおよび永続ストアとは別に構成されています。JMSリソースを構成するベスト・プラクティスの手順については後ほど説明します。
WebLogic JMS分散宛先が機能するには、WebLogicクラスタが機能している必要があります。
クラスタ化されたJMS構成には、2種類あります。
クラスタをターゲットとして指定されたJMSサーバーおよびストアは、簡略化された構成、簡略化されたHA、およびリソースの動的スケーリング機能を提供します。クラスタ・サイズの増加に応じて、JMSサーバー、ストアおよび分散宛先メンバーが構成の変更を必要とせずに自動的に追加されます。
注意:
クラスタをターゲットとして指定されたJMSは、構成されたクラスタのかわりにWebLogic動的クラスタを利用する場合には使用可能な唯一のJMSオプションです。「簡略化されたJMSクラスタと高可用性の構成」を参照してください
個別に構成されたJMS HAは、個別に構成されたJMSサーバーおよびストアのセットからなり、これらのサーバーおよびストアにターゲットとしてクラスタ内の移行可能なターゲットが指定されます。このオプションは、主に、以前のバージョンとの互換性を保つために存在しています。
クラスタを使用していない場合は、最小サイズのクラスタを再検討して使用し、スタンドアロン宛先のかわりに分散宛先を使用する可能性があります。これにより、構成とアプリケーションを複数のサーバーに容易に拡張できるようになるため、将来のHAおよびスケーリングのサポートについて、ご使用のアプリケーションが「将来においても有効な」ものになります。非クラスタ・アプリケーションおよび構成をクラスタ化されたトポロジに変更するのは困難なプロセスであるため、クラスタの活用は、構成およびアプリケーション設計の初期段階で行うのが最適です。
注意:
高可用性とスケーリングについては、移行可能なターゲットを使用するかわりに、適切な高可用性構成設定とともにJMSアーティファクトにクラスタをターゲットとして指定することをお薦めします。クラスタにJMSサーバーと永続ストアを構成するには、次の手順を実行します。
クラスタをターゲットとしてJMSを設定する手順は、次のとおりです。
カスタム・ストアを作成し、クラスタにターゲット指定します。「簡略化されたJMSクラスタと高可用性の構成」を参照してください「データの安全な永続化」で説明しているように、データを安全に永続化できるようにストアが構成されていることを確認します。
JMSサーバーを構成して、同じクラスタにターゲット指定します。さらにステップ1で作成したストアを参照するようにJMSサーバーを構成します。複数のJMSサーバーで同じストアを参照できます。
クラスタ内の個別に構成されたJMSを設定する手順は、次のとおりです。
クラスタ内の各WebLogic Serverにカスタム・ストアを作成します。各ストアを、サーバー上のデフォルトの移行可能なターゲット、またはカスタム移行可能なターゲットにターゲット指定します。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。「データの安全な永続化」で説明しているように、データを安全に永続化できるようにストアが構成されていることを確認します。
注意:
チューニングと管理の柔軟性が高まるカスタム・ストアを使用することをお薦めします。また、デフォルト・ファイル・ストアはJVM間で移行できません。移行可能なのはカスタム・ストアのみです。
各WebLogicサーバーでJMSサーバーを構成します。ステップ1で作成されたサーバーのストアを参照するように、JMSサーバーを構成します。ストアに使用されたターゲットにJMSサーバーをターゲット指定します。複数のJMSサーバーで同じストアを参照できます。
JMSサーバー上のメッセージ数またはバイト数(あるいは両方)の割当てを構成します。デフォルトの割当てがないため、割当てを構成すると、メモリー不足状況の防止に役立ちます。経験則によれば、従来、各メッセージはページ・アウトする場合でも最低512バイトのメモリーを消費すると仮定されます。
注意:
永続JDBCストア・メッセージ、永続ファイル・ストア・メッセージおよび非永続メッセージはすべて、ページ・アウトするまでJVMメモリーに完全にキャッシュされます。また、すべてのタイプのメッセージにおいて、メッセージがページ・アウトした後もJVMメモリーにヘッダーが残ります。
JMSページングはデフォルトで有効ですが、デフォルトの動作が環境に対して有効であることを確認します。『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージのページングによるメモリーの解放に関する項を参照してください。
JMSモジュールで、JMS接続ファクトリおよび宛先の構成がカプセル化されます。ベスト・プラクティスは、クラスタ内の同種のJMSサーバーのセットごとに、システム・モジュールとシステム・モジュール・サブデプロイメントを構成することです。これにより、JMSモジュール・リソース構成、JMSモジュール・サブデプロイメントおよびJMSサーバー構成の間で単純な1対1の対応が保持されます。
同種のJMSサーバーのセットは、次のいずれかです。
ストアの分散ポリシーがDistributed
に設定されている、クラスタをターゲットとして指定された単一のJMSサーバー。
ストアの分散ポリシーがSingleton
に設定されている、クラスタをターゲットとして指定された単一のJMSサーバー。
1つ以上の個別に構成されたJMSサーバーのセット。
異なるJMS構成は、それぞれ異なる構成名と異なるJNDI名が使用されているかぎり、同じクラスタ・スコープに共存できます。
JMSリソースには、特定のターゲット指定のガイドラインをお薦めします。
これらは次のとおりです。
デフォルトのターゲット指定、WebLogicサーバーのターゲット指定、宛先を含むクラスタのターゲット指定は避けてください。かわりに、宛先で高度なターゲット指定(サブデプロイメントのターゲット指定)を使用して、サブデプロイメントがJMSサーバーまたはSAFエージェントのみを参照するようにしてください。これは、非分散、分散およびインポート済を含む、すべての宛先タイプに適用されます。
ドメインの現在のJMSサーバーまたはSAFエージェントのみが特定のアプリケーションに使用される場合でも、次の理由によりこれがベスト・プラクティスとなります。
現在のアプリケーションに関連しない新しいJMSサーバーまたはSAFエージェントは、他のアプリケーション、Webサービス、またはサード・パーティ製品で導入できます。
今後、アプリケーションでは、スケーラビリティや管理上の目的で異なる宛先や異なるJMSサーバーまたはSAFエージェントが必要になります。
Webサービス・デプロイメントおよびエラー・キューを構成する場合は常に高度なターゲット指定を使用します。これは、開発環境と本番環境のどちらも該当します。
分散キュー内でエラー宛先を使用するには、その親の宛先と同じサブデプロイメントにエラー宛先をターゲット指定する必要があります。
ほとんどの場合、デフォルトのターゲット指定ではリソースがモジュールのターゲットを継承するため、デフォルトのターゲット指定と接続ファクトリを一緒に使用できます。リモート・クライアントでのみ使用される接続ファクトリの場合、モジュールのサブデプロイメント・ターゲットを使用します。
WebLogic Serverで高可用性機能を実現および利用するためのベスト・プラクティスについて説明します。
この項には次のトピックが含まれます:
高可用性(HA)を実現するには、クラスタ化されたWebLogic機能を利用するアプリケーションを開発し、開発時にクラスタを使用します。非クラスタ・アプリケーションからクラスタ・アプリケーションへの変更は困難なプロセスであるため、これは構成およびアプリケーション設計の初期段階で行うのが最適です。
WebLogic JMSでは、メッセージのホストJMSサーバー・インスタンスが実行中の場合にのみ、コンシューマが送信メッセージを使用できます。メッセージが共有ファイル・システムまたはデータベース、あるいは分散宛先に格納されている場合でも、メッセージを回復できるJMSサーバー・インスタンスは、メッセージが最初に格納されたのと同じインスタンスのみです。たとえば、メッセージが複数のJMSサーバー・インスタンスでホストされている分散キューに送信された場合、メッセージはこれらのインスタンスの1つのみに内部的にロード・バランシングされ、その特定のインスタンスに格納されます。後にそのインスタンスがクラッシュした場合、そのインスタンスが再起動するまでの間、メッセージはコンシューマに対して使用不可になります。
障害後にメッセージの可用性を回復するために、WebLogicには、WebLogic Server JVM全体を自動的に再起動または移行(あるいはその両方)する機能があります。これには、障害の発生後にJVM内でJMSサーバーおよびストア・インスタンスを格納する機能、または同じクラスタ内にある別のJVMにインスタンスを移行する機能も含まれています。最後に、同じクラスタ内の複数のJMSサーバー間で宛先をクラスタリング(分散)する機能があります。分散宛先は、宛先の保存済メッセージの一部が、障害が発生したJMSサーバーおよびストアが再起動または移行されるまで待機している間使用できない場合でも、論理宛先のその他のメッセージは実行中のJMSサーバーを介して生成および使用できるため、高可用性の実現に役立ちます。
通常、HAは次の組合せを使用することで実現します。
WebLogicクラスタリング(動的または構成済クラスタ)。詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogic Serverのクラスタリングの理解に関する項を参照してください。
サーバー全体の移行または再起動(あるいはこの両方)。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。
WebLogic JMSサーバーおよびストアの再起動準備完了。『WebLogic永続ストアの管理』のサービスの再起動準備完了に関する項を参照してください。
クラスタ内でのJVM間のJTAサービスの移行(JMSアプリケーションはトランザクションを利用することが多いため)。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。
クラスタ内でのJVM間のJMSサービスの移行。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。
クラスタ・リーシング。サービスの自動移行とサーバー全体の自動移行では、いずれもクラスタ・リーシングを設定する必要があります。クラスタ・リーシングでなく、データベース・リーシングを構成するのがベスト・プラクティスです。Oracle WebLogic Serverクラスタの管理のリースを参照してください。
分散宛先。『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項を参照してください。
ファイル・ストアを使用している場合は、ファイルが高可用性のストレージ(RAIDなど)に格納されていること、および障害発生後にファイル・データを回復できるように、クラスタ内のすべてのマシンから(SANなどを介して)、またはサーバー全体の移行後にWebLogic Serverをホストする可能性のあるすべてのマシンから一元的にアクセスできることを確認してください。JTAがJDBC TLogストアを使用していない場合は、トランザクション・ログはデフォルトでデフォルト・ファイル・ストアに格納されるため、デフォルト・ファイル・ストアも同様に高可用性と一元的なアクセスが必要となります。『WebLogic永続ストアの管理』のファイルの場所に関する項および高可用性ファイル・ストアについてのその他の要件に関する項を参照してください。
注意:
ファイル・ストアが中央ディレクトリの場所を使用するようにするには、カスタムまたはデフォルト・ファイル・ストアのディレクトリを明示的に構成することが重要です。そうしない場合、ファイル・ストアは現在のWebLogic Server名に基づいたディレクトリの場所を使用してデータを回復するため、ファイル・ストアがWebLogic Server間を移動した場合に間違ったディレクトリからデータを回復する可能性があります。
ページング・ファイルとキャッシュ・ファイルは、高可用性を必要とせず、パフォーマンス上の理由により、ローカル・ファイル・システムに配置する必要があります。
カスタム・データベース・ストア、トランザクション・ログJDBCストアまたはクラスタ・データベース・リーシングを使用している場合は、データベース表をOracle RACなどの可用性の高いデータベース・ソリューションに格納する必要があります。
データの非同期レプリケーションを利用する障害回復ソリューションがある場合は、通常、ファイル・ベースのストレージはお薦めしません。かわりに、すべてのJMSデータとJTAデータを、メッセージング操作とデータベース操作の組合せを実行する任意のアプリケーションと同じデータベースに格納することを強くお薦めします。これにより、障害回復後も、回復されたメッセージおよびデータの同期を保つことができます。『WebLogic永続ストアの管理』のJDBCストアの使用に関する項およびJDBC TLogストアの使用に関する項を参照してください。
JMSレジリエンシを確保するには、一般に、インフラストラクチャ・レベル・レジリエンシおよびJMSアプリケーション・レジリエンシの2つの主な領域で注意が必要です。
前述の「高可用性のベスト・プラクティス」で説明しているように、最初の領域はインフラストラクチャ・レベルの回復力で、これは通常、構成によって解決され、永続性、クラスタの活用、JVM移行およびサービス移行が含まれます。2つ目の領域はJMSアプリケーションの回復力です。これは一般に、JMSプロバイダ(WebLogic JMSのみでなく)に適用されるコーディングのベスト・プラクティスによって解決され、次で説明しています。
JMSプロバイダとの間で回復不能なクライアントAPIレベルのメッセージング障害が発生した場合には、プログラマが責任を持って関連するJMSリソースを閉じて再作成し、また必要に応じて失敗した操作を再試行するようにします。JMSリソースを再作成するための推奨手順は、JMSリソースを作成する場合と同様です。たとえば、JMSプロデュースまたはJMSコンシュームの呼出しで例外がスローされた場合は、親のJMS接続またはJMSコンテキストを閉じ、初期JNDIコンテキストを閉じて(まだ開いている場合)、最後に初期コンテキストを再作成し、JMS接続ファクトリおよび宛先をJNDIから再取得して、接続またはJMSContext、セッション、プロデューサまたはコンシューマを再作成します。
サーバー側アプリケーションでの例外処理は、通常、JMS非同期コンテナまたはプーリングを利用することで簡略化されます。
サーバー側メッセージングでの同期アプリケーションのエラー処理では、組込みプーリングを利用して問題を単純に処理できます(たとえば、接続、セッションおよびプロデューサを作成し、各送信済メッセージに対する接続を閉じるなど)。プールにより、キャッシュからオブジェクトが取得され、必要に応じて再作成されます。プーリングは、JMS接続ファクトリにアクセスするリソース参照、またはJMS 2.0 Java EE 7 JMSコンテキスト・インジェクションを使用して透過的に有効化されます。リソース参照によってオブジェクトがプールされる場合でも、通常、エラーの発生後には新しいJMS接続ファクトリまたは宛先オブジェクトを取得するのが最良です(これらのオブジェクトがなんらかの理由で変更されている場合に備えて)。『Oracle WebLogic Server JMSアプリケーションの開発』のEJBやサーブレットと組み合せたWebLogic JMSの使用に対する拡張サポートに関する項を参照してください。
非同期のonMessageサーバー側メッセージングのエラー処理では、通常、WebLogic MDBコンテナを利用するか、MDBが選択肢にない場合はフレームワークからのJMS JCAアダプタを利用するのが最良です。これらのコンテナにより、障害が自動的に処理され、必要に応じて再試行されます。詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』を参照してください。
非同期メッセージング・アプリケーションでコンテナを利用できない場合は、アプリケーションで接続にonException例外リスナーを登録し、障害を検出して処理することを強くお薦めします。javadocのjavax.jms.Connection.setExceptionListener()
、またはJMS 2.0を使用している場合はjavax.jms.JMSContext.setExceptionListener()
を参照してください。
注意:
JMSクライアント・オブジェクトの再作成を必要としない例外タイプが1つあります。それは、メッセージ・プロデューサによってスローされるjavax.jms.ResourceAllocationException
です。この例外は、割当て条件に達したためにサーバーがメッセージを受け入れられないという、メッセージ割当て障害を示しています。
アプリケーションでは、比較的負荷の高い作成操作が頻繁に実行されすぎるのを防ぐために、短期間での操作の再試行を回避する必要があります。これは、ほとんどの障害は即時には解決されず、JNDIコンテキスト、接続、セッション、プロデューサまたはコンシューマなどのJMSクライアント・オブジェクトを短期間のうちに頻繁に破棄して作成すると、メッセージの送信または受信などの通常の実行時操作よりもはるかに高い負荷がかかる可能性があるためです。つまり、短期間での再試行は、他の操作よりもはるかに多くのリソースを消費する可能性があります。Oracleでは、即時に1回再試行した後、少なくとも最大数秒間の間隔をおき、再試行の間隔を段階的に長くすることをお薦めします。
JMSリソースのプールまたはキャッシュは、非常に推奨されるベスト・プラクティスです。エラー処理を簡略化するために、このアドバイスを無視して、各JMSメッセージに対して常に新しいJMS接続やセッションなどを作成するアプリケーションを上書きしたほうがよいと感じることがあります。しかし、これらのアイテムがプールまたはキャッシュされない場合、短期間での再試行について前述したのと同じコスト上の理由により、このアプローチはお薦めしません。メッセージング・アプリケーションによっては、パフォーマンスへの影響が5倍以上になる場合があります。プーリングを使用できない場合は、アプリケーションでJMSオブジェクトをキャッシュして再利用できるようにすることをお薦めします。
操作で成功が返されれば、その操作は成功したと想定できますが、例外がスローされた場合には、常にその操作が失敗したと想定できるわけではありません。たとえば、メッセージ送信の失敗は、生成されたメッセージがサーバーの宛先に正常に届いていても、サーバーが内部の成功応答を送信元クライアントに送信できなければ発生する可能性があります。別の例としては、コミット呼出しの失敗は、必ずしもトランザクションがコミットされなかったことを示しているわけではありません(プロデューサの例と同様の理由により)。
JMS接続ファクトリでの構成可能なWebLogic JMS再接続設定、および対応する再接続weblogic.jms.extension.WLConnection
およびweblogic.jms.extension.JMSContext
APIは非推奨になっています。これらは、将来のリリースでは削除または無視される予定です。
分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic JMSは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。
分散キューは、任意のクラスタ化されたキューイング使用例に対してかなり容易に適用でき、そうした使用例からMDB、SOA JMSアダプタまたはOSAアダプタから使用する際に適用が最も簡単です。MDBおよびアダプタ・オプションは、すべての分散宛先メンバーがコンシューマによって処理されていることを自動的に確認します。さらに、これらのコンテナは障害に対して回復力があり、一般に、宛先タイプに関係なく、コンシューマ・アプリケーションの安全かつマルチスレッド化するための実証済の簡単な方法を提供します。
分散トピックは、直接サブスクライバに制限があり、高度な拡張機能の使用が必要ため、MDB、SOA JMSアダプタまたはOSA JMSアダプタを使用してサブスクライブする場合に最適です。MDBおよびアダプタ・コンテナは、自動的にサブスクリプションおよびコンシューマを設定します。
分散トピックは、「レプリケートされた分散トピック」ではなく、「パーティション化された分散トピック」(共通分散トピック・タイプ)として設定することをお薦めします。これは、RDTは動的クラスタ、WebLogicマルチテナント、またはクラスタをターゲットとして指定されたJMS構成ではサポートされていないが、PDTはすべての拡張機能でスケーラビリティとフル・サポートを提供する傾向があるからです。PDTは、転送ポリシーがレプリケートされるかわりにパーティション化されるように構成された共通分散トピックです。RDTをすでに使用している場合には、PDTに置き換えることを検討してください。
『Oracle WebLogic ServerメッセージドリブンBeanの開発』の「JMSトピックを使用したMDBの構成とデプロイメント」と、『Oracle WebLogic Server JMSアプリケーションの開発』の「分散宛先の使用」およびRDTのPDTへの置き換えに関する項を参照してください。
注意:
WebLogic JMSクライアントは、外部トランザクション・マネージャを直接サポートしません。可能な場合、WebLogic TMを使用します。上級ユーザーの場合、トランザクション・サブシステムの割込みトランザクション・マネージャ機能をXAリソースとして使用できます。『Oracle WebLogic Server JTAアプリケーションの開発』のサード・パーティ・トランザクション・マネージャで管理されるトランザクションへの参加に関する項を参照してください。
JMSリソースと同じサーバーやクラスタで実行するアプリケーションのURLを指定しないでください。最初のコンテキストがURLを指定せずに作成されると、ローカル・サーバーまたはクラスタJNDIが自動的に参照されます。
URLが複数のアドレスに解決する場合、WebLogic Serverクライアントはリスト内のアドレスをランダムに選択して開始し、成功するまで順番に各アドレスを自動で試行します。
本番システムでは、「URL構文」に示す複数のホスト/ポートURL表記を使用せず、最初のホスト名解決にDNSラウンド・ロビンやハードウェア・ロード・バランサを使用することを検討します
注意:
JMS接続ファクトリは、JNDIから取得されます。ただし、デフォルトでは、JNDIコンテキスト・アドレスとは関係なく、接続がロード・バランスされます。JMS接続ファクトリは通常、JMS接続ファクトリの構成済ターゲットに含まれるサーバー間でロード・バランシングを行います。EJBリファレンスと同様に、JMS接続ファクトリは、ドメイン構成から暗黙的に取得され、クラスタの拡張および縮小に伴って暗黙的に更新されるサーバー・アドレスのリストを含む「スマート・スタブ」です。つまり、JNDIコンテキストのURLがクラスタ内の単一のサーバーのみを参照していて、このJNDIコンテキストからクラスタをターゲットに指定されたまたはターゲットがデフォルト指定される接続ファクトリが取得されても、JMS接続はクラスタ全体でロード・バランシングされます。
WebLogic URLの構文およびアプリケーション用のURLの作成に使用する方法を学習します。
WebLogic URL構文は次のようになります。
[t3|t3s|http|https|iiop|iiops]://address[,address]...
説明:
address = hostlist : portlist
hostlist = hostname [,hostname]...
portlist = portrange [+portrange]...
portrange = port [-port]
port-port
を使用してポート範囲を示し、+で複数のポート範囲を分割します。たとえば、簡単なアドレスは、通常t3://hostA:7001
のようになります。アドレスt3://hostA,hostB:7001-7002
は、次のアドレスに相当します。
t3://hostA,hostB:7001+7002
t3://hostA:7001-7002,hostB:7001-7002
t3://hostA:7001+7002,hostB:7001+7002
t3://hostA:7001,hostA:7002,hostB:7001,hostB:7002
JMS順序単位を分散宛先またはSAFインポート済宛先と組み合せて使用する場合は、宛先の順序単位ルーティング・ポリシーを「パス・サービス」オプションに構成し、クラスタの「パス・サービス」を構成することをお薦めします。「パス・サービス」オプションは、新しいメンバーが分散宛先に構成されている場合でも順序を保持し、クラスタ・ターゲットのJMS構成で唯一サポートされているポリシーです。
『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。
厳密なメッセージの順序付けが必要で順序単位機能が使用できない場合には、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージの再配信の順序付けに関する項を参照してください。
さらに、別のベスト・プラクティスとしては、外部JMSサーバー・マッピングをMDB、res-refかコンテキスト・インジェクションJMSプール、またはメッセージング・ブリッジと組み合せて使用する方法があります。これらのコンポーネントは、マッピングに加えて外部JMSサーバーで構成されたセキュリティ資格証明を使用してリモートJMSリソースにアクセスします。
または、WL JMS SAFエージェントを使用して、リモートWebLogic JMSメッセージをローカル・サーバーまたはクラスタに転送することを検討してください。
『Oracle WebLogic Server JMSアプリケーションの開発』の「FAQ :リモートJMSプロバイダの統合」を参照してください。