25 Enterprise Managerの高可用性

この章では、各Enterprise Managerコンポーネントのインストールおよび構成に関するベスト・プラクティスを説明し、次のトピックを扱います:

エージェントの高可用性

次の各項では、管理エージェントのインストールおよび構成に関するベスト・プラクティスについて説明します。

ブート時の起動および障害時の再起動を自動的に行う管理エージェントの構成

管理エージェントは手動で起動されます。管理対象ホスト上の重要なリソースが確実にモニタリングされるように、ホストの起動時に管理エージェントが自動的に起動することが重要です。そのためには、あらゆるオペレーティング・システムのメカニズムを使用して、管理エージェントが自動的に開始するようにします。たとえば、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/agent_inst/bin/emctl getemhome'を入力するか、Enterprise Managerコンソール内のエージェント・ホームページで確認できます。

リポジトリの高可用性

次の項では、リポジトリ構成に関するベスト・プラクティスについて説明します。

リポジトリの高可用性に関する一般的なベスト・プラクティス

Enterprise Managerをインストールする前に、管理リポジトリの設定に使用されるデータベースを準備する必要があります。Database Configuration Assistant (DBCA)を使用してデータベースをインストールし、Oracleインストールのすべてのベスト・プラクティスを継承することを確認します。

  • 基本となるストレージ・テクノロジとして「自動ストレージ管理(ASM)」を選択します。

  • ARCHIVELOGモードの有効化

  • ブロック・チェックサムの有効化

  • REDOログ・ファイルのサイズおよびグループの適切な構成

  • フラッシュ・リカバリ領域の使用

  • フラッシュバック・データベースの有効化

  • ファスト・スタート・フォルト・リカバリを使用したインスタンス・リカバリ時間の制御

  • データベース・ブロック・チェックの有効化

  • DISK_ASYNCH_IOの設定

管理リポジトリへの適用が必要な高可用性の推奨事項については、MAAアドバイザを使用します。MAAアドバイザにアクセスするには、リポジトリ・データベースのホームページで「可用性」→「MAAアドバイザ」の順に選択します。

管理リポジトリをホストするデータベースが、必要な可用性が実現されるように構成されていることを確認するための、これらのベスト・プラクティスおよび他のベスト・プラクティスの詳細は、高可用性の概要を参照してください。

管理リポジトリに対するRACの構成

管理リポジトリがReal Application Cluster(RAC)データベースの場合、適切な接続文字列を使用して管理サービスを構成する必要があります。SCAN接続文字列で、リポジトリ層でのノードの追加または削除後に、リポジトリ接続記述子の再構成が必要にならないようにすることを推奨します。接続文字列では常に、SID_NAMEではなくSERVICE_NAMEが使用されるようにします。

詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

次の例では、リポジトリのための接続文字列を示します。

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primary-cluster-scan.example.com)(PORT=1521))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=PDB.example.com)))

リポジトリ接続記述子は、管理サービスから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

リポジトリ接続記述子を更新した後、任意のOMSから次のコマンドを実行して、管理サービスとリポジトリ・ターゲットに使用されるモニタリング構成に同じ変更を加えます。

emctl config emrep -conn_desc <repository_connect descriptor as above>

Oracle Management Serviceの高可用性

次の各項では、OMSの高可用性の構成について説明します。

OMSの高可用性を実現するには、まず、少なくとも1つのOMSを常に使用可能な状態にします。リカバリ時間目標(RTO)によって異なりますが、アクティブ/アクティブ構成では、少なくとも1つの追加OMSを追加することで、ノードの損失に伴う停止時間なしにこれを実現することができます。または、プライマリ・サーバーで障害が発生したときに別のサーバーの同じアドレスでOMSが実行できるようにすることで、アクティブ/パッシブ構成ではノードの損失に伴う停止時間が短縮します。高可用性を実現するアーキテクチャに関するオプションの詳細は、「高可用性ソリューション」を参照してください。

障害時リカバリを含む、さらに高度な可用性レベルに将来移行できるように、環境を最適に準備するために実行できるステップがいくつもあります。これらは、高可用性を得るために選択した方法や、インストール時に最初に選択した可用性レベルには関係ありません。これらのステップの詳細は、「別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を確保するようにEnterprise Manager OMSを構成するためのベスト・プラクティス」を参照してください。

OMSの高可用性を保証するには、Enterprise Managerによって管理される環境のサイズと範囲およびEnterprise Managerの使用方法の規模と複雑さ(管理者の数や利用される機能の種類など)に対応できるように十分な数のOMSも必要です。

環境の十分なキャパシティを保証するため、またはパッシブOMSへのフェイルオーバーに伴う停止時間を防ぐために、環境に複数のアクティブなOMSが必要な場合は、サーバー・ロード・バランサ(SLB)が必要です。SLBは、管理エージェントと管理者が一連のOMSサーバーと通信するための1つのアドレスを提供し、どのOMSが使用可能かを識別するためにOMSをモニターして、使用可能なOMSに通信をルーティングします。

SLBの実装にはコストがかかる場合があります。環境の1つのOMSで処理要件に対処できる場合、さらにOMSのアクティブ/パッシブ・フェイルオーバーに伴う停止時間がRTO要件を満たす場合は、高可用性を提供するためにSLBは必要ありません。「仮想ホスト名を使用したHAフェイルオーバーのためのアクティブ/パッシブ環境でのEnterprise Manager OMSの構成」の手順は、仮想IPアドレスと共有記憶域を使用して高可用性を構成する方法の例を示しています。

環境のRTOまたは処理ニーズに対処するために、1つ以上のOMSを追加する必要がある場合は、「追加の管理サービスのインストール」を参照してください。OMSを追加した場合は、SLBに対して複数のOMSの構成方法を確認するために、「サーバー・ロード・バランサ(SLB)の内側への複数の管理サービスの構成」を参照してください。

