升級程式 upgrade-procedure

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

升級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發佈伺服器陣列會進行復寫。

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或網頁模組 如有需要.
  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. 設定 DocumentNodeStoreService.cfg 次要Author執行個體上的檔案,以指向尚未升級之Mongo執行個體的復本集。

  6. 啟動次要Author例項。

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

TarMK發佈陣列 tarmk-publish-farm

TarMK發佈陣列 tarmk-publish-farm-1

此區段的假設拓撲包含兩個TarMK發佈執行個體,由Dispatcher前導,而該前導又是負載平衡器。 從Author伺服器到TarMK Publish伺服器陣列會進行復寫。

tarmk-pub-farmv5

升級執行 upgrade-execution-2

upgrade-publish2

  1. 在負載平衡器處停止流向發佈2執行個體的流量。
  2. 執行 升級前維護 位於「發佈2」。
  3. 執行 就地升級 位於「發佈2」。
  4. 更新Dispatcher或網頁模組 如有需要.
  5. 排清Dispatcher快取。
  6. QA會透過防火牆後面的Dispatcher驗證Publish 2。
  7. 關閉發佈2。
  8. 複製Publish 2執行個體。
  9. 開始發佈2.

如果成功 if-successful-2

upgrade-publish1

  1. 啟用流量以發佈2。
  2. 停止流向發佈1的流量。
  3. 停止Publish 1執行個體。
  4. 以Publish 2的副本取代Publish 1執行個體。
  5. 更新Dispatcher或網頁模組 如有需要.
  6. 排清Publish 1的Dispatcher快取。
  7. 開始發佈1。
  8. QA會透過防火牆後面的Dispatcher驗證Publish 1。

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

pub_rollback

  1. 建立Publish 1的復本。
  2. 以Publish 1的副本取代Publish 2執行個體。
  3. 排清Publish 2的Dispatcher快取。
  4. 開始發佈2.
  5. QA會透過防火牆後面的Dispatcher驗證Publish 2。
  6. 啟用流量以發佈2。

最終升級步驟 final-upgrade-steps

  1. 啟用流量以發佈1。
  2. QA會從公用URL執行最終驗證。
  3. 從製作環境啟用復寫代理程式。
  4. 繼續內容製作。
  5. 執行 升級後檢查.

final

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