1 WebLogic Continuous Availabilityの概要

Oracle WebLogic Server Continuous Availabilityは、地理的に分散した場所にデータ・センターを展開する最大可用性アーキテクチャ(MAA)を構築するための統合ソリューションを提供します。

• 継続的可用性とは?

• 継続的可用性の用語

• 継続的可用性の主な機能

• WebLogic ServerおよびCoherenceの付加価値の高可用性機能

• Oracle Databaseの高可用性およびディザスタ・リカバリ

継続的可用性とは?

継続的可用性とは、必要時にアプリケーションを必ず使用できるように、高可用性および障害時リカバリの両ソリューションを採用することで最大限の可用性を提供するシステムの機能です。

一般的に、高可用性ソリューションは1つのデータ・センターにおける冗長性を提供します。障害時リカバリ・ソリューションは、自然災害などによる計画外の本番サイトの機能停止に対する防護機能を提供します。アプリケーションとデータを地理的に離れたスタンバイ・サイトに置くリカバリ戦略を使用します。

Oracle WebLogic Server Continuous Availabilityは、地理的に分散した場所にデータ・センターを展開する最大可用性アーキテクチャ(MAA)を構築するための統合ソリューションを提供します。統合されたコンポーネントにはOracle WebLogic Server、Oracle Coherence、Oracle Traffic DirectorおよびOracle Site Guardが含まれます。この統合ソリューションの主な利点は迅速なフェイルオーバーまたはスイッチオーバー、アプリケーション全体の可用性の向上、データの整合性、人的エラーおよびリスクの軽減、作業のリカバリ、およびリアルタイム・データのローカル・アクセスです。

継続的可用性の用語

Oracle WebLogic Server Continuous Availabilityに適用される共通用語の包括的なリストについて学習します。

• アクティブ/アクティブ: アクティブ/アクティブ・ソリューションは、スケーラビリティの向上および高可用性の提供のために、複数のアクティブなサーバーをデプロイします。アクティブ/アクティブ・デプロイでは、すべてのインスタンスは、同時にリクエストを処理します。ドメイン全体またはサイト全体に障害が発生するとき、同一サイトまたは別サイトのいずれかに配置された別ドメイン内のアクティブ・サーバーによってトランザクションをリカバリできます。

• アクティブ/パッシブ: アクティブ/パッシブ・ソリューションには、アクティブな(本番)サイトとは地理的に異なる位置で、スタンバイ・サイトを設定してペアにする作業が含まれます。本番サイトとスタンバイ・サイトの両方で対称トポロジおよび容量を構成することをお薦めしますが、スタンバイ・サイトは本番サイトと比較して、サービスやリソースの数が同じか下回る場合があります。ノード数や容量が異なると、機能レベルおよびパフォーマンス・レベルで不整合が発生する可能性があります。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データが、定期的にスタンバイ・サイトにレプリケートされます。通常の場合、スタンバイ・サイトはパッシブ・モードであり、本番サイトが使用できないときに起動されます。通常、このモデルは、2つのサイトがWAN経由で接続されていて、ネットワーク待機時間の関係で2つのサイトにまたがるクラスタリングができない場合に採用されます。

• WebLogic Serverクラスタ: WebLogic Serverクラスタとは、同時に稼働し、協調動作によってスケーラビリティと信頼性の向上を実現する、WebLogic Serverの複数のサーバー・インスタンスの集合です。クラスタでは、管理対象サーバーごとに、ほとんどのリソースおよびサービスがまったく同じようにデプロイされるため、フェイルオーバーとロード・バランシングが可能になります。

• Coherenceクラスタ: Coherenceクラスタは、Coherenceを実行する、Coherenceサーバーと呼ばれるJava Virtual Machines (JVM)プロセスの集合です。Coherenceクラスタは、アプリケーションのスケーラビリティ、可用性およびパフォーマンスを向上させるためにデータをメモリー内に分散する、複数のCoherenceサーバー・インスタンスで構成されています。アプリケーション・データは自動的かつ透過的に分散され、クラスタ・メンバーをまたがってバックアップされます。

• ストレッチ・クラスタ:: ストレッチ・クラスタとは、地理的に近い範囲内のデータ・センターにノードを拡張できるクラスタのことで、通常はサイト間の比較的に低遅延のネットワーキングが保証されています。ストレッチ・クラスタは、拡張クラスタとも呼ばれています。

