Show Menu
トピック×

アップグレード手順

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

TarMK のオーサー層

トポロジの開始

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

アップグレードの準備

  1. コンテンツのオーサリングを停止します。
  2. スタンバイインスタンスを停止します。
  3. オーサーのレプリケーションエージェントを無効にします。

アップグレードの実行

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

成功した場合

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

If Unsuccessful (Rollback)

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

MongoMK オーサークラスター

トポロジの開始

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

アップグレードの準備

  1. コンテンツのオーサリングを停止します。
  2. バックアップ用のデータストアのクローンを作成します。
  3. 1 つの AEM オーサーインスタンス(プライマリオーサー)以外をすべて停止します。
  4. 1つを除くすべてのMongoDBノードをレプリカセットから削除します。プライマリMongoインスタンスです
  5. Update the DocumentNodeStoreService.cfg file on the primary Author to reflect your single member replica set
  6. プライマリオーサーを再起動して、正常に再起動することを確認します。
  7. プライマリオーサーのレプリケーションエージェントを無効にします。
  8. プライマリオーサーインスタンスで アップグレード前のメンテナンスタスク を実行します。
  9. 必要に応じて、プライマリ Mongo インスタンスの MongoDB を WiredTiger が搭載されたバージョン 3.2 にアップグレードします。

アップグレードの実行

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

成功した場合

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

If Unsuccessful (Rollback)

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

TarMK パブリッシュファーム

TarMK パブリッシュファーム

この節で想定されるトポロジは、ロードバランサーと Dispatcher を介して動作する 2 つの TarMK パブリッシュインスタンスで構成されています。オーサーサーバーから 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 を検証します。

If Unsuccessful (Rollback)

  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. コンテンツのオーサリングを再開します。