| Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド 12cリリース1(12.1.0.1) B65086-03 |
|
 前 |
 次 |
エンタープライズ全体にわたって様々な組合せでEnterprise Managerをデプロイする選択肢がある場合、環境全体をアップグレードすることは、様々なホストに配置された様々なレベル(層)のソフトウェアおよび構成のアップグレードを伴う、非常に複雑な作業になります。さらに、ゼロに近い停止時間で、または監視の欠如を最低限に抑えて環境をアップグレードするうえでの課題もあります。
これらの課題を考慮して、要件を最も満たす方式を選択する柔軟性を提供するだけではなく、シームレスでエラーのないように全体のアップグレード操作を簡略化するアップグレード・オプションが用意されています。
この章では、これらのアップグレード方式の概要を説明します。この章の具体的な内容は次のとおりです。
既存のEnterprise Managerシステムをアップグレードするために、次のアップグレード方式が用意されています。
1システム・アップグレード方式: この方式では、旧リリースのEnterprise Managerを実行しているホストでEnterprise Manager Cloud Controlにアップグレードできます。この方式では、既存のデータベースのOracle Management Repository(管理リポジトリ)もアップグレードされます。アップグレードが同じホスト上で行われるため、ある程度の停止時間が発生します。
この方式が意味するのは、Oracle Management Service(OMS)が1つ稼働している環境でEnterprise Managerシステムをアップグレードすることではありません。Enterprise Managerシステムを旧システムと同じホストでアップグレードすること、そしてEnterprise Managerシステムが常に1つしか存在しないことです。複数OMS環境のアップグレードについては、第21章を参照してください。
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-1は3種類のアップグレード方式の違いをまとめたものです。
表2-1 アップグレード方式の違い
|
注意: ジョブは既存の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アップグレード・コンソールにアクセスするために、スーパー管理者権限でログインします。
|
重要:
|
提供される機能は次の図に明確に表されています。
|
注意: アップグレードをサポートする旧リリースには、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と管理リポジトリのアップグレードを可能にする主要なユーザー・インタフェースです。
提供される機能は次の図に明確に表されています。
この項では、それぞれのアップグレード方式について、実行されるおおよそのフローまたはシーケンスについて説明します。特に、次の項目について説明します。
次の図は、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システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。
インストーラを使用してターゲット・ホストでEnterprise Manager Cloud Controlをインストールおよび構成する場合、デフォルトで次の処理が自動的に実行されます。
インストール・ウィザードで入力したミドルウェア・ホームの場所に次のコンポーネントをインストールします。
Oracle Management Service 12c
Oracle Management Agent 12c
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システム・アップグレード方式と2システム・アップグレード方式を組み合せたものです。1システム・アップグレード方式と同様、まず、管理エージェントの事前デプロイとスイッチオーバーからアップグレード・プロセスを開始します。その後、2システム・アップグレード方式のように、リモート・ホストにEnterprise Manager Cloud Controlをインストールします。ただし、Enterprise Managerの旧リリースで使用していた管理リポジトリをアップグレードしてから、旧リリースを廃止するという違いがあります。このため、一度に複数のEnterprise Managerシステムが存在することはありません。
リモート・ホストにEnterprise Manager Cloud Controlのソフトウェア・バイナリをインストールし、既存の管理リポジトリをアップグレードしてから、ソフトウェア・バイナリを構成すれば、インストールは完了です。
ソフトウェア・バイナリのインストール中、Oracleホームを作成し、ミドルウェア・ホームの場所に次のコンポーネントをインストールします。
Oracle Management Service 12c
Oracle Management Agent 12c
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です。
プラグインと管理エージェントを構成します。