• 高可用性: 高可用性とはシステムまたはデバイスを必要なときに使用可能にする能力です。高可用性アーキテクチャにより、サービスを中断することなく、ユーザーはシステムにアクセスできます。高可用性システムをデプロイすることで、システムの停止時間つまり使用不可の時間が最小化され、システムの稼働時間つまり使用可能な時間が最大化されます。

• 障害時リカバリ: 障害時リカバリとは、自然災害などによる計画外の本番サイトの機能停止に対する防護機能です。アプリケーションとデータを地理的に離れたスタンバイ・サイトに置くリカバリ戦略を使用します。

• スイッチオーバー: スイッチオーバーとは、本番サイトとスタンバイ・サイトのロールを逆にするプロセスです。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のスタンバイ・サイトが新しい本番サイトになり、現在の本番サイトが新しいスタンバイ・サイトになります。

• フェイルオーバー: フェイルオーバーとは、(たとえば本番サイトに障害が発生したことなどが原因で)本番サイトが突然使用できなくなった後で、現在のスタンバイ・サイトを新しい本番サイトにするプロセスです。

• 遅延: 遅延とは、あるクラスタから別のクラスタにパケットが移動するためにかかる時間で、サイト間の経路の長さおよびその間の層を含む多くのことがらの要因である可能性があります。通常、遅延はtracerouteまたはpingなどのユーティリティを使用してテスト・パケットをサイト間に送信することにより決定されます。遅延またはラウンドトリップ時間(RTT)は、システムにアクセスするときにユーザーが経験するレスポンス時間に直接的な影響があります。高遅延の影響は、システム上のユーザーがひとりのみの場合でも見られます。

• メトロポリタン・エリア・ネットワーク(MAN): MANとは、都市またはキャンパス全体に広がるテレコミュニケーションまたはコンピュータ・ネットワークです。IEEE 802.6標準に指定されたデータ通信用のMAN標準は、分散キュー・デュアルバス(DQDB)と呼ばれます。DQDBを使用すると、ネットワークは最大で20マイル(30 km)の長さに及び、34–155 Mbit/sの速度で稼働できます。MANではストレッチ・クラスタ・トポロジが適しています。

• ワイド・エリア・ネットワーク(WAN): WANとは、地理的に遠く離れた、様々なLAN、MANおよびその他のローカルのコンピュータ・ネットワーク・アーキテクチャの間に及ぶテレコミュニケーションまたはコンピュータ・ネットワークです。ワイド・エリア・ネットワークは、専用電話回線を使用して確立されることがよくあります。WANの距離および遅延は、構成できるトポロジのタイプを決定する際に考慮に入れる必要があります。

継続的可用性の主な機能

Oracle WebLogic Server Continuous Availabilityは計画的アップグレードや予期せぬ障害の際に、最大限の可用性、信頼性およびアプリケーションの安定性を提供します。Oracle WebLogic Server、Oracle CoherenceおよびOracle Fusion Middlewareの既存の高可用性機能に作成されます。

継続的可用性は、次に示す項で説明している主な機能をサポートします。

• 自動クロスサイトXAトランザクション・リカバリ

• WebLogic Serverゼロ・ダウンタイム・パッチ適用

• WebLogic Serverマルチテナントのライブ・リソース・グループ移行

• Coherenceフェデレーテッド・キャッシュ

• Coherence GoldenGate HotCache

• Oracle Traffic Director

• Oracle Site Guard

自動クロスサイトXAトランザクション・リカバリ

自動クロスサイトXAトランザクション・リカバリは、ドメイン全体、あるいは別ドメインまたは別サイトでサーバーが実行しているサイト全体にまたがる、XAトランザクションの自動リカバリを提供します。クロスサイト・トランザクション・リカバリはリース・フレームワークを使用してクロスサイト・リカバリを自動化しています。リース設計は、クラスタ内でのトランザクション・リカバリ・サービス(TRS)移行のデータベース・リースの既存のモデルに従います。

ノート:

自動クロスサイトXAトランザクション・リカバリは、WebLogic Server 12.2.1.4.0で非推奨になっており、次のリリースで削除されます。

