ヘッダーをスキップ
Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド
11g リリース1 (11.1.1)
B61394-05
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

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

この章では、Oracle Fusion Middleware障害時リカバリについて紹介します。

内容は次のとおりです。

1.1 障害時リカバリの概要

この項では、Oracle Fusion Middlewareの障害時リカバリの概要について説明します。

内容は次のとおりです。

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

いかなる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 Manager、Rules、Oracle TopLink、Oracle Business Intelligence Publisherなど)は、Oracle WebLogic Serverコンテナで稼働することに加えて、IBM WebsphereやJBossなど、Oracle以外のコンテナでも稼働できます。

Oracle Fusion Middleware障害時リカバリ・ソリューションは、Oracle Fusion Middlewareの中間層コンポーネントの障害保護にストレージ・レプリケーション・テクノロジを使用しています。このソリューションでは、ホット・プラグ可能なデプロイメントがサポートされており、サード・パーティ・ベンダーの推奨するソリューションと互換性があります。

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

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

1.1.2 用語

この項では、障害時リカバリに関して次の用語を定義します。

  • 非対称トポロジ

    Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。たとえば、スタンバイ・サイトのほうが本番サイトより、ホストやインスタンスの数が少ないというようなケースが考えられます。第4.4項では、非対称トポロジの作成方法を説明します。

  • 障害

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

  • 障害時リカバリ

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

  • ホスト名別名

    このガイドでは、「ホスト名別名」という用語と「物理ホスト名」という用語を区別しています。

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

    この項で後述する「物理ホスト名」の定義も参照してください。

  • 物理ホスト名

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

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

    この項で前述した「ホスト名別名」の定義も参照してください。

  • 仮想ホスト名

    仮想ホスト名はネットワーク・アドレスを指定可能なホスト名で、ロード・バランサまたはハードウェア・クラスタを通じて、1つ以上の物理マシンにマップされます。ロード・バランサの場合、このマニュアルでは仮想サーバー名の名前は仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。


    注意:

    このドキュメントで「仮想ホスト名」という用語を使用する場合、それが仮想IPアドレスに関連付けられることを前提とします。IPアドレスが必要とされたり使用される場合、明示的に言及します。


  • 仮想IP

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

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

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

  • 本番サイトの設定

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

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

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

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

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

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

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

  • サイトの同期

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

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

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

  • 対称トポロジ

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

  • トポロジ

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

  • ターゲット

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

  • システム

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

  • サイト

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

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

この項では、Oracle Fusion Middlewareの一般的なエンタープライズ・デプロイメント向けに、障害時リカバリ・ソリューションを設定する作業について紹介します。

内容は次のとおりです。

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

この項では、Oracle Fusion Middlewareコンポーネントのデプロイメント・アーキテクチャについて説明します。

Oracle Fusion Middlewareコンポーネントおよびアプリケーションの製品バイナリ・ファイルと構成は、中間層のOracleホーム・ディレクトリにデプロイされます。また、製品のほとんどで、メタデータとランタイム・データもデータベース・リポジトリに格納されます。

そのため、Oracle Fusion Middleware障害時リカバリ・ソリューションによって、データベースに格納されている中間層ファイル・システム・データは、本番サイトとスタンバイ・サイトで同期がとられています。

Oracle Fusion Middleware障害時リカバリ・ソリューションでは、Oracle Fusion Middlewareのデータおよびデータベースの内容にデータ保護を実現するために、次の方法がサポートされています。

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

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

  • データベースの内容

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

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

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

図1-1の説明が続きます
「図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 Fusion Middlewareホーム・ディレクトリに対するシンボリック・リンクを、本番サイトのホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、 第3.2.3項を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oracle Fusion Middleware障害時リカバリ・ソリューションがサポートしている各種Oracle製品群のコンポーネントには、次のようなものがあります。

  • Oracle WebLogic Server

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

  • Oracle ADF

    Oracle Application Development Framework(Oracle ADF)向けの障害時リカバリに関する推奨事項については、第2.2項を参照してください。

  • Oracle WebCenter Portalのコンポーネント:

    • Oracle WebCenter Portal: Spaces

    • Oracle WebCenter PortalのPortlet Producers

    • Oracle WebCenter PortalのDiscussion Server

    • Oracle WebCenter Contentサーバー

    • Oracle WebCenter Portal Pagelet Producer

    • Oracle WebCenter Portal Activity Graph Engines

    • Oracle WebCenter PortalのPersonalization

    • Oracle WebCenter Portalの分析

    • Oracle WebCenter Portal Services Producer

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

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

    • Oracle SOA Service Infrastructure

    • Oracle BPEL Process Manager

    • Oracle Mediator

    • Oracle Human Workflow

    • Oracle B2B

    • Oracle Web Services Manager

    • Oracle User Messaging Service

    • Oracle JCA Adapters

    • Oracle Business Activity Monitoring

    • Oracle Business Process Management

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

  • Oracle Identity Managementのコンポーネント:

    • Oracle Internet Directory

    • Oracle Virtual Directory

    • Oracle Directory Integration Platform

    • Oracle Identity Federation

    • Oracle Directory Services Manager

    • Oracle Access Manager

    • Oracle Adaptive Access Manager

    • Oracle Identity Manager

    • Oracle Identity Navigator

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

  • Oracle Portal、Forms、ReportsおよびBusiness Intelligence Discovererのコンポーネント:

    • Oracle Portal

    • Oracle Forms

    • Oracle Reports

    • Oracle Business Intelligence Discoverer(Discoverer)

    これらのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.6項を参照してください。

  • Oracle Web Tierのコンポーネント:

    • Oracle HTTP Server

    • Oracle Web Cache

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

  • Oracle WebCenter Content:

    • Oracle WebCenter Content

    • Oracle WebCenter Content: Inbound Refinery

    • Oracle WebCenter Content: Imaging

    • Oracle WebCenter Content: Information Rights

    • Oracle WebCenter Content: Records

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

  • Oracle Business Intelligence:

    • Oracle Business Intelligence Enterprise Edition(Oracle BI EE)

    • Oracle Business Intelligence Publisher

    • Oracle Real-Time Decisions

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