高可用性oracle enterprise manager 12c cloud …...高可用性oracle enterprise manager 12c...

Oracleホワイト・ペーパー 2012年5月

高可用性Oracle Enterprise Manager 12c Cloud Controlの配置


製品概要 .............................................................................................................................. 2 はじめに .............................................................................................................................. 2 Cloud Controlアーキテクチャ ............................................................................................. 3 Level 3 MAA設定の実装 ...................................................................................................... 4

Cloud Controlインフラストラクチャ ............................................................................. 6 Cloud Controlインストールの準備 ................................................................................. 7 ステップ1：Oracle Management ServiceサーバーへのCloud Controlのインストール .................................................................................................................. 9 ステップ2：サーバー・ロードバランサ（SLB）の構成 ............................................. 13 ステップ3：Cloud Controlへのリポジトリ・データベース・ターゲットの追加 ........ 19 ステップ4：Oracle Software Libraryの構成 ................................................................ 20 ステップ5：2番目のOracle Management Serviceの追加 ............................................ 20 ステップ6：スタンバイ・データベースの追加 ........................................................... 26 ステップ7：Oracle RACへのスタンバイ・データベースの変換 ................................ 34

結論 ................................................................................................................................... 39


製品概要

オラクルの統合エンタープライズIT管理製品ラインであるOracle Enterprise Managerは、業界初の包括

的なクラウド・ライフ・サイクル管理ソリューションです。Oracle Enterprise Managerが提供するビジ

ネス主導型のIT管理機能を使用すると、アプリケーションからディスクに至るまで、エンタープライズ・

クラウドおよび従来のオラクルのIT環境を簡単に設定、管理、サポートできるようになります。Enterprise

Managerを利用することで、次の利点が得られます。

• ビジネス上の観点から管理を実行することで、Oracle Fusion Applicationsを含む従来型のアプリケー

ションとクラウド・アプリケーションのサービス・レベルを最高レベルへと引き上げます。

• Oracleスタックとエンジニアド・システムに対するインテリジェント管理を実現する最善のソリュー

ションによって、IT管理への投資から最大の収益を得ることができます。

• オラクルのナレッジベースと顧客環境がリアルタイムで統合されているため、比類のない顧客サポー

トが実現されます。

はじめに

Oracle Enterprise Manager Cloud Controlにより、オラクルはシステム管理への独自のアプローチを採用して、

組織が1つのツールおよび緊密に統合された一連の機能を導入して、データセンター内のすべての層なら

びにアプリケーションのライフ・サイクル全体を管理できるようにします。Cloud Controlを使用するこ

とで、組織はアプリケーションのコストを低減すると同時に、サービス品質を劇的に改善できます。

システム管理へのこの独自のアプローチにより、Cloud Controlはデータセンターにおいて、一般的に見受

けられる他の管理ツールよりもはるかに重要な役割を果たします。したがって、Cloud Controlの停止は

ポイント・ソリューション・ツールの停止より多大な影響を及ぼすため、多くのCloud Controlの配置で

高可用性が重要な要件となります。Cloud Controlを利用できなくなると、管理者はビジネス・クリティ

カルなアプリケーションの状態を把握できないだけでなく、日常的なタスクの多くを実行できなくなり

ます。

Cloud Controlの配置には幅広いコンポーネントが含まれており、高可用性インストールでは各コンポー

ネントを考慮する必要があります。このことは、高可用性実装の全体的な配置アーキテクチャに多くの

可能性をもたらします。このホワイト・ペーパーでは、Maximum Availability Architecture（MAA）Level 3構成での高可用性Cloud Controlの設定に必要なステップを詳細に説明します。この構成は、パフォーマ

ンスと可用性を維持しながら、コストを抑制します。ステップには多数のベスト・プラクティスの推奨

事項が含まれており、構成を構築する際の全体的な配置ステップ数と再構成が最小限で済む順序になっ

ています。設定ステップでは、自動プロセスを可能な限り利用することで、Cloud Controlの設定にかか

る時間をさらに短縮し、人的エラーのリスクを最小限に抑えます。

2


Cloud Controlアーキテクチャ

Cloud Controlは、データセンターの監視と管理の中心点になります。これを達成するには、さまざまな

分散コンポーネントから情報を収集し、一元化リポジトリに統合します。Cloud Controlが適切に動作す

るには、これらのコンポーネントすべてが協調して動作する必要があります。この情報の収集、処理、

および提示に関わるコンポーネントと情報のフローは次のようになります。

• Oracle Management Agent（エージェント） – Oracle Management Agentは、社内の各監視対象ホスト

にインストールされるソフトウェア・コンポーネントです。エージェントは、ホスト上で稼働する

ターゲットから情報を収集し、この情報をOracle Management Serviceに送信します。エージェントは、

Cloud Controlユーザーの代わりにターゲットへの処理も実行します。Cloud Controlが管理できるター

ゲットの種類は多数あります。その例として、ホスト、データベース、リスナー、Oracle Automatic Storage Management（Oracle ASM）、Oracle WebLogic Server、サービス・バス、およびOracle Fusion Applicationsのコンポーネントがあります。

• Oracle Management Service – Oracle Management Serviceは、Cloud Controlの中心的なコンポーネント

であり、他のすべてのコンポーネントとやり取りします（図1を参照）。 Oracle Management ServiceはOracle WebLogic Server上に配置されます。エージェントがデータをアッ

プロードし、管理者がCloud Controlコンソールにアクセスできるように、Oracle Management Serviceは利用可能になっている必要があります。

• Oracle Management Repository（リポジトリ） – Oracle Management Repositoryは、永続データ・スト

アとして使用されます。リポジトリに保管される情報には、ユーザー情報、ジョブ定義、監視とア

ラートの設定、全構成、ターゲットに関わる監視データがあります。Oracle Management Repositoryは、

利用可能なリポジトリに依存しているため、リポジトリが利用できないと、Cloud Controlを実行でき

ません。

• Oracle Software Library – Oracle Software Libraryは、ソフトウェア・パッチ、仮想アプライアンス・

イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェア、およびアプリケーション・

ソフトウェアに関連するディレクティブ・スクリプトなどのソフトウェア・エンティティを保管する

ファイル・システム・リポジトリです。Oracle Software LibraryはOracle Management Serviceによって

アクセスされ、自己更新やエージェントプッシュなどの機能のために、Cloud Controlフレームワーク

によって幅広く使用されます。

