JMSおよびJTAの高可用性

8 JMSおよびJTAの高可用性

Java Message Service (JMS)サービスやJava Transaction API (JTA)サービスを構成して可用性を高めるためには、それらのサービスを、クラスタ内のサーバーから別のサーバーに移行できる移行可能ターゲットにデプロイします。

JMSおよびJTAの高可用性サービスについて
Java Message Service (JMS)は、ネットワーク内のコンピュータ間でメッセージングと呼ばれる正式な通信をサポートするアプリケーション・プログラム・インタフェース(API)です。
JMSおよびJTAサービスのための移行可能ターゲットについて
JMSサービスやJTAサービスを構成して可用性を高めるためには、それらのサービスを、移行可能ターゲット(クラスタ内のサーバーから別のサーバーに移行できる特別なターゲット)にデプロイします。
JMSおよびJTAの高可用性の移行可能ターゲットの構成
移行可能ターゲットを構成するには、ターゲットをホストできるサーバーを指定します。任意の時点で移行可能ターゲットをホストできるサーバーは1つのみです。また、サービスで優先するホストと、優先ホストで障害が発生した場合のバックアップ・サーバーも設定します。
優先サーバーと候補サーバー
JMSサービスを移行可能ターゲットにデプロイする際は、サービスをホストするユーザー優先サーバーのターゲットを選択できます。ユーザー優先サーバーで障害が発生したときにサービスをホストできる控えの候補サーバー(CCS)を指定することもできます。
ファイル永続性の使用
ファイルの永続性を使用するかわりに、信頼性の向上、クラウド環境での保管、ディザスタ・リカバリ・シナリオでの一貫性の向上を実現するために、データベースにJMSおよびJTAデータを格納することをお薦めします。たとえば、JMSおよびJTAにはそれぞれJDBCストアおよびTLOG-in-DB機能を使用します。ファイル・システムを使用する場合は、高可用性のために共有ファイル・システムを使用する必要があります。
NFSでのファイル・ストアの使用
JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再起動の動作を確認することをお薦めします。NFSの実装に応じて、フェイルオーバーまたは再起動後に異なる問題が発生する可能性があります。
データベース永続ストアを使用したWLS JMSの構成
WLS JMS構成を、ファイルベースの永続ストア(デフォルト構成)からデータベースの永続ストアに変更します。
トランザクション・ログを永続化するためのデータベース・ストアの構成
環境に標準のOracle Fusion Middlewareがインストールされていることを確認したら、JDBCトランザクション・ログ(TLOG)ストアを構成できます。
自動サービス移行およびFMWコンポーネント用のJDBC永続ストアの構成のための構成ウィザードの使用
構成ウィザードの「高可用性のオプション」画面を使用してJDBC永続ストアを自動化し、サービス移行を構成します。この画面は、最初に自動サービス移行、永続ストア、またはその両方を使用するFusion Middlewareクラスタ、および構成ウィザードを使用してドメインに追加され、選択されたHAオプションが自動的に追加される、すべての後続のクラスタを作成するときに表示されます。

親トピック: 高可用性環境の作成

JMSおよびJTAの高可用性サービスについて

Java Message Service (JMS)は、ネットワーク内のコンピュータ間でメッセージングと呼ばれる正式な通信をサポートするアプリケーション・プログラム・インタフェース(API)です。

Java Transaction API (JTA)は、トランザクション・マネージャと分散トランザクション・システム(リソース・マネージャ、アプリケーション・サーバーおよびトランザクション・サーバー)に関わるパーティ間の標準のJavaインタフェースを指定します。

WebLogic JMSでは、宛先のホストJMSサーバーが実行中の場合のみ、メッセージを使用可能です。メッセージが中央の永続ストアにある場合、それにアクセスできるのは、最初にメッセージを格納したサーバーのみです。WebLogicには、障害後にJMSサーバーを自動的に再起動または移行(あるいはその両方)する機能があります。また、同じクラスタ内の複数のJMSサーバー間で宛先をクラスタリング(分散)する機能もあります。

