Wartungsaufgaben vor einem Upgrade pre-upgrade-maintenance-tasks

CAUTION
AEM 6.4 hat das Ende der erweiterten Unterstützung erreicht und diese Dokumentation wird nicht mehr aktualisiert. Weitere Informationen finden Sie in unserer technische Unterstützung. Unterstützte Versionen suchen here.

Bevor Sie mit dem Upgrade beginnen, ist es wichtig, die folgenden Wartungsaufgaben durchzuführen, damit das System bereit ist und zurückgesetzt werden kann, falls Probleme auftreten:

Überprüfung auf ausreichenden Festplattenspeicher ensure-sufficient-disk-space

Wenn Sie das Upgrade durchführen, ist zusätzlich zur Aktualisierung von Inhalt und Code auch eine Migration des Repositorys erforderlich. Durch die Migration wird eine Kopie des Repositorys im neuen Segment-TAR-Format erstellt. Daher benötigen Sie genügend Speicherplatz, um eine zweite, möglicherweise größere Version Ihres Repositorys beizubehalten.

Vollständige Sicherung von AEM fully-back-up-aem

Bevor Sie mit dem Upgrade beginnen, sollten Sie eine vollständige Sicherungskopie von AEM erstellen. Stellen Sie sicher, dass Sie Ihr Repository, Ihre Anwendungsinstallation, Ihren Datenspeicher und gegebenenfalls Ihre Mongo-Instanzen sichern. Weitere Informationen zum Sichern und Wiederherstellen einer AEM-Instanz finden Sie unter Sicherung und Wiederherstellung.

Sicherung von Änderungen unter /etc backup-changes-etc

Ein Upgrade ist ein guter Anlass, um vorhandene Inhalte und Konfigurationen unter den Pfaden /apps und /libs im Repository zu pflegen und zusammenzuführen. Änderungen am Pfad /etc, einschließlich Context-Hub-Konfigurationen, müssen oft nach einem Upgrade neu angewendet werden. Beim Upgrade wird zwar eine Sicherungskopie aller Änderungen, die nicht zusammengeführt werden können, unter /var erstellt. Wir empfehlen aber trotzdem, diese Änderungen vor dem Upgrade manuell zu sichern.

Erstellen der quickstart.properties-Datei generate-quickstart-properties

Wenn Sie AEM von einer JAR-Datei aus starten, wird eine quickstart.properties-Datei unter crx-quickstart/conf erstellt. Falls AEM bisher nur mit dem Startskript gestartet wurde, ist diese Datei nicht vorhanden und das Upgrade schlägt fehl. Überprüfen Sie, ob diese Datei vorhanden ist, und starten Sie AEM aus der JAR-Datei neu, falls sie nicht vorhanden ist.

Konfigurieren von Workflow- und Auditprotokoll-Löschung configure-wf-audit-purging

Für die Aufgaben WorkflowPurgeTask und com.day.cq.audit.impl.AuditLogMaintenanceTask sind separate OSGi-Konfigurationen erforderlich, sonst werden diese nicht ausgeführt. Falls diese Aufgaben beim Ausführen von Aufgaben vor dem Upgrade fehlschlagen, sind die Ursache dafür wahrscheinlich fehlende Konfigurationen. Daher müssen Sie die OSGi-Konfigurationen für diese Aufgaben hinzufügen oder diese Aufgaben vollständig aus der Liste der Optimierungsaufgaben vor dem Upgrade löschen, falls Sie diese nicht ausführen möchten. Die Dokumentation zum Konfigurieren von Workflow-Bereinigungsaufgaben finden Sie unter Verwalten von Workflow-Instanzen Die Konfiguration der Wartungsaufgaben im Auditprotokoll finden Sie unter Auditprotokollwartung in AEM 6.

Informationen zu Workflow- und Auditprotokolllöschungen in CQ 5.6 sowie zur Bereinigung von Auditprotokollen in AEM 6.0 finden Sie unter Workflow- und Auditknoten bereinigen.

Installieren, Konfigurieren und Ausführen der Aufgaben vor dem Upgrade install-configure-run-pre-upgrade-tasks

