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