1 Oracle Fusion Middleware障害時リカバリの概要

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

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

• Oracle Fusion Middleware障害時リカバリの概要
  Oracle Fusion Middleware障害時リカバリで解決する問題および用語について確認します。
• Oracle Fusion Middlewareコンポーネントの障害時リカバリの設定
  Oracle Fusion Middlewareエンタープライズ・デプロイメント向けに障害時リカバリを設定する方法を確認します。

Oracle Fusion Middleware障害時リカバリの概要

Oracle Fusion Middleware障害時リカバリで解決する問題および用語について学習します。

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

• 問題の説明と一般的なソリューション
  エンタープライズ・デプロイメント向けにOracle Fusion Middleware障害時リカバリ・ソリューションをLinuxとUNIXのオペレーティング・システムにデプロイして、レプリケーション・テクノロジとOracle Data Guardテクノロジを利用する方法を学習します。
• 用語
  障害時リカバリの用語を確認します。

問題の説明と一般的なソリューション

エンタープライズ・デプロイメント向けにOracle Fusion Middleware障害時リカバリ・ソリューションをLinuxとUNIXのオペレーティング・システムにデプロイして、レプリケーション・テクノロジとOracle Data Guardテクノロジを利用する方法を学習します。

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

また、エンタープライズ・デプロイメントは、予測不可能な障害や天災から保護する必要があります。保護するためのソリューションとして、本番サイトとは別の場所にスタンバイ・サイトを設定する方法があります。スタンバイ・サイトは本番サイトと比較して、サービスやリソースの数が同じか下回る場合がありますが、機能レベルとパフォーマンス・レベルの不整合を防ぐために、本番サイトとスタンバイ・サイトの両方で対称トポロジと容量を構成することをお薦めします。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データが、定期的にスタンバイ・サイトにレプリケートされます。スタンバイ・サイトは通常はパッシブ・モードであり、本番サイトを利用できない場合に起動されます。このデプロイメント・モデルは、アクティブ・パッシブ・モデルと呼ばれることがあります。通常、このモデルは、2つのサイトがWAN経由で接続されていて、ネットワーク待機時間の関係で2つのサイトにまたがるクラスタリングができない場合に採用されます。

ホット・プラグ可能性は、Oracle Fusion Middlewareの中核となる戦略の一つであり、重要な機能の一つでもあります。異機種が混在する企業向けに構築されたOracle Fusion Middlewareは、モジュール形式のコンポーネント・ソフトウェアで構成されており、それらのソフトウェアは、一般的な各種プラットフォーム上で稼働し、他のテクノロジやビジネス・アプリケーションと相互運用されます。たとえば、Oracle Fusion Middlewareの製品(ADF、Oracle BPEL Process Manager、Oracle Enterprise Service Bus、Oracle Web Services Manager、Adapters、Oracle Access Manager、Oracle Identity Governance、Rules、Oracle TopLink、Oracle Business Intelligence Publisherなど)は、Oracle WebLogic Serverコンテナで稼働することに加えて、IBM WebsphereやJBossなど、Oracle以外のコンテナでも稼働できます。

Oracle Fusion Middleware障害時リカバリ・ソリューションは、Oracle Fusion Middlewareの中間層コンポーネントの障害保護に異なるレプリケーション・テクノロジを使用しています。ストレージ・レベルのレプリケーションを使用し、サード・パーティ・ベンダーの推奨するソリューションと互換性があります。また、このドキュメントで説明するDBFSやrsyncなど、FMWの中間層構成をレプリケートするためにサポートされているその他の方法もあります。

Oracle Fusion Middlewareに含まれるOracle Databaseの障害保護は、Oracle Data Guardによって実現されます。

用語

障害時リカバリの用語について学習します。

障害時リカバリでは、次の用語を使用します。

• 障害

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

• 障害時リカバリ

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

• ホスト名別名

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

• 物理ホスト名

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

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

• 仮想ホスト名

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

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

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

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

• 仮想IP

  一般的に、仮想IPはハードウェア・クラスタやロード・バランサに割り当てることができます。クラスタにおいて単一のシステム・ビューをネットワークのクライアントに対して実現するために、クラスタのメンバーであるサーバーのグループに対して仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPはハードウェア・クラスタやサーバーのロード・バランサに割り当てることができます。

  ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタ(スタンドアロンのシステムにも設定可能)へのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的ハードウェア・クラスタ構成では、各システムには固有の物理IPアドレスと物理ホスト名が付与されながら、数個のクラスタIPアドレスを付与することもできます。これらのクラスタIPアドレスは、2台のノードにおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

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

