WebSphere Extended Deployment Compute Grid, Version 6.1.1
             Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows,


Rollout einer Edition durchführen

Wenn Sie den Anwendungseditionsmanager verwenden möchten, um ein Rollout von Compute-Grid-Anwendungen durchzuführen, müssen Sie Eigner der Komponente "Operations Optimization" von WebSphere Extended Deployment sein. Compute-Grid-Anwendungen sind J2EE-Anwendungen (Java 2 Platform Enterprise Edition), die einem der Grid-Programmiermodelle entsprechen. Wenn Sie ein Rollout einer Edition durchführen, ersetzen Sie eine aktive Edition durch eine neue Edition.

Vorbereitungen

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 diese Task auszuführen.
Anmerkung: Das Rollout der Anwendungsedition scheitert, wenn zwei Benutzer-IDs in zwei Administrationskonsolen versuchen, ein paralleles Rollout einer Anwendungseditition durchzuführen.

Informationen zu dieser Task

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 abwä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.

Prozedur

  1. Installieren Sie die neue Edition. Geben Sie 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 Rollout-Einstellungen 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- oder andere Middleware-Anwendungen an:

    1. 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 hilfreich ist, wenn es sich um einen großen Cluster handelt. Alternativ können Sie mit Scripting ein Gruppen-Rollout mit einer bestimmten Gruppengröße durchführen. Weitere Informationen finden Sie in den Beschreibungen der Tasks zur Verwaltung 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 Option Atomares Rollout, 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 Ihr Cluster sehr groß ist, sollten Sie das Rollout auf kleinere Gruppen aufteilen. Hierfür dient das Gruppen-Rollout. Der atomare Modus kann 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.

    2. Wählen Sie die Neustartstrategie aus. Die Neustartstrategie teilt dem Anwendungseditionsmanager 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. 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 Anwendungsedition 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.

    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 Anwendungseditionsmanager wartet, 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. Dies ist für persistente Sitzungen, z. B. solche Sitzungen, die in der Datenbank gesichert sind oder über DRS repliziert werden, nicht erforderlich, aber für temporäre (im Hauptspeicher befindliche) Sitzungen wichtig. 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.

    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 Auswirkung auf die neue Edition, mit der das Rollout durchgeführt wird.
      • Server oder Cluster-Member nach Beendigung aller aktiven Sitzungen und Dialoge stilllegen: Entfernt die Server bzw. Cluster-Member, wenn alle aktiven Sitzungen und Dialoge für die jeweiligen Server bzw. Cluster-Member beendet sind.
      • 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.
  4. Starten Sie das Rollout. Klicken Sie auf OK. Diese Aktion startet die unterbrechungsfreie Ersetzung der älteren 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. Für eine Compute-Grid-Anwendung bricht der Job-Scheduler nach Ablauf der Ausräumzeit diese Jobs (für das Rollout der Anwendung), die immer noch an den stillgelegten Endpunkten ausgeführt werden, ab.

Nächste Schritte

Zum Validieren der Ergebnisse klicken Sie auf Anwendungen > Edition Control Center > Anwendungsname. Die neue Edition sollte die aktive Edition auf dem Implementierungsziel sein. 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 Werte zurückgesetzt werden, z. B. /clusters/cluster1-validation/jdbc/CustomerData zurück in /clusters/cluster1/jdbc/CustomerData.




Zugehörige Informationen
Compute-Grid-Jobs und ihre Umgebung verwalten
Task-Artikel    

Nutzungsbedingungen | Feedback

Letzte Aktualisierung: 24.09.2009 16.46 Uhr EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.gridmgr.doc/info/scheduler/tcgappedroll.html