アップグレード手順 upgrade-procedure

NOTE
ほとんどのAdobe Experience Manager(AEM) アップグレードはインプレースで実行されるので、アップグレードにはオーサー層のダウンタイムが必要です。 これらのベストプラクティスに従うことで、パブリッシュ層のダウンタイムを最小限に抑えたり、なくしたりできます。

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

TarMK オーサー層 tarmk-author-tier

トポロジの開始 starting-topology

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

tarmk_starting_topology

アップグレードの準備 upgrade-preparation

upgrade-preparation-author

  1. コンテンツのオーサリングを停止します。。

  2. スタンバイインスタンスを停止します。

  3. 作成者のレプリケーションエージェントを無効にします。

  4. を実行します。 アップグレード前のメンテナンスタスク.

アップグレードの実行 upgrade-execution

execute_upgrade

  1. インプレースアップグレードを実行します。。

  2. Dispatcher モジュールの更新 必要に応じて.

  3. QA がアップグレードを検証します。

  4. オーサーインスタンスをシャットダウンします。

成功した場合 if-successful

if_successful

  1. アップグレードしたインスタンスをコピーして、コールドスタンバイを作成します。

  2. オーサーインスタンスを起動します。

  3. スタンバイインスタンスを起動します。

失敗した場合(ロールバック) if-unsuccessful-rollback

rollback

  1. コールドスタンバイインスタンスを新しいプライマリとして起動します。。

  2. コールドスタンバイからオーサー環境を再構築します。

MongoMK オーサークラスター mongomk-author-cluster

トポロジの開始 starting-topology-1

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

mongo-topology

アップグレードの準備 upgrade-preparation-1

mongo-upgrade_prep

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

アップグレードの実行 Upgrade-execution-1

mongo-execution

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

成功した場合 if-successful-1

mongo-secondaries

  1. アップグレードされた Mongo インスタンスに接続する新しい 6.5 オーサーインスタンスを作成します。。

  2. クラスターから削除した MongoDB ノードを再構築します。

  3. を更新します。 DocumentNodeStoreService.cfg フルレプリカセットを反映するファイル。

  4. オーサーインスタンスを 1 つずつ再起動します。

  5. クローン作成されたデータストアを削除します。

失敗した場合(ロールバック) if-unsuccessful-rollback-2

mongo-rollback

  1. クローン作成されたデータストアに接続するために、セカンダリオーサーインスタンスを再設定します。。

  2. アップグレードしたオーサープライマリインスタンスをシャットダウンします。

  3. アップグレードされた Mongo プライマリインスタンスをシャットダウンします。

  4. セカンダリ Mongo インスタンスを起動し、そのうちの 1 つを新しいプライマリとして設定します。。

  5. を設定します。 DocumentNodeStoreService.cfg セカンダリオーサーインスタンス上のファイルが、まだアップグレードされていない Mongo インスタンスのレプリカセットを指している。

  6. セカンダリオーサーインスタンスを起動します。

  7. アップグレードされたオーサーインスタンス、Mongo ノード、データストアをクリーンアップします。

TarMK パブリッシュファーム tarmk-publish-farm

TarMK パブリッシュファーム tarmk-publish-farm-1

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

tarmk-pub-farmv5

アップグレードの実行 upgrade-execution-2

upgrade-publish2

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

成功した場合 if-successful-2

upgrade-publish1

  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 を検証します。

失敗した場合(ロールバック) if-unsuccessful-rollback-1

pub_rollback

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

アップグレードの最終手順 final-upgrade-steps

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

final

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