アップグレード前のメンテナンスタスク

アップグレードを開始する前に次のメンテナンスタスクに従って、システムを準備し、問題が発生した場合にロールバックできるようにしておくことが重要です。

十分なディスク領域の確保

アップグレードを実行する場合は、コンテンツおよびコードのアップグレードアクティビティの他に、リポジトリの移行を実行する必要があります。この移行により、新しい Segment Tar 形式でリポジトリのコピーが作成されます。その結果、大容量になる可能性があるリポジトリの 2 つ目のバージョンを保持するのに十分なディスク領域が必要になります。

AEM の完全なバックアップ

アップグレードを開始する前に、AEM を完全にバックアップする必要があります。リポジトリ、アプリケーションのインストール環境、データストアおよび Mongo インスタンスをバックアップします(該当する場合)。AEM インスタンスのバックアップおよび復元について詳しくは、バックアップと復元を参照してください。

/etc に対する変更のバックアップ

The upgrade process does a good job of maintaining and merging existing content and configurations from under the /apps and /libs paths in the repository. For changes made to the /etc path, including Context Hub configurations, it is often necessary to re-apply these changes after the upgrade. While the upgrade will make a backup copy of any changes that it cannot merge under /var, we recommend backing up these changes manually before beginning the upgrade.

quickstart.properties ファイルの生成

jar ファイルから AEM を起動すると、quickstart.properties の下に crx-quickstart/conf ファイルが生成されます。これまで AEM を起動スクリプトのみで起動していた場合、このファイルは存在せず、アップグレードは失敗します。このファイルが存在するかどうかを確認し、存在しない場合は jar ファイルから AEM を起動してください。

ワークフローおよび監査ログのパージの設定

WorkflowPurgeTask タスクおよび com.day.cq.audit.impl.AuditLogMaintenanceTask タスクには個別の OSGi 設定が必要であり、この設定がない場合は機能しません。アップグレード前タスクの実行中にこれらのタスクが失敗した場合に最も考えられる原因は、設定がないことです。そのため、これらのタスク用の OSGi 設定を追加するか、これらのタスクを実行しない場合はアップグレード前の最適化タスクリストからこれらのタスクを削除する必要があります。ワークフローのパージタスクの設定については、ワークフローインスタンスの管理を参照し、監査ログのメンテナンスタスクの設定については、AEM 6 での監査ログのメンテナンスを参照してください。

CQ 5.6 でのワークフローおよび監査ログのパージと AEM 6.0 での監査ログのパージについては、ワークフローおよび監査ノードのパージを参照してください。

アップグレード前のタスクのインストール、設定および実行

AEM で可能なカスタマイズのレベルにより、通常、アップグレードの実行方法は環境によって異なります。そのため、標準化されたアップグレード手順を作成することは簡単ではありません。

以前のバージョンでは、停止された AEM アップグレードまたは失敗した AEM アップグレードを安全に再開することも困難でした。そのため、完全なアップグレード手順を再度開始する必要があったり、不完全なアップグレードが警告なしでおこなわれたりしました。

これらの問題に対応するために、アドビは複数の拡張機能をアップグレードプロセスに追加して、アップグレードプロセスの回復性を高め、使いやすくしました。以前は手動で実行する必要があったアップグレード前のメンテナンスタスクを最適化および自動化する開発作業がおこなわれています。また、問題を簡単に見つけてプロセスを完全に調べられるように、アップグレード後のレポートが追加されました。

アップグレード前のメンテナンスタスクは、現在、一部または全部を手動で実行する様々なインターフェイスに分割されています。AEM 6.3 で導入されたアップグレード前のメンテナンス最適化では、統一された方法でこれらのタスクをトリガーして、その結果をオンデマンドで調査できます。

アップグレード前の最適化手順に含まれているすべてのタスクは、AEM 6.0 以降のすべてのバージョンと互換性があります。

設定方法

AEM 6.3 以降では、アップグレード前のメンテナンス最適化タスクは quickstart jar に含まれています。AEM 6 の古いバージョンからアップグレードする場合、この最適化タスクは、パッケージマネージャーからダウンロードできる個別のパッケージを介して利用できます。

パッケージは以下の場所にあります。

使用方法

PreUpgradeTasksMBean OSGI コンポーネントは、アップグレード前のメンテナンスタスクのリストで事前設定されており、それらのすべてのタスクを一度に実行できます。以下の手順に従ってタスクを設定できます。

  1. Go to the Web Console by browsing to https://serveraddress:serverport/system/console/configMgr

  2. preupgradetasks」を検索し、最初に一致したコンポーネントをクリックします。コンポーネントのフルネームは、com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl です。

  3. 次に示すように、実行が必要なメンテナンスタスクのリストを変更します。

    1487758925984

タスクリストは、インスタンスの開始に使用する実行モードによって異なります。各メンテナンスタスクの設計対象の実行モードの説明を次に示します。

