[AIX Solaris HP-UX Linux Windows][z/OS]

Rollout einer Edition durchführen

Wenn Sie ein Rollout einer Edition durchführen, ersetzen Sie eine aktive Edition durch eine neue Edition. Bei der neuen Edition kann es sich um eine einfache Änderung der Anwendung handeln oder um eine wesentlichere Änderung. Falls die neue Edition mit früheren Versionen kompatibel ist, können Sie ein Rollout durchführen, um die aktive Edition zu ersetzen, ohne vorhandene Clients zu beeinträchtigen. Damit ein Rollout einer neuen Edition durchgeführt werden kann, müssen Sie zuerst die Anwendungsedition mit den neuen Editionsinformationen installieren.

Vorbereitende Schritte

Sie müssen eine Anwendungsedition haben, die installiert und gestartet ist, und Sie müssen die Verwaltungsberechtigungen der Rolle Konfiguration (Configurator) oder Verwaltung (Administrator) haben, um ein Rollout durchzuführen.
  • Das Rollout scheitert, wenn zwei Benutzer-IDs in zwei Administrationskonsolen parallel versuchen, den Prozess durchzuführen.
  • Optimieren Sie die SOAP-Connector-Eigenschaften, indem Sie für den Deployment Manager einen Wert angeben, der größer ist als der Wert für den gesamten Zeitraum, der erforderlich ist, um ein Rollout auf Ihrem System durchzuführen, und starten Sie den Deployment Manager erneut. Wenn Sie die Eigenschaft nicht setzen, kann dies dazu führen, dass der Rolloutprozess bei Überschreitung des requestTimeout-Werts fehlschlägt. Die Formel, mit der der zu setzende Wert geschätzt wird, lautet wie folgt: Anzahl_der_Gruppen_für_Rollout * (Ausräumintervall + interne Quiesce-Zeitlimits_ungefähr_5_Minuten + Zeit_für_Anwendungs-/Serverneustart_ungefähr_10_Minuten). Alternativ dazu können Sie den Wert auf 0 setzen, um das Zeitlimit zu inaktivieren.
    • Wenn Sie das Rollout mit dem Tool wsadmin durchführen, passen Sie den Zeitlimitwert für die Anforderung an, indem Sie die Eigenschaft com.ibm.SOAP.requestTimeout bei soap.client.props im Deployment-Manager-Profil setzen. Der Standardwert ist 180 Sekunden und muss entsprechend erhöht werden.
    • Wenn Sie das Rollout über die Administrationskonsole durchführen, passen Sie das Anforderungszeitlimit an, indem Sie auf Systemverwaltung > Deployment Manager > Verwaltungsservices > JMX-Connector > SOAPConnector > Angepasste Eigenschaften > requestTimeout klicken. Der Standardwert beträgt 600 Sekunden und muss entsprechend erhöht werden.

      Weitere Informationen finden Sie in den Beschreibungen der Eigenschaften des JMX-Connectors (Java™ Management Extensions).

  • Wenn Sie einen Rollout in der Administrationskonsole ausführen, setzen Sie die Verfallszeit der Sitzungen für die Administrationskonsole auf einen Wert, der höher ist als der Wert, der die für den gesamten Rollout erforderliche Zeit angibt. Multiplizieren Sie den Wert für das Anforderungszeitlimit mit der Anzahl der Gruppen, die während des Rollouts verarbeitet werden. Weitere Informationen zum Ablauf von Sitzungen für die Administrationskonsole finden Sie im Abschnitt zum Ändern der Verfallszeit für Konsolensitzungen.
  • Sie müssen für jede neue Edition, die Sie installieren, eine Multi-Cluster-Routing-Richtlinie definieren, um ein Rollout durchführen zu können. Führen Sie die entsprechenden Verwaltungstasks aus, um für Ihre neuen Editionen die Multi-Cluster-Routing-Richtlinien hinzuzufügen. Weitere Informationen zu Multi-Cluster-Routing-Richtlinien finden Sie im Abschnitt zu den Regeln für Verwaltungstasks für ODR-Routing-Richtlinien.

