| Oracle Enterprise Manager管理 11gリリース1（11.1.0.1） B61022-01 |
|
 戻る |
 次へ |
単一リソース構成は、保護された記憶域の形式を利用する単一インスタンスのEnterprise Manager構成で、リポジトリ・データベースとソフトウェア・インストールの両方を保護します。最も一般的なインストール・タイプの1つとして、単一リソース構成に高可用性を実装する場合、時間とリソースのどちらの観点からも高いコスト効率が実現されます。これは、Recovery Manager、フラッシュバック、Ultrasafe、自動ストレージ管理などのすでに利用可能なテクノロジの活用を目的とするためです。
この章では次のトピックについて説明します。
この章では、構成例のみについて説明します。各自の環境にデプロイする実際のGrid Control構成は、組織のニーズに応じて異なります。たとえば、本番環境でファイアウォールと他のセキュリティ上の考慮事項を実装するとします。ファイアウォールとセキュリティ・プロトコルの実装の固有情報については、次のEnterprise Managerドキュメントを参照してください。
Grid Controlコンポーネント間の接続の保護については、第2章「Enterprise Managerセキュリティ」
Grid Controlコンポーネント間のファイアウォールの構成については、『Oracle Enterprise Manager Grid Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
この章は、一般的な構成を説明する他に、Grid Controlコンポーネント間のアーキテクチャとデータのフローを理解する場合も役立ちます。この知識に基づき、特定の管理要件に合せたGrid Controlの構成方法に関して、より適切な意思決定を行うことができます。
Grid Controlアーキテクチャは、次のソフトウェア・コンポーネントで構成されます。
Oracle Management Agent
Oracle Management Service
Oracle Management Repository
Oracle Enterprise Manager 11g Grid Controlコンソール
|
関連項目: 各Grid Controlコンポーネントの詳細は、『Oracle Enterprise Manager概要』 |
図17-1は、単一ホストにGrid Controlをインストールする場合に各Grid Controlコンポーネントが相互運用する構成を示しています。これは、新しいGrid Controlインストール・タイプのインストールを使用する場合のデフォルト構成です。
Enterprise Managerリリース11gでは、インストール時に新しいデータベースは作成されません。Enterprise Managerと同じホスト上にデータベースをインストールする必要があります。
すべてのGrid Controlコンポーネントを単一ホストにインストールする場合、管理データは次の経路で伝送されます。
管理者はGrid Controlコンソールを使用して、各ホストの管理エージェントで検出される管理対象ターゲットを監視および管理します。Grid Controlコンソールは次のURLを使用してOracle HTTP Serverに接続します。
https://host1.acme.com:7799/em
管理サービスは、Grid Controlコンソールを使用して管理者がリクエストするとおりに管理リポジトリからデータを取得します。
管理エージェントは、Oracle HTTP ServerアップロードURL経由でデータ（ホストのすべての管理対象ターゲットに関する管理データ、管理サービスや管理リポジトリ・データベースを含む）をロードします。管理エージェントは、データをOracle HTTP Serverに直接アップロードします。アップロードURLのデフォルトのポートは1159です（インストール時に使用可能な場合）。アップロードURLは、管理エージェントのホーム・ディレクトリにある次の構成ファイルのREPOSITORY_URLプロパティで定義されます。
AGENT_HOME/sysman/config/emd.properties (UNIX) AGENT_HOME\sysman\config\emd.properties (Windows)
|
関連項目: Oracle Enterprise Managerのディレクトリ構造（特にAGENT_HOMEディレクトリ）の詳細は、『Oracle Enterprise Manager Grid Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。 |
管理サービスはJDBC接続を使用して、データを管理リポジトリ・データベースにロードし、そのデータがGrid Controlコンソールに表示されるように管理リポジトリから情報を取得します。管理リポジトリの接続の詳細をリストして変更するには、次のemctlコマンドを使用します。
emctl config oms -list_repos_details emctl config oms -store_repos_details
管理サービスはHTTP経由で管理エージェントにデータを送信します。管理エージェント・ソフトウェアには、管理サービスからのメッセージについて管理エージェントURLをリスニングする組込みHTTPリスナーがあります。そのため、管理サービスはOracle HTTP Serverを無視して管理エージェントと直接通信できます。管理エージェントがリモート・システム上にある場合、管理エージェント・ホストにOracle HTTP Serverは必要ありません。
管理サービスは管理エージェントURLを使用して、管理エージェント、Enterprise Managerの発行ジョブ、およびその他の管理機能の可用性を監視します。
管理エージェントURLは、管理エージェントのホーム・ディレクトリにある次の構成ファイルのEMD_URLプロパティで特定できます。
AGENT_HOME/sysman/config/emd.properties (UNIX) AGENT_HOME\sysman\config\emd.properties (Windows)
次に例を示します。
EMD_URL=https://host1.acme.com:3872/emd/main
さらに、Grid Controlコンソールに表示される管理エージェントの名前は、管理エージェントのホスト名と、管理エージェントURLで使用されるポートで構成されます。
Enterprise Managerは単一のエンティティとして機能しますが、技術的には、次のソフトウェア・コンポーネントで構成される分散型の多層ソフトウェア・アーキテクチャで構築されています。
Oracle Management Services（OMS）
Oracle Management Agent（エージェント）
Oracle Management Repository（リポジトリ）
各コンポーネントは、構成と機能がそれぞれ異なり、バックアップとリカバリに対して異なるアプローチを必要とします。このため、バックアップおよりリカバリ戦略について、この章では層別に説明します。Enterprise Managerアーキテクチャの概要については、『Oracle Enterprise Manager Grid Control基本インストレーション・ガイド』を参照してください。
Oracle Configuration Manager
Oracle Configuration Manager（OCM）は、クライアント構成情報の収集やその情報のOracleリポジトリへのアップロードに使用されます。クライアント構成データが定期的にアップロードされる場合、カスタマ・サポート担当者はこのデータを分析してカスタマにより良いサービスを提供できます。
Oracleソフトウェアをインストールする場合、インストーラで、OCMを設定および構成するオプションを使用できます。ソフトウェアがソフトウェア専用モードでインストールされるリカバリ・シナリオの場合、OMSとエージェントのOracleホームから次の操作を実行してOCMを手動で構成できます。
<OracleHome>/ccr/bin/setupCCR
Oracle Configuration ManagerクライアントはORACLE_HOMEディレクトリにインストールされます。OCMがインストールされると、ORACLE_HOMEディレクトリと、OCMがインストールされるホストに関連する構成データが収集されます。OCMは構成データを収集およびアップロードする他に、Oracle Configuration Managerクライアントへのソフトウェアの更新が利用できるかどうかも確認します。更新が利用できる場合、OCMは更新をダウンロードして、カスタマのシステムにインストールされたOracle Configuration Managerソフトウェアを更新します。
リポジトリは、エージェントが収集したすべての情報が格納される記憶域です。これは、データベース・ジョブ、パッケージ、プロシージャ、ビューおよび表領域などのオブジェクトで構成されます。リポジトリはOracle Database内で構成されるため、リポジトリのバックアップおよびリカバリ戦略は、基本的にはOracle Databaseの戦略と同じになります。データベースのバックアップ・プロシージャは、十分に確立した標準であり、RMANバックアップ・ユーティリティを使用して実装できます。このユーティリティには、Enterprise Managerコンソールからアクセスできます。
リポジトリ・データベースの計画外の停止を回避するために、高可用性のベスト・プラクティスを使用することをお薦めします。このためには、次の標準のデータベース・バックアップ戦略を使用します。
データベースはarchivelogモードにします。リポジトリ・データベースをarchivelogモードで実行しないと、メディア障害後のリカバリ不能な状況でデータベースが脆弱なままになります。
Enterprise Managerコンソールを介して推奨バックアップ戦略オプションを使用し、RMANによる通常のホット・バックアップを実行します。DataGuardやRACなどの他のユーティリティも、データ損失を防ぐ包括的な戦略の一部として使用できます。
これらの戦略に従うと、全体バックアップが作成された後、以降は毎回増分バックアップが作成されます。増分の変更はベースラインにロールアップされ、新しい全体バックアップ・ベースラインが作成されます。
推奨バックアップ戦略を使用すると、Enterprise Managerのバックアップ実行機能も利用でき、ジョブはEnterprise Managerのジョブ・サブシステムを通じて自動的にスケジュールされます。これで、バックアップの履歴がレビューで使用可能になり、バックアップのステータスがリポジトリ・データベース・ターゲットのホームページで表示されます。このバックアップ・ジョブとアーカイブおよびフラッシュバック・テクノロジを併用すると、リポジトリのいずれかの部分が失われた場合のリストア・ポイントが得られます。このタイプのバックアップ処理およびアーカイブ・ログとオンライン・ログにより、リポジトリを最後に完了したトランザクションまでリカバリできます。
最後のリポジトリのバックアップが発生した時間を「リポジトリの詳細」セクションの「管理サービスとリポジトリ概要」ページで表示できます。
バックアップの設定
まず、Enterprise Managerの「リカバリ設定」ページ（「ターゲット」→「データベース」→リポジトリ・データベース・ターゲット→「可用性」→「リカバリ設定」）にナビゲートし、図17-2に示すように、ログのアーカイブおよびデータベースのフラッシュバックを有効にします。
次に、「バックアップ・ポリシー」ページ（「ターゲット」→「データベース」→リポジトリ・データベース・ターゲット→「可用性」→「バックアップ設定」→「ポリシー」）にナビゲートし、図17-3に示すように、ブロック変更トラッキングを有効にしてバックアップ操作を高速化します。
Enterprise Managerを使用したバックアップの構成方法のサマリーは、『Oracle Database 2日でデータベース管理者』を参照してください。データベースの高可用性に関するベスト・プラクティスの付加情報は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。
リポジトリ・データベースの停止時はGrid Controlは使用できないため、リポジトリ・データベースのリカバリはRMANを使用して実行する必要があります。次の2種類のリカバリを考慮する必要があります。
完全リカバリ: Enterprise Managerに関する特別な考慮事項はありません。
ポイント・イン・タイム/不完全リカバリ: リカバリされたリポジトリは、トランザクションの損失のため、エージェントと同期化されていない場合があります。この状況では、エージェントで使用できる最新の状態とリポジトリが同期化されないかぎり、一部のメトリックがGrid Controlで誤って表示される場合があります。
リポジトリの再同期化機能（Enterprise Managerバージョン10.2.0.5以上）により、Enterprise Managerリポジトリをエージェントで使用可能な最新の状態と同期化するプロセスを自動化できます。
リポジトリをエージェントと再同期化するには、Enterprise Managerコマンドライン・ユーティリティ（emctl）のresync reposコマンドを使用します。
emctl resync repos -full -name "<descriptive name for the operation>"
このコマンドは、リポジトリをリストアした後、かつ、OMSを起動する前に、OMS Oracleホームから実行する必要があります。コマンドの発行後、すべてのOMSを起動し、図17-5に示すように、Enterprise Managerコンソールの「リポジトリの同期化」ページからリポジトリの再同期化の進行状況を監視します。
リポジトリのリカバリが完了するのは、再同期化ジョブがすべてのエージェントで完了したときです。
障害発生時にデータベースを最新のトランザクションまでリカバリできるように、リポジトリ・データベースをarchivelogモードで実行することをお薦めします。データベースを最後のトランザクションまでリカバリできない場合は、リポジトリの同期化を使用して、最後のバックアップの作成時に存在していたターゲットの監視機能をリストアできます。バックアップ後に行ったアクションは、自動的にはリカバリされません。リポジトリの同期化で自動的にリカバリされないアクションの例は次のとおりです。
通知ルール
優先資格証明
グループ、サービス、システム
ジョブ/デプロイメント手順
カスタム・レポート
新しいエージェント
手動によるエージェントの再同期化
Enterprise Managerのリポジトリの同期化機能は、10.2.0.5以上のエージェントにのみ使用できます。これより前のエージェントは、次の手順でエージェントを停止して手動で再同期化する必要があります。
エージェントを停止します。
agentstmp.txt、lastupld.xml、state/*およびupload/*ファイルを<AGENT_HOME>/sysman/emdディレクトリから削除します。
エージェントを再起動します。
リポジトリ（または任意のデータベース）をリカバリする前提条件は、リポジトリの有効な一貫性バックアップがあることです。Enterprise Managerを使用してバックアップ・プロセスを自動化すると、リポジトリのリカバリが必要になった場合に備えて、通常の最新バックアップが常に用意されます。Recovery Manager（RMAN）は、Oracle Databaseのバックアップ、リストアおよびリカバリを行うユーティリティです。RMANのリカバリ・ジョブの構文は、安全な場所に保存する必要があります。これにより、Enterprise Managerリポジトリ・データベースの完全リカバリを実行できます。最も単純な形式では、構文は次のようになります。
run {
restore database;
recover database;
}
実際の構文は、環境によって長さや複雑さが異なります。構文をRMANのバックアップおよびリカバリ・ジョブから抽出する方法、またはRMANの一般的な使用方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
次の各シナリオでは、様々なリポジトリのリカバリ状況とそのリカバリ手順を示します。
リポジトリ・データベースはarchivelogモードで実行されています。最近のバックアップ、アーカイブ・ログ・ファイルおよびREDOログがあります。リカバリ・データベース・ディスクがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。
解決方法:
emctl stop omsを使用して、OMSを停止します。
RMANを使用してデータベースをリカバリします。
すべてのOMSに対してコマンドemctl start omsを使用してサイトを立ち上げます。
サイトが完全に動作していることを確認します。
リポジトリ・データベースはnoarchivelogモードで実行されています。全体オフライン・バックアップがあります。リカバリ・データベース・ディスクがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。
解決方法:
emctl stop omsを使用して、OMSを停止します。
RMANを使用してデータベースをリカバリします。
emctl resync repos -full -name "<resync name>"を使用して、OMS Oracleホームの1つからリポジトリの再同期化を開始します。
emctl start omsを使用して、OMSを起動します。
10.2.0.5より前のすべてのエージェントを手動で修正します。このためには、エージェントを停止し、<AGENT_HOME>/sysman/emdディレクトリのagentstmp.txt、lastupld.xml、state/*およびupload/*ファイルを削除してエージェントを再起動します。
Grid Controlにログインします。「管理サービスとリポジトリ概要」ページにナビゲートします。「関連リンク」の下の「リポジトリの同期化」をクリックします。再同期化ジョブのステータスを監視します。エラーの修正後、失敗したジョブがあれば、そのジョブを再発行します。
サイトが完全に動作していることを確認します。
リポジトリ・データベースはホストA上でarchivelogモードで実行されています。最近のバックアップ、アーカイブ・ログ・ファイルおよびREDOログがあります。リポジトリ・データベースがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。
解決方法:
コマンドemctl stop omsを使用して、OMSを停止します。
RMANを使用して、データベースを別のホスト（ホストB）上でリカバリします。
次の操作を実行して資格証明ストアのリポジトリの接続記述子を修正します。
$emctl config oms –store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman
コマンドemctl start omsを使用して、OMSを起動します。
次のコマンドをOMSから実行し、リポジトリ・データベース・ターゲットをホストB上で実行されているエージェントに再配置します。
$emctl config repos -host <hostB> -oh <OH of repository on hostB> -conn_desc "<TNS connect descriptor>"
|
注意: このコマンドは、次の条件を満たしている場合にのみ、リポジトリ・データベースの再配置に使用できます。
新規エージェントがホストBにインストールされている場合は、以前に検出されたデータベース・ターゲットがないことを確認する必要があります。 |
次のコマンドをOMSから実行し、OMSおよびリポジトリ・ターゲットの監視構成を変更します。
$emctl config emrep -conn_desc "<TNS connect descriptor>"
サイトが完全に動作していることを確認します。
リポジトリ・データベースはホストA上でnoarchivelogモードで実行されています。全体オフライン・バックアップがあります。ホストAはハードウェア障害のために失われました。すべてのデータファイルと制御ファイルが失われました。
解決方法:
emctl stop omsを使用して、OMSを停止します。
RMANを使用して、データベースを別のホスト（ホストB）上でリカバリします。
資格証明ストアのリポジトリの接続記述子を修正します。
$emctl config oms –store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman
リポジトリの再同期化を開始します。
emctl resync repos -full -name "<resync name>"
これは、OMS Oracleホームの1つから開始します。
コマンドemctl start omsを使用して、OMSを起動します。
次のコマンドを実行し、ホストB上で実行されているエージェントにリポジトリ・データベース・ターゲットを再配置します。
emctl config repos -agent <agent on host B> -host <hostB> -oh <OH of repository on hostB> -conn_desc "<TNS connect descriptor>"
次のコマンドを実行し、OMSおよびリポジトリ・ターゲットの監視構成を変更します。
emctl config emrep -conn_desc "<TNS connect descriptor>"
10.2.0.5より前のすべてのエージェントを手動で修正します。このためには、エージェントを停止し、<AGENT_HOME>/sysman/emdディレクトリのagentstmp.txt、lastupld.xml、state/*およびupload/*ファイルを削除してエージェントを再起動します。
Grid Controlにログインします。「管理サービスとリポジトリ概要」ページにナビゲートします。「関連リンク」の下の「リポジトリの同期化」をクリックします。再同期化ジョブのステータスを監視します。前述のエラーの修正後、失敗したジョブがあれば、そのジョブを再発行します。
サイトが完全に動作していることを確認します。
Oracle Management Service（OMS）は管理エージェントを編成し、ターゲットを検出、監視および管理し、収集された情報を将来の参照および分析のためリポジトリに格納します。OMSは、Enterprise Managerコンソール用のWebインタフェースもレンダリングします。Enterprise Managerバージョン11.1では、OMSアーキテクチャが変更されています。
OMSは通常、ステートレスです。一時データおよび構成データの一部は、OMSファイルシステムに格納されます。共有ローダーの「recv」ディレクトリは、データがリポジトリにロードされる前に、エージェントからロードされたメトリック・データを一時的に格納します。OMSが停止すると、共有ローダー内の場所に格納されているデータを他の動作しているOMSがアップロードします。高可用性（HA）構成では、共有ローダー受信ディレクトリは冗長ディスクなどのHA記憶域テクノロジを使用して保護する必要があります。
OMS構成のスナップショットは、emctl exportconfig omsコマンドを使用して取得できます。
emctl exportconfig oms [-sysman_pwd <sysman password>]
[-dir <backup dir>] Specify directory to store backup file
[-keep_host] Specify this parameter if the OMS was installed
using a virtual hostname.
For example: ORACLE_HOSTNAME
|
注意: exportconfig omsコマンドは、Enterprise Managerバージョン10.2.0.5以上でのみ使用できます。 |
exportconfigを実行すると、特定の時点のOMSのスナップショットが取得されるため、最新のOMS構成を定期的にバックアップできます。必要に応じて、最新のスナップショットを同一または別のホスト上のフレッシュOMSインストールにリストアできます。
OMSコンポーネントのバックアップ戦略は次のとおりです。
ソフトウェア・ホーム
3つのWebLogicコンポーネントで構成: Middewareホーム、OMS Oracleホーム、WebTier（OHS）Oracleホーム。 ソフトウェア・ホームは、パッチやパッチセットが適用される場合のみ変わります。このため、ファイルシステムレベルのバックアップは、各パッチ/パッチセットの適用後に作成する必要があります。Oracleインベントリ・ファイルとソフトウェア・ホームをバックアップしてください。 .
|
重要: Enterprise Managerバージョン11.1以降では、OMS Oracleホームの場所は、監視対象環境のすべてのOMSと同じ場所にしてください。 |
インスタンス・ホーム
WebLogic、OMS、WebTierの構成ファイルで構成されます。インスタンス・ホームはemctl exportconfig omsコマンドを使用してバックアップできます。
ソフトウェア・ライブラリ
Enterprise Managerのパッチ適用機能とプロビジョニング機能で使用されるコンポーネントで構成されます。ソフトウェア・ライブラリのバックアップにはOracle Database Filesystem（DBFS）をお薦めします。DBFSテクノロジを使用すると、Oracleデータベースの表領域をマウント済ファイルシステムとしてアプリケーションに公開できます。すべてのファイルは、内部でOracleデータベースにセキュア・ファイルとして格納されます。DBFSを使用してEnterprise Managerリポジトリ・データベースにソフトウェア・ライブラリを格納すると、ソフトウェア・ライブラリとEnterprise Managerリポジトリの一貫したバックアップを行うOracleデータベースの包括的な機能を活用できます。DBFSの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
共有ローダー受信ディレクトリ
共有ローダー受信（RECV）ディレクトリは、データがリポジトリにロードされる前に、エージェントからアップロードされたメトリック・データを一時的に格納します。受信ディレクトリを保護するには、高可用性ストレージ・テクノロジを使用します。
AdminServer
Enterprise Managerバージョン11.1以降では、OMSのWebLogicアーキテクチャにAdminServerの概念が導入されています。AdminServerは、OMSドメイン全体の構成に対する中央制御エンティティとして機能します。AdminServerは、Grid Controlデプロイメントにインストールされた最初のOMSの不可欠な要素であり、ソフトウェア・ホームとインスタンス・ホームを共有します。
OMSが失われた場合、ソフトウェアのインストールのみで構成は後で実行するというオプションを使用して、再インストールする必要があります。この追加管理サービス・オプションは、『Oracle Enterprise Manager Grid Controlインストレーションおよび基本構成』で説明されています。OMS構成は、次のコマンドを使用してOMSコンフィギュレーション・アシスタントでリストアできます。
omsca recovery -BACKUP_FILE <file>
次の項で示すemctl exportconfigコマンドで生成されるエクスポート・ファイルを使用します。
OMSのリカバリは、基本的に、ソフトウェア・ホームをリカバリしてインスタンス・ホームを構成する2つの手順で構成されます。同じホストでリストアする場合、ソフトウェア・ホームをファイルシステム・バックアップからリストアできます。バックアップが存在しない場合、ソフトウェア・ホームは、WebLogicおよびOMSのソフトウェア専用インストール、アドオン（ある場合）のソフトウェア専用インストール、クラッシュ前に適用されたすべてのパッチを使用して再構築できます。前述のように、OMS Oracleホームの場所は修正されるため、変更できません。そのため、以前に使用された場所でOMS Oracleホームをリストアするようにします。
ソフトウェア・ホームをリカバリすると、インスタンス・ホームはリカバリ・モードでomscaコマンドを使用して再構築できます。
次の各シナリオでは、OMSの様々なリカバリ状況とそのリカバリ手順を示します。
|
重要: OMSリカバリの前提条件は、最近の有効なOMS構成バックアップがあることです。OMS構成が変更されるたびに、emctl exportconfig omsコマンドを使用してOMSをバックアップすることをお薦めします。このコマンドは、WebLogic AdminServerを実行するプライマリOMSで実行する必要があります。
または、Enterprise Managerのジョブ・システムを使用して、このコマンドを定期的に実行できます。 |
サイトは単一OMSをホストします。SLBはありません。AdminServerを実行するプライマリAdminServerでemctl exportconfig omsコマンドを使用してOMS構成をバックアップしました。OMS Oracleホームが失われました。
解決方法:
ローダー受信ディレクトリとソフトウェア・ライブラリの場所にアクセスできることを確認します。
以前に取得したファイルシステム・バックアップからソフトウェア・ホームをリストアします。または、バックアップが存在しない場合は、ソフトウェア専用インストール方法を使用してWebLogicおよびOMS Oracleホームを再構築し、以前にインストールされたアドオンをソフトウェア専用モードで再インストールして、以前に適用されたすべてのパッチを再適用する必要があります。OMS Oracleホームの場所は以前に使用した場所と同じにする必要があります。
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
omsca recover –as –ms –backup_file <file>
注意: 渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。
エージェントを構成します。
>agentca -f >emctl secure agent -emdWalletSrcUrl <oms url>
この時点では、OMSとともに再インストールされたエージェントで使用されるポートに基づき、次の2つのオプションがあります。
オプションA: エージェントは以前のインストールと同じポートを使用します。
エージェントはOMSによって自動的にブロックされます。エージェントをエージェントのホームページから再同期化します。
オプションB: エージェントは別のポートを使用します。
次のコマンドを実行し、再インストールされたエージェントにOMSおよびリポジトリのターゲットを再配置します。
emctl config emrep -agent <reinstalled agent>
例: emctl config emrep -agent foo.us.oracle.com:3872
重複したターゲットを「管理サービスとリポジトリ概要」ページで探します。再インストールされたエージェントに、重複するターゲットを古いエージェントから再配置します。古いエージェントを削除します。
サイトが完全に動作していることを確認します。
サイトは単一OMSをホストします。OMSはホストA上で実行されています。SLBはありません。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAが失われました。
解決方法:
ローダー受信ディレクトリとソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。
通常、ファイルシステムのリストアはホスト間で機能しません。ソフトウェア専用インストール方法を使用してWebLogicおよびOMS Oracleホームを再構築し、以前にインストールされたアドオンをソフトウェア専用モードで再インストールして、以前に適用されたすべてのパッチを再適用する必要があります。OMS Oracleホームの場所は以前に使用した場所と同じにする必要があります。
以前に生成されたOMS構成バックアップ・ファイルを指定してomscaをリカバリ・モードで実行し、新しいOMSを構成します。
omsca recover –as –ms –backup_file <file>
エージェントを構成します。
agentca -f emctl secure agent -emdWalletSrcUrl <oms url>
すべてのエージェントが指し示すOMSを変更してから、すべてのエージェントを再保護します。
デプロイメント内のすべてのエージェントが、ホストB上で実行されている新しいOMSを指すようにします。各エージェントに対し、次のコマンドを実行します。
emctl secure agent -emdWalletUrlSrc "http://hostB:<httpport>/em"
次のコマンドを実行し、エージェントBにOMSおよびリポジトリ・ターゲットを再配置します。
emctl config emrep -agent <agent on host "B">.
|
注意: 新しいマシンでは、OMSをホストしていた以前のマシンとは異なるホスト名を使用するため、監視対象の環境内のすべてのエージェントに、新しいOMSを検索する場所を指示する必要があります。 |
重複したターゲットを、Enterprise Managerコンソールの「管理サービスとリポジトリ概要」ページで探します。「重複したターゲット」リンクをクリックして「重複したターゲット」ページにアクセスします。重複したターゲットのエラーを解決するには、重複したターゲットの名前を、競合が発生しているエージェントで変更する必要があります。重複したターゲットをエージェントAからエージェントBに再配置します。
サイトが完全に動作していることを確認します。
サイトは単一OMSをホストします。OMSはホストA上で実行されています。SLBはありません。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAが失われました。
解決方法:
ローダー受信ディレクトリとソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。
通常、ファイルシステムのリストアはホスト間で機能しません。ソフトウェア専用インストール方法を使用してWebLogicおよびOMS Oracleホームを再構築し、以前にインストールされたアドオンをソフトウェア専用モードで再インストールして、以前に適用されたすべてのパッチを再適用する必要があります。OMS Oracleホームの場所は以前に使用した場所と同じにする必要があります。
ホストBもホスト名ホストAに反応するようにネットワーク構成を変更します。この構成方法の特別な手順については、本書では扱いません。ただし、いくつかの汎用的な構成方法を次に示します。
ホストBとホストAの両方のネットワーク・アドレスがホストBの物理IPに解決するようにDNSサーバーを変更します。
マルチホームのホストB。ホストB上でホストAの追加IPを構成します。たとえば、ホストBで次のコマンドを実行します。
> ifconfig eth0:1 <IP of HostA> netmask <netmask> > /sbin/arping -q -U -c 3 -I eth0 <IP of HostA>
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
omsca recover –as –ms –backup_file <file>
OMSを再度保護します。
emctl secure oms host <Host A>
エージェントを構成します。
> agentca -f followed by
> emctl secure agent -emdWalletSrcUrl <oms url>
次のコマンドを実行し、エージェントBに管理サービスおよびリポジトリ・ターゲットを再配置します。
emctl config emrep -agent <agent on host B>
重複したターゲットを、Enterprise Managerコンソールの「管理サービスとリポジトリ概要」ページで探します。「重複したターゲット」リンクをクリックして「重複したターゲット」ページにアクセスします。重複したターゲットのエラーを解決するには、重複したターゲットの名前を、競合が発生しているエージェントで変更する必要があります。重複したターゲットをエージェントAからエージェントBに再配置します。
サイトが完全に動作していることを確認します。
サイトは複数のOMSをホストします。すべてのOMSの前にサーバー・ロード・バランサがあります。WebLogic AdminServerを実行するプライマリOMSでemctl exportconfig omsコマンドを使用してOMS構成をバックアップしました。プライマリOMSが失われました。
解決方法:
共有ローダー受信ディレクトリと共有ソフトウェア・ライブラリの場所にアクセスできることを確認します。
以前に取得したファイルシステム・バックアップからソフトウェア・ホームをリストアします。または、バックアップが存在しない場合は、ソフトウェア専用インストール方法を使用してWebLogicおよびOMS Oracleホームを再構築し、以前にインストールされたアドオンをソフトウェア専用モードで再インストールして、以前に適用されたすべてのパッチを再適用する必要があります。OMS Oracleホームの場所は以前に使用した場所と同じにする必要があります。
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
omsca recover -as -ms -backup_file <file>
OMSとともにインストールされたエージェントを再度保護します。
emctl secure agent -emdWalletSrcUrl "http://slb:<httpport>/em"
この時点では、OMSとともに再インストールされたエージェントで使用されるポートに基づき、次の2つのオプションがあります。
オプションA: エージェントは以前と同じポートを取得します。OMSはエージェントを自動的にブロックします。エージェントをエージェントのホームページから再同期化します。
オプションB: エージェントは別のポートを取得します。次のコマンドを実行し、再インストールされたエージェントに管理サービスおよびリポジトリ・ターゲットを再配置します。
emctl config emrep -agent <reinstalled agent>
重複したターゲットを「管理サービスとリポジトリ概要」ページで探します。再インストールされたエージェントに、重複するターゲットを古いエージェントから再配置します。古いエージェントを削除します。
各追加OMSでemctl enroll omsを実行して、追加のOMS（ある場合）を、リカバリされた管理サーバーに再登録します。
サイトが完全に動作していることを確認します。
サイトは複数のOMSをホストします。OMSの前にサーバー・ロード・バランサがあります。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAのプライマリOMSが失われたため、ホストBでリカバリする必要があります。
共有ローダー受信ディレクトリと共有ソフトウェア・ライブラリの場所が新しいOMSホスト（ホストB）からアクセス可能であることを確認します。
通常、ファイルシステムのリストアはホスト間で機能しません。ソフトウェア専用インストール方法を使用して、WebLogicおよびOMS Oracleホームを再構築します。以前にインストールされたアドオンをソフトウェア専用モードで再インストールし、以前に適用されたすべてのパッチを再適用する必要があります。OMS Oracleホームの場所は以前に使用した場所と同じにする必要があります。
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
omsca recover -as -ms -backup_file <file>
エージェントを構成します。
agentca -f followed by
emctl secure agent -emdWalletSrcUrl "http://slb:<httpport>/em"
新しいOMSをSLBに追加します。
再インストールされたエージェントにOMSおよびリポジトリ・ターゲットを再配置します。
emctl config emrep -agent <agent on Host B>
重複したターゲットを「管理サービスとリポジトリ概要」ページで探します。ホストB上のエージェントに、重複したターゲットをホストA上のエージェントから再配置します。ホストA上のエージェントを削除します。
追加のOMS（ある場合）を、リカバリした管理サーバーに再登録します。
emctl enroll oms -as_host <HostB> -as_port <admin secure port>
各追加OMSでこのコマンドを実行します。
サイトが完全に動作していることを確認します。
複数のOMSサイト。OMSの前にはSLBがあります。OMS構成は最初のOMSでemctl exportconfig omsコマンドを使用してバックアップされました。追加のOMSが失われたため、同一または別のホストでリカバリする必要があります。
共有ローダー受信ディレクトリと共有ソフトウェア・ライブラリの場所にアクセスできることを確認します。
同じホストでリカバリする場合、ファイルシステム・バックアップからソフトウェア・ホームをリストアします。また、バックアップが存在しない場合や別のホストでリカバリする場合は、ソフトウェア専用インストール方法を使用してWebLogicおよびOMS Oracleホームを再構築します。以前にインストールされたアドオンをソフトウェア専用モードで再インストールし、以前に適用されたすべてのパッチを再適用する必要があります。リストアされたOMS Oracleホームの場所は、以前と同じにしてください。
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
omsca recover –ms –backup_file <file>
エージェントを構成します。
agentca -f followed by emctl secure agent -emdWalletSrcUrl "http://slb:<httpport>/em"
新しいOMSをSLBに追加します（別のホストでリカバリする場合）。
この時点では、OMSとともに再インストールされたエージェントで使用されるポートに基づき、次の3つのオプションがあります。
オプションA: 同じホストにインストールされたOMS。エージェントは以前と同じポートを取得します。
エージェントはOMSによって自動的にブロックされます。エージェントをエージェントのホームページから再同期化します。
オプションB: 同じホストにインストールされたOMS。エージェントは別のポートを取得します。
重複したターゲットを「管理サービスとリポジトリ概要」ページで探します。再インストールされたエージェントに、重複するターゲットを古いエージェントから再配置します。古いエージェントを削除します。
オプションC: 別のホストにインストールされたOMS。
重複したターゲットを「管理サービスとリポジトリ概要」ページで探します。再インストールされたエージェントに、重複するターゲットを古いエージェントから再配置します。
サイトが完全に動作していることを確認します。
エージェントは、監視対象の各ホストにデプロイされている統合ソフトウェア・コンポーネントです。これらのホスト上で実行されているすべてのターゲットの監視、中間層のOMSへのこの監視情報の伝達、ホストおよびそのターゲットの管理およびメンテナンスを行います。
エージェントのバックアップに関する特別な考慮事項はありません。ベスト・プラクティスとしては、エージェントの参照インストールを異なるプラットフォームに対して保持し、emd.propertiesファイルで実行済のカスタマイズと適用済のパッチが最新の状態に保たれるようにします。参照エージェント・インストールのインストールおよび保持には、Grid Controlコンソールのデプロイメント・オプションを使用します。
エージェントが失われた場合、参照インストールからクローニングして再インストールする必要があります。通常、参照インストールからのクローニングは、カスタマイズおよびパッチの追跡および再適用が不要なため、エージェント・インストールをリカバリする最速の方法です。同一ポートを使用してエージェントを再インストールする場合は、注意が必要です。Enterprise Managerのエージェントの再同期化機能を使用すると、再インストールされたエージェントを、リポジトリに存在するターゲット情報を使用して再構成できます。同一ポートを使用してエージェントを再インストールする場合、OMSは、エージェントが再インストールされたことを検出し、以前に行われたカスタマイズが再インストールされたエージェント内の自動検出ターゲットによって上書きされるのを防ぐため、エージェントを一時的にブロックします。
|
ブロックされたエージェント ブロックされたエージェントとは、ブロックされたエージェントからのすべてのハートビートまたはアップロード・リクエストをOMSが拒否している状態です。このため、ブロックされたエージェントは、アラートまたはメトリック・データをOMSにアップロードできません。ただし、ブロックされたエージェントは、監視データの収集は続行します。 |
エージェントの再同期化ボタンをクリックすると、エージェントのホームページでエージェントを再同期化および非ブロック化できます。再同期化では、すべてのターゲットをリポジトリからエージェントにプッシュした後、エージェントを非ブロック化します。
次の各シナリオでは、様々なエージェントのリカバリ状況とそのリカバリ手順を示します。エージェントのリカバリは、バージョン10.2.0.5以上のエージェントの場合にサポートされます。エージェントの再同期化機能では、再インストールしたエージェントが、クラッシュした以前のエージェントと同じポートを使用する必要があります。
エージェントは複数のターゲットを監視しています。エージェント・インストールが失われました。
Oracle Universal Installerを使用して、エージェントのOracleホームを削除します。
新規エージェントをインストールするか、エージェントのクローニング・オプションを使用して、Enterprise Managerを介してエージェントを再インストールします。クラッシュしたエージェントが使用していたものと同じポートを指定します。インストールの場所は、以前のインストールと同じである必要はありません。
OMSによって、エージェントが再インストールされたことが検出され、エージェントがブロックされます。
エージェントの再同期化をエージェントのホームページから開始します。
リポジトリのすべてのターゲットが新しいエージェントにプッシュされます。エージェントはバックログ・ファイルのクリアを指示されるため、クリア状態にします。エージェントは非ブロック化されます。
ユーザー定義メトリックのスクリプトの場所が変更された場合は、ユーザー定義メトリックを再構成します。
エージェントが動作しており、すべてのターゲット構成がリストアされたことを確認します。
エージェントは複数のターゲットを監視しています。エージェントOracleホームのファイルシステム・バックアップがあります。エージェント・インストールが失われました。
OUIを使用してエージェントOracleホームを削除します。
エージェントをファイルシステム・バックアップからリストアします。エージェントを起動します。
OMSによって、エージェントがバックアップからリストアされたことが検出され、エージェントがブロックされます。
エージェントの再同期化をエージェントのホームページから開始します。
リポジトリのすべてのエージェントが新しいエージェントにプッシュされます。エージェントはバックログ・ファイルのクリアを指示されるため、クリア状態にします。エージェントは非ブロック化されます。
次のemctlコマンドを使用して、エージェントが機能しており、すべてのターゲット構成がリストアされたことを確認します。
emctl status agent emctl upload agent
エラーがなく、バックログにXMLファイルがないことを確認します。
OMSとリポジトリの両方に障害が同時に発生した場合は、リカバリを同一または別のホスト上で行う必要があるかどうか、複数のOMSの前にSLBがあるかどうかなどの要因に応じて、リカバリ状況がより複雑になります。一般に、このタイプの複合障害のリカバリでは、前述の該当するリカバリ・シナリオで説明されている手順に従い、まずリポジトリを、次にOMSをリカバリします。次の各シナリオでは、OMSとリポジトリの2つの障害と、それに必要なリカバリ手順を示します。
リポジトリとOMSは同一ホスト（ホストA）にインストールされています。リポジトリ・データベースはNOARCHIVELOGモードで実行されています。全体コールド・バックアップがあります。最新のOMSバックアップ・ファイルがあります（emctl exportconfig oms）。リポジトリ、OMSおよびエージェントがクラッシュしました。
「同一ホスト上の不完全リカバリ」に示すリポジトリのリカバリ手順に従います。次の例外があります。
OMS Oracleホームが使用できず、リストアしたリポジトリに対してOMSを起動する前にリポジトリの再同期化を開始する必要があるため、次のPL/SQLブロックを介して「resync」を発行します。SQLplusを使用してリポジトリにSYSMANとしてログインし、次のコマンドを実行します。
begin emd_maintenance.full_repository_resync('<resync name>'); end;
「単一OMS、サーバー・ロード・バランサ（SLB）なし、OMSを同一ホスト上でリストア」に示すOMSリカバリ手順に従います。
サイトが完全に動作していることを確認します。
リポジトリ、プライマリOMSおよび追加OMSはすべて、異なるホスト上にあります。リポジトリ・データベースはnoarchivelogモードで実行されています。最新のバックアップのOMSバックアップ・ファイルがあります（emctl exportconfig oms）。データベースの全体コールド・バックアップがあります。3つのホストすべてが失われました。
「同一ホスト上の不完全リカバリ」に示すリポジトリのリカバリ手順に従います。次の例外があります。
OMS Oracleホームが使用できず、リストアしたリポジトリに対してOMSを起動する前にリポジトリの再同期化を開始する必要があるため、次のPL/SQLブロックを介して「resync」を発行します。SQLplusを使用してリポジトリにSYSMANとしてログインし、次のコマンドを実行します。
begin emd_maintenance.full_repository_resync('resync name'); end;
「複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ」に示すOMSリカバリ手順に従います。次の例外があります。
バックアップ・ファイルにあるリポジトリ接続記述をオーバーライドするには、追加のomscaパラメータ“-REPOS_CONN_STR <restored repos descriptor>”を渡します。「複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ」に示す他のパラメータとともにこのパラメータを追加する必要があります。
「複数OMS、SLB構成済、追加OMSを同一または別のホスト上でリカバリ」に示すOMSリカバリ手順に従います。次の例外があります。
バックアップ・ファイルにあるリポジトリ接続記述とAdminServerの詳細をオーバーライドするには、追加のomscaパラメータを渡します。
“-REPOS_CONN_STR <restored repos descriptor>” –AS_HOST <recovered admin host> -AS_HTTPS_PORT <recovered admin port>
「複数OMS、SLB構成済、追加OMSを同一または別のホスト上でリカバリ」に示す他のパラメータとともにこのパラメータを追加する必要があります。
サイトが完全に動作していることを確認します。
Enterprise Managerコマンドライン・ユーティリティ（emctl）では、すべての主要コンポーネントで必要とされるバックアップおよびリカバリ操作の実行を可能にする新規コマンドが多数追加されています。
exportconfig oms
指定したディレクトリにOMS構成のスナップショットをエクスポートします。
使用状況:
emctl exportconfig oms [-sysman_pwd <sysman password>]
[-dir <backup dir>] Specify the directory used to store the backup file
[-keep_host] Specify to back up hostname if no SLB is defined
(Use this option only if recovery will be performed
on the machine that responds to this hostname)
importconfig oms
指定したバックアップ・ファイルからOMS構成をインポートします。
使用状況:
emctl importconfig oms [-sysman_pwd <sysman password>] [-reg_pwd <registration password>]
-file <backup file> Required backup file to import from
[-key_only] Specify to import emkey only
[-no_resecure] Specify not to resecure the oms after import
(default is to resecure after import)
config emrep
OMSおよびリポジトリ・ターゲットを構成します。このコマンドを使用して、ターゲットの監視エージェントや、このターゲットの監視に使用される接続文字列を変更します。
使用状況:
emctl config emrep [-sysman_pwd <sysman password>]
[-agent <new agent>] Specify a new destination Agent for emrep target
[-conn_desc [<jdbc connect descriptor>]]
Update the Connect Descriptor with value if specified,
else from value stored in the emoms.properties file.
config repos
リポジトリ・データベース・ターゲットを構成します。このコマンドを使用して、ターゲットの監視エージェントや監視プロパティ（ホスト名、Oracleホームおよびこのターゲットの監視に使用される接続文字列）を変更します。
使用状況:
emctl config repos [-sysman_pwd <sysman password>]
[-agent <new agent>] Specify new destination agent for repository target
[-host <new host>] Specify new hostname for repository target
[-oh <new oracle home>] Specify new OracleHome for repository target
[-conn_desc [<jdbc connect descriptor>]]
Update the Connect Descriptor with the specified value,
else from the value stored in emoms.properties
resync repos
リポジトリの再同期化操作を発行します。–fullオプションを指定すると、リポジトリへの最新の状態のアップロードがすべてのエージェントに指示されます。–agentlistオプションを使用してエージェントのリストを指定すると、そのリストのエージェントと再同期化できます。
使用状況:
emctl resync repos (-full|-agentlist "agent names") [-name "resync name"] [-sysman_pwd "sysman password"]
abortresync repos
現在実行されているリポジトリの再同期化操作を中断します。リポジトリの再同期化を完全に停止するには、–fullオプションを使用します。–agentlistオプションを使用すると、リストしたエージェントとの再同期化を停止できます。
使用状況:
emctl abortresync repos (-full|-agentlist "agent names") -name "resync name" [-sysman_pwd "sysman password"]
statusresync repos
指定したリポジトリの再同期化操作のステータスをリストします。
使用状況:
emctl statusresync repos -name "resync name"
create service
Windowsでのみ有効です。このコマンドにより、Oracle Management Service用のサービスがWindows上に作成されます。このコマンドを使用して、コールド・フェイルオーバー・クラスタ設定内のフェイルオーバー・ホスト上にあるOMS用のWindowsサービスを管理します。
使用状況:
emctl create service [-user <username>] [-pwd <password>]
-name <servicename> Name of service to be created
delete service
Windowsでのみ有効です。Windows上のOracle Management Service用のサービスを削除します。
使用状況:
emctl delete service
-name <servicename> Name of service to be deleted
resyncAgent
すべてのターゲット構成をリポジトリからプッシュすることで、リストアまたは再インストールされたエージェントを再同期化します。
使用状況:
emcli resyncAgent -agent="Agent Name"
[-keep_blocked]
