Upgrade-Verfahren

Letzte Aktualisierung: 2023-11-07
  • Themen:
  • Upgrading
    Weitere Informationen zu diesem Thema
  • Erstellt für:
  • Developer
HINWEIS

Für das Upgrade sind Ausfallzeiten für die Autorenstufe erforderlich, da die meisten Adobe Experience Manager (AEM)-Upgrades direkt durchgeführt werden. Durch Befolgen dieser Best Practices können Sie Ausfallzeiten der Veröffentlichungsstufe minimieren oder vermeiden.

Beim Aktualisieren Ihrer AEM-Umgebungen müssen Sie die Unterschiede beim Ansatz zwischen dem Aktualisieren von Autorenumgebungen oder Veröffentlichungsumgebungen berücksichtigen, um Ausfallzeiten für Autoren und Endbenutzer zu minimieren. Auf dieser Seite wird das allgemeine Verfahren zum Aktualisieren einer AEM Topologie beschrieben, die derzeit mit einer Version von AEM 6.x ausgeführt wird. Da der Prozess zwischen der Autoren- und Veröffentlichungsstufe und Mongo- und TarMK-basierten Implementierungen unterschiedlich ist, wurde jede Ebene und jeder Mikrokernel in einem separaten Abschnitt aufgelistet. Bei der Ausführung Ihrer Bereitstellung empfiehlt Adobe zunächst die Aktualisierung Ihrer Autorenumgebung, um festzustellen, ob sie erfolgreich ist, und dann den Übergang zu den Veröffentlichungsumgebungen.

TarMK-Autorenebene

Starttopologie

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. Dieser Ansatz ist zwar hier nicht dargestellt, kann aber auch für Bereitstellungen verwendet werden, die Abladungen verwenden. 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.

tarmk_starting_topology

Vorbereiten des Upgrades

upgrade-preparation-author

  1. Beenden Sie das Verfassen von Inhalten…

  2. Beenden Sie die Standby-Instanz.

  3. Deaktivieren Sie Replikationsagenten auf der Autoreninstanz.

  4. Führen Sie die Wartungsaufgaben vor dem Upgrade aus.

Ausführen des Upgrades

execute_upgrade

  1. Führen Sie das In-Place-Upgrade aus…

  2. Aktualisieren des Dispatcher-Moduls falls erforderlich.

  3. QA validiert die Aktualisierung.

  4. Fahren Sie die Autoreninstanz herunter.

Bei erfolgreichem Upgrade

if_successful

  1. Kopieren Sie die aktualisierte Instanz, um eine Cold Standby-Instanz zu erstellen.

  2. Starten Sie die Autoreninstanz.

  3. Starten Sie die Standby-Instanz.

Bei fehlgeschlagenem Upgrade (Rollback)

rollback

  1. Starten Sie die Cold-Standby-Instanz als neue Primärinstanz…

  2. Erstellen Sie die Autorenumgebung aus der Cold-Standby-Instanz neu.

MongoMK-Autorencluster

Starttopologie

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 den Autorenservern zur TarMK-Veröffentlichungsfarm.

mongo-topology

Vorbereiten des Upgrades

mongo-upgrade_prep

  1. Beenden Sie das Verfassen von Inhalten…
  2. Klonen Sie den Datenspeicher für die Sicherung.
  3. Beenden Sie alle bis auf eine AEM Autoreninstanz, Ihren primären Autor.
  4. Entfernen Sie alle bis auf einen MongoDB-Knoten aus der Replikatgruppe, Ihrer primären Mongo-Instanz.
  5. Aktualisieren Sie die DocumentNodeStoreService.cfg -Datei auf der primären Autoreninstanz, um die Replikatgruppe Ihrer einzelnen Mitglieder widerzuspiegeln.
  6. Starten Sie die primäre Autoreninstanz neu, um sicherzustellen, dass sie ordnungsgemäß neu gestartet wird.
  7. Deaktivieren Sie Replikationsagenten auf der primären Autoreninstanz.
  8. Ausführen Wartungsaufgaben vor der Aktualisierung auf der primären Autoreninstanz.
  9. Aktualisieren Sie bei Bedarf MongoDB auf der primären Mongo-Instanz auf Version 3.2 mit WiredTiger.

Ausführen des Upgrades

mongo-execution

  1. Führen Sie ein In-Place-Upgrade auf der primären Autoreninstanz aus…
  2. Aktualisieren des Dispatchers oder Webmoduls falls erforderlich.
  3. QA validiert die Aktualisierung.

