Der Algorithmus für das Rollout einer neuen Edition
hat Auswirkungen auf Ihre Betriebsumgebung.
Die Installation und Verteilung einer Anwendungsedition unterscheiden sich von der Aktivierung der Anwendungsedition.
Für eine unterbrechungsfreie Ersetzung sind zwei Basismuster verfügbar: Gruppen-Rollout und atomares Rollout.
Die Schritte, die zum Rollout der neuen Edition ausgeführt werden müssen,
richten sich danach, welche dieser Optionen Sie auswählen.
Die dynamischen Cluster werden während des Rollouts in den manuellen Betriebsmodus versetzt. Wenn die Arbeitslast
während des Rollouts zu hoch wird, findet die Anwendungsverteilung nicht statt.
Planen Sie Ihre Rollouts so, dass Zeiten mit Spitzenauslastungen und Lastspitzen vermieden werden. Nach Abschluss des Rollouts wird der
dynamische Cluster in den ursprünglichen Betriebsmodus zurück versetzt.
Probleme vermeiden: In Zeiten mit hohem Datenverkehr sollte kein Rollout durchgeführt werden.
gotcha
Gruppen-Rollout
Wenn Sie ein Gruppen-Rollout durchführen,
wird das Rollout für die Servergruppen in den Clustern ausgeführt.
Für jeden Server werden die folgenden Schritte ausgeführt:
- Die Arbeit für den Server wird stillgelegt.
- Die Anwendung oder der Server wird gestoppt.
- Die Serverkonfiguration wird aktualisiert.
- Die Anwendung bzw. der Server wird erneut gestartet.
- Der Server wird mit der neuen Edition in den Bereitschaftsmodus versetzt.
Atomares Rollout
Bevor Sie ein atomares Rollout durchführen,
ermitteln Sie, welche Arbeitslast der Zielservercluster verarbeiten kann.
Bei Ausführung eines atomaren Rollout wird die neue Edition zunächst
auf der einen Hälfte des Clusters aktiviert und anschließend auf der anderen Hälfte des Clusters.
Während die erste Hälfte des Clusters offline gesetzt und aktualisiert wird,
werden die Anwendungsanforderungen an die andere Hälfte des Clusters weitergeleitet.
Überprüfen Sie, ob diese Hälfte des Clusters während des Rollout die gesamte Arbeitslast handhaben kann.
Wenn Sie ein atomares Rollout durchführen, werden
für jeden Server die folgenden Schritte
ausgeführt:
- Die Arbeit für die Hälfte der Server wird in den Wartemodus versetzt.
- Die Anwendungen oder Server der ersten Hälfte der Server werden gestoppt.
- Die Konfigurationen werden aktualisiert.
- Die Anwendungen oder Server der ersten Serverhälfte werden gestartet.
- Die Arbeit für die zweite Hälfte der Server wird in den Wartemodus versetzt.
- Die Weiterleitung der Anforderungen an die auf der ersten Hälfte der Server ausgeführte neue Edition wird gestartet.
- Die Anwendungen oder Server der zweiten Serverhälfte werden gestoppt, die Konfigurationen werden aktualisiert, und anschließend werden die Anwendungen bzw. Server gestartet.
- Das Rollout ist abgeschlossen.
Standardeinstellungen für Rollout
Die folgenden Optionen sind für die Rollout-Optionen in der Administrationskonsole voreingestellt:
- Gruppen-Rollout:
- Rollout-Strategie = Gruppe, Gruppengröße = 1
- Neustartstrategie = Anwendung
- Ausräumintervall = 30 Sekunden
- Atomares Rollout:
- Rollout-Strategie = atomar
- Neustartstrategie = Anwendung
- Ausräumintervall = 30 Sekunden
Rollout-Optionen für die Scripting-Schnittstelle
Die Rollout-Optionen "Gruppe" und "Atomar" in der Administrationskonsole bieten eine voreingestellte Auswahl von
Rollout-Optionen.
Die Scripting-Schnittstelle können diese Optionen flexibler gesteuert werden.
Weitere Informationen finden Sie in den Beschreibungen der Tasks zur Verwaltung von Anwendungseditionen.
Folgende Scripting-Optionen sind vorhanden:
- Rollout-Strategie: Gibt die Rollout-Methode an. Sie können Gruppen von Knoten nacheinander zu aktualisieren oder
die atomare Strategie (trennen und austauschen) verwenden.
- Gruppe: Gibt an, dass der Zielcluster für das Rollout in Gruppen eingeteilt wird.
Das Gruppen-Rollout empfiehlt sich insbesondere für große Cluster.
Mit einer Unteroption können Sie die Größe der Gruppe angeben.
Die Gruppengröße gibt die Anzahl der Knoten an, die jeweils verarbeitet werden sollen.
Der Standardwert ist
1.
- Atomar: Gibt an, dass während des Rollout nur jeweils eine Edition der Anwendung Anforderungen
bearbeiten kann. Dies führt dazu, dass zuerst die eine Hälfte des Anwendungsservercluster offline gesetzt und aktualisiert wird und dann die andere Hälfte.
Anwendungsanforderungen, die eingehen, während beide Hälften des Clusters offline sind, werden vom On Demand Router (ODR) in eine Warteschlange gestellt.
- Neustartstrategie: Gibt an, ob die Anwendung oder der gesamte Anwendungsserver erneut gestartet werden soll.
- Anwendung: Aktiviert die neue Edition in jedem Anwendungsserver, indem die Anwendung erneut gestartet wird.
Der Anwendungsserver bleibt aktiv.
- Server: Aktiviert die neue Edition in jedem Anwendungsserver, indem der Server selbst erneut gestartet wird.
Diese Option ist erforderlich, wenn Sie Connector und native Bibliotheken aktualisieren oder die
Java Virtual Machine zurücksetzen müssen.
- Ausräumintervall: Gibt an, wie lange auf die Verarbeitung von Anforderungen gewartet werden soll, bevor die Anwendung bzw. der
Anwendungsserver gestoppt wird.
Der Standardwert ist 30 Sekunden.