別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を確保するようにEnterprise Manager OMSを構成するためのベスト・プラクティス

この項では、別名ホスト名と記憶域レプリケーションを使用した障害時リカバリとの互換性を確保する方法でEnterprise Manager OMSをインストールする必要があるEnterprise Manager管理者向けに、ベスト・プラクティスを示します。将来、障害時リカバリが必要になった場合、これらのベスト・プラクティスによって実装に必要なステップが少なくなります。これらのベスト・プラクティスは、すべてのMAA高可用性レベルのインストールに対応します。最高のMAA高可用性レベルのニーズを考慮してスタンドアロンOMSをインストールすると、最大限の柔軟性が得られ、将来的にさらに上のMAA高可用性レベルに簡単に移行することができます。

概要および要件

Enterprise Manager OMSンストールで、別名ホスト名と記憶域レプリケーションを使用する障害時リカバリをサポートするためには、次のインストール条件を満たしている必要があります:

  • ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ディレクトリが、スタンバイ・サイトにレプリケートできる記憶域にインストールされている必要があります。

  • OMSのインストールは、OMSのプライマリ・サイト・ホストおよびスタンバイ・サイト・ホストと同じ別名ホスト名が維持されるような方法で実行する必要があります。別名ホスト名を使用してソフトウェアを構成すると、プライマリ・サイトまたはスタンバイ・サイトどちらのOMSホストでも変更なしで同じバイナリと構成を使用できます。

  • ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースが、スタンバイ・サイトにレプリケートできる記憶域に、Oracleインベントリの場所を使用してインストールされる必要があります。

  • ソフトウェア所有者とタイムゾーンのパラメータを、該当のOracle Management Service(OMS)をホストするすべてのノードで同じにする必要があります。

  • ミドルウェア、インスタンス、OMSエージェントおよびOracleインベントリ・ディレクトリへのパスは、このOMSをホストするすべてのノードで同じである必要があります。

ORACLE_BASEにOMSインストール・ベース・ディレクトリを作成します

障害時リカバリをサポートするには、ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ディレクトリが、スタンバイ・サイトにレプリケートできる記憶域にインストールされている必要があります。これらのそれぞれのディレクトリは、従来はORACLE_BASEの直下に配置されました。OMSを一度インストールすると、ディレクトリ・パスを変更することはできません。このようにディレクトリそれぞれがORACLE_BASEの直下にあるインストールをレプリケートされた記憶域に後から移行すると、インストール済ソフトウェアの元のディレクトリ・パスを維持するためにORACLE_BASEをレプリケートされた記憶域に再配置する必要が生じ、そのパスの下にローカルにインストールされているソフトウェアをアンインストールしてから別のローカル・ストレージ・ディレクトリに再インストールしなければならなくなるなど、複雑になることがあります。

記憶域を将来移行する際の柔軟性を最大限にするためには、1つのディレクトリをORACLE_BASEの下に作成して、すべてのOMSソフトウェア(ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ディレクトリなど)のベース・ディレクトリとして使用します。たとえば、ORACLE_BASEが/u01/app/oracleの場合は、新しいOMSインストールのベース・ディレクトリを/u01/app/oracle/OMSのように作成します。このディレクトリは、レプリケートされた記憶域のマウント・ポイントになります。ソフトウェアをこのディレクトリにローカルにインストールした場合、このディレクトリをレプリケートされた記憶域の1つのマウント・ポイントにすることができ、単純な移行が可能になります。OMSのインストール時にディレクトリの場所を指定または確認する際に、ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリがこのディレクトリの下にインストールされるように確認します。

別名ホスト名の構成

障害時リカバリをサポートするには、プライマリ・サイトのホストとスタンバイ・サイトのホストが、OMSインストールで使用されているのと同じホスト名で稼働できることが必要です。これは、別名ホスト名を使用して実現できます。

「ホスト名の計画」のガイダンスを使用して、インストールで使用する別名ホスト名を構成します。オプション2: この項に示す両方のサイトの別名ホスト名を使用すると柔軟性を最大限に高めることができるため、新しいインストール用のベスト・プラクティスとして使用することをお薦めします。

オプション2を実施するには、OMSをインストールするときに、ORACLE_HOSTNAME=<ALIAS_HOST_NAME>パラメータを指定するか、OUIインストールの「ホスト名」フィールドに別名ホスト名を指定します。たとえば、インストール・ウィザードのコマンドラインに次のパラメータを指定します。

ORACLE_HOSTNAME=oms1.example.com

OMSインストール・ベース・ディレクトリに配置されたOracleインベントリの構成

障害時リカバリをサポートするには、レプリケートされた記憶域を使用するプライマリ・サイトのホストとスタンバイ・サイトのホストによって1つのOMSインストールを共有します。レプリケートされた記憶域にはアクティブなOMSのみがマウントされます。場合によっては、プライマリ・サイトまたはスタンバイ・サイトのいずれかがアクティブ・サイトになっているときに、ソフトウェア保守アクティビティを実行する必要があります。そのような場合に、インストールの詳細を含むOracleインベントリを両方の場所から使用できることが重要です。

ローカルOracleインベントリからレプリケートされた記憶域のOracleインベントリへOMSインストールを移動するための手動移行アクティビティを実行せずにすむように、OracleインベントリをOMSインストール・ベース・ディレクトリに作成します。

次のステップを実行して、OMSインストール・ベース・ディレクトリ内に配置したインベントリを設定するようにインストーラを準備します。

  1. OMSインストール・ベース・ディレクトリを作成します。
  2. Oracleインベントリ・ディレクトリを新しいOMSインストール・ベース・ディレクトリ内に作成します。

    $ cd <OMS installation base directory>

    $ mkdir oraInventory

  3. oraInst.locファイルを作成します。このファイルには、Universal Installerで必要なOracleインベントリ・ディレクトリのパス情報が含まれます。

    $ cd oraInventory

    $ vi oraInst.loc

    Oracleインベントリ・ディレクトリのパス情報を入力し、ソフトウェア所有者のグループをoinstallユーザーとして指定します。たとえば:

    inventory_loc=/u01/app/oracle/OMS/oraInventory

    inst_group=oinstall

