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

高可用性システムは、実質的に今日のすべてのビジネスの成功に欠かせないものです。それと同様に、これらのミッションクリティカルなシステムを監視する管理インフラストラクチャの可用性が高いことも重要です。Enterprise Manager Grid Controlのアーキテクチャでは、スケーラビリティと可用性の確保が徹底的に図られています。ビジネスをサポートする資産管理に集中する一方で、サービス・レベル合意を満たすように設計されています。

高可用性のGrid Controlを構成する場合の目的は、システムの各コンポーネントと管理データのフローを保護することです。これは、ホストや管理サービスの障害などのパフォーマンスまたは可用性の問題が起きた場合に備えるためです。

最大可用性アーキテクチャ（MAA）では、Enterprise Managerの各コンポーネントの障害を防ぐことにより、高可用性のEnterprise Managerの実装を実現します。

各種Enterprise Managerコンポーネントの障害による影響は次のとおりです。

管理エージェントの障害、または管理エージェントと管理サービス間の通信障害

Enterprise Managerコンソールは引き続き使用できるため、管理リポジトリの履歴データを表示できますが、ターゲットはEnterprise Managerで監視されなくなります。
管理サービスの障害

Enterprise Managerコンソールが使用できなくなり、ほぼすべてのEnterprise Managerサービスが利用できなくなります。
管理リポジトリの障害

管理エージェントでアップロードされたデータを保存するEnterprise Managerの一部に障害が発生し、ほぼすべてのEnterprise Managerサービスが利用できなくなります。

全体として、Enterprise Managerのどのコンポーネントに障害が発生した場合も、サービスが大きく中断する可能性があります。したがって、高可用性アーキテクチャを使用して各コンポーネントを強化することが必須になります。

高可用性の最新情報

技術は急速に変化し、高可用性の実装がOracle Enterprise Managerの範囲を超えて拡張しているため、Oracleの高可用性ソリューションとサードパーティとの統合（F5またはサードパーティ・クラスタウェアなど）に関する最新情報については、次のリソースを定期的に確認する必要があります。

Oracle Maximum Availability ArchitectureのWebサイト

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
サポート・ノート330072.1: 「Grid Controlコンポーネントの高可用性の構成方法」

高可用性の定義

Oracle Enterprise Managerの柔軟性の高い分散アーキテクチャにより、広範囲のデプロイメント構成が可能になるため、ビジネスの監視ニーズと管理ニーズを満たすだけでなく、ビジネス・ニーズの指示に従った拡張が可能になります。

このため、Enterprise Managerの高可用性を単一の実装として範囲を狭めて定義することはできませんが、使用可能なリソース、Oracleテクノロジ、およびITインフラストラクチャへの投資を防止するベスト・プラクティスに基づく保護レベルの範囲で定義できます。Enterprise Managerデプロイメントおよびビジネス・ニーズに応じて、ビジネスの維持に必要な高可用性のレベルを実装できます。Enterprise Managerの高可用性は4つのレベルに分類できます。各レベルは以前の拡大する実装コストや複雑さだけでなく、徐々に増加する可用性のレベルに基づいて決定します。

高可用性のレベル

高可用性ソリューションの各レベルは、ビジネス要件と使用可能なITリソースで左右されます。次の表に、Oracle Enterprise Managerインストールの4つの高可用性レベルをまとめています。

表16-1 Enterprise Managerの可用性レベル

高可用性レベル	ビジネス・ニーズ	ハードウェア要件
レベル1	ビジネス・アプリケーションのイベントに対処します。	適切に調整された、冗長記憶域のある単一インスタンス（1つのホスト） 11.1.0.7 RDBMS + 保護された記憶域
レベル2	ビジネス・アプリケーションのサービス品質を保証できます。	単一サイトでのData Guardを使用したコールド・フェイルオーバー・クラスタ構成レベル1 + Data Guard
レベル3	手動プロセスによる操作上のオーバーヘッドおよび莫大な費用	ローカル・サイトのData Guardを使用するn個のインスタンスによるRAC（制限されたサイト障害に対する保護）レベル2 + RACのプライマリ・サイト
レベル4	主なビジネス・サービスとビジネス・アプリケーションの損失に対する収益の影響	セカンダリ・サイトのData Guardを使用するn個のインスタンスによるRAC（サイト損失に対する保護）レベル3 + リモート・サイトのData Guard

注意:

レベル3と4は本書では扱いません。詳細は、Real Application ClusterおよびDataguardのドキュメントを参照してください。

高可用性ニーズの決定

前述のように、選択した可用性レベルは、利用可能なハードウェア・リソースや組織のビジネス・ニーズなどの要因によって決まります。ただし、高可用性ニーズのあらゆる面（ハードウェア、ビジネス・プロセス、労力、コストなど）を客観的に網羅する方法で高可用性計画を作成するには問題があります。これを解決するには、目標復旧時間（Recovery Time Objective: RTO）および目標復旧ポイント（Recovery Point Objective: RPO）の観点で高可用性ニーズを定義します。

目標復旧時間: 障害後にビジネス・プロセスや技術リソースをリストアできる期間。重要な質問: 純利益が影響を受けるまでにビジネス・プロセス/リソースはどの程度の速さで実行する必要があるのか?
目標復旧ポイント: 障害発生から最後のバックアップまでの期間。重要な質問: どのくらいのデータを解放するのか?

RTOおよびRPOの観点から高可用性ニーズを定義すれば、ユーザーの要求を効率的に満たすことができます。どちらの値も最悪のシナリオを使用して決める必要があります。

RTO、RPO、および可用性レベル

可用性が高いEnterprise Manager環境を実装する際に考慮する必要がある様々な要因がある場合、最終的にはRTO、RPO、およびいずれかの可用性レベルの実装に必要なコストの相互関係を基に決定します。次の表は、これらの要因の相互関係を示しています。

表16-2 高可用性レベルの比較

レベル	RTO	RPO	構築時間	コスト
1	98.0%	数時間	数時間から数日	$
2	98.8%	数分	数時間から数日	$$
3	99.9%	数分から数秒	数日	$$$
4	99.9%	数分から数秒	数日	$$$$

この表は高可用性レベルを選択する際の規定の推奨方法ではありませんが、ビジネス・ニーズに基づく意思決定プロセスに役立ちます。たとえば、稼働時間の要件が95%で、希望の平均修復時間が数秒の場合、レベル4を選択する必要があります。この表には、生存性やスケーラビリティなどの要因は反映されていません。したがって、レベル3と4の外見上の違いはわずかですが、相違があります。プライマリ・サイトの損失時に生存性が必要な場合は、レベル4のアーキテクチャで進める必要があります。サイトの損失時に同等のパフォーマンスが必要な場合は必須になります。DGが非対称的に拡大/縮小されるレベル3のアーキテクチャでは、稼働時のパフォーマンスが低下します。パフォーマンス・レベルを維持する必要がある場合は、アーキテクチャのサイズが両方のサイトで対称的に設定されるレベル4が必要になります。これは特に、プライマリ・サイトまたはセカンダリ・サイトで長時間アクティブに実行するフェイルオーバー・ルーチンを計画して実行する場合に当てはまります。たとえば、一部の金融機関では、操作手順の一環としてこれを義務付けています。