升级过程 upgrade-procedure

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

升级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和文件数据存储。 从Author服务器到TarMK Publish场的复制操作。

mongo-topology

升级准备 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节点和数据存储。

TarMKPublish农场 tarmk-publish-farm

TarMKPublish农场 tarmk-publish-farm-1

此部分假设的拓扑包含两个TarMK发布实例,这些实例由Dispatcher前导,这些实例又由负载平衡器前导。 从“创作”服务器到TarMK Publish场的复制操作。

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 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. 执行升级后检查

最终

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