Wartungsaufgaben vor einer Aktualisierung

Bevor Sie mit der Aktualisierung 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

Wenn Sie die Aktualisierung 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 Segment-TAR-Format erstellt. Daher benötigen Sie ausreichend Festplattenspeicher, um eine zweite (möglicherweise größere) Version des Repositorys zu speichern.

Vollständige Sicherung von AEM

Bevor Sie mit der Aktualisierung beginnen, sollten Sie eine vollständige Sicherungskopie von AEM erstellen. Erstellen Sie Sicherungskopien des Repositorys, der Anwendungsinstallation, des Datenspeichers und der Mongo-Instanzen, falls zutreffend. Weitere Informationen zum Sichern und Wiederherstellen einer AEM-Instanz finden Sie unter Sicherung und Wiederherstellung.

Sicherung von Änderungen unter /etc

Der Aktualisierungsprozess bietet eine gute Möglichkeit, vorhandenen Inhalt und Konfigurationen unter den Pfaden /apps und /libs im Repository zu verwalten und zusammenzuführen. Für Änderungen am Pfad /etc, einschließlich ContextHub-Konfigurationen, ist es häufig erforderlich, diese Änderungen nach der Aktualisierung erneut anzuwenden. Während das Upgrade eine Sicherungskopie aller Änderungen erstellt, die unter /var nicht zusammengeführt werden können, empfehlen wir, diese Änderungen vor Beginn des Upgrades manuell zu sichern.

Erstellen der quickstart.properties-Datei

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 die Aktualisierung schlägt fehl. Überprüfen Sie daher, dass diese Datei vorhanden ist, und starten Sie AEM andernfalls von der JAR-Datei aus neu.

Konfigurieren von Workflow- und Auditprotokoll-Löschung

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 der Aktualisierung 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 der Aktualisierung löschen, falls Sie diese nicht ausführen möchten. Dokumentation zum Konfigurieren von Workflow-Löschaufgaben finden Sie unter Verwalten von Workflow-Instanzen. Informationen zur Konfiguration von Wartungsaufgaben für Auditprotokolle finden Sie unter Wartung von Auditprotokollen in AEM 6.

Informationen zum Workflow und zum Löschen von Auditprotokollen in CQ 5.6 und AEM 6.0 finden Sie unter Löschen von Workflow- und Auditknoten.

Installieren, Konfigurieren und Ausführen der Aufgaben vor der Aktualisierung

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

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

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

Die Wartungsaufgaben vor einer Aktualisierung 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 der Aktualisierung können diese Aufgaben einheitlich ausgelöst und ihre Ergebnisse bei Bedarf überprüft werden.

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

Einrichtung

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

Sie finden die Pakete hier:

Verwendung

Die OSGi-Komponente PreUpgradeTasksMBean ist mit einer Liste von Wartungsaufgaben vor der Aktualisierung 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 navigieren.

  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 der Ausführungsmodi für die einzelnen Wartungsaufgaben.

Aufgabe Ausführungsmodus Hinweise
TarIndexMergeTask crx2
DataStoreGarbageCollectionTask crx2 Mark und Sweep werden ausgeführt. Lassen Sie bei freigegebenen Datenspeichern diesen Schritt aus und gehen Sie
manuell vor oder bereiten Sie die Instanzen vor der Ausführung richtig vor.
ConsistencyCheckTask crx2
WorkflowPurgeTask crx2/crx3 Vor der Ausführung muss die Adobe Granite Workflow-Bereinigung in OSGi konfiguriert werden.
GenerateBundlesListFileTask crx2/crx3
RevisionCleanupTask crx3 Für TarMK-Instanzen auf AEM 6.0 bis 6.2 führen Sie stattdessen die Offline-Revisionsbereinigung durch.
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 Vor der Ausführung muss der Auditprotokoll-Bereinigungsplaner in OSGi konfiguriert werden.
VORSICHT

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 einer Aktualisierung ausgelöst wird.

Standardkonfiguration der Konsistenzprüfungen vor einer Aktualisierung

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

  • system – Das von den Wartungs-Konsistenzprüfungen von Granite verwendete Tag.

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

Die Liste kann bearbeitet werden. Mit den Plus- (+) und Minus-Schaltflächen (-) neben den Tags können Sie weitere benutzerdefinierte Tags hinzufügen oder die Standard-Tags entfernen.

MBean-Methoden

Der Zugriff auf die Funktion für verwaltete Beans ist über die JMX-Konsole möglich.

Sie können wie folgt auf die MBeans zugreifen:

  1. Wechseln Sie zur JMX-Konsole unter https://serveraddress: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 der Aktualisierung an.
