| Oracle® Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55546-01 |
|
 戻る |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55546-01 |
|
戻る |
バックエンド システムのスケーラビリティや可用性をより高めるソリューションがますます求められています。こうした要求に応え、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 では次の領域の機能が提供されます。
スケーラビリティ
可用性
ロード バランシング
フェイルオーバ
インストールされている Oracle RAC は、単一の標準的なオラクル データベースのように見え、同じツールと慣行を使用して管理されます。クラスタのすべてのノードで同じデータベースに対してトランザクションを実行すると、RAC により各ノードから共有データへのアクセスが調整されて一貫性が維持され、整合性が確保されます。クラスタにはノードを簡単に追加でき、追加時にデータを分割する必要もありません。つまり、RAC ノード、ストレージ、またはその両方を追加することで、処理と要求の増加に伴い、データベース層を水平方向に拡張できます。その後、新しいノードにマップされるデータ ソースを追加することにより、WebLogic Server を拡張できます。
RAC ノードまたはインスタンスに障害が発生した場合には、指定したコンフィグレーションに応じて、WebLogic Server または Oracle Thin Driver により、セッション要求がクラスタ内の別のノードにリダイレクトされます。WebLogic Server では、Oracle RAC はデータベース接続のフェイルオーバを提供しません。データベースがトランザクション マネージャである場合、進行中のトランザクションは通常、ロールバックされます。WebLogic Server がトランザクション マネージャである場合は、進行中のトランザクションは、完了またはロールバックする必要があるという観点から、障害発生時のトランザクションの状態に基づいてフェイルオーバされます。
アプリケーションで RAC ノード間のロード バランシングが必要な場合には、JDBC マルチ データ ソースを Oracle RAC ノードと併用して実現する方法がサポートされています (マルチ データ ソースはデータ ソースのグループを抽象化したものであり、接続リクエストの際に、マルチ データ ソースと関連付けられたデータ ソース間のロード バランシングまたはフェイルオーバ処理を提供します)。マルチ データ ソースを形成するデータ ソースは、ラウンドロビン方式でアクセスされます。接続を切り替えるとき、WebLogic Server はリストの順序で次のデータ ソースから接続を選択します。マルチ データ ソースと Oracle RAC の併用の詳細については、「Oracle RAC でのマルチ データ ソースの使用」を参照してください。
Oracle Database 10g (10.2) 以前での Oracle RAC デプロイメントの場合は、マルチ データ ソースを使用する場合にのみ XA がサポートされます。そのため、XA のロード バランシングは、マルチ データ ソースを使用する場合にのみサポートされます。マルチ データ ソースを使用しないコンフィグレーションでは、Oracle Thin Driver で提供される接続時フェイルオーバ機能を使用して、Oracle RAC と連携します。Oracle の Technical Note 235118.1 で説明されているように、Oracle Thin Driver でロード バランシングをコンフィグレーションした場合、トランザクションの開始と終了が同じ Oracle RAC インスタンスで行われるかどうかは保証されません。Oracle RAC では、グローバル トランザクション内のすべてのデータベース操作が同じ Oracle インスタンスにルーティングされる必要があるため、この確認済みの制限があることで、XA と Oracle RAC を併用する場合にドライバ レベルのロード バランシングは使用できないことになります。結果として、プライマリ/プライマリの RAC コンフィグレーションは使用できません。
Oracle Database 11g (11.1) では、WebLogic Server 用の高可用性データベース ソリューションとして Oracle 11g RAC がサポートされています。ただし、このリリースでは、WebLogic Server は、ロード バランシングを使用した XA をサポートする Oracle 11g RAC の新機能はサポートしていません。その代わりとして WebLogic Server では、引き続きマルチ データ ソースを使った実績のある統合アーキテクチャを使用してロード バランシングを使用した XA をサポートします。
Oracle RAC は JDBC 接続時フェイルオーバ機能を提供していますが、大半のコンフィグレーションでは、これではなく WebLogic JDBC マルチ データ ソースを使用してフェイルオーバを処理することをお勧めします。接続時フェイルオーバには、代替 RAC ノードへの接続をあらかじめ作成する機能はありませんが、マルチ データ ソースでは、常に複数の接続をフェイルオーバの処理に利用できます。詳細については、「Oracle RAC でのマルチ データ ソースの使用」を参照してください。
|
注意 : Transparent Application Failover (TAF) は WLS データ ソースではサポートされていません。TAF は現在、JDBC を通じて提供されるため、透過的ではありません。予測不能かつ回復不可能な状態で、進行中の一部のクエリ結果と PreparedStatement に影響を与えることが明らかになっています。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 Fusion Middleware Oracle WebLogic Server クラスタの使い方』を参照してください。
Oracle RAC に関する最新のハードウェア要件については、Oracle RAC のドキュメントを参照してください。ただし、WebLogic Server で Oracle RAC を使用するには、堅牢なプロダクション レベルのハードウェア上で Oracle RAC インスタンスを実行する必要があります。Oracle RAC のコンフィグレーションでは、アプリケーションの負荷要件を適切に予想し、それに見合ったデータベース処理性能を実現する必要があります。データベースの応答が著しく遅れると、データベースのフェイルオーバ処理の間に予期しない動作が生じるおそれがあります。
WebLogic Server を Oracle RAC と共に使用するには、各 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 をインストールしてコンフィグレーションしたら、これ以降の節で説明するように各 RAC インスタンスに対してリスナ プロセスをコンフィグレーションする必要があります。Oracle RAC ノードに対して、オペレーティング システムおよび Oracle ソフトウェアをインストールおよびコンフィグレーションする方法については、Oracle のドキュメントを参照してください。
リスナ プロセスは、Oracle RAC に、ユーザ プロセスと Oracle インスタンス間で通信経路を確立します。WebLogic Server で Oracle RAC を使用する場合、ユーザ プロセスは通常、JDBC データ ソースです。
データ ソースは作成されると、アプリケーションが使用するデータベース接続のプールを作成しようとします。プールされたデータベース接続が操作できなくなったり、データ ソース容量が増えるようにコンフィグレーションされている場合、データ ソースは、コンフィグレーション ファイルに指定されている最大値になるまで、データベース接続を追加作成しようとします。こうしたすべてのケースにおいて、Oracle リスナ プロセスは Oracle RAC インスタンスに対する接続リクエストを処理します。
図 B-2 に Oracle リスナ プロセスの機能を示します。
この機能を有効にするには、2 つのオプションがあります。
ローカル リスナを使用する。Oracle クラスタ内の各 RAC インスタンスごとにリスナ プロセスをコンフィグレーションします。各 RAC インスタンスについてローカル リスナのコンフィグレーションが必要です。各データベース インスタンスは、そのローカル リスナのみ登録するようにコンフィグレーションする必要があります。
Oracle インスタンスのリスナ登録は、listener.ora ファイルで静的にコンフィグレーションしたり、インスタンスの初期化パラメータ local_listener を使用して動的に登録できます (両方で登録可能)。動的に登録することをお勧めします。
リスナは、共有ディスパッチ プロセスまたは専用プロセスのいずれかを起動できます。WebLogic Server を使用する場合、専用プロセスの使用をお勧めします。
リモート リスナを使用する。WLS では、マルチ データ ソース内のデータ ソースの JDBC URL で SERVICE_NAME と INSTANCE_NAME の両方を指定する必要があります。「リモート リスナが有効または無効になっている場合のマルチ データ ソースのコンフィグレーション」を参照してください。
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 を指定できない場合は、リモート リスナを無効にする必要があります。リモート リスナを無効化するには、各 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 を使用する場合、RAC インスタンスと対話でき、期待通りに動作するように WebLogic ドメインをコンフィグレーションする必要があります。以下の節では、コンフィグレーションのオプションと要件について説明します。
WebLogic Server では、Oracle RAC を使用するための数種類のコンフィグレーション オプションがサポートされています。
グローバル トランザクション (XA) の使用時に、複数の Oracle 10g RAC または Oracle 11g RAC インスタンスに接続するには、トランザクション対応の WebLogic JDBC マルチ データ ソース (フェイルオーバとロード バランシングをサポート) を使用して RAC ノードに接続することをお勧めします。詳細については、「グローバル トランザクションを利用する場合のマルチ データ ソースの使用」を参照してください。
XA を使用していない場合に、複数の Oracle 10g RAC または Oracle 11g RAC インスタンスに接続するには、(非トランザクション対応の) マルチ データ ソースを使用して RAC ノードに接続することをお勧めします。フェイルオーバとロード バランシングをサポートする、標準的なマルチ データ ソース コンフィグレーションを使用してください。詳細については、「グローバル トランザクションを利用しない場合のマルチ データ ソースの使用」を参照してください。
マルチ データ ソースの使用を選択できず XA も使用していない場合に、複数の Oracle RAC ノードに接続するには、Oracle 10g RAC または Oracle 11g RAC を接続時フェイルオーバ機能と共に使用します。ロード バランシングは、このコンフィグレーションではサポートされていません。詳細については、「グローバル トランザクションを利用しない場合の接続時フェイルオーバの使用」を参照してください。
以下の表を、特定のアプリケーションに適したコンフィグレーションを判断する際の指標としてご利用ください。
表 B-1 Oracle RAC と併用するためのコンフィグレーションの選択
| ロード バランシングは必要 ? | フェイルオーバは必要 ? | グローバル トランザクション (XA) は必要 ? | JDBC ストアは必要 ? | RAC サービスは必要 ? | 参照先 |
|---|---|---|---|---|---|
|
はい |
はい |
はい |
いいえ |
いいえ |
グローバル トランザクションを利用する場合のマルチ データ ソースの使用 |
|
はい |
はい |
いいえ |
はい |
いいえ |
グローバル トランザクションを利用しない場合のマルチ データ ソースの使用 |
|
はい |
はい |
はい |
はい |
はい |
|
|
いいえ |
はい |
いいえ |
はい |
はい |
グローバル トランザクションを利用しない場合の接続時フェイルオーバの使用 |
RAC ノード上で実行されている特定のサービスに接続するようにデータ ソースをコンフィグレーションすることもできます。このコンフィグレーションでは、マルチ データ ソースが必要です。ロード バランシングとフェイルオーバの両方がサポートされています。XA および非 XA の両方とも提供されます。詳細については、「RAC ノード上のサービスへの接続のコンフィグレーション」を参照してください。
WebLogic Server を Oracle RAC と共に使用するには、WebLogic JDBC データ ソースで Oracle JDBC Thin Driver 11g を使用して、データベース接続を作成する必要があります。
フェイルオーバをコンフィグレーションする際には、次の情報について考慮する必要があります。
マルチ データ ソースはグローバル トランザクションに対してフェイルオーバとロード バランシングを提供します。この場合、接続時フェイルオーバを使用したデータ ソース コンフィグレーションに関わる制限や確認済みの問題は生じません。マルチ データ ソースのフェイルオーバ機能の説明については、「マルチ データ ソース フェイルオーバ機能の拡張」を参照してください。
図 B-3 に示すこのコンフィグレーションを使用すると、以下の利点があります。
マルチ データ ソース制御による、より高速なフェイルオーバ
WebLogic Server ヘルス モニタによる、自動フェイルバック
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://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 がすべての RAC ノードで利用可能になるまでの遅延時間、通常 5 分未満)
たとえば、アプリケーションで設定されている最長のトランザクション タイムアウトが 180 秒の場合には、XARetryDurationSeconds を 180 秒 + 300 秒の合計、つまり 480 秒に設定します。
|
注意 : 一般に XARetryDurationSeconds は、すべてのトランザクションが適切に完了するように、必要とされる最小限の時間よりも長めに設定した方がよいでしょう。最小限必要な時間より大きな値を設定しても、通常の運用時であればアプリケーションのパフォーマンスには影響しません。この追加された処理は、準備状態にあるが完了に失敗したトランザクションにのみ影響します。 |
必要に応じて、XARetryIntervalSeconds にも値を設定できます。この値は、XA 呼び出しの再試行の間隔を決定します。デフォルトでは、この値は 60 秒です。値を小さくすると、XA の再試行の間隔が短くなります。ほとんどの場合は、デフォルト値で十分です。
Administration Console から XARetryDurationSeconds および XARetryIntervalSeconds を有効化するには、次の手順を使用します。
まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします。
[ドメイン構造] ツリーで [サービス｜JDBC] を展開し、[データ ソース] を選択します。
[JDBC データ ソースの概要] ページでデータ ソース名をクリックします。
[コンフィグレーション : 接続プール] タブを選択します。
画面下方向にスクロールし、[詳細] をクリックして詳細な接続プール オプションを表示します。
[XA 再試行期間] および [XA 再試行間隔] を更新します。
[保存] をクリックします。
必要に応じて、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 マルチ データ ソースのコンフィグレーション」を参照してください。マルチ データ ソース内のデータ ソースを、RAC ノード上で実行されるサービスに接続するようにコンフィグレーションする方法については、「RAC ノード上のサービスへの接続のコンフィグレーション」を参照してください。
このコンフィグレーションでデータベース接続を使用するには、アプリケーションで JNDI ツリー上のマルチ データ ソースを 1 つルックアップしてから、接続を要求します。マルチ データ ソースは、コンフィグレーションで指定されたアルゴリズムの種類に基づいて、接続リクエストに応じるためにどちらのデータ ソース (つまり、フェイルオーバまたはロード バランシング) を使用するかを決定します。
マルチ データ ソースには、使用するシステムでの RAC の役割 (ロード バランシングまたはフェイルオーバ) によって、次の属性のいずれかを指定できます。
AlgorithmType="Load-Balancing" または AlgorithmType="Failover"
Load-Balancing を指定すると、接続リクエストは利用可能なデータ ソース群に渡って分散されます。High-Availability を指定した場合、接続リクエストはリストの最初にある利用可能なプールで処理されます。データ ソースが切断された場合、接続リクエストはリスト内の次のデータ ソースで処理されます。
FailoverRequestIfBusy="true"
フェイルオーバ アルゴリズムと共にこの属性を指定すると、データ ソース内の接続がすべて使用中の場合にフェイルオーバできるようになります。
TestFrequencySeconds="120"
この属性は、WebLogic Server が以前に異常としてマークされたデータ ソースの状態をチェックして、接続を再作成できるかどうか、およびデータ ソースを再有効化できるかどうかを確認する頻度を制御します。詳細については、「 JDBC マルチ データ ソースのコンフィグレーション」を参照してください。
RAC ノードの高速フェイルオーバの場合は、この値を 10 (秒) のような短い間隔に設定します。
|
注意 : リリース 11.1 では、WebLogic Server 用の高可用性データベースとして Oracle 11g RAC がサポートされています。ただし、ロード バランシングを使用した XA をサポートする Oracle 11g RAC で新たに追加された Oracle サービス機能はサポートされません。その代わりとして WebLogic Server では、引き続きマルチ データ ソースを使った実績のある統合アーキテクチャを使用してロード バランシングを使用した XA をサポートします。 |
このコンフィグレーションでは、マルチ データ ソースによってトランザクションが必ず 1 つの Oracle RAC インスタンスに「固定」されます。個々のトランザクションはトランザクションに対する最初の接続要求時にロード バランシングされます。RAC インスタンスが使用できなくなった場合には、マルチ データ ソース レベルでフェイルオーバが処理されます。PREPARE 操作の前に、RAC インスタンスに障害があった場合、再試行の期間が時間切れになるまでこの操作が再試行されます。PREPARE 操作の後に障害があった場合は、トランザクションは別のインスタンスにフェイルオーバされます。
マルチ データ ソース内の XA データ ソースには、以下のルールが適用されます。
すべてのデータ ソースが均一である必要がある。つまり、すべてのデータ ソースが XA ドライバを使用することが必要であるか、または XA ドライバを使用できるデータ ソースはありません。
すべての XA 関連の属性について、指定する場合には、各データ ソースに同じ値を設定する必要がある。こうした属性には以下のものがあります。
XARetryDurationSeconds
SupportsLocalTransaction
KeepXAConnTillTxComplete
NeedTxCtxOnClose
XAEndOnlyOnce
NewXAConnForCommit
RollbackLocalTxUponConnClose
RecoverOnlyOnce
KeepLogicalConnOpenOnRelease
|
注意 : XA を利用しない場合にも 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"
アプリケーションがデータ ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細については、「予約時の接続テストによるフェイルオーバの有効化」を参照してください。
これは、別の 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"
アプリケーションがデータ ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細については、「予約時の接続テストによるフェイルオーバの有効化」を参照してください。
フェイルオーバ、およびマルチ データ ソース内での接続リクエストのルーティング (実質的には別の 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>
|
注意 : 読みやすくするために改行が追加されています。 |
RAC クラスタ内の Oracle サービスに負荷管理を依存する場合は、サービス ID (SID) を使用する代わりにマルチ データ ソースを使用して、それらのサービスに接続する必要があります。WebLogic Server のデータ ソースは特定の RAC ノード上の特定のサービスにのみ接続するようにコンフィグレーション可能であり、負荷管理とロード バランシングの両方を提供します。
通常、RAC サービスに接続するには、以下の手順が必要です。
接続する各サービスごとにマルチ データ ソースを作成する。
各マルチ データ ソース内では、サービスが各ノード上でアクティブに実行されるかどうかにかかわらず、サービスがコンフィグレーションされているクラスタ内の各 RAC ノードごとにデータ ソースを 1 つずつ作成する。
「サービスに接続するためのデータ ソースのコンフィグレーション」では、これらのデータ ソースをコンフィグレーションする際の特別な考慮事項について説明します。「サービス接続のコンフィグレーション」では、ロード バランシングまたは負荷管理に関するサンプル コンフィグレーションを示します。
Oracle RAC ノード上で実行されるサービスに接続するためのデータ ソースのコンフィグレーションは、他のデータ ソースのコンフィグレーションと同じ方法で (WLST、Administration Console、またはコンフィグレーション ウィザードを使用して) 行いますが、以下の例外があります。
initial-capacity="0"
この設定は、WLS の起動時に非アクティブなプールに関するプール作成エラーを防ぎ、ノード上のサービスに接続できない場合でも WLS がデータ ソースを作成できるようにします。このオプションを 0 に設定しない場合、データ ソースの作成が失敗して、サービスの正常な起動が失敗する可能性があります。
Administration Console では、データ ソースを作成した後で編集し、[初期容量] を 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)))"
Administration Console でコンフィグレーションする場合は、[データベース ドライバ] ドロップダウンから [Oracles's Driver (Thin) for RAC Service-Instance connections] を選択し、[サービス名] フィールドでサービスを指定します。
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)))"
Administration Console でコンフィグレーションする場合は、[データベース ドライバ] ドロップダウンから [Oracle's Driver (Thin XA) for RAC Service-Instance connections] を選択し、[サービス名] フィールドでサービスを指定します。
|
注意 : SERVICE_NAME は特定のマルチ データ ソース内のすべてのデータ ソースで同じにする必要があります。特定のマルチ データ ソース内では各データ ソースごとに異なるホスト名とポートを指定します。 |
接続プールの max-capacity (Administrat on Console では [最大容量]) を指定する場合は、コンフィグレーション内の各 RAC ノードの接続容量とすべてのデータ ソースからの接続の総数を考慮する必要があります。詳細については、「接続プールのキャパシティ プランニング」を参照してください。
適切なマルチ データ ソース アルゴリズムの選択
サービス接続のシナリオでは、マルチ データ ソースでロード バランシング アルゴリズムをコンフィグレーションすることをお勧めします。マルチ データ ソースでロード バランシング アルゴリズムをコンフィグレーションした場合、接続プールはラウンドロビン方式で使用されます。この場合は、関連付けられたサービスが現在アクティブになっているすべての RAC ノード間で、負荷がロードバランシングされます。
マルチ データ ソースでフェイルオーバ アルゴリズムをコンフィグレーションした場合は、接続の試行が何らかの理由 (たとえば、RAC ノードが使用できなくなった場合や、データ ソースで使用可能な接続がなくなった場合など) で失敗するまでは、1 番目のデータ ソースを使用して、関連付けられた RAC ノード上のサービスに接続します。失敗すると、2 番目のデータ ソースを使用して、関連付けられた RAC ノード上のサービスに接続します。この場合、1 番目のデータソースが接続している RAC ノードは、サービスが実行されている残りのノードよりも使用率が大きくなります。
以下の機能を提供するようにコンフィグレーションを設計できます。
負荷管理
ロード バランシング
これらのコンフィグレーションについて次の 2 つの節で説明します。
負荷管理のコンフィグレーションでは、各マルチ データ ソースは各 RAC ノード上の特定のサービス用にコンフィグレーションされたデータ ソースを 1 つずつ持っています。ここで、接続先のサービスが特定の RAC ノード上でアクティブと非アクティブのどちらの状態になっているかは関係ありません。そのおかげで、予期しないダウンタイムや定期的メンテナンスのために別のノードが使用できなくなった場合は、ノード上の非アクティブなサービスを素早く起動して、そのサービスへの接続を作成することができます。また、負荷の需要に基づいて、特定のサービスで使用可能な容量を素早く増やしたり減らしたりできます。
ノード上のサービスが起動されると、関連付けられているデータ ソースはサービスが現在アクティブであることを検出します。データ ソースは必要に応じて、そのサービスへの接続を確立し始めます。特定のノード上のサービスを停止した場合、関連付けられているデータ ソースはそのノードへの接続を確立できなくなり、そのノード上でサービスが再起動されるまで、データ ソースは非アクティブになります。
WLS データ ソースは接続テストを実行します。このため、データ ソースは RAC コンフィグレーションのトポロジの変化に適応することができます。データ ソースは、関連付けられたサービスがアクティブか非アクティブかを確認するためにポーリングを行います。サービスが RAC ノード上で使用できなくなった場合、接続テストは失敗します。
この例では、RAC ノード 1、2、および 3 では、サービス 1 がアクティブになっていて、サービス 2 が非アクティブになっています。RAC ノード 4 および 5 では、サービス 2 がアクティブになっていて、サービス 1 は非アクティブになっています。
RAC ノード 1 が何らかの理由で使用できなくなった場合は、RAC ノード 4 のサービス 1 を起動できます。WebLogic Server はノード 4 でこのサービスが実行されていることを検出し、必要に応じて、関連付けられたバックアップ データ ソースからノード 4 への接続を確立し始めます。
ロード バランシングのコンフィグレーションでは、各 RAC ノード上に現在実行されている複数のサービスがあります。各 WLS マルチ データ ソースには、各ノード上の特定のサービスに接続するようにコンフィグレーションされたアクティブな接続プールが 1 つずつあります。このシナリオでは、ロード バランシング アルゴリズムを使用するように各マルチ データ ソースをコンフィグレーションします。
この例では、使用可能なすべての RAC ノード上で、サービス 1 とサービス 2 がそれぞれアクティブに実行されています。その結果、各マルチ データ ソース内のすべての接続プールは、ラウンドロビン方式でアクティブに接続を確立し、5 つのノード間で負荷がバランシングされます。
データ ソースに指定する [最大容量] 値によって、特定の RAC ノードへの接続容量が超過する可能性があることに注意することが大切です。各データ ソースのこの値の設定方法を決定するときは、以下の要因を考慮する必要があります。
RAC ノードがサポートできる同時接続の最大数。これは、特定の RAC ノードで使用可能なメモリと、各サービス接続によって消費されるメモリ量 (サービスごとに変わる可能性がある) に基づきます。各接続によるメモリ消費は、WLS サーバから生成可能な作業の量に対する主要な制限となります。WLS データ ソースから特定の RAC ノードへの接続を多く作成しすぎて、使用可能なメモリ量を超過すると、RAC ノードでのパフォーマンスが低下したり、接続の失敗につながる可能性があります。
1 つのノードで使用可能なメモリ量は (セッション メモリごとの) PGA ターゲット属性に基づく必要があります。
特定の RAC ノードへの接続を潜在的に作成可能なデータ ソースの最大数と、各データ ソース/マルチ データ ソースを対象指定する WebLogic Server インスタンスの数。たとえば、3 つの WLS サーバに対象指定されている 1 つのデータ ソースがある場合、各サーバはそのデータ ソースの独自のインスタンスを使用するので、データ ソースは 3 つのデータ ソースとしてカウントされます。このことは、サービスがクラスタの一部であっても、独立したサーバ インスタンスであっても当てはまります。
特定の RAC ノード上でアクティブに実行できるサービスの最大数と、各サービスへの各接続によってノード上で消費されるメモリ。
特定のノード上の各サービスごとに予期される相対的な負荷。たとえば、サービス 1 で予期される負荷がサービス 2 で予期される負荷の 2 倍になる場合もあります。
サービスがノード上で常にアクティブになるかどうかにかかわらず、そのノードでサービスを起動する必要がある場合に備えて、そのサービス用のリソースを割り当てる必要があります。
データ ソースの [最大容量] 値を設定するときは、常に最悪のシナリオを使用する。たとえば、各データ ソースに関連付けられている RAC ノード上で使用可能なすべてのサービスがアクティブに実行される場合を想定します。
以下の例では、各データ ソースの [最大容量] 値を決定する方法について説明します。これは問題を概念的に示すことを目的とした非常に単純な例であり、実際の状況はより複雑になることに留意してください。一般に、最初はデータ ソースに低い [最大容量] 値を設定して、RAC ノードのメモリ使用率やパフォーマンスをモニタしてから、関連付けられた RAC ノードの最大容量に近づくまで、[最大容量] 値を調節して上げていくのがよいでしょう。
例
以下のような基本のコンフィグレーションがあると仮定します。
5 つの RAC ノード。各ノードに 16GB ずつのメモリ。
各 RAC ノード上でアクティブに実行される 2 つのサービス。サービス 1 は 1 接続あたり 10MB、サービス 2 は 1 接続あたり 20MB を使用する。
各サービスの負荷は同じ。つまり、各サービスは特定の RAC ノード上で同じ数の接続を生成する。
2 つの WebLogic Server クラスタ。クラスタ 1 には 5 つのサーバがある。クラスタ 2 には 4 つのサーバがある。
特定の RAC ノードで、1 つのデータ ソースがクラスタ 1 に対象指定されていて、サービス 1 に接続するようコンフィグレーションされている。
特定の RAC ノードで、1 つのデータ ソースがクラスタ 2 に対象指定されていて、サービス 2 に接続するようコンフィグレーションされている。
サービス 2 は 1 接続あたりでサービス 1 の 2 倍のメモリを使用するため、サービス 2 にはノードのメモリを約 10GB、サービス 1 には約 5GB を割り当てる必要があります。
クラスタ 1 には 5 つの WLS サーバがあるので、この RAC ノードへの接続要求を行うデータ ソースは 5 つあります。つまり、特定のデータ ソースからの接続に使用できるメモリは 1GB となります (5GB/5)。各接続は 10MB のメモリが必要なので、クラスタ 1 に対象指定された各データ ソースの [最大容量] 値は 100 以下にする必要があります。
クラスタ 2 には 4 つの WLS サーバがあるので、この RAC ノードへの接続要求を行うデータ ソースは 4 つあります。つまり、特定のデータ ソースからの接続に使用できるメモリは 2.5GB となります (10GB/4)。各接続は 20MB のメモリが必要なので、クラスタ 2 に対象指定された各データ ソースの [最大容量] 値は 125 以下にする必要があります。
サービス 2 がサービス 1 より多くの負荷を生成した場合は、これらの値を適切に調整する必要があります (サービス 2 に接続しているデータ ソースの [最大容量] 値を増やして、サービス 1 に接続しているデータ ソースの値を減らします)。以下のような状況を保つことで、
(サービス 1 への最大接続数 x 1 つの接続で使用されるメモリ) + (サービス 2 への最大接続数 x 1 つの接続で使用されるメモリ) < 使用可能なメモリ
パフォーマンス低下や接続障害の可能性を回避することができます。
または、図 B-6 で示すような単純なコンフィグレーションでは、各データ ソースに指定する [最大容量] 値を以下の公式で大まかに決定することができます。
接続プールの最大容量 = RAC ノードへの最大接続数/(WebLogic Server インスタンスの数 x 各インスタンスに対象指定されるデータ ソースの数 x コンフィグレーション済みのアクティブな RAC サービスの数 x RAC ノードの数)
各要素の説明は次のとおりです。
「RAC ノードへの最大接続数」を決定するには、すべてのノードで使用可能な合計のメモリ量を各接続で消費されるメモリ量で割ります。
「WebLogic Server インスタンスの数」は、データ ソースが対象指定されているサーバ インスタンスの数です。データ ソースが WLS クラスタに対象指定されている場合は、クラスタ内のサーバの数になります。
図 B-6 の例では、
各 RAC ノードで使用可能なメモリは 8GB、各接続で使用されるメモリは 10MB という数字に基づいて、この RAC ノードのグループに対しては、合計で最大 4000 の接続を確立できると仮定する。
データ ソースが対象指定されているサーバ インスタンスは合計で 5 つある。
各サーバ インスタンスに対象指定されているデータ ソースは 5 つある。
各 RAC ノード上で実行される 2 つのサービスがある。
5 つの RAC ノードがある。
このコンフィグレーションで、各データ ソースに対して入力する [最大容量] 値は次のようになります。
接続プールの最大容量 = 4000/(5 サーバ インスタンス x 5 データ ソース x 2 サービス x 5 RAC ノード)
したがって、各データ ソースの [最大容量] 値は 16 になります。
この公式はデータ ソースのコンフィグレーションに関する一般的なガイドラインに過ぎないことに留意してください。多くのコンフィグレーションは非常に複雑なため、このような単純な計算は使えません。
使用すべき [最大容量] 値を計算するときは、必ず、コンフィグレーション全体で予想される最悪のシナリオを考慮してください。この値は、最悪の状況が発生した場合に備えて大きい値をコンフィグレーションしておくよりも、通常の処理に合わせて小さい値をコンフィグレーションするのが適当です。RAC ノードを常に監視して、データ ソースの [最大容量] 値を増やしても安全かどうかを判断することができます。
マルチ データ ソースをアプリケーションで使用できない場合は、接続時フェイルオーバおよびロード バランシングを使用するようデータ ソースをコンフィグレーションできます。接続時フェイルオーバとロード バランシングを行うようにコンフィグレーションされたデータ ソースを使用して、WebLogic Server と複数の Oracle RAC ノードを接続するには、後述するように、RAC クラスタ内の各 RAC インスタンスに、Oracle Thin Driver と共に JDBC データ ソースをコンフィグレーションします。図 B-7 に、システムの概要を示します。
図 B-7 Oracle Thin Driver の接続時フェイルオーバを使用したデータ ソースのコンフィグレーション
Administration Console、または、普段ドメインをコンフィグレーションしている方法 (weblogic.Admin コマンドライン ユーティリティ、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"
アプリケーションがデータ ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細については、「予約時の接続テストによるフェイルオーバの有効化」を参照してください。
これは、別の 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 では、高速接続フェイルオーバがサポートされています。高速接続フェイルオーバとは、アプリケーションに依存せずに RAC イベント通知を実装するための Oracle 機能です。RAC イベント通知としては、無効な接続の検知とクリーンアップ、使用可能な接続のロード バランシング、アクティブな 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 コンフィグレーション文字列を設定し、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 が以下の要件を満たしている必要があります。
グローバル トランザクションは、RAC クラスタの同じインスタンスで開始、準備、終了する必要があります。これは、JDBC データ ソースのコンフィグレーションで KeepXAConnTillTxComplete="true" を設定すると、WebLogic Server のデータ ソースによって管理されます。
|
注意 : 11.1 より前のデータベースの場合、WebLogic Server では、Oracle RAC を使用できるようにするため、Oracle Thin Driver の接続時フェイルオーバ機能を使用しています。Oracle の Technical Note 235118.1 で説明されているように、Oracle Thin Driver でロード バランシングをコンフィグレーションした場合、トランザクションの開始と終了が同じ RAC インスタンスで行われるかどうかは保証されません。Oracle RAC では、グローバル トランザクション内のすべてのデータベース操作が同じ Oracle インスタンスにルーティングされる必要があるため、この確認済みの制限があることで、XA と Oracle RAC を併用する場合に接続レベルのロード バランシングは使用できないことになります。結果として、プライマリ/プライマリの RAC コンフィグレーションは使用できません。このリリースの WebLogic Server では、WebLogic Server 用の高可用性データベースとして Oracle 11g RAC がサポートされています。ただし、ロード バランシングを使用した XA をサポートする Oracle 11g RAC で新たに追加された Oracle サービス機能はサポートされません。その代わりとして WebLogic Server では、引き続きマルチ データ ソースを使った実績のある統合アーキテクチャを使用してロード バランシングを使用した XA をサポートします。 |
グローバル トランザクションを利用する場合は、トランザクション 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 コンフィグレーションを考えてみます。
WebLogic クラスタには 2 つのサーバ (server1 と server2) がある。
JDBC データ ソース ds1 がこのクラスタに割り当てられている (このデータ ソースと同一のインスタンスが、クラスタ内のすべてのインスタンス上に存在している)。
JDBC データ ソース ds1 が Oracle RAC クラスタに接続するようにコンフィグレーションされていて、接続時フェイルオーバが有効になっている。RAC1 がプライマリ RAC インスタンスとして、RAC2 がセカンダリ RAC インスタンスとして設定されている。データ ソース ds1 がこのクラスタに割り当てられている (このデータ ソースと同一のインスタンスが、WebLogic クラスタ内のすべてのノード上に存在している)。
次のシナリオでは、データ変更が消失することがあります。
server2 と RAC1 のネットワーク接続が切断される。これにより、server2 の cp1 でのデータベース接続が RAC2 にフェイルオーバする。server1 の同じデータ ソースは、RAC1 への接続を維持している。
server1 でアプリケーションがトランザクションを開始し、cp1 からのデータベース接続 (RAC1 への接続) を使用してデータを変更する。
アプリケーションが server2 の EJB を呼び出し、server2 の cp1 からのデータベース接続 (RAC2 への接続) を使用してデータを変更する。
アプリケーションが server1 のトランザクションを完了する。
結果 : RAC1 でのデータ変更はコミットされます。RAC 2 でのデータ変更は無視されます。WebLogic Server トランザクション マネージャは、このリソースに対して prepare と commit を呼び出します。このケースでは、データ ソースの名前が同じであるためこれらが同じリソースとみなされ、呼び出しはデータ ソースの 1 つのインスタンスに対してのみ行われます。これらのデータ ソースには別々の RAC インスタンスへの接続が含まれているため、一方の RAC インスタンスでのデータ変更はコミットされますが、もう一方の RAC インスタンスでのデータ変更は消失します。
回避策 : ネットワーク障害を回避するため、WebLogic Server インスタンスと Oracle RAC インスタンスの間に余分なネットワーク ハードウェアを供給します。
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 Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ストア接続のモニタ」を参照してください。
JDBC ストアのしくみでは、Oracle RAC と併用するためのコンフィグレーションのオプションが限られています。JDBC ストアは、グローバル トランザクションをサポートするようにコンフィグレーションされた JDBC データ ソースを使用するようにコンフィグレーションすることはできません。JDBC ストアは、非 XA JDBC ドライバを使用する JDBC データ ソースを使用する必要があります。このコンフィグレーション オプションの詳細については、「グローバル トランザクションを利用しない場合のマルチ データ ソースの使用」を参照してください。
JDBC ストアは、1 つの接続が失敗するまで、その接続を保持します。失敗すると、次の接続に進んで、プロセスを繰り返します。したがって、JDBC ストアでは、ロード バランシング マルチ データ ソースを使用することを含めて、ロード バランシングを実装することができません。フェイル オーバ アルゴリズムを使用するには、JDBC ストアに対してマルチ データ ソースをコンフィグレーションする必要があります。
つまり、JDBC ストアについては次のようにします。
非 XA ドライバを使用する。
マルチ データ ソースをフェイルオーバ モードでコンフィグレーションする。
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 番目の試行で障害が発生すると、例外がコール スタックに伝播されます。この場合、失敗したトランザクションに関連するメッセージを回復するには手動での再起動が必要になります。
|
注意 : 自動的な再試行が成功しない場合は、WebLogic Server を再起動する必要があります。 |