• コンソール – コンソールは、Cloud Controlのメイン・ユーザー・インタフェースとして機能するブラ

ウザ・ベースのWebアプリケーションです。管理者はこのコンソールにより、設定されたCloud Controlターゲットを監視、管理、およびレポートします。

• Oracle Enterprise Manager Command Line Interface（Oracle EMCLI） – ユーザーはOracle EMCLIを使用して、コマンドラインからインタラクティブに、またはスクリプトの一部として、Cloud Control機能にアクセスできます。その結果、ユーザーが操作しなくても、Cloud Controlの処理を複雑なビジ

ネス・プロセスに組み込むことができます。

3


図1：Cloud Controlの主要コンポーネント

Level 3 MAA設定の実装

構成オプションには多くの種類があり、構成オプションによってCloud Controlシステムが実現する可用性

が決まります。高可用性Cloud Controlの実装を設計する際には、各層について考慮する必要があります。

システム全体を機能させるには、すべての層が利用可能で、連携する必要があるためです。

高可用性Cloud Control実装の設計を簡素化するための4つの基本構成レベルをCloud Controlのドキュメン

トで説明しています。これらの4つの構成は、Level 1からLevel 4へと進み、レベルが上がるごとに可用性

が向上します。Level 1の場合、Oracle Management Serviceとデータベースが1つずつしかなく、冗長コン

ポーネントが構成されていないため、計画停止または計画外停止からの保護が最小限になります。した

がって、Oracle Management Serviceまたはリポジトリのいずれかに障害が発生すると、コンポーネントが

復旧するまでシステムを利用できなくなります。これとは対照的に、Level 4の場合、複数の物理的な場

所に設置した冗長コンポーネントを使用することで、はるかに高いレベルの保護が実現されます。次の

表に、可用性のレベルを簡単にまとめます。

レベル

サイト

説明

ロードバランサの要件

1 単一サイト Oracle Management Serviceとリポジトリのホストが単一サイト上に構成され

る。それぞれが自身のホスト上に存在し、フェイルオーバーはなし。

なし

2 単一サイトアクティブ/パッシブ・モードで共有ストレージにOracle Management Service

のペアがインストールされ、VIPベースのフェイルオーバーが実行される。

リポジトリ・ホストでローカル・フィジカル・スタンバイ・データベースが構成される。

なし

3 単一サイト複数のOracle Management Serviceがサーバー・ロードバランサ（SLB）ととも

にアクティブ/アクティブ構成で配置される。

ローカル・ロード

バランサ

4


Oracle RACプライマリ・データベース

Oracle RACフィジカル・スタンバイ・データベース（プライマリ・データベー

スと同じサイト）

4 マルチサイトアクティブ・コンポーネントがプライマリ・サイト上に配置される。

アクティブ/アクティブ構成のプライマリOracle Management Serviceとサー

バー・ロードバランサ（SLB）

Oracle RACプライマリ・データベース

必須：

各サイトにローカ

ル・ロードバランサ

オプション：

グローバル・ロード

バランサ

すべてのスタンバイ・コンポーネントがパッシブ・モードでスタンバイ・サイ

トに配置される。スタンバイ・サイトのコンポーネントは、スイッチオーバー/

フェイルオーバーの後にのみアクティブになる。

複数のスタンバイOracle Management Serviceでサーバー・ロードバランサ

（SLB）が構成される。

Oracle RACフィジカル・スタンバイ・データベース

このドキュメントでは、Level 3 MAA設定の実装について説明します。この構成は、単一サイト内で非常

に高いレベルの保護を実現します。

次の図は、Level 3構成を示します。図に示すように、この構成は、ローカルのサーバー・ロードバランサ

（SLB）によってアクセスされる複数のOracle Management Service、およびOracle Real Application Clusters（Oracle RAC）を使用するリポジトリ・データベースからなります。Oracle Management Service層とリポ

ジトリ層の間の待機時間が長くなると、Cloud Controlの全体的なパフォーマンスに影響が及ぶため、リ

ポジトリとアクティブなOracle Management Serviceを互いに近い場所に配置することを推奨します。 Level 3構成には複数のアクティブなOracle Management Serviceとリポジトリ・サーバーがあるため、デー

タベース・ホストまたはOracle Management Serviceホストのいずれかに障害が発生しても、可用性が持続

します。さらに、Level 3構成では、Oracle Data Guardスタンバイ・データベースを利用します。このスタ

ンバイ・データベースは、データベース記憶域に障害が発生したときに、データベース層を保護します。

Level 3構成の場合、サイト障害は保護されない点に留意してください。サイト障害の保護が必要な場合

は、Level 4の設定を検討してください。

5


図2：Cloud Control Level 3 MAA配置

可用性の各種レベルについて詳しくは、『Enterprise Manager Cloud Control』のドキュメントを参照して

ください。

Cloud Controlインフラストラクチャ

このCloud Controlインストールの設定に使用するハードウェアは次のとおりです。

• プライマリ・リポジトリDB用のLinuxクラスタ×2ノード

• スタンバイ・リポジトリDB用のLinuxクラスタ×2ノード

• Oracle Management Service用のLinuxサーバー×2

• F5 SLB

• Oracle Software Library用のNFSストレージ・サーバー

6


上記の構成を構築するためのステップを次のフローチャートに示します。

Cloud Controlインストールの準備

実装の前に、Oracle Management Serviceとリポジトリのノードで準備ステップを実行する必要があります。

これらのステップは次のとおりです。

データベース・クラスタの準備

Level 3 Cloud Controlの実装前に行う最初のステップは、プライマリおよびスタンバイ・データベース・

クラスタを構成することです。このドキュメントの手順では、プライマリ・クラスタとスタンバイ・ク

ラスタがすでに構成済みであることを前提とします。

Level 3の設定では、スタンバイ・クラスタをプライマリ・クラスタと同じサイトに配置します。スタン

バイ・クラスタは、プライマリ・データベース・クラスタ全体の障害を保護します。スタンバイ・デー

タベース環境をプライマリ環境と同じハードウェアで構成することにより、スタンバイへのフェイルオー

バー時にCloud Controlを最大限の能力で稼働できます。

2つのクラスタを次のように構成します。

• プライマリ・クラスタとスタンバイ・クラスタの両方でOracle Enterprise Linux 5.6（x86-64）を稼働

• Oracle Clusterware 11g Release 2（11.2）バイナリをプライマリ・クラスタとスタンバイ・クラスタ

にインストールして構成

