Enterprise ManagerのアップグレードとDR準備状況への移行

5 Enterprise ManagerのアップグレードとDR準備状況への移行

この章では、記憶域レプリケーションDRアーキテクチャを使用して、スタンバイOMSを実装するためのベスト・プラクティスでEnterprise Manager環境をアップグレードする方法を説明します。

この章の具体的な内容は次のとおりです。

Enterprise ManagerのアップグレードとDR準備状況への移行の概要

Enterprise Manager Cloud Control 12.1.0.3には、MAA障害時リカバリ(DR)アーキテクチャへの大幅な変更が含まれています。Enterprise Manager Cloud Control 12.1.0.3からは、推奨されるMAA DRアーキテクチャである、記憶域レプリケーションを使用したスタンバイOMSは、単一のWebLogicドメイン、レプリケートされた記憶域および別名ホスト名を使用します。スタンバイWebLogicドメインDRアーキテクチャを使用する以前のスタンバイOMSは、Enterprise Manager Cloud Control 12.1.0.3では非推奨になり、Enterprise Manager Cloud Control 13.1ではサポートされなくなりました。記憶域レプリケーションDRアーキテクチャを使用したスタンバイOMSのベスト・プラクティスの実装には、次のものが含まれます。

アプリケーションの仮想ホスト名に対して保護されたOMSおよびエージェント
別名ホスト名を使用して構成された各OMSおよび中央エージェント
レプリケートされた記憶域にインストールされ、サイト間でレプリケートされた各OMSおよび中央エージェント
レプリケートされた記憶域のインベントリにアタッチされ、サイト間でレプリケートされた各OMSおよび中央エージェントのインストール
各サイトのOMSサーバー間で共有され、サイト間でレプリケートされたソフトウェア・ライブラリおよびBI Publisher記憶域
現在どのサイトがアクティブ・サイトであるかにかかわらずホストをモニタリングするために、各サイトの各物理ホストにインストールされたエージェント

ベスト・プラクティスで構成された記憶域レプリケーションDRアーキテクチャを使用したスタンバイOMSをすでに実装している環境では、標準のアップグレード手順を使用でき、この章で説明する追加ステップは必要ありません。記憶域レプリケーションDRアーキテクチャを使用したスタンバイOMSに対してベスト・プラクティスをまだ実装していない環境では、Enterprise Manager Cloud Control 13cで障害時リカバリをサポートするためには移行が必要になります。

新しいアーキテクチャへの移行のプロセスを支援するため、「DR準備状況へのアップグレードおよび移行」というインストーラの新しいモードが作成されました。この新しいモードはUPGRADE_TRANSITIONというパラメータを渡すことによって有効になり、標準のGUIインストールで最初のOMSでの使用に対してのみサポートされ、従う必要のある準備およびアップグレード後のステップの特定のフローが必要になります。ConfigureGC.shに従ってのみインストールするソフトウェアでは、「DR準備状況へのアップグレードおよび移行」のサポートは提供されません。また、「DR準備状況へのアップグレードおよび移行」を使用した追加のOMSのアップグレードはサポートされていません。複数OMS環境では、追加のOMSは最初にアンインストールされ、移行に関連付けられた最初のOMSおよび関連するアップグレード後プロセスが完了している必要があります。そうなっている場合には、追加のOMSをデプロイできます。

「アップグレードおよびDR準備状況への移行」のインストールでは、プライマリOMSおよびリポジトリをEnterprise Manager Cloud Control 13.2.0.0またはEnterprise Manager Cloud Control 13.3.0.0からEnterprise Manager Cloud Control 13.4.0.0にアップグレードすることに加え、次のステップを実行できます。

レプリケートされた記憶域上のプライマリOMSに対してEnterprise Manager 13cソフトウェアをインストール
アップグレードされたEnterprise Manager 13cのプライマリOMSを別名ホスト名を使用するように構成
アップグレードされたEnterprise Manager 13cインストールをレプリケートされた記憶域の指定されたインベントリにアタッチ

「DR準備状況へのアップグレードおよび移行」プロセスは、インストーラ自体のコンテキスト外の相当の準備と追加ステップが必要です。アップグレードおよび移行のプロセスの一環として必要とされる変更の度合は、記憶域レプリケーションDRアーキテクチャを使用するスタンバイOMSのベスト・プラクティスに既存のインストールが従う度合によって異なります。変更の度合いが最大になるのは、別名ホスト名の実装と、OMSおよびOMSエージェント(中央エージェント)の、ローカル記憶域上のインストールおよびインベントリから、レプリケートされた記憶域上のインストールおよびインベントリへの再配置です。構成変更のサブセットのみを必要とする環境に対応するため、このプロセスの変化形を実行できます。次の表に、各シナリオに該当するプロセスの概要を示します。

追加のOMSのデプロイに成功した後、WebLogicデモ証明書が再生成され、すべてのOMSサーバー上の別名ホスト名に反映され、OMS1上のEnterprise Manager 13c OMSからのバイナリがアンインストールされ、物理ホスト名エージェントがすべてのプライマリおよびスタンバイOMSサーバーにデプロイされます。

表5-1 アップグレード・モードでサポートされている移行

古いインストール	アップグレードされたインストール	古いインベントリ	アップグレードされたインベントリ	古いホスト名	アップグレードされたホスト名	アップグレード・モード
ローカルまたはレプリケート	レプリケート	ローカル	レプリケート	フィジカル	エイリアス	DR準備状況へのアップグレードおよび移行
ローカルまたはレプリケート	レプリケート	ローカル	レプリケート	エイリアス	同じ	DR準備状況へのアップグレードおよび移行
ローカルまたはレプリケート	レプリケート	レプリケート	同じ	フィジカル	エイリアス	DR準備状況へのアップグレードおよび移行
ローカルまたはレプリケート	レプリケート	レプリケート	同じ	エイリアス	同じ	アップグレード

Enterprise Manager 13cリリース2または13cリリース3から13cリリース4へのアップグレードとDR準備状況への移行

この章の内容は次のとおりです。

Enterprise Manager 13cの13cリリース4へのアップグレードとDR準備状況への移行のプロセス

アップグレードおよび移行のプロセスは、準備状況を確認するための環境全体にわたる準備アクティビティから開始します。環境の準備が整えられると、すべてのOMSサーバーの一貫したバックアップのセットがサイトおよびリポジトリ・データベースの両方に作成されます。バックアップが完了すると、スタンバイOMSおよびOMSエージェントのアンインストールが開始します。スタンバイOMSが削除され、スタンバイOMSエージェントがアンインストールされ、スタンバイOMSバイナリがアンインストールされます。

スタンバイ・サイトのアンインストールが完了すると、両方のサイトでサーバーの綿密な準備が開始します。OMSインストール・ベース・ディレクトリが特定され、プライマリおよびスタンバイOMSサーバーがレプリケートされた記憶域構成および別名ホスト名用に準備され、Oracleインベントリ・ロケーション・ポインタ・ファイルがプライマリOMS1上のレプリケートされた記憶域のOracleインベントリ・ディレクトリに作成され、Enterprise Manager 13cインストール・ソフトウェアがプライマリOMS1サーバー上にステージングされ、ローカル・ロック・ファイル・ディレクトリがすべてのプライマリおよびスタンバイOMSサーバー上に作成されます。

両サイトでの準備が完了すると、プライマリ・サイトの追加OMSおよび追加OMSエージェントが削除されてアンインストールされ、OMS1のアップグレードおよび移行が開始します。プライマリOMS1およびOMS1エージェントが停止され、インストーラが起動し、OMS1およびリポジトリのアップグレードおよび移行が開始します。OMS1のアップグレードと移行が完了すると、OMS1は停止され、ローカル・ロック・ファイル用に構成され、再起動されます。

この時点で、OMS1エージェントのアップグレードおよび移行が開始します。OMS1エージェントがEnterprise Manager 13.4にアップグレードされ、OMS1エージェントに対してエージェントのアップグレード後のクリーンアップが実行され、OMS1エージェントがローカル記憶域およびインベントリからレプリケートされた記憶域およびインベントリに再配置され、別名ホスト名を使用するためにOMS1エージェントを準備およびリカバリするステップが実行され、OMS1関連のターゲットがリカバリされた別名ホスト名エージェントに再配置されます。

エージェントとターゲットの再配置が完了すると、更新されたEnterprise Manager 13c SLB構成を使用するためにOMS1が再保護され、OMSとBI Publisherとの間の内部チャネルが構成され、遅延DDMPジョブが発行されます。DDMPジョブが完了すると、OMS1のアップグレードおよび移行が完了し、追加OMSのデプロイが開始します。別名ホスト名エージェントが、レプリケートされた記憶域上のインベントリとともに、レプリケートされた記憶域上の各追加OMSサーバーにデプロイされます。追加OMSが「Oracle Management Serviceの追加」デプロイメント・プロシージャを使用してデプロイされます。

これで両サイトでのアップグレードおよび移行プロセスが完了します。

ノート:

関連する停止時間に対応できる開発環境およびテスト環境では、アップグレードおよび移行が成功したことを確認するため、新しいスタンバイOMSへの、および新しいスタンバイOMSからのスイッチオーバーを実行でき、さらに追加のパッチ適用および他のメンテナンス・テストも実行できます。

アップグレードおよび移行が完了し、成功したことがわかったら、必要に応じてアップグレードおよび移行の中間ファイルをバックアップして削除できます。

Enterprise Managerの13cリリース4へのアップグレードとDR準備状況への移行

スタンバイWebLogicドメイン障害時リカバリ(DR)アーキテクチャを使用してスタンバイOMSで構成されたEnterprise Manager 13cリリース2 (13.2.0.0)または13cリリース 3 (13.3.0.0)環境から、Enterprise Manager 13cリリース4 (13.4.0.0)にアップグレードし、記憶域レプリケーションDRアーキテクチャを使用してスタンバイOMSに移行するには、次のステップに従います。

ステップ1: DR準備状況へのアップグレードおよび移行の準備
ステップ2: スタンバイOMSおよびOMSエージェントの削除
ステップ3: DR準備状況へのアップグレードおよび移行のためのプライマリおよびスタンバイOMSの準備
ステップ4: プライマリの追加OMSおよび追加OMSエージェントの削除
ステップ5: OMS1およびリポジトリのアップグレードと移行
ステップ6: OMS1エージェントのDR準備状況への移行
ステップ7: プライマリ・サイト構成の更新
ステップ8: 新しいプライマリの追加OMS別名ホスト名エージェントと追加OMSの追加
ステップ9: プライマリおよびスタンバイ・サイト構成のファイナライズ

DR準備状況へのアップグレードおよび移行の準備

この項では、アップグレードおよび移行を確実に成功させるために必要な準備ステップについて説明します。一般的なアプローチとして、このアップグレードおよび移行の準備は、アップグレードまたは他の負荷の大きいメンテナンス・アクティビティに対して実行する準備と同様であると考えます。それらのメンテナンス・アクティビティと同様に、アップグレードおよび移行のアクティビティを開始する前に環境が正常であることを確認することが重要です。

アップグレードおよび移行のプロセス全体を理解し、さらにこの項で使用される規則も理解することが重要です。この手順では次の2ユーザーが参照されます。

root
Oracleソフトウェア所有者ユーザー

コマンドを使用する際に特定のユーザーについての言及がない場合、コマンドはOracleソフトウェア所有者ユーザーとして実行する必要があります。rootとして実行する必要のあるコマンドは明示的に示されます。環境に直接rootとしてログインできない場合、sudoまたは他の手段を使用してコマンドをrootとして実行できます。環境で他の手段を使用してコマンドをrootとして実行する場合、それらがroot権限で実行されるように必ずコマンドに適切な変更を加え、これらのコマンドを開発環境でテストするか、環境をテストして、正しい構造になっていることを確認します。

変数は、コマンド内では<VARIABLE>のように山カッコを使用して示されます。環境は多種多様になる可能性があるため、直接の変数置換はご使用の環境では機能しない場合があります。その場合、ご使用の環境と、この項の例に反映されたサンプルの環境との違いを特定し、ご使用の環境にその違いを反映するような変数置換を採用する必要があります。

これらの手順では、OMSを含むEnterprise Managerサーバーは、個々にOMSサーバーまたはOMSn (OMS1など)として、また集合的にOMSまたはOMSサーバーとして参照されます。そのため、OMSサーバーという参照には、BI Publisherが構成される場合のBI Publisherなど、OMS以外のコンポーネントが含まれることがよくあります。コマンドemctl start omsでOMSを起動する、という参照はOMS、BI Publisher (構成される場合)、WebLogicノード・マネージャおよびWebLogic管理サーバー(OMS1上の場合)を含む特定のOMSサーバー上にインストールおよび構成された完全な製品スタックを起動するということになります。

Enterprise Manager 13cの13cリリース4へのアップグレードとDR準備状況への移行を進める前に、必ず次のことを確認してください。

ステップ1: Enterprise Manager Cloud Control 13cリリース4のアップグレードおよびDR準備状況への移行の前提条件
ステップ2: アプリケーションの仮想ホスト名に対するEnterprise Managerインストールの保護
ステップ3: レプリケートされた記憶域がプロビジョニングされ、プライマリ・サイトで現在アクティブであるようにする
ステップ4: アップグレードおよび移行がプライマリ・サイトで行われるようにする
ステップ5: OMSインストール・ベース・ディレクトリの特定
ステップ6: デモ証明書のかわりにカスタムのWLS証明書を使用する場合に必要な追加ステップ
ステップ7: アップグレードされたEnterprise Manager 13c環境に対するSLB構成の更新
ステップ8: バックアップの作成