タスク 実行モード 備考
TarIndexMergeTask crx2
DataStoreGarbageCollectionTask crx2 マークアンドスイープを実行します。共有データストアの場合、この手順を削除して
手動で実行するか、実行前にインスタンスを適切に準備します。
ConsistencyCheckTask crx2
WorkflowPurgeTask crx2 / crx3 実行前に、Adobe Granite のワークフローのパージ設定 OSGi を設定する必要があります。
GenerateBundlesListFileTask crx2 / crx3
RevisionCleanupTask crx3 AEM 6.0 から 6.2 の TarMK インスタンスについては、代わりに手動でオフラインでのリビジョンクリーンアップを実行します。
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 実行前に、監査ログのパージスケジューラー OSGi 設定を設定する必要があります。
注意

DataStoreGarbageCollectionTask を使用した場合、マークアンドスイープフェーズを含むデータストアガベージコレクション操作が呼び出されます。共有データストアを使用するデプロイメントでは、別のインスタンスによって参照される項目が削除されないように、再設定するかインスタンスを適切に準備します。そのためには、このアップグレード前のタスクをトリガーする前に、すべてのインスタンスに対してマークフェーズを手動で実行する必要がある場合があります。

アップグレード前のヘルスチェックのデフォルトの設定

PreUpgradeTasksMBeanImpl OSGI コンポーネントは、runAllPreUpgradeHealthChecks メソッドが呼び出されたときに実行されるアップグレード前のヘルスチェックタグのリストで事前設定されています。

  • system - Granite のメンテナンスヘルスチェックで使用するタグです。

  • pre-upgrade - アップグレード前に実行するように設定できるすべてのヘルスチェックに追加できるカスタムタグです。

このリストは編集できます。タグの横のプラス​(+)​ボタンとマイナス​(-)​ボタンを使用して、カスタムタグを追加したり、デフォルトのタグを削除したりすることができます。

MBean メソッド

マネージド Bean 機能には、JMX コンソールを使用してアクセスできます。

以下の手順で MBean にアクセスできます。

  1. Going to the JMX Console at https://serveraddress:serverport/system/console/jmx

  2. PreUpgradeTasks」を検索し、結果をクリックします。

  3. Operations」セクションからメソッドを選択し、次のウィンドウで「Invoke」を選択します。

PreUpgradeTasksMBeanImpl によって公開されている使用可能なすべてのメソッドのリストを以下に示します。

メソッド名 説明
getAvailablePreUpgradeTasksNames() INFO 使用可能なアップグレード前のメンテナンスタスク名のリストを表示します。
getAvailablePreUpgradeHealthChecksTagNames() INFO アップグレード前のヘルスチェックのタグ名のリストを表示します。
runAllPreUpgradeTasks() アクション : リスト内のすべてのアップグレード前のメンテナンスタスクを実行します。
runPreUpgradeTask(preUpgradeTaskName) アクション : パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクを実行します。
isRunAllPreUpgradeTaskRunning() ACTION_INFO Checks if the runAllPreUpgradeTasksmaintenance task is currently running.
getAnyPreUpgradeTaskRunning() ACTION_INFO アップグレード前のメンテナンスタスクが現在実行されているかどうかをチェックし、
現在実行されているタスクの名前を含む配列を返します。
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) アクション : パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクの正確な実行時間を表示します。
getPreUpgradeTaskLastRunState(preUpgradeTaskName) アクション : パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクの最終実行状態を表示します。
runAllPreUpgradeHealthChecks(shutDownOnSuccess) アクション :

Runs all the pre-upgrade health checks and saves their status in a file named preUpgradeHCStatus.properties that is located in the sling home path. If the shutDownOnSuccess parameter is set to true, the AEM instance will be shut down, but only if all the pre-upgrade health checks have an OK status.

properties ファイルは今後のアップグレードの前提条件として使用され、
アップグレード前のヘルスチェックの実行に失敗した場合は、
アップグレードプロセスが停止されます。アップグレード前のヘルスチェックの結果を無視して
アップグレードを開始する場合は、このファイルを削除できます。

detectUsageOfUnavailableAPI(aemVersion) アクション : 指定された AEM バージョンにアップグレードしたときに適合しない
すべての読み込み済みパッケージをリストします。ターゲットの AEM バージョンは、
パラメーターとして指定する必要があります。
メモ

MBean メソッドは、以下から呼び出すことができます。

  • JMX コンソール
  • JMX に接続する外部アプリケーション
  • cURL

カスタムログインモジュールの無効化

メモ

この手順は、AEM 5 バージョンからアップグレードする場合にのみ必要です。以前の AEM 6 バージョンからのアップグレードの場合は、完全にスキップできます。

The way custom LoginModules are configured for authentication at the repository level has fundamentally changed in Apache Oak.

CRX2 を使用していた旧バージョンの AEM では、repository.xml ファイルで設定をおこないましたが、AEM 6 以降では、Web コンソールを使用して、Apache Felix JAAS Configuration Factory サービスで設定をおこないます。

そのため、既存の設定を無効にして、アップグレード後、Apache Oak 用に再作成する必要があります。

