ドキュメントAEM 6.5ユーザーガイド

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

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
  • トピック：

作成対象：

  • 管理者

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

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

  • AEM の完全なバックアップ

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

  • quickstart.properties ファイルの生成

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

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

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

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

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

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

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

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

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

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

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

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

アップグレードを実行する際には、コンテンツとコードのアップグレードアクティビティに加えて、リポジトリの移行を実行する必要があります。この移行により、新しいセグメント Tar 形式でリポジトリのコピーが作成されます。その結果、大容量になり得るリポジトリの 2 番目のバージョンを保持するために十分なディスク領域が必要になります。

AEM の完全なバックアップ

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

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

アップグレードプロセスは、リポジトリの /apps パスおよび /libs パスの下にある既存のコンテンツおよび設定のメンテナンスやマージに役立ちます。Context Hub 設定などの /etc パスに加えられた変更は、多くの場合、アップグレード後に再適用する必要があります。アップグレードにより、マージできない変更のバックアップコピーが /var の下に作成されますが、アップグレードの開始前にこれらの変更を手動でバックアップすることをお勧めします。

quickstart.properties ファイルの生成

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

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

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

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

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

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

以前のバージョンでは、停止または失敗した AEM アップグレードを安全に再開することも困難でした。この問題により、完全なアップグレード手順の再開が必要になったり、警告が表示されずに不完全なアップグレードが実行されたりすることがありました。

これらの問題に対処するために、アドビはアップグレードプロセスにいくつかの拡張機能を追加し、より柔軟で使いやすくしました。以前は手動で実行する必要があった、アップグレード前のメンテナンスタスクの最適化と自動化が進められています。また、アップグレード後のレポートを追加して、プロセスを完全に調べて問題を見つけやすくしました。

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

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

設定方法

AEM 6.3 以降では、アップグレード前のメンテナンス最適化タスクが quickstart jar に含まれています。

使用方法

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

  1. https://serveraddress:serverport/system/console/configMgr にブラウジングして web コンソールに移動

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

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

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

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

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

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

MBean メソッド

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

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

  1. JMX コンソール（https://serveraddress:serverport/system/console/jmx）に移動

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

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

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

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

アップグレード前のすべてのヘルスチェックを実行して、sling ホームパスにある preUpgradeHCStatus.properties というファイルにそれらのステータスを保存します。shutDownOnSuccess パラメーターが true に設定されていると、AEM インスタンスがシャットダウンされますが、これはアップグレード前のすべてのヘルスチェックのステータスが OK の場合のみです。

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

detectUsageOfUnavailableAPI(aemVersion)
アクション
指定された AEM バージョンにアップグレードしたときに適合しなくなる
すべての読み込み済みパッケージをリストします。ターゲットの AEM バージョンは、
パラメーターとして指定する必要があります。
NOTE
MBean メソッドは、以下から呼び出すことができます。
  • JMX コンソール
  • JMX に接続する外部アプリケーション
  • cURL

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

NOTE
この手順は、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>
NOTE
詳しくは、外部ログインモジュールによる認証を参照してください。
AEM 6 での LoginModule 設定例については、AEM 6 での LDAP の設定を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通常、AEM が永続性の処理に使用する基礎的な Apache Oak スタックは、必要に応じてデータベーススキーマのアップグレードに対処します。

ただし、スキーマを自動的にアップグレードできない場合も考えられます。それは、ほとんどの場合、権限が限られているユーザーの下でデータベースが実行されている、セキュリティレベルの高い環境です。このような状況が発生した場合、AEM は引き続き古いスキーマを使用します。

このようなシナリオが発生しないようにするには、次の手順を実行してスキーマをアップグレードします。

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

  2. データベーススキーマをアップグレードします。この結果を達成するために必要なツール確認するには、データベースのタイプに関するドキュメントを参照してください。

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

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

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

NOTE
このアップグレード前のメンテナンスタスクは、次の場合にのみ必要です。
  • 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. 問題の原因となっている 1 人以上のユーザーのバックアップを作成します。バックアップの作成は、パッケージマネージャーから実行できます。詳しくは、パッケージの使用方法を参照してください。

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

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

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

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

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2