Enterprise Manager Cloud Control 13cリリース4のアップグレードおよびDR準備状況への移行の前提条件

DR準備状況へのアップグレードおよび移行を実行するための前提条件は、標準のアップグレードを実行するための前提条件のスーパーセットです。Enterprise Manager Cloud Control 13cリリース4へのアップグレードの前提条件で指定された前提条件を確認、理解し、環境がそれを満たすようにします。この章で特に言及されていない前提条件が、インストーラを使用した実際のDR準備状況へのアップグレードおよび移行の開始前までに、適時アップグレードおよび移行プロセスで実行されるようにします。この章の手順では、OMSおよびOMSエージェントを停止するタイミングについて説明します。

アプリケーションの仮想ホスト名に対するEnterprise Managerインストールの保護

障害時リカバリ構成では、OMSおよびエージェントをアプリケーションの仮想ホスト名に対して保護することが必要です。これは、DNSを使用して手動で、またはグローバル・ロード・バランサを使用して自動化された方法で実装できます。アップグレードおよび移行を実行する前に、OMSおよびエージェントがアプリケーションの仮想ホスト名に対して保護されていることを確認します。アプリケーションの仮想ホスト名の詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「アプリケーションの仮想ホスト名の考慮事項」を参照してください。

レプリケートされた記憶域がプロビジョニングされ、プライマリ・サイトで現在アクティブであるようにする

この章では、別名ホスト名を使用したOMSおよびOMSエージェント・ソフトウェアのインストール、構成および実行に使用される記憶域を説明するために、レプリケートされた記憶域および記憶域レプリケーションという用語を使用します。プライマリ・サイトの特定のOMS用の記憶域は、スタンバイ・サイトの対応する記憶域にレプリケートされます。どのサイトがアクティブであっても同じインストール・ソフトウェアおよび構成にアクセスできるように、変更は、スイッチオーバーが発生する前に、定義されたスケジュールで必要に応じて最小限にレプリケートされます。選択されるテクノロジによっては、レプリケーションの方向を変更し、他方のサイトの記憶域をアクセス用に準備するために、記憶域管理者によって手動のステップが行われる必要のある場合があります。各OMS (OMS1、OMS2など)には、プライマリ・サイトおよびスタンバイ・サイトにサーバーが1台あり、各OMSに対して1台のみのサーバーが任意の一定時間にアクティブになります。アクティブのサイトのサーバーは、レプリケートされた記憶域を使用してOMSをホストします。

OMSおよびOMSエージェント・ソフトウェアの記憶域レプリケーションに加え、ソフトウェア・ライブラリおよびBI Publisherの共有記憶域のレプリケーションをサポートするために、このアップグレードおよび移行のプロセスを実行する前にプロビジョニングされる必要のある他の2つの記憶域レプリケーションのセットがあります。ソフトウェア・ライブラリは、すでにサイトでOMS間で共有され、既存の2ドメイン・インストールの一環としてプライマリ・サイトとスタンバイ・サイト間でレプリケートされているはずであるため、ソフトウェア・ライブラリの記憶域レプリケーションはすでに対応されているはずです。そのため、このアップグレードおよび移行プロセスの始めにソフトウェア・ライブラリがバックアップされますが、このアップグレードおよび移行にはソフトウェア・ライブラリのレプリケーションの準備に対応するステップは含められていません。現在の2ドメイン・インストールをサポートするために、ソフトウェア・ライブラリが、すべてのOMS上の同じパスを使用してプライマリ・サイトおよびスタンバイ・サイトの両方のすべてのOMS上で現在使用可能であり、移行された環境においてどのサイトがアクティブであっても使用可能であり続けるように、ソフトウェア・ライブラリのレプリケーションが適切に構成されていることを確認します。

BI Publisherの共有記憶域は、同じパス、同じマウント・ポイント・オプションなどを使用して、スイッチオーバーまたはフェイルオーバー時にスタンバイ・サイトOMSの各々にマウントできるように、スタンバイ・サイトにレプリケートされる必要があります。スタンバイ・サイトにあるBI Publisherの共有記憶域は、プライマリ・サイトで使用されるテクノロジと同じテクノロジ(ソフトウェア・バージョンおよび構成オプションを含む)を使用する必要があります。この章では、BI Publisherの共有記憶域の記憶域レプリケーションの設定または構成について特別な説明はしていません。このアップグレードと移行のプロセスを開始する前に、プライマリ・サイトおよびスタンバイ・サイトのOMSサーバーの各々が、それぞれのサイトにあるレプリケートされたBI Publisherの共有記憶域をマウントできるように構成されていることを確認します。BI Publisherがプライマリ・サイトですでに構成されている場合、この構成はアップグレードおよび移行において継承されるため、レプリケートされたBI Publisherの共有記憶域を使用するように構成されていることを確認します。BI Publisherがプライマリ・サイトでまだ構成されていない場合、レプリケートされたBI Publisherの共有記憶域上のBI Publisherの構成ボリュームおよびクラスタ・ボリュームのディレクトリをインストーラに指定する必要があります。これらBI Publisherの構成ボリュームおよびクラスタ・ボリュームのディレクトリは、レプリケートされたBI Publisherの共有記憶域のプライマリ・サイト上に作成される必要があります。この章のステップでは、レプリケートされたBI Publisherの共有記憶域の構成ボリュームおよびクラスタ・ボリュームのディレクトリがインストーラの適切な画面で指定されるようにします。

記憶域レプリケーションの要件の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の記憶域の考慮事項に関する項を参照してください。

BI Publisherの共有記憶域を含めたBI Publisherの高可用性の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のBI Publisherの高可用性に関する項を参照してください。

レプリケートされた記憶域がリクエストされたようにプロビジョニングされており、レプリケーションが現在プライマリ・サイトがアクティブであるように構成されていることを確認します。これは、記憶域レプリケーションがアップグレードおよび移行をサポートする準備ができていることを保証することによって、アップグレードおよび移行のメンテナンス・ウィンドウ中の遅延を防ぎます。

アップグレードおよび移行がプライマリ・サイトで行われるようにする

アップグレードおよび移行のプロセスでは、プライマリWebLogicドメインをアップグレードおよび移行して、両サイトで使用される新しい1つのWebLogicドメインにします。

次のことを確認します。

アップグレードおよび移行のプロセスはプライマリ・サイトで開始される。
スタンバイWebLogicドメインをアップグレードおよび移行のソースドメインとして使用しない。

OMSインストール・ベース・ディレクトリの特定

レプリケートされた記憶域上のミドルウェア・ホーム、インスタンス・ベース、エージェント・ベースおよびOracleインベントリの場所の親ディレクトリである、OMSインストール・ベース・ディレクトリとして使用するディレクトリを特定します。OMSインストール・ベース・ディレクトリは、レプリケートされた記憶域のマウント・ポイントとして機能できます。この章で説明するOMSインストール・ベース・ディレクトリの構成例は/u01/app/oracle/OMSで、変数<OMS_MOUNT_POINT>として示されます。

OMSインストール・ベース・ディレクトリの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のOracle Management Serviceの高可用性に関する項を参照してください。

デモ証明書のかわりにカスタムのWLS証明書を使用する場合の追加ステップ

別名ホスト名への移行の一環として、物理ホスト名のかわりに別名ホスト名のFQDNを反映するために、各OMSでWebLogic Server証明書が更新される必要があります。アップグレードおよび移行のプロセスには、デフォルトのWebLogic Serverデモ証明書に対してこれらの更新を実行するのに必要な手順が含まれています。カスタムのWLS証明書の更新に必要な手順は含まれていません。

カスタムのWLS証明書の詳細は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』のWebLogic Serverのカスタム証明書の構成に関する項を参照してください。

WLSにカスタム証明書を使用する場合、続行する前に、必要な証明書を取得しており、アップグレードおよび移行のプロセスにおいて適切な時点で更新を実行するために必要なステップを理解していることを確認します。

アップグレードされたEnterprise Manager 13c環境に対するSLB構成の更新

SLB構成の更新では、EM 13cでのAlways-On Monitoring (AOM)、BI PublisherおよびJava仮想マシン診断(JVMD)のSLB構成要件をサポートする必要があります。プライマリ・サイトおよびスタンバイ・サイトの両方のSLB構成がAOM、BI PublisherおよびJVMDをサポートするために必要な新しい構成で更新されることを確認します。以降のステップで、OMSを再保護して、BI PublisherおよびJVMDの更新された構成を実装します。

EM 13cでの高可用性についてのSLB構成の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のロード・バランサの構成に関する項を参照してください。

EM 13cでの障害時リカバリについてのSLB構成の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の管理サービスの障害時リカバリに関する項を参照してください。

サイト用のSLBの構成についての詳細なステップごとのステップの例は、ホワイトペーパーEnterprise Manager 13c Cloud Control F5 BIG-IPローカル・トラフィック・マネージャでのOMS高可用性の構成を参照してください。

バックアップの作成

アップグレードおよび移行を開始する前に、環境全体をリセットする必要がある場合にフォールバックとして使用できるバックアップのセットを作成します。バックアップ・プロセスには5つのパートがあります。

各OMS関連ディレクトリのフル・バックアップ
各OMSの構成のバックアップ
ソフトウェア・ライブラリのバックアップ
BI Publisher記憶域のバックアップ(構成されている場合)
リポジトリ・データベースの対応するバックアップ

OMSの関連ディレクトリのバックアップには、インスタンス、ミドルウェア、エージェントおよびインベントリを含める必要があります。OMSの関連ディレクトリのバックアップはファイルシステム・バックアップであるため、rootとして実行され、OMSおよびエージェントが停止している間に実行される必要があります。これらのバックアップは、可用性を確保するため、時間差方式で一度に1つのOMSに対して実行できます。各OMSをバックアップする必要があります。

ソフトウェア・ライブラリの単一の対応するバックアップが必要です。

BI Publisherが構成される場合には、BI Publisherの構成およびクラスタ・ボリュームの単一の対応するバックアップも必要です。データベースの対応するバックアップも作成または特定される必要があります。

Enterprise Managerのバックアップの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のEnterprise Managerのバックアップとリカバリに関する項を参照してください。

DR準備状況へのアップグレードおよび移行のためのプライマリおよびスタンバイOMSの準備

DR準備状況へのアップグレードおよび移行のためにプライマリOMSおよびスタンバイOMSを準備するには、次のステップに従います。

すべてのプライマリおよびスタンバイOMSサーバーのレプリケートされた記憶域構成用の準備

すべてのプライマリおよびスタンバイOMSサーバーをレプリケートされた記憶域構成用に準備します。各対応するプライマリおよびスタンバイOMSサーバーは、ミドルウェア・ホーム、インスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ホームを含むレプリケートされた記憶域をマウントするように構成される必要があります。これらのディレクトリは、アップグレードおよび移行のプロセスで使用されます。

これらの4つすべてのディレクトリが、レプリケートされた記憶域へのマウントポイントとして機能できる、OMSインストール・ベース・ディレクトリの下に配置されているようにすることがベスト・プラクティスです。また、各サイトのすべてのOMSサーバーは、BI Publisherおよびソフトウェア・ライブラリの共有記憶域をマウントするよう構成され、共有記憶域は1つのサイトのすべてのOMS間で共有され、サイト間でレプリケートされる必要があります。ディレクトリ・パスは、すべてのOMSサーバーで、ミドルウェア・ホーム、インスタンス・ベース、エージェント・ベース、Oracleインベントリ・ホーム、BI Publisherおよびソフトウェア・ライブラリ記憶域について同一である必要があります。

すべてのプライマリおよびスタンバイOMSサーバーのレプリケートされた記憶域構成用の準備は、次のときに完了します。

レプリケートされた記憶域がプライマリ・サイトでアクティブのとき
レプリケートされた記憶域がプライマリ・サイトのOMSサーバーにマウントされるとき
レプリケーションが構成され、構成されたスケジュールで実行しているとき
所有権および権限がプライマリ・サイトのOMSサーバーにマウントされた記憶域に適切に設定されているとき

記憶域の考慮事項の詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「記憶域の考慮事項」を参照してください。

すべてのプライマリおよびスタンバイOMSサーバーの別名ホスト名用の準備

プライマリ・サイトおよびスタンバイ・サイトの各対応するOMSホストが両サイトで同じ別名ホスト名で構成されるように、すべてのプライマリOMSサーバーおよびスタンバイOMSサーバーの別名ホスト名を構成します。各サイトのすべてのOMSサーバーが、この別名ホスト名を使用して同じサイトの他のすべてのOMSサーバーと通信できることを確認します。

詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「オプション2 - ホスト名計画時の両サイトの別名ホスト名」を参照してください。

プライマリOMS1のOracleインベントリ・ディレクトリへのインベントリ・ロケーション・ポインタ・ファイルの作成

