ヘッダーをスキップ
Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド
12cリリース1(12.1.0.1)
B65086-03
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

2 アップグレード方式の概要

エンタープライズ全体にわたって様々な組合せでEnterprise Managerをデプロイする選択肢がある場合、環境全体をアップグレードすることは、様々なホストに配置された様々なレベル(層)のソフトウェアおよび構成のアップグレードを伴う、非常に複雑な作業になります。さらに、ゼロに近い停止時間で、または監視の欠如を最低限に抑えて環境をアップグレードするうえでの課題もあります。

これらの課題を考慮して、要件を最も満たす方式を選択する柔軟性を提供するだけではなく、シームレスでエラーのないように全体のアップグレード操作を簡略化するアップグレード・オプションが用意されています。

この章では、これらのアップグレード方式の概要を説明します。この章の具体的な内容は次のとおりです。

アップグレード方式の概要

既存のEnterprise Managerシステムをアップグレードするために、次のアップグレード方式が用意されています。

表2-1は3種類のアップグレード方式の違いをまとめたものです。

表2-1 アップグレード方式の違い

1システムのアップグレード方式 2システムのアップグレード方式 異なるホストでの1システムのアップグレード方式

OMSと管理リポジトリのアップグレードにのみ焦点を当てた従来の方式とは異なり、OMSおよび管理リポジトリをアップグレードする前に、管理エージェントの事前デプロイ操作とスイッチオーバーを行います。

フレッシュ・インストールと同様です。

フレッシュ・インストールと同様です。

ある程度の停止時間が必要です。

(基本的に、管理エージェントをスイッチオーバーしてからOMSをアップグレードするまで停止します)。

停止時間は必要最低限に抑えられるか、または停止時間は必要ありません。

ある程度の停止時間が必要です。

旧リリースのEnterprise Managerを実行しているホストでEnterprise Manager Cloud Controlにアップグレードします。

既存のEnterprise Managerシステムを実行していないホストにEnterprise Manager Cloud Controlをインストールします。

既存のEnterprise Managerを実行していないホストにEnterprise Manager Cloud Controlをインストールしますが、既存のデータベース自体の管理リポジトリをアップグレードします。

同一のホストでアップグレードされるため、ハードウェア・リソースを追加する必要はありません。

異なるホストにインストールされるため、ハードウェア・リソースの追加が必要です。

異なるホストにインストールされるため、ハードウェア・リソースの追加が必要です。

アップグレード後のEnterprise Managerシステムに構成情報をコピーして新しいシステムに引き継げるように、既存のEnterprise Managerシステムを停止する必要があります。

管理エージェントの旧リリースがすべて、新しくアップグレードされた環境にスイッチオーバーされるまで、既存のEnterprise Managerシステムは実行を継続できます。

新しいシステムに構成情報をコピーして新しいシステムに引き継げるように、既存のEnterprise Managerシステムを停止する必要があります。

OMSおよび管理リポジトリをアップグレードする前に、管理エージェントをデプロイし、構成する必要があります。

OMSおよび管理リポジトリをアップグレードするまたはで、管理エージェントをデプロイし、構成することができます。

OMSおよび管理リポジトリをアップグレードする前に、管理エージェントをデプロイし、構成する必要があります。

管理エージェントはインクリメンタルまたは段階的な方法、つまりグループでデプロイし、構成できます。

管理エージェントはインクリメンタルまたは段階的な方法、つまりグループでデプロイし、構成できます。

管理エージェントはインクリメンタルまたは段階的な方法、つまりグループでデプロイできます。

OMSおよび管理リポジトリをアップグレードする前に、管理エージェントをスイッチオーバーする必要があります。

OMSおよび管理リポジトリをアップグレードした後で、管理エージェントをスイッチオーバーする必要があります。

OMSおよび管理リポジトリをアップグレードする前に、管理エージェントをスイッチオーバーする必要があります。

既存の認証済データベース自体の管理リポジトリをアップグレードします。

バックアップしたデータベースの管理リポジトリをアップグレードします。したがって、前提条件として、既存のOracle Databaseをバックアップする必要があります。

既存の認証済データベース自体の管理リポジトリをアップグレードします。

ポートやファイアウォールの設定を変更する必要はありません。アップグレード後の管理エージェントおよびOMSは、アップグレード前と同じポートを使用します。

ポートやファイアウォールの設定を一部変更する必要があります。アップグレード後の管理エージェントは、アップグレード前と同じポートを使用します。ただし、リモート・ホストにインストールされた管理エージェントとOMSは新しいポートを使用する可能性があります。

