WebLogic JDBC のコンフィグレーションと管理
|
 |
 |
|
バックエンド システムのスケーラビリティや可用性をより高めるソリューションがますます求められています。こうした要求に応え、WebLogic Server では Oracle Real Application Clusters (RAC) の使用がサポートされています。
以下の節では、WebLogic Server で Oracle Real Application Clusters を使用する場合の要件およびコンフィグレーション タスクについて説明します。
Oracle RAC および WebLogic Server はどちらも複雑なシステムです。これらを一緒に使用するには、クラスタ化ソフトウェアおよび共有ストレージ ソリューションに加え、両方のシステム上での固有のコンフィグレーションが必要になります。ここでは、高度なレベルで要求されるコンフィグレーションについて説明します。Oracle RAC のコンフィグレーション、使用しているクラスタ化ソフトウェア、オペレーティング システム、およびストレージ ソリューションに関する詳細は、各ベンダが提供するマニュアルを参照してください。
Oracle Real Application Clusters (RAC) は、複数のマシンから単一のデータベースに高いパフォーマンスでアクセスできる高可用性ソリューションに追加できるソフトウェア コンポーネントです。RAC は、複数のクラスタ化されたマシン上で実行され、クラスタ技術を介して共有ストレージ デバイスにアクセスする、複数の Oracle データベース インスタンスから構成されます。このアーキテクチャをサポートするため、データベース インスタンスをホストするマシンは高速な相互接続でリンクされて、クラスタを形成します。相互接続とは、クラスタのノード間を通信する手段として使用される物理的なネットワークです。クラスタ機能は、オペレーティング システムまたは互換性のあるサードパーティのクラスタリング ソフトウェアで提供されます。図 B-1 に Oracle RAC のコンフィグレーションを示します。
図 B-1 Oracle Real Application Clusters のコンフィグレーション
インストールされている Oracle RAC は、単一の標準的なオラクル データベースのように見え、同じツールと慣行を使用して管理されます。クラスタのすべてのノードで同じデータベースに対してトランザクションを実行すると、RAC により各ノードから共有データへのアクセスが調整されて一貫性が維持され、整合性が確保されます。クラスタにはノードを簡単に追加でき、追加時にデータを分割する必要もありません。つまり、RAC ノード、ストレージ、またはその両方を追加することで、処理と要求の増加に伴い、データベース層を水平方向に拡張できます。その後、新しいノードにマップされるデータ ソースを追加することにより、WebLogic Server を拡張できます。
クラスタ内の各 RAC ノードには同等のアクセスと権限があるので、ノードがなくなった場合、パフォーマンスに影響することはあっても、ダウンタイムが発生することはありません。RAC ノードに障害が発生した場合には、指定したコンフィグレーションに応じて WebLogic Server または Oracle Thin Driver により、処理中のトランザクションがクラスタ内の別のノードにリダイレクトされます。Oracle RAC も WebLogic Server も、データベース接続のフェイルオーバを提供しません。しかしトランザクションは、障害発生のタイミングに基づき完了せざるを得ないという意味で、フェイルオーバされます。
アプリケーションで RAC ノード間のロード バランシングが必要な場合には、JDBC マルチ データ ソースを Oracle RAC ノードと併用して実現する方法がサポートされています。マルチ データ ソースを形成するデータ ソースは、ラウンドロビン方式でアクセスされます。接続を切り替えるとき、WebLogic Server はリストの順序で次のデータ ソースから接続を選択します。マルチ データ ソースと Oracle RAC の併用の詳細については、「Oracle RAC でのマルチ データ ソースの使用」を参照してください。
マルチ データ ソースを使用できない場合、XA 使用時にロード バランシングを行う方法はサポートされていません。マルチ データ ソースを使用しないコンフィグレーションでは、Oracle Thin Driver で提供される接続時フェイルオーバ機能を使用して、Oracle RAC と連携します。Oracle の Technical Note 235118.1 で説明されているように、Oracle Thin Driver でロード バランシングをコンフィグレーションした場合、トランザクションの開始と終了が同じ Oracle RAC インスタンスで行われるかどうかは保証されません。Oracle RAC では、グローバル トランザクション内のすべてのデータベース操作が同じ Oracle インスタンスにルーティングされる必要があるため、この確認済みの制限があることで、XA と Oracle RAC を併用する場合にドライバ レベルのロード バランシングは使用できないことになります。結果として、プライマリ/プライマリの RAC コンフィグレーションは使用できません。
Oracle RAC は JDBC 接続時フェイルオーバ機能を提供していますが、大半のコンフィグレーションでは、これではなく WebLogic JDBC マルチ データ ソースを使用してフェイルオーバを処理することをお勧めします。接続時フェイルオーバには、代替 RAC ノードへの接続をあらかじめ作成する機能はありませんが、マルチ データ ソースでは、常に複数の接続をフェイルオーバの処理に利用できます。詳細については、「Oracle RAC でのマルチ データ ソースの使用」を参照してください。
注意 : Transparent Application Failover (TAF) では Oracle OCI Driver を使用する必要があります。BEA では Oracle Thin Driver を使用する必要があるため、TAF はサポートされていません。
WebLogic Server で Oracle RAC を使用するには、次の要件を考慮する必要があります。
注意 : WebLogic Server でサポートされるハードウェア プラットフォームやオペレーティング システム、および WebLogic Server の各バージョンやサービス パックでサポートされる Oracle RAC のバージョンの最新情報については、『WebLogic Platform サポート対象のコンフィグレーション』を参照してください。Oracle RAC ソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracle のマニュアルを参照してください。
WebLogic Server および Oracle RAC の標準的なシステムには、WebLogic Server クラスタ、Oracle RAC クラスタ、および共有ストレージ用のハードウェアが含まれます。
WebLogic Server クラスタは、さまざまハードウェア オプションを使用して多くの方法でコンフィグレーションできます。WebLogic Server クラスタのコンフィグレーションの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
Oracle RAC に関する最新のハードウェア要件については、Oracle RAC のマニュアルを参照してください。ただし、WebLogic Server で Oracle RAC を使用するには、堅牢なプロダクション レベルのハードウェア上で Oracle RAC インスタンスを実行する必要があります。Oracle RAC のコンフィグレーションでは、アプリケーションの負荷要件を適切に予想し、それに見合ったデータベース処理性能を実現する必要があります。データベースの応答が著しく遅れると、データベースのフェイルオーバ処理の間に予期しない動作が生じるおそれがあります。
Oracle RAC のコンフィグレーションでは、データ ファイル、制御ファイル、およびパラメータ ファイルはすべて、各 RAC インスタンスで共有されて使用されます。次のいずれかのアーキテクチャを使用する HA ストレージ ソリューションが推奨されます。
サポートされているストレージ ソリューションの全リストについては、Oracle のマニュアルを参照してください。
WebLogic Server を Oracle RAC と共に使用するには、各 RAC ノードに次のソフトウェアをインストールする必要があります。
注意 : WebLogic Server でサポートされるハードウェア プラットフォームやオペレーティング システム、および WebLogic Server の各バージョンやサービス パックでサポートされる Oracle RAC のバージョンの最新情報については、『WebLogic Platform サポート対象のコンフィグレーション』を参照してください。Oracle RAC ソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracle のマニュアルを参照してください。
Oracle RAC をインストールしてコンフィグレーションしたら、これ以降の節で説明するように各 RAC インスタンスに対してリスナ プロセスをコンフィグレーションする必要があります。Oracle RAC ノードに対して、オペレーティング システムおよび Oracle ソフトウェアをインストールおよびコンフィグレーションする方法については、Oracle のマニュアルを参照してください。
リスナ プロセスは、Oracle RAC に、ユーザ プロセスと Oracle インスタンス間で通信経路を確立します。WebLogic Server で Oracle RAC を使用する場合、ユーザ プロセスは通常、JDBC データ ソースです。
データ ソースは作成されると、アプリケーションが使用するデータベース接続のプールを作成しようとします。プールされたデータベース接続が操作できなくなったり、データ ソース容量が増えるようにコンフィグレーションされている場合、データ ソースは、コンフィグレーション ファイルに指定されている最大値になるまで、データベース接続を追加作成しようとします。こうしたすべてのケースにおいて、Oracle リスナ プロセスは Oracle RAC インスタンスに対する接続リクエストを処理します。
図 B-2 に Oracle リスナ プロセスの機能を示します。
この機能を有効化するには、Oracle クラスタにおいて各 RAC インスタンスのリスナ プロセスをコンフィグレーションする必要があります。各 RAC インスタンスについてローカル リスナのコンフィグレーションが必要です。各データベース インスタンスは、そのローカル リスナのみ登録するようにコンフィグレーションする必要があります。
Oracle インスタンスのリスナ登録は、listener.ora ファイルで静的にコンフィグレーションしたり、インスタンスの初期化パラメータ local_listener を使用して動的に登録できます (両方で登録可能)。動的に登録することをお勧めします。
リスナは、共有ディスパッチ プロセスまたは専用プロセスのいずれかを起動できます。WebLogic Server を使用する場合、専用プロセスの使用をお勧めします。
Oracle RAC を使用すると、接続のフェイルオーバを処理するようにリモート リスナをコンフィグレーションできますが、通常、処理速度が低すぎるため、リモート リスナの使用はサポートされていません。リモート リスナを無効化するには、各 RAC ノードで spfile.ora にリストされているすべてのリモート リスナを削除します。たとえば、次のようになります。
*.remote_listener=''
代わりに、フェイルオーバの処理には JDBC マルチ データ ソースを使用することをお勧めします。
詳細については、「フェイルオーバのコンフィグレーションに関する考慮事項」参照してください。
Oracle 9i RAC または Oracle 10g RAC と共に WebLogic Server を使用する場合、RAC インスタンスと対話でき、期待通りに動作するように WebLogic ドメインをコンフィグレーションする必要があります。以下の節では、コンフィグレーションのオプションと要件について説明します。
Oracle RAC と WebLogic Server を併用するために、数種のコンフィグレーション オプションがサポートされています。
以下の表を、特定のアプリケーションに適したコンフィグレーションを判断する際の指標としてご利用ください。
WebLogic Server を Oracle RAC と共に使用するには、WebLogic JDBC データ ソースで Oracle JDBC Thin Driver 10g を使用して、データベース接続を作成する必要があります。
フェイルオーバをコンフィグレーションする際には、次の情報について考慮する必要があります。
マルチ データ ソースを使用するとグローバル トランザクションでフェイルオーバ機能を利用でき、この場合、データ ソースのコンフィグレーションで接続時フェイルオーバ機能を使用することに関連した制限や確認済みの問題がありません。マルチ データ ソースのフェイルオーバ機能については、『WebLogic JDBC プログラマーズ ガイド』の「マルチ データ ソース フェイルオーバ機能の拡張」を参照してください。
図 B-3 に示すこのコンフィグレーションを使用すると、以下の利点があります。
RAC ノードが利用できなくなった場合、マルチ データ ソースによってデータベース接続のフェイルオーバが処理されます。WebLogic Server で接続をテストした結果、失敗した場合には、その接続の再作成が試行されます。その試行に失敗すると、サーバではデータ ソースが無効化され、接続リクエストはマルチ データ ソース内の (他の RAC ノードに対応する) 他のデータ ソースにルーティングされます。WebLogic Server では、無効化されたデータ ソース内のデータベース接続の再作成が定期的に試行されます。WebLogic Server は、接続の再作成に成功すると、次にデータ ソースを再有効化し、再び接続リクエストをデータ ソースにルーティングし始めます。接続リクエストのルーティングと自動ヘルス チェック機能を実施するため、Oracle Thin Driver の接続時フェイルオーバを利用するコンフィグレーションに比べて、障害後、接続リクエストに対応するまでにわずかな遅延が生じます。
マルチ データ ソースの使用を選択できない場合、WebLogic Server では RAC インスタンスが利用できなくなっており、プライマリ/プライマリの RAC コンフィグレーションの使用が選択できなければ、Oracle Thin Driver の接続時フェイルオーバ機能を使用して接続のフェイルオーバが処理されます。WebLogic Server で接続をテストした結果、失敗した場合には、サーバで取得した新しい接続でその接続が置き換えられ、ドライバによって改めてどの RAC インスタンスを使用するかが、インスタンスの可用性に基づいて決定されます。接続が、接続テストで失敗した場合、WebLogic Server はデータ ソース内のすべての接続を自動的に閉じます。WebLogic Server は、どのノードに接続するかの判断にドライバを使用し、接続を新しい接続で置き換えます。この場合、プライマリ RAC ノードは失敗しているので、新しい接続はセカンダリ RAC ノードに対してのものとなります。WebLogic Server は、リクエストに応じる前に、新しい接続をテストします。
ある RAC ノードが別の RAC ノードにフェイルオーバした場合、現在、障害の発生しているノードの処理中のトランザクション ブランチに関連するデータがクラスタ全体で利用可能になるまでに、遅延が発生することがあります。これにより、未完了のトランザクションが適切に完了できなくなり、さらにはデータベース内でデータのロックが発生することがあります。このような遅延発生の可能性を防ぐために、WebLogic Server には Oracle RAC に対する XA 呼び出しの再試行を有効にする 2 つのコンフィグレーション属性、XARetryDurationSeconds と XARetryIntervalSeconds が用意されています。
XARetryDurationSeconds は、保留中のトランザクションの XA 操作 (回復、コミット、ロールバックなど) の再試行を繰り返す間隔を指定します。XARetryIntervalSeconds では、設定した期間内に再試行する頻度を指定します。
XA 呼び出しの再試行を有効化するには、Oracle RAC インスタンスに接続する WebLogic ドメイン内のすべての JDBC データ ソースに対して、XARetryDurationSeconds の値を追加で指定します。たとえば次のように指定します。
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91"
xmlns:sec="http://www.bea.com/ns/weblogic/91/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/91/security/wls"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/91/domain.xsd">
<name>oracleRACXAPool</name>
...
<jdbc-xa-params>
...
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
</jdbc-xa-params>
</jdbc-data-source>
XARetryDurationSeconds の値は、以下の公式に従って決定します。
たとえば、アプリケーションで設定されている最長のトランザクション タイムアウトが 180 秒の場合には、XARetryDurationSeconds を 180 秒 + 300 秒の合計、つまり 480 秒に設定します。
注意 : 一般に XARetryDurationSeconds は、すべてのトランザクションが適切に完了するように、必要とされる最小限の時間よりも長めに設定した方がよいでしょう。最小限必要な時間より大きな値を設定しても、通常の運用時であればアプリケーションのパフォーマンスには影響しません。この追加された処理は、準備状態にあるが完了に失敗したトランザクションにのみ影響します。
必要に応じて、XARetryIntervalSeconds にも値を設定できます。この値は、XA 呼び出しの再試行の間隔を決定します。デフォルトでは、この値は 60 秒です。値を小さくすると、XA の再試行の間隔が短くなります。ほとんどの場合は、デフォルト値で十分です。
Administration Console から XARetryDurationSeconds および XARetryIntervalSeconds を有効化するには、次の手順を使用します。
必要に応じて、weblogic.Admin コマンドライン ユーティリティ、WebLogic Scripting Tool (WLST)、または JMX プログラムを使用できます。
ノードに障害が発生した場合、データベースに対する処理中のトランザクションには何が起こるのでしょう。プライマリ Oracle RAC ノードに障害が発生した場合はどうでしょうか。WebLogic Server では、透過的なフェイルオーバはサポートされていますか。こうした疑問や WebLogic Server での障害処理に関するその他の質問への回答として、トランザクション処理の段階を順を追って説明し、その中で各段階での障害の処理方法について解説します。
最初に障害が発生する可能性のある段階は、アプリケーションでトランザクションをコミットする呼び出しを行う前です。データベースまたは RAC ノードにこの段階で障害が発生すると、アプリケーションは例外を受け取ります。アプリケーションでは新しい接続を取得して、新たにトランザクションの処理を試行する必要があります。WebLogic Server では透過的なフェイルオーバはサポートされていません。
アプリケーションでトランザクションをコミットする呼び出しを行った後で障害が発生した場合、処理中の任意のトランザクション処理は PREPARE 操作が完了しているかどうかによって変わります。PREPARE 操作が完了していない場合、トランザクション マネージャによってトランザクションはロールバックされ、アプリケーションにトランザクション障害の例外が送出されます。PREPARE 操作が完了している場合、トランザクション マネージャでは別のノードを使用して処理中のトランザクションを完了しようとします。
COMMIT 操作の間に障害が発生した場合、トランザクション マネージャでは COMMIT 操作を複数回、再試行します。この複数回の試行中、接続はブロックされます。COMMIT 操作が再試行の最初のセットで成功しない場合、アプリケーションは例外を受け取ります。その後トランザクション マネージャは、成功するまで定期的に COMMIT 操作を再試行し続けます。トランザクションが破棄時間までの間に正常に完了できなかった場合、トランザクションはヒューリスティックな完了を余儀なくされます。
マルチ データ ソースを使用して WebLogic Server と複数の Oracle RAC ノードを接続するには、まず RAC クラスタ内の各 RAC インスタンスに、Oracle Thin Driver と共に JDBC データ ソースをコンフィグレーションします。次に、ロードバランシングのアルゴリズムとフェイルオーバのアルゴリズムのどちらかを使用してマルチ データ ソースをコンフィグレーションし、データ ソースを追加します。
図 B-3 に、一般的なマルチ データ ソースのコンフィグレーションを示します。
Administration Console、または、ドメインのコンフィグレーションによく用いる他の方法 (weblogic.Admin コマンドライン ユーティリティ、Weblogic Scripting Tool (WLST)、JMX プログラムなど) を使用できます。WebLogic JDBC マルチ データ ソースのコンフィグレーションについては、「JDBC マルチ データ ソースのコンフィグレーション」を参照してください。
このコンフィグレーションでデータベース接続を使用するには、アプリケーションで JNDI ツリー上のマルチ データ ソースを 1 つルックアップしてから、接続を要求します。マルチ データ ソースは、コンフィグレーションで指定されたアルゴリズムの種類に基づいて、接続リクエストに応じるためにどちらのデータ ソース (つまり、フェイルオーバまたはロード バランシング) を使用するかを決定します。
マルチ データ ソースには、使用するシステムでの RAC の役割 (ロード バランシングまたはフェイルオーバ) によって、次の属性のいずれかを指定できます。
AlgorithmType="Load-Balancing" または AlgorithmType="Failover" FailoverRequestIfBusy="true" TestFrequencySeconds="120" このコンフィグレーションでは、マルチ データ ソースによってトランザクションが必ず 1 つの Oracle RAC インスタンスに「固定」され、RAC インスタンスが利用不可能になった場合には、マルチ データ ソース レベルでフェイルオーバが処理されます。PREPARE 操作の前に、RAC インスタンスに障害があった場合、再試行の期間が時間切れになるまでこの操作が再試行されます。PREPARE 操作の後に障害があった場合は、トランザクションは別のインスタンスにフェイルオーバされます。
マルチ データ ソース内の XA データ ソースには、以下のルールが適用されます。
注意 : XA を利用しない場合にも RAC インスタンス間のフェイルオーバおよびロード バランシングにはマルチ データ ソースを使用することをお勧めしますが、その場合、上記の XA 固有のコンフィグレーション要件は適用されません。詳細については、「グローバル トランザクションを利用しない場合のマルチ データ ソースの使用」を参照してください。
マルチ データ ソース内の各データ ソースには、以下の属性が必要です。
<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
KeepXAConnTillTxComplete="true" XARetryDurationSeconds="300"TestConnectionsOnReserve="true"TestTableName="name_of_small_table" 物理データベース接続のテストに使用されるテーブルの名前。この属性の詳細については、「データソースの接続テスト オプション」を参照してください。マルチ データ ソース、および関連する 2 つのデータ ソースのサンプル コンフィグレーション コードを以下に示します。
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91"
xmlns:sec="http://www.bea.com/ns/weblogic/91/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/91/security/wls"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/91/domain.xsd">
<name>oracleRACXAPool</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<profile-type>0</profile-type>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>oracleRACXAJndiName</jndi-name>
<global-transactions-protocol>TwoPhaseCommit
</global-transactions-protocol>
</jdbc-data-source-params>
<jdbc-xa-params>
<keep-xa-conn-till-tx-complete>true</keep-xa-conn-till-tx-complete>
<xa-end-only-once>true</xa-end-only-once>
<xa-set-transaction-timeout>true</xa-set-transaction-timeout>
<xa-transaction-timeout>120</xa-transaction-timeout>
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
</jdbc-xa-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91"
xmlns:sec="http://www.bea.com/ns/weblogic/91/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/91/security/wls"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/91/domain.xsd">
<name>oracleRACXAPool2</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@lcqsol25:1521:SNRAC2</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<profile-type>0</profile-type>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>oracleRACXAJndiName2</jndi-name>
<global-transactions-protocol>TwoPhaseCommit
</global-transactions-protocol>
</jdbc-data-source-params>
<jdbc-xa-params>
<keep-xa-conn-till-tx-complete>true</keep-xa-conn-till-tx-complete>
<xa-end-only-once>true</xa-end-only-once>
<xa-set-transaction-timeout>true</xa-set-transaction-timeout>
<xa-transaction-timeout>120</xa-transaction-timeout>
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
</jdbc-xa-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91"
xmlns:sec="http://www.bea.com/ns/weblogic/91/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/91/security/wls"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/91/domain.xsd">
<name>oracleRACXAMDS</name>
<jdbc-data-source-params>
<jndi-name>oracleRACMDSJndiName</jndi-name>
<algorithm-type>Load-Balancing</algorithm-type>
<data-source-list>oracleRACXAPool,oracleRACXAPool2</data-source-list>
</jdbc-data-source-params>
</jdbc-data-source>
以下の節では、グローバル トランザクションを必要としないアプリケーション内のマルチ データ ソースと共に Oracle RAC を使用するコンフィグレーションについて説明します。
<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
TestConnectionsOnReserve="true"TestTableName="name_of_small_table" WebLogic JDBC マルチ データ ソース、および関連するデータ ソースのサンプル コンフィグレーション コードを以下に示します。
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91"
xmlns:sec="http://www.bea.com/ns/weblogic/91/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/91/security/wls"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/91/domain.xsd">
<name>jdbcPool</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@lcqsol24:1521:snrac1</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-connections-on-reserve>true</test-connections-on-reserve>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>jdbcDataSource</jndi-name>
</jdbc-data-source-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91"
xmlns:sec="http://www.bea.com/ns/weblogic/91/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/91/security/wls"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/91/domain.xsd">
<name>jdbcPool2</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@lcqsol25:1521:SNRAC2</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-connections-on-reserve>true</test-connections-on-reserve>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>jdbcDataSource2</jndi-name>
<global-transactions-protocol>OnePhaseCommit
</global-transactions-protocol>
</jdbc-data-source-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91"
xmlns:sec="http://www.bea.com/ns/weblogic/91/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/91/security/wls"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/91/domain.xsd">
<name>jdbcNonXAMultiPool</name>
<jdbc-data-source-params>
<jndi-name>jdbcDataSource</jndi-name>
<algorithm-type>Failover</algorithm-type>
<data-source-list>jdbcPool,jdbcPool2</data-source-list>
<failover-request-if-busy>true</failover-request-if-busy>
</jdbc-data-source-params>
</jdbc-data-source>
マルチ データ ソースをアプリケーションで使用できない場合は、接続時フェイルオーバおよびロード バランシングを使用するようデータ ソースをコンフィグレーションできます。接続時フェイルオーバとロード バランシングを行うようにコンフィグレーションされたデータ ソースを使用して、WebLogic Server と複数の Oracle RAC ノードを接続するには、後述するように、RAC クラスタ内の各 RAC インスタンスに、Oracle Thin Driver と共に JDBC データ ソースをコンフィグレーションします。図 B-4 は、システムの概要を示します。
図 B-4 Oracle Thin Driver の接続時フェイルオーバを使用したデータ ソースのコンフィグレーション
JDBC 接続プールは、Administration Console を使用して作成するか、普段ドメインをコンフィグレーションしている方法 (weblogic.Admin コマンドライン ユーティリティ、Weblogic Scripting Tool (WLST)、JMX プログラムなど) で作成できます。
データ ソースに接続が作成されると、Oracle Thin Driver によって使用する Oracle RAC インスタンスが決定されます。アプリケーションでは接続を取得すると、JNDI ツリーでデータ ソースをルックアップして、データ ソースから接続を要求します。データ ソースは、データ ソース内の接続のプールから使用可能な接続のうち 1 つを配信します。
以下の節では、コンフィグレーションのオプションと要件について説明します。
以下の節では、Oracle RAC の接続時フェイルオーバ機能を使用して接続の障害に対処するコンフィグレーションについて説明します。このコンフィグレーションでは、障害のケースによって、フェイルオーバにかかる時間が TCP タイムアウトと同じ長さになる場合もあります。これは環境により数分間に及ぶ場合があります。
このコンフィグレーションを使用するには、以下の属性で WebLogic ドメインに JDBC データ ソースを作成します。
<url>jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=
(PROTOCOL=TCP)(HOST=lcqsol24)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)
(HOST=lcqsol25)(PORT=1521))(FAILOVER=on)(LOAD_BALANCE=off))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=snrac)))</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
ConnectionReserveTimeoutSeconds="120"TestConnectionsOnReserve="true"TestTableName="name_of_small_table" 物理データベース接続のテストに使用されるテーブルの名前。この属性の詳細については、「データソースの接続テスト オプション」を参照してください。<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91"
xmlns:sec="http://www.bea.com/ns/weblogic/91/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/91/security/wls"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/91/domain.xsd">
<name>oracleRACNonXAPool</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)
HOST=lcqsol24)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)
(HOST=lcqsol25)(PORT=152))(FAILOVER=on)
(LOAD_BALANCE=off))(CONNECT_DATA=(SERVER=DEDICATED)
(SERVICE_NAME=snrac)))</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-connections-on-reserve>true</test-connections-on-reserve>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<profile-type>4</profile-type>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>oracleRACJndiName</jndi-name>
<global-transactions-protocol>OnePhaseCommit
</global-transactions-protocol>
</jdbc-data-source-params>
</jdbc-data-source>
Oracle RAC で XA (グローバル トランザクション) を使用する際は、以下の要件および制限を考慮する必要があります。
このコンフィグレーションでは、Oracle Thin Driver の接続時フェイルオーバを使用して「グローバル トランザクションを利用しない場合の接続時フェイルオーバの使用」に説明されているようにデータベース接続を作成する必要があります。
XA を使用する場合には、Oracle 9i RAC が以下の要件を満たしている必要があります。
グローバル トランザクションは、RAC クラスタの同じインスタンスで開始、準備、終了する必要があります。これは、JDBC データ ソースのコンフィグレーションで KeepXAConnTillTxComplete="true" を設定すると、WebLogic Server のデータ ソースによって管理されます。
注意 : WebLogic Server では、Oracle RAC を使用できるようにするため、Oracle Thin Driver の接続時フェイルオーバ機能を使用しています。Oracle の Technical Note 235118.1 で説明されているように、Oracle Thin Driver でロード バランシングをコンフィグレーションした場合、トランザクションの開始と終了が同じ RAC インスタンスで行われるかどうかは保証されません。Oracle RAC では、グローバル トランザクション内のすべてのデータベース操作が同じ Oracle インスタンスにルーティングされる必要があるため、この確認済みの制限があることで、XA と Oracle RAC を併用する場合に接続レベルのロード バランシングは使用できないことになります。結果として、プライマリ/プライマリの RAC コンフィグレーションは使用できません。
グローバル トランザクションを利用する場合は、トランザクション ID (XID) が RAC クラスタ内でユニークになっている必要があります。しかし、Oracle Thin ドライバや Oracle RAC インスタンスでは、RAC クラスタ内で XID がユニークになっているかどうかを識別できません。同じ XID のトランザクションが複数存在すると、SQL コードが RAC クラスタの別々のインスタンスで実行されるおそれがあり、その場合でも例外は送出されません。
WebLogic Server トランザクション マネージャは、ユニークなトランザクション ID を生成します。しかし、フェイルオーバが発生した場合には、トランザクションが発信側インスタンスでなく RAC インスタンスで継続されてデータに矛盾が生じるおそれがあります。「障害発生時に、完了したトランザクションに矛盾 (データの消失) が生じる可能性」を参照してください。
以下の節では、Oracle RAC と共に XA および WebLogic Server を使用する場合の既知の問題や制限について説明します。これらの制限事項は、Oracle バグ番号 3428146 および 395790 でも説明されています。これらの問題の詳細については、Oracle にお問い合わせください。
マルチ データ ソースが使用されていない場合、障害発生時に、トランザクションを開始したインスタンス以外の RAC インスタンスで発生したトランザクション処理 (データの変更) が、通知や例外が送出されることなく消失することがあります。
たとえば、次のような WebLogic Server コンフィグレーションを考えてみます。
server1 と server2) がある。ds1 がこのクラスタに割り当てられている (このデータ ソースと同一のインスタンスが、クラスタ内のすべてのインスタンス上に存在している)。ds1 が Oracle RAC クラスタに接続するようにコンフィグレーションされていて、接続時フェイルオーバが有効になっている。RAC1 がプライマリ RAC インスタンスとして、RAC2 がセカンダリ RAC インスタンスとして設定されている。データ ソース ds1 がこのクラスタに割り当てられている (このデータ ソースと同一のインスタンスが、WebLogic クラスタ内のすべてのノード上に存在している)。結果 : RAC1 でのデータ変更はコミットされます。RAC 2 でのデータ変更は無視されます。WebLogic Server トランザクション マネージャは、このリソースに対して prepare と commit を呼び出します。このケースでは、データ ソースの名前が同じであるためこれらが同じリソースとみなされ、呼び出しはデータ ソースの 1 つのインスタンスに対してのみ行われます。これらのデータ ソースには別々の RAC インスタンスへの接続が含まれているため、一方の RAC インスタンスでのデータ変更はコミットされますが、もう一方の RAC インスタンスでのデータ変更は消失します。
回避策 : ネットワーク障害を回避するため、WebLogic Server インスタンスと Oracle RAC インスタンスの間に余分なネットワーク ハードウェアを供給します。
RAC クラスタにおいてトランザクション ID が利用できなくなる時間帯があります。これは Oracle の既知の制限です。この制限が原因で、障害発生時に一部の未完了トランザクションが正しく完了されない場合があり、結果としてデータベースでデッドロックが発生するおそれがあります。このような障害が発生することを防ぐために、WebLogic Server には Oracle RAC に対する XA 呼び出しの再試行を有効にする 2 つのコンフィグレーション属性、XARetryDurationSeconds と XARetryIntervalSeconds が用意されています。これらのコンフィグレーション オプションの詳細については、「フェイルオーバ中の遅延」を参照してください。
トランザクションの処理中に、PREPARE 操作は完了したがその結果がトランザクション ログに書き込まれていない時点で、データベース サーバ インスタンスがクラッシュした場合、そのトランザクションに対するクライアントからの COMMIT 呼び出しが数分間に渡ってハングすることがあります (TCP タイムアウト期間が経過するまでハングが続く場合もあります)。この事態が発生する時間帯は短く、問題が起こることはまれです。現時点でこの問題の回避策はありません。
JDBC ストアと Oracle RAC を併用している場合、Oracle RAC ノードのフェイルオーバに関して考慮する必要のある機能と制限があります。以下の節を参照してください。
JDBC ストアのしくみでは、Oracle RAC と併用するためのコンフィグレーションのオプションが限られています。JDBC ストアは、グローバル トランザクションをサポートするようにコンフィグレーションされた JDBC データ ソースを使用するようにコンフィグレーションすることはできません。JDBC ストアは、非 XA JDBC ドライバを使用する JDBC データ ソースを使用する必要があります。
JDBC ストアは、1 つの接続が失敗するまで、その接続を保持します。失敗すると、次の接続に進んで、プロセスを繰り返します。したがって、JDBC ストアでは、ロード バランシング マルチ データ ソースを使用することを含めて、ロード バランシングを実装することができません。フェイル オーバ アルゴリズムを使用するには、JDBC ストアに対してマルチ データ ソースをコンフィグレーションする必要があります。このコンフィグレーション オプションの詳細については、「グローバル トランザクションを利用しない場合のマルチ データ ソースの使用」を参照してください。
JMS には制限された接続再試行のメカニズムがあります。このメカニズムによって、JMS はそのデータベース接続をホストする RAC ノードの障害に対して、特に通知することなく対応できます。データベースで、ネットワークの軽微な「一時的中断」、または別のノードにフェイルオーバした RAC データベースに遭遇した場合、2 度目の接続の試み (再試行) によって次の RAC ノードの対応を引き継ぎます。
再試行が行われる時間、および実施される再試行の数は、制限されています。これは、接続の再試行時間が長期化することによるネガティブな影響を最小限に抑えるためです。長い期間、データベース接続が利用できない状態のままだと、遅延により JMS 機能の適切な処理 (たとえば、正しいメッセージの順序の維持など) の続行が妨げられることがあります。さらに、この期間内に処理の進行が十分に行われない場合、トランザクション マネージャによってトランザクションの JMS リソースが応答なしと判断されることがあり、メモリ不足の状態が発生することもあります。RAC のフェイルオーバ時間の単位を最小限に抑えるために役立つシステム レベルのチューニング ガイドラインがあります。このガイドラインは、自動での再試行を成功させるために重要です。
自動での再試行を緊密なループで行うことは、JMS の処理にトランザクションを伴う場合に特に重要です。JDBC ストアで I/O 障害が発生すると、ストア レコードが不明な状態になり、それによってメッセージ自体も不明な状態に置かれます。メッセージがこの不明な状態のままコミットされないように、JMS ではそのメッセージに関連するトランザクションを「failedTransaction」とマークします。トランザクション マネージャで、これ以降にこのメッセージのコミットを完了するどのような試みがなされた場合にも、JMS では javax.transaction.xa.XAException が送出され、errorCode が XAException.XAER_RMERR に設定されます。この例外は、トランザクション マネージャに対して、リソース マネージャ (JMS) に一時的なエラーが発生していること、およびトランザクション マネージャでコミット処理を再試行する必要があることを示すものです。この再試行ロジックにより、JMS が上部レイヤに (RMERR に変化する) どのような障害をも通信する以前に、接続を確立するための 2 番目の試行が実施されます。RMERR が生成された場合、その後でメッセージを回復してトランザクションを完了するには、WebLogic Server を再起動するのが唯一の方法です。
自動での再試行ロジックは、現在の WebLogic Server では次のようなオプションで管理されています。
-Dweblogic.store.jdbc.IORetryDelaySeconds=X
ここで、X は、データベースへの接続が再試行されるまでに経過する必要のある秒数です。デフォルトでは 1 秒です。この値は、0 から 15 に制限されていて、再試行は 1 回だけ行われます。2 番目の試行で障害が発生すると、例外がコール スタックに伝播されます。この場合、失敗したトランザクションに関連するメッセージを回復するには手動での再起動が必要になります。
|
|
|