レプリケートされた記憶域へのアップグレードおよび移行の一環として、OMSおよびOMSエージェント・ソフトウェアはOMSインストール・ベース・ディレクトリの下にあるレプリケートされた記憶域上のOracleインベントリに関連付けられる必要があります。アップグレードが完了したら、OMSおよびOMSエージェントのすべてのメンテナンスにこのOracleインベントリの場所を使用して、どのサイトが現在アクティブのサイトとして機能していてもソフトウェア・メンテナンスを実行できるようにすることが重要になります。

レプリケートされた記憶域に配置されたOracleインベントリ・ディレクトリを作成し、プライマリOMS1のそのディレクトリにoraInst.locインベントリ・ロケーション・ポインタ・ファイルを作成します。インベントリ・ロケーション・ポインタ・ファイルは、レプリケートされた記憶域上のインベントリに、アップグレードされたソフトウェアが関連付けられるよう、インストーラを起動してアップグレードを実行する際に使用されます。

詳細は、Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイドの「OMSインストール・ベース・ディレクトリ配下のOracleインベントリの構成」を参照してください。

プライマリOMS1サーバーでのEnterprise Manager 13cインストール・ソフトウェアのステージング

アップグレードの準備としてEnterprise Manager 13cインストール・ソフトウェアをプライマリOMS1サーバーのディレクトリにステージングします。

すべてのプライマリおよびスタンバイ・サイトOMSでのローカル・ロック・ファイル・ディレクトリの準備

OHSのローカル・ロック・ファイルの格納に使用できるローカル記憶域に配置され、Oracleソフトウェア所有者ユーザーに所有されるディレクトリを作成または特定し、すべてのプライマリおよびスタンバイOMSサーバー上でそのディレクトリを一貫して構成します。以降のステップで、ローカル・ロック・ファイル格納用にこのディレクトリを使用するよう各OMSを構成することになります。

スタンバイOMSおよびOMSエージェントの削除

スタンバイOMSおよびOMSエージェントの削除は次のステップで実行します。

すべての追加スタンバイOMSインスタンスの削除

すべての追加スタンバイOMSインスタンスを削除するには、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの追加スタンバイOMSインスタンスの削除に関する項を参照してください。

最初のスタンバイOMSの削除

最初のスタンバイOMSを削除するには、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの最初のスタンバイOMSの削除に関する項を参照してください。

すべてのスタンバイOMSエージェントの削除

スタンバイOMSエージェントをすべて削除するには、各スタンバイOMSエージェントについて、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドのOracle Management Agentのアンインストールに関する項を参照してください。

すべてのスタンバイOMSバイナリのアンインストール

すべてのスタンバイOMSインスタンスのバイナリをアンインストールするには、各スタンバイOMSについて、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「Enterprise Managerのアンインストール」の手順を参照してください。

プライマリの追加OMSおよび追加OMSエージェントの削除

アップグレードを開始する前に、追加OMSと、追加OMS上のエージェントを削除します。各追加OMSに対して環境で次のステップを順に実行します。

ノート:

この時点では追加OMSおよびOMSエージェントのみが削除されるため、この項の手順はOracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「OMSのみをアンインストールし管理リポジトリを保持するための前提条件」の手順のサブセットになります。

プライマリの追加OMSおよび追加OMSエージェントを削除するには、次のステップに従います。

プライマリの追加OMSの停止と削除

プライマリ・サイトのすべての追加OMSを削除するには、各プライマリの追加OMSについて、個別に追加OMSを順に停止および削除する必要があります。

各プライマリの追加OMSについて追加OMSを停止および削除するには、次のステップに従います。

追加OMSサーバーで、Publisherが構成されている場合、次のコマンドを実行してOracle BI Publisher管理対象サーバーを停止します。

<OLD_ORACLE_HOME>/bin/emctl stop oms -bip_only -force

ノート:
Oracle BI Publisher管理対象サーバーの停止が失敗した場合は、オペレーティング・システムのコマンドを使用して手動で強制終了します。必ず、プロセスを正常に停止します。たとえば、Linuxでは‘kill -9 xxxx’ではなく‘kill xxxx’を使用します。ここでxxxxはプロセスになります。
追加OMSサーバーで、Publisherが構成されている場合、次のコマンドを実行して前のステップで停止されたBI Publisher管理対象サーバーを削除します。

<OLD_ORACLE_HOME>/bin/configureBIP –delete
追加OMSサーバーで、omsca deleteを実行して2つ目のプライマリOMS構成を削除します。これによりEnterprise ManagerリポジトリおよびWebLogic構成から追加のOMSが正常に削除され、構成ファイルが適切に更新されます。

<OLD_ORACLE_HOME>/bin/omsca delete -OMSNAME <ADDITIONAL_OMS_NAME> -REP_CONN_STR "<REPOSITORY_CONNECTION_STRING>"

追加OMSの<ADDITIONAL_OMS_NAME>、たとえばEMGC_OMS2は、追加OMSでのemctl status oms -detailsの実行の出力で確認できます。追加OMSの出力で、Managed Server Instance Nameに対して返された値を確認します。たとえば、Managed Server Instance Name: EMGC_OMS2となっています。
Enterprise Managerで、次の手順のBIP<#>、OMS<#>およびohs<#>にある<#>を追加OMSの適切な番号に置き換えて、削除したばかりの追加OMSに関連するターゲットを削除します。
1. BIP<#>、EMGC_OMS<#>およびohs<#>ターゲットのステータスがDownに変わるまで待機します。
2. OMS<#>でBI Publisherが構成されている場合、削除されたOMS<#>のBIP<#>ターゲットを削除します。
  1. ターゲット/EMGC_GCDomain/GCDomain/BIP<#>のホーム・ページに移動します。
  2. 「WebLogic Server」、「ターゲット設定」、「ターゲットの削除」の順に選択します。
  3. 「警告」ページで「はい」を選択します。
  4. ターゲットが削除されたことを確認します。
3. 削除されたOMS<#>のOMS<#>ターゲットを削除します。
  1. ターゲット/EMGC_GCDomain/GCDomain/EMGC_OMS<#>のホーム・ページに移動します。
  2. 「WebLogic Server」、「ターゲット設定」、「ターゲットの削除」の順に選択します。
  3. 「警告」ページで「はい」を選択します。
  4. ターゲットが削除されたことを確認します。
4. 削除されたOMS<#>のohs<#>ターゲットを削除します。
  1. ターゲット/EMGC_GCDomain/instance<#>/ohs<#>のホーム・ページに移動します。
  2. 「Oracle HTTP Server」、「ターゲット設定」、「ターゲットの削除」の順に選択します。
  3. 「確認」ダイアログで、「はい」を選択します。
  4. ターゲットが削除されたことを確認します。
OMS<#>エージェント<OLD_OMS_AGENT_HOME>/bin/emctl upload agentからアップロードします

ノート:
OMS<#>エージェントからアップロードするステップは、管理者に環境内の最新のコンポーネントの状態について可視性を与えるため、高可用性構成で実行する顧客に対して、(OMS<#> が削除された後に)この順で追加されます。

ノート:
数分間続いた後クリアされる可能性のあるアップロードの試行中に、エラーEMDアップロード・エラー:フル・アップロードが失敗しました: uploadXMLFilesはスキップされました :: OMSバージョンはまだ確認されていませんが発生する場合があります。この問題が解決されない場合、OMS関連エラー(OMS_DOWN)へのpingのトレース・ファイルを確認します。

プライマリの追加OMSエージェントの停止とアンインストール

プライマリの追加OMSエージェントをすべて削除するには、各プライマリの追加OMSエージェントについて、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドのOracle Management Agentのアンインストールに関する項を参照してください。

プライマリの追加OMSバイナリのアンインストール

すべてのプライマリの追加OMSインスタンスのバイナリをアンインストールするには、各プライマリの追加OMSについて、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドにあるEnterprise Managerのアンインストールの手順を参照してください。

OMS1およびリポジトリのアップグレードと移行

OMS1およびリポジトリのアップグレードおよび移行を行う前に、次のことを確認します。

環境がアップグレードおよび移行のプロセス用に準備されていること。アップグレードおよび移行のプロセスについて前に示したすべてのステップが完了していること。
Enterprise Manager Cloud Control 13cリリース4へのアップグレードの前提条件に示された前提条件を満たしていること。
続行する前にプライマリOMS1およびプライマリOMS1エージェントが停止していること。

次のステップを使用して、OMS1およびリポジトリのアップグレードおよび移行を実行します。

OMS1およびOracle Management Repositoryの13cリリース4へのアップグレードおよび移行

OMS1およびリポジトリをアップグレードおよび移行するには、プライマリOMS1で次のステップに従います。

ステップ1: DR準備状況にアップグレードおよび移行するためのEnterprise Manager Cloud ControlインストーラのGUIモードでの起動
ステップ2: Oracle Configuration Managerの有効化
ステップ3: 最新のソフトウェア更新の適用
ステップ4: 前提条件チェックの実行および環境の検証
ステップ5: インストール・タイプの選択
ステップ6: ミドルウェア・ホームの構成およびホスト名の検証
ステップ7: データベース接続の詳細の指定
ステップ8: プラグインのアップグレードまたは移行あるいは依存プラグインのデプロイ
ステップ9: 追加のプラグインのデプロイ
ステップ10: 既存のWebLogic Serverドメインの拡張
ステップ11: Oracle BI Publisherの共有場所の構成
ステップ12: ポートの構成
ステップ13: アップグレードの詳細の確認
ステップ14: アップグレードの進捗のモニタリング
ステップ15: アップグレードの終了

DR準備状況にアップグレードおよび移行するためのEnterprise Manager Cloud ControlインストーラのGUIモードでの起動

管理リポジトリ、OMS、インベントリ、ソフトウェア・ライブラリおよびEnterprise Managerの動作に不可欠なその他のコンポーネントをバックアップすることを強くお薦めします。これによって、アップグレードに失敗した場合に、元の内容に戻すことができます。

既存のOMS1が実行されているホストで、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。

./em13400_<platform>.bin -invPtrLoc <absolute_path_to_oraInst.loc_on_replicated_storage> ORACLE_HOSTNAME=<OMS1_ALIAS_HOSTNAME_FQDN> UPGRADE_TRANSITION=true OLD_INVENTORY_LOCATION=<OLD_INVENTORY_HOME>

例:

./em13400_linux64.bin -invPtrLoc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=emoms1.example.com UPGRADE_TRANSITION=true OLD_INVENTORY_LOCATION=/u01/app/oracle/oraInventory

次の各パラメータがインストーラに渡されることを確認します。

次のパラメータおよび値を指定すると、Enterprise Manager Cloud Control 13cのインストールがレプリケートされた記憶域にあるOracleインベントリと関連付けられるようになります。

-invPtrLoc <absolute_path_to_oraInst.loc_on_replicated_storage>
次のパラメータおよび値を指定すると、インストーラの「DR準備状況へのアップグレードおよび移行」モードを有効にします。

UPGRADE_TRANSITION=true
次のパラメータおよび値は、アップグレードされたOMS1に使用する別名ホスト名を指定します。

ノート:
必要に応じて「インストールの詳細」ページの「ホスト名」フィールドが、OMS1の別名ホスト名に一致するよう、確認され更新されていることを確認します。

ORACLE_HOSTNAME=<OMS1_ALIAS_HOSTNAME_FQDN>
次のパラメータおよび値は、アップグレードされているEnterprise Manager Cloud Controlインストールに関連付けられた古いOracleインベントリのディレクトリを指定します。

OLD_INVENTORY_LOCATION=<OLD_INVENTORY_HOME>

Oracle Configuration Managerの有効化

(オプション)「My Oracle Supportの詳細」画面でMy Oracle Support資格証明を入力してOracle Configuration Managerを有効にし、「次」をクリックします。今はOracle Configuration Managerを有効にしない場合、詳細を何も入力せずに「次」をクリックして最新のソフトウェア更新の適用に進みます。

インストール・ウィザードを実行しているホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールの完了後、構成情報を手動で収集し、My Oracle Supportにアップロードしてください。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

前提条件チェックの実行および環境の検証

「前提条件チェック」画面で、インストール・ウィザードによって実行された前提条件チェックのステータスを確認し、環境がアップグレード成功のためのすべての最小要件を満たしているかどうかを確認します。次に、「次へ」をクリックします。

インストール・ウィザードでは、この画面に達すると前提条件チェックが自動的に実行されます。前提条件チェックのステータスは、「警告」、「失敗」、「成功」、「未実行」、「進行中」または「保留」です。

「警告」または「失敗」ステータスになったチェックがある場合は、アップグレードを続行する前に問題を調査して修正してください。前提条件を満たさなかった理由と解決方法の詳細が画面に表示されます。問題を修正した後、この画面に戻り、「再実行」をクリックして前提条件を再度チェックします。

インストール・タイプの選択

「インストール・タイプ」ページで次のステップに従います。

「DR準備状況へのアップグレードおよび移行」を選択します。
「1システム・アップグレード」が選択されていることを確認します。
アップグレードおよび移行する管理サーバーのホームを選択します。

たとえば、/u01/app/oracle/MWare1とします
「次へ」をクリックします。

ミドルウェア・ホームの構成およびホスト名の検証

「インストールの詳細」ページで次のステップに従います。

