アップグレード手順
メモ
ほとんどの AEM のアップグレードはインプレースで実行されるので、アップグレードにはオーサー層のダウンタイムが必要になります。これらのベストプラクティスに従うことによって、パブリッシュ層のダウンタイムを最小限に抑えたり、排除したりすることができます。
AEM 環境をアップグレードする場合は、作成者とエンドユーザーのダウンタイムを最小化するために、オーサー環境とパブリッシュ環境のアップグレードのアプローチの違いを考慮する必要があります。このページでは、AEM 6.x のバージョンで現在実行されている AEM トポロジをアップグレードする手順の概要を説明します。オーサー層とパブリッシュ層および Mongo ベースと TarMK ベースのデプロイメントではプロセスが異なるので、各層およびマイクロカーネルは個別の節に記載されています。デプロイメントを実行するときは、最初にオーサー環境をアップグレードし、成功を確認してから、パブリッシュ環境をアップグレードすることをお勧めします。
TarMK のオーサー層
トポロジの開始
この節で想定されるトポロジは、TarMK で実行されているオーサーサーバーとコールドスタンバイで構成されています。オーサーサーバーから TarMK パブリッシュファームにレプリケーションがおこなわれます。ここには示されていませんが、このアプローチは、オフロードを使用するデプロイメントでも活用できます。オーサーインスタンスでレプリケーションエージェントを無効にして再度有効にする前に、新しいバージョンでオフロードインスタンスをアップグレードまたは再構築してください。

アップグレードの準備

- コンテンツのオーサリングを停止します。
- スタンバイインスタンスを停止します。
- オーサーのレプリケーションエージェントを無効にします。
- アップグレード前のメンテナンスタスクを実行します。
アップグレードの実行

- インプレースアップグレードを実行します。
- 必要に応じて、Dispatcher モジュールを更新します。
- QA がアップグレードを検証します。
- オーサーインスタンスをシャットダウンします。
成功した場合

- 新しいコールドスタンバイを作成するために、アップグレードされたインスタンスをコピーします。
- オーサーインスタンスを起動します。
- スタンバイインスタンスを起動します。
失敗した場合(ロールバック)

- コールドスタンバイインスタンスを新しいプライマリとして起動します。
- コールドスタンバイからオーサー環境を再構築します。
MongoMK オーサークラスター
トポロジの開始
この節で想定されるトポロジは、2 つ以上の MongoMK データベースを使用する 2 つ以上の AEM オーサーインスタンスを含む MongoMK オーサークラスターで構成されています。すべてのオーサーインスタンスは 1 つのデータストアを共有します。以下の手順は、S3 データストアとファイルデータストアの両方に適用できます。オーサーサーバーから TarMK パブリッシュファームへのレプリケーションが発生します。

アップグレードの準備

- コンテンツのオーサリングを停止します。
- バックアップ用のデータストアのクローンを作成します。
- 1 つの AEM オーサーインスタンス(プライマリオーサー)以外をすべて停止します。
- レプリカセットから 1 つの MongoDB ノード(プライマリ Mongo インスタンス)以外をすべて削除します。
- 単一メンバーのセカンダリセットが反映されるように、プライマリ作成者上の
DocumentNodeStoreService.cfg
ファイルをアップデートします。
- プライマリオーサーを再起動して、正常に再起動することを確認します。
- プライマリオーサーのレプリケーションエージェントを無効にします。
- プライマリオーサーインスタンスでアップグレード前のメンテナンスタスクを実行します。
- 必要に応じて、プライマリ Mongo インスタンスの MongoDB を WiredTiger が搭載されたバージョン 3.2 にアップグレードします。
アップグレードの実行

- プライマリオーサーでインプレースアップグレードを実行します。
- 必要に応じて、Dispatcher モジュールまたは Web モジュールを更新します。
- QA がアップグレードを検証します。
成功した場合

- アップグレードされた Mongo インスタンスに接続する新しい 6.3 オーサーインスタンスを作成します。
- クラスターから削除された MongoDB ノードを再構築します。
- レプリカのフルセットが反映されるように、
DocumentNodeStoreService.cfg
ファイルを更新します。
- オーサーインスタンスを 1 つずつ再起動します。
- クローン作成されたデータストアを削除します。
失敗した場合(ロールバック)

- クローン作成されたデータストアに接続するために、セカンダリオーサーインスタンスを再設定します。
- アップグレードされたオーサープライマリインスタンスをシャットダウンします。
- アップグレードされた Mongo プライマリインスタンスをシャットダウンします。
- セカンダリ Mongo インスタンスを起動し、そのうちの 1 つを新しいプライマリとして設定します。
- アップグレードされていない Mongo インスタンスのレプリカセットを指すように、セカンダリオーサーインスタンスで
DocumentNodeStoreService.cfg
ファイルを設定します。
- セカンダリオーサーインスタンスを起動します。
- アップグレードされたオーサーインスタンス、Mongo ノードおよびデータストアをクリーンアップします。
TarMK パブリッシュファーム
TarMK パブリッシュファーム
この節で想定されるトポロジは、ロードバランサーと Dispatcher を介して動作する 2 つの TarMK パブリッシュインスタンスで構成されています。オーサーサーバーから TarMK パブリッシュファームにレプリケーションがおこなわれます。

アップグレードの実行

- ロードバランサーで Publish 2 インスタンスへのトラフィックを停止します。
- Publish 2 でアップグレード前のメンテナンスタスクを実行します。
- Publish 2 でインプレースアップグレードを実行します。
- 必要に応じて、Dispatcher モジュールまたは Web モジュールを更新します。
- Dispatcher キャッシュをフラッシュします。
- QA が、ファイアウォールの後ろにある Dispatcher を介して Publish 2 を検証します。
- Publish 2 をシャットダウンします。
- Publish 2 インスタンスをコピーします。
- Publish 2 を起動します。
成功した場合

- Publish 2 へのトラフィックを有効にします。
- Publish 1 へのトラフィックを停止します。
- Publish 1 インスタンスを停止します。
- Publish 1 インスタンスを Publish 2 のコピーに置き換えます。
- 必要に応じて、Dispatcher モジュールまたは Web モジュールを更新します。
- Publish 1 の Dispatcher キャッシュをフラッシュします。
- Publish 1 を起動します。
- QA が、ファイアウォールの後ろにある Dispatcher を介して Publish 1 を検証します。
失敗した場合(ロールバック)

- Publish 1 のコピーを作成します。
- Publish 2 インスタンスを Publish 1 のコピーに置き換えます。
- Publish 2 の Dispatcher キャッシュをフラッシュします。
- Publish 2 を起動します。
- QA が、ファイアウォールの後ろにある Dispatcher を介して Publish 2 を検証します。
- Publish 2 へのトラフィックを有効にします。
アップグレードの最終手順
- Publish 1 へのトラフィックを有効にします。
- QA がパブリック URL から最終検証を実行します。
- オーサー環境からレプリケーションエージェントを有効にします。
- コンテンツのオーサリングを再開します。
- アップグレード後のチェックを実行します。

Business.Adobe.com リソース