1
高可用性の概要

このリリースのOracle Application Serverでは、前のリリースで使用可能であった高可用性ソリューションが拡張および強化されています。Oracle Application Serverのフレキシブルで自動化された新しい高可用性ソリューションのテストが実施されました。これらのソリューションについては、このマニュアルで説明されています。これらのソリューションはすべて、Oracle Application Serverに配置するアプリケーションがビジネス目標の達成に必要な可用性を実現することを目的としています。このマニュアルで説明するソリューションと手順の目的は、Oracle Application Serverコンポーネントのシングル・ポイント障害をなくし、サービスをいっさい停止しないか最小限の停止にとどめることにあります。

この章では、高可用性とその重要性についてOracle Application Serverの観点から説明します。

1.1 高可用性とは

この項では、問題解決の観点から高可用性の概要を示します。この項の内容は次のとおりです。

• 第1.1.1項「高可用性の問題」

• 第1.1.2項「高可用性ソリューション」

1.1.1 高可用性の問題

ミッション・クリティカルなコンピュータ・システムは、24時間365日利用可能である必要があります。しかし、計画停止または計画外停止では、システムの一部またはすべてを停止することがあります。システムの可用性は、システム導入後の合計時間のうちのサービス提供時間の割合で測定されます。表1-1に、例を示します。

表1-1    可用性の割合と対応する停止時間の値 

可用性の割合	年間停止時間の概算
95%	18日
99%	4日
99.9%	9時間
99.99%	1時間
99.999%	5分

表1-2に、コンピュータ・システムで想定される様々な障害のタイプを示します。

表1-2    システムの停止および障害のタイプ 

停止のタイプ	障害のタイプ
計画外停止	システム障害
	データ障害
	災害
	人為ミス
計画停止	システム・メンテナンス1
	データ・メンテナンス

1 ハードウェアおよびソフトウェアの変更（オペレーティング・システム、アプリケーション・サーバー、構成、アプリケーションの変更）を含みます。

停止のこれら2つのタイプ（計画停止と計画外停止）は通常、システムの可用性要件の設計時には別々に扱われます。システムの要件は、計画外停止に関しては非常に制限的な場合がありますが、計画停止に関しては非常にフレキシブルな場合があります。これは、営業時間には負荷がピークに達するが、夜間と週末にはほとんど非アクティブなままであるアプリケーションの場合に当てはまります。

1.1.2 高可用性ソリューション

高可用性ソリューションは、1つのデータ・センター配置における高可用性を実現するローカル高可用性ソリューションと、通常は地理的に分散配置されていて、洪水や地域的なネットワークの停止などの災害からアプリケーションを保護する、障害時リカバリ・ソリューションに分類できます。

想定される障害タイプのうち、プロセス障害、ノード障害、メディア障害および人為ミスは、ローカル高可用性ソリューションで保護できます。ローカルの物理的な障害については、地理的に分散された障害時リカバリ・ソリューションで保護できます。

高可用性の問題を解決するには、いくつかのテクノロジとベスト・プラクティスが必要になります。その中で最も重要なメカニズムは冗長性です。高可用性は、システムとコンポーネントに冗長性を持たせることによって実現されます。ローカル高可用性ソリューションは、冗長性のレベルによってアクティブ/アクティブ・ソリューションやアクティブ/パッシブ・ソリューションに分類されます（図1-1を参照）。アクティブ/アクティブ・ソリューションでは、複数のアクティブなシステム・インスタンスが配置されます。これにより、スケーラビリティが向上し、高可用性が実現されます。すべてのインスタンスは、同時にリクエストを処理します。

アクティブ/パッシブ・ソリューションでは、リクエストを処理するアクティブ・インスタンスと、スタンバイ状態のパッシブ・インスタンスを配置します。さらに、この2つのインスタンスの間にハートビート・メカニズムが設定されます。このメカニズムは、オペレーティング・システムのベンダー固有のクラスタウェアで提供および管理されます。通常、ベンダー固有のクラスタ・エージェントでは、クラスタ・ノード間の監視とフェイルオーバーを自動的に行うことも可能なため、アクティブ・インスタンスに障害が発生した場合には、エージェントがそのアクティブ・インスタンスを完全に停止して、パッシブ・インスタンスをアクティブ化します。アプリケーション・サービスは、処理を再開できます。その結果、アクティブ/パッシブの役割が切り替わります。計画停止または計画外停止の場合は、この同じ手順を手動で行えます。アクティブ/パッシブ・ソリューションは一般に、コールド・フェイルオーバー・クラスタとも呼ばれます。

