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

Konzepte des Application Edition Manager

Wenn Sie den Unterschied zwischen Versionen und Editionen im Application Edition Manager, die Methoden für die Implementierung und das Upgrade Ihrer Anwendung sowie Validierung und Kompatibilität von Editionen verstehen, können Sie den Application Edition Manager zur Verwaltung Ihrer Anwendungsimplementierungen einsetzen.

Mit einer Edition können nicht verwaltete Webanwendungen definiert werden. Für diese Anwendungen kann jedoch weder ein Rollout durchgeführt werden, noch können sie in den Validierungsmodus versetzt werden. Nicht verwaltete Webanwendungen werden zwar unterstützt, aber aufgrund ihres Charakters stehen ihnen nicht alle Funktionen zur Verfügung, wie es bei Anwendungen mit unterstütztem Life-Cycle-Management der Fall ist.
Veraltetes Feature Veraltetes Feature: Server mit unterstütztem und vollständigem Lifecycle-Management sind in WebSphere Application Server Version 9.0 veraltet. Migrieren Sie WebSphere Liberty-Server in eine Liberty-Verbundkonfiguration. Es gibt keine empfohlene Migrationsaktion für andere Servertypen.depfeat

Versionen und Editionen

Die Begriffe Version und Edition unterscheiden zwischen dem, was in Ihrer Entwicklungs- und Build-Umgebung geschieht, und dem, was in Ihrer Implementierungs- und Betriebsumgebung geschieht. Eine Version ist eine Nachfolgegeneration einer Schnittstelle, einer Funktion, einer Implementierung, einer gesamten Anwendung usw. Version ist ein Entwicklungs- und Build-Konzept. Eine Edition ist eine Nachfolgegeneration einer Implementierung, z. B. der Implementierung einer bestimmten Gruppe versionsgesteuerter Artefakte. Edition ist ein Implementierungs- und Betriebskonzept.

Eine Anwendungsedition ist eine eindeutige Implementierung einer bestimmten Anwendung. In der Verwaltungsumgebung von WebSphere Application Server ist eine Anwendungsedition eine Anwendung, die durch die Kombination eines Anwendungsnamens und eines Editionsnamens eindeutig gekennzeichnet ist. Mehrere Editionen derselben Anwendung können denselben Anwendungsnamen haben, aber nicht denselben Editionsnamen. Der Editionsname kann numerisch, z. B. 1.0 oder 2.0, oder beschreibend sein, z. B. erste Edition oder blaue Edition.
  • Basisedition bezieht sich auf eine implementierte Anwendung, die keine Editionsinformationen besitzt.
  • Editionsaktivierung unterscheidet zwischen zwei Status, die eine Anwendungsedition annehmen kann. Wenn eine Edition installiert wird, ist sie inaktiv. Die Edition kann nur gestartet werden, wenn sie aktiv ist. Der Übergang vom Status inaktiv in den Status aktiv wird als Aktivierung bezeichnet.
  • Gleichzeitige Aktivierung bezeichnet den Vorgang, bei dem mehrere Editionen derselben Anwendung aktiv sind und gleichzeitig gestartet werden. Wenn mehrere Editionen gleichzeitig aktiv sind, können einige Benutzer auf die eine und andere Benutzer auf eine andere Edition zugreifen. Wenn Sie beispielsweise eine neue Edition einer Anwendung einführen, liegt Ihnen möglicherweise daran, dass eine von Ihnen ausgewählte Gruppe von Benutzern die Edition testet, aber nicht alle Benutzer Zugriff auf die neue Edition haben. Für die gleichzeitige Aktivierung müssen Sie eine Routing-Richtlinie definieren, die festlegt, welche Benutzer Zugriff auf die Edition haben. Eine Routing-Richtlinie wird mit den Konfigurationsmetadaten einer Anwendung gespeichert. Eine Routing-Richtlinie verhindert außerdem Mehrdeutigkeit und bestimmt, welche Edition die Steuerung erhält. Das folgende Beispiel zeigt ein Diagramm von gleichzeitig aktiven Editionen.
Abbildung 1. Gleichzeitig aktive EditionenAbbildung 1 zeigt mehrere Editionen derselben gleichzeitig aktivierten Anwendung

