Für das Upgrade muss mit Ausfallzeiten für die Autorenschicht gerechnet werden, da der Großteil der AEM-Upgrades als In-Place-Upgrade durchgeführt wird. Sie können Ausfallzeiten der Autorenschicht minimieren oder ganz vermeiden, indem Sie sich an die folgenden Best Practices halten.
Wenn Sie die AEM-Umgebungen upgraden, müssen Sie sich die Unterschiede beim Upgrade von Autorenumgebungen und Veröffentlichungsumgebungen bewusst machen, um Ausfallzeiten für Autoren und Endbenutzer zu minimieren. Auf dieser Seite finden Sie einen Überblick über Upgrades einer AEM-Topologie, die auf einer AEM 6.x-Version ausgeführt wird. Da sich der Vorgang für die Autoren- und Veröffentlichungsschicht und ebenfalls für Bereitstellungen mit Mongo und TarMK unterscheidet, werden die einzelnen Schichten und Mikrokernel in separaten Abschnitten behandelt. Beim Ausführen der Bereitstellung wird empfohlen, zuerst die Autorenumgebung upzugraden und, wenn dies erfolgreich war, mit den Veröffentlichungsumgebungen fortzufahren.
In diesem Abschnitt wird von einer Topologie mit einem Autorenserver ausgegangen, der auf TarMK mit einem Cold Standby ausgeführt wird. Die Replikation erfolgt vom Autorenserver an die TarMK-Veröffentlichungsfarm. Obwohl hierin nicht beschrieben, kann dieser Ansatz auch für Deployments, die nach dem Prinzip Offloading arbeiten. Stellen Sie sicher, dass Sie die Offloading-Instanz auf der neuen Version upgraden oder neu erstellen, bevor Sie Replikationsagenten, die auf der Autoreninstanz deaktiviert waren, neu aktivieren.
Beenden Sie das Verfassen von Inhalten.
Beenden Sie die Standby-Instanz.
Deaktivieren Sie Replikationsagenten auf der Autoreninstanz.
Führen Sie die Wartungsaufgaben vor dem Upgrade aus.
Führen Sie das In-Place-Upgrade aus.
Aktualisieren Sie das Dispatcher-Modul, falls erforderlich.
QA überprüft das Upgrade.
Beenden Sie die Autoreninstanz.
Kopieren Sie die upgegradete Instanz, um ein neues Cold Standby zu erstellen.
Starten Sie die Autoreninstanz.
Starten Sie die Standby-Instanz.
Starten Sie die Cold-Standby-Instanz als neue Primärinstanz.
Erstellen Sie die Autorenumgebung aus der Cold-Standby-Instanz neu.
In diesem Abschnitt wird von einer Topologie mit einem MongoMK-Autoren-Cluster mit mindestens zwei AEM-Autoreninstanzen ausgegangen, gesichert von mindestens zwei MongoMK-Datenbanken. Die Autoreninstanzen nutzen einen gemeinsamen Datenspeicher. Diese Schritte gelten für S3- und Dateidatenspeicher. Die Replikation erfolgt von Autorenservern an die TarMK-Veröffentlichungsfarm.
DocumentNodeStoreService.cfg
auf der primären Autoreninstanz, dem einzigen Mitglied des Replikationssatzes.Erstellen Sie neue 6.5-Autoreninstanzen, die mit der upgegradeten Mongo-Instanz verbunden sind.
Erstellen Sie die MongoDB-Knoten, die aus dem Cluster entfernt wurden.
Aktualisieren Sie die DocumentNodeStoreService.cfg
-Dateien, damit der vollständige Replikationssatz berücksichtigt wird.
Starten Sie die Autoreninstanzen einzeln neu.
Entfernen Sie den geklonten Datenspeicher.
Konfigurieren Sie die sekundären Autoreninstanzen neu, um diese mit dem geklonten Datenspeicher zu verbinden.
Beenden der upgegradeten primären Autoreninstanz
Beenden Sie die upgegradete primäre Mongo-Instanz.
Starten Sie die sekundären Mongo-Instanzen neu, wobei eine dieser Instanzen als neue primäre Instanz fungieren muss.
Konfigurieren Sie die Dateien DocumentNodeStoreService.cfg
auf den sekundären Autoreninstanzen so, dass sie auf den Replikationssatz noch nicht upgegradeter Mongo-Instanzen verweisen.
Starten Sie die sekundären Autoreninstanzen.
Bereinigen Sie die upgegradeten Autoreninstanzen, den Mongo-Knoten und den Datenspeicher.
In diesem Abschnitt wird von einer Topologie mit zwei TarMK-Veröffentlichungsinstanzen ausgegangen, mit Dispatchern im Frontend, die wiederum einen Lastausgleich im Frontend haben. Die Replikation erfolgt vom Autorenserver an die TarMK-Veröffentlichungsfarm.