図1-1    アクティブ/アクティブおよびアクティブ/パッシブの高可用性ソリューション

画像の説明

包括的な高可用性システムでは、アーキテクチャの冗長性に加えて、次のローカル高可用性テクノロジも必要です。

• プロセス障害の検出と自動再起動

  構成やソフトウェアに障害が発生したため、予期しないときにプロセスが停止する場合があります。プロセスの監視と再起動が適切に行われるシステムでは、すべてのシステム・プロセスが常時監視され、障害がある場合にそれらが再起動されます。

  システム・プロセスは、特定の時間間隔における再起動の回数も記録している必要があります。短期間に何度も再起動を行うと他の障害を引き起こすことがあるため、これも重要な機能です。したがって、特定の時間間隔における再起動や再試行の回数の上限も指定しておく必要があります。

• クラスタリング

  システムのコンポーネントをまとめてクラスタリングすることにより、クライアント側は、ランタイム処理と管理性の観点から、これらのコンポーネントを機能的に1つのエンティティと見なすことができます。クラスタは、1つのコンピュータ、または同じワークロードを共有する複数のコンピュータ上で実行される一連のプロセスです。クラスタリングと冗長性には密接な関係があります。クラスタは、システムの冗長性を実現します。

• 構成管理

  類似したコンポーネントを1つのグループにクラスタリングすると、多くの場合、共通の構成を共有する必要があります。適切な構成管理によって、コンポーネントが同じ受信リクエストに対して同一のレスポンスを返したり、これらのコンポーネントの構成を同期化することが可能になります。また、管理目的の停止時間を短縮する可用性の高い構成管理を実現できます。

• 状態のレプリケーションとルーティング

  ステートフル・アプリケーションでは、これらのリクエストを処理しているプロセスに障害が発生した場合、リクエストのステートフル・フェイルオーバーを有効にするためにクライアント状態をレプリケートできます。

• サーバーのロード・バランシングとフェイルオーバー

  同じサーバー・コンポーネントの複数のインスタンスを使用できる場合、これらのコンポーネントに対するクライアント・リクエストは、各インスタンスのワークロードがほぼ同一になるようにロード・バランシングされます。ロード・バランシング・メカニズムが利用されると、インスタンスは冗長になります。いずれかのインスタンスに障害が発生した場合、そのインスタンスに対するリクエストを、障害の発生していないインスタンスに送信できます。

• バックアップとリカバリ

  ユーザー・エラーによってシステムが誤作動することがあります。特定の状況下では、コンポーネントまたはシステムの障害が修復不可能なこともあります。そのため、バックアップとリカバリの機能を使用してシステムを一定の間隔でバックアップし、修復不可能な障害が発生したときにバックアップをリストアできるようにする必要があります。

障害時リカバリ・ソリューションでは通常、2つの同種のサイト（1つはアクティブ・サイト、もう1つはパッシブ・サイト）を設定します。サイトはそれぞれが自己完結型のシステムです。一般的に、アクティブ・サイトを本番サイト、パッシブ・サイトをスタンバイ・サイトと呼びます。通常の運用では、本番サイトがリクエストを処理しますが、サイトでフェイルオーバーやスイッチオーバーが発生すると、スタンバイ・サイトが本番サイトを引き継ぎ、すべてのリクエストはそのサイトにルーティングされます。フェイルオーバーのためにスタンバイ・サイトを保持するには、スタンバイ・サイトに同種のインストールとアプリケーションを含めるだけでなく、データと構成を本番サイトからスタンバイ・サイトに常時同期化する必要もあります。

図1-2    地理的に分散された障害時リカバリ

画像の説明

1.2 Oracle Application Serverの高可用性の概要

Oracle Application Serverの高可用性の概要については、次の各項で説明します。

• 第1.2.1項「用語」

• 第1.2.2項「Oracle Application Serverの基本アーキテクチャ」

• 第1.2.3項「Oracle Application Serverの高可用性アーキテクチャ」

• 第1.2.4項「最適な高可用性アーキテクチャの選択」

1.2.1 用語

次に示す用語の定義は、このマニュアルで説明されている概念の理解に役立ちます。