サーバー全体の移行または自動サービス移行のいずれかを使用すれば、JMSサーバーを自動的に再起動または移行(フェイルオーバー)する、あるいはその両方が可能です。

ノート:

JMSまたはJTAの操作の詳細は、次を参照してください。

Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理のWebLogic JMSクラスタリングの構成
Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理のOracle AQ JMSとの相互運用性
Oracle WebLogic Server JTAアプリケーションの開発のJTAの構成
管理コンソール・オンライン・ヘルプのドメインのJTAオプションの構成に関する項およびクラスタのJTAオプションの構成に関する項。

ノート:

サーバー全体の移行の詳細は、サーバー全体の移行を参照してください。

親トピック: JMSおよびJTAの高可用性

JMSおよびJTAサービスのための移行可能ターゲットについて

JMSサービスやJTAサービスを構成して可用性を高めるためには、それらのサービスを、移行可能ターゲット(クラスタ内のサーバーから別のサーバーに移行できる特別なターゲット)にデプロイします。

移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。

移行可能ターゲットは、ターゲットをホストできるサーバーのセットを指定します。移行可能なターゲットをホストできるサーバーは常に1つのみです。また、次を指定します。

サービスのユーザー優先ホスト
優先サーバーが失敗した場合のバックアップ・サーバーの順序リスト

移行可能ターゲットを使用するようにサービスを構成すると、それは、現時点でそれをホストするサーバー・メンバーから独立した存在になります。たとえば、JMSキューがデプロイされているJMSサーバーを、移行可能ターゲットを使用するように構成した場合、そのキューは、特定のサーバー・メンバーが使用可能かどうかに依存せずに動作します。キューは、クラスタ内のいずれかのサーバーが移行可能ターゲットをホストしている場合、常に使用できます。

固定された移行可能サービスは、1) サーバーの障害または、2) 定期的に計画されるメンテナンスの場合、クラスタ内のサーバーから別のサーバーに手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのサーバーにも移行できます。

移行可能ターゲットの構成は、JMSおよびJTAの高可用性の移行可能ターゲットの構成を参照してください。

ノート:

JMSの管理の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』の次のトピックを参照してください。

親トピック: JMSおよびJTAの高可用性

JMSおよびJTAの高可用性の移行可能ターゲットの構成

移行可能ターゲットを構成するには、ターゲットをホストできるサーバーを指定します。任意の時点で移行可能ターゲットをホストできるサーバーは1つだけです。また、サービスで優先するホストと、優先ホストで障害が発生した場合のバックアップ・サーバーも設定します。

移行可能ターゲットを構成するには、管理コンソール・オンライン・ヘルプの次の項を参照してください。

親トピック: JMSおよびJTAの高可用性

優先サーバーと候補サーバー

JMSサービスを移行可能ターゲットにデプロイする際は、サービスをホストするユーザー優先サーバーのターゲットを選択できます。ユーザー優先サーバーで障害が発生したときにサービスをホストできる控えの候補サーバー(CCS)を指定することもできます。

移行可能ターゲットにCCSが指定されていない場合、JMSサーバーをクラスタ内で使用可能な任意のサーバーに移行できます。

個別の移行可能ターゲットをJMSサービスに作成すると、必要に応じて、クラスタ内の別々のサーバー上で常に各サービスを継続することができます。また逆に、JTAとJMS両方のCCSとして同じサーバー群を選択し、両方のサービスが確実にクラスタ内の同じサーバーに配置されるように構成することもできます。

親トピック: JMSおよびJTAの高可用性

ファイル永続性の使用

