1 Oracle Fusion Middlewareディザスタ・リカバリの理解

Oracle Fusion Middlewareディザスタ・リカバリは、様々なOracle製品スイートでOracle Fusion Middlewareコンポーネントに対する保護を提供するディザスタ・リカバリ・ソリューションです。

この章の内容は次のとおりです。

ディザスタ・リカバリの用語

ディザスタ・リカバリの用語について学習します。

ディザスタ・リカバリでは、次の用語が使用されます。

• 障害

  サイトまたは地域で許容できないダメージまたは損失を引き起こす、突然かつ計画外の致命的なイベント。この障害というイベントが発生すると、許容しがたいほどの期間にわたって、重大な機能、プロセスまたはサービスを提供する機会が損なわれるので、組織はそのリカバリ計画を実行します。

• ディザスタ・リカバリ

  本番サイトにおいて、天災による停止や計画外の停止を予防する機能。別の場所に設置したセカンダリ・サイトにアプリケーションやデータをレプリケートするためのリカバリ戦略を使用します。

• ディザスタ・リカバリ・トポロジ

  Oracle Fusion Middlewareディザスタ・リカバリ・ソリューションを構成する、本番サイトとセカンダリ・サイトのハードウェアおよびソフトウェアのコンポーネント。

• エンタープライズ・デプロイメント・ガイド

  エンタープライズ・デプロイメント・ガイドには、検証済の詳細な手順が記載されており、選択したOracle Fusion Middleware製品のマルチホスト型でセキュアかつ高可用性の本番トポロジを単一のデータ・センターの範囲で計画、準備、インストールおよび構成できます。『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』はここから参照できます。

• ホスト名別名

  ホスト名別名とは、実際のネットワーク名を指定する以外に、システムにアクセスするための代替手段です。通常は、システムのネットワーク名と同じIPアドレスに変換されます。これは、DNSのような名前解決システムで定義することも、各システムのローカル・ホスト・ファイルでローカルに定義することもできます。1つのシステムに対して複数のホスト名別名を定義できます。

• 物理ホスト名

  物理ホスト名とは、gethostname()コールまたはhostnameコマンドで返されるシステムのホスト名です。通常の場合、物理ホスト名は、クライアントがシステムにアクセスするために使用するネットワーク名でもあります。この場合、DNS (または使用中の任意の名前解決メカニズム)でこの名前にIPアドレスが関連付けられます。関連付けられたIPは、システムのネットワーク・インタフェースのいずれか1つで有効化されます。

  1つのシステムには通常、物理ホスト名が1つ設定されています。また、ネットワーク・インタフェースで有効化されているIPアドレスに対応して、クライアントがネットワークを介してアクセスするために使用するネットワーク名を、追加で1つ以上設定することもできます。各ネットワーク名は、1つ以上のホスト名別名に置き換えることができます。

• 本番(プライマリ)サイト

  障害保護トポロジにおける本番(プライマリ)サイトとは、システムのワークロードをある正確な時点に実行しているシステムです。これは、ある正確な時点にビジネス・ロジックの実行とリクエストの処理にアクティブに使用されている、ハードウェア、ネットワークおよびストレージ・リソースとプロセスのグループです。

• 最大可用性アーキテクチャ

  Oracleの最大可用性アーキテクチャ(Oracle MAA)とは、Oracle製品(Database、Fusion Middleware、Applications)のデータ保護および可用性に関するベスト・プラクティスのブループリントです。いかなるOracleデプロイメントにおいても、Oracleの最大可用性アーキテクチャのベスト・プラクティスを実装することが重要な要件の1つとなります。Oracleシステムを設定および管理するための推奨事項が用意されています。Oracleの最大可用性には、エンタープライズ・デプロイメント・ガイドの推奨事項が含まれており、データ・センターまたはリージョン全体に影響する停止の計画停止時間と計画外停止時間を最小限に抑えるための障害保護のベスト・プラクティスが追加されています。

• リカバリ・ポイント目標(RPO)

  リカバリ・ポイント目標とは、システムで許容されるデータ損失の量、または停止が発生したときにビジネスの観点から受け入れられるデータ損失の量です。