• 本番サイトの設定

  このマニュアルに記述した手順を使用して本番サイトを作成するには、物理ホスト名およびホスト名別名を計画して作成し、共有ストレージ上でOracle Fusion Middlewareインスタンスのインストール先とするOracleホーム・ディレクトリに対するマウント・ポイントおよびシンボリック・リンク(該当する場合)をホスト上に作成し、バイナリ・ファイルとインスタンスをインストールして、アプリケーションをデプロイする必要があります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、「ストレージの設定」を参照してください。

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

  本番サイトが突然使用できなくなった後で、現在のスタンバイ・サイトを新しい本番サイトにするプロセス。たとえば、本番サイトに障害が発生したためなどです。このマニュアルでは、サイトのフェイルオーバーを指す用語として「フェイルオーバー」も使用します。

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

  現在の本番サイトおよび現在のスタンバイ・サイトをそれらの元の役割に戻すプロセス。スイッチバックは、スイッチオーバー処理の完了後に行う計画済の操作です。スイッチバックを行うと、各サイトの元のロールがリストアされます。具体的には、現在のスタンバイ・サイトが本番サイトになり、現在の本番サイトがスタンバイ・サイトになります。このマニュアルでは、サイトのスイッチバックを指す用語として「スイッチバック」も使用します。

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

  本番サイトとスタンバイ・サイトの役割を逆転するプロセス。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のスタンバイ・サイトが新しい本番サイトになり、現在の本番サイトが新しいスタンバイ・サイトになります。このマニュアルでは、サイトのスイッチオーバーを指す用語として「スイッチオーバー」も使用します。

• サイトの同期

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

• スタンバイ・サイトの設定

  スタンバイ・サイトを作成するプロセス。このマニュアルに記述した手順を使用して本番サイトを作成するには、物理ホスト名およびホスト名別名を計画して作成し、スタンバイ共有ストレージ上のOracleホーム・ディレクトリに対するマウント・ポイントおよびシンボリック・リンク(該当する場合)を作成する必要があります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、「ストレージの設定」を参照してください。

• 対称トポロジ

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

• 非対称トポロジ

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

  ノート:

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

• トポロジ

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

• ターゲット

  ターゲットは、エンタープライズ内のインフラストラクチャおよびビジネス・コンポーネントを表すコアEnterprise Managerエンティティです。ビジネスが効率的に機能するには、これらのコンポーネントを監視および管理する必要があります。たとえば、Oracle Fusion MiddlewareドメインやOracle Databaseなどです。

• システム

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

• サイト

  サイトは、アプリケーションのグループを実行するのに必要なデータセンターにある、一連の様々なターゲットを指します。サイトは、たとえば、Oracle Fusion Middlewareインスタンス、データベース、ストレージなどがあります。データセンターは、Oracle Site Guardによって複数のサイトを定義することができ、各データセンターにおけるスイッチオーバーやフェイルオーバーなどの操作は、独立して管理されます。

Oracle Fusion Middlewareコンポーネントの障害時リカバリの設定

Oracle Fusion Middlewareエンタープライズ・デプロイメント向けに、障害時リカバリ・ソリューションを設定する方法を学習します。

次の項では、設定の詳細について説明します。

• Oracle Fusion Middleware障害時リカバリ・アーキテクチャの概要
  Oracle Fusion Middlewareコンポーネントのデプロイメント・アーキテクチャ、およびOracle Fusion Middlewareのデータとデータベースの内容を保護するためにサポートされている方法について確認します。
• このドキュメントに記述されているコンポーネント
  Oracle Fusion Middleware障害時リカバリがサポートしているOracle製品スイートについて確認します。

Oracle Fusion Middleware障害時リカバリ・アーキテクチャの概要

Oracle Fusion Middlewareコンポーネントのデプロイメント・アーキテクチャ、およびOracle Fusion Middlewareのデータとデータベースの内容を保護するためにサポートされている方法について学習します。

Oracle Fusion Middlewareコンポーネントおよびアプリケーションの製品バイナリ・ファイルと構成は、中間層の異なるディレクトリにデプロイされます。また、製品のほとんどで、メタデータとランタイム・データもデータベース・リポジトリに格納されます。そのため、Oracle Fusion Middleware障害時リカバリ・ソリューションによって、データベースに格納されている中間層ファイル・システム・データは、本番サイトとスタンバイ・サイトで同期がとられています。

Oracle Fusion Middlewareデータおよびデータベースの内容を保護するために、Oracle Fusion Middleware障害時リカバリでは、次の方法をサポートしています。

• Oracle Fusion Middleware製品バイナリ・ファイル、構成ファイルおよびメタデータ・ファイル

  レプリケーション・テクノロジを使用します。

• データベースの内容

  OracleデータベースにはOracle Data Guard(サード・パーティのデータベースにはベンダー推奨のソリューション)を使用します。

図1-1に、Oracle Fusion Middleware障害時リカバリ・トポロジの概要を示します。

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

図1-1に示したソリューションの重要な側面をいくつか、次に示します。

• このソリューションにはサイトが2つあります。現在の本番サイトは稼働中かつアクティブであり、2番目のサイトはスタンバイ・サイトとして動作し、パッシブ・モードになっています。

• 各サイト上のホストには、そのサイトの共有ストレージ・システムにアクセスするためのマウント・ポイントが定義されています。