• アクティブ/アクティブ: 高可用性システムでは、そのシステムの同等のメンバーがリクエストを同時に処理しています。どのメンバーにも障害が発生していない通常の運用では、同等のメンバーはすべてアクティブで、スタンバイ状態にあるメンバーはありません。これをアクティブ/アクティブ・システムと呼びます。

• アクティブ/パッシブ: 高可用性システムでは、システムの一部のメンバーが積極的にリクエストを処理しており（機能している）、他のメンバーは非アクティブになっています。これら非アクティブなメンバーは、パッシブな状態にあるといえます。これらは1つ以上のアクティブ・ノードに障害が発生するまでアクティブ化されません。システム・サービスのコンシューマは、この障害を意識しないこともあります。通常、アクティブ/アクティブ・システムのほうが、アクティブ/パッシブ・システムよりもコンシューマにとって透過的で、スケーラビリティに優れたオプションを提供します。

• フェイルオーバー: 高可用性システムのメンバーに予期しない障害（計画外停止）が発生した場合、コンシューマへのサービス提供を継続するために、フェイルオーバー操作が実行されます。アクティブ/パッシブ・システムの場合、フェイルオーバー操作によってパッシブ・メンバーがアクティブになり、コンシューマは障害が発生したメンバーからそのメンバーにリダイレクトされます。フェイルオーバー操作は、手動で実行できます。また、ハードウェア・クラスタ・サービスを設定して自動化できます。これにより、障害を検出したり、クラスタ・リソースを障害が発生したノードからスタンバイ・ノードへ移行させることが可能になります。アクティブ/アクティブ・システムの場合、フェイルオーバーはロード・バランサのエンティティが、アクティブ・メンバーにリクエストを配信することにより実現されます。アクティブ・メンバーに障害が発生した場合には、ロード・バランサが障害を検出し、障害が発生したメンバーへのリクエストを残りのアクティブ・メンバーに自動的にリダイレクトします。

• フェイルバック: システムがフェイルオーバー操作に成功した後、障害が発生した元のメンバーが修復されて、スタンバイ・メンバーとしてシステムに再導入されます。フェイルバック・プロセスを開始してこのメンバーをアクティブにしてから、他のメンバーを非アクティブにすることもできます。このプロセスによって、システムが障害発生前の構成に戻されます。

• ハードウェア・クラスタ: ハードウェア・クラスタとはコンピュータの集まりであり、ネットワーク・サービス（例: IPアドレス）またはアプリケーション・サービス（例: データベース、Webサーバー）のシングル・ビューをこれらのサービスのクライアントに提供します。ハードウェア・クラスタ内の各ノードは、それぞれのプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは相互に通信して、アプリケーション、システム・リソースおよびデータを協調してユーザーに提供する単一のシステムのように機能します。

  ハードウェア・クラスタは、専用のハードウェア（クラスタ・インターコネクト、共有記憶域）とソフトウェア（ヘルス・モニター、リソース・モニター）を使用して、高可用性とスケーラビリティを実現します（クラスタ・インターコネクトは、ハートビート情報がノードの停止を検出する際にハードウェア・クラスタで使用されるプライベート・リンクです）。専用のハードウェアとソフトウェアが必要であるため、通常、ハードウェア・クラスタはSun社、HP社、IBM社、Dell社などのハードウェア・ベンダーによって提供されます。1つのハードウェア・クラスタ内で構成可能なノード数は、ベンダーによって異なりますが、Oracle Application Serverの高可用性では2つのノードのみを必要とします。そのため、このドキュメントでは、2つのノードを持つハードウェア・クラスタを高可用性ソリューションで使用することを前提とします。

• クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアで、可用性とパフォーマンスの操作を他のノードと協調させます。クラスタウェアは、リソースのグループ化やモニタリング、およびサービスを移行させる機能を提供します。クラスタ・エージェントによって、サービスのフェイルオーバーを自動化できます。

• クラスタウェア: クラスタ・メンバーの処理を、1つのシステムとして管理するソフトウェアです。これにより、クラスタ・メンバー間のハートビート・メカニズムを通じて、監視対象のリソースとサービスのセットを定義したり、これらのリソースとサービスをクラスタ内の別のメンバーにできるだけ効率的かつ透過的な方法で移動することができます。