Informationen zu diesem Vorgang

Sie können auch Application Edition Manager verwenden, wenn Sie ein Rollout für Stapelanwendungen durchführen möchten. Dabei handelt es sich um Java-EE-5-Anwendungen (Java Enterprise Edition 5), die einem der Programmiermodelle für Stapelanwendungen entsprechen.

Vorgehensweise

  1. Installieren Sie die neue Edition. Führen Sie die im Abschnitt "Anwendungsedition installieren" beschriebenen Schritte aus, aber geben Sie die Informationen zur neuen Edition an. Geben Sie beispielsweise im Feld Anwendungsedition den Wert 2.0 und im Feld Anwendungsbeschreibung die Zeichenfolge Zweite Edition ein. Wählen Sie dieselben Implementierungsziele aus, die auch für die aktuelle Edition verwendet wurden.
  2. Speichern und synchronisieren Sie Ihre Knoten.
  3. Geben Sie die Rollouteinstellungen an. Klicken Sie auf Anwendungen > Edition Control Center > Anwendungsname. Wählen Sie Ihre neue Edition aus, z. B. 2.0, und klicken Sie anschließend auf Rollout.

    Geben Sie die folgenden Einstellungen für Unternehmens- und andere Middlewareanwendungen an:

    1. Wählen Sie Atomar oder Gruppiert als Rollouttyp aus.

      Verwenden Sie die Option Gruppenrollout, wenn Sie Editionen auf Membern des Zielclusters gruppenweise ersetzen möchten. Gewöhnlich wird das Gruppenrollout ausgewählt, das nützlich ist, wenn das Cluster vier oder mehr Member enthält. Alternativ können Sie mit Scripting ein Gruppenrollout mit einer bestimmten Gruppengröße durchführen. Weitere Informationen zum Gruppenrollout finden Sie in den Beschreibungen der Verwaltungstasks für das Management von Anwendungseditionen. Sobald die neue Edition während des Gruppenrollouts verfügbar ist, werden alle Anforderungen an die neue Edition weitergeleitet.

      Verwenden Sie die Rolloutoption 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 Rollouttyp 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 Gruppenrollout durchführen. Der atomare Modus wird auch für ein Implementierungsziel verwendet, das nur einen einzigen Server umfasst. Bei einem solchen Implementierungsziel werden die Aktionen, die sonst für die zweite Hälfte des Clusters ausgeführt werden, einfach weggelassen. Wenn Sie die Implementierungsziele vor Ausführung eines atomaren Rollouts 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 Rolloutperiode bedient werden.

      Fehler vermeiden Fehler vermeiden: Bevor Sie ein atomares Rollout durchführen, ermitteln Sie, welche Arbeitslast der Ziel-Server-Cluster verarbeiten kann. Bei Ausführung eines atomaren Rollouts 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 Rollouts die gesamte Arbeitslast handhaben kann.gotcha
    2. 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 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 des Clusters 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-Kompilierung (Just-in-Time Compilation) verbrauchen.

    3. 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 Intelligent Management 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 Intelligent Management 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 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. Geben Sie den Wert 0 an, um auf die Beendigung der Sitzungen für alle unvollständigen Anforderungen zu warten. Wenn Sie warten möchten, bis das Ausräumintervall oder die Sitzungen für alle unvollständigen Anforderungen beendet wurden, geben Sie für das Ausräumintervall einen größeren Wert als 0 an.

      Der Stilllegungsmanager für Anwendungseditionen wartet 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. Um zu erzwingen, dass beim Warmstart das vollständige Ausräumintervall abgewartet wird, können Sie die Systemeigenschaft appedition.rollout.softreset.fulldrainageinterval im Deployment Manager auf "true" setzen.

      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 in den Beschreibungen der angepassten Eigenschaften des Web-Containers.

      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 zur Eigenschaft "timeout" finden Sie in den Beschreibungen der angepassten JVM-Eigenschaften. Sie müssen die angepassten Eigenschaften com.ibm.ws.webcontainer.ServletDestroyWaitTime und com.ibm.ejs.sm.server.quiesceTimeout in allen Serverinstanzen setzen, auf denen die Anwendungseditionen implementiert werden.

    Geben Sie die folgenden Einstellungen für SIP-Anwendungen (Session Initiation Protocol) an:
    1. Wählen Sie eine Quiesce-Strategie aus. Die Quiesce-Strategie legt fest, wie alte Server oder Cluster-Member, auf denen die aktuelle Edition ausgeführt wird, entfernt werden. Diese Einstellung hat keine Auswirkungen auf die neue Edition, mit der das Rollout durchgeführt wird.
      Server oder Cluster-Member nach Beendigung aller aktiven Sitzungen und Dialoge stilllegen:
      Entfernt den Server bzw. das Cluster-Member, wenn alle aktiven Sitzungen und Dialoge für den Server bzw. das Cluster-Member beendet wurden.
      Server oder Cluster-Member nach dem angegebenen Intervall stilllegen:
      Entfernt den Server bzw. das Cluster-Member nach dem angegebenen Zeitraum. Geben Sie den Zeitraum in Sekunden, Minuten oder Stunden an.
      Achtung: Das Rollout wird für SIP-Anwendungen, die in einem dynamischen Cluster, der aus einem statischen Cluster erstellt wurde, implementiert sind, nicht unterstützt.
  4. Starten Sie das Rollout. Klicken Sie auf OK. Diese Aktion startet die unterbrechungsfreie Ersetzung der vorherigen Edition durch die neue Edition.

