MAAベスト・プラクティス Enterprise Manager 10gR2および10gR3

MAA ベスト・プラクティス Enterprise
Manager 10gR2 および 10gR3
オラクル・ホワイトペーパー
2007 年 1 月
Maximum
Availability
Architecture
Oracle Best Practices For High Availability
Maximum Availability Architecture
高可用性を得るための Oracle の
ベスト・プラクティス
概要
可用性の高いシステムは、今日、いかなるビジネスの成功にも不可欠です。また、
これらの基幹システムの高可用性を監視する管理インフラストラクチャも重要で
す。オラクル社の Oracle Enterprise Manager Grid Control（EM GC）のアーキテクチャ
は、当初からスケーラブルで高い可用性を実現するように設計されています。ビ
ジネスの品質保証契約を満たしながら、ビジネスをサポートする資産の管理に集
中できるようになります。
このホワイト・ペーパーでは、オラクル社の高可用性に関する専門家の経験を参
考にして、Maximum Availability Architecture（MAA）推奨事項に従うことにより
高可用性の EM を配置するベスト・プラクティスを列記します。Maximum
Availability Architecture は、オラクル社の実証済高可用性テクノロジと推奨事項に
基づいたベスト・プラクティスの青写真です。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
2
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
Enterprise Manager コンポーネントの概要
EM Maximum Availability Architecture の
利点:
1. スケーラビリティ
2 停止に気付くことのないサービス
3. 自動フェイルオーバー
4. 障害時リカバリ
Enterprise Manager には次の 3 つの主要コンポーネントがあります。
•
Management Agent − データベース、アプリケーション・サーバーなどの
データ・センター・リソースを監視し、Oracle Management Service と通信
するネイティブ・プロセス。
•
Oracle Management Service（OMS） − エージェントにより収集された情
報を処理し、EM Grid Control コンソール GUI を表示し、データ格納用リ
ポジトリを使用する J2EE アプリケーション。
•
Management Repository − 特別なスキーマ内に EM データを格納する
Oracle データベース。
図 1 に、EM の基本コンポーネントを示します。
Grid Control
コンソール
図 1: Enterprise Manager のアーキテクチャ
このホワイト・ペーパーでは、EM GCアーキテクチャをよく理解していることが
前提です。EM GCアーキテクチャについて復習するには、オンライン・ドキュメ
ント・ライブラリ（ http://otn.oracle.co.jp/products/oem/index.html）の各種資料を参
照してください。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
3
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
高可用性を得るための Enterprise Manager の構成
MAA は、EM の各コンポーネントで障害をガードすることにより、高可用性の
Enterprise Manager（EM）実装を提供します。
EM コンポーネントの障害には、次のようなものがあります。
•
Management Agent の障害または Management Agent と OMS 間の通信障害:
ターゲットは EM により監視されませんが、EM コンソールは使用可能で
あり、リポジトリから履歴データを表示できます。
Enterprise Manager は、監視されるアプ
リケーションの中で最高の可用性を備え
ていることが必要です。
•
Oracle Management Service（OMS）の障害: EM コンソールと同様に、ほと
んどの EM サービスが使用不能になります。
•
リポジトリの障害: エージェントによりアップロードされたデータの保
存について EM の一部で障害が発生し、ほとんどの EM サービスが使用
不能になります。
全体に、EM のいずれのコンポーネントでも障害の発生は実質的なサービス低下
を招くため、高可用性アーキテクチャを使用して各コンポーネントを堅牢にして
おくことが重要です。EM は、単一のインスタンス・データベースをリポジトリ
として使用して、アクティブ/アクティブ・モードまたはアクティブ/パッシブ・モー
ドで実行するように構成できます。この 2 つのアーキテクチャの概要を次に示し
ます。
アクティブ/パッシブ: アクティブ/パッシブ構成には 2 つのハードウェア・ノード
が含まれ、単一のノードが 1 度に 1 つの OMS インスタンス（アクティブ）を実行
します。実際に OMS をホストするノードはアクティブ・ノードと呼ばれます。
OMS を潜在的にホスト可能なノードまたはノードのセットはパッシブ・ノードと
呼ばれます。OMS または OMS が依存するリソース（ディスクやノード自体）が
クラッシュした場合、OMS は必要なすべてのリソースとともに再配置され、パッ
シブ・ノードで再起動されます。図 2 にアクティブ/パッシブ・モードで構成され
た EM の主要コンポーネントを示します。次のような利点があります。
•
構成、セットアップ、メンテナンスが容易
•
Server Load Balancer（SLB）が不要
このソリューションの大きな欠点は、単一の OMS とデータベース・インスタンス
というスケールを超えた場合、利用できないことです。また、コンポーネント障
害で停止した場合、EM がスタンバイ・ハードウェアで再起動するため解決に時
間がかかります。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
4
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
共有ストレージ
アクティブ
OMS
共有ストレージ
アクティブ
DB
スタンバイ
OMS
スタンバイ
DB
図 2: EM Maximum Availability Architecture（アクティブ/パッシブ）
•
アクティブ/アクティブ（MAA）構成: アクティブ/アクティブ構成では、
同じアプリケーション・ワークロードを処理するために、2 つ以上の OMS
インスタンスが構成されます。これらのインスタンスは、同じマシンま
たは異なるマシンに置くことができます。アクティブ・インスタンスは
ロード・バランサ・ルーターによりフロントエンドに置かれます。この
ルーターは、リクエストをいずれかのアクティブ・インスタンスにリダ
イレクトできます。アクティブ OMS のいずれかのノードが停止した場合、
OMS の残りのノードがワークロードを引き継ぎます。図 3 にアクティブ/
アクティブ・モードで構成された EM の主要コンポーネントを示します。
次のような利点があります。
•
すべてのノードが稼働している場合、ハードウェア利用率が高く
なり、パフォーマンスがよくなります（スループットが高い）
•
スケーラビリティ
•
フェイルオーバーが高速になります
この構成の欠点は、ノードが停止した場合、パフォーマンスが低下する
可能性があることです。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
5
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
ロードバランサ
Grid Control
コンソール
ストレージ
リポジトリ
図 3: EM Maximum Availability Architecture（アクティブ/アクティブ）
次のセクションでは、EM の各コンポーネントを MAA（アクティブ/アク
ティブ HA アーキテクチャ）に適合させるためのベスト・プラクティス
を説明します。これらのベスト・プラクティスは、新たに EM をインス
トールする手順をもとにしていますが、ベスト・プラクティスの多くは、
既存の Enterprise Manager インストールに MAA アーキテクチャを後付け
するためにも使用できます。
注意: このホワイト・ペーパーで説明するベスト・プラクティスの多く
は、EMをアクティブ/アクティブおよびアクティブ/パッシブのいずれ
のモードで構成する場合にも適用されます。アクティブ/パッシブ・モー
ドでOMSとリポジトリを構成するための詳細な手順は、Metalink Note:
405642.1とMetalinkNote: 405979.1に公開されています。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
6
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
Management Repository の構成:
EM をインストールする前に、Management Repository をセットアップするための
データベースを準備する必要があります。OUI/DBCA を使用してデータベースを
インストールし、オラクル社のインストール・ベスト・プラクティスをすべて継
承します。
•
データベースの構成:
•
Automatic Storage Management
（ASM）: データベース管理者に、すべて
のサーバーとストレージ・プラット
フォームを対象とした一貫性のある単一
ストレージ管理インタフェースを提供す
る Oracle Database 10g の機能。
高可用性とスケーラビリティの両方を得るために、最新の認定済デー
タベース・バージョンで RAC オプションを有効にしてリポジトリを
構成します。EM のために認定されたデータベースの最新バージョン
は、「オラクル製品主なシステム要件」ページ
（http://www.oracle.co.jp/products/system/index.html）を参照してくださ
い。
•
基盤ストレージ・テクノロジとして、Automatic Storage Management
（ASM）を選択します。
•
データベース・インストールの完了後、次を実行します。
•
データベース・ホームの$ORACLE_HOME/rbdms/admin ディレク
トリに移動し、‘dbmspool.sql’を実行します。これにより、
DBMS_SHARED_POOL パッケージをインストールし、
Management Repository のスループットが改善されます。
•
Enterprise Manager のインストール: Oracle Universal Installer（OUI）を使
用して EM をインストールすると、リポジトリの構成について次の 2 つ
のオプションが示されます。
RAC ノードの数: リポジトリを構成する
ための RAC ノード数がわからない場合、
単一ノード RAC でリポジトリを構成し、
その後、必要に応じてマルチ・ノード・
アーキテクチャへと拡大します。
•
Option 1: Install using a new database（新しいデータベースを使用して
インストール）（デフォルト・インストール）
•
Option 2: Install using an existing database（既存データベースを使用し
てインストール）
MAA には、「Option 2: Install using an existing database」を選択します。
「existing database」を求めるプロンプトに対して、リポジトリをセットアッ
プするために前の手順で構成されたデータベースを指定できます。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
7
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
Oracle Management Service（OMS）の構成
リポジトリの構成後、次の手順を実行して、EM Grid Control 中間層となる OMS
をインストールし構成して、さらに可用性を高めます。中間層の冗長性とスケー
ラビリティの追加手順を説明する前に、OMS 自体が Oracle Process Management and
Notification Service（OPMN）に基づく再起動メカニズムを内蔵していることを知っ
ておくことが必要です。このサービスは、停止した OMS の再起動を試行します。
•
OMS のインストール位置: 複数の OMS とリポジトリ・ノードを持つ大
きな環境を管理している場合、リポジトリ・ノードとは異なるハードウェ
ア・ノードに OMS をインストールすることを検討してください（図 4）。
これにより将来、OMS を拡張できます。
ハードウェア
ノード 1
リポジトリ
ハードウェア
ノード 2
リポジトリ
クラスタ
ハードウェア
ノード 3
ハードウェア
ノード 4
図 4: 別々のハードウェア上にある OMS とリポジトリ
OMS のインストール位置を決定する場合、OMS とリポジトリ間のネット
ワーク遅延も考慮する必要があります。OMS とリポジトリ間の距離は、
ネットワーク遅延に影響し、EM パフォーマンスを決定する要因の 1 つで
す。
OMS 層とリポジトリ層間のネットワーク遅延が大きい場合、または EM
実行のために利用できるハードウェアに制限がある場合、OMS をリポジ
トリと同じハードウェアにインストールします（図 5）。これにより、EM
の高可用性が確保され、コストも低く抑えられます。
クラスタ
リポジトリ
リポジトリ
ハードウェア
ノード 1
ハードウェア
ノード 2
図 5: 同じハードウェア上にある OMS とリポジトリ
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
8
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
注意: EM 10g release 10.2.0.2 で開始する場合、OMS を RAC リポジトリと
同じノードにインストールできます。同じにするには、図 3 ならびに
README に指定された指示を参照してください。
•
OMS の追加インストール: OUI オプション「Add Additional Management
Service」を使用して、1 つ以上の OMS を追加インストールします。高可
用性のためには OMS が 2 つ以上必要ですが、予想ワークロードに応じて、
またはシステム使用率データに基づいて、OMS プロセスを追加インス
トールできます。
サイズに関する推奨事項は、『Enterprise Manager アドバンスト構成』の
第 9 章を参照してください。
•
OMS とリポジトリ間の通信の構成: すべての OMS プロセスをインス
トール後、OMS プロセスが RAC リポジトリの各ノードと冗長的に通信
する構成にします。その手順は、次のとおりです。
•
インストールした各 OMS で、ファイル
$ORACLE_HOME/sysman/config/emoms.properities のフィールド
emdRepConnectDescriptor を変更します。この構成の目的は、OMS に
データベース・クラスタのすべてのインスタンスを認識させ、データ
ベース・サービス EMREP を介してリポジトリへのアクセスを提供す
ることです。
この変更スクリプトの例を次に示します。
oracle.sysman.eml.mntr.emdRepConnectDescriptor=(DESCRIPTION\=
(ADDRESS_LIST\=(FAILOVER\=ON)
(ADDRESS\=(PROTOCOL\=TCP)(HOST\=hostname.oms1.com)
(PORT\=1521))(ADDRESS\=(PROTOCOL\=TCP)(HOST\=hostname.oms
2.com)
(PORT\=1521)) (CONNECT_DATA\=(SERVICE_NAME\=EMREP)))
Oracle Database ネットワーキングおよび FAILOVER パラメータの
詳細は、『Oracle® Database Net Services 管理者ガイド』の第 13
章「Oracle Net Services の拡張機能の使用」を参照してください。
•
共有ファイル・システム・ロード・ディレクトリの構成: EM 10gR2 の新
機能により、すべての OMS プロセスは Management Agents によりアップ
ロードされた情報を共有ディレクトリに残すことができます。これには
次の 2 つの利点があります。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
9
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
I.
すべての OMS がエージェント・データを処理でき、使用可能なリソー
スを有効に活用できます。
II. OMS で障害が発生した場合、別の OMS でエージェント・データを
処理できます。
Shared File System Loader を使用するように Management Service を構成す
るためには、次の手順が必要になります。
1.
すべての Oracle Management Service を停止します。
2.
冗長ファイル・システム・ストレージを使用するすべての
Management Services がアクセスできる共有受信ディレクトリを
構成します。
3.
すべての OMS ホストで個別に emctl config oms loader -shared yes
-dir <loaderdirectory>を実行します。ここで、<loader directory>は
手順 2 で作成された共有受信ディレクトリに対する完全パスで
す。
注意: すべての OMS が同じ共有ディレクトリを指すように構成されてい
ないと、Enterprise Manager は起動に失敗します。この共有ディレクトリ
は、冗長ストレージ上にあることが必要です。
•
OMS インストール後のリポジトリの構成: いくつかのパラメータは、リ
ポジトリ・データベース・インストール中に構成する必要があります（前
述）。また一部のパラメータは OMS のインストール後に設定が必要です。
EM コンソールが使用可能になると、リポジトリでベスト・プラクティス
を構成できます。このベスト・プラクティスは次の領域に分類されます。
•
ストレージの構成
•
高可用性とリカバリ性のための RAC を使用した Oracle Databse 10g
の構成
•
ARCHIVELOG モードの有効化
•
ブロック・チェックサムの有効化
•
REDO ログ・ファイルとグループのサイズの適切な構成
•
フラッシュ・リカバリ領域の使用
•
フラッシュバック・データベースの有効化
•
インスタンス・リカバリ時間を制御するファスト・スタート障害
時リカバリの使用
•
データベース・ブロック・チェックの有効化
•
DISK_ASYNCH_IO の設定
これらの設定の詳細は、このホワイト・ペーパーの対象外です。詳細は
『Oracle® Database 高可用性ベスト・プラクティス』の 2.1 項と 2.2 項を参照
してください。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
10
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
エージェントの構成
Management Agents:
• EM インフラストラクチャでは実際の
作業者は何もすることがなく退屈
• エージェントの可用性は EM Grid
Control を最大限活用するための鍵
EM 高可用性の最後は、エージェントの構成です。エージェントの構成に入る前
に、エージェントにはデフォルトで組み込まれる高可用性機能がある点に注意し
てください。ウォッチドッグ・プロセスは、エージェント起動時に自動的に作成
され、各エージェント・プロセスを監視します。エージェント・プロセス障害が
発生すると、ウォッチドッグは、自動的にエージェント・プロセスの再起動を試
行します。
デフォルト EM Grid Control インストールにおけるエージェント層と OMS 層間の
通信は、ポイントツーポイント・セットアップです。そのため、デフォルト構成
では、OMS は使用不可能になるシナリオから保護されません。このシナリオでは、
エージェントは OMS（およびリポジトリ）に監視情報をアップロードできなくな
り、その結果、そのエージェントが手動で別の OMS を指すように構成されるまで、
ターゲットは監視されません。
Server Load Balancer（SLB）:
通常、負荷の過剰な OMS が発生しない
ように OMS 間でトラフィックを効率的
に分散するハードウェア。
このハードウェアを製造しているベン
ダーは、BIG-IP F5、Radware
WSD/CT100c、Nortel Alteon、Foundry
ServerIron、NetScaler、Cisco ACE/CSM
などです。
この状況を回避するには、エージェントと OMS 間でハードウェア Server Load
Balancer（SLB）を使用します。このロード・バランサは、各 OMS の健全度とス
テータスを監視し、ロード・バランサを通じて行われた接続を確実にリダイレク
トして、あらゆるタイプの障害に対し OMS ノードを存続させます。SLB を使用
するその他の利点は、ロード・バランサが EM に対するユーザー通信を管理する
構成が可能なことです。ロード・バランサは使用可能なリソースのプールを作成
することにより、これを処理します。
•
Server Load Balancer（SLB）の構成: EM 高可用性のため、OMS が提供
する 3 つの外部サービスに対応したプールを SLB で作成します。これら
のサービスが提供する機能は次のとおりです。
1.
エージェントにデータをアップロードするためのアクセス
2.
エージェント通信を保護するためのアクセス
3.
EM コンソール GUI に対するアクセス
OMS ノードの実際の位置は、これらのプールを介してロード・バランサ
により実際上「仮想化」されます。
•
SLB を通じて通信するエージェントを構成: ロード・バランサはすべて
のエージェントが使用できる仮想 IP アドレスを提供します。ロード・バ
ランサをセットアップ後、SLB を通じて OMS にトラフィックをルーティ
ングするようにエージェントを構成する必要があります。そのためには、
エージェントでプロパティ・ファイルを数箇所変更します。後述する Web
IV Note を参照してください。
•
SLB を後付けできるエージェントを構成: 初期インストールでは、一部
のシステムで SLB に対するアクセスがありませんが、後で追加が必要な
ことは分かっています。その場合、初期インストールの一部として SLB
に使用する仮想 IP アドレスを構成し、その IP アドレスが既存の OMS を
指すようにします。エージェントと OMS 間のセキュアな通信は、ホスト
名に基づいて行われます。後で新しいホスト名が導入された場合、各エー
ジェントは SLB によりメンテナンスされる新しい仮想 IP を指すように構
成されるため、各エージェントを再度保護する必要はありません。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
11
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
•
SLB を通じてトラフィックをリダイレクトする OMS を構成: 最後に
OMS を変更して、Server Load Balancer の機能を活用します。これらの変
更により、すべての OMS ノードは、Server Load Balancer を通じてトラ
フィックを EM コンソールにリダイレクトするため、EM ユーザーには単
一 URL が示されます。
•
$ORACLE_HOME/sysman/config/emoms.properties の
ConsoleServerName プロパティを変更して、ロード・バランサが管理
する仮想ホスト名を指すようにします。
•
$ORACLE_HOME/Apache/Apache/conf/ssl.conf にある Oracle HTTP
Server 構成ファイルに定義された ServerName プロパティを変更して、
ロード・バランサにより管理される仮想ホスト名を指すようにします。
•
$ORACLE_HOME/Apache/Apache/conf/ssl.conf にある Oracle HTTP
Server 構成ファイルの Port の値を 443 に変更します。これは、OMS
とエージェント間をデフォルトの保護された構成で実行しているも
のと仮定します。
注意: EM高可用性のためにハードウェア・ロード・バランサを構成す
る詳細な手順は、『Metalink Note 353074.1:How to configure Grid Control
10.2 Management Servers behind a Server Load Balancer (SLB)』を参照して
ください。
障害時リカバリ
一般に、高可用性はアプリケーション障害やシステム・レベルの問題など、ロー
カルな停止を保護しますが、障害耐久力は、自然災害、火事、停電、疎開、長期
ストなどによるデータ・センターの壊滅的障害という大規模な停止を保護します。
Maximum Availability では、サイトの消失が企業を管理する管理ツールの停止を招
いてはなりません。
EM の Maximum Availability Architecture では、プライマリ管理インフラストラク
チャで障害が発生した場合、セカンダリ・データ・センターが管理インフラスト
ラクチャを肩代わりするリモート・フェイルオーバー・アーキテクチャの配置が
不可欠です。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
12
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
プライマリ
セカンダリ
共有ローダー
ストレージ
リポジトリ
スタンバイ
SLB
スタンバイ
OMS
スタンバイ
リポジトリ
図 6: EM 障害時リカバリ・アーキテクチャ
図 6 から分かるように、Enterprise Manager のための障害時リカバリのセットアッ
プでは、基本的に、スタンバイ RAC、スタンバイ OMS、スタンバイ Server Load
Balancer をインストールし、プライマリ・コンポーネントが停止した場合にそれ
らが自動的に起動する構成にします。
次のセクションに、障害時リカバリのために主要 EM コンポーネントを構成する
ベスト・プラクティスを列記します。
注意: スタンバイ・データベースをセットアップするには、インストール時に Data
Guard の初期セットアップでプライマリ・データベースの再起動が必要なため、
コマンドラインを使用して次の各手順を実行します。
•
リポジトリのためのスタンバイ・データベースのインストール:
1.
バージョン 10.2 の EM でスタンバイ・データベースを作成します。
スタンバイ・データベースはフィジカル・スタンバイのみであること
が必要です。
フィジカル・スタンバイ・データベースを作成するには、『Oracle®
Data Guard 概要および管理』の第 3 章の指示に従ってください。
2.
Enterprise Manager コンソールに戻り、新しいスタンバイ・データベー
スを検出します。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
13
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
3.
プライマリ・データベースのターゲット・ページに移動し、指示（後
述）に従って、プライマリ・データベースとスタンバイ・データベー
スを Data Guard Broker Control の下に置きます。
4.
スタンバイ・データベース・インスタンスを RAC クラスタにする場
合、ホワイト・ペーパー『MAA/Data Guard 10g Release 2 セットアッ
プ・ガイド - RAC プライマリのための RAC ロジカル・スタンバイの
作成』で説明する手順に従ってください。
『Oracle® Database 高可用性ベスト・プラクティス』の第 2.4 項に
掲載された推奨事項に従って、プライマリ・リポジトリとスタン
バイ・リポジトリを構成します。
Data Guard は、コミットされたデータ
ベース・トランザクションをプライマリ
とセカンダリ間で同期化することにより、
プライマリ・データベースのミラー・イ
メージをメンテナンスする製品です。
•
Data Guard を構成: Data Guard は EM 障害時リカバリ戦略の鍵です。Data
Guard パフォーマンスのための標準データベース・ベスト・プラクティス
に従ってください。Data Guard のすべての機能の詳細は『Data Guard
「スイッチオーバー」
（計画的アクション）
または「フェイルオーバー」（計画外停
止）が発生した場合、Data Guard は次の
処理を実行します。
•
•
Concepts Guide』を参照してください。
『Oracle® Data Guard Broker』の第 6 章に、Data Guard 構成の作成、
管理、監視のための Oracle Enterprise Manager グラフィカル・ユー
最後のトランザクションのセカン
ダリへの移動を管理する。
制御をセカンダリに移しリカバリ
して、新しいプライマリにする。
ザー・インタフェース（GUI）の詳細な使用方法が記載されています。
•
フェイルオーバー・サイトのために OMS プロセスを追加インストール:
EM インストーラの「Create Additional Management Service」オプションを
使用して、セカンダリ OMS プロセスを追加します。プライマリと同様、
必要に応じてスタンバイ・データベース・インスタンスと同じノードに
OMS をインストールできます。セカンダリ OMS を構成するには、次の
手順を順に実行します。
1.
インストールの際、プライマリで実行しているリポジトリを指すよう
に OMS を構成します。
2.
インストール完了後、OMS を停止し、
$ORACLE_HOME/sysman/config/emoms.properities ファイルを編集し
て、OMS がスタンバイ・データベースを指すように次のプロパティ
を変更します。

oracle.sysman.eml.mntr.emdRepConnectDescriptor=<database
connection string>

oracle.sysman.emSDK.svlt.ConsoleServerName=<virtual host name>
次のプロパティを追加します。

MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
em.FastConnectionFailover=true
14
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
•
共有ローダー・ディレクトリを構成: 共有ローダー・ディレクトリがプラ
イマリ・サイトとスタンバイ・サイトでレプリケーションされるように
構成します。完全なサイト停止が発生した場合、プライマリ側の OMS が
エージェントからデータを受け取り、それを共有ローダー・ディレクト
リにステージングしたものの、そのデータを処理する時間がなかったと
いう可能性があります。通常では、そのデータは予期しないサイト停止
で消失してしまいます。このデータ消失は、ハードウェア・ベンダーの
ディスク・レベルのレプリケーション技術を使用して制御できます。そ
の場合、障害が発生すると、スタンバイ側で有効化されている OMS は、
最後のトランザクションに至るまでエージェント・データを処理できま
す。
注意: OMS が使用する共有ディレクトリは、プライマリ・サイトとスタ
ンバイ・サイトで同じ名前にします。
Data Guard Observer: プライマリ・プ
ロセスとセカンダリ・プロセスの健全度
を監視するために構成されるプロセス。
Observer は、通常、スタンバイ・サイト
のいずれかのホストにインストールされ
ます。
•
ファスト・スタート・フェイルオーバーのために Data Guard Observer
を構成: Database 10.2 に導入された新機能は、ファスト・スタート・フェ
イルオーバー（FSFO）と Observer プロセスです。プライマリ・リポジト
リ・データベースで障害が発生した場合、Observer はスタンバイ・サイト
へのリポジトリのフェイルオーバーをトリガーします。この機能により、
管理者が介入しなくてもリポジトリを迅速に移動できます。リポジト
リ・データベースを Data Guard Broker の制御下に置く構成の場合、EM を
通じて Observer プロセスを有効化できます。
•
スタンバイ・サイトで OMS を開始するためのトリガーを構成: データ
ベースには、データベース起動を開始する Oracle トリガーを実行する機
能があります。Data Guard と組み合せてこれらのトリガーを構成し、Data
Guard のスイッチオーバーまたはフェイルオーバーが発生した場合、スタ
ンバイ・サイトで OMS プロセスを開始することができます。Enterprise
Manager に関連したトリガーの例は、付録にあります。
このようなクライアント・フェイルオーバーの自動化に使用される基盤
テクノロジの詳細は、OTN の Maximum Availability Architecture ページの
『Client Failover Best Practices for Highly Available Oracle Databases: Oracle
Database 10g Release 2』（英語）に説明されています。
注意: スタンバイ OMS プロセスは、Data Guard フェイルオーバー・トリ
ガーが開始されるまで、いつでも使用できるように準備すること（開始
はしない）、またはプライマリとスタンバイ間のネットワーク遅延が少
ない場合には、プライマリからのリクエストを処理する構成にすること
ができます。
•
ハードウェア Server Load Balancer を追加: 障害時リカバリ環境で完全
な冗長性を実現するため、2 つ目のハードウェア Server Load Balancer を
スタンバイ・サイトにインストールします。
1. セカンダリ SLB は、プライマリと同じ形式で構成することが必
要です。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
15
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
2. セカンダリ OMS がセカンダリ Server Load Balancer が作成した
「仮想プール」の一部となるように構成します。
一部の SLB ベンダー（F5 Networks など）は、サイト停止の場合、プラ
イマリ・サイトの SLB により表わされる仮想 IP の制御をスタンバイ・
サイトの SLB に渡す追加サービスを提供しています。これは、プライ
マリ・サイトからスタンバイ・サイトへのエージェント・トラフィッ
クの自動切り替えを促進にするために使用できます。
結論
高可用性および障害時リカバリのアーキテクチャには、様々な環境要件に合わせ
たカスタマイズが必要です。このホワイト・ペーパーで説明したベスト・プラク
ティスは、大部分の環境に対し、フォールト・トレラントな高可用性を持つ管理
ソリューションを構成するためのガイドラインを提供します。Oracle の Maximum
Availability Architecture を詳しく説明したホワイト・ペーパーは、OTN-Japan の次
のサイトで入手できます。
http://otn.oracle.co.jp/products/availability/htdocs/maa.html
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
16
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
付録:
•
DB 障害時リカバリ・トリガーおよびスクリプトの例:
次のトリガーが、データベースのインスタンスの起動時に発行されます。
トリガーは、OMS プロセスを開始するスクリプト start_oms を呼び出しま
す。この機能は、計画外のサイト停止が発生した場合、スタンバイ・デー
タベースの OMS を開始するために使用できます。
データベース起動後のトリガーmanage_service の作成または置換
DECLARE
role VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
IF role = 'PRIMARY' THEN
DBMS_SERVICE.START_SERVICE('gcha_oms');
begin
dbms_scheduler.create_job(
job_name=>'oms_start',
job_type=>'executable',
job_action=>'<script location>/start_oms.ksh',
enabled=>TRUE
);
end;
ELSE
DBMS_SERVICE.STOP_SERVICE('gcha_oms');
END IF;
END;
/
OMS を開始するためのスクリプト start_oms.ksh:
#!/bin/ksh
<OMS INSTALL LOCATION>/bin/emctl start oms
•
参考:
•
このホワイト・ペーパーで参照している資料の大部分は次にあります。
次のサイトの「Documentation」タブ:
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/index.
htm
•
Enterprise Manager の概念:
http://otn.oracle.co.jp/products/oem/index.html
•
Oracle Database ネットワーキング: 『Oracle® Database Net Services 管
理者ガイド』の第 13 項「Oracle Net Services の拡張機能の使用」
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/po
rtal_4.htm
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
17
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
Maximum Availability Architecture
•
高可用性リポジトリの構成:
『Oracle® Database 高可用性ベスト・プラクティス』の第 2.1 項と第
2.2 項
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/po
rtal_4.htm
•
Server Load Balancer のセットアップ:
Metalink Note 353074.1（英語）
（https://metalink.oracle.com/ へのログイン・アカウントが必要です。）
•
アクティブ/パッシブ・モードでの OMS のセットアップ:
Metalink Note 405642.1（英語）
（https://metalink.oracle.com/ へのログイン・アカウントが必要です。）
•
アクティブ/パッシブ・モードでのリポジトリのセットアップ:
Metalink Note 405979.1（英語）
（https://metalink.oracle.com/ へのログイン・アカウントが必要です。）
•
フィジカル・スタンバイ・データベースの作成:
『Oracle® Data Guard 概要および管理』の「フィジカル・スタンバイ・
データベースの作成」
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/po
rtal_4.htm
•
『Oracle® Database 高可用性ベスト・プラクティス』の第 2.4 項「Data
Guard を使用した Oracle Database 10g の構成」
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/po
rtal_4.htm
•
Data Guard 構成を作成、管理、監視するための Oracle Enterprise
Manager グラフィカル・ユーザー・インタフェース（GUI）
『Oracle® Data Guard Broker』の第 6 章
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/po
rtal_4.htm
•
『MAA / Data Guard 10g Release 2 Setup Guide –Creating a RAC Logical
Standby for a RAC Primary』
『Oracle® Data Guard Broker』の第 6 章
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/po
rtal_4.htm
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
18
Oracle Corporation 発行「MAA Best Practices Enterprise Manager 10gR2 & 10gR3」の翻訳版です。
MAA ベスト・プラクティス Enterprise Manager 10gR2 および 10gR3
2007 年 1 月
著者: Anirban Chatterjee, James Viscusi
寄稿者:
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 © 2007, Oracle. 無断転載を禁ず。
この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。
オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載
されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証
または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、
契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理
的に、いかなる形式や方法によっても再生または伝送することはできません。
Oracle、JD Edwards、PeopleSoft および Siebel は、Oracle Corporation および関連会社の登録商標です。他の製品名
は、それぞれの所有者の商標です。

Download Report