アクティブ/アクティブ・アーキテクチャでは、同一サイトまたは別サイトのいずれかに配置された別ドメインでアクティブ・サーバーを稼働することで、ドメイン全体またはサイト全体の障害発生時にトランザクションをリカバリできます。アクティブ/パッシブ・アーキテクチャでは、別の場所にあるパッシブ(スタンバイ)・サイトのサーバーを、本番サイトが使用できないときに起動できます。

詳細は、Oracle WebLogic Server JTAアプリケーションの開発の複数サイトまたはデータ・センターにまたがるトランザクション・リカバリを参照してください。クロスサイトXAトランザクション・リカバリを継続的可用性アーキテクチャで使用する場合の考慮事項は、「自動クロスサイトXAトランザクション・リカバリ」を参照してください。

自動クロスサイトXAトランザクション・リカバリは、「WebLogic Serverの高可用性機能」で説明されているWebLogic Serverの高可用性機能も活用します。

WebLogic Serverゼロ・ダウンタイム・パッチ適用

WebLogic Serverゼロ・ダウンタイム・パッチ適用(ZDTパッチ適用)は、停止時間またはセッションの消失を回避しながら、パッチの公開を編成するための自動メカニズムを提供します。これによって、パッチの適用中に可用性および予測性が求められる重要なアプリケーションのリスクと停止時間が軽減されます。

定義したワークフローを使用することで、手動操作をほとんど行わずにドメイン内の任意の数のノードをパッチ適用または更新することができます。変更は1回に1ノードに対して公開されるため、ノードが更新されるまでOracle Traffic Directorなどのロード・バランサが受信トラフィックを残りのノードにリダイレクトできます。

ZDTカスタム・フック機能は、ロールアウトを変更するために追加コマンドを実行できるパッチ適用ワークフローで拡張ポイントと呼ばれる特定のポイントを識別します。ユーザーは、管理サーバー・ノードまたはリモート・ノードのいずれかで実行されるワークフローの事前定義済拡張ポイントの1つ以上で拡張の実行を指定できます。『ゼロ・ダウンタイム・パッチ適用ワークフローの管理』のカスタム・フックを使用したワークフローの変更に関する項を参照してください。

ロールアウト処理中にCoherenceデータの高可用性を維持しながら、ZDTパッチ適用を使用してCoherenceアプリケーションを更新できます。

ZDTパッチ適用の機能の概要については、『ゼロ・ダウンタイム・パッチ適用ワークフローの管理』の「ダウンタイムなしのパッチ適用の概要」を参照してください。

WebLogic Serverマルチテナントのライブ・リソース・グループ移行

WebLogic Serverマルチテナント環境では、アプリケーション・ユーザーに影響を及ぼさずに、あるクラスタ/サーバーからドメイン内の別のクラスタ/サーバーへ実行中のパーティション・リソース・グループを移行できます。リソース・グループを移行する主な利点は、計画的イベントのアプリケーション停止時間が排除されることです。

ノート:

WebLogic Server Multitenantドメイン・パーティションおよびリソース・グループは、WebLogic Server 12.2.1.4.0で非推奨になっており、次のリリースで削除されます。

リソース・グループは、(通常は)デプロイ可能な関連リソースのコレクションです(たとえば、Java EEアプリケーションとそのデータ・リソース、Java Message Service (JMS)アーティファクト、およびアプリケーションが使用する他のリソースなどです)。リソース・グループを移行する場合、リソース・グループが使用している仮想ターゲットを、ある物理ターゲット(クラスタ/サーバー)から別の物理ターゲットに変更します。移行後、仮想ターゲットは新しい物理ターゲット(クラスタ/サーバー)を示します。

リソース・グループおよび移行の詳細は、Oracle WebLogic Server Multitenantの使用の次の項を参照してください。

• リソース・グループの構成

• リソース・グループの移行: 主なステップおよびWLSTの例

Coherenceフェデレーテッド・キャッシュ

Oracle Coherenceフェデレーテッド・キャッシュ機能は、複数の地理的に分散したクラスタにまたがってキャッシュ・データを非同期にレプリケートします。キャッシュされたデータがクラスタ間でレプリケートされることで冗長性、オフサイト・バックアップ、および地理的に異なる場所にいるアプリケーション・ユーザーに対する複数アクセス・ポイントが提供されます。

フェデレーテッド・キャッシュでは多彩なレプリケーション・テクノロジがサポートされています。これには次のものがあります。