ファイルの永続性を使用するかわりに、信頼性の向上、クラウド環境での保管、ディザスタ・リカバリ・シナリオでの一貫性の向上を実現するために、データベースにJMSおよびJTAデータを格納することをお薦めします。たとえば、JMSおよびJTAにはそれぞれJDBCストアおよびTLOG-in-DB機能を使用します。ファイル・システムを使用する場合は、高可用性のために共有ファイル・システムを使用する必要があります。

WebLogicは、次のように複数の目的を持つ複数のタイプのファイル・ストアを提供します:

各WebLogic Serverには、デフォルトのファイル・ストアがあります。ただし、JMSメッセージ、JTAトランザクション、EJBタイマーなどのクリティカルなデータの格納には、デフォルトのファイル・ストアを使用しないでください。かわりに、JDBCストア、TLOG-in-DBおよびデータベース格納タイマーを使用する必要があります。デフォルト・ストアに格納される非クリティカル・データの例は、アプリケーションのライフサイクル状態(特定のアプリケーションが管理上一時停止されているかどうかなど)です。デフォルトのファイル・ストアにクリティカル・データがない場合、デフォルトのファイル・ストアのファイル・ロックを無効にするリスクが軽減されるため、壊滅的な破損が発生した場合に、このようなストアを削除しても安全です。
JMSに大きいメッセージ・バックログがある場合、WebLogic JMSページング・ストアはアクティブです。サーバーが実行されていない場合、JMSページング・ファイル内のデータは再ロードされないため、WebLogic Serverが実行されていないときにファイルを安全に削除できます。対応する永続メッセージは、デフォルトのファイル・ストア、カスタム・ファイル・ストアまたはカスタムJDBCストアに同時に格納されます。
WebLogic診断ストアには、クリティカルでない診断データが含まれます。これらは、診断のオーバーヘッドを最小限に抑えるために非常に高いパフォーマンスを実現するバッファリング・モード内で実行されますが、これにより障害後の破損のリスクが高まります。このようなファイルが破損した場合は、WebLogic Serverが再起動しても安全であり、ファイルを削除しても安全です。

『Oracle WebLogic Serverのパフォーマンスのチューニング』のWebLogic永続ストアのチューニングに関する項を参照してください。

親トピック: JMSおよびJTAの高可用性

NFSでのファイル・ストアの使用

JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再開動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーまたは再起動後に異なる問題が発生する可能性があります。

サーバーの再開動作の検証
サーバーの再起動の動作を確認するには、WebLogic Serverの実行時に、それらのサーバーをホストするノードを異常停止させます。
ファイル・ロックを無効にするための前提条件
システム・プロパティを使用したすべてのストアのファイル・ロックの無効化
デフォルトのファイル・ストアのファイル・ロックの無効化
予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムでファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。
カスタム・ファイル・ストアのファイル・ロックの無効化
予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムでファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。
JMSページング・ファイル・ストアのファイル・ロックの無効化
予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムでJMSページング・ファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。
診断ファイル・ストアのファイル・ロックの無効化
予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムで診断ページング・ファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。

親トピック: JMSおよびJTAの高可用性

サーバーの再開動作の検証

サーバーの再起動の動作を確認するには、WebLogic Serverの実行時に、それらのサーバーをホストするノードを異常停止させます。

サーバーをサーバー移行用に構成した場合、サーバーは、フェイルオーバー期間の経過後にフェイルオーバー・モードで自動的に起動します。
サーバーをサーバー移行用に構成しなかった場合、ノードが完全に再起動した後、同じホスト上でWebLogic Serverを手動で再起動できます。

予期しないマシン障害の後にWebLogic Serverが再起動しない場合は、サーバーのログ・ファイルを参照して、次のようなI/O例外によるものかどうかを確認してください。

<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent 
store "_WLS_server_1" could not be deployed: 
weblogic.store.PersistentStoreException: java.io.IOException: 
[Store:280021]There was an error while opening the file store file 
"_WLS_SERVER_1000000.DAT" 
weblogic.store.PersistentStoreException: java.io.IOException: 
[Store:280021]There was an error while opening the file store file 
"_WLS_SERVER_1000000.DAT" 
at weblogic.store.io.file.Heap.open(Heap.java:168) 
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
...
java.io.IOException: Error from fcntl() for file locking, Resource
temporarily unavailable, errno=11