インストーラがOracle WebLogic ServerおよびJava Development Kitを自動的にインストールできる、レプリケートされた記憶域上の新しいミドルウェア・ホームを入力します。この新しいミドルウェア・ホームが、OMSインストール・ベース・ディレクトリ配下のレプリケートされた記憶域にあることを確認します。たとえば、/u01/app/oracle/OMS/MWare_newです
ノート:
- ここで入力または検証するミドルウェア・ホームがEnterprise Manager Cloud Controlのみに使用されていることを確認してください。
- 他のOracle Fusion Middleware製品またはコンポーネントは、同じミドルウェア・ホームにインストールしないでください。
「ホスト名」を確認し、それがインストーラが起動されたときにORACLE_HOSTNAMEパラメータで指定されたOMS1の別名ホスト名であることを確認します。「ホスト名」がOMS1の別名ホスト名と一致しない場合、フィールドの内容をOMS1の別名ホスト名に置き換えます。
例: emoms1.example.com
「次へ」をクリックします。

データベース接続の詳細の指定

「データベース接続の詳細」ページで、「DDMPジョブを無効にします」を選択し、データベース接続の詳細の指定の以降の手順に従います。DDMPジョブは、後にアップグレードおよび移行のプロセスで発行されます。

ノート:

この時点でデータベースに対して実行する様々な前提条件チェック、および失敗した場合にそれらを修正する方法の詳細は、Enterprise Manager Cloud Control 13cリリース4にアップグレードするための前提条件を参照してください。

プラグインのアップグレードまたは移行あるいは依存プラグインのデプロイ

「プラグイン・アップグレード」画面で、次の影響のいずれかを受けるプラグインを確認して「次」をクリックします。

新しいバージョンが存在する場合にアップグレード
新しいバージョンが存在しない場合に移行
アップグレード対象のプラグインに新しい依存関係が存在する場合またはリリースで導入された新しいデフォルト・プラグインがある場合は、デプロイ済。

ここで、新しいバージョンとは、インストールに使用するEnterprise Managerソフトウェア(DVDまたはダウンロードしたソフトウェア)で提供されているプラグインの新しいバージョンを指します。

ノート:

13cリリース4でのみサポートされ、将来のリリースではサポートされないプラグイン・バージョンにアップグレード可能な非推奨のプラグインが環境にある場合があります。そのような非推奨のプラグインがこのアップグレードの画面でデフォルトで選択されている場合、選択内容を確認し、そのようなプラグインのアップグレードを続行するかどうかを決めるよう求められます。

ノート:

次の画面に進む前に、次のコマンドを実行して関連するOMSインスタンスすべてを停止します。<ORACLE_HOME>はOMSのOracleホームです。

$<ORACLE_HOME>/bin/emctl stop oms -all

ノート:

新しいバージョンが、使用するEnterprise Managerソフトウェアに存在しないがOracleソフトウェア・ダウンロードには存在する場合、既存のプラグインをデフォルトで自動的に移行するかわりに、新しいバージョンをOracleソフトウェア・ダウンロードから手動でダウンロードして既存のプラグインをアップグレードすることもできます。次のステップを実行します。
1. 必要なプラグインを手動でダウンロードします。
  - Oracleプラグインは、プラグインの更新からダウンロードできます。
  - Oracleのパートナによって作成されたプラグインは、Enterprise Manager Extensibility Exchangeで入手できます。
2. 次のオプションを指定してインストーラを起動し、追加のプラグインがダウンロードされている場所を渡します。
  
  UNIXプラットフォームの場合:
  
  ./em13400_<platform>.bin PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
  
  Microsoft Windowsプラットフォームの場合:
  
  setup_em13400_win64.exe PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
  
  ここには、ソフトウェア・キット(DVD、ダウンロードしたソフトウェア)で使用可能なプラグインや、このカスタムの場所で使用可能なプラグインの一覧が表示されます。インストールするものを選択できます。
プラグインの新しいバージョンが利用できるようになると、この画面にはそのプラグインが、自動的にアップグレードされるプラグインとしてリストされます。
OMSまたは管理エージェントの一部にサポートされていないプラグインがあるというメッセージが表示された場合は、メッセージの説明に従ってプラグインをアップグレードし、OMSのアップグレードを再試行します。

追加のプラグインのデプロイ

「プラグインの選択」画面で、OMSのアップグレード中に自動的にアップグレードされるプラグイン以外にデプロイするオプション・プラグインを選択し、「次」をクリックします。

ノート:

13cリリース4でのみサポートされ、将来のリリースではサポートされない非推奨のプラグインを選択した場合、選択内容を確認し、そのプラグインのデプロイメントを続行するかどうかを決めるよう求められます。

ノート:

この画面にリストされていないプラグインをインストールする場合は、次のステップに従います。

必要なプラグインを手動でダウンロードします。
- Oracleプラグインは、プラグインの更新からダウンロードできます。
- Oracleのパートナによって作成されたプラグインは、Enterprise Manager Extensibility Exchangeで入手できます。
次のオプションを指定してインストーラを起動し、追加のプラグインがダウンロードされている場所を渡します。

UNIXプラットフォームの場合:

em13400_<platform>.bin INSTALL_SWONLY_WITH_PLUGINS=true PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>

Microsoft Windowsプラットフォームの場合:

setup_em13400_win64.exe INSTALL_SWONLY_WITH_PLUGINS=true PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>

ここには、ソフトウェア・キット(DVD、ダウンロードしたソフトウェア)で使用可能なプラグインや、このカスタムの場所で使用可能なプラグインの一覧が表示されます。インストールするものを選択できます。

既存のWebLogic Serverドメインの拡張

「WebLogic Serverドメインの拡張」ページで、既存のWebLogic Serverドメインの拡張に示された手順に従います。

ノート:

「管理サーバー・ホスト」は依然としてOMS1の物理ホスト名を示しています。管理サーバーはOMS1別名ホスト名をこのアップグレードのモードの一部として使用するよう更新されるため、これで問題ありません。
OMSインスタンス・ベースの場所がレプリケートされた記憶域にあることを確認します。レプリケートされた記憶域がOMSインストール・ベース・ディレクトリまたはOMSインストール・ベース・ディレクトリの上に構成され、ミドルウェア・ホームがOMSインストール・ベース・ディレクトリの下にある場合、OMSインスタンス・ベースの場所はデフォルトでミドルウェア・ホームのピア・ディレクトリとなるため、変更する必要はありません。たとえば、/u01/app/oracle/OMS/gc_instです。
マウント・ポイントがNFSマウントされた記憶域を使用する場合、ロック・ファイル・ディレクトリをローカル記憶域に配置するように警告メッセージが表示されます。アップグレードおよび移行のプロセスのアップグレード後ステップで、httpロック・ファイルはアップグレードの完了後にローカル記憶域のディレクトリに配置されます。

Oracle BI Publisherの共有場所の構成

「Enterprise Manager共有場所の詳細」画面で、次の操作を実行して「次」をクリックします。

共有場所にすでにOracle BI Publisherがインストールおよび構成されているOMSをアップグレードする場合、Oracle BI Publisherを構成するためのフィールドは事前に入力され、グレー表示されます。それらはそのままにし、この画面の他のセクションに進むことができます。

しかし、Oracle BI PublisherがまだインストールされていないOMSをアップグレードする場合または共有場所にOracle BI Publisherはインストールされているが構成されていないOMSをアップグレードする場合、次の操作を実行します。

(i) Oracle BI Publisherのために使用できる共有場所を特定します。

既存の共有の場所が自動的に移入されます。既存の共有場所がない場合、新たに作成し、最初のOMSをインストールするホストおよび追加のOMSインスタンスをインストールする予定のホストでそれが認識されることを確認します。

インストールが成功するように、インストール時に共有ディレクトリ用のハードディスク・ドライブを約400MB予約できます。ただし、追加のプラグインをインストールしたり、さらに多くのレポートを作成するにつれて、領域の使用率は時間とともに増えていくため、最終的に少なくとも10GBに拡張し、将来的にはさらに拡張できるようにすることをお薦めします。

注意:

ソフトウェア・ライブラリ、または以前のリリースのEnterprise Managerのゴールド・イメージのステージング用に使用していた共有場所がすでにある場合、同じ場所を使用するよう選択できます。ただし、共有場所内のディレクトリはOracle BI Publisher、ソフトウェア・ライブラリおよびステージング済のゴールド・イメージに対して固有になるようにします。たとえば、共有場所/u01/software/examplehost/shrd/をすでに使用していて、ソフトウェア・ライブラリが/u01/software/examplehost/shrd/SW内に構成されている場合、同じ場所を使用できますが、Oracle BI Publisher用のこの共有場所内のディレクトリは必ず/u01/software/examplehost/shrd/BIPにします。

(ii) この画面で、「Oracle BI Publisherの共有場所の構成」を選択します。次のディレクトリ・パスを入力します。最初のOMSのインストールに使用するユーザー・アカウントに、これらのパスの読取りおよび書込み権限があることを確認します。

ノート:

Microsoft Windowsでインストーラを起動すると、「Enterprise Manager共有場所の詳細」画面には「構成ボリューム」オプションと「クラスタ・ボリューム」オプションが表示されません。これは予測されている動作です。

「構成ボリューム」に、Oracle BI Publisherリポジトリおよび構成ファイルが格納される共有記憶域の場所にある/configディレクトリまでのパスを入力します。たとえば、/u01/software/examplehost/shrd/BIP/configです。

「クラスタ・ボリューム」に、Oracle BI Publisherが高可用性環境で動作するためにOracle BI Publisherスケジューラ記憶域が保持される共有記憶域の場所にある/clusterディレクトリまでのパスを入力します。たとえば、/u01/software/examplehost/shrd/BIP/clusterです。

警告:

インストール後、これらのディレクトリを削除しないでください。これらのディレクトリはOracle BI Publisherが適切に機能するために必要なため、インストール後にも必要になります。
インストールおよび構成されているOracle BI Publisherを有効または無効にします。Oracle BI Publisherを有効にすると、ソフトウェアが起動され、Enterprise Managerシステム内で使用するための準備が整えられます。Oracle BI Publisherを無効にすると、ソフトウェアは起動されずにそのままになります。

Oracle BI Publisherを有効にするには、「Oracle BI Publisherの有効化」を選択します。

ノート:

インストール時にOracle BI Publisherを無効にするよう選択した場合、インストール後に、アップグレードされたOMSのOracleホームから次のEM CTLコマンドを実行して有効にできます。

$<ORACLE_HOME>/bin/emctl config oms -enable_bip

次に例を示します。

/u01/software/em13c/oraclehome/bin/emctl config oms -enable_bip

コマンドはOracle BI Publisherを有効にするのみで、起動はしません。起動するには、アップグレードされたOMSのOracleホームから次のコマンドを実行します。

$<ORACLE_HOME>/bin/emctl start oms -bip_only

/u01/software/em13c/oraclehome/bin/emctl start oms -bip_only

ポートの構成

「ポート構成の詳細」画面で、このリリースに追加されている新しいコンポーネントに使用するポートをカスタマイズして「次」をクリックします。

ほとんどのコンポーネントのポートは以前のリリースから自動的に引き継がれるため、この画面には、このリリースに追加されている新しいコンポーネント用のポートのみが示されます。

ノート:

この画面のすべてのポートが-1として表示される場合、インストーラがホスト上のポートをバインドできないことを示します。この問題を解決するには、インストーラを終了して、ホスト名とこのホストのIP構成を検証し(ホストのIPアドレスが別のホストで使用されていないことを確認)、インストーラを再起動して実行しなおします。

Oracleによって推奨されるポート範囲の内部または外部にある空きカスタム・ポートを入力できます。

ポートが空いているかどうかを確認するには、次のコマンドを実行します。

UNIXの場合:

netstat -an | grep <port no>
Microsoft Windowsの場合:

netstat -an|findstr <port_no>

ただし、カスタム・ポートは、1024より大きく、65535未満である必要があります。または、ポートがstaticports.iniファイルに事前に定義されていて、それらのポートを使用する場合、「staticports.iniファイルのインポート」をクリックして、ファイルを選択します。

ノート:

staticports.iniファイルがインストール中に渡される場合、staticports.iniファイルで定義されたポートがデフォルトで表示されます。ファイルが渡されない場合、推奨範囲から使用可能な最初のポートが表示されます。

staticports.iniファイルは次の場所にあります。

<Software_Extracted_Location>/response

アップグレードの詳細の確認

「確認」画面で、アップグレードのために指定した詳細を確認します。

インストーラはプラグインのあるソフトウェア・インストールのみを実行します。このステップはプロセスの一部です。実際のアップグレードは進行していません。

詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。
詳細を確認し問題がない場合、「アップグレード」をクリックしてアップグレードを開始します。

ノート:

「DR準備状況へのアップグレードおよび移行」を実行するときには、表示されている「ホスト名」がOMS1の別名ホスト名になっていることを確認します。そうなっていない場合、「インストールの詳細」画面に戻り、「ホスト名」が適切に指定されていることを確認します。

アップグレードの進捗のモニタリング

「インストールの進行状況」画面で、アップグレード操作の全体的な進行状況(パーセント)と各コンフィギュレーション・アシスタントのステータスを確認します。

ノート:

コンフィギュレーション・アシスタントが失敗すると、インストーラが停止し、失敗したコンフィギュレーション・アシスタントに関連する問題が解決するまで後続のコンフィギュレーション・アシスタントは実行されません。この場合は、問題を診断して解決してから、「インストールの進行状況」画面で「再試行」をクリックし、失敗したコンフィギュレーション・アシスタントから再度実行します。

