| Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド 13c リリース3 E98554-01 |
|
 前 |
 次 |
この章では、記憶域レプリケーションDRアーキテクチャを使用して、スタンバイOMSを実装するためのベスト・プラクティスでEnterprise Manager環境をアップグレードする方法を説明します。
この章の具体的な内容は次のとおりです。
アプリケーションの仮想ホスト名に対して保護された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をデプロイできます。
レプリケートされた記憶域上のプライマリOMSに対してEnterprise Manager 13cソフトウェアをインストール
アップグレードされたEnterprise Manager 13cのプライマリOMSを別名ホスト名を使用するように構成
アップグレードされたEnterprise Manager 13cインストールをレプリケートされた記憶域の指定されたインベントリにアタッチ
「DR準備状況へのアップグレードおよび移行」プロセスは、インストーラ自体のコンテキスト外の相当の準備と追加手順が必要です。アップグレードおよび移行のプロセスの一環として必要とされる変更の度合は、記憶域レプリケーションDRアーキテクチャを使用するスタンバイOMSのベスト・プラクティスに既存のインストールが従う度合によって異なります。変更の度合いが最大になるのは、別名ホスト名の実装と、OMSおよびOMSエージェント(中央エージェント)の、ローカル記憶域上のインストールおよびインベントリから、レプリケートされた記憶域上のインストールおよびインベントリへの再配置です。構成変更のサブセットのみを必要とする環境に対応するため、このプロセスの変化形を実行できます。次の表に、各シナリオに該当するプロセスの概要を示します。
追加のOMSのデプロイに成功した後、WebLogicデモ証明書が再生成され、すべてのOMSサーバー上の別名ホスト名に反映され、OMS1上のEnterprise Manager 12c OMSからのバイナリがアンインストールされ、物理ホスト名エージェントがすべてのプライマリおよびスタンバイOMSサーバーにデプロイされます。
表5-1 アップグレード・モードでサポートされている移行
| 古いインストール | アップグレードされたインストール | 古いインベントリ | アップグレードされたインベントリ | 古いホスト名 | アップグレードされたホスト名 | アップグレード・モード |
|---|---|---|---|---|---|---|
ローカルまたはレプリケート |
レプリケート |
ローカル |
レプリケート |
物理 |
別名 |
DR準備状況へのアップグレードおよび移行 |
ローカルまたはレプリケート |
レプリケート |
ローカル |
レプリケート |
別名 |
同じ |
DR準備状況へのアップグレードおよび移行 |
ローカルまたはレプリケート |
レプリケート |
レプリケート |
同じ |
物理 |
別名 |
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.2にアップグレードされ、OMS1エージェントに対してエージェントのアップグレード後のクリーンアップが実行され、OMS1エージェントがローカル記憶域およびインベントリからレプリケートされた記憶域およびインベントリに再配置され、別名ホスト名を使用するためにOMS1エージェントを準備およびリカバリする手順が実行され、OMS1関連のターゲットがリカバリされた別名ホスト名エージェントに再配置されます。
エージェントとターゲットの再配置が完了すると、更新されたEnterprise Manager 13c SLB構成を使用するためにOMS1が再保護され、OMSとBI Publisherとの間の内部チャネルが構成され、遅延DDMPジョブが発行されます。DDMPジョブが完了すると、OMS1のアップグレードおよび移行が完了し、追加OMSのデプロイが開始します。別名ホスト名エージェントが、レプリケートされた記憶域上のインベントリとともに、レプリケートされた記憶域上の各追加OMSサーバーにデプロイされます。追加OMSが「Oracle Management Serviceの追加」デプロイメント・プロシージャを使用してデプロイされます。
追加のOMSのデプロイに成功した後、WebLogicデモ証明書が再生成され、すべてのOMSサーバー上の別名ホスト名に反映され、OMS1上のEnterprise Manager 12c OMSからのバイナリがアンインストールされ、物理ホスト名エージェントがすべてのプライマリおよびスタンバイOMSサーバーにデプロイされます。
注意:
関連する停止時間に対応できる開発環境およびテスト環境では、アップグレードおよび移行が成功したことを確認するため、新しいスタンバイOMSへの、および新しいスタンバイOMSからのスイッチオーバーを実行でき、さらに追加のパッチ適用および他のメンテナンス・テストも実行できます。スタンバイWebLogicドメイン・障害時リカバリ(DR)アーキテクチャを使用してスタンバイOMSで構成されたEnterprise Manager 12c リリース5 (12.1.0.5)、13c リリース1 (13.1.0.0)、または13c リリース2 (13.2.0.0)環境から、Enterprise Manager 13c リリース3 (13.3.0.0)にアップグレードし、記憶域レプリケーションDRアーキテクチャを使用してスタンバイOMSに移行するには、次の手順に従います。
この項では、アップグレードおよび移行を確実に成功させるために必要な準備手順について説明します。一般的なアプローチとして、このアップグレードおよび移行の準備は、アップグレードまたは他の負荷の大きいメンテナンス・アクティビティに対して実行する準備と同様であると考えます。それらのメンテナンス・アクティビティと同様に、アップグレードおよび移行のアクティビティを開始する前に環境が正常であることを確認することが重要です。
アップグレードおよび移行のプロセス全体を理解し、さらにこの項で使用される規則も理解することが重要です。この手順では次の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 12cの13c リリース3へのアップグレードとDR準備状況への移行を進める前に、必ず次のことを確認してください。
DR準備状況へのアップグレードおよび移行を実行するための前提条件は、標準のアップグレードを実行するための前提条件のスーパーセットです。Enterprise Manager Cloud Control 13cリリース3へのアップグレードの前提条件で指定された前提条件を確認、理解し、環境がそれを満たすようにします。この章で特に言及されていない前提条件が、インストーラを使用した実際のDR準備状況へのアップグレードおよび移行の開始前までに、適時アップグレードおよび移行プロセスで実行されるようにします。この章の手順では、OMSおよびOMSエージェントを停止するタイミングについて説明します。
障害時リカバリ構成では、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ドメインをアップグレードおよび移行のソースドメインとして使用しない。
レプリケートされた記憶域上のミドルウェア・ホーム、インスタンス・ベース、エージェント・ベースおよびOracleインベントリの場所の親ディレクトリである、OMSインストール・ベース・ディレクトリとして使用するディレクトリを特定します。OMSインストール・ベース・ディレクトリは、レプリケートされた記憶域のマウント・ポイントとして機能できます。この章で説明するOMSインストール・ベース・ディレクトリの構成例は/u01/app/oracle/OMSで、変数<OMS_MOUNT_POINT>として示されます。
OMSインストール・ベース・ディレクトリの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のOracle Management Serviceの高可用性に関する項を参照してください。
別名ホスト名への移行の一環として、物理ホスト名のかわりに別名ホスト名のFQDNを反映するために、各OMSでWebLogic Server証明書が更新される必要があります。アップグレードおよび移行のプロセスには、デフォルトのWebLogic Serverデモ証明書に対してこれらの更新を実行するのに必要な手順が含まれています。カスタムのWLS証明書の更新に必要な手順は含まれていません。
カスタムのWLS証明書の詳細は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』のWebLogic Serverのカスタム証明書の構成に関する項を参照してください。
WLSにカスタム証明書を使用する場合、続行する前に、必要な証明書を取得しており、アップグレードおよび移行のプロセスにおいて適切な時点で更新を実行するために必要な手順を理解していることを確認します。
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高可用性の構成を参照してください。
各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およびスタンバイ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サーバーと通信できることを確認します。
詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「オプション2 - ホスト名計画時の両サイトの別名ホスト名」を参照してください。
レプリケートされた記憶域へのアップグレードおよび移行の一環として、OMSおよびOMSエージェント・ソフトウェアはOMSインストール・ベース・ディレクトリの下にあるレプリケートされた記憶域上のOracleインベントリに関連付けられる必要があります。アップグレードが完了したら、OMSおよびOMSエージェントのすべてのメンテナンスにこのOracleインベントリの場所を使用して、どのサイトが現在アクティブのサイトとして機能していてもソフトウェア・メンテナンスを実行できるようにすることが重要になります。
レプリケートされた記憶域に配置されたOracleインベントリ・ディレクトリを作成し、プライマリOMS1のそのディレクトリにoraInst.locインベントリ・ロケーション・ポインタ・ファイルを作成します。インベントリ・ロケーション・ポインタ・ファイルは、レプリケートされた記憶域上のインベントリに、アップグレードされたソフトウェアが関連付けられるよう、インストーラを起動してアップグレードを実行する際に使用されます。
詳細は、Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイドの「OMSインストール・ベース・ディレクトリ配下のOracleインベントリの構成」を参照してください。
アップグレードの準備としてEnterprise Manager 13cインストール・ソフトウェアをプライマリOMS1サーバーのディレクトリにステージングします。
OHSのローカル・ロック・ファイルの格納に使用できるローカル記憶域に配置され、Oracleソフトウェア所有者ユーザーに所有されるディレクトリを作成または特定し、すべてのプライマリおよびスタンバイOMSサーバー上でそのディレクトリを一貫して構成します。以降の手順で、ローカル・ロック・ファイル格納用にこのディレクトリを使用するよう各OMSを構成することになります。
スタンバイOMSおよびOMSエージェントの削除は次の手順で実行します。
手順2: 最初のスタンバイOMSの削除
すべての追加スタンバイOMSインスタンスを削除するには、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの追加スタンバイOMSインスタンスの削除に関する項を参照してください。
最初のスタンバイOMSを削除するには、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの最初のスタンバイOMSの削除に関する項を参照してください。
注意:
この時点では追加OMSおよびOMSエージェントのみが削除されるため、この項の手順はOracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「OMSのみをアンインストールし管理リポジトリを保持するための前提条件」の手順のサブセットになります。プライマリの追加OMSおよび追加OMSエージェントを削除するには、次の手順に従います。
プライマリ・サイトのすべての追加OMSを削除するには、各プライマリの追加OMSについて、個別に追加OMSを順に停止および削除する必要があります。
各プライマリの追加OMSについて追加OMSを停止および削除するには、次の手順に従います。
環境がアップグレードおよび移行のプロセス用に準備されていること。アップグレードおよび移行のプロセスについて前に示したすべての手順が完了していること。
Enterprise Manager Cloud Control 13cリリース3へのアップグレードの前提条件に示された前提条件を満たしていること。
続行する前にプライマリOMS1およびプライマリOMS1エージェントが停止していること。
次の手順を使用して、OMS1およびリポジトリのアップグレードおよび移行を実行します。
OMS1およびリポジトリをアップグレードおよび移行するには、プライマリOMS1で次の手順に従います。
手順1: DR準備状況にアップグレードおよび移行するためのEnterprise Manager Cloud ControlインストーラのGUIモードでの起動
手順3: 最新のソフトウェア更新の適用
手順4: 前提条件チェックの実行および環境の検証
手順5: インストール・タイプの選択
手順7: データベース接続の詳細の指定
手順9: 追加のプラグインのデプロイ
手順12: ポートの構成
手順13: アップグレードの詳細の確認
手順14: アップグレードの進捗のモニタリング
手順15: アップグレードの終了
管理リポジトリ、OMS、インベントリ、ソフトウェア・ライブラリおよびEnterprise Managerの動作に不可欠なその他のコンポーネントをバックアップすることを強くお薦めします。これによって、アップグレードに失敗した場合に、元の内容に戻すことができます。
既存のOMS1が実行されているホストで、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。
./em13300_<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>例:
./em13300_linux64.bin -invPtrLoc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=emoms1.domain.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>
(オプション)「My Oracle Supportの詳細」画面でMy Oracle Support資格証明を入力してOracle Configuration Managerを有効にし、「次」をクリックします。今はOracle Configuration Managerを有効にしない場合、詳細を何も入力せずに「次」をクリックして最新のソフトウェア更新の適用に進みます。
インストール・ウィザードを実行しているホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールの完了後、構成情報を手動で収集し、My Oracle Supportにアップロードしてください。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
「ソフトウェアの更新」画面で、最新のPSUパッチを含む、最新のソフトウェア更新を適用して「次」をクリックします。
ソフトウェア更新は、オフライン・モード(インターネット接続がない場合)またはオンライン・モード(インターネット接続がある場合)でダウンロードできます。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
「前提条件チェック」画面で、インストール・ウィザードによって実行された前提条件チェックのステータスを確認し、環境がアップグレード成功のためのすべての最小要件を満たしているかどうかを確認します。次に、「次」をクリックします。
インストール・ウィザードでは、この画面に達すると前提条件チェックが自動的に実行されます。前提条件チェックのステータスは、「警告」、「失敗」、「成功」、「未実行」、「進行中」または「保留」です。
「警告」または「失敗」 ステータスになったチェックがある場合は、アップグレードを続行する前に問題を調査して修正してください。前提条件を満たさなかった理由と解決方法の詳細が画面に表示されます。問題を修正した後、この画面に戻り、「再実行」をクリックして前提条件を再度チェックします。
「データベース接続の詳細」ページで、「DDMPジョブを無効にします」を選択し、データベース接続の詳細の指定の以降の手順に従います。DDMPジョブは、後にアップグレードおよび移行のプロセスで発行されます。
「プラグイン・アップグレード」画面で、次の影響のいずれかを受けるプラグインを確認して「次」をクリックします。
新しいバージョンが存在する場合にアップグレード
新しいバージョンが存在しない場合に移行
アップグレード対象のプラグインに新しい依存関係が存在する場合またはリリースで導入された新しいデフォルト・プラグインがある場合は、デプロイ済。
ここで、新しいバージョンとは、インストールに使用するEnterprise Managerソフトウェア(DVDまたはダウンロードしたソフトウェア)で提供されているプラグインの新しいバージョンを指します。
注意:
13cリリース3でのみサポートされ、将来のリリースではサポートされないプラグイン・バージョンにアップグレード可能な非推奨のプラグインが環境にある場合があります。そのような非推奨のプラグインがこのアップグレードの画面でデフォルトで選択されている場合、選択内容を確認し、そのようなプラグインのアップグレードを続行するかどうかを決めるよう求められます。
注意:
次の画面に進む前に、次のコマンドを実行して関連するOMSインスタンスすべてを停止します。<ORACLE_HOME>はOMSのOracleホームです。
$<ORACLE_HOME>/bin/emctl stop oms -all
注意:
新しいバージョンが、使用するEnterprise Managerソフトウェアに存在しないが、Oracle Technology Network (OTN)には存在する場合、既存のプラグインをデフォルトで自動的に移行するかわりに、新しいバージョンをOTNから手動でダウンロードして既存のプラグインをアップグレードすることもできます。次の手順を実行します。
必要なプラグインを次の場所から手動でダウンロードします。
http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/oem-plugins-2882950.html
さらに、パートナまたは顧客のプラグインをダウンロードする場合は、次の場所からダウンロードします。
次のオプションを指定してインストーラを起動し、追加のプラグインがダウンロードされている場所を渡します。
UNIXプラットフォームの場合:
./em13300_<platform>.bin PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
Microsoft Windowsプラットフォームの場合:
setup_em13300_win64.exe PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
ここには、ソフトウェア・キット(DVD、ダウンロードしたソフトウェア)で使用可能なプラグインや、このカスタムの場所で使用可能なプラグインの一覧が表示されます。インストールするものを選択できます。
プラグインの新しいバージョンが利用できるようになると、この画面にはそのプラグインが、自動的にアップグレードされるプラグインとしてリストされます。
OMSまたは管理エージェントの一部にサポートされていないプラグインがあるというメッセージが表示された場合は、メッセージの説明に従ってプラグインをアップグレードし、OMSのアップグレードを再試行します。
「プラグインの選択」画面で、OMSのアップグレード中に自動的にアップグレードされるプラグイン以外にデプロイするオプション・プラグインを選択し、「次」をクリックします。
注意:
13cリリース3でのみサポートされ、将来のリリースではサポートされない非推奨のプラグインを選択した場合、選択内容を確認し、そのプラグインのデプロイメントを続行するかどうかを決めるよう求められます。
注意:
この画面にリストされていないプラグインをインストールする場合は、次の手順に従います。
必要なプラグインを次の場所から手動でダウンロードします。
http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/oem-plugins-2882950.html
さらに、パートナまたは顧客のプラグインをダウンロードする場合は、次の場所からダウンロードします。
次のオプションを指定してインストーラを起動し、追加のプラグインがダウンロードされている場所を渡します。
UNIXプラットフォームの場合:
em13300_<platform>.bin INSTALL_SWONLY_WITH_PLUGINS=true PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
Microsoft Windowsプラットフォームの場合:
setup_em1330_win64.exe INSTALL_SWONLY_WITH_PLUGINS=true PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
ここには、ソフトウェア・キット(DVD、ダウンロードしたソフトウェア)で使用可能なプラグインや、このカスタムの場所で使用可能なプラグインの一覧が表示されます。インストールするものを選択できます。
「WebLogic Serverドメインの拡張」ページで、既存のWebLogic Serverドメインの拡張に示された手順に従います。
注意:
「管理サーバー・ホスト」は依然としてOMS1の物理ホスト名を示しています。管理サーバーはOMS1別名ホスト名をこのアップグレードのモードの一部として使用するよう更新されるため、これで問題ありません。
OMSインスタンス・ベースの場所がレプリケートされた記憶域にあることを確認します。レプリケートされた記憶域がOMSインストール・ベース・ディレクトリまたはOMSインストール・ベース・ディレクトリの上に構成され、ミドルウェア・ホームがOMSインストール・ベース・ディレクトリの下にある場合、OMSインスタンス・ベースの場所はデフォルトでミドルウェア・ホームのピア・ディレクトリとなるため、変更する必要はありません。たとえば、/u01/app/oracle/OMS/gc_instです。
マウント・ポイントがNFSマウントされた記憶域を使用する場合、ロック・ファイル・ディレクトリをローカル記憶域に配置するように警告メッセージが表示されます。アップグレードおよび移行のプロセスのアップグレード後手順で、httpロック・ファイルはアップグレードの完了後にローカル記憶域のディレクトリに配置されます。
「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
注意:
NFSマウントされたドライブを設置し、OMSインスタンス・ベース・ディレクトリ(gc_inst)をNFSマウントされたドライブに作成した場合、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。これを行うには、httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。OMS1エージェントをDR準備状況に移行するには次の手順に従います。
OMS1エージェントをEnterprise Manager 13cリリース3にアップグレードするには、各手順に示されたコマンドを使用して次の手順を実行します。
13c管理エージェントのアップグレードの確認の手順に従って、OMS1エージェントがEnterprise Manager 13c リリース3へのアップグレードに成功したことを確認します。
OMS1エージェントがEnterprise Manager 13cリリース3へのアップグレードに成功したことを確認した後、古い管理エージェントのアップグレード後クリーンアップの実行の手順に従って、以前のバージョンのOMS1エージェント・インストールをクリーンアップします。
OMS1エージェントをローカルのOracleインベントリに登録されたローカル記憶域上の場所から、レプリケートされた記憶域のOracleインベントリに登録されたレプリケートされた記憶域上の場所に再配置するには、各手順に示されたコマンドを使用して次の手順を実行します。
注意:
これらの手順は、中央エージェントのベース・ディレクトリのOracleミドルウェア・ホーム外への移動の手順に基づいています。ただし、このドキュメントの手順以外の、新しい場所に対して異なるOracleインベントリを使用するためにコマンドに指定する必要のある追加パラメータがあることに注目することが大切です。OMS1エージェントは、OMS1エージェントを別名ホスト名で構成するために、レプリケートされた記憶域上の既存のインストールを使用します。別名ホスト名を使用してOMS1エージェントを再デプロイする準備をするには、各手順に示されたコマンドを使用して次の手順を実行します。
物理ホスト名のかわりに別名ホスト名を使用してOMS1エージェントを再デプロイするには、各手順に示されたコマンドを使用して次の手順を実行します。
物理ホスト名エージェントに関連付けられた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を再保護するには、次の手順に従います。
Enterprise Manager 13.1以降では、Oracle Management ServiceからBI Publisherへの通信がSLBを通るように構成できます。これによって、この通信を必要とするすべてのオペレーションが確実にSLBを経由するようになります。
内部チャネルの詳細は、Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「BI Publisherにアクセスするためのパス」を参照してください。
内部チャネルをBI Publisher用に構成するには、次の手順に従います。
DDMPジョブは、以前に「データベース接続の詳細」ページで「DDMPジョブを無効にします」オプションが選択されたときのアップグレード中に無効にされています。DDMPジョブの詳細は、遅延データ移行ジョブのステータスの追跡を参照してください
DDMPジョブを発行するには、次の手順に従います。
Not Startedを示す必要があります。新しいプライマリの追加OMS別名ホスト名エージェントと追加OMSを追加するには、次の手順に従います。
Enterprise Managerで、エージェントを各プライマリの追加OMSサーバーの別名ホスト名にデプロイします。Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドの「ホスト・ターゲットの追加ウィザードを使用したスタンドアロン管理エージェントのインストール」の手順に従う際に、次の情報を確認し、この情報を使用します。
Enterprise Managerで、各プライマリの追加OMSサーバーの別名ホスト名エージェントを使用して、追加のOMSを1つずつデプロイします。Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドの「Oracle Management Serviceの追加」の手順に従う際に、次の情報を確認し、この情報を使用します。
プライマリおよびスタンバイ・サイト構成をファイナライズするには、次の手順に従います。
サイトがデモンストレーションWebLogic証明書を使用している場合に、WebLogicの通信が確実に両方のサイトで適切に機能するようにするには、証明書を別名ホスト名で再作成する必要があります。Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの「別名ホスト名を反映するためのデモンストレーション・キーストアの更新」の手順に従います。
プライマリOMS1サーバー上のEnterprise Manager 12c OMSのバイナリをアンインストールするには、中央エージェントが古いミドルウェア・ホーム外の場所に移行されている場合の古いOMSホームの削除を参照してください。
Enterprise Managerで、エージェントを各プライマリおよびスタンバイOMSサーバーの物理ホスト名にデプロイします。Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドの「ホスト・ターゲットの追加ウィザードを使用したスタンドアロン管理エージェントのインストール」の手順に従う際に、次の情報を確認し、この情報を使用します。
すべてのOMSノード上のエージェントに正しいタイムゾーン構成があることを確認するには、次の手順に従います。
アップグレードおよび移行後のアクティビティを実行するには、次の手順に従います。
手順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で次のディレクトリを確認します。
agentDeploy.shを実行する前の名前変更されたエージェント・ベース・ディレクトリ
<NEW_OMS_AGENT_BASE>/agent_inst.YYYYMMDD
例:
/u01/app/oracle/OMS/oms_agent/agent_inst.20160502
EM 13.2インストーラに使用されたステージング・ディレクトリ
<UPGRADE_STAGING_DIR>
例:
/u01/app/oracle/OMS/stage
すべてのプライマリおよびスタンバイOMSサーバーで次のことを確認します。
アンインストールされたEM 12cインストールのインスタンス・ベース・ディレクトリ。
<OLD_INSTANCE_BASE>
例:
/u01/app/oracle/gc_inst
このアップグレードおよび移行のプロセス前またはプロセス中に作成されたバックアップ。
<BACKUP_DIR>
例:
/u01/app/oracle/local/backup
EM 12cソフトウェアおよび環境を参照する、cronなどを介したスケジュール済ジョブ。
<BACKUP_DIR>
例:
crontab -l