• リカバリ時間目標(RTO)

  リカバリ時間目標とは、システムで許容される停止時間、または停止が発生したときにアプリケーションやサービスが使用できない状態にあってもビジネスの観点から受け入れられる時間です。

• サイトのフェイルオーバー

  本番サイトに障害が発生したことが原因で本番サイトが突然使用できなくなった後、現在のセカンダリ・サイトを新しい本番(プライマリ)サイトにするプロセス。このドキュメントでは、フェイルオーバーという用語は、サイトのフェイルオーバーの意味でも使用されます。

• サイトのスイッチバック

  現在の本番サイトおよび現在のセカンダリ・サイトをそれらの元の役割に戻すプロセス。スイッチバックは、スイッチオーバー操作の完了後に行う計画済の操作です。現在のセカンダリ・サイトが本番サイトになり、現在の本番サイトがセカンダリ・サイトになります。このドキュメントでは、スイッチバックという用語は、サイトのスイッチバックの意味でも使用されます。

• サイトのスイッチオーバー

  本番サイトとセカンダリ・サイトの役割を逆転するプロセス。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のセカンダリ・サイトが新しい本番サイトになり、現在の本番サイトが新しいセカンダリ・サイトになります。このドキュメントでは、スイッチオーバーという用語は、サイトのスイッチオーバーの意味でも使用されます。

• サイトの同期

  本番サイトで行った変更をセカンダリ・サイトに適用するプロセス。たとえば、本番サイトで新しいアプリケーションがデプロイされたら、同期を実行して、同じアプリケーションがセカンダリ・サイトでもデプロイされるようにする必要があります。

• セカンダリ(スタンバイ)サイト

  セカンダリ・サイトとは、プライマリ・サイトが処理していたビジネス・ロジックとリクエストを引き継ぐことができるバックアップの場所です。通常、セカンダリ・サイトは「スタンバイ(非アクティブ)モード」であるため、「スタンバイ」とも呼ばれます。つまり、通常の操作中は本番ワークロードを処理していません。ただし、セカンダリ・サイトを他の目的で使用できないわけではありません。このことが特に当てはまるのは、セカンダリ・サイトがレポート操作の目的や、変更をプライマリ・サイトで適用する前に検証するというさらに重要な目的で使用されるような最新のモデルです。

• 対称トポロジ

  Oracle Fusion Middlewareディザスタ・リカバリ構成の1つで、本番サイトとセカンダリ・サイトの間で各階層の構成が完全に一致します。同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションがあり、同じ容量で構成されたサイトとシステムの両方で同じポートが使用されています。このドキュメントでは、エンタープライズ構成用に、Oracle Fusion Middlewareディザスタ・リカバリの対称トポロジを設定する方法について説明します。

• 非対称トポロジ

  Oracle Fusion Middlewareディザスタ・リカバリ構成の1つで、本番サイトとセカンダリ・サイトの間で各階層の構成に相違があります。たとえば、セカンダリ・サイトの方が本番サイトより、ホストやインスタンスの数が少ないというようなケースが考えられます。

  ノート:

  スケール・ダウンされたセカンダリ・システムの使用はお薦めしません。非対称のスタンバイは、ワークロードが適切に処理されないとカスケード・フォールの原因になる可能性があり、構成ミスとデータ損失を引き起こす場合もあります。

• システム

  システムとは、相互に機能することでアプリケーションをホスティングする、一連のターゲット(ホスト、データベース、アプリケーション・サーバーなど)を指します。たとえば、Enterprise Managerでアプリケーションを監視するには、最初に、アプリケーションが動作するターゲットであるデータベース、リスナー、アプリケーション・サーバーおよびホストで構成されるシステムを作成します。

• サイト

  サイトとは、アプリケーションのグループを実行するのに必要なデータセンターにある、一連の様々なコンポーネントを指します。サイトは、たとえば、Oracle Fusion Middlewareインスタンス、データベース、ストレージなどがあります。

