Wählen Sie Atomar oder Gruppiert als Rollout-Typ aus.
Verwenden Sie die Option Gruppen-Rollout, wenn Sie Editionen auf Membern des Zielclusters gruppenweise ersetzen möchten.
Gewöhnlich wird das Gruppen-Rollout ausgewählt, das nützlich ist, wenn das Cluster vier oder mehr Member enthält.
Alternativ können Sie mit Scripting ein Gruppen-Rollout mit einer bestimmten Gruppengröße durchführen.
Weitere Informationen hierzu finden Sie im Artikel
Verwaltungs-Tasks für das Management von Anwendungseditionen
. Sobald die neue Edition während des Gruppen-Rollout verfügbar ist, werden alle Anforderungen an die neue Edition weitergeleitet.
Verwenden Sie die Rollout-Option Atomar, wenn Sie eine Edition zuerst in einer Hälfte des Clusters und anschließend in der anderen Hälfte des Clusters
durch eine andere Edition ersetzen möchten.
Wenn Sie diesen Rollout-Typ wählen, werden alle Benutzeranforderungen von derselben Edition der Anwendung bearbeitet.
Da alle Benutzeranforderungen von derselben Edition bearbeitet werden, wird Ihr Cluster mit halber Kapazität betrieben.
Wenn der Cluster vier oder mehr Member enthält, sollten Sie erwägen,
den Cluster in kleinere Gruppen zu unterteilen, indem Sie ein Gruppen-Rollout ausführen.
Der atomare Modus wird auch für ein Implementierungsziel verwendet werden, das nur einen einzigen Server umfasst.
Bei einem solchen Implementierungsziel werden die Aktion, die sonst für die zweite Hälfte des Clusters ausgeführt werden,
einfach weggelassen.
Wenn Sie die Implementierungsziele vor Ausführung eines atomaren Rollout stoppen,
werden sie nach dem Ersetzen der aktiven Edition durch die neue Edition
unabhängig von der gewählten Neustartstrategie gestartet.
Diese Vorgehensweise ermöglicht eine bessere Verfügbarkeit für die Anforderungen, die während der Rollout-Periode bedient werden.
Probleme vermeiden: 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.
gotcha
Wählen Sie die Neustartstrategie aus.
Die Neustartstrategie teilt dem Application Edition Manager mit, wie jedes Implementierungsziel die neue Edition in die Laufzeitumgebung
des Servers lädt.
Mit der Zurücksetzungsstrategie Warmstart wird die Anwendung zurückgesetzt, indem
sie auf jedem Server im Cluster gestoppt und erneut gestartet wird,
sobald die alte Edition durch die neue auf diesem Server ersetzt wurde.
Gewöhnlich wird der Warmstart ausgewählt, der beim Neustart von Anwendungen die beste Leistung bietet, weil
in diesem Fall die neue Edition geladen wird,
indem die Anwendung im aktiven Anwendungsserver gestoppt und anschließend erneut gestartet wird.
Der Server bleibt während dieses Prozesses aktiv. Beim Warmstart werden die nativen Bibliotheken nicht aus dem Hauptspeicher entladen. Ein Warmstart
ist im Allgemeinen sicher für solche Anwendungen, die keine nativen Bibliotheken verwenden.
Wenn ein Warmstart in einer Produktionsumgebung verwendet wird, müssen Sie den Anwendungsserverprozess
überwachen, um sicherzustellen, dass genügend virtueller Speicher verfügbar ist.
Bei einem Kaltstart werden alle Anwendungsserver im Cluster gestoppt und erneut gestartet, wenn die frühere Edition durch die neue Edition ersetzt wird.
Dabei werden der Prozessspeicher und alle von der Anwendung verwendeten nativen Bibliotheken
aktualisiert. Mit dieser Strategie wird eine Nichtverfügbarkeit des virtuellen Speichers verhindert, und
es können neue Versionen der nativen Bibliotheken geladen werden. Wählen Sie den Kaltstart als Neustartstrategie
aus, wenn Sie ein Rollout einer Edition durchführen, die
von den neuen Versionen nativer Bibliotheken oder anderen Abhängigkeiten, die nur durch Stoppen und erneutes Starten
des gesamten Anwendungsservers aktualisiert werden, abhängig ist oder wenn Sie größere Anwendungen haben, die
große Speichermengen für JIT (Just-in-Time Compilation) verbrauchen.
Legen Sie das Ausräumintervall in Sekunden fest.
Das Ausräumintervall gibt den HTTP-Sitzungen Zeit, ihre Arbeit fertig zu stellen, bevor die Anwendung bzw. der Server neu gestartet wird.
Es legt fest, wie lange der Application Edition Manager wartet, bevor die Neustartstrategie umgesetzt wird.
Affinitäten, z. B. Transaktions-, Aktivitäts- und kompensationsbezogene Affinitäten,
sowie Aktivitäten, die WebSphere Virtual Enterprise
nicht bekannt sind, verlängern das effektive
Ausräumintervall, weil der Server erst dann gestoppt wird, wenn alle diese Arbeitseinheiten abgeschlossen sind.
Anwendungen mit Aktivitäten, die WebSphere Virtual Enterprise
nicht bekannt sind, können die Benachrichtigung
über eingeleitete Stilllegung der MBean "AppEditionManager" als Auslöser verwenden, um
mit der Shutdown-Verarbeitung zu beginnen, und das Ausräumintervall als Zeitraum verwenden, in dem der Shutdown
ausgeführt wird.
Dies ist für persistente Sitzungen, z. B. für solche Sitzungen, die in der Datenbank gesichert sind oder über
VMware Distributed Resource Scheduler (DRS)
repliziert werden, nicht erforderlich, aber für temporäre (im Hauptspeicher befindliche) Sitzungen wichtig.
Das Ausräumintervall ermöglicht es,
Anforderungen mit Affinitäten und unvollständige Anforderungen zum Abschluss zu bringen.
Um den Verlust temporärer Sitzungen zu verhindern, müssen Sie das Ausräumintervall auf einen höheren Wert als das Zeitlimit für Anwendungssitzungen setzen.
Wenn das Rollout beginnt und die einzelnen Server aktualisiert werden, wird jeder Server für das Starten neuer Sitzungen
zunächst als nicht auswählbar markiert.
Setzen Sie diese Einstellung auf 0, wenn nicht auf die Beendigung der Sitzungen gewartet werden soll.
Wenn ein Warmstart durchgeführt wird, wartet der Stilllegungsmanager für Anwendungseditionen
bis das Ausräumintervall vollständig abgelaufen ist, um sicherzustellen, dass vorhandene Sitzungen beendet werden können.
Der Stilllegungsmanager für Anwendungseditionen wartet, unabhängig davon, ob noch nicht beendete Sitzungen existieren oder
ob die Sitzungen vor Ablauf des definierten Ausräumintervalls beendet werden.
Wenn ein Warmstart durchgeführt wird, wartet der Stilllegungsmanager für Anwendungseditionen möglicherweise nicht,
bis das Ausräumintervall vollständig abgelaufen ist.
Dem Stilllegungsmanager stehen PMI-Statistikdaten (Performance Monitoring
Infrastructure) zur Verfügung, anhand deren er feststellen kann, ob alle aktiven Anforderungen auf einem Server stillgelegt wurden.
Wenn alle Anforderungen vor Ablauf des Ausräumintervalls stillgelegt wurden, muss der
Stilllegungsmanager für Anwendungseditionen nicht warten, bis das Ausräumintervall vollständig abgelaufen ist.
Das Ausräumintervall bietet die Möglichkeit, dass vorhandene Sitzungen beendet werden.
Nach Ablauf des Ausräumintervalls gibt es aber einen Zeitraum, während dessen weiterhin
unvollständige Anforderungen ankommen können.
Für diese Fälle stellt der
On Demand Router (ODR) einen Zeitlimitwert von
60 Sekunden für den Abschluss der Stilllegungsoperation bereit.
Wenn die Anforderungen innerhalb von
60 Sekunden beendet werden oder wenn die
60 Sekunden ablaufen, wird die Anwendung oder (im Fall eines Kaltstarts) der Server gestoppt.
Wenn unvollständige Anforderungen noch immer nicht abgeschlossen wurden, stellt
WebSphere Application Server Network Deployment eine Stilllegungszeit von
60 Sekunden bereit, bevor die Anwendung oder Serverinstanz gestoppt wird.
Für Kaltstartstrategien stellt WebSphere Application Server Network Deployment ein Quiesce-Zeitlimit von 180 Sekunden bereit, bevor die Serverinstanz gestoppt wird.
Sie können den Zeitraum, während dessen der Web-Container auf die Beendigung von Anforderungen wartet,
mit der angepassten Eigenschaft com.ibm.ws.webcontainer.ServletDestroyWaitTime definieren.
Weitere Informationen finden Sie
im Artikel Benutzerdefinierte Merkmale für Webcontainer.
Sie können den Zeitraum, den die Serverinstanz auf die Beendigung von Anforderungen wartet, bevor sie den Systemabschluss einleitet,
mit der angepassten Eigenschaft "com.ibm.ejs.sm.server.quiesceTimeout" definieren.
Weitere Informationen finden Sie im Artikel
Benutzerdefinierte JVM-Merkmale. Sie
müssen die angepassten Eigenschaften "com.ibm.ws.webcontainer.ServletDestroyWaitTime"
und "com.ibm.ejs.sm.server.quiesceTimeout" auf allen Serverinstanzen setzen, auf denen die Anwendungseditionen implementiert werden.