Ergebnisse

Wenn sich eine Edition nicht im Validierungsmodus befindet, wird die aktuelle Edition nach Abschluss des Rollouts durch die neue Edition ersetzt. Eine Edition, die sich im Validierungsmodus befindet, wird auf dem ursprünglichen Implementierungsziel installiert, und die geklonte Umgebung wird gelöscht. Die Routing-Regeln werden aktualisiert, um mit dem Routing an die neue Edition zu beginnen.

Während des Anwendungsrolloutprozesses werden Fehler, die in der ersten Zielgruppe auftreten, anders behandelt als Fehler, die in späteren Gruppen auftreten. Bei atomaren Rollouts entspricht die erste Gruppe der ersten Hälfe der Zeile, in denen die neue Edition aktiviert wird. Bei Gruppenrollouts entspricht die erste Gruppe der ersten Gruppe von Zielen, in denen die neue Edition aktiviert wird. Wenn während des Rollouts in der ersten Zielgruppe ein Fehler auftritt (wenn beispielsweise eine Anwendung oder ein Server nicht gestartet werden kann), schlägt der Rolloutprozess fehl. Die aktuelle Anwendungsedition bleibt aktiv. Wenn ein Fehler nach dem Rollout in der ersten Zielgruppe auftritt, wird der Rolloutprozess erfolgreich ausgeführt. Die neue Anwendungsedition wird aktiviert. Die alte Anwendungsedition wird inaktiviert.

Nächste Schritte

Klicken Sie zum Validieren der Ergebnisse auf Anwendungen > Edition Control Center > Anwendungsname. Die neue Edition ist die aktive Edition auf dem Implementierungsziel. Die neue Edition wird automatisch gestartet, weil sie eine aktive Edition ersetzt.

Wenn ein Rollout einer Edition im Validierungsmodus durchgeführt wird, werden die Bindungsnamen auf die ursprünglichen Werte zurückgesetzt. Beispiel: /clusters/cluster1-validation/jdbc/CustomerData wird wieder in /clusters/cluster1/jdbc/CustomerData geändert.


Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twve_appedroll
Dateiname:twve_appedroll.html