ただし、誤って「再試行」をクリックする前にインストーラを終了してしまった場合は、この画面を開くためにインストーラを再起動しないでください。かわりに、OMSのOracleホームからrunConfig.shスクリプトを起動し、サイレント・モードでコンフィギュレーション・アシスタントを再度実行してください。runConfig.shスクリプトが失敗した場合、サービス・リクエストを発行してOracleサポートに連絡してください。

$<ORACLE_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_Middleware_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

次に例を示します。

/u01/software/em13c/oraclehome/oui/bin/runConfig.sh ORACLE_HOME=/u01/software/em13c/oraclehome MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗した場合、サービス・リクエストを発行してOracleサポートに連絡してください。
管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。

ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

アップグレードの終了

「終了」画面に、Enterprise Managerのアップグレードに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、ウィザードを終了します。

ソフトウェア・バイナリがコピーおよび構成されると、allroot.shスクリプトを実行するように求められます。別のウィンドウを開き、rootとしてログインし、これらのスクリプトを手動で実行します。

Microsoft Windowsオペレーティング・システム上でインストールしている場合、このスクリプトの実行は要求されません。

プライマリOMS1のロック・ファイル用のローカル・ファイル・システムの場所の指定

アップグレードおよび移行が完了したら、レプリケートされた記憶域がNFSを使用してマウントされる場合、httpd.confファイルをhttpロック・ファイルのローカル記憶域上の場所を指定するように編集します。Oracle Enterprise Managerの基本インストレーション・ガイドの「Enterprise Managerシステムのインストール後のインストール後タスクの実行」に続くステップの指示に従います。

ノート:

NFSマウントされたドライブを設置し、OMSインスタンス・ベース・ディレクトリ(gc_inst)をNFSマウントされたドライブに作成した場合、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。これを行うには、httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。

WebLogicおよびOMSが別名ホスト名用に構成されていることの確認

アップグレードおよび移行でOMSを別名ホスト名用に構成することに成功したことを確認するには、次のステップに従います。

プライマリOMS1で、httpd.confファイル内に構成されたServerNameがOMS1の別名ホスト名を示していることを確認します。
grep ^ServerName <NEW_INSTANCE_HOMEBASE>/user_projects/domains/GCDomain/config/fmwconfig/components/OHS/ohs<#>/httpd.conf

次に例を示します。

grep ^ServerName /u01/app/oracle/OMS/gc_inst/user_projects/domains/GCDomain/config/fmwconfig/components/OHS/ohs1/httpd.conf

出力の例:
```
[oracle@host1 ~]$ grep ^ServerName /u01/app/oracle/OMS/gc_inst/user_projects/domains/GCDomain/config/fmwconfig/components/OHS/ohs1/httpd.conf
ServerName emoms1.example.com
```

プライマリOMS1でemctl status oms -detailsの出力を調べます。

<NEW_MIDDLEWARE_HOME>/bin/emctl status oms -details

次に例を示します。

/u01/app/oracle/OMS/MWare_13.4/bin/emctl status oms -details

出力の例(重要点):

[oracle@host1 ~]$ /u01/app/oracle/OMS/MWare_13.4/bin/emctl status oms -details
Oracle Enterprise Manager Cloud Control 13c Release 4
Copyright (c) 1996, 2019 Oracle Corporation. All rights reserved.
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : emoms1.example.com
…
WLS Domain Information
Domain Name : GCDomain
Admin Server Host : emoms1.example.com
…
Oracle Management Server Information
Managed Server Instance Name: EMGC_OMS1
Oracle Management Server Instance Host: emoms1.example.com
WebTier is Up
Oracle Management Server is Up
JVMD Engine is Up
…

プライマリOMS1の物理ホスト名のFQDNを使用してブラウザを介してWebLogic管理コンソールにログインし、設定を確認して別名ホスト名が構成されていることを確認します。

https://<PRIMARY_OMS1_PHYSICAL_FQDN>:<ADMIN_SERVER_HTTPS_PORT>/console

次に例を示します。

https://host1.example.com:7101/console
1. GCDomain、「環境」の順に移動し、「サーバー」を選択します。「サーバー」表で各「サーバー」に対して次のことを実行します。
  1. 「サーバー名」のリンクをクリックします。
  2. 「構成」タブ内の「一般」タブで、「リスニング・アドレス」フィールドに<OMS1_ALIAS_HOSTNAME_FQDN>が表示されていることを確認します。
    
    次に例を示します。
    
    emoms1.example.com
2. GCDomain、「環境」の順に移動し、「マシン」を選択します。次のステップを実行します。
  1. 「マシン名」をクリックします。
  2. 「構成」タブ内の「ノード・マネージャ」タブで、「リスニング・アドレス」フィールドに<OMS1_ALIAS_HOSTNAME_FQDN>が表示されていることを確認します。
    
    次に例を示します。
    
    emoms1.example.com

OMS1エージェントのDR準備状況への移行

OMS1エージェントをDR準備状況に移行するには次のステップに従います。

ステップ1: OMS1エージェントのEnterprise Manager 13cリリース4へのアップグレード
ステップ2: OMS1エージェントのアップグレードの確認
ステップ3: OMS1エージェントのエージェント・アップグレード後のクリーンアップの実行
ステップ4: ローカル記憶域およびインベントリから、レプリケートされた記憶域およびインベントリへのOMS1エージェントの再配置
ステップ5: 別名ホスト名を使用したOMS1エージェントの再デプロイの準備
ステップ6: 別名ホスト名を使用したOMS1エージェントの再デプロイ
ステップ7: 別名ホスト名OMS1エージェントへのOMS1ターゲットの再配置
ステップ8: Enterprise Managerでのターゲットおよび構成情報の確認および更新
ステップ9: 存在しない物理ホスト名OMS1エージェントの廃止

OMS1エージェントのEnterprise Manager 13cリリース4へのアップグレード

OMS1エージェントをEnterprise Manager 13cリリース4にアップグレードするには、各ステップに示されたコマンドを使用して次のステップを実行します。

OMS1エージェントを起動します。

<OLD_OMS_AGENT_HOME>/bin/emctl start agent

例:

/u01/app/oracle/oms_agent/core/13.4.0.0.0/bin/emctl start agent
EMコンソールにログインし、エージェントが正常になり、すべてのOMS関連のターゲットがエージェント使用不可をレポートしなくなるまで待機します。
エージェント・アップグレード・コンソールまたはEM CLIを使用した13cリリース4への中央エージェントまたはスタンドアロン管理エージェントのアップグレードの手順に従って、OMS1エージェントをEnterprise Manager 13cリリース4にアップグレードします。

ノート:
エージェントの移動やクリーンアップの実行はまだ行わないでください。これらのアクティビティは次のステップで行われます。

OMS1エージェントのアップグレードの確認

13c管理エージェントのアップグレードの確認の手順に従って、OMS1エージェントがEnterprise Manager 13cリリース4へのアップグレードに成功したことを確認します。

OMS1エージェントのエージェント・アップグレード後のクリーンアップの実行

OMS1エージェントがEnterprise Manager 13cリリース4へのアップグレードに成功したことを確認した後、古い管理エージェントのアップグレード後クリーンアップの実行の手順に従って、以前のバージョンのOMS1エージェント・インストールをクリーンアップします。

ローカル記憶域およびインベントリから、レプリケートされた記憶域およびインベントリへのOMS1エージェントの再配置

OMS1エージェントをローカルのOracleインベントリに登録されたローカル記憶域上の場所から、レプリケートされた記憶域のOracleインベントリに登録されたレプリケートされた記憶域上の場所に再配置するには、各ステップに示されたコマンドを使用して次のステップを実行します。

ノート:

これらの手順は、中央エージェントのベース・ディレクトリのOracleミドルウェア・ホーム外への移動の手順に基づいています。ただし、このドキュメントの手順以外の、新しい場所に対して異なるOracleインベントリを使用するためにコマンドに指定する必要のある追加パラメータがあることに注目することが大切です。

エージェント・ベース・ディレクトリの下にplugins.txtファイルが存在していることを確認します。

ls -alF <OLD_OMS_AGENT_BASE>

例:

ls -alF /u01/app/oracle/oms_agent
エージェント・ベース・ディレクトリの下にplugins.txtファイルが存在している場合、このファイルのバックアップを作成します。

cp -p <OLD_OMS_AGENT_BASE>/plugins.txt <OLD_OMS_AGENT_BASE>/plugins.txt.before_agent_migrate_regen_YYYYMMDD

例:

cp -p /u01/app/oracle/oms_agent/plugins.txt /u01/app/oracle/oms_agent/plugins.txt.before_agent_migrate_regen_20160502
エージェントが起動し、稼働していることを確認します。エージェントが実行していない場合は起動します。

<INTERIM_OMS_AGENT_HOME>/bin/emctl status agent

例:

/u01/app/oracle/oms_agent/agent_13.4.0.0.0/bin/emctl status agent

先に進む前に、エージェントが起動し、稼働していることを確認します。

plugins.txtファイルを再生成します。

<INTERIM_OMS_AGENT_HOME>/perl/bin/perl <INTERIM_OMS_AGENT_HOME>/sysman/install/create_plugin_list.pl -instancehome <INTERIM_OMS_AGENT_INSTANCE_HOME>

例:

/u01/app/oracle/oms_agent/agent_13.4.0.0.0/perl/bin/perl /u01/app/oracle/oms_agent/agent_13.4.0.0.0/sysman/install/create_plugin_list.pl -instancehome /u01/app/oracle/oms_agent/agent_inst

AgentMigrate.plスクリプトを実行し、エージェントをレプリケートされた記憶域およびレプリケートされた記憶域上のOracleインベントリに再配置します。

<INTERIM_OMS_AGENT_HOME>/perl/bin/perl <INTERIM_OMS_AGENT_HOME>/sysman/install/AgentMigrate.pl -instanceHome <INTERIM_OMS_AGENT_INSTANCE_HOME> -newAgentBaseDir <NEW_OMS_AGENT_BASE> -invPtrLoc <NEW_INVENTORY_HOME>/oraInst.loc

例:

/u01/app/oracle/oms_agent/agent_13.4.0.0.0/perl/bin/perl /u01/app/oracle/oms_agent/agent_13.4.0.0.0/sysman/install/AgentMigrate.pl -instanceHome /u01/app/oracle/oms_agent/agent_inst -newAgentBaseDir /u01/app/oracle/OMS/oms_agent -invPtrLoc /u01/app/oracle/OMS/oraInventory/oraInst.loc

rootとしてログインし、指示されたらroot.shスクリプトを実行します。

<NEW_OMS_AGENT_HOME>/root.sh

例:

/u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/root.sh
エージェントのステータスを取得します。

<NEW_OMS_AGENT_HOME>/bin/emctl status agent

例:

/u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/bin/emctl status agent
先に進む前に、Enterprise Managerコンソールで、Enterprise Manager関連のターゲットのステータスが「ステータス保留中(ブラックアウト後)の診断」を表示しなくなり、OMS1エージェントおよびホスト・ターゲットが「エージェント使用不可」を表示しなくなるまで待機します。
AgentDeinstall.plスクリプトを起動してローカル記憶域上の暫定エージェントをアンインストールします。

<INTERIM_OMS_AGENT_HOME>/perl/bin/perl <INTERIM_OMS_AGENT_HOME>/sysman/install/AgentDeinstall.pl -agentHome <INTERIM_OMS_AGENT_HOME>

例:

/u01/app/oracle/oms_agent/agent_13.4.0.0.0/perl/bin/perl /u01/app/oracle/oms_agent/agent_13.4.0.0.0/sysman/install/AgentDeinstall.pl -agentHome /u01/app/oracle/oms_agent/agent_13.4.0.0.0

ノート:
<INTERIM_OMS_AGENT_HOME>の下のローカル記憶域に配置された暫定エージェントのインストールのみアンインストールされることになります。Cloud Controlからターゲットを削除しないでください。これらのターゲットは、今は <NEW_OMS_AGENT_HOME>の下のレプリケートされた記憶域に再配置されたエージェントによって管理されているためです。そのため、AgentDeinstall.plコマンドの出力の下部にあるメッセージ「Make sure to delete the targets manually from the Cloud Control Console for a successful deinstallation」は無視してください。

別名ホスト名を使用したOMS1エージェントの再デプロイの準備

OMS1エージェントは、OMS1エージェントを別名ホスト名で構成するために、レプリケートされた記憶域上の既存のインストールを使用します。別名ホスト名を使用してOMS1エージェントを再デプロイする準備をするには、各ステップに示されたコマンドを使用して次のステップを実行します。

<NEW_OMS_AGENT_BASE>の下にあるplugins.txtファイルを更新して現在の情報を含めます。
1. 現在のplugins.txt関連のファイルを特定します。
  
  ls -ltr <NEW_OMS_AGENT_BASE>/plugins*
  
  例:
  
  ls -ltr /u01/app/oracle/OMS/oms_agent/plugins*
2. 既存のplugins.txtファイルがある場合にはそのファイルのバックアップを作成します。
  
  cp -p <NEW_OMS_AGENT_BASE>/plugins.txt <NEW_OMS_AGENT_BASE>/plugins.txt.before_update_YYYYMMDD
  
  例:
  
  cp -p /u01/app/oracle/OMS/oms_agent/plugins.txt /u01/app/oracle/OMS/oms_agent/plugins.txt.before_update_20160502
