| Oracle Enterprise Manager管理 11gリリース1（11.1.0.1） B61022-01 |
|
 戻る |
 次へ |
複数リソース構成では、Enterprise Managerインストールに冗長性が追加されるため、さらに高いレベルの可用性が作成されます。複数のホストを使用する場合、Enterprise Managerコンポーネントをレプリケートしてフェイルオーバー用に構成できます。これにより、生存性が高まるだけでなく、障害発生後のEnterprise Managerのリストアに必要な時間が大幅に短縮されます。RTOが高い場合、複数ホスト構成を使用したEnterprise Managerのインストールが必須になります。
この章では次のトピックについて説明します。
Enterprise Manager Database Controlでのアクティブおよびパッシブ高可用性環境の仮想ホスト名の使用
仮想ホスト名を使用した高可用性フェイルオーバーのアクティブおよびパッシブ環境でのGrid Control OMSの構成方法
Oracle環境を一元管理する場合に利用可能な機能を最初に確認するには、単一ホストにGrid Controlのすべてのコンポーネントをインストールする方法が効率的です。
管理リポジトリ・データベースが別のホスト上にあり、管理サービスとリソースが競合しない状況では、単一ホスト環境から論理的に進行する方法がより分散的になります。このような構成のメリットとしてスケーラビリティがあります。管理リポジトリや管理サービスのワークロードを分割できるようになりました。この構成では、システム・ロードに応じて、各層に割り当てられるリソースを調整する柔軟性もあります（このような構成については、「図18-2 複数の管理サービスのインストールによるGrid Controlアーキテクチャ」に示します）。
さらに分散した構成では、管理対象ターゲットに関するデータが次の経路で送られるため、管理者はGrid Controlコンソールからデータを収集、保存、利用できるようになります。
管理者はGrid Controlコンソールを使用して、「単一ホストでのGrid Controlコンポーネントのデプロイ」で説明する単一ホスト・シナリオと同様にターゲットを監視および管理します。
管理エージェントは、管理リポジトリ・ホストや管理サービス・ホストなどのネットワーク上の各ホストにインストールされます。管理エージェントは、管理サービス・アップロードURL経由で管理サービスにそのデータをアップロードします。これは、各管理エージェントのホーム・ディレクトリのemd.propertiesファイルで定義されます。アップロードURLは、Oracle HTTP Serverによってデータを直接アップロードします。
管理リポジトリは、管理リポジトリ・データベースをホストする専用の別マシンにインストールされます。管理サービスはJDBC接続を使用して、データを管理リポジトリ・データベースにロードし、そのデータがGrid Controlコンソールに表示されるように管理リポジトリから情報を取得します。このリモート接続は管理サーバーで定義され、emctlコマンドからアクセスおよび変更できます。
管理サービスは、管理エージェントURL経由でHTTPによって各リモート管理エージェントと直接通信します。管理エージェントURLは、各管理エージェントのホーム・ディレクトリのemd.propertiesファイルにあるEMD_URLプロパティで定義されます。「単一ホストでのGrid Controlコンポーネントのデプロイ」で説明するように、管理エージェントには組込みHTTPリスナーがあるため、管理エージェント・ホストにOracle HTTP Serverは必要ありません。
比較的大規模な本番環境では、管理サービスへのロードを軽減してデータ・フローの効率性を高めるために追加の管理サービスのインストールが必要になります。
複数の管理サービスを使用する場合の管理データのフローについて
「図18-2 複数の管理サービス・インストールによるGrid Controlアーキテクチャ」は、Grid Control環境のスケーラビリティを改善するためにさらに管理サービスが追加された典型的な環境を示しています。
複数の管理サービス構成では、管理データは次の経路で移動します。
管理者は、2つのURLのいずれかを使用してGrid Controlコンソールにアクセスできます。各URLは別の管理サービス・インストールを参照しますが、同じセットのターゲットを表示し、そのすべてが共通の管理リポジトリにロードされます。Grid Controlコンソールは、URLのホスト名やポートに応じて、いずれかの管理サービス・ホスト上の管理サービスから（Oracle HTTP Server経由で）データを取得します。
各管理サービスは、emd.propertiesファイルのアップロードURLに基づき、特定の管理サービスにそのデータをアップロードします。そのデータは、Oracle HTTP Server経由で管理サービスに直接アップロードされます。
複数の管理サービスをインストールする場合、ベスト・プラクティスとして、共有ディレクトリへの管理サービスのアップロードが必要です。これにより、すべての管理サービス・プロセスは、管理エージェントからアップロードされたファイルを管理できます。このため、いずれかの管理サーバーが失われたために管理エージェントからのデータのアップロードが中断されることがなくなります。
この機能は、各管理サービス・プロセスのコマンドラインで次のように構成します。
emctl config oms loader -shared <yes|no> -dir <load directory>
|
重要: ロード・バランサを追加することで、次の問題を回避できます。
ロード・バランサの詳細は、「高可用性の構成」を参照してください。 |
|
注意: この環境でソフトウェア・ライブラリを使用する場合、共有管理サービス・ローダーと同じ方法で共有記憶域を使用するように構成する必要があります。ソフトウェア・ライブラリの場所を変更する手順は次のとおりです。
|
各管理サービスはJDBC経由で共通の管理リポジトリと通信します。管理リポジトリは、管理リポジトリ専用ホスト上のデータベースにインストールされます。各管理サービスはemgc.propertiesファイルで定義される同じデータベース接続情報を使用して、管理エージェントのデータを管理リポジトリにロードします。管理サービスは同じ接続情報を使用して、Grid Controlコンソールでリクエストしたとおりに管理リポジトリからデータを取り出します。
システムの管理サービスは、共通の管理リポジトリで定義されたリモート管理エージェントと直接通信できます。管理サービスは、各管理エージェントに割り当てられる一意の管理エージェントURLを使用してHTTPで管理エージェントと通信します。
「単一ホストでのGrid Controlコンポーネントのデプロイ」で説明するように、管理エージェントURLは、各管理エージェントのホーム・ディレクトリのemd.propertiesファイルにあるEMD_URLプロパティで定義されます。各管理エージェントには組込みのHTTPリスナーがあるため、管理エージェント・ホストにOracle HTTP Serverは必要ありません。
単一インスタンス・データベースを管理リポジトリとして使用するアクティブ/アクティブまたはアクティブ/パッシブ・モードで実行するようにEnterprise Managerを構成できます。アクティブ/アクティブ・モードの概要を次に示します。
ハードウェアおよびソフトウェアの高可用性ソリューションを利用する一般的なGrid Control構成の詳細は、次の項を参照してください。これらの構成は、最大可用性アーキテクチャ（MAA）に含まれます。
Enterprise Managerをインストールする前に、管理リポジトリの設定に使用されるデータベースを準備する必要があります。Database Configuration Assistant （DBCA）を使用してデータベースをインストールし、Oracleインストールのすべてのベスト・プラクティスを継承することを確認します。
データベースの構成
高可用性とスケーラビリティの両方を確保するには、RACオプションが有効な、最新リリースの認証データベースで管理リポジトリを構成する必要があります。Enterprise Managerに認証される最新リリースのデータベースは、My Oracle Support Webサイトの認証タブで確認します。
基本となるストレージ・テクノロジとして「自動ストレージ管理（ASM）」を選択します。
データベース・インストールが完了した場合:
データベース・ホームの$ORACLE_HOME/rbdms/adminディレクトリに移動してdbmspool.sqlを実行します。
DBMS_SHARED_POOLパッケージがインストールされます。このパッケージは、管理リポジトリのスループットの改善に役立ちます。
Enterprise Managerのインストール
Oracle Universal Installer（OUI）を使用してEnterprise Managerをインストールする場合、既存のデータベースを使用して管理リポジトリを構成するオプションが表示されます。
（前述のように）管理リポジトリ・データベースのインストール時に構成するパラメータと、管理サービスのインストール後に設定する必要のあるパラメータがあります。
管理リポジトリの各RACノードに管理エージェントをインストールして開始します。管理エージェントをインストールして管理リポジトリ・データベースをターゲットとして検出すると、Enterprise Managerコンソールを使用して管理リポジトリでこれらのベスト・プラクティスを構成できます。
これらのベスト・プラクティスは次の分野に分類されます。
記憶域の構成
高可用性および高速リカバリ用にRACを使用するOracle Database 11gの構成
ARCHIVELOGモードの有効化
ブロック・チェックサムの有効化
REDOログ・ファイルのサイズおよびグループの適切な構成
フラッシュ・リカバリ領域の使用
フラッシュバック・データベースの有効化
ファスト・スタート・フォルト・リカバリを使用したインスタンス・リカバリ時間の制御
データベース・ブロック・チェックの有効化
DISK_ASYNCH_IOの設定
これらの設定の詳細は、『Oracle Database高可用性ベスト・プラクティス』で入手できます。
管理リポジトリへの適用が必要な高可用性の推奨事項については、MAAアドバイザを使用します。MAAアドバイザにアクセスする手順は次のとおりです。
データベース・ターゲットのホームページで「高可用性」セクションを見つけます。
「コンソール」項目の横の「詳細」をクリックします。
「高可用性コンソール」ページの「可用性のサマリー」セクションで、「MAAアドバイザ」項目の横にある「詳細」をクリックします。
管理リポジトリを構成したら、次の手順では、Enterprise Manager Grid Control中間層（管理サービス）をインストールして可用性が向上するように構成します。中間層の冗長性およびスケーラビリティを追加する手順を説明する前に、管理サービス自体に、Oracle Weblogicノード・マネージャおよびOracle Process Management and Notification Service（OPMN）に基づく組込み再起動メカニズムがあることに注意してください。これらのサービスは、停止した管理サービスの再起動を試みます。OPMNおよびノード・マネージャはそのホスト・マシンが再起動すれば自動的に再起動するため、オペレーティング・システムのサービスとして実行することをお薦めします。
管理サービスと管理リポジトリのノードが複数ある大規模な環境を管理している場合、管理リポジトリのノードとは異なるハードウェア・ノードに管理サービスをインストールすることを検討します（図18-3）。これにより、管理サービスを今後拡大できます。
また、管理サービスと管理リポジトリ間のネットワーク待機時間も検討しながら、管理サービスのインストールの場所を決めます。管理サービスと管理リポジトリ間の距離は、ネットワーク待機時間に影響を与える要因の1つになるため、Enterprise Managerのパフォーマンスが決定します。
管理サービスと管理リポジトリ層との間のネットワーク待機時間が長いか、Enterprise Managerの実行に使用可能なハードウェアが制限される場合、管理サービスを管理リポジトリと同じハードウェアにインストールできます（図18-4）。このため、Enterprise Managerの高可用性が実現し、コストが削減されます。
事前に計画を立てる場合、高可用性のEnterprise Managerデプロイを構成するには、管理サービスの最初のインストールで正しいオプションを選択します。デフォルトのインストール・オプションを使用して最初に構成された既存のEnterprise ManagerデプロイにMAAベスト・プラクティスを組み込むこともできます。次の項では、両方の方法について説明します。
管理サービス・プロセスは、RAC管理リポジトリの各ノードと冗長形式で通信するように構成する必要があります。
Real Application Cluster（RAC）のノードはその仮想IP（vip）名で参照されることに注意してください。 service_nameパラメータは、connect_dataモードでシステム識別子（SID）のかわりに使用され、フェイルオーバーが有効になります。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
管理サービスからemctlコマンドを実行してリポジトリ接続記述子を構成します。
emctl config oms -store_repos_details -repos_conndesc '"(DESCRIPTION= (ADDRESS_LIST=(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.example.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=EMREP)))"' -repos_user sysman
以前の変更を加えた後、emctl config emrep -conn_descコマンドを実行して、管理サービスとリポジトリ・ターゲットに使用される監視構成に同じ変更を加えます。
Grid Controlの管理サービスには、共有ファイルシステム・ローダーという高可用性機能があります。共有ファイルシステム・ローダーでは、管理エージェントから受信する管理データ・ファイルが、共有受信ディレクトリと呼ばれる共通の共有場所に一時的に格納されます。すべての管理サービスは、共有受信ディレクトリと同じ記憶域の場所を使用するように構成されます。管理サービスは、管理リポジトリにファイルをアップロードするワークロードを管理サービス間で分散するように内部で調整します。管理サービスが停止した場合、そのワークロードは稼働している管理サービスに引き継がれます。冗長ファイル記憶域を使用してすべての管理サービスからアクセスできる共有受信ディレクトリを選択する必要があります。
最初の管理サービスのインストール時に、すぐに利用できるように共有受信ディレクトリを構成するには、runInstaller（Windowsのsetup.exe）にSHARED_RECEIVE_DIRECTORY_LOCATION=<shared recv directory>オプションを渡します。Oracleでは、この場所をインスタンス・ホームやミドルウェア・ホーム以外の場所にすることをお薦めします。
インストール時に構成しない場合、共有ファイルシステム・ローダーは、すべての管理サービスで次のemctlコマンドを実行してインストール後に構成することもできます。
emctl config oms loader -shared yes -dir <shared recv directory>
|
注意: 共有ファイルシステム・ローダーを最初の管理サービスで構成する場合、後からインストールする追加の管理サービスは、共有ファイルシステム・ローダーの構成を継承します。そのため、共有受信ディレクトリは、インストールを実行する前に追加の管理サービスで利用できるようにしておきます。 |
Windowsで共有ファイルシステム・ローダーを構成する際に次の内容を検討します。
Windowsプラットフォームの場合、Enterprise Managerインストールでは、LocalSystemアカウントを使用して管理サービスをサービスとして実行するように構成できます。これはローカル・アカウントであり、通常、ドメイン認証が必要な共有ファイルシステムのネットワーク・ドライブにアクセスできません。この問題を解決するには、次のように管理サービスをドメイン・ユーザーとして実行するように構成します。
「コントロール パネル」に移動して「サービス」パネルを開きます。
該当のサービス（Oracleoms11gProcessManager）をダブルクリックします。
「ローカル システム アカウント」の「ログオン」ユーザーを「アカウント」に変更します。
共有ネットワーク・ドライブにアクセスできるドメイン・ユーザーを指定します。
「OK」をクリックします。
Windowsで共有ファイルシステムを構成する際、マップ・ネットワーク共有にローカル・ドライブ名を使用しないでください。かわりにUNCの場所を使用します。
emctl config oms loader -shared yes -dir \\\\<host>\\<share-name>\\<recv-dir> for example emctl config oms loader -shared yes -dir \\\\hostA\\vol1\\recv
ディレクトリの場所を指定する際は、二重のバックスラッシュを使用することに注意してください。
|
注意: ローダー・ディレクトリのOMSで作成されたファイルを他のOMSで変更できるように、ユーザー等価をOMS間で適切に設定する必要があります。 |
ソフトウェア・ライブラリの場所にはすべての管理サービスからアクセスできるようにする必要があるため、共有ファイルシステム・ローダー・ディレクトリと同様の考慮事項がここでも適用されます。ソフトウェア・ライブラリの構成はインストール時に行われません。構成は、Enterprise Managerコンソールを使用してインストール後に行う必要があります。
Enterprise Managerのホームページで「デプロイ」タブをクリックします。
「プロビジョニング」サブタブをクリックします。
「プロビジョニング」ページで「管理」サブタブをクリックします。
「ソフトウェア・ライブラリ構成」セクションで「追加」をクリックして、「ソフトウェア・ライブラリのディレクトリの場所」を、管理サービスを実行するホストからアクセス可能な共有記憶域に設定します。
この項では、複数の管理サービスに対するエージェントとブラウザのトラフィックを均等にするサーバー・ロード・バランサ（SLB）を設定するためのガイドラインについて説明します。設定には次の2つの手順があります。
SLBの構成
管理サービスで必要な変更の追加
次の表を参考にしてGrid Control管理サービスでSLBを設定します。
表18-1 管理サービスのポート
| Grid Controlサービス | TCPポート | モニター名 | 永続性 | プール名 | ロード・バランシング | 仮想サーバー名 | 仮想サーバー・ポート |
|---|---|---|---|---|---|---|---|
|
セキュア・アップロード |
1159 |
mon_gcsu1159 |
なし |
pool_gcsu1159 |
ラウンド・ロビン |
vs_gcsu1159 |
1159 |
|
エージェント登録 |
4889 |
mon_gcar4889 |
有効なCookie挿入 |
pool_gcar4889 |
ラウンド・ロビン |
vs_gcar4889 |
4889 |
|
セキュア・コンソール |
7799 |
mon_gcsc7799 |
ソースIP |
pool_gcsc7799 |
ラウンド・ロビン |
vs_gcsc443 |
443 |
|
非保護コンソール（オプション） |
7788 |
mon_gcuc7788 |
ソースIP |
pool_gcuc7788 |
ラウンド・ロビン |
vs_gcuc80 |
80 |
SLBにパッケージされている管理ツールを使用します。サンプル構成が付属しています。この例では、表18-0に示すデフォルトのポートを使用してホストAおよびホストBで2つの管理サービスが実行していると仮定します。
プールの作成
プールは、ロード・バランシング方法を使用して特定のTCPポートでトラフィックを受信するためにグループ化された一連のサーバーです。各プールには、永続性の定義の独自の特性と、使用されるロード・バランシング・アルゴリズムがあります。
表18-2 プール
| プール名 | 使用方法 | メンバー | 永続性 | ロード・バランシング |
|---|---|---|---|---|
|
pool_gcsu1159 |
セキュア・アップロード |
ホストA: 1159 ホストB: 1159 |
なし |
ラウンド・ロビン |
|
pool_gcar4889 |
エージェント登録 |
ホストA: 4889 ホストB: 4889 |
アクティブなcookie挿入、有効期限は60分 |
ラウンド・ロビン |
|
pool_gcsc7799 |
保護されたコンソールへのアクセス |
ホストA: 7799 ホストB: 7799 |
ソースIP、有効期限は60分 |
ラウンド・ロビン |
|
pool_gcuc7788（オプション） |
非保護コンソールへのアクセス |
ホストA: 7788 ホストB: 7788 |
ソースIP、有効期限は60分 |
ラウンド・ロビン |
仮想サーバーの作成
仮想サーバー（仮想IPアドレスとポート番号を含む）は、クライアントのアドレス可能なホスト名またはIPアドレスであり、これによって、クライアントはロード・バランシング・プールのメンバーを利用できます。仮想サーバーがリクエストを受信すると、選択したロード・バランシング方法に基づいてそのリクエストをプールのメンバーに誘導します。
モニターの作成
モニターは、プール・メンバーの動作状況を検証する場合に使用されます。モニターは、ロード・バランシング・プールのメンバーであるノード上の接続やサービスを検証します。これは、規定の間隔でサービスのステータスを断続的に確認するように設計されます。確認するサービスが指定時間内に応答しない場合、ロード・バランサはプールから自動的にそのサービスを取り出し、プールの他のメンバーを選択します。ノードやサービスが再度使用可能になると、モニターはその状況を検出し、プールから自動的にアクセス可能なメンバーがトラフィックを処理できます。
表18-4 モニター
| モニター名 | 構成 | 関連ホスト |
|---|---|---|
|
mon_gcsu1159 |
タイプ: https 間隔: 60 タイムアウト: 181 送信文字列: GET /em/upload 受信文字列: Http Receiver Servlet active! |
ホストA: 1159 ホストB: 1159 |
|
mon_gcar4889 |
タイプ: http 間隔: 60 タイムアウト: 181 送信文字列: GET /em/genwallet 受信文字列: GenWallet Servlet activated |
ホストA: 4889 ホストB: 4889 |
|
mon_gcsc7799 |
タイプ: https 間隔: 5 タイムアウト: 16 送信文字列: GET /em/console/home HTTP/1.0\n 受信文字列: /em/console/logon/logon;jsessionid= |
ホストA: 7799 ホストB: 7788 |
|
mon_gcuc7788（オプション） |
タイプ: https 間隔: 5 タイムアウト: 16 送信文字列: GET /em/console/home HTTP/1.0\n 受信文字列: /em/console/logon/logon;jsessionid= |
ホストA: 7788 ホストB: 7788 |
注意: SSOが構成されている場合、モニターmon_gcsc7799およびmon_gcuc7788には次の代替定義を使用します。
表18-5 SSO構成のモニター
| モニター名 | 構成 | 関連ホスト |
|---|---|---|
|
mon_gcsc7799 |
タイプ: https 間隔: 5 タイムアウト: 16 送信文字列: GET /em/genwallet 受信文字列: GenWallet Servlet activated |
ホストA: 7799 ホストB: 7788 |
|
mon_gcuc7788（オプション） |
タイプ: https 間隔: 5 タイムアウト: 16 送信文字列: GET /em/genwallet 受信文字列: GenWallet Servlet activated |
ホストA: 7788 ホストB: 7788 |
|
注意: F5 SLBモニターは、「受信文字列」を応答の最初の5120文字内で予測します。SSO環境の場合、「受信文字列」は制限5120を超えた時点で返されます。モニターはこの状況では機能しません。 |
次の手順を実行します。
管理サービスを再保護します。
デフォルトでは、管理サービス側証明書のサービス名は、管理サービス・ホストの名前を使用します。管理エージェントは、ロード・バランサ経由で管理サービスと通信する場合、この証明書を受け入れません。次のコマンドを実行して、最初の管理サービスで証明書を再生成する必要があります。
emctl secure -oms -sysman_pwd <sysman_pwd> -reg_pwd <agent_reg_password> -host slb.example.com -secure_port 1159 -slb_port 1159 -slb_console_port 443 [-lock] [-lock_console]
すべての管理エージェントを再保護します。
SLB設定の前にインストールされた管理エージェント（管理サービス・インストールに付属する管理エージェントなど）は、管理サービスに直接アップロードしています。これらの管理エージェントは、SLBの設定後にアップロードできません。これらの管理エージェントを再保護してSLBにアップロードするには、各管理エージェントで次のコマンドを実行します。
emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em
最初の管理サービスを高可用性に設定した場合、追加の管理サービスを高可用性に設定するには次の2つの方法があります。
MAAベスト・プラクティスによる新規の追加管理サービスのインストール
既存の追加管理サービスへのMAAベスト・プラクティスの組込み
どちらの場合も、次の考慮事項に注意してください。
追加の管理サービスは、ネットワーク待機時間があるため、管理リポジトリ・データベースに近接するネットワークでホストする必要があります。
共有ファイルシステム・ローダーに使用されるディレクトリのすべての管理サービスで同じパスを構成します。
追加の管理サービスは、最初の管理サービスと同じOSユーザーおよびグループを使用してインストールする必要があります。各管理サービスによって共有ローダー・ディレクトリに作成されるファイルに他の管理サービス・プロセスからアクセスしてそのファイルを変更できるように、適切なユーザー等価を設定する必要があります。
管理リポジトリ・データベースのパラメータを調整します。たとえば、データベースへの同時接続が可能なプロセスの数を増やす必要があります。必要なプロセスの数は環境全体やデータベースへの特定のロードによって異なりますが、一般的なガイドラインとして、追加する管理サービスごとにプロセスの数を40増やす必要があります。
OUIインストーラを使用して追加の管理サービスをインストールします。追加の管理サービスは、最初の管理サービスのHA構成の大部分を継承します。インストール後、次の手順を実行してHA構成を完了します。
SLBで別のプールに追加の管理サービスを追加して、SLB構成を更新します。新しい管理サービスのモニターを設定します。
追加の管理サービスをインストールした場合、次の手順で最初の管理サービスの構成をコピーします。
emctl exportconfig oms -dir <location for the export file>を使用して、最初の管理サービスから構成をエクスポートします。
エクスポートしたファイルを追加の管理サービスにコピーします。
追加の管理サービスを停止します。
emctl importconfig oms -file <full path of the export file>を使用して、エクスポートした構成を追加の管理サービスにインポートします。
追加の管理サービスを再起動します。
emcli setup -url=https://slb.example.com/em -username sysman -password <sysmanパスワード> -nocertvalidateを使用してEMCLIを設定します。
emctl secure agent -emdWalletSrcUrl https://slb.example.com:<upload port>/emを使用して、SLBにアップロードする追加の管理サービスとともにインストールされる管理エージェントを再保護します。
SLBで別のプールに追加の管理サービスを追加して、SLB構成を更新します。新しい管理サービスのモニターを設定します。UIアクセスに使用されるSLB仮想ポートにポート・ディレクティブを設定するようにssl.confファイルを変更します。
Enterprise Managerの高可用性の最終手順として、管理エージェントを構成します。管理エージェントに即時利用可能な高可用性が組み込まれている点に価値があります。管理エージェントの起動で自動的に作成されるウォッチドッグ・プロセスは、管理エージェント・プロセスを監視します。管理エージェント・プロセスに障害が発生した場合、ウォッチドッグは、管理エージェント・プロセスの再起動を自動で試みます。
デフォルトのEnterprise Manager Grid Controlインストールでの管理エージェント層と管理サービス層との間の通信は、ポイントツーポイントの設定になります。そのため、デフォルトの構成では、管理サービスが利用可能になるシナリオは保護されません。そのシナリオでは、管理エージェントは管理サービス（および管理リポジトリ）に監視情報をアップロードできないため、管理エージェントが別の管理サービスを指し示すように手動で構成されるまでターゲットは監視されない状態になります。
この状況を回避するには、管理エージェントと管理サービス間でハードウェアのサーバー・ロード・バランサ（SLB）を使用します。ロード・バランサは、各管理サービスの状態とステータスを監視し、どのタイプの障害が発生した場合でも、確立された接続をロード・バランサ経由で稼働中の管理サービス・ノードに誘導します。SLBを使用する場合、Enterprise Managerとのユーザー通信を管理するようにロード・バランサを構成できるというメリットもあります。ロード・バランサは、使用可能なリソースのプールを作成して通信を処理します。
SLB経由で通信する管理エージェントの構成
ロード・バランサは、すべての管理エージェントが使用できる仮想IPアドレスを提供します。ロード・バランサを設定した場合、SLB経由で管理サービスに管理エージェントのトラフィックをルーティングするようにエージェントを構成する必要があります。これを行うには、管理エージェントでプロパティ・ファイルにいくつかの変更を加えます。
すべての管理エージェントを再保護します。SLB設定の前にインストールされた管理エージェントは、管理サービスに直接アップロードしています。これらの管理エージェントは、SLBの設定後にアップロードできません。これらの管理エージェントを再保護してSLBにアップロードするには、各管理エージェントで次のコマンドを実行します。
emctl secure agent -emdWalletSrcUrl https://slb.example.com:<upload port>/em
SLBの組込みを許可する管理エージェントの構成
一部のインストールでは最初のインストール時にSLBにアクセスできませんが、後からSLBを追加する必要があるかどうかを予測できます。この場合、最初のインストールの一環としてSLBに使用される仮想IPアドレスを構成し、そのIPアドレスが既存の管理サービスを指し示すようにします。管理エージェントと管理サービス間のセキュアな通信は、ホスト名に基づきます。新しいホスト名が後から導入される場合、各管理エージェントはSLBで維持される新しい仮想IPを指し示すように構成されるため、再保護する必要はありません。
管理エージェントから管理サービスへの管理データのフローを保護する計画を実装する前に、いくつかの主な概念を認識する必要があります。
具体的には、管理エージェントは、管理サービスに対する永続的な接続は維持しません。管理エージェントは収集された監視データやターゲット状態の緊急の変更をアップロードする必要がある場合、管理サービスへの接続を確立します。ネットワーク障害やホストの不具合などで接続できない場合、管理エージェントはデータを保持し、後から情報の送信を再試行します。
管理サービスが使用できない状況を保護するには、管理エージェントと管理サービス間でロード・バランサを使用できます。
ただし、このような構成を実装する場合、管理データのアップロードをロード・バランシングする際のデータのフローを必ず把握してください。
図18-5は、一連の管理エージェントがそのデータをロード・バランサにアップロードし、データが2つの管理サービス・インストールのいずれかにリダイレクトされる典型的なシナリオを示しています。
この例では、管理エージェント・データのアップロードのみがロード・バランサでルーティングされます。Grid Controlコンソールでは、引き続き一意の管理サービス・アップロードURLによって単一の管理サービスに直接接続します。この抽象的な概念により、いずれかの管理サービス・コンポーネントが失われたかどうかにかかわらず、Grid Controlは管理エージェントとGrid Controlコンソールの両方に一貫したURLを表示できます。
管理サービス・データのアップロードを複数の管理サービス・インストールにロード・バランスする場合、データは次の経路で送られます。
各管理エージェントは、そのデータを共通のロード・バランサURLにアップロードします。このURLは、各管理エージェントのemd.propertiesファイルで定義されます。つまり、管理エージェントは、ロード・バランサで公開される仮想サービスに接続します。ロード・バランサは、リクエストされたサービスを提供するいずれかの利用可能なサーバーにそのリクエストをルーティングします。
各管理サービスは、データを受け取るとすぐにローカル・ファイルにデータを一時的に格納し、管理エージェントに受信を知らせます。その後管理サービスはサービス間で調整し、いずれかのサービスがバックグラウンド・スレッドでデータを正しい年代順にロードします。
また、各管理サービスはJDBC経由で共通の管理リポジトリと通信します。これは、「複数の管理サービスのインストールの使用」で定義する複数の管理サービス構成の場合と同様です。
各管理サービスはHTTP経由で各管理エージェントと直接通信します。これは、「複数の管理サービスのインストールの使用」で定義する複数の管理サービス構成の場合と同様です。
通常、高可用性がアプリケーション障害やシステムレベルの問題などのローカルの故障を保護するのに対して、耐障害性は、自然災害、火災、停電、排気、広範囲の妨害行為によるデータセンターの壊滅的な障害などの大規模な故障を保護します。可用性が最大の場合、サイトの損失が原因で、エンタープライズを処理する管理ツールの障害が発生することはありません。
Enterprise Managerの最大可用性アーキテクチャでは、プライマリ管理インフラストラクチャが災害による被害を受けた場合、セカンダリ・データセンターが管理インフラストラクチャを引き継ぐことができるリモート・フェイルオーバー・アーキテクチャのデプロイが義務付けられています。
図18-6に示すように、Enterprise Managerの障害リカバリの設定は、スタンバイRAC、スタンバイ管理サービス、スタンバイ・サーバー・ロード・バランサをインストールし、プライマリ・コンポーネントの障害発生時にこれらを自動起動する仕組みで基本的に構成されています。
次の項では、Enterprise Managerの主要コンポーネントを障害リカバリ用に構成するベスト・プラクティスを示します。
次の前提条件を満たす必要があります。
前述の項で説明したGrid Control MAAガイドラインのとおりにプライマリ・サイトを構成します。管理サービスの前にSLBがあり、すべての管理エージェントは、SLBによって管理サービスにアップロードするように構成されます。
スタンバイ・サイトは、ファイルオーバーの発生時にパフォーマンスが損なわれないように、ハードウェアとネットワークのリソースの点でプライマリ・サイトと同様にしてください。
最大量のREDOデータの生成を処理するために、プライマリ・サイトとスタンバイ・サイト間に十分なネットワーク・バンド幅が必要です。
プライマリ・サイトとスタンバイ・サイトでレプリケートする共有ファイルシステム・ローダーとソフトウェア・ライブラリに使用される共有記憶域を構成します。サイトで障害が発生した場合、ハードウェア・ベンダーのディスク・レベル・レプリケーション技術を使用して該当の共有記憶域の内容をスタンバイ・サイトで利用できるようにする必要があります。
障害リカバリ環境で完全な冗長性を確保するには、別のロード・バランサをスタンバイ・サイトにインストールしておきます。セカンダリSLBをプライマリと同じ方法で構成する必要があります。一部のSLBベンダー（F5 Networksなど）では、サイトで障害が発生した場合に、プライマリ・サイトのSLBで提供される仮想IPの制御を、スタンバイ・サイトのSLBに渡す際に使用可能な追加サービスが提供されます。このサービスを使用すると、プライマリ・サイトからスタンバイ・サイトへの管理エージェント・トラフィックの自動切替えが容易になります。
この手順は、Grid Control MAAガイドラインによるプライマリ・サイトの構成で開始します。次に、スタンバイ管理リポジトリ・データベースを設定する手順を示します。
Data Guard用のスタンバイ管理リポジトリ・ホストを準備します。
スタンバイ管理リポジトリの各ホストに管理エージェントをインストールします。プライマリ・サイトのSLBでアップロードするように管理エージェントを構成します。スタンバイ管理リポジトリ・ホストにCRSおよびデータベース・ソフトウェアをインストールします。プライマリ・サイトと同じバージョンを使用してください。
Data Guard用のプライマリ管理リポジトリ・データベースを準備します。
プライマリ管理リポジトリ・データベースがまだ構成されていない場合、アーカイブ・ログ・モードを有効にして、フラッシュ・リカバリ領域を設定し、プライマリ管理リポジトリ・データベースのフラッシュバック・データベースを有効にします。
物理スタンバイ・データベースを作成します。
Enterprise Managerでは、スタンバイ管理リポジトリ・データベースは物理スタンバイにします。Enterprise Managerコンソールを使用して、スタンバイ環境で物理スタンバイ・データベースを設定します。Enterprise Managerコンソールでは、スタンバイRACデータベースの作成はサポートされていません。スタンバイ・データベースをRACにする必要がある場合、単一インスタンスを使用してスタンバイ・データベースを構成し、Enterprise Managerコンソールの「RACデータベースへの変換」オプションを使用して、単一インスタンスのスタンバイ・データベースをRACに変換します。また、単一インスタンスのスタンバイ作成時に、後でRACへの変換が容易になるようにデータベース・ファイルを共有記憶域に作成しておく必要があります。
「RACデータベースへの変換」オプションは、Oracle Databaseリリース10.2.0.5、11.1.0.7以上で使用できます。Oracle Databaseリリース11.1.0.7の場合、「RACデータベースへの変換」オプションが機能するにはパッチ8824966が必要です。
リスナーに静的サービスを追加します。
ブローカ操作時にインスタンスを再起動するようにData Guardを有効にするには、特定の名前のサービスを、各インスタンスのローカル・リスナーに静的に登録する必要があります。GLOBAL_DBNAME属性の値は、連結文字列<db_unique_name>_DGMGRL.<db_domain>に設定してください。たとえば、LISTENER.ORAファイルでは次のようになります。
SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME=sid_name)
(GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain)
(ORACLE_HOME=oracle_home)))
スタンバイ・データベースでフラッシュバック・データベースを有効にします。
物理スタンバイを検証します。
Enterprise Managerコンソールで物理スタンバイ・データベースを検証します。「Data Guard」ページでログ切替えボタンをクリックしてログを切り替え、切替えが受け入れられてスタンバイ・データベースに適用されていることを検証します。
スタンバイ管理サービスをインストールする前に、次の内容を検討します。
Oracleでは、このアクティビティを限られた期間あるいは計画されたメンテナンスの時間帯に行うことをお薦めします。新しい管理サービスをスタンバイ・サイトにインストールする場合、その管理サービスはプライマリ・サイトの管理リポジトリ・データベースに接続するように最初に構成されます。一部のワークロードが新しい管理サービスによって引き継がれます。このため、スタンバイ・サイトの管理サービスの場所がプライマリ・サイトの管理リポジトリ・データベースとかなり離れている場合は、パフォーマンスが一時的に失われることがあります。ただし、データ損失はなく、スタンバイ管理サービスを構成後に停止すると、パフォーマンスは回復します。
共有ファイルシステム・ローダーやソフトウェア・ライブラリに使用される共有記憶域は、プライマリ・サイトと同じパスを使用してスタンバイ・サイトで使用できるようにする必要があります。
次の手順で最初のスタンバイ管理サービスをインストールします。
プライマリ・サイトの最初の管理サービスで次のコマンドを実行して、管理リポジトリにemkeyをコピーします。
emctl config emkey -copy_to_repos
次の引数を指定してインストーラを実行し、ソフトウェア専用インストールを行います。
runInstaller -noconfig -validationaswarnings
個別パッチを適用します。
<OMS Oracle Home>/install/oneoffs/apply_NewOneoffs.pl <OMS Oracle Home> OC9321514,9207217
スタンバイ・モードでomscaを実行して管理サービスを構成します。スタンバイ用の別のドメイン名を選択します。たとえば、プライマリWebLogicドメインがGCDomainの場合、GCDomainStbyを選択します。
omsca standby DOMAIN_NAME GCDomainStby -nostart
管理リポジトリの詳細が求められた場合、プライマリ・データベースの詳細を指定します。
次のコマンドを実行して仮想アドオンを構成します。
addonca -oui -omsonly -name vt -install gc
管理サービスのインストールに付属する管理エージェントを次のコマンドを実行して構成します。
<Agent Oracle Home>/bin/agentca -f
次のコマンドを使用して、プライマリ管理サービスから構成をエクスポートします。
emctl exportconfig oms -dir <エクスポートの場所>
エクスポートしたファイルをスタンバイ管理サービスにコピーします。
次のコマンドを使用して、エクスポートした構成をスタンバイ管理サービスにインポートします。
emctl importconfig oms -file <エクスポート・ファイルのフルパス>
追加のスタンバイ管理サービスを次のようにインストールします。
インストーラの画面で、プライマリ・データベースの詳細とスタンバイ管理サーバーの詳細を指定します。インストール後、次の手順を実行してHA構成を完了します。
次の引数を指定してインストーラを実行し、ソフトウェア専用インストールを行います。
runInstaller -noconfig -validationaswarnings
個別パッチを適用します。
<OMS Oracle Home>/install/oneoffs/apply_NewOneoffs.pl <OMS Oracle Home> OC9321514,9207217
omscaを実行して管理サービスを構成します。管理リポジトリの詳細が求められた場合、プライマリ・データベースの詳細を指定します。管理サーバーの詳細が求められた場合、スタンバイ管理サーバーの詳細を指定します。
omsca add –nostart
次のコマンドを実行して仮想アドオンを構成します。
addonca -oui -omsonly -install gc
管理サービスのインストールに付属する管理エージェントを次のコマンドを実行して構成します。
<Agent Oracle Home>/bin/agentca -f
次のコマンドを使用して、プライマリ管理サービスから構成をエクスポートします。
emctl exportconfig oms -dir <エクスポートの場所>
エクスポートしたファイルをスタンバイ管理サービスにコピーします。
次のコマンドを使用して、エクスポートしたファイルをスタンバイ管理サービスにインポートします。
emctl importconfig oms -file <エクスポート・ファイルのフルパス>
次のように、インストールを検証して設定を完了します。
SLBで別のプールにスタンバイ管理サービスを追加して、スタンバイSLB構成を更新します。新しい管理サービスのモニターを設定します。
最初のスタンバイ管理サービスで次のコマンドを実行して、スタンバイ管理サービスがスタンバイ管理リポジトリ・データベースを指し示すようにします。
emctl config oms -store_repos_details -repos_conndesc <connect descriptor of standby database> -repos_user sysman -no_check_db
各管理サービスで次のコマンドを実行してすべての管理サービスを停止します。
emctl stop oms -all
スイッチオーバーは、プライマリ・サイトからスタンバイ・サイトに操作が転送される計画的なアクティビティです。これは、通常、障害リカバリ（DR）・シナリオのテストや検証、プライマリ・インフラストラクチャでの計画されたメンテナンス・アクティビティの場合に行われます。この項では、スタンバイ・サイトへのスイッチオーバーの手順について説明します。どの方向にスイッチオーバーする場合も同じ手順が適用されます。
Enterprise Managerコンソールを使用して、管理リポジトリ・データベースのスイッチオーバーを行うことはできません。Data Guard BrokerコマンドラインのツールDGMGRLをかわりに使用します。
スタンバイ・データベースを準備します。
リカバリが最新であることを検証します。Enterprise Managerコンソールを使用して、「Data Guardの概要」ページの「スタンバイ・データベース」セクションでスタンバイ・データベースの「適用ラグ」列の値を表示できます。
プライマリEnterprise Managerアプリケーション層を停止します。
各管理サービスで次のコマンドを実行して、プライマリ・サイトのすべての管理サービスを停止します。
emctl stop oms -all
管理リポジトリ・データベースで実行しているEnterprise Managerジョブを停止します。
- alter system set job_queue_processes=0;
共有ローダー・ディレクトリ/ソフトウェア・ライブラリの可用性を検証します。
プライマリ・サイトのすべてのファイルがスタンバイ・サイトで使用できることを確認します。
スタンバイ・データベースにスイッチオーバーします。
DGMGRLを使用して、スタンバイ・データベースへのスイッチオーバーを実行します。プライマリ・サイトまたはスタンバイ・サイトでコマンドを実行できます。スイッチオーバー・コマンドは、プライマリ・データベースとスタンバイ・データベースの状態を検証し、ロールのスイッチオーバーに影響を与えます。また、古いプライマリ・データベースを再起動してそのデータベースを新しいスタンバイ・データベースとして設定します。
SWITCHOVER TO <standby database name>;
スイッチオーバー後の状態を検証します。スタンバイ・データベースを完全に監視するには、データベースを監視するユーザーにSYSDBA権限が必要です。スタンバイ・データベースはマウント専用状態であるため、この権限が必要になります。プライマリ・データベースとスタンバイ・データベースを監視するユーザーに両方のデータベースのSYSDBA権限があればベスト・プラクティスになります。
SHOW CONFIGURATION; SHOW DATABASE <primary database name>; SHOW DATABASE <standby database name>;
Enterprise Managerアプリケーション層を起動します。
スタンバイ・サイトのすべての管理サービスを起動します。
emctl start oms
スタンバイ・サイトの管理リポジトリ・データベース（新しいプライマリ・データベース）で実行しているEnterprise Managerジョブを起動します。
- alter system set job_queue_processes=10;
管理サービスと管理リポジトリ・ターゲットを再配置します。
管理サービスと管理リポジトリ・ターゲットは、プライマリ・サイトのいずれかの管理サービス上の管理エージェントで監視されます。スイッチオーバー/フェイルオーバー後にターゲットが監視されるようにするには、スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行して、そのターゲットをスタンバイ・サイトの管理サービスに再配置します。
emctl config emrep -agent <agent name> -conn_desc
スタンバイSLBにスイッチオーバーします。
プライマリSLBをスタンバイSLBにフェイルオーバーするには、ネットワークの適切な変更を行います。つまり、クライアント（ブラウザおよび管理エージェント）で変更を行わずに、すべてのリクエストをスタンバイSLBで処理するようにします。
これでスイッチオーバー操作は完了です。アプリケーションにアクセスし、サイトが完全に機能してプライマリ・サイトの機能と同じであるかどうかをテストします。これ以外の方向にスイッチオーバーする場合も同じ手順を繰り返します。
元のプライマリ・データベースに障害が発生し、プライマリ・データベースがすぐにリカバリする可能性がない場合、スタンバイ・データベースをプライマリ・データベースに変換できます。これは手動フェイルオーバーと呼ばれます。プライマリ・データベースの障害発生時にプライマリ・データベースとターゲットのスタンバイ・データベースが同期化していたかどうかによって、データ損失の有無が決まります。
この項では、スタンバイ・データベースにフェイルオーバーして、Enterprise Managerのアプリケーション状態をリカバリする手順について説明します。これは、管理リポジトリ・データベースをすべての管理エージェントと再同期化し、フラッシュバック・データベースを使用して元のプライマリ・データベースをスタンバイとして有効にすることで行います。
ここで手動という言葉は、以降に「自動フェイルオーバー」で説明するファスト・スタート・フェイルオーバーのフェイルオーバーと対比する場合に使用されます。
共有ローダー・ディレクトリおよびソフトウェア・ライブラリの可用性を検証します。
プライマリ・サイトのすべてのファイルがスタンバイ・サイトで使用できることを確認します。
スタンバイ・データベースにフェイルオーバーします。
プライマリ・サイトでデータベースを停止します。DGMGRLを使用してスタンバイ・データベースに接続し、FAILOVERコマンドを実行します。
FAILOVER TO <standby database name>;
フェイルオーバー後の状態を検証します。
SHOW CONFIGURATION; SHOW DATABASE <primary database name>; SHOW DATABASE <standby database name>;
フェイルオーバーの完了後、元のプライマリ・データベースを再度有効にしないかぎり、そのデータベースを新しいプライマリ・データベースのスタンバイ・データベースとして使用することはできません。
新しいプライマリ・データベースと管理エージェントを再同期化します。
Data Guardの最大保護または最大可用性レベルで実行している場合、フェイルオーバーでのデータ損失はないため、この手順を省略します。ただし、データ損失がある場合は、新しいプライマリ・データベースとすべての管理エージェントを同期化します。
スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行します。
emctl resync repos -full -name "<name for recovery action>"
このコマンドは、スタンバイ・サイトの管理サービスの起動時に各管理エージェントで実行される再同期化ジョブを発行します。
リポジトリの再同期化はリソース集中型操作です。管理リポジトリが十分に調整されていれば、操作はできるだけ早く完了できます。特にMy Oracle Supportのノート271855.1の説明に従ってアドバンスト・キューイング表に関連するIOT/索引を日常的にまとめていない場合、再同期化の前に手順を実行すると、再同期化操作をさらに速く終わらせる場合にかなり役立ちます。
Enterprise Managerアプリケーション層を起動します。
各管理サービスで次のコマンドを実行して、スタンバイ・サイトのすべての管理サービスを起動します。
emctl start oms
管理サービスと管理リポジトリ・ターゲットを再配置します。
管理サービスと管理リポジトリ・ターゲットは、プライマリ・サイトのいずれかの管理サービス上の管理エージェントで監視されます。スイッチオーバー/フェイルオーバー後にターゲットが監視されるようにするには、スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行して、そのターゲットをスタンバイ・サイトの管理エージェントに再配置します。
emctl config emrep -agent <agent name> -conn_desc
スタンバイSLBにスイッチオーバーします。
プライマリSLBをスタンバイSLBにフェイルオーバーするには、ネットワークの適切な変更を行います。つまり、クライアント（ブラウザおよび管理エージェント）で変更を行わずに、すべてのリクエストをスタンバイSLBで処理するようにします。
フラッシュバックを使用して元のプライマリ・データベースをスタンバイ・データベースとして設定します。
障害が発生したサイトへのアクセスがリストアされると、フラッシュ・バックデータベースが有効な場合、元のプライマリ・データベースを、新しいプライマリ・データベースの物理スタンバイとして回復できます。
元のプライマリ・サイトですべての管理サービスを停止します。
emctl stop oms -all
元のプライマリ・データベースをマウント状態で再起動します。
shutdown immediate;
startup mount;
元のプライマリ・データベースを回復します。
DGMGRLを使用して古いプライマリ・データベースに接続し、REINSTATEコマンドを実行します。
REINSTATE DATABASE <old primary database name>;
新たに回復されたスタンバイ・データベースは、新しいプライマリ・データベースに対するスタンバイ・データベースとしての機能を開始します。
回復後の状態を検証します。
SHOW CONFIGURATION; SHOW DATABASE <primary database name>; SHOW DATABASE <standby database name>;
リポジトリの再同期化を監視して完了します。
Grid Controlコンソールの「管理サービスとリポジトリ概要」ページにナビゲートします。「関連リンク」で「リポジトリの同期化」をクリックします。このページには、管理エージェントごとに再同期化操作の進捗状況が表示されます。進捗状況を監視します。
このページでは、表示されたエラーの修正後に、失敗した操作を手動で再発行する必要があります。一般的に通信関連のエラーは管理エージェントの停止が原因で発生するため、管理エージェントの再起動後にこのページで操作を再発行することでエラーを修正できます。
たとえば、停止した古い管理エージェントなど、管理エージェントがなんらかの理由で起動できない場合、このページで操作を手動で停止する必要があります。再同期化は、すべてのジョブのステータスが「完了」または「停止中」になると完了とみなされます。
これでフェイルオーバー操作は完了です。アプリケーションにアクセスし、サイトが完全に機能してプライマリ・サイトの機能と同じであるかどうかをテストします。サイトの操作を元のプライマリ・サイトに戻す必要がある場合は、スイッチオーバー手順を実行します。
この項では、ファスト・スタート・フェイルオーバーおよびオブザーバ・プロセスを使用して、障害検出とフェイルオーバー手順を完全に自動化する方法について説明します。プロセスは高度なレベルで次のように機能します。
ファスト・スタート・フェイルオーバー（FSFO）は、フェイルオーバーが必要かどうかを判断し、スタンバイ・データベースへのフェイルオーバーを自動的に開始します。
データベースのフェイルオーバーが完了すると、DB_ROLE_CHANGEデータベース・イベントが開始します。
このイベントにより、Enterprise Managerアプリケーション層を構成および開始するスクリプトをコールするトリガーが起動します。
次の手順を実行します。
Enterprise Managerアプリケーション層の構成を作成してスクリプトを起動します。
Enterprise Managerアプリケーション層の構成を自動化してプロセスを起動するスクリプトを開発します。OH/sysman/haディレクトリにある、Grid Controlに付属のサンプルを参照してください。スタンバイ・サイトのサンプル・スクリプトはこのディレクトリに含まれており、必要に応じてカスタマイズします。パスワードが求められずにリモートのシェル・スクリプトを実行できるようにssh等価が設定されていることを確認します。スタンバイ・データベース・ホストからアクセスできる場所にスクリプトを置きます。プライマリ・サイトに同様のスクリプトを置きます。
#!/bin/sh # Script: /scratch/EMSBY_start.sh # Primary Site Hosts # Repos: earth, OMS: jupiter1, jupiter2 # Standby Site Hosts # Repos: mars, # OMS: saturn1, saturn2 LOGFILE="/net/mars/em/failover/em_failover.log" OMS_ORACLE_HOME="/scratch/OracleHomes/em/oms11" CENTRAL_AGENT="saturn1.example.com:3872" #log message echo "###############################" >> $LOGFILE date >> $LOGFILE echo $OMS_ORACLE_HOME >> $LOGFILE id >> $LOGFILE 2>&1 #startup all OMS #Add additional lines, one each per OMS in a multiple OMS setup ssh orausr@saturn1 "$OMS_ORACLE_HOME/bin/emctl start oms" >> $LOGFILE 2>&1 ssh orausr@saturn2 "$OMS_ORACLE_HOME/bin/emctl start oms" >> $LOGFILE 2>&1 #relocate Management Services and Repository target #to be done only once in a multiple OMS setup #allow time for OMS to be fully initialized ssh orausr@saturn1 "$OMS_ORACLE_HOME/bin/emctl config emrep -agent $CENTRAL_AGENT -conn_desc -sysman_pwd <password>" >> $LOGFILE 2>&1 #always return 0 so that dbms scheduler job completes successfully exit 0
トリガーによるスクリプトの実行を自動化します。
データベース・イベントDB_ROLE_CHANGEトリガーを作成します。これは、データベースのロールがスタンバイからプライマリに変わると起動します。OH/sysman/haディレクトリにある、Grid Controlに付属のサンプルを参照してください。
--
--
-- Sample database role change trigger
--
--
CREATE OR REPLACE TRIGGER FAILOVER_EM
AFTER DB_ROLE_CHANGE ON DATABASE
DECLARE
v_db_unique_name varchar2(30);
v_db_role varchar2(30);
BEGIN
select upper(VALUE) into v_db_unique_name
from v$parameter where NAME='db_unique_name';
select database_role into v_db_role
from v$database;
if v_db_role = 'PRIMARY' then
-- Submit job to Resync agents with repository
-- Needed if running in maximum performance mode
-- and there are chances of data-loss on failover
-- Uncomment block below if required
-- begin
-- SYSMAN.setemusercontext('SYSMAN', SYSMAN.MGMT_USER.OP_SET_IDENTIFIER);
-- SYSMAN.emd_maintenance.full_repository_resync('AUTO-FAILOVER to '||v_db_unique_name||' - '||systimestamp, true);
-- SYSMAN.setemusercontext('SYSMAN', SYSMAN.MGMT_USER.OP_CLEAR_IDENTIFIER);
-- end;
-- Start the EM mid-tier
dbms_scheduler.create_job(
job_name=>'START_EM',
job_type=>'executable',
job_action=> '<location>' || v_db_unique_name|| '_start_oms.sh',
enabled=>TRUE
);
end if;
EXCEPTION
WHEN OTHERS
THEN
SYSMAN.mgmt_log.log_error('LOGGING', SYSMAN.MGMT_GLOBAL.UNEXPECTED_ERR,
SYSMAN.MGMT_GLOBAL.UNEXPECTED_ERR_M || 'EM_FAILOVER: ' ||SQLERRM);
END;
/
|
注意: 使用するデプロイメントに基づき、ローダー受信ディレクトリとソフトウェア・ライブラリに使用されるSLBおよび共有記憶域のフェイルオーバーを同期化および自動化するには追加の手順が必要です。これらの手順はベンダーに固有のものなので、本書では扱いません。Enterprise Managerアプリケーション層の起動および構成スクリプトからこれらの手順を開始する方法もあります。 |
ファスト・スタート・フェイルオーバーおよびオブザーバを構成します。
Enterprise Managerコンソールのファスト・スタート・フェイルオーバー構成ウィザードで、FSFOを有効にしてオブザーバを構成します。
これで、フェイルオーバーの自動化の設定が完了です。
次の項では、各Grid Controlコンポーネントのインストールおよび構成に関するベスト・プラクティスについて説明します。
管理エージェントは手動で起動します。ホストのブート時に管理対象ホストで重要なリソースの監視が確実に行われるようにするには、管理エージェントが自動で起動することが重要になります。そのためには、オペレーティング・システムのメカニズムの一部および全部を使用して管理エージェントを自動的に起動します。たとえば、UNIXシステムの場合はブート時に管理エージェントをコールするエントリをUNIX /etc/init.dに置きます。あるいは、自動的に起動するWindowsサービスを設定します。
管理エージェントを起動すると、ウォッチドッグ・プロセスは管理エージェントを監視し、障害が発生した場合にエージェントの再起動を試みます。ウォッチドッグの動作は、管理エージェント・プロセスの開始前に設定される環境変数で制御します。この動作を制御する環境変数は次のとおりです。ここで説明するテストはすべて、デフォルトの設定で行われました。
EM_MAX_RETRIES: ウォッチドッグがEM_RETRY_WINDOW内で管理エージェントの再起動を試行する最大回数。デフォルトでは、管理エージェントを3回再起動します。
EM_RETRY_WINDOW: EM_MAX_RETRIES環境変数と一緒に使用される時間間隔（秒単位）。管理エージェントを再起動するかどうかを判断します。デフォルトは600秒です。
ウォッチドッグが、EM_RETRY_WINDOW期間内でEM_MAX_RETRIESの回数を超えた管理エージェントの再起動が必要であることを検出すると、管理エージェントは再起動されません。
管理エージェントは、管理エージェント・ホーム・ディレクトリの$AGENT_HOME/$HOSTNAME/sysman/emdサブ・ツリーのローカル・ファイルを使用して、その中間状態と収集された情報を保持します。
これらのファイルが管理リポジトリにアップロードされる前に損失または破損した場合、監視データの損失や、管理リポジトリにアップロードされていない保留中のアラートが発生します。
少なくとも、ストライプ化またはミラー化された冗長記憶域でこれらのサブディレクトリを構成します。可用性をさらに強化するには、冗長記憶域に$AGENT_HOME全体を置きます。管理エージェントのホーム・ディレクトリを表示するには、コマンドラインにコマンドemctl getemhomeを入力するか、Grid Controlコンソールの「管理サービスとリポジトリ」タブおよび「エージェント」タブで表示します。
管理サービスには、管理リポジトリにロードされる前に収集された中間データの結果が含まれます。ローダー受信ディレクトリにはこれらのファイルが含まれます。管理サービスがデータを受信してすぐにそのデータをロードできる場合、このディレクトリは通常は空になります。管理サービスでファイルを受信すると、管理エージェントは、そのファイルをコミット済とみなすため、そのローカル・コピーを削除します。これらのファイルが管理リポジトリにアップロードされる前に失われた場合、データは損失します。少なくとも、ストライプ化またはミラー化された冗長記憶域でこれらのサブディレクトリを構成します。管理サービスを共有ファイルシステム・ローダー用に構成する場合、すべてのサービスで同じローダー受信ディレクトリを共有します。共有ローダー受信ディレクトリは、NetApps Filerなどのクラスタ化されたファイルシステムに置くことをお薦めします。
Grid Controlには、あらかじめ構成された一連のデフォルト・ルールがあり、多くの共通ターゲットを監視します。これらのルールを拡張して、Grid Controlインフラストラクチャと、ネットワーク上の他のターゲットを監視し、特定の監視ニーズを満たすことができます。
次に、Enterprise Managerで実行されるデフォルトの監視を拡張する一連の推奨事項を示します。「プリファレンス」ページの「通知ルール」リンクを使用して、構成/ルールページで提供されるデフォルトのルールを調整します。
「エージェント使用不可」ルールが、使用不可のすべての管理エージェントでアラートを発生するように設定され、管理エージェントでエラーが消去されることを確認します。
リポジトリ操作の可用性ルールが、管理サービスまたは管理リポジトリのノードに関する使用不可の問題を通知するように設定されていることを確認します。また、「データを提供しないターゲット」条件でアラートを通知し、管理リポジトリとして機能するデータベースに対して検出されるデータベース・アラートを通知するようにこのルールを変更します。
管理サービスのステータスで警告またはしきい値のクリアがヒットした場合にアラートが発生するようにリポジトリ操作の可用性ルールを変更します。
Enterprise Managerでは、電子メール通知、PL/SQLパッケージ、SNMPアラートによるエラー・レポート・メカニズムが提供されます。これらのメカニズムは本番サイトのインフラストラクチャに基づき構成します。通知に電子メールを使用する場合、複数のSMTPサーバーが利用可能なときにそのサーバーで管理者に通知するように、Grid Controlコンソールを使用して通知ルールを構成します。通知ルールを構成するには、「設定」の「通知メソッド」オプションでデフォルトの電子メール・サーバー設定を変更します。
データベースのバックアップ手順は確立されています。Grid Controlコンソールで提供されるRMANインタフェースを使用して、管理リポジトリのバックアップを構成します。実装方法の詳細は、RMANドキュメントまたは最大可用性アーキテクチャのドキュメントを参照してください。
管理リポジトリ以外に管理サービスと管理エージェントも定期的にバックアップする必要があります。バックアップは構成の変更後に行ってください。
Grid Controlに関する問題がある場合、診断作業はコンソールで開始します。「管理システム」タブでは、管理サービスのすべての操作と現在のアラートの概要にアクセスできます。その他のページには、管理サービスのプロセスの状態とログが記録されたエラーの概要が示されます。概要ページには、管理リポジトリへのロードを待機しているファイル数や、管理エージェントによる完了を待機している作業数の履歴表示が示されるため、これらのページはパフォーマンス問題の原因を判断する際に役立ちます。
Grid Controlコンソールからターゲットの状態や可用性にアクセスする場合、特に管理サービスの障害後は、UIへの情報の表示が遅くなります。Grid Controlコンソールのターゲットの状態は、監視対象ホストで状態が変わると遅れる場合があります。「管理システム」ページを使用して、処理する保留ファイルのバックログを判断します。
コールド・フェイルオーバー・クラスタ（CFC）環境とも呼ばれるアクティブおよびパッシブ環境は、一度に1つのノードでアプリケーションを実行できる高可用性ソリューションのいずれかのタイプを参照します。これらの環境は、通常、クラスタ・ソフトウェアを組み合せて使用することで、論理ホスト名とIPアドレス、インターコネクト・ホストおよび記憶域システムを提供して情報を共有し、アプリケーションの高可用性を実現します。
|
注意: 管理リポジトリとWebLogic Serverソフトウェアをホストするデータベースは、Grid Controlの実行前にインストールしておく必要があります。WebLogic Serverのインストールの詳細は、『Oracle Enterprise Manager Grid Control基本インストレーション・ガイド』を参照してください。 |
この章の内容は、次のとおりです。
この項では、Enterprise Manager Database Controlを使用するコールド・フェイルオーバー・クラスタ環境でOracle Databaseリリース11gR1を構成する場合の情報をデータベース管理者に提供します。
クラスタの別のホストへのフェイルオーバー後にDatabase Controlがデータベース・インスタンスに対応する場合、次の条件を満たしている必要があります。
データベースのインストールは仮想IPアドレスを使用して行います。
バイナリ、構成、ランタイム・データ（データベースを含む）を保持する共有ディスクやボリュームでインストールを実行します。
稼働中のノードに構成データとメタデータもフェイルオーバーします。
稼働中のノードにインベントリの場所をフェイルオーバーします。
ソフトウェア所有者とタイムゾーンのパラメータは、該当データベースをホストするクラスタ・メンバーのすべてのノードで同じにします。
次の項目は、開始前の構成とインストールに関する考慮点です。
クラスタ・メンバーの物理ホスト名を仮想ホスト名でオーバーライドするには、パラメータORACLE_HOSTNAMEを使用してソフトウェアをインストールする必要があります。
インベントリ・ポインタの場合、コマンド・パラメータinvPtrLocを使用して、共有インベントリの場所のファイルを指し示すようにソフトウェアをインストールする必要があります。このファイルには、共有インベントリの場所のパスがあります。
データベース・ソフトウェア、データベースの構成、Database Controlは共有ボリューム上にあります。
仮想ホスト名と仮想IPアドレスの別名を設定するには、クラスタウェアで自動的に設定できるようにするか、Oracleサービスのインストールおよび起動前に手動で設定します。仮想ホスト名は静的にして、ネットワークで常に解決できるようにします。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupコマンドやtracerouteコマンドと類似する標準のTCPツールを使用して設定を検証できます。
共有記憶域は、使用しているクラスタウェアで管理できます。あるいは、共有ファイルシステム・ボリューム（サポートされている場合）を使用できます。最も一般的な共有ファイルシステムはNFSです。Oracle Cluster File Systemソフトウェアも使用できます。
一部のバージョンのオペレーティング・システムでは、Oracleデータベースのリリース11gR1をインストールする前に特定のオペレーティング・システム・パッチを適用する必要があります。インストールの実行時に十分なカーネル・リソースも使用できる状態にしておく必要があります。
インストーラを起動する前に、特定の環境変数を検証してください。次の各変数は、クラスタに参加するすべてのマシンへのソフトウェアのインストールに使用しているアカウントに対して同一に設定する必要があります。
オペレーティング・システム変数TZ。タイムゾーン設定。インストール前に設定を解除してください。
PERL変数。インストールとDatabase Controlで不正なPERLライブラリのセットを取得しないように、PERL5LIBなどの変数の設定を解除してください。
動的ライブラリに使用されるパス。オペレーティング・システムに基づき、変数はLD_LIBRARY_PATH、LIBPATH、SHLIB_PATH、またはDYLD_LIBRARY_PATHになります。これらの変数は、クラスタの各ノードで表示および使用可能なディレクトリのみを指し示すようにします。
ソフトウェア所有者のユーザーとグループは、クラスタのすべてのノードで同一に定義する必要があります。これを検証するには、次のコマンドを使用します。
$ id -a uid=1234(oracle) gid=5678(dba) groups=5678(dba)
インベントリ・ファイルが共有記憶域にあることを確認するには、次の手順を実行します。
新しいORACLE_HOMEディレクトリを作成します。
新しいOracleホームにOracleインベントリ・ディレクトリを作成します。
cd <shared oracle home> mkdir oraInventory
oraInst.locファイルを作成します。このファイルには、Universal Installerで必要なインベントリ・ディレクトリのパス情報が含まれます。
vi oraInst.loc
Oracleインベントリ・ディレクトリのパス情報を入力し、ソフトウェア所有者のグループをdbaユーザーとして指定します。次に例を示します。
inventory_loc=/app/oracle/product/11.1/oraInventory inst_group=dba
オペレーティング・システムのタイプに応じて、oraInst.locファイルのデフォルトのディレクトリは、/etc（Linuxの場合など）または/var/opt/oracle（SolarisおよびHP-UXの場合など）になります。
インストーラを起動するには、インベントリの場所のファイルoraInst.locを指し示し、仮想グループのホスト名を指定します。次の例のデバッグ・パラメータはオプションです。
$ export ORACLE_HOSTNAME=lxdb.acme.com $ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.acme.com -debug
Windows環境の場合、Oracleソフトウェアで必要なサービスやキーをコピーするには追加の手順が必要です。クラスタリング・ソフトウェアで共有Windowsレジストリが提供されない場合、これらの手順が必要になることに注意してください。
最初のホストでregeditを使用すると、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesから各Oracleサービスをエクスポートします。
最初のホストでregeditを使用すると、HKEY_LOCAL_MACHINE\SOFTWARE\ORACLEをエクスポートします。
手順1および2で作成されたファイルをフェイルオーバー・ホストにインポートするにはregeditを使用します。
サービスは次の順序で開始してください。
アクティブなノードでIPアドレスを確立します。
TNSリスナーを起動します。
データベースを起動します。
データベース・コンソールを起動します。
機能をテストします。
サービスが開始しない場合は、次の手順を実行します。
フェイルオーバー・ボックスでIPを確立します。
TNSリスナーを起動します。
lsnrctl start
データベースを起動します。
dbstart
Database Controlを起動します。
emctl start dbconsole
機能をテストします。
サービスを手動で停止するには、次の手順を実行します。
アプリケーションを停止します。
Database Controlを停止します。
emctl stop dbconsole
TNSリスナーを停止します。
lsnrctl stop
データベースを停止します。
dbshut
IPを停止します。
Grid Controlリポジトリが別のホストにフェイルオーバーするには、次の条件を満たす必要があります。
インストールは、仮想ホスト名と関連する一意のIPアドレスを使用して行います。
バイナリ、構成、ランタイム・データ（リポジトリ・データベースを含む）を保持する共有ディスクやボリュームでインストールを実行します。
稼働中のノードに構成データとメタデータもフェイルオーバーします。
稼働中のノードにインベントリの場所をフェイルオーバーします。
ソフトウェア所有者とタイムゾーンのパラメータは、該当のOMSをホストするクラスタ・メンバーのすべてのノードで同じにします。
次のインストールおよび構成の要件に注意してください。
クラスタ・メンバーの物理ホスト名を仮想ホスト名でオーバーライドするには、パラメータORACLE_HOSTNAMEを使用してソフトウェアをインストールする必要があります。
インベントリ・ポインタの場合、コマンドライン・パラメータ-invPtrLocを使用して、共有インベントリの場所のファイルを指し示すようにソフトウェアをインストールする必要があります。このファイルには、共有インベントリの場所のパスがあります。
データベース・ソフトウェア、データベースの構成、データ・ファイルは共有ボリューム上にあります。
NFSがマウントされたボリュームをインストールに使用する場合、マウント・コマンドでrsizeとwsizeを指定してI/O問題を防止します。My Oracle Supportのノート279393.1 Linux.NetApp: NetApp Filer StorageのRHEL/SUSE設定の推奨事項を参照してください。
例:
grid-repo.acme.com:/u01/app/share1 /u01/app/share1 nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0
|
注意: 共有については、フェイルオーバー後にアクティブなホストにマウントできる非共有フェイルオーバー・ボリュームにも当てはまります。 |
仮想ホスト名と仮想IPアドレスを設定するには、クラスタウェアで設定できるようにするか、Oracleサービスのインストールおよび起動前に手動で設定します。仮想ホスト名は静的にして、ネットワークで常に解決できるようにします。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupやtracerouteなどの標準のTCPツールを使用してホスト名を検証できます。次に示すコマンドを使用して検証します。
nslookup <virtual hostname>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
nslookup <virtual IP>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
必ずクラスタのすべてのノードでこれらのコマンドを実行し、正しい情報が返されることを検証します。
一部のバージョンのオペレーティング・システムでは、11gR1をインストールする前に特定のパッチを適用する必要があります。ユーザーが11gR1ソフトウェアをインストールして使用するには、十分なカーネル・リソースも使用できるようにしておく必要があります。詳細は、オペレーティング・システムのインストール・ガイドを参照してください。
インストーラを起動する前に、特定の環境変数を検証する必要があります。各変数は、クラスタに参加するすべてのマシンにソフトウェアをインストールしているアカウントに対して同一に設定する必要があります。
OS変数TZ（タイムゾーンの設定）
インストール前にこの変数の設定を解除してください。
PERL変数
PERLライブラリの不正なセットを誤って取得しないように、PERL5LIBなどの変数の設定も解除してください。
同じオペレーティング・システム、オペレーティング・システム・パッチ、カーネルのバージョン。したがって、RHEL 3およびRHEL 4は、CFCシステムの場合、許可されません。
システム・ライブラリ
LIBPATH、LD_LIBRARY_PATH、SHLIB_PATHなどです。同じシステム・ライブラリがある必要があります。
ソフトウェア所有者のユーザーとグループは、クラスタのすべてのノードで同一に定義する必要があります。これは次のidコマンドを使用して検証できます。
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
インベントリは次の手順で設定できます。
新しいORACLE_HOMEディレクトリを作成します。
新しいOracleホームにOracleインベントリ・ディレクトリを作成します。
cd <shared oracle home>
mkdir oraInventory
oraInst.locファイルを作成します。このファイルには、Universal Installerで必要なインベントリ・ディレクトリのパス情報が含まれます。
vi oraInst.loc
Oracleインベントリ・ディレクトリのパス情報を入力し、ソフトウェア所有者のグループをoinstallユーザーとして指定します。
例:
inventory_loc=/app/oracle/product/11.1/oraInventory inst_group=oinstall
ソフトウェアをインストールするには、次の手順を実行します。
ソフトウェア・バイナリの両方のノードで共有ディスクの場所を作成します。
インベントリの場所のファイルoraInst.loc（この場合はORACLE_BASEの下）を指し示し、仮想グループのホスト名を指定します。次に例を示します。
$ export ORACLE_HOSTNAME=grid-repo.acme.com $ runInstaller -invPtrLoc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=grid-repo.acme.com
リポジトリDBソフトウェアを共有の場所にのみインストールします。次に例を示します。
/oradbnas/app/oracle/product/oradb111 using Host1
DBCAを起動し、すべてのデータ・ファイルが共有の場所にあるように作成します。次に例を示します。
/oradbnas/oradata
引き続きインストールの残りの手順を通常どおりに実行します。
完了したら、ファイルoraInst.locおよびoratabを/etcにコピーします。また、/opt/oracleもすべてのクラスタ・メンバー・ホスト（Host2、Host3など）にコピーします。
Windows環境の場合、Oracleソフトウェアで必要なサービスやキーをコピーするには追加の手順が必要です。クラスタリング・ソフトウェアで共有Windowsレジストリが提供されない場合、これらの手順が必要になることに注意してください。
最初のホストでregeditを使用すると、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesから各Oracleサービスをエクスポートします。
最初のホストでregeditを使用すると、HKEY_LOCAL_MACHINE\SOFTWARE\ORACLEをエクスポートします。
手順1および2で作成されたファイルをフェイルオーバー・ホストにインポートするにはregeditを使用します。
サービスは必ず適切な順序で開始してください。
アクティブなノードでIPアドレスを確立します。
TNSリスナーが同じフェイルオーバー・グループに含まれる場合はリスナーを起動します。
データベースが同じフェイルオーバー・グループに含まれる場合はデータベースを起動します。
フェイルオーバーの場合、次の手順を実行します。
フェイルオーバー・ボックスでIPアドレスを確立します。
TNSリスナー（lsnrctl start）が同じフェイルオーバー・グループに含まれる場合はリスナーを起動します。
データベース（dbstart）が同じフェイルオーバー・グループに含まれる場合はデータベースを起動します。
これで、フローティング・ホスト名を利用するCFC環境にGrid Control管理リポジトリをデプロイできるようになりました。
CFC環境にOMS中間層をデプロイするには、「仮想ホスト名を使用した高可用性フェイルオーバーのアクティブおよびパッシブ環境でのGrid Control OMSの構成方法」を参照してください。
この項では、コールド・フェイルオーバー・クラスタ（CFC）環境でEnterprise Manager 11gR1 Grid Controlを構成するGrid Control管理者向けの一般的な情報を提供します。
Grid Controlが別のホストにフェイルオーバーするには、次の条件を満たす必要があります。
インストールは、仮想ホスト名と関連する一意のIPアドレスを使用して行います。
バイナリ、構成、ランタイム・データ（受信ディレクトリを含む）を保持する共有ディスク/ボリュームにインストールします。
稼働中のノードに構成データとメタデータもフェイルオーバーします。
稼働中のノードにインベントリの場所をフェイルオーバーします。
ソフトウェア所有者とタイムゾーンのパラメータは、該当のOracle Management Service（OMS）をホストするクラスタ・メンバーのすべてのノードで同じにします。
クラスタ・メンバーの物理ホスト名を仮想ホスト名でオーバーライドするには、パラメータORACLE_HOSTNAMEを使用してソフトウェアをインストールする必要があります。インベントリ・ポインタの場合、コマンドライン・パラメータ-invPtrLocを使用して、共有インベントリの場所のファイルを指し示すようにソフトウェアをインストールする必要があります。このファイルには、共有インベントリの場所のパスがあります。
NFSがマウントされたボリュームをインストールに使用する場合、マウント・コマンドでrsizeとwsizeを指定してI/O問題の発生を防止します。
次に例を示します。
oms.acme.com:/u01/app/share1 /u01/app/share1 nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0
|
注意: 共有フェイルオーバー・ボリュームについては、フェイルオーバー後にアクティブなホストにマウントできる非共有フェイルオーバー・ボリュームにも当てはまります。 |
仮想ホスト名と仮想IPアドレスを設定するには、クラスタウェアで設定できるようにするか、Oracleサービスのインストールおよび起動前にユーザー自身が手動で設定します。仮想ホスト名は静的にして、ネットワークで常に解決できるようにします。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupやtracerouteなどの標準のTCPツールを使用してホスト名を検証できます。次のコマンドを使用して検証します。
nslookup <virtual hostname>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
nslookup <virtual IP>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
必ずクラスタのすべてのノードでこれらのコマンドを実行し、正しい情報が返されることを検証します。
共有記憶域は、使用しているクラスタウェアで管理できます。あるいは、共有ファイルシステム（FS）・ボリューム（OCFS V1などのサポート対象外のタイプを除く）を使用できます。最も一般的な共有ファイルシステムはNFSです。
|
注意: OHSディレクトリが共有記憶域上にある場合、ローカル・ディスクを指し示すようにhttpd.confファイルのLockFileディレクティブを変更する必要があります。変更しない場合、ロック問題が発生する可能性があります。 |
一部のバージョンのオペレーティング・システムでは、11gR1をインストールする前にオペレーティング・システムの特定のパッチを適用する必要があります。ユーザーが11gR1ソフトウェアをインストールして使用するには、十分なカーネル・リソースも使用できるようにしておく必要があります。詳細は、オペレーティング・システムのインストール・ガイドを参照してください。インストーラを起動する前に、特定の環境変数を検証する必要があります。各変数は、クラスタに参加するすべてのマシンにソフトウェアをインストールしているアカウントに対して同一に設定する必要があります。
OS変数TZ
タイムゾーンの設定。インストール前にこの変数の設定を解除してください。
PERL変数
PERLライブラリの不正なセットへの関連付けが行われないように、PERL5LIBなどの変数の設定も解除してください。
ソフトウェア所有者のユーザーとグループは、クラスタのすべてのノードで同一に定義する必要があります。これは次のidコマンドを使用して検証できます。
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
次の手順で共有インベントリを設定します。
新しいORACLE_HOMEディレクトリを作成します。
新しいOracleホームにOracleインベントリ・ディレクトリを作成します。
$ cd <shared oracle home>
$ mkdir oraInventory
oraInst.locファイルを作成します。このファイルには、Universal Installerで必要なインベントリ・ディレクトリのパス情報が含まれます。
vi oraInst.loc
Oracleインベントリ・ディレクトリのパス情報を入力し、ソフトウェア所有者のグループをoinstallユーザーとして指定します。次に例を示します。
inventory_loc=/app/oracle/product/11.1/oraInventory
inst_group=oinstall
ソフトウェアをインストールする場合は次の手順を参照してください。
ソフトウェア・バイナリの両方のノードで共有ディスクの場所を作成します。
WebLogic Serverをインストールします。WebLogic Serverのインストールの詳細は、『Oracle Enterprise Manager Grid Control基本インストレーション・ガイド』を参照してください。
インベントリの場所のファイルoraInst.loc（この場合はORACLE_BASEの下）を指し示し、仮想グループのホスト名を指定します。次に例を示します。
$ export ORACLE_HOSTNAME=lxdb.acme.com $ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.acme.com -debug
既存のDBを使用してEMをインストールする方法を使用してクラスタ・メンバーHost1にOracle Management Serviceをインストールします。
引き続きインストールの残りの手順を通常どおりに実行します。
完了したら、ファイルoraInst.locおよびoratabを/etcにコピーします。また、/opt/oracleもすべてのクラスタ・メンバー・ホスト（Host2、Host3など）にコピーします。
Windows環境の場合、Oracleソフトウェアで必要なサービスやキーをコピーするには追加の手順が必要です。クラスタリング・ソフトウェアで共有Windowsレジストリが提供されない場合、これらの手順が必要になることに注意してください。
最初のホストでregeditを使用すると、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesから各Oracleサービスをエクスポートします。
最初のホストでregeditを使用すると、HKEY_LOCAL_MACHINE\SOFTWARE\ORACLEをエクスポートします。
手順1および2で作成されたファイルをフェイルオーバー・ホストにインポートするにはregeditを使用します。
サービスは必ず適切な順序で開始してください。次の順序で行います。
アクティブなノードでIPアドレスを確立します。
TNSリスナー（同じフェイルオーバー・グループに含まれる場合）を起動します。
データベース（同じフェイルオーバー・グループに含まれる場合）を起動します。
emctl start omsを使用してGrid Controlを起動します。
機能をテストします。
フェイルオーバーの場合、次の手順を参照してください。
フェイルオーバー・ボックスでIPを確立します。
TNSリスナーが同じフェイルオーバー・グループに含まれる場合はコマンドlsnrctl startを使用してリスナーを起動します。
データベースが同じフェイルオーバー・グループに含まれる場合はコマンドdbstartを使用してデータベースを起動します。
コマンドemctl start omsを使用してGrid Controlを起動します。
機能をテストします。
これで、フローティング・ホスト名を利用するCFC環境にGrid ControlのOMS中間層コンポーネントをデプロイできるようになりました。
CFC環境にリポジトリ・データベースをデプロイするには、「アクティブおよびパッシブ高可用性環境でのGrid Controlリポジトリの構成」を参照してください。
この項では、既存の管理エージェントから別のエージェントにコールド・フェイルオーバー・クラスタ（CFC）を再配置するGrid Control管理者向けに全般的な情報を提供します。ターゲットは複数のノードで実行可能ですが、CFC環境のアクティブなノードでのみ実行されます。
CFC環境は、通常、クラスタ・ソフトウェアを組み合せて使用することで、仮想ホスト名とIPアドレス、インターコネクト・ホストおよび記憶域システムを提供して情報を共有し、アプリケーションの高可用性を実現します。仮想ホスト名とIPのフェイルオーバーを自動化し、Enterprise Managerターゲットを再配置してパッシブ・ノードでアプリケーションを再起動する場合、Oracle Enterprise Managerのコマンドライン・インタフェース（EM CLI）とOracle Clusterware（Oracle Databaseリリース10gまたは11gを実行）、またはサードパーティのクラスタ・ソフトウェアを使用する必要があります。一部のOracleパートナ・ベンダーでは、この分野のクラスタウェア・ソリューションが提供されています。
Enterprise Managerコマンドライン・インタフェース（EM CLI）では、各種オペレーティング・システムのテキストベースのコンソール（端末セッション）からEnterprise Manager Grid Control機能にアクセスできます。EM CLIを使用すると、Enterprise Manager Grid Controlコンソールベースの操作（ターゲット、ジョブ、グループ、ブラックアウト、通知、アラートの監視および管理など）を実行できます。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。
Oracle Enterprise Manager 10gリリース10.2.0.5以降では、クラスタの各ノードで実行する単一のOracle Management Agentで、アクティブ/パッシブ高可用性に構成されたターゲットを監視できます。CFCクラスタの各物理ノードで必要になるのは1つの管理エージェントのみです。これは、パッシブ・ノードにフェイルオーバーする場合、Enterprise Managerは、一連のEMCLIコマンドを使用して、障害が発生したノードの管理エージェントから新しく有効になったノードの別の管理エージェントにHA監視対象ターゲットを移動できるためです。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。
アクティブ/パッシブ環境でアプリケーションが実行している場合、アクティブなノードに障害が発生すると、クラスタウェアはパッシブ・ノードでアプリケーションを起動します。Enterprise Managerがこのタイプの構成でターゲットを引き続き監視する場合、既存の管理エージェントには追加の構成が必要です。
次の項では、新しいアクティブなノードでターゲットを自動化および再起動する環境を準備する方法について説明します。フェイルオーバーおよびフォールバックの手順も示します。
次の項では、Oracle Management Serviceプロセスと通信する既存の管理エージェントを使用してCFC構成をサポートするEnterprise Managerの構成方法について説明します。
アクティブ/パッシブ環境を次のように準備します。
オペレーティング・システムのクロックがクラスタのすべてのノード間で同期化されていることを確認します（Network Time Protocol（NTP）または別のネットワーク同期化方法の使用を検討します。）
EM CLIのRELOCATE_TARGETSコマンドは、Enterprise Managerリリース10.2.0.5（およびそれ以上）の管理エージェントでのみ使用してください。
次の項では、OMSプロセスと通信する既存の管理エージェントを使用してCFC構成をサポートするEnterprise Managerの構成方法について説明します。次に示す例は、2つのノードで構成されるクラスタに1つのフェイルオーバー・グループがある構成に基づいています。CFCアクティブ/パッシブ環境で実行するターゲットの詳細は、My Oracle Supportのノート406014.1を参照してください。
EM CLIを構成します。
ターゲットの再配置を設定および構成するには、Oracle Enterprise Managerコマンドライン・インタフェース（EM CLI）を使用します。EM CLIおよび管理プラグインの詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』および『Oracle Enterprise Manager拡張ガイド』を参照してください。
管理エージェントをインストールします。
クラスタの各ノードのローカル・ディスク・ボリュームに管理エージェントをインストールします。管理エージェントをインストールすると、Grid Controlコンソールに表示されます。
ターゲットを検出します。
アクティブ/ パッシブ・ターゲットを構成した後、Grid Controlコンソールの管理エージェント検出画面を使用してターゲット（データベース、リスナー、アプリケーション・サーバーなど）を追加します。アクティブ・ノード（現在新しいターゲットをホストしているノード）で検出を実行します。
ノードのフェイルオーバー後にターゲットの再配置の速度を上げるには、ターゲットのフェイルオーバーの自動開始に必要なコマンドが含まれるスクリプトを使用して次の手順を構成します。通常、クラスタウェア・ソフトウェアには、Enterprise Managerのターゲットを再配置するスクリプトを自動的に実行できるメカニズムがあります。また、サンプル・スクリプトについては、「スクリプト例」を参照してください。
障害が発生したアクティブ・ノードのターゲット・サービスを停止します。
ターゲットが実行しているアクティブ・ノードで、仮想IPで実行しているターゲット・サービスを停止します。
必要に応じて、アクティブ・ノードでこのターゲットの記憶域の接続を解除します。
仮想IPと共有記憶域で実行しているすべてのアプリケーションを停止します。
新しいアクティブ・ノードでターゲットのIPアドレスを有効にします。
必要に応じて、現在アクティブなノードでターゲットの記憶域を接続します。
EM CLIを使用してGrid Controlにターゲットを再配置します。
新しいアクティブ・ノードの管理エージェントにターゲットを再配置するには、フェイルオーバーの操作後に再配置する必要があるターゲット・タイプ（リスナー、アプリケーション・サーバーなど）ごとにEM CLIのRELOCATE TARGETコマンドを発行します。次に例を示します。
emcli relocate_targets -src_agent=<node 1>:3872 -dest_agent=<node 2>:3872 -target_name=<database_name> -target_type=oracle_database -copy_from_src -force=yes
この例では、管理エージェントのデフォルト・ポートはポート3872です。構成に適したポート番号を検索するには、該当の管理エージェントのemd.propertiesファイルでEMD_URLパラメータの値を使用します。
注意: フェイルオーバー・イベントの場合、ソース・エージェントは実行しません。ただし、RELOCATE操作を行うために、ソース管理エージェントを実行する必要はありません。EM CLIは、管理リポジトリに対してRELOCATE操作を直接実行するOMSクライアントです。
HAターゲットを元のアクティブ・ノードまたはその他のクラスタ・メンバー・ノードに戻すには、次の手順を実行します。
HAターゲットをアクティブ・ノードに戻すには、「フェイルオーバー手順」のステップを繰り返します。
Grid Controlコンソールでターゲットのステータスを検証します。
再配置操作時にフェイルオーバー（またはスイッチオーバー）されるターゲット・タイプごとに同じコマンドを発行します。たとえば、同じEM CLIコマンドを発行して、リスナー、アプリケーション・サーバーなどを再配置します。表18-6に、ターゲットの再配置に使用するEM CLIパラメータを示します。
表18-6 EM CLIパラメータ
| EM CLIパラメータ | 説明 |
|---|---|
|
-src_agent |
フェイルオーバーの発生前にターゲットが実行していた管理エージェント。 |
|
-dest_agent |
フェイルオーバー後にターゲットを監視する管理エージェント。 |
|
-target_name |
フェイルオーバーするターゲットの名前。 |
|
-target_type |
フェイルオーバーするターゲットのタイプ（Enterprise Managerの内部ターゲット・タイプ）。たとえば、（スタンドアロン・データベースまたはOracle RACインスタンスの）Oracleデータベース、データベース・リスナーのOracleリスナーなど。 |
|
-copy_from_src |
ソース管理エージェントと同じタイプのプロパティを使用してターゲットを特定します。これは必須パラメータです。このパラメータを指定しないと、ターゲットの定義が不正になる場合があります。 |
|
-force |
同様にフェイルオーバーする依存性を強制します（必要な場合）。 |
次の項では、スクリプト例を示します。
#! /bin/ksh #get the status of the targets emcli get_targets - targets="db1:oracle_database;listener_db1:oracle_listener" -noheader if [[ $? != 0 ]]; then exit 1; fi # blackout the targets to stop false errors. This blackout is set to expire in 30 minutes emcli create_blackout -name="relocating active passive test targets" - add_targets="db1:oracle_database;listener_db1:oracle_listener" - reason="testing failover" - schedule="frequency:once;duration:0:30" if [[ $? != 0 ]]; then exit 1; fi # stop the listener target. Have to go out to a OS script to use the 'lsnrctl set current_listener' function emcli execute_hostcmd -cmd="/bin/ksh" -osscript="FILE" - input_file="FILE:/scratch/oraha/cfc_test/listener_stop.ksh" - credential_set_name="HostCredsNormal" - targets="host1.us.oracle.com:host" if [[ $? != 0 ]]; then exit 1; fi # now, stop the database emcli execute_sql -sql="shutdown abort" - targets="db1:oracle_database" - credential_set_name="DBCredsSYSDBA" if [[ $? != 0 ]]; then exit 1; fi # relocate the targets to the new host emcli relocate_targets - src_agent=host1.us.oracle.com:3872 - dest_agent=host2.us.oracle.com:3872 - target_name=db1 -target_type=oracle_database - copy_from_src -force=yes - changed_param=MachineName:host1vip.us.oracle.com if [[ $? != 0 ]]; then exit 1; fi emcli relocate_targets - src_agent=host1.us.oracle.com:3872 - dest_agent=host2.us.oracle.com:3872 - target_name=listener_db1 -target_type=oracle_listener - copy_from_src -force=yes - changed_param=MachineName:host1vip.us.oracle.com if [[ $? != 0 ]]; then exit 1; fi # Now, restart database and listener on the new host emcli execute_hostcmd -cmd="/bin/ksh" -osscript="FILE" - input_file="FILE:/scratch/oraha/cfc_test/listener_start.ksh" - credential_set_name="HostCredsNormal" - targets="host2.us.oracle.com:host" if [[ $? != 0 ]]; then exit 1; fi emcli execute_sql -sql="startup" - targets="db1:oracle_database" - credential_set_name="DBCredsSYSDBA" if [[ $? != 0 ]]; then exit 1; fi # Time to end the blackout and let the targets become visible emcli stop_blackout -name="relocating active passive test targets" if [[ $? != 0 ]]; then exit 1; fi # and finally, recheck the status of the targets emcli get_targets - targets="db1:oracle_database;listener_db1:oracle_listener" -noheader if [[ $? != 0 ]]; then exit 1; fi
#!/bin/ksh export ORACLE_HOME=/oradbshare/app/oracle/product/11.1.0/db export PATH=$ORACLE_HOME/bin:$PATH lsnrctl << EOF set current_listener listener_db1 start exit EOF
#!/bin/ksh export ORACLE_HOME=/oradbshare/app/oracle/product/11.1.0/db export PATH=$ORACLE_HOME/bin:$PATH lsnrctl << EOF set current_listener listener_db1 stop exit EOF