OMSをインストールする際に、-invPtrloc <oraInst.loc file with path>パラメータを次のようにインストール・ウィザードのコマンドラインに指定して、OracleインベントリをOMSインストール・ベース・ディレクトリに指定します。

-invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc

インストーラによって、指定の場所にインベントリが作成されます。このOMSおよびOMSエージェントのすべてのインストール、パッチ適用およびアップグレード・アクティビティにこのインベントリを使用します。

すべてのノードでのソフトウェア所有者とグループの同一構成

プライマリ・サイトに複数のOMSをインストールする際に、同じソフトウェア所有者とグループを使用するように、障害時リカバリに対応するために、スタンバイ・サイトのOMSホストでもソフトウェア所有者とグループを同じように構成する必要があります。プライマリ・サイトのために選択した所有者名およびIDとグループ名およびIDを、スタンバイ・サイトでも使用できるようにしてください。

ソフトウェア所有者のユーザーとグループの構成がすべてのOMSノードで同一であることを確認するには、次の例のようにidコマンドを実行します。

$ id -a

uid=550(oracle) gid=50(oinstall) groups=501(dba)

すべてのノードで同様に構成にするタイムゾーンの選択

プライマリ・サイトに複数のOMSをインストールする際に、同じタイムゾーンを使用するように、障害時リカバリに対応するために、スタンバイ・サイトのOMSホストでもタイムゾーンを同じように構成する必要があります。両方のサイトで使用できるタイムゾーンを選択して、すべてのOMSホストでタイムゾーンが同一になるようにします。

インストールおよび構成

次に、この項で説明したベスト・プラクティスを促進するインストール・ステップの概要を示します。必要な前提条件やインストール後の追加の作業など、インストール・ステップの詳細は、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。

NFSがマウントされたボリュームをインストールに使用する場合、マウント・コマンドでrsizeとwsizeを指定してI/O問題の発生を防止します。

たとえば:

nas.example.com:/export/share1 /u01/app/oracle/OMS nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noacl,vers=3,timeo=600 0 0

ノート:

その他の重要なNFS関連の要件は、NFSマウント・ポイントの場所の要件を確認してください。『Oracle Enterprise Manager基本インストレーション・ガイド』のEnterprise Managerシステムをインストールするための前提条件を参照してください。

ソフトウェアをインストールする場合は次のステップを参照してください。

  1. ORACLE_BASEにOMSインストール・ベース・ディレクトリを作成します。レプリケートされた記憶域にここでインストールする場合は、レプリケートされた記憶域をこのディレクトリにマウントしてください。

  2. 各OMSホストにインストールするすべてのOMSの別名ホスト名を構成します。

  3. すべてのホストで同じ定義になるようにソフトウェア所有者とグループを構成します。

  4. すべてのホストで同じ設定になるようにタイムゾーンを構成します。

  5. 『Enterprise Manager基本インストレーション・ガイド』でOracle Enterprise Managerのインストールを参照して、詳しい準備とインストールの手順に従います。インストール・プロセスでは次の情報を指定します:

    1. ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースがOMSインストール・ベース・ディレクトリ内に配置されるように確認します。

    2. インベントリの場所のファイルとOMSの別名ホスト名を指定します。これらは、コマンドラインに次の例のように指定できます。

      $ <Software_Location>/em_<platform>.bin -invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=oms1.example.com

      Enterprise Managerのインストール・ウィザードのUIからこの情報を求められた場合、ORACLE_HOSTNAMEを指定することもできます。

  6. 引き続きインストールの残りの手順を実行します。

仮想ホスト名を使用したHAフェイルオーバーのためのアクティブ/パッシブ環境でのEnterprise Manager OMSの構成

この項では、コールド・フェイルオーバー・クラスタ(CFC)環境でEnterprise Managerを構成する必要があるEnterprise Manager管理者向けに、一般的な情報を提供します。

概要および要件

Enterprise Managerで別のホストにフェイルオーバーするには、次の条件を満たしている必要があります:

  • インストールは、仮想ホスト名と関連する一意のIPアドレスを使用して行います。

  • バイナリおよびgc_instディレクトリを保持する共有ディスクやボリュームにインストールします。

  • 稼働中のノードにインベントリの場所をフェイルオーバーします。

  • ソフトウェア所有者とタイムゾーンのパラメータは、該当のOracle Management Service(OMS)をホストするクラスタ・メンバーのすべてのノードで同じにします。

インストールおよび構成

クラスタ・メンバーの物理ホスト名を仮想ホスト名でオーバーライドするには、パラメータORACLE_HOSTNAMEを使用してソフトウェアをインストールする必要があります。

コマンドライン・パラメータ-invPtrLocを使用して、共有インベントリの場所のファイルを指し示すようにソフトウェアをインストールする必要があります。このファイルには、共有インベントリの場所のパスがあります。

NFSがマウントされたボリュームをインストールに使用する場合、マウント・コマンドでrsizeとwsizeを指定してI/O問題の発生を防止します。

たとえば:

nas.example.com:/export/share1 /u01/app/share1 nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0

ノート:

共有フェイルオーバー・ボリュームについては、フェイルオーバー後にアクティブなホストにマウントできる非共有フェイルオーバー・ボリュームにも当てはまります。

仮想ホスト名/仮想IPアドレスの設定

仮想ホスト名と仮想IPアドレスを設定するには、クラスタウェアで設定できるようにするか、Oracleサービスのインストールおよび起動前にユーザー自身が手動で設定します。仮想ホスト名は静的にして、ネットワークで常に解決できるようにします。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupやtracerouteなどの標準のTCPツールを使用してホスト名を検証できます。次のコマンドを使用して検証します。

