Enterprise Consoleを使用するコントローラのアップグレード

On this page:

Related pages:

Enterprise Consoleを使用してコントローラインスタンスをアップグレードできます。Enterprise Consoleにより、単一のコントローラおよびHAペアを発見し、アップグレードすることができるため、アップグレードプロセスが簡素化されます。

アップグレードについて

Enterprise Console では、4.1 以上から最新バージョンまで、コントローラのアップグレード（スタンドアロンと HA ペア）をサポートしています。3.x や 4.0.x などの以前のバージョンのコントローラを使用していて、4.4.x か最新バージョンにアップグレードする場合、コントローラのインストーラを使用してまず 4.1 にアップグレードしてください。その後、Enterprise Console を使用して最新バージョンにアップグレードする必要があります。
4.1以上のコントローラを検出して最新バージョンにアップグレードしても、イベントサービスは自動的にアップグレードされません。個別のアップグレードジョブで行う必要があります。
一度に複数のバージョンをアップグレードできます。つまり、中間バージョンごとに個別にアップグレードを実行する必要はありません。
Enterprise Consoleが認識しているどのバージョンにコントローラをアップグレードするかを選択できます。つまり、コントローラを中間バージョンにアップグレードしたり、最新バージョンにアップグレードしたりできます（Enterprise Consoleインストーラがこれらのバージョン向けに実行されている場合）。ただし、コントローラを古いバージョンにアップグレードすることはできません。
既存のコントローラが現在の負荷を処理しており、ライセンスの変更を行っていない場合、コントローラのアップグレード時にハードウェアをアップグレードする必要はありません。コントローラの容量の上限に近づいているかを判断するには、「コントローラの問題のトラブルシューティング」を参照してください。
過去のバージョンのライセンスを保有していても、コントローラを新しいバージョンにアップグレードすると、そのライセンスは機能します。ただし、過去のバージョンの一時ライセンスを保有していて、現在は新しいライセンスを保有している場合、新しいライセンスは古いコントローラでは機能しません。この場合、ライセンスを適用する前にコントローラを最新バージョンにアップグレードする必要があります。
アップグレードによりコントローラのダウンタイムが発生しますが、コントローラのアップグレード中にエージェントを停止する必要はありません。
4.5 より、コントローラの検出およびアップグレードシナリオの間、Enterprise Console は .passwordfile ファイルがコントローラホームディレクトリにあると想定します。Enterprise Console はこのパスワードを読み取り、コントローラと比較して検証します。アップグレードが完了すると、Enterprise Consoleはファイルを削除し、暗号化されたデータベースにパスワードを保存します。

手動で Glassfish 管理者パスワードを変更する場合は、Enterprise Console コントローラの設定でも更新する必要があります。

アップグレードの前に

コントローラのアップグレードを開始する前に、正しい更新順序に従っていることを確認します。4.1 より前のバージョンから 4.4.x か最新バージョンにアップグレードする場合、まず埋め込み型イベントサービスを手動でアップグレードしてから、コントローラをアップグレードする必要があります。
最新のリリースノートと、インスタンスの最新バージョンとそのリリースの問題や機能拡張について知ろうとしているバージョンの間の中間バージョンのリリースノートを確認します。
最新のコントローラシステム要件とコントローラの問題のトラブルシューティングを確認して、パフォーマンスプロファイルを変更する必要があるかどうか判断します。

コントローラをアップグレードする前か後に、Enterprise Console GUI の [Platform Configurations] ページでコントローラプロファイルを変更できます。Update Platform Configurationsこのプロセスは不可逆的で、大きいサイズのプロファイルから小さいサイズのプロファイルに移行することはできません。
コントローラのdatabase.logでエラーがあるか確認します。ログは <controller_home>/db/logs/database.log にあります。ログには InnoDB: Error の行はありません。エラーが見つかった場合には、アップグレードを実行する前にAppDynamicsサポートにお問い合わせください。データベースが破損しているコントローラをアップグレードすると、コントローラの状態が悪くなり、復元に時間がかかることがあります。
JVM オプションでない Glassfish 設定を変更した場合、変更内容に注意してください。アップグレード後に構成が必要な場合があります。Enterprise Consoleでは、domain.xmlやdb.cnfなどの構成ファイルに対する多くの一般的なカスタマイズが認識され、保持されますが、すべてが保持されることは保証されません。ファイルの構成を手動で変更した場合、更新後に構成を確認してください。変更の保存方法については、「構成変更の保持」を参照してください。
以前コントローラを管理していた Enterprise Console をアンインストールし、新しい Enterprise Console インスタンスを使用してコントローラを検出し、アップグレードする場合、Enterprise Console で検出とアップグレードのプロセスを続行させるために、まず .passwordfile ファイルを手動で作成する必要があります。コントローラホームディレクトリにファイルを作成し、ファイルに値 AS_ADMIN_PASSWORD=<controllerRootUserPassword> を追加します。
HTTPS の有効時にアップグレードを実行する場合は、ホスト名が数字で始まらないことを確認します。Enterprise Console のホスト名が数字で始まる場合、アップグレードは失敗します。これは、CN/SAN での DNS 名の JDK 制限によります。
リリース3.8で、データベースユーザーパスワードの保存メカニズムが変わりました。3.7.x 以前からアップグレードする場合、データベースユーザパスワードに関する考慮事項については、3.8 ドキュメントの「Upgrade the Controller」ページを参照してください。
次のセクションの手順に従って、既存のコントローラをバックアップします。

