Wartungsaufgaben vor einem Upgrade pre-upgrade-maintenance-tasks

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. Bei der 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. Bei Änderungen, die am /etc-Pfad vorgenommen wurden, einschließlich Context Hub-Konfigurationen, ist es oft notwendig, diese Änderungen nach dem Upgrade erneut vorzunehmen. Auch wenn das Upgrade eine Sicherungskopie aller Änderungen erstellt, die nicht unter /var zusammengeführt werden können, empfiehlt Adobe, diese Änderungen vor dem Upgrade manuell zu sichern.

Erzeugen der Datei quickstart.properties generate-quickstart-properties

Beim Starten von AEM aus der .jar-Datei wird eine Datei quickstart.properties unter crx-quickstart/conf erzeugt. 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, ohne die sie nicht ausgeführt werden können. 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 Bereinigen von Workflow- und Auditknoten.

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. Dieses Problem führte zu Situationen, in denen das Upgrade komplett neu gestartet werden musste oder fehlerhafte 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 Schnittstellen 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.

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:

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.

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:

Die Liste kann bearbeitet werden. Sie können die Schaltflächen Plus (+) und Minus (-) neben den Tags verwenden, 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 zugegriffen werden.

Sie können wie folgt auf die MBeans zugreifen:

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

Deaktivieren von benutzerdefinierten Anmeldemodulen disable-custom-login-modules

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.

Um die in der JAAS-Konfiguration von repository.xml definierten benutzerdefinierten Module zu deaktivieren, müssen Sie die Konfiguration so bearbeiten, dass die Standardkonfiguration LoginModule verwendet wird, wie im folgenden Beispiel dargestellt:

<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>

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

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

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

Wenn Sie TarMK-Cold-Standby verwenden, beenden Sie alle Cold-Standby-Instanzen. Dies garantiert eine effiziente Möglichkeit, bei Problemen im Upgrade wieder online zu gehen. 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 Anwendungs-Code enthalten sind.

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

Falls Sie TarMK verwenden, sollten Sie vor dem Upgrade eine Offline-Revisionsbereinigung durchführen. Dadurch werden die Repository-Migration und die nachfolgenden Upgrade-Aufgaben wesentlich 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

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 zur Datenspeicherbereinigung.

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. In solchen Fällen handelt es sich meistens um Hochsicherheitsumgebungen, in denen die Datenbank unter einer Person mit eingeschränkten Benutzerberechtigungen läuft. Wenn eine solche Situation eintritt, verwendet AEM weiterhin das alte Schema.

Um zu verhindern, dass ein solches Szenario eintritt, aktualisieren Sie das Schema wie folgt:

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

In Ausnahmefällen kann es vorkommen, dass Dienstbenutzer in einer älteren AEM-Version fälschlicherweise als reguläre Benutzer gekennzeichnet werden.

Wenn eine solche Situation eintritt, 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:

Rotieren von Protokolldateien rotate-log-files

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