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

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

• 十分なディスク領域の確保
• AEM の完全なバックアップ
• /etc に対する変更のバックアップ
• quickstart.properties ファイルの生成
• ワークフローおよび監査ログのパージの設定
• アップグレード前のタスクのインストール、設定および実行
• カスタムログインモジュールの無効化
• /install ディレクトリからの更新の削除
• すべてのコールドスタンバイインスタンスの停止
• カスタムのスケジュール済みジョブの無効化
• オフラインでのリビジョンクリーンアップの実行
• データストアのガベージコレクションの実行
• 必要に応じてデータベーススキーマをアップグレードする
• アップグレードを妨げる可能性のあるユーザーの削除
• ログファイルのローテーション

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

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

AEM の完全なバックアップ

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

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

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

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 の古いバージョンからアップグレードする場合、この最適化タスクは、パッケージマネージャーからダウンロードできる個別のパッケージを介して利用できます。

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

• AEM 6.0 からアップグレードする場合

• AEM 6.1 からアップグレードする場合

• AEM 6.2 からアップグレードする場合

使用方法

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

1. https://serveraddress:serverport/system/console/configMgrを参照してWebコンソールに移動

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

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

   

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

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

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

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

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

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

MBean メソッド

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

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

1. JMXコンソール(https://serveraddress:serverport/system/console/jmx)に移動します。

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

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

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

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

リポジトリレベルでの認証用にカスタム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>

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

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

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

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

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

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

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

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

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

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.

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

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

• インスタンスを実稼動トラフィックから切り離す
• 問題の原因となるユーザーのバックアップを作成します。 これは、Package Managerで行うことができます。 詳しくは、パッケージの使い方を参照してください。
• 問題の原因となっているユーザーを削除します。 以下は、このカテゴリに該当する可能性のあるユーザーのリストです。
  • dynamic-media-replication
  • communities-ugc-writer
  • communities-utility-reader
  • communities-user-admin
  • oauthservice
  • sling-scripting

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

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

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

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

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

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

   Oakでのスキーマのアップグレードの処理方法について詳しくは、ApacheのWebサイト](https://jackrabbit.apache.org/oak/docs/nodestore/document/rdb-document-store.html#upgrade)の[このページを参照してください。

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

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

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