22 高可用性ソリューション
高可用性システムは、実質的に今日のすべてのビジネスの成功に欠かせないものです。それと同時に、これらのミッションクリティカルなシステムをモニタリングする管理インフラストラクチャの可用性が高いことも重要です。Enterprise Manager Cloud Controlのアーキテクチャでは、スケーラビリティと可用性の確保が徹底的に図られています。ビジネスをサポートする資産管理に集中する一方で、ビジネスのサービス・レベル合意を満たすように設計されています。
高可用性のCloud Controlを構成する場合の目的は、システムの各コンポーネントと管理データのフローを保護することです。これは、ホストや管理サービスの障害などのパフォーマンスまたは可用性の問題が起きた場合に備えるためです。
最大可用性アーキテクチャ(MAA)では、Enterprise Managerの各コンポーネントの障害を防ぐことにより、高可用性のEnterprise Managerの実装を実現します。
各種Enterprise Managerコンポーネントの障害による影響は次のとおりです。
-
管理エージェントの障害、または管理エージェントと管理サービス間の通信障害
エージェントによってモニターされるターゲットが、Enterprise Managerによってモニターされなくなります。
-
管理サービスの障害
Enterprise Managerが停止します。
-
管理リポジトリの障害
Enterprise Managerが停止します。
-
ソフトウェア・ライブラリの障害
Enterprise Manager操作の一部が使用不可になります。これらの操作には、自己更新、およびエージェント・デプロイメントを含むプロビジョニングとパッチ適用の操作が含まれます。
全体として、Enterprise Managerのどのコンポーネントに障害が発生した場合も、サービスが大きく中断する可能性があります。したがって、高可用性アーキテクチャを使用して各コンポーネントを強化することが必須になります。
ノート:
BI Publisherの高可用性ソリューションの設定方法の詳細は、「BI Publisherの高可用性」を参照してください。
高可用性の最新情報
技術は急速に変化し、高可用性の実装がOracle Enterprise Managerの範囲を超えて拡張しているため、オラクル社の高可用性ソリューションとサードパーティとの統合(F5またはサードパーティ・クラスタウェアなど)に関する最新情報については、次のリソースを定期的に確認する必要があります。
-
次のOracle Maximum Availability ArchitectureのWebサイトを参照してください。
-
Enterprise Manager 13cフレームワークおよびインフラストラクチャに関するWebサイト
HTTP://www.oracle.com/technetwork/oem/frmwrk-infra-496656.html
高可用性の定義
Oracle Enterprise Managerの柔軟性の高い分散アーキテクチャにより、広範囲のデプロイメント構成が可能になるため、ビジネスのモニタリング・ニーズと管理ニーズを満たすだけでなく、ビジネス・ニーズの指示に従った拡張が可能になります。
このため、Enterprise Managerの高可用性を単一の実装として範囲を狭めて定義することはできませんが、使用可能なリソース、Oracleのテクノロジ、およびITインフラストラクチャへの投資を保護するベスト・プラクティスに基づく保護レベルの範囲で定義できます。Enterprise Managerのデプロイメントおよびビジネス・ニーズに応じて、ビジネスの維持に必要な高可用性のレベルを実装できます。Enterprise Managerの高可用性は、4つのレベルに分類できます。各レベルは、これまでの、拡大する実装コストや複雑さだけでなく、徐々に増加する可用性のレベルに基づきます。
高可用性のレベル
高可用性ソリューションの各レベルは、ビジネス要件と使用可能なITリソースで左右されます。しかし、このレベルは、使用可能な様々なオプションを示すのに便利な、可能なデプロイメントのサブセットを表していることに注意することが重要です。IT組織は、いずれかのレベルに正確に一致する必要のない、独自の構成をデプロイする可能性があります。
次の表に、Oracle Enterprise Managerインストールの4つの高可用性レベルの例を、一般的なリソース要件とともにまとめています。
表22-1 Enterprise Managerの高可用性レベル
レベル | 説明 | 最小ノード数 | 推奨ノード数 | ロード・バランサの要件 |
---|---|---|---|---|
レベル1 |
OMSおよびリポジトリ・データベース。それぞれが固有のホストにフェイルオーバーなしで存在する。 |
1 |
2 |
なし |
レベル2 |
共有記憶域にVIPベースのフェイルオーバーありでインストールされているOMS。データベースはローカルのData Guardを使用している。 |
2 |
4 |
なし |
レベル3 |
OMSはアクティブ/アクティブ構成。データベースはRACとローカルのData Guardを使用している。 |
3 |
5 |
ローカル・ロード・バランサ |
レベル4 |
アクティブ/アクティブ構成のプライマリ・サイトのOMS。リポジトリOracle RACを使用してデプロイされている。 スタンバイ・サイトに重複したハードウェアがデプロイされている。 OMSおよびソフトウェア・ライブラリのDRは、プライマリおよびスタンバイ・サイト間の記憶域レプリケーションを使用している。 データベースDRはOracle Data Guardを使用している。 ノート: レベル4はMAAベスト・プラクティスで、最も費用効率が高く、シンプルなアーキテクチャで、最も高い可用性を達成します。 |
4 |
8 |
必須: サイトごとのローカル・ロード・バランサ。 オプション: グローバル・ロード・バランサ |
可用性レベルの比較
次の表で、各HAレベルの保護レベルと復旧時間を比較します。
表22-2 保護の高可用性レベル
レベル | OMSホスト障害 | OMSストレージ障害 | データベース・ホスト障害 | データベース・ストレージ障害 | サイト障害/障害復旧 |
---|---|---|---|---|---|
レベル1 |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
レベル2 |
はい |
いいえ |
はい |
はい |
いいえ |
レベル3 |
はい |
はい |
はい |
はい |
いいえ |
レベル4 |
はい |
はい |
はい |
はい |
はい |
表22-3 高可用性レベルの復旧時間
レベル | ノード障害 | ローカル・ストレージ障害 | サイト障害 | コスト |
---|---|---|---|---|
レベル1 |
数時間から数日 |
数時間から数日 |
数時間から数日 |
$ |
レベル2 |
数分 |
数時間から数日 |
数時間から数日 |
$$ |
レベル3 |
停止なし |
数分 |
数時間から数日 |
$$$ |
レベル4 |
停止なし |
数分 |
数分 |
$$$$ |
この表に示されていない1つの基準はスケーラビリティです。レベル3と4には、ビジネス・ニーズの拡大に応じてEnterprise Managerのインストールを拡大する機能があります。RACデータベースとして実行しているリポジトリは、RACクラスタに新しいノードを追加することで容易に拡張できるので、OMSサーバーを追加するだけで、管理サービス層を拡大することができます。
スタンバイ・デプロイメントへのフェイルオーバー時にパフォーマンスを平準化する必要がある場合は、ローカル・スタンバイ・データベース、またはスタンバイRACデータベースおよびスタンバイOMSサーバーを含むレベル4スタンバイ・サイトのいずれであっても、デプロイメントのサイズが両方のサイトで対称的であることが重要です。これは特に、プライマリまたはセカンダリ・サイトで長時間アクティブに実行する計画フェイルオーバー・ルーチンを実行する場合に当てはまります。たとえば、一部の金融機関では、操作手順の一部としてこれを義務付けています。
プライマリ・サイトの損失時に生存性が必要な場合、レベル4のアーキテクチャで稼働する必要があります。
高可用性レベルの実装
エンタープライズに対し高可用性要件を決定したら、環境に適したいずれかの高可用性レベルの実装を開始する準備ができました。次の情報ロードマップを使用して、各レベルの実装手順を参照します。