• Oracle Database 11g Release 2（11.2）バイナリをプライマリ・クラスタとスタンバイ・クラスタに

インストール

7


• SCANリスナーをプライマリ・クラスタとスタンバイ・クラスタに構成

• emrep1とemrep2のプライマリ・システム名でクラスタemrep-clを形成

• emreps1とemreps2のスタンバイ・システム名でクラスタemreps-clを形成

オラクルのベスト・プラクティスに従って、プライマリ・クラスタとスタンバイ・クラスタのそれぞれ

に、共有データベース記憶域用のASMディスクを構成します。

'DATA'（データ）および'FRA'（ファスト・リカバリ領域）のASMディスク・グループをプライマリ・ク

ラスタとスタンバイ・クラスタに構成して、利用できるようにします。基盤となるストレージ・ハード

ウェアで冗長性をサポートするため、オラクルのベスト・プラクティスに従って、これらに外部冗長性

を構成します。

クライアント接続用にSingle Client Access Name（SCAN）を使用するため、Oracle Database 11g Release 2を使用します。可能な場合、SCANアドレスの使用を推奨します。SCANアドレスを使用すると、Oracle Management Serviceデータベース接続を再構成しなくても、データベース・クラスタ・ノードを追加およ

び削除できます。

Single Client Access Nameについて詳しくは、『Oracle Database 11g リリース2 Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

リポジトリ・データベースの準備

Cloud Controlのインストール中、Cloud Controlリポジトリとして使用するデータベースを指定するように

インストーラによって指示されます。計画した構成でOracle RACデータベースをリポジトリとして使用す

る場合、Oracle RACデータベースを作成してから、Cloud Controlをインストールすることを推奨します。

単一のインスタンス・データベースを使用してインストールした後でOracle RACに変換する場合とは逆

に、このアプローチでは、全体的なステップおよび構成を完了する所要時間が短縮されます。

プライマリCloud Controlリポジトリとして使用する、'emrep'という名前のデータベースをプライマリ・

データベース・クラスタ上に作成します。このデータベースはemrep1インスタンスとemrep2インスタン

スから成ります。データファイル、REDOロゴ、および制御ファイルは'DATA'共有ASMディスク・グルー

プに配置します。

『Enterprise Manager Cloud Control Basic Installation Guide』で指定された要件を満たすことに加えて、

ARCHIVELOGモードでデータベースを構成し、フラッシュバック・データベースを有効にします。デー

タベースの作成時にこれらのオプションを有効にすることを推奨します。この時点でオプションを有効

にすると、後でスタンバイ・データベースを作成および管理するときに、データベースを再構成する必

要がなくなります。

Oracle RAC上のリポジトリ・データベース作成の前提条件の情報と推奨事項について詳しくは、次のド

キュメントを参照してください。

• Oracle Clusterware管理およびデプロイメント・ガイド

• Oracle Real Application Clusters管理およびデプロイメント・ガイド

• Automatic Storage Management管理者ガイド

• Enterprise Manager Cloud Control基本インストレーション・ガイド

• 『Oracle Enterprise Manager Cloud Control 12c Sizing Guidelines』

8

http://docs.oracle.com/cd/E16338_01/rac.112/b56290/toc.htm




http://docs.oracle.com/cd/E16338_01/server.112/b61035/toc.htm

http://docs.oracle.com/cd/E26854_01/install.12101/b65084/toc.htm

http://www.oracle.com/technetwork/oem/framework-infra/em12c-sizing-1590739.pdf


Oracle Management Serviceノードの準備

Cloud Controlソフトウェアのインストール前に完了する必要のある最終ステップは、Oracle Management Serviceノードを準備することです。

高可用性Oracle Management Service層を作成する際に、複数の管理サービスを構成する必要があります。

Linuxサーバー2台をOracle Management Serviceサーバーとして使用します。これらのサーバーは、次のよ

うに構成します。

• 両方のサーバーでOracle Enterprise Linux 5.6（x86-64）を稼働

• システム名をoms1およびoms2と命名

• 両サーバーからアクセス可能なNFSの場所を構成し、/cc12_SWLibとしてマウント

Oracle Management Serviceの要件について詳しくは、Enterprise Manager Cloud Control基本インストレー

ション・ガイドを参照してください。

データベース・クラスタとOracle Management Serviceノードの準備が完了したら、Oracleインストーラを

使用して、Cloud Controlのインストールを開始できます。

ステップ1：Oracle Management ServiceサーバーへのCloud Controlのインストール

Cloud Controlのインストールは、Oracle Management Serviceサーバーとして構成される最初のノードから

開始します。

この例では、インストール・メディアをステージングし、oms1というホストでインストーラを開始します。

ここでは、拡張インストールを使用して、新しいOracle Enterprise Manager Systemを作成することを選択

します。Middlewareホームを/u01/Middlewareとして指定します。これは、Oracle Management Serviceホスト

の空のディレクトリです。

ステップ5の時点では、追加のプラグインはインストールしません。ステップ6では、Oracle WebLogicドメインとノード・マネージャのパスワードを指定します。

ステップ6では、Oracle WebLogicドメインとノード・マネージャのパスワードを指定します。

9




ステップ7では、作成したリポジトリ・データベースのログイン資格証明を指定します。データベース・

ホストの1つを指定し、service/SIDを'emrep'と指定します。

ヒント：ステップ7でクラスタ・データベース・インスタンスを入力すると、データベース接続文字列を

変更するように指示されます。Oracle Database 11g Release 2を使用している場合は、変更を指示されたら、

SCANアドレスを使用する接続文字列を指定することを推奨します。データベースへの接続にSCANアド

レスを使用することで、Oracle Management Serviceが使用する接続文字列を後で変更しなくても、Oracle RACクラスタでノードを追加または削除できます。

Oracle Database 11g Release 2でクラスタ・データベースを使用しているため、次に示すように接続文字列

を変更して、SCANアドレスを指定します。 (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = emrep-cl-scan.example.com)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = emrep)

))

ステップ9のリポジトリ構成の詳細では、Management Tablespace、Configuration Data Tablespace、および

JVM Diagnostics Data Tablespaceの場所として、以前作成したASMディスク・グループを指定します。

10


このOracle Management Serviceのポートを指定するようメッセージが表示されたら、Oracle Management Serviceホストとして使用する他のサーバー上でも空いているポートを指定することを推奨します。そう

すると、後のロードバランサの設定が容易になります。

ステップ10では、インストール・プロセス中に次のようにポートを構成します。