3. エージェントが起動し、稼働していることを確認します。エージェントが実行していない場合は起動します。
  
  <NEW_OMS_AGENT_HOME>/bin/emctl status agent
  
  例:
  
  /u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/bin/emctl status agent
  
  先に進む前に、エージェントが起動し、稼働していることを確認します。
4. 次のスクリプトを実行してplugins.txtファイルを生成します。
  
  <NEW_OMS_AGENT_HOME>/perl/bin/perl <NEW_OMS_AGENT_HOME>/sysman/install/create_plugin_list.pl -instancehome <NEW_OMS_AGENT_INSTANCE_HOME>
  
  例:
  
  /u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/perl/bin/perl /u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/sysman/install/create_plugin_list.pl -instancehome /u01/app/oracle/OMS/oms_agent/agent_inst
5. plugins.txt関連ファイルを確認します。
  
  ls -ltr <NEW_OMS_AGENT_BASE>/plugins*
  
  例:
  
  ls -ltr /u01/app/oracle/OMS/oms_agent/plugins*
OMS1エージェントからアップロードします。

<NEW_OMS_AGENT_HOME>/bin/emctl upload agent

例:

/u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/bin/emctl upload agent
プライマリOMS1エージェントを停止します。

<NEW_OMS_AGENT_HOME>/bin/emctl stop agent

例:

/u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/bin/emctl stop agent
OMS1エージェントのインスタンス・ディレクトリを移動します。

mv <NEW_OMS_AGENT_INSTANCE_HOME> <NEW_OMS_AGENT_INSTANCE_HOME>.YYYYMMDD

例:

mv /u01/app/oracle/OMS/oms_agent/agent_inst /u01/app/oracle/OMS/oms_agent/agent_inst.20160502

別名ホスト名を使用したOMS1エージェントの再デプロイ

物理ホスト名のかわりに別名ホスト名を使用してOMS1エージェントを再デプロイするには、各ステップに示されたコマンドを使用して次のステップを実行します。

OMS1エージェントおよびそのモニタリングされているすべてのターゲットがCloud Controlコンソールで使用不可状態になるまで待機します。
古い物理ホスト名に基づくエージェントのOracleホーム・ターゲットを削除して、別名ホスト名を使用したエージェントの再デプロイによる共有エージェントの問題を防ぎます。同じステップが、ローカル記憶域上にあるアップグレードされた暫定Enterprise Manager 13cの物理ホスト名エージェントに1回と、レプリケートされた記憶域上にあるEnterprise Manager 13cの物理ホスト名エージェントに1回の、2回実行されます。
1. ローカル記憶域に配置された、アップグレードされた暫定Enterprise Manager 13c物理ホスト名エージェントのOracleホームに対して次のステップを実行します。
  
  <INTERIM_OMS_AGENT_HOME>
  
  例:
  
  /u01/app/oracle/oms_agent/agent_13.4.0.0.0
  1. Enterprise Managerで、ローカル記憶域に配置された、アップグレードされた暫定Enterprise Manager 13c物理ホスト名エージェントのOracleホームに移動します。
  2. 「Oracleホーム」、「ターゲット設定」、「ターゲットの削除」の順に選択します。
  3. 「確認」ダイアログで「はい」を選択します。
  4. Oracleホームが削除されていることを確認します。
2. レプリケートされた記憶域に配置された、Enterprise Manager 13c物理ホスト名エージェントのOracleホームに対して次のステップを実行します。
  
  <NEW_OMS_AGENT_HOME>
  
  例:
  
  /u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0
  1. Enterprise Managerで、レプリケートされた記憶域に配置された、Enterprise Manager 13c物理ホスト名エージェントのOracleホームに移動します。
  2. 「Oracleホーム」、「ターゲット設定」、「ターゲットの削除」の順に選択します。
  3. 「確認」ダイアログで「はい」を選択します。
  4. Oracleホームが削除されていることを確認します。
ノート:
次のステップでagentDeploy.shを実行する前に、前述のステップが正常に完了していることを確認することが重要です。
agent_instを作成します。

<NEW_OMS_AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<NEW_OMS_AGENT_BASE> AGENT_INSTANCE_HOME=<NEW_OMS_AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<OMS1_ALIAS_HOSTNAME_FQDN> AGENT_PORT=<OMS_AGENT_PORT> -configOnly OMS_HOST=<OMS_HOST> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<AGENT_REG_PASSWORD> PLUGIN_RSPFILE=<NEW_OMS_AGENT_BASE>/plugins.txt

例:

/u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=/u01/app/oracle/OMS/oms_agent AGENT_INSTANCE_HOME=/u01/app/oracle/OMS/oms_agent/agent_inst ORACLE_HOSTNAME=emoms1.example.com AGENT_PORT=3872 -configOnly OMS_HOST=em.example.com EM_UPLOAD_PORT=4900 AGENT_REGISTRATION_PASSWORD=myagentpassword PLUGIN_RSPFILE=/u01/app/oracle/OMS/oms_agent/plugins.txt
rootとしてログインし、前述のコマンドの出力で指示されたらroot.shスクリプトを実行します。

<NEW_OMS_AGENT_HOME>/root.sh

例:

/u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/root.sh
エージェントのステータスを確認します。すべてのアップロードが完了するまで必要に応じて繰り返します。

<NEW_OMS_AGENT_HOME>/bin/emctl status agent

例:

/u01/app/oracle/OMS/oms_agent/agent_13.4.0.0.0/bin/emctl status agent
Enterprise Managerで、OMS1の別名ホスト名エージェントおよびホストがターゲットとして「稼働中」のステータスでEMに示されていることを確認します。

別名ホスト名OMS1エージェントへのOMS1ターゲットの再配置

物理ホスト名エージェントに関連付けられたOMS1関連ターゲットを別名ホスト名エージェントに再配置するには、各ステップに示されたコマンドを使用して次のステップを実行します。

次のコマンドを使用し、oracle_emrep targetを新しいOMSホストの管理エージェントに再配置します。

<NEW_MIDDLEWARE_HOME>/bin/emcli login -username="<EM_USERNAME>"

<NEW_MIDDLEWARE_HOME>/bin/emcli sync

<NEW_MIDDLEWARE_HOME>/bin/emctl config emrep -agent <OMS1_ALIAS_HOSTNAME_FQDN>:<OMS_AGENT_PORT>

例:

/u01/app/oracle/OMS/MWare_13.4/bin/emcli login -username="john.doe@example.com"

/u01/app/oracle/OMS/MWare_13.4/bin/emcli sync

/u01/app/oracle/OMS/MWare_13.4/bin/emctl config emrep -agent emoms1.example.com:3872

ノート:
エージェント間のタイムゾーンの差によるエラーが発生した場合、エージェントのタイムゾーンを一致させます。emctl config emrep -agentを実行し、フラグ-ignore_timeskewを設定した場合、管理サービスとリポジトリ・ターゲットが新しいエージェントに移動されたときにモニター対象ターゲットの可用性が影響を受けてモニタリング・データが失われることがあります。管理エージェントのタイムゾーンのリセットの詳細は、Oracle Enterprise Manager Cloud Control管理者ガイドの「管理エージェントのEMCTLコマンド」のemctl resetTZ agentを参照してください。これらのエラーが修正されたら、ターゲットの再配置を再試行します。
Oracleソフトウェア所有者ユーザーのホーム・ディレクトリの下に、OMS1の別名ホスト名にOMS1の物理ホスト名をマップするために使用されるマッピング・ファイルを作成します。

vi <ORACLE_SOFTWARE_OWNER_USER_HOME>/<PRIMARY_OMS1_PHYSICAL_HOSTNAME>_to_<OMS1_ALIAS_HOSTNAME>_host_mapping.txt

例:

vi /home/oracle/host1_to_emoms1_host_mapping.tx

このファイルには、物理および別名ホスト名のFQDNのカンマ区切りのリストが含まれている必要があります。最初のエントリはレプリケートされるホスト名(この場合OMS1の物理ホスト名)で、2つ目のエントリは新しいホスト名(この場合OMS1の別名ホスト名)です。

<PRIMARY_OMS1_PHYSICAL_FQDN>,<OMS1_ALIAS_HOSTNAME_FQDN>

例:

host1.example.com,emoms1.example.com
emcliを介してrelocate_wls動詞を一度実行してターゲットを再配置します。

<NEW_MIDDLEWARE_HOME>/bin/emcli relocate_wls -target_name=/EMGC_GCDomain/GCDomain -host=<OMS1_ALIAS_HOSTNAME_FQDN> -port=<ADMIN_SERVER_HTTPS_PORT> -dest_agent=<OMS1_ALIAS_HOSTNAME_FQDN>:<OMS_AGENT_PORT> -src_agent=<PRIMARY_OMS1_PHYSICAL_FQDN>:<OMS_AGENT_PORT> -debug

例:
/u01/app/oracle/OMS/MWare_13.4/bin/emcli relocate_wls -target_name=/EMGC_GCDomain/GCDomain -host=emoms1.example.com -port=7101 -dest_agent=emoms1.example.com:3872 -src_agent=host1.example.com:3872 -debug
2回目にemcliを介してrelocate_wls動詞を追加パラメータとともに実行して、ターゲットのホスト名を必要に応じて更新します。

<NEW_MIDDLEWARE_HOME>/bin/emcli relocate_wls -target_name=/EMGC_GCDomain/GCDomain -host=<OMS1_ALIAS_HOSTNAME_FQDN> -port=<ADMIN_SERVER_HTTPS_PORT> -dest_agent=<OMS1_ALIAS_HOSTNAME_FQDN>:<OMS_AGENT_PORT> -src_agent=<PRIMARY_OMS1_PHYSICAL_FQDN>:<OMS_AGENT_PORT> -input_file=old_to_new_host_mapping_file:<ORACLE_SOFTWARE_OWNER_USER_HOME>/<PRIMARY_OMS1_PHYSICAL_HOSTNAME>_to_<OMS1_ALIAS_HOSTNAME>_host_mapping.txt -debug

例:
/u01/app/oracle/OMS/MWare_13.4/bin/emcli relocate_wls -target_name=/EMGC_GCDomain/GCDomain -host=emoms1.example.com -port=7101 -dest_agent=emoms1.example.com:3872 -src_agent=host1.example.com:3872 -input_file=old_to_new_host_mapping_file:/home/oracle/host1_to_emoms1_host_mapping.txt -debug
プライマリOMS1上の別名ホスト名に関連付けられた、レプリケートされた記憶域上のアップグレード済ミドルウェア・ホームのOracleホームを削除します。このOracleホームは、次のステップで再検出されます。これは、関連付けが確実に正しいOracleホームに適切に行われるよう実行されます。

Oracleホームを削除するには:
1. Enterprise Managerで、プライマリOMS1上の別名ホスト名に関連付けられた、レプリケートされた記憶域上のアップグレード済ミドルウェア・ホームのOracleホームに移動します。
  
  Host <OMS1_ALIAS_HOSTNAME_FQDN>
  
  Host Location <NEW_MIDDLEWARE_HOME>
  
  例:
  
  Host emoms1.example.com
  
  Home Location /u01/app/oracle/OMS/MWare_13.4
  
  Oracleホームのターゲット名の例:
  
  oms13c1_1_emoms1.example.com_9136
2. 「Oracleホーム」、「ターゲット設定」、「ターゲットの削除」の順に選択します。
3. 「確認」ダイアログで「はい」を選択します。
4. Oracleホームが削除されていることを確認します。
プライマリOMS1上で「Oracleホーム昇格ターゲットの検出」ジョブを実行し、別名ホスト名に関連付けられた、レプリケートされた記憶域上のアップグレード済ミドルウェア・ホームのOracleホームを検出します。
1. 「エンタープライズ」、「ジョブ」の順に移動し、「アクティビティ」を選択します。
2. 「ジョブの作成」をクリックします。
3. 「ジョブ・タイプの選択 - Oracle Enterprise Manager」ダイアログで「Oracleホーム昇格ターゲットの検出」を選択します。
4. 「選択」をクリックします。
5. 「Promote OMS1 Oracle Home」のようにジョブの名前を入力します。
6. 「ターゲット」セクションで「追加」をクリックします。
7. 「検索と選択: ターゲット」ダイアログで、OMS1の別名ホスト名を選択します
  
  <OMS1_ALIAS_HOSTNAME_FQDN>
  
  例:
  emoms1.example.com
8. 「選択」をクリックします。
9. 「パラメータ」タブをクリックします。
10. 「パス」に、レプリケートされた記憶域上のプライマリOMS1の、アップグレード済ミドルウェア・ホームへのパスを入力します。
  
  <NEW_MIDDLEWARE_HOME>
  
  例:
  /u01/app/oracle/OMS/MWare_13.4
11. 「エンティティの管理」が「Oracleホーム」に設定され、「アクション」が「検出と管理」に設定されていることを確認します。
12. 「送信」をクリックします。
13. ジョブが「成功しました」となったら、ジョブ出力を確認して、Oracleホームが適切に検出されたことを確認します。
プライマリOMS1上の別名ホスト名に関連付けられた、レプリケートされた記憶域上のアップグレード済ミドルウェア・ホームのOracleホーム・ターゲットのホームページに移動します。
1. 「関連付けられたインスタンス・ターゲット」リストを確認します。
2. リストされたターゲットがない場合、数分待機し、リフレッシュして、このリストが移入されるまで繰り返します。
3. リストが移入されたら、次の項に示されるターゲットおよび構成情報の確認および更新に進みます。

