この章では、Oracle Fusion Middleware障害時リカバリについて紹介します。
次のトピックが含まれます:
この項では、Oracle Fusion Middlewareの障害時リカバリの概要について説明します。
次のトピックが含まれます:
いかなるOracle Fusion Middlewareエンタープライズ・デプロイメントにおいても、最大可用性アーキテクチャの実現が重要な要件の一つとなります。Oracle Fusion Middlewareには、広範囲にわたる高可用性機能が組み込まれています。この高可用性機能には、プロセス停止の検出と再起動、サーバー・クラスタリング、サーバー移行、クラスタウェアの統合、GridLink、ロード・バランシング、フェイルオーバー、バックアップとリカバリ、ローリング・アップグレード、ローリング構成変更などが含まれており、計画外の停止からエンタープライズ・デプロイメントのを保護し、計画済の停止についても最小限に抑えます。
また、エンタープライズ・デプロイメントは、予測不可能な障害や天災から保護する必要があります。保護するためのソリューションとして、本番サイトとは別の場所にスタンバイ・サイトを設定する方法があります。スタンバイ・サイトは本番サイトと比較して、サービスやリソースの数が同じか下回る場合があります。アプリケーション・データ、メタデータ、構成データおよびセキュリティ・データが、定期的にスタンバイ・サイトにレプリケートされます。通常の場合、スタンバイ・サイトはパッシブ・モードであり、本番サイトが使用できないときに起動されます。このデプロイメント・モデルは、アクティブ/パッシブ・モデルと呼ばれることがあります。通常、このモデルは、2つのサイトがWAN経由で接続されていて、ネットワーク待機時間の関係で2つのサイトにまたがるクラスタリングができない場合に採用されます。
ホット・プラグ可能性は、Oracle Fusion Middlewareの中核となる戦略の一つであり、重要な機能の一つでもあります。異機種が混在する企業向けに構築されたOracle Fusion Middlewareは、モジュール形式のコンポーネント・ソフトウェアで構成されており、それらのソフトウェアは、一般的な各種プラットフォーム上で稼働し、IBM、Microsoft、SAPなど、他のソフトウェア・ベンダーのミドルウェア・テクノロジやビジネス・アプリケーションと相互運用されます。たとえば、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データベースの障害保護は、Oracle Data Guardによって実現されます。
このドキュメントでは、エンタープライズ・デプロイメント向けにOracle Fusion Middleware障害時リカバリ・ソリューションをLinuxとUNIXのオペレーティング・システムにデプロイして、ストレージ・レプリケーション・テクノロジとOracle Data Guardテクノロジを利用する方法について説明します。
非対称型トポロジ: Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。たとえば、スタンバイ・サイトのほうが本番サイトより、ホストやインスタンスの数が少ないというようなケースが考えられます。非対称トポロジの作成方法については、第4.4項「非対称スタンバイ・サイトの作成」に記述されています。
障害: 容認しがたい損傷や損失を引き起こす、突発的で計画外の惨事のこと。この障害というイベントが発生すると、許容しがたいほどの期間にわたって、重大な機能、プロセスまたはサービスを提供する機会が損なわれるので、組織はそのリカバリ計画を実行します。
障害時リカバリ: 本番サイトにおいて、天災による停止や計画外の停止を予防する機能。別の場所に設置したスタンバイ・サイトにアプリケーションやデータをレプリケートするためのリカバリ戦略を使用します。
ホスト名別名: このガイドでは、「ホスト名別名」という用語と「物理ホスト名」という用語を区別しています。
ホスト名別名とは、実際のネットワーク名を指定する以外に、システムにアクセスするための代替手段です。通常は、システムのネットワーク名と同じIPアドレスに変換されます。これは、DNSのような名前解決システムで定義することも、各システムのローカル・ホスト・ファイルでローカルに定義することもできます。1つのシステムに対して複数のホスト名別名を定義できます。
この項で後述する「物理ホスト名」の定義も参照してください。
物理ホスト名: 物理ホスト名とは、gethostname()
コールまたはhostname
コマンドで返されるシステムのホスト名です。通常の場合、物理ホスト名は、クライアントがシステムにアクセスするために使用するネットワーク名でもあります。この場合、DNS(または使用中の任意の名前解決メカニズム)でこの名前にIPアドレスが関連付けられます。関連付けられたIPは、システムへのネットワーク・インタフェースのいずれか1つで有効化できます。
1つのシステムには通常、物理ホスト名が1つ設定されています。また、ネットワーク・インタフェースで有効化されているIPアドレスに対応して、クライアントがネットワークを介してアクセスするために使用するネットワーク名を、追加で1つ以上設定することもできます。さらに、各ネットワーク名は、1つ以上のホスト名別名に置き換えることもできます。
この項で前述した「ホスト名別名」の定義も参照してください。
本番サイトの設定: 本番サイトを作成するプロセス。このマニュアルに記述した手順を使用して本番サイトを作成するには、物理ホスト名およびホスト名別名を計画して作成し、共有ストレージ上でOracle Fusion Middlewareインスタンスのインストール先とするOracleホーム・ディレクトリに対するマウント・ポイントおよびシンボリック・リンク(該当する場合)をホスト上に作成し、バイナリとインスタンスをインストールして、アプリケーションをデプロイする必要があります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
サイトのフェイルオーバー: (本番サイトに障害が発生したことなどが原因で)本番サイトが突然使用できなくなった後で、現在のスタンバイ・サイトを新しい本番サイトにするプロセス。このドキュメントでは、サイトのフェイルオーバーを指す用語として「フェイルオーバー」も使用します。
サイトのスイッチバック: 現在の本番サイトおよび現在のスタンバイ・サイトのロールを元に戻すプロセス。スイッチバックは、スイッチオーバー処理の完了後に行う計画済の操作です。スイッチバックを行うと、各サイトの元のロールがリストアされます。具体的には、現在のスタンバイ・サイトが本番サイトになり、現在の本番サイトがスタンバイ・サイトになります。このドキュメントでは、サイトのスイッチバックを指す用語として「スイッチバック」も使用します。
サイトのスイッチオーバー: 本番サイトとスタンバイ・サイトのロールを逆にするプロセス。スイッチオーバーは、定期的な検証のために行う、または現在の本番サイトで計画メンテナンスを実行するための計画済の操作です。スイッチオーバー中に、現在のスタンバイ・サイトが新しい本番サイトになり、現在の本番サイトが新しいスタンバイ・サイトになります。このドキュメントでは、サイトのスイッチオーバーを指す用語として「スイッチオーバー」も使用します。
サイトの同期化: 本番サイトで行った変更をスタンバイ・サイトに適用するプロセス。たとえば、本番サイトで新しいアプリケーションがデプロイされたら、同期化を実行して、同じアプリケーションがスタンバイ・サイトでもデプロイされるようにする必要があります。
スタンバイ・サイトの設定: スタンバイ・サイトを作成するプロセス。このマニュアルに記述した手順を使用して本番サイトを作成するには、物理ホスト名およびホスト名別名を計画して作成し、スタンバイ共有ストレージ上のOracleホーム・ディレクトリに対するマウント・ポイントおよびシンボリック・リンク(該当する場合)を作成する必要があります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
対称トポロジ: 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データベースには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 Fusion Middlewareホーム・ディレクトリに対するシンボリック・リンクを、本番サイトのホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリューム間で、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
スタンバイ・サイトの共有ストレージにマウント・ポイントを作成する必要があります。スタンバイ・サイトの共有ストレージ上のOracle Fusion Middlewareホーム・ディレクトリに対するシンボリック・リンクを、スタンバイ・サイト・ホストに設定する必要もあります。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。マウント・ポイントおよびシンボリック・リンクは、スタンバイ・サイト・ホスト用と本番サイト・ホスト用で同一である必要があります。
本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージに、中間層のファイル・システムなどのデータをコピーするには、ストレージ・レプリケーション・テクノロジを使用します。
ストレージ・レプリケーションが有効化されると、アプリケーションのデプロイメント、構成、メタデータ、データおよび製品バイナリ情報が、本番サイトからスタンバイ・サイトにレプリケートされます。
スタンバイ・サイト・ホストでは、Oracleソフトウェアのインストールを実行する必要はいっさいありません。製品サイトの記憶域がスタンバイ・サイトの記憶域にレプリケートされると、同等のOracleホーム・ディレクトリおよびデータが、スタンバイ・サイトの記憶域に書き込まれます。
指定した間隔で増分レプリケーションが行われるようにスケジュールを作成します。中間層の構成を頻繁に変更しない本番デプロイメントには、この間隔として1日に1回をお薦めします。また、本番サイトで中間層の構成を変更するたびに(本番サイトに新しいアプリケーションをデプロイした場合など)、手動による同期化を実施する必要があります。一部のOracle Fusion Middlewareコンポーネントでは、ファイル・システム上にデータが生成されるため、リカバリ・ポイントの目標に応じて、より頻繁なレプリケーションが必要になる場合があります。Oracle Fusion Middlewareコンポーネントの障害時リカバリに関する推奨事項の詳細は、第2章「Fusion Middlewareコンポーネントに関する推奨事項」を参照してください。
手動による同期化を実施する前に、サイトのスナップショットを取得して、現時点の状態を取得しておく必要があります。これにより、スナップショットがスタンバイ・サイトの記憶域にレプリケートされるようになります。また必要に応じて、このスナップショットを使用して、スタンバイ・サイトを前の同期状態にロールバックすることもできます。レプリケーションに失敗した場合は、レプリケーションが前回成功した(スナップショットが作成された)ポイントにリカバリできます。
Oracle Fusion Middlewareリポジトリやカスタム・アプリケーション・データベースなど、すべてのOracleデータベース・リポジトリをレプリケートするには、Oracle Data Guardを使用します。Oracle Data Guardを使用してOracleデータベースで障害保護を実現する方法の詳細は、第3.3項「データベースに関する考慮事項」を参照してください。
Oracle Fusion Middleware障害時リカバリ・トポロジにサード・パーティのデータベースが含まれる場合、それらのデータベースにはベンダーが推奨するソリューションを使用してください。
ユーザー・リクエストは最初に、本番サイトにルーティングされます。
本番サイトに障害または計画外の停止が発生した場合には、次の手順を実行して、トポロジ内でスタンバイ・サイトが本番のロールを引き継げるようにします。
本番サイトからスタンバイ・サイトへのレプリケーションを停止します(障害発生時には、その障害によりレプリケーションがすでに停止している可能性があります)。
Oracle Data Guardを使用して、Oracleデータベースのフェイルオーバーまたはスイッチオーバーを実行します。
スタンバイ・サイトでサービスとアプリケーションを起動します。
グローバルなロード・バランサを使用して、ユーザー・リクエストをスタンバイ・サイトに再ルーティングします。この時点では、スタンバイ・サイトが本番のロールを引き継いでいます。
Oracle Fusion Middleware障害時リカバリ・ソリューションがサポートしている各種Oracle製品群のコンポーネントには、次のようなものがあります。
Oracle WebLogic Serverのコンポーネント:
Oracle WebLogic Serverのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.1項「Oracle WebLogic Serverに関する推奨事項」を参照してください。
Oracle ADF
Oracle Application Development Framework(Oracle ADF)向けの障害時リカバリに関する推奨事項については、第2.2項「Oracle ADFに関する推奨事項」を参照してください。
Oracle WebCenterのコンポーネント:
Oracle WebCenter Spaces
Oracle WebCenter Portlets
Oracle WebCenter Discussions Server
Oracle WebCenter Wiki and Blog Server
Oracle WebCenterのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.3項「Oracle WebCenterに関する推奨事項」を参照してください。
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 SOA Suiteに関する推奨事項」を参照してください。
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 Authorization Policy Manager
Oracle Identity Navigator
Oracle Identity Managementのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.5項「Oracle Identity Managementに関する推奨事項」を参照してください。
Oracle Portal、Forms、ReportsおよびBusiness Intelligence Discovererのコンポーネント:
Oracle Portal
Oracle Forms
Oracle Reports
Oracle Business Intelligence Discoverer (Discoverer)
これらのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.6項「Oracle Portal、Forms、ReportsおよびDiscovererに関する推奨事項」を参照してください。
Oracle Web Tierのコンポーネント:
Oracle HTTP Server
Oracle Web Cache
Oracle Web Tierのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.7項「Oracle Web Tierコンポーネントに関する推奨事項」を参照してください。
Oracle Enterprise Content Management:
Oracle Universal Content Management
Oracle Inbound Refinery
Oracle Imaging and Process Management
Oracle Information Rights Management
Oracle Universal Records Management
Oracle Enterprise Content Managementのコンポーネント向けの障害時リカバリに関する推奨事項については、第2.8項「Oracle Enterprise Content Managementに関する推奨事項」を参照してください。