Übersicht über Migration, Koexistenz und Interoperabilität
Für die Migration auf eine neue Version von WebSphere Application Server muss eine sorgfältige Betrachtung der Faktoren, wie z. B. Produktedition, Profiltypen, Serverkonfiguration und Anwendungsimplementierung, stattfinden. In dieser Übersicht werden die Konzept, Terminologie, Tools und Strategien eingeführt, mit deren Hilfe Sie das Produkt erfolgreich migrieren können.
Allgemeine Migrationsterminologie
- Version oder Release: Eine Aktualisierung des Produkts, die wesentliche neue Funktionen enthält.
- Edition: In einer Version das Produktpaket, das bestimmte Featuresätze enthält, z. B. Network Deployment.
- Profil: Ein Satz von Dateien, der die Laufzeitumgebung für einen Anwendungsserverprozess, wie z. B. einen Deployment Manager oder einen Anwendungsserver, definiert. Profile enthalten die Konfiguration für das Verhalten des Anwendungsservers und die Implementierungsposition der Anwendungen.
- Quelle: Der Ursprung der Daten und Objekte für die Migration, wie z. B. Quellenprofil oder Quellenmaschine.
- Ziel: Das Ziel der Daten und Objekte für die Migration, wie z. B. Zielprofil oder Zielmaschine.
- Knoten: Eine Gruppierung von verwalteten und nicht verwalteten Server oder Server-Clustern. Jeder von einer Zelle verwaltete Knoten kann eine eindeutige Konfiguration haben.
- Zell: Eine Gruppe, die einen Deployment Manager enthält, der mindestens einen Knoten und mindestens eine Konfiguration verwaltet. Knoten in der Zelle sind in den Deployment Manager eingebunden. Die Konfiguration auf Zellenebene ist auf allen Knoten gängig.
- Heterogene Zellenumgebung: Dieser Begriff wird verwendet, wenn das Release mindestens eines eingebundenen Knotens älter als das Release des Deployment Manager ist, der die Zelle verwaltet. Knoten dürfen nicht mehr als drei Releases älter sein als der Deployment Manager.
Grundlegende Migrationskonzepte
Die Migration einer Zelle mit Deployment Manager und eingebundenen Knoten erfordert besondere Beachtung. Da der Deployment Manager die Konfiguration in der Zelle steuert, muss jeder Knoten bei der Migration mit dem neuen Deployment Manager synchronisiert werden.
Migrationstools
Die Tools, die Sie für die Migration Ihrer Produktkonfiguration verwenden, müssen in der neuen Installation im Zielrelease ausgeführt werden. Aktualisieren Sie, wenn möglich, die neue Installation auf das neueste verfügbare Fixpack, bevor Sie die Migration starten. Die Migrationstools von WebSphere Application ServerVersion 9.0 unterstützt nur die Migration von Version 7.0 oder höher und nicht die Migration in demselben Release, z. B. von Version 9.0 auf Version 9.0. Informationen zum Replizieren Ihrer Konfiguration auf Maschinen derselben Version und desselben Release finden Sie in den Abschnitten zur eigenschaftsbasierten Konfiguration bzw. zur Verwendung des wsadmin-Scripting-Befehls exportWasprofile in der Befehlsgruppe "ConfigArchiveOperations" für das Objekt "AdminTask".
- WASPreUpgrade
- Erstellt einen Snapshot des Quellenprofils der alten Installation und speichert ihn in einem Sicherungsverzeichnis. Für ferne Migrationen erfasst der Befehl WASPreUpgrade weitere von Ihrer Konfiguration referenzierte Artefakte im Sicherungsverzeichnis.
- manageprofiles
- Erstellt das Zielprofil. Das Zielprofil muss denselben Typ haben wie das Quellenprofil. Sie können beispielsweise kein Deployment-Manager-Profil in ein eigenständiges Anwendungsserverprofil migrieren. Je nach Profiltyp müssen außerdem der Zellen- und/oder der Knotenname des Quellenprofils übereinstimmen.
- WASPostUpgrade
- Führt die Daten im Migrationssicherungsverzeichnis im Zielprofil zusammen. Sie können weitere angeben, um zu steuern, ob die alte Konfiguration inaktiviert wird, ob die Installation der Anwendungen verzögert wird usw.
Die Konfigurationsmigrationstools implementieren Ihre Anwendungen im Zielprofil so wie sie im Quellenprofil waren. Testen Sie Ihre Anwendungen vor der Migration Ihrer Konfiugration in einer nicht für Produktionszwecke bestimmten Umgebung mit WebSphere Application Server Version 9.0. Nehmen Sie anschließend Änderungen an den Anwendungen vor, die erforderlich sind, um sicherzustellen, dass die Anwendungen in dieser Umgebung ausgeführt werden. Um die erforderlichen Änderungen schnell zu ermitteln, können Sie Ihre Anwendungen mit Migration Toolkit for Application Binaries und WebSphere Application Server Migration Toolkit scannen. Weitere Informationen finden Sie unter Migration Toolkit auf WASdev.
Sie können den Befehl WASMigrationAppInstaller so oft wie nötig ausführen, um die Anwendungen zu installieren, die nicht vom Befehl WASPostUpgrade installiert wurden.
Für ferne Migrationen können Sie den Befehl createRemoteMigrJar verwenden, um eine JAR-Datei zu erstellen, mit der Sie den Befehl WASPreUpgrade auf einem System ausführen können, auf dem WebSphere Application Server nicht installiert ist.
Verwenden Sie die Migrationstools, um Anwendungen und Konfigurationsdaten auf die neue Version zu migrieren. Dieser Prozess wird im Artikel Produktkonfigurationen migrieren beschrieben. Weitere Informationen finden Sie im Artikel Migrationstools verwenden.
Heterogene Zellenumgebungen
Eine Zelle kann Knoten mit unterschiedlichen Versionen von WebSphere Application Server enthalten. Eine heterogene Zelle mit WebSphere Application Server Version 9.0 kann Knoten enthalten, die WebSphere Application Server Version 9.0 und Version 7.0 oder höher unterstützen. Wenn ein Member einer Zelle in einer heterogenen Zellenumgebung auf dem Stand einer Version vor Version 7.0 ist, können die Tools den Deployment Manager nicht migrieren. Der Administrator muss die Knoten mindestens auf Version 7.0 migrieren oder sie aus der Zelle entfernen.
- Sie führen eine schrittweise Migration Ihres vorhandenen Systems durch.
- Sie migrieren den Deployment Manager auf Version 9.0. Der Deployment Manager muss den höchsten Knotenversionsstand haben. Wenn Knoten mit einer früheren Versionen existieren, wird durch diese Migration des Deployment Manager eine heterogene Zelle mit der höchsten Version von WebSphere Application Server erstellt.
- Wenn Sie anschließend die Knoten nacheinander auf die höchste Version migrieren,
ändert sich die Zelle in eine Zelle mit der höchsten Version von WebSphere Application Server.
Anmerkung: Diese Zelle kann keine höhere Version haben als der Deployment Manager.
- Sie migrieren den Deployment Manager auf Version 9.0
und binden anschließend die Knoten mit der älteren Version in den Deployment Manager der neuen Version ein.
Diese Art der Migration wird nur für Knoten mit Version 7.0 oder höher unterstützt.
- Zunächst migrieren Sie den Deployment Manager auf Version 9.0. Der Deployment Manager muss den höchsten Knotenversionsstand haben.
- Anschließend können Sie Knoten mit Version 7.0 oder höher in die neue höchste Deployment-Manager-Version einbinden.
Fehler vermeiden: Bei dieser Methode der schrittweisen Migration verbleibt Ihr System in einer heterogenen Zellenumgebung, wobei die Knoten von einem Deployment Manager von Version 9.0 verwaltet werden. Ihr Migrationsplan sollte letzten Endes die Migrationen aller Knoten auf den Stand von Version 9.0 vorsehen, damit eine einheitliche Verwaltung der Knoten sichergestellt ist.gotcha
Vorhandene Funktionen funktionieren in einer heterogenen Zellenumgebung weiterhin Sie sollten in der Lage sein, angemessene Operationen auszuführen, wie z. B. vorhandene Anwendungen ausführen, Verwaltungsoperationen wie "addNode" ausführen, einen heterogenen Cluster erstellen, das System konfigurieren, MBeans aufrufen und Anwendungen implementieren. Eine Entscheidung bezüglich der Unterstützung neuer Funktionen in einer heterogene Zellenumgebung kann von Fall zu Fall auf der Grundlage der Funktion, der Priorität und der verfügbaren Ressourcen getroffen werden.

