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

Transcription

1 MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 オラクル ホワイトペーパー 2007 年 1 月 Maximum Availability Architecture Oracle Best Practices For High Availability

2 高可用性を得るための Oracle のベスト プラクティス 概要 可用性の高いシステムは 今日 いかなるビジネスの成功にも不可欠です また これらの基幹システムの高可用性を監視する管理インフラストラクチャも重要です オラクル社の Oracle Enterprise Manager Grid Control(EM GC) のアーキテクチャは 当初からスケーラブルで高い可用性を実現するように設計されています ビジネスの品質保証契約を満たしながら ビジネスをサポートする資産の管理に集中できるようになります このホワイト ペーパーでは オラクル社の高可用性に関する専門家の経験を参考にして Maximum Availability Architecture(MAA) 推奨事項に従うことにより高可用性の EM を配置するベスト プラクティスを列記します Maximum Availability Architecture は オラクル社の実証済高可用性テクノロジと推奨事項に基づいたベスト プラクティスの青写真です MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 2

3 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アーキテクチャについて復習するには オンライン ドキュメント ライブラリ ( の各種資料を参照してください MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 3

4 高可用性を得るための 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

5 アクティブ OMS 共有ストレージ スタンバイ OMS アクティブ DB 共有ストレージ スタンバイ DB 図 2: EM Maximum Availability Architecture( アクティブ / パッシブ ) アクティブ / アクティブ (MAA) 構成 : アクティブ / アクティブ構成では 同じアプリケーション ワークロードを処理するために 2 つ以上の OMS インスタンスが構成されます これらのインスタンスは 同じマシンまたは異なるマシンに置くことができます アクティブ インスタンスはロード バランサ ルーターによりフロントエンドに置かれます このルーターは リクエストをいずれかのアクティブ インスタンスにリダイレクトできます アクティブ OMS のいずれかのノードが停止した場合 OMS の残りのノードがワークロードを引き継ぎます 図 3 にアクティブ / アクティブ モードで構成された EM の主要コンポーネントを示します 次のような利点があります すべてのノードが稼働している場合 ハードウェア利用率が高くなり パフォーマンスがよくなります ( スループットが高い ) スケーラビリティ フェイルオーバーが高速になりますこの構成の欠点は ノードが停止した場合 パフォーマンスが低下する可能性があることです MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 5

6 ロードバランサ Grid Control コンソール ストレージ リポジトリ 図 3: EM Maximum Availability Architecture( アクティブ / アクティブ ) 次のセクションでは EM の各コンポーネントを MAA( アクティブ / アクティブ HA アーキテクチャ ) に適合させるためのベスト プラクティスを説明します これらのベスト プラクティスは 新たに EM をインストールする手順をもとにしていますが ベスト プラクティスの多くは 既存の Enterprise Manager インストールに MAA アーキテクチャを後付けするためにも使用できます 注意 : このホワイト ペーパーで説明するベスト プラクティスの多くは EMをアクティブ / アクティブおよびアクティブ / パッシブのいずれのモードで構成する場合にも適用されます アクティブ / パッシブ モードでOMSとリポジトリを構成するための詳細な手順は Metalink Note: とMetalinkNote: に公開されています MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 6

7 Management Repository の構成 : EM をインストールする前に Management Repository をセットアップするためのデータベースを準備する必要があります OUI/DBCA を使用してデータベースをインストールし オラクル社のインストール ベスト プラクティスをすべて継承します データベースの構成 : Automatic Storage Management (ASM): データベース管理者に すべてのサーバーとストレージ プラットフォームを対象とした一貫性のある単一ストレージ管理インタフェースを提供する Oracle Database 10g の機能 高可用性とスケーラビリティの両方を得るために 最新の認定済データベース バージョンで RAC オプションを有効にしてリポジトリを構成します EM のために認定されたデータベースの最新バージョンは オラクル製品主なシステム要件 ページ ( を参照してください 基盤ストレージ テクノロジとして 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

8 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

9 注意 : EM 10g release で開始する場合 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

10 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

11 エージェントの構成 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

12 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 :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

13 プライマリ セカンダリ 共有ローダー ストレージ スタンバイ 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

14 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 を構成 : Data Guard は EM 障害時リカバリ戦略の鍵です 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> 次のプロパティを追加します em.fastconnectionfailover=true MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 14

15 共有ローダー ディレクトリを構成 : 共有ローダー ディレクトリがプライマリ サイトとスタンバイ サイトでレプリケーションされるように構成します 完全なサイト停止が発生した場合 プライマリ側の 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

16 2. セカンダリ OMS がセカンダリ Server Load Balancer が作成した 仮想プール の一部となるように構成します 一部の SLB ベンダー (F5 Networks など ) は サイト停止の場合 プライマリ サイトの SLB により表わされる仮想 IP の制御をスタンバイ サイトの SLB に渡す追加サービスを提供しています これは プライマリ サイトからスタンバイ サイトへのエージェント トラフィックの自動切り替えを促進にするために使用できます 結論 高可用性および障害時リカバリのアーキテクチャには 様々な環境要件に合わせたカスタマイズが必要です このホワイト ペーパーで説明したベスト プラクティスは 大部分の環境に対し フォールト トレラントな高可用性を持つ管理ソリューションを構成するためのガイドラインを提供します Oracle の Maximum Availability Architecture を詳しく説明したホワイト ペーパーは OTN-Japan の次のサイトで入手できます MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 16

17 付録 : 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 タブ: htm Enterprise Manager の概念 : Oracle Database ネットワーキング : Oracle Database Net Services 管理者ガイド の第 13 項 Oracle Net Services の拡張機能の使用 rtal_4.htm MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 17

18 高可用性リポジトリの構成 : Oracle Database 高可用性ベスト プラクティス の第 2.1 項と第 2.2 項 rtal_4.htm Server Load Balancer のセットアップ : Metalink Note ( 英語 ) ( へのログイン アカウントが必要です ) アクティブ / パッシブ モードでの OMS のセットアップ : Metalink Note ( 英語 ) ( へのログイン アカウントが必要です ) アクティブ / パッシブ モードでのリポジトリのセットアップ : Metalink Note ( 英語 ) ( へのログイン アカウントが必要です ) フィジカル スタンバイ データベースの作成 : Oracle Data Guard 概要および管理 の フィジカル スタンバイ データベースの作成 rtal_4.htm Oracle Database 高可用性ベスト プラクティス の第 2.4 項 Data Guard を使用した Oracle Database 10g の構成 rtal_4.htm Data Guard 構成を作成 管理 監視するための Oracle Enterprise Manager グラフィカル ユーザー インタフェース (GUI) Oracle Data Guard Broker の第 6 章 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 章 rtal_4.htm MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR3 18

19 MAA ベスト プラクティス Enterprise Manager 10gR2 および 10gR 年 1 月著者 : Anirban Chatterjee, James Viscusi 寄稿者 : Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファックス : Copyright 2007, Oracle. 無断転載を禁ず この文書はあくまで参考資料であり 掲載されている情報は予告なしに変更されることがあります オラクル社は 本ドキュメントの無謬性を保証しません また 本ドキュメントは 法律で明示的または暗黙的に記載されているかどうかに関係なく 商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません オラクル社は 本書の内容に関していかなる保証もいたしません また 本書により 契約上の直接的および間接的義務も発生しません 本書は 事前の書面による承諾を得ることなく 電子的または物理的に いかなる形式や方法によっても再生または伝送することはできません Oracle JD Edwards PeopleSoft および Siebel は Oracle Corporation および関連会社の登録商標です 他の製品名は それぞれの所有者の商標です