Enterprise Managerでのターゲットおよび構成情報の確認および更新

Enterprise Managerコンソールを使用してリンクからWebLogic管理コンソールにアクセスできるようにするには、WebLogic管理コンソールのURLを更新します。Enterprise Managerコンソールを使用してURLを更新するには、次のステップを実行します。

WebLogicドメイン・ターゲットに移動します(/EMGC_GCDomain/GCDomain)。
「WebLogicドメイン」、「ターゲット設定」、「モニタリング構成」の順に選択します。
ホスト名を確認し、ホスト名にOMSの別名ホスト名のFQDNが含まれていることを確認します。
WebLogic管理コンソールのURIを確認し、WebLogic管理コンソールのURLをプライマリOMS1の物理ホスト名のFQDNを含むように更新します。

https://<PRIMARY_OMS1_PHYSICAL_FQDN>:<ADMIN_SERVER_HTTPS_PORT>/console

次に例を示します。

https://host1.example.com:7101/console
前述の変更をした場合、「OK」をクリックします。変更していない場合、「取消」をクリックします。

ノート:
各スイッチオーバーまたはフェイルオーバー操作後には、WebLogic管理コンソールのURIをOMS1をホストしている物理ホストに更新する必要があります。

存在しない物理ホスト名OMS1エージェントの廃止

次のステップを使用して、Enterprise Managerで、存在しなくなったOMS1エージェント(物理ホスト名に関連付けられていたエージェント)を廃止します。

プライマリOMS1上の古い物理ホスト名に基づいたエージェントのホームページに移動します。

<PRIMARY_OMS1_PHYSICAL_FQDN>:<OMS_AGENT_PORT>

次に例を示します。

host1.example.com:3872
「エージェント」、「ターゲット設定」、「エージェント廃止」の順に選択します。
「確認」ダイアログで「続行」を選択します。
プライマリOMS1上の古い物理ホスト名に基づいたエージェントにモニタリングされているターゲットを確認します。
ノート:

モニタリングされるターゲットには、プライマリOMS1サーバーの古い物理ホスト名に関連付けられた古いOracleホーム、エージェント、プライマリOMS1サーバーの物理ホスト名ホスト、および名前にプライマリOMS1サーバーの物理ホスト名を含む他のターゲットのみが含まれるようにします。プライマリOMS1の物理ホスト名をターゲット名の一部として含まない他のすべてのWebLogicドメイン関連ターゲットが、新しい別名ホスト名エージェントにのみ関連付けられているのであれば、/EMGC_GCDomain/GCDomain Oracle WebLogicドメイン・ターゲットが古い物理ホスト名エージェントと新しい物理ホスト名エージェントの両方の下にリストされても問題ありません。

レプリケートされた記憶域および別名ホスト名にアップグレードおよび移行されたOMSコンポーネントおよびエージェントの現在のバージョンに関連する追加ターゲットがある場合、先に進む前にemcli relocate_targetsコマンドを使用してこれらのターゲットを取り消して新しいエージェントに再配置し、前述のエージェント廃止ステップを再開します。
ノート:
前述のサブステップ完了後、この時点で、OMSコンポーネントの現在のバージョンに関連のない追加ターゲット、およびレプリケートされた記憶域および別名ホスト名にアップグレードおよび移行されたものの、まだエージェント(OMSサーバーにローカルにインストールされた他のソフトウェア、または物理ホストからモニタリングされる必要のある他のターゲットなど)によって管理される必要があるエージェントがある場合には、2つのオプションがあります。
- これらのターゲットをemcli relocate_targetsコマンドを使用して新しいエージェントに再配置し、後に、以降のホストベースのエージェントのプライマリおよびスタンバイOMSへのデプロイのステップでプライマリOMS1に作成した後で、それらを新しいレプリケートされた記憶域のエージェントから、新しい物理ホスト名エージェントにもう一度再配置します。
  
  または
- 新しい物理ホスト名エージェントが以降のホストベースのエージェントのプライマリおよびスタンバイOMSへのデプロイのステップでプライマリOMS1にデプロイされた後で、エージェントの廃止およびターゲットの再検出とともにターゲットを削除できるようにします。
「続行」を選択します。
エージェント廃止の確認ダイアログが表示されたら、「OK」を選択します。

プライマリ・サイト構成の更新

プライマリ・サイト構成を更新するには、次のステップに従います。

ステップ1: 更新されたEnterprise Manager 13cのSLB構成を含めるためのOMS1の再保護
ステップ2: Oracle Management ServiceとBI Publisher間の内部チャネルの構成
ステップ3: DDMPジョブの発行

更新されたEnterprise Manager 13cのSLB構成を含めるためのOMS1の再保護

SLBは、このアップグレードおよび移行のプロセスの一環として、必要なEnterprise Manager 13cの構成を含めるように更新される必要があります。このステップでは、BI PublisherおよびJVMDに対して、Enterprise Manager 13cのSLBの更新された構成を使用するために、OMS1の構成を再保護します。

Enterprise Manager 13cでの高可用性に対するSLB構成の詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「ロード・バランサの構成」を参照してください。

Enterprise Manager 13cでの障害時リカバリに対するSLB構成の詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「管理サービスの障害時リカバリ」を参照してください。

サイト用のSLBの構成についての詳細なステップごとのステップの例は、ホワイトペーパーEnterprise Manager 13c Cloud Control F5 BIG-IPローカル・トラフィック・マネージャでのOMS高可用性の構成を参照してください

ノート:

エージェントを再保護しなくて済むように、emctl secure omsコマンドが、OMSが元々SLB構成用に保護されていたときに使用された同じ-host、-slb_portおよび-slb_console_portとともに実行されるようにすることが重要です。SLB構成を大幅に変更する必要がある場合には、エージェントが適切に再保護されていることを確認します。

更新されたEnterprise Manager 13cのSLB構成を含めるためにOMS1を再保護するには、次のステップに従います。

更新されたSLB構成を反映するためにOMSを保護します。

<NEW_MIDDLEWARE_HOME>/bin/emctl secure oms -host <OMS_HOST> -slb_port <SLB_VS_SECURE_UPLOAD_PORT> -slb_console_port <SLB_VS_SECURE_CONSOLE_PORT> -slb_bip_http_port <SLB_VS_UNSECURE_BIP_CONSOLE_PORT> -slb_bip_https_port <SLB_VS_SECURE_BIP_CONSOLE_PORT> -slb_jvmd_https_port <SLB_VS_SECURE_JVMD_PORT> -lock_console -lock_upload

次に例を示します。

/u01/app/oracle/OMS/MWare_13.4/bin/emctl secure oms -host em.example.com -slb_port 4900 -slb_console_port 443 -slb_bip_http_port 8080 -slb_bip_https_port 5443 -slb_jvmd_https_port 7301 -lock_console -lock_upload
OMS1を停止します。

<NEW_MIDDLEWARE_HOME>/bin/emctl stop oms -all

次に例を示します。

/u01/app/oracle/OMS/MWare_13.4/bin/emctl stop oms -all
OMS1を起動します。

<NEW_MIDDLEWARE_HOME>/bin/emctl start oms

次に例を示します。

/u01/app/oracle/OMS/MWare_13.4/bin/emctl start oms

Oracle Management ServiceとBI Publisher間の内部チャネルの構成

Enterprise Manager 13.1以降では、Oracle Management ServiceからBI Publisherへの通信がSLBを通るように構成できます。これによって、この通信を必要とするすべてのオペレーションが確実にSLBを経由するようになります。

内部チャネルの詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「BI Publisherにアクセスするためのパス」を参照してください。

内部チャネルをBI Publisher用に構成するには、次のステップに従います。

プライマリOMS1で次のコマンドを実行し、内部チャネルの現在の設定を確認します。

<NEW_MIDDLEWARE_HOME>/bin/emcli login -username="<EM_USERNAME>"

<NEW_MIDDLEWARE_HOME>/bin/emcli sync

<NEW_MIDDLEWARE_HOME>/bin/emcli unregister_bipublisher

次に例を示します。

/u01/app/oracle/OMS/MWare_13.4/bin/emcli login -username="john.doe@example.com"

/u01/app/oracle/OMS/MWare_13.4/bin/emcli sync

/u01/app/oracle/OMS/MWare_13.4/bin/emcli unregister_bipublisher

出力の例:

$ /u01/app/oracle/OMS/MWare_13.4/bin/emcli login -username="john.doe@example.com"

Enter password :

Login successful

$ /u01/app/oracle/OMS/MWare_13.4/bin/emcli sync

Synchronized successfully

$ /u01/app/oracle/OMS/MWare_13.4/bin/emcli unregister_bipublisher

Error: The BI Publisher managed server named "https://emoms1.example.com:9803/xmlpserver" is registered. Use -force option to overwrite this.

ノート:
このコマンドはunregister_bipublisherと呼ばれますが、-forceパラメータが渡されなければ、実際に何かを登録解除するわけではありません。このコマンドの出力に、内部チャネルの現在の設定が表示されます。-forceを渡さないでください。
プライマリOMS1で次のコマンドを実行し、内部チャネルをSLB構成を使用するように変更します。

<NEW_MIDDLEWARE_HOME>/bin/emcli setup_bipublisher -force -nodeploy -proto=https -host=<OMS_HOST> -port=<SLB_VS_SECURE_BIP_CONSOLE_PORT> -uri=xmlpserver

次に例を示します。

/u01/app/oracle/OMS/MWare_13.4/bin/emcli setup_bipublisher -force -nodeploy -proto=https -host=em.example.com -port=5443 -uri=xmlpserver

出力の例:

$ /u01/app/oracle/OMS/MWare_13.4/bin/emcli setup_bipublisher -force -nodeploy -proto=https -host=em.example.com -port=5443 -uri=xmlpserver

BI Publisher "https://em.example.com:5443/xmlpserver" has been registered for use with Enterprise Manager.
プライマリOMS1で次のコマンドを実行し、内部チャネルの設定が更新されたことを確認します。ここで出力は、OMS1の別名ホスト名ではなく<OMS_HOST>を表示するはずです。

<NEW_MIDDLEWARE_HOME>/bin/emcli unregister_bipublisher

次に例を示します。

/u01/app/oracle/OMS/MWare_13.4/bin/emcli unregister_bipublisher

出力の例:

$ /u01/app/oracle/OMS/MWare_13.4/bin/emcli unregister_bipublisher

Error: The BI Publisher managed server named "https://em.example.com:5443/xmlpserver" is registered. Use -force option to overwrite this.

ノート:
このコマンドはunregister_bipublisherと呼ばれますが、-forceパラメータが渡されなければ、実際に何かを登録解除するわけではありません。このコマンドの出力に、内部チャネルの現在の設定が表示されます。-forceを渡さないでください。

DDMPジョブの発行

DDMPジョブは、以前に「データベース接続の詳細」ページで「DDMPジョブを無効にします」オプションが選択されたときのアップグレード中に無効にされています。DDMPジョブの詳細は、遅延データ移行ジョブのステータスの追跡を参照してください

DDMPジョブを発行するには、次のステップに従います。

「設定」、「Cloud Controlの管理」に移動し、「アップグレード後のタスク」を選択します。
「遅延データ移行」タブの表にリストされたジョブのステータスを確認します。すべてのタブがステータスNot Startedを示す必要があります。
表のすべての行を選択し、「開始」ボタンをクリックします。
ジョブが正常に完了するようジョブをモニタリングします。
1. ブラウザのリロード・ボタンを使用して現在のページをリロードします。
2. ページ右上に表示されるリフレッシュ・アイコンをクリックします。

新しいプライマリの追加OMS別名ホスト名エージェントと追加OMSの追加

新しいプライマリの追加OMS別名ホスト名エージェントと追加OMSを追加するには、次のステップに従います。

ステップ1: すべてのプライマリの追加OMSサーバーへの別名ホスト名エージェントのデプロイ
ステップ2: 追加OMSのデプロイ

すべてのプライマリの追加OMSサーバーへの別名ホスト名エージェントのデプロイ

Enterprise Managerで、エージェントを各プライマリの追加OMSサーバーの別名ホスト名にデプロイします。Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドの「ホスト・ターゲットの追加ウィザードを使用したスタンドアロン管理エージェントのインストール」の手順に従う際に、次の情報を確認し、この情報を使用します。

「ホスト・ターゲットの追加: ホストとプラットフォーム」ページで、最初の行の「ホスト」フィールドに追加OMSの別名ホスト名の完全修飾ドメイン名を入力します。

次に例を示します。

emoms2.example.com
「ホスト・ターゲットの追加: インストールの詳細」ページで次のことを実行します。
1. レプリケートされた記憶域のOMSインストール・ベース・ディレクトリの下に配置される必要のある、インストール・ベース・ディレクトリを入力します。追加OMS上のこのディレクトリ・パスは、OMS1エージェントで使用されるディレクトリ・パスと同じである必要があります。
  
  次に例を示します。
  
  /u01/app/oracle/OMS/oms_agent
