Oracle® Fusion Middleware

Oracle WebLogic Serverのための継続的可用性

12c (12.2.1.2.0)

E82865-02(原本部品番号:E78002-02)

2016年12月

Oracle Continuous Availabilityの機能および利点、サポートされているアーキテクチャ、さらにサポートされているアーキテクチャでの継続的可用性の機能の使用方法および設計に関する考慮事項と推奨事項について説明するドキュメント。

Oracle Fusion Middleware Oracle WebLogic Serverのための継続的可用性, 12c (12.2.1.2.0)

E82865-02

Copyright (C) 2015, 2016, Oracle and/or its affiliates All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 WebLogic Continuous Availabilityの概要

- 継続的可用性とは?

- 継続的可用性の用語

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

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

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

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

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

- Coherence GoldenGate HotCache

- Oracle Traffic Director

- Oracle Site Guard

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

- WebLogic Serverの高可用性機能

- Coherence永続性およびクラスタ

- Oracle Databaseの障害時リカバリ

2 継続的可用性に関してサポートされているMAAアーキテクチャ

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層

- アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタ

3 継続的可用性の設計に関する考慮事項

- 一般的な設計に関する考慮事項および推奨事項

- 潜在的な障害シナリオ

- グローバル・ロード・バランサ

- Oracle Traffic Director

- Web層

- WebLogic Server

- クラスタリング

- シングルトン・サービス

- サーバーおよびサービスの移行

- データ・ストア

- リース

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

- データソース

- セキュリティ

- ストレージ

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

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

- Coherence

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

- Coherence永続キャッシュ

- Coherence GoldenGate Hot Cache

- データベース

- Oracle Enterprise ManagerとOracle Site Guard

- アクティブ/アクティブ・アプリケーション層トポロジの設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の障害シナリオ

- アクティブ/パッシブ・アプリケーション層トポロジの設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の障害シナリオ

- アクティブ/アクティブ・ストレッチ・クラスタ・トポロジの設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの障害シナリオ

はじめに

Oracle WebLogic Server Continuous Availabilityは、地理的に分散した場所にデータ・センターを展開する最大可用性アーキテクチャを構築するための統合ソリューションを提供します。このドキュメントでは、Oracle WebLogic Continuous Availabilityの機能および利点、サポートされているアーキテクチャ、さらにサポートされているアーキテクチャでの継続的可用性の機能の使用方法および設計に関する考慮事項と推奨事項について説明します。

対象読者

このドキュメントは、管理者、開発者、および継続的可用性が要求されるOracle WebLogic Serverの構成と管理を役割とする方を対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracle Fusion Middlewareドキュメントを参照してください。

- ゼロ・ダウンタイム・パッチ適用ワークフローの管理

- WebLogic Server Multitenantの使用

- Oracle WebLogic Server JTAアプリケーションの開発

- Oracle WebLogic Server JDBCデータ・ソースの管理

- Oracle Coherenceの管理

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

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が含まれます。この統合ソリューションの主な利点は迅速なフェイルオーバーまたはスイッチオーバー、アプリケーション全体の可用性の向上、データの整合性、人的エラーおよびリスクの軽減、作業のリカバリ、およびリアルタイム・データのローカル・アクセスです。

継続的可用性の用語

次のリストで、継続的可用性に適用される共通用語について説明します。

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

- アクティブ/パッシブ: アクティブ/パッシブ・ソリューションには、アクティブな(本番)サイトとは地理的に異なる位置で、スタンバイ・サイトを設定してペアにする作業が含まれます。スタンバイ・サイトは本番サイトと比較して、サービスやリソースの数が同じか下回る場合があります。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データが、定期的にスタンバイ・サイトにレプリケートされます。通常の場合、スタンバイ・サイトはパッシブ・モードであり、本番サイトが使用できないときに起動されます。通常、このモデルは、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、Oracle CoherenceおよびOracle Fusion Middlewareの既存の高可用性機能の上に構築され、次の項で説明する主な機能をサポートしています。

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

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

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

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

- Coherence GoldenGate HotCache

- Oracle Traffic Director

- Oracle Site Guard

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

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

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

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

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

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

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

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

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

ゼロ・ダウンタイム・パッチ適用ワークフローの管理のゼロ・ダウンタイム・パッチ適用の概要を参照してください。

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

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

