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