Mit dem Application Edition Manager können Sie unterschiedliche Versionen und Editionen Ihrer Anwendung verwalten. Dieser Artikel beschreibt den Unterschied zwischen Versionen und Editionen im Application Edition Manager, die Methoden für den Upgrade Ihrer Anwendung sowie Validierung und Kompatibilität von Editionen.
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. Diese Begriffe unterscheiden zwischen dem, was in Ihrer Entwicklungs- und Build-Umgebung geschieht, und dem, was in Ihrer Implementierungs- und Betriebsumgebung geschieht.
Viele Geschäftsanwendungen setzen eine konstante Verfügbarkeit voraus. Optionen für Konfigurationen von WebSphere Application Server, die eine ständige Verfügbarkeit unterstützen, sind im WebSphere Application Server Network Deployment Information Center und anderen Quellen wie IBM Redbooks dokumentiert. Der Standard für Anwendungsverfügbarkeit setzt voraus, dass Anwendungen in Anwendungsserver-Clustern implementiert werden. Die Redundanz eines Cluster ist für die Gewährleistung einer ständigen Verfügbarkeit unerlässlich.
Störungsfreier Anwendungs-Upgrade bezieht sich auf die Fähigkeit, einen Upgrade ohne Beeinträchtigung der ständigen Verfügbarkeit der Anwendung durchführen zu können. Benutzer der Anwendung müssen während des Upgrades der Anwendung keinen Serviceausfall hinnehmen.
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. Beispielsweise werden Anwendungen, die vor dem Hinzufügen der Edition-Manager-Unterstützung zur WebSphere Extended Deployment-Zelle installiert wurden, im Edition Manager als Basiseditionen angezeigt.
Editionsaktivierung unterscheidet zwischen zwei Status, die eine Anwendungsedition annehmen kann. Wenn eine Edition installiert wird, ist sie inaktiv. Eine inaktive Edition kann nicht gestartet werden. Es ist eine explizite Aktion erforderlich, um eine Edition in den Status aktiv zu versetzen. Eine aktive Edition kann gestartet werden. 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-Policy definieren, die festlegt, welche Benutzer Zugriff auf die Edition haben.
Eine Routing-Policy verhindert Mehrdeutigkeit und bestimmt, welche Edition die Steuerung erhält.
Im Folgenden sehen Sie ein Beispieldiagramm für gleichzeitige Aktivierung:
WebSphere Extended Deployment stellt Routing-Policys für Anwendungen bereit. Eine Routing-Policy wird mit den Konfigurationsmetadaten einer Anwendung gespeichert. Mit einer Routing-Policy können Sie Regeln festlegen, die den On Demand Router (ODR) anweisen, basierend auf bestimmten Kriterien bestimmte Anwendungsanforderungen an eine Edition oder eine andere zu senden. Sie können verschiedene Kriterien verwenden, die angeben, welche Anforderungen an eine bestimmte Anwendungsedition gesendet werden. Auf diese Weise können Anforderungen von bestimmten Benutzern an eine Edition und Anforderungen von anderen Benutzern an eine andere Edition gesendet werden.
Edition-Rollout bezieht sich auf die Implementierung und Aktivierung einer Anwendungsedition in einem Server-Cluster. Damit Anwendungsaktualisierungen störungsfrei durchgeführt werden können, werden beim Anwendungs-Rollout Anforderungen für die Anwendung in einem bestimmten Server stillgelegt, wodurch der Server vor dem Empfang neuer Anforderungen geschützt wird. Anschließend wird die derzeit aktive Edition gestoppt, die neue Edition gestartet und schließlich der Anforderungsfluss an die Edition wieder freigegeben. Beim Editions-Rollout in einem Server-Cluster werden diese Aktivitäten auf den Servern im Cluster ausgeführt.
Beim Gruppen-Rollout wird eine Edition auf Membern des Ziel-Cluster gruppenweise ersetzt. 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. Beim Gruppen-Rollout werden Server gleichzeitig auf die neue Edition aktualisiert. Jeder Server in der Gruppe wird stillgelegt, ausgeräumt, gestoppt und zurückgesetzt. Mit der Administrationskonsole kann jeweils nur eine Gruppe aktualisiert werden. Alternativ können Sie Scripts verwenden, um das Rollout für mehrere Gruppen durchzuführen.
Es gibt Zeiträume während des Gruppen-Rollout, in denen beide Editionen der Anwendung - die alte und die neue - verfügbar sind und gleichzeitige Benutzeranforderungen bearbeiten. Es gibt einige Server im Cluster, bei denen die Umstellung von der alten Edition auf die neue Edition bereits stattgefunden hat, einige Server, bei denen die Umstellung gerade durchgeführt wird, und einige Server, für die die Umstellung noch nicht gestartet wurde. Sofern keine Routing-Regel etwas anderes definiert, werden Anwendungsanforderungen an die Server gesendet, die eine aktive Instanz einer Edition der angeforderten Anwendung haben. Wenn Sie beispielsweise ein Rollout von Edition 1.0 auf 1.1 durchführen, können Anwendungsanforderungen von Edition 1.0 und 1.1 bearbeitet werden, solange das Rollout noch nicht abgeschlossen ist.
Die folgende Abbildung zeigt ein Beispiel für ein Gruppen-Rollout:
Die Rollout-Option atomar ersetzt eine Edition auf der Hälfte der Cluster-Server gleichzeitig, damit alle Benutzeranforderungen jeweils einheitlich von einer Edition der Anwendung bearbeitet werden. Zu jedem Zeitpunkt werden alle Benutzeranforderungen entweder von der alten oder von der neuen Edition verarbeitet.
Durch das atomare Rollout wird sichergestellt, dass alle Anwendungsanforderungen von jeweils einer Edition, z. B. 1.0 oder 1.1, aber nicht von beiden Editionen verarbeitet 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 verarbeiten könnte. Deshalb reiht der ODR alle Anforderungen, die für diese Anwendung ankommen, vorübergehend in eine Warteschlange ein. Wenn die die vollständig offline ist, wird die erste Hälfte des Cluster wieder online gesetzt. Die zweite Hälfte des Cluster wird von der alten auf die neue Edition umgestellt und wieder online gesetzt.
Die folgende Abbildung zeigt ein Beispiel für ein atomares Rollout:
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-Regel 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. Hierbei verlässt die Edition den Validierungsmodus. Beim Verlassen des Validierungsmodus wird das Validierungsziel gelöscht.
Die folgende Abbildung zeigt ein Beispiel für Validierung:
Einige Anwendungsänderungen sind für Benutzer transparent und andere nicht. Wenn ein Anwendungs-Upgrade mindestens dieselben Anwendungsprogrammierschnittstellen wie die letzte Änderung und keine semantischen Änderungen an wesentlichem Verhalten enthält, ist diese Anwendungsedition ein abwärtskompatibler Upgrade. Vorhandene Benutzer können die aktualisierte Anwendung verwenden, ohne ihre Verwendungsweise zu ändern, und sollten auch keine Unterschiede zwischen der aktuellen und den früheren Editionen erkennen.
Ein Anwendungs-Upgrade, der von vorhandenen Benutzer eine Umstellung in ihrer Verwendung der Anwendung erfordert, ist ein inkompatibler Upgrade. Manchmal 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.
Related concepts
Application Edition Manager
Related tasks
Lernprogramm zum Edition Manager
Related reference
Editionsstatus