複数OMS環境では、サーバー・ロード・バランサ(SLB)を使用している場合、新しい管理エージェントとOMSのために同じSLBに新しいポートを開くか、またはまったく新規にSLBを構成することができます。

ポートやファイアウォールの設定を一部変更する必要があります。アップグレード後の管理エージェントは、アップグレード前と同じポートを使用します。ただし、リモート・ホストにインストールされた管理エージェントとOMSは新しいポートを使用する可能性があります。

複数OMS環境では、サーバー・ロード・バランサ(SLB)を使用している場合、新しい管理エージェントとOMSのために同じSLBに新しいポートを開くか、またはまったく新規にSLBを構成することができます。

デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。

デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。

デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。

実行中のジョブは、停止時間の開始時に中止されます。

実行中のジョブは、バックアップの開始後、既存のEnterprise Managerシステムで引き続き実行されます。Enterprise Manager Cloud Controlでは、これらのジョブは中止された、または失敗したように見えます。

実行中のジョブは、停止時間の開始時に中止されます。

スケジュール済のジョブは、猶予期間に余裕があれば、停止時間の終了後に実行されます。それ以外の場合は省略されます。

スケジュール済のジョブはバックアップ時間から、ターゲットの管理エージェントがEnterprise Manager Cloud Controlに移行されるまで、既存のEnterprise Managerシステムで実行されます。管理エージェントの移行後は、このジョブはEnterprise Manager Cloud Controlで実行されます。

スケジュール済のジョブは、猶予期間に余裕があれば、停止時間の終了後に実行されます。それ以外の場合は省略されます。

繰返しジョブは、停止時間後、次にスケジュールされた時刻に実行されます。繰返しジョブの時間が停止時間と重なる場合、その実行は省略されます。

繰返しジョブは、既存のEnterprise Manageシステムでのスケジュールに従って引き続き実行されます。管理エージェントの移行後、ジョブはEnterprise Manager Cloud Controlで実行されます。

繰返しジョブは、停止時間後、次にスケジュールされた時刻に実行されます。繰返しジョブの時間が停止時間と重なる場合、その実行は省略されます。



注意:

ジョブは既存のEnterprise Managerシステム、またはEnterprise Manager Cloud Controlで実行されます。両方のシステムで実行されることはありません。ジョブの本当の状態は、そのジョブが実際に実行されていたシステムでのみ確認できます。詳細は、付録Cを参照してください。また、すべてのターゲットで使用されるすべての管理エージェントを同時に移行しないかぎり、複数のターゲットを使用したジョブはどちらのシステムでも実行されません。

アップグレード・ユーティリティの概要

アップグレード方式の1つを選択し、アップグレード操作全体をシームレスに編成して、データ移行プロセスなどのアップグレード後アクティビティを追跡できるようにするために、次のユーティリティが用意されています。

アップグレード後コンソール

Enterprise Manager 12cアップグレード・コンソールは、Enterprise Manager 10g Grid Controlリリース5(10.2.0.5.0)またはEnterprise Manager 11g Grid Controlリリース1(11.1.0.1.0)をEnterprise Manager Cloud Controlにアップグレードするための主要なユーザー・インタフェースであり、開始点でもあります。

Enterprise Manager 12cアップグレード・コンソールにより、適切なアップグレード方式の選択、Oracle Management Agent 12cソフトウェアの事前デプロイ、および管理エージェントの旧リリースから新たに事前デプロイされた管理エージェントへのスイッチオーバーができるようになります。


注意:

Oracle Management Service 12cは、Oracle Management Agent 12cとのみ通信します。したがって、旧リリースとは異なり、既存のOMSをアップグレードする前に、まず、使用しているシステムの管理エージェントをアップグレードする必要があります。このため、Enterprise Manager 12cアップグレード・コンソールはアップグレード・プロセスの開始点となるのです。

Enterprise Manager 12cアップグレード・コンソールアクセスするには、既存のEnterprise Managerシステムにアップグレード前コンソール・パッチを適用します。ダウンロードしてプラットフォームに適用する必要があるパッチの詳細は、次のURLにアクセスしてください。

http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

パッチのダウンロード後、このパッチにパッケージ化されているReadMeの指示に従って操作します。パッチを適用するには、必ず最新のOPatchリリースを使用してください。パッチの適用後、Enterprise Manager 12cアップグレード・コンソールにアクセスするために、スーパー管理者権限でログインします。