これらのポートのうち、次のポートが後のSLB構成で関連します。

• Enterprise Manager Upload HTTP Port：4889

• Enterprise Manager Upload HTTP SSL Port：4900

• Enterprise Manager Central Console HTTP Port：7788

• Enterprise Manager Central Console HTTP SSL Port：7799

インストールが完了すると、Cloud Controlへのアクセス方法を示すサマリー画面が表示されます。この

画面に表示される情報はメモしておいてください。

11


インストールの直後に、Oracle Management Serviceの初期構成を検証して、セキュリティ設定、使用され

るポート、ロードバランサの設定といった構成の詳細を決定する必要があります。

それには、Oracle Management Serviceサーバーから"emctl status oms –details"コマンドを実行します。

$ ./emctl status oms -details Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0 Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved. Enter Enterprise Manager Root (SYSMAN) Password : Console Server Host : oms1.example.com HTTP Console Port : 7788 HTTPS Console Port : 7799 HTTP Upload Port : 4889 HTTPS Upload Port : 4900 OMS is not configured with SLB or virtual hostname Agent Upload is locked. OMS Console is locked. Active CA ID:1 Console URL: https://oms1.example.com:7799/em Upload URL: https://oms1.example.com:4900/empbs/upload WLS Domain Information Domain Name : GCDomain Admin Server Host:oms1 Managed Server Information Managed Server Instance Name:EMGC_OMS1 Managed Server Instance Host:oms1.example.com

Oracle Management Serviceアプリケーション・トラフィックには、ブラウザとOracle Management Service間のトラフィック（Cloud Controlにアクセスするユーザーが作り出すブラウザ・トラフィック）、および

エージェントとOracle Management Service間のトラフィック（自身のデータをOracle Management Serviceにアップロードするエージェントが作り出すトラフィック）が含まれます。ブラウザとOracle Management Service間のトラフィック、およびエージェントとOracle Management Service間のトラフィックは、HTTPまたはHTTPSのいずれかを使用するように構成できます。

Cloud Controlコンポーネント間で安全な通信を確保するには、すべてのエージェントとOracle Management Service間のトラフィック、およびブラウザとOracle Management Service間のトラフィックでHTTPSを使用

することを推奨します。

上記の出力は、Agent UploadとOracle Management Serviceのコンソール・ポートがロックされているため、

HTTPSを使用していることを示しています。その場合、これ以上処理を実行する必要はありません。ま

た、この出力は、現在、Oracle Management ServiceがSLBまたは仮想ホスト名で構成されていないことも

示しています。Console URLとUpload URLは、アプリケーションへのアクセスが、Oracle Management Serviceのインストール先である物理ホスト（oms1）から直接行われることを示しています。

データベース・サーバーに接続するためにOracle Management Serviceによって使用されるリポジトリ接続

文字列を、"emctl config oms –list_repos_details"コマンドを使用してチェックすることを推奨します。

$ ./emctl config oms -list_repos_details Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0 Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved.

12

https://oms1.example.com:7799/em

https://oms1.example.com:4900/empbs/upload


Repository Connect Descriptor : (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=emrep-cl- scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=emrep))) Repository User :SYSMAN

上記の出力は、Oracle Management Serverの初期インストールの使用中に指定されたSCANアドレスを示し

ます。

Oracle Management Serviceが適切に動作していることを最終的に検証するには、Cloud Controlにログイン

します。この例では、次のURLを使用します。


ステップ1の後、Cloud Controlトポロジは次のようになります。

図3：最初のOracle Management Serviceのインストール後のCloud Controlトポロジ

上の図に示すように、リポジトリ層はOracle RACの使用によってノード障害から保護されていますが、

Oracle Management Serviceノードが失われると、アプリケーションはノードが復旧されるまで利用できな

くなります。

ステップ2：サーバー・ロードバランサ（SLB）の構成

上に示すように、最初のOracle Management Serviceのインストールでは、Cloud Controlのユーザーとエー

ジェントが物理ホスト名を使用してOracle Management Serviceに直接接続できるようにシステムを構成し

ます。高可用性Cloud Controlの構成では、複数のOracle Management Serviceサーバーが存在し、ユーザー

とエージェントは、利用可能な管理サービスにトラフィックを送信できるロードバランサを介してOracle Management Serviceに接続できる必要があります。

最初のOracle Management Serviceのインストール直後に、SLBを構成する必要があります。

この例のSLBは、11.1.0, Build 1943.0 Finalを実行するF5 BIG-IPローカル・トラフィック・マネージャです。

このOracle Management Serviceは、コンソールとアップロード・トラフィックのセキュリティのためだけ

に構成されるため、Secure UploadサービスとSecure ConsoleサービスのみをSLBに構成します。

13



SLB設定では次を構成します。

• ヘルス・モニター

• TCPプロファイル

• プール

• 永続化プロファイル（コンソール・サービスのみ）

• 仮想サーバー

また、クライアント・リクエストがIPアドレスではなくホスト名を参照できるように、仮想サーバーIPアドレスとホスト名（oms.example.com）をDNSサーバーに登録します。

次の表に、SLB設定中に作成されたF5オブジェクトをまとめます。

Cloud Control サービス

TCP ポート

モニター名

永続性

プール名

ロードバランシング

仮想サーバー名

仮想サーバー・ポート

Secure Upload 4900 mon_ccsu4900 なし pool_ccsu4900 ラウンド・ロビン vs_ccsu4900 4900

Secure Console 7799 mon_ccsc7799 ソースIP pool_ccsc7799 ラウンド・ロビン vs_ccsc443 443

ステップ2.1：ヘルス・モニターの作成

ヘルス・モニターは、設定された間隔でサービスの状態を継続的にチェックします。チェックされてい

るサービスが指定のタイムアウト時間内に応答しない場合、またはサービスの状態にパフォーマンスの

低下が示されている場合、サービスは自動的にプールから取り出されて、プールの他のメンバーが選択

されます。

ヘルス・モニターは、次の表の設定を使用して構成されます。

Cloud Controlサービス

TCPポートモニター名種類間隔

タイムアウト

送信文字列受信文字列

Secure Console

7799

mon_ccsc7799

https

5

16

GET /em/console/home HTTP/1.1¥r¥nHost: ¥r¥nConnection:Close ¥r¥n¥r¥n

/em/login.jsp

Secure Upload

4900

mon_ccsu4900

https

60

181

GET /empbs/upload ¥r¥n

Http Receiver Servlet active!

