| Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド 12cリリース3 (12.1.0.3) B65086-09 |
|
 前 |
 次 |
Enterprise Managerは過去に何度もリリースされましたが、Enterprise Manager Cloud Controlはこれらのリリースすべてに大きな変更を加えた最新のリリースです。Enterprise Manager Grid Controlと呼ばれた旧リリースとは異なり、このリリースはEnterprise Manager Cloud Controlと呼ばれます。
Enterprise Manager Cloud Controlは、ユーザー・インタフェースが改良され、安定性、信頼性、パフォーマンスがより高められた、様々な新しい機能や強化された機能を提供します。さらに、Enterprise Manager Cloud ControlのコンソールからMy Oracle Supportへシームレスにアクセスし、サービス・リクエストの管理、パッチのデプロイ、ナレッジ・ベースの記事の確認を行うことができます。
この章では、既存の旧リリースのEnterprise Manager Grid ControlまたはEnterprise Manager Cloud Controlを12cリリース3 (12.1.0.3)にアップグレードする方法について説明します。エンタープライズ全体にわたって様々な組合せでEnterprise Managerをデプロイする選択肢がある場合、環境全体をアップグレードすることは、特に様々なホストに配置された様々なレベル(層)のソフトウェアおよび構成のアップグレードを伴う場合、非常に複雑な作業になります。さらに、ゼロに近い停止時間で、または監視の欠如を最低限に抑えて環境をアップグレードするうえでの課題もあります。
このような課題を考慮して、要件を最も満たす方式を選択できる柔軟性を提供するアップグレード・オプションが用意されています。このアップグレード・オプションは、シームレスでエラーのないものにするためにアップグレード操作全体を簡略化することも目的としています。
この章では、用意されている各種のアップグレード方式の概要を示し、各方式で使用されるユーティリティと、既存のEnterprise Managerシステムをアップグレードするための各方式に従ったプロセス全体について説明します。この章の具体的な内容は次のとおりです。
「12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済]、12cリリース2 (12.1.0.2)から12cリリース3 (12.1.0.3)へのアップグレード」
「10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)から12cリリース3 (12.1.0.3)へのアップグレード」
この項では、Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済]および12cリリース2 (12.1.0.2)から12cリリース3 (12.1.0.3)へのアップグレード用に用意されているアップグレード方式の概要を示し、使用するユーティリティおよびこのアップグレード方式で行うプロセス全体について説明します。
この項の具体的な内容は次のとおりです。
|
注意: バンドル・パッチ1を未適用の12cリリース1 (12.1.0.1)から12cリリース3 (12.1.0.3)へは直接アップグレードできません。このようなリリースをアップグレードするには、次の手順に従います。
手順(1)から手順(3)については、Oracle Enterprise Managerバンドル・パッチ1適用ガイドに説明されている手順に従ってください。手順(4)については、第II部で説明されている手順に従ってください。 |
|
注意: Enterprise Manager Cloud Controlのこれまでのリリースの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。 |
|
注意: 12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済]および12cリリース2 (12.1.0.2)から12cリリース3 (12.1.0.3)へアップグレードする手順については、第II部を参照してください。 |
12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済]および12cリリース2 (12.1.0.2)から12cリリース3 (12.1.0.3)へのアップグレードには、1システム・アップグレード方式のみが提供されています。2システム・アップグレード方式はサポートされていません。
|
注意: 12cリリース1 (12.1.0.1) [バンドル・パッチ1を未適用]から12cリリース3 (12.1.0.3)へはアップグレードできません。まず、バンドル・パッチ1を適用し、次に12cリリース3 (12.1.0.3)にアップグレードします。 |
1システム・アップグレード方式は、同じホスト上のEnterprise Manager Cloud Controlをアップグレードします。同じホスト上のOracle Management Service (OMS)と既存データベース内のOracle Management Repository (管理リポジトリ)をアップグレードします。アップグレードが同じホスト上で行われるため、ある程度の停止時間が発生します。
このアップグレード方式で、Enterprise Managerシステムは単一インスタンス、または複数OMS環境の実装(エンタープライズの規模が大きい場合に必要)のいずれかになる場合があります。どちらの場合でも、新規OMSは同じホスト上の元のOMSをアップグレードしますが、ある時点でアクティブになるのは新規システムまたは元のシステムのいずれかのみです。複数OMS環境のアップグレードについては、第5.5項を参照してください。
|
注意: インストーラは既存の管理エージェントをアップグレードしません。OMSをアップグレードした後、エージェント・アップグレード・コンソールを使用して管理エージェントを個別にアップグレードする必要があります。エージェント・アップグレード・コンソールは、OMSをアップグレードした後にEnterprise Manager Cloud Controlコンソールに表示されるGUIメインのコンソールです。詳細は、2.1.2.2項を参照してください。 |
表2-1に、12cリリース全体でのOMSと管理エージェント間の互換性について示します。
表 2-1 12cリリースにおけるOMSと管理エージェントの互換性
|
Oracle Management Agent 12cリリース1(12.1.0.1) |
Oracle Management Agent 12cリリース2 (12.1.0.2) |
Oracle Management Agent 12cリリース3 (12.1.0.3) |
|
|
Oracle Management Service 12cリリース1 (12.1.0.1) |
はい (バンドル・パッチ1を適用済および未適用の管理エージェントを含む) |
いいえ |
いいえ |
|
Oracle Management Service 12cリリース2 (12.1.0.2) |
はい (バンドル・パッチ1を適用済および未適用の管理エージェントを含む) |
はい |
いいえ |
|
Oracle Management Service 12cリリース3 (12.1.0.3) |
はい (2012年1月にリリースされた[バンドル・パッチ1を適用済]管理エージェントのみ) |
はい |
はい |
この項では、12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済]および12cリリース2 (12.1.0.2)を12cリリース3 (12.1.0.3)にアップグレードする際に使用するユーティリティについて説明します。特に、次の項目について説明します。
Enterprise Manager Cloud Controlインストール・ウィザードは、1システム・アップグレード方式の選択、および既存のOMSと管理リポジトリのアップグレードを可能にする主要なユーザー・インタフェースです。
提供される機能は次の図に明確に表されています。
エージェント・アップグレード・コンソールは、Enterprise Manager Cloud Control 12cに組み込まれているグラフィカル・ユーザー・インタフェースです。Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)に組み込まれているこのコンソールでは、次のOracle Management Agentの1つ以上のリリースをアップグレードできます。
12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済のみ]
12cリリース2 (12.1.0.2)
|
注意: エージェント・アップグレード・コンソールは、Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)で使用できました。しかし、Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)で使用可能なコンソールは、この項で説明する管理エージェントのリリースのみをアップグレードします。バンドル・パッチ1を未適用のOracle Management Agent 12cリリース1 (12.1.0.1)がある場合は、最初にバンドル・パッチ1を適用し、次にエージェント・アップグレード・コンソールを使用して12cリリース3 (12.1.0.3)にアップグレードします。 |
|
注意: 複数OMS環境ではすべてのOMSインスタンスがアップグレードされた後に、エージェント・アップグレード・コンソールを使用して管理エージェントをアップグレードできるようになります。 |
次の図は、1システム・アップグレード方式を使用した12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済]および12cリリース2 (12.1.0.2)から12cリリース3 (12.1.0.3)へのアップグレードを選択したときに、実行する必要のある手順の高度なフローまたは順序を表しています。
|
注意: Oracle Management Service 12cは、Oracle Management Agent 12c (12.1.0.3、12.1.0.2およびバンドル・パッチ1を適用済の12.1.0.1)とのみ通信します。したがって、旧リリースとは異なり、最初にOMSおよび管理リポジトリをアップグレードしてから、エージェント・アップグレード・コンソールを使用して管理エージェントをアップグレードする必要があります。エージェント・アップグレード・コンソールは、OMSをアップグレードした後にEnterprise Manager Cloud Controlコンソールに表示されるGUIメインのコンソールです。詳細は、2.1.2.2項を参照してください。 |
インストーラを使用してOMSおよび管理リポジトリをアップグレードする場合、デフォルトでインストーラが次の処理も実行します。
インストーラで入力したミドルウェア・ホームの場所に次のコンポーネントをインストールします。
指定するミドルウェア・ホームにまだインストールされていない場合は、Java Development Kit (JDK) 1.6.0.43.0およびOracle WebLogic Server 11gリリース1 (10.3.6)。
Oracle Management Service 12 cリリース3 (12.1.0.3)。
Oracle JRF 11gリリース(11.1.1.6.0) (oracle_commonディレクトリを含む)。
Oracle Web Tier 11gリリース(11.1.1.6.0) (Oracle_WTディレクトリを含む)。
すでにデプロイされているプラグインをアップグレードするか引き継ぎます。
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)ソフトウェアに新しいバージョンがある場合は、デプロイされているプラグインをアップグレードします。
次の場合は、デプロイされているプラグインをアップグレードせずに引き継ぎます。
(a) Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)ソフトウェアに新しいバージョンがない場合。
(b)デプロイされているプラグインがすでにEnterprise Manager Cloud Control 12cリリース3 (12.1.0.3)ソフトウェアでのバージョン以上である場合。
同じ管理サーバー構成詳細(同じ管理サーバー、同じポートなど)によって、新規のOracle WebLogicドメインとノード・マネージャを作成します。
Oracle Management Service 12cに関連するすべての構成の詳細を格納する、Oracle Management Serviceインスタンス・ベース・ディレクトリ(gc_inst)をミドルウェア・ホーム外に作成します。
たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instとします。
既存の認証済データベース自体の管理リポジトリをアップグレードします。
次の構成アシスタントを実行して、インストールまたはアップグレードされたコンポーネントを構成します。
APMエンジン構成の停止
管理サーバー構成の停止
プラグイン前提条件チェック
リポジトリ・アップグレード
MDSスキーマ構成
OMS構成
プラグイン・デプロイおよび構成
Oracle Management Serviceの起動
Oracle Configuration Managerリピータ構成
|
注意: インストーラは、OMSとともにインストール済の既存の管理エージェントをアップグレードしません。エージェント・アップグレード・コンソールを使用して、(その他すべての管理エージェントとともに)アップグレードする必要があります。詳細は、2.1.2.2項を参照してください。 |
この項では、アップグレード方式の概要を示し、3つのアップグレード方式の違いを明示して、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)を12cリリース3 (12.1.0.3)にアップグレードするために使用するユーティリティと実行するプロセス全体について説明します。
この項の具体的な内容は次のとおりです。
|
注意: 10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)から12cリリース3 (12.1.0.3)にアップグレードするための手順については、第III部を参照してください。 |
10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)を12cリリース3 (12.1.0.3)にアップグレードするための次のアップグレード方式が用意されています。
1システム・アップグレード方式: この方式では、旧リリースのEnterprise Managerを実行しているホストでEnterprise Manager Cloud Controlにアップグレードできます。この方式では、既存のデータベースのOracle Management Repository(管理リポジトリ)もアップグレードされます。アップグレードが同じホスト上で行われるため、ある程度の停止時間が発生します。
この方式が意味するのは、Oracle Management Service(OMS)が1つ稼働している環境でEnterprise Managerシステムをアップグレードすることではありません。Enterprise Managerシステムを旧システムと同じホストでアップグレードすること、そしてEnterprise Managerシステムが常に1つしか存在しないことです。複数OMS環境のアップグレードについては、第11.6項を参照してください。
2システム・アップグレード方式: この方式では、既存のEnterprise Managerシステムを実行していないホストにEnterprise Manager Cloud Controlをインストールできます。
既存のデータベースの管理リポジトリはアップグレードされませんが、バックアップされたデータベースの管理リポジトリがアップグレードされるので、2つのEnterprise Managerシステムが存在できるようになります。新しいEnterprise Managerシステムは旧システムと共存するので、停止時間はまったく発生しないか、発生したとしてもほぼゼロです。
異なるホストでの1システム・アップグレード方式: この方式では、既存のEnterprise Managerを実行していないホストにEnterprise Manager Cloud Controlをインストールできます。
この方式は2システム・アップグレード方式と似ていますが、2システム・アップグレード方式とは異なり、既存のデータベース自体の管理リポジトリがアップグレードされます。Enterprise Managerシステムは常に1つしか存在しないため、ある程度の停止時間が発生します。
表2-2に、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)を12cリリース3 (12.1.0.3)にアップグレードするために用意されている3つのアップグレード方式の違いを示します。この違いを理解して、個々の要件を最も満たす方式を選択してください。
表2-2 アップグレード方式の違い
| 1システムのアップグレード方式 | 2システムのアップグレード方式 | 異なるホストでの1システムのアップグレード方式 |
|---|---|---|
|
OMSと管理リポジトリのアップグレードにのみ焦点を当てた従来の方式とは異なり、OMSおよび管理リポジトリをアップグレードする前に、管理エージェントの事前デプロイ操作とスイッチオーバーを行います。 |
フレッシュ・インストールと同様です。 |
影響は1システムのアップグレード方式と同じですが、Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)のホストが異なります。 |
|
(基本的に、管理エージェントのスイッチオーバーを開始してから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を構成することができます。 詳細は、第3.5項を参照してください。 |
ポートやファイアウォールの設定を一部変更する必要があります。アップグレード後の管理エージェントは、アップグレード前と同じポートを使用します。ただし、リモート・ホストにインストールされた管理エージェントとOMSは新しいポートを使用する可能性があります。 複数OMS環境では、サーバー・ロード・バランサ(SLB)を使用している場合、新しい管理エージェントとOMSのために同じSLBに新しいポートを開くか、またはまったく新規にSLBを構成することができます。 詳細は、第3.5項を参照してください。 |
|
デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。 |
デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。 |
デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。 |
|
実行中のジョブは、バックアップの開始後、既存の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で実行されます。両方のシステムで実行されることはありません。ジョブの本当の状態は、そのジョブが実際に実行されていたシステムでのみ確認できます。詳細は、付録Dを参照してください。また、すべてのターゲットで使用されるすべての管理エージェントを同時に移行しないかぎり、複数のターゲットを使用したジョブはどちらのシステムでも実行されません。 |
この項では、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)を12cリリース3 (12.1.0.3)にアップグレードする際に使用するユーティリティについて説明します。これらのユーティリティでは、アップグレード方式の1つを選択し、アップグレード操作全体をシームレスに編成して、アップグレード後アクティビティも追跡できます。
特に、次の項目について説明します。
アップグレード前コンソールは、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)を12cリリース3 (12.1.0.3)にアップグレードするための主要なユーザー・インタフェースとして機能し、開始点になります。
アップグレード前コンソールにより、適切なアップグレード方式の選択、Oracle Management Agent 12cソフトウェアの事前デプロイ、および管理エージェントの旧リリースから新たに事前デプロイされた管理エージェントへのスイッチオーバーができるようになります。
|
注意: Oracle Management Service 12cは、Oracle Management Agent 12c (12.1.0.3、12.1.0.2およびバンドル・パッチ1を適用済の12.1.0.1)とのみ通信します。したがって、旧リリースとは異なり、既存のOMSをアップグレードする前に、まず、使用しているシステムの管理エージェントをアップグレードする必要があります。このため、アップグレード前コンソールはアップグレード・プロセスの開始点となるのです。 |
アップグレード前コンソールにアクセスするには、次を行います。
(オプション) My Oracle Supportのノート822485.1に従って、OMSに最新のPSUパッチを適用します。My Oracle Supportにアクセスするには、次のURLにアクセスします。
|
注意: 10gリリース5 (10.2.0.5)では、PSU 3 (9282397)以上が適用されていることを確認してください。11gリリース1 (11.1.0.1)では、PSU 1 (10065631)以上が適用されていることを確認してください。 |
(必須) アップグレード前コンソール・パッチをすべてのOMSインスタンスに適用します。ダウンロードしてプラットフォームに適用する必要があるパッチの詳細は、次のURLにアクセスしてください。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html
パッチのダウンロード後、このパッチに付属しているReadMeの指示に従って操作します。パッチを適用するには、必ず最新のOPatchリリースを使用してください。
パッチを適用した後、スーパー管理者権限でEnterprise Manager Grid Controlにログインし、「デプロイ」タブをクリックしてから「Enterprise Manager 12cアップグレード・コンソール」をクリックします。
|
重要:
|
提供される機能は次の図に明確に表されています。
|
注意: アップグレードに対応している旧リリースは、Oracle Management Agent 10gリリース2 (10.2.x.x.x)、Oracle Management Agent 11gリリース1 (11.1.0.1)、Oracle Management Service 10gリリース5 (10.2.0.5)、およびOracle Management Service 11gリリース1 (11.1.0.1)です。 |
Enterprise Manager Cloud Controlインストール・ウィザードは、実行するアップグレード方式の選択、および既存のOMSと管理リポジトリのアップグレードを可能にする主要なユーザー・インタフェースです。
提供される機能は次の図に明確に表されています。
この項では、それぞれのアップグレード方式について、実行されるおおよそのフローまたはシーケンスについて説明します。特に、次の項目について説明します。
次の図は、1システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。
アップグレード前コンソールを使用して、Oracle Management Agent 12cソフトウェアをデプロイし、古い管理エージェントから新たにデプロイされた管理エージェントへスイッチオーバーすることができます。デプロイとスイッチオーバーはどちらも管理エージェントのインストールとアップグレードを処理しますが、これらはまったく異なる操作であることがわかるでしょう。
|
注意: 最良の慣例として、スイッチオーバー操作を開始するかなり前に、デプロイ操作を完了しておくことをお薦めします。 |
デプロイ操作では管理エージェントのソフトウェア・バイナリがコピーされ、ホスト上でこれらの構成が行われますが、スイッチオーバー操作では古い管理エージェントが停止され、Enterprise Manager Cloud Controlで連携するように新しい管理エージェントが起動されます。
ソフトウェア・バイナリのコピーとホスト上での構成の間、既存のEnterprise Managerシステムが停止されないこと、または動作が妨げられないことを保証するために、これら2つの操作は区別され、異なるエンティティとして扱われます。一度コピーされ、構成されたソフトウェア・バイナリは、より迅速にスイッチオーバーできるようになります。これは、古い管理エージェントを停止し、新しい管理エージェントを起動するための時間しか、この操作にはかからないためです。
管理エージェントのスイッチオーバーが完了すれば、OMSと管理リポジトリをアップグレードできるようになります。
|
注意: 最良の慣例として、スイッチオーバー操作の完了後、ただちにすべてのOMSインスタンスをアップグレードすることもお薦めします。1システム・アップグレード方式での停止時間は、基本的に管理エージェントをスイッチオーバーしたときから、すべてのOMSインスタンスをアップグレードするときまで続くということに注意してください。したがって、アップグレード操作が遅れれば遅れるほど、停止時間が長くなります。この停止時間中、監視されるターゲットはなく、OMSインスタンスにアップロードされる監視データもありません。 |
インストーラを使用して、ホスト上のEnterprise Manager Cloud Controlをアップグレードする場合、インストーラはデフォルトで次の操作を実行します。
インストーラで入力したミドルウェア・ホームの場所に次のコンポーネントをインストールします。
Oracle Management Service 12c。
Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0 (JDK)。
|
注意: Oracle WebLogic Server 11gリリース1 (10.3.6)およびJDK 1.6.0.43.0は、既存のインストールの使用を指定しない場合にのみインストールされます。12cのインストール・プロセスを使用して、Enterprise Manager 12cとともに使用するJDKおよびOracle WebLogic Serverをインストールすることを強くお薦めします。サポートされているバージョンまたはそれ以降に、これらがすでに存在する場合は自動的に検出され、インストール場所のミドルウェア・ホームが表示されます。この場合、このミドルウェア・ホームのパスを確認するだけですみます。 |
Oracle JRF 11gリリース(11.1.1.6.0) (oracle_commonディレクトリを含む)と、Oracle Web Tier 11gリリース(11.1.1.6.0) (Oracle_WTディレクトリを含む)。
プラグイン:
Oracleデータベース管理プラグイン
Oracle Fusion Middleware管理プラグイン
Oracle My Oracle Support管理プラグイン
Oracle Exadata管理プラグイン
アップグレード前コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたその他のプラグイン(これらのプラグインがソフトウェア・キットに含まれている場合)
アップグレードする旧リリースのEnterprise Managerシステムに応じて、Oracle WebLogicドメイン、管理サーバー、ノード・マネージャおよび管理対象サーバーを作成または再利用します。
Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)からアップグレードする場合、デフォルトで次のものが作成されます。
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)からアップグレードする場合は、同じ管理サーバー構成(同じ管理サーバー、同じポートなど)によって、新規のOracle WebLogicドメインとノード・マネージャが作成されます。
ミドルウェア・ホーム外にOMSインスタンス・ベース・ディレクトリ(gc_inst)を作成し、OMSに関連するすべての構成情報を格納します。
たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instとします。
既存の認証済データベース自体の管理リポジトリをアップグレードします。
インストールまたはアップグレードされたコンポーネントを構成するために実行する構成アシスタントの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
|
注意: インストーラにより、既存の管理エージェントがアップグレードされることはありません。これは管理エージェントがアップグレード前コンソールにより事前デプロイされているからです。 |
次の図は、2システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。
インストーラを使用してターゲット・ホストでEnterprise Manager Cloud Controlをインストールおよび構成する場合、デフォルトで次の処理が自動的に実行されます。
インストーラで入力したミドルウェア・ホームの場所に次のコンポーネントをインストールします。
Oracle Management Service 12c
Oracleデータベース管理プラグイン
Oracle Fusion Middleware管理プラグイン
Oracle My Oracle Support管理プラグイン
Oracle Exadata管理プラグイン
アップグレード前コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたその他のプラグイン(これらのプラグインがソフトウェア・キットに含まれている場合)
|
注意: Oracle WebLogic Server 11gリリース1 (10.3.6)およびJDK 1.6.0.43.0は、既存のインストールの使用を指定しない場合にのみインストールされます。12cのインストール・プロセスを使用して、Enterprise Manager 12cとともに使用するJDKおよびOracle WebLogic Serverをインストールすることを強くお薦めします。サポートされているバージョンまたはそれ以降に、これらがすでに存在する場合は自動的に検出され、インストール場所のミドルウェア・ホームが表示されます。この場合、このミドルウェア・ホームのパスを確認するだけですみます。 |
指定したエージェント・ベース・ディレクトリ(ミドルウェア・ホーム外)にOracle Management Agent 12cをインストールします。
GCDomainと呼ばれるOracle WebLogicドメインを作成します。このWebLogicドメインでは、デフォルトのユーザー・アカウントweblogicが管理ユーザーとして使用されます。これは、必要に応じてインストーラで変更することもできます。
nodemanagerと呼ばれるノード・マネージャのユーザー・アカウントを作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。
Oracle Management Service 12cに関連するすべての構成の詳細を格納するために、ミドルウェア・ホーム外にOMSインスタンス・ベースの場所(gc_inst)を構成します。
たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instとします。
インストールまたはアップグレードされたコンポーネントを構成するために実行する構成アシスタントの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
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システム・アップグレード方式と2システム・アップグレード方式を組み合せたものです。1システム・アップグレード方式と同様、まず、管理エージェントの事前デプロイとスイッチオーバーからアップグレード・プロセスを開始します。その後、2システム・アップグレード方式のように、リモート・ホストにEnterprise Manager Cloud Controlをインストールします。ただし、Enterprise Managerの旧リリースで使用していた管理リポジトリをアップグレードしてから、旧リリースを廃止するという違いがあります。このため、一度に複数のEnterprise Managerシステムが存在することはありません。
リモート・ホストにEnterprise Manager Cloud Controlのソフトウェア・バイナリをインストールし、既存の管理リポジトリをアップグレードしてから、ソフトウェア・バイナリを構成すれば、インストールは完了です。
ソフトウェア・バイナリのインストール中に、インストーラは次の処理を実行します。
Oracleホームを作成し、ミドルウェア・ホームの場所に次のコンポーネントをインストールします。
Oracle Management Service 12c
Oracleデータベース管理プラグイン
Oracle Fusion Middleware管理プラグイン
Oracle My Oracle Support管理プラグイン
Oracle Exadata管理プラグイン
指定したエージェント・ベース・ディレクトリ(ミドルウェア・ホーム外)にOracle Management Agent 12cをインストールします。
ソフトウェア・バイナリの構成中に、インストーラは次の処理を実行します。
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/gc_instとします。
インストールまたはアップグレードされたコンポーネントを構成するために実行する構成アシスタントの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
