Dieser Artikel beschreibt, wie eine aktive Edition durch eine neue ersetzt wird.
Bei der neuen Edition kann es sich um eine einfache Änderung der Anwendung handeln, z. B. eine Fehlerkorrektur, oder
eine wesentlichere Änderung.
Solange die neue Edition rückwärtskompatibel ist, kann ein Rollout durchgeführt werden, um die aktive
Edition zu ersetzen, ohne dass die vorhandenen Clients beeinträchtigt werden.
Zum Rollout einer neuen Edition müssen Sie zuerst die Anwendungsedition mit den neuen Editionsinformationen installieren.
Vorbereitungen
Sie müssen eine Anwendungsedition installiert und gestartet haben.
Gründe und Szenarios für die Ausführung dieser Task
Gehen Sie zum Rollout einer Edition wie folgt vor:
- Klicken Sie auf Anwendungen > Neue Anwendung installieren.
- Geben Sie die neue zu installierende EAR-Datei an und klicken Sie auf Weiter.
- Geben Sie im Feld Anwendungsedition die neuen Editionsinformationen ein.
Geben Sie z. B. 2.0 ein.
- Geben Sie im Feld Anwendungsbeschreibung den Typ der neuen Edition ein, die Sie installieren möchten.
Geben Sie z. B. Zweite Edition ein.
- Füllen Sie die verbleibenden Felder aus und klicken Sie auf Weiter. Weitere
Informationen zur Verwendung des Assistenten für Anwendungsinstallation finden Sie im
WebSphere Application Server Information Center.
- Wählen Sie auf der Seite Servern Module zuordnen in der Liste Cluster
und Server dasselbe Implementierungsziel wie für die aktuelle Edition aus.
Für das Rollout einer Edition gelten unabhängig vom Typ des Implementierungsziels (dynamischer
Cluster, statischer Cluster oder eigenständiger Server) immer dieselben Basisschritte.
Für dieses Lernprogramm klicken Sie auf den dynamischen Cluster BTDC1.
- Wählen Sie in der Liste Vorhandene Arbeitsklassen aus dieser Anwendungsedition klonen die Arbeitsklasse
Edition 1.0 aus und klicken Sie auf Weiter. Wenn Sie eine Anwendungsedition installieren, wird dieser
eine Standardarbeitsklasse zugeordnet.
Die Arbeitsklasse legt die Standard-Routing-Regeln für die Anwendungsedition fest.
Die Arbeitsklassen einer Anwendung bilden die Routing-Policy für diese Anwendung.
Wenn Sie nachfolgende Editionen installieren, können Sie eine Arbeitsklasse Ihrer Wahl zuordnen.
Für das Rollout einer Edition wird jedoch empfohlen, die Arbeitsklasseninformationen beizubehalten.
Jede Edition hat ihre eigene unabhängige Arbeitsklassendefinition. Für dieses Lernprogramm
klonen Sie die Arbeitsklasse der Edition 1.0, um die Arbeitsklasse für die Edition 2.0 festzulegen.
- Bearbeiten Sie die Anzeigen des Installationsassistenten.
- Speichern und synchronisieren Sie Ihre Knoten.
- Klicken Sie auf Anwendungen > Edition Control Center.
- Wählen Sie Ihre neue Edition aus (Edition 2.0) und klicken Sie auf Rollout.
Wählen Sie Atomar oder Gruppiert aus.
Verwenden Sie das Gruppen-Rollout, wenn Sie Editionen in Membern des Ziel-Cluster
gruppenweise ersetzen möchten.
Alternativ können Sie mit Scripting ein Gruppen-Rollout mit einer bestimmten Größe durchführen.
Weitere Informationen hierzu finden Sie im Artikel AdminTasks
für die Verwaltung von Anwendungseditionen. Während des Gruppen-Rollout können Anforderungen so lange von der alten Edition oder der neuen
Edition bearbeitet werden, bis die Ersetzung abgeschlossen ist.
Verwenden Sie die Rollout-Option "atomar", um jeweils in der Hälfte des Cluster eine Edition durch eine andere zu ersetzen.
Auf diese Weise werden alle Benutzeranforderungen jeweils nur von einer Edition der Anwendung verarbeitet.
Dies bedeutet jedoch, dass Ihr Cluster mit halber Kapazität läuft.
Wenn Ihr Cluster sehr groß ist, eignet sich das Gruppen-Rollout unter Umständen besser.
Der atomare Modus kann auch für ein einzelnes Serverimplementierungsziel verwendet werden. In diesem
Fall werden die Aktionen, die sonst für die zweite Hälfte des Cluster ausgeführt werden,
weggelassen.
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 Strategie 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.
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 wird der gesamte Anwendungsserver erneut gestoppt und erneut gestartet. Dabei
werden der Prozessspeicher und alle von der Anwendung verwendeten nativen Bibliotheken
aktualisiert. Auf diese Weise wird eine Nichtverfügbarkeit des virtuellen Speichers verhindert, und
es können neue Versionen der nativen Bibliotheken geladen werden. Beim Rollout einer
Anwendungsedition, die neue Versionen vorausgesetzter nativer Bibliotheken enthält,
müssen Sie "Kaltstart" als Neustartstrategie auswählen.
Mit der Strategie Kaltstart wird die Anwendung zurückgesetzt, indem
jeder Server im Cluster gestoppt und erneut gestartet wird,
sobald die alte Edition durch die neue auf diesem Server ersetzt wurde.
- Legen Sie das Ausräumintervall in Sekunden fest.
Das Ausräumintervall gibt an, wie lange ein Anwendungsserver
Clients mit Affinität zu diesem Server weiter bedient, nachdem ein Rollout-Prozess gestartet wurde und bevor
die Neustartstrategie umgesetzt wird. Affinitäten, z. B. Transaktions-, Aktivitäts- und kompensationsbezogene Affinitäten,
sowie Aktivitäten, die WebSphere Extended Deployment 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 Extended Deployment unbekannt 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.
- Klicken Sie auf OK. Damit wird eine störungsfreie Ersetzung von Edition
1.0 durch Edition 2.0 gestartet.
Ergebnis
Eine Edition, die sich im Validierungsmodus befindet, wird im ursprünglichen Implementierungsziel installiert, und
die geklonte Umgebung wird gelöscht.
Wenn beim Rollout ein Fehler auftritt, versucht der Application Edition Manager, die ausgeführten Aktionen rückgängig zu machen.
Wenn Edition 1.0 beispielsweise in zwei von drei Servern eines Cluster durch
Edition 2.0 ersetzt wurde und beim Ersetzen der Edition im dritten Server ein Fehler auftritt,
ersetzt der Application Edition Manager Edition 2.0 auf dem ersten und zweiten Server wieder durch Edition
1.0.
Nächster Artikel
Zum Überprüfen der Ergebnisse kehren Sie in das Edition Control Center zurück. Wählen Sie dort Ihre Anwendung aus und klicken Sie auf
Editionsimplementierungen verwalten.
Edition
2.0 ersetzt
1.0 als aktive Edition im Implementierungsziel
BTDC1. Die neue Edition wird automatisch gestartet, weil sie eine aktive Edition ersetzt.
Beim Rollout einer Anwendungsedition im Validierungsmodus müssen die Bindungsnamen
auf die ursprünglichen Namen zurückgesetzt werden, z. B.
/clusters/cluster1-validation/jdbc/CustomerData zurück in
/clusters/cluster1/jdbc/CustomerData.