アップグレードを開始する前に次のメンテナンスタスクに従って、システムを準備し、問題が発生した場合にロールバックできるようにしておくことが重要です。
アップグレードを実行する場合は、コンテンツおよびコードのアップグレードアクティビティの他に、リポジトリの移行を実行する必要があります。この移行により、新しい Segment Tar 形式でリポジトリのコピーが作成されます。その結果、大容量になる可能性があるリポジトリの 2 つ目のバージョンを保持するのに十分なディスク領域が必要になります。
アップグレードを開始する前に、AEM を完全にバックアップする必要があります。リポジトリ、アプリケーションのインストール環境、データストアおよび Mongo インスタンスをバックアップします(該当する場合)。AEM インスタンスのバックアップおよび復元について詳しくは、バックアップと復元を参照してください。
このアップグレードプロセスは、リポジトリの/apps
パスと/libs
パスの下から既存のコンテンツと設定を管理および結合するのに役立ちます。 /etc
パスに対して行われた変更(Context Hub設定を含む)については、多くの場合、アップグレード後にこれらの変更を再適用する必要があります。 /var
の下で結合できない変更のバックアップコピーはアップグレードで作成されますが、アップグレードを開始する前に、手動でこれらの変更をバックアップすることをお勧めします。
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 コンポーネントは、アップグレード前のメンテナンスタスクのリストで事前設定されており、それらのすべてのタスクを一度に実行できます。以下の手順に従ってタスクを設定できます。
https://serveraddress:serverport/system/console/configMgr
を参照してWebコンソールに移動
「preupgradetasks」を検索し、最初に一致したコンポーネントをクリックします。コンポーネントのフルネームは、com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
です。
次に示すように、実行が必要なメンテナンスタスクのリストを変更します。
タスクリストは、インスタンスの開始に使用する実行モードによって異なります。各メンテナンスタスクの設計対象の実行モードの説明を次に示します。
タスク | 実行モード | 備考 |
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 にアクセスできます。
JMXコンソール(https://serveraddress:serverport/system/console/jmx)に移動します。
「PreUpgradeTasks」を検索し、結果をクリックします。
「Operations」セクションからメソッドを選択し、次のウィンドウで「Invoke」を選択します。
PreUpgradeTasksMBeanImpl
によって公開されている使用可能なすべてのメソッドのリストを以下に示します。
メソッド名 | 種類 | 説明 |
getAvailablePreUpgradeTasksNames() |
INFO | 使用可能なアップグレード前のメンテナンスタスク名のリストを表示します。 |
getAvailablePreUpgradeHealthChecksTagNames() |
情報 | アップグレード前のヘルスチェックのタグ名のリストを表示します。 |
runAllPreUpgradeTasks() |
アクション : | リスト内のすべてのアップグレード前のメンテナンスタスクを実行します。 |
runPreUpgradeTask(preUpgradeTaskName) |
アクション : | パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクを実行します。 |
isRunAllPreUpgradeTaskRunning() |
ACTION_INFO | runAllPreUpgradeTasksmaintenance タスクが現在実行中かどうかを確認します。 |
getAnyPreUpgradeTaskRunning() |
ACTION_INFO | アップグレード前のメンテナンスタスクが現在実行されているかどうかをチェックし、 現在実行されているタスクの名前を含む配列を返します。 |
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) |
アクション : | パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクの正確な実行時間を表示します。 |
getPreUpgradeTaskLastRunState(preUpgradeTaskName) |
アクション : | パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクの最終実行状態を表示します。 |
runAllPreUpgradeHealthChecks(shutDownOnSuccess) |
アクション : | アップグレード前のヘルスチェックをすべて実行し、そのステータスをSlingホームパス内の properties ファイルは今後のアップグレードの前提条件として使用され、 |
detectUsageOfUnavailableAPI(aemVersion) |
アクション : | 指定された AEM バージョンにアップグレードしたときに適合しない すべての読み込み済みパッケージをリストします。ターゲットの AEM バージョンは、 パラメーターとして指定する必要があります。 |
MBean メソッドは、以下から呼び出すことができます。
この手順は、AEM 5 バージョンからアップグレードする場合にのみ必要です。以前の AEM 6 バージョンからのアップグレードの場合は、完全にスキップできます。
リポジトリレベルでの認証用にカスタムLoginModules
を設定する方法は、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 の設定を参照してください。
パッケージは、AEM インスタンスをシャットダウンした後にのみ crx-quickstart/install ディレクトリから削除します。これは、インプレースアップグレード手順を開始する前の最後の手順の 1 つです。
ローカルファイルシステムの crx-quickstart/install
ディレクトリを介してデプロイされたサービスパック、機能パックまたはホットフィックスを削除します。これにより、更新が完了した後に、新しい AEM バージョンに古いホットフィックスおよびサービスパックが誤ってインストールされることが防止されます。
TarMK コールドスタンバイを使用している場合は、すべてのコールドスタンバイインスタンスを停止します。これをおこなうことにより、アップグレードで問題が発生した場合に、オンラインに効率よく戻ることができます。アップグレードが正常に完了したら、アップグレードされたプライマリインスタンスからコールドスタンバイインスタンスを再構築する必要があります。
アプリケーションコードに含まれている OSGi スケジュール済みジョブを無効にします。
この手順は、TarMK インストール環境でのみ必要となります。
TarMK を使用している場合は、アップグレードの前にオフラインでのリビジョンクリーンアップを実行してください。これにより、リポジトリの移行ステップが作成され、後続のアップグレードタスクがより迅速に実行されます。また、アップグレード完了後に、オンラインでのリビジョンクリーンアップが正常に実行されるようになります。オフラインでのリビジョンクリーンアップの実行について詳しくは、オフラインでのリビジョンクリーンアップの実行を参照してください。
この手順は、crx3 を実行するインスタンスにのみ必要です。
CRX3 インスタンスでリビジョンクリーンアップを実行した後は、データストアのガベージコレクションを実行して、データストア内の参照されていない blob を削除する必要があります。手順については、データストアのガベージコレクションに関するドキュメントを参照してください。
このアップグレード前のメンテナンスタスクは、次の場合にのみ必要です。
サービスユーザーが古い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.
この問題を回避するには、次の手順を実行します。
この問題を回避するには、次の手順を実行します。
通常、基盤となるApache OakスタックAEMで永続性を使用する場合は、必要に応じてデータベーススキーマのアップグレードが行われます。
ただし、スキーマを自動的にアップグレードできない場合があります。 これらは、ほとんどの場合、非常に限られた権限を持つユーザーの下でデータベースが実行される高いセキュリティ環境です。 この場合、AEMは古いスキーマを引き続き使用します。
このような状況を回避するには、次の手順に従ってスキーマをアップグレードする必要があります。
アップグレードが必要なAEMインスタンスをシャットダウンします。
データベーススキーマをアップグレードします。 この処理を行うために使用する必要のあるツールを確認するには、使用するデータベースの種類に関するドキュメントを参照してください。
Oakでのスキーマのアップグレードの処理方法について詳しくは、ApacheのWebサイト](https://jackrabbit.apache.org/oak/docs/nodestore/document/rdb-document-store.html#upgrade)の[このページを参照してください。
AEMのアップグレードを続行します。
アップグレードを開始する前に、現在のログファイルをアーカイブすることをお勧めします。これにより、アップグレード中やアップグレード後にログファイルを監視およびスキャンし、問題が発生した場合に問題を特定して解決することが容易になります。