既存のコントローラのバックアップ

Enterprise Console は <controller_home>/backup にある変更された構成ファイルのコピーなど、アップグレードを通してエージェントデータ、レポート、構成、その他のタイプのデータを保持します。それでも、予期せぬエラーイベントでデータを失うリスクを緩和するために、コントローラのアップグレードを行う前に必ず既存のインストールディレクトリをバックアップしてください。

Enterprise ConsoleではMySQLデータはバックアップされません。スタンドアロンインストールをアップグレードする前にMySQLデータをバックアップする必要があります。

何らかの理由でアップグレードが正常に終了しなかった場合、詳細については、「アップグレードのトラブルシューティング」を参照してください。

コントローラインスタンスをバックアップするには

コントローラアプリケーションのサーバーとデータベースを停止します。
- Linux の場合、以下を実行します。
```
platform-admin.sh stop-controller-appserver
```
- Windowsでは、以下を実行します。
```
platform-admin.exe cli stop-controller-appserver --with-db
```
コントローラホームディレクトリ全体をバックアップロケーションにコピーして、コントローラホームをバックアップします。以下の点に注意してください。
- コントローラのデータホームが Controller ディレクトリの下にない場合には、必ず database ディレクトリもバックアップしてください。
- データセット全体をバックアップできない場合には、最も重要なテーブルを選択してバックアップできます。「コントローラデータのバックアップと復元」ページにあるメタデータバックアップ SQL スクリプトを使用します。
バックアップの完了後とアップグレード前には、コントローラを再起動します。

アップグレード後

domain.xml ファイル、db.cnf、その他の構成ファイルのいずれかを手動で、または Glassfish asadmin ユーティリティを使用して設定した場合、アップグレード後に構成ファイルか GUI の [Controller Configurations] ページでそれらの変更を確認し、保存されていないカスタマイズを再適用してください。Enterprise Console は一部の推奨カスタマイズを保存します。アップグレードしたら、<controller_home>/backup ディレクトリに共通の構成ファイルのバックアップコピーが作成されます。
オプション手順として、Enterprise Console GUI または mysql-upgrade ジョブを使用して、コントローラをアップグレードした後に MySQL バージョンをアップグレードできます。詳細については、「バンドルされる MySQL データベースのバージョン」を参照してください。

アップグレードのトラブルシューティング

アップグレードがいずれかの理由で失敗しても、Enterprise Consoleはディスク上の変更をロールバックしません。これにより、インストールやアップグレードを再試行する前に、問題を診断してトラブルシューティングする機会を得ることができます。

問題をトラブルシューティングするには、platform-admin/logs/platform-admin-server.log のインストールログを確認してください。コントローラの server.log ファイルに追加の情報が含まれている場合があります。

チェックポイントからの再開

Enterprise Console では、失敗した最後のポイント（チェックポイント）からアップグレードを再開する機能が提供されています。インストール中、アプリケーションは複数のステージでチェックポイントを作成します。インストールが失敗した場合、チェックポイントから再開すると、正常に完了した以前のすべてのステージがスキップされ、失敗した最後のポイントがある特定のステージの最初からインストールが再開します。

フラグ useCheckpoint=true を引数としてコマンドの --args の後に渡すことにより、失敗したコントローラジョブを CLI から再開することもできます。

いずれかの理由で、最後のチェックポイントからのアップグレードが失敗した場合、アップグレードを最初から再試行できます。チェックポイントから再開するのではなく、[Retry] をクリックするだけです。ただし、アップグレードが失敗した後に最初から再試行すると、db.cnfおよびdomain.xmlへのカスタマイズが上書きされることがあることに注意してください。

タイムアウト

一般的なアップグレードの問題として、アップグレードプロセスのタイムアウトがあります。Enterprise Console は更新またはインストール後にコントローラやデータベースを再起動しようとします。しかし、大規模なデータベースやシステムリソースによっては、再起動にかなりの時間がかかることがあります。Enterprise Console が設定されたタイムアウト時間内（デフォルトでは 30 分）にコントローラを再起動できない場合、オペレーションは失敗します。

システム起動のデフォルトのタイムアウト時間を増やすことができます。タイムアウトは platform-admin/archives/controller/<version>/playbooks/controller.groovy に定義されています。controllerStartRetryTimeout = 45 * 60 の値を更新し（分単位）、チェックポイントからアップグレードを再試行します。

コントローラのアップグレードが完了しても、監査レポートはすぐには機能しません。監査データベーステーブルが移行されるのはアップグレードプロセスの後のみで、移行の完了に1時間以上かかります。移行プロセスの完了前に監査レポートを実行すると、server.logファイルに監査テーブル移行メッセージが記録されます。特別な対処は不要です。1時間後にもう一度監査レポートを実行してください。