• どちらのサイトでも、Oracle Fusion Middlewareコンポーネントはサイトの共有記憶域システムにデプロイされます。そのため、ミドルウェア・コンポーネントの製品バイナリ・ファイルや構成データなど、すべてのOracleホーム・ディレクトリを本番サイトの共有ストレージ上のボリュームに作成し、共有ストレージ上のOracleホーム・ディレクトリにコンポーネントをインストールする必要があります。図1-1では、Oracle Fusion Middlewareホストの各クラスタに対して、別々のボリュームが共有ストレージに作成されています(各サイトの共有ストレージ・システムで、Web、アプリケーション、セキュリティの各ボリュームが、それぞれWebクラスタ、アプリケーション・クラスタおよびセキュリティ・クラスタ用として作成されています)。

• 本番サイトの共有ストレージにマウント・ポイントを作成する必要があります。本番サイトの共有ストレージに作成したマウント・ポイントを使用して、本番サイトのOracle Fusion MiddlewareソフトウェアをOracleホーム・ディレクトリにインストールします。本番サイトの共有ストレージ上のOracleホーム・ディレクトリに対するシンボリック・リンクを、本番サイトのホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、「ストレージの設定」を参照してください。

• スタンバイ・サイトの共有ストレージにマウント・ポイントを作成する必要があります。スタンバイ・サイトの共有ストレージ上のOracleホーム・ディレクトリに対するシンボリック・リンクを、スタンバイ・サイト・ホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、「ストレージの設定」を参照してください。マウント・ポイントおよびシンボリック・リンクは、スタンバイ・サイト・ホスト用と本番サイト・ホスト用で同一である必要があります。

• 本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージに、中間層のファイル・システムなどのデータをコピーするには、レプリケーション・テクノロジ(ストレージ・レベルのレプリケーション、rsync、DBFS)を使用します。

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

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

• 指定した間隔で増分レプリケーションが行われるようにスケジュールを作成します。中間層の構成を頻繁に変更しない本番デプロイメントには、この間隔として1日に1回をお薦めします。また、本番サイトで中間層の構成を変更するたびに、手動による同期化を実施する必要があります。たとえば、本番サイトに新しいアプリケーションをデプロイした場合などです。一部のOracle Fusion Middlewareコンポーネントでは、ファイル・システム上にデータが生成されるため、リカバリ・ポイントの目標に応じて、より頻繁なレプリケーションが必要になる場合があります。Oracle Fusion Middlewareコンポーネントの障害時リカバリに関する推奨事項の詳細は、「Oracle Fusion Middlewareコンポーネントに関する推奨事項」を参照してください。

• 手動による同期化を実施する前に、バックアップを取得して、現時点の状態を取得しておく必要があります。たとえば、ストレージ・レベルのレプリケーションを使用する場合は、サイトのスナップショットを取得する必要があります。これにより、スナップショットがスタンバイ・サイトの記憶域にレプリケートされるようになります。また必要に応じて、このスナップショットを使用して、スタンバイ・サイトを前の同期状態にロールバックすることもできます。レプリケーションに失敗した場合は、レプリケーションが前回成功した(スナップショットが作成された)ポイントにリカバリできます。

• Oracle Fusion Middlewareリポジトリやカスタム・アプリケーション・データベースなど、すべてのOracle Databaseリポジトリをレプリケートするには、Oracle Data Guardを使用します。Oracle Data Guardを使用してOracle Databaseで障害保護を実現する方法の詳細は、「データベースに関する考慮事項」を参照してください。

• Oracle Fusion Middleware障害時リカバリ・トポロジにサード・パーティのデータベースが含まれる場合、それらのデータベースにはベンダーが推奨するソリューションを使用してください。

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

• 本番サイトに障害または計画外の停止が発生した場合には、次のステップを実行して、トポロジ内でスタンバイ・サイトが本番のロールを引き継げるようにします。

  1. 本番サイトからスタンバイ・サイトへのレプリケーションを停止します(障害発生時には、その障害によりレプリケーションがすでに停止している可能性があります)。

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

  3. スタンバイ・サイトでサービスとアプリケーションを起動します。

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

このドキュメントに記述されているコンポーネント

Oracle Fusion Middleware障害時リカバリがサポートしているOracle製品スイートについて学習します。

Oracle Fusion Middleware障害時リカバリでは、次のような様々なOracleスイートのコンポーネントをサポートしています。

• Oracle WebLogic Server

  Oracle WebLogic Serverのコンポーネント向けの障害時リカバリに関する推奨事項については、「Oracle WebLogic Serverに関する推奨事項」を参照してください。

• Oracle SOA Suiteのコンポーネント:

  • Oracle SOAサービス・インフラストラクチャ

  • Oracle Service Bus

  • Oracle Managed File Transfer。

  • Oracle BPEL Process Manager

  • Oracle Mediator

  • Oracle Human Workflow

  • Oracle B2B

  • Oracle Web Services Manager。

  • Oracle User Messaging Service。

  • Oracle JCAアダプタ

  • Oracle Business Activity Monitoring

  • Oracle Business Process Management

  Oracle SOA Suiteのコンポーネント向けの障害時リカバリに関する推奨事項については、「Oracle SOA Suiteに関する推奨事項」を参照してください。