• 仮想ホスト名

  仮想ホスト名とはネットワーク・アドレスを指定可能なホスト名で、1つ以上の物理システムにマップできます。そのためには、ロード・バランサまたはハードウェア・クラスタを通じて、ノード内の関連するVIPを有効にします。

  ロード・バランサの場合、このドキュメントでは仮想サーバー名という用語は仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にシステムと通信します。

  ハードウェア・クラスタでは、仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。

  単一ホストのコンテキストでは、仮想ホスト名とは、実際のネットワーク名を指定する以外に、システムにアクセスするための追加のホスト名です。通常、ノードのネットワーク・インタフェースで有効な仮想IPにマップされるか、システム内の既存のIPアドレスにマップされます。この最後のケースでは、名前解決システムのDNSで、またはローカル・ホスト・ファイルでローカルに、システムのホスト名別名になります。

• 仮想IP

  一般に、仮想IP (VIP)とは、セカンダリ・ネットワーク・インタフェース・コントローラ(NIC)または仮想ネットワーク・インタフェース・コントローラ(VNIC)に割り当てられるIPです。ハードウェア・ノードまたは仮想マシンは、独自の物理IPアドレスと物理ホスト名を持ち、複数のVIPアドレスを追加で使用できます。これらのVIPアドレスは、異なるノード間を「浮動」します(移行できます)。VIPは、ロード・バランサとハードウェア・クラスタでも使用されます。VIPは、バックエンド・ポイントからアクセッサを抽象化する単一エントリ・ポイントのIPアドレスを表し、様々な目的のためにノード間で移行または移動できます。

  従来、ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタへのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。

  現在、正確なコンポーネントを(コンシューマに対して透過的に)別のハードウェアにフェイルオーバーする必要がある場合には、仮想IPは手動またはアプリケーション・サーバー経由でも管理されます(たとえば、WebLogicにはサーバー移行による仮想IP移行機能が用意されています)。

  また、ロード・バランサも一連のサーバーのエントリ・ポイントとして仮想IPを使用します。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。

• WebLogic Server全体の移行

  サーバー全体の移行は、障害発生時にWebLogic Serverインスタンスが物理的に別のシステムに移行するときに行われます。

• WebLogicサービスの移行

  サービス・レベルの移行は、WebLogic Serverで実行されているサービスが、クラスタ内の別のWebLogic Serverインスタンスに移動するときに行われます。

Oracle Fusion Middlewareディザスタ・リカバリの概要

Oracle Fusion Middlewareディザスタ・リカバリについて学習します。

障害保護戦略は、システムのライフ・サイクルにおける様々なフェーズに対応する必要があります。

• 初期設定

  セカンダリの場所にあるプライマリ・システムの初期レプリカを取得するように、最初にシステムを構成します。

• スイッチオーバーとフェイルオーバーの管理

  データ・センターまたは地域全体に影響する計画停止時間または計画外停止時間が発生したら、ワークロードをセカンダリの場所に移動します。

• メンテナンス

  • 継続的な同期

    構成、メタデータおよびランタイム・データがプライマリ・システムで変更されたら、その変更を反映してセカンダリの場所を最新の状態に保ちます。

  • パッチ適用

    ディザスタ・リカバリ・トポロジにパッチを適用します。

  • スケール・アウト操作

    プライマリも変更されたら、セカンダリのシステムをスケーリングします。

初期設定を実行して、障害保護システムのライフサイクルを準備する前に、障害保護システムの実装の推進要因となる重要な側面を理解することが不可欠です。また、ローカル障害からの保護を提供する機能と障害から保護する機能を区別することも重要です。

そのほか、障害保護構成において様々なバリエーションの決定要因となる主な領域が2つあります。データ・レプリケーション(システムをセカンダリの場所にレプリケートする方法)と構成の仮想化(プライマリで使用される構成をセカンダリで有効にする方法)です。Oracle MAAの推奨事項に従う際には、次の点を理解することが重要です。ディザスタ・ソリューションではプライマリのレプリカであるセカンダリ・システムを使用して、プライマリが完全に失われた場合に、セカンダリ・システムが優れた本番サイトそのものになることができるようにする必要があります。以降の項では、これらの領域について詳しく説明します。

障害保護とローカル障害保護