このエラーは、NFSv3システムでファイル・ストアに対するロックが解放されていないときに発生します。WebLogic Serverは、同じ管理対象サーバーの2つのインスタンスが偶然起動した場合にデータ破損が発生しないように、JMSデータおよびトランザクション・ログを格納しているファイルに対するロックを保持します。NFSv3ストレージ・デバイスはロック所有者を追跡しないため、ロック所有者が失敗した場合、NFSはロックを無期限に保持します。このため、予期しないマシン障害とそれに続く再起動の後に、WebLogic Serverがロックを取得しようとしても、失敗する可能性があります。

このエラーの解決方法は、NFS環境によって異なります: (このトピックの更新については、『Oracle Fusion Middlewareリリース・ノート』を参照してください。)

NFSv4環境の場合、サーバー移行を完了する所要時間内にロックを解放するよう、NASサーバーでチューニング・パラメータを設定できます(この項の手順に従う必要はありません)。ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックに関する情報は、使用しているストレージのベンダーのドキュメントを参照し、結果をテストしてください。

NFSv3環境の場合、次の項で、デフォルト・ファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストア、診断ファイル・ストアに対するWebLogicのファイル・ロック・メカニズムを無効化する方法について説明します。

警告:

NFSv3のファイル・ロックにより、複数の管理対象サーバーが任意の時点で同じファイル・ストアに書込みを行う場合に、深刻なファイルの破損が発生しないようにします。

NFSv3のファイル・ロックを無効化する場合は、特定のファイル・ストアに書込みを行う管理対象サーバーが1つのみとなるよう、管理手順や管理ポリシーを実装する必要があります。破損は、同じクラスタまたは別のクラスタ、同じノードまたは別のノード、あるいは同じドメインまたは別のドメインに管理対象サーバーが2つ存在することにより発生する可能性があります。

ポリシーの例としては、ドメインをコピーしない、WLS構成オブジェクト(サーバーやストア)の一意のネーミング・スキームを強制しない、各ドメインに独自の記憶域ディレクトリを必ず含める、2つのドメインに同じディレクトリを参照する同じ名前のストアを含めることはできない、などがあげられます。

ファイル・ストアを使用する場合は、サーバー移行用に、必ずデータベース・ベースのリース・オプションを構成してください。このオプションにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、特定の管理対象サーバーの複数のインスタンスが自動的に再起動しなくなります。

親トピック: NFSでのファイル・ストアの使用

ファイル・ロックを無効にするための前提条件

デフォルトでは、すべてのファイル・ストアはロックされます。WebLogicファイル・ロック機能は、同時実行シナリオで発生する可能性のある重大なファイル破損を防ぐように設計されています。ファイル・ロックを無効にするリスクを軽減するには、次の前提条件タスクを実行します:

ファイル・ストアを使用するサーバーがサーバー移行用に構成されている場合、デフォルトのコンセンサス・リースではなく、必ずデータベースベースのクラスタ・リース・オプションを構成してください。これにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、特定のWebLogic Serverの複数のインスタンスの自動的な同時再起動が防止されます。
自動サービス移行(ASM)を使用しているファイル・ストアでは、ファイル・ロックを無効にしないでください。
- ASMは、安全に機能するためにファイル・ストア・ロックを必要とし、次のシナリオでアクティブ化されます:
  1. カスタム・ファイル・ストア・ターゲットが移行可能ターゲットに設定され、移行可能ターゲットが手動(デフォルト)以外の移行ポリシーを使用して構成されます。
  2. ストアが「オフ」(デフォルト)以外の移行ポリシーで構成されている場合、カスタム・ファイル・ストア・ターゲットはWebLogicクラスタに設定されます。
  3. WebLogic Serverは、手動(デフォルト)以外の移行ポリシー値を持つJTA移行可能ターゲットで構成されます。これにより、デフォルトのファイル・ストアの移行が発生する可能性があります。
