ヘッダーをスキップ
Oracle® Fusion Middleware高可用性ガイド
12c (12.1.3.0.0)
E56218-02
  目次へ移動
目次
前
前 		 次
次		  

6 JMSおよびJTAの高可用性

この章では、Java Message Service (JMS)およびJava Transaction API (JTA)の高可用性について説明します。

この章には次のトピックが含まれます:


関連項目:

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のドメイン構成およびクラスタ構成に関する項

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

Java Message Service (JMS)は、ネットワーク内のコンピュータ間でメッセージングと呼ばれる正式な通信をサポートするApplication Program Interface (API)です。

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

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

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


関連項目:

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

6.2 JMSおよびJTAの高可用性サービスの構成

移行可能ターゲット(クラスタ内のサーバーから別のサーバーに移行できる特別なターゲット)を使用すると、JMSサービスやJTAサービスを構成して可用性を高めることができます。移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。

JMSサービスを移行できるように構成するには、そのサービスを移行可能ターゲットにデプロイする必要があります。移行可能ターゲットでは、ターゲットをホストできるサーバーのセットを指定し、そのサービスを優先的にホストするサーバーを指定したり、その優先サーバーで障害が発生した場合のバックアップ・サーバー候補を順序付けしたリストを指定したりできます。移行可能なターゲットをホストできるサーバーは常に1つのみです。

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

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


関連項目:

JMSの管理の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』の次の内容に関する各項を参照してください。

  • 高可用性ベスト・プラクティス

  • 「Oracle AQ JMSとの相互運用性」

6.3 ユーザー優先サーバーと候補サーバー

JMSサービスを移行可能ターゲットにデプロイする際は、サービスをホストするユーザー優先サーバーのターゲットを選択できます。また、移行可能ターゲットを構成する場合は、ユーザー優先サーバーで障害が発生したときにサービスをホストできる控えの候補サーバー(CCS: Constrained Candidate Server)を指定することもできます。移行可能ターゲットに控えの候補サーバーが指定されていない場合、JMSサーバーをクラスタ内で使用可能な任意のサーバーに移行できます。

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


関連項目:

詳細は、管理コンソール・オンライン・ヘルプの次の各項目を参照してください。

  • JMS関連サービスのための移行可能ターゲットの構成

  • JTAトランザクション回復サービスの移行可能ターゲットの構成

6.4 ファイル永続性を使用するうえでの考慮事項(WebLogic JMS)

ファイル・システム上に格納されるJMSメッセージとJTAログを構成できます。高可用性を確保するためには、共有ファイル・システムを使用する必要があります。共有ファイル・システムを使用して、これらのアーティファクトを格納する際の考慮事項については、第4章「共有記憶域の使用」を参照してください。


関連項目:

詳細は、『Oracle WebLogic Server JMSリソースの管理』のWebLogic JMSのアーキテクチャおよび環境に関する項を参照してください。

6.4.1 NFSでのファイル・ストアの使用に関する考慮事項

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

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

  • サーバーをサーバー移行用に構成した場合、サーバーは、フェイルオーバー期間の経過後にフェイルオーバー・モードで自動的に起動します。

  • サーバーをサーバー移行用に構成しなかった場合、ノードが完全に再起動した後に同じホスト上のWebLogic Serverを手動で再起動できます。

予期しないマシン障害の後にOracle 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つのドメインに同じディレクトリを参照する同じ名前のストアを含めることはできない、などがあげられます。

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

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

管理コンソールを使用してデフォルト・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

  1. 必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

  2. 「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。

  3. 「サーバーのサマリー」リストで、変更するサーバーを選択します。

  4. 「構成」→「サービス」タブを選択します。

  5. 「デフォルト・ストア」セクションを下にスクロールし、「詳細」をクリックします。

  6. 下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。

  7. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

  8. 変更したサーバーを再起動して変更を反映します。

生成される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>

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

管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

  1. 必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

  2. 「ドメイン構造」ツリーで、「サービス」ノードを開いて「永続ストア」を選択します。

  3. 「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。

  4. カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックします。

  5. 下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。

  6. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

  7. カスタム・ファイル・ストアが使用中の場合、変更を反映するにはサーバーを再起動する必要があります。

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>

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

管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

  1. 必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

  2. 「ドメイン構造」ツリーで、「サービス」ノードを開き、次に「メッセージング」ノードを開いて「JMSサーバー」を選択します。

  3. 「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。

  4. JMSサーバーの「構成」→「全般」タブで、下にスクロールして「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。

  5. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

  6. 変更したサーバーを再起動して変更を反映します。

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>

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

管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

  1. 必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

  2. 「ドメイン構造」ツリーで、「診断」ノードを開いて「アーカイブ」を選択します。

  3. 「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。

  4. 「[server_name]の設定」ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。

  5. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

  6. 変更したサーバーを再起動して変更を反映します。

生成される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サーバーおよび永続ストアに関する項

  • 『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用に関する項

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

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

WLS JMS永続ストアは、ファイルベースのストアまたはデータベース内でJDBCでアクセス可能なストアへの永続性に対応しています。この項では、WLS JMS構成を、ファイルベースの永続ストア(デフォルト構成)からデータベースの永続ストアに変更する方法を説明します。

永続ストアの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用に関する項を参照してください。

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

この項の内容は次のとおりです。

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

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

  • 少なくとも1つのクラスタと1つ以上のJMSサーバーを使用するOracle Fusion Middlewareがインストールされていること

  • JMSサーバーが、ファイル永続ストアを使用すること(デフォルト構成)

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

この項では、WLS JMSを、デフォルトのファイルベースの永続ストアから、データベースベースの永続ストアに切り替える手順を説明します。

次の手順は、データベース永続ストアを使用する構成のJMSサーバーごとに、実行する必要があります。

  1. JDBCストアを作成します。手順の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理』のJDBCストアの使用に関する項を参照してください。


    注意:

    JDBCストアのデータベース表に一意の名前を付けるための接頭辞を、指定する必要があります。

  2. JDBCストアをJMSサーバーに関連付けます。

    1. Weblogic Server管理コンソールで、「サービス」→「メッセージング」→「JMSサーバー」に移動します。

    2. このサーバーに保留メッセージがないことを確認します。「制御」タブで、すべての宛先に対するメッセージの生成および挿入を停止し、残りのメッセージが排出されるのを待ちます。

    3. 「全般的な構成」タブを選択します。「永続ストア」で新しく作成したJDBCストアを選択し、「保存」をクリックします。

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

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

この項では、トランザクション・ログ(TLOG)用のデータベースベースのストアを構成する手順を説明します。JDBC TLOGストアを構成する前に、Oracle Fusion Middlewareの標準的なインストールを行う必要があります。

標準的なインストールの後で、ファイル・システムにTLOGストアを構成します。場合によっては、TLOGをデータベースに格納するよう構成することをお薦めします。

JDBC TLOGをデータベース・ストアに格納するよう構成する手順の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理』のJDBC TLOGストアの使用に関する項を参照してください。

次の点に注意してください。

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


注意:

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

  前
前 		 次
次
  目次へ移動
目次