いかなるOracle Fusion Middlewareデプロイメントにおいても、Oracleの最大可用性アーキテクチャの実現が重要な要件の1つとなります。Oracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドでは、単一のデータ・センターの範囲内でベスト・プラクティスと推奨事項を提供します(『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照)。Oracle Fusion Middlewareには、広範囲にわたる高可用性機能が組み込まれています。この高可用性機能には、プロセス停止の検出と再起動、サーバー・クラスタリング、サービス移行、クラスタの統合、GridLink、ロード・バランシング、フェイルオーバー、バックアップとリカバリ、ローリング・アップグレード、ローリング構成変更などが含まれており、計画外停止時間からエンタープライズ・デプロイメントを保護し、計画停止時間を最小限に抑えます。

Fusion Middlewareシステムで発生する停止時間のほとんどは、ローカル障害が原因です。これらは、データ・センター内のコンポーネントやリソースの一部に影響する障害ですが、その正確なコンポーネントがローカルで冗長化されていれば修正できます。これらの停止によってデータ・センター全体がアクセス不可になることは通常ありません。したがって、障害保護は、これらのローカル障害に対する既存の戦略に追加して初めて意味を持ちます。リージョン全体に影響する完全なサイトの停止や停止時間が発生することは、ローカル・ストレージのクラッシュ、ハイパーバイザの障害、ローカル・ネットワークの問題などと比べてはるかにまれです。このタイプの停止時間から保護するには、ご使用のFusion Middlewareコンポーネントのエンタープライズ・デプロイメント・ガイドに記載されている推奨事項に従ってください。エンタープライズ・デプロイメント・ガイドは、この障害保護ガイドの基盤となっています。

これらのローカル障害に加えて、エンタープライズ・デプロイメントは、データ・センターまたは地域全体をダウンさせる可能性のある予測不可能な障害や天災から保護する必要があります。Fusion Middlewareの最大可用性アーキテクチャは、障害保護も含めて、Fusion Middlewareエンタープライズ・デプロイメント・ガイドで規定されているすべてのベスト・プラクティスを実装します。障害保護ソリューションでは、本番サイトとは地理的に異なる場所に、本番サイトと同一のサービスおよびリソースを備えたセカンダリ・サイトを設定する必要があります。機能レベルとパフォーマンス・レベルでの不整合を防ぐために、本番サイトとセカンダリ・サイトの両方で対称トポロジと容量を構成することをお薦めします。セカンダリ・サイトは通常、パッシブ・モードです。このデプロイメント・モデルは、アクティブ/パッシブ・モデルまたはアクティブ/スタンバイ・モデルと呼ばれることがあります。このコンテキストでの「パッシブ」とは、その時点でプライマリが処理している本番ワークロードをセカンダリ・サイトが処理していないことを意味します。ただし、セカンダリ・システムを通常の操作で使用できないわけではありません。このガイドで提案されているDR構成内のセカンダリ・システムは、新しいアプリケーションの確認やパッチの検証、あるいはそれらの変更をプライマリ・システムに適用する前のワークロード・テストの実行に使用されます。通常、このモデルは、2つのサイトがWAN経由で接続されていて、ネットワーク待機時間の関係で2つのサイトにまたがるクラスタリングができない場合に採用されます。

データ・レプリケーション

ほとんどのOracle Fusion Middlewareコンポーネントはステートフルです。様々な永続的形式で保存された様々なタイプのデータを、プライマリ・サイトからセカンダリ・サイトにコピーする必要があります。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データを、定期的にセカンダリ・サイトにレプリケートする必要があります。これを行うのは、スイッチオーバーまたはフェイルオーバーのシナリオにおいて、新しいアクティブ・サイトからの応答を、元のプライマリから提供されたものと完全に一致させるためです。様々なWebLogicコンポーネントやFusion Middlewareコンポーネントがファイル・システムに構成情報を保存します。また、キーストア(アイデンティティおよび信頼用)などのアーティファクトは、Oracle Fusion Middleware 14.1.2エンタープライズ・デプロイメントのSSL構成の重要な要素です。これらのストアは、外部のボールトやファイル・システムにも存在している可能性があります。