nslookup <virtual hostname>

このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。

nslookup <virtual IP>

このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。

必ずクラスタのすべてのノードでこれらのコマンドを実行し、正しい情報が返されることを検証します。

共有記憶域の設定

共有記憶域は、使用しているクラスタウェアで管理するか、あるいは、NFSなどの共有ファイル・システム(FS)ボリューム(OCFS V1などのサポート対象外のタイプを除く)を使用できます。

ノート:

OCFS V1のみ、サポート対象外です。OCFSの他のすべてのバージョンがサポートされます。

OHSディレクトリが共有記憶域上にある場合、ローカル・ディスクを指し示すようにhttpd.confファイルのLockFileディレクティブを変更する必要があります。変更しない場合、ロック問題が発生する可能性があります。

環境の設定

一部のバージョンのオペレーティング・システムでは、Enterprise Manager 24aiをインストールする前に特定のオペレーティング・システム・パッチを適用する必要があります。ユーザーがEnterprise Manager 24aiソフトウェアをインストールし使用するには、十分なカーネル・リソースを使用可能である必要もあります。詳細は、オペレーティング・システムのインストレーション・ガイドを参照してください。インストーラを起動する前に、特定の環境変数を検証する必要があります。各変数は、クラスタに参加するすべてのマシンにソフトウェアをインストールしているアカウントに対して同一に設定する必要があります。

  • OS変数TZ

    タイムゾーン設定。インストール前にこの変数の設定を解除してください。

  • PERL変数

    PERLライブラリの不正なセットへの関連付けが行われないように、PERL5LIBなどの変数の設定も解除してください。

オペレーティング・システムIDの同期化

ソフトウェア所有者のユーザーとグループは、クラスタのすべてのノードで同一に定義する必要があります。これは次のidコマンドを使用して検証できます。

$ id -a

uid=550(oracle) gid=50(oinstall) groups=501(dba)

共有インベントリの設定

次のステップで共有インベントリを設定します。

  1. 新しいORACLE_HOMEディレクトリを作成します。
  2. 新しいORACLE_HOMEにOracleインベントリ・ディレクトリを作成します。

    $ cd <shared oracle home>

    $ mkdir oraInventory

  3. oraInst.locファイルを作成します。このファイルには、Universal Installerで必要なOracleインベントリ・ディレクトリのパス情報が含まれます。

    vi oraInst.loc

    Oracleインベントリ・ディレクトリのパス情報を入力し、ソフトウェア所有者のグループをoinstallユーザーとして指定します。たとえば:

    inventory_loc=/app/oracle/share1/oraInventory

    inst_group=oinstall

ソフトウェアのインストール

ソフトウェアをインストールする場合は次のステップを参照してください。

  1. ソフトウェア・バイナリの両方のノードで共有ディスクの場所を作成します。
  2. インベントリの場所のファイルoraInst.loc(この場合はORACLE_BASEの下)を指し示し、仮想グループのホスト名を指定します。たとえば:

    $ <Software_Location>/em_<platform>.bin -invPtrLoc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.example.com -debug

    Enterprise Managerインストール・ウィザードのUIからこの情報を求められた場合、ORACLE_HOSTNAMEを指定することもできます。

  3. Oracle Management Serviceをクラスタ・メンバーのHost1にインストールします。
  4. 引き続きインストールの残りの手順を通常どおりに実行します。
  5. 完了したら、ファイルoraInst.locおよびoratabをすべてのクラスタ・メンバー・ホスト(Host2、Host3など)の/etcにコピーします。
サービスの開始

サービスは必ず正しい順序で起動してください。次の順序で行います。

  1. アクティブなノードでIPアドレスを設定します。
  2. TNSリスナー(同じフェイルオーバー・グループに含まれる場合)を起動します。
  3. データベース(同じフェイルオーバー・グループに含まれる場合)を起動します。
  4. emctl start omsを使用してEnterprise Managerを起動します
  5. 機能をテストします。

フェイルオーバーの場合は、「スイッチオーバーおよびフェイルオーバー操作の実行」を参照してください。

追加の管理サービスのインストール

追加の管理サービスをインストールするには次の2つの方法があります。

  • 「Oracle Management Serviceの追加」デプロイメント・プロシージャの使用(推奨)。このデプロイメント・プロシージャの使用の詳細は、『Oracle Enterprise Manager基本インストレーション・ガイド』のOracle Management Serviceの追加を参照してください。

  • サイレント・モードでの追加のOracle Management Serviceのインストール(代替策)。サイレント・モードでのインストールの詳細は、『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』のサイレント・モードでのOMSの追加インストールに関する章を参照してください。

サーバー・ロード・バランサ(SLB)の内側への複数の管理サービスの構成

次の各項では、サーバー・ロード・バランサを使用してアクティブ/アクティブ構成でOMSの高可用性を構成する方法について説明します。

ソフトウェア・ライブラリの構成

ソフトウェア・ライブラリの場所は、すべてのアクティブな管理サービスからアクセスできる必要があります。ソフトウェア・ライブラリがインストール中に構成されない場合、Enterprise Managerコンソールを使用してインストール後に構成する必要があります。

  1. Enterprise Managerのホームページで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。
  2. 「ソフトウェア・ライブラリ: 管理」ページで、「OMS共有ファイル・システム」を選択します。
  3. 新しいOMS共有ファイル・システムを追加するには、「+」(追加)をクリックします。
  4. 「OMS共有ファイル・システムの場所の追加」ダイアログ・ボックスで、場所の一意名を指定し、すべての管理サービス・ホストからアクセスできる共有記憶域に場所を設定します。
ロード・バランサの構成

この項では、使用可能な管理サービスにエージェントとブラウザのトラフィックを分散するサーバー・ロード・バランサ(SLB)を設定するためのガイドラインについて説明します。

サーバー・ロード・バランサの要件