ステップ2.2 TCPプロファイルの作成

TCPプロファイルは、Cloud Controlトラフィックの動作を制御するために作成します。

2つのTCPプロファイルを作成します。1つはSecure Consoleサービス用、1つはSecure Uploadサービス用です。

これらは、TCPプロファイルのデフォルト設定で作成します。

14


図4：セキュア・コンソール用のTCPプロファイルの作成

ステップ2.3 プールの作成

プールは、ロードバランシング方式を使用して、特定のTCPポートでトラフィックを受信するためにグ

ループ化された一連のサーバーです。各プールには、永続性定義の独自の特性、使用されるロードバラ

ンシング・アルゴリズムがあります。すべてのCloud Controlプールのロードバランシング・アルゴリズ

ムで優先される設定は、Least Connections (Member)です。

次に示すように、プールをロードバランサ上に作成します。


プール名

関連付けられたヘルス・モニター

ロードバランシング

メンバー

Secure Console pool_ccsc7799 mon_ccsc7799 Least Connections (member) oms1.example.com:7799 oms2.example.com:7799

Secure Upload pool_ccsu4900 mon_ccsu4900 Least Connections (member) oms1.example.com:4900 oms2.example.com:4900

oms2はまだ構成されていませんが、2番目のOracle Management Serviceホストをこの時点でサーバー・プー

ルに追加することを推奨します。そうすることで、2番目のOracle Management Serviceのインストール後に

SBL構成を変更する必要がなくなります。

ステップ 2.4 コンソール永続化プロファイルの作成

特定のセッションに対するすべてのCloud Controlユーザー・リクエストが、セッション全体で同じ管理

サービスに送られるようにするには、コンソール永続化プロファイルが必要です。このような永続化プ

ロファイルがないと、ユーザー・セッションは複数のOracle Management Serviceにまたがり、Cloud Controlユーザーは何度もログインする必要が生じます。

次の属性を備えた永続化プロファイルを作成します。


F5永続化プロファイル名種類タイムアウト有効期限

Secure Console sourceip_ccsc7799 Source Address Affinity

3600 適用外

15


図5：Secure Consoleの永続化プロファイルの作成

ステップ2.5 仮想サーバーの作成

ロードバランサ構成の最終ステップでは、仮想サーバーを定義します。仮想IPアドレスとポート番号を

持つ仮想サーバーは、クライアントのアドレス可能なホスト名またはIPアドレスであり、これにより、

クライアントはロードバランシング・プールのメンバーを利用できるようになります。仮想サーバーは

リクエストを受信すると、選択されたロードバランシング方式に基づいてリクエストをプールのメンバー

に送信します。

次の表の設定を使用して、Secure ConsoleサービスとSecure Uploadサービス用の仮想サーバーを作成します。


仮想サーバー名

仮想IPとポート

プロトコル・プロファイル

（クライアント）

HTTP プロファ

イル

SNATプール

iRULE デフォルト・プール

デフォルトの永続化プロファイル

Secure Console

vs_ccsc443 <仮想ホストIP>:443

tcp_ccsc 7799

なし自動なし pool_ccsc 7799

sourceip_ ccsc7799

Secure Upload

vs_ccsu4900 <仮想ホストIP>:4900

tcp_ccsu 4900

なし自動なし pool_ccsu 4900

なし

ステップ2.6：Oracle Management Service構成の更新

SLB設定の完了後、SLBホスト名を使用してOracle Management Serviceを再度セキュリティ設定する必要が

あります。

emctl secure oms -sysman_pwd <sysman_pwd> -reg_pwd <agent_reg_password> -host oms.example.com -secure_port 4900 -slb_port 4900 -slb_console_port 443

16


-console -lock -lock_console

Oracle Management Serviceはこのコマンドの実行後、再起動します。

"emctl status –details"出力は、Oracle Management ServiceがSLBに対して構成されていることを示しています。

$ ./emctl status oms -details Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0 Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved. Enter Enterprise Manager Root (SYSMAN) Password : Console Server Host : oms1.example.com HTTP Console Port : 7788 HTTPS Console Port : 7799 HTTP Upload Port : 4889 HTTPS Upload Port : 4900 SLB or virtual hostname:oms.example.com HTTPS SLB Upload Port : 4900 HTTPS SLB Console Port : 443 Agent Upload is locked. OMS Console is locked. Active CA ID: 1 Console URL: https://oms.example.com:443/em Upload URL: https://oms.example.com:4900/empbs/upload WLS Domain Information Domain Name : GCDomain Admin Server Host: oms1.example.com Managed Server Information Managed Server Instance Name: EMGC_OMS1 Managed Server Instance Host: oms1.example.com

上記の出力は、Console URLとUpload URLがOracle Management Serviceの物理ホストではなく、SLBを参照

していることを示しています。

SLBは構成されましたが、以前Oracle Management Serviceに配置されたエージェントは引き続き、最初の

Oracle Management Serviceサーバーの物理ホスト名にアップロードしています。このことは、"emctl status agent"コマンドの出力から判別できます。

$ ./emctl status agent Oracle Enterprise Manager 12c Release 1 12.1.0.1.0 Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved. --------------------------------------------------------------- Agent Version : 12.1.0.1.0 OMS Version : 12.1.0.1.0 Protocol Version : 12.1.0.1.0 Agent Home : /u01/Middleware/agent/agent_inst Agent Binaries : /u01/Middleware/agent/core/12.1.0.1.0 Agent Process ID : 15661

17

https://oms.example.com/em

https://oms.example.com:4900/empbs/upload


Parent Process ID :15594 Agent URL : https://oms1.example.com:3872/emd/main/ Repository URL : https://oms1.example.com:4900/empbs/upload Started at : 2012-02-09 06:48:14 Started by user : oraha Last Reload : (none) Last successful upload : 2012-02-21 19:58:44 Last attempted upload : 2012-02-21 20:02:04 Total Megabytes of XML files uploaded so far :182.23 Number of XML files pending upload : 1,488 Size of XML files pending upload(MB) : 24.28 Available disk space on upload filesystem : 57.28% Collection Status : Collections enabled Last attempted heartbeat to OMS : 2012-02-23 05:25:48 Last successful heartbeat to OMS : 2012-02-21 20:00:49 --------------------------------------------------------------- Agent is Running and Ready

このエージェントがSLBを介してアップロードを開始するように、SLBホスト名を使用してエージェント

に再度セキュリティを設定します。

emctl secure agent –emdWalletSrcUrl https://oms.example.com:4900/em