• アクティブ/パッシブ: アクティブ・クラスタからパッシブ・クラスタにデータをレプリケートします。パッシブ・サイトは読取り専用操作とオフサイト・バックアップをサポートしています。

• アクティブ/アクティブ: アクティブ・クラスタ間でデータをレプリケートします。一方のアクティブ・クラスタに置かれるデータは、もう一方のアクティブ・クラスタでレプリケートされます。異なるサイトのアプリケーションはローカル・クラスタ・インスタンスへのアクセスを保有します。

• ハブ・アンド・スポーク: 単一ハブ・クラスタから複数のスポーク・クラスタへデータをレプリケートします。ハブ・クラスタはデータの送信のみ可能で、スポーク・クラスタはデータの受信のみ可能です。このトポロジには複数の地理的に分散したクラスタのコピーが必要です。各スポーク・クラスタは読取り専用を実行するためにローカル・アプリケーションで使用できます。

Oracle Coherenceの管理のクラスタ間のキャッシュのフェデレートを参照してください。

Coherence GoldenGate HotCache

Oracle Coherence GoldenGate HotCache機能は、リアルタイムでキャッシュ内のデータベース変更を検出して反映します。データベースに対するサード・パーティの更新により、Coherenceアプリケーションで、最新でない失効した可能性のあるデータが使用されることがあります。Coherence GoldenGate HotCacheは、リアルタイムでデータベースをモニタリングし、変更をCoherenceキャッシュにプッシュすることでこの問題を解決します。これには、失効したデータのみを処理する効率的なプッシュ・モデルが採用されています。データベースに変更が行われる際にデータがプッシュされるため、待機時間の短さが保証されます。

最大可用性アーキテクチャでは、フェイルオーバー中にデータベースが二次サイトにレプリケートされると、GoldenGate HotCacheを使用してデータベース変更がキャッシュに反映されます。

Oracle Coherenceの統合のOracle Coherence GoldenGate HotCacheとの統合を参照してください。

Oracle Traffic Director

ノート:

Oracle Traffic Directorは、WebLogic Server 12.2.1.4.0では非推奨となり、次のリリースで削除されます。

Oracle Traffic Directorは、ネットワーク上のアプリケーション・サーバーおよびWebサーバーへのHTTP、HTTPSおよびTCPトラフィックをルーティングする、高速かつ信頼性および拡張性の高いソフトウェア・ロード・バランサです。クライアントから受信したリクエストの、指定されたロード・バランシング・メソッドに基づく使用可能サーバーへの分散、指定されたルールに基づくリクエストのルーティング、頻繁にアクセスされるデータのキャッシュ、トラフィックの優先付け、およびサービス品質の制御を行います。Oracle Traffic Directorはレイヤー7のソフトウェア・ロード・バランサで、グローバル・ロード・バランサのかわりになるものではありません。

Oracle Traffic Directorのアーキテクチャでは、大量のアプリケーション・トラフィックを低遅延で処理できます。高可用性を図るために、アクティブ/パッシブまたはアクティブ/アクティブのいずれかのフェイルオーバーに対するOracle Traffic Directorインスタンスのペアを設定できます。ネットワークのへのトラフィック量の増大に伴い、リクエストのルーティング先となるバックエンド・サーバーを追加してOracle Traffic Directorを再構成することで、環境を簡単に拡張できます。

Oracle Traffic DirectorとContinuous Availabilityの機能(ゼロ・ダウンタイム・パッチ適用およびライブ・パーティション移行など)は強固に統合され、ローリング・アップグレード・プロセス中またはパーティション移行中にアプリケーションにゼロ・ダウンタイムを提供します。この統合により、変更を必要とせずにアプリケーションで高可用性が可能になります。

Oracle Traffic Directorを継続的可用性アーキテクチャで使用する場合の考慮事項は、「Oracle Traffic Director」を参照してください。Oracle Traffic Directorに関する一般情報については、『Oracle Traffic Directorの管理』の「はじめに」を参照してください。

Oracle Site Guard

