Active GridLink for RAC：Oracle WebLogic ServerとOracle Real
by user
Comments
Transcript
Active GridLink for RAC：Oracle WebLogic ServerとOracle Real
Oracleホワイト・ペーパー 2013年5月 WebLogic Active GridLink Oracle WebLogic ServerとOracle Database Real Application Clustersのインテリジェントな統合 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 はじめに ....................................................................................................................................................1 Oracle Real Application Clusters..................................................................................................5 Oracle Database 12cの新機能 ......................................................................................................6 Oracle WebLogic ServerとOracle Database RAC ...............................................................7 高速接続フェイルオーバー.....................................................................................................8 ランタイム接続ロードバランシング ................................................................................9 接続アフィニティ ...................................................................................................................... 11 WebLogic GridLinkデータソースの構成.............................................................................. 13 WebLogic Server 12cとOracle Database 12c.................................................................... 15 アプリケーション継続性....................................................................................................... 16 ユースケース1：アプリケーション継続性を使用しない場合のエクスペリ エンス ...............................................................................................................................................16 ユースケース2：アプリケーション継続性を使用した場合のエクスペリエ ンス ....................................................................................................................................................18 トランザクション・ガード.................................................................................................. 19 データベース常駐接続プール（DRCP） ...................................................................... 20 プラガブル・データベース.................................................................................................. 21 グローバル・データベース・サービス ........................................................................ 23 まとめ ......................................................................................................................................................24 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 はじめに 高可用性とスケーラビリティは、今日のミッション・クリティカルな情報システムに不可欠な属性です。ほ とんどのビジネス・ユーザーは1年中、1日のほとんどの時間、中断しないコンピューティング・サービスを 求めています。このレベルのアップタイムは、24×365（24時間365日）と呼ばれます。またビジネスには、 （ハードウェアやソフトウェアのアップグレードなどの）計画的なメンテナンス作業中に、高可用性を維持 できるメカニズムも必要です。 このレベルの信頼性と可用性でシステムを実行するには、多くの複雑さが伴います。このような問題には、 Java EEの中間層サービスとバックエンドのデータベース・サービスの両方が含まれます。たとえば、データ ベース・ノードに障害が発生すると、アプリケーション・リクエストが長時間ブロックされることがありま す。アプリケーションが後続のエラー・メッセージを受信した後に、新しい接続を取得すべきかどうかを判 断するのは容易ではありません。中間層アプリケーションでは通常、新規または再起動したデータベース・ ノードが認識されません。また、低速、ハング、あるいは停止状態のデータベース・ノードに関するナレッ ジにもアクセスできない可能性があり、ユーザーはTCP/IPのタイムアウトまで待機することになります。 データベース・セッション、インスタンス、ノード、ストレージ・デバイス、またはネットワーク・コン ポーネントに問題がある場合、アプリケーション開発者がこのような停止を目立たないように隠すことは困 難です。ユーザーに対してシステムのメッセージ・ブロードキャストのエラーやタイムアウトが表示される 場合があり、フラストレーション、生産性低下、機会損失の原因となります。 2001年のOracle Real Application Clusters（Oracle RAC）のリリース以降、オラクルはあらゆる種類のビジネ ス・アプリケーション向けに、スケーラビリティと可用性の高いデータベース・ソリューションを提供して きました。Oracle RACは共有のキャッシュ・アーキテクチャを持つクラスタ・データベースであり、卓越し たフォルト・トレランス、パフォーマンス、スケーラビリティを実現しています。また、関連するアプリ ケーションに影響を与えずに、既存のIT環境に導入できます。Oracle Database 12cでは、Oracle RACと組み 合わせて必須ビジネス・アプリケーションの可用性、信頼性、パフォーマンスを向上させる多くの新機能の ほか、自動リカバリ機能とクラウド統合機能が導入されています。 1 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 Oracle WebLogic Server 12c（12.1.2）とOracle Database 12cは連携して動作することで、高い可用性、ス ケーラビリティ、パフォーマンスを実現することが確認されています。Oracle WebLogic Serverは、SpecJの パフォーマンス・テストが示すとおりナンバー1のアプリケーション・サーバーであり、統合環境でOracle Databaseと一緒に使用すると、パフォーマンス結果がさらに向上します。また、豊富な接続プールや管理機 能に透過的にアクセスしながら、データベース・アクセス時間を最小限に短縮できます。このような業界 トップのテクノロジーによって、計画停止および計画外停止時のユーザー・エクスペリエンスが改善され、 トランザクション結果が保証されます。 Oracle WebLogic Serverは、Oracle Real Application Clustersをサポートするための推奨ソリューション1 1と して、Oracle Database RAC 11gおよび12cと完全に統合され認定を受けている唯一のアプリケーション・ サーバーです。Oracle WebLogic Serverは、セキュリティ、トランザクション処理、接続プーリング、管理、 およびその他の重要な機能に関するJava EE実装のすべての側面をサポートします。Oracle WebLogic Active GridLink for RACでは、他のベンダーでは利用できない包括的なミドルウェアおよびデータベース統合機能に より、この環境が拡張されます。 たとえば、Oracle WebLogic Serverのデータソース/接続プーリング・ソリューションとOracle Database 12c を組み合わせることで、Oracle RACにより優れたパフォーマンス、スケーラビリティ、および可用性の機能 を持つハイエンド環境が実現します。ロードバランシングおよびアフィニティ機能により、オンライン・ト ランザクション処理シナリオのパフォーマンスが向上し、スループットおよび全体の応答時間も向上します。 本来のフェイルオーバー・ソリューションにより障害を迅速に検出でき、Oracle RACノードの計画停止およ び計画外停止時に正常にシャットダウンできます。 1 Active GridLink機能については、『Oracle Fusion Middlewareライセンス情報』ドキュメントを参照してください。 2 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 図1：WebLogic Active GridLink for RAC Oracle Database Release 12c Release 1（12.1）以降、Oracle DatabaseでJavaのアプリケーション継続性がサ ポートされるようになりました。この機能により、コミット結果の概要とアクティブ・リクエストのリカバ リが有効になり、高可用性（HA）インフラストラクチャのJDBCベースのアプリケーションでシステム障害 によるアプリケーション・エラーを回避できるようになりました。これは、フェイルオーバーが発生すると、 すべてのアクティブ・リクエストが即時にリカバリ/再送信され、データベース・サービスへの接続がリス トアされるためです。 図2：アプリケーション継続性を使用した場合のユーザー・エクスペリエンス Oracle Database 12cではトランザクション・ガードも導入されています。トランザクション・ガードとは、 データベース・セッションを使用不可にした最後の実行中トランザクションの結果を停止後に返す信頼性 ツールです。もう1つの最先端の高パフォーマンス・ソリューションとしてデータベース常駐接続プールが あり、多くのクライアント間で共有できるサーバー内に接続プールを作成することで、企業およびミッショ ン・クリティカルなシナリオで優れたパフォーマンス結果を出すことができます。 3 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 以上の機能やその他の独自機能については、この後のページで詳しく説明します。本書ではまず、Oracle RAC、Oracle Database 12c、およびOracle WebLogic Server 12c（バージョン12.1.2）の相互関係の概要につ いて説明します。次に、Oracle WebLogic Server 12cとOracle Database 12cによる統合シナリオについて重 点的に説明します。ここでは、ランタイム接続ロードバランシング、XAアフィニティ、Webセッション・ア フィニティ、高速接続フェイルオーバー、およびOracle RACノードをダウンタイムなしで追加/削除するプロ セスに関する重要な技術的詳細について説明します。ここでは、Oracle Database 12cの新機能がすべて網羅 されています。これらの新機能が、WebLogic Server（アプリケーション継続性、トランザクション・ガー ド、データベース常駐接続プール、プラガブル・データベース、グローバル・データベース・サービスを含 む）に関連するためです。 4 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 Oracle Real Application Clusters Oracle RACは、サーバーのプールに単一のデータベースを透過的にデプロイして、ハードウェア障害や計画 停止に対するフォルト・トレランスを実現します。これは、Oracleデータベースのクラスタを作成するため の、業界をリードするソリューションです。シングル・インスタンスのOracleデータベースの場合、Oracle データベースとインスタンスの関係は1対1です。Oracle RAC環境の場合、データベースとインスタンスの関 係は1対多となります。 高可用性とスケーラビリティの達成は、アプリケーションでOracle RACでのワークロードを管理するための 機能です。もっとも重要な要素には、特定のアプリケーションまたはアプリケーション動作のサブセットに 対するサービスの定義が含まれます。ワークロードは、サービスの種類によってグループ化および優先順位 付けできます。たとえば、オンライン・ユーザーとバッチ処理ジョブ、およびレポーティング・サービスが、 それぞれ同時に別のサービスを使用してデータベースに接続できます。 図3は、Oracle RACとOracle Databaseが連携し、1つのOracle Databaseにアクセスする複数のサーバーに対 し、単一システム・イメージを提供する方法を示しています。Oracle RACでは、それぞれのOracleインスタ ンスが、通常別々のサーバー上で実行されます。 図3：Oracle Real Application Clusters 5 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 Oracle Database 12cの新機能 Oracle Database 12cは、オラクルの歴史上もっとも成功したリリースの1つです。Oracle Database 12cには 革新的機能の包括的セットが搭載されており、世界をリードするデータベースが、オラクルのプライベー ト・クラウド用およびパブリック・クラウド用の主要コンポーネントとなります。Oracle WebLogic Server 12cはOracle Database 12cと緊密に統合されているため、ユーザーは次の機能を利用できます。 • アプリケーション継続性 – リカバリ可能エラーとなる停止（通常は基盤のソフトウェア、フォアグラ ウンド、ハードウェア、通信、ネットワーク、またはストレージ・レイヤーに関連）で起動します。 アプリケーション継続性を使用すると、計画外停止および計画停止を処理する際のユーザー・エクス ペリエンスが向上します。 • トランザクション・ガード – データベース・セッションを使用不可にした最後の実行中トランザク ションの結果を停止後に返す信頼性ツールです。トランザクション・ガードを使用しないと、アプリ ケーションの停止後に操作が再試行されることにより、トランザクションが重複または正しくない順 序でコミットされ、論理的破損が生じる可能性があります。 • データベース常駐接続プール- 多くのクライアント間で共有できるサーバー内に接続プールを作成し ます。このアーキテクチャでは、サーバー・プロセス数の削減とデータベース・サーバーの全体的な スケーラビリティの向上により、サーバーのメモリ消費量が大幅に減ります。 • Oracleデータベースの統合とプラガブル・データベース – 複数のアプリケーションやデータベースを、 同じシステム・プラットフォーム上か同じデータベース内でホストできるようにします。この独自機 能により、Oracleデータベースにスキーマ、オブジェクト、および関連構造のポータブル・セットを 含めることができます。これはアプリケーションに対し、論理上は別のデータベースとして表示され ます。 • グローバル・データ・サービス – 一般的なサービスを提供するレプリケーションされたデータベース 間で、管理者がクライアント・ワークロードを自動的かつ透過的に管理できます。データベース・ サービスは、1つまたは複数のデータベース・インスタンスを名前付きで表示したものです。サービ スによって、データベース・ワークロードをグループ化し、特定の作業リクエストを適切なインスタ ンスにルーティングできます。グローバル・サービスとは、データ・レプリケーションによって同期 される複数のデータベースにより提供されるサービスです。 • Oracle Active Data Guardによるローリング・アップグレード – 新しいPL/SQLパッケージの提供によ り、フィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行プロセス が自動化されます。この機能は、新しいOracle Databaseバージョンやパッチ・セットにアップグ レードしたり、他のデータベース・メンテナンスを実行したりする場合に便利です。アップグレード 計画を入力するだけで、PL/SQLパッケージによって、アップグレードが3フェーズ（開始、スイッチ オーバー、終了）計画で自動化されます。 Oracle WebLogic Server 12cとOracle Database 12cは連携して動作し、高い可用性、スケーラビリティ、パ フォーマンスを実現することが十分に確認されています。すべてのOracle Databaseソリューション（アプリ ケ ー シ ョ ン 継 続 性 、 ト ラ ン ザ ク シ ョ ン ・ ガ ー ド 、 デ ー タ ベ ー ス 常 駐 接 続 プ ー ル を 含 む ） は 、 Oracle WebLogic Server JDBCデータソースと接続プールの実装により使用可能になります。 6 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 Oracle WebLogic ServerとOracle Database RAC Java EEアプリケーション・サーバーでは、データベース・インタラクションは通常データソース実装によって 処理されます。データベースへの接続をJDBCデータソースとして構成し、公開します。Oracle WebLogic Server には、Oracle Real Application Clustersをサポートするための次の2つのデータソースが実装されています。 • • 顧客の本番デプロイメントで問題なく使用されてきたマルチ・データソース・ソリューション Oracle WebLogic Active GridLink for RACと呼ばれる新しい実装。これは、Oracle DatabaseとOracle RACの最新の進化を利用した、市場をリードする中間層の統合ソリューションです。 Oracle WebLogic Serverでは、Active GridLink for RACを使用した、Oracle RACクラスタをサポートする単一 のデータソース実装が導入されました。これにより、FANイベントに対応して、高速接続フェイルオーバー （FCF）、ランタイム接続ロードバランシング（RCLB）およびOracle RACインスタンスをスムーズに停止でき ます。XAアフィニティは、グローバル・トランザクションIDレベルでサポートされます。Webセッション・ アフィニティは、HTTPセッション・スコープ内でサポートされます。 Universal Connection Pool（UCP）のOracle RACの統合機能は、WebLogic Server GridLinkデータソース実装 によって活用され、FCF、RCLBおよびアフィニティ機能を提供します。 このOracle WebLogic Serverの単一データソース実装は、Oracle RACとのより深い統合を提供する基盤とし て、データソースの接続先であるデータベース・サービスの完全で無制限な使用をサポートします。プール 内における接続のアクティブな管理は、接続プール自体に構成される静的設定（最小/最大容量、タイムア ウトなど）と、“クライアント”にOracle RACクラスタ内のステート変更を知らせるOracle RACのOracle Notification Service（ONS）サブシステムから接続プールが受信するリアルタイム情報に基づきます。 Universal Connection Pool JavaライブラリはWebLogic Serverと統合され、WebLogic GridLinkデータソース 実装によって活用されて、高速接続フェイルオーバー、ランタイム接続ロードバランシングおよびアフィニ ティ機能を提供します。 Oracle Databaseサービスは、Oracle Databaseのワークロードの管理を論理的に抽象化したものです。サー ビスは、論理的に分離したグループにワークロードを分割します。各サービスは、一般的な属性やサービ ス・レベルのしきい値および優先順位でワークロードを表します。これらのサービスはOracle Databaseに組 み込まれ、ワークロードの単一システム・イメージ、ワークロードの優先順位付け、実際のトランザクショ ンのパフォーマンス測定、およびパフォーマンス目標に違反があった場合の警告およびアクションを提供し ます。サービスにより、データベース管理者は、ワークロードの構成、ワークロードの管理、ワークロード の有効化/無効化、および単一エンティティとしてのワークロードの測定が可能になります。 GridLinkデータソースは、データベース・サービスに非表示のOracle RACインスタンスへの一連の異機種接 続を含む接続プールに関連付けられます。アプリケーションがデータソースから接続をリクエストすると、 適切な接続がプールから借用され、アプリケーションに提供されます。この時、接続プールが受信したロー ドバランシング情報と、使用中の接続の分散に基づいてアプリケーションに提供されます。 7 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 Active GridLink for RACにより、単一データソース・アプローチによるWebLogic ServerとOracle RACデータ ベースの併用が簡単になり、Oracle RACの使用に必要な構成および管理の複雑さが軽減されます。Oracle RAC環境向けのマルチ・データソース構成の使用は、引き続きサポートされます。Oracle RACマルチ・デー タソースからGridLinkデータソースへのアップグレードは簡単で、単一のGridLinkデータソースをマルチ・ データソースと同じJNDI名で作成することで行います。これにより、維持すべき構成アーチファクトの数が 削減されます。 WebLogic Server 12cでは、Active GridLinkにOracle Database 12cの統合（アプリケーション継続性、トラン ザクション・ガード、データベース常駐接続プール、プラガブル・データベースおよびグローバル・デー タ・サービスの最新機能を含む）が含まれます。 高速接続フェイルオーバー 高速接続フェイルオーバー（FCF）機能は、Universal Connection Poolを通じて実装された高速アプリケー ション通知（FAN）クライアントです。この機能では、シングル・インスタンス・データベース上での Oracle JDBCドライバおよびOracle RACデータベース、またはOracle Restartの使用が必要です。 WebLogic GridLinkデータソースは、Universal Connection Poolの実装からFCFと統合されます。FCFの使用 により、次の操作を実行できます。 • 高速な障害検出 • 接続プールからの無効な接続の迅速な中断および削除 • Oracle RACノードの計画停止および計画外停止の際のスムーズな停止 • ノードの追加または削除などの、トポロジの変更への適応 • クラスタを再結合するものを含む、すべてのアクティブなOracle RACインスタンスへのランタイム 作業リクエストの配信 ONSは、Oracle RACデータベースによって使用され、ステートの変更を記述するイベントをブロードキャス トします。GridLinkデータソースは、ONSから通知を受信するように登録できるため、Oracle RACデータ ベースに生じたステート変更を迅速に認識できます。これらのステート変更通知イベントを使用することで、 GridLinkデータソースは接続プールに理論的に適応できるため、変更が発生した際に、Oracle RACデータ ベースへの継続的で信頼性の高い効率的なアクセスが実現します。 Oracle RACクラスタ内のステート変更へ適応して対応できることにより、WebLogic Serverは、計画外停止 によって停止または切り離されたOracle RACインスタンスへの接続を迅速に取り消し、終了および破棄する ことによって停止に対応します。定期的に接続にポーリングを実行してOracle RACインスタンスが有効であ ることを確認したり、関与していない接続にノードを引き継がせたりする必要はありません。これにより、 接続をテストする必要がなくなり、障害モードによっては数分間にわたってハングする可能性のあるOracle RACノード障害から無効な接続を迅速に削除できます。 8 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 さらに、WebLogic Serverは、接続のセットを積極的に再配分し、停止後に新しいOracle RACインスタンス が追加または再起動された場合のシナリオをサポートできます。これにより、WebLogic ServerがOracle RACデータベース内のリソースを完全に使用できるようになります。さらに、データベース・サービス・モ デルの使用により、データベース管理者はOracle RACサービス/インスタンスの割当てを変更できます。これ らの変更は、影響を受けたWebLogic接続プールを通じてシームレスに適用され、接続プール構成を変更す る必要はありません。また、Oracle RACデータベースの専用インスタンスを表すために複数のデータソース を複雑に配置する必要もなくなります。 WebLogic GridLinkデータソースは、高速接続フェイルオーバー機能を提供し、Oracle RACデータベース・ サービスおよびノード・イベント（UP、DOWN）に対応して、プール内の予約された物理接続が常に有効な データベース・ノードを指すようにします。またこれにより、使用可能なデータベース・ノード間で、物理 接続が適切に分散されるようになります。高速接続フェイルオーバーの動作は、GridLinkデータソース上の 構成設定として有効化されます。 高速接続フェイルオーバー機能が有効化されている場合、以下のシナリオがサポートされます。 • 計画停止イベント - 計画停止は、予定された時点で実施されるデータベース保守またはその他のア クティビティとして定義されます。これらのイベントのサポートは、Oracle RACサービスを正しく 停止できる場合に利用可能です。そのようなシナリオでは、作業が完了し、接続のコントロールが プールへ戻るまで、借りている接続や使用中の接続は中断されません。これは、顧客の大規模な異 機種環境において計画停止を管理する際に、特に効率的な方法です。 • 計画外停止イベント – Oracle RACクラスタへの古い接続を検出して削除することで、計画外停止が サポートされます。古い接続には、サービス停止やノード停止イベントのために、Oracle RACクラ スタのインスタンス上に使用可能なサービスがない接続が含まれます。借りている接続や使用可能 な接続で古いものが検出され、接続がプールから削除される前にそれらのネットワーク接続が切断 されます。これらの削除された接続は、プールによって置き換えられません。代わりに、アプリ ケーションは、接続との作業を実行する前に接続を再試行する必要があります。 計画外停止シナリオと計画停止シナリオのおもな違いは、借用した接続が処理される方法にありま す。プール内でアイドル状態の古い接続（借用していない）は、計画外停止シナリオと同じ方法で 削除されます。 • UPイベント – Oracle RACインスタンスの再接続および新規インスタンスのシナリオ（Oracle RACク ラスタに対象サービスを提供するインスタンスが追加される）をサポートします。このインスタン スは、クラスタにとって新規、または停止イベント後に再起動されたものです。いずれの場合も、 WebLogic JDBC接続プールが新しいインスタンスを認識し、必要に応じてノードへの接続を作成し ます。 ランタイム接続ロードバランシング WebLogic GridLinkデータソースおよびJDBC接続プールがOracle RACデータベースが提供するロードバラン シング機能を利用することにより、スループットが向上し、リソースの使用がより効率的になります。ラン タイム接続ロードバランシングでは、Oracle JDBCドライバおよびOracle RACデータベースの使用が必要です。 9 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 ドバランシングの使用によってパフォーマンス上の利点が大幅に得られることが明らかになりました。これ らの利点は、ハードウェアの観点からOracle RACクラスタ・ノードの均衡が取れている場合や、クラスタ上 のノードの平均ロードが適度に統一されていることが予測される場合にも確認できます。多くの場合、ロー ド特性に一時的な差異があれば、ランタイム接続ロードバランシングはOracle RACクラスタに最適なロード バランシング・メカニズムになります。 ロードバランシング・アドバイザリ・サービスは、接続の送信先に関するアドバイスなど、クラスタの現在 の状態をクライアントに知らせるFANイベントを発行します。WebLogic Serverの接続プールは、データ ベースが発行したロードバランシング・アドバイザリ・イベントを受信し、図4に示すように、Oracle RAC ノードへ接続を分散します。 図4：ランタイム接続ロードバランシング ランタイム接続ロードバランシングが提供する利点には以下のものがあります。 • プールされた接続を管理することで得られる高いパフォーマンスとスケーラビリティ • データベース・インスタンスにルーティングする作業のパーセンテージに関する継続的な推奨の受 信 • CPU容量や応答時間など、バックエンド・ノードの異なる能力に基づいた作業分散の調整 • クラスタ再構成の変更、アプリケーション・ワークロード、過負荷ノード、ハングへの迅速な対応 • Oracle RACロードバランシング・アドバイザリからのメトリックの受信。パフォーマンスが良好な インスタンスへの接続がもっとも頻繁に使用されます。パフォーマンスの低いインスタンスへの新 規および未使用の接続は、長期にわたって遠ざけられます。分散メトリックが受信されない場合、 接続はランダム選択を使用して選択されます。 10 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 接続アフィニティ WebLogic GridLinkデータソースは、Oracle RACデータベースが提供するアフィニティ機能を利用します。接 続アフィニティでは、Oracle JDBCドライバおよび 11.1.1.6以上のバージョンのOracle RACデータベースを使用する必要があります。 接続アフィニティにより、接続プールは特定のOracle RACインスタンスに送られた接続を選択し、顧客アプ リケーションに最適なパフォーマンスを提供できます。プールでは、ランタイム接続のロードバランシング によってOracle RACインスタンスが選択され、最初の接続が作成されます。その後の接続は、同じインスタ ンスに対するアフィニティによって作成されます。 WebLogic GridLinkデータソースは、トランザクションベースのアフィニティ、Webセッション・アフィニ ティ、およびデータ・アフィニティをサポートします。 トランザクションベースのアフィニティ トランザクションベースのアフィニティは、クライアント・アプリケーションまたは障害イベントのどちら かによって解放できるOracle RACインスタンスへのアフィニティです。通常、アプリケーションは、Oracle RACインスタンスに長期間存続するアフィニティが求められる場合や、新規のOracle RACインスタンスへの リダイレクトの（パフォーマンス面の）コストが高い場合にこのタイプのアフィニティを使用します。分散 されたトランザクションに含まれるWebLogic XA接続は、トランザクションが持続する間、Oracle RACイン スタンスへのアフィニティを維持します。この場合、分散トランザクション中に異なるOracle RACインスタ ンスに接続がリダイレクトされると、アプリケーションには大幅なパフォーマンス・コストが発生します。 アフィニティは、個別のデータソースではなくグローバル・トランザクションIDに基づいて確立されます。 この方法により、同じOracle RACクラスタ用に構成されている別々のデータソースから取得される接続が、 すべて同じOracle RACインスタンスに関連付けられます。LLR 2フェーズ・コミットの最適化は、Oracle RAC データソースによってサポートされ、XAアフィニティにも使用できます。 図5：XAアフィニティ 11 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 Webセッション・アフィニティ WebLogic Webセッション・アフィニティは、インスタンス、クライアント・アプリケーション、または障 害イベントのいずれかによって解放できるOracle RACインスタンスへのアフィニティです。通常、アプリ ケーションは、Oracle RACインスタンスに短期間存続するアフィニティが想定される場合や、新規のOracle RACインスタンスへリダイレクトされるパフォーマンス・コストが最小の場合にこのタイプのアフィニティ を使用します。たとえばメール・クライアント・セッションでは、Oracle RACインスタンスに対してWeb セッション・アフィニティを使用してパフォーマンスを向上させることができます。接続が別のインスタン スにリダイレクトされると、クライアントへの影響が比較的少なくなります。同じレコード・セットに対し、 同じOracle RACインスタンスによって繰り返しの操作やトランザクションを処理する必要がある場合、この タイプのアフィニティは便利です。オンライン・ショッピングやオンライン・バンキングなどのビジネス・ アプリケーションは、このパターンの典型的な例です。 GridLinkデータソースはセッション・アフィニティ・ポリシーを使用して、トランザクションを含むすべて のWebセッション・データベース操作がOracle RACクラスタの同じOracle RACインスタンスに送られるよう にします。同じHTTPセッション・スコープ内の最初の接続リクエストはRCLBを使用して接続を選択し、後 続のリクエストはアフィニティによって処理されます。アフィニティが終了した後は、接続の選択はRCLBに 戻ります。 Webセッション・コンテキストは、HTTPセッションCookieに格納され、アフィニティ・コールバックを介 してアクセスされます。これは、セッション完了後にアプリケーションによって消去され、HTTPセッション 内で伝播できます。アフィニティ・コールバックは接続プールによって使用され、アフィニティ・コンテキ ストを格納および取得します。 Webセッション・アフィニティのスコープは、HTTPセッションのライフ・サイクルやデータベースの障害 イベントによって決まります。 GridLinkデータソースのセッション・アフィニティ・ポリシーはデフォルトで常に有効になっていますが、 以下の場合、Webセッションはセッション・アフィニティに対してアクティブです。 • Oracle RACが有効かつアクティブであり、サービスのRCLBが有効である場合。サービスのGOAL （CLB_GOALではない）がSERVICE_TIMEまたはTHROUGHPUTに設定されている場合、サービスの RCLBは有効です。 • クラスタ待機時間において十分なパフォーマンスの向上が見込めるとデータベースによって判断さ れ、ペイロードのアフィニティ・フラグがTRUEに設定されている場合。 データベースの可用性状況が高いなどで、セッション・アフィニティを実装してもメリットがないとデータ ベースによって判断された場合、データベースのロードバランシング・アルゴリズムはデフォルトの作業割 当てポリシーに戻り、ペイロードのアフィニティ・フラグはFALSEに設定されます。 WebLogic Webセッション・アフィニティは、以下の図6のように、Oracle RACクラスタの待機時間を短縮す ることで極めて高いパフォーマンスを実現します。 12 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 図6：Webセッション・アフィニティ WebLogic GridLinkデータソースの構成 WebLogic管理コンソールまたはWebLogic Scripting Tool（WLST）を使用してGridLinkデータソースを作成 できます。GridLinkデータソースは、Active GridLink機能の実装です。 構成に使用できるデータソースには3種類あります。汎用データソースは、単一のデータベース・アクセス 向けの実装です。マルチ・データソースは、Oracle Notification Serviceを利用しないOracle RAC統合向けの ネイティブのWebLogic中間層実装です。GridLinkデータソースは、FCF、RCLB、アフィニティ、および Database 12cのすべての機能をサポートするOracle RACを利用する新しいActive GridLink実装です。これは、 構成の際にSCANの使用をサポートします。 13 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 図7：WebLogicデータソースの構成 GridLinkデータソースは、以下のように、データソース名およびJNDIロケーションを使用するだけで構成で きます。 図8：GridLinkデータソースの構成 14 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 Oracle Notification Serviceを利用するには、リスナーとONSを構成する必要があります。SCANアドレスは、 両方に対して使用できます。Service Nameは、Oracle RACデータベースで作成されるサービスです。 Host:PortはYour_SCAN:1521です。ONS構成は、Your_SCAN:6200など、ONSポートと同じSCANアドレスを 使用します。 図9：ONSの構成 高速接続フェイルオーバー、ランタイム接続ロードバランシング、アフィニティなどのActive GridLinkのす べてのパフォーマンス機能は、1つのフラグ‘FAN Enabled’によって有効化されます。異なるパフォーマンス 機能やHA機能は、アプリケーション・シナリオによって自動的に有効になります。たとえば、FCFは障害 ケースが発生した場合に起動されます。アプリケーションによってグローバル・トランザクションが開かれ た場合、XAトランザクション・アフィニティが最初の接続のRCLBイベントに基づいて開始します。Web セッション・シナリオでは、セッション・アフィニティが最初に適用されてから、RCLBが適用されます。目 標は、使用している異機種システムおよびアプリケーションに最適の高可用性、スケーラビリティおよびパ フォーマンス・ソリューションを提供することです。 Oracle Database 12cの統合により、FAN Enableフラグによって、グローバル・データベース・サービスなど の機能も有効になります。 リスナーおよびONSが構成されると、接続はWebLogic Server管理コンソールで簡単にテストできます。 WebLogic Server 12cとOracle Database 12c ほとんどのエンタープライズ環境およびミッション・クリティカル環境において、顧客のアプリケーションと インフラストラクチャにとって必要なのは、高可用性サービスだけでなく完全にリカバリ可能なサービスで あり、トランザクション結果が保証されていることです。Oracle Database 12cには、業界で何十年も待ち望 まれてきた新しいHA機能（アプリケーション継続性やトランザクション・ガードなど）が含まれています。 15 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 Oracle WebLogic Server 12c（12.1.2）とOracle Database 12cは、一緒に動作して高可用性、スケーラビリティ およびパフォーマンスを実現することが確認されています。いくつかの詳細について確認してみましょう。 アプリケーション継続性 アプリケーション継続性では、停止後に影響を受けるデータベース・セッションの実行中の作業がリカバリ されるため、停止がエンドユーザーやアプリケーションからマスクされます。このリカバリはアプリケー ションの下で実行されるため、停止してもアプリケーションには若干の実行遅延しか生じません。Oracle Database 12cで導入されたアプリケーション継続性は、Oracleデータベースを使用するシステムとアプリ ケーションのフォルト・トレランスを強化します。また、アプリケーション継続性は、Oracle WebLogic Server Active Gridlink、Oracle Universal Connection Pool、およびOracle JDBC-Thin Driverで使用できます。 リカバリ可能なエラーによってデータベース・セッションが使用できなくなった場合、アプリケーション継 続性によって、データベース・リクエストを中断なく迅速にリプレイできます。リクエストには、データ ベースへのトランザクション/非トランザクション・コール、およびクライアントや中間層でローカルに実 行されるコールが含まれる場合があります。リプレイが正常に実行されると、データベース・セッションの 中断箇所からアプリケーションを続行できます。ユーザーが送金、飛行機予約などの処理結果を把握できな いままにはしません。また、ログオン・ストームからリカバリするため、管理者が中間層サーバーを不要に 再起動する必要もなくなります。アプリケーション継続性により、多くの計画停止および計画外停止がマス クされ、アプリケーション開発者がリクエストのリカバリを試行する必要がなくなるため、ユーザー・エク スペリエンスが向上します。 アプリケーション継続性がないと、次の理由により、アプリケーションで安全に停止をマスクすることがほ ぼ不可能になる場合があります。 • クライアントの状態が、入力データ、返されるデータ、およびキャッシュされた変数に関して現状 のままとなり、データベース・セッションに反映された状態変更は失われます。 • コミットが発行済みの場合、コミット・メッセージは永続的ではありません。また、失われたリク エストのステータスを確認しても、それが将来的にコミットされないという保証はありません。 • アプリケーションが操作する必要がある非トランザクション・データベースのセッション・ステー トが失われます。 • リクエストが続行できれば、データベースとデータベース・セッションは正しい状態にあることにな ります。 オラクルのアプリケーション継続性機能によって、このアプリケーション開発者の作業が処理されるため、 多くの停止を安全にマスクできます。アプリケーション継続性では、安全にマスクできる停止をマスクしよ うとするため、開発者の生産性が上がります。 ユースケース1：アプリケーション継続性を使用しない場合のエクスペリエンス アプリケーション継続性がないと、ネットワーク停止、インスタンス障害、ハードウェア障害、修復、構成 変更、パッチなどによる停止がデータベース・リカバリによってマスクされません。 16 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 図10：計画外停止の以前のエクスペリエンス 図7は以前のエクスペリエンスを示しています。リクエストが完了しても、エラーがエンドユーザーに返さ れる可能性があります。 図11：計画停止の以前のエクスペリエンス 計画停止は、計画外停止より高頻度です。Oracle RAC、Oracle RAC One、Oarcle Data GuardまたはOracle Restartを、FANを有効にしてOracle接続プール（Oracle WebLogic Server Connection Pool、Oracle Universal Connection Pool、Oracle JDBC Implicit Connection Cache（ICC）、ODP.NET、OCI Session Pool）と組み合 わせて使用するアプリケーションの場合、Oracle Database 10g Release 2からは計画停止がマスクされてい 17 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 ます。 ユースケース2：アプリケーション継続性を使用した場合のエクスペリエンス 図9は、アプリケーション継続性を使用するアプリケーションで、Oracle Database 12cを使用した場合の ユーザー・エクスペリエンスの向上を示しています。 図12：アプリケーション継続性を使用した場合のユーザー・エクスペリエンス リプレイが正常に実行されると、アプリケーション継続性によって、多くのリカバリ可能なデータベース停 止がアプリケーションやそのユーザーからマスクされます。データベース・セッション、全セッション （セッション・ステート、カーソル、変数を含む）、および最後の実行中トランザクション（ある場合）の リストアにより、マスキングが実行されます。 • リカバリ可能なエラーによりデータベース・セッションが使用できなくなると、アプリケーション 継続性によって、セッションの再構築とオープン・トランザクションの正しい状態へのリストアが 試行されます。 • トランザクションが正常にコミットされ再実行が不要な場合は、アプリケーションに正常ステータ スが返されます。 • リプレイが成功すると、リクエストは重複のリスクなく安全に継続されます。 • リプレイが成功しないと、データベースでリプレイが拒否され、アプリケーションでは元のエラー が受信されます。成功するには、リプレイによって、クライアントが以前にリクエストで受信した （アプリケーションによって決定された可能性がある）データと完全に同じデータが、クライアン トに対して返される必要があります。 18 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 アプリケーション継続性のWebLogicデータソース構成 WebLogicデータソースの実装では、データソース・スキーマであるweblogic-jdbc.xsdが拡張され、次の新 しい要素を含む構成が提供されます。 トランザクション・ガード Oracle Database 12cのトランザクション・ガードによって、データベース・セッションを使用不可にした最 後の実行中トランザクションの結果が停止後に返されます。トランザクション・ガードを使用しないと、ア プリケーションの停止後に操作が再試行されることにより、トランザクションが重複または正しくない順序 でコミットされ、論理的破損が生じる可能性があります。 トランザクション・ガードによって、ユーザーのフラストレーション、カスタマ・サポートへの問い合わせ、 機会損失の原因となる曖昧なエラーのコストがかからなくなります。トランザクション・ガードは、独自ソ リューションと比べて優れた安全性とパフォーマンス、および少ないオーバーヘッドで既知の結果を出すこ とができ、最大1回の実行で済みます。 トランザクション・ガードを使用すると、最後の送信がコミット/完了されているかに関係なく、停止後に 正しいアプリケーションやユーザーの状態に戻るため、ユーザー・エクスペリエンスが向上します。トラン ザクション・ガードを使用すると、停止後に曖昧なエラー・メッセージを受信するといった不確実な状態に ならず、最後に実行中だった操作の結果が不明なままになるということがありません。アプリケーションに は通常、次のようなフラストレーションの原因となりうるメッセージが表示される場合があります。 • カスタマ・サポートにお問い合わせください • 再送信やリロードをクリックしないでください • BackSpaceキーを使用しないでください 開発者は、トランザクション・ガードAPIをアプリケーションや中間層のエラー処理に組み込むことができ ます。図13のフローを以下に示します。作業がクライアントからアプリケーションに送信され（手順1）、 次にOracleデータベースにコールが送信されます（手順2）。セッションでリカバリ可能なエラーが発生す ると（手順3）、エラー処理でトランザクション・ガードが起動され、そのセッションで最後に実行中で あった作業の結果が返されます（手順4）。トランザクション・ガードの信頼性の高いプロトコルによって、 トランザクション結果がアプリケーションに返される際、返される値で結果が保持されます。コミット済み またはコミットされていない結果がアプリケーションに返されると、結果はこのままとなります（手順5）。 これは非常に重要です。コミット済みの結果はコミット済みのままです。コミットされていない結果はコ ミットされないままであり、処理を進めて問題ありません。たとえば、安全に再送信できます。また、停止 時にはアプリケーションがアプリケーション自体を再送信できます。 トランザクション・ガードの使用には、次のような利点があります。 19 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 • ビジネスの場合：ユーザー・エクスペリエンスが大幅に向上し、サポートへの問い合わせや機会損 失が減ります • ユーザーの場合：停止後に送信した最後の作業の結果の信頼性が高くなります • 開発者の場合：停止への対応や処理の生産性が上がります • 全般：独自ソリューションと比べ、パフォーマンスと安全性が向上します 図13：トランザクション・ガードによって、信頼性の高いコミット結果が得られます データベース常駐接続プール（DRCP） 中間層の接続プール（WebLogic Sever JDBC接続プールなど）では、すべての接続キャッシュで、サーバー への最小限の数の接続が維持されます。接続ごとに、サーバーで使用済みのリソースが表示されます。この ようなオープン接続がすべて継続使用されることはありません。つまり、サーバー容量を不要に専有してい る未使用のリソースがあるということです。複数の中間層のシナリオ（Oracle WebLogicクラスタの使用な ど）では、このような接続は異なるインスタンス間で共有されることはなく、これらのセッションの一部が アイドル状態であってもキャッシュ内に保持されます。ただしWebLogic接続プール数が多いと、データ ベース・サーバーへの非アクティブな接続数が大幅に増え、データベース・リソースが浪費されます。 たとえば、中間層の接続プール（WebLogic JDBC接続プールなど）でプールの最小サイズが200の場合、接 続プールのサーバーとの接続数は200、これらの接続と関連するデータベース・サーバーのサーバー・プロ セス数は200となります。接続プールの最小サイズが200のWebLogicインスタンスが30個ある場合、サー バーの対応するサーバー・プロセス数は6,000（200×30）になります。通常はどんな時でも、接続は5%し か使用されません（サーバー・プロセスも同様です）。したがって、6,000のサーバー・プロセスのうち、 同時にアクティブなのは300だけです。つまり、5,700を超える未使用のサーバー・プロセスによって、リ ソースが浪費されていることになります。 20 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 データベース常駐接続プールを実装すると、サーバー側にプールが作成され、複数のクライアント・プール （WebLogic JDBC接続プールなど）の間で共有されます。このタイプの実装によって、サーバー上のメモリ 消費量が大幅に減り、データベースのスケーラビリティが向上します。 データベース常駐接続プールは、クライアント側とサーバー側の両方で有効にする必要があります。 図14：データベース常駐接続プール データベース常駐接続プールとOracle WebLogic Serverを統合すると、次の利点が得られます。 • プールされた専用サーバーを、クライアントのシステムおよびプロセスで共有 • 接続/切断コストの削減 接続時にサーバーを"ロック" 切断時にサーバーを"解放" • 専用サーバーの待機時間の短いパフォーマンス • DRCP対応のクライアント・ドライバによる優れたスケーラビリティ プラガブル・データベース Oracle Database 12cによって、同じプラットフォーム上やデータベース内で、複数のアプリケーションや データベースをホストできます。 プラガブル・データベース（PDB）は、Oracleデータベースにスキーマ、オブジェクト、および関連構造の ポータブル・セットを含めることができるOracle Database 12cの機能です。これはアプリケーションに対し、 論理上は別のデータベースとして表示されます。コンテナ・データベース（CDB）にはPDBが含まれます。 21 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 図15：プラガブル・データベース プラガブル・データベースは、もっともコスト効率の高いデータベース統合の形式です。別々のコンピュー ター上の複数の物理データベースを、Exadata Database Machineなどのエンジニアド・システム上の1つの データベースに統合することで、次の利点が得られます。 • ハードウェアのコスト削減 • アプリケーションのデータベース・バックエンドの移植性 • データベースとシステムの管理の簡素化 • データベースのアカウントと権限の一元管理 • アップグレード・パスの簡素化/迅速化 22 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 グローバル・データベース・サービス 図16：グローバル・データベース・サービス 管理者はグローバル・データ・サービスにより、一般的なサービスを提供するレプリケーションされたデー タベース間で、クライアント・ワークロードを自動的かつ透過的に管理できます。データベース・サービス は、1つまたは複数のデータベース・インスタンスを名前付きで表示したものです。サービスによって、 データベース・ワークロードをグループ化し、特定の作業リクエストを適切なデータベース・インスタンス にルーティングできます。グローバル・サービスとは、データ・レプリケーションによって同期される複数 のデータベースにより提供されるサービスです。グローバル・データベース・サービスには次の利点があり ます。 • グローバルに分散した構成内の任意の場所にデータベース・サービスをデプロイできます • 既存の高速接続フェイルオーバー（FCF）、ランタイム接続ロードバランシング（RLB）、および データベース・アフィニティが透過的にサポートされます • Oracle RAC、Oracle Data Guard、GoldenGate、またはその他のレプリケーション・テクノロジーで 相互接続されたシングル・インスタンスのOracleデータベースを、データベースに含めることがで きます WebLogicデータソース構成でグローバル・データベース・サービスを簡単に有効化できます。 • 高速接続フェイルオーバー（FCF）の有効化 • ONSの自動構成 – setONSConfigurationのコールが不要 • 接続URLでのグローバル・サービスの名前と地域の指定 23 Active GridLink for RAC：Oracle WebLogic ServerとOracle Real Application Clustersのインテリジェントな統合 図17：WebLogicおよびグローバル・データベース・サービス まとめ Oracle WebLogic Server 12cはOracle Database 12cと緊密に連携し、パフォーマンスと可用性を最大限に高 める豊富な接続プールや管理機能に透過的にアクセスしながら、データベースのアクセス時間を最小限に短 縮できるよう設計されています。このような業界トップのテクノロジーによって、計画停止および計画外停 止時のユーザー・エクスペリエンスが改善され、トランザクション結果が保証されます。Oracle WebLogic Server は 、 Oracle Real Application Clusters をサポートするための推奨ソリューションとして、Oracle Database RAC 11gおよび12cと完全に統合され認定を受けている唯一のアプリケーション・サーバーです。 Oracle WebLogic Serverは、セキュリティ、トランザクション処理、接続プーリング、管理、およびその他 の重要機能に関するJava EE実装のすべての側面をサポートしています。 Oracle WebLogic Server Active GridLink for RACでは、他のベンダーでは利用できない包括的なミドルウェア およびデータベース統合機能により、顧客の環境が拡張されます。この製品は、Oracle Database RAC 11gお よび12cを活用できるよう、明示的に設計されています。これらの成熟したソフトウェア製品が連携して動 作することで、高可用性、スケーラビリティ、およびパフォーマンスが実現されます。Oracle WebLogic Server 12cはOracle Database 12cと緊密に統合されているため、顧客はシステムの可用性、トランザクショ ンの整合性、およびユーザーの生産性を上げる新機能を利用できます。 24 Active GridLink for RAC Copyright © 2013, Oracle and/or its affiliates. All rights reserved.. 2013年5月 著者：Frances Zhao-Perez 共著者：David Baum Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口： 電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 oracle.com 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一切間違いがないこ とを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示 的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文 書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いか なる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。 UNIXはThe Open Groupの登録商標です。 0513