Oracle Fusion Middlewareディザスタ・リカバリ・ソリューションでは、Oracle Fusion Middlewareの中間層コンポーネントの障害保護に様々なレプリケーション・テクノロジを使用できます。ストレージ・レベルのレプリケーションを使用でき、サードパーティのストレージ・ベンダーが推奨するソリューションと互換性があります。また、DBFSやrsyncなど、サポートされている他の方法を使用して、Fusion Middlewareの中間層構成をレプリケートすることもできます。通常は1つのレプリケーション戦略がすべてのファイル・システムに使用されますが、各ケースのRTO、RPOおよび一貫性のニーズに応じて、データのタイプごとに異なる方法を採用できます。

Oracle Fusion Middlewareで使用されるOracle Databaseのレプリケーションおよび障害保護は、Oracle Data Guardによって提供されます。これは、リモート・ミラー構成でOracle Fusion Middlewareを障害から保護するためにサポートされている唯一の構成です。

様々なタイプのデータのレプリケーション頻度は、(データベース上かファイル・システム上かに関係なく)システムで要求されるリカバリ・ポイント目標(RPO)と同程度の高さにする必要があります。プライマリ・システムからセカンダリ・システムへの移行にかかる時間は、システムのリカバリ時間目標(RTO)と同程度の短さにする必要があります。

アクセス・ポイントと構成の仮想化

セカンダリに変更を加えることなくプライマリの構成およびメタデータを使用することも、適切な障害保護ソリューションの重要な側面です。障害保護ソリューションでは、プライマリ構成を操作してセカンダリに合せることは避ける必要があります。このような操作を行うと、フェイルオーバー・シナリオのRTOが長くなり、アプリケーションが進化するにつれてメンテナンスが困難になります。レプリケートする必要のある情報量が少なければ少ないほど、レプリケーション・サイクルのスケジュール頻度を高めることができるため、システムのリカバリ・ポイント目標が短くなります。構成をプライマリから実行することもスタンバイから実行することも可能にするには、次の要件を満たす必要があります。

• システムにアクセスするクライアントとその他のアプリケーションまたはサービスは、スイッチオーバーまたはフェイルオーバーの後、フェイルオーバーしたリソースへのアクセスに使用されるhostnameを変更することなく、引き続き同じアドレスをアクセスに使用する必要があります。特に、これらのフロントエンド・アドレスがパブリックで、何千ものブラウザまたはデバイスによって使用されている場合、障害はコンシューマに対して透過的である必要があります。

• Fusion Middlewareシステム内の様々なコンポーネントによって使用されるすべてのリスニング・アドレス(システムのフロントエンド・アドレス以外)は、両方の場所でアクティブ化できるホスト名(各場所で異なるIPにマッピング)である必要があります。これにより、セカンダリがプライマリから受け取る構成内のリスニング・アドレスを置き換える必要がなくなります。

• 外部の依存関係(Fusion Middlewareドメインの一部ではないサービスなど)には、プライマリとセカンダリの両方から同じ構成でアクセスできる必要があります。これには、外部のホスト名、ストレージ、またはネットワーク・リソースが含まれます。両方のリージョンでこれらすべてに等しくアクセスできる必要があります。

対称性の要件

Oracle Fusion Middlewareディザスタ・リカバリ・トポロジでは、セカンダリ・サイトにあるプライマリのレプリカが使用されます。スケール・ダウンされたセカンダリ・システムの使用はお薦めしません。非対称のセカンダリ・システムは、ワークロードが適切に処理されないとカスケード・フォールの原因になる可能性があり、構成ミスとデータ損失を引き起こす場合もあります。2つのサイト間の対称性は、次に基づいて構成されます。

• ハードウェア、ノードおよびインフラストラクチャ・リソース

  本番サイトとセカンダリ・サイトに同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションがあります。また、両方のサイトで同じポートが使用されます。システムは同じ容量で構成されており、まったく同じワークロードを持続できる必要があります。

• ディレクトリ名とパス

  本番サイトのホストに存在するすべてのファイルが、セカンダリ・サイトのピア・ホストにある同一ディレクトリ・パスに存在する必要があります。したがって、WebLogicドメイン、デプロイメントおよび構成に対するOracleホームの名前とディレクトリ・パスは、本番サイトとセカンダリ・サイトで同じである必要があります。