Da AEM ein hohes Maß an Anpassung erlaubt, gibt es in der Regel keine einheitliche Vorgehensweise für die Durchführung von Upgrades. Es ist deshalb schwierig, ein standardisiertes Verfahren für Upgrades zu entwickeln.

In vorherigen Versionen war es zudem problematisch, gestoppte oder fehlgeschlagene AEM-Upgrades wieder sicher fortzusetzen. Dies führte zu Situationen, in denen das Upgrade komplett neu gestartet werden musste oder defekte Upgrades durchgeführt wurden, ohne dass Warnungen ausgelöst wurden.

Um diese Probleme zu beheben, hat Adobe einige Verbesserungen am Upgrade-Prozess vorgenommen, sodass dieser jetzt ausfallsicherer und benutzerfreundlicher ist. Wartungsaufgaben vor einem Upgrade, die bisher manuell durchgeführt werden mussten, wurden optimiert und automatisiert. Darüber hinaus wurden Berichte hinzugefügt, die nach dem Upgrade erstellt werden, sodass der Vorgang umfassend überprüft werden kann und Probleme einfach identifizierbar sind.

Die Wartungsaufgaben vor einem Upgrade sind derzeit auf verschiedene Benutzeroberflächen verteilt und werden teilweise oder vollständig manuell durchgeführt. Durch die in AEM 6.3 eingeführte Optimierungsfunktionen für die Wartungsaufgaben im Vorfeld des Upgrades können diese Aufgaben einheitlich ausgelöst und ihre Ergebnisse bei Bedarf überprüft werden.

Sämtliche Aufgaben, die zum Optimierungsschritt vor dem Upgrade gehören, sind mit allen Versionen (ab Version 6.0) kompatibel.

Einrichtung how-to-set-it-up

In AEM 6.3 und höher ist die Optimierung der Wartungsaufgaben vor einem Upgrade Teil der quickstart-Datei. Bei einem Upgrade von älteren AEM 6-Versionen ist sie über separate Pakete verfügbar, die Sie von Package Manager herunterladen können.

Die Pakete finden Sie hier:

Verwendung how-to-use-it

Die OSGi-Komponente PreUpgradeTasksMBean ist mit einer Liste von Wartungsaufgaben vor dem Upgrade vorkonfiguriert, die gleichzeitig ausgeführt werden können. Sie können die Aufgaben mit den nachfolgenden Schritten konfigurieren:

  1. Navigieren Sie zur Web-Konsole , indem Sie zu https://serveraddress:serverport/system/console/configMgr

  2. Suchen Sie nach preupgradetasks und klicken Sie auf die erste übereinstimmende Komponente. Der vollständige Name der Komponenten lautet com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl.

  3. Ändern Sie die Liste der auszuführenden Wartungsaufgaben wie unten gezeigt:

    1487758925984

Die Aufgabenliste unterscheidet sich je nach dem verwendeten Ausführungsmodus zum Starten der Instanz. Nachfolgend finden Sie eine Beschreibung des Ausführungsmodus, für den jede Wartungsaufgabe entwickelt wurde.

Aufgabe
Ausführungsmodus
Anmerkungen
TarIndexMergeTask
crx2
DataStoreGarbageCollectionTask
crx2
Läuft markieren und kehren. Entfernen Sie bei freigegebenen Datenspeichern diesen Schritt und führen Sie
-Instanzen manuell oder ordnungsgemäß vorbereiten, bevor sie ausgeführt werden.
ConsistencyCheckTask
crx2
WorkflowPurgeTask
crx2/crx3
Vor der Ausführung muss die Adobe Granite Workflow Purge Configuration OSGi konfiguriert werden.
GenerateBundlesListFileTask
crx2/crx3
RevisionCleanupTask
crx3
Führen Sie bei TarMK-Instanzen unter AEM 6.0 bis 6.2 stattdessen die Offline-Revisionsbereinigung manuell aus.
com.day.cq.audit.impl.AuditLogMaintenanceTask
crx3
Vor der Ausführung muss die OSGi-Konfiguration für die Auditprotokolllöschung konfiguriert werden.
CAUTION
Die Aufgabe DataStoreGarbageCollectionTask ruft einen Vorgang zur Datenspeicherbereinigung mit der Mark- und Sweep-Phase auf, falls sie verwendet wird. Bei Bereitstellungen mit einem freigegebenen Datenspeicher muss dieser entweder neu konfiguriert oder die Instanz ordnungsgemäß vorbereitet werden, um das Löschen von Elementen, auf die andere Instanzen verweisen, zu vermeiden. Hierzu muss die Mark-Phase möglicherweise auf allen Instanzen manuell ausgeführt werden, bevor diese Aufgabe vor einem Upgrade ausgelöst wird.

