Related pages:

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

アップグレードについて

現在のコントローラバージョンが 4.5.17 未満の場合は、「Upgrade the Controller Using the Enterprise Console」を参照してください。

  • Enterprise Console は、スタンドアロンおよび HA ペアコントローラのアップグレードをサポートしています。状況に応じた一連のアクションを確認するには、次の表を使用します。

    現在のコントローラのバージョンアップグレード後のコントローラバージョン実行するアクション
    4.5.17 以降コントローラバージョン 20.x または最新バージョン
    1. ダウンロードポータルにアクセスし、コントローラバージョンをダウンロードします。
    2. Enterprise Console を使用してコントローラをアップグレードします。
  • Enterprise Consoleが認識しているどのバージョンにコントローラをアップグレードするかを選択できます。つまり、コントローラを中間バージョンにアップグレードしたり、最新バージョンにアップグレードしたりできます（Enterprise Consoleインストーラがこれらのバージョン向けに実行されている場合）。ただし、コントローラを古いバージョンにアップグレードすることはできません。
  • 過去のバージョンのライセンスを保有していても、コントローラを新しいバージョンにアップグレードすると、そのライセンスは機能します。ただし、過去のバージョンの一時ライセンスを保有していて、現在は新しいライセンスを保有している場合、新しいライセンスは古いコントローラでは機能しません。この場合、ライセンスを適用する前にコントローラを最新バージョンにアップグレードする必要があります。 
  • アップグレードによりコントローラのダウンタイムが発生しますが、コントローラのアップグレード中にエージェントを停止する必要はありません。

  • Enterprise Console は、コントローラのホームディレクトリに .passwordfile ファイルが存在することを想定しています。Enterprise Console はこのパスワードを読み取り、コントローラと比較して検証します。アップグレードが完了すると、Enterprise Consoleはファイルを削除し、暗号化されたデータベースにパスワードを保存します。

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

アップグレードの前に

  • コントローラのアップグレードを開始する前に、正しい更新順序に従っていることを確認します。 
  • 最新のリリース ノートと、インスタンスの最新バージョンとそのリリースの問題や機能拡張について知ろうとしているバージョンの間の中間バージョンのリリースノートを確認します。 

  • 最新の「コントローラシステム要件」と「コントローラの問題のトラブルシューティング」を確認してコントローラの現在のワークロードを確認します。必要に応じて、パフォーマンスプロファイルを変更し、ハードウェアリソースを増やす必要があるかどうか判断します。

    コントローラをアップグレードする前か後に、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 の制限により、アップグレードは失敗します。
  • 次のセクションの手順に従って、既存のコントローラをバックアップします。

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

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

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

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

コントローラインスタンスをバックアップするには
  1. コントローラアプリケーションのサーバーとデータベースを停止します。

    • Linux では、以下を実行します。

      platform-admin.sh stop-controller-appserver

    • Windowsでは、以下を実行します。

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

アップグレード後

  • 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 = 10 * 60 seconds = 10 minutes を更新してから、チェックポイントからアップグレードを再試行することができます。

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