| Oracle Database高可用性概要 11gリリース1（11.1） E05748-03 |
|
 戻る |
 次へ |
Maximum Availability Architecture（MAA）は、Oracleのベスト・プラクティスの将来図です。これは、実績のあるOracle高可用性テクノロジと推奨事項に基づいています。MAAの目標は、構成上の推奨事項を提供し、お使いのアーキテクチャとOracle機能を最大限に利用するヒントを調整することにより、最適な高可用性アーキテクチャを設計する際の複雑さをなくすことです。
この章では、Oracle環境の様々な高可用性アーキテクチャについて説明します。これは組織に適したアーキテクチャの選択に役立ちます。
この章の内容は次のとおりです。
次の項では、Oracle Database高可用性アーキテクチャの概要を説明します。
Oracle Clusterware機能が搭載されたOracle Database（コールド・フェイルオーバー・クラスタ）
Oracle Real Application Clusters（Oracle RAC）機能が搭載されたOracle Database
これらすべてのアーキテクチャでは、MAAのベスト・プラスティスを利用する必要があります。
異なるアーキテクチャの比較と、利点および考慮事項の最も重要な点は、「正しい高可用性アーキテクチャの選択」の項を参照してください。
アーキテクチャを選択すると、MAAのホワイト・ペーパーや『Oracle Database高可用性ベスト・プラクティス』に記述されている運用上および構成上のベスト・プラクティスを使用してそのアーキテクチャを実装できます。各アーキテクチャの利点をすべて最大限に生かすには、これらのベスト・プラクティスが必要です。ベスト・プラクティスのドキュメントの詳細は、第5章「MAAおよび高可用性ベスト・プラクティス」を参照してください。
Oracle Databaseは、単一インスタンスの非クラスタ・データベースです。このアーキテクチャはノードやデータベースの冗長性を備えていませんが、このアーキテクチャで使用できる多くの高可用性機能と、結果として生じるいくつかのデータベース・アーキテクチャがあります。これらの高可用性機能は、特定の障害や計画メンテナンス・アクティビティに対する単一コンピュータ上のスタンドアロン・データベースの魅力および可用性を高めます。
オラクル社では、このアーキテクチャの次のOracle機能を使用することをお薦めします。これは、結果として生じる高可用性アーキテクチャの基盤となるものです。
ファスト・スタート・リカバリは、インスタンスやデータベースのリカバリ時間を制限および最適化します。
自動ストレージ管理（ASM）は、ストレージ障害を許容し、ストレージのパフォーマンスおよび使用率を最適化します。
Oracle Flashbackテクノロジは、論理障害の修復を最適化します。オラクル社では、十分な領域で自動UNDO管理を使用して必要なUNDO保存の保証を実現し、フラッシュバック・データベースを有効にして、フラッシュ・リカバリ領域に十分な領域とI/O帯域幅を割り当てることをお薦めします。
Recovery Manager（RMAN）は、データ障害の論理的な修復を最適化します。オラクル社では、フラッシュ・リカバリ領域にローカル・バックアップを作成および保存することをお薦めします。
フラッシュ・リカバリ領域は、ローカル・リカバリに関連するファイルを管理します。
オンライン再編成および再定義は、動的データ変更を可能にします。
Oracleセキュリティ機能は、認可されていないアクセスや変更を防止します。
データ・リカバリ・アドバイザは、様々なデータ障害について優れたアドバイスと修復を行います。
データ・ブロック破損の予防と検出のパラメータは、破損や書込み欠落を検出および防止します。
動的リソース・プロビジョニングは、動的システム変更を可能にします。
オンライン・パッチ適用は、典型的な診断パッチの動的データベース・パッチを可能にします。
Oracle Secure Backupは、一元化されたテープ・バックアップ管理ソリューションを提供します。
図4-1は、ASMインスタンスを含む基本的な単一ノードのOracle Databaseを示しています。脚注1このアーキテクチャでは、フラッシュバック・データベース、オンライン再定義、Recovery ManagerおよびOracle Secure Backupなどの高可用性機能を使用しています。
Oracle Clusterwareは、ユーザー・アプリケーションおよびOracleデータベースの可用性を管理するソフトウェアです。Oracle Clusterwareを実行するサーバーは、同じオペレーティング・システムを実行している必要があります。
現在、高可用性アーキテクチャの多くは、基本的なノードの冗長性と自動ノード・フェイルオーバーを提供するためにクラスタのみを使用します。ただし、Oracle Clusterwareを使用すると、サード・パーティのクラスタウェアを使用する必要性やメリットがなくなります。
Oracle Clusterwareには、サード・パーティのクラスタウェアよりも優れた次のような多くの利点があります。
Oracle Clusterwareにより、Oracleのソフトウェア・ソリューションをすべて使用できるので、他のクラスタウェア・ソフトウェアを管理するコストや複雑さを回避できます。
調整やサポートが必要なソフトウェアの組合せの数が減ることで、システム・ソフトウェアの管理性および可用性が向上します。
Oracle Clusterwareでは、Oracle Real Application Clustsers（Oracle RAC）やOracle Data Guardとの統合や移行がシームレスに行われます。
4.1.7項では、Oracle RACおよびOracle Data Guardによる最高レベルの可用性を実現する方法について説明します。
Oracle Clusterwareにはクラスタ管理に必要な機能がすべて含まれます。これらの機能には、ノード・メンバーシップ、グループ・サービス、グローバル・リソース管理、および高可用性機能（サード・パーティ・アプリケーションの管理、イベント管理、および障害後にOracleクライアントが新しいプライマリ・データベースに再接続できるOracle通知サービスなど）があります。
Oracle Clusterwareはプライベート・ネットワークと投票ディスクを使用して、スプリット・ブレイン脚注2のシナリオを検出および解決します。
Oracle Clusterwareでは、システムやサーバーの障害からOracleインスタンスを保護するコールド・フェイルオーバー・クラスタが提供されています。コールド・フェイルオーバー・クラスタの基本的な機能として、サーバーで稼働しているデータベース・インスタンスを監視し、障害が検出された場合は、クラスタ内のスペア・サーバーでそのインスタンスを再起動します。ネットワーク・アドレスは、バックアップ・ノードにフェイルオーバーされます。ネットワーク上のクライアントはフェイルオーバー実行時に一定期間ロックアウトしますが、インスタンスが起動すると、他のデータベース・インスタンスで処理されます。また、Oracle Clusterware機能を使用してアプリケーションとアプリケーション・リソースを再配置し（CRS_RELOCATEコマンドを使用）、別のノードにワークロードを移動して本番サーバーで計画システム・メンテナンスを実行できます。
Oracle Clusterwareを使用したコールド・フェイルオーバー・クラスタ・ソリューションにより、基本的なデータベース・アーキテクチャよりも優れた次のような利点が得られます。
ノード障害とインスタンス障害を数分で自動リカバリ
Oracle統合クライアントの自動通知および再接続脚注3
障害検出メカニズムのカスタマイズが可能。
たとえば、データベース・チェック・アクションで好きなアプリケーション問合せを使用できます。アプリケーション別の障害検出を行うと、Oracle Clusterwareはインスタンス停止などの明らかな場合のみでなく、アプリケーション問合せが特定のサービス・レベルを満たしていないなどの場合にもフェイルオーバーできます。
サード・パーティ・アプリケーションを管理する高可用性機能
Oracle Clusterwareのローリング・リリース・アップグレード
Oracle Clusterwareのコールド・フェイルオーバー・クラスタの操作については、図4-2および図4-3を参照してください。これらの図は、Oracle Clusterwareのフレームワークを使用して、Oracleデータベースおよびカスタム・アプリケーションの高可用性を実現する方法を示しています。
図4-2は、Oracle Clusterwareを使用して、基本的なOracle Databaseアーキテクチャを拡張し、コールド・フェイルオーバー・クラスタを実現する構成を示しています。この図では、構成は通常モードで機能します。ノード1は、アプリケーションとユーザーにサービスを提供するアクティブ・インスタンスで、Oracle Databaseに接続されています。ノード2は、ノード1とOracle Databaseに接続されていますが、現在スタンバイ・モードになっています。
図4-2 Oracle Clusterware機能が搭載されたOracle Database（コールド・フェイルオーバー・クラスタ前）
図4-3は、コールド・フェイルオーバー・クラスタ後のOracle Clusterware構成です。この図では、ノード2はOracle Databaseに接続されたアクティブ・インスタンスで、アプリケーションとユーザーにサービスを提供しています。ノード1は、ノード2とOracle Databaseに接続されていますが、現在スタンバイ・モードでアイドルになっています。
この透過的なフェイルオーバー機能を実現するために、Oracle Clusterwareでは、クラスタ内のノードごとに仮想IPアドレスが必要です。また、Oracle Clusterwareでは、アプリケーションの仮想IPアドレスを定義するため、ユーザーはそのアプリケーションが稼働しているクラスタ・ノードのアプリケーションに個別にアクセスできます。複数のアプリケーションVIPを定義できます。通常、実行中のアプリケーションごとに1つのアプリケーションVIPを定義します。Cluster Ready Services（CRS）で定義されるアプリケーション・リソースに依存することで、アプリケーションVIPはアプリケーションと結び付けられます。
図4-3 Oracle Clusterware機能が搭載されたOracle Database（コールド・フェイルオーバー・クラスタ後）
|
注意: Oracle Enterprise ManagerとOracle Universal Installer（OUI）はどちらも、Oracle Clusterware構成をサポートしません。Oracle Clusterware環境を構成するには、プラットフォーム別のOracle Clusterwareのインストレーション・ガイドの手順に従って実行します。 |
Oracle DatabaseとOracle RACを組み合せたアーキテクチャは、本質的に高可用性システムです。従来のモノリシック・データベース・サーバーは高価で、容量およびリソースへの要求の変更に対して柔軟性がありませんが、これとは異なり、Oracle RACでは複数のインターコネクトされたコンピュータの処理能力を組み合せて、システムの冗長性、スケーラビリティおよび高可用性を提供します。
Oracle RAC環境の典型的なクラスタでは、計画停止および計画外停止に対して連続的なサービスを提供できます。Oracle RACは、標準のOracle機能をベースに、さらに高度な可用性を確立します。フラッシュバック・テクノロジやオンライン再編成などの単一インスタンス高可用性機能は、すべてOracle RACにも適用されます。Oracle RAC環境では、アプリケーションは、アプリケーション・コードを変更せずに増加するデータ処理要求を満たすようスケール変更されます。さらに、アプリケーションがクラスタ内の他の部分で実行している間、クラスタ内のコンポーネントのサブセット上でメンテナンス操作を行うことが可能なため、計画停止時間を短縮できます。
Oracle RACはクラスタ化によって得られる冗長性を利用し、nノード・クラスタのn - 1ノード障害における可用性を提供しています。1つのノードが完全にアイドルになっているコールド・クラスタ・モデルとは異なり、アプリケーションのスケールを変更するためにすべてのインスタンスとノードをアクティブにできます。
Oracle RACを搭載するOracle Databaseアーキテクチャには、従来のモノリシック・データベース・サーバーやコールド・フェイルオーバー・クラスタ・モデルよりも優れた次のような利点があります。
データベース・インスタンスにまたがるスケーラビリティ
停止時間またはアプリケーションへの変更なしで、汎用ハードウェアを使用して処理能力を向上できる柔軟性
コンピュータおよびインスタンスの障害からの許容および迅速なリカバリが可能（数秒で測定）
システム変更およびハードウェア変更のローリング・アップグレード
一部の個別パッチのローリング・パッチ・アップグレード
高速、自動、インテリジェントな接続およびサービスの再配置ならびにフェイルオーバー
ロード・バランシングのアドバイスおよび実行時の接続ロード・バランシング
データベースおよびクラスタの機能を統合する包括的な管理性
図4-4は、Oracle RACを搭載するOracle Databaseアーキテクチャを示しています。
Oracle RACを搭載するOracle Databaseアーキテクチャは、単一データ・センターにあるスケーラビリティおよび可用性ソリューションとして主に設計されています。特定の状況では、クラスタ内のノードが遠く離れているOracle RACシステムを構築してデプロイすることができます。このアーキテクチャは、拡張クラスタと呼ばれます。脚注4
Oracle RAC拡張クラスタは、サイト障害からの超高速リカバリを実現し、全サイトのすべてのノードが1つのデータベース・クラスタの構成要素としてトランザクションをアクティブに処理できるアーキテクチャです。たとえば、企業キャンパスを持つ企業の場合、拡張Oracle RAC構成が別の建物内にある個別Oracle RACノードで構成されている可能性があります。拡張クラスタのOracle RACは、ローカルのOracle RACクラスタよりも優れた高可用性を提供しますが、組織の障害時リカバリ要件を完全に満たすとはかぎりません。
2つのデータ・センターが互いに比較的近い場所にある場合、拡張クラスタは一部の災害に対して高度な保護機能を提供できますが、すべての災害に対して提供できるわけではありません。両方のサイトが同じ災害によって影響を受ける可能性があるかどうかを確認する必要があります。たとえば、拡張クラスタ構成を適切に設定すると、ローカルの停電、航空機の墜落事故またはサーバー・ルームの水害といった災害に備えることができます。ただし、広い地域に影響を及ぼす地震、ハリケーンおよび地域洪水などの広範囲な災害に対して保護することはできません。（完璧な障害時リカバリについては、4.1.7項「Oracle RACおよびData Guard機能を搭載したOracle Database - MAA」で説明するアーキテクチャを使用します。）
拡張クラスタでOracle RACを使用する利点は次のとおりです。
インスタンス障害やノード障害に要するフェイルオーバー時間全体を無駄にすることなく、すべてのシステム・リソースの十分な使用が可能
1つのサイトに障害が発生した場合の超高速リカバリ
4.1.3項「Oracle Real Application Clusters（Oracle RAC）機能が搭載されたOracle Database」に示すOracle RACのすべての利点
|
注意: このアーキテクチャは効率的であり、正常に実装されていますが、この説明で提案された環境（距離、待機時間および保護の程度を含む）でのみ実装してください。 |
図4-5は、2つの異なる場所にある6つのノード（サイトAとサイトBにそれぞれ3つのノードがある）に複数のアクティブ・インスタンスが存在する構成の拡張クラスタのOracle RACを示しています。パブリック・インターコネクト、プライベート・インターコネクト、およびストレージ・エリア・ネットワーク（SAN）は、すべて別々の専用チャネル上にあり、それぞれに冗長性が構成されています。可用性の理由から、Oracle Databaseは両方のサイトでミラー化される単一データベースです。また、いずれかのサイトに障害が発生した場合のクラスタ全体の停止を防ぐために、構成には、安価な標準ネットワーク・ファイル・システム（NFS）でマウントされた3つ目の投票ディスク・デバイスが含まれています。
|
関連項目:
|
Oracle Data Guardは、データベース障害、ノード障害、破損およびメディア障害が発生した場合に超高速自動フェイルオーバー（ファスト・スタート・フェイルオーバーと呼ばれる）を提供する高可用性および障害時リカバリ・ソリューションです。さらに、スタンバイ・データベースは、読取り専用アクセス、続いてリーダー・ファーム用、レポート作成用、テストおよび開発用に使用できます。
従来のソリューション（テープからのバックアップおよびリカバリ、ストレージ・ベースのリモート・ミラー化およびデータベース・ログの送信など）では、ある程度の高可用性が提供されますが、Data GuardではOracleデータベースの包括的な高可用性および障害時リカバリ・ソリューションが提供されます。
Data Guardには、従来のソリューションよりも優れた多くの利点があります。内容は次のとおりです。
データ破損、書込み欠落、およびデータベース障害とサイト障害に対応する高速自動フェイルオーバー
プライマリ・データベースでのデータ破損と書込み欠落に対する保護
Data Guardのローリング・アップグレード機能による停止時間の短縮
RTOおよびRPOを犠牲にせずに、プライマリ・データベースのアクティビティ（バックアップ、問合せまたはレポート作成など）のオフロードが可能
サイト障害の場合は、インスタンスの再起動、ストレージの再マスタリングまたはアプリケーションの再接続が不要
アプリケーションに対して透過的
ネットワーク使用の効率化
さらに、Oracleデータベースに常駐するデータの場合、データ損失ゼロ機能が組み込まれているOracle Data Guardは、データ保護および障害時リカバリに関して従来のリモート・ミラー化ソリューションよりも効率的かつ安価でより最適化されています。Oracle Data Guardには、障害時リカバリとデータ保護のテクノロジを選択する際に、従来のリモート・ミラー化ソリューションよりもOracle Data Guardを採用する方が正しいと判断する、技術上およびビジネス上の理由があります。リモート・ミラー化ソリューションを使用する場合と比較した、Oracle Data Guardを使用する利点の概要を次に示します。
ネットワーク効率の向上: Oracle Data Guardでは、REDOデータのみをリモート・サイトに送信する必要があります。一方で、リモート・ミラー化ソリューションがデータ保護に使用される場合、通常はデータベース・ファイル、オンラインREDOログ、アーカイブREDOログおよび制御ファイルをミラー化する必要があります。フラッシュ・リカバリ領域がリモートでミラー化されるソースのボリューム上にある場合、フラッシュバック・ログもリモートでミラー化する必要があります。つまり、Data Guardと比較すると、リモート・ミラー化ソリューションでは各変更を何度もリモート・サイトに送信します。
パフォーマンスの向上: Data Guardは書込みをプライマリ・データベースのREDOログにのみ送信しますが、リモート・ミラー化ソリューションでは、これらの書込みとすべての書込みI/Oを、データ・ファイル、オンライン・ログ・ファイル・グループに追加されたメンバー、アーカイブREDOログ・ファイルおよび制御ファイルに送信する必要があります。Data Guardは、データ・ファイルに書き込むOracleデータベース書込み（DBWR）プロセスに影響を与えないように設計されています。これは、DBWRを低速化させるものはどんなものでもデータベースのパフォーマンスに影響を及ぼすためです。一方で、リモート・ミラー化ソリューションは、データ損失ゼロの同期構成に伴うネットワークおよびディスクI/Oの遅延に対するDBWRプロセスの書込みI/Oをすべて制御するため、DBWRのパフォーマンスに影響を与えます。ミラー化と比較すると、Data Guardではパフォーマンスと効率性が向上します。Data Guardは常にスタンバイ・データベースの状態を検証し、REDOを適用する前にデータを確認します。また、プライマリ・データベースを引き続き保護しながら、更新にスタンバイ・データベースを使用できます。
WANに対する適性の向上: ストレージ・システムに基づくリモート・ミラー化ソリューションでは、ストレージ・システムで使用される基本的な通信テクノロジ（ファイバ・チャネル、ESCON）が原因で距離の制限がある場合があります。一般的な例として、2つのボックスがポイント・ツー・ポイント方式で接続され、同期して実行している場合、この2つのボックス間で可能な距離は最大でわずか10kmです。専用デバイスを使用すれば、この距離は66kmまで拡張できますが、スタンバイ・データ・センターが66kmよりも離れている場合、サード・パーティ・ベンダーの一連のリピータやコンバータを使用する必要があります。これらのデバイスにより、ESCON/ファイバ・チャネルは適切なIP、ATMまたはSONETネットワークに変換されます。
リジリエンスおよびデータ保護の向上: Oracle Data Guardでは、リモート・ミラー化ソリューションよりも優れたデータ保護とデータ・リジリエンスが保証されます。これは、本番データベースで発生した破損はリモート・ミラー化ソリューションによってスタンバイ・サイトにミラー化できますが、Data Guardでは破損が削除されるためです。たとえば、ディスクに宛先違いの書込みが発生した場合、ファイル・システムに破損がある場合、あるいはディスクにブロックを書き込む際にホスト・バス・アダプタによってブロックが破損した場合、リモート・ミラー化ソリューションはこの破損をDRサイトに伝播します。Data GuardではログのREDOデータのみを伝播し、REDOデータの適用前にログ・ファイルの一貫性がチェックされるため、このような外部破損はすべてData Guardによって削除されます。
柔軟性の向上: Data Guardは純粋な汎用ハードウェアをベースに実装されます。必要なものは、2つのコンピュータ間で確立されるTCP/IPベースの標準ネットワーク・リンクのみです。高価なハードウェアは不要です。また、プライマリとは異なる方法でストレージをレイアウトできます。たとえば、異なるディスク、ボリューム、ファイル・システムなどにファイルを配置できます。
機能性の向上: Data Guardには完全なデータ保護機能（フィジカル・スタンバイ・データベースのREDO Apply、ロジカル・スタンバイ・データベースのSQL Apply、複数の保護モード、プッシュボタンによる自動スイッチオーバーとフェイルオーバー機能、自動ギャップ検出および解決、GUI駆動による管理および監視フレームワーク、REDOログの宛先のカスケード表示）が備わっています。これは、データ保護および障害時リカバリに関して、リモート・ミラー化ソリューションよりも最適化された包括的で効率的なソリューションです。
ROIの増加: ビジネスでは、IT投資からできるかぎり多くの価値を確実に得る必要があります。使用されていないITインフラストラクチャはありません。Data Guardは、ビジネスが障害時リカバリ・サイトに対する高額の投資から有益なものを得られるように設計されています。通常、これはリモート・ミラー化ソリューションでは不可能です。
次の項では、Oracle Data Guardを使用する、お薦めの高可用性および障害時リカバリ・アーキテクチャについて説明します。
単一のスタンバイ・データベース・アーキテクチャは、次の主な特性および推奨事項から構成されています。
プライマリ・データベースはサイトAにあります。
スタンバイ・データベースはサイトBにあります。プライマリ・データベースに対するパフォーマンスの影響を最小限に抑えてデータ損失をゼロにする必要がある場合、ベスト・プラクティスは、プライマリ・データベースから200マイル以内の場所にセカンダリ・サイトを配置することです。ただし、同期REDO転送では物理的な距離制限が課せられないことに注意してください。
ファスト・スタート・フェイルオーバーは、ユーザーが操作せず、リカバリ時間の制限がない状態で自動フェイルオーバーを提供する場合に推奨されます。プライマリ・データベースが非同期REDO転送を使用する場合、ビジネス要件を満たすには、許容される最大データ損失またはData GuardブローカのFastStartFailoverLagLimitプロパティを構成します。オブザーバ（Thinクライアントのウォッチドッグ）がアプリケーション層に存在し、プライマリ・データベースの可用性を監視します。オブザーバの詳細は、『Oracle Data Guard Broker』を参照してください。
読取り専用アクセスが十分な場合は、フィジカル・スタンバイ・データベースを使用します。
レポートを作成するために索引を追加する必要がある場合、およびロジカル・スタンバイ・データベースとSQL Applyでサポートされるデータ型のみをアプリケーションで使用する場合は、ロジカル・スタンバイ・データベースを評価します。
図4-6は、ファスト・スタート・フェイルオーバーの発生時、および発生前後のプライマリ・データベース、ターゲット・スタンバイ・データベースおよびオブザーバの関係を示しています。
図4-6 ファスト・スタート・フェイルオーバー時のプライマリ・データベース、スタンバイ・データベースおよびオブザーバの関係
次に、単一のスタンバイ・データベースを使用したData Guardの構成例について説明します。
あるエネルギ供給会社では、プライマリ・データ・センターから10マイル離れた設備にあるスタンバイ・データベースを使用しています。顧客サービスや安全性に影響を与える停止またはデータ損失は、Data Guardの同期転送および自動フェイルオーバー（ファスト・スタート・フェイルオーバー）によって回避されます。
通信業界に対する、あるインフラストラクチャ・サービス・プロバイダは、同期REDO転送に構成されたプライマリから400マイル以上離れた場所にある単一のスタンバイ・データベースを使用し、データ保護と高可用性を最大限に高めるデータ損失ゼロのフェイルオーバーを実現します。
ある通信プロバイダは非同期REDO転送を使用して、米国の西海岸にあるプライマリ・データベースと、2,200マイル以上離れた東海岸のスタンバイ・データベースを同期化します。これにより、プロバイダは地理的に離れた既存のデータ・センターを使用して、独自の高可用性を提供できます。
ある世界規模の製造会社では、Data Guardを使用してストレージベースのリモート・ミラー化を切り替え、プライマリ・サイトから50マイル離れたリカバリ・サイトでスタンバイ・データベースを管理しています。Data Guardには、より包括的なデータ保護機能があります。効率的なネットワーク使用の向上は、ネットワークをアップグレードする追加費用を負担せずに成長する余裕が多くあることを意味します。
このアーキテクチャは、同じData Guard構成に複数のスタンバイ・データベースがある点を除き、4.1.5.1項で説明した単一のスタンバイ・データベース・アーキテクチャと同じです。次に、複数のスタンバイ・データベース・アーキテクチャの実装について説明します。
プライマリ・データベースまたはターゲット・スタンバイ・データベースの機能停止時の、継続した透過的な障害または高可用性の保護
リーダー・ファームまたは検索データベース
レポート作成データベース
レスポンス時間を改善する、地域別のレポート作成データベースまたはリーダー・データベース
同期転送はローカル・スタンバイ・データベースに送信し、非同期転送はリモート・スタンバイ・データベースに送信して、最適レベルのパフォーマンスとデータ保護を実現
スナップショット・スタンバイ・データベースを使用したテストおよび開発のクローン
ローリング・アップグレード
フィジカル・スタンバイ・データベースを、ロジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースに変換したり、ロジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースを追加で作成したりできることに注意してください。
一時的なロジカル・スタンバイ・データベースを使用して、データベース・アップグレードの停止時間を最小限に抑えることができます。一時的なロジカル・スタンバイ・データベースの使用は、ロジカル・スタンバイ・データベースが存在しないData Guardアーキテクチャで有用です。
複数のスタンバイ・データベース環境では、（計画メンテナンスで）一時的なロジカル・スタンバイ・データベースを一時的に作成し、これをフィジカル・スタンバイ・データベース・ロールに戻すことができます。たとえば、一時的なロジカル・スタンバイ・データベースを使用し、必要に応じて、データベース・アップグレードの停止時間を最小限に抑えることができます。アップグレードを実行する際に個別のロジカル・スタンバイ・データベースを作成する必要はありません。一時的なロジカル・スタンバイ・データベースでローリング・アップグレードを行う高度な手順は次のとおりです。
フィジカル・スタンバイ・データベースでローリング・データベース・アップグレードの実行を開始します。
フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに一時的に変換し、アップグレードを実行します。（データ型の制限は、アップグレードの実行に必要な短期間に制限されます。）
ロジカル・スタンバイ・データベースをフィジカル・スタンバイ・データベース・ロールに戻します。
|
関連項目: 一時的なロジカル・スタンバイ・データベースでローリング・アップグレードを実行する順を追った手順については、『Oracle Data Guard概要および管理』または『Oracle Database高可用性ベスト・プラクティス』を参照してください。 |
スナップショット・スタンバイ・データベースをクローンまたはテスト・データベースとして使用し、新機能や新リリースをテストできます。スナップショット・スタンバイ・データベースは、データ保護とRPOが損われないように、引き続きREDOデータを受信して待ち行列に入れます。
スナップショット・スタンバイ・データベースは、時間が経過するにつれてプライマリ・データベースから分岐します。これは、プライマリ・データベースのREDOデータが受信時に適用されないためです。REDO Applyは、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに戻し、スナップショット・スタンバイ・データベースに対して行われたローカルな更新がすべて破棄されるまでREDOデータを適用しません。スナップショット・スタンバイ・データベースのローカルな更新によってさらに分岐しますが、プライマリ・データベースのデータは、スタンバイ・サイトにあるREDOログによって完全に保護されます。
プライマリ・サイトの本番データベースおよびセカンダリ・サイトの複数のスタンバイ・データベースを図4-7に示します。また、複数のスタンバイ・データベース環境の別の例については、図2-7「スタンバイ・データベースのリーダー・ファーム」を参照してください。
図4-7 プライマリ・サイトおよび複数のスタンバイ・サイトでのData Guard機能を搭載するOracle Databaseアーキテクチャ
|
関連項目:
|
次に、複数のスタンバイ・データベースを使用したData Guardの構成例を示します。
世界的に有名なある金融機関では、フェイルオーバー後の連続的なデータ保護を維持するために、2つのリモート・フィジカル・スタンバイ・データベースを使用しています。プライマリ・システムに障害が発生した場合、最初のスタンバイ・データベースが新しいプライマリになります。2番目のスタンバイ・データベースは、新しいプライマリからデータを自動的に受信するため、データが常に保護されることが保証されます。
米国内の有名なある保険プロバイダでは、同じData Guard構成で2つのスタンバイ・データベースを管理しています。1つはフィジカル・スタンバイ・データベース、もう1つはロジカル・スタンバイ・データベースです。この戦略では、複数のスタンバイ・データベースを管理することでリスクがさらに軽減されます。各データベースは別のアーキテクチャ（REDO ApplyとSQL Apply）を使用して実装されています。
世界的に有名なあるE-Commerceサイトでは、フィジカル・データベースとロジカル・データベースを組み合せた複数のスタンバイ・データベースを使用しています。これらは、障害時リカバリと、SQL Applyを使用して複数のロジカル・スタンバイ・データベースをプロビジョニングすることによる読取りパフォーマンスの向上を目的としています。
法的機関や金融機関に対する、ある世界的な情報サービス・プロバイダでは、同じData Guard構成で複数のスタンバイ・データベースを使用して、データベースの大幅なアップグレードやプラットフォームの移行における停止時間を最小限に抑えています。
また、大規模なデータ・センターがData Guard要件に従って多くのアプリケーションをサポートする必要がある場合、Data Guardハブを構築して、総所有コストを削減できます。
データベース・サーバーとストレージ・グリッドを使用すると、システム・リソースのプールを利用するスタンバイ・データベースおよびテスト・ハブを構築できます。システム・リソースは、様々な優先度に応じて動的に割り当てたり、割当てを解除したりすることができます。たとえば、プライマリ・データベースがスタンバイ・ハブのいずれかのスタンバイ・データベースにフェイルオーバーした場合、テスト・リソースが一時的に不足している間に、新しいプライマリ・データベースが、より多くのシステム・リソースとストレージ・リソースを取得します。Oracleグリッド・テクノロジでは、ビジネス要件を損うことなく、高レベルの使用率と低TCOが可能になります。
Data Guardハブは次の要素から構成できます。
サーバー・クラスタ（グリッド・サーバーと呼ばれる）内にある、Oracle RAC環境の複数のスタンバイ・データベース
ストレージ・グリッドの利用
スタンバイ・ハブでは、低コストで高い使用率を実現することが前提になります。すべてのデータベースを同時にフェイルオーバーする可能性はほとんどありません。そのため、フェイルオーバーが発生した場合、本番アクティビティに対するシステム・リソースの優先順位を決め、スタンバイ・データベース機能に対する新しいシステム・リソースをグリッドに割り当てることができます。ロールの移行時に、該当アプリケーションに対してストレージ・リソースおよびシステム・リソースを追加で割り当てることができます。
たとえば、Data Guardハブには、グリッド・サーバーとストレージ・アーキテクチャでサポートされる複数のデータベースとアプリケーションを含めることができます。この構成は、グリッドで10個のアプリケーションとデータベースをサポートする一元集中リソースから構成されます。これに対して、非グリッド・インフラストラクチャでは10個のシステム単位またはストレージ単位を個別に管理します。
あるいは、スナップ・ショット・データベースから構成されるテスト・ハブの構成もあります。スナップ・ショット・スタンバイ・データベース・ハブでは、アプリケーションごとに個々のサーバーを構築および管理するのではなく、グリッドのストレージ・リソースとサーバー・リソースを組み合せて利用できます。
Oracle RACで提供されるスケーラビリティやその他の高可用性の利点がビジネスで必要とされないものの、Oracle Data Guardとコールド・フェイルオーバー・クラスタの利点はすべて必要とされる場合、このアーキテクチャが妥協案になります。Oracle Database 11gでは、Oracle Clusterwareのコールド・フェイルオーバー・クラスタとOracle Data Guardを組み合せると、緊密に統合されたソリューションが実現します。このソリューションでは、コールド・フェイルオーバー・クラスタでセカンダリ・ノードへのフェイルオーバーが透過的であり、Data Guard環境の再構成や追加手順は必要ありません。
プライマリ・サイトとセカンダリ・サイトで構成されるOracle ClusterwareおよびOracle Data Guardのアーキテクチャを図4-8に示します。プライマリ・サイトとセカンダリ・サイトの両方に、Oracleアプリケーション・サーバー、2つのデータベース・インスタンス、およびOracle Databaseがあります。
図4-8 Oracle Clusterware（コールド・フェイルオーバー・クラスタ）およびOracle Data Guard
図4-8の詳細は次のとおりです。
セカンダリ・サイトのアプリケーション・サーバーはWANトラフィック・マネージャと点線で結ばれています。これは、アプリケーション・サーバーがこの時点でクライアント・リクエストをアクティブに処理していないことを示します。セカンダリ・サイトのアプリケーション・サーバーは、スタンバイ・データベースがフィジカル・スタンバイ・データベースでActive Data Guardオプションが有効な場合、またはロジカル・スタンバイ・データベースの場合は、アクティブになり、問合せなどのクライアント・リクエストを処理できます。
Oracle Data Guardでは、REDOデータはプライマリ・データベースからセカンダリ・サイトに送信され、データベース間で同期化されます。
Oracle Clusterwareは、ユーザー・アプリケーションおよびOracleデータベースの可用性を管理します。
Oracle Clusterwareはノード障害を許容し、Data Guardはデータ破損、書込み欠落、データベース障害およびサイト障害に対する保護を提供します。（詳細は、「Data Guard機能が搭載されたOracle Database」を参照してください。）
コールド・フェイルオーバー・クラスタは図4-8に示されていませんが、セカンダリ・サイトにパッシブ・ノードを追加することで構成できます。
Oracle RACおよびOracle Data Guardを使用する場合、アプリケーションを変更せずに最高レベルの可用性を実現できます。これらのOracle機能は、スケジューリングした停止の停止時間を短縮し、スケジューリングしていない停止を防止、検出およびリカバリする最も包括的なアーキテクチャを提供します。このアーキテクチャはOracle RACとData Guardの利点を組み合せたもので、Maximum Availability Architecture（MAA）の推奨アーキテクチャです。
サイト障害から保護するために、MAAでは別々のシステム（クラスタ）とデータ・センターにOracle RACおよびData Guardを配置することをお薦めします。図4-9は、Oracle Database、Oracle RACおよびData Guardを使用するMAAの推奨構成を示しています。各サイトがロール移行後のアプリケーションのパフォーマンス要件とスケーラビリティ要件に対応できるようにするには、対称型のサイトを構成することをお薦めします。さらに、サイトが対称型であると、ロール移行における操作上のプラクティスが簡素化されます。
図4-9 Oracle RACおよびData Guard機能が搭載されたOracle Database - MAA
SQL ApplyモードでのOracle Data Guardと同様、Oracle Streamsは、データベースの変更を取得して指定先に伝播し、これらの伝播先で変更を適用できます。Streamsは、データのレプリケート用に最適化されます。Streamsではソース・データベースで変更を取得でき、取得した変更はレプリカ・データベースに非同期に伝播されます。Streamsを使用して構成および管理される論理的なコピーはレプリカと呼ばれます。これはロジカル・スタンバイ・データベースではありません。ロジカル・スタンバイ・データベースには、スタンバイ・データベースの通常定義の範囲を超える機能が数多く備わっているためです。
Streamsを使用して、本番データベースの論理的なコピーを構成および管理できます。Streamsを使用すると作業が増える場合がありますが、特定のビジネス要件を満たすために必要な高い柔軟性が得られます。
Streams機能が搭載されたOracle Databaseは粒度を提供し、レプリケートの対象およびレプリケート方法を制御します。Streamsは、双方向レプリケーション、データ変換、サブセット化、カスタム適用関数および異種プラットフォームをサポートしています。また、プライマリ・データベースからレプリカ・データベースへの変更レコードのルーティングをユーザーが完全に制御できるようにします。Streamsでは、プライマリ・データベースまたはレプリカ・データベースのダウンストリームでデータを取得できます。これにより、ユーザーは何百ものレプリカ・データベースをサポート可能なハブ・アンド・スポーク・ネットワーク構成を構築できます。
次の条件の中に当てはまるものが1つ以上ある場合は、Streams機能が搭載されたOracle Databaseの使用を検討してください。
両方のサイトまたはデータベースで更新が必要であり、その変更を双方向で伝播する必要がある。
サイト構成が異種プラットフォーム上にある。
プライマリ・データベースとレプリカ間で異なるキャラクタ・セットが必要
情報のきめ細かな制御およびデータ共有が必要
統合高可用性ソリューションの構築およびメンテナンスのための投資ならびに専門知識を増やすことができる。
図4-10は、3つのOracleデータベース間でスキーマのデータをレプリケートする、Streamsを使用したOracle Databaseのサンプルを示しています。hrスキーマの表に加えられたDMLおよびDDLの変更は、環境内のすべてのデータベースで取得され、環境内の各データベースに伝播されます。
|
関連項目: Streamsを使用したマルチソース・レプリケーション環境の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。 |
図4-10 複数のデータベースのデータを共有する、Streams機能が搭載されたOracle Databaseアーキテクチャ
Data GuardでStreamsを構成すると、構成内のデータベースを個別に保護できます。図4-11は、Oracle Data Guardによってハブおよびいずれかのサテライトのデータ保護が追加されるハブ・アンド・スポーク・ネットワーク構成を示しています。
この項では、様々な高可用性アーキテクチャの利点をまとめ、ビジネスに合った正しい高可用性アーキテクチャを選択するためのガイドラインを示します。
第3章「高可用性要件の特定」では、ビジネスと割り当てられた予算に合う高可用性要件によって、適切なアーキテクチャを特定する方法について説明しています。主な要因は次のとおりです。
たとえば、表4-1は、計画外アクティビティと計画アクティビティにおける様々な停止の確率に関する見識を示しています。このデータは、ユーザーの実際の体験やOracleサービス・リクエストから導出されたものです。
| アクティビティ | 停止 |
|---|---|
|
メディア障害またはディスク障害 |
高 |
|
アプリケーションのパッチ |
高 |
|
アプリケーション障害 |
高 |
|
論理データ（DMLおよびDDL）を操作する論理障害またはユーザー障害 |
高 |
|
データ破損および書込み欠損 |
中 |
|
コンピュータ障害 |
中 |
|
データベースのパッチ |
中 |
|
ハードウェアのパッチおよびアップグレード |
低 |
|
オペレーティング・システムのパッチおよびアップグレード |
低 |
|
データベースまたはアプリケーションのアップグレード |
低 |
|
データベース障害 |
低 |
|
プラットフォームの移行 |
低（きわめて低い） |
|
サイトの障害 |
低（きわめて低い） |
表4-2は、RTO、RPO、MO、スケーラビリティおよび他の要因に関するビジネス要件に基づいた推奨されるアーキテクチャを示しています。
| 使用を検討する高可用性アーキテクチャ | ビジネスまたはアプリケーションの影響 |
|---|---|
|
Oracle Clusterware機能が搭載されたOracle Database（コールド・フェイルオーバー・クラスタ） |
|
|
Oracle Real Application Clusters（Oracle RAC）機能が搭載されたOracle Database |
|
|
拡張クラスタのOracle RAC機能が搭載されたOracle Database |
|
|
Data Guard機能が搭載されたOracle Database |
フィジカル・スタンバイ・データベースでのこのソリューションの機能:
ロジカル・スタンバイ・データベースでのこのソリューションの機能:
|
|
Oracle ClusterwareおよびData Guard機能が搭載されたOracle Database |
|
|
Oracle RACおよびData Guard機能が搭載されたOracle Database |
|
|
Streams機能が搭載されたOracle Database |
|
脚注1 データベースはそのまま使用できますが、アプリケーションで障害のあるシステムに接続されている部分が一時的に影響を受けます。
脚注2 MOが高いアーキテクチャでは、構築およびメンテナンスに追加の時間と専門知識が必要になりますが、特定のビジネス要件を満たすために必要な柔軟性と機能性が高まります。
表4-3は、Oracle Databaseで構築するアーキテクチャによって提供されるその他の機能と、各アーキテクチャの最大の特徴を示しています。
表4-3 その他の高度なOracle高可用性アーキテクチャ機能
| Oracle高可用性アーキテクチャ | 重要な特徴とその他の機能 |
|---|---|
|
Oracle Database（基本的なアーキテクチャ） すべての高可用性アーキテクチャの基本 |
|
|
Oracle Clusterware機能が搭載されたOracle Database（コールド・フェイルオーバー・クラスタ） |
|
|
Oracle Real Application Clusters（Oracle RAC）機能が搭載されたOracle Database サーバー・データベース・グリッドの高可用性、スケーラビリティおよび基本 |
|
|
拡張クラスタのOracle RAC機能が搭載されたOracle Database サイト障害の保護を備えたデータベース・グリッド |
|
|
Data Guard機能が搭載されたOracle Database 最も単純な高可用性、データ保護および障害時リカバリ・ソリューション |
|
|
Oracle ClusterwareおよびData Guard機能が搭載されたOracle Database データの追加および障害時リカバリ保護による高可用性ソリューション |
|
|
Oracle RACおよびData Guard機能が搭載されたOracle Database スケーラビリティが組み込まれた、最善の高可用性、データ保護および障害時リカバリ・ソリューション |
|
|
Streams機能が搭載されたOracle Database脚注3 双方向のレプリケーションと情報の管理 |
|
脚注1 Oracle ClusterwareおよびOracle RACによるローリング・アップグレードでは、停止時間がゼロになります。
脚注2 Oracle Data Guardによるローリング・アップグレードでは、停止時間が最小限に抑えられます。
脚注3 堅牢なソリューションを構築するための初期投資は、特定のビジネス要件を満たすためにStreamsが提供する長期間の柔軟性と機能に見合う十分な価値があります。
表4-4は、統合されたOracleクライアントの検出時間およびクライアント・フェイルオーバー時間を含むリカバリ時間を適宜示しています。最適なリカバリ時間と構成を実現するには、MAAベスト・プラクティスを採用する必要があります。Oracle高可用性ベスト・プラクティスの推奨事項については『Oracle Database高可用性ベスト・プラクティス』と、次のWebサイトからダウンロード可能なホワイト・ペーパーを参照してください。
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
表4-4 計画外停止時に達成可能なリカバリ時間
| 停止範囲 | Oracle Database |
コールド・クラスタ | Oracle RACおよび拡張クラスタのRAC | Data Guard | Oracle RACおよびData Guard | Streams |
|---|---|---|---|---|---|---|
|
サイト障害 |
数時間〜数日 |
数時間〜数日 |
停止時間ゼロ脚注4（停止が1つの建物に影響を与える場合） 停止が建物に影響を与える場合は数時間〜数日 |
数秒〜1分脚注1 |
数秒〜1分脚注1 |
停止時間ゼロ脚注2 |
|
コンピュータ障害 |
数分〜数時間脚注3 |
数分 |
停止時間ゼロ脚注4 |
数秒〜1分 |
停止時間ゼロ脚注4 |
停止時間ゼロ脚注4 |
|
ストレージ障害 |
停止時間ゼロ脚注5 |
停止時間ゼロ脚注5 |
停止時間ゼロ3 |
停止時間ゼロ3 |
停止時間ゼロ3 |
停止時間ゼロ3 |
|
人的エラー |
30分未満脚注6 |
30分未満脚注6 |
30分未満4 |
30分未満4 |
30分未満4 |
30分未満4 |
|
データ破損 |
数時間（場合によって異なる）脚注7 |
数時間（場合によって異なる）脚注7 |
数時間（場合によって異なる）脚注7 |
数秒〜1分 |
数秒〜1分 |
数秒〜1分 |
脚注1 このリカバリ時間は、データベースおよび既存の接続フェイルオーバーに適用されます。ネットワーク接続は変わり、他のサイト固有のファイルオーバー・アクティビティによって、全体的なリカバリ時間が長くなる場合があります。
脚注2 アプリケーションで、障害のあるシステムに接続されている部分が一時的に影響を受けます。レプリカにフェイルオーバーするように、障害のあるアプリケーション接続を構成できます。
脚注3 リカバリ時間の大部分は、障害のあるシステムのリストアに要する時間です。
脚注4 データベースはそのまま使用できますが、アプリケーションで障害のあるシステムに接続されている部分が一時的に影響を受けます。
脚注5 ストレージ障害は、ミラー化および自動リバランス機能のあるASMを使用して防止されます。
脚注6 人的エラー時のリカバリ時間は、主に検出時間によって異なります。悪意のあるDMLまたはDDLトランザクションの検出に数秒かかった場合、一般に、適切なトランザクションのフラッシュバックには数秒しかかかりません。通常、検出時間が長くなると、適切なトランザクションの修復に必要なリカバリ時間が長くなります。例外は表を元に戻す場合です。この場合は、検出時間にかかわらず、文字どおり即時にリカバリされます。
脚注7 リカバリ時間は、リカバリに使用されるバックアップの古さと、破損データをデータベースに一致させるためにスキャンされるログ変更の回数によって異なります。
表4-5に、あらゆるタイプの計画停止時間に対して各Oracle高可用性アーキテクチャで達成可能なリカバリ時間を示します。
表4-5 計画停止時に達成可能なリカバリ時間
| システム変更またはデータ変更 | 停止タイプ | Oracle Database |
Oracle RAC | Data Guard | MAA | Streams |
|---|---|---|---|---|---|---|
|
システム変更: 動的リソース・プロビジョニング |
-- |
停止時間ゼロ |
停止時間ゼロ |
停止時間ゼロ |
停止時間ゼロ |
停止時間ゼロ |
|
システム変更: ローリング・アップグレード |
システム・レベル・アップグレード |
数分〜数時間 |
停止時間ゼロ |
数秒〜5分 |
停止時間ゼロ |
停止時間ゼロ |
|
システム変更: ローリング・アップグレード |
クラスタまたはサイト全体のアップグレード |
数分〜数時間 |
数分〜数時間 |
数秒〜5分 |
数秒〜5分 |
停止時間ゼロ脚注1 |
|
システム変更: ローリング・アップグレード |
ストレージの移行 |
停止時間ゼロ脚注2 |
停止時間ゼロ2 |
停止時間ゼロ2 |
停止時間ゼロ2 |
停止時間ゼロ2 |
|
システム変更: ローリング・アップグレード |
データベースの個別パッチ |
数分〜1時間 |
停止時間ゼロ脚注3 |
数秒〜5分 |
停止時間ゼロ3 |
停止時間ゼロ |
|
システム変更: ローリング・アップグレード |
データベース・パッチ・セットおよびバージョンのアップグレード |
数分〜数時間 |
数分〜数時間 |
数秒〜5分 |
数秒〜5分 |
停止時間ゼロ1 |
|
システム変更: ローリング・アップグレード |
プラットフォームの移行 |
数分〜数時間 |
数分〜数時間 |
数分〜数時間 |
数分〜数時間 |
停止時間ゼロ1 |
|
データ変更 |
オンライン再編成および再定義 |
停止時間ゼロ |
停止時間ゼロ |
停止時間ゼロ脚注4 |
停止時間ゼロ4 |
停止時間ゼロ4 |
脚注1 メンテナンス中のシステムに接続されているアプリケーション（またはアプリケーションの一部）が一時的に影響を受けます。
脚注2 ASMは、データベースがオンラインのまま、ディスクが追加または削除されると、格納されたデータのリバランスを自動的に行います。ストレージの移行の場合、ASMによって利用されるため、一時的に両方のストレージ・アレイを必要とします。
脚注3 限定された個別パッチの場合のみ
脚注4 DBMS_REDEFINITIONパッケージを使用して、表をオンラインで再編成できます。ただし、オンラインでの変更は、SQL Applyまたはデータ・キャプチャではサポートされていないため、このサブプログラムの影響は、ロジカル・スタンバイ・データベースまたはレプリカ・データベースでは見えません。詳細は、『Oracle Data Guard概要および管理』または『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
Oracle Application Serverでは、Oracle Application Serverの柔軟性のある自動化された高可用性ソリューションが提供され、Oracle Application Serverにデプロイするアプリケーションが必要な可用性を満たしてビジネス目標を実現できます。このマニュアルで説明するソリューションの詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
この項の内容は次のとおりです。
Oracle Application Serverには、あらゆる障害に対する最大の保護を目的とした高可用性および障害時リカバリ・ソリューションがあり、インストール、デプロイメントおよびセキュリティにおける柔軟性の高いオプションが用意されています。Oracle Application Serverのローカルの高可用性および障害時リカバリの冗長性は、その冗長な高可用性アーキテクチャに基づいています。
高度なレベルでは、Oracle Application Serverのローカルの高可用性アーキテクチャには、OracleAS中間層とOracleASインフラストラクチャのアクティブ-アクティブおよびアクティブ-パッシブのアーキテクチャがあります。どちらのソリューションも高可用性を提供しますが、通常、アクティブ-アクティブ・ソリューションの方が、高いスケーラビリティと高速フェイルオーバーを提供します。ただし、費用が高額になる傾向があります。アクティブ-アクティブまたはアクティブ-パッシブのカテゴリでは、インストール、コスト、スケーラビリティおよびセキュリティの容易さが異なる複数のソリューションがあります。
ローカルの高可用性ソリューションをベースに、Oracle Application Serverの障害時リカバリ・ソリューションであるOracle Application Server Guardを構築します。この独自のソリューションでは、Oracle Databaseで実績のあるOracle Data Guardテクノロジとアプリケーション分野の高度な障害時リカバリ・テクノロジを組み合せて、アプリケーション・システム全体の包括的な障害時リカバリ・ソリューションを作成します。このソリューションには同種の本番サイトとスタンバイ・サイトが必要になりますが、障害時リカバリ設定でインスタンスが妨害されなければ、その他のOracle Application Serverインスタンスをどちらのサイトにもインストールできます。2つのサイトが同種性を保つには、構成とデータを定期的に同期化する必要があります。
Oracle Application Serverでは、同じワークロードをサポートする複数のインスタンスをサポートすることにより、冗長性が得られます。このような冗長構成では、ワークロードの分散またはフェイルオーバーの設定のいずれか、またはその両方によって可用性が向上します。
Oracle Application Serverシステムへのエントリ・ポイント（コンテンツのキャッシュ）からバック・エンド層（データ・ソース）まで、リクエストによって交わるすべての層は、Oracle Application Serverを使用して冗長方式で構成できます。この構成は、OracleAS Clusterを使用したアクティブ-アクティブ構成、またはOracleASコールド・フェイルオーバー・クラスタを使用したアクティブ-パッシブ構成のいずれかになります。
Oracle Application Serverでは、そのスタックにまたがって高可用性をサポートする様々な機能やトポロジが提供されます。これには、OracleAS中間層やOracleASインフラストラクチャ層で拡張するソリューションなどがあります。
『Oracle Application Server高可用性ガイド』では、Oracle Application Serverの次の高可用性サービスの詳細について説明しています。
プロセス停止の検出と自動再起動
構成の管理
状態のレプリケーション
サーバーのロード・バランシングおよびフェイルオーバー
バックアップおよびリカバリ
障害時リカバリ
可用性が高く、リジリエンスがあるアプリケーションでは、アプリケーションのすべてのコンポーネントの可用性が高いか、それらのコンポーネントが障害および変更を許容する必要があります。たとえば、可用性の高いアプリケーションは、そのアプリケーションに影響を与えるすべてのコンポーネント（ネットワーク・トポロジ、アプリケーション・サーバー、アプリケーションのフローと設計、システム、およびデータベースの構成やアーキテクチャなど）を分析する必要があります。このマニュアルでは、主にデータベースの高可用性ソリューションに焦点を当てています。
次のMAA WebサイトでOracle Application Server、Enterprise Managerおよびアプリケーションに関する高可用性ソリューションと推奨事項を参照してください。
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
脚注の凡例
脚注1: 単一インスタンス・データベースでは、クラスタ化されたASM（ストレージ・グリッド）またはクラスタ化されていないASMを使用できます。