| Oracle® Fusion Middleware Oracle WebLogic Server JDBCの構成と管理 11gリリース1 (10.3.3) B60997-01 |
|
 前 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCの構成と管理 11gリリース1 (10.3.3) B60997-01 |
|
前 |
バックエンド・システムのスケーラビリティや可用性をより高めるソリューションがますます求められています。こうしたリクエストに応えるため、WebLogic ServerではOracle Real Application Clusters (Oracle RAC)の使用がサポートされています。
次の項では、WebLogic ServerでOracle Real Application Clustersを使用する場合の要件および構成タスクについて説明します。
Oracle RACとWebLogic Serverはどちらも複雑なシステムです。これらを一緒に使用するには、クラスタリング・ソフトウェアおよび共有ストレージ・ソリューションに加え、両方のシステム上での固有の構成が必要になります。このドキュメントでは、要求される構成について概要レベルで説明します。Oracle RAC、使用しているクラスタリング・ソフトウェア、使用しているオペレーティング・システム、および使用しているストレージ・ソリューションの構成に関する詳細は、それぞれのベンダーが提供するドキュメントを参照してください。
Oracle Real Application Clusters (Oracle RAC)は、複数のマシンのユーザーが単一のデータベースに高いパフォーマンスでアクセスすることを可能にする高可用性ソリューションに追加できるソフトウェア・コンポーネントです。Oracle RACは、複数のクラスタリングされたマシン上で実行され、クラスタ技術によって共有ストレージ・デバイスにアクセスする複数のOracleデータベース・インスタンスで構成されます。このアーキテクチャをサポートするため、データベース・インスタンスをホストするマシンは高速のインターコネクトでリンクされて、クラスタを形成します。インターコネクトとは、クラスタのノード間の通信手段として使用される物理的なネットワークです。クラスタ機能は、オペレーティング・システムまたは互換性のあるサード・パーティのクラスタリング・ソフトウェアによって提供されます。図B-1にOracle RACの構成を示します。
Oracle RACは次の領域で機能を提供します。
スケーラビリティ
可用性
ロード・バランシング
フェイルオーバー
インストールされているOracle RACは、単一の標準的なOracleデータベースのように見え、同じツールと実行方法で管理されます。クラスタのすべてのノードは同じデータベースに対してトランザクションを実行し、Oracle RACにより各ノードから共有データへのアクセスが調整されて一貫性が維持され、整合性が確保されます。クラスタにはノードを簡単に追加でき、追加時にデータを分割する必要もありません。つまり、Oracle RACノード、ストレージ、またはその両方を追加することで、処理とリクエストの増加に伴い、データベース層を水平方向に拡張できます。その後、新しいノードにマップされるデータ・ソースを追加することにより、WebLogic Serverを拡張できます。
構成によっては、Oracle RACノードまたはインスタンスに失敗した場合、WebLogic ServerまたはOracle Thin Driverがクラスタ内の他のノードにセッション・リクエストをリダイレクトします。WebLogic Serverとともに使用する場合、Oracle RACは、データベース接続用のフェイルオーバーを提供しないことに注意してください。インフライト・トランザクションは、通常、データベースがトランザクション・マネージャであるときにロールバックします。WebLogic Serverがトランザクション・マネージャであるとき、処理中のトランザクションは、失敗時のトランザクションの状態に基づいて完了またはロールバックされるという意味でフェイルオーバーされます。
アプリケーションでOracle RACノード間のロード・バランシングが必要な場合、WebLogic Serverは、JDBCマルチ・データ・ソースをOracle RACノードで使用することでこの機能をサポートします(マルチ・データ・ソースはデータ・ソースのグループを抽象化したものであり、接続リクエストの際に、マルチ・データ・ソースと関連付けられたデータ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供します)。マルチ・データ・ソースを形成するデータ・ソースは、ラウンドロビン方式でアクセスされます。接続を切り替える場合、WebLogic Serverはリストされた順に次のデータ・ソースから接続を選択します。Oracle RACでのマルチ・データ・ソース使用の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
Oracle Database 10g (10.2)以前でのOracle RACデプロイメントの場合は、マルチ・データ・ソースを使用する場合にのみXAがサポートされます。そのため、XAのロード・バランシングは、マルチ・データ・ソースを使用する場合にのみサポートされます。マルチ・データ・ソースを使用しない構成では、WebLogic ServerはOracle Thin Driverで提供される接続時フェイルオーバー機能を使用して、Oracle RACと連携します。OracleのTechnical Note 235118.1で説明されているように、Oracle Thin Driverでロード・バランシングを構成した場合、トランザクションの開始と終了が同じOracle RACインスタンスで行われるかどうかは保証されません。Oracle RACでは、グローバル・トランザクション内のすべてのデータベース操作が同じOracleインスタンスにルーティングされる必要があり、この既知の制限があることで、Oracle RACでXAを使用する場合、ドライバ・レベルのロード・バランシングを使用できないことになります。結果として、プライマリ/プライマリのRAC構成は使用できません。
Oracle Database 11g (11.1)では、WebLogic Server用の高可用性データベース・ソリューションとしてOracle RAC 11gがサポートされています。ただし、このリリースでは、WebLogic Serverは、ロード・バランシングを使用したXAをサポートするOracle RAC 11gの新機能はサポートしていません。そのかわりとしてWebLogic Serveｒは、引き続きマルチ・データ・ソースを使った実績のある統合アーキテクチャをロード・バランシングを使用したXAのかわりに使用します。
Oracle RACはJDBC接続時フェイルオーバー機能を提供していますが、大半の構成では、それではなく、WebLogic JDBCマルチ・データ・ソースを使用してフェイルオーバーを処理することをお薦めします。接続時フェイルオーバーには、代替Oracle RACノードへの接続をあらかじめ作成する機能はありませんが、マルチ・データ・ソースでは、常に複数の接続をフェイルオーバーの処理に利用できます。詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
|
注意: Transparent Application Failover (TAF)はWLSデータ・ソースではサポートされていません。JDBCを通じて提供されるTAFは、現在、透過的ではありません。進行中の問合せ結果とプリペアド文に予測不能かつリカバリ不可能な影響を与えることがドキュメント化されています。TAF JDBCは、アプリケーション・レベルで特定のリカバリ・コードを必要とし、WebLogicがキャッシュしている可能性のある文の整合性に影響を与えます。 |
WebLogic ServerでOracle RACを使用するには、次の要件を考慮する必要があります。
|
注意: WebLogic Serverでサポートされるハードウェア・プラットフォームやオペレーティング・システム、およびWebLogic Serverの各バージョンやサービス・パックでサポートされるOracle RACのバージョンの最新情報については、「Oracle Fusion Middleware Supported System Configurations」ページ(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)を参照してください。Oracle RACソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracleのドキュメントを参照してください。 |
WebLogic ServerおよびOracle RACの標準的なシステムには、WebLogic Serverクラスタ、Oracle RACクラスタ、および共有ストレージ用のハードウェアが含まれます。
WebLogic Serverクラスタを構成する複数の方法および様々なハードウェア・オプションがあります。WebLogic Serverクラスタの構成については、『Oracle WebLogic Serverクラスタの使い方』を参照してください。
Oracle RACに関する最新のハードウェア要件については、Oracle RACのドキュメントを参照してください。ただし、WebLogic ServerでOracle RACを使用するには、堅牢な本番品質のハードウェア上でOracle RACインスタンスを実行する必要があります。Oracle RACの構成では、アプリケーションの負荷要件を適切に予想し、それに見合ったデータベース処理性能を実現する必要があります。データベースのレスポンスが著しく遅れると、データベースのフェイルオーバー処理の間に予期しない動作が生じるおそれがあります。
WebLogic ServerをOracle RACで使用するには、各Oracle RACノードに次のソフトウェアをインストールする必要があります。
Oracle RACのサポートに必要なオペレーティング・システムのパッチ。詳細は、Oracleが提供するリリース・ノートを参照してください。
Oracle 10gまたはOracle 11gのデータベース管理システム
使用しているオペレーティング・システム用のクラスタリング・ソフトウェア。サポートされるクラスタリング・ソフトウェアおよびクラスタ構成については、Oracleのドキュメントを参照してください。
Veritas Cluster File Systemなどの共有ストレージ・ソフトウェア。一部のクラスタリング・ソフトウェアには、ファイル・ストレージ・ソリューションが含まれています。その場合は、共有ストレージ・ソフトウェアは必要ありません。
|
注意: WebLogic Serverでサポートされるハードウェア・プラットフォームやオペレーティング・システム、およびWebLogic Serverの各バージョンやサービス・パックでサポートされるOracle RACのバージョンの最新情報については、「Oracle Fusion Middleware Supported System Configurations」ページ(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)を参照してください。Oracle RACソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracleのドキュメントを参照してください。 |
Oracle RACをインストールして構成したら、次の項で説明するように各Oracle RACインスタンスに対してリスナー・プロセスを構成する必要があります。Oracle RACノードに対して、オペレーティング・システムおよびOracleソフトウェアをインストールおよび構成する方法については、Oracleのドキュメントを参照してください。
リスナー・プロセスは、Oracle RACに、ユーザー・プロセスとOracleインスタンス間で通信経路を確立します。WebLogic ServerでOracle RACを使用する場合、ユーザー・プロセスは通常、JDBCデータ・ソースです。
データ・ソースは作成されると、アプリケーションが使用するデータベース接続のプールを作成しようとします。プールされたデータベース接続が操作できなくなったり、データ・ソース容量が増えるように構成されている場合、データ・ソースは、構成ファイルに指定されている最大値になるまで、データベース接続を追加作成しようとします。こうしたすべてのケースにおいて、Oracleリスナー・プロセスはOracle RACインスタンスに対する接続リクエストを処理します。
図B-2にOracleリスナー・プロセスの機能を示します。
この機能を有効にするには、2つのオプションがあります。
ローカル・リスナーの使用：Oracleクラスタ内の各Oracle RACインスタンスごとにリスナー・プロセスを構成します。各Oracle RACインスタンスについてローカル・リスナーの構成が必要です。各データベース・インスタンスは、そのローカル・リスナーのみ登録するように構成する必要があります。
Oracleインスタンスのリスナー登録は、listener.oraファイルで静的に構成したり、インスタンスの初期化パラメータlocal_listenerを使用して動的に登録できます(両方で登録可能)。動的に登録することをお薦めします。
リスナーは、共有ディスパッチ・プロセスまたは専用プロセスのいずれかを起動できます。WebLogic Serverを使用する場合、専用プロセスの使用をお薦めします。
リモート・リスナーの使用：WLSでは、マルチ・データ・ソース内のデータ・ソースのJDBC URLでSERVICE_NAMEとINSTANCE_NAMEの両方を指定する必要があります。「リモート・リスナーが有効または無効になっている場合のマルチ・データ・ソースの構成」を参照してください。
Oracle RACバックエンドに対して、サーバー側のロード・バランシング機能が(remote_listenersを使用して)有効化されている場合は、マルチ・データ・ソース構成のデータ・ソースに使用されたJDBC URLには、INSTANCE_NAMEを含める必要があります。たとえば、次の形式でURLを指定できます。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))
URLにINSTANCE_NAMEを指定できない場合、リモート・リスナーを無効に設定する必要があります。リモート・リスナーを無効に設定するには、各Oracle RACノード上のspfile.ora内にリストされている任意のリモート・リスナーを削除します。例:
*.remote_listener="
この場合、マルチ・データ・ソース構成のデータ・ソースで使用するには次のURLをお薦めします。
jdbc:oracle:thin:@host-vip:port/dbservice
または
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))( CONNECT_DATA=(SERVICE_NAME=dbservice)))
Oracle RACでWebLogic Serverを使用する場合、Oracle RACインスタンスと対話でき、期待どおりに動作するようにWebLogicドメインを構成する必要があります。次の項では、構成のオプションと要件について説明します。
WebLogic Serverでは、Oracle RACを使用するためのいくつかの構成オプションがサポートされています。
グローバル・トランザクション(XA)の使用時に、複数のOracle RAC 10gまたはOracle RAC 11gインスタンスに接続するには、トランザクション対応のWebLogic JDBCマルチ・データ・ソース(フェイルオーバーとロード・バランシングをサポート)を使用してOracle RACノードに接続することをお薦めします。詳細は、「グローバル・トランザクションを利用する場合のマルチ・データ・ソースの使用」を参照してください。
XAを使用していない場合に、複数のOracle RAC 10gまたはOracle RAC 11gインスタンスに接続するには、(非トランザクション対応の)マルチ・データ・ソースを使用してOracle RACノードに接続することをお薦めします。フェイルオーバーとロード・バランシングをサポートする、標準的なマルチ・データ・ソース構成を使用してください。詳細は、「グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用」を参照してください。
マルチ・データ・ソースの使用を選択できずXAも使用していない場合に、複数のOracle RACノードに接続するには、Oracle RAC 10gまたはOracle RAC 11gを接続時フェイルオーバー機能とともに使用します。ロード・バランシングは、この構成ではサポートされていません。詳細は、「グローバル・トランザクションを利用しない場合の接続時フェイルオーバーの使用」を参照してください。
以下の表を、特定のアプリケーションに適した構成を判断する際の指標としてご利用ください。
表B-1 Oracle RACと併用するための構成の選択
| ロード・バランシングは必要? | フェイルオーバーは必要? | グローバル・トランザクション(XA)は必要? | JDBCストアは必要? | Oracle RACサービス | 次を参照 |
|---|---|---|---|---|---|
|
はい |
はい |
はい |
いいえ |
いいえ |
グローバル・トランザクションを利用する場合のマルチ・データ・ソースの使用 |
|
はい |
はい |
いいえ |
はい |
いいえ |
グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用 |
|
はい |
はい |
はい |
はい |
はい |
|
|
いいえ |
はい |
いいえ |
はい |
はい |
グローバル・トランザクションを利用しない場合の接続時フェイルオーバーの使用 |
Oracle RACノードの実行中の特定のサービスに接続するデータ・ソースも構成できます。この構成では、マルチ・データ・ソースが必要になります。ロード・バランシングおよびフェイルオーバーの両方がサポートされています。XAおよびXA以外のドライバの両方が提供されています。詳細は、「Oracle RACノード上のサービスに対する接続の構成」を参照してください。
WebLogic ServerをOracle RACとともに使用するには、WebLogic JDBCデータ・ソースでOracle JDBC Thin Driver 11gを使用して、データベース接続を作成する必要があります。
フェイルオーバーを構成する際には、次の情報について考慮する必要があります。
マルチ・データ・ソースはグローバル・トランザクションに対してフェイルオーバーとロード・バランシングを提供し、接続時フェイルオーバーを使用したデータ・ソース構成に関する制限や既知の問題はありません。マルチ・データ・ソースのフェイルオーバー機能の説明については、「マルチ・データ・ソース・フェイルオーバー機能の拡張」を参照してください。
図B-3に示すこの構成を使用すると、以下の利点があります。
マルチ・データ・ソース制御による、より高速なフェイルオーバー
WebLogic Serverヘルス・モニターによる、自動フェイルバック
マルチ・データ・ソースは、Oracle RACノードが利用不可能な場合にデータベース接続用フェイルオーバーを処理します。WebLogic Serverで接続テストに失敗した場合、接続の再作成を試みます。それに失敗した場合、サーバーでは、マルチ・データ・ソースの他のデータ・ソース(他のOracle RACノードに対応)に対するルート接続リクエストとデータ・ソースが無効に設定されます。WebLogic Serverは、無効化されたデータ・ソースのデータベース接続の再作成を定期的に試みます。接続が正常に再作成された場合、次にデータ・ソースを再有効化し、データ・ソースへの接続リクエストのルーティングを開始します。接続リクエストのルーティングおよび正常性チェックの機能により、Oracle Thin driver接続時フェイルオーバーの構成に依存する場合に比べて、最小時間で失敗後の接続リクエストを満たします。
マルチ・データ・ソースが選択肢にない場合、Oracle RACインスタンスが利用できなくなり、プライマリ/プライマリ構成が選択できなければ、WebLogic Serverは、Oracle Thin Driverの接続時フェイルオーバー機能を使用して接続のフェイルオーバーを処理します。WebLogic Serverが接続をテストして接続が失敗した場合、サーバーは新しい接続を取得して置き換えを行い、ドライバは、どのOracle RACインスタンスを使用するかを、インスタンスの可用性に基づいて改めて決定します。接続テストで接続が失敗した場合、WebLogic Serverはデータ・ソース内のすべての接続を自動的に閉じます。WebLogic Serverは、ドライバを使用してどのノードに接続するかを判断し、接続を新しいものに置き換えます。この場合、プライマリOracle RACノードは失敗しているため、新しい接続はセカンダリOracleノードに対するものとなります。WebLogic Serverは、リクエストに応じる前に新しい接続をテストします。
あるOracle RACノードが別のOracle RACノードにフェイルオーバーした場合、現在障害の発生しているノードの処理中のトランザクション・ブランチに関連するデータがクラスタ全体で利用可能になるまでに、遅延が発生することがあります。これにより、未完了のトランザクションが適切に完了できなくなり、さらにはデータベース内でデータのロックが発生することがあります。このような遅延発生の可能性を防ぐために、WebLogic ServerにはOracle RACに対するXA呼出しの再試行を有効にする2つの構成属性、XARetryDurationSecondsとXARetryIntervalSecondsが用意されています。
XARetryDurationSecondsは、保留中のトランザクションのXA操作(回復、コミット、ロールバックなど)の再試行を繰り返す間隔を指定します。XARetryIntervalSecondsでは、設定した期間内に再試行する頻度を指定します。
XA呼出しの再試行を有効化するには、Oracle RACインスタンスに接続するWebLogicドメイン内のすべてのJDBCデータ・ソースに対して、XARetryDurationSecondsの値を追加で指定します。例:
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>oracleRACXAPool</name>
...
<jdbc-xa-params>
...
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
</jdbc-xa-params>
</jdbc-data-source>
XARetryDurationSecondsの値は、次の式で決定します。
XARetryDurationSeconds = (データ・ソースからの接続を使用するトランザクションの最長トランザクション・タイムアウト) + (XIDがすべてのOracle RACノードで利用可能になるまでの遅延、通常は5分未満)
たとえば、アプリケーションで設定されている最長のトランザクション・タイムアウトが180秒の場合には、XARetryDurationSecondsを180秒+ 300秒の合計、つまり480秒に設定します。
|
注意: 一般にXARetryDurationSecondsは、すべてのトランザクションが適切に完了するように、必要とされる最小限の時間よりも長めに設定した方がよいでしょう。最小限必要な時間より大きな値を設定しても、通常の運用時であればアプリケーションのパフォーマンスには影響しません。この追加された処理は、準備状態にあるが完了に失敗したトランザクションにのみ影響します。 |
必要に応じて、XARetryIntervalSecondsにも値を設定できます。この値は、XA呼出しの再試行の間隔を決定します。デフォルトでは、この値は60秒です。値を小さくすると、XAの再試行の間隔が短くなります。ほとんどの場合は、デフォルト値で十分です。
管理コンソールからXARetryDurationSecondsおよびXARetryIntervalSecondsを有効化するには、次の手順に従います。
管理コンソールのチェンジ・センターでロックして変更をクリックします(まだ行っていない場合)。
「ドメイン構造」ツリーで「サービス」>「JDBC」を展開し、「データ・ソース」を選択します。
「JDBCデータ・ソースの概要」ページでデータ・ソース名をクリックします。
構成: 接続プールタブを選択します。
画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。
「XA再試行期間」]および「XA再試行間隔」を更新します。
「保存」をクリックします。
オプションで、WebLogic Scripting Tool (WLST)またはJMXプログラムを使用できます。
ノードに障害が発生した場合、データベースに対する処理中のトランザクションには何が起こるのでしょう。プライマリOracle RACノードに障害が発生した場合はどうでしょうか。WebLogic Serverでは、透過的なフェイルオーバーはサポートされていますか。こうした疑問やWebLogic Serverでの障害処理に関するその他の質問への回答として、トランザクション処理の段階を順を追って説明し、その中で各段階での障害の処理方法について解説します。
障害が発生する最初の段階は、アプリケーションがコミットするトランザクションを呼び出す前である可能性があります。この段階でデータベースまたはOracle RACノードに障害が発生した場合、アプリケーションは例外を受け取り、新しい接続を取得してトランザクションの処理を新たに試行する必要が生じます。WebLogic Serverは、透過的フェイルオーバーをサポートしていません。
アプリケーションがトランザクションをコミットする呼出しを行った後で障害が発生した場合、処理中のトランザクションの扱いはPREPARE操作が完了しているかどうかによって変わります。PREPARE操作が完了していない場合、トランザクション・マネージャによってトランザクションはロールバックされ、アプリケーションにトランザクション障害の例外がスローされます。PREPARE操作が完了している場合、トランザクション・マネージャは別のノードを使用して処理中のトランザクションを完了しようとします。
COMMIT操作の最中に障害が発生した場合、トランザクション・マネージャはCOMMIT操作を複数回、再試行します。この複数回の試行中、接続はブロックされます。COMMIT操作が再試行の最初のセットで成功しない場合、アプリケーションは例外を受け取ります。その後トランザクション・マネージャは、成功するまで定期的にCOMMIT操作を再試行し続けます。トランザクションが破棄時間までの間に正常に完了できなかった場合、トランザクションはヒューリスティックな完了を余儀なくされます。
マルチ・データ・ソースを使用してWebLogic Serverと複数のOracle RACノードを接続するには、まずOracle RACクラスタ内の各Oracle RACインスタンスに、Oracle Thin DriverとともにJDBCデータ・ソースを構成します。次に、ロード・バランシングのアルゴリズムとフェイルオーバーのアルゴリズムのどちらかを使用してマルチ・データ・ソースを構成し、データ・ソースを追加します。
図B-3に、一般的なマルチ・データ・ソースの構成を示します。
ドメインを構成するには、管理コンソールか、または、WebLogic Scripting Tool (WLST)やJMXプログラムなどのお好きな方法を使用できます。WebLogic JDBCマルチ・データ・ソースの構成については、第4章「JDBCマルチ・データ・ソースの構成」を参照してください。データ・ソースのマルチ・データ・ソースを、Oracle RACノードで実行中のサービスに接続できるように構成する方法については、「Oracle RACノードのサービスに対する接続の構成」を参照してください。
この構成でデータベース接続を使用するには、アプリケーションでJNDIツリー上のマルチ・データ・ソースを1つルックアップしてから、接続をリクエストします。マルチ・データ・ソースは、構成で指定されたアルゴリズムの種類に基づいて、接続リクエストに応じるためにどちらのデータ・ソース(つまり、フェイルオーバーまたはロード・バランシング)を使用するかを決定します。
マルチ・データ・ソースは、システム内のOracle RACの役割(ロード・バランシングまたはフェイルオーバー)によっては、次の属性を持ちます。
AlgorithmType="Load-Balancing"またはAlgorithmType="Failover"
Load-Balancingを指定すると、接続リクエストは利用可能なデータ・ソース全体に分散されます。High-Availabilityを指定した場合、接続リクエストはリストの最初にある利用可能なプールで処理されます。データ・ソースが切断された場合、接続リクエストはリスト内の次のデータ・ソースで処理されます。
FailoverRequestIfBusy="true"
フェイルオーバー・アルゴリズムとともにこの属性を指定すると、データ・ソース内の接続がすべて使用中の場合にフェイルオーバーできるようになります。
TestFrequencySeconds="120"
この属性は、WebLogic Serverが以前に「異常」としてマークしたデータ・ソースのヘルス状態をチェックして、接続を再作成できるかどうか、およびデータ・ソースを再有効化できるかどうかを確認する頻度を制御します。詳細は、第4章「JDBCマルチ・データ・ソースの構成」を参照してください。
Oracle RACノードの高速フェイルオーバーのためには、この値に短い間隔 - たとえば、10(秒) - を設定します。
|
注意: リリース11.1では、WebLogic Server用の高可用性データベースとしてOracle RAC 11gがサポートされています。ただし、ロード・バランシングを使用したXAをサポートするOracle RAC 11gで新たに追加されたOracleサービス機能はサポートされません。そのかわりとしてWebLogic Serverでは、引き続きマルチ・データ・ソースを使った実績のある統合アーキテクチャを使用してロード・バランシングを使用したXAをサポートします。 |
この構成では、マルチ・データ・ソースによってトランザクションが必ず1つのOracle RACインスタンスに固定されます。個々のトランザクションはトランザクションに対する最初の接続リクエスト時にロード・バランシングされます。Oracle RACインスタンスが使用できなくなった場合は、マルチ・データ・ソース・レベルでフェイルオーバーが処理されます。PREPARE操作の前にOracle RACインスタンスに障害があった場合、再試行の期間が時間切れになるまでこの操作が再試行されます。PREPARE操作の後に障害があった場合は、トランザクションは別のインスタンスにフェイルオーバーされます。
マルチ・データ・ソース内のXAデータ・ソースには、以下のルールが適用されます。
すべてのデータ・ソースが均一である必要があります。つまり、すべてのデータ・ソースがXAドライバを使用することが必要であるか、またはXAドライバを使用できるデータ・ソースはありません。
すべてのXA関連の属性について、指定する場合には、各データ・ソースに同じ値を設定する必要があります。こうした属性には以下のものがあります。
XARetryDurationSeconds
SupportsLocalTransaction
KeepXAConnTillTxComplete
NeedTxCtxOnClose
XAEndOnlyOnce
NewXAConnForCommit
RollbackLocalTxUponConnClose
RecoverOnlyOnce
KeepLogicalConnOpenOnRelease
|
注意: XAを利用しない場合にもOracle RACインスタンス間のフェイルオーバーおよびロード・バランシングにはマルチ・データ・ソースを使用することをお薦めしますが、その場合、前述のXA固有の構成要件は適用されません。詳細は、「グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用」を参照してください。 |
マルチ・データ・ソース内の各データ・ソースには、以下の属性が必要です。
Oracle Thin JDBC Driver 11g。例:
<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url> <driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
KeepXAConnTillTxComplete="true"
分散トランザクションが完了するまでのトランザクション処理の間中、必ずデータ・ソースで物理データベース接続を予約し、アプリケーションに同じ接続を提供するようにします。
これは、Oracle RACでの適切なトランザクション処理のためには必須です。
XARetryDurationSeconds="300"
WebLogic Serverのトランザクション・マネージャによる、指定された時間内でのXAの回復、コミット、ロールバック呼出しの再試行を有効にします。
TestConnectionsOnReserve="true"
アプリケーションがデータ・ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。
別のOracle RACノードのフェイルオーバーを有効にする必要があります。
TestTableName="name_of_small_table"。物理データベース接続のテストに使用される表の名前です。この属性の詳細は、「データ・ソースの接続テスト・オプション」を参照してください。
マルチ・データ・ソース、および関連する2つのデータ・ソースのサンプル構成コードを以下に示します。
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/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://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/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://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/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を使用する構成について説明します。
データ・ソースには以下の属性を指定する必要があります。
Oracle Thin JDBC Driver 11g。例:
<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url> <driver-oracle.jdbc.OracleDriver/driver-name>
TestConnectionsOnReserve="true"
アプリケーションがデータ・ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。
マルチ・データ・ソース内にフェイルオーバーおよび接続リクエスト・ルーティング(事実上、別のOracle RACノードへのフェイルオーバー)を有効化するために、必須です。
TestTableName="name_of_small_table"
物理的なデータベース接続をテストするために使用する表の名前。この属性の詳細は、「データ・ソースの接続テスト・オプション」を参照してください。
WebLogic JDBCマルチ・データ・ソース、および関連するデータ・ソースのサンプル構成コードを以下に示します。
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/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://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/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://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/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>
|
注意: 読みやすくするために改行が追加されています。 |
Oracle RACクラスタ内のOracleサービスに依存してワークロード管理をする場合は、サービスID (SID)を使用するかわりにマルチ・データ・ソースを使用して、それらのサービスに接続する必要があります。WebLogic Serverのデータ・ソースは特定のOracle RACノード上の特定のサービスにのみ接続するように構成でき、ワークロード管理とロード・バランシングの両方を提供します。
一般に、Oracle RACサービスに接続するには、次を行う必要があります。
接続する各サービスごとにマルチ・データ・ソースを作成します。
各ノードでサービスがアクティブに実行されているかどうかに関係なく、各マルチ・データ・ソース内で、サービスを構成するクラスタにある各Oracle RACノードに対して1つのデータ・ソースを作成します。
「サービスに接続するためのデータ・ソースの構成」では、これらのデータ・ソースを構成する際の特別な考慮事項について説明します。「サービス接続の構成」では、ロード・バランシングまたはワークロード管理に関するサンプル構成を示します。
Oracle RACノード上で実行されるサービスに接続するためのデータ・ソースの構成は、他のデータ・ソースの構成と同じ方法で(WLST、管理コンソール、または構成ウィザードを使用して)行いますが、以下の例外があります。
initial-capacity="0"
この設定は、WLSの起動時に非アクティブなプールに関するプール作成エラーを防ぎ、ノード上のサービスに接続できない場合でもWLSがデータ・ソースを作成できるようにします。このオプションを0に設定しない場合、データ・ソースの作成が失敗して、サービスの正常な起動が失敗する可能性があります。
管理コンソールでは、データ・ソースを作成した後で編集し、「初期容量」を0に設定します。
11gのOracle JDBC Thin (またはThin XA)ドライバ。例:
非XAの場合:
driver-name="oracle.jdbc.OracleDriver" url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service_1)(INSTANCE_NAME=DB_02)))"
管理コンソールで構成する場合は、データベース・ドライバドロップダウンから「OracleのRACサービス・インスタンス接続用ドライバ(Thin)」を選択し、「サービス名」フィールドでサービスを指定します。
XAの場合:
driver-name="oracle.jdbc.xa.client.OracleXADataSource" url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service1)(INSTANCE_NAME=DBase1)))"
管理コンソールで構成する場合は、データベース・ドライバドロップダウンから「OracleのRACサービス・インスタンス接続用ドライバ(Thin XA)」を選択し、「サービス名」フィールドでサービスを指定します。
|
注意: SERVICE_NAMEは特定のマルチ・データ・ソース内のすべてのデータ・ソースで同じにする必要があります。特定のマルチ・データ・ソース内では各データ・ソースごとに異なるホスト名とポートを指定します。 |
接続プールに対してmax-capacity (管理コンソールの「最大容量」)を指定する場合は、構成内の各Oracle RACノードの接続容量およびすべてのデータ・ソースからの接続の総数を考慮する必要があります。詳細は、「接続プールのキャパシティ・プランニング」を参照してください。
適切なマルチ・データ・ソース・アルゴリズムの選択
サービス接続のシナリオでは、マルチ・データ・ソースをロード・バランシング・アルゴリズムで構成することをお薦めします。マルチ・データ・ソースがロード・バランシング・アルゴリズムで構成されている場合、接続プールはラウンド・ロビン方式で使用されます。この場合、関連付けられたサービスが現在アクティブになっているすべてのOracle RACノード間で、ワークロードがロード・バランシングされます。
マルチ・データ・ソースがフェイルオーバー・アルゴリズムで構成された場合、最初のデータ・ソースは、なんらかの理由によって接続に失敗するまで、関連付けられたOracle RACノード上のサービスに接続するために使用されます(たとえば、Oracle RACノードが使用できないようになるか、またはデータ・ソースでそれ以上接続できなくなります)。その時点では、第2のデータ・ソースが関連付けられたOracle RACノード上のサービスなどに接続するために使用されます。この場合、最初のデータ・ソースに接続しているOracle RACノードは、サービス実行中の残りのノードより多く使用されます。
以下の機能を提供するように構成を設計できます。
ワークロード管理
ロード・バランシング
これらの構成について次の2つの項で説明します。
ワークロード管理の構成では、各マルチ・データ・ソースには、指定したOracle RACノード上の接続対象のサービスがアクティブかまたは非アクティブであるかどうかに関係なく、各Oracle RACノードの指定したサービスに対して1つのデータ・ソースが構成されています。これにより、未計画の停止時間またはスケジュール済メンテナンスによって別のノードが使用されなくなる場合、ノードで非アクティブなサービスを迅速に開始し、そのサービスの接続を作成できます。また、ワークロードの要請に基づいて、使用可能な容量を迅速に増減できます。
ノード上のサービスが起動されると、関連付けられているデータ・ソースはサービスが現在アクティブであることを検出します。データ・ソースは必要に応じて、そのサービスへの接続を確立し始めます。特定のノード上のサービスを停止した場合、関連付けられているデータ・ソースはそのノードへの接続を確立できなくなり、そのノード上でサービスが再起動されるまで、データ・ソースは非アクティブになります。
WLSデータ・ソースでは、接続のテストを行います。これにより、データベースがOracle RAC構成のトポロジの変更によって調整できます。データ・ソースは、ポーリングを行って、関連付けられたサービスがアクティブか非アクティブであるかを判断します。Oracle RACノード上でサービスが使用できない場合、接続テストに失敗します。
この例では、サービス1はOracle RACノードの1、2および3でアクティブで、サービス2は同じノード上で非アクティブです。サービス2は、Oracle RACノードの4および5でアクティブで、サービス1は、同じノード上で非アクティブです。
Oracle RACノード1は、なんらかの理由で使用不可になる場合、サービス1をOracle RACノード4上で開始できます。WebLogic Serverはサービスがノード4上で実行されていることを検出し、必要に応じて関連付けられたバックアップ・データ・ソースからの接続をノード4に作成し始めます。
ロード・バランシング構成では、各Oracle RACノード上で同時に複数のサービスが実行しています。各WLSマルチ・データ・ソースには、各ノードの指定したサービスに接続するために構成する1つのアクティブな接続プールがあります。このシナリオでは、ロード・バランシング・アルゴリズムを使用してマルチ・データ・ソースを構成する必要があります。
この例では、サービス1およびサービス2はそれぞれ使用可能なすべてのOracle RACノード上でアクティブに実行されています。その結果、各マルチ・データ・ソースのすべての接続プールは、5つのノード間のワークロードのバランスを取って、アクティブにラウンド・ロビン方式で接続を作成します。
特に注意すべき点は、データ・ソースに対して指定した最大容量の値によっては、特定のOracle RACノードの接続容量を超える可能性があることです。各データ・ソースに対してこの値を設定する方法を決定するときに、次の要素を考慮する必要があります。
Oracle RACでサポートできる最大同時接続数。これは、特定のOracle RACノードでの使用可能なメモリーおよび各サービス接続が消費するメモリー量(サービスごとに異なります)に基づきます。各接続によるメモリー消費は、WLSサーバーから生成される作業の量を制限する主要素です。WLSデータ・ソースから特定のOracle RACノードへの接続をあまりに多く作成して使用可能なメモリー量を超えると、Oracle RACノード上のパフォーマンスが低下するかまたは接続が失敗する可能性があります。
1つのノードで使用可能なメモリー量は(セッション・メモリーごとの) PGAターゲット属性に基づく必要があります。
特定のOracle RACノードへの接続を作成できるデータ・ソースの最大数、および単一データ・ソースまたはマルチ・データ・ソースがターゲットとするWebLogicサーバーのインスタンス数。たとえば、1つのデータ・ソースが3つのWLSサーバーをターゲットとする場合、各サーバーはそれぞれデータ・ソースの固有のインスタンスを使用するため、データ・ソースの個数が3になります。これは、サーバーがクラスタの一部である場合または独立したサーバー・インスタンスである場合も同じです。
特定のOracle RACノードでアクティブに実行しているサービスの最大数および各サービスへの各接続によってノード上で使用されるメモリー。
特定のノード上の各サービスごとに予想される相対的なワークロード。たとえば、サービス1で予想されるワークロードがサービス2で予想されるワークロードの2倍になる場合もあります。
サービスがノード上で常にアクティブになるかどうかにかかわらず、そのノードでサービスを起動する必要がある場合に備えて、そのサービス用のリソースを割り当てる必要があります。
データ・ソースの最大容量の値を設定するときは、常に最悪のケースのシナリオを使用します。たとえば、すべての使用可能なサービスが各データ・ソースに関連付けられたOracle RACノード上でアクティブに実行していると想定します。
次の例では、各データ・ソースの最大容量の値を決定する方法について説明します。これは、問題を概念的に説明するための簡単な例であり、現実の状況ははるかに複雑であることに注意してください。一般的に、一番良い方法は、データ・ソースの最大容量の値を低めに設定し、Oracle RACノードのメモリー使用量およびパフォーマンスを監視して、関連付けられたOracle RACノードの最大容量に達成するまで最大容量の値を増やすことです。
例
以下のような基本の構成があると仮定します。
Oracle RACノードが5つで、各ノードはメモリーが16GBです。
2つのサービスは、各Oracle RACノード上でアクティブに実行しています。サービス1は、接続当たり10MBのメモリーを使用し、サービス2は接続当たり20MBのメモリーを使用します。
各サービスのワークロードは同じです。つまり、各サービスは、指定したOracle RACノード上に同じ接続数を生成します。
2つのWebLogic Serverクラスタ。クラスタ1には5つのサーバーがあります。クラスタ2には4つのサーバーがあります。
指定したOracle RACノードにおいて、1つのデータ・ソースはクラスタ1をターゲットとし、サービス1に接続するように構成されています。
指定したOracle RACノードにおいて、1つのデータ・ソースはクラスタ2をターゲットとし、サービス2に接続するように構成されています。
サービス2は1接続あたりでサービス1の2倍のメモリーを使用するため、サービス2にはノードのメモリーを約10GB、サービス1には約5GBを割り当てる必要があります。
クラスタ1では、5つのWLSサーバーがあるので、このOracle RACノードに接続リクエストを作成するデータ・ソースが5つあります。これにより、指定したデータ・ソースからの接続に対して1GBのメモリーが使用可能になります(5GB/5)。各接続に対して10MBのメモリーが必要であるため、クラスタ1をターゲットとする各データ・ソースの最大容量値が100以下である必要があります。
クラスタ2では4つのWLSサーバーがあるため、このOracle RACノードに接続リクエストを作成するデータ・ソースが4つあります。これにより、指定したデータ・ソースからの接続に対して2.5GBのメモリーが使用可能になります(10GB/4)。各接続に対して20MBのメモリーが必要であるため、クラスタ2をターゲットとする各データ・ソースの最大容量値が125以下である必要があります。
サービス2がサービス1より多くのワークロードを生む場合は、これらの値を適切に調整する必要があります(サービス2に接続しているデータ・ソースの最大容量の値を増やして、サービス1に接続しているデータ・ソースの値を減らします)。次である間は:
(サービス1への最大接続数x 1つの接続で使用されるメモリー) + (サービス2への最大接続数x 1つの接続で使用されるメモリー) <使用可能なメモリー
パフォーマンス低下や接続障害の可能性を回避することができます。
または、図B-6で示すような単純な構成では、各データ・ソースに指定する「最大容量」値を次の式で大まかに決定することができます。
Maximum connection pool capacity = Maximum number of connections to Oracle RAC nodes/(Number of WebLogic Server instances x Nmber of data sources targeted to each instance x Number of active Oracle RAC services configured x Number of Oracle RAC Nodes)
説明:
Oracle RACノードへの最大接続数は、すべてのノード上の使用可能なメモリーの合計を、各接続が消費するメモリーで除算することによって決まります。
WebLogic Serverインスタンス数は、データ・ソースがターゲットとするサーバー・インスタンスの数です。データ・ソースがWLSクラスタをターゲットとする場合は、クラスタ内のサーバーの数になります。
図B-6の例では:
Oracle RACノード当たりの使用可能なメモリーが8GB、1接続当たりの消費メモリーが10MBであることに基づき、Oracle RACノードのグループに作成できる接続の合計数を最大4000個と想定します。
データ・ソースがターゲットとするサーバー・インスタンスは合計で5つです。
各サーバー・インスタンスをターゲットとするデータ・ソースは5つです。
各Oracle RACノードで2つのサービスが実行されます。
Oracle RACノードは5つです。
この構成では、各データ・ソースに対して入力する最大容量の値は次のようになります。
Maximum connection pool capacity = 4000/(5 server instances x 5 data sources x 2 services x 5 Oracle RAC nodes)
したがって、各データ・ソースの最大容量の値は16になります。
この式はデータ・ソースの構成に関する一般的なガイドラインにすぎないことに留意してください。多くの構成は非常に複雑なため、このような単純な計算は使えません。
使用する必要がある最大容量の値を計算する際は、常に構成全体での最悪のケースのシナリオを考慮する必要があります。最悪の状況が発生したときのために大きすぎる値を設定するよりも、通常のオペレーションのために低めの値を設定するのが良い方法です。常にOracle RACノードを監視して、データ・ソースの最大容量値を増やしても安全かどうかを決定することができます。
マルチ・データ・ソースをアプリケーションで使用できない場合は、接続時フェイルオーバーおよびロード・バランシングを使用するようデータ・ソースを構成できます。接続時フェイルオーバーとロード・バランシングを行うように構成されたデータ・ソースを使用して、WebLogic Serverと複数のOracle RACノードを接続するには、後述するように、Oracle RACクラスタ内の各Oracle RACインスタンスにOracle Thin DriverとともにJDBCデータ・ソースを構成します。図B-7にシステムの概要を示します。
図B-7 Oracle Thin Driverの接続時フェイルオーバーを使用したデータ・ソースの構成
ドメインを構成するには、管理コンソールか、または、WebLogic Scripting Tool (WLST)やJMXプログラムなどのお好きな方法を使用できます。
データ・ソースに接続が作成されると、Oracle Thin Driverによって使用するOracle RACインスタンスが決定されます。アプリケーションは接続を取得すると、JNDIツリーでデータ・ソースをルックアップして、データ・ソースからの接続をリクエストします。データ・ソースは、データ・ソース内の接続のプールから使用可能な接続を1つ選んで提供します。
次の項では、構成のオプションと要件について説明します。
次の項では、Oracle RACの接続時フェイルオーバー機能を使用して接続の障害に対処する構成について説明します。この構成では、障害のケースによって、フェイルオーバーにかかる時間がTCPタイムアウトと同じ長さになる場合もあります。これは環境により数分間に及ぶ場合があります。
この構成を使用するには、以下の属性でWebLogicドメインにJDBCデータ・ソースを作成します。
接続時フェイルオーバーを行うように構成されたOracle Thin JDBC Driver 11g。例:
<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"
接続に対するアプリケーション・リクエストが、接続が利用できるまで120秒間待機できるようにします。
TestConnectionsOnReserve="true"
アプリケーションがデータ・ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。
別のOracle RACノードのフェイルオーバーを有効にする必要があります。
TestTableName="name_of_small_table"。物理データベース接続のテストに使用される表の名前です。この属性の詳細は、「データ・ソースの接続テスト・オプション」を参照してください。
以下にサンプル構成コードを示します。
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/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>
|
注意: 読みやすくするために改行が追加されています。 |
WebLogic Serverでは、アプリケーションに依存せずにOracle RACイベント通知を実装するOracle機能である、高速接続フェイルオーバーがサポートされており、無効な接続の検知とクリーン・アップ、使用可能な接続のロード・バランシング、アクティブなOracle RACインスタンスへの作業の再配布などが可能です。
詳細は、『Oracle® Database JDBC Developer's Guide and Reference』のFast Connection Failover(http://download-east.oracle.com/docs/cd/B19306_01/java.102/b14355/fstconfo.htm#CIHJBFFC)を参照してください。
データ・ソースでの高速接続フェイルオーバーを有効にするには、以下の接続プール・プロパティを設定します。
ドライバ・クラス名 - クラス名をoracle.jdbc.pool.OracleDataSourceに設定します。
プロパティ - ONS構成文字列を設定し、リモートでOracle RACノードをOracle FAN/ONSイベントにサブスクライブするようにします。例: ONSConfiguration=nodes=hostname1:port1,hostname2:port2
|
注意: OracleのOracleDataSourceクラスはXA対応ではないため、設定後のデータ・ソースにXA接続プールは実装されません。 |
OracleドライバはONSを使用して高速接続フェイルオーバーを実装するため、WebLogicクラス・パスにons.jarを追加する必要があります。それには、ドメインのbinディレクトリにあるsetDomainEnvスクリプトを編集して、POST_CLASSPATH変数にons.jarを追加します。
Oracle RACでXA (グローバル・トランザクション)を使用する際は、以下の要件および制限を考慮する必要があります。
XAを使用する場合には、Oracle RACが以下の要件を満たしている必要があります。
グローバル・トランザクションはOracle RACクラスタの同じインスタンスで開始、作成および終了する必要があります。WebLogicサーバーでは、JDBCデータ・ソースの構成でKeepXAConnTillTxComplete="true"と設定した場合、そのようにできます。
|
注意: 11.1より前のデータベースの場合、WebLogic Serverでは、Oracle RACを使用できるようにするため、Oracle Thin Driverの接続時フェイルオーバー機能を使用しています。OracleのTechnical Note 235118.1で説明されているように、Oracle Thin Driverでロード・バランシングを構成した場合、トランザクションの開始と終了が同じOracle RACインスタンスで行われるかどうかは保証されません。Oracle RACでは、グローバル・トランザクション内のすべてのデータベース操作が同じOracleインスタンスにルーティングされる必要があり、この既知の制限があることで、Oracle RACでXAを使用する場合、接続時ロード・バランシングは使用できないことになります。結果として、プライマリ/プライマリのOracle RAC構成は使用できません。このリリースのWebLogic Serverでは、WebLogic Server用の高可用性データベースとしてOracle RAC 11gがサポートされています。ただし、ロード・バランシングを使用したXAをサポートするOracle RAC 11gで新たに追加されたOracleサービス機能はサポートされません。そのかわりとしてWebLogic Serverでは、引き続きマルチ・データ・ソースを使用した実績のある統合アーキテクチャを使用してロード・バランシングを使用したXAをサポートします。 |
グローバル・トランザクションを利用する場合は、トランザクションID (XID)がOracle RACクラスタ内で一意である必要があります。しかし、Oracle ThinドライバやOracle RACインスタンスでは、Oracle RACクラスタ内でXIDが一意であるかどうかを識別できません。同じXIDのトランザクションが複数存在すると、SQLコードがOracle RACクラスタの別々のインスタンスで実行されるおそれがあり、その場合でも例外はスローされません。
WebLogic Serverトランザクション・マネージャは、一意のトランザクションIDを生成します。ただし、一部のフェイルオーバー・シナリオでは、トランザクションは、元のインスタンス以外のOracle RACインスタンス上で続行されます。そのため、データ不整合の問題が発生する可能性があります。「障害の状況により不整合なトランザクションの完了(データ損失)が生じる可能性」を参照してください。
次の項では、Oracle RACとともにXAおよびWebLogic Serverを使用する場合の既知の問題や制限について説明します。
|
注意: これらの制限事項の一部は、Oracleバグ番号3428146および395790でも説明されています。これらの問題の詳細は、Oracleにお問い合せください。 |
障害の状況によっては、マルチ・データ・ソースが使用されていない場合、トランザクションが開始されたインスタンス以外のOracle RACインスタンスで発生したトランザクション処理(データ変更)が通知や例外のスローがないまま失われることがあります。
たとえば、次のようなWebLogic Server構成を考えます。
WebLogicクラスタに2つのサーバー(server1とserver2)があります。
JDBCデータ・ソースds1がこのクラスタに割り当てられています(このデータ・ソースと同一のインスタンスが、クラスタ内のすべてのインスタンス上に存在します)。
JDBCデータ・ソースds1がOracle RACクラスタに接続するように構成されていて、接続時フェイルオーバーが有効になっています。RAC1がプライマリOracle RACインスタンスとして、RAC2がセカンダリOracle RACインスタンスとして設定されています。データ・ソースds1がこのクラスタに割り当てられています(このデータ・ソースと同一のインスタンスが、WebLogicクラスタ内のすべてのノード上に存在します)。
次のシナリオでは、データ変更が失われます。
server2とRAC1のネットワーク接続が切断されます。これにより、server2のcp1でのデータベース接続がRAC2にフェイルオーバーします。server1の同じデータ・ソースは、RAC1への接続を維持しています。
server1でアプリケーションがトランザクションを開始し、cp1からのデータベース接続(RAC1への接続)を使用してデータを変更します。
アプリケーションがserver2のEJBを呼び出し、server2のcp1からのデータベース接続(RAC2への接続)を使用してデータを変更します。
アプリケーションがserver1のトランザクションを完了します。
結果: RAC1上のデータ変更はコミットされます。RAC2上のデータ変更は無視されます。WebLogic Serverトランザクション・マネージャは、リソースに対して準備とコミットをコールします。この場合、複数のデータ・ソースが同じ名前であるため、同じリソースと見なされ、データ・ソースの1つのインスタンスのみに対してコールが作成されます。データ・ソースには、異なるOracle RACインスタンスへの接続が含まれているため、データ変更が1つのOracle RACインスタンス上でコミットされますが、もう1つのOracle RACインスタンス上の変更は失われます。
回避策 :ネットワーク障害を回避するため、WebLogic ServerインスタンスとOracle RACインスタンスの間に冗長なネットワーク・ハードウェアを供給します。
Oracle RACクラスタ全体でトランザクションIDが利用できなくなる時間帯があります。これは既知の制限が原因で、障害発生時に一部の未完了トランザクションが正常に完了できない場合があり、結果としてデータベースでデッドロックが発生するおそれがあります。このような障害が発生することを防ぐために、WebLogic ServerにはOracle RACに対するXA呼出しの再試行を有効にする2つの構成属性、XARetryDurationSecondsとXARetryIntervalSecondsが用意されています。これらの構成オプションの詳細は、「フェイルオーバー中の遅延」を参照してください。
Oracle DataBase Controlを使用した場合、トランザクション処理の順番は保証されません。たとえば、DataBase Controlを使って、次のトランザクション・シーケンスを実行するWebサービスを実装する場合を考えます。
表を作成
レコード1を挿入
レコード2を挿入
レコード3を挿入
レコードを選択
表を作成した後でプライマリ・ノードが一時的に停止すると、データベースに送信されたトランザクションが、順序どおりに実行されない可能性があります。
JDBCストアとOracle RACを併用している場合、Oracle RACノードのフェイルオーバーに関して考慮する必要のある機能と制限があります。次の項を参照してください。
JDBCストアを使用する主なサービスのリストについては、『Oracle WebLogic Serverサーバー環境の構成』のストア接続の監視に関する項を参照してください。
JDBCストアの仕様により、Oracle RACと併用するための構成の選択肢は限られています。JDBCストアは、グローバル・トランザクションをサポートするように構成されたJDBCデータ・ソースを使用するように構成することはできません。JDBCストアは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があります。この構成オプションの詳細は、「グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用」を参照してください。
JDBCストアは、1つの接続が失敗するまでその接続を保持し、失敗した時点で次の接続に移って、プロセスを繰り返します。したがって、JDBCストアでは、ロード・バランシング・マルチ・データ・ソースを使用することを含めて、ロード・バランシングを実装することができません。フェイルオーバー・アルゴリズムを使用するには、JDBCストアに対してマルチ・データ・ソースを構成する必要があります。
要するに、JDBCストアの場合は:
非XAドライバを使用します
マルチ・データ・ソースをフェイルオーバー・モードで構成します
JMSには、制限された接続再試行メカニズムがあり、これらのメカニズムを使用すると、そのデータベース接続を持つOracle RACノードで発生する障害に対して、サイレントに対応できます。データベースに対してネットワークが一時中断するかまたはOracle RACデータベースが別のノードにフェイルオーバーした場合、第2の接続の試行(再試行)が次のOracle RACノードを継承します。
接続再試行時間の拡張による負の効果を最小化するために、再試行時間および再試回数は制限されています。データベース接続が長時間にわたり使用不可能な場合、遅延によって、JMSが処理を適切に続行する(たとえば、メッセージの正しい順序を保持する)機能が妨害されるおそれがあります。また、この時間内に、処理が十分に進行しない場合、トランザクション・マネージャによってトランザクションのJMSリソースが失効を宣言されるか、メモリー不足が発生する可能性があります。自動再試行が成功するために重要なOracle 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番目の試行で障害が発生すると、例外がコール・スタックに伝播されます。この場合、失敗したトランザクションに関連するメッセージを回復するには手動での再起動が必要になります。
|
注意: 自動再試行が成功しない場合は、WebLogic Serverを再起動する必要があります。 |