Bei erfolgreichem Upgrade

mongo-secondaries

  1. Erstellen Sie neue 6.5-Autoreninstanzen, die mit der upgegradeten Mongo-Instanz verbunden sind…

  2. Erstellen Sie die MongoDB-Knoten neu, die aus dem Cluster entfernt wurden.

  3. Aktualisieren Sie die DocumentNodeStoreService.cfg -Dateien, um die vollständige Replikatgruppe widerzuspiegeln.

  4. Starten Sie die Autoreninstanzen einzeln neu.

  5. Entfernen Sie den geklonten Datenspeicher.

Bei fehlgeschlagenem Upgrade (Rollback)

mongo-rollback

  1. Konfigurieren Sie die sekundären Autoreninstanzen neu, um diese mit dem geklonten Datenspeicher zu verbinden…

  2. Beenden der upgegradeten primären Autoreninstanz.

  3. Beenden Sie die upgegradete primäre Mongo-Instanz.

  4. Starten Sie die sekundären Mongo-Instanzen neu, wobei eine dieser Instanzen als neue primäre Instanz fungieren muss…

  5. Konfigurieren Sie die DocumentNodeStoreService.cfg -Dateien in den sekundären Autoreninstanzen auf den Replikatsatz der noch nicht aktualisierten Mongo-Instanzen verweisen.

  6. Starten Sie die sekundären Autoreninstanzen.

  7. Bereinigen Sie die aktualisierten Autoreninstanzen, den Mongo-Knoten und den Datenspeicher.

TarMK-Veröffentlichungsfarm

TarMK-Veröffentlichungsfarm

Die angenommene Topologie für diesen Abschnitt besteht aus zwei TarMK-Veröffentlichungsinstanzen, die von Dispatchern angeführt werden, die wiederum mit einem Lastenausgleich konfrontiert sind. Die Replikation erfolgt vom Autorenserver zur TarMK-Veröffentlichungsfarm.

tarmk-pub-farmv5

Ausführen des Upgrades

upgrade-publish2

  1. Beenden Sie den Traffic an die Veröffentlichungsinstanz 2 auf dem Lastausgleich…
  2. Ausführen Wartung vor der Aktualisierung auf Publish 2.
  3. Führen Sie einen Ersetzende Aktualisierung auf Publish 2.
  4. Aktualisieren des Dispatchers oder Webmoduls falls erforderlich.
  5. Leeren Sie den Dispatcher-Cache.
  6. QA validiert Publish 2 über den Dispatcher hinter der Firewall.
  7. Veröffentlichung beenden 2.
  8. Kopieren Sie die Veröffentlichungsinstanz 2 .
  9. Starten Sie Publish 2.

Bei erfolgreichem Upgrade

upgrade-publish1

  1. Aktivieren Sie Traffic zur Veröffentlichungsinstanz 2…
  2. Beenden Sie den Traffic auf Publish 1.
  3. Beenden Sie die Veröffentlichungsinstanz 1.
  4. Ersetzen Sie die Veröffentlichungsinstanz 1 durch eine Kopie von Veröffentlichung 2.
  5. Aktualisieren des Dispatchers oder Webmoduls falls erforderlich.
  6. Leeren Sie den Dispatcher-Cache für Publish 1.
  7. Veröffentlichung starten 1.
  8. QA validiert die Veröffentlichung 1 über den Dispatcher hinter der Firewall.

Bei fehlgeschlagenem Upgrade (Rollback)

pub_rollback

  1. Erstellen Sie eine Kopie der Veröffentlichungsinstanz 1. .
  2. Ersetzen Sie die Instanz im Veröffentlichungsmodus 2 durch eine Kopie im Veröffentlichungsmodus 1.
  3. Leeren Sie den Dispatcher-Cache für Publish 2.
  4. Starten Sie Publish 2.
  5. QA validiert Publish 2 über den Dispatcher hinter der Firewall.
  6. Aktivieren Sie Traffic auf Publish 2.

Abschließende Upgrade-Schritte

  1. Aktivieren Sie Traffic zur Veröffentlichungsinstanz 1…
  2. QA führt die endgültige Validierung über eine öffentliche URL durch.
  3. Aktivieren Sie Replikationsagenten aus der Autorenumgebung.
  4. Setzt die Inhaltserstellung fort.
  5. Führen Sie Prüfungen nach dem Upgrade durch.

final

Auf dieser Seite