Wenn ein Problem auftritt, das die Kommunikation des Clients mit dem Node Agent oder die Weiterleitung der neuen Portdaten zwischen den Cluster-Membern und dem Node Agent verhindert, können Anforderungen im Client fehlschlagen. In einigen Fällen sind diese Fehler temporär. In anderen Fällen müssen Sie einen oder mehrere Prozesse erneut starten, um einen Fehler zu beheben.
Zum Vermeiden der Probleme beim Client-Routing, die in diesen Fällen auftreten können, können Sie auf den Cluster-Membern statische Ports konfigurieren. Bei Verwendung statischer Ports ändern sich die Portdaten nicht, während ein Clientprozess Informationen zu den Cluster-Membern abruft. Selbst wenn die Cluster-Member erneut gestartet werden oder Probleme bei der Kommunikation oder der Weiterleitung von Daten zwischen Prozessen bestehen, sind die vom Client gespeicherten Portdaten immer noch gültig. Diese Umgehung führt nicht notwendigerweise dazu, dass diese Probleme gelöst werden, doch treten die Symptome nicht erwarteter oder uneinheitlicher Routing-Entscheidungen nicht mehr auf.
gotchaWenn Sie weder die Migrations- noch die Koexistenzoption für die frühere Version von WebSphere Application Server auswählen, wird die vorhandene Installation ignoriert. Aufgrund der miteinander in Konflikt stehenden Portzuordnungen können Sie jeweils nur eine einzige Version ausführen. Es können problemlos beide Versionen gleichzeitig ausgeführt werden, wenn Sie in einer der Versionen andere Ports als die Standardports verwenden.
Potenzielle Migrationsprobleme
Weitere Informationen
WebSphere Application Server Version 9.0 kann mit Version 7.0 oder höher koexistieren. Je nachdem, welche Version von WebSphere Application Server zuvor verwendet wurde, können Portkonflikte auftreten, die aufgelöst werden müssen. Weitere Informationen finden Sie in den Artikeln Koexistierende Anwendungsserver ausführen und Porteinstellungen konfigurieren.
Bei der Migration von WebSphere Application Server werden die vorhandene Konfiguration und die vorhandenen Anwendungen verwendet und so geändert, dass sie mit der Umgebung mit WebSphere Application Server Version 9.0 kompatibel sind. Vorhandene Anwendungskomponenten und Konfigurationseinstellungen werden während des Migrationsprozesses auf die Umgebung mit Version 9.0 angewendet.
Falls Sie eine frühere Version von WebSphere Application Server verwenden, hat der Systemadministrator möglicherweise Anwendungs- und Servereinstellungen speziell auf die Umgebung abgestimmt. Es ist wichtig, eine Strategie für die Migration dieser Einstellungen zu haben, die ein Höchstmaß an Effizienz gewährleistet.
Für eine schrittweise manuelle Migration der Konfiguration von WebSphere Application Server Version 7.0 oder höher können Sie die Migrationstools mehrere Male ausführen und jedes Mal eine andere Gruppe von Profilen angeben. Eine schrittweise Migration von WebSphere Application Server bedeutet in der Regel, dass Ihr System in einer heterogenen Releaseumgebung ausgeführt wird. Eine Migration in dieser Umgebung zieht Knotenmigrationen zu verschiedenen Zeiten mit sich, sodass über eine längere Zeit heterogene Zellen existieren, bis die Migration abgeschlossen ist.