WebLogic Server 環境のコンフィグレーション
|
 |
 |
|
以下の節では、永続ストアをコンフィグレーションおよびモニタする方法について説明します。永続ストアは、永続性を必要とする WebLogic Server のサブシステムおよびサービスに対し、組み込みの高性能なストレージ ソリューションを提供します。
永続ストアは、永続性を必要とする WebLogic Server のサブシステムおよびサービスに対し、組み込みの高性能なストレージ ソリューションを提供します。たとえば、永続 JMS メッセージを格納したり、ストア アンド フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイルベースのストアまたは JDBC 対応データベースの永続性をサポートします。
表 6-1 に、永続ストアへの接続を作成できる WebLogic サービスおよびサブシステムの多くを示します。永続ストアを使用する各サブシステムには、そのサブシステムを特定するためのユニークな接続 ID が指定されます。
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
ストアの接続 ID の詳細については、「ストア接続のモニタ」を参照してください。
永続ストアのパフォーマンス上の主な目標はスループットの向上です。複数のサブシステムが同じサーバ インスタンスまたは移行可能な対象を対象指定していれば、これらのサブシステムで同じ永続ストアを共有できます。
この点が、永続ストアを使用するパフォーマンス上の利点です。なぜなら、同じストアを使用する複数のサービスに関係するトランザクションであっても、そのトランザクションのトランザクション マネージャによって永続ストアが単一のリソースとして扱われるためです。たとえば、JMS と EJB のタイマーが 1 つのストアを共有し、JMS メッセージと EJB タイマーが単一のトランザクションで作成された場合、そのトランザクションは 1 フェーズとなり、リソースの書き込みは 1 回しか発生しません。一方、2 フェーズの場合であれば、リソースごとに 2 回ずつで合計 4 回のリソース書き込みが発生し、加えてトランザクション ログでのトランザクション エントリの書き込みが 1 回発生することになります。
ファイル ストアおよび JDBC ストアは、プロセスのクラッシュやハードウェアの電源障害が発生しても、コミットされた更新を失うことなく存続できます。コミットされていない更新は保持されるとは限りませんが、クラッシュ後にトランザクションが部分的に完了した状態で残されることはありません。
以下に、ファイル ストアと JDBC ストアの類似点と相違点を挙げます。
注意 : データベースが高速なディスクを備えたハイエンドのハードウェア上で実行され、WebLogic Server がそれよりも低速なディスクを備えたハードウェア上で実行されている場合は、JDBC ストアの方がパフォーマンスが良くなる場合もあります。
ファイル ストア データのセキュリティを確保するには、すべてのファイル ストア ディレクトリに適切なディレクトリ パーミッションを設定する必要があります。データの暗号化が必要な場合は、適切なサード パーティ暗号化ソフトウェアを使用する必要があります。
高可能性の点では、永続ファイルベースのストア (デフォルトまたはカスタム) は、「サーバレベル」の移行機能の一部としてその親サーバとともに移行できます。この場合、サービスレベルではなく、サーバレベルで自動または手動で移行できます。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「Server Migration」を参照してください。ただし、ファイルベースのストアは、クラスタ内の移行可能な対象サーバからアクセスできる共有ディスク上にコンフィグレーションする必要があります。
ファイルベースのストアは、JMS サーバおよび JTA トランザクション回復サービスの「サービスレベル」の移行の一部として移行することもできます。この場合、クラスタ内のサーバから別のサーバに移動させることができます。サービスレベルの移行の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「Service Migration」を参照してください。ただし、この場合も、ファイルベースのストアはクラスタ内の移行可能な対象サーバからアクセスできる共有ディスク上にコンフィグレーションする必要があります。
したがって、JMS サーバまたは JTA トランザクション ログの移行後に、リモート マシンに存在する永続ストアにアクセスするアプリケーションがある場合は、以下の高可用性ストレージ ソリューションのいずれかを実装する必要があります。
注意 : ファイル ストアが切断されて再接続された場合、永続 JMS メッセージの送受信を正常に続行するには、ホスト サーバ インスタンスを再起動する必要があります。たとえば、ファイル ストアを含むファイル システムがアンマウントされた後再びマウントされた場合、ホスト サーバを再起動せずに永続 JMS メッセージを送信しようとすると JMS 例外が生成されます。
管理サーバを含め、すべてのサーバ インスタンスには、コンフィグレーションが不要なデフォルトの永続ストアがあります。デフォルト ストアはファイルベースのストアで、サーバ インスタンスの data\store\default ディレクトリに格納された一連のファイルにデータを保持します。デフォルト ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ メカニズムを使用することで最適に動作するサブシステムから使用することができます。たとえば、永続ストアがコンフィグレーションされていない JMS サーバは、管理対象サーバ用のデフォルトのストアを使用して永続メッセージングをサポートします。
デフォルト ストアは、DefaultFileStoreMBean パラメータを直接操作してコンフィグレーションできます。この MBean がドメインのコンフィグレーション ファイルに定義されていない場合は、DefaultFileStoreMBean がデフォルト値で常に存在していることがコンフィグレーション サブシステムによって保証されます。
また、Administration Console を使用してデフォルト ストアのパラメータを変更することもできます。たとえば、デフォルトのディレクトリの場所や同期書き込みポリシーを変更できます。詳細については、Administration Console オンライン ヘルプの「デフォルト ストアの設定の変更」を参照してください。
デフォルトのファイル ストアを使用するだけでなく、特定のニーズに合わせてカスタム ファイル ストアや JDBC ストアをコンフィグレーションすることもできます。詳細については、「カスタム ファイル ストアと JDBC ストアの使い方」を参照してください。唯一の例外は、トランザクション ログ (TLOG) です。TLOG では、常にデフォルト ストアを使用します。これは、サーバの起動プロセスの初期に必ずトランザクション ログを使用するためです。
デフォルト ストアのデータは、ドメインのルート ディレクトリの servername サブディレクトリにある data\store\default ディレクトリに保持されます。
たとえば、デフォルト ファイル ストアのディレクトリ名が指定されていない場合、次のディレクトリがデフォルトになります。
bea_home\user_projects\domains\domain-name\servers\server-name\data\store\default
domainname はドメインのルート ディレクトリ (通常は c:\bea\user_projects\domains\domainname) です。これは、WebLogic Server プログラム ファイルが格納されるディレクトリ (通常は c:\bea\weblogic90) に対応するディレクトリです。
ただし、DefaultFileStoreMBean パラメータを直接操作するか Administration Console を使用して、デフォルト ストアの格納場所を変更することもできます。詳細については、Administration Console オンライン ヘルプの「デフォルト ストアの設定の変更」を参照してください。
ドメインのコンフィグレーション ファイルでのデフォルト ファイル ストアの定義例を示します。この例では、デフォルトのディレクトリと同期書き込みポリシーの設定がオーバーライドされています。
<server>
<name>myserver</name>
<default-file-store>
<directory>C:/store</directory>
<synchronous-write-policy>Disabled</synchronous-write-policy>
</default-file-store>
</server>
デフォルトのファイル ストアを使用するだけでなく、特定のニーズに合わせてファイル ストアや JDBC ストアをコンフィグレーションすることもできます。デフォルト ファイル ストアと同様、カスタム ファイル ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、特定のストレージ デバイスにデータを保持するカスタム ファイル ストアを作成することもできます。ファイル ストアのディレクトリをコンフィグレーションする場合は、そのファイル ストアが配置されているサーバ インスタンスにアクセスできるディレクトリを設定する必要があります。
JDBC ストアは、リレーショナル データベースをストレージとして使用している場合にコンフィグレーションできます。JDBC ストアを使用することで、指定の JDBC データ ストアを介してアクセスできる標準の JDBC 対応データベースに永続メッセージを格納できます。JDBC ストアのデータベース テーブルに格納されたデータには、WLStore という論理名が付けられます。データベースの高可用性とパフォーマンスをコンフィグレーションするかどうかは、データベース管理者の判断です。
永続ストアのコンフィグレーションの詳細については、「カスタム永続ストアを使用すべき状況」を参照してください。
WebLogic Server では、カスタム ファイル ストアや JDBC ストアを作成するためのコンフィグレーション オプションが用意されています。たとえば、次のような状況が考えられます。
カスタム永続ストアは、以下の方法でコンフィグレーションできます。
config.xml) を直接編集する。
以下の節では、カスタム ファイル ストアの例を示し、同期書き込みポリシーを選択する上でのコンフィグレーション ガイドラインについて説明します。
カスタム ファイル ストアを作成する場合は、デフォルトの FileStoreMBean パラメータを直接編集できます。Administration Console を使用してカスタム ファイル ストアを作成する方法については、Administration Console オンライン ヘルプの「ファイル ストアの作成」を参照してください。
カスタム ファイル ストアを作成するための主な手順は次のとおりです。
ドメインのコンフィグレーション ファイルでのデフォルト ファイル ストアの定義例を示します。この例では、ファイルが /disk1/jmslog ディレクトリに保持されるように定義されています。
<file-store>
<name>SampleFileStore</name>
<target>myserver</target>
<directory>/disk1/jmslog</directory>
</file-store>
表 6-2 に、ファイル ストアの変更可能なコンフィグレーション パラメータを示します。
|
|
||
|
|
||
|
|
Administration Console を使用してカスタム ファイル ストアをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「ファイル ストアの作成」を参照してください。
デフォルトの同期書き込みポリシーである [Direct-Write] では、ファイル ストアのデータが Solaris および Windows オペレーティング システムのディスクに直接書き込まれます。Windows システム上では通常、[Cache-Flush] を選んだ場合よりも速く書き込まれます。
通常、デフォルト ポリシーから [Disabled] に変更すると、ファイル ストアのパフォーマンスは大幅に向上します。その代わり、オペレーティング システムがクラッシュしたり、ハードウェアの障害が発生したりした場合には、メッセージがトランザクション対応であっても、送信したメッセージが失われたり、同じメッセージを重複して受信したりする可能性があります。これは、書き込みがメモリにキャッシュされると、ディスクに正常に格納されるまで待機せず、すぐにトランザクションが完了するためです。オペレーティング システムでは通常のシャットダウン時に未処理の書き込みをすべてフラッシュするので、OS をシャット ダウンするだけではこうしたエラーは発生しません。こうしたエラーは、ビジー状態のサーバの電源を突然遮断することでエミュレートできます。
以下の節では、JDBC ストアの例を示し、既存の DDL を使用した JDBC ストア用のデータベースの作成について説明します。また、DDL ファイルで Oracle blob レコード カラムを有効にする方法についても説明します。
JDBC ストアを作成する場合は、デフォルトの JDBCStoreMBean パラメータを直接編集できます。Administration Console を使用して JDBC ストアを作成する方法については、Administration Console オンライン ヘルプの「JDBC ストアの作成」を参照してください。
JDBC ストアでプレフィックスを使用する場合のコンフィグレーション ガイドライン、および JDBC データ ソースの推奨設定については、「JDBC ストアのコンフィグレーションのガイドライン」を参照してください。
ドメインのコンフィグレーション ファイルでの JDBC ストアの定義例を示します。この例では、JDBC データ ソース MyDataSource を使用しており、論理名が指定されています。
<jdbc-store>
<name>SampleJDBCStore</name>
<target>yourserver</target>
<data-source>MyDataSource</data-source>
<logical-name>Baz</logical-name>
</jdbc-store>
表 6-3 に、JDBC ストアの変更可能なコンフィグレーション パラメータを示します。
|
|
||
|
|
||
|
|
||
|
|
||
|
|
Administration Console を使用して JDBC ストアをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JDBC ストアの作成」を参照してください。
JDBC ストアを使用する場合、JDBC ドライバを介してアクセスできるデータベースであればバッキング データベースにできます。WebLogic Server では、サポートされるデータベース用の一部の JDBC ドライバが自動的に検出されます。
これらのデータベースごとに対応する DDL (データ定義言語) ファイルがあり、WL_HOME\server\lib\weblogic.jar ファイル内の weblogic/store/io/jdbc/ddl ディレクトリに格納されています。WL_HOME は、WebLogic Server の最上位のインストール ディレクトリです。
DDL ファイルは、JDBC ストアのデータベース テーブル (WLStore) を作成するための SQL コマンド (末尾がセミコロン) を含むテキスト ファイルです。したがって、このリストに含まれていないデータベースを使用する場合は、そのデータベースに合わせて既存の DDL ファイルを編集します。詳細については、「カスタム DDL ファイルを使用した JDBC ストア テーブルの作成」を参照してください。
[JDBC ストア : コンフィグレーション] ページには [DDL ファイルからのテーブルの作成] オプションがあります。このオプションを使用すると、JDBC ストアのバッキング テーブル (WLStore) の作成に使用するコンフィグレーション済みの DDL ファイルにアクセスできます。JDBC ストアのバッキング テーブルがすでに存在する場合、このオプションは無視されます。このオプションを使用するのは、サポートされないデータベース用に作成したカスタム DDL ファイルを指定する場合や、以前のリリースの JMS JDBC ストア テーブルを現在の JDBC ストア テーブルにアップグレードする場合などです。
[DDL ファイルからのテーブルの作成] フィールドに DDL ファイル名が指定されておらず、バッキング テーブルが存在しないことが JDBC ストアによって検出されると、データベース ベンダに固有のコンフィグレーション済み DDL ファイルが実行され、自動的にテーブルが作成されます (「サポートされる JDBC ドライバ」を参照してください)。
[DDL ファイルからのテーブルの作成] に DDL ファイル名が指定されており、バッキング テーブルが存在しないことが JDBC ストアによって検出されると、まずファイル パスに指定した DDL ファイルが検索され、見つからない場合は CLASSPATH 内の DDL ファイルが検索されます。ファイルが見つかった時点で、その DDL ファイル内の SQL が実行されて JDBC ストアのバッキング テーブルが作成されます。コンフィグレーション済みのファイルが見つからず、既存のテーブルもない場合、JDBC ストアは起動に失敗します。
「サポートされる JDBC ドライバ」のリストにないデータベースを使用する場合は、既存の DDL テンプレート ファイルをコピーし、使用するデータベースに合わせて編集できます。
jar xf weblogic.jar /weblogic/store/io/jdbc/ddl
注意 : weblogic/store/io/jdbc/ddl パラメータを省略すると、jar ファイル全体が抽出されます。
Oracle データベースの場合は、oracle_blob.ddl ファイルを使用すると、レコード カラムの型がデフォルトの LONG RAW 型ではなく BLOB 型の JDBC ストア テーブルを作成できます。oracle_blob.ddl ファイルは、「サポートされる JDBC ドライバ」に示すように、WebLogic CLASSPATH にあらかじめコンフィグレーションされています。
JDBC ストアで Oracle BLOB DDL を使用するには
すでに Oracle の LONG RAW カラムに入っているデータを保持する必要がある場合は、この方法で BLOB に切り替えないようにしてください。このような場合は、SQL ALTER TABLE コマンドに関する Oracle ドキュメントを参照してください。
JDBC utils.Schema ユーティリティを使用すると、既存のバージョンを削除することで新しい JDBC ストア データベース テーブル (WLStore) を再生成できます。通常、このテーブルは自動的に作成されるため、このユーティリティを実行する必要はありません。しかし、既存の JDBC ストア データベース テーブルに障害が発生した場合は、utils.Schema ユーティリティを使用して削除できます。
utils.Schema ユーティリティは Java プログラムで、以下の項目を指定するコマンドライン引数をとります。
$ java utils.Schemaurl JDBC_driver[options]DDL_file
注意 : utils.Schema を実行するには、CLASSPATH に weblogic.jar ファイルを指定する必要があります。
表 6-5 に、utils.Schema のコマンドライン引数を示します。
|
|
|
|
|
たとえば、次のコマンドでは、ユーザ名 user1、パスワード foobar で、Oracle サーバ DEMO の MYWLStore という JDBC テーブルが削除されます。
$ echo "drop MYWLStore;" > drop.ddl
$ java utils.Schema
jdbc:weblogic:oracle:DEMO \
weblogic.jdbc.oci.Driver -u user1 -p foobar -verbose \
drop.ddl
以下の節では、JDBC ストアのプレフィックスを使用する場合のガイドライン、JDBC ストア用の WebLogic JDBC データ ソースの推奨設定、および JDBC ストアを使用した JMS トランザクションの処理について説明します。
JDBC ストア データベースには、WLStore というデータベース テーブルが含まれます。このデータベース テーブルは、WebLogic Server によって自動的に生成され、内部的に使用されます。JDBC ストアには任意指定のプレフィックス名パラメータがあり、これを使用するとより正確にデータベース テーブルにアクセスできます。
JDBC WLStore テーブル名のプレフィックスはコンフィグレーションするのが常にベスト プラクティスです。特に次の場合にはコンフィグレーションする必要があります。
ほとんどのデータベースでは、JDBC ストアのバッキング データベース テーブルのプレフィックス名オプションを、コンフィグレーションした JDBC ストアごとに次のフォーマットで設定する必要があります。これにより、JDBC ストア テーブル名にプレフィックスが付加され、有効なテーブル名になります。
[[[catalog.]schema.]prefix]
[[catalog.]schema.]prefix フォーマット内の各ピリオド記号は重要です。通常、catalog は DBMS が参照するシステム テーブルのセットを識別し、schema はテーブル オーナー (username) の ID に対応します。プレフィックスを指定しないと、JDBC ストアのテーブル名は単に WLStore となり、データベースでは JDBC 接続の現在のユーザに基づいて暗黙的にスキーマが決定されます。
たとえば、データベース管理者は、次のようにプロダクション データベースで販売部門用の固有のテーブルを管理できます。
[[[Production.]JMSAdmin.]Sales]
この場合、テーブルは JMSAdmin スキーマによって Production カタログ内に作成され、SalesWLStore という名前になります。
Oracle などの一部の DBMS ベンダの場合、設定または選択するカタログがないので、このフォーマットは [[schema.]prefix] となります。詳細については、お使いの DBMS のマニュアルでテーブルの完全修飾名に関する説明を参照してください。ただし、その DBMS で指定されている構文が、このオプションに必要なフォーマットとは異なる場合があることに注意します。
警告 : WLStore テーブルがすでにデータベース内にある状態でプレフィックス名の設定を変更する場合は、既存のテーブル データの保持の面で注意が必要です。この場合、データベース管理者が既存のデータベース テーブルの名前を変更して、新たにコンフィグレーションしたテーブルの名前に一致させる必要があります。
JDBC ストアに JDBC データ ソースまたはマルチ データ ソースを使用する場合は、以下の設定を推奨します。
WebLogic Server には、堅牢な JDBC データ ソースが用意されています。JDBC 接続プールでは、障害が発生したデータベースがオンラインに復旧した場合、WebLogic Server を再起動しなくても、自動的にこのデータベースとの再接続を確立できます。この機能を活用し、JDBC ストアをより堅牢なものとして使用するには、JDBC ストアに関連付けられている JDBC データ ソースの以下のオプションをコンフィグレーションします。
TestConnectionsOnReserve="true"ConnectionCreationRetryFrequencySeconds=
TestTableName="SYSTABLES""600"
JDBC のデフォルトのテスト テーブル名については、『WebLogic JDBC のコンフィグレーションと管理』の「Connection Testing Options for a Data Source」を参照してください。データベースの再接続の試行数の設定については、『WebLogic JDBC のコンフィグレーションと管理』の「接続作成の再試行の有効化」を参照してください。
JDBC ストアとして使用するデータ ソースで DB2 用の WebLogic Type 4 JDBC ドライバを使用する場合は、JMS の内部的なバッチ処理の要件を満たすため、BatchPerformanceWorkaround プロパティを「true」に設定する必要があります。
詳細については、『WebLogic Type 4 JDBC ドライバ ガイド』の「バッチ挿入およびバッチ更新に関するパフォーマンスの回避策」を参照してください。
JDBC ストアは、グローバル トランザクションをサポートするようにコンフィグレーションされた JDBC データ ソースを使用するようにコンフィグレーションすることはできません。JDBC ストアは、非 XA JDBC ドライバを使用する JDBC データ ソースを使用する必要があります。また、このデータ ソースで [ロギング ラスト リソース] または [2 フェーズ コミットのエミュレート] を有効にすることはできません。
JDBC ストアは、XAResource インタフェースを実装しているため、JDBC ストア自体のリソース マネージャとして動作し、JDBC ドライバ レベルより上位のトランザクションを処理します。つまり、ストア自体が XAResource を実装し、メッセージがデータベースに格納されている場合でもそのデータベースに依存せずにトランザクションを処理します。
このため、JDBC ストアとデータベース (JMS メッセージが格納されているデータベースと同じ場合でも) を使用する場合、それは常に 2 フェーズ コミット トランザクションになります。
JDBC ストアでの JMS トランザクションの使用については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS によるトランザクションの使い方」を参照してください。
LLR による最適化を使用すると、トランザクションは 2 フェーズ コミット プロトコルに従いますが、データベース操作は単一のローカル トランザクションで処理されるため、トランザクション全体のパフォーマンスは向上します。LLR による最適化の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「Understanding the Logging Last Resource Transaction Option」を参照してください。
既存の各永続ストアおよび開かれている各ストア接続の統計情報をモニタできます。
各永続ストアは、実行時には PersistentStoreRuntimeMBean インスタンスによって表現されます。以下のオプションが用意されています。
永続ストアは、開かれている各永続ストア接続についても PersistentStoreConnectionRuntimeMBean を登録します。以下のオプションが用意されています。
表 6-8 に、永続ストアへの接続を作成できる WebLogic サービスおよびサブシステムの実行時プレフィックス名のほとんどを示します。
|
|
|