| Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド 12cリリース4 (12.1.0.4) B65085-14 |
|
 前 |
 次 |
| Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド 12cリリース4 (12.1.0.4) B65085-14 |
|
前 |
次 |
この章では、各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が実行できるようにすることで、アクティブ/パッシブ構成ではノードの損失に伴う停止時間が短縮します。高可用性を実現するアーキテクチャに関するオプションの詳細は、第16章「高可用性ソリューション」を参照してください。
障害時リカバリを含む、さらに高度な可用性レベルに将来移行できるように、環境を最適に準備するために実行できる手順がいくつもあります。これらは、高可用性を得るために選択した方法や、インストール時に最初に選択した可用性レベルには関係ありません。これらの手順の詳細は、「別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSを構成するためのベスト・プラクティス」を参照してください。
OMSの高可用性を保証するには、Enterprise Managerによって管理される環境のサイズと範囲およびEnterprise Managerの使用方法の規模と複雑さ(管理者の数や利用される機能の種類など)に対応できるように十分な数のOMSも必要です。可用性を構成および監視する方法や、運用状況に基づいて必要なOMS数を決定する方法の詳細は、My Oracle Supportノート1940179.1の『EM運用の考慮事項およびトラブルシューティングに関するホワイトペーパー・マスター索引』を参照してください。
環境の十分なキャパシティを保証するため、またはパッシブ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インストールで使用されているのと同じホスト名で稼働できることが必要です。これは、別名ホスト名を使用して実現できます。
第18章「ホスト名の計画」のガイダンスを使用して、インストールで使用する別名ホスト名を構成します。オプション2: この項に示された両方のサイトの別名ホスト名は、最大の柔軟性を実現できるため、新しくインストールする際のベスト・プラクティスとして推奨されます。
オプション2を実施するには、OMSをインストールするときに、ORACLE_HOSTNAME=<ALIAS_HOST_NAME>パラメータを指定するか、OUIインストールの「ホスト名」フィールドに別名ホスト名を指定します。たとえば、runInstallerコマンドラインに次のパラメータを含めます。
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>パラメータを次のようにrunInstallerコマンドラインに指定して、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基本インストレーション・ガイド』のEnterprise Managerシステムのインストールに関する項を参照して、詳しい準備とインストールの手順に従います。インストール・プロセスでは次の情報を指定します。
ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースがOMSインストール・ベース・ディレクトリ内に配置されるように確認します。
インベントリの場所のファイルとOMSの別名ホスト名を指定します。これらは、コマンドラインに次の例のように指定できます。
$ runInstaller -invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=oms1.example.com
Enterprise ManagerのrunInstaller 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ディレクティブを変更する必要があります。変更しない場合、ロック問題が発生する可能性があります。
一部のバージョンのオペレーティング・システムでは、12cをインストールする前に特定のオペレーティング・システム・パッチを適用する必要があります。ユーザーが12cソフトウェアをインストールして使用するには、十分なカーネル・リソースも使用できるようにしておく必要があります。詳細は、オペレーティング・システムのインストール・ガイドを参照してください。インストーラを起動する前に、特定の環境変数を検証する必要があります。各変数は、クラスタに参加するすべてのマシンにソフトウェアをインストールしているアカウントに対して同一に設定する必要があります。
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の下)を指し示し、仮想グループのホスト名を指定します。次に例を示します。
$ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.example.com -debug
Enterprise ManagerのrunInstaller 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のホームページで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。
「プロビジョニング」サブタブをクリックします。
「プロビジョニング」ページで「管理」サブタブをクリックします。
「ソフトウェア・ライブラリ構成」セクションで「追加」をクリックして、「ソフトウェア・ライブラリのディレクトリの場所」を、管理サービス・ホストからアクセス可能な共有記憶域に設定します。
この項では、使用可能な管理サービスにエージェントとブラウザのトラフィックを分散するサーバー・ロード・バランサ(SLB)を設定するためのガイドラインについて説明します。
サーバー・ロード・バランサの要件
SLBの背後にアクティブ/アクティブ構成でOMSを構成するために、SLBは次の要件を満たす必要があります。
SLBは複数の仮想サーバー・ポートをサポートする必要があります。
構成によっては、SLBで最大5ポートが必要になる場合があります(セキュア・アップロード、エージェント登録、セキュア・コンソール、非保護コンソール、BI Publisher)。
永続性のサポート。
ブラウザとOMS間のHTTPおよびHTTPSトラフィックには永続性が必要です。
アプリケーションの監視のサポート。
SLBはOMSの状態の監視と、障害の検知が可能である必要があるので、リクエストが使用できないOMSに転送されることはありません。
SLBの構成には次の2つの手順があります。
SLBを構成します。
管理サービスで必要な変更の追加
次の表を参考にしてCloud Control管理サービスでSLBを設定します。
表17-1 管理サービスのポート
| Cloud Controlサービス | TCPポート | モニター名 | 永続性 | プール名 | ロード・バランシング | 仮想サーバー名 | 仮想サーバー・ポート |
|---|---|---|---|---|---|---|---|
|
セキュア・アップロード |
1159 |
mon_gcsu4900 |
なし |
pool_gcsu4900 |
ラウンド・ロビン |
vs_gcsu4900 |
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にパッケージされている管理ツールを使用します。サンプル構成が付属しています。この例では、表33-1に示すデフォルトのポートを使用してホストAおよびホストBで2つの管理サービスが実行していると仮定します。
プールの作成
プールは、ロード・バランシング方法を使用して特定のTCPポートでトラフィックを受信するためにグループ化された一連のサーバーです。各プールには、永続性の定義の独自の特性と、使用されるロード・バランシング・アルゴリズムがあります。
表17-2 プール
| プール名 | 使用方法 | メンバー | 永続性 | ロード・バランシング |
|---|---|---|---|---|
|
pool_gcsu4900 |
セキュア・アップロード |
ホストA: 4900 ホストB: 4900 |
なし |
ラウンド・ロビン |
|
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アドレスであり、これによって、クライアントはロード・バランシング・プールのメンバーを利用できます。仮想サーバーがリクエストを受信すると、選択したロード・バランシング方法に基づいてそのリクエストをプールのメンバーに誘導します。
モニターの作成
モニターは、プール・メンバーの動作状況を検証する場合に使用されます。モニターは、ロード・バランシング・プールのメンバーであるノード上の接続やサービスを検証します。これは、規定の間隔でサービスのステータスを断続的に確認するように設計されます。確認するサービスが指定時間内に応答しない場合、ロード・バランサはプールから自動的にそのサービスを取り出し、プールの他のメンバーを選択します。ノードやサービスが再度使用可能になると、モニターはその状況を検出し、プールから自動的にアクセス可能なメンバーがトラフィックを処理できます。
表17-4 モニター
| モニター名 | 構成 | 関連ホスト |
|---|---|---|
|
mon_gcsu4900 |
タイプ: https 間隔: 60 タイムアウト: 181 送信文字列: GET /empbs/upload 受信文字列: Http Receiver Servlet active! |
ホストA: 4900 ホストB: 4900 |
|
mon_gcar4889 |
タイプ: http 間隔: 60 タイムアウト: 181 送信文字列: GET /empbs/genwallet 受信文字列: GenWallet Servlet activated |
ホストA: 4889 ホストB: 4889 |
|
mon_gcsc7799 |
タイプ: https 間隔: 5 タイムアウト: 16 送信文字列: GET /em/consoleStatus.jsp 受信文字列: Enterprise Manager Console is UP |
ホストA: 7799 ホストB: 7799 |
|
mon_gcuc7788(オプション) |
タイプ: http 間隔: 5 タイムアウト: 16 送信文字列: GET /em/consoleStatus.jsp 受信文字列: Enterprise Manager Console is UP |
ホストA: 7788 ホストB: 7788 |
|
mon_gcscbip7799 |
タイプ: https 間隔: 5 タイムアウト: 16 送信文字列: GET /xmlpserver/services 受信文字列: getDocumentData |
ホストA: 7799 ホストB: 7799 |
|
mon_gcucbip7788 |
タイプ: https 間隔: 5 タイムアウト: 16 送信文字列: GET /xmlpserver/services 受信文字列: getDocumentData |
ホストA: 7799 ホストB: 7799 |
|
注意: 一部のロード・バランサでは、リテラル\r\nを使用して送信文字列に明示的に追加するには、<CR><LF>文字が必要です。これはベンダー固有です。詳細は、SLBのドキュメントを参照してください。 |
次の手順を実行してください。
Oracle Management Serviceの再保護
デフォルトでは、管理サービス側証明書のサービス名は、管理サービス・ホストの名前を使用します。管理エージェントは、ロード・バランサ経由でOracle Management Serviceと通信する場合、この証明書を受け入れません。次のコマンドを実行して、各管理サービスで証明書を再生成する必要があります。
emctl secure oms -host slb.example.com -secure_port 4900 -slb_port 4900 -slb_console_port 443 -console [-lock] [-lock_console]
出力例:
Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Securing OMS... Started. Enter Enterprise Manager Root (SYSMAN) Password : Enter Agent Registration Password : Securing OMS... Successful Restart OMS
すべての管理エージェントを再保護します。
SLB設定の前にインストールされた管理エージェント(管理サービス・インストールに付属する管理エージェントなど)は、管理サービスに直接アップロードしています。これらの管理エージェントは、SLBの設定後にアップロードできません。これらの管理エージェントを再保護してSLBにアップロードするには、各管理エージェントで次のコマンドを実行します。
emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em
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>
