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

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

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

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

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

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

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

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

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

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


関連項目:

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

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

  • Oracle AQ JMSとの相互運用性

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

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

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


関連項目:

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

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

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

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

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


関連項目:

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

5.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永続ストアの使用に関する項

5.5 トランザクション・リカバリ権限のスキーマの構成

次の操作に対してWebLogic Serverのトランザクション・マネージャを有効にするには、適切なデータベース権限が必要です。

トランザクション・リカバリ権限のスキーマを構成する手順は次のとおりです。

  1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:

    sqlplus "/ as sysdba"

  2. sys.dba_pending_transactionsに対してselectをappropriate_userに付与します。

  3. 任意のトランザクションに対してforceをappropriate_userに付与します。

  前
前 		 次
次
  目次へ移動
目次