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

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

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

作成対象：

  • 管理者
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 つ以上の MongoMK データベースを使用する 2 つ以上の AEM オーサーインスタンスを含む 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. アップグレードされていない Mongo インスタンスのレプリカセットを指すように、セカンダリオーサーインスタンスで DocumentNodeStoreService.cfg ファイルを設定します。

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

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

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

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

この節で想定されるトポロジは、ロードバランサーと Dispatcher を介して動作する 2 つの TarMK パブリッシュインスタンスで構成されています。オーサーサーバーから TarMK パブリッシュファームにレプリケーションが行われます。

tarmk-pub-farmv5

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

upgrade-publish2

  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 を起動します。

成功した場合 if-successful-2

upgrade-publish1

  1. Publish 1 へのトラフィックを有効にします。
  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 1 へのトラフィックを有効にします。

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

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

final

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