SLBの背後にアクティブ/アクティブ構成でOMSを構成するために、SLBは次の要件を満たす必要があります。

  • SLBでは、公開ポートを構成して、SLBロード・バランサ構成に含まれるOMSが提供する各種サービスにアクセスできるようにする必要があります。

    構成によっては、SLBで最大4ポート(セキュア・アップロード、エージェント登録、セキュア・コンソール、非保護コンソール)が必要になる場合があります。

  • 永続性のサポート。

    ユーザー対話用ブラウザとOMSの間のHTTPおよびHTTPSトラフィックには、対話セッション全体でOMSページ間のナビゲーションが同じプール・メンバーに対して確実に発生するように永続性設定が必要です。

  • アプリケーションのモニタリングのサポート。

    SLBはOMSの状態のモニタリングと、障害の検知が可能である必要があるので、リクエストが使用できないOMSに転送されることはありません。

  • SLB環境のSSL構成についての理解。

    次に、使用可能なSSL構成を示します。

    • レイヤー3ロード・バランシング: ロード・バランサは、受信SSL接続をバックエンドのOMSサーバーにトンネリングします。このSSL構成は、SSLトンネリングとも呼ばれます。

    • SSLプロキシ: ロード・バランサはクライアントSSL接続を終端して、バックエンドOMSサーバーへのSSL接続を開始するプロキシとして機能します。これにより、ロード・バランサは、ルールの適用、仮想サーバー認証の実行、Cookie/セッションの永続性などのセッションの変更を可能にするレイヤー7検査を利用できるようになります。このSSL構成は、SSLエンドツーエンドとも呼ばれます。

    • SSL終端: ロード・バランサへのクライアント・ブラウザ・セッションは、SSLを使用して暗号化され、ロード・バランサで復号化されてから、暗号化されていないトラフィックがバックエンドOMSに送信されます。OMSでは、このSSL構成はサポートされていません。

SLBの構成には次の2つのステップがあります。

  1. SLBの構成
  2. 管理サービスで必要な変更の追加
SLB側の設定

次の表を参考にして、Enterprise Manager管理サービスとともにSLBを設定します。

次の表に示す各種構成アイテムについては、このドキュメントの後続の各項で説明します。

表25-1 管理サービスのポート

Enterprise Managerサービス OMS TCPポート モニター名 TCPプロファイル名 永続性プロファイル プール名 仮想サーバー名 SLB仮想サーバー・ポート

セキュア・コンソール

7799

mon_ccsc

tcp_ccsc

sourceip_ccsc

pool_ccsc

vs_ccsc443

443

非保護コンソール

7788

mon_ccuc

tcp_ccuc

sourceip_ccuc

pool_ccuc

vs_ccuc80

80

セキュア・アップロード

4900

mon_ccsu

tcp_ccsu

なし

pool_ccsu

vs_ccsu4900

4900

エージェント登録

4889

mon_ccar

tcp_ccar

cookie_ccar

pool_ccar

vs_ccar4889

4889

Always-On Monitoringセキュア・アップロード

8081

mon_ccaom

tcp_ccaom

なし

pool_ccaom

vs_ccaom8081

8081

セキュアなJVMD

7301

mon_ccsjvmd

tcp_ccsjvmd

sourceip_ccsjvmd

pool_ccsjvmd

vs_ccsjvmd7301

7301

非保護JVMD

7202

mon_ccujvmd

tcp_ccujvmd

sourceip_ccujvmd

pool_ccujvmd

vs_ccujvmd7202

7202

暗号プロファイルは、HTTPSトラフィックのセキュリティ、互換性および速度を定義するために使用します。暗号はEnterprise Managerでサポートされ、Enterprise Managerへの接続に使用できる暗号または除外する必要がある暗号を決定するためにSLB管理者が使用します。

ノート:

