| Oracle® Fusion Middleware高可用性ガイド 12c (12.2.1.1) E77258-01 |
|
 前へ |
 次へ |
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のドメイン構成およびクラスタ構成に関する項
注意:
サーバー全体の移行の詳細は、サーバー全体の移行を参照してください。
JMSサービスやJTAサービスを構成して可用性を高めるためには、それらのサービスを、移行可能ターゲット(クラスタ内のサーバーから別のサーバーに移行できる特別なターゲット)にデプロイします。
移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。
移行可能ターゲットは、ターゲットをホストできるサーバーのセットを指定します。移行可能なターゲットをホストできるサーバーは常に1つのみです。また、次を指定します。
サービスのユーザー優先ホスト
優先サーバーが失敗した場合のバックアップ・サーバーの順序リスト
移行可能ターゲットを使用するようにサービスを構成すると、それは、現時点でそれをホストするサーバー・メンバーから独立した存在になります。たとえば、JMSキューがデプロイされているJMSサーバーを、移行可能ターゲットを使用するように構成した場合、そのキューは、特定のサーバー・メンバーが使用可能かどうかに依存せずに動作します。キューは、クラスタ内のいずれかのサーバーが移行可能ターゲットをホストしている場合、常に使用できます。
固定された移行可能サービスは、1) サーバーの障害または、2) 定期的に計画されるメンテナンスの場合、クラスタ内のサーバーから別のサーバーに手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのサーバーにも移行できます。
移行可能ターゲットの構成は、JMSおよびJTAの高可用性の移行可能ターゲットの構成を参照してください。
注意:
JMSの管理の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』の、次の内容を参照してください。
高可用性ベスト・プラクティス
「Oracle AQ JMSとの相互運用性」
移行可能ターゲットを構成するには、ターゲットをホストできるサーバーを指定します。任意の時点で移行可能ターゲットをホストできるサーバーは1つだけです。また、サービスで優先するホストと、優先ホストで障害が発生した場合のバックアップ・サーバーも設定します。
移行可能ターゲットを構成するには、管理コンソール・オンライン・ヘルプの次の項を参照してください。
JMS関連サービスのための移行可能ターゲットの構成
JTAトランザクション回復サービスの移行可能ターゲットの構成
JMSサービスを移行可能ターゲットにデプロイする際は、サービスをホストするユーザー優先サーバーのターゲットを選択できます。ユーザー優先サーバーで障害が発生したときにサービスをホストできる控えの候補サーバー(CCS)を指定することもできます。
移行可能ターゲットにCCSが指定されていない場合、JMSサーバーをクラスタ内で使用可能な任意のサーバーに移行できます。
個別の移行可能ターゲットをJMSサービスに作成すると、必要に応じて、クラスタ内の別々のサーバー上で常に各サービスを継続することができます。また逆に、JTAとJMS両方のCCSとして同じサーバー群を選択し、両方のサービスが確実にクラスタ内の同じサーバーに配置されるように構成することもできます。
ファイル・システムを構成して、JMSメッセージとJTAログを格納します。高可用性を確保するためには、共有ファイル・システムを使用する必要があります。
共有ファイル・システムを使用する際の考慮事項の詳細は、共有記憶域の使用を参照してください。
注意:
詳細は、Oracle WebLogic Server JMSリソースの管理のWebLogic JMSのアーキテクチャおよび環境を参照してください。
JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再開動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーまたは再起動後に異なる問題が発生する可能性があります。
サーバーの再起動の動作を確認するには、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つのドメインに同じディレクトリを参照する同じ名前のストアを含めることはできない、などがあげられます。
ファイル・ストアを使用する場合は、サーバー移行用に、必ずデータベース・ベースのリース・オプションを構成してください。このオプションにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、特定のサーバーの複数のインスタンスが自動的に再起動しなくなります。
予期しないマシン障害の後に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>
予期しないマシン障害の後に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>
予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムで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>
予期しないマシン障害の後にWebLogic Serverが再起動せず、NFSシステムで診断ページング・ファイル・ストアに対するロックが開放されないことがサーバー・ログ・ファイルで示される場合は、ファイルのロックを無効にできます。
管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
生成される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サーバーおよび永続ストアの構成を参照してください。
WLS JMS構成を、ファイルベースの永続ストア(デフォルト構成)からデータベースの永続ストアに変更します。
永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービス用に組み込まれたストレージ・ソリューションです。たとえば、永続的なJMSメッセージを格納できます。
永続ストアは、ファイルベースのストアまたはデータベース内でJDBCでアクセス可能なストアへの永続性に対応しています。永続ストアの詳細は、WebLogic Server永続ストアの管理のWebLogic永続ストアを参照してください。
WebLogicメッセージング・コンポーネントをモニター、制御および構成する一般的なタスクの詳細は、Fusion Middleware ControlによるOracle WebLogic Serverの管理のWebLogic Serverメッセージングを参照してください。
データベース永続ストアを使用したWLS JMSを構成するには、ご使用の設定が特定の要件を満たしていることを確認してください。
設定で次の要件を満たしている必要があります。
少なくとも1つのクラスタと1つ以上のJMSサーバーを使用するOracle Fusion Middlewareがインストールされていること
JMSサーバーが、ファイル永続ストアを使用すること(デフォルト構成)
JMSサーバーをファイルベースの永続ストアからデータベース永続ストアに切り替えられます。
次の手順は、データベース永続ストアを使用するように構成する必要があるJMSサーバーごとに実行する必要があります。
JDBCストアを作成します。Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理のJDBCストアの使用を参照してください。
注意:
JDBCストアのデータベース表に一意の名前を付けるための接頭辞を、指定する必要があります。
JDBCストアをJMSサーバーに関連付けます。
Weblogic Server管理コンソールで、「サービス」→「メッセージング」→「JMSサーバー」に移動します。
このサーバーに保留メッセージがないことを確認します。「制御」タブで、すべての宛先に対するメッセージの生成および挿入を停止し、残りのメッセージが排出されるのを待ちます。
「全般的な構成」タブを選択します。「永続ストア」で新しく作成したJDBCストアを選択し、「保存」をクリックします。
データベース永続ストアを使用して、JMSサーバーが起動されます。
環境に標準のOracle Fusion Middlewareがインストールされていることを確認したら、JDBCトランザクション・ログ(TLOG)ストアを構成できます。
JDBCトランザクション・ログ(TLOG)ストアを構成する前に、標準Oracle Fusion Middlewareがインストールされている必要があります。
インストールの後で、ファイル・システムにTLOGストアを構成します。場合によっては、TLOGをデータベースに格納するよう構成することをお薦めします。データベース・ストアに格納するためにJDBC TLOGを構成する詳細は、WebLogic永続ストアの管理のJDBC TLOGストアの使用を参照してください。
クラスタ内の管理対象サーバー用にJDBC TLOGストアを構成する際には、いくつかのガイドラインに従います。
JDBC TLOGストアを構成するには、次のことが必要です。
クラスタ内の管理対象サーバーごとに、この手順を繰り返してください。
管理対象サーバー名を接頭辞に使用して、それぞれの管理対象サーバーごとに一意のTLOGストア名を作成してください。
永続ストア用に作成したデータ・ソースが、高可用性設定でクラスタにターゲット設定されていることを確認してください。
構成を終了すると、構成済のデータベースベースの永続ストアに、TLOGが送信されます。
注意:
スケール・アップまたはスケール・アウトによって、クラスタに新しい管理対象サーバーを追加する場合は、新しい管理対象サーバー用のJDBC TLOGストアも作成する必要があります。