重要:

  • パッチを適用するには、OMSを停止する必要があります。この結果、パッチ操作が完了するまで、使用しているEnterprise Managerシステムは停止します。

  • パッチを適用しても、デプロイ・ページにEnterprise Manager 12cアップグレード・コンソールへのハイパーリンクが表示されない場合は、次の手順を実行します。

    1. 次の場所からjsp_servletディレクトリを移動します。

      $<OMS_INSTANCE_BASE>/user_user_projects/domains/GCDomain/generated_classes

    2. OMSホームからOMSを停止します。

      $<OMS_HOME>/bin/emctl stop oms

    3. OMSホームからOMSを再開します。

      $<OMS_HOME>/bin/emctl start oms


提供される機能は次の図に明確に表されています。

コンソールのアップグレード

注意:

アップグレードをサポートする旧リリースには、Oracle Management Agent 10gリリース2(10.2.x.x.x)、Oracle Management Agent 11gリリース(111.1.0.1.0)、Oracle Management Service 10gリリース5 (10.2.0.5.0)およびOracle Management Service 11gリリース1(11.1.0.1.0)が含まれます。

インストール・ウィザード

Enterprise Manager Cloud Controlインストール・ウィザードは、実行するアップグレード方式の選択、および既存のOMSと管理リポジトリのアップグレードを可能にする主要なユーザー・インタフェースです。

提供される機能は次の図に明確に表されています。

install_wiz.gifは前後のテキストで説明されています。

アップグレード後コンソール

アップグレード後コンソールは、発生データ移行ジョブや遅延データ移行ジョブを含むアップグレード後のアクティビティすべてを追跡するための主要なユーザー・インタフェースです。さらに、差分レポートを生成し、アップグレード後のEnterprise Managerシステムで現在アクティブでないターゲットのリストを表示することができます。

提供される機能は次の図に明確に表されています。

postupg_console.gifは前後のテキストで説明されています。

注意:

これらのジョブに関する詳細は、第26章第27章第28章、および第29章を参照してください。

アップグレード・プロセスの概要

この項では、それぞれのアップグレード方式について、実行されるおおよそのフローまたはシーケンスについて説明します。特に、次の項目について説明します。

1システム・アップルグレード・プロセス

次の図は、1システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。

1システム・アップグレード

Enterprise Manager 12cアップグレード・コンソールを使用して、Oracle Management Agent 12cソフトウェアをデプロイし、古い管理エージェントから新たにデプロイされた管理エージェントへスイッチオーバーすることができます。デプロイスイッチオーバーはどちらも管理エージェントのインストールとアップグレードを処理しますが、これらはまったく異なる操作であることがわかるでしょう。


注意:

最良の慣例として、スイッチオーバー操作を開始するかなり前に、デプロイ操作を完了しておくことをお薦めします。

デプロイ操作では管理エージェントのソフトウェア・バイナリがコピーされ、ホスト上でこれらの構成が行われますが、スイッチオーバー操作では古い管理エージェントが停止され、Enterprise Manager Cloud Controlで連携するように新しい管理エージェントが起動されます。

ソフトウェア・バイナリのコピーとホスト上での構成の間、既存のEnterprise Managerシステムが停止されないこと、または動作が妨げられないことを保証するために、これら2つの操作は区別され、異なるエンティティとして扱われます。いったんコピーされ、構成されたソフトウェア・バイナリは、より迅速にスイッチオーバーできるようになります。これは、古い管理エージェントを停止し、新しい管理エージェントを起動するための時間しか、この操作にはかからないためです。

管理エージェントのスイッチオーバーが完了すれば、OMSと管理リポジトリをアップグレードできるようになります。


注意:

最良の慣例として、スイッチオーバー操作の完了後、ただちにOMSをアップグレードすることもお薦めします。1システム・アップグレード方式での停止時間は、基本的に管理エージェントをスイッチオーバーしたときから、OMSをアップグレードするときまで続くということに注意してください。したがって、アップグレード操作が遅れれば遅れるほど、停止時間が長くなります。この停止時間中、監視されるターゲットはなく、OMSにアップロードされる監視データもありません。

