升级过程 upgrade-procedure

NOTE
由于大多数Adobe Experience Manager (AEM)升级都是在就地执行的,因此升级需要创作层停机。 通过遵循这些最佳实践,您可以最大限度地减少或消除发布层停机时间。

升级AEM环境时,必须考虑升级创作环境或发布环境之间方法上的差异,以最大程度地减少创作和最终用户的停机时间。 此页概述了升级AEM 6.x版本上当前运行的AEM拓扑的高级过程。由于该过程在创作层和发布层以及基于Mongo和TarMK的部署中有所不同,因此每个层和微内核都列在单独的部分中。 在执行部署时,Adobe建议首先升级创作环境,确定是否成功,然后继续发布环境。

TarMK创作层 tarmk-author-tier

开始拓扑 starting-topology

此部分的假设拓扑包含在TarMK上运行的带有冷备用的Author服务器。 从创作服务器复制到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

回滚

  1. 启动冷备用实例作为新的主实例。

  2. 从冷备用重新构建创作环境。

MongoMK创作聚类 mongomk-author-cluster

开始拓扑 starting-topology-1

此部分的假设拓扑包含一个MongoMK创作聚类,其中至少具有两个AEM Author实例,并至少由两个MongoMK数据库支持。 所有创作实例都共享数据存储。 这些步骤应同时适用于S3和文件数据存储。 从创作服务器到TarMK发布场的复制操作。

蒙戈拓扑

升级准备 upgrade-preparation-1

mongo-upgrade_prep

  1. 停止内容创作。
  2. 克隆数据存储以进行备份。
  3. 停止所有AEM创作实例,但停止一个主要作者。
  4. 从副本集(您的主Mongo实例)中删除除一个MongoDB节点之外的所有节点。
  5. 更新 DocumentNodeStoreService.cfg 文件,以反映单个成员副本集。
  6. 重新启动主要作者以确保其正确重新启动。
  7. 在主创作实例上禁用复制代理。
  8. 运行 升级前维护任务 在主创作实例上。
  9. 如有必要,请使用WiredTiger将主Mongo实例上的MongoDB升级到版本3.2。

升级执行 Upgrade-execution-1

mongo-execution

  1. 运行 就地升级 在主作者上。
  2. 更新Dispatcher或Web模块 如果需要.
  3. QA验证升级。

如果成功 if-successful-1

mongo-secondaries

  1. 创建新的6.5创作实例,这些实例连接到升级的Mongo实例。

  2. 重建从群集中删除的MongoDB节点。

  3. 更新 DocumentNodeStoreService.cfg 文件以反映完整的复制副本集。

  4. 每次重新启动一个创作实例。

  5. 删除克隆的数据存储。

如果失败(回滚) if-unsuccessful-rollback-2

mongo-rollback

  1. 重新配置辅助创作实例以连接到克隆的数据存储。

  2. 关闭已升级的创作主实例。

  3. 关闭已升级的Mongo主实例。

  4. 启动辅助Mongo实例,并将其中一个实例作为新的主实例。

  5. 配置 DocumentNodeStoreService.cfg 辅助创作实例上的文件指向尚未升级的Mongo实例的副本集。

  6. 启动辅助创作实例。

  7. 清理升级的创作实例、Mongo节点和数据存储。

TarMK发布场 tarmk-publish-farm

TarMK发布场 tarmk-publish-farm-1

此部分假设的拓扑包含两个TarMK发布实例,这些实例由Dispatcher前导,这些实例又由负载平衡器前导。 从创作服务器到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. 关闭发布2。
  8. 复制发布2实例。
  9. 启动Publish 2.

如果成功 if-successful-2

upgrade-publish1

  1. 启用流量以发布2。
  2. 停止流向Publish 1。
  3. 停止发布1实例。
  4. 将发布1实例替换为发布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实例替换为发布1的副本。
  3. 刷新Publish 2的Dispatcher缓存。
  4. 启动Publish 2.
  5. QA通过防火墙后面的Dispatcher验证Publish 2。
  6. 启用流量以发布2。

最终升级步骤 final-upgrade-steps

  1. 启用流量以发布1。
  2. QA从公共URL执行最终验证。
  3. 从创作环境启用复制代理。
  4. 继续内容创作。
  5. 执行 升级后检查.

最终

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