Always-On MonitoringサービスがHA構成内のOMSホスト以外のホストにインストールされる場合は、OMSホストのかわりに、Always-On Monitoringサービスをインストールするホストを指定する必要があります
SLBにパッケージされている管理ツールを使用します。サンプル構成が付属しています。この例では、表33-1に示すデフォルトのポートを使用してホストAおよびホストBで2つの管理サービスが実行していると仮定します。

  1. モニターの作成

    モニターは、プール・メンバーの動作状況を検証する場合に使用されます。モニターは、ロード・バランシング・プールのメンバーであるノード上の接続やサービスを検証します。これは、規定の間隔でサービスのステータスを断続的に確認するように設計されます。確認するサービスが指定時間内に応答しない場合、ロード・バランサはプールから自動的にそのサービスを取り出し、プールの他のメンバーを選択します。ノードやサービスが再度使用可能になると、モニターはその状況を検出し、プールから自動的にアクセス可能なメンバーがトラフィックを処理できます。

    表25-2 モニター

    Enterprise Managerサービス OMS TCPポート モニター名 タイプ 間隔 タイムアウト 送信文字列 受信文字列

    セキュア・コンソール(SSLを使用していない場合)

    7799

    mon_ccsc

    HTTPS

    5

    16

    		 
    GET /em/consoleStatus.jsp HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close

    Enterprise Manager Console is UP

    非保護コンソール(SSLを使用していない場合)

    7788

    mon_ccuc

    HTTP

    5

    16

    		 
    GET /em/consoleStatus.jsp HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close

    Enterprise Manager Console is UP

    セキュア・アップロード

    4900

    mon_ccsu

    HTTPS

    60

    181

    		 
    GET /empbs/upload HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close

    Http Receiver Servlet active!

    エージェント登録

    4889

    mon_ccar

    HTTP

    60

    181

    		 
    GET /empbs/genwallet HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close

    GenWallet Servlet activated

    Always-On Monitoringセキュア・アップロード

    8081

    mon_ccaom

    HTTPS

    60

    181

    		 
    GET /upload HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close

    Always On Monitoring is active

    セキュアなJVMD

    7301

    mon_ccsjvmd

    HTTPS

    60

    181

    		 
    GET /jamservlet/comm HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
    		 
    Reply to empty request

    非保護JVMD

    7202

    mon_ccujvmd

    HTTPS

    60

    181

    		 
    GET /jamservlet/comm HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
    		 
    Reply to empty request

    ノート:

    一部のロード・バランサでは、リテラル\r\nを使用して送信文字列に明示的に追加するには、<CR><LF>文字が必要です。これはベンダー固有です。詳細は、SLBのドキュメントを参照してください。

  2. プールの作成

    プールとは、サーバーのセットのことです。このセットは、ロード・バランサの背後に構成され、OMSサービスごとに特定のTCPポートを通じてトラフィックを受信するようにグループ化されています。

    ロード・バランシングの方式は、SLBベンダーによって異なります。一般的な方式として、ラウンドロビン方式、最小接続方式、ソースIPハッシュ方式があります。ご使用のSLBのドキュメントで使用可能な方式を調べて、目的のSLBとオペレーティング・システム環境に最適な方式を判断してください。

    各プールには、永続性の定義の独自の特性と、使用されるロード・バランシング・アルゴリズムがあります。

    表25-3 プール

    Enterprise Managerサービス プール名 関連付けられた状態モニター ロード・バランシング OMSホスト:OMSサービス・ポート

    セキュア・コンソール

    pool_ccsc

    mon_ccsc

    最小接続(メンバー)

    OMSホストA:7799

    OMSホストB:7799

    非保護コンソール

    pool_ccuc

    mon_ccuc

    最小接続(メンバー)

    OMSホストA:7788

    OMSホストB:7788

    セキュア・アップロード

    pool_ccsu

    mon_ccsu

    最小接続(メンバー)

    OMSホストA:4900

    OMSホストB:4900

    エージェント登録

    pool_ccar

    mon_ccar

    最小接続(メンバー)

    OMSホストA:4889

    OMSホストB:4889

    Always-On Monitoringセキュア・アップロード

    pool_ccaom

    mon_ccaom

    最小接続(メンバー)

    OMSホストA:8081

    OMSホストB:8081
    セキュアなJVMD pool_ccsjvmd mon_ccsjvmd 最小接続(メンバー)

    OMSホストA:7301

    OMSホストB:7301

    非保護JVMD

    pool_ccujvmd

    mon_ccujvmd

    		最小接続(メンバー)

    OMSホストA:7202

    OMSホストB:7202

  3. TCPプロファイルの作成

    TCPプロファイルは、ネットワーク・トラフィックの特定のタイプ(TCPやHTTPなど)の動作を制御するための構成可能な設定であるTCP設定のコレクションです。こうしたプロファイルにより、ネットワーク・トラフィックの制御が強化され、ユーザーは特定のクライアントまたはアプリケーションの様々な特性(異なるブラウザなど)を制御できます。

    さらに、個別のTCPプロファイルは、対象のオペレーティング環境の必要に応じて異なるサービスまたは仮想サーバーに関連付けることができます。

    TCPプロファイルの値は、ネットワーク・パフォーマンスに重大な影響を与える可能性があるため慎重に使用する必要があります。また、ネットワークおよび操作の要件を十分に検討して使用してください。

    TCPプロファイルの設定は、サイトおよびSLBに固有であるため、TCPプロファイルの設定について特定のOMS要件はありません。TCPプロファイルの必要な構成設定については、SLBのドキュメントおよびネットワーク管理者に問い合せてください。

    表25-4 TCPプロファイル

    Enterprise Managerサービス TCPプロファイル名

    セキュア・コンソール

    tcp_ccsc

    非保護コンソール

    tcp_ccuc

    セキュア・アップロード

    tcp_ccsu

    エージェント登録

    tcp_ccar

    Always-On Monitoringセキュア・アップロード

    tcp_ccaom
    セキュアなJVMD tcp_ccsjvmd
    非保護JVMD tcp_ccujvmd

  4. 永続性プロファイルの作成

    特定のタイプのアプリケーションでは、同じクライアントが同じプール・メンバーに戻る必要があります。これは、永続性または「スティッキネス」と呼ばれます。これを、永続性プロファイルを使用して構成し、仮想サーバーに適用できます。Oracle Enterprise Managerサービスの場合、セキュア・アップロード・サービス以外の各サービスに対して永続性を構成する必要があります。

    一部の製品では、Cookieなしのセッション永続性がサポートされます。このような製品は、受信リクエストのIPアドレスに依存します。状況によっては、発信元IPアドレスが変更されることがあり、セッションの永続性が失われることや、リクエストが誤ったバックエンド・サーバーにリダイレクトされることがあります。そのような場合は、ソース・アドレス・アフィニティではなく、永続性のためにCookieを使用するようにサービスを定義することをお薦めします。Cookieの永続性は、SSLプロキシ接続アーキテクチャを実装しているときにのみ適用できます。レイヤー3ロード・バランシング(旧称: SSLトンネリング)の場合、永続性タイプの選択肢はソース・アドレス・アフィニティのみです。

    表25-5 永続性プロファイル

    Enterprise Managerサービス 永続性プロファイル名 タイプ タイムアウト 有効期限

    セキュア・コンソール

    sourceip_ccsc

    ソース・アドレス・アフィニティまたはCookie

    3600

    該当なし

    非保護コンソール

    sourceip_ccuc

    ソース・アドレス・アフィニティまたはCookie

    3600

    該当なし

    エージェント登録

    cookie_ccar

    Cookie

    該当なし

    3600

    セキュアなJVMD

    sourceip_ccsjvmd

    ソース・アドレス・アフィニティ

    3600

    該当なし

    非保護JVMD

    sourceip_ccujvmd

    ソース・アドレス・アフィニティまたはCookie

    3600

    該当なし

  5. ルールの作成

    ルールは、ロード・バランサ・デバイスを通過するネットワーク・トラフィックに対して実行するスクリプトです。ルールを使用すると、機能的なニーズに応じて様々な方法でネットワーク・トラフィックに影響を与えることができます。

    ローカルのロード・バランサに応じて、次のようなタイプのルールを構成できます。
    • リクエストのソースに基づいてアプリケーション・リソースへのアクセスを提供するアクセス制御ルール。
    • 許可されるHTTPメソッドを指定するアクセス・メソッド・ルール。
    • 受信HTTPリクエストを別の宛先URLにルーティングするURLリダイレクト・ルール。
    • HTTPリクエスト・ヘッダーまたはレスポンス・ヘッダーを追加、変更または削除するリクエスト・ヘッダー・ルールおよびレスポンス・ヘッダー・ルール。
    • HTTPヘッダーのサイズと、ヘッダー内でピリオド文字およびアンダースコア文字を使用できるかどうかを指定するHTTPヘッダー・ルール。

    ルールの機能とルール定義の構文は、ロード・バランサのベンダーによって異なります。これらの機能と構文ガイダンスの詳細は、ベンダーのドキュメントを参照してください。

    このドキュメントの例では、非保護コンソールと非保護BI Publisherの仮想サーバーは、非保護コンソール・サービス(ポート80)と非保護BI Publisher (ポート8080)にリクエストをリダイレクトして、ロード・バランサ上のセキュア・コンソール・サービス(ポート443)とセキュアBI Publisher (ポート5443)に送信するために、概念的なルールを使用しています。

  6. 仮想サーバーの作成

    仮想サーバー(仮想IPアドレスとポート番号を含む)は、クライアントのアドレス可能なホスト名またはIPアドレスであり、これによって、クライアントはロード・バランシング・プールのメンバーを利用できます。仮想サーバーがリクエストを受信すると、選択したロード・バランシング方法に基づいてそのリクエストをプールのメンバーに誘導します。

    表25-6 必須仮想サーバー

    Enterprise Managerサービス 仮想サーバー名 仮想IPおよびポート プロトコル・プロファイル(クライアント) ルール名 デフォルト・プール デフォルトの永続性プロファイル

    セキュア・コンソール

    vs_ccsc443

    VIP:443

    tcp_ccsc

    なし

    pool_ccsc

    sourceip_ccsc

    非保護コンソール*

    vs_ccuc80

    VIP:80

    tcp_ccuc

    ccuc_httptohttps

    pool_ccuc

    sourceip_ccuc

    セキュア・アップロード

    vs_ccsu4900

    VIP:4900

    tcp_ccsu

    なし

    pool_ccsu

    なし

    エージェント登録

    vs_ccar4889

    VIP:4889

    tcp_ccar

    なし

    pool_ccar

    cookie_ccar

    Always-On Monitoringセキュア・アップロード

    vs_ccaom8081

    VIP:8081

    tcp_ccaom

    なし

    pool_ccaom

    sourceip_aom

    セキュアなJVMD

    vs_ccsjvmd7301

    VIP:7301

    tcp_ccsjvmd

    なし

    pool_ccsjvmd

    sourceip_ccsjvmd

    非保護JVMD

    vs_ccujvmd7202

    VIP:7202

    tcp_ccujvmd

    なし

    pool_ccujvmd

    sourceip_ccujvmd

    * これらのエントリはEnterprise Managerへの非保護および非暗号化アクセスを提供するため、ベスト・プラクティスとは見なされず、推奨されません。