• 共有記憶域: 各ハードウェア・クラスタ・ノードが、各自のプロセス・セットを実行するスタンドアロン・サーバーの場合でも、通常、クラスタ対応のために必要とされる記憶域サブシステムは共有されます。共有記憶域とは、両方のノードから同じ記憶域（通常はディスク）にアクセスできるクラスタの機能のことです。両ノードはこの記憶域に対して等しくアクセスできますが、一方のノード（1次ノード）が記憶域に対して常に頻繁にアクセスします。1次ノードで障害が発生すると、ハードウェア・クラスタのソフトウェアは、2次ノードがこの記憶域にアクセスすることを許可します。OracleAS Cold Failover Cluster環境のOracleAS Infrastructureでは、そのORACLE_HOMEはこのような共有記憶域のファイル・システムに配置されます。このファイル・システムは、1次ノードによってマウントされます。1次ノードで障害が発生した場合は、2次ノードがファイル・システムを引き継いでマウントします。場合によっては、1次ノードが共有記憶域の制御を放棄することもあります。たとえば、ハードウェア・クラスタのソフトウェアが1次ノードによるInfrastructureの使用は不可能と判断し、2次ノードへの移行を決定した場合などです。

• 1次ノード: 常に、1つ以上のInfrastructureインストールを頻繁に実行しているノードです。このノードで障害が発生すると、Infrastructureは2次ノードにフェイルオーバーされます。1次ノードではアクティブなInfrastructureインストールが実行されるため、1次ノードはホット・ノードと見なされます。この項の2次ノードの定義を参照してください。

• 2次ノード: 1次ノードで障害が発生した場合に、Infrastructureの実行を引き継ぐノードです。それまで2次ノードではInfrastructureが実行されていないため、2次ノードはコールド・ノードと見なされます。アプリケーションがホット・ノード（1次）からコールド・ノード（2次）へフェイルオーバーされるため、このタイプのフェイルオーバーはコールド・フェイルオーバーと呼ばれます。この項の1次ノードの定義を参照してください。

• ネットワーク・ホスト名: ネットワーク・ホスト名は、/etc/hostsファイル（UNIXの場合）、C:¥WINDOWS¥system32¥drivers¥etc¥hostsファイル（Windowsの場合）またはDNS解決のいずれかで指定される、IPアドレスに割り当てられる名前です。この名前は、マシンが接続しているネットワークで参照可能です。多くの場合、ネットワーク・ホスト名と物理ホスト名は同じものを指します。しかし、各マシンが持つ物理ホスト名は1つのみですが、ネットワーク・ホスト名は複数持つことができます。したがって、マシンのネットワーク・ホスト名が常に物理ホスト名になるわけではありません。

• 物理ホスト名: このマニュアルでは、物理ホスト名とネットワーク・ホスト名の用語が区別されます。このマニュアルでは、物理ホスト名は、現行マシンの内部名を表すために使用されます。UNIXでは、hostnameコマンドにより返される名前です。

  物理ホスト名は、Oracle Application Server中間層インストール・タイプにより、ローカル・ホストを参照する名前として使用されます。物理ホスト名はインストール時に、インストーラにより現行マシンから取得され、ディスク上のOracle Application Server構成メタデータに格納されます。

• スイッチオーバー: 通常の運用時に、システムのアクティブ・メンバーのメンテナンスまたはアップグレードが必要になることがあります。スイッチオーバー・プロセスを開始すると、メンテナンスまたはアップグレードが必要な計画停止中のメンバーによって処理されているワークロードを、他のメンバーに引き継がせることができます。スイッチオーバー操作によって、システムのコンシューマにサービスを継続して提供できます。

• スイッチバック: スイッチオーバー操作が実行されると、メンテナンスまたはアップグレードが必要なシステムのメンバーが非アクティブになります。メンテナンスまたはアップグレードが完了すると、システムがスイッチバック操作を行い、アップグレードしたメンバーをアクティブにして、スイッチオーバー前のシステム構成に戻します。

• 仮想ホスト名: 仮想ホスト名はネットワーク・アドレスで参照可能なホスト名で、ロード・バランサまたはハードウェア・クラスタを使用して1つ以上の物理マシンにマッピングされます。ロード・バランサの場合、仮想サーバー名は、このドキュメントの仮想ホスト名と同じ意味で使用されます。ロード・バランサは、一連のサーバーを表す仮想ホスト名を持つことができ、クライアントはこの仮想ホスト名を使用してマシンと間接的に通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタの仮想IPは、クラスタの特定のノードに永続的に割り当てられるものではないため、仮想ホスト名も特定のノードに永続的に割り当てられません。

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