エージェントにセキュリティを再設定した後、"emctl status agent"出力のRepository URLには、最初のOracle Management Serviceサーバーのホスト名ではなく、SLBホスト名が反映されます。

最終ステップでは、物理的なOracle Management ServiceではなくSLBを使用して、ブラウザからCloud Controlに接続可能になったことをクライアントに伝えます。


Oracle EMCLIもこの時点で、SLBを介して接続できるように再構成する必要があります。それには、次

のコマンドを使用します。

emcli setup -url=https://oms.example.com/em -username=em_user

Oracle EMCLIの構成について詳しくは、Enterprise Managerコマンドライン・インタフェースを参照して

ください。

18

https://oms1.example.com:3872/emd/main/

https://oms1.example.com:4900/empbs/upload

https://oms.example.com:4900/em



http://docs.oracle.com/cd/E26854_01/em.121/b70512/toc.htm


SLB設定の完了後、Cloud Controlトポロジは次のようになります。

図6：ロードバランサ構成後のCloud Controlトポロジ

図に示すように、エージェントとクライアントはロードバランサを介して接続し、通信します。

Cloud ControlとF5ロードバランサの構成について詳しくは、オラクル/F5のホワイト・ペーパー『Configuring OMS High Availability with F5 Big-IP Local Traffic Manager』を参照してください。

ステップ3：Cloud Controlへのリポジトリ・データベース・ターゲットの追加

Cloud Controlのインストール後、リポジトリ・データベース用に使用するOracle RACホストは、Cloud Controlターゲットとして表示されなくなります。Cloud Control環境にこれらのホストを追加するには、

それぞれエージェントをインストールする必要があります。エージェントをインストールするには、

「Setup」→「Add Target」→「Add Targets Manually」にナビゲートして、Add Host Targetsウィザード

を使用します。

リポジトリ・ホストの追加後、「Targets」→「Databases」にナビゲートし、Add Targetウィザードを使用

して、リポジトリ自体をデータベース・ターゲットとして追加できます。このフローの一部として、プラ

イマリ・データベース・ターゲットのクラスタ・ターゲットも追加するようメッセージが表示されます。

19

http://www.oracle.com/technetwork/oem/framework-infra/wp-em12c-config-oms-ha-bigip-1552459.pdf


ステップ4：Oracle Software Libraryの構成

高可用性Cloud Controlのインストールでは、管理サービスとして使用する各ホストからOracle Software Libraryにアクセスできる必要があります。Oracle Software LibraryはCloud Controlインフラストラクチャの

重要な部分であるため、配置先のファイル・システムには高可用性が備わっている必要があります。Oracle Software Library用に使用できるファイル・システムは、NFS、OCFS2、およびACFSです。

この例のインストールでは、Oracle Software Libraryを高可用性NFSファイル・システムに配置します。次

に、mountpoint /cc12_SWLibを使用して、このNFSファイル・システムを最初のOracle Management Serviceにマウントします。また、この時点で、同じマウント・ポイントを使用して、ファイル・システムを

oms2にマウントします。

「Setup」→「Provisioning and Patching」→「Software Library」にナビゲートして、Cloud Controlコン

ソールからOracle Software Libraryを構成します。

NFSファイル・システム上のcc12_SWLibというOracle Management Service共有ファイル・システムを追加

することで、Oracle Software Libraryの場所を構成します。

ステップ5：2番目のOracle Management Serviceの追加

Cloud Controlで標準の配置手順を実行して、Oracle Management Serviceを追加します。配置手順により、

共通のプロビジョニング操作とパッチ操作が自動化されます。配置手順は、Cloud Controlコンソールか

ら編成および管理します。

次のステップでは、"Add Management Service"の配置手順を実行するために従う手順について説明します。

ステップ5.1：2番目のOracle Management Serviceサーバーへのエージェントのインストール

新しいOracle Management Serviceサーバーで配置手順を実行可能にするには、Cloud Controlエージェント

をサーバーに配置する必要があります。それには、ステップ3でエージェントをデータベース・リポジト

リ・サーバーに配置したときと同じ手順を使用します。

「Setup」→「Add Target」→「Add Targets Manually」に移動して、Add Host Targetsのガイド付きワー

クフローを使用し、Oracle Enterprise Managerエージェントのインストールを完了します。

20


ステップ5.2："Add Management Service"の配置手順を使用した2番目のOracle Management Serviceの追加

"Add Management Service"の配置手順は標準搭載されています。ターゲット管理サービス・ホストで一連

の前提条件チェックを実行し、2番目のOracle Management Serviceを追加するプライマリ管理サービスの

クローンを実行します。

配置手順を実行する前に、「Self Update」に移動してProvisioning Bundle Updatesをチェックすることで

（「Setup」→「Extensibility」→「Self Update」）、最新バージョンの配置手順を実行していることを確

認します。この操作により、適用する必要のある保留中の更新がなく、最新バージョンの配置手順を実

行していることが分かります。

最新バージョンを使用していることを確認したら、「Enterprise」→「Provisioning and Patching」→「Procedure Library」にナビゲートし、「Add Management Service Deployment Procedure」を選択する

と、配置手順にアクセスできます。

「Launch」ボタンをクリックして、配置手順を実行します。

21


配置手順では、新しい管理サービスを追加するためのガイド付きワークフローが示されます。配置手順

では、Oracle Software Libraryやロードバランサの構成の完了など、前提条件について確認するよう指示

されます。前にステップでこれらすべてのタスクを実行してあるので、設定が済んだことを確認する

ボックスを選択します。

インストーラ・ウィザードの次のステップでは、2番目のOracle Management Serviceの宛先ホストとイン

ストール場所を指定するよう指示されます。また、このステップでは、ソース・サーバー（最初の

Oracle Management Serviceホスト）とターゲット・サーバー（新しいOracle Management Serviceホスト）

のログイン資格証明の指定も必要です。このステップのホスト名付き資格証明の一部を設定し、使用し

ます。1

1 名前付き資格証明を使用すると、Oracle Enterprise Manager内で資格証明を保存および共有できます。保存された資格

証明は、ユーザー名/パスワードの組合せまたはパブリック/プライベート・キーのペアです。

22


次のページでは、ソース・サーバーから宛先サーバーにファイルを転送する方法を指定します。NFSアクセス用に構成した共有ファイル・システムがあるため、「Shared Directory」オプションを選択し、