Anwendungsupgrade und -implementierung

Viele Geschäftsanwendungen setzen eine konstante Verfügbarkeit voraus. Der Standard für Anwendungsverfügbarkeit setzt voraus, dass Anwendungen in Anwendungs-Server-Clustern implementiert werden. Die Redundanz eines Clusters ist für die Gewährleistung einer ständigen Verfügbarkeit unerlässlich. Unterbrechungsfreies Anwendungsupgrade bezieht sich auf die Fähigkeit, ein Upgrade ohne Beeinträchtigung der ständigen Verfügbarkeit der Anwendung durchführen zu können. Anders ausgedrückt, Benutzer der Anwendung müssen während des Upgrades der Anwendung keinen Serviceausfall hinnehmen.

Wenn Sie ein Rollout einer Edition durchführen, ersetzen Sie eine aktive Edition durch eine neue Edition. Damit ein unterbrechungsfreies Anwendungsupgrade sichergestellt wird, umfasst das Rollout einer Edition folgende Schritte:
  • Einen Server vom Eingang weiterer Anforderungen abschirmen.
  • Anforderungen für Anwendungen in einem bestimmten Server stilllegen.
  • Die derzeit aktive Edition stoppen.
  • Die neue Edition starten.
  • Den Anforderungsfluss an die Edition wiederaufnehmen.

Wenn Sie ein Rollout einer Edition in einem Anwendungs-Server-Cluster ausführen, werden diese Aktivitäten für alle Server des Clusters ausgeführt:

Wenn ein Gruppenrollout in einem Zielcluster ausgeführt werden soll, können Sie das Cluster in Gruppen unterteilen und eine Gruppengröße definieren, die die Anzahl der Knoten angibt, die gleichzeitig verarbeitet werden sollen. Wenn das Gruppenrollout durchgeführt wird, werden die Server einer Gruppe gleichzeitig auf die neue Edition aktualisiert. Jeder Server in der Gruppe wird stillgelegt, gestoppt und zurückgesetzt. Über die Administrationskonsole kann jeweils nur ein Rollout für eine Gruppe durchgeführt werden. Sobald ein Member der neuen Edition verfügbar ist, werden alle Anforderungen an die neue Edition weitergeleitet.

Während Sie ein Rollout einer Edition durchführen, gibt es einige Server im Cluster, die von der alten Edition auf die neue Edition umgestellt wurden, einige Server, bei denen die Umstellung gerade durchgeführt wird, und einige Server, für die die Umstellung noch nicht gestartet wurde. Alle Anwendungsanforderungen werden an einen beliebigen Server gesendet, der eine aktive Instanz der letzten Edition der angeforderten Anwendung besitzt. Wenn Sie beispielsweise ein Rollout von Edition 1.0 auf 2.0 durchführen, werden alle Anwendungsanforderungen von 2.0 bedient, sobald Edition 2.0 auf dem Server verfügbar ist. Alle Server, auf denen weiterhin die Edition 1.0 ausgeführt wird, bedienen so lange keine Anforderungen, bis der Server auf Edition 2.0 aktualisiert wird. Das folgende Beispiel zeigt ein Diagramm eines Gruppenrollout.

Abbildung 2. Gruppenrollout
Abbildung 2 zeigt ein Diagramm eines Gruppenrollouts, bei dem ein Zielcluster in Gruppen aufgeteilt wird

Bei Ausführung eines atomaren Rollouts einer Edition wird eine Edition auf der Hälfte der Cluster-Server gleichzeitig ersetzt, damit alle Benutzeranforderungen einheitlich von einer Edition der Anwendung bedient werden. Alle Benutzeranforderungen werden entweder von der alten oder von der neuen Edition bedient, aber niemals von beiden Editionen.