- ASMとファイル・ロックの無効化の両方が必要な場合は、ファイル・ストアではなくデータベース・ストアにクリティカルなデータを格納して、ファイルの破損のリスクを回避します。たとえば、ファイル・ストアのかわりにカスタムJDBCストアを使用し、各WebLogic Serverのデフォルト・ファイル・ストアのかわりにJDBC TLOGストアを使用するようにJTAを構成します。
ヒューマン・エラーを回避し、任意の時点でサーバーの1つのインスタンスのみを手動で起動するには、追加の手続き上の予防措置を実施する必要があります。同様に、2つのドメインに、同じディレクトリを参照する同じ名前のストアがあることがないように、注意を払う必要があります。

親トピック: NFSでのファイル・ストアの使用

システム・プロパティを使用したすべてのストアのファイル・ロックの無効化

WebLogic Server 14.1.2リリース以降では、次に示すように、weblogic.ServerコマンドラインでJavaシステム・プロパティを指定するか、JVMの起動スクリプトを指定して、デフォルト、ページング、診断およびカスタム・ファイル・ストアを含むすべてのファイル・ストアのロックを無効にできます:

"-Dweblogic.store.file.LockEnabled=false"

親トピック: NFSでのファイル・ストアの使用

デフォルト・ファイル・ストアのファイル・ロックの無効化

予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムでファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。

管理コンソールを使用してデフォルト・ファイル・ストアのファイル・ロックを無効化するには:

必要に応じ、「チェンジ・センター」で「ロックして編集」をクリックします。
「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。
「サーバーのサマリー」リストで、変更するサーバーを選択します。
「構成」>「サービス」タブを選択します。
「デフォルト・ストア」のセクションへスクロール・ダウンし、「詳細」をクリックします。
スクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。

生成されるconfig.xmlのエントリは、次のようになります。

<server>
 <name>examplesServer</name>
 ...
 <default-file-store>
 <synchronous-write-policy>Direct-Write</synchronous-write-policy>
 <io-buffer-size>-1</io-buffer-size>
 <max-file-size>1342177280</max-file-size>
 <block-size>-1</block-size>
 <initial-size>0</initial-size>
 <file-locking-enabled>false</file-locking-enabled>
 </default-file-store>
 </server>

親トピック: NFSでのファイル・ストアの使用

カスタム・ファイル・ストアのファイル・ロックの無効化

予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムでカスタム・ファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。

管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効化するには:

必要に応じて、「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで「サービス」ノードを開きます。「永続ストア」を選択します。
「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。
カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックします。
スクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
カスタム・ファイル・ストアが使用中であった場合、変更を反映するには、サーバーを再起動する必要があります。

config.xmlのエントリは、次の例のようになります。

<file-store>
 <name>CustomFileStore-0</name>
 <directory>C:\custom-file-store</directory>
 <synchronous-write-policy>Direct-Write</synchronous-write-policy>
 <io-buffer-size>-1</io-buffer-size>
 <max-file-size>1342177280</max-file-size>
 <block-size>-1</block-size>
 <initial-size>0</initial-size>
 <file-locking-enabled>false</file-locking-enabled>
 <target>examplesServer</target>
 </file-store>

親トピック: NFSでのファイル・ストアの使用

JMSページング・ファイル・ストアのファイル・ロックの無効化

予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムでJMSページング・ファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。

管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効化するには:

必要に応じて、「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「メッセージング」ノードを拡張して、「JMSサーバー」を選択します。
「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。
「JMSサーバー」の「構成」から「一般」タブに進み、スクロール・ダウンします。「ページング・ファイル・ロックの有効化」チェック・ボックスの選択を解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。