NFSの場所をShared Directory Pathに指定します。共有ディレクトリを使用するため、このステップでは

ソースおよびターゲット・ステージングの場所を指定する必要はありません。

また、新しいOracle Management Serviceのポートも指定する必要があります。SLB構成を簡素化するため、

2番目のOracle Management Serviceのポートを最初のOracle Management Serviceで構成したポートと同じに

することを推奨します。

23


最後に、2番目のOracle Management Serviceを追加した後で、SLBで完了する必要のあるステップについての

指示があります。2番目のOracle Management Serviceの詳細がSLM構成で指定されていない場合は、これらの

ステップに従う必要がありますが、Oracle Management Serviceを構成したときにこのOracle Management Serviceの詳細をSLBプールに追加したので、このステップに従う必要はありません。

24


これらのステップを送信する電子メール・アドレスを任意で指定することができます（注：それには、

「Setup」→「Notifications」→「Notification Methods」ページからEmail Notification Methodを構成してい

る必要があります）。

送信後、ソフトウェア・ホームをソース・サーバーからターゲット・サーバーにクローニングすること

で、2番目のOracle Management Serviceを追加するプロセスが完了します。

次の図は、2番目のOracle Management Serviceをインストールした後のCloud Controlトポロジを示します。

図7：2番目のOracle Management Serviceのインストール後のCloud Controlトポロジ

図に示すように、ロードバランサが両方のOracle Management Serviceにトラフィックを送信できるようになり

ました。Oracle Management Serviceのいずれかが失われると、ロードバランサによるそのOracle Management Serviceへのトラフィックが停止され、アプリケーションの可用性が維持されます。これで、リポジトリ

層のデータベース・ノードまたはOracle Management Service層の管理サービス・ノードの障害から保護さ

れます。

25


ステップ6：スタンバイ・データベースの追加

スタンバイ・データベースを追加することで、リポジトリ・データベースが完全な故障から保護されます。

スタンバイ・データベースは、切り離された環境でデータのコピーを提供します。このコピーは、プラ

イマリ・データベースで障害が発生するとアクティブになります。

ステップ6.1：スタンバイ・ノードへのエージェントのインストール

スタンバイ・データベースを構成する前に、スタンバイ・データベース・サーバーをCloud Control環境

に追加する必要があります。それには、前のステップで示されたエージェント配置ウィザードを使用し

ます。

「Setup」→「Add Target」→「Add Host Targets」に移動して、Add Host Targetsのガイド付きワークフ

ローを使用し、Cloud Controlエージェントのインストールを完了します。

ステップ6.2：スタンバイ・クラスタ・ターゲットの追加

エージェントによってターゲットがスタンバイ・ノードに配置されたら、スタンバイ・ノードのクラス

タ・ターゲットも追加します。

それには、「Setup」→「Add Targets」→「Add Targets Manually」にナビゲートします。次に、「Add Non- Host Targets Using Guided Process」を選択し、Target Typeで「Oracle Cluster and High Availability Service」を選択します。

Cluster Target Hostへの入力を指示されたら、スタンバイ・データベース・ホストのいずれかのホスト名

を指定します。次に、クラスタ・メンバーであるホストを選択し、クラスタ・ターゲットを追加するた

めの必須フィールドの入力を完了させます。

26


スタンバイ・クラスタを追加したら、ASMインスタンスとリスナーを追加します。それには、「Setup」→「Add Targets」→「Add Targets Manually」に再びナビゲートし、今回はTarget Typesの「Oracle Database, Listener and Automatic Storage Management」に対し、「Add Non-Host Targets Using Guided Processes」を選択します。

Hostへの入力を指示されたら、スタンバイ・クラスタ・ノードのいずれかのホスト名を指定します。

ここここここここここここここここここ

27


クラスタ内のすべてのホストでデータベースを検索するように指定してから、検出されたすべてのター

ゲットを構成および追加します。

スタンバイ・ノード上のDatabase Oracleホームも管理対象の状態にする必要があります。それには、

「Setup」→「Add Target」→「Auto Discovery Results」にナビゲートして、「Non- Host Targets」タブ

をクリックし、検出されたDatabase Oracleホームの状態を変更します（注：「View」オプションをク

リックして表示された列をカスタマイズできます）。

ステップ6.3：Cloud Controlの"Add Standby Database"機能を使用したスタンバイ・データベースの作成

Oracle RAC上で稼働するCloud Control管理リポジトリ、および2番目の管理サービスの追加により、Cloud Controlインストールは、プライマリ・サイトのコンポーネント障害から保護されます。データベースま

たはOracle Management Serviceサーバーが利用不可になっても、アプリケーションは機能し続けることが

できます。

Oracle Data Guardを追加すると、データベース記憶域が停止しても、データベースは障害から保護され

ます。個別のハードウェアに構成されたスタンバイ・データベースにデータベースの更新を継続的に送

ることで、保護が実現します。

スタンバイ・サイト構成の最初のステップでは、リポジトリ・データベース用の単一インスタンスのスタ

ンバイ・データベースを作成します。このステップは、Cloud Controlリポジトリ・データベースのター

ゲット・ホームページにナビゲートして、メニューから「Availability」→「Add Standby Database」を

選択することで、Cloud Control内から実行できます。

28


まず、Add Standby Databaseウィザードを起動して、単一インスタンスのフィジカル・スタンバイ・デー

タベースを作成します。

Oracle RMANを使用して、「Online Backup」を選択します。

プライマリ・データベース上でスタンバイREDOログを作成するように指示されます。

29


Instance Nameに'emdr'と指定します。Standby Database Locationを指定するには、虫眼鏡をクリックして、

最初のスタンバイ・データベース・ホストの「Database Oracle Home」を選択します。

File Locationsについては、ウィザードによって提供されるデフォルト値をそのまま指定します。

30


Database Unique NameとTarget Nameに'emdr'と指定します。また、SYSDBA資格証明を使用したスタンバイ・

データベースの監視を指定するボックスが選択されていることを確認します。マウントされたスタンバ

イ・データベースを完全に監視するにはSYSDBA資格証明が必要なため、このボックスを選択します。

次に、「Finish」をクリックして、スタンバイ・データベースを作成するジョブを実行します。

31


スタンバイ・データベースが正常に作成されたら、Data Guardホームページにナビゲートして、すべて

が適切に機能していることを確認します。それには、リポジトリ・データベース・ホームページにナビ

ゲートして、「Availability」→「Data Guard Administration」を選択します。次のスクリーンショット