Durch das atomare Rollout wird sichergestellt, dass alle Anwendungsanforderungen von einer Edition, entweder 1.0 oder 2.0, aber nicht von beiden Editionen, bedient werden. Die derzeit verfügbare Edition wird in der Hälfte der Server im Cluster offline gesetzt. In diesen Servern wird die neue Edition aktiviert und gestartet. Sie bleiben aber so lange offline, bis der nächste Schritt abgeschlossen ist. Im nächsten Schritt wird die derzeit aktive Edition in den verbleibenden Servern offline gesetzt. Zu diesem Zeitpunkt besitzt keiner der Server eine Instanz einer der beiden Editionen, die die Anwendungsanforderungen bedienen könnte. Deshalb stellt der ODR alle Anforderungen, die für diese Anwendung ankommen, vorübergehend in eine Warteschlange. Wenn die Anwendung vollständig offline ist, wird die erste Hälfte des Clusters wieder online gesetzt. Die zweite Hälfte des Clusters wird von der alten auf die neue Edition umgestellt und wieder online gesetzt. Das folgende Beispiel zeigt ein Diagramm eines atomaren Rollouts:

Abbildung 3. Atomares Rollout
Abbildung 3 veranschaulicht, wie die erste Hälfte des Zielclusters wieder online gesetzt wird, nachdem die gesamte Anwendung offline gegangen ist, und wie die zweite Hälfte des Clusters von der alten auf die neue Edition umgestellt und wieder online gesetzt wird.

Editionsvalidierung und -kompatibilität

Editionsvalidierung bezeichnet einen Sonderfall gleichzeitiger Aktivierung, bei dem das zugeordnete Implementierungsziel einer Edition, z. B. ein dynamischer Cluster, geklont wird und die Edition dann in dem geklonten Implementierungsziel gestartet werden kann. Das geklonte Implementierungsziel ist das so genannte Validierungsziel. Es müssen Routing-Regeln verwendet werden, die festlegen, welche Anwendungsanforderungen an die zu validierende Edition gesendet werden. Wenn eine Edition validiert wird, befindet sie sich im Validierungsmodus.

Im Validierungsmodus wird sichergestellt, dass eine neue Edition einer Anwendung in ihrer Produktionsumgebung funktioniert, ohne die derzeit verfügbare Edition offline setzen zu müssen. Gewöhnlich wird eine Testarbeitslast an eine Edition im Validierungsmodus gesendet, um zu prüfen, ob gewisse Teile der Anwendungsumgebung und -konfiguration, z. B. Konnektivität und Datenbankzugriff, wie erwartet funktionieren. Wenn ein Rollout einer Edition im Validierungsmodus durchgeführt wird, findet das Rollout in dem Implementierungsziel statt, in dem die Edition ursprünglich installiert wurde. Durch das Rollout verlässt die Edition den Validierungsmodus. Nach Abschluss der Validierung wird das Validierungsziel gelöscht. Das folgende Beispiel zeigt ein Diagramm einer Editionsvalidierung.

Abbildung 4. Editionsvalidierung
Abbildung 4 zeigt, wie ein dynamischer Cluster geklont und die Edition dann während der Editionsvalidierung für den Start im geklonten Implementierungsziel vorbereitet wird.

Einige Anwendungsänderungen sind transparent, andere können nur vom Endbenutzer gesehen werden. Wenn ein Anwendungsupgrade mindestens dieselben Anwendungsprogrammierschnittstellen wie die letzte Änderung und keine semantischen Änderungen des wesentlichen Verhaltens aufweist, ist diese Anwendungsedition ein abwärtskompatibles Upgrade. Vorhandene Benutzer können die aktualisierte Anwendung verwenden, ohne ihre Verwendungsweise zu ändern und ohne Unterschiede zwischen der aktuellen und den früheren Editionen zu erkennen.

Ein Anwendungsupgrade, das von vorhandenen Benutzern eine Umstellung bei der Verwendung der Anwendung erfordert, ist ein inkompatibles Upgrade. Möglicherweise muss eine ältere Funktion entfernt oder eine Schnittstelle geändert werden, um beispielsweise die Wartungsfreundlichkeit oder andere Faktoren zu verbessern. Dabei ist es möglich, dass inkompatible Änderungen in Ihre Implementierungsumgebung eingeführt werden. Inkompatible Änderungen erfordern eine sorgfältige Planung, damit die Auswirkungen auf die vorhandenen Benutzer gesteuert werden können.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



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