2. 別名ホスト名エージェントのポートを入力します。これは最初のOMSで使用されるポートと同じポート番号である必要があり、アクティブのサイトのOMSサーバーのホストで実行しているOMSエージェントによって使用されるポート番号になります。
  
  次に例を示します。
  
  3872
3. 「オプションの詳細」を開き、「追加パラメータ」に次のように追加してレプリケートされた記憶域のOracleインベントリの使用を指定します。INVENTORY_LOCATION=<NEW_INVENTORY_HOME>
  
  次に例を示します。
  
  INVENTORY_LOCATION=/u01/app/oracle/OMS/oraInventory

追加OMSのデプロイ

Enterprise Managerで、各プライマリの追加OMSサーバーの別名ホスト名エージェントを使用して、追加のOMSを1つずつデプロイします。Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドの「Oracle Management Serviceの追加」の手順に従う際に、次の情報を確認し、この情報を使用します。

「接続先の選択」ページで次のことを実行します。
1. 「接続先ホスト」で追加OMSの、別名ホスト名の完全修飾ドメイン名を選択します。
  
  次に例を示します。
  
  emoms2.example.com
2. 「接続先インスタンス・ベースの場所」を確認します。これは、OMS1上の値と一致する必要があり、レプリケートされた記憶域上に配置される必要があります。
  
  次に例を示します。
  
  /u01/app/oracle/OMS/gc_inst
3. 「ソース」および「接続先」資格証明を選択または追加します。資格証明は、Oracleソフトウェア所有者ユーザーのものである必要があります。
「オプション」ページの「接続先ポート」セクションで、デフォルトで表示されるポートを検証します。これらのデフォルトのポートは、OMS1によってすでに割り当てられ、使用されているポートに基づいています。追加OMS上のこれらのポートをOMS1上のポートと同じままにすることがベスト・プラクティスです。
レプリケートされた記憶域がNFSマウントされている場合、「インストール後タスク」の手順に従って、追加OMSがデプロイされた後に、追加OMSのロック・ファイルをNFSマウントされたドライブからローカル・ファイル・システムの場所に必ず移動してください。

プライマリおよびスタンバイ・サイト構成のファイナライズ

プライマリおよびスタンバイ・サイト構成をファイナライズするには、次のステップに従います。

ステップ1: 別名ホスト名を反映するためのデモンストレーション・キーストアの更新
ステップ2: プライマリOMS1上のEnterprise Manager OMSバイナリのアンインストール
ステップ3: ホストベースのエージェントのプライマリおよびスタンバイOMSへのデプロイ
ステップ4: すべてのOMSノード上のエージェントに正しいタイムゾーン構成があることの確認
ステップ5: アップグレードおよび移行後のアクティビティの実行

別名ホスト名を反映するためのデモンストレーション・キーストアの更新

サイトがデモンストレーションWebLogic証明書を使用している場合に、WebLogicの通信が確実に両方のサイトで適切に機能するようにするには、証明書を別名ホスト名で再作成する必要があります。Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「別名ホスト名を反映するためのデモンストレーション・キーストアの更新」のステップに従います。

プライマリOMS1上のEnterprise Manager OMSバイナリのアンインストール

プライマリOMS1サーバー上のEnterprise Manager OMSのバイナリをアンインストールするには、中央エージェントが古いミドルウェア・ホーム外の場所に移行されている場合の古いOMSホームの削除を参照してください。

ホストベースのエージェントのプライマリおよびスタンバイOMSへのデプロイ

Enterprise Managerで、エージェントを各プライマリおよびスタンバイOMSサーバーの物理ホスト名にデプロイします。Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドの「ホスト・ターゲットの追加ウィザードを使用したスタンドアロン管理エージェントのインストール」の手順に従う際に、次の情報を確認し、この情報を使用します。

「ホスト・ターゲットの追加: ホストとプラットフォーム」ページで、プライマリおよびスタンバイOMSサーバーの各々に対して、それぞれの行に物理ホストの完全修飾ドメイン名を入力します。

次に例を示します。

host1.example.com
「ホスト・ターゲットの追加: インストールの詳細」ページで次のことを実行します。
1. インストール・ベース・ディレクトリを入力します。これは、これらのエージェントがプライマリおよびスタンバイ・サイトのターゲット・ホスト上で常に実行するため、ローカル記憶域に配置される必要があります。
  
  次に例を示します。
  
  /u01/app/oracle/local/oms_agent
2. 物理ホスト名エージェントのポートを入力します。これは、アクティブ・サイトのOMSサーバーのホストで実行中の別名ホスト名OMSエージェントで使用されるポート番号とは異なるポート番号である必要があります。
  
  次に例を示します。
  
  1830
3. 「オプションの詳細」を開き、「追加パラメータ」に次のように追加してローカル記憶域のOracleインベントリの使用を指定します。INVENTORY_LOCATION=<INVENTORY_HOME>
  
  次に例を示します。
  
  INVENTORY_LOCATION=/u01/app/oracle/oraInventory

すべてのOMSノード上のエージェントに正しいタイムゾーン構成があることの確認

すべてのOMSノード上のエージェントに正しいタイムゾーン構成があることを確認するには、次のステップに従います。

プライマリOMS1からemcliを使用して、すべてのOMSエージェント(物理ホスト名のローカル記憶域エージェントおよび別名ホスト名のレプリケートされた記憶域エージェント)の構成を確認します。各追加OMSに対して必要に応じてコマンドを追加します。

<NEW_MIDDLEWARE_HOME>/bin/emcli login -username="<EM_USERNAME>"

<NEW_MIDDLEWARE_HOME>/bin/emcli get_agent_properties -agent_name="<PRIMARY_OMS1_PHYSICAL_FQDN>:<LOCAL_AGENT_PORT>"

<NEW_MIDDLEWARE_HOME>/bin/emcli get_agent_properties -agent_name="<PRIMARY_OMS<#>_PHYSICAL_FQDN>:<LOCAL_AGENT_PORT>"

<NEW_MIDDLEWARE_HOME>/bin/emcli get_agent_properties -agent_name="<STANDBY_OMS1_PHYSICAL_FQDN>:<LOCAL_AGENT_PORT>"

<NEW_MIDDLEWARE_HOME>/bin/emcli get_agent_properties -agent_name="<STANDBY_OMS<#>_PHYSICAL_FQDN>:<LOCAL_AGENT_PORT>"

<NEW_MIDDLEWARE_HOME>/bin/emcli get_agent_properties -agent_name="<OMS1_ALIAS_HOSTNAME_FQDN>:<OMS_AGENT_PORT>"

<NEW_MIDDLEWARE_HOME>/bin/emcli get_agent_properties -agent_name="<OMS<#>_ALIAS_HOSTNAME_FQDN>:<OMS_AGENT_PORT>"

次に例を示します。

/u01/app/oracle/OMS/MWare_13.4/bin/emcli login -username="john.doe@example.com"

/u01/app/oracle/OMS/MWare_13.4/bin/emcli get_agent_properties -agent_name="host1.example.com:1830"

/u01/app/oracle/OMS/MWare_13.4/bin/emcli get_agent_properties -agent_name="host2.example.com:1830"

/u01/app/oracle/OMS/MWare_13.4/bin/emcli get_agent_properties -agent_name="host3.example.com:1830"

/u01/app/oracle/OMS/MWare_13.4/bin/emcli get_agent_properties -agent_name="host4.example.com:1830"

/u01/app/oracle/OMS/MWare_13.4/bin/emcli get_agent_properties -agent_name="emoms1.example.com:3872"

/u01/app/oracle/OMS/MWare_13.4/bin/emcli get_agent_properties -agent_name="emoms2.example.com:3872"
コマンドの結果を確認します。ローカル・エージェントがタイムゾーン構成においてレプリケートされた記憶域エージェントと異なる場合、ローカル・エージェントのタイムゾーンをリセットします。
OMS関連のエージェントが一貫したタイムゾーンになるよう、必要に応じていずれかのエージェントのタイムゾーンをリセットします。これは、ターゲットがエージェント間で移動される必要がある場合に重要です。
1. タイムゾーンをリセットする必要のある各エージェントに対して、エージェント・ホームから次の操作を実行します。
  
  echo $TZ
  
  <AGENT_HOME>/bin/emctl config agent getTZ
  
  <AGENT_HOME>/bin/emctl stop agent
  
  <AGENT_HOME>/bin/emctl resetTZ agent
2. sqlplusを介してリポジトリにログインし、emctl resetTZ agentコマンドの出力に示されるコマンドを実行します。
  
  <AGENT_HOME>/bin/emctl start agent
ステップ1を繰り返し、結果を確認して、今はタイムゾーンが一貫していることを確認します。

アップグレードおよび移行後のアクティビティの実行

アップグレードおよび移行後のアクティビティを実行するには、次のステップに従います。

ステップ1: 残りのアップグレード後アクティビティの確認および完了
ステップ2: (オプション)アップグレードおよび移行後のスイッチオーバー、パッチ適用およびプラグイン・デプロイメント・テストの実行
ステップ3: クリーンアップ

残りのアップグレード後アクティビティの確認および完了

この時点で、アップグレードおよび移行のプロセス固有のステップが完了しています。『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』で参照されるアップグレード後のアクティビティを確認して、環境で必要な残りのタスクが確実に完了しているようにします。特に、OMSサーバー以外のシステム上の管理エージェントのアップグレード、JVMDエージェントのアップグレード、およびカスタム証明書でのWebLogicの再構成などの環境に適した他のステップの実行などの、アップグレードおよび移行のプロセスの一環としてまだ達成されていないステップに注意を払います。

アップグレードおよび移行後のスイッチオーバー、パッチ適用およびプラグイン・デプロイメント・テストの実行

このステップは、テストまたは開発環境にあるアップグレードおよび移行された環境において信頼性を築くことを目的としています。これらのステップには停止時間が含まれ、デプロイする固有のパッチおよびプラグインを特定することを計画する必要があります。スイッチオーバーのテストは、未計画および計画された停止を防ぐためにスタンバイを正常に使用できるようにし、業務担当者が新しいスタンバイ構成およびスイッチオーバー・プロセスを熟知できるようにするために、問題が特定され解決されるよう、アップグレードおよび移行完了後の最初の適切なタイミングにスケジュールされることをお薦めします。

パッチ適用の考慮事項:

OMSPatcherを使用してパッチ適用を実行する際、別名ホスト名の構成に起因する、ホスト検証チェックを無効にするように次のプロパティを設定します。

OMSPatcher.OMS_DISABLE_HOST_CHECK=true

Oracleインベントリの考慮事項:

これでアップグレードおよび移行が完了したので、EM環境でメンテナンスを実行する際に考慮する必要のあるOracleインベントリの場所が、ローカル記憶域のOracleインベントリと、レプリケートされた記憶域のOracleインベントリの2セット存在します。このアップグレードおよび移行のプロセスでは、/etc/oraInst.locに配置された中央のOracleインベントリ・ポインタには変更を加えていません。このポインタは、レプリケートされた記憶域のOracleインベントリ、ローカル記憶域のOracleインベントリ、または場合によっては別のOracleインベントリでさえも参照する可能性があります。重要なのは、メンテナンス操作を実行する際に、特定のインストール済ソフトウェアに使用される必要のあるOracleインベントリに必ず気づくようにすることです。ローカル・エージェントなどのローカルにインストールされたソフトウェアに対する操作は、ローカル記憶域のOracleインベントリに対して実行される必要があります。OMSおよびOMSエージェントなどのレプリケートされた記憶域にインストールされたソフトウェアに対する操作は、現在どの物理ホストがソフトウェアをホストしているかにかかわらず、レプリケートされた記憶域にインストールされたソフトウェアを管理できるようにするため、レプリケートされた記憶域のOracleインベントリに対して実行する必要があります。

クリーンアップ

アップグレードおよび移行が成功したことが確実であるために、アップグレードおよび移行からフォールバックする必要はもうなく、ログ、構成または他の長期の参照情報が必要に応じて他の手段を介してコピーまたはバックアップされているときには、アップグレードおよび移行のプロセスの一環としてローカルおよびレプリケートされた記憶域に作成された、古いインストールに関連する一時ディレクトリ、バックアップ、ディレクトリなどを削除できます。

確認する領域のリストは次のとおりです。

プライマリOMS1で次のディレクトリを確認します。
1. agentDeploy.shを実行する前の名前変更されたエージェント・ベース・ディレクトリ
  
  <NEW_OMS_AGENT_BASE>/agent_inst.YYYYMMDD
  
  例:
  
  /u01/app/oracle/OMS/oms_agent/agent_inst.20160502
2. EM 13.4インストーラに使用されたステージング・ディレクトリ
  
  <UPGRADE_STAGING_DIR>
  
  例:
  
  /u01/app/oracle/OMS/stage
すべてのプライマリおよびスタンバイOMSサーバーで次のことを確認します。
1. アンインストールされたEMインストールのインスタンス・ベース・ディレクトリ。
  
  <OLD_INSTANCE_BASE>
  
  例:
  
  /u01/app/oracle/gc_inst
2. このアップグレードおよび移行のプロセス前またはプロセス中に作成されたバックアップ。
  
  <BACKUP_DIR>
  
  例:
  
  /u01/app/oracle/local/backup
3. EMソフトウェアおよび環境を参照する、cronなどを介したスケジュール済ジョブ。
  
  <BACKUP_DIR>
  
  例:
  
  crontab -l