• 仮想IP: クラスタの仮想IP、ロード・バランサの仮想IPとも呼ばれます。一般に、仮想IPはハードウェア・クラスタまたはロード・バランサに割り当てることができます。ネットワーク・クライアントに対してクラスタのシングル・システム・ビューを提供する際には、仮想IPがクラスタのメンバーであるサーバー・グループのエントリ・ポイントとして機能します。仮想IPは、サーバーのロード・バランサまたはハードウェア・クラスタに割り当てることができます。

  ハードウェア・クラスタは、クラスタの仮想IPを使用して、外部に対するクラスタへのエントリ・ポイントを示します（スタンドアロン・マシン上にも設定できます）。ハードウェア・クラスタのソフトウェアは、外部クライアントによるこのIPアドレスへの接続中、クラスタの2つの物理ノード間でのこのIPアドレスの移動を管理します。その際、クライアントは、このIPアドレスが現在どの物理ノードでアクティブであるかを知る必要はありません。2つのノードを持つ標準的なハードウェア・クラスタ構成の場合、各マシンは固有の物理IPアドレスと物理ホスト名を持ちますが、複数のクラスタIPアドレスを持つことができます。これらのクラスタIPアドレスは、2つのノード間で浮動または移行します。現在、クラスタIPアドレスの所有権を持っているノードが、そのアドレスのアクティブ・ノードになります。

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

1.2.2 Oracle Application Serverの基本アーキテクチャ

高可用性について最初に理解する必要があるのは、システムの基本アーキテクチャです。次に、このシステムの高可用性を実現するために、すべてのコンポーネントおよびコンポーネント間の接続を調べて、それらの可用性を向上させます。これにより、基本アーキテクチャを冗長にするだけで、高可用性アーキテクチャが実現します。

図1-3に、Oracle Application Serverの基本アーキテクチャを示します。

図1-3    Oracle Application Serverの基本アーキテクチャ

画像の説明

高レベルでは、Oracle Application ServerはOracle Application Server中間層ビジネス・アプリケーション、Oracle Identity ManagementおよびOracleAS Metadata Repositoryで構成されます。後者の2つは、OracleAS Infrastructureの一部です。

Oracle Identity Managementソフトウェアは、ユーザー認証、許可およびID情報を管理します。機能的には、次の主要コンポーネントから構成されます。

• OracleAS Single Sign-On

• Oracle Delegated Administration Services

• Oracle Internet Directory

• Oracle Directory Integration and Provisioning

アーキテクチャの観点では、Oracle Identity ManagementはOracle HTTP ServerのWebサーバー層、Oracle Application Server Containers for J2EE（OC4J）インスタンスによって構成されるセキュリティ・アプリケーションであるOracleAS Single Sign-On/Oracle Delegated Administration Servicesの中間層、およびバックエンドのOracle Internet Directory/Oracle Directory Integration and Provisioning層に分けられます。OracleAS Metadata Repositoryは、OracleAS InfrastructureとOracleAS中間層全体のコンポーネントの構成、管理および製品のメタデータを管理するOracleデータベースです。

この中間層は、次のようなOracle Application Serverビジネス・アプリケーションをホスティングします。

• Oracle Application Server Portal

• Oracle Application Server Wireless

• Oracle Application Server Integration

これらのアプリケーションはセキュリティとメタデータのサポートのために、Oracle Identity ManagementおよびOracleAS Metadata Repositoryに依存しています。また、中間層にはWebキャッシュ・サブ階層（Oracle Application Server Web Cache）、Webサーバー・サブ階層（Oracle HTTP Server）およびOC4Jインスタンスも含まれます。中間層の背後では、OracleAS Metadata Repositoryがデータ層として機能します。実際の配置では、他のデータベースもデータ層に存在する場合があります（例: 中間層に配置されるOC4Jアプリケーションのカスタマ・データベース）。

図1-4に、Oracle Application Serverビジネス・アプリケーションやOracle Application Server Infrastructureサービスに到達するまでにクライアント・リクエストが通過する様々なサブ層を示します。図1-5には、Infrastructureサービス全体の概要があります。これには、Oracle Identity Management、メタデータ・リポジトリおよびLDAPサービスが含まれます。