のように、すべてが正常な状態であることを示している必要があります。

さらに、Oracle Data Guardの検証をData Guard管理ホームページから実行できます。

32


ステップ6.4：Maximum Availabilityモードへのスタンバイ・データベースの切替え

Maximum Performance、Maximum Availability、およびMaximum Protectionの各モードは、さまざまなレベル

の保護（パフォーマンス、可用性、およびコストとのトレードオフ）を提供します。Add Standby DatabaseウィザードでMaximum Performanceモードのフィジカル・スタンバイ・データベースを作成すると、スタ

ンバイ・サイトへの非同期書込みが可能になります。このスタンバイ・データベースはプライマリ・デー

タベースと同じサイトにあるため、データベースをMaximum Availabilityモードで再構成することを選択

します。その結果、スタンバイ・データベースへの同期書込みが実行されて、プライマリ・データベー

スに障害が発生した場合に、より高いレベルのデータ保護が実現します。

Data Guard Administrationページの「Protection Mode」をクリックして、Maximum Availabilityモードに切

り替えます。

次の画面で「Maximum Availability」を選択し、「Continue」を選択します。

「emdr」スタンバイ・データベースを選択して、処理を続行します。

33


保護モードの変更後、Oracle Data Guard構成の状態をData Guard Administrationページから再びチェックし

ます。現在、Maximum Availabilityモードで実行中であることが示されています。

次の図は、スタンバイ・データベース作成後のCloud Controlトポロジを示します。

図8：スタンバイ・データベース作成後のCloud Controlトポロジ

上に示すように、スタンバイ・データベースの使用によって、プライマリOracle RACクラスタの完全な

障害からインストールが保護されます。ただし、このスタンバイ・データベースは単一ノード上のみで

稼働しているため、利用可能な容量がプライマリより少ない状態です。

ステップ7：Oracle RACへのスタンバイ・データベースの変換

スタンバイ・データベースがアクティブになったときに、Cloud Controlのパフォーマンスを確実に維持

するため、このデータベースをOracle RACに変換して、プライマリ・サイトをミラーリングするように

します。単一インスタンスのスタンバイ・データベースをOracle RACに変換するには、Cloud ControlのConvert Cluster Database機能を使用します。

34


この機能にアクセスするには、スタンバイ・データベースのホームページにナビゲートして、「Availability」→「Convert to Cluster Database」を選択します。

クラスタ・データベース・インスタンスのOracle Homeを指定し、クラスタとOracle ASMの資格証明を指

定します。

変換されるスタンバイ・データベースが読取り専用モードになっていないため、この処理がOracle RACプロセスへの変換の一部としてウィザードで実行されることを示すメッセージが表示されます。

次に、新しいクラスタ・データベースの接頭辞を指定し、クラスタ内の2番目のノードでさらにデータ

ベースを構成することを選択します。

35


既存のデータベース領域とファスト・リカバリ領域の使用を選択します。

詳細を確認した後、ジョブを実行します。

36


ジョブが実行されたら、Data Guard AdministrationページからOracle Data Guardの状態をチェックします。

スタンバイ・データベースがOracle RACに変換されたことが示されています。

次の図は、「はじめに」で示したとおりのトポロジを示します。SLBを作成し、追加のOracle Management Serviceをインストールし、スタンバイ・データベースを作成してからOracle RACに変換して、MAA Level 3構成に辿りつきました。

図9：Cloud Control Level 3トポロジ

図に示すように、各層の障害から保護されています。

プライマリ・データベースが利用できなくなると、スタンバイ・データベースがアクティブになり、Oracle Management Service層によって使用される接続文字列を、アクティブになったスタンバイ・データベース

に接続するよう変更できます。

プライマリ・データベースからスタンバイへのスイッチオーバーまたはフェイルオーバーは、'dgmgrl'インタフェースからData Guard Brokerを使用して実行されます。Oracle Management Serviceによって使用さ

れるリポジトリの接続文字列を変更するには、各Oracle Management Serviceから'emctl config oms -store_ repos_details'コマンドを実行します。

この例では、各Oracle Management Serviceサーバーで以下を実行して、Oracle Management Service接続文字

列を再構成します。

37


emctl config oms -store_repos_details -repos_conndesc “(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=emreps-cl- scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=emdr)))” - repos_user sysman

この再構成の後、各Oracle Management Serviceを再起動できます。

再起動後、'Management Services and Repository'ターゲットは監視されなくなります。このターゲットの監

視を再開するには、スタンバイ・サイトの管理エージェントにターゲットを再配置する必要があります。

それには、'emctl config emrep'コマンドを実行します。この例では、'Management Services and Repository'ターゲットを次のように再構成します。

emctl config emrep –agent emreps1.example.com:3872 –conn_desc “(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=emreps-cl- scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=emdr)))”

場合によっては、上記の再構成ステップを自動化した方が望ましいことがあります。それには、リポジ

トリ・データベース上でロールの変更が検出されたときに起動するデータベース・トリガー設定を使用

します。

スタンバイ・サイトのスイッチオーバーまたはフェイルオーバー（フェイルオーバー・プロセスの自動

化を含む）について詳しくは、Cloud Control管理者ガイドを参照してください。

38

http://docs.oracle.com/cd/E26854_01/doc.121/b65081/toc.htm


結論

Cloud Controlによって提供される機能の幅広さと奥深さにより、Cloud Controlは重要なデータセンター・

アプリケーションとなります。そのため、Cloud Controlインフラストラクチャの高可用性はほとんどの

場合、必要不可欠とされています。

高可用性Cloud Control実装の構築には、数多くのさまざまなトポロジの構成が含まれ、各トポロジはソ

リューション全体の特定の部分を成します。

高可用性Cloud Control配置の実装は、各種コンポーネントの配置と構成の最適な順序を計画することで、

大幅に簡素化、効率化できます。同様に、Cloud Controlによって提供される自動化機能を利用すると、

所要時間とエラー数を軽減できます。

39

高可用性Oracle Enterprise Manager

12c Cloud Controlの配置

2012年5月

著者：Mark McGill

共著者：Raj Aggarwal、

David Parker-Bastable

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

海外からのお問い合わせ窓口：

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

www.oracle.com

Copyright © 2012, Oracle and/or its affiliates.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一切間違いがない

ことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての

黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認

し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ること

なく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel XeonはIntel

Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録商

標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。

1010

高可用性oracle enterprise manager 12c cloud …...高可用性oracle enterprise manager 12c...

Documents