Oracle Enterprise Manager Cloud ControlのコンポーネントであるOracle Site Guardは障害時リカバリ・ソリューションであり、管理者はサイトの完全なスイッチオーバーやフェイルオーバーを自動化することでエンタープライズ・デプロイメントの停止時間を最小限に抑えることができます。Oracle Site Guardはサイト・レベルで動作するので、アプリケーション、ミドルウェアおよびデータベースなどの個々のサイト・コンポーネントに対して面倒な障害時リカバリを手動で実行する必要がなくなります。本番サイト全体のトラフィックは、単一の操作でスタンバイ・サイトにリダイレクトできます。

管理者には、データベース、アプリケーションおよびストレージ・レプリケーションなどの領域での特別な知識またはドメインの専門知識は不要です。Oracle Site Guardを使用することにより、本番サイトに影響を与えることなく、障害時リカバリの準備状況を継続して監視できます。

Oracle Site Guard構成は、Enterprise Managerコマンド行インタフェース(EMCLI)または互換バージョンのOracle Enterprise Manager Cloud Control (Cloud Control)のいずれかを使用して管理できます。

『Oracle Site Guard管理者ガイド』のOracle Site Guardの概要に関する項を参照してください。

WebLogic ServerおよびCoherenceの付加価値の高可用性機能

Oracle Continuous Availabilityは、クラスタリング、シングルトン・サービス、セッション・レプリケーション、Coherence永続性、CoherenceクラスタなどのWebLogic ServerおよびCoherenceの高可用性機能を活用します。

「継続的可用性の主な機能」で説明した機能以外に、Oracle Continuous Availabilityは次の項で説明する主な機能も活用します。

WebLogic Serverの高可用性機能

次のWebLogic Serverの機能をOracle Continuous Availabilityの機能と組み合せて使用し、最高レベルの可用性を達成できます。

• クラスタリング: WebLogic Serverクラスタは、ドメイン内で同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。「クラスタリング」を参照してください。

• シングルトン・サービス: サーバーおよびサービスの移行、永続データ・ストアおよびリースなどのサービスにより、JMSおよびJTAなどのシングルトン・サービスのWebLogic Serverクラスタでの可用性が高まります。「シングルトン・サービス」を参照してください。

• セッション・レプリケーション: セッション・レプリケーションは、クラスタ内の異なるサーバー・インスタンスにまたがるセッションに格納されたデータをレプリケートするために使用される、WebLogic Serverクラスタの機能です。「セッション・レプリケーション」を参照してください。

• トランザクションおよびデータソースの機能:

  • Oracle Real Application Clusters (Oracle RAC)ノードの迅速な障害検出と、継続的接続のための残りノードへのフェイルオーバーを提供するために高速接続フェイルオーバーを使用するActive GridLinkデータ・ソース。Active Gridlinkを継続的可用性アーキテクチャで使用する場合の考慮事項は、「データソース」を参照してください。Oracle WebLogic Server JDBCデータ・ソースの管理のActive GridLinkデータ・ソースの使用を参照してください。

  • サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納する、データベース内のトランザクション・ログ(JDBC TLog)。WebLogic Serverでは、システムのクラッシュやネットワーク障害からのリカバリ時にTLogが使用されます。Oracle WebLogic Server JTAアプリケーションの開発のトランザクション・ログ・ファイルを使用したトランザクションのリカバリを参照してください。

  • TLogストアへのトランザクション・チェックポイントの書込みをなくす、トランザクションTLog書込みなし(No TLog)。Oracle WebLogic Server JTAアプリケーションの開発のトランザクションTLog書込みなしのXAトランザクションを参照してください。

  • 1つの非XAリソースがXAと同じACID(原子性、整合性、分離性、耐久性)保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションである、ロギング・ラスト・リソース(LLR)によるトランザクションの最適化。Oracle WebLogic Server JTAアプリケーションの開発のロギング・ラスト・リソース・トランザクションの最適化を参照してください。

    これらの機能はデータベースをレプリケートするOracle Data Guardと連携して、リカバリに必要なトランザクション・ログの可用性を高めます。Oracle Data Guard概要および管理のOracle Data Guardの概要を参照してください。

Oracle Fusion Middlewareにおける高可用性の詳細は、Oracle Fusion Middleware高可用性ガイドの高可用性の概要を参照してください。

Coherence永続性およびクラスタ

Coherence永続性は、Coherence分散キャッシュの永続性およびリカバリを管理する、一連のツールおよびテクノロジです。致命的障害や、計画的メンテナンスによるクラスタ再起動の後に迅速なリカバリができるように、キャッシュされたデータは保持されます。永続性とフェデレーテッド・キャッシュは必要に応じて共に使用できます。Oracle Coherenceの管理の永続キャッシュを参照してください。