config.xmlファイルのエントリは、次の例のようになります。

 <jms-server>
 <name>examplesJMSServer</name>
 <target>examplesServer</target>
 <persistent-store>exampleJDBCStore</persistent-store>
 ...
 <paging-file-locking-enabled>false</paging-file-locking-enabled>
 ...
 </jms-server>

親トピック: NFSでのファイル・ストアの使用

診断ファイル・ストアのファイル・ロックの無効化

予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムで診断ページング・ファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。

管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには:

必要に応じて、「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで「診断」ノードを開きます。「アーカイブ」を選択します。
「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。
[server_name]の設定ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。

生成されるconfig.xmlファイルは、次のようになります。

 <server>
 <name>examplesServer</name>
 ...
 <server-diagnostic-config>
 <diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
 <diagnostic-store-file-locking-enabled>false</diagnostic-store-file-locking-
enabled>
 <diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type>
 <data-retirement-enabled>true</data-retirement-enabled>
 <preferred-store-size-limit>100</preferred-store-size-limit>
 <store-size-check-period>1</store-size-check-period>
 </server-diagnostic-config>
 </server>

ノート:

『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSサーバーおよび永続ストアに関する項を参照してください。

親トピック: NFSでのファイル・ストアの使用

データベース永続ストアを使用したWLS JMSの構成

WLS JMS構成を、ファイルベースの永続ストア(デフォルト構成)からデータベースの永続ストアに変更します。

永続ストアについて
永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービス用に組み込まれたストレージ・ソリューションです。たとえば、永続的なJMSメッセージを格納できます。
データベース永続ストアを使用したWLS JMSの構成の前提条件
データベース永続ストアを使用したWLS JMSを構成するには、ご使用の設定が特定の要件を満たしていることを確認してください。
WLS JMSでのファイルベースの永続ストアからデータベース永続ストアへの切替え
JMSサーバーをファイルベースの永続ストアからデータベース永続ストアに切り替えられます。

親トピック: JMSおよびJTAの高可用性

永続ストアについて

永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービス用に組み込まれたストレージ・ソリューションです。たとえば、永続的なJMSメッセージを格納できます。

永続ストアは、ファイルベースのストアまたはデータベース内でJDBCでアクセス可能なストアへの永続性に対応しています。永続ストアの詳細は、WebLogic Server永続ストアの管理のWebLogic永続ストアを参照してください。

WebLogicメッセージング・コンポーネントをモニター、制御および構成する一般的なタスクの詳細は、Fusion Middleware ControlによるOracle WebLogic Serverの管理のWebLogic Serverメッセージングを参照してください。

親トピック: データベース永続ストアを使用したWLS JMSの構成

データベース永続ストアを使用したWLS JMSの構成の前提条件

データベース永続ストアを使用したWLS JMSを構成するには、ご使用の設定が特定の要件を満たしていることを確認してください。

設定で次の要件を満たしている必要があります。

少なくとも1つのクラスタと1つ以上のJMSサーバーを使用するOracle Fusion Middlewareがインストールされていること
JMSサーバーが、ファイル永続ストアを使用すること(デフォルト構成)

親トピック: データベース永続ストアを使用したWLS JMSの構成

WLS JMSでのファイルベースの永続ストアからデータベース永続ストアへの切替え

JMSサーバーをファイルベースの永続ストアからデータベース永続ストアに切り替えられます。

この手順のステップに従って、データベース永続ストアを使用するように構成する必要があるJMSサーバーごとに実行する必要があります。

JDBCストアを作成します。Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理のJDBCストアの使用を参照してください。

ノート:

JDBCストアのデータベース表に一意の名前を付けるための接頭辞を、指定する必要があります。
JDBCストアをJMSサーバーに関連付けます。
1. Weblogic Server管理コンソールで、「サービス」→「メッセージング」→「JMSサーバー」に移動します。
2. このサーバーに保留メッセージがないことを確認します。「制御」タブで、すべての宛先に対するメッセージの生成および挿入を停止し、残りのメッセージが排出されるのを待ちます。
3. 「全般的な構成」タブを選択します。「永続ストア」で新しく作成したJDBCストアを選択し、「保存」をクリックします。

データベース永続ストアを使用して、JMSサーバーが起動されます。

親トピック: データベース永続ストアを使用したWLS JMSの構成

トランザクション・ログを永続化するためのデータベース・ストアの構成

環境に標準のOracle Fusion Middlewareがインストールされていることを確認したら、JDBCトランザクション・ログ(TLOG)ストアを構成できます。

JDBC TLOGストアを構成するための要件
JDBCトランザクション・ログ(TLOG)ストアを構成する前に、標準Oracle Fusion Middlewareがインストールされている必要があります。
JDBC TLOGストアの構成
クラスタ内の管理対象サーバー用にJDBC TLOGストアを構成する際には、いくつかのガイドラインに従います。

親トピック: JMSおよびJTAの高可用性

JDBC TLOGストアを構成するための要件

JDBCトランザクション・ログ(TLOG)ストアを構成する前に、標準Oracle Fusion Middlewareがインストールされている必要があります。

インストールの後で、ファイル・システムにTLOGストアを構成します。場合によっては、TLOGをデータベースに格納するよう構成することをお薦めします。データベース・ストアに格納するためにJDBC TLOGを構成する詳細は、WebLogic Server永続ストアの管理のJDBC TLOGストアの使用に関する項を参照してください。

親トピック: トランザクション・ログを永続化するためのデータベース・ストアの構成

JDBC TLOGストアの構成

クラスタ内の管理対象サーバー用にJDBC TLOGストアを構成する際には、いくつかのガイドラインに従います。

JDBC TLOGストアを構成するには、次のことが必要です。

クラスタ内の管理対象サーバーごとに、この手順を繰り返してください。
管理対象サーバー名を接頭辞に使用して、それぞれの管理対象サーバーごとに一意のTLOGストア名を作成してください。
永続ストア用に作成したデータ・ソースが、高可用性設定でクラスタにターゲット設定されていることを確認してください。

構成を終了すると、構成済のデータベースベースの永続ストアに、TLOGが送信されます。

ノート:

スケール・アップまたはスケール・アウトによって、クラスタに新しい管理対象サーバーを追加する場合は、新しい管理対象サーバー用のJDBC TLOGストアも作成する必要があります。

親トピック: トランザクション・ログを永続化するためのデータベース・ストアの構成

自動サービス移行およびFMWコンポーネント用のJDBC永続ストアの構成のための構成ウィザードの使用

構成ウィザードの「高可用性のオプション」画面を使用して、JDBC永続ストアを自動化し、サービス移行を構成します。この画面は、最初に自動サービス移行、永続ストア、またはその両方を使用するFusion Middlewareクラスタ、および構成ウィザードを使用してドメインに追加され、選択されたHAオプションが自動的に追加される、すべての後続のクラスタを作成するときに表示されます。

「自動サービス移行の有効化」オプションを選択する場合、自動サービス移行に必要な移行可能ターゲット定義を構成します。データベースまたはコンセンサスのいずれかのリース・オプションを選択できます。「データベース・リーシング」を選択すると、データソースのリーシングも構成されます。

同じ画面で、オプション「JTAトランザクション・ログ永続性」および「JMSサーバー永続性」を使用して、JDBCストアを自動的に構成します。Fusion Middlewareコンポーネント・テンプレートは、JMSサーバーのJDBC永続ストアおよびトランザクション・ログを自動的に定義します。

ドメインの作成プロセス中の「高可用性のオプション」画面での選択内容の詳細は、「高可用性オプションの構成」を参照してください。

親トピック: JMSおよびJTAの高可用性