repository.xml の JAAS 設定で定義したカスタムモジュールを無効にするには、次の例のようにデフォルトの LoginModule を利用するように設定を変更する必要があります。

<Security >
             ....
          <!--
                 Use LoginModule authenticating against repository itself
                 -->
                 <LoginModule class = "com.day.crx.core.CRXLoginModule" >
                     <param name = "anonymousId" value = "anonymous" />
                     <param name = "adminId" value ="admin" />
                     <param name = "disableNTLMAuth" value = "true" />
                     <param name = "tokenExpiration" value = "43200000" />
                     <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
                -->
                 </LoginModule >
         </ Security>
メモ

詳しくは、外部ログインモジュールによる認証を参照してください。

AEM 6 での LoginModule 設定例については、AEM 6 での LDAP の設定を参照してください。

/install ディレクトリからの更新の削除

メモ

パッケージは、AEM インスタンスをシャットダウンした後にのみ crx-quickstart/install ディレクトリから削除します。これは、インプレースアップグレード手順を開始する前の最後の手順の 1 つです。

ローカルファイルシステムの crx-quickstart/install ディレクトリを介してデプロイされたサービスパック、機能パックまたはホットフィックスを削除します。これにより、更新が完了した後に、新しい AEM バージョンに古いホットフィックスおよびサービスパックが誤ってインストールされることが防止されます。

すべてのコールドスタンバイインスタンスの停止

TarMK コールドスタンバイを使用している場合は、すべてのコールドスタンバイインスタンスを停止します。これをおこなうことにより、アップグレードで問題が発生した場合に、オンラインに効率よく戻ることができます。アップグレードが正常に完了したら、アップグレードされたプライマリインスタンスからコールドスタンバイインスタンスを再構築する必要があります。

カスタムのスケジュール済みジョブの無効化

アプリケーションコードに含まれている OSGi スケジュール済みジョブを無効にします。

オフラインでのリビジョンクリーンアップの実行

メモ

この手順は、TarMK インストール環境でのみ必要となります。

TarMK を使用している場合は、アップグレードの前にオフラインでのリビジョンクリーンアップを実行してください。これにより、リポジトリの移行ステップが作成され、後続のアップグレードタスクがより迅速に実行されます。また、アップグレード完了後に、オンラインでのリビジョンクリーンアップが正常に実行されるようになります。オフラインでのリビジョンクリーンアップの実行について詳しくは、オフラインでのリビジョンクリーンアップの実行を参照してください。

データストアのガベージコレクションの実行

メモ

この手順は、crx3 を実行するインスタンスにのみ必要です。

CRX3 インスタンスでリビジョンクリーンアップを実行した後は、データストアのガベージコレクションを実行して、データストア内の参照されていない blob を削除する必要があります。手順については、データストアのガベージコレクションに関するドキュメントを参照してください。

必要に応じてデータベーススキーマをアップグレードする

通常、基盤となるApache OakスタックAEMで永続性を使用する場合は、必要に応じてデータベーススキーマのアップグレードが行われます。

ただし、スキーマを自動的にアップグレードできない場合があります。 これらは、ほとんどの場合、非常に限られた権限を持つユーザーの下でデータベースが実行される高いセキュリティ環境です。 この場合、AEMは古いスキーマを引き続き使用します。

このような状況を回避するには、次の手順に従ってスキーマをアップグレードする必要があります。

  1. アップグレードが必要なAEMインスタンスをシャットダウンします。

  2. データベーススキーマをアップグレードします。 この処理を行うために使用する必要のあるツールを確認するには、使用するデータベースの種類に関するドキュメントを参照してください。

    Oakでのスキーマのアップグレードの処理方法について詳しくは、ApacheのWebサイト のこのページを参照してください

  3. AEMのアップグレードを続行します。

アップグレードを妨げる可能性のあるユーザーの削除

メモ

このアップグレード前のメンテナンスタスクは、次の場合にのみ必要です。

  • AEM 6.3より前のAEMバージョンからアップグレードしています
  • アップグレード中に、以下に示すエラーが発生した場合。

サービスユーザーが古いAEMバージョンで、通常のユーザーとして不適切にタグ付けされる場合は、例外的に発生します。

この場合、アップグレードは次のようなメッセージで失敗します。

ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.

この問題を回避するには、次の手順を実行します。

  1. インスタンスを実稼動トラフィックから切り離す

  2. 問題の原因となるユーザーのバックアップを作成します。 これは、Package Managerで行うことができます。 For more information, see How to Work with Packages.

  3. 問題の原因となっているユーザーを削除します。 以下は、このカテゴリに該当する可能性のあるユーザーのリストです。

    1. dynamic-media-replication
    2. communities-ugc-writer
    3. communities-utility-reader
    4. communities-user-admin
    5. oauthservice
    6. sling-scripting

ログファイルのローテーション

アップグレードを開始する前に、現在のログファイルをアーカイブすることをお勧めします。これにより、アップグレード中やアップグレード後にログファイルを監視およびスキャンし、問題が発生した場合に問題を特定して解決することが容易になります。

このページ