Standardkonfiguration der Konsistenzprüfungen vor einem Upgrade default-configuration-of-the-pre-upgrade-health-checks

Die OSGi-Komponente PreUpgradeTasksMBeanImpl umfasst eine vorkonfigurierte Liste von Tags für Konsistenzprüfungen vor einem Upgrade, die ausgeführt werden sollen, wenn die Methode runAllPreUpgradeHealthChecks aufgerufen wird:

  • System - das Tag, das von den Wartungs-Konsistenzprüfungen für Granite verwendet wird

  • pre-upgrade  – Ein benutzerdefiniertes Tag, das Sie allen Konsistenzprüfungen hinzufügen können, deren Ausführung vor einem Upgrade festgelegt werden können.

Die Liste kann bearbeitet werden. Sie können das Pluszeichen (+) und minus (-) -Schaltflächen neben den Tags, um weitere benutzerdefinierte Tags hinzuzufügen oder die standardmäßigen Tags zu entfernen.

MBean-Methoden

Auf die Funktion für verwaltete Beans kann über die JMX-Konsole.

Sie können wie folgt auf die MBeans zugreifen:

  1. Wechseln Sie zur JMX-Konsole unter  https://Server-Adresse:Serverport/system/console/jmx.

  2. Suchen Sie nach PreUpgradeTasks und klicken Sie auf das Ergebnis.

  3. Wählen Sie im Bereich Operations eine Methode und im daraufhin angezeigten Fenster Invoke aus.

Nachfolgend finden Sie eine Liste aller verfügbaren Methoden, die von PreUpgradeTasksMBeanImpl bereitgestellt werden:

Name der Methode
Typ
Beschreibung
getAvailablePreUpgradeTasksNames()
INFO
Zeigt die Namensliste der verfügbaren Wartungsaufgaben vor dem Upgrade an.
getAvailablePreUpgradeHealthChecksTagNames()
INFO
Zeigt die Namensliste Liste der Konsistenzprüfungen vor dem Upgrade an.
runAllPreUpgradeTasks()
ACTION
Führt alle in der Liste genannten Wartungsaufgaben vor dem Upgrade aus.
runPreUpgradeTask(preUpgradeTaskName)
ACTION
Führt die Wartungsaufgabe vor dem Upgrade mit dem als Parameter angegebenen Namen aus.
isRunAllPreUpgradeTaskRunning()
ACTION_INFO
Überprüft, ob die runAllPreUpgradeTasksmaintenance-Aufgabe gerade ausgeführt wird.
getAnyPreUpgradeTaskRunning()
ACTION_INFO
Überprüft, ob gerade Wartungsaufgaben vor dem Upgrade ausgeführt werden und
gibt ein Array mit den Namen der gerade ausgeführten Aufgaben aus.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName)
ACTION
Gibt die genaue Ausführungszeit der Wartungsaufgaben vor dem Upgrade mit dem Namen als Parameter an.
getPreUpgradeTaskLastRunState(preUpgradeTaskName)
ACTION
Gibt den letzten Ausführungsstatus der Wartungsaufgabe vor dem Upgrade mit dem Namen als Parameter an.
runAllPreUpgradeHealthChecks(shutDownOnSuccess)
ACTION

