升級前維護任務

開始升級之前,請務必遵循這些維護任務,以確保系統已就緒,並且一旦出現問題,可以回滾:

確保足夠的磁碟空間

執行升級時,除了內容和程式碼升級活動外,還需執行存放庫移轉。 移轉會以新的區段Tar格式建立存放庫復本。 因此,您將需要足夠的磁碟空間來保留儲存庫的第二個版本(可能更大)。

完全備份AEM

AEM應在開始升級前完全備份。 請務必備份儲存庫、應用程式安裝、資料存放區和Mongo例項(如果適用)。 有關備份和還原AEM實例的詳細資訊,請參閱備份和還原

備份對/etc的更改

升級程式可妥善維護和合併存放庫/apps/libs路徑下的現有內容和設定。 若要變更/etc路徑(包括內容中樞設定),通常必須在升級後重新套用這些變更。 雖然升級會製作任何無法在/var下合併的更改的備份副本,但建議在開始升級前手動備份這些更改。

生成quickstart.properties檔案

從jar檔案啟動AEM時,將在crx-quickstart/conf下產生quickstart.properties檔案。 如果AEM過去只是使用啟動指令碼啟動,則此檔案將不存在,且升級將失敗。 請務必檢查此檔案是否存在,並從jar檔案重新啟動AEM(如果不存在)。

配置工作流和審核日誌清除

WorkflowPurgeTaskcom.day.cq.audit.impl.AuditLogMaintenanceTask任務需要單獨的OSGi配置,沒有它們將無法工作。 如果在升級前任務執行期間失敗,則最可能的原因是缺少配置。 因此,如果您不想執行這些任務,請務必為這些任務新增OSGi設定,或從升級前最佳化任務清單中完全移除這些設定。 可在管理工作流實例中找到配置工作流清除任務的文檔,並可在AEM 6的審核日誌維護中找到審核日誌維護任務配置。

有關CQ 5.6上的工作流和審核日誌清除以及AEM 6.0上的審核日誌清除,請參閱清除工作流和審核節點

安裝、配置和運行預升級任務

由於AEM允許的自訂層級,環境通常不會遵循執行升級的統一方式。 這使得建立標準化的升級程式成為一個困難的過程。

在舊版中,停止或無法安全恢復的AEM升級也相當困難。 這會導致需要重新啟動完整升級過程,或執行有缺陷的升級而未觸發任何警告的情況。

為了解決這些問題,Adobe已在升級程式中新增數項增強功能,使其更具彈性且方便使用。 必須手動執行的升級前維護任務正在優化和自動化。 此外,還添加了升級後報告,以便能夠充分審查該過程,希望更容易發現任何問題。

預升級維護任務目前分散在手動部分或完全執行的各種介面上。 AEM 6.3中推出的升級前維護最佳化可讓您以統一方式觸發這些工作,並可依需求檢查其結果。

升級前最佳化步驟中包含的所有工作都與AEM 6.0以後的所有版本相容。

如何設定

在AEM 6.3和更新版本中,升級前維護優化任務包含在quickstart Jar中。 如果您從舊版AEM 6升級,則可透過個別套件使用,而您可從套件管理器下載這些套件。

您可以在以下位置找到套件:

如何使用

PreUpgradeTasksMBean OSGI元件預配置了可一次運行的升級前維護任務清單。 您可以依照下列程式來設定工作:

  1. 瀏覽至​https://serveraddress:serverport/system/console/configMgr,前往Web主控台

  2. 搜尋「preupgradetasks」,然後按一下第一個相符的元件。 元件的全名為com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl

  3. 修改需要運行的維護任務清單,如下所示:

    1487758925984

任務清單會因用於啟動實例的運行模式而異。 以下是每個維護任務的運行模式描述。

任務 執行模式 附註
TarIndexMergeTask crx2
DataStoreGarbageCollectionTask crx2 將執行標籤和掃描。 對於共用資料儲存區,請刪除此步驟,然後手動運行
或在執行前正確準備實例。
ConsistencyCheckTask crx2
WorkflowPurgeTask crx2/crx3 在執行前,必須先設定AdobeGranite工作流程清除設定OSGi。
GenerateBundlesListFileTask crx2/crx3
RevisionCleanupTask crx3 對於AEM 6.0到6.2上的TarMK例項,請改為手動執行離線修訂清除。
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 運行前必須配置審核日誌清除計畫程式OSGi配置。
注意