getAvailablePreUpgradeHealthChecksTagNames() INFO Zeigt die Namensliste Liste der Konsistenzprüfungen vor der Aktualisierung an.
runAllPreUpgradeTasks() AKTION Führt alle in der Liste genannten Wartungsaufgaben vor der Aktualisierung aus.
runPreUpgradeTask(preUpgradeTaskName) AKTION Führt die Wartungsaufgabe vor der Aktualisierung mit dem als Parameter angegebenen Namen aus.
isRunAllPreUpgradeTaskRunning() ACTION_INFO Überprüft, ob die runAllPreUpgradeTasksmaintenance-Aufgabe derzeit ausgeführt wird.
getAnyPreUpgradeTaskRunning() ACTION_INFO Überprüft, ob gerade Wartungsaufgaben vor der Aktualisierung ausgeführt werden und
gibt ein Array mit den Namen der gerade ausgeführten Aufgaben aus.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) AKTION Gibt die genaue Ausführungszeit der Wartungsaufgaben vor der Aktualisierung mit dem Namen als Parameter an.
getPreUpgradeTaskLastRunState(preUpgradeTaskName) AKTION Gibt den letzten Ausführungsstatus der Wartungsaufgabe vor der Aktualisierung mit dem Namen als Parameter an.
runAllPreUpgradeHealthChecks(shutDownOnSuccess) AKTION

Führt alle Konsistenzprüfungen vor der Aktualisierung aus und speichert ihren Status in einer Datei mit dem Namen preUpgradeHCStatus.properties, die sich im Sling-Startpfad befindet. Wenn der Parameter shutDownOnSuccess auf true gesetzt ist, wird die AEM-Instanz heruntergefahren, jedoch nur, wenn alle Konsistenzprüfungen vor der Aktualisierung den Status "OK"aufweisen.

Die Eigenschaftendatei wird als Vorbedingung für zukünftige Aktualisierungen verwendet
und der Aktualisierungsvorgang wird angehalten, wenn die Konsistenzprüfungen vor einer Aktualisierung
fehlgeschlagen sind. Wenn Sie das Ergebnis der Konsistenzprüfungen
vor einer Aktualisierung ignorieren und die Aktualisierung trotzdem starten möchten, können Sie die Datei löschen.
detectUsageOfUnavailableAPI(aemVersion) AKTION Listet alle importierten Pakete auf, die nach der
Aktualisierung auf eine bestimmte AEM-Version nicht mehr kompatibel sind. Die AEM-Zielversion muss
als Parameter angegeben werden.
HINWEIS

Die MBean-Methoden können über folgende Komponenten aufgerufen werden:

  • Die JMX-Konsole
  • Eine beliebige externe Anwendung, die eine Verbindung mit JMX herstellt
  • cURL

Deaktivieren von benutzerdefinierten Anmeldemodulen

HINWEIS

Dieser Schritt ist nur erforderlich, wenn Sie eine Aktualisierung von einer AEM 5-Version durchführen. Für Aktualisierungen ä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 der Aktualisierung 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>
HINWEIS

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

HINWEIS

Entfernen Sie Pakete aus dem Verzeichnis „crx-quickstart/install“ erst, NACHDEM Sie die AEM-Instanz heruntergefahren haben. Dies ist einer der letzten Schritte vor dem Start des Aktualisierungsverfahrens.

Entfernen Sie alle Service Packs, Feature Packs oder Hotfixes, die im lokalen Dateisystem im Verzeichnis crx-quickstart/install bereitgestellt sind. Dadurch wird die unbeabsichtigte Installation alter Hotfixes und Service Packs auf der neuen AEM-Version nach der Aktualisierung verhindert.

Beenden aller Cold-Standby-Instanzen

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

Deaktivieren von benutzerdefinierten geplanten Aufträgen

Deaktivieren Sie in OSGi geplante Aufträge, die im Anwendungscode enthalten sind.

Durchführen der Offline-Revisionsbereinigung

HINWEIS

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

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

Durchführen der Datenspeicherbereinigung

HINWEIS

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

Nach der Revisionsbereinigung auf CRX3-Instanzen sollten Sie die Datenspeicherbereinigung ausführen, um nicht referenzierte BLOB-Objekte aus dem Datenspeicher zu löschen. Eine Anleitung finden Sie in der Dokumentation zur Datenspeicherbereinigung.

Aktualisieren Sie bei Bedarf das Datenbankschema.

Normalerweise übernimmt der zugrunde liegende Apache Oak-Stapel, den AEM für die Persistenz verwendet, bei Bedarf die Aktualisierung 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 das Schema wie folgt aktualisieren:

  1. Beenden Sie die AEM Instanz, die aktualisiert werden muss.

  2. Aktualisieren Sie das Datenbankschema. Lesen Sie die Dokumentation für Ihren Datenbanktyp , um zu erfahren, welche Tools Sie dazu benötigen.

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

  3. Fahren Sie mit der AEM fort.

Löschen Sie Benutzer, die die Aktualisierung behindern

HINWEIS

Diese Wartungsaufgabe vor der Aktualisierung ist nur erforderlich, wenn:

  • Sie aktualisieren von AEM Versionen, 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 in älteren AEM-Versionen landen, die nicht ordnungsgemäß als normale Benutzer getaggt sind.

In diesem Fall schlägt die Aktualisierung 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:

  1. Trennen der Instanz vom Produktions-Traffic

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

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

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

Rotieren von Protokolldateien

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

Auf dieser Seite