Enterprise Manager側の設定

次のステップを実行してください。

  1. Oracle Management Serviceの再保護

    デフォルトでは、管理サービス側証明書のサービス名は、管理サービス・ホストの名前を使用します。管理エージェントは、ロード・バランサ経由でOracle Management Serviceと通信する場合、この証明書を受け入れません。次のコマンドを実行して、各管理サービスで証明書を再生成する必要があります。

    emctl secure oms   
  -host slb.example.com    
  -secure_port 4900    
  -slb_port 4900   
  -slb_console_port 443
  -slb_jvmd_https_port 7301
  -lock_consle
  -lock_upload
  Oracle Enterprise Manager 24 Release 1
  Copyright (c) 1996, 2024 Oracle Corporation. All rights reserved.
  Securing OMS... Started
  Enter Enterprise Manager Root (SYSMAN) Password :
  Enter Agent Registration Password :
  (c) 1996, 2024 Oracle Corporation. All rights reserved.
  Securing OMS... Started.
  Securing OMS... Successful
  Restart OMS

    slb_console_portは、Enterprise Managerにアクセスするために使用される仮想サーバー・ポートに相当します。これは、上で(仮想サーバー名 - vs_gcsc443) 443の仮想サーバー・ポートとともに定義されます。

    Oracle Management Serviceを再保護した後で、OMSを再起動します。このステップは、ロード・バランサでサポートするOMSごとに繰り返します。

  2. すべての管理エージェントを再保護します。

    SLB設定の前にインストールされた管理エージェント(管理サービス・インストールに付属する管理エージェントなど)は、管理サービスに直接アップロードしています。これらの管理エージェントは、SLBの設定後にアップロードできません。これらの管理エージェントを再保護してSLBにアップロードするには、各管理エージェントで次のコマンドを実行します。

    emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em
  3. Always-On Monitoringの構成

    emscaユーティリティを使用してAlways-on Monitoringアプリケーションを構成する方法の詳細は、『Enterprise Manager管理者ガイド』でAlway-On Monitoringの章を参照してください。

    特定のOMSを保護した後、それらに対して次のコマンドを一度だけ実行します。 

    emctl set property -name "oracle.sysman.core.events.emsURL" -value "https://slb.example.com:8081/upload"                         

Enter Enterprise Manager Root (SYSMAN) Password :

Oracle Enterprise Manager 24 Release 1

Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
 
