| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 12c リリース1 (12.1.1) B65905-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 12c リリース1 (12.1.1) B65905-02 |
|
前 |
次 |
この章では、永続ストアをチューニングする方法について説明します。永続ストアは、永続性が必要なWebLogic Serverのサブシステムおよびサービスに高性能な組込みストレージ・ソリューションを提供します。
この章を読み込む前に、WebLogicストアの管理と監視についてよく知っておくことをお薦めします。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使い方を参照してください。
次の項では、永続ストアの使い方について説明します。
管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルト・ストアはファイルベースのストアで、サーバー・インスタンスのdata\store\defaultディレクトリに格納された一連のファイルにデータを保持します。デフォルト・ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト・ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができます。たとえば、永続ストアが構成されていないJMSサーバーは、管理対象サーバー用のデフォルトのストアを使用して永続メッセージングをサポートします。次を参照してください:
『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項。
Oracle WebLogic Server管理コンソール・ヘルプのデフォルト・ストアの設定の変更に関する項。
デフォルトのファイル・ストアを使用するだけでなく、特定のニーズに合わせてファイル・ストアやJDBCストアを構成することもできます。デフォルト・ファイル・ストアと同様、カスタム・ファイル・ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、特定のストレージ・デバイスにデータを保持するカスタム・ファイル・ストアを作成することもできます。ファイル・ストアのディレクトリを構成する場合は、そのファイル・ストアが配置されているサーバー・インスタンスにアクセスできるディレクトリを設定する必要があります。
JDBCストアは、リレーショナル・データベースをストレージとして使用している場合に構成できます。JDBCストアを使用することで、指定のJDBCデータ・ストアを介してアクセスできる標準のJDBC対応データベースに永続メッセージを格納できます。JDBCストアのデータベース表に格納されたデータには、WLStoreという論理名が付けられます。データベースの高可用性とパフォーマンスを構成するかどうかは、データベース管理者の判断です。次を参照してください:
『Oracle WebLogic Serverサーバー環境の構成』のカスタム永続ストアの使用タイミング。
『Oracle WebLogic Serverサーバー環境の構成』のファイル・ストアとJDBCストアの比較。
『Oracle WebLogic Serverサーバー環境の構成』のカスタム(ユーザー定義)ファイル・ストアの作成。
『Oracle WebLogic Serverサーバー環境の構成』のJDBCストアの作成。
JDBC TLOGストアを構成してトランザクション・ログがデータベースに永続化されるようにできます。これによって、ベースとなるデータベースのレプリケーションとHA特性を利用したり、障害時リカバリを簡易化したり、トランザクション・リカバリ・サービスの移行を改善できます。『Oracle WebLogic Serverサーバー環境の構成』のJDBC TLogストアの使用に関する項を参照してください。
各JMSサーバーではファイルベースのページング・ストアが暗黙的に作成されます。このストアは、WebLogic Server JVMが低メモリー状態で動作しているときに、非永続性メッセージおよび永続メッセージのページングに使用されます。ページング・ストアを使用すると、アプリケーションによってはディスク・アクティビティが増大することがあります。
オプションで、ページングが開始するしきい値設定およびディレクトリの場所を変更できます。可能な場合、一時ディレクトリなどローカルなファイル・システムにページング・ストア・ディレクトリの場所を指定すると、パフォーマンスを向上できます。ページング・ストア・ファイルはJMSサーバーを再起動するたびに自動的に再読込みされるので、どこからでもアクセスできる場所にバックアップ、レプリケートまたは配置する必要はありません。『Oracle WebLogic Server JMSの構成と管理』のWebLogic Server 9.x以降でJMSサーバーの動作を参照してください。
|
注意: ページングされた永続メッセージは、次の2つの場所に格納される可能性があります。
|
ローカルでマウントされたエンタープライズクラスのフラッシュ・ストレージ・デバイス上のディレクトリを参照するようJMSサーバーのページング・ディレクトリを構成すると、多くの場合、JMSメッセージ(永続または非永続)のページングのパフォーマンスを向上させることができます。これは、他のテクノロジよりも大幅に速い可能性があります。
|
注意: ほとんどのフラッシュ・ストレージ・デバイスは単一障害点で、通常、ローカル・デバイスとしてのみアクセス可能です。障害の後にデータをリカバリしたり、必要に応じて自動的に再構築したりしないJMSサーバーのページング・ディレクトリとしては適しています。 安全にリカバリできる必要のあるデータが通常含まれるカスタム・ストアやデフォルト・ストアとしては、ほとんどの場合、フラッシュ・ストレージ・デバイスは適していません。デフォルト・ストアまたはカスタム・ストアの |
フラッシュ・ストレージ・デバイスを使用してJMSメッセージをページングするには、次の手順を使用します。
JMSサーバーのメッセージ・ページング・ディレクトリ属性をフラッシュ・ストレージ・デバイスのパスに設定します。「メッセージ・ページング・ディレクトリの指定」を参照してください。
「メッセージ・バッファ・サイズ」属性(ページングのアクティブ化を制御)をチューニングします。高速のI/O処理によって負荷を吸収できる場合、より低いしきい値を使用できます。「「メッセージ・バッファ・サイズ」オプションのチューニング」を参照してください。
JMSサーバーの割当てをチューニングし、フラッシュ・ストレージの領域の制限に対応します。これによって、JMSサーバーで、デバイスに格納できる以上のメッセージをページングしなくなります。場合によっては、ランタイム・エラーや自動停止が発生することがあります。控えめな目安として、ページ・ファイルの使用量は、最低1.5 * ((アクティブなメッセージの最大数) * (512 + メッセージ本文の最大サイズ)) (16MB単位で切上げ)と想定します。「割当ての定義」を参照してください。
診断ストアは、ファイル・ストアで、暗黙的に「無効化された」同期書込みポリシーを使用します。診断ストアは、WebLogicサーバーの診断情報を格納します。WebLogicサーバーのインスタンスごとに1つの診断ストアが構成されています。『Oracle WebLogic Server診断フレームワークの構成と使用』の診断アーカイブの構成を参照してください。
同じサーバー・インスタンスを共有するサブシステムでは、サブシステムごとにストアを使用するのではなく複数のサブシステムで1つのストアを共有します。ストアを共有すると、次の理由から効率性が高まります。
同時発生する複数のリクエストを1つのストアで1つのI/Oにまとめることで、全体のディスク使用率が減少します。
参加するリソースが1つだけのトランザクションは軽量の1フェーズ・トランザクションです。逆に、複数のストアが関与するトランザクションは、より重い2フェーズ・トランザクションになります。
たとえば、同じサーバー・インスタンスで動作するすべてのSAFエージェントやJMSサーバーは、同じストアを共有するように構成します。
古いストア(群)を拡張しなくなった場合にのみ、新しいストアを追加します。
次の項では、JDBCストアのチューニングについて説明します。
JDBCストアのI/O負荷が高い場合、複数のJDBC接続を使用してI/O操作を同時に処理するようJDBCストアを構成すると、パフォーマンスが向上します。『Oracle WebLogic Serverサーバー環境の構成』のJDBCストアのI/Oマルチスレッドの有効化に関する項を参照してください。
Oracle BLOBSを使用する場合、ThreeStepThreshold値をチューニングしてパフォーマンスを改善できます。詳細は、『Oracle WebLogic Serverサーバー環境の構成』の「Oracle BLOBレコード列の有効化」を参照してください。
空のストアを初期化するために使用されるJDBCストアDDLの場所は、構成できるようになっています。これにより、データベース表を作成するためのカスタムDDLを簡単に使用できるようになっています。このDDLはデータベースの特定のパフォーマンス・チューニングに使用されることもあります。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成に関する項および『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項を参照してください。
次の項では、ファイル・ストアのチューニングについて説明します。
次の項では、ファイル・ストアのチューニングに関する一般的な情報を提供します。
基本的な(非RAIDの)ディスク・ハードウェアの場合、ファイル・ストアごとに1つの専用のディスクを使用することを検討します。ディスク上の別のストアと競合しなくてよい場合、ストアの処理速度は4 - 5倍上昇します。構成された各ストアや各JMSサーバー用のJMSページング・ストアの他に、デフォルト・ファイル・ストアがあることに留意してください。
カスタムとデフォルトのファイル・ストアの場合は、同期書込みポリシーをチューニングします。
「直接書込み - キャッシュあり」、「直接書込み」および「キャッシュ・フラッシュ」の3つのトランザクションの安全な同期書込みポリシーがあります。「直接書込み - キャッシュあり」は、これらのポリシーのうち最もパフォーマンスがよく、「キャッシュ・フラッシュ」は、最もパフォーマンスの悪いポリシーです。「直接書込み」は、デフォルトです。他のポリシーとは異なり、「直接書込み - キャッシュあり」は、プライマリ・ファイルに加えてキャッシュ・ファイルを作成します。
「無効化された」同期書込みポリシーは、トランザクションで安全ではありません。「無効化された」書込みポリシーを使用すると、特にクライアント負荷が低いときに、パフォーマンスを大幅に向上します。ただし、書込みポリシーは、システムの開始時および停電のときに非同期になって、データが失われる可能性があるので、安全ではありません。
『Oracle WebLogic Serverサーバー環境の構成』の同期書込みポリシーの構成のガイドラインに関する項を参照してください。
|
注意: 以前のバージョンのMicrosoft Windowsでは、Windowsのデフォルトの |
ベンダーを直接的に比較する場合、永続ストアの書込みポリシーをすべて同等のポリシーにします。WebLogic以外の一部のベンダーには、デフォルトで「無効」に相当する動作をするものがあります。
同期書込みポリシーに応じて、カスタム・ストアとデフォルト・ストアには、複数の追加のチューニング可能な属性があります。これにより、パフォーマンスが向上する可能性があります。これには、CacheDirectory、MaxWindowBufferSize、IOBufferSize、BlockSize、InitialSizeおよびMaxFileSizeなどがあります。詳細は、Oracle WebLogic Server MBeanリファレンスのJMSFileStoreMBeanに関する項を参照してください。
|
注意:
|
ディスク・パフォーマンスがボトルネックの状況が続く場合、組込みのライトバック・キャッシュを備えたディスク・コントローラ・ハードウェアまたはRAIDコントローラ・ハードウェアの購入を検討します。これらのキャッシュで一時的に永続データを揮発性のメモリーへ保存すると、大幅にパフォーマンスが向上します。ライトバック・キャッシュでのトランザクションを確実に安全なものにするには、ライトバック・キャッシュを停電、ホスト・マシン障害、およびオペレーティング・システム障害から保護する必要があります。このような保護機能は通常、バッテリ・バックアップのあるライトバック・キャッシュで提供されます。
「直接書込み - キャッシュあり」同期書込みポリシーは、通常最もパフォーマンスのよいオプションで、トランザクション上安全なディスク書込みが行われます。通常は、「無効」同期書込みポリシーほどパフォーマンスはよくありませんが、「無効」ポリシーは、システム障害の発生時にバッファされた書込みが失われないようにする方法がない場合、本番システムに対して安全なオプションではありません。
直接書込み - キャッシュありファイル・ストアは、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期して書込みます。また、ファイル・ストアは、ファイル・ストアの構成のCacheDirectory属性で定義された場所にある、対応するキャッシュ・ファイルにも非同期に書込みます。キャッシュ・ディレクトリとプライマリ・ファイルは、別々の目的に使用され、異なる場所に存在する必要があります。多くの場合は、プライマリ・ファイルは、高可用性のためにリモート記憶域に格納されている必要があります。キャッシュ・ファイルは、高可用性ではなく、厳密にパフォーマンスのために使用されるので、ローカルな場所に格納できます。
「直接書込み - キャッシュあり」同期書込みポリシーを選択すると、次の複数の追加のチューニング・オプションを考慮する必要があります。
CacheDirectoryの設定。パフォーマンスのためにキャッシュ・ディレクトリがローカルなファイル・システムに存在する必要があります。デフォルトでは、オペレーティング・システムのtempディレクトリに存在しています。
MaxWindowBufferSizeおよびIOBufferSize属性の増加。これらの属性は、ファイル・ストアのネイティブなメモリー使用量をチューニングします。
InitialSizeおよびMaxFileSize属性の増加。これらの属性は、それぞれストアの初期サイズとストア内の特定のファイルの最大サイズをチューニングします。
BlockSize属性のチューニング。「ファイル・ストアのブロック・サイズのチューニング」を参照してください。
個別のチューニング・パラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのJMSFileStoreMBeanに関する項を参照してください。
エンタープライズクラスのフラッシュ・ドライブを使用すると、リアルタイム・アプリケーションでのデータのアクセスが回転式ディスクより大幅に速くなり、他のタスクの処理にメモリーを使用できるため、I/Oのパフォーマンスを向上させることができます。
CacheDirectory属性をフラッシュ・ストレージ・デバイスへのパスで更新して、デバイスにストアのプライマリ・ファイルのフル・コピーを収容できるだけの十分な空き記憶域があることを確認します。Oracle WebLogic Server MBeanリファレンスのCacheDirectory属性に関する項を参照してください。
直接書込み - キャッシュありポリシーをチューニングする際には、次の項目を考慮する必要があります。
直接書込み - キャッシュあり同期書込みポリシーを使用する場合は、さらにセキュリティおよびファイル・ロッキングの考慮事項がある場合があります。『Oracle WebLogic Server本番環境の保護』と、Oracle WebLogic Server MBeanリファレンスの「JMSFileStoreMBean」のCacheDirectoryおよびLockingEnabled属性を参照してください。
JMSFileStoreMBeanは非推奨ですが、個別のbean属性が、カスタムとデフォルト・ファイル・ストアの非推奨ではないbeansに適用されます。
ストアが実行されていないときにキャッシュ・ディレクトリを削除すると安全ですが、次回ストアを起動するときに時間がかかる場合があります。ストアのホストWebLogicサーバーが(kill -9の後でもOS/JVMのクラッシュの後でもなく)現在の起動の前に正常にシャットダウンされた場合かつプライマリ・ファイル(たとえば、ストアの管理圧縮ファイル)にオフライン変更がなかった場合は、キャッシュ・ファイルを再利用して、ファイル・ストアの起動とリカバリ・プロセスを迅速化することができます。既存のキャッシュ・ファイルを起動するときに安全に使用できない場合、それらは自動的に破棄されて新しいファイルが作成されます。また、「ログ280102」という警告が作成されます。移行またはフェイルオーバーのイベント後、同じ警告メッセージが作成されますが、無視できます。
直接書込み - キャッシュありファイル・ストアを使用して、wlfileioのネイティブ・ドライバのロードに失敗した場合、同期書込みポリシーは自動的に同等の直接書込みに変更され、AvoidDirectIO=trueになります。実行中のカスタムまたはデフォルトのファイル・ストアの構成済および実際の同期書込みポリシーとドライバを表示する場合は、サーバーのログでWL-280008およびWL-280009のメッセージを参照してください。
未使用のキャッシュ・ファイルがディスク領域を消費しないようにする場合、一時的に作成されたドメインに残されたキャッシュ・ファイルを定期的に削除するようにテスト環境と開発環境を変更する必要がある場合があります。本番環境では、ファイル・ストアによってキャッシュ・ファイルが自動的に管理されます。
|
非推奨の注意: この項に記載されている |
直接書込みの同期書込みポリシーによるファイル・ストアの場合は、Oracleサポートまたはリリース・ノートにおいて、weblogic.Serverのオプションをコマンド・ライン設定するか、またはストアを実行するJVMのスクリプトを起動するように指示されます。
JVMで実行しているすべてのストアをグローバルに変更します。
-Dweblogic.store.AvoidDirectIO=true
シングル・ストアの場合に使用します。ここでは、store-nameは、ストアの名前を示します。
-Dweblogic.store.store-name.AvoidDirectIO=true
デフォルトのストアの場合に使用します。ここでは、server-nameは、ストアをホストするサーバーの名前を示します。
-Dweblogic.store._WLS_server-name.AvoidDirectIO=true
AvoidDirectIOを個別のストアに設定すると、グローバルなオプションの-Dweblogic.store.AvoidDirectIOの設定がオーバーライドされます。たとえば、AおよびBという2つのストアがあり、次のオプションを設定しているとします:
-Dweblogic.store.AvoidDirectIO=true -Dweblogic.store.A.AvoidDirectIO=false
この場合、ストアBの場合のみAvoidDirectIO=trueの設定があります。
|
注意:
|
特にファイル・ストアの直接書込みポリシーのチューニングに記載されているように、直接書込みをAvoidDirectIO=trueで使用する場合、または物理記憶域待機時間によりパフォーマンスが限定されているハードライブ・ベースのライト・バック・キャッシュを持つシステムの場合は、同期書込みポリシーの直接書込み(デフォルト)、直接書込み - キャッシュありまたはキャッシュ・フラッシュを使用して構成されたファイル・ストアのファイル・ストア・ブロック・サイズをチューニングしてください。
次のケースについて検討します。
単一のWebLogic JMSプロデューサは永続メッセージを1つずつ送信します。
ネットワークのオーバーヘッドは、ごくわずかであることが分かっています。
ファイル・ストアのディスク・ドライブの回転速度は10,000 rpmです。
ディスク・ドライブはバッテリ・バックアップのあるライトバック・キャッシュを備えています。
また、メッセージ・レートは1秒間に166メッセージと測定されています。
このケースでは、バッテリ・バックアップのあるライトバック・キャッシュによって高いメッセージ・レートが可能なように思われますが、実際のレートは低く、ディスク・ドライブの待機時間(10,000 rpm/60秒、つまり166 rps)と同じ数値になります。ストアのブロック・サイズをファイル・システムのブロック・サイズと一致するようチューニングすることで、大幅な改善が可能です。
以下のようなケースでは、ブロック・サイズをチューニングしても全く改善が見られなかったり、改善したとしても不十分であったりする可能性があります。
キャッシュによって待機時間が小さくなっています(つまり、I/Oサブシステムは重大なボトルネックではありません)。
ライトバック・キャッシングが使用されておらず、ディスク・ドライブの待機時間が大きいため、パフォーマンスが制限されています。
使用しているブロック・サイズが大きい場合は、パフォーマンスとファイル・スペースの間にトレード・オフが存在する可能性があります。複数のアプリケーション・レコードは、同時に書き込まれた場合にのみ、単一のブロックにまとめられます。そのためブロック・サイズを大きくすると、サーバー・アクティビティが同時に実行されることがほとんどなく、小さいレコードしか生成されないアプリケーションの場合、ストア・ファイルのサイズが大幅に増大することになります。この場合、小さいレコードがブロックごとに1つずつ格納され、各ブロックの残りのスペースは使用されません。例として、100バイト長の小さなメッセージを送信する単一のプロデューサを含む、Web Service Reliable Messaging (WS-RM)アプリケーションが挙げられます。ここでは、ストアを使用するのはアプリケーションだけです。
パフォーマンスを向上するために、ストアのブロック・サイズをファイル・ストアをホストするファイル・システムのブロック・サイズと一致するように、チューニングすることをお薦めします(一般的に、多くのファイル・システムの場合、4096)。または、ブロック・サイズをその他の値にチューニングしても(ページングおよびキャッシュ・ユニット)パフォーマンスを向上する場合があります。ブロック・サイズをチューニングして、パフォーマンスが向上されない場合、ブロック・サイズをデフォルトのままに設定しておくことをお薦めします。これにより、ファイル・システム・リソースの使用を最小化することができます。
|
非推奨の注意: この項に記載されている |
ストアのブロック・サイズを設定するには、次のいずれかのプロパティをコマンド・ラインで使用するか、または、ストアを実行するJVMのスクリプトを起動してください。
既存するファイルを持たないすべてのファイル・ストアのブロック・サイズをグローバルに設定します。
-Dweblogic.store.BlockSize=block-size
既存のファイルを持たない特定のファイル・ストアのブロック・サイズを設定します。
-Dweblogic.store.store-name.BlockSize=block-size
ファイル・ストアに既存のファイルがない場合、デフォルトのファイル・ストアのブロック・サイズを設定します。
-Dweblogic.store._WLS_server-name. BlockSize=block-size
ブロック・サイズは、512から8192の間の整数を設定します。最も近い2の倍数に自動的に切り捨てられます。
BlockSizeを個別のストアに設定すると、グローバルなオプションの-Dweblogic.store.BlockSizeの設定がオーバーライドされます。たとえば、AおよびBという2つのストアがあり、次のオプションを設定しているとします:
-Dweblogic.store.BlockSize=8192 -Dweblogic.store.A.BlockSize=512
この場合、ストアBのブロック・サイズは、8192になり、ストアAのブロック・サイズが512になります。
|
注意: コマンド・ライン・プロパティを使用したブロック・サイズの設定は、既存のファイルを持たないファイル・ストアでのみ可能です。ストアに既存のファイルが存在する場合は、ストアの最初の作成時に設定されたブロック・サイズがそのまま使用されます。 |
ファイル・ストアの現在のブロック・サイズおよび同期書込みポリシーは、ストアをホストするサーバーのサーバー・ログで確認することができます。「280009」のストアがオープンされたというメッセージを検索してください。
ファイル・システムの現在のブロック・サイズを確認するには、使用しているオペレーティング・システムのドキュメントを参照してください。例:
Linux ext2およびext3ファイル・システムの場合: /sbin/dumpe2fs /dev/ボリューム名を実行し、「Block size」を検索します。
Windows NTFSの場合: fsutil fsinfo ntfsinfo ボリューム名:を実行し、「Bytes Per Cluster」を検索します。
ストアの既存のファイルのデータを保持する必要がない場合は、ホストのWebLogic Serverインスタンスを停止してファイルを削除すれば、ストアを再起動した際にブロック・サイズを変更できます。データを保持する必要がある場合は、新しいブロック・サイズを指定したファイル・ストアを作成して、既存のファイルが存在するストアのブロック・サイズを変換します。その際は、コマンド・ライン・ストア管理ユーティリティのcompactコマンドを使用します。
java -Dweblogic.store.BlockSize=block-size weblogic.store.Admin
helpと入力して、使用可能なコマンドを確認します。
Storeadmin->compact -dir file-store-directory
『Oracle WebLogic Serverサーバー環境の構成』のJavaコマンド・ラインを使用したストア管理に関する項を参照してください。
次の項では、ネットワーク・ファイル・システム(NFS)でのWebLogic永続ストアの使い方について説明します。
NFS記憶域は、同期書込みリクエストが揮発性メモリーに警告なしでバッファされるように構成されているので、トランザクション・データを完全に保護しない場合があります。ファイル・ストアのディレクトリがNFSマウントに存在して、ファイル・ストアの同期書込みポリシーが「無効化された」以外である場合、NFS実装と構成をチェックして、同期の書込みがサポートされるように構成されていることを確認します。「無効化された」の同期書込みポリシーを使用すると、同期書込みが行われていないので、一般的にはトランザクションで安全ではありません。記憶域デバイスの物理機能を超える最大数の永続メッセージまたはトランザクション・スループットを表示すると、同期書込みリクエストの不要なバッファリングが発生する可能性があります。NFSサーバーで、ファイル・ストアをホストするエクスポート済のNFSディレクトリの同期書込み設定をチェックします。SANベースのファイル・ストアまたはJDBCストアでは、安全な集中型の記憶域を提供する簡単な方法が用意されている場合があります。
NFS搭載のディレクトリにJMSメッセージとトランザクション・ログが格納されている場合、マシンが不意に障害したら、サーバーの再起動の動作を検証することをお薦めします。NFS実装に応じて、フェイルオーバーまたは再起動後、様々な問題が発生する可能性があります。Web Logicサーバーの実行中に、Web Logicサーバーをホストするノードを突然にシャットダウンして、動作を検証できます。サーバーの移行のためにサーバーが構成されている場合、対応するフェイルオーバー期間後、フェイルオーバー・ノード上でサーバーが自動的に起動する必要があります。起動しない場合は、同じホスト(ノードが完全に起動した後)上のWebLogicサーバーを手動で再起動します。
|
注意: サーバーの移行を完了するのに必要なおおよその時間内にロックを解放するよう、NFS v4ベースのネットワーク接続ストレージ(NAS)サーバーを構成できます。NFS v4環境をチューニングしてテストする場合、この項の手順に従う必要はありません。ストレージ・デバイス上のNFSマウントされたディレクトリに格納されたファイルのロックに関する情報については、ストレージ・ベンダーのドキュメントを参照してください。 |
NFSマウントされたディレクトリにJMSメッセージとトランザクション・ログが格納されている場合、マシンの突然の障害後、Oracle WebLogicサーバーが再起動されないと、サーバーのログ・ファイルに次のエラーが表示されることがあります。
例8-1 ストアの再起動の失敗エラー・メッセージ
MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent store "_WLS_server_soa1" could not be deployed: weblogic.store.PersistentStoreException: java.io.IOException: [Store:280021]There was an error while opening the file store file "_WLS_SERVER_SOA1000000.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
NFSシステムがストア上のロックを解放しないために、このエラーが発生します。WebLogicサーバーでは、同じWebLogicサーバーの2つのインスタンスを誤って起動した場合、データが破損しないように、JMSデータとトランザクション・ログを格納するファイルでのロックが維持されます。NFSストレージ・デバイスは、マシンに障害が発生したことを適切なタイミングで認識しないので、ロックを解放しません。その結果、マシンに障害が発生しマシンの再起動後、WebLogicサーバーが前にロックされたファイルをロックしようとすると、失敗します。ストレージ・デバイス上のNFS搭載ディレクトリに格納されたファイルのロックに関する追加の情報については、ストレージ・ベンダーのドキュメントを参照してください。NFS環境でロック動作を適正にチューニングできない場合は、次の2つの方法で、ログ・ファイルおよびデータ・ファイルのロックを解除します。
次の2つの方法のいずれかで、ログ・ファイルおよびデータ・ファイルのロックを解除します。
ログおよびJMSデータ・ファイルを手動でロック解除し、ロック済の永続ストア・ファイルのコピーを作成してサーバーを起動し、その後の操作のために以前に作成したコピーを使用します。ロック済の永続ストア・ファイルのコピーを作成するには、ファイルの名前を変更し、再度元の名前にコピーします。次のサンプルでは、トランザクション・ログが/shared/tlogsディレクトリおよびJMSデータが/shared/jmsディレクトリに格納されると仮定します。
例8-2 NFSロックを削除するためのサンプル・ステップ
cd /shared/tlogs mv _WLS_SOA_SERVER1000000.DAT _WLS_SOA_SERVER1000000.DAT.old cp _WLS_SOA_SERVER1000000.DAT.old _WLS_SOA_SERVER1000000.DAT cd /shared/jms mv SOAJMSFILESTORE_AUTO_1000000.DAT SOAJMSFILESTORE_AUTO_1000000.DAT.old cp SOAJMSFILESTORE_AUTO_1000000.DAT.old SOAJMSFILESTORE_AUTO_1000000.DAT mv UMSJMSFILESTORE_AUTO_1000000.DAT UMSJMSFILESTORE_AUTO_1000000.DAT.old cp UMSJMSFILESTORE_AUTO_1000000.DAT.old UMSJMSFILESTORE_AUTO_1000000.DAT
この方法を使用すると、WebLogicのファイル・ロック・メカニズムは、同じサーバーの複数のインスタンスが誤って起動されたときにデータが障害されないように、データの保護を続行します。ただし、マシンに突然に障害が発生すると、サーバーを再起動する必要があります。ファイル・ストアでは、ファイル・ストアを使用して大量のデータを格納する場合、複数の連番の付けられた.DATファイルが作成されます。この場合は、すべてのファイルをコピーし、名前を変更する必要があります。
|
注意: この方法を使用すると、WebLogic Serverのロックが無効になっているので、自動サーバーを再起動して、フェイルオーバーに成功する必要があります。ただし、この方法を使用する場合は注意してください。WebLogicのファイル・ロック機能は、望ましくない同時実行性シナリオで発生するサーバー・ファイルの破損を避けるように設計されています。ファイル・ストアを使用するサーバーは、サーバーの移行のために構成されている場合、常に、データベースに基づくリース・オプションを構成します。これにより、データベース表を使用して追加のロック・メカニズムが実行され、同じWebLogic Serverの複数のインスタンスが自動的に再起動するのを防ぎます。人為的なエラーが発生しないようにし、ある時点でサーバーのインスタンスが1つのみ手動で起動されたことを確認するために、さらに手続き上の注意を払う必要があります。同じように、同じディレクトリを参照する同じ名前のストアを持つ2つのドメインが存在しないことを確認するためにも、さらに注意を払う必要があります。 |
次の項に記載されているように、WebLogic Server管理コンソールによっても、デフォルトのファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストアおよび診断ファイル・ストアのWebLogicファイル・ロック・メカニズムを無効化できます。
WebLogic Server管理コンソールを使用してデフォルトのファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。
必要に応じて、管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。
2.「ドメイン構造」ツリーで、「環境」ノードを拡張し、「サーバー」を選択します。
「サーバーのサマリー」リストで、変更するサーバーを選択します。
「構成」>「サービス」タブを選択します。
「デフォルト・ストア」のセクションへスクロール・ダウンし、「詳細」をクリックします。
スクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して、変更を反映します。
結果のconfig.xmlエントリは、次のようになります。
例8-3 デフォルトのファイル・ストアのファイル・ロックを無効化する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管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。
必要に応じて、管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「永続ストア」を選択します。
「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。
カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックすると、ストアの詳細設定が表示されます。
ページの下部にスクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
カスタム・ファイル・ストアが使用中であった場合、変更を反映するには、サーバーを再起動する必要があります。
結果のconfig.xmlエントリは、次のようになります。
例8-4 カスタム・ファイル・ストアのファイル・ロックを無効化する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管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。
必要に応じて、管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「メッセージング」ノードを拡張して、「JMSサーバー」を選択します。
「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。
JMSサーバーの「構成」>「一般」タブで、スクロール・ダウンして、「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して、変更を反映します。
結果のconfig.xmlエントリは、次のようになります。
WebLogic Server管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。
必要に応じて、管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「診断」ノードを拡張し、「アーカイブ」を選択します。
「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。
[server_name]の設定ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。
「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して、変更を反映します。
結果のconfig.xmlエントリは、次のようになります。
例8-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-lockingenabled> <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>
