| Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド 13cリリース1 E70367-03 |
|
 前 |
 次 |
この章では、各Cloud 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/agent_inst/bin/emctl getemhomeを入力するか、Cloud Controlコンソールのエージェントのホームページで確認できます。
次の項では、リポジトリ構成に関するベスト・プラクティスについて説明します。
Enterprise Managerをインストールする前に、管理リポジトリの設定に使用されるデータベースを準備する必要があります。Database Configuration Assistant (DBCA)を使用してデータベースをインストールし、Oracleインストールのすべてのベスト・プラクティスを継承することを確認します。
基本となるストレージ・テクノロジとして「自動ストレージ管理(ASM)」を選択します。
ARCHIVELOGモードの有効化
ブロック・チェックサムの有効化
REDOログ・ファイルのサイズおよびグループの適切な構成
フラッシュ・リカバリ領域の使用
フラッシュバック・データベースの有効化
ファスト・スタート・フォルト・リカバリを使用したインスタンス・リカバリ時間の制御
データベース・ブロック・チェックの有効化
DISK_ASYNCH_IOの設定
管理リポジトリへの適用が必要な高可用性の推奨事項については、MAAアドバイザを使用します。MAAアドバイザにアクセスするには、リポジトリ・データベースのホームページで「可用性」→「MAAアドバイザ」の順に選択します。
管理リポジトリをホストするデータベースが必要な可用性を実現するように構成するための、これらのベスト・プラクティスおよび他のベスト・プラクティスの詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。
管理リポジトリがReal Application Cluster(RAC)データベースの場合、適切な接続文字列を使用して管理サービスを構成する必要があります。SCAN接続文字列で、リポジトリ層でのノードの追加または削除後に、リポジトリ接続記述子の再構成が必要にならないようにすることを推奨します。接続文字列では常に、SID_NAMEではなくSERVICE_NAMEが使用されるようにします。
詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
次の例に、データベース・バージョンが11gリリース2より前である場合のリポジトリの接続文字列を示します。
(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)))
次の例に、データベース・バージョンが11gリリース2以上である場合のリポジトリの接続文字列を示します。
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primary-cluster-scan.example.com)(PORT=1521))(CON NECT_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>
次の各項では、OMSの高可用性の構成について説明します。
OMSの高可用性を実現するには、まず、少なくとも1つのOMSを常に使用可能な状態にします。リカバリ時間目標(RTO)によって異なりますが、アクティブ/アクティブ構成では、少なくとも1つの追加OMSを追加することで、ノードの損失に伴う停止時間なしにこれを実現することができます。または、プライマリ・サーバーで障害が発生したときに別のサーバーの同じアドレスでOMSが実行できるようにすることで、アクティブ/パッシブ構成ではノードの損失に伴う停止時間が短縮します。高可用性を実現するアーキテクチャに関するオプションの詳細は、第18章「高可用性ソリューション」を参照してください。
障害時リカバリを含む、さらに高度な可用性レベルに将来移行できるように、環境を最適に準備するために実行できる手順がいくつもあります。これらは、高可用性を得るために選択した方法や、インストール時に最初に選択した可用性レベルには関係ありません。これらの手順の詳細は、「別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSを構成するためのベスト・プラクティス」を参照してください。
OMSの高可用性を保証するには、Enterprise Managerによって管理される環境のサイズと範囲およびEnterprise Managerの使用方法の規模と複雑さ(管理者の数や利用される機能の種類など)に対応できるように十分な数のOMSも必要です。
環境の十分なキャパシティを保証するため、またはパッシブOMSへのフェイルオーバーに伴う停止時間を防ぐために、環境に複数のアクティブなOMSが必要な場合は、サーバー・ロード・バランサ(SLB)が必要です。SLBは、管理エージェントと管理者が一連のOMSサーバーと通信するための1つのアドレスを提供し、どのOMSが使用可能かを識別するためにOMSを監視して、使用可能なOMSに通信をルーティングします。
SLBの実装にはコストがかかる場合があります。環境の1つのOMSで処理要件に対処できる場合、さらにOMSのアクティブ/パッシブ・フェイルオーバーに伴う停止時間がRTO要件を満たす場合は、高可用性を提供するためにSLBは必要ありません。「仮想ホスト名を使用したHAフェイルオーバーのアクティブ/パッシブ環境でのCloud Control OMSの構成」の手順は、仮想IPアドレスと共有記憶域を使用して高可用性を構成する方法の例を示しています。
環境のRTOまたは処理ニーズに対処するために、1つ以上のOMSを追加する必要がある場合は、「追加の管理サービスのインストール」を参照してください。OMSを追加した場合は、SLBに対して複数のOMSの構成方法を確認するために、「サーバー・ロード・バランサ(SLB)の内側への複数の管理サービスの構成」を参照してください。
この項では、別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSをインストールする、Cloud Control管理者のためのベスト・プラクティスを説明します。将来、障害時リカバリが必要になった場合、これらのベスト・プラクティスによって実装に必要な手順が少なくなります。これらのベスト・プラクティスは、すべてのMAA高可用性レベルのインストールに対応します。最高のMAA高可用性レベルのニーズを考慮してスタンドアロンOMSをインストールすると、最大限の柔軟性が得られ、将来的にさらに上のMAA高可用性レベルに簡単に移行することができます。
Cloud Control OMSインストールが、別名ホスト名と記憶域レプリケーションを使用する障害時リカバリをサポートするためには、次のインストール条件を満たす必要があります。
ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ディレクトリが、スタンバイ・サイトにレプリケートできる記憶域にインストールされている必要があります。
OMSのインストールは、OMSのプライマリ・サイト・ホストおよびスタンバイ・サイト・ホストと同じ別名ホスト名が維持されるような方法で実行する必要があります。別名ホスト名を使用してソフトウェアを構成すると、プライマリ・サイトまたはスタンバイ・サイトどちらのOMSホストでも変更なしで同じバイナリと構成を使用できます。
ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースが、スタンバイ・サイトにレプリケートできる記憶域に、Oracleインベントリの場所を使用してインストールされる必要があります。
ソフトウェア所有者とタイムゾーンのパラメータを、該当のOracle Management Service(OMS)をホストするすべてのノードで同じにする必要があります。
ミドルウェア、インスタンス、OMSエージェントおよびOracleインベントリ・ディレクトリへのパスは、この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
障害時リカバリをサポートするには、レプリケートされた記憶域を使用するプライマリ・サイトのホストとスタンバイ・サイトのホストによって1つのOMSインストールを共有します。レプリケートされた記憶域にはアクティブなOMSのみがマウントされます。場合によっては、プライマリ・サイトまたはスタンバイ・サイトのいずれかがアクティブ・サイトになっているときに、ソフトウェア保守アクティビティを実行する必要があります。そのような場合に、インストールの詳細を含むOracleインベントリを両方の場所から使用できることが重要です。
ローカルOracleインベントリからレプリケートされた記憶域のOracleインベントリへOMSインストールを移動するための手動移行アクティビティを実行せずにすむように、OracleインベントリをOMSインストール・ベース・ディレクトリに作成します。
次の手順を実行して、OMSインストール・ベース・ディレクトリ内に配置したインベントリを設定するようにインストーラを準備します。
OMSインストール・ベース・ディレクトリを作成します。
Oracleインベントリ・ディレクトリを新しいOMSインストール・ベース・ディレクトリ内に作成します。
$ cd <OMS installation base directory>
$ mkdir oraInventory
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関連の要件は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のNFSマウント・ポイントの場所の要件に関する項を参照してください。 |
ソフトウェアをインストールする場合は次の手順を参照してください。
ORACLE_BASEにOMSインストール・ベース・ディレクトリを作成します。レプリケートされた記憶域にここでインストールする場合は、レプリケートされた記憶域をこのディレクトリにマウントしてください。
各OMSホストにインストールするすべてのOMSの別名ホスト名を構成します。
すべてのホストで同じ定義になるようにソフトウェア所有者とグループを構成します。
すべてのホストで同じ設定になるようにタイムゾーンを構成します。
Enterprise Manager基本インストレーション・ガイドのOracle Enterprise Manager Cloud Control 13cリリース1のインストールに関する項を参照して、詳しい準備とインストールの手順に従います。インストール・プロセスでは次の情報を指定します。
ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースがOMSインストール・ベース・ディレクトリ内に配置されるように確認します。
インベントリの場所のファイルとOMSの別名ホスト名を指定します。これらは、コマンドラインに次の例のように指定できます。
$ <Software_Location>/em_<platform>.bin -invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=oms1.example.com
Enterprise Managerのインストール・ウィザードのUIからこの情報を求められた場合、ORACLE_HOSTNAMEを指定することもできます。
引き続きインストールの残りの手順を実行します。
この項では、コールド・フェイルオーバー・クラスタ(CFC)環境でEnterprise Manager Cloud Controlを構成するCloud Control管理者向けの一般的な情報を提供します。
Cloud Controlが別のホストにフェイルオーバーするには、次の条件を満たす必要があります。
インストールは、仮想ホスト名と関連する一意の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アドレスを設定するには、クラスタウェアで設定できるようにするか、Oracleサービスのインストールおよび起動前にユーザー自身が手動で設定します。仮想ホスト名は静的にして、ネットワークで常に解決できるようにします。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupやtracerouteなどの標準のTCPツールを使用してホスト名を検証できます。次のコマンドを使用して検証します。
nslookup <virtual hostname>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
nslookup <virtual IP>
このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。
必ずクラスタのすべてのノードでこれらのコマンドを実行し、正しい情報が返されることを検証します。
共有記憶域は、使用しているクラスタウェアで管理するか、あるいは、NFSなどの共有ファイルシステム(FS)ボリューム(OCFS V1などのサポート対象外のタイプを除く)を使用できます。
|
注意: OCFS V1のみ、サポート対象外です。OCFSの他のすべてのバージョンがサポートされます。 |
OHSディレクトリが共有記憶域上にある場合、ローカル・ディスクを指し示すようにhttpd.confファイルのLockFileディレクティブを変更する必要があります。変更しない場合、ロック問題が発生する可能性があります。
一部のバージョンのオペレーティング・システムでは、13cをインストールする前に特定のオペレーティング・システム・パッチを適用する必要があります。ユーザーが13cソフトウェアをインストールして使用するには、十分なカーネル・リソースも使用できるようにしておく必要があります。詳細は、オペレーティング・システムのインストール・ガイドを参照してください。インストーラを起動する前に、特定の環境変数を検証する必要があります。各変数は、クラスタに参加するすべてのマシンにソフトウェアをインストールしているアカウントに対して同一に設定する必要があります。
OS変数TZ
タイムゾーン設定。インストール前にこの変数の設定を解除してください。
PERL変数
PERLライブラリの不正なセットへの関連付けが行われないように、PERL5LIBなどの変数の設定も解除してください。
ソフトウェア所有者のユーザーとグループは、クラスタのすべてのノードで同一に定義する必要があります。これは次のidコマンドを使用して検証できます。
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
次の手順で共有インベントリを設定します。
新しいORACLE_HOMEディレクトリを作成します。
新しいORACLE_HOMEにOracleインベントリ・ディレクトリを作成します。
$ cd <shared oracle home>
$ mkdir oraInventory
oraInst.locファイルを作成します。このファイルには、Universal Installerで必要なOracleインベントリ・ディレクトリのパス情報が含まれます。
vi oraInst.loc
Oracleインベントリ・ディレクトリのパス情報を入力し、ソフトウェア所有者のグループをoinstallユーザーとして指定します。次に例を示します。
inventory_loc=/app/oracle/share1/oraInventory
inst_group=oinstall
ソフトウェアをインストールする場合は次の手順を参照してください。
ソフトウェア・バイナリの両方のノードで共有ディスクの場所を作成します。
インベントリの場所のファイル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を指定することもできます。
Oracle Management Serviceをクラスタ・メンバーのHost1にインストールします。
引き続きインストールの残りの手順を通常どおりに実行します。
完了したら、ファイルoraInst.locおよびoratabをすべてのクラスタ・メンバー・ホスト(Host2、Host3など)の/etcにコピーします。
サービスは必ず正しい順序で起動してください。次の順序で行います。
アクティブなノードでIPアドレスを設定します。
TNSリスナー(同じフェイルオーバー・グループに含まれる場合)を起動します。
データベース(同じフェイルオーバー・グループに含まれる場合)を起動します。
emctl start omsを使用してCloud Controlを起動します。
機能をテストします。
フェイルオーバーの場合は、「スイッチオーバーおよびフェイルオーバー操作の実行」を参照してください。
追加の管理サービスをインストールするには次の2つの方法があります。
Oracle Management Serviceの追加デプロイメント・プロシージャの使用(推奨)。デプロイメント・プロシージャの使用の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のOracle Management Serviceの追加に関する章を参照してください。
サイレント・モードでの追加のOracle Management Serviceのインストール(代替策)。サイレント・モードでのインストールの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のサイレント・モードでの追加のOMSのインストールに関する説明を参照してください。
次の各項では、サーバー・ロード・バランサを使用してアクティブ/アクティブ構成でOMSの高可用性を構成する方法について説明します。
ソフトウェア・ライブラリの場所は、すべてのアクティブな管理サービスからアクセスできる必要があります。ソフトウェア・ライブラリがインストール中に構成されない場合、Enterprise Managerコンソールを使用してインストール後に構成する必要があります。
Enterprise Managerのホームページで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。
「ソフトウェア・ライブラリ: 管理」ページで、「OMS共有ファイルシステム」を選択します。
新しいOMS共有ファイルシステムを追加するには、「+」(追加)をクリックします。
「OMS共有ファイル・システムの場所の追加」ダイアログ・ボックスで、場所の一意名を指定し、すべての管理サービス・ホストからアクセスできる共有記憶域に場所を設定します。
この項では、使用可能な管理サービスにエージェントとブラウザのトラフィックを分散するサーバー・ロード・バランサ(SLB)を設定するためのガイドラインについて説明します。
サーバー・ロード・バランサの要件
SLBの背後にアクティブ/アクティブ構成でOMSを構成するために、SLBは次の要件を満たす必要があります。
SLBは複数の仮想サーバー・ポートをサポートする必要があります。
構成によっては、SLBで最大5ポートが必要になる場合があります(セキュア・アップロード、エージェント登録、セキュア・コンソール、非保護コンソール、BI Publisher)。
永続性のサポート。
ブラウザとOMS間のHTTPおよびHTTPSトラフィックには永続性が必要です。
アプリケーションの監視のサポート。
SLBはOMSの状態の監視と、障害の検知が可能である必要があるので、リクエストが使用できないOMSに転送されることはありません。
SLBの構成には次の2つの手順があります。
SLBを構成します。
管理サービスで必要な変更の追加
次の表を参考にしてCloud Control管理サービスでSLBを設定します。
表19-1 管理サービスのポート
| Cloud Controlサービス | TCPポート | モニター名 | TCPプロファイル名 | 永続性プロファイル | プール名 | 仮想サーバー名 | 仮想サーバー・ポート |
|---|---|---|---|---|---|---|---|
|
セキュア・コンソール |
7799 |
mon_ccsc |
tcp_ccsc |
sourceip_ccsc |
pool_ccsc |
vs_ccsc443 |
443 |
|
セキュアBI Publisher |
9851 |
mon_ccscbip |
tcp_ccscbip |
sourceip_ccscbip |
pool_ccscbip |
vs_ccscbip5443 |
5443 |
|
非保護コンソール |
7788 |
mon_ccuc |
tcp_ccuc |
sourceip_ccuc |
pool_ccuc |
vs_ccuc80 |
80 |
|
非保護BI Publisher |
9788 |
mon_ccucbip |
tcp_ccucbip |
sourceip_ccucbip |
pool_ccucbip |
vs_ccucbip8080 |
8080 |
|
セキュア・アップロード |
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 |
SLBにパッケージされている管理ツールを使用します。サンプル構成が付属しています。この例では、表33-1に示すデフォルトのポートを使用してホストAおよびホストBで2つの管理サービスが実行していると仮定します。
モニターの作成
モニターは、プール・メンバーの動作状況を検証する場合に使用されます。モニターは、ロード・バランシング・プールのメンバーであるノード上の接続やサービスを検証します。これは、規定の間隔でサービスのステータスを断続的に確認するように設計されます。確認するサービスが指定時間内に応答しない場合、ロード・バランサはプールから自動的にそのサービスを取り出し、プールの他のメンバーを選択します。ノードやサービスが再度使用可能になると、モニターはその状況を検出し、プールから自動的にアクセス可能なメンバーがトラフィックを処理できます。
表19-2 モニター
| Cloud Controlサービス | TCPポート | モニター名 | タイプ | 間隔 | タイムアウト | 送信文字列 | 受信文字列 |
|---|---|---|---|---|---|---|---|
|
セキュア・コンソール(SSOを使用していない場合) |
7799 |
mon_ccsc |
https |
5 |
16 |
GET /em/consoleStatus.jsp HTTP/1.1\r\nHost: \r\nConnection: Close \r\n\r\n |
Enterprise Manager Console is UP |
|
セキュア・コンソール(SSOを使用している場合) |
7799 |
mon_ccsc |
https |
5 |
15 |
GET /empbs/genwallet \r\n |
GenWallet Servlet activated |
|
セキュアBI Publisherコンソール |
9851 |
mon_ccscbip |
https |
5 |
16 |
GET /xmlpserver/services HTTP/1.1\r\nHost: \r\nConnection: Close \r\n\r\n |
And now... Some Services |
|
非保護コンソール(SSOを使用していない場合) |
7788 |
mon_ccuc |
http |
5 |
16 |
GET /em/consoleStatus.jsp HTTP/1.1\r\nHost: \r\nConnection: Close \r\n\r\n |
Enterprise Manager Console is UP |
|
非保護コンソール(SSOを使用している場合) |
7788 |
mon_ccuc |
http |
5 |
16 |
GET /empbs/genwallet \r\n |
GenWallet Servlet activated |
|
非保護BI Publisherコンソール |
9788 |
mon_ccucbip |
http |
5 |
16 |
GET /xmlpserver/services HTTP/1.1\r\nHost: \r\nConnection: Close \r\n\r\n |
And now... Some Services |
|
セキュア・アップロード |
4900 |
mon_ccsu |
https |
60 |
181 |
GET /empbs/upload \r\n |
Http Receiver Servlet active! |
|
エージェント登録 |
4889 |
mon_ccar |
http |
60 |
181 |
GET /empbs/genwallet \r\n |
GenWallet Servlet activated |
|
Always-On Monitoringセキュア・アップロード |
8081 |
mon_ccaom |
https |
60 |
181 |
GET /upload \r\n |
Always On Monitoring is active |
|
注意: 一部のロード・バランサでは、リテラル\r\nを使用して送信文字列に明示的に追加するには、<CR><LF>文字が必要です。これはベンダー固有です。詳細は、SLBのドキュメントを参照してください。 |
プールの作成
プールは、ロード・バランシング方法を使用して特定のTCPポートでトラフィックを受信するためにグループ化された一連のサーバーです。各プールには、永続性の定義の独自の特性と、使用されるロード・バランシング・アルゴリズムがあります。
表19-3 プール
| Cloud Controlサービス | プール名 | 関連付けられた状態モニター | ロード・バランシング | メンバー |
|---|---|---|---|---|
|
セキュア・コンソール |
pool_ccsc |
mon_ccsc |
最小接続(メンバー) |
OMSホストA:7799 OMSホストB:7799 |
|
セキュアBI Publisher |
pool_ccscbip |
mon_ccscbip |
最小接続(メンバー) |
OMSホストA:9851 OMSホストB:9851 |
|
非保護コンソール |
pool_ccuc |
mon_ccuc |
最小接続(メンバー) |
OMSホストA:7788 OMSホストB:7788 |
|
非保護BI Publisher |
pool_ccucbip |
mon_ccucbip |
最小接続(メンバー) |
OMSホストA:9788 OMSホストB:9788 |
|
セキュア・アップロード |
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 |
TCPプロファイルの作成:
次の表に従って、Cloud ControlサービスごとにTCPプロファイルを作成する必要があります。
永続性プロファイルの作成
特定のタイプのアプリケーションでは、同じクライアントが同じプール・メンバーに戻る必要があり、これを永続性または「固定性」と呼びます。これを、永続性プロファイルを使用して構成し、仮想サーバーに適用できます。ORACLE Cloud Controlサービスの場合、セキュア・アップロード・サービス以外の各サービスに対して永続性を構成する必要があります。
表19-5 永続性プロファイル
| Cloud Controlサービス | F5永続性プロファイル名 | タイプ | タイムアウト | 有効期限 |
|---|---|---|---|---|
|
セキュア・コンソール |
sourceip_ccsc |
ソース・アドレス・アフィニティ |
3600 |
該当なし |
|
セキュアBIPコンソール |
sourceip_ccscbip |
ソース・アドレス・アフィニティ |
3600 |
該当なし |
|
非保護コンソール |
sourceip_ccuc |
ソース・アドレス・アフィニティ |
3600 |
該当なし |
|
非保護BIPコンソール |
sourceip_ccucbip |
ソース・アドレス・アフィニティ |
3600 |
該当なし |
|
エージェント登録 |
cookie_ccar |
Cookie |
該当なし |
3600 |
仮想サーバーの作成
仮想サーバー(仮想IPアドレスとポート番号を含む)は、クライアントのアドレス可能なホスト名またはIPアドレスであり、これによって、クライアントはロード・バランシング・プールのメンバーを利用できます。仮想サーバーがリクエストを受信すると、選択したロード・バランシング方法に基づいてそのリクエストをプールのメンバーに誘導します。
表19-6 必須仮想サーバー
| Cloud Controlサービス | 仮想サーバー名 | 仮想IPおよびポート | プロトコル・プロファイル(クライアント) | HTTPプロファイル | ソース・アドレス変換 | iRule | デフォルト・プール | デフォルトの永続性プロファイル |
|---|---|---|---|---|---|---|---|---|
|
セキュア・コンソール |
vs_ccsc443 |
VIP:443 |
tcp_ccsc |
なし |
自動マップ |
なし |
pool_ccsc |
sourceip_ccsc |
|
セキュアBI Publisher |
vs_ccscbip5443 |
VIP:5443 |
tcp_ccscbip |
なし |
自動マップ |
なし |
pool_ccscbip |
Sourceip_ccscbip |
|
非保護コンソール* |
vs_ccuc80 |
VIP:80 |
tcp_ccuc |
http |
自動マップ |
なし |
pool_ccuc |
sourceip_ccuc |
|
非保護BI Publisher* |
vs_ccucbip8080 |
VIP:8080 |
tcp_ccucbip |
http |
自動マップ |
なし |
pool_ccucbip |
sourceip_ccucbip |
|
セキュア・アップロード |
vs_ccsu4900 |
VIP:4900 |
tcp_ccsu |
なし |
自動マップ |
なし |
pool_ccsu |
なし |
|
エージェント登録 |
vs_ccar4889 |
VIP:4889 |
tcp_ccar |
http |
自動マップ |
なし |
pool_ccar |
cookie_ccar |
|
Always-On Monitoringセキュア・アップロード |
vs_ccaom8081 |
VIP:8081 |
tcp_ccaom |
なし |
自動マップ |
なし |
pool_ccaom |
sourceip_aom |
* これらのエントリはEnterprise Managerへの非保護および非暗号化アクセスを提供するため、ベスト・プラクティスとは見なされず、推奨されません。
次の手順を実行してください。
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_http_port/slb_jvmd_https_port 7301 -console [-lock] [-lock_console]
出力例:
Oracle Enterprise Manager Cloud Control 13c Release 1 Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved. Securing OMS... Started. Securing OMS... Restart OMS
すべての管理エージェントを再保護します。
SLB設定の前にインストールされた管理エージェント(管理サービス・インストールに付属する管理エージェントなど)は、管理サービスに直接アップロードしています。これらの管理エージェントは、SLBの設定後にアップロードできません。これらの管理エージェントを再保護してSLBにアップロードするには、各管理エージェントで次のコマンドを実行します。
emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em
Always-On Monitoringの構成
OMSを保護した後、Always-On Monitoringを構成する必要があります(パートナーOMSからHTTPS設定を取得するため)。emscaユーティリティを使用してAlways-on Monitoringアプリケーションを構成する方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
特定の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 Cloud Control 13c Release 1 Copyright (c) 1996, 2015 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コンポーネントを再起動する必要はありません。
SLBを構成してサード・パーティ/カスタムSSL証明書を使用する場合、エージェント、SLBおよびOMSの間の信頼関係を維持するためにCA証明書が適切に構成されていることを確認する必要があります。具体的には、次の内容を実行する必要があります。
SLBのCA証明書をOMSトラスト・ストアにインポートします。
Enterprise Manager CA証明書をSLBのトラスト・ストアにコピーします。
Enterprise Managerは、カスタム証明書ではなくデフォルトのEnterprise Manager証明書を使用します。エージェントがSLBを介してOMSに情報を正常にアップロードするため、カスタムの信頼できる証明書をOMSおよびエージェントのトラスト・ストアにコピー/インポートする必要があります。次の手順は、SLBがサード・パーティ/カスタムSSL証明書で構成される場合に12c OMSおよびエージェントを保護するために使用されるプロセスを示しています。
SLBで使用されるSSL証明書の確認
次の手順を実行して、SLBがOMSと別の証明書を使用しているかどうかを確認します。
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
デフォルトのEnterprise Manager自己署名証明書がSLBで使用される場合、両方のコマンドの出力は次のように表示されます。
発行者 : CN=<OMS Hostname>, C=US, ST=CA, L=<OMS Hostname>のEnterpriseManager, OU=<OMS Hostname>のEnterpriseManager, O=<OMS Hostname>のEnterpriseManager
カスタムまたは自己署名SSL証明書がSLBで使用される場合、SLB名で実行されるコマンドの出力が次に示されている詳細を提供します。
発行者 : CN=Entrust Certification Authority - L1C, OU="(c) 2014 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) 2014 Entrust, Inc.")を使用しています。
OpenSSLがOSで使用できる場合、次のコマンドを実行してCNの値も確認できます。
$openssl s_client -connect <HOSTNAME>:<PORT>
OMSおよびエージェントのトラスト・ストアへのSLBのSSL証明書のインポート
base64形式のSLB証明書をcustomca.txtという名前のテキスト・ファイルにエクスポートします。
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証明書は |
すべてのOMSを再起動します。
cd <OMS_HOME>/bin
emctl stop oms -all
emctl start oms
このEnterprise Manager設定を指すすべてのエージェントを保護します。
cd <AGENT_HOME>/bin
./emctl secure agent –emdWalletSrcUrl <SLB Upload URL>