Property oracle.sysman.core.events.emsURL has been set to value

https://slb.example.com:8081/upload for all Management Servers

OMS restart is not required to reflect the new property value

    このコマンドを有効にするために、Enterprise Managerコンポーネントを再起動する必要はありません。

    2つ目/後続のAlways-On Monitoringインスタンスの追加

    最新のAlways-On Monitoring (AOM)リリースを「自己更新」からダウンロードします。AOMのインストール先の場所にems.zipファイルをコピーして、そのファイルを解凍します。

    emscaツールは、次の例で示すように、Always-On Monitoringインスタンスを同じ/異なるホストにさらに追加するために再実行できます。 

    cd ems/scripts

./emsca add_ems
Oracle Enterprise Manager 24 Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved. 
---------------------------------------------------------------  
Event Monitoring Service Repository Connection String : emshost:25059:emssid
Event Monitoring Service Repository Username : ems
Event Monitoring Service Repository Password :
Enterprise Manager Repository Connection String : emhost:25059:emsid
Enterprise Manager Repository Username : sysman
Enterprise Manager Repository Password :
Enter Enterprise Manager Middleware Home : /mylocation/omsOracleHome
Connecting to EMS repository.
Registering EMS instance
Event Monitoring Service Upload URL: https://myemshost:1830/upload
Oracle PKI Tool : Version 12.1.3.0.0
Copyright (c) 2004, 2024, Oracle and/or its affiliates. All rights reserved.
Certificate was added to keystore
  4. EMCLIの構成

    EMコンソールのSLBホスト名とポートを使用するように、EMCLIクライアント・インストールを構成します。この再構成には、約15分から20分かかることがあります。

     emcli setup -url=”https://slb.example.com:443/em” -username=sysman -trustall
Enterprise ManagerとSLBでのSSLの構成

SLBを構成してサード・パーティ/カスタムSSL証明書を使用する場合、エージェント、SLBおよびOMSの間の信頼関係を維持するためにCA証明書が適切に構成されていることを確認する必要があります。具体的には、次の内容を実行する必要があります。

  • SLBのCA証明書をOMSトラスト・ストアにインポートします。

  • Enterprise Manager CA証明書をSLBのトラスト・ストアにコピーします。

Enterprise Managerでは、カスタム証明書ではなく、デフォルトのEnterprise Manager証明書が使用されます。エージェントでSLBを介してOMSに正常に情報がアップロードされるようにするには、これらの信頼できるカスタム証明書を、OMSとエージェントのトラスト・ストアにコピー/インポートする必要があります。次の手順は、SLBがサード・パーティ/カスタムSSL証明書で構成されている場合の、OMSとエージェントの保護に使用されるプロセスを示しています。

SLBで使用されるSSL証明書の確認

次のステップを実行して、SLBがOMSと別の証明書を使用しているかどうかを確認します。

  1. URLで使用されている証明書チェーンを確認するには、次のコマンドを実行します。

    <OMS_HOME>/bin/emctl secdiag openurl -url <HTTPS URL>

    SLB URLで使用されている証明書を確認するには、次のコマンドを実行します。

    <OMS_HOME>/bin/emctl secdiag openurl -url https://<SLB Hostname>:<HTTPS Upload port>/empbs/upload

    OMS URLで使用されている証明書を確認するには、次のコマンドを実行します。

    <OMS_HOME>/bin/emctl secdiag openurl -url https://<OMS Hostname>:<HTTPS Upload port>/empbs/upload

  2. デフォルトのEnterprise Manager自己署名証明書がSLBで使用される場合、両方のコマンドの出力は次のように表示されます。

    発行者 : CN=<OMS Hostname>, C=US, ST=CA, L=<OMS Hostname>のEnterpriseManager, OU=<OMS Hostname>のEnterpriseManager, O=<OMS Hostname>のEnterpriseManager

  3. カスタムまたは自己署名SSL証明書がSLBで使用される場合、SLB名で実行されるコマンドの出力が次に示されている詳細を提供します。

    発行者 : CN=Entrust Certification Authority - L1C, OU="(c) 2024 Entrust, Inc.", OU=www.entrust.net/rpa is incorporated by reference, O="Entrust, Inc.", C=US

    この例では、SLBは信頼できる証明書としてOMSにインポートする必要があるカスタム証明書(CN=Entrust Certification Authority - L1C, OU="(c) 2024 Entrust, Inc.")を使用しています。

  4. OpenSSLがOSで使用できる場合、次のコマンドを実行してCNの値も確認できます。

    openssl s_client -connect <HOSTNAME>:<PORT>

OMSおよびエージェントのトラスト・ストアへのSLBのSSL証明書のインポート

  1. base64形式のSLB証明書をcustomca.txtという名前のテキスト・ファイルにエクスポートします。
  2. OMSを保護します。

    cd <OMS_HOME>/bin>

    ./emctl secure oms -host <SLB Host name> -secure_port <HTTPS Upload Port> -slb_port <SLB upload Port> -slb_console_port <SLB Console port> -console -trust_certs_loc <path to customca.txt>

    ノート:

    emctl secure omsコマンドを使用してSLBの背後のすべてのOMSを保護する必要があります。

    OMSのCA証明書は<EM_INSTANCE_HOME>/em/EMGC_OMS1/sysman/config/b64LocalCertificate.txtファイルに存在し、SLBのSSLトラスト・ストアにコピーする必要があります。

  3. すべてのOMSを再起動します。

    cd <OMS_HOME>/bin

    emctl stop oms -all

    emctl start oms

  4. このEnterprise Manager設定を指すすべてのエージェントを保護します。

    cd <AGENT_HOME>/bin

    ./emctl secure agent –emdWalletSrcUrl <SLB Upload URL>

複数のOMS高可用性をSLBの背後に構成する方法の詳細は、Oracle Maximum Availability Architecture Best Practices for Enterprise Managerを参照してください。