DataStoreGarbageCollectionTask 正在調用帶有標籤和掃描階段的「資料儲存垃圾收集」操作(如果使用)。對於使用共用資料存放區的部署,請務必重新設定或正確準備執行個體,以避免刪除其他執行個體所參考的項目。 這可能需要在觸發此升級前任務之前,在所有實例上手動運行標籤階段。

升級前運行狀況檢查的預設配置

PreUpgradeTasksMBeanImpl OSGI元件預先設定了升級前健康狀況檢查標籤清單,可在呼叫runAllPreUpgradeHealthChecks方法時執行:

  • system - granite維護狀況檢查所使用的標籤

  • 預先升級 — 此為自訂標籤,可新增至您可設定在升級前執行的所有健全狀態檢查

清單是可編輯的。 您可以使用標籤以外的加號​(+)​和減號​(-)​按鈕來新增更多自訂標籤,或移除預設標籤。

MBean方法

可使用JMX控制台訪問托管Bean功能。

您可以通過以下方式訪問MBean:

  1. 前往​https://serveraddress:serverport/system/console/jmx​的JMX主控台

  2. 搜索​PreUpgradeTasks,然後按一下結果

  3. 從​Operations​節中選擇任何方法,並在以下窗口中選擇​Invoke

以下是PreUpgradeTasksMBeanImpl公開的所有可用方法的清單:

方法名稱 類型 說明
getAvailablePreUpgradeTasksNames() 資訊 顯示可用的升級前維護任務名稱清單。
getAvailablePreUpgradeHealthChecksTagNames() 資訊 顯示升級前運行狀況檢查標籤名稱的清單。
runAllPreUpgradeTasks() 動作 運行清單中的所有升級前維護任務。
runPreUpgradeTask(preUpgradeTaskName) 動作 以參數指定的名稱運行升級前維護任務。
isRunAllPreUpgradeTaskRunning() ACTION_INFO 檢查runAllPreUpgradeTasksmaintenance任務當前是否正在運行。
getAnyPreUpgradeTaskRunning() ACTION_INFO 檢查當前是否有任何升級前維護任務正在運行,並
返回包含當前運行任務名稱的陣列。
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) 動作 顯示升級前維護任務的確切運行時間,並將名稱指定為參數。
getPreUpgradeTaskLastRunState(preUpgradeTaskName) 動作 顯示升級前維護任務的最後運行狀態,並將名稱指定為參數。
runAllPreUpgradeHealthChecks(shutDownOnSuccess) 動作

運行所有預升級運行狀況檢查,並將其狀態保存在位於Sling主目錄路徑中名為preUpgradeHCStatus.properties的檔案中。 如果shutDownOnSuccess參數設為true,則AEM執行個體將關閉,但只有在所有預先升級的健康狀況檢查皆為「確定」狀態時才會關閉。

屬性檔案將用作任何將來升級
的先決條件,如果升級前運行狀況檢查
執行失敗,則升級過程將停止。 如果要忽略預升級
運行狀況檢查的結果,然後啟動升級,則可以刪除該檔案。

detectUsageOfUnavailableAPI(aemVersion) 動作 列出當
升級到指定的AEM版本時,將不再滿足的所有導入包。 目標AEM版本必須
指定為參數。
注意

MBean方法可通過以下方式調用:

  • JMX控制台
  • 連接到JMX的任何外部應用程式
  • cURL

禁用自定義登錄模組

注意

只有從AEM 5版本升級時才需要此步驟。 您可以完全略過此選項,以從舊版AEM 6升級。

自訂LoginModules在存放庫層級進行驗證的設定方式在Apache Oak中已根本改變。

在使用CRX2設定的AEM版本中,會放置在repository.xml檔案中,而從AEM 6開始,則會透過Web主控台在Apache Felix JAAS Configuration Factory服務中完成。