この基本アーキテクチャは、プロセスの自動監視と再起動、アプリケーション・サーバーのバックアップとリカバリなど、多数の可用性機能をサポートしますが、完全な高可用性を保証するわけではありません。ここには、いくつかのシングル・ポイント障害が存在します。それを解消するには、各コンポーネントに冗長性を持たせる必要があります。これは、基本アーキテクチャを高可用性アーキテクチャへと拡張することにより実現されます。

関連項目 『Oracle Application Server概要』

図1-4    Oracle Application Serverの基本アーキテクチャのサブ層

画像の説明

図1-5    Infrastructureサービスの概要

画像の説明

1.2.3 Oracle Application Serverの高可用性アーキテクチャ

Oracle Application Serverは、柔軟性の高いインストール、配置およびセキュリティ・オプションとともに、ローカル高可用性、あらゆる障害に対して最大限の保護を提供する障害時リカバリ・ソリューションを備えています。Oracle Application Serverのローカル高可用性ソリューションと障害時リカバリ・ソリューションの冗長性は、その冗長な高可用性アーキテクチャから実現されます。

高レベルでは、Oracle Application Serverのローカル高可用性アーキテクチャには、OracleAS中間層とOracleAS Infrastructureのいくつかのアクティブ/アクティブおよびアクティブ/パッシブ・アーキテクチャが含まれています。どちらのソリューションを使用しても高可用性は実現できますが、一般的にはアクティブ/アクティブ・ソリューションのほうがスケーラビリティに優れ、フェイルオーバーも迅速です。その一方で、より多くのコストがかかるというデメリットもあります。アクティブ/アクティブとアクティブ/パッシブのどちらのカテゴリでも、インストールの容易さ、コスト、スケーラビリティおよびセキュリティが異なる複数のソリューションがあります。

ローカル高可用性ソリューションの上部には、Oracle Application Server Disaster RecoveryソリューションであるOracle Application Server Guardが構築されます。このユニークなソリューションでは、Oracle Databaseの実績のあるOracle Data Guardテクノロジがアプリケーション分野の高度な障害時リカバリ・テクノロジと統合されます。これにより、アプリケーション・システム全体における包括的な障害時リカバリ・ソリューションが提供されます。このソリューションには、同種の本番サイトとスタンバイ・サイトが必要ですが、障害時リカバリ設定のインスタンスに影響しない範囲で、それぞれのサイトに他のOracle Application Serverインスタンスをインストールすることもできます。これら2つのサイトの同質性を確保するには、両サイト間で構成とデータを定期的に同期化する必要があります。

1.2.4 最適な高可用性アーキテクチャの選択

世界のすべてのシステムに通用する、ただ1つの最適な高可用性ソリューションは存在しませんが、ご使用のシステムに最適なソリューションを選択することはできます。高可用性システムを設計するうえで最も重要な決定は、ビジネスまたはアプリケーションのサービス・レベル要件に基づく最適な高可用性アーキテクチャまたは冗長性タイプの選択であるといえます。高可用性の実装にかかるコストは、そのレベルによって異なるため、ビジネスの可用性の要件を理解することは非常に重要です。

Oracle Application Serverには、様々なサービス・レベル要件に合せた数多くの高可用性ソリューションが用意されています。ご使用のアプリケーションにとって最も包括的なソリューションが最適であるとはかぎりません。最適な高可用性アーキテクチャの選択には、ビジネスのサービス・レベル要件をまず理解することが不可欠です。

次に、高可用性アーキテクチャを決定するのに役立つ高レベルの質問を示します。

1. ローカル高可用性: 本番システムは24時間365日利用する必要がありますか。

2. スケーラビリティ: 複数のアクティブなOracle Application Serverインスタンスでスケーラビリティを実現する必要がありますか。

3. サイト間の障害時リカバリ: この機能は必要ですか。

これらの質問に対する回答に基づいて、次の2つの項目で選択を行う必要があります。

1. インスタンスの冗長性: 基本、アクティブ/アクティブまたはアクティブ/パッシブ

2. サイト間の障害時リカバリ対応アーキテクチャ: YまたはN

表1-3に、ビジネス要件に基づくアーキテクチャの選択を示します。

表1-3    サービス・レベル要件とアーキテクチャの選択 