アプリケーションがCoherenceキャッシュへのエントリを要求するとき、エントリがキャッシュ内に存在せず、データベース内に存在する場合、Coherenceはキャッシュをデータベースの値で更新します。これをリードスルー・キャッシングと呼びます。Oracle Coherenceでのアプリケーションの開発のリードスルー・キャッシングを参照してください。

Coherenceクラスタは、アプリケーションのスケーラビリティ、可用性およびパフォーマンスを向上させるためにデータをメモリー内に分散する、複数のCoherenceサーバー・インスタンスで構成されています。アプリケーション・データは自動的かつ透過的に分散され、クラスタ・メンバーをまたがってバックアップされます。Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成と管理を参照してください。

Oracle Databaseの高可用性およびディザスタ・リカバリ

Oracle WebLogic Serverは、Oracle Databaseの高可用性(HA)およびディザスタ・リカバリの機能との統合を強力にサポートしています。これらのHAおよびディザスタ・リカバリの機能の統合により、データベース・アクセス時間が最小化され、その一方で、接続パフォーマンスとアプリケーションの可用性の両方を最大化する高度なプール管理機能への透過的アクセスが可能になります。

ノート:

このリリースのWebLogic Serverでサポートされる特定のデータベース・バージョンの最新の詳細情報は、Oracle Technology Networkの「Oracle Fusion Middlewareのサポートされるシステム構成」のページを参照してください。

Oracle WebLogic ServerおよびCoherenceは、この項で説明されているHAデータベース機能を利用します。これらの全製品の統合によって、次のようにOracle Databaseのフェイルオーバーおよびスイッチオーバーの管理および編成に寄与し、高速かつ自動的なデータベースのフェイルオーバーが実現します。

• Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。1つ以上のスタンバイ・データベースを作成、維持、管理、モニターして、本番のOracleデータベースが障害やデータ破損に耐えられるようにするための包括的なサービス・セットが用意されています。Oracle Data Guardでは、これらのスタンバイ・データベースが、トランザクション的に一貫性のあるプライマリ・データベースのコピーとして維持されます。計画的または計画外の障害によりプライマリ・データベースが使用できなくなると、Oracle Data Guardは任意のスタンバイ・データベースを本番ロールに切り替えることができるため、障害に関連する停止時間が最短に抑えられます。Oracle Data Guard概要および管理のOracle Data Guardの概要を参照してください。

• Oracle Active Data Guardは、ミッション・クリティカルなOracle Databaseに対する単一点障害をなくす、総合的なソリューションです。これは、同期化された本番データベース(プライマリ)の物理レプリカ(スタンバイ)を維持することによって、データ損失および停止時間を防止します。停止が発生した場合、クライアント接続は素早くスタンバイおよび再開サービスにフェイルオーバーされます。Active Data Guardは、Oracle Databaseとの深い統合、障害分離および独自のOracle対応のデータ検証により、最高レベルのデータ保護を提供します。プライマリに影響するシステムおよびソフトウェアの不具合、データの破損および管理者の過失は、スタンバイに反映されません。読取り専用ワークロードおよびバックアップをアクティブなスタンバイ・データベースに直接誘導することにより、無駄な冗長性をなくし、出資に対して高い利益が得られます。Oracle Data Guard概要および管理のOracle Data Guardスタート・ガイドを参照してください。

• Oracle Data Guard Brokerでは、これらのプライマリ・データベースとスタンバイ・データベースを統合ユニットとしてまとめて管理およびモニターできるようにブローカ構成として論理的にグループ化されます。これによって通知がWebLogic Active GridLinkに送信されると、そこでフェイルオーバー・サイトのデータベースへの新規接続が行われ、Oracle Clusterwareと連携してロールベース・サービスがフェイルオーバーされます。Data Guard BrokerのOracle Data Guard Brokerの概要を参照してください。

• Oracle Real Application Clusters (Oracle RAC)はクラスタ化されたOracle Databaseで、データベースとも呼ばれる共有のデータ・ファイルのセットに対して、クラスタの異なるサーバー上で複数のデータベース・インスタンスを実行できます。データベースは複数のハードウェア・システムにまたがっていますが、アプリケーションには単一の一元的データベースのように見えます。Oracle Real Application Clusters管理およびデプロイメント・ガイドのOracle RACの概要を参照してください。

