10gリリース3（10.1.3.1.0）
B31835-01
 目次 |
 索引 |
| Oracle Application Server 高可用性ガイド 10gリリース3（10.1.3.1.0） B31835-01 |
|
このリリースのOracle Application Serverでは、前のリリースで使用可能であった高可用性ソリューションが拡張および強化されています。Oracle Application Serverのフレキシブルで自動化された新しい高可用性ソリューションのテストが実施されました。これらのソリューションについては、このマニュアルで説明されています。これらのソリューションはすべて、Oracle Application Serverに配置するアプリケーションがビジネス目標の達成に必要な可用性を実現することを目的としています。このマニュアルで説明するソリューションと手順の目的は、Oracle Application Serverコンポーネントのシングル・ポイント障害をなくし、サービスをいっさい停止しないか最小限の停止にとどめることにあります。
この章では、高可用性とその重要性についてOracle Application Serverの観点から説明します。この章に含まれている項は次のとおりです。
この項では、問題解決の観点から高可用性の概要を示します。この項の内容は次のとおりです。
ミッション・クリティカルなコンピュータ・システムは、24時間365日利用可能である必要があります。しかし、計画停止または計画外停止では、システムの一部またはすべてを停止することがあります。システムの可用性は、システム導入後の合計時間のうちのサービス提供時間の割合で測定されます。表1-1に、例を示します。
| 可用性の割合 | 年間停止時間の概算 |
|---|---|
|
95% |
18日 |
|
99% |
4日 |
|
99.9% |
9時間 |
|
99.99% |
1時間 |
|
99.999% |
5分 |
表1-2に、コンピュータ・システムで想定される様々な障害のタイプを示します。
| 停止のタイプ | 障害のタイプ |
|---|---|
|
計画外停止 |
システム障害 |
|
|
データ障害 |
|
|
災害 |
|
|
人為ミス |
|
計画停止 |
システム・メンテナンス（オペレーティング・システム、アプリケーション・サーバー、構成、アプリケーションの変更などのハードウェアおよびソフトウェアの変更を含む） |
|
|
データ・メンテナンス |
停止のこれら2つのタイプ（計画停止と計画外停止）は通常、システムの可用性要件の設計時には別々に扱われます。システムの要件は、計画外停止に関しては非常に制限的な場合がありますが、計画停止に関しては非常にフレキシブルな場合があります。これは、営業時間には負荷がピークに達するが、夜間と週末にはほとんど非アクティブなままであるアプリケーションの場合に当てはまります。
高可用性ソリューションは、1つのデータ・センター配置における高可用性を実現するローカル高可用性ソリューションと、通常は地理的に分散配置されていて、洪水や地域的なネットワークの停止などの災害からアプリケーションを保護する、障害時リカバリ・ソリューションに分類できます。
想定される障害タイプのうち、プロセス障害、ノード障害、メディア障害および人為ミスは、ローカル高可用性ソリューションで保護できます。ローカルの物理的な障害については、地理的に分散された障害時リカバリ・ソリューションで保護できます。
高可用性の問題を解決するには、いくつかのテクノロジとベスト・プラクティスが必要になります。その中で最も重要なメカニズムは冗長性です。高可用性は、システムとコンポーネントに冗長性を持たせることによって実現されます。ローカル高可用性ソリューションは、冗長性のレベルによってアクティブ/アクティブ・ソリューションとアクティブ/パッシブ・ソリューションに分類されます（図1-1を参照）。
包括的な高可用性システムでは、アーキテクチャの冗長性に加えて、次のローカル高可用性テクノロジも必要です。
構成やソフトウェアに障害が発生したため、予期しないときにプロセスが停止する場合があります。プロセスの監視と再起動が適切に行われるシステムでは、すべてのシステム・プロセスが常時監視され、障害がある場合にそれらが再起動されます。
システム・プロセスは、特定の時間間隔における再起動の回数も記録している必要があります。短期間に何度も再起動を行うと他の障害を引き起こすことがあるため、これも重要な機能です。したがって、特定の時間間隔における再起動や再試行の回数の上限も指定しておく必要があります。
システムのコンポーネントをまとめてクラスタリングすることにより、クライアント側は、ランタイム処理と管理性の観点から、これらのコンポーネントを機能的に1つのエンティティとみなすことができます。クラスタは、1つのコンピュータ、または同じワークロードを共有する複数のコンピュータ上で実行される一連のプロセスです。クラスタリングと冗長性には密接な関係があります。クラスタは、システムの冗長性を実現します。
類似したコンポーネントを1つのグループにクラスタリングすると、多くの場合、共通の構成を共有する必要があります。適切な構成管理によって、コンポーネントが同じ受信リクエストに対して同一のレスポンスを返したり、これらのコンポーネントの構成を同期化することが可能になります。また、管理目的の停止時間を短縮する可用性の高い構成管理を実現できます。
ステートフル・アプリケーションでは、これらのリクエストを処理しているプロセスに障害が発生した場合、リクエストのステートフル・フェイルオーバーを有効にするためにクライアント状態をレプリケートできます。
同じサーバー・コンポーネントの複数のインスタンスを使用できる場合、これらのコンポーネントに対するクライアント・リクエストは、各インスタンスのワークロードがほぼ同一になるようにロード・バランシングされます。ロード・バランシング・メカニズムが利用されると、インスタンスは冗長になります。いずれかのインスタンスに障害が発生した場合、そのインスタンスに対するリクエストを、障害の発生していないインスタンスに送信できます。
ユーザー・エラーによってシステムが誤作動することがあります。特定の状況下では、コンポーネントまたはシステムの障害が修復不可能なこともあります。そのため、バックアップとリカバリの機能を使用してシステムを一定の間隔でバックアップし、修復不可能な障害が発生したときにバックアップをリストアできるようにする必要があります。
障害時リカバリ・ソリューションでは通常、2つの同種のサイト（1つはアクティブ・サイト、もう1つはパッシブ・サイト）を設定します。サイトはそれぞれが自己完結型のシステムです。一般的に、アクティブ・サイトを本番サイト、パッシブ・サイトをスタンバイ・サイトと呼びます。通常の運用では、本番サイトがリクエストを処理しますが、サイトでフェイルオーバーやスイッチオーバーが発生すると、スタンバイ・サイトが本番サイトを引き継ぎ、すべてのリクエストはそのサイトにルーティングされます。フェイルオーバーのためにスタンバイ・サイトを保持するには、スタンバイ・サイトに同種のインストールとアプリケーションを含めるだけでなく、データと構成を本番サイトからスタンバイ・サイトに常時同期化する必要もあります。
Oracle Application Serverの高可用性の概要については、次の各項で説明します。
次に示す用語の定義は、このマニュアルで説明されている概念の理解に役立ちます。
ハードウェア・クラスタは、専用のハードウェア（クラスタ・インターコネクト、共有記憶域）とソフトウェア（ヘルス・モニター、リソース・モニター）を使用して、高可用性とスケーラビリティを実現します（クラスタ・インターコネクトは、ハートビート情報がノードの停止を検出する際にハードウェア・クラスタで使用されるプライベート・リンクです）。専用のハードウェアとソフトウェアが必要であるため、通常、ハードウェア・クラスタはSun社、HP社、IBM社、Dell社などのハードウェア・ベンダーによって提供されます。1つのハードウェア・クラスタ内で構成可能なノード数は、ベンダーによって異なりますが、Oracle Application Serverの高可用性では2つのノードのみを必要とします。そのため、このドキュメントでは、2つのノードを持つハードウェア・クラスタを高可用性ソリューションで使用することを前提とします。
OracleAS Cold Failover Cluster（中間層）環境では、Oracleホーム・ディレクトリは共有記憶域システムにインストールするか、ハードウェア・クラスタ内の各ノードのローカル記憶域にインストールできます。
/etc/hostsファイル（UNIXの場合）、C:¥WINDOWS¥system32¥drivers¥etc¥hostsファイル（Windowsの場合）またはDNS解決のいずれかで指定される、IPアドレスに割り当てられる名前です。この名前は、マシンが接続しているネットワークで参照可能です。多くの場合、ネットワーク・ホスト名と物理ホスト名は同じものを指します。しかし、各マシンが持つ物理ホスト名は1つのみですが、ネットワーク・ホスト名は複数持つことができます。したがって、マシンのネットワーク・ホスト名が常に物理ホスト名になるわけではありません。
hostnameコマンドにより返される名前です。物理ホスト名は、Oracle Application Serverにより、ローカル・ホストを参照する名前として使用されます。物理ホスト名はインストール時に、インストーラにより現行マシンから取得され、ディスク上のOracle Application Server構成メタデータに格納されます。
ハードウェア・クラスタは、クラスタの仮想IPを使用して、外部に対するクラスタへのエントリ・ポイントを示します（スタンドアロン・マシン上にも設定できます）。ハードウェア・クラスタのソフトウェアは、外部クライアントによるこのIPアドレスへの接続中、クラスタの2つの物理ノード間でのこのIPアドレスの移動を管理します。その際、クライアントは、このIPアドレスが現在どの物理ノードでアクティブであるかを知る必要はありません。2つのノードを持つ標準的なハードウェア・クラスタ構成の場合、各マシンは固有の物理IPアドレスと物理ホスト名を持ちますが、複数のクラスタIPアドレスを持つことができます。これらのクラスタIPアドレスは、2つのノード間で浮動または移行します。現在、クラスタIPアドレスの所有権を持っているノードが、そのアドレスのアクティブ・ノードになります。
また、ロード・バランサも一連のサーバーのエントリ・ポイントとして仮想IPを使用します。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーに割り当てられるのではなく、サーバーとクライアントの間のプロキシとして機能するロード・バランサに割り当てられます。
可用性の高いOracle Application Serverのインストールを作成する前に、Oracle Application Serverの基本アーキテクチャについて理解する必要があります。次に、Oracle Application Serverの高可用性を実現するために、すべてのコンポーネントおよびコンポーネント間の接続経路を調べて、それらの可用性を向上させます。これにより、基本アーキテクチャを冗長にすることで、高可用性アーキテクチャが実現します。
図1-3に、Oracle Application Serverの基本アーキテクチャを示します。
高レベルでは、Oracle Application ServerはOracle HTTP ServerとOracle Containers for J2EE（OC4J）で構成されます。OC4Jは、ビジネス・アプリケーションをデプロイするJ2EEコンテナを提供します。
必要に応じて、リリース10.1.4、リリース2（10.1.2）またはリリース9.0.4のOracle Identity Managementを使用することもできます。詳細は、次の項を参照してください。
このリリースのOracle Application Serverには、J2EE中間層のみが含まれています。Oracle Identity ManagementまたはOracleAS Metadata Repositoryは含まれていません。
ビジネス・アプリケーションで、Oracle Identity Managementコンポーネントが提供するサービスが必要な場合は、リリース3（10.1.3.1.0）のJ2EE中間層にビジネス・アプリケーションをデプロイし、実行できます。それによって、これらのアプリケーションからリリース10.1.4、リリース2（10.1.2.x）またはリリース9.0.4のOracle Identity Managementにアクセスできるようになります。図1-3を参照してください。
Oracle Identity Managementは、ユーザー認証、許可およびID情報を管理します。これは、次の主要コンポーネントで構成されます。
可用性の高い環境では、中間層、Oracle Identity ManagementおよびOracleAS Metadata Repositoryのすべてにおいて高度な可用性を実現する必要があります。このガイドでは、高可用性J2EE中間層の設定方法について説明します。高可用性Oracle Identity ManagementおよびOracleAS Metadata Repositoryの設定方法の詳細は、使用しているOracle Identity Managementリリースの『Oracle Application Server高可用性ガイド』を参照してください。
OracleAS Metadata RepositoryデータベースはOracle Identity Managementリリースに関連付けられていますが、OracleAS Metadata RepositoryデータベースはDCMまたはリリース3（10.1.3.1.0）のインスタンス構成情報の格納には使用されません。リリース3（10.1.3.1.0）にはDCMは含まれません。OracleAS Metadata Repositoryは、Oracle Identity Managementコンポーネントのみに使用されます。
Oracle Application Serverは、柔軟性の高いインストール、配置およびセキュリティ・オプションとともに、ローカル高可用性、あらゆる障害に対して最大限の保護を提供する障害時リカバリ・ソリューションを備えています。ローカル高可用性ソリューションと障害時リカバリ・ソリューションのアーキテクチャに含まれる冗長ノードおよび冗長プロセスによって、高可用性が実現されます。
高レベルでは、Oracle Application Serverのローカル高可用性アーキテクチャには複数のアクティブ/アクティブおよびアクティブ/パッシブ・アーキテクチャが含まれています。どちらのソリューションを使用しても高可用性は実現できますが、一般的にはアクティブ/アクティブ・ソリューションのほうがスケーラビリティに優れ、フェイルオーバーも迅速です。その一方で、より多くのコストがかかるというデメリットもあります。アクティブ/アクティブとアクティブ/パッシブのどちらのカテゴリでも、インストールの容易さ、コスト、スケーラビリティおよびセキュリティが異なる複数のソリューションがあります。
ローカル高可用性ソリューションの上部には、Oracle Application Server Disaster RecoveryソリューションであるOracle Application Server Guardが構築されます。このユニークなソリューションでは、Oracle Databaseの実績のあるOracle Data Guardテクノロジがアプリケーション分野の高度な障害時リカバリ・テクノロジと統合されます。これにより、アプリケーション・システム全体における包括的な障害時リカバリ・ソリューションが提供されます。このソリューションには、同種の本番サイトとスタンバイ・サイトが必要ですが、障害時リカバリ設定のインスタンスに影響しない範囲で、それぞれのサイトに他のOracle Application Serverインスタンスをインストールすることもできます。これら2つのサイトの同質性を確保するには、両サイト間で構成とデータを定期的に同期化する必要があります。
世界のすべてのシステムに通用する、ただ1つの最適な高可用性ソリューションは存在しませんが、ご使用のシステムに最適なソリューションを選択することはできます。高可用性システムを設計するうえで最も重要な決定は、ビジネスまたはアプリケーションのサービス・レベル要件に基づく最適な高可用性アーキテクチャまたは冗長性タイプの選択であるといえます。高可用性の実装にかかるコストは、そのレベルによって異なるため、ビジネスの可用性の要件を理解することは非常に重要です。
Oracle Application Serverには、様々なサービス・レベル要件に合せた数多くの高可用性ソリューションが用意されています。ご使用のアプリケーションにとって最も包括的なソリューションが最適であるとはかぎりません。最適な高可用性アーキテクチャの選択には、ビジネスのサービス・レベル要件をまず理解することが不可欠です。
次に、高可用性アーキテクチャを決定するのに役立つ高レベルの質問を示します。
これらの質問に対する回答に基づいて、次の2つの項目で選択を行う必要があります。
表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 |
基本（Oracle Identity Management）1 |
Y |
|
Y |
Y |
Y |
アクティブ/パッシブおよびアクティブ/アクティブ（Oracle Identity Management）1 |
Y |
次の段落では、リリース10.1.4またはリリース2（10.1.2）のOracle Identity Managementについて説明します。
中間層とOracle Identity Managementには、それぞれ別の高可用性アーキテクチャを選択できますが、ローカル高可用性および障害時リカバリの要件は同一である必要があります。また、スケーラビリティの要件は、中間層とOracle Identity Managementでは別に評価する必要があります。Oracle Identity Managementでは通常、処理するリクエストが少ないため、中間層ほどのスケーラビリティは必要とされません。
このようなスケーラビリティ要件の違いのため、配布するアーキテクチャは中間層とOracle Identity Managementとで異なる場合があります。たとえば、ローカル高可用性、サイト間の障害時リカバリ、スケーラブルな中間層とOracle Identity Managementの基本的なスケーラビリティを組み合せた配置が必要であるとします。この場合は、アクティブ/アクティブの中間層、アクティブ/パッシブのOracle Identity Management、および本番サイトのすべての中間層とOracle Identity Management構成をミラー化するスタンバイ障害時リカバリ・サイトを配置することになります。
表1-4に、高可用性情報を含むOracle Application Serverのガイド（このガイド以外）を示します。この情報は、Oracle Application Serverの各種コンポーネントの高可用性に関連するものです。
|
 Copyright © 2006, Oracle. All Rights Reserved. |
|