21 Enterprise Managerの高可用性
この章では、各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高可用性ベスト・プラクティス』を参照してください。
管理リポジトリに対する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が実行できるようにすることで、アクティブ/パッシブ構成ではノードの損失に伴う停止時間が短縮します。高可用性を実現するアーキテクチャに関するオプションの詳細は、「高可用性ソリューション」を参照してください。
障害時リカバリを含む、さらに高度な可用性レベルに将来移行できるように、環境を最適に準備するために実行できるステップがいくつもあります。これらは、高可用性を得るために選択した方法や、インストール時に最初に選択した可用性レベルには関係ありません。これらのステップの詳細は、「別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つように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 OMSをインストールする、Cloud Control管理者のためのベスト・プラクティスを説明します。将来、障害時リカバリが必要になった場合、これらのベスト・プラクティスによって実装に必要なステップが少なくなります。これらのベスト・プラクティスは、すべてのMAA高可用性レベルのインストールに対応します。最高のMAA高可用性レベルのニーズを考慮してスタンドアロンOMSをインストールすると、最大限の柔軟性が得られ、将来的にさらに上のMAA高可用性レベルに簡単に移行することができます。
概要および要件
Cloud Control 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インストール・ベース・ディレクトリ内に配置したインベントリを設定するようにインストーラを準備します。
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 Cloud Control基本インストレーション・ガイド』のEnterprise Managerシステムをインストールするための前提条件に関する項を参照してください。
ソフトウェアをインストールする場合は次のステップを参照してください。
-
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を指定することもできます。
-
-
引き続きインストールの残りの手順を実行します。
仮想ホスト名を使用したHAフェイルオーバーのアクティブ/パッシブ環境でのCloud Control OMSの構成
この項では、コールド・フェイルオーバー・クラスタ(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アドレスの設定
仮想ホスト名と仮想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コマンドを使用して検証できます。
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
サービスの開始
サービスは必ず正しい順序で起動してください。次の順序で行います。
- アクティブなノードで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のインストールに関する章を参照してください。
サーバー・ロード・バランサ(SLB)の内側への複数の管理サービスの構成
次の各項では、サーバー・ロード・バランサを使用してアクティブ/アクティブ構成で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の構成
- 管理サービスで必要な変更の追加
SLB側の設定
次の表を参考にしてCloud Control管理サービスでSLBを設定します。
表21-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 |
セキュアな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 |
注意:
Always-On MonitoringサービスがHA構成内のOMSホスト以外のホストにインストールされる場合は、OMSホストのかわりに、Always-On Monitoringサービスをインストールするホストを指定する必要があります。-
モニターの作成
モニターは、プール・メンバーの動作状況を検証する場合に使用されます。モニターは、ロード・バランシング・プールのメンバーであるノード上の接続やサービスを検証します。これは、規定の間隔でサービスのステータスを断続的に確認するように設計されます。確認するサービスが指定時間内に応答しない場合、ロード・バランサはプールから自動的にそのサービスを取り出し、プールの他のメンバーを選択します。ノードやサービスが再度使用可能になると、モニターはその状況を検出し、プールから自動的にアクセス可能なメンバーがトラフィックを処理できます。
表21-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
セキュア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
非保護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
セキュアなJVMD
7301
mon_ccsjvmd
HTTPS
60
181
GET /jamservlet/comm\r\n
Reply to empty request
非保護JVMD
7202
mon_ccujvmd
HTTPS
60
181
GET /jamservlet/comm\r\n
Reply to empty request
注意:
一部のロード・バランサでは、リテラル\r\nを使用して送信文字列に明示的に追加するには、<CR><LF>文字が必要です。これはベンダー固有です。詳細は、SLBのドキュメントを参照してください。
-
プールの作成
プールは、ロード・バランシング方法を使用して特定のTCPポートでトラフィックを受信するためにグループ化された一連のサーバーです。各プールには、永続性の定義の独自の特性と、使用されるロード・バランシング・アルゴリズムがあります。
表21-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
セキュアなJVMD pool_ccsjvmd mon_ccsjvmd 最小接続(メンバー) OMSホストA:7301
OMSホストB:7301
非保護JVMD
pool_ccujvmd
mon_ccujvmd
最小接続(メンバー) OMSホストA:7202
OMSホストB:7202
-
TCPプロファイルの作成:
次の表に従って、Cloud ControlサービスごとにTCPプロファイルを作成する必要があります。
表21-4 TCPプロファイル
Cloud Controlサービス TCPプロファイル名 セキュア・コンソール
tcp_ccsc
セキュアなBIPコンソール
tcp_ccscbip
非保護コンソール
tcp_ccuc
非保護BIPコンソール
tcp_ccucbip
セキュア・アップロード
tcp_ccsu
エージェント登録
tcp_ccar
Always-On Monitoringセキュア・アップロード
tcp_ccaom
セキュアなJVMD tcp_ccsjvmd 非保護JVMD tcp_ccujvmd -
永続性プロファイルの作成
特定のタイプのアプリケーションでは、同じクライアントが同じプール・メンバーに戻る必要があり、これを永続性または「固定性」と呼びます。これを、永続性プロファイルを使用して構成し、仮想サーバーに適用できます。ORACLE Cloud Controlサービスの場合、セキュア・アップロード・サービス以外の各サービスに対して永続性を構成する必要があります。
表21-5 永続性プロファイル
Cloud Controlサービス F5永続性プロファイル名 タイプ タイムアウト 有効期限 セキュア・コンソール
sourceip_ccsc
ソース・アドレス・アフィニティ
3600
該当なし
セキュアなBIP Publisher
sourceip_ccscbip
ソース・アドレス・アフィニティ
3600
該当なし
非保護コンソール
sourceip_ccuc
ソース・アドレス・アフィニティ
3600
該当なし
非保護BIP Publisher
sourceip_ccucbip
ソース・アドレス・アフィニティ
3600
該当なし
エージェント登録
cookie_ccar
Cookie
該当なし
3600
セキュアなJVMD
sourceip_ccsjvmd
ソース・アドレス・アフィニティ
3600
該当なし
非保護JVMD
sourceip_ccujvmd
ソース・アドレス・アフィニティ
3600
該当なし
-
仮想サーバーの作成
仮想サーバー(仮想IPアドレスとポート番号を含む)は、クライアントのアドレス可能なホスト名またはIPアドレスであり、これによって、クライアントはロード・バランシング・プールのメンバーを利用できます。仮想サーバーがリクエストを受信すると、選択したロード・バランシング方法に基づいてそのリクエストをプールのメンバーに誘導します。
表21-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
自動マップ
ccuc_httptohttps
pool_ccuc
sourceip_ccuc
非保護BI Publisher*
vs_ccucbip8080
VIP:8080
tcp_ccucbip
http
自動マップ
ccuc_httptohttps
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
セキュアなJVMD
vs_ccsjvmd7301
VIP:7301
tcp_ccsjvmd
なし
自動マップ
なし
pool_ccsjvmd
sourceip_ccsjvmd
非保護JVMD
vs_ccujvmd7202
VIP:7202
tcp_ccujvmd
http
自動マップ
なし
pool_ccujvmd
sourceip_ccujvmd
* これらのエントリはEnterprise Managerへの非保護および非暗号化アクセスを提供するため、ベスト・プラクティスとは見なされず、推奨されません。
Enterprise ManagerおよびSLB (リリース12.1.0.2以降)のSSLの構成
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証明書のインポート
SLBに対して複数のOMSの高可用性を構成する方法の詳細は、Enterprise Manager 13c Cloud Control: F5 BIG-IPローカル・トラフィック・マネージャを使用したOMSの高可用性の構成
テクニカル・ホワイトペーパーを参照してください。