• ポート番号

  ポート番号は、リスナーによってリクエストのルーティングに使用されます。ポート番号は構成に保存され、本番サイトのホストとセカンダリ・サイトのピア・ホストで同じである必要があります。

• セキュリティ

  本番サイトとセカンダリ・サイトの両方に同じユーザー・アカウントが存在している必要があります。中央の同じLDAPコンテンツおよびポリシーに両方の場所からアクセスできる必要があります。また、本番サイトとセカンダリ・サイトでファイル・システムとSSLを同様に構成する必要があります。たとえば、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』では、本番サイトでSSLが使用されるため、プライマリとまったく同様に構成したSSLをセカンダリ・サイトでも使用する必要があります。

• ロード・バランサと仮想サーバー名

  本番サイトについては、仮想サーバー名を使用してフロントエンド・ロード・バランサを設定する必要があります。セカンダリ・サイトについては、同じ仮想サーバー名を使用して同一のフロントエンド・ロード・バランサを設定する必要があります。

• ソフトウェア

  本番サイトとセカンダリ・サイトで同じバージョンのソフトウェアを使用する必要があります。また、両方のサイトでオペレーティング・システムのパッチ・レベルが同じである必要があります。さらに、本番サイトとセカンダリ・サイトの両方にOracleまたはサード・パーティ・ソフトウェアのパッチを適用する必要があります。

Oracle Fusion Middlewareディザスタ・リカバリ・アーキテクチャの概要

Oracle Fusion Middlewareエンタープライズ・デプロイメントのディザスタ・リカバリ・ソリューションにおける一般的なトポロジと主な側面について学習します。

図1-1に、オンプレミス・トポロジとしてのOracle Fusion Middlewareディザスタ・リカバリ・トポロジの概要を示します。

図1-1 Oracle Fusion Middlewareディザスタ・リカバリ・トポロジにおける本番サイトとスタンバイ・サイト

プライマリ・システムは、Oracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドに従って構築されています。図1-1に示したソリューションのその他の重要な側面をいくつか次に示します。

• このソリューションには2つのサイトが含まれています。現在の本番サイトが稼働中かつアクティブであるのに対し、2番目のサイトはセカンダリ・サイトとして機能し、パッシブ・モードになっています。

• 各サイトのホストには、関連するEDGに規定されているように、そのサイトの共有ストレージ・システムにアクセスするためのマウント・ポイントが定義されています。本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージに、中間層のファイル・システムなどのデータをコピーするには、レプリケーション・テクノロジ(ストレージ・レベルのレプリケーション、rsyncまたはDBFS)を使用します。

• ファイル・レプリケーションが有効化されると、アプリケーションのデプロイメント、構成、メタデータ、データおよび製品バイナリ情報が、本番サイトからスタンバイ・サイトにレプリケートされます。

• スタンバイ・サイト・ホストでは、Oracleソフトウェアのインストールを実行する必要はいっさいありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされると、同等のOracleホーム・ディレクトリおよびデータが、スタンバイ・サイトのストレージに書き込まれます。

• Oracle Fusion Middlewareリポジトリやカスタム・アプリケーション・データベースなど、すべてのOracle Databaseリポジトリをレプリケートするには、Oracle Data Guardを使用します。Oracle Data Guardによって提供される障害保護の詳細は、『Oracle Data Guard』を参照してください。

• 各リージョンの中間層は、そのリージョンのローカルのデータベースにのみ接続します。プライマリの中間層からセカンダリのデータベースへのリージョン間接続とセカンダリの中間層からプライマリのデータベースへのリージョン間接続は避ける必要があります。ファイアウォールやホスト名解決などの要因によっては、これらの接続がハングしてFusion Middlewareシステムの稼働状態に影響する可能性があるためです。

• 通常の操作では、ユーザー・リクエストは最初に本番サイトにルーティングされます。