インストール・ウィザードを使用して、ホスト上のEnterprise Manager Cloud Controlをアップグレードする場合、インストール・ウィザードはデフォルトで次の操作を実行します。

  • OMSおよび管理エージェントのアップグレード

  • Oracle WebLogic Server 11gリリース1(10.3.5)およびJava Development Kit 1.6 v24(JDK)をインストールします。また、oracle_commonディレクトリを含むOracle JRF 11gリリース(11.1.1.4.0)、およびOracle_WTディレクトリを含むOracle Web Tier 11gリリース(11.1.1.4.0)もインストールします。


    注意:

    Oracle WebLogic Server 11gリリース1(10.3.5)およびJDK 1.6 v24は、使用環境内に存在しない場合にのみインストールされます。サポートされているバージョンまたはそれ以降に、これらがすでに存在する場合は自動的に検出され、インストール場所のミドルウェア・ホームが表示されます。この場合、このミドルウェア・ホームのパスを確認するだけですみます。

  • 次のプラグインをインストールします。

    • Oracleデータベース管理プラグイン

    • Oracle Fusion Middleware管理プラグイン

    • Oracle My Oracle Support管理プラグイン

    • Oracle Exadata管理プラグイン

    • Enterprise Manager 12cアップグレード・コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたその他のプラグイン(これらのプラグインがソフトウェア・キットに含まれている場合)

  • アップグレードする旧リリースのEnterprise Managerシステムに応じて、Oracle WebLogicドメイン、管理サーバー、ノード・マネージャおよび管理対象サーバーを作成または再利用します。

    • Enterprise Manager 10g Grid Controlリリース5(10.2.0.5.0)からアップグレードする場合、デフォルトで次のものが作成されます。

      • GCDomainと呼ばれるOracle WebLogicドメインは、Enterprise Manager Cloud Controlの構成中に自動的に作成されます。このWebLogicドメインでは、デフォルトのユーザー・アカウントweblogicが管理ユーザーとして使用されます。これは、必要に応じてインストーラで変更することもできます。

      • Enterprise Manager Cloud Controlの構成中に、nodemanagerという名前のノード・マネージャ・ユーザー・アカウントが自動的に作成されます。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

    • Enterprise Manager 11g Grid Controlリリース1(11.1.0.1.0)からアップグレードする場合、旧Enterprise Managerシステム用に作成されたOracle WebLogicドメインおよびノード・マネージャが新しいシステムで再利用されます。

  • ウィザードに入力されたミドルウェア・ホームにOMSインスタンス・ベース・ディレクトリ(gc_inst)を作成し、OMSに関連するすべての構成情報を保存します。

  • 次の構成アシスタントを実行して、インストールまたはアップグレードされたコンポーネントを構成します。

    • プラグイン前提条件チェック

    • リポジトリ・アップグレード・アシスタント

    • MDSスキーマ・コンフィギュレーション・アシスタント

    • OMSコンフィギュレーション・アシスタント

    • プラグイン・デプロイおよびコンフィギュレーション・アシスタント

    • Oracle Management Serviceの起動

    • プラグイン・インベントリ移行

    • Oracle Configuration Managerリピータ構成アシスタント

    • OMS対応Oracle Configuration Manager


注意:

インストーラにより、既存の管理エージェントがアップグレードされることはありません。これは管理エージェントがEnterprise Manager 12cアップグレード・コンソールにより事前デプロイされているからです。

2システム・アップルグレード・プロセス

次の図は、2システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。

2システム・アップグレード