ビジネス要件			選択するアーキテクチャ
ローカル高可用性	スケーラビリティ	障害時リカバリ	インスタンスの冗長性	障害時リカバリ
N	N	N	基本	N
Y	N	N	アクティブ/パッシブ	N
N	Y	N	アクティブ/アクティブ	N
N	N	Y	基本	Y
Y	Y	N	アクティブ/アクティブ	N
Y	N	Y	アクティブ/パッシブ	Y
N	Y	Y	アクティブ/アクティブ（中間層） 基本（Infrastructure）1	Y
Y	Y	Y	アクティブ/アクティブ（中間層） アクティブ/パッシブ（Infrastructure）1	Y

1 OracleAS Disaster Recoveryは、基本およびアクティブ/パッシブのInfrastructureアーキテクチャをサポートしていますが、アクティブ/アクティブ・アーキテクチャはサポートしていません。基本またはアクティブ/パッシブのアーキテクチャのスケーラビリティを向上させるには、高性能のCPUやメモリーの追加によってInfrastructureハードウェアの処理能力を上げてください。

OracleAS中間層とOracleAS Infrastructureには、それぞれ別の高可用性アーキテクチャを選択できますが、ローカル高可用性および障害時リカバリの要件は同一である必要があります。また、スケーラビリティの要件は、OracleAS中間層とOracleAS Infrastructureでは別に評価する必要があります。後者では通常、処理するID管理リクエストが少ないため、中間層ほどのスケーラビリティは必要とされません。

このようなスケーラビリティ要件の違いのため、配置するアーキテクチャはOracleAS中間層とOracleAS Infrastructureとで異なる場合があります。たとえば、ローカル高可用性、サイト間の障害時リカバリ、スケーラブルな中間層とOracleAS Infrastructureの基本的なスケーラビリティを組み合せた配置が必要であるとします。この場合は、アクティブ/アクティブの中間層、アクティブ/パッシブのOracleAS Infrastructure、および本番サイトのすべての中間層とOracleAS Infrastructure構成をミラー化するスタンバイ障害時リカバリ・サイトを配置することになります。

1.3 他のドキュメントの高可用性に関する情報

次の表に、Oracleライブラリにある他のドキュメントの高可用性に関する情報の参照先一覧を示します。この情報は、Oracle Application Serverの各種コンポーネントの高可用性に関連するものです。

表1-4    Oracleドキュメントの高可用性に関する情報の参照先 

コンポーネント	情報の場所
高可用性の概要	『Oracle Application Server概要』の「高可用性」
Oracle Installer	Oracle Application Serverのインストレーション・ガイドの「高可用性環境へのインストール」
Oracle Application Server Backup and Recovery Tool	『Oracle Application Server管理者ガイド』のバックアップとリストアに関する部分
Oracle Application Server Web Cache	『Oracle Application Server Web Cache管理者ガイド』
Identity Managementサービスのレプリケーション	『Oracle Application Server Single Sign-On管理者ガイド』の「拡張構成」
Identity Managementの高可用性の配置	『Oracle Identity Management概要および配置プランニング・ガイド』の「Oracle Identity Managementの配置プランニング」
データベースの高可用性	『Oracle高可用性アーキテクチャおよびベスト・プラクティス』
Distributed Configuration Managementコマンド	『Distributed Configuration Management管理者ガイド』
Oracle Process Manager and Notification Serverコマンド	『Oracle Process Manager and Notification Server管理者ガイド』
OC4Jの高可用性	『Oracle Application Server Containers for J2EEサービス・ガイド』 『Oracle Application Server Containers for J2EEユーザーズ・ガイド』 『Oracle Application Server Containers for J2EE Enterprise JavaBeans開発者ガイド』
Java Object Cache	『Oracle Application Server Web Services開発者ガイド』
OC4Jプロセスのロード・バランシング	『Oracle HTTP Server管理者ガイド』
Oracle Application Server Wirelessの高可用性	『Oracle Application Server Wireless管理者ガイド』
Oracle Business Intelligence Discovererの高可用性	『Oracle Business Intelligence Discoverer構成ガイド』
OracleAS Forms Services	『Oracle Application Server Forms Services利用ガイド』
OracleAS Reports Services	『Oracle Application Server Reports ServicesレポートWeb公開ガイド』
Oracle Application Server Integration InterConnectのiniファイルに関する情報	『Oracle Application Server Integration InterConnectユーザーズ・ガイド』

これらのドキュメントとその他のドキュメントへの参照情報は、このマニュアルの本文にも適宜記載されています。