• 本番サイトの障害または計画停止が発生した場合、次のサマリー・ステップが実行され、トポロジ内でセカンダリ・サイトがプライマリ・ロールを引き継ぎます。

  1. 本番サイトからセカンダリ・サイトへのファイル・レプリケーションが停止されます(障害発生時には、その障害により、レプリケーションはすでに停止されている可能性があります)。

  2. Oracle Data Guardを使用して、Oracle Databaseのフェイルオーバーまたはスイッチオーバーが実行されます。

  3. セカンダリ・サイトのサービスおよびアプリケーションが起動されます。

  4. グローバル・ロード・バランサまたはDNSを使用して、変更ユーザー・リクエストがセカンダリ・サイトに再ルーティングされます。この時点で、セカンダリ・サイトが本番のロールを引き継いでいます。

以降の章では、障害保護システムを最初に構成する方法と、そのライフサイクルを通じてシステムを管理する方法について詳しく説明します。

Oracle Cloud InfrastructureでのOracle Fusion Middlewareディザスタ・リカバリ

Oracle Cloud Infrastructureを使用して、オンプレミスのプライマリ・デプロイメントのセカンダリ・システムをホストする方法を学習します。

セカンダリ・システムがOracle Cloud Infrastructure (OCI)に存在する場合、プライマリ・システムを分析し、セカンダリにピア・リソースを作成して、Fusion Middlewareシステム全体をセカンダリにレプリケートするフレームワークが用意されています。このフレームワークはオープン・ソースであり、GitHubで入手できます。フレームワークにより、JEE/Jakartaコンポーネントに基づいて、既存のOracle WebLogicドメイン環境またはFusion Middlewareドメイン環境の対称ディザスタ・リカバリ・システムがOCIに作成および構成されます(LDAPなどのシステム・コンポーネントは対象となりません。これは、標準のWebLogicデプロイメントに基づくシステムを対象としています)。このフレームワークは、プライマリ環境がエンタープライズ・デプロイメント・ガイドに従っている場合に、最大レベルの自動化を実現します。作成したリソースのインベントリが維持されますが、このインベントリはクリーンアップや再利用が簡単に行えるため、ディザスタ・リカバリのデプロイメントと確認をすばやく実行でき、高いコストが発生することもありません。これらのアーキテクチャは通常、ハイブリッドの障害保護アーキテクチャと呼ばれ、「オンプレミスからオンプレミス」の障害保護システムと比較して多くのメリットをもたらします。

• ワークロードを段階的かつ簡単にクラウドに移行できます。セカンダリ・システムは、システムをクラウドに移行するためのベッド・テストとして使用できます。これにより、クラウド・インフラストラクチャに迅速かつ汎用的な方法で慣れることができます。

• OCIの高可用性と信頼性の機能を活用します。Oracle Cloud Infrastructureは、フォルト・ドメインと可用性ドメイン、様々なレベルでのストレージの継続的ミラーリング、ロード・バランサとネットワーク・デバイスの冗長性などを使用して、多くの高可用性機能を提供します。

• 共有ストレージ、ネットワーク、コンピュート、その他の多くのインフラストラクチャ要素がOracle Cloudによって直接管理されることで、管理のオーバーヘッドが最小限に抑えられるため、本格的なセカンダリ・オンプレミスと比較してコストを削減できます。Oracle Cloudユニバーサル・クレジットを使用してセカンダリをプロビジョニングできます。また、何回かテストした後にDR構成を使用しないと判断した場合には、セカンダリ・システムをすぐにクリーンアップでき、クレジットをすばやく回収して他の目的で利用できます。

これらの一般的なメリットとは別に、OracleのWebLogicハイブリッド・ディザスタ・リカバリ・フレームワークは、人的エラーを回避し、多くのMAAベスト・プラクティスを実装する信頼性の高いプロセスを通じて、障害保護の設定作業を完全に自動化します。

プライマリ・システムはOCI上に存在していても構いません。このフレームワークを使用すると、プライマリ・システムが、Oracle Fusion MiddlewareをOCIにインストールする手動手順を使用して作成された場合や、Oracle Marketplaceスタックを使用している場合でも、OCIにセカンダリ・コピーを作成できます。一般に、設定手順、レプリケーション・テクノロジおよび構成はOCIに固有であり、このような場合には正確な実装の詳細が提供されます。トポロジの詳細と付属している様々なツールの使用方法は、GitHubのWLS_HYDRフレームワークのページを参照してください。