• Oracle Clusterwareは、Oracle RACデータベースのインスタンスの可用性を管理します。プライマリ・データベースを使用可能な状態に保つために、障害が発生したインスタンスを迅速にリカバリしようとします。障害が発生したインスタンスをOracle Clusterwareがリカバリできない場合、ブローカは自動的に1つ少なくなったインスタンスで引き続き動作します。プライマリ・データベースの最後のインスタンスに障害が発生すると、ブローカは指定されたスタンバイ・データベースにフェイルオーバーする手段を提供します。プライマリ・データベースの最後のインスタンスに障害が発生し、ファスト・スタート・フェイルオーバーが有効化されている場合は、事前決定済のスタンバイ・データベースへのフェイルオーバーが自動的に実行され、継続的な高可用性を提供できます。Oracle Clusterware管理およびデプロイメント・ガイドのOracle Clusterwareの概要を参照してください。

• Oracle GoldenGateは高パフォーマンスのソフトウェア・アプリケーションで、ログ・ベースの双方向データ・レプリケーションを使用して、リアルタイムの取得、変換、ルーティング、異機種システム間のデータベース・トランザクションの配信をします。Oracle GoldenGateはデータベースをアクティブ/アクティブ・モードにできます。Oracle GoldenGateを使用するアプリケーションは、Oracle GoldenGateレプリケーションの非同期特性が原因のデータ損失を許容する必要があります。『Oracle GoldenGateの管理』のOracle GoldenGateの管理の概要に関する項を参照してください。

• Oracle Database Global Data Services (GDS)は、データベース・サービスの配信をグローバル・スケールで合理化するものであり、MAA環境にデータベースをデプロイする際のキーとなります。これらの技術により、データ・センター内およびデータ・センターをまたがるロード・バランシングの実行の間、レプリケーションおよびフェイルオーバーを監視し、リソース使用を最適化し、分散データベース環境におけるデータベース管理業務の効率を上げます。GDSは、Oracle Real Application Clusters (RAC)間でGlobal Serviceを有効にし、Oracle Data Guard、Oracle GoldenGate、またはその他のレプリケーション技術を介して相互接続された単一インスタンスのOracleデータベースを有効にすることで機能します。この分散インフラストラクチャに対するクライアント・アクセスは完全に透過的です。GDSの実装は、最小限の変更で容易にOracle WebLogic Serverに適用できます。『Oracle Database Global Data Services概要および管理ガイド』のGlobal Data Servicesの概要に関する項を参照してください。

• Application Continuity (AC)はOracle RAC、Oracle RAC One NodeおよびOracle Active Data Guardオプションで使用可能であり、リカバリ可能な機能停止に続いてインフライト・データベース・セッションをリカバリすることで、エンド・ユーザーおよびアプリケーションから機能停止をマスクします。Application Continuityは、リカバリ可能なエラーがデータベース・セッションを使用不可にしたときに、中断せずに迅速な方法でデータベース・リクエストのリプレイを可能にします。リクエストには、データベースへのトランザクション・コールおよび非トランザクション・コールと、クライアントまたは中間層でローカルに実行されたコールが含まれることがあります。リプレイが成功した後、アプリケーションはそのデータベース・セッションが停止した位置から続行できます。『Real Application Clusters管理およびデプロイメント・ガイド』のアプリケーション・コンティニュイティの確保に関する項を参照してください。

WebLogic Server Active GridLinkは、アプリケーション・コンティニュイティやグローバル・データ・サービスなどのOracle Database機能を統合することにより、最高の可用性を提供します。Application Continuityは、計画外停止に遭遇した場合、トランザクションを再度実行します。エンドユーザー・アプリケーションはエラーを受け取らず、停止があったことを知ることすらありません。Active GridLink、Application ContinuityおよびData Guardは、高可用性環境における計画済および計画外のデータベース停止への保護を提供します。

これらの技術により、データ・センター内およびデータ・センターをまたがるロード・バランシングの実行の間、レプリケーションおよびフェイルオーバーを監視し、リソース使用を最適化し、分散データベース環境におけるデータベース管理業務の効率を上げます。