Führt alle Konsistenzprüfungen vor der Aktualisierung aus und speichert deren Status in der Datei preUpgradeHCStatus.properties, die im Sling-Stammpfad gespeichert ist. Wenn der Parameter shutDownOnSuccess auf true gesetzt ist, wird die AEM-Instanz heruntergefahren, allerdings nur, wenn der Status für alle Konsistenzprüfungen vor einem Upgrade „OK“ lautet.

Die Eigenschaftendatei wird als Vorbedingung für zukünftige Upgrades verwendet
und der Upgrade-Vorgang wird angehalten, wenn die Konsistenzprüfungen vor eines Upgrades
fehlgeschlagen sind. Wenn Sie das Ergebnis der Konsistenzprüfungen
vor einem Upgrade ignorieren und das Upgrade trotzdem starten möchten, können Sie die Datei löschen.

detectUsageOfUnavailableAPI(aemVersion)
ACTION
Listet alle importierten Pakete auf, die nach dem
Upgrade auf eine bestimmte AEM-Version nicht mehr kompatibel sind. Die Zielversion AEM muss
als Parameter angegeben.
NOTE
Die MBean-Methoden können wie folgt aufgerufen werden:
  • Die JMX-Konsole
  • Jede externe Anwendung, die eine Verbindung zu JMX herstellt
  • cURL

Deaktivieren von benutzerdefinierten Anmeldemodulen disable-custom-login-modules

NOTE
Dieser Schritt ist nur erforderlich, wenn Sie ein Upgrade von einer AEM 5-Version durchführen. Für Upgrades älterer AEM 6-Versionen kann der Schritt übersprungen werden.

Die Art und Weise, wie LoginModules für die Authentifizierung auf der Repository-Ebene konfiguriert werden, hat sich in Apache Oak entscheidend geändert.

In AEM-Versionen mit CRX2 wurde die Konfiguration in der Datei repository.xml platziert. Ab AEM 6 erfolgt sie über die Web-Konsole im Dienst „Apache Felix JAAS Configuration Factory“.

Daher müssen die vorhandenen Konfigurationen deaktiviert und für Apache Oak nach dem Upgrade erneut erstellt werden.

Zum Deaktivieren der in der JAAS-Konfiguration von repository.xml definierten benutzerdefinierten Module müssen Sie die Konfiguration so ändern, dass das standardmäßige LoginModule verwendet wird, wie dies in diesem Beispiel der Fall ist:

<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>
NOTE
Weitere Informationen finden Sie unter Authentifizierung mit dem externen Anmeldemodul.
Ein Beispiel der LoginModule-Konfiguration in AEM 6 finden Sie im Abschnitt Konfigurieren von LDAP mit AEM 6.

Entfernen von Updates aus dem /install-Verzeichnis remove-updates-install-directory

NOTE
Entfernen Sie nur Pakete aus dem Verzeichnis crx-quickstart/install , nachdem Sie die AEM-Instanz heruntergefahren haben. Dies ist einer der letzten Schritte vor dem Start des Upgrade-Verfahrens.

Entfernen Sie alle Service Packs, Feature Packs oder Hotfixes, die im lokalen Dateisystem im Verzeichnis crx-quickstart/install bereitgestellt sind. Dadurch wird verhindert, dass alte Hotfixes und Service Packs nach Abschluss der Aktualisierung versehentlich zusätzlich zur neuen AEM installiert werden.

Beenden aller Cold-Standby-Instanzen stop-tarmk-coldstandby-instance

Wenn Sie TarMK Cold Standby verwenden, beenden Sie alle Cold-Standby-Instanzen. Dies stellt sicher, dass das System problemlos in den Online-Modus wechseln kann, falls bei dem Upgrade Probleme aufgetreten sind. Nach erfolgreichem Upgrade müssen die Cold-Standby-Instanzen auf Basis der aktualisierten primären Instanzen neu erstellt werden.

Deaktivieren von benutzerdefinierten geplanten Aufträgen disable-custom-scheduled-jobs

Deaktivieren Sie alle geplanten OSGi-Aufträge, die im Anwendungscode enthalten sind.

Durchführen der Offline-Revisionsbereinigung execute-offline-revision-cleanup