因此,升級後必須停用任何現有設定,並針對Apache Oak重新建立。

要禁用repository.xml的JAAS配置中定義的自定義模組,需要修改配置以使用預設LoginModule,如本示例所示:

<Security >
             ....
          <!--
                 Use LoginModule authenticating against repository itself
                 -->
                 <LoginModule class = "com.day.crx.core.CRXLoginModule" >
                     <param name = "anonymousId" value = "anonymous" />
                     <param name = "adminId" value ="admin" />
                     <param name = "disableNTLMAuth" value = "true" />
                     <param name = "tokenExpiration" value = "43200000" />
                     <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
                -->
                 </LoginModule >
         </ Security>
注意

如需詳細資訊,請參閱使用外部登入模組進行驗證

有關AEM 6中LoginModule配置的示例,請參閱使用AEM 6配置LDAP。

從/install目錄中刪除更新

注意

關閉AEM執行個體後,僅從crx-quickstart/install目錄中移除套件。 這是開始就地升級程式之前的最後步驟之一。

移除已透過本機檔案系統上crx-quickstart/install目錄部署的任何Service Pack、Feature Pack或Hotfix。 這可避免更新完成後,無意中將舊的Hotfix和Service Pack安裝在新的AEM版本之上。

停止任何冷備用實例

如果使用TarMK冷備,請停止任何冷備實例。 這將保證在升級中出現問題時,能以有效的方式重新上線。 成功完成升級後,需要從升級的主實例重建冷備用實例。

禁用自定義計畫作業

停用應用程式程式碼中包含的任何OSGi排程作業。

執行離線修訂清除

注意

此步驟僅對TarMK安裝是必要的

若使用TarMK,您應在升級前執行離線修訂清除。 這將使儲存庫遷移步驟和後續升級任務的執行速度更快,並有助於確保升級完成後線上修訂清除能夠成功執行。 有關運行離線修訂清除的資訊,請參閱執行離線修訂清除

執行資料儲存垃圾收集

注意

只有執行crx3的例項才需要此步驟

在CRX3例項上執行修訂清除後,您應執行「資料存放區垃圾收集」以移除資料存放區中任何未參考的Blob。 有關說明,請參閱資料儲存垃圾收集上的文檔。

如果需要,請升級資料庫架構

通常,用於永續性的基礎Apache Oak stack AEM會視需要負責升級資料庫架構。

但是,當無法自動升級架構時,可能會發生案例。 這些環境大多是高安全性的,資料庫在權限非常有限的用戶下運行。 如果發生此情況,AEM將繼續使用舊結構。

為避免發生此情況,您需依照下列程式升級結構:

  1. 關閉需要升級的AEM執行個體。

  2. 升級資料庫架構。 請查閱資料庫類型的文檔,以了解實現此目標所需的工具。

    如需Oak如何處理架構升級的詳細資訊,請參閱Apache網站🔗上的本頁。

  3. 繼續升級AEM。

刪除可能阻礙升級的用戶

注意

只有符合以下條件時才需要此升級前維護任務:

  • 您從AEM 6.3之前的版本升級
  • 在升級期間,您會遇到下列任何錯誤。

有些特殊情況下,服務使用者最終可能會遇到較舊的AEM版本,而未正確標示為一般使用者。

如果發生此情況,升級會失敗並出現下列訊息:

ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.

若要解決此問題,請務必執行下列動作:

  1. 將執行個體與生產流量分離

  2. 建立導致問題的用戶的備份。 您可以透過套件管理器完成此操作。 有關詳細資訊,請參閱如何使用包。

  3. 刪除導致問題的用戶。 以下是可能屬於此類別的使用者清單:

    1. dynamic-media-replication
    2. communities-ugc-writer
    3. communities-utility-reader
    4. communities-user-admin
    5. oauthservice
    6. sling-scripting

旋轉日誌檔案

建議您在開始升級之前先封存目前的記錄檔。 這樣,在升級期間和升級後就能更輕鬆地監視和掃描日誌檔案,以識別和解決可能發生的任何問題。

本頁內容