リソース・グループは、(通常は)デプロイ可能な関連リソースのコレクションです(たとえば、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は、ネットワーク上のアプリケーション・サーバーおよび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はWebLogic ServerおよびCoherenceに付属する高可用性機能も活用します。

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

Oracle Continuous Availabilityはこの項で説明されている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と連携してロールベース・サービスがフェイルオーバーされます。Oracle Site Guardは、Oracle Data Guardブローカを使用してデータベースのフェイルオーバーまたはスイッチオーバーを実行します。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の管理for Windows and UNIXのOracle GoldenGateの概要を参照してください。

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

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

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

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

2 継続的可用性に関してサポートされているMAAアーキテクチャ

この章では、サポートされている最大可用性アーキテクチャ(MAA)ソリューションについて説明します。このソリューションは、複数のデータ・センター間における停止時間に対してOracle WebLogic Serverシステムを保護するための継続的可用性の提供に使用できます。また、各アーキテクチャによる継続的可用性の機能の使用方法について説明します。設計上の考慮事項およびベスト・プラクティスについては、「継続的可用性の設計に関する考慮事項」を参照してください。

サポートされているMAAソリューションには次のものがあります。

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層

- アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタ

アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層

図2-1は、アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション・インフラストラクチャ層を使用した、お薦めする継続的可用性ソリューションを示しています。設計上の考慮事項およびベスト・プラクティスについては、「アクティブ/アクティブ・アプリケーション層トポロジの設計に関する考慮事項」を参照してください。

図2-1 アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション・インフラストラクチャ層のトポロジ

このサンプル・トポロジの主な特徴は次のとおりです。

- グローバル・ロード・バランサ。

- 各サイトにあるOracle Traffic Director (OTD)の2つのインスタンス(1つはアクティブ、もう1つはパッシブ)。Oracle Traffic Directorは、Web層またはWebLogic Serverクラスタへのリクエストのバランスをとることができます。

- Oracle HTTP Server (OHS) Web Tier (環境のタイプに基づくオプションのコンポーネント)。

- 2つの異なるデータ・センター(サイト1およびサイト2)で構成された2つの異なるWebLogic Serverドメイン。両方のサイトのドメインは、アクティブで、対称トポロジで構成されている必要があります。アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の設計に関する考慮事項を参照してください。ドメインには次のものが含まれます。

- ドメイン内のWebLogic Server管理サーバーによって管理されている、WebLogic Serverクラスタ内の管理対象サーバー(MS1、MS2およびMS3)の集合。この例では、Active Gridlink (AG)が管理対象サーバーのプライマリ・データベースへの接続に使用されています。(汎用のDataSourceまたはMultiDataSourceが使用可能ですが、高可用性および向上したパフォーマンスが提供されることからActive Gridlinkをお薦めします。)ゼロ・ダウンタイム・パッチ適用(ZDT)によって、ローリング方式による管理対象サーバーのパッチ適用の提示が可能です。

- ドメイン内のWebLogic Server管理サーバーによって管理されている、Coherenceクラスタ(COH1、COH2およびCOH3)。Coherence永続キャッシュは、クラスタで障害が発生した場合に、キャッシュ済データのリカバリに使用されます。Read-ThroughキャッシングまたはCoherence GoldenGateキャッシュが、データベースからのキャッシュの更新に使用されます。

- 構成データ、ローカル・バイナリ、ログなどのファイル・ストア。

- Oracle Enterprise Manager Cloud Controlのコンポーネントであり、サイトのフェイルオーバーおよびスイッチオーバーを編成するOracle Site Guard。

- 2つの異なるデータ・センター内にある2つの別個のOracle RACデータベース・クラスタ。プライマリ・アクティブのOracle RACデータベース・クラスタはサイト1にあります。サイト2にはスタンバイ(パッシブ)読取り専用モードでOracle RACデータベース・クラスタが含まれます。クラスタにはトランザクション・ログ、JMSストアおよびアプリケーション・データが含まれる場合があります。データはOracle Active Data Guardを使用してレプリケートされます。(最高レベルの高可用性が提供されることからOracle RACデータベース・クラスタの使用が推奨されていますが、これは必須ではありません。単一データベースまたはマルチテナント・データベースも使用できます。)

このトポロジは継続的可用性の機能を次のように使用します。

- 自動クロスサイトXAトランザクション・リカバリ: 両方のドメインがアクティブのため、「自動クロスサイトXAトランザクション・リカバリ」で説明されているようにこの機能の全要素を使用できます。このアーキテクチャでは、手動操作を行うことなく、自動的にトランザクションをリカバリできます。

- WebLogicゼロ・ダウンタイム・パッチ適用: 両方のドメインがアクティブのため、各サイトで別個に更新のロールアウトを編成できます。WebLogic Serverゼロ・ダウンタイム・パッチ適用を参照してください。

- Coherenceフェデレーテッド・キャッシュ: 「Coherenceフェデレーテッド・キャッシュ」で説明されているように、この機能の全要素を使用できます。キャッシュされたデータはクラスタ間でレプリケートされます。異なるサイトにあるアプリケーションはローカル・クラスタ・インスタンスへのアクセスを保有します。

- Coherence HotCache: アクティブ・データベースで行われる更新に対して、Coherenceキャッシュをリアルタイムで更新します。Coherence GoldenGate HotCacheを参照してください。

- Oracle Traffic Director: サーバー可用性に応じて、アプリケーション・サーバーへのトラフィック・ルーティングを調整します。各サイトで構成されたインスタンスのペア(アクティブ/アクティブまたはアクティブ/パッシブのいずれか)を保持することで、Oracle Traffic Directorで高可用性を達成できます。Oracle Traffic Directorを参照してください。

- Oracle Site Guard: データベースのみがこのアーキテクチャでスタンバイ・モードにあるため、Oracle Site Guardはデータベースのフェイルオーバーのみを制御します。両方のドメインがアクティブのため、これはアプリケーション・アーキテクチャ層に適用されません。Oracle Site Guardを参照してください。

アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層

図2-2 は、アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション・インフラストラクチャ層を使用した、お薦めする継続的可用性トポロジを示しています。設計上の考慮事項およびベスト・プラクティスについては、「アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層」を参照してください。

図2-2 アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション・インフラストラクチャ層のトポロジ

このトポロジの主な特徴は次のとおりです。

- グローバル・ロード・バランサ。

- 各サイトにあるOracle Traffic Director (OTD)の2つのインスタンス。Oracle Traffic Directorは、Web層またはWebLogic Serverクラスタへのリクエストのバランスをとることができます。サイト1で、1つのインスタンスはアクティブで、もう1つはパッシブです。サイト2では両方ともスタンバイ状態です。サイト2がアクティブになると、そのサイト上のOracle Traffic Directorインスタンスがリクエストのルーティングを開始します。

- Oracle HTTP Server (OHS) Web Tier (環境のタイプに基づくオプションのコンポーネント)。

- 2つの異なるデータ・センター(サイト1およびサイト2)で構成された2つの異なるWebLogic Serverドメイン。サイト1のドメインはアクティブで、サイト2のドメインはスタンバイ(パッシブ)・モードにあります。アクティブ/パッシブ・ドメインの各ペアの構成は同じである必要があります。アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の設計に関する考慮事項を参照してください。
ドメインには次のものが含まれます。

- ドメイン内のWebLogic Server管理サーバーによって管理されている、WebLogic Serverクラスタ内の管理対象サーバー(MS1、MS2およびMS3)の集合。この例では、Active Gridlink (AG)が管理対象サーバーのプライマリ・データベースへの接続に使用されています。(汎用のDataSourceまたはMultiDataSourceが使用可能ですが、高可用性および向上したパフォーマンスが提供されることからActive Gridlinkをお薦めします。)ゼロ・ダウンタイム・パッチ適用(ZDT)によって、ローリング方式による管理対象サーバーのパッチ適用の提示が可能です。

- ドメイン内のWebLogic Server管理サーバーによって管理されている、Coherenceクラスタ(COH1、COH2およびCOH3)。Coherence永続キャッシュは、クラスタで障害が発生した場合に、キャッシュ済データのリカバリに使用されます。Read-ThroughキャッシングまたはCoherence GoldenGateキャッシュが、データベースからのキャッシュの更新に使用されます。

- 構成データ、ローカル・バイナリ、ログなどのファイル・ストア。

- Oracle Enterprise Manager Cloud Controlのコンポーネントであり、サイトのフェイルオーバーおよびスイッチオーバーを編成するOracle Site Guard。

- 2つの異なるデータ・センター内にある2つの別個のOracle RACデータベース・クラスタ。プライマリ・アクティブのOracle RACデータベース・クラスタはサイト1にあります。サイト2にはスタンバイ(パッシブ)読取り専用モードでOracle RACデータベース・クラスタが含まれます。クラスタにはトランザクション・ログ、JMSストアおよびアプリケーション・データが含まれる場合があります。データはOracle Active Data Guardを使用してレプリケートされます。(最高レベルの高可用性が提供されることからOracle RACデータベース・クラスタの使用が推奨されていますが、これは必須ではありません。単一データベースまたはマルチテナント・データベースも使用できます。)

このアーキテクチャは継続的可用性の機能を次のように使用します。

- 自動クロスサイトXAトランザクション・リカバリ: サイト2のドメインがスタンバイ・モードにあるため、フェイルオーバー中、サイト2のドメインを最初に起動する必要があります。ドメインを起動した後、「自動クロスサイトXAトランザクション・リカバリ」で説明されているように、クロスサイト・トランザクション・リカバリ機能を使用できます。

- WebLogic Serverゼロ・ダウンタイム・パッチ適用: このアーキテクチャでは、WebLogic Serverゼロ・ダウンタイム・パッチ適用で説明されているように、サイト1のアクティブ・ドメインでゼロ・ダウンタイム・パッチ適用機能を使用できます。サーバーがサイト2のスタンバイ(パッシブ)・ドメインで実行中ではないため、OPatchを使用できます。サーバーがアクティブになると、パッチを適用したOracleホームが示されます。詳細は、Opatchによるパッチ適用のOPatchを使用した環境へのパッチ適用を参照してください

- Coherenceフェデレーテッド・キャッシュ: このアーキテクチャでは、パッシブ・サイトは読取り専用操作とオフサイト・バックアップをサポートしています。Coherenceフェデレーテッド・キャッシュを参照してください。

- Coherence HotCache: このアーキテクチャでは、サイト1のアクティブ・データベースでの更新がリアルタイムでCoherenceキャッシュを更新し、データベース更新がサイト2にレプリケートされます。データ・レプリケーションがサイト2で発生すると、HotCacheはリアルタイムでキャッシュを更新します。Coherence GoldenGate HotCacheを参照してください。

- Oracle Traffic Director: このアーキテクチャでは、Oracle Traffic Directorがサイト2のスタンバイ(パッシブ)・ドメインでスタンバイ・モードにあります。サイト2がフェイルオーバー後にアクティブになると、スタンバイ・サイト上のOracle Traffic Directorインスタンスが(Oracle Site Guardによりフェイルオーバー前またはフェイルオーバー後に実行されるスクリプトを使用して)アクティブ化され、Oracle Traffic Directorインスタンスが最近起動されたサーバーに対してリクエストのルーティングを開始します。Oracle Traffic Directorを参照してください。

- Oracle Site Guard: このアーキテクチャでサイト1に障害が発生すると、何がどのような順序で発生する必要があるかを指定するスクリプトを使用してOracle Site Guardがフェイルオーバーを開始します。たとえば、WebLogic Server、Coherence、Webアプリケーション、およびその他のサイト・コンポーネントを特定の順序で起動できます。スクリプトはフェイルオーバー前またはフェイルオーバー後のいずれかで実行できます。Oracle Site GuardはOracle Data Guardブローカと統合されてデータベースをフェイルオーバーします。Oracle Site Guardを参照してください。

アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタ

図2-3は、アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタ・アプリケーション・インフラストラクチャ層を使用した、お薦めする継続的可用性ソリューションを示しています。設計上の考慮事項およびベスト・プラクティスについては、「アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタ」を参照してください。

図2-3 アクティブ/アクティブ・ストレッチ・クラスタ・アプリケーション・インフラストラクチャ層およびアクティブ/パッシブ・データベース層のトポロジ

このトポロジの主な特徴は次のとおりです。

- グローバル・ロード・バランサ。

- 各サイトにあるOracle Traffic Director (OTD)の2つのインスタンス(1つはアクティブ、もう1つはパッシブ)。Oracle Traffic Directorは、Web層またはWebLogic Serverクラスタへのリクエストのバランスをとることができます。

- Oracle HTTP Server (OHS) Web Tier (環境のタイプに基づくオプションのコンポーネント)。

- 2つの異なるデータ・センター(サイト1およびサイト2)間まで拡張するクラスタとして構成されたWebLogic Server。クラスタ内のすべてのサーバーがアクティブです。クラスタは、静的にも動的にもなります。クラスタリングを参照してください。

- ドメインには次のものが含まれます。

- サイト1の管理対象サーバー(MS1、MS2およびMS3)のグループと、もう1つのサイト2の管理対象サーバー(MS4、MS5およびMS6)のグループで構成される、WebLogic Serverクラスタ。管理対象サーバーはサイト1にあるWebLogic Server管理サーバーによって管理されます。この例では、Active Gridlink (AG)が管理対象サーバーのプライマリ・データベースへの接続に使用されています。(汎用のDataSourceまたはMultiDataSourceが使用可能ですが、高可用性および向上したパフォーマンスが提供されることからActive Gridlinkをお薦めします。)ゼロ・ダウンタイム・パッチ適用(ZDT)によって、ローリング方式による管理対象サーバーのパッチ適用の提示が可能です。

- ドメイン内のWebLogic Server管理サーバーによって管理されている、各サイト(COH1、COH2およびCOH3)のCoherenceクラスタ。Coherence永続キャッシュは、クラスタで障害が発生した場合に、キャッシュ済データのリカバリに使用されます。Read-ThroughキャッシングまたはCoherence GoldenGateキャッシュが、データベースからのキャッシュの更新に使用されます。

- 構成データ、ローカル・バイナリ、ログなどのファイル・ストア。

- Oracle Enterprise Manager Cloud Controlのコンポーネントであり、サイトのフェイルオーバーおよびスイッチオーバーを編成するOracle Site Guard。

- 2つの異なるデータ・センター内にある2つの別個のOracle RACデータベース・クラスタ。プライマリ・アクティブのOracle RACデータベース・クラスタはサイト1にあります。サイト2にはスタンバイ(パッシブ)読取り専用モードでOracle RACデータベース・クラスタが含まれます。クラスタにはトランザクション・ログ、JMSストアおよびアプリケーション・データが含まれる場合があります。データはOracle Active Data Guardを使用してレプリケートされます。(最高レベルの高可用性が提供されることからOracle RACデータベース・クラスタの使用が推奨されていますが、これは必須ではありません。単一データベースまたはマルチテナント・データベースも使用できます。)

このアーキテクチャは継続的可用性の機能を次のように使用します。

- 自動クロスサイトXAトランザクション・リカバリ: サーバーのすべてが同じクラス内にあるため、既存のWebLogic Serverの高可用性機能、サーバーおよびサービス移行を使用してトランザクションをリカバリできます。

- サーバー全体の移行では、移行可能なサーバー・インスタンスとそのすべてのサービスが、障害発生時に物理的に別のマシンに移行されます。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

- サービス移行では、障害発生時にサービスがクラスタ内の別のサーバー・インスタンスに移動されます。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。

- WebLogicゼロ・ダウンタイム・パッチ適用: クラスタ内のすべてのサーバーがアクティブのため、WebLogic Serverゼロ・ダウンタイム・パッチ適用で説明されているように、この機能の全要素を使用できます。

- Coherenceフェデレーテッド・キャッシュ: 「Coherenceフェデレーテッド・キャッシュ」で説明されているように、この機能の全要素を使用できます。

- Coherence HotCache: 「Coherence GoldenGate HotCache」で説明されているように、この機能の全要素を使用できます。

- Oracle Traffic Director: サーバー可用性に応じて、アプリケーション・サーバーへのトラフィック・ルーティングを調整します。Oracle Traffic Directorで説明されているように、この機能の全要素を使用できます。

- Oracle Site Guard: データベースのみがこのアーキテクチャでスタンバイ・モードにあるため、Oracle Site Guardはデータベースのフェイルオーバーのみを制御します。クラスタ内のすべてのサーバーがアクティブのため、これはアプリケーション・アーキテクチャ層に適用されません。Oracle Site Guardを参照してください。

3 継続的可用性の設計に関する考慮事項

この章では、WebLogic Server Continuous Availabilityでサポートされているマルチデータ・センター最大可用性アーキテクチャ(MAA)の設計に関する考慮事項について説明します。

内容は次のとおりです。

- 一般的な設計に関する考慮事項および推奨事項

- アクティブ/アクティブ・アプリケーション層トポロジの設計に関する考慮事項

- アクティブ/パッシブ・アプリケーション層トポロジの設計に関する考慮事項

- アクティブ/アクティブ・ストレッチ・クラスタ・トポロジの設計に関する考慮事項

一般的な設計に関する考慮事項および推奨事項

この項の設計に関する考慮事項および推奨事項は、サポートされているMAAソリューションのすべてに適用され、継続的可用性を提供するために使用できます。MAAアーキテクチャでは、地理的に分散した場所にデータ・センターが展開されます。「継続的可用性に関してサポートされているMAAアーキテクチャ」を参照してください。

Oracle Maximum Availability Architecture(MAA)は、Oracleにおける実証済の高可用性テクノロジ、専門家の推奨事項およびお客様の経験に基づくOracleのベスト・プラクティスのブループリントです。MAAの目的は、コストおよび複雑さを最小限に抑えてOracleのお客様にとって最適な高可用性アーキテクチャを実現することです。

ここでは、次の項目について説明します。

- 潜在的な障害シナリオ

- グローバル・ロード・バランサ

- Oracle Traffic Director

- Web層

- WebLogic Server

- Coherence

- データベース

- Oracle Enterprise ManagerとOracle Site Guard

潜在的な障害シナリオ

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

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

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

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

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

異なる障害シナリオにおける継続的可用性の機能の動作を次の項で説明します。

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の障害シナリオ

- アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の障害シナリオ

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの障害シナリオ

グローバル・ロード・バランサ

グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。

プライマリサイト障害の場合に、スタンバイ・サイトが本番ロールをとった後、グローバル・ロード・バランサがユーザー・リクエストをスタンバイ・サイトへ再ルーテイングするために使用されます。F5 –BigIP Global Traffic Manager (GTM)およびCisco –Global Site Selector (GSS)などのグローバル・ロード・バランサは、(解決プロセスを従来型のDNSサーバーからオフロードすることで)DNSサーバー解決も処理します。

通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。

DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバー(計画済)およびフェイルオーバー(計画外)として機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。DNSスイッチオーバーの実行手順は、ディザスタ・リカバリ・ガイドのDNS名の手動変更を参照してください。

Oracle Traffic Director

MAA環境では、Oracle Traffic Directorフェイルオーバー・グループを構成する必要があります。Oracle Traffic Directorの2つのインスタンスを1つまたは2つの仮想IP (VIP)アドレスを使用して結合すると、高可用性が保証されます。フェイルオーバー・グループ内の両方のホストでは、同じオペレーティング・システム・バージョンを実行し、同一のパッチおよびサービス・パックを使用し、同じ構成のOracle Traffic Directorインスタンスを実行する必要があります。

2つのOracle Traffic Directorインスタンスが高可用性を提供するために仮想IPアドレス(VIP)でグループ化されている場合、アクティブ/パッシブ・フェイルオーバー・モードになります。VIPはリクエストを受信して、プライマリ・インスタンスと指定されているOracle Traffic Directorインスタンスにルーティングします。プライマリ・インスタンスに到達できない場合、リクエストはバックアップ・インスタンスにルーティングされます。

アクティブ/アクティブ・フェイルオーバー・モードには、2つのフェイルオーバー・グループが必要です。各フェイルオーバー・グループは一意のVIPを持つ必要があり、それぞれプライマリ・ロールとバックアップ・ロールが逆となる同じノードで構成されています。フェイルオーバー・グループ内の各インスタンスは、プライマリ・インスタンスおよびバックアップとして指定され、それぞれにVIPが1つずつ割り当てられます。Oracle Traffic Directorの管理のフェイルオーバー・グループの作成と管理を参照してください。

Oracle Traffic DirectorをLinuxプラットフォームで高可用性モード(アクティブ/パッシブとアクティブ/アクティブの両方)で実行している場合、フェイルオーバー・グループを構成するために使用されるすべてのホスト上でOracle Traffic DirectorのみがKeepalivedプロセスのコンシューマであることを確認してください。KeepalivedはLinux上で実行されるプロセスです。これはヘルスチェック・フレームワークで、Hot Standbyプロトコルを実装しています。これらのホスト上で実行され、Keepalivedプロセスを必要とするアプリケーションは他にありません。

Oracle HTTP ServerおよびApacheプラグインも、Continuous AvailabilityアーキテクチャでWebLogic Serversに対するリクエストのロード・バランスをとるために使用できますが、Oracle Traffic Directorで受け取る統合は提供されません。

次の各項で、Oracle Traffic Directorに継続的可用性を構成するための特定のガイドラインを提供します。

ネットワークの準備

- Oracle Traffic Directorのフェイルオーバー・グループに使用する各サイトごとに仮想IPアドレスを1つ割り当てます。アドレスは、フェイルオーバー・グループ内のノードと同じサブネットに属している必要があります。このアドレスはDNSで解決可能でネットワーク上でアクセス可能である必要があります。フェイルオーバー・グループの仮想IPが作成されるネットワーク・インタフェースで、すべての管理ノード・ホストで同じアドレスであることを確認してください。これは、フェイルオーバー・グループをプライマリ・サイトからスタンバイ・サイトに円滑に移行するための必要条件です。

- スタンバイ・サイトで、プライマリ・サイトのホスト名およびプライマリ・サイトの仮想IPが対応するピア・システムのIPアドレスに解決されることを確認してください。これは、/etc/hostsファイルでホスト名の別名を作成して設定できます。両方の障害時リカバリ・デプロイメント・オプションに対して、すべてのシステム用の別名およびIP名が存在することを確認してください。

ベスト・プラクティス

1. スタンバイ・サイトを定期的にテストすることをお薦めします。これは、両サイトでの障害を軽減するために役立ちます。スタンバイ・サイトを、現在のプライマリ・サイトとロールを切り替えてテストします:

a. サイト・スイッチオーバー・プロシージャに従ってスタンバイ・サイトを新規プライマリ・サイトに切り替えます。

b. 一度テストが完了したら、サイト・スイッチバック・プロシージャに従ってロールをリバースします。

定期的テストで、プライマリ・サイトとスタンバイ・サイトの両方が完全に機能していることが検証され、両方のサイトで障害のリスクが軽減されます。スイッチオーバー・プロシージャおよびスイッチバック・プロシージャも検証されます。

2. 同じプロジェクト内でプロジェクトレベルおよび共有レベルのレプリケーションを構成しないでください。

3. Oracle Traffic Director設定が共有ストレージにあり、リモート・サイトにレプリケートされてOracle Traffic Directorのバイナリおよび最新の構成データがサイト障害またはサイト・メンテナンス・イベント中にスタンバイ・サイトで使用可能になっていることを確認します。Oracle Traffic Directorのすべてのバイナリ、構成データ、ログおよびセキュリティ・データが既存のレプリケーション・テクノロジを使用してリモート・サイトにレプリケートされている必要があります。

4. 次の場合、プロジェクトおよび共有にスケジュール・レプリケーション・モードを使用します。

a. データが頻繁には変更されません。

b. リカバリ・ポイントの目標値は、スケジュールされたレプリケーション期間内に入ります。

5. 次の場合、プロジェクトおよび共有に継続的レプリケーション・モードを使用します。

a. スタンバイ・サイトは可能なかぎりプライマリ・サイトに近いことが必要です。

b. リカバリ・ポイントの目標値は数秒の範囲で、許容されるのはほとんど発生しないデータ損失に対するものです。データは重要な性質を持ったものです。

6. バックアップ、テストおよび開発タイプの環境をオフロードするためにスナップショットおよびクローンをターゲット・サイトで使用できます。

7. ローカル・スタンバイ・サイト(データ・センター内の障害時リカバリ)を構成する場合はレプリケーション・チャネルでSSLを無効にすることを検討します。暗号化アルゴリズムを削除するとレプリケーション・スループットがより高くなります。

8. レプリケーションがワイド・エリア・ネットワークにわたる場合は常にSSLを有効にします。OTDインスタンス同期ベースのスタンバイ障害時リカバリ・オプションの場合、OTDインスタンスの変更をサイト間で転送するためにリモート同期ツールおよびスケジューラ・アプリケーションが各サイトの管理サーバー・ホストに必要です。NIS設定が構成されNISサービスが開始されていることを確認します

Web層

Web層の構成は継続的可用性MAAアーキテクチャではオプションです。Oracle HTTP Server (OHS)およびOracle WebLogic Serverプロキシ・プラグインなどのWeb層製品は、WebLogic Serverアプリケーションを効率的にフロントエンド化にするように設計されています。

可能な場合、Oracle Traffic Director (OTD)を使用してWebLogic Serverインスタンスに対するすべてのロード・バランシングを処理することをお薦めします。次の場合は、Oracle Traffic Directorを含むWeb層をフロントエンドにしないでください。

- HTML、イメージ、JavaScriptなどのような静的コンテンツ。Oracle Traffic Directorは、ロールアウト処理中に最大可用性を提供するゼロ・ダウンタイム・パッチ適用や、MTパーティション内のアプリケーションおよびリソースのWebLogicクラスタ間での移行中に継続的可用性を提供するライブ・パーティション移行などのContinuous Availability機能と統合されています。

- Oracle HTTP ServerまたはWebLogic Serverプロキシ・プラグインをすでに使用しているミドルウェア構成。

既存のレプリケーション・テクノロジまたは方法を使用して、Web層のバイナリおよび構成をサイト間で整合性のあるものにします。

OHSおよびWebLogic Serverプロキシ・プラグインはその他のWebLogic Server Continuous Availability機能とともに使用できますが、手動操作が必要な場合がありOracle Traffic Directorと同様レベルの可用性が提供されません。

Oracle HTTP ServerおよびWebLogic Serverプロキシ・プラグインの詳細は次を参照してください。

- Oracle HTTP Serverの管理のOracle HTTP Serverの概要。

- Oracle WebLogic Serverプロキシ・プラグイン12.2.1.2の使用のOracle WebLogic Serverプロキシ・プラグインの概要。

WebLogic Server

継続的可用性MAAアーキテクチャでのWebLogic Serverの設計に関する考慮事項の詳細は、次の各項を参照してください。

- クラスタリング

- シングルトン・サービス

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

- データソース

- セキュリティ

- ストレージ

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

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

クラスタリング

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティ、信頼性および高可用性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバー・インスタンスを追加することによって強化できます。また、新たにサーバー・インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバー・インスタンスでは、同一バージョンのWebLogic Serverを実行する必要があります。

WebLogic Serverでは、次の2種類のクラスタがサポートされます。

- 動的クラスタ - 動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。これにより、追加のサーバー容量が必要な場合に動的クラスタ内のサーバー・インスタンスの数を簡単にスケール・アップできます。動的クラスタにより、ルールおよびポリシーを定義および構成して動的クラスタをスケール・アップまたは縮小できます。
動的クラスタでは、管理対象サーバーの構成は単一の共有テンプレートに基づいています。クラスタ化された管理対象サーバーの構成が非常に簡素化され、マシン・リソースへのサーバーの動的割当ておよび最小構成を使用したリソース使用率の増加が可能になります。

動的クラスタの拡張度により、ユーザーが識別した条件に基づいてクラスタをスケール・アップまたはダウンできます。クラスタのスケーリングは、要求時に(管理者により対話的に)特定の日時に、または様々なサーバー・メトリックで見られるパフォーマンスに基づいて実行できます。

動的クラスタを縮小する場合、管理対象サーバーは段階的に停止され、作業/トランザクションを完了できます。必要に応じて、シングルトン・サービスが自動的にクラスタ内の別のインスタンスに移行されます。

- 静的クラスタ - 静的クラスタでは、エンドユーザーが新規サーバーを構成してクラスタに追加し、手動で起動および停止する必要があります。クラスタの拡張および縮小は自動ではないため、管理者が実行する必要があります。

多くの場合、動的クラスタを使用して拡張度をWebLogicデプロイメントに提供することをお薦めします。動的クラスタの利点は、最小構成、クラスタの拡張度およびクラスタ縮小時のJMSとJTAシングルトン・サービスの適切な移行です。

ただし、一部のインスタンスでは静的クラスタの使用が必要なものがあります。

- 手動でシングルトン・サービスを移行する必要がある場合。動的クラスタはシングルトン・サービスの手動の移行をサポートしていません。

- お使いの構成がOracle SOA SuiteおよびOracle Business Process Managementなど、Oracle Fusion Middlewareの上位スタック製品を含む場合。これらの製品は、このリリースでは動的クラスタのサポートを提供していません。

シングルトン・サービス

シングルトン・サービスとは、管理対象サーバーで実行されるサービスであり、1度にクラスタ内の1つのメンバー上でのみ使用可能になります。WebLogic Serverでは、シングルトン・サービスを自動的に監視したり、あるサーバー・インスタンスから別のサーバー・インスタンスに移行したりできます。

JMS関連サービスおよびユーザー定義シングルトン・サービスなどの固定サービスは、WebLogicクラスタ内の個々のサーバー・インスタンスにホストされています。シングルトンJMSまたはJTAサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、シングルトン・サービスをクラスタ内の任意のサーバー・インスタンスに自動または手動で移行できるようにWebLogic Serverを構成できます。

アプリケーション内に、クラスタの複数のメンバーで同時に実行したくないタスクを実行するためのシングルトン・サービスを定義できます。シングルトン・サービスの自動移行では、ユーザー定義シングルトン・サービスのヘルス・モニタリングと移行を自動化できます。

シングルトン・サービスについては、次の項で説明します。内容は次のとおりです。

- サーバーおよびサービスの移行

- データ・ストア

- リース

サーバーおよびサービスの移行

Oracle WebLogic Serverでは、次の2種類の自動移行メカニズムをサポートしています。

- サーバー全体の移行では、移行可能なサーバー・インスタンスとそのすべてのサービスが、障害発生時に物理的に別のマシンに移行されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

- サービスの移行では、失敗したサービスが1つのサービス・インスタンスからクラスタ内で使用可能な別のサーバー・インスタンスに移行されます。状況によっては、サービスの移行のほうがサーバー全体の移行よりはるかに良好に機能します。これは、サーバー全体とは対照的にシングルトン・サービスの移行のみを実行しているためです。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。

サーバー全体の移行およびサービスの移行は、どちらもデータベースのリース表を構成する必要があります。リースを参照してください。

MAA環境でサーバーおよびサービスの移行を使用するためのWebLogicサーバーの構成の詳細は、Oracle SOA Suiteエンタープライズ・デプロイメント・ガイドのエンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用を参照してください。

データ・ストア

Oracle WebLogic Serverのトランザクション・ログおよびOracle WebLogic ServerのJMSには、データベース・ベースおよびファイル・ベースの2種類の永続データ・ストアがあります。

永続ストアをデータベースに保持することにより、基礎となるデータベース・システムに固有のレプリケーションおよび高可用性の利点が提供されます。JMS、TLogおよびアプリケーションが同じデータベースおよびOracle Data Guardで処理されたレプリケーション内にある場合、クロスサイトの同期が簡素化され、NASやSANなどの共有ストレージ・サブシステムの必要性は中間層で軽減されます。データベースを参照してください。

ただし、TLogおよびJMSストアをデータベースに格納すると、システム・パフォーマンスに対するペナルティがあります。このペナルティは、サイトの1つが他のサイトのデータベースと相互通信する必要がある場合に増加します。理想的には、パフォーマンスの観点から見て、各サイトに対してローカルな共有ストレージを両方の種類のストアに使用し、パフォーマンスの低下なしでゼロ・データ損失を保証するためにストレージ・レベルでの適切なレプリケーション戦略とバックアップ戦略をプロビジョニングする必要があります。データベース・ストアを使用したほうがシステム用の共有ストレージより適しているかどうかは、JMSおよびトランザクション・データの重要度によります。これは、共有ストレージが提供する保護のレベルがデータベースが保証するよりはるかに低いためです。

アクティブ/アクティブ・トポロジおよびアクティブ/パッシブ・トポロジでは、データベースにデータ・ストアを維持することが必須です。JMSおよびJTAストアなどのWebLogic Serverストアを、Oracle RACなどの高可用性のデータベースに維持し、最大のパフォーマンスおよび可用性を得るためにActive GridLinkデータソースを使用してデータベースに接続することをお薦めします。

アクティブ/アクティブ・ストレッチ・クラスタの場合、データ・ストアをNASやSANなどの共有ストレージ・サブシステムに維持するか、データベースに維持するかを選択できます。

リース

リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタ全体エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に1つしか存在しません。また、サーバーやクラスタの障害時にはリースをフェイルオーバーさせることができ、シングル・ポイント障害を回避するために役立ちます。Oracle WebLogic Serverクラスタの管理のリースを参照してください。

データベース・リースの場合、次をお薦めします。

- Oracle RACおよびActive GridLink (AGL)などの高可用性データベース。

- スタンバイ・データベース、および2つのデータベース間のレプリケーションを提供するOracle Data Guard。

データベース・リースを使用する際、データベースが(スイッチオーバーまたはフェイルオーバー中に)サーバー移行の分離時間よりも長い期間使用不可を続けている場合、Oracle WebLogic Serversが停止する場合があります。サーバー移行の分離時間は、『Oracle WebLogic Serverクラスタの管理』の次のトピックに説明されているように調整できます。

- クラスタでの移行可能サーバーの動作

- サーバー全体の移行におけるクラスタ・マスターの役割

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

WebLogic Serverでは、クラスタ内の複数のサーバー間でHTTPセッション状態をレプリケートするために次の3つの方法が用意されています。

- メモリー内レプリケーション - WebLogic Serverはメモリー内レプリケーションを使用して、1つのサーバー・インスタンスから別のインスタンスにセッション状態をコピーします。プライマリ・サーバーはクライアントが最初に接続するサーバー上にプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンス上に予備のレプリカを作成します。サーブレットのホストとなっているサーバーで障害が起きた場合に使用できるように、レプリカは最新の状態に保たれます。

- JDBCベースの永続性 - JDBCベースの永続性では、WebLogic Serverはファイル・ベースまたはJDBCベースの永続性メカニズムを使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。それぞれの永続性メカニズムの詳細は、Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発のセッションの永続性の構成を参照してください。

- Coherence*Web - Coherence*Webは、WebLogic ServerのインメモリーHTTP状態レプリケーション・サービスの代替ではありません。ただし、アプリケーションに大量くのHTTPセッション状態オブジェクトがある場合、HTTPセッション状態オブジェクト・データの格納によってメモリー制約が発生する場合、または既存のCoherenceクラスタを再利用する場合は、Coherence*Webを使用することをお薦めします。Oracle Coherence*WebでのHTTPセッション・マネージメントの管理のWebLogic ServerでのCoherence*Webの使用方法を参照してください。

遅延モデル、セッション損失に対する許容度およびパフォーマンスに応じて、もっとも要件に適した方法を選択する必要があります。

- 遅延が小さい場合、たとえばMANネットワーク(ストレッチ・クラスタ・トポロジ)などでは、WebLogic Serverインメモリー・セッション・レプリケーションをお薦めします。ただし、サイトで障害が発生した場合はセッション損失の可能性があります。

- 遅延が大きく(WANネットワーク)、アクティブ/アクティブまたはアクティブ/パッシブ・トポロジの場合、およびお使いのアプリケーションがセッション損失を許容できない場合、データベース・セッション・レプリケーションをお薦めします。

多くの場合、インメモリー・セッション・レプリケーションのほうがデータベース・セッション・レプリケーションよりはるかに良好に機能します。Oracle WebLogic Serverクラスタの管理のクラスタのフェイルオーバーとレプリケーションを参照してください。

データソース

WebLogic Active GridLink Data Sourcesは、Oracle RACデータベースおよびOracle Data Guardと統合されて最高のパフォーマンス、高いスケーラビリティおよび最高の可用性を提供します。Oracle RACとの統合により、Active GridLinkは高速接続フェイルオーバー(FCF)、ランタイム接続ロード・バランシング(RCLB)およびアフィニティの各機能を実行できます。Active GridLinkは、データベース内の計画済メンテナンスを、エンドユーザーに対する中断なしで処理する一方ですべての作業が完了するようにできます。

JMSおよびJTAストアなどのWebLogic Serverストアおよびリース表を、Oracle RACなどの高可用性のデータベースに維持し、Active GridLinkデータソースを使用してデータベースに接続することをお薦めします。データベース内でストアおよびリース表を格納する方法には、次のメリットがあります。

- 基礎となるデータベース・システムに固有のレプリケーションおよびその他の高可用性の側面を利用します。

- 障害時リカバリ・シナリオの処理を強化します。JMS、TLogおよびアプリケーションが同じデータベース内にありレプリケーションがData Guardにより処理される場合、クロスサイトの同期について心配する必要はありません。

- NASまたはSANなどの共有ストレージ・サブシステムの必要性を軽減します。データベースの使用により全体的なシステムの複雑さも減ります。これは多くの場合、データベースが標準のランタイム/アプリケーション作業用にすでに存在しているためです。

お使いのActive GridLink URLを構成してフェイルオーバー時間をデータベース間で最小化できます。Oracle WebLogic Server JDBCデータ・ソースの管理のサポートされるAGLデータソースURL形式を参照してください。

セキュリティ

WebLogic ServerとJava EEアプリケーションを本番環境にデプロイする前に、セキュリティ・ニーズを決定し、適切なセキュリティ対策を講じることが重要です。Oracle WebLogic Server本番環境の保護の本番環境のセキュリティの確保を参照してください。

ストレージ

通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。MAA環境で考慮が必要な一部のストレージ・アーティファクトは静的および動的として分類されています。

- 静的アーティファクトは、頻繁には変更されないファイルやディレクトリです。これには次のものがあります。

- ホーム: Oracleホームは通常、OracleホームとOracle WebLogic Serverホームで構成されます。

- Oracleインベントリ: これには、/etcディレクトリにある、oraInst.locおよびoratabファイルが含まれます。

- 動的またはランタイム・アーティファクトは、頻繁に変更されるファイルです。ランタイム・アーティファクトには、次のものが含まれています。

- ドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。

- Oracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。

- .earファイルや.warファイルなどのアプリケーション・アーティファクト。

- MDSリポジトリなどのデータベース・アーティファクト。

- Oracle Fusion Middlewareで使用されるデータベース・メタデータ・リポジトリ。

- JMSプロバイダやトランザクション・ログなどの永続ストア。データ・ストアを参照してください。

- デプロイメント・プラン: ファイル・アダプタやJMSアダプタなどのテクノロジ・アダプタの更新に使用されます。これらは、アーティファクトがデプロイされるクラスタ内のすべてのノードにアクセスできる場所に保存する必要があります。

可用性が最大になるように、バイナリの冗長インストールを使用することをお薦めします。各ノードは独自のOracleホームを持ち、ゼロ・ダウンタイム・パッチの適用時に1つのノード内のサーバーのみが一度に停止されるようにする必要があります。

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

ゼロ・ダウンタイム・パッチ適用(ZDTパッチ適用)では、アップグレードのロールアウト処理中に継続的なアプリケーション可用性が提供されます。これはロールアウト処理中の障害の可能性が常に存在しても変わりません。MAA環境では、一度に1つのサイトに対してパッチを適用し、その他のサイトに対する更新の時間をずらしてサイトの同期が残るようにすることをお薦めします。サイト障害シナリオの場合、失敗したサイトがZDTパッチ適用を再開する前に再開できるようにします。

ZDTパッチ適用を使用する場合、次を考慮してください。

- ロールアウトは一度に1つのノードを停止するため、クラスタ内のノードが増えるほどクラスタのトラフィック処理能力への影響が少なくなります。

- クラスタのノードが2つのみで一方のノードがパッチ適用のために停止している場合、高可用性は保証されません。クラスタ内には2個を超えるノードを持つことをお薦めします。

- 管理対象サーバーを管理サーバーと同じノードに含めた場合、両方のサーバーをともに停止してOracleホームを更新する必要があります。

- 2つのクラスタでOracleホームを共有する同じノード上にサーバーを持つことができますが、両方のクラスタを停止して同時にパッチを適用する必要があります。

- Oracleホームが2つ含まれている構成の場合、適用するパッチをテストできるように、本番マシン以外に2つ目のOracleホームを作成してパッチを適用することをお薦めしますが、必須ではありません。そのノードのOracleホームは、本番ドメインで使用しているOracleホームと同じである必要があります。

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

クロスサイトXAトランザクション・リカバリはリース・フレームワークを使用してクロスサイト・リカバリを自動化しています。クロスサイト・トランザクション・リカバリのためのリース表の設計要件は、リースで説明されているように基本的にトランザクション・リカバリ・サービスのデータベース・リース用に定義された要件と同じです。リース表は管理対象サーバーが起動されてサイトが構成されるときに自動的に作成されます。サイトのすべてのドメインについて、サイト当たり1つのリース表があります。

Oracle WebLogic Server JTAアプリケーションの開発の複数サイトまたはデータ・センターにまたがるトランザクション・リカバリを参照してください。

管理対象サーバーのリスニング・アドレスを指定するには(静的IPではなく)ホスト名を常に使用し、すべてのサイトに同一のホスト名を構成することをお薦めします。サイト間でホスト名は同一で、IPは同一ではないため、同じように構成されたサーバーまたはドメインをリカバリ・サイトで単純に開始する動的な機能がホスト名により提供されます。

表3-1は、継続的可用性のMAAトポロジで構成できるJTA MBeanプロパティに対してお薦めする設定を示しています。Oracle WebLogic Server MBeanリファレンスのJTAMBeanも参照してください。

表3-1 クロスサイトXAトランザクション・リカバリ用の構成可能なMBeanプロパティ

構成プロパティ

説明

お薦めする設定

CrossSiteRecoveryLeaseExpiration

リースが期限切れになり、その後別のサイトによるリカバリの対象となる時間を秒数を指定します。

30秒(デフォルト)

CrossSiteRecoveryRetryInterval

リカバリ・サイト・サーバーがリース表をチェックしてリースが期限切れになっていないか、所有するサーバーが停止していないかを確認する間隔を指定します。

60秒(デフォルト)

CrossSiteRecoveryLeaseUpdate

サーバーがそのリースを更新する頻度を指定します

10秒(デフォルト)

Coherence

継続的可用性MAAアーキテクチャでのCoherenceの設計に関する考慮事項の詳細は、次の各項を参照してください。

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

- Coherence永続キャッシュ

- Coherence GoldenGate Hot Cache

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

(ストレッチ・クラスタではなく)フェデレーテッド・キャッシュを実行しているCoherenceの場合、問題のいくつかを次に示します。

- Coherenceデータが、ネットワークの分断またはリモート・クラスタの機能停止の後も他のサイトのなんらかのポイントに順序付け方式で到達しています(Coherenceでは順序付けはCoherenceパーティションごとです)。

- リモート・サイトはローカル・サイトが更新された後の一定期間に失効データを読み取る場合があります。

- 更新競合の可能性があり、これらを識別してアプリケーション固有の競合解消機能を呼び出します。

Coherenceフェデレーテッド・キャッシュは、次の理由でサイト間に最終競合モデルを実装しています。

- データ・センターはどこにでも配置でき、場所は遅延または使用可能な帯域幅に制約されません。

- リモートのデータ・センターまたはクラスタの使用不可状態が許容されることは、きわめて望ましいことです。通信が停止していることとリモート・クラスタが停止していることの違いを述べることは非常に困難であり、区別する必要はありません。

- アクティブ/アクティブ構成における完全整合性にはなんらかの種類の分散センターの並行制御および同期書込みが必要です。これは、パフォーマンスに大きな影響を与えることがあり、望ましいことではありません。かわりに、整合性が重要なところでは、同期レプリケーションを伴うストレッチ・クラスタを使用できます。この場合、データ・センター間に保証帯域幅とともに最大遅延をアサートすることが妥当です。

Coherence永続キャッシュ

致命的障害や、計画的メンテナンスによるクラスタ再起動の後に迅速なリカバリができるように、キャッシュされたデータは保持されます。マルチデータ・センター環境では、Coherence永続性およびフェデレーテッド・キャッシュの両方を使用して障害時または計画メンテナンス・イベント中の最高レベルの保護を確保することをお薦めします。

永続性は、分散キャッシュに対してのみ使用可能で、集中パーティション割当て戦略を使用する必要があります。次の2つの永続性モードがあります。

- アクティブ永続性 – キャッシュの内容はすべてのミューテーションで自動的に永続化され、クラスタ/サービスの起動時に自動的にリカバリされます。

- オンデマンド永続性 – キャッシュ・サービスは手動で永続化され、リクエスト時に永続性コーディネータを使用してリカバリされます。

Oracle Coherenceの管理の永続キャッシュを参照してください。

Coherence GoldenGate Hot Cache

データの混合を伴う単一Coherenceクラスタ内では、データの一部がデータベースにより所有され、一部がCoherenceにより所有され、Coherence Read-ThroughキャッシュとCoherence GoldenGate Hot Cacheの両方を使用できます。

HotCacheおよびRead-Throughキャッシュ間の選択は、(1) データベースがCoherenceのバックで更新された場合にRead-Throughが失効読取りにつながる場合があるか、(2) HotCacheのリアルタイム性が他の理由で優先されるかということになります。HotCacheおよびRead-Throughの両方を併用して、たとえばHotCache経由でリアルタイム更新をプッシュするが、その後は削除または期限切れのためにデータが削除されたケースを処理するという状況もありえます。

データベース

Oracle Databaseの障害時リカバリに説明されているように、OracleではMAAアーキテクチャでデータベースの高可用性を提供するために統合できる製品をいくつか提供しています。トポロジに関係なく、目標はデータベースのスイッチオーバーおよびフェイルオーバーにかかる時間を最小化することです。

計画済および計画外の両方の停止に備えてお使いのデータベースの高可用性を達成するには、次の製品を組み合せたアクティブ/パッシブ構成を使用することをお薦めします。

- 可用性の高いデータベースとしてのOracle RAC。

- ミッション・クリティカルなOracle Databaseに対する単一点障害を排除するOracle Data Guard。これは、リモートの場所に同期化された本番データベースの物理レプリカを維持することによって、データ損失および停止時間を防止します。本番データベースがどのような理由で使用不可になっている場合でも、クライアント接続が短時間で、また一部の構成では透過的に、同期されたレプリカにフェイルオーバーされてサービスを回復します。アプリケーションは、わずかな変更または変更なしでOracle Data Guardを利用できます。

注意:

Oracle Data Guardはアクティブ/パッシブ構成でのみ使用できますが、ゼロデータ損失が保証されます。

- Oracle Active Data Guardは、Oracle Data Guardのインフラストラクチャの組込みオプションで、プライマリ・データベースから変更が適用されている間も、フィジカル・スタンバイ・データベースを読取り専用で開くことができます。これにより、読取り専用アプリケーションは、プライマリ・データベースで非常に大きいトランザクション・ボリュームの処理中であっても、スタンバイ・データベースとプライマリ・データベース上のデータ間での遅延を最小限に抑えながら、フィジカル・スタンバイを使用できます。これはリアルタイム問合せと呼ばれることもあります。
Oracle Active Data Guardスタンバイ・データベースは、アプリケーションに透過的に、プライマリ・データベースにより検出されたデータ破損の自動修復に使用されます。プライマリ・データベースでの計画外停止の場合も、スタンバイ・データベースへの迅速なフェイルオーバーにより高可用性が保たれます。Active Data Guardスタンバイ・データベースは、プライマリ・データベースのブロック対ブロックのフィジカル・レプリカであるため、特定のプライマリ・データベースから高速増分バックアップをオフロードすることもできます。

- Oracle Data Guardブローカは、Data Guard構成の作成、メンテナンス、監視を自動化および集中化する分散管理フレームワークです。Data Guard Brokerが実行できる操作の一部として、Data Guard構成の作成、管理、監視、構成内のすべてのデータベースにわたる複雑なロール変更を開始および制御するためのスイッチオーバーまたはフェイルオーバーの起動、およびフェイルオーバーを自動発生させるための構成があります。
Data GuardブローカをOracle Data Guardとともにデプロイすることは、Oracle Site Guardを障害時リカバリに使用できるようにする前に必須のことです。

- Active GridLinkは、データベース・サーバーのスケジュール済メンテナンス・プロセスをアプリケーションに対して透過的にします。データベース・サーバーでメンテナンスのためにインスタンスを停止する場合、セッション排出によって、そのノードでインスタンスを使用しているすべての作業が完了し、アイドル・セッションが削除されることが保証されます。セッションは、処理中の作業に影響を与えることなく排出されます。

- Application Continuityは、計画済および計画外の停止中にユーザーを保護します。計画外の停止イベント中に最大の可用性を得るにはApplication ContinuityおよびActive GridLinkを使用します。

- サイトにまたがって排出する高速アプリケーション通知(FAN)を伴うGlobal Data Services (GDS)またはData Guardブローカ。Active Data Guardを使用する場合、セカンダリ・データベースにスイッチオーバーされる前に作業が完了する可能性があります。

お使いの構成でアクティブ/アクティブ・データベース構成が必要な場合、次をお薦めします。

- Oracle GoldenGate。データベースをアクティブ/アクティブ・モードにできます。読取りおよび書込みサービスの両方が両方のサイトのデータベースでアクティブ/アクティブであること。Oracle GoldenGateの管理for Windows and UNIXのアクティブ/アクティブ型高可用性のためのOracle GoldenGateの構成を参照してください。
Oracle Golden Gateを使用する際、Application ContinuityおよびActive GridLinkをサイト内(イントラサイト)で使用して計画済および計画外の停止のデータベース・イベントを処理できます。Application Continuityは、サイト間(インターサイト)のフェイルオーバーまたはスイッチオーバー操作中に使用してトランザクションをリプレイすることはできません。Application Continuityは、Oracle Logical StandbyおよびOracle Golden Gateを含めた論理的に異なるデータベースに対するフェイルオーバーをサポートしていません。リプレイには、トランザクション・ロスがないことが検証済のデータベースに適用される厳密な要件があります。

注意:

Oracle GoldenGateの非同期レプリケート特性のため、アプリケーションはネットワークの遅れが原因のデータ損失を許容する必要があります。

- Oracle GoldenGateを使用するすべてのアプリケーション/スキーマに対して完全なアクティブ/アクティブを備えた競合解決を実装すること。

- 失効データ(対話中のサイトに限定)の表示を避けるためにWebアフィニティを必要とする環境を設計すること。Global Data Services (GDS)は、サイトにローカルなデータベースに対するアフィニティを提供してグローバル・サービスを管理できます。

環境でアクティブ/アクティブ・データベースが必要な場合、これらのテクノロジの組合せを使用して計画済メンテナンス・イベントで可用性を最大限、データ損失を最小限にできます。

Oracle Enterprise ManagerとOracle Site Guard

Oracle Site GuardはOracle Enterprise Managerの一部であり、障害時リカバリ・サイトの間に柔軟でシームレスなスイッチオーバーとフェイルオーバーの編成を提供することでエンタープライズ・デプロイメントの停止時間を最小限に抑えることができます。Oracle Site Guardの障害時リカバリ自動化機能により、ヒューマン操作の必要性が排除され、スイッチオーバーまたはフェイルオーバー・プロセスでの人為的エラーが防止されます。

Oracle Site Guardをサイト間でのスイッチオーバーおよびフェイルオーバーのために構成する方法の詳細は、Site Guard管理者ガイドのOracle Site Guardの構成を参照してください。

Site Guardのベスト・プラクティスは、http://www.oracle.com/technetwork/database/availability/maa-site-guard-exalogic-exadata-1978799.pdfにあるOracle Exalogic用Oracle Site Guardを使用した障害時リカバリの自動化ホワイト・ペーパーを参照してください。

アクティブ/アクティブ・アプリケーション層トポロジの設計に関する考慮事項

一般的な設計に関する考慮事項および推奨事項に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層に示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の障害シナリオ

アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の設計に関する考慮事項

アクティブ/アクティブ・トポロジで継続的可用性の機能を最大限に利用するには、次を考慮してください。

- アクティブ/アクティブ・ドメインは対称的トポロジで構成する必要があります。これらは類似しており、同じドメイン構成(ドメインおよびサーバーの名前、ポート番号、ユーザー・アカウント、ロード・バランサおよび仮想サーバー名など)と同じソフトウェア・バージョンを使用する必要があります。ホスト名(静的IPではない)は、管理対象サーバーのリスニング・アドレスの指定に使用する必要があります。このトポロジでクロスサイト・トランザクション・リカバリを構成すると、構成可能なMBeanプロパティ、SiteName、RecoverySiteNameはサイト固有です。サイトを同期状態に維持するために現在使用している既存のレプリケーション・テクノロジまたは方法はすべて使用できます。

注意:

クロスサイトXAトランザクション・リカバリを利用する際、いくつかの構成パラメータ(表3-1を参照)が、サイトに固有の「サイト名」および「リカバリ・サイト名」とともに存在します。構成をレプリケートするときにこれらのパラメータおよび名前を上書きしないでください。

- このトポロジ・ネットワークの遅延は、通常大です(WANネットワーク)。アプリケーションでサイト間のセッションのレプリケーションが必要な場合、データベース・セッション・レプリケーションまたはCoherence*Webのいずれかを選択する必要があります。セッション・レプリケーションを参照してください。

- サーバーおよびサービスの移行は、アクティブ/アクティブ・トポロジのイントラサイト(サイト内)でのみ適用されます。サーバーおよびサービスの移行を参照してください。

- JMSはこのトポロジのイントラサイトでのみサポートされています。フェイルオーバーまたは計画済メンテナンス中のJMSリカバリはサイト間ではサポートされていません。

- ゼロ・ダウンタイム・パッチ適用は、アクティブ/アクティブ・トポロジのイントラサイト(サイト内)でのみ適用されます。各サイトのWebLogicホーム、Javaおよびアプリケーションは別々にアップグレードできます。アップグレード・バージョンを同期状態に維持し、両方のサイトのドメインを対称に維持してください。

- 異なるContinuous Availability機能を組み合せることにより、障害時のデータ損失を最小限にするようにアプリケーションを設計できます。たとえば、クロスサイトXAトランザクション・リカバリ、Coherenceフェデレーテッド・キャッシュ、Coherence HotCacheまたはCoherence Read-Throughキャッシュを組み合せて使用できます。
Coherenceデータがデータベースにバックアップされており、ネットワーク・パーティション障害が発生した場合、フェデレーテッド・キャッシュはレプリケーションを実行できず、Coherenceクラスタが独自に作業を継続できるため、両方のサイトのデータの整合性が失われます。サイト間の通信が再開すると、バックアップされたデータがデータベースからCoherenceにCoherence HotCacheまたはCoherence Read-Throughキャッシュ経由で送られ、最終的にはCoherenceキャッシュのデータが同期されます。Coherenceを参照してください。

- アクティブ/アクティブ・トポロジでは、Oracle Site Guardはデータベースのスイッチオーバーまたはフェイルオーバーのみを実行できます。アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の障害シナリオを参照してください。

- 図3-1および図3-2は、クロスサイト・トランザクション・リカバリのデフォルト・パラメータ設定を使用したベンチマーク・テスト中に見つかった結果を表しています。この図は、中間層が失敗したときのサイト間でのトランザクションのリカバリで生じた遅延を示しています。図3-1は、サイト間の遅延が1秒の場合に平均リカバリ時間が170から180ミリ秒の範囲であったことを表しています。図3-2は、サイト間の遅延が77ミリ秒の場合に平均トランザクション・リカバリ時間が90から100ミリ秒の範囲であったことを表しています。
遅延が増加するに伴って、クロスサイト・トランザクション・リカバリ・パラメータのCrossSiteRecoveryLeaseExpiration、CrossSiteRecoveryRetryIntervalおよびCrossSiteRecoveryLeaseUpdateを増やして遅延にあわせる必要があります。クロスサイト・トランザクション・リカバリのリース表が維持されているデータベースがサイトの1つに対してリモートである場合、これらの値のチューニングが特に重要です。「クロスサイトXAトランザクション・リカバリ」を参照してください。

図3-1 サイト間の遅延が1秒のクロスサイト・トランザクション・リカバリ

図3-2 サイト間の遅延が77ミリ秒のクロスサイト・トランザクション・リカバリ

アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・アプリケーション層の障害シナリオ

表3-2は、アクティブ/アクティブ・アプリケーション層トポロジに対する異なる障害シナリオのそれぞれでContinuous Availabilityの機能がどのように使用されているかを説明しています。

表3-2 アクティブ/アクティブ・アプリケーション層およびアクティブ/パッシブ・データベース層の障害シナリオ

継続的可用性の機能

完全サイト障害

部分サイト/中間層障害(WebLogic Server/Coherence/OTD)

メンテナンス機能停止

ネットワークの分断障害

サイト間のトランザクション・リカバリ

- Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。

- JDBC TLogは、Oracle Data GuardまたはOracle Active Data Guardなどのレプリケーション・テクノロジによってサイト2のデータベースにレプリケートされます。

- トランザクションはクロスサイト・トランザクション・リカバリを使用してサイト2にリカバリされます。

プライマリ・サイトのリース表が期限切れになった場合、サイト2のサーバーが自動的にTLog表の所有権をとり、トランザクション・リカバリを開始します。

- エンドユーザーがOracle Site Guardでスイッチオーバー操作を起動してスイッチオーバー操作の編成を開始します。

- Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。

- JDBC TLogがサイト2のデータベースにレプリケートされます。

- トランザクションはクロスサイト・トランザクション・リカバリを使用してサイト2にリカバリされます。

- サイト1はそのトランザクションの処理を続行します。

- トランザクションがストアへの書込みトランザクションの前に失敗した場合、サイト2のサーバーは動作を続けます。トランザクション・ログ・ストアが利用できずにトランザクションが失敗した場合、サーバーは停止します(デフォルト動作)。

- リース表への接続を試行するサーバーはリカバリ・サイトに対するリカバリができないことの警告を書き込みます。

Oracle Traffic Director

サイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。

サイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。

- サイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。

サイト1のOracle Traffic Directorおよびサイト2のOracle Traffic Directorは、そのサイトで稼働しているサーバーへのトラフィックのルーティングを続行します。

Oracle Site Guard

Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがデータベース内のロールをプライマリからセカンダリに切り替えます。

何もしません。

- エンドユーザーがOracle Site Guardでスイッチオーバー操作を起動してスイッチオーバー操作の編成を開始します。

- Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがデータベース内のロールをプライマリからセカンダリに切り替えます

何もしません。

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

サイト2のCoherenceクラスタがアクティブになります。

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。

アクティブ/パッシブ・アプリケーション層トポロジの設計に関する考慮事項

一般的な設計に関する考慮事項および推奨事項に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層に示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。

- アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の障害シナリオ

アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の設計に関する考慮事項

アクティブ/パッシブ・トポロジで継続的可用性の機能を最大限に利用するには、次を考慮してください。

- すべてのアクティブ/パッシブ・ドメインのペアは対称的トポロジで構成する必要があります。これらは同等であり、同じドメイン構成(ディレクトリの名前およびパス、ポート番号、ユーザー・アカウント、ロード・バランサおよび仮想サーバー名など)とソフトウェア・バージョンを使用する必要があります。ホスト名(静的IPではない)は、管理対象サーバーのリスニング・アドレスの指定に使用する必要があります。サイト間でホスト名が同じ場合(IPは同一ではない)、そのホスト名により、同じように構成されたサーバーまたはドメインをリカバリ・サイトで開始する動的な機能が提供されます。

- このトポロジで遅延に関する考慮事項はありません。唯一の要件は、JMSおよびJTA TLogなどのストアがデータベースに維持されることです。

- パッシブ・モードでWebLogic Serverのサーバーは構成されますが、稼働していません。障害がある場合、パッシブ・サイトのWebLogic Serverのサーバーが起動され、JTAおよびJMSのトランザクション/メッセージがリカバリされます。作業はその後2番目のサイトで実行されます。

- JMSはこのトポロジでサポートされています。パッシブ・サイトには、JMSサーバー、ストアおよび宛先の構成が同一になるようにプライマリ・サイトのドメインの完全なコピーが含まれている必要があります。
フェイルオーバーまたはスイッチオーバーの場合、ストアまたはJMSサーバー(あるいはその両方)がクラスタをターゲットとしている場合は同数のサーバーをクラスタで起動する必要があります。このプロセスは、JMSサーバー+ストア+宛先のそれぞれが、実行していたサーバーに固有のものであるためです。MyServer1とMyServer2がプライマリ・ドメインにある場合、これらの各サーバーにJMS Server + ストアがあります。これらのサーバーのキューにメッセージが含まれている可能性があります。1つのサーバーのみを再起動すると、リカバリされるのはその1つのサーバーに対するメッセージのみです。

スタンバイ・ドメインは、レプリケーション・フェーズ中は実行できず、最初のデータ・センターの停止が確認された後にのみ起動できます。このプロセスは、データの破損を防いでリカバリを強制するために必要です。2つのJMSサーバー/ストアがまったく同じデータを書込み/更新している場合、予期できない結果が発生します。また、メッセージ・リカバリはJMSの起動時にのみ発生します。その際、JMSサーバーはストアの完全な内容を読み取って宛先状態を再作成します。

非同期レプリケーションは喪失メッセージ(メッセージがプライマリ・データ・センターに書き込まれたがコピーされていない)または重複メッセージ(メッセージがプライマリ・データ・センターで消費/削除されたがレプリケートされたデータ・センターに残っている)になる可能性があります。

ディザスタ・リカバリ・ガイドのOracle WebLogic Server Java Message Service (JMS)およびトランザクション・ログ(TLog)の推奨事項を参照してください。

- ゼロ・ダウンタイム・パッチ適用は、お使いのWebLogicホーム、Javaおよびアプリケーションをアクティブなサイトでローリング方式でアップグレードします。計画済メンテナンスおよびパッシブ・サイトへのスイッチオーバー中、およびサーバーの起動後に、ゼロ・ダウンタイム・パッチ適用を使用してWebLogic、Javaまたはアプリケーションをアップグレードします。両方のサイトのドメインを対称に維持するには、両方のサイトでアップグレード・バージョンを同期状態に維持してください。

- アクティブ/パッシブ・トポロジでは、Coherenceはスタンバイ・モードにあり、WebLogic Serverのようなパッシブ・モードではありません。スタンバイ・サイトにはアクティブなサイトからのキャッシュ・データのバックアップがあります。Coherenceフェデレーテッド・キャッシュをアクティブ/パッシブ・モードで使用すると、このレプリケーションは非同期ですが絶えず発生します。

- このトポロジでは、Oracle Site Guardを使用してすべてのサイト・コンポーネント(Oracle Traffic Director、WebTier、WebLogic Server、Coherenceおよびデータベース)のフェイルオーバー/スイッチオーバーを編成することをお薦めします。

アクティブ/パッシブ・データベース層を使用するアクティブ/パッシブ・アプリケーション層の障害シナリオ

表3-3は、アクティブ/パッシブ・アプリケーション層トポロジに対する異なる障害シナリオのそれぞれでContinuous Availabilityの機能がどのように使用されているかを説明しています。

表3-3 アクティブ/パッシブ・アプリケーション層およびアクティブ/パッシブ・データベース層の障害シナリオ

継続的可用性の機能

完全サイト障害

部分サイト/中間層障害(WebLogic Server/Coherence/OTD)

メンテナンス機能停止

ネットワークの分断障害

サイト間のトランザクション・リカバリ

- Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。

- JDBC TLogが、Oracle Data GuardまたはOracle Active Data Guardなどのレプリケーション・テクノロジを使用してサイト2のデータベースにレプリケートされます。

- トランザクションはサーバーが再起動されたときにリカバリされます。

- Oracle Site GuardがOracle Data Guardと統合されてデータベースおよびアプリケーション・インフラストラクチャのスイッチオーバーを編成します。

- トランザクションはサーバーが起動するときにリカバリされます。

- Oracle Site Guardは、Oracle Data Guardとともにデータベースおよびアプリケーション・インフラストラクチャのスイッチオーバーを編成します。

- JDBC TLogが、Oracle Data GuardまたはOracle Active Data Guardなどのレプリケーション・テクノロジを使用してサイト2のデータベースにレプリケートされます。

- トランザクションはサーバーが起動されたときにリカバリされます。

何もしません。

Oracle Traffic Director

スタンバイ・サイトのOracle Traffic Directorインスタンスが、(Oracle Site Guardによって、何がどのような順序で発生するかを指定するスクリプトを使用して)アクティブ化されます。(スクリプトはフェイルオーバーの前または後に実行できます。)

- スタンバイ・サイトのOracle Traffic Directorインスタンスが、(Oracle Site Guardによって、何がどのような順序で発生するかを指定するスクリプトを使用して)アクティブ化されます。(スクリプトはフェイルオーバーの前または後に実行できます。)

- Oracle Traffic Directorが、サイト2のサーバーへのトラフィックのルーティングを開始します。

スタンバイ・サイトのOracle Traffic Directorインスタンスが、(Oracle Site Guardによって、何がどのような順序で発生するかを指定するスクリプトを使用して)アクティブ化されます。(スクリプトはフェイルオーバーの前または後に実行できます。)

何もしません。

Oracle Site Guard

Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。

Oracle Site Guardは中間層でのみフェイルオーバーします。

- 顧客はOracle Site Guardを使用してサイト1の停止を開始します。

- Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがデータベース内のロールをプライマリからセカンダリに切り替えます。

何もしません。

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

サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して整合します。

サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはリモート・サイトが稼働状態に戻ったときに整合します。

サイト2のCoherenceクラスタがアクティブになります。キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはリモート・サイトが稼働状態に戻ったときに整合します。

キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。

アクティブ/アクティブ・ストレッチ・クラスタ・トポロジの設計に関する考慮事項

一般的な設計に関する考慮事項および推奨事項に説明されているようにすべての継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタに示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの設計に関する考慮事項

- アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの障害シナリオ

アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの設計に関する考慮事項

アクティブ/アクティブ・ストレッチ・クラスタで継続的可用性の機能を最大限に利用するには、次を考慮してください。

- マルチデータ・センターでは、アクティブ/アクティブ・ストレッチ・クラスタ環境のデータ・センター間のセッション・レプリケーションによってシステムで重大なパフォーマンス低下が引き起こされる可能性があります。異なる2つのレプリケーション・グループ(各サイトに1つ)を定義して、2つのサイト間で発生するレプリケーションの可能性を最小限にすることをお薦めします。

注意:

レプリケーション・グループの使用は、同一サイト内のサーバーのみに状態をレプリケートするために最良の方法ですが、決定的な方法ではありません。1つのサーバーが一方のサイトで使用でき、その他のサーバーはもう一方のサイトで使用できる場合、MANの間でレプリケーションが発生し、そのセッションの間はサーバーが同じサイトで元のようにオンラインになっても継続します。

- アクティブ/アクティブ型ストレッチ・クラスタはメトロ遅延モデルでのみ機能します。遅延は10ミリ秒より長くできません。

- 競合およびセキュリティの理由で、サイト間の共有ストレージの使用はお薦めしません。

- 両方のサイトが、2つのサイトのいずれかにある単一の管理サーバーで管理されます。各サイトが、JMSおよびトランザクションのログ(TLog)用の個別の共有ストレージを使用します。または、データベースが永続ストアとして使用されます。サイト1からサイト2(およびその逆)へのディスク・ミラーリングおよびレプリケーションを使用して、各サイトのこれらのアーティファクトのリカバリ可能なコピーを提供できます。一意のWebLogic Server管理コンソールが、両方のサイトで稼働しているサーバーを構成およびモニターするために使用されます。WebLogic Serverのインフラストラクチャは、ドメインで使用されているすべての異なるドメイン・ディレクトリに構成の変更をコピーする責任があります。

- 管理サーバー障害の場合、単一データ・センター・トポロジでの管理サーバー障害に適用される同じ考慮事項がマルチデータ・センターのアクティブ/アクティブ・ストレッチ・クラスタ・トポロジにも適用されます。高可用性ガイドの管理サーバーのフェイルオーバーまたはフェイルバックに説明されている標準のフェイルオーバー・プロシージャを使用してノード障害に対処します(管理サーバー・ドメイン・ディレクトリをホストしていた共有ストレージを指す同じデータ・センターにある別のノードで管理サーバーを再起動します)。また、適切なバックアップおよびリストア・プロシージャをデプロイして管理サーバーのドメイン・ディレクトリを定期的にコピーします。管理サーバーをホストしているサイト(ノードを含む)に影響を及ぼす障害がある場合、異なるサイトでサーバーを再起動する必要があります。そのためには、既存のストレージ・レプリケーション・テクノロジを使用して、フェルオーバー・サイトで使用可能な管理サーバーのドメイン・ディレクトリをコピーする必要があります。フェイルオーバー・サイトのサーバー/ディレクトリを(ドメインおよびアプリケーション・ディレクトリの両方を含めて)、元のサイトとまったく同一のドメイン・ディレクトリ構造が管理サーバーのドメイン・ディレクトリに対して作成されるようにリストアします。管理サーバーがリストアされるノードでノード・マネージャを再起動します。
同様に、管理サーバーは異なるサブネットにフェイルオーバーされ、その他のノードによりアクセス可能な異なるIP (VIP)の使用が必要になります。このサブネットのホスト名解決システムに適切な変更を加えて、このVIPが管理サーバーがサイト1でリスニング・アドレスとして使用した元の仮想ホスト名にマップするようにします。たとえば、サイト1でADMINHOSTVHN1が10.10.10.1にマップし、一方、サイト2でローカルの/etc/hostsまたはDNSサーバーのいずれかをADMINHOSTVHN1が20.20.20.1にマップされるように更新する必要があります。すべてのサーバーがADMINHOSTVHN1を管理サーバーにアクセスするアドレスとして使用します。管理サーバーがOracle HTTP ServerおよびLBRのフロント・エンドの場合、クライアントはこの変更に依存しません。クライアントが管理サーバーのリスニング・ホスト名に直接アクセスする場合、DNS解決でも更新する必要があります。

また、管理サーバーに対してホスト名検証が有効になっている場合、適切な信頼ストアとキー・ストアも新規証明書で更新する必要があります。『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の手順を使用します。

Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方にアクセスして、管理サーバーが正常に機能していることを確認します。

- 管理サーバーに対してリモートのサーバーは、配置されているサーバーよりも再起動が長くかかります。その理由は、管理サーバーとのすべての通信(起動時にドメイン構成を取得するためのもの)および最初の通信プール作成およびデータベース・アクセスがサイト間の遅延の影響を受けるためです。高可用性ガイドの管理サーバーの高可用性トポロジを参照してください。

- 自動化されたサイト間でのサーバー移行は、データベースがJMSおよびTLogの永続性のために使用されていないかぎりお薦めしません。それ以外の場合は、適切な永続ストアの一定のレプリカをサイト間で設定する必要があります。

- (顧客サイトのインフラストラクチャによっては)あるサイトで使用されている仮想IPが他のサイトへの移行に有効であるという可能性はありません。最初にサイト1で使用可能なリスニング・アドレスをサイト2で(あるいはその逆で)有効にするためには、通常、追加の操作が必要です。この操作は移行前スクリプトで自動化できますが、(単一データ・センターの範囲内で発生する)標準の自動化サーバー移行と比較すると一般にRTOは増加します。

- サイト間のトランザクションおよびJMSリカバリは、WebLogic Serverストレッチ・クラスタ内部のサービスまたはサーバーの移行を使用して発生します。サーバーおよびサービスの移行を参照してください。JMSまたはJTAのサーバーまたはサービス移行の場合、高可用性データベース上でリースしているデータベースの使用をお薦めします。コンセンサス非データベース・リースで構成されている場合、ストレッチ・クラスタ内のサーバーがリブートに失敗し、環境でネットワークの分断障害が発生したときにドメイン全体の再起動が必要になる可能性があります。

- アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでのゼロ・ダウンタイム・パッチ適用では、ストレッチ・クラスタ内のすべてのサーバーに対する更新が両方のサイト間で編成されます。ゼロ・ダウンタイム・パッチ適用を参照してください。

- アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、2つのサイト間でWebLogic Serverクラスタのみを拡張します。Coherenceでは、2つのアクティブなサイト間でデータをレプリケートするためにフェデレーテッド・キャッシュを使用して各サイトにCoherenceクラスタを持つ必要があります。Coherenceクラスタがサイト間で拡張されると、スプリット・ブレインの影響を受けやすくなります。

- Oracle Site Guardはアクティブ/パッシブ・トポロジまたはコンポーネントでのみ機能しますアクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、Oracle Site Guardはデータベースのフェイルオーバー/スイッチオーバーのみを実行できます。

- 表3-4は、ストレッチ・クラスタ・トポロジでのデータベース・リースに構成するお薦めの設定のリストを示しています。Oracle WebLogic Server MBeanリファレンスのMBeanに関する次の説明を参照してください。

- ClusterMBean

- JDBCConnectionPoolParamsBean

表3-4 ストレッチ・クラスタでのデータベース・リースにお薦めする設定

構成プロパティ

MBean/コマンド

説明

お薦めする設定

DatabaseLeasingBasisConnectionRetryCount

ClusterMBean

データベース・リースがデータソースから有効な接続を取得するための最大試行回数。

5 (デフォルト値は1

DatabaseLeasingBasisConnectionRetryDelay

ClusterMBean

接続が失敗したときに、データベース・リースがデータソースから新規接続の取得を試行する前に待機する時間の長さ(ミリ秒)。

2000 (デフォルト値は1000です)

TestConnectionOnReserve

JDBCConnectionPoolParamsBean

接続をクライアントに渡す前にWebLogic Serverでテストできるようにします。

有効。データソースのリース用。サーバーはスイッチオーバー中は稼働状態のままです。

-Dweblogic.cluster.jta.SingletonMasterRetryCount

サーバーの起動コマンド

シングルトン・マスターが選択されてそのリスニング・ポートをオープンするための試行カウントを指定します。シングルトン・マスターは、JTAを非アクティブ化する最初の試行時にすぐに使用可能にならない場合があります。

4 (デフォルト値は20です)

DatabaseLeasingBasisConnectionRetryCountが5に設定されているため、このプロパティは4に減らせます。この設定はデータベース・サーバーのブート中の時間コストを減らせます。

- 図3-3および図3-4は、ベンチマーク・テスト中に見つかった、異なる遅延に対するシステム全体のスループット(両方のサイトは一緒に稼働しています)で見られる低下を示す結果を表しています。図3-3は、約20ミリ秒のラウンド・トリップ時間(RTT)の遅延中にスループットが25%程度低下することを示しています。図3-4は、アプリケーションをデプロイするためにかかる時間の増加(同じサイトのすべてのサーバーおよびデータベースのデプロイメントと比較した場合)を表しています。
多くのテストで見られる提供データとパフォーマンスのペナルティを考慮して、アクティブ/アクティブ・ストレッチ・クラスタ・トポロジで遅延が2つのサイト間の通信に影響を及ぼす場合は10ミリ秒の遅延(RTT)を超えないことをお薦めします。

図3-3 ストレッチ・クラスタにおける遅延によるスループット低下

図3-4 デプロイメントの遅れ対ストレッチ・クラスタにおける遅延

アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの障害シナリオ

表3-5は、アクティブ/アクティブ・ストレッチ・クラスタ・トポロジに対する異なる障害シナリオのそれぞれでContinuous Availabilityの機能がどのように使用されているかを説明しています。

表3-5 アクティブ/アクティブ・ストレッチ・クラスタおよびアクティブ/パッシブ・データベース層の障害シナリオ

継続的可用性の機能

完全サイト障害

部分サイト/中間層障害(WebLogic Server/Coherence/OTD)

メンテナンス機能停止

ネットワークの分断障害

サイト間のトランザクション・リカバリ

- Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。

- JDBC TLogがサイト2のデータベースにレプリケートされます。

- サーバーおよびサービスをWebLogic Serverのサーバーおよびサービスの移行の機能を使用して移行します。

トランザクションが発生してストレッチ・クラスタで使用可能なサーバーにリカバリできるようになるか、サーバー移行が発生してトランザクションが移行済サーバーにリカバリされます。

- サイト1のアプリケーション・インフラストラクチャは、停止する前にサーバーが作業を完了できるように段階的に停止されます。

- Oracle Site GuardがOracle Data Guardと統合されてデータベースおよびアプリケーション・インフラストラクチャのスイッチオーバーを編成します。

- JDBC TLogがサイト2のデータベースにレプリケートされます。

- トランザクションが発生してストレッチ・クラスタで使用可能なサーバーにリカバリできるようになるか、サーバー移行が発生してトランザクションが移行済サーバーにリカバリされます。

- データベースとともに配置されたサイトはトランザクションの処理を続行します。データベースに対してリモートのサイトは接続例外およびトランザクション障害を取得します。

- サイト2はデータベースと通信できないためトランザクションは失敗します。

- イントラ・サーバーのトランザクション分断がある場合、トランザクションが失敗してトランザクションの状態に応じてロールバックするかコミットを再試行します。通信が再開すると、トランザクションが最終的にコミット/ロールバックします。

Oracle Traffic Director

サイト2のOracle Traffic Directorは、そのサイト上のサーバーへのトラフィックのルーティングを続行します。

サイト2のOracle Traffic Directorは、そのサイト上のサーバーへのトラフィックのルーティングを続行します。

- サイト1上のOracle Traffic Directorは停止します。

- サイト2のOracle Traffic Directorは、そのサイト上のサーバーへのトラフィックのルーティングを続行します。

サイト1およびサイト2の両方のOracle Traffic Directorは、それぞれのサイト上のサーバーへのトラフィックのルーティングを続行します。

Oracle Site Guard

Oracle Site Guardはデータベースのフェイルオーバーを編成します

何もしません。

Oracle Site Guardはデータベースのスイッチオーバーを編成します

何もしません。

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

動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。

動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールアウトが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。

動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。

動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。

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

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。

キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。