升級程式 upgrade-procedure

NOTE
由於大部分的Adobe Experience Manager (AEM)升級都會就地執行,因此升級作業需要製作層級的停機時間。 遵循這些最佳實務,您就能將Publish層級停機時間降到最低或完全消除。

升級AEM環境時,您必須考慮升級作者環境或發佈環境之間的方法差異,以將作者和一般使用者的停機時間減至最少。 此頁面概述升級AEM 6.x版本目前所執行AEM拓撲的高階程式。由於程式在製作和發佈層級,以及Mongo和TarMK型部署之間有所不同,因此每個層級和微核心都會列在單獨的區段中。 執行部署時,Adobe建議先升級作者環境、判斷是否成功,然後繼續發佈環境。

TarMK作者階層 tarmk-author-tier

正在啟動拓撲 starting-topology

此區段的假設拓撲包含在TarMK上執行且具有「冷待命」的Author伺服器。 從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. 啟動Author例項。

  3. 啟動待命執行個體。

如果失敗(回覆) if-unsuccessful-rollback

回覆

  1. 啟動「冷待命」執行處理作為新的「主要」。

  2. 從冷待命重新建置作者環境。

MongoMK作者叢集 mongomk-author-cluster

正在啟動拓撲 starting-topology-1

此段落的假設拓撲包含至少兩個AEM Author執行個體的MongoMK製作叢集,且支援至少兩個MongoMK資料庫。 所有作者執行個體都會共用資料存放區。 這些步驟應同時適用於S3和檔案資料存放區。 從Author伺服器到TarMK Publish伺服器陣列會進行復寫。

mongo-topology

升級準備 upgrade-preparation-1

mongo-upgrade_prep

  1. 停止內容製作。
  2. 複製資料存放區以進行備份。
  3. 停止所有,但一個AEM Author例項(您的主要作者)除外。
  4. 從復本集(您的主要Mongo執行個體)移除所有MongoDB節點,但一個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. 重新設定次要Author例項,以連線至複製的資料存放區。

  2. 關閉升級的作者主要執行個體。

  3. 關閉升級的Mongo主要執行個體。

  4. 啟動次要Mongo執行個體,並將其中一個執行個體作為新的主要執行個體。

  5. 設定次要Author執行個體上的DocumentNodeStoreService.cfg檔案,以指向尚未升級之Mongo執行個體的復本集。

  6. 啟動次要Author例項。

  7. 清理升級的作者執行個體、Mongo節點和資料存放區。

TarMK Publish農場 tarmk-publish-farm

TarMK Publish農場 tarmk-publish-farm-1

此區段的假設拓撲包含兩個TarMK發佈執行個體,由Dispatcher前導,而該前導又是負載平衡器。 從Author伺服器到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