アップグレード手順

AEM環境をアップグレードする際は、作成者とエンドユーザーの両方のダウンタイムを最小限に抑えるために、オーサー環境またはパブリッシュ環境のアップグレードのアプローチの違いを考慮する必要があります。 このページでは、AEM 6.x のバージョンで現在実行中のAEMトポロジをアップグレードするための高レベルの手順について説明します。このプロセスは、オーサー層とパブリッシュ層、Mongo と TarMK ベースのデプロイメントとで異なるので、各層とマイクロカーネルは別の節に記載されています。 デプロイメントを実行する場合は、まずオーサー環境をアップグレードし、成功を判断してから、パブリッシュ環境に進むことをお勧めします。

TarMK オーサー層

トポロジの開始

この節で想定されるトポロジは、TarMK 上で実行され、コールドスタンバイを使用するオーサーサーバーで構成されます。 オーサーサーバーから TarMK パブリッシュファームへのレプリケーションが発生します。 ここでは説明しませんが、この方法は、オフロードを使用するデプロイメントにも利用できます。 オーサーインスタンスでレプリケーションエージェントを無効にした後、再度有効にする前に、新しいバージョンでオフロードインスタンスをアップグレードまたは再構築してください。

アップグレードの準備

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

アップグレードの実行

1. インプレースアップグレードを実行します。
2. 必要に応じて、Dispatcher モジュールを更新します。
3. QA がアップグレードを検証します。
4. オーサーインスタンスをシャットダウンします。

成功した場合

1. 新しいコールドスタンバイを作成するために、アップグレードされたインスタンスをコピーします。
2. オーサーインスタンスを起動します。
3. スタンバイインスタンスを起動します。

失敗した場合（ロールバック）

1. コールドスタンバイインスタンスを新しいプライマリとして起動します。
2. コールドスタンバイからオーサー環境を再構築します。

MongoMK オーサークラスター

トポロジの開始

この節で想定されるトポロジは、少なくとも 2 つの MongoMK データベースをベースとする、2 つ以上の AEM オーサーインスタンスを持つ MongoMK オーサークラスターで構成されます。 すべてのオーサーインスタンスは 1 つのデータストアを共有します。 以下の手順は、S3 とファイルの両方のデータストアに適用する必要があります。 オーサーサーバーから TarMK パブリッシュファームへのレプリケーションが発生します。

アップグレードの準備

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

アップグレードの実行

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

成功した場合

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

失敗した場合（ロールバック）

1. クローン作成されたデータストアに接続するために、セカンダリオーサーインスタンスを再設定します。
2. アップグレードされたオーサープライマリインスタンスをシャットダウンします。
3. アップグレードされた Mongo プライマリインスタンスをシャットダウンします。
4. セカンダリ Mongo インスタンスを起動し、そのうちの 1 つを新しいプライマリとして設定します。
5. アップグレードされていない Mongo インスタンスのレプリカセットを指すように、セカンダリオーサーインスタンスで DocumentNodeStoreService.cfg ファイルを設定します。
6. セカンダリオーサーインスタンスを起動します。
7. アップグレードされたオーサーインスタンス、Mongo ノードおよびデータストアをクリーンアップします。

TarMK パブリッシュファーム

TarMK パブリッシュファーム

この節で想定されるトポロジは、2 つの TarMK パブリッシュインスタンスで構成され、Dispatcher がフロントし、ロードバランサーがフロントします。 オーサーサーバーから TarMK パブリッシュファームへのレプリケーションが発生します。

アップグレードの実行

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

成功した場合

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

失敗した場合（ロールバック）

1. Publish 1 のコピーを作成します。
2. Publish 2 インスタンスを Publish 1 のコピーに置き換えます。
3. Publish 2 の Dispatcher キャッシュをフラッシュします。
4. Publish 2 を起動します。
5. QA が、ファイアウォールの後ろにある Dispatcher を介して Publish 2 を検証します。
6. Publish 2 へのトラフィックを有効にします。

アップグレードの最終手順

1. Publish 1 へのトラフィックを有効にします。
2. QA がパブリック URL から最終検証を実行します。
3. オーサー環境からレプリケーションエージェントを有効にします。
4. コンテンツのオーサリングを再開します。
5. アップグレード後のチェックを実行します。

Business.Adobe.com リソース

Multichannel Communication Cms Cloud Dynamic Forms Digital Rights Management Headless Cms Digital Asset Management