NOTE
Dieser Schritt ist nur für TarMK-Installationen erforderlich.

Falls Sie TarMK verwenden, sollten Sie vor dem Upgrade eine Offline-Revisionsbereinigung durchführen. Dadurch werden die Repository-Migration und die nachfolgenden Upgrade-Aufgaben viel schneller ausgeführt. Dies wiederum unterstützt die erfolgreiche Online-Revisionsbereinigung nach dem Upgrade. Informationen zum Ausführen der Offline-Revisionsbereinigung finden Sie unter Durchführen der Offline-Revisionsbereinigung.

Durchführen der Datenspeicherbereinigung execute-datastore-garbage-collection

NOTE
Dieser Schritt ist nur für Instanzen erforderlich, die crx3 ausführen

Nachdem Sie die Revisionsbereinigung auf CRX3-Instanzen ausgeführt haben, sollten Sie die Datenspeicherbereinigung ausführen, um alle nicht referenzierten Blobs im Datenspeicher zu entfernen. Anweisungen finden Sie in der Dokumentation unter Datenspeicherbereinigung.

Löschen von Benutzern, die das Upgrade behindern könnten delete-users-that-might-hinder-the-upgrade

NOTE
Diese Wartungsaufgabe vor dem Upgrade ist nur erforderlich, wenn:
  • Sie führen ein Upgrade von AEM-Versionen durch, die älter als AEM 6.3 sind
  • Während des Upgrades werden alle unten aufgeführten Fehler angezeigt.

Es gibt Ausnahmefälle, in denen Dienstbenutzer, die nicht ordnungsgemäß als normale Benutzer getaggt sind, in älteren AEM-Versionen landen.

In diesem Fall schlägt das Upgrade mit einer Meldung wie der folgenden fehl:

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.

Um dieses Problem zu umgehen, gehen Sie folgendermaßen vor:

Um dieses Problem zu umgehen, gehen Sie folgendermaßen vor:

  • Trennen der Instanz vom Produktions-Traffic

  • Erstellen Sie eine Sicherung der Benutzer, die das Problem verursachen. Dies ist über Package Manager möglich. Weitere Informationen finden Sie unter Arbeiten mit Paketen.

  • Löschen Sie die Benutzer, die das Problem verursachen. Nachfolgend finden Sie eine Liste der Benutzer, die unter diese Kategorie fallen können:

    • dynamic-media-replication
    • communities-ugc-writer
    • communities-utility-reader
    • communities-user-admin
    • oauthservice
    • sling-Skripterstellung

Upgrade des Datenbankschemas bei Bedarf upgrade-the-database-schema-if-needed

Normalerweise übernimmt der zugrunde liegende Apache Oak-Stack, den AEM für die Persistenz verwendet, bei Bedarf das Upgrade des Datenbankschemas.

Es kann jedoch vorkommen, dass das Schema nicht automatisch aktualisiert werden kann. Dabei handelt es sich hauptsächlich um Sicherheitsumgebungen, in denen die Datenbank unter einem Benutzer mit sehr eingeschränkten Berechtigungen ausgeführt wird. In diesem Fall wird AEM weiterhin das alte Schema verwenden.

Um dies zu verhindern, müssen Sie wie folgt ein Upgrade für das Schema durchführen:

  1. Beenden Sie die AEM Instanz, die ein Upgrade benötigt.

  2. Führen Sie ein Upgrade für das Datenbankschema durch. Lesen Sie die Dokumentation für Ihren Datenbanktyp, um zu erfahren, welche Tools Sie dazu benötigen.

    Weitere Informationen dazu, wie Oak mit Schema-Upgrades umgeht, finden Sie auf dieser Seite der Apache-Website.

  3. Fahren Sie mit dem Upgrade von AEM fort.

Rotieren von Protokolldateien rotate-log-files

Bevor Sie mit dem Upgrade beginnen, empfiehlt es sich, die aktuellen Protokolldateien zu archivieren. Dadurch können Sie Protokolldateien vor und nach dem Upgrade einfacher überwachen und scannen, um auftretende Probleme zu identifizieren.

recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56