インストーラを使用してターゲット・ホストでEnterprise Manager Cloud Controlをインストールおよび構成する場合、デフォルトで次の処理が自動的に実行されます。

  • インストール・ウィザードで入力したミドルウェア・ホームの場所に次のコンポーネントをインストールします。

    • Java Development Kit (JDK) 1.6 v24

    • Oracle WebLogic Server 11gリリース1(10.3.5)

    • Oracle Management Service 12c

    • Oracle Management Agent 12c

    • Oracle JRF 11gリリース(11.1.1.4.0)(oracle_commonディレクトリを含む)

    • Oracle Web Tier 11gリリース(11.1.1.4.0)(Oracle_WTディレクトリを含む)

    • Oracle Management Plug-Ins

      • Oracleデータベース管理プラグイン

      • Oracle Fusion Middleware管理プラグイン

      • Oracle My Oracle Support管理プラグイン

      • Oracle Exadata管理プラグイン

      • Enterprise Manager 12cアップグレード・コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたその他のプラグイン(これらのプラグインがソフトウェア・キットに含まれている場合)


        注意:

        Oracle WebLogic Server 11gリリース1(10.3.5)およびJDK 1.6 v24は、使用環境内に存在しない場合にのみインストールされます。サポートされているバージョンまたはそれ以降に、これらがすでに存在する場合は自動的に検出され、インストール場所のミドルウェア・ホームが表示されます。この場合、このミドルウェア・ホームのパスを確認するだけですみます。

  • GCDomainと呼ばれるOracle WebLogicドメインを作成します。このWebLogicドメインでは、デフォルトのユーザー・アカウントweblogicが管理ユーザーとして使用されます。これは、必要に応じてインストーラで変更することもできます。

  • nodemanagerと呼ばれるノード・マネージャのユーザー・アカウントを作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

  • Oracle Management Service 12cに関連するすべての構成の詳細を格納するために、ミドルウェア・ホーム内のOMSインスタンス・ベースの場所を構成します。これは、必要に応じてインストーラで変更することもできます。

    たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/Middleware/gc_instです。これは、必要に応じてインストーラで変更することもできます。

  • 次の構成アシスタントを実行して、インストールまたはアップグレードされたコンポーネントを構成します。

    • プラグイン前提条件チェック

    • リポジトリ・アップグレード・アシスタント

    • MDSスキーマ構成

    • OMS構成

    • プラグイン・デプロイおよび構成

    • Oracle Management Serviceの起動

    • プラグイン・インベントリ移行

    • Oracle Configuration Managerリピータ構成

    • OMS対応Oracle Configuration Manager

    • エージェント・コンフィギュレーション・アシスタント

  • OMSを保護するために、内部的にパスワードを生成します。このパスワードはOMSコンフィギュレーション・アシスタントにより生成され、生成後、30日目で有効期限が切れます。

    OMSコンフィギュレーション・アシスタント、またはプラグイン・デプロイおよびコンフィギュレーション・アシスタントに失敗した場合は、必ず30日以内に問題を解決してください。解決しなかった場合、エージェント・コンフィギュレーション・アシスタントの実行中に管理エージェントの保護でエラーが発生します。

    30日以内に問題を解決できない場合、管理エージェント・ホームから次のコマンドを実行します。

    $<AGENT_HOME>/sysman/install/agentDeploy.sh OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_upload_https_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password>

異なるホスト上での1システム・アップグレード・プロセス

次の図は、異なるホスト上で1システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。

one_sys_on_diff_host.gif

図のように、この方式は1システム・アップグレード方式と2システム・アップグレード方式を組み合せたものです。1システム・アップグレード方式と同様、まず、管理エージェントの事前デプロイとスイッチオーバーからアップグレード・プロセスを開始します。その後、2システム・アップグレード方式のように、リモート・ホストにEnterprise Manager Cloud Controlをインストールします。ただし、Enterprise Managerの旧リリースで使用していた管理リポジトリをアップグレードしてから、旧リリースを廃止するという違いがあります。このため、一度に複数のEnterprise Managerシステムが存在することはありません。

リモート・ホストにEnterprise Manager Cloud Controlのソフトウェア・バイナリをインストールし、既存の管理リポジトリをアップグレードしてから、ソフトウェア・バイナリを構成すれば、インストールは完了です。

ソフトウェア・バイナリのインストール中、Oracleホームを作成し、ミドルウェア・ホームの場所に次のコンポーネントをインストールします。

  • Java Development Kit (JDK) 1.6 v24

  • Oracle WebLogic Server 11gリリース1(10.3.5)

  • Oracle Management Service 12c

  • Oracle Management Agent 12c

  • Oracle JRF 11gリリース(11.1.1.4.0)(oracle_commonディレクトリを含む)

  • Oracle Web Tier 11gリリース(11.1.1.4.0)(Oracle_WTディレクトリを含む)

  • Oracle Management Plug-Ins

    • Oracleデータベース管理プラグイン

    • Oracle Fusion Middleware管理プラグイン

    • Oracle My Oracle Support管理プラグイン

    • Oracle Exadata管理プラグイン

ソフトウェア・バイナリの構成中、次の操作を実行します。

  • GCDomainと呼ばれるOracle WebLogicドメインを作成します。このWebLogicドメインでは、デフォルトのユーザー・アカウントweblogicが管理ユーザーとして使用されます。これは、必要に応じてインストーラで変更することもできます。

  • nodemanagerと呼ばれるノード・マネージャのユーザー・アカウントを作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

  • Oracle Management Service 12cに関連するすべての構成の詳細を格納するために、ミドルウェア・ホーム内のOracle Management Serviceインスタンス・ベースの場所(gc_inst)を構成します。

    たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/Middleware/gc_instです。

  • プラグインと管理エージェントを構成します。