1. Oracle WebLogic ServerおよびCoherenceのための高可用性とディザスタ・リカバリ・ガイド
  2. WebLogic Serverの高可用性およびディザスタ・リカバリの概要

1 WebLogic Serverの高可用性およびディザスタ・リカバリの概要

Oracle WebLogic ServerをOracle CoherenceおよびOracle Databaseと組み合せることで、地理的に分散した場所のデータ・センターにわたって最大可用性アーキテクチャアーキテクチャ(MAA)を構築するために使用できる機能が提供されます。
  • WebLogic Serverの高可用性およびディザスタ・リカバリについて
    高可用性とディザスタ・リカバリの両方のソリューションを使用することで、アプリケーションを必要なタイミングで確実に使用できます。
  • 用語
    Oracle WebLogic ServerおよびCoherenceの高可用性とディザスタ・リカバリに適用される一般的な用語の包括的なリストを学習します。
  • WebLogic Serverの高可用性のコンポーネントおよび機能
    Oracle WebLogic Serverには、Oracle CoherenceおよびOracle Databaseの高可用性機能とともに動作するコンポーネントと機能が備わっており、計画的アップグレードや予期せぬ障害の際に、最大限の可用性、信頼性およびアプリケーションの安定性を提供します。
  • Coherenceの高可用性のコンポーネントおよび機能
    Oracle Coherenceには、Oracle WebLogic ServerおよびOracle Databaseの高可用性機能とともに動作するコンポーネントと機能が備わっており、計画的アップグレードや予期せぬ障害の際に、最大限の可用性、信頼性およびアプリケーションの安定性を提供します。
  • Oracle Databaseの高可用性およびディザスタ・リカバリ
    Oracle WebLogic Serverは、Oracle Databaseの高可用性(HA)およびディザスタ・リカバリの機能との統合を強力にサポートしています。これらのHAおよびディザスタ・リカバリの機能の統合により、データベース・アクセス時間が最小化され、その一方で、接続パフォーマンスとアプリケーションの可用性の両方を最大化する高度なプール管理機能への透過的アクセスが可能になります。
  • ロード・バランサ
    ロード・バランサは、Webサーバーの1つが停止した場合に残りの稼働中のWebサーバーにリクエストがルーティングされるようにすることで、高可用性を実現します。
  • サポートされているMAAアーキテクチャ
    WebLogic Serverでは、3つの主要な最大可用性アーキテクチャ(MAA)ソリューションをサポートしており、複数のデータ・センターにわたるダウンタイムに対してOracle WebLogic Serverシステムを保護できます。
  • 潜在的な障害シナリオ
    潜在的な障害シナリオには、予想外のサイト全体またはサイトの一部の障害からメンテナンス機能停止まで含まれます。

WebLogic Serverの高可用性およびディザスタ・リカバリについて

高可用性とディザスタ・リカバリの両方のソリューションを使用することで、アプリケーションを必要なタイミングで確実に使用できます。

一般的に、高可用性ソリューションは1つのデータ・センターにおける冗長性を提供します。ただし、データ・センターの本番デプロイメントでは、予測不可能な障害や天災から保護する必要もあります。ディザスタ・リカバリ・ソリューションは、本番サイトとは地理的に異なる場所にスタンバイ・サイトを設定することで、アプリケーションおよびデータのリカバリ戦略を提供します。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データが、定期的にスタンバイ・サイトにレプリケートされます。

Oracle WebLogic ServerおよびCoherenceには、サーバー・クラスタリング、サーバー移行、クラスタ統合、Active GridLink、ロード・バランシング、フェイルオーバー、バックアップおよびリカバリ、ローリング・アップグレード、ローリング構成変更など、豊富な高可用性機能セットが組み込まれており、デプロイメントを計画外ダウンタイムから保護し、計画ダウンタイムを最小限に抑えます。構成に含まれているOracleデータベースの障害保護は、Oracle Data GuardおよびOracle Real Application Clusters (Oracle RAC)を通じて提供されます。

Oracle WebLogic Server、Oracle CoherenceおよびOracle Databaseの高可用性およびディザスタ・リカバリ機能を使用して、地理的に分散した場所のデータ・センターにまたがる最大可用性アーキテクチャ(MAA)を設計および構築できます。Oracle Maximum Availability Architecture (MAA)は、計画的停止に対するダウンタイムを短縮し、計画外停止を防止、検出およびリカバリするOracleの包括的なアーキテクチャです。これらの統合ソリューションの主な利点は、迅速なフェイルオーバーまたはスイッチオーバー、アプリケーション全体の可用性の向上、データの整合性、人的エラーおよびリスクの軽減、作業のリカバリ、およびリアルタイム・データのローカル・アクセスです。高可用性のベスト・プラクティスのブループリント(https://www.oracle.com/database/technologies/high-availability/maa.html)を参照してください。

親トピック: WebLogic Serverの高可用性およびディザスタ・リカバリの概要

用語

Oracle WebLogic ServerおよびCoherenceの高可用性とディザスタ・リカバリに適用される一般的な用語の包括的なリストを学習します。

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

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

  • ドメイン・ペア: ドメイン・ペアは、アクティブ・ドメインとパッシブ・ドメインで構成されます。WebLogicドメイン・ペアを含むアクティブ/アクティブ・アプリケーション・インフラストラクチャ層では、インフラストラクチャ層が2つのサイトにまたがり、各サイトにプライマリ・アクティブ・ドメインとセカンダリ・パッシブ・ドメインがあります。各サイトのプライマリ・ドメインは独立したドメインであり、対称トポロジで構成する必要はありませんが、ドメイン・ペアは対称である必要があります。たとえば、サイト1でドメインAがプライマリ(アクティブ)ドメインであり、サイト2でドメインBがプライマリ(アクティブ)ドメインである場合、サイト1でセカンダリ(パッシブ)ドメインとしてドメインBが存在し、サイト2でセカンダリ(パッシブ)ドメインとしてドメインAが存在する必要があります。つまり、ドメイン自体は一意にできても、各サイトのドメイン・ペアは対称である必要があります。

  • 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の距離および遅延は、構成できるトポロジのタイプを決定する際に考慮に入れる必要があります。

親トピック: WebLogic Serverの高可用性およびディザスタ・リカバリの概要

WebLogic Serverの高可用性のコンポーネントおよび機能

Oracle WebLogic Serverには、Oracle CoherenceおよびOracle Databaseの高可用性機能とともに動作するコンポーネントと機能が備わっており、計画的アップグレードや予期せぬ障害の際に、最大限の可用性、信頼性およびアプリケーションの安定性を提供します。

これらのWebLogic Serverのコンポーネントと機能については、次の各項を参照してください。

  • WebLogic Serverゼロ・ダウンタイム・パッチ適用
  • クラスタリング
    WebLogic Serverクラスタでは、作業負荷を複数のWebLogic Serverインスタンスに分散することにより、アプリケーションにスケーラビリティと信頼性が提供されます。
  • シングルトン・サービス
    シングルトン・サービスとは、常にクラスタの1つの管理対象サーバー・インスタンス上のみで実行する必要のあるサービス(JMSやJTAトランザクション・リカバリ・システムなど)のことです。WebLogic Serverでは、シングルトン・サービスを自動的に監視したり、あるサーバー・インスタンスから別のサーバー・インスタンスに移行したりできます。
  • セッション・レプリケーション
    セッション・レプリケーションはWebLogic Serverクラスタの機能の1つであり、クラスタ内の異なるサーバー・インスタンスにわたってセッションに格納されたデータをレプリケートするために使用します。
  • トランザクションおよびデータ・ソースの機能
    Active Gridlinkデータ・ソース、JDBC TLogおよびNo TLog、ロギング・ラスト・リソースなどのWebLogic Server機能を使用すると、WebLogic Server構成に高可用性を提供できます。

親トピック: WebLogic Serverの高可用性およびディザスタ・リカバリの概要

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

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

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

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

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

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

親トピック: WebLogic Serverの高可用性のコンポーネントおよび機能

クラスタリング

WebLogic Serverクラスタでは、作業負荷を複数のWebLogic Serverインスタンスに分散することにより、アプリケーションにスケーラビリティと信頼性が提供されます。

スケーラビリティのために、WebLogic Serverクラスタにデプロイされたアプリケーションの能力を、必要に応じて動的に増強できます。サービスを中断させることなく、つまり、クライアントおよびエンド・ユーザーへの影響なしにアプリケーションを動作させ続けながら、クラスタにサーバー・インスタンスを追加できます。

WebLogic Serverクラスタでは、サーバー・インスタンスで障害が発生してもアプリケーションの処理を継続できます。アプリケーション・コンポーネントのクラスタリングは、そのコンポーネントをクラスタ内の複数のサーバー・インスタンスにデプロイすることによって行います。そのため、あるコンポーネントが動作しているサーバー・インスタンスに障害が発生した場合、同じコンポーネントがデプロイされている別のサーバー・インスタンスでアプリケーションの処理を継続できます。詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogic Serverのクラスタリングの理解に関する項を参照してください。

親トピック: WebLogic Serverの高可用性のコンポーネントおよび機能

シングルトン・サービス

シングルトン・サービスとは、常にクラスタの1つのインスタンス上のみで実行する必要のあるサービス(JMSやJTAトランザクション・リカバリ・システムなど)のことです。WebLogic Serverでは、シングルトン・サービスを自動的に監視したり、あるサーバー・インスタンスから別のサーバー・インスタンスに移行したりできます。

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

親トピック: WebLogic Serverの高可用性のコンポーネントおよび機能

セッション・レプリケーション

セッション・レプリケーションはWebLogic Serverクラスタの機能の1つであり、クラスタ内の異なるサーバー・インスタンスにわたってセッションに格納されたデータをレプリケートするために使用します。

WebLogic Serverでは、クラスタ内のサーバー間でHTTPセッション・ステートをレプリケートする方法として、インメモリー・レプリケーション、JDBCベースの永続性およびCoherence*Webという3つの方法があります。「セッション・レプリケーション」を参照してください。

親トピック: WebLogic Serverの高可用性のコンポーネントおよび機能

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

Active Gridlinkデータ・ソース、JDBC TLogおよびNo TLog、ロギング・ラスト・リソースなどのWebLogic Server機能を使用すると、WebLogic Server構成に高可用性を提供できます。

  • Active GridLinkデータ・ソースは高速接続フェイルオーバーを使用して、Oracle Real Application Clusters (Oracle RAC)ノードの迅速な障害検出を提供し、継続的な接続のために残りのノードへのフェイルオーバーを提供します。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トランザクションを参照してください。

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

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

親トピック: WebLogic Serverの高可用性のコンポーネントおよび機能

Coherenceの高可用性のコンポーネントおよび機能

Oracle Coherenceには、Oracle WebLogic ServerおよびOracle Databaseの高可用性機能とともに動作するコンポーネントと機能が備わっており、計画的アップグレードや予期せぬ障害の際に、最大限の可用性、信頼性およびアプリケーションの安定性を提供します。

親トピック: WebLogic Serverの高可用性およびディザスタ・リカバリの概要

Coherence永続性およびクラスタ

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

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

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

親トピック: Coherenceの高可用性のコンポーネントおよび機能

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

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

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

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

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

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

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

親トピック: Coherenceの高可用性のコンポーネントおよび機能

Coherence GoldenGate HotCache

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

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

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

親トピック: 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は、高可用性環境における計画済および計画外のデータベース停止への保護を提供します。

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

親トピック: WebLogic Serverの高可用性およびディザスタ・リカバリの概要

ロード・バランサ

ロード・バランサは、Webサーバーの1つが停止した場合に残りの稼働中のWebサーバーにリクエストがルーティングされるようにすることで、高可用性を実現します。

ロード・バランサには、グローバル・ロード・バランサとローカル・ロード・バランサの2つのタイプがあります。ロード・バランサには、Big IP、Cisco、Brocadeなどのハードウェア・デバイスや、ソフトウェア・アプリケーションがあります。

グローバル・ロード・バランサは、同一の論理環境として稼働させる必要があるサイトが複数存在する場合に使用します。これは、事前に定義したルール・セットを基準にして、サイト間のリクエストを分散させることを目的としています。グローバル・ロード・バランサは、通常、ディザスタ・リカバリ・デプロイメントで使用します。

Oracle HTTP Serverなどのローカル・ロード・バランサは、サイト内でトラフィックを分散するために使用します。標準的なデプロイメントでは、高可用性を提供するためにWeb層に2つ以上のOracle HTTP Serverインスタンスが構成されています。『Oracle HTTP Serverの管理』のOracle HTTP Serverの高可用性アーキテクチャとフェイルオーバーに関する考慮事項の項を参照してください。Web層にOracle HTTP Serverを含めることは要件ではなく、アプリケーション層でハードウェア・ロード・バランサからWebLogic Serverインスタンスにトラフィックを直接ルーティングすることもできます。ただし、Web層にはWebLogic Serverインスタンスの障害発生時の高速フェイルオーバーやHTTPリダイレクションといったいくつかの利点があるため、サポートされているMAAアーキテクチャにこれを含めることをお薦めします。

親トピック: WebLogic Serverの高可用性およびディザスタ・リカバリの概要

サポートされているMAAアーキテクチャ

WebLogic Serverでは、3つの主要な最大可用性アーキテクチャ(MAA)ソリューションをサポートしており、複数のデータ・センターにわたるダウンタイムに対してOracle WebLogic Serverシステムを保護できます。

MAAアーキテクチャでは、地理的に分散した場所にデータ・センターが展開されます。Oracle MAAは、Oracleにおける実証済の高可用性テクノロジ、専門家の推奨事項およびお客様の経験に基づくOracleのベスト・プラクティスのブループリントです。MAAの目的は、コストおよび複雑さを最小限に抑えてOracleのお客様にとって最適な高可用性アーキテクチャを実現することです。

WebLogic ServerおよびCoherenceでサポートされているMAAアーキテクチャの詳細および設計上の考慮事項は、次の各トピックを参照してください:

親トピック: WebLogic Serverの高可用性およびディザスタ・リカバリの概要

潜在的な障害シナリオ

潜在的な障害シナリオには、予想外のサイト全体またはサイトの一部の障害からメンテナンス機能停止まで含まれます。

このドキュメントで説明されている設計に関する考慮事項および推奨事項は、次の潜在的障害シナリオに適用されます。

  • 完全サイト障害 - 完全サイト障害では、本番環境の負荷に対応するよう準備されたセカンダリ・サイトにデータベース、中間層アプリケーション・サーバーおよびすべてのユーザー接続をフェイルオーバーします。

  • 部分サイト障害 - このドキュメントの文脈では、部分障害は中間層で発生します。中間層での部分サイト障害は、中間層全体(WebLogic ServerおよびCoherence)、WebLogic Serverのみの障害、Coherenceクラスタ障害、またはOracle HTTP Serverで2つのインスタンスが高可用性のために構成されているときの一方のインスタンス内の障害で構成されることがあります。

  • ネットワークの分断 - サイト間の通信が失敗します。

  • メンテナンス機能停止 - 計画済メンテナンス中にサイトのすべてのコンポーネントが段階的に停止されます。スイッチオーバーがサイトからサイトへと実行されます。

親トピック: WebLogic Serverの高可用性およびディザスタ・リカバリの概要