Ü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.
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.
Häufig gestellte Fragen
Kann ich einfach auf die neuen Dateien von WebSphere Application Server for z/OS Version 9.0 verweisen und meine Server erneut starten?
Nein. WebSphere Application Server for z/OS Version 9.0 erfordert die Migration Ihrer Konfiguration von Version 7.0 oder höher auf Version 9.0.
Wird die Migration für jeden Knoten einzeln ausgeführt?
Ja. Bei der Migration der Konfiguration werden die bereitgestellten Dienstprogramme für jeden einzelnen Knoten in Ihrer Konfiguration ausgeführt.
Obwohl ein eigenständiger Anwendungsserver nur einen Knoten hat, muss dieser Knoten migriert werden. Die Schritte sind im Wesentlichen dieselben wie bei der Migration eines anderen Knotens. Die einzige Ausnahme ist, dass kein Deployment Manager aktiv ist. Im Artikel Eigenständigen Anwendungsserverknoten unter z/OS migrieren: Prüfliste finden Sie eine Prüfliste der Aktivitäten, die für die Migration eines eigenständigen Anwendungsserverknotens ausgeführt werden müssen.
Was tun die Migrationsdienstprogramme?
Die Migrationsdienstprogramme haben folgende Zielsetzungen:
Dienstprogramm | Zweck |
BBOWMG1B (Migrationen eigenständiger Anwendungsserver) BBOWMG1F (Migrationen eingebundener Knoten) |
Ermöglicht, dass alle Server auf dem zu migrierenden Knoten für den Start
im PRR-Modus (Peer Restart and Recovery) konfiguriert werden können.
Nachdem dieser Job abgeschlossen ist, müssen Sie alle Server auf dem zu migrierenden Knoten starten und warten, bis sie beendet sind. Der PRR-Verarbeitungsmodus löst alle ausstehenden Transaktionen auf, löscht die Transaktionsprotokolle und stoppt den Server. Dieser Job wird nicht für eine Migration des Deployment Manager benötigt und ist für Konfigurationen, die keine Connectors für verteilte Transaktionen (XA) verwenden, optional. Dieser Job ist nur erforderlich, wenn Sie XA-Adapter verwenden und die XA-Protokolle migrieren müssen. Überprüfen Sie Ihre Ressourcenprovider in der Administrationskonsole von Version 7.0 oder höher, indem Sie auf Ressourcen > JDBC-Provider klicken und überprüfen, ob XA-Provider wie DB2, Apache Derby ausgewählt wurden. |
BBOWMG2B (Migrationen eigenständiger Anwendungsserver) BBOWMG2F (Migrationen eingebundener Knoten) |
Inaktiviert den PPR-Modus und
versetzt alle Server
in den normale Betriebsmodus zurück.
Nach Abschluss dieses Jobs müssen nicht alle Server gestartet werden. Dieser Job wird nicht für eine Migration des Deployment Manager benötigt und ist für Konfigurationen, die keine XA-Connectors verwenden, optional. Dieser Job ist nur erforderlich, wenn Sie XA-Adapter verwenden und die XA-Protokolle migrieren müssen. Überprüfen Sie Ihre Ressourcenprovider in der Administrationskonsole von Version 7.0 oder höher, indem Sie auf Ressourcen > JDBC-Provider klicken und überprüfen, ob XA-Provider wie DB2, Apache Derby ausgewählt wurden. |
BBOMBHFS oder BBOMBZFS (Migrationen eigenständiger Anwendungsserver)
BBOMDHFS oder BBOMDZFS (Migrationen von Deployment Managern) BBOMMHFS oder BBOMMZFS (Migrationen eingebundener Knoten) |
Optional: Erstellt ein Dateisystem und einen Mountpunkt
für das Konfigurationsstammverzeichnis von Version 9.0
und hängt das Dateisystem an. Falls Sie für die Konfiguration von Version 9.0 ein vorhandenes Dateisystem verwenden möchten, müssen Sie den Mountpunkt, der beim Erstellen der Migrationsdefinition angegeben wurde, manuell erstellen und sich vergewissern, dass das Dateisystem angehängt ist, anstatt diesen Job auszuführen. In jedem Fall müssen Sie das Konfigurationsdateisystem sowie den Mountpunkt erstellen und das Dateisystem anhängen, bevor Sie mit der Migration fortfahren. |
Folgende Dienstprogramme für die Migration eigenständiger
Anwendungsserver:
Folgende Dienstprogramme für die Migration eines Deployment Manager:
Folgende Dienstprogramme für die Migration eingebundener Knoten:
|
BBOWMG3x führt die vollständige Migration des Knotens von Version 7.0 oder höher auf Version 9.0 durch. BBOWxPRO erstellt lediglich das Ausgangs- und Standardprofil von WebSphere Application Server. BBOWxPRE führt lediglich den upgradevorbereitenden Prozess für die Migration aus. BBOWxPOS führt lediglich die upgradenachbereitenden und Abschlussprozesse (Änderung der Dateiberechtigung) für die Migration aus. |
BBOMBCP (Migrationen eigenständiger Anwendungsserver) BBOMDCP (Migrationen von Deployment Managern) BBOMMCP (Migrationen eingebundener Knoten) |
Kopiert die generierten
JCL-Prozeduren zum Starten der Server in die angegebene Prozedurenbibliothek.
Wenn Sie festlegen, dass die Konfiguration von Version 9.0 andere JCL-Startprozedurnamen verwenden soll, aktualisiert dieses Dienstprogramm die neue Konfiguration von Version 9.0 und ersetzt dabei die Namen, die in der ursprünglichen Konfiguration von Version 7.0 oder höher enthalten waren, durch die neuen JCL-Namen. |
Wo sollen die Migrationsjobs ausgeführt werden?
Führen Sie die Jobs in demselben System aus, in dem sich der zu migrierende Knoten befindet.
Was geschieht, wenn ein Knoten migriert wird?
Die Migrationsdienstprogramme wandeln den Inhalt des Konfigurationsdateisystems von WebSphere Application Server Version 7.0 oder höher um und fügen ihn zu einem neuen eigenständigen Konfigurationsdateisystem von Version 9.0 zusammen.
Gehen vorhandene Konfigurationen während der Migration verloren?
Während der Migration bleibt die ursprüngliche Konfigurationsstruktur von WebSphere Application Server Version 7.0 oder höher erhalten. Falls die Migration vor der Beendigung fehlschlägt, bleibt die vorhandene Konfiguration erhalten.
Werden alle Anwendungsserver migriert, wenn der Knoten mehrere Anwendungsserver hat?
Ja. Das Dienstprogramm ermittelt und migriert alle Server, einschließlich des Node Agent. Wenn Sie die Migrationsdienstprogramme für den Knoten aufrufen, werden alle Server auf dem Knoten migriert.
Müssen die Server auf einem Knoten gestoppt werden, damit die Migration durchgeführt werden kann?
Ja. In einer Konfiguration mit mehreren Knoten ist es möglich, die anderen Knoten aktiv zu lassen. Für jeden Knoten, den Sie migrieren möchten, müssen Sie die Server stoppen.
Wenn ein Anwendungsserverknoten, der Teil einer Network-Deployment-Konfiguration ist, migriert wird, muss der Deployment Manager von Version 9.0 für diese Zelle aktiviert sein. Dies liegt daran, dass die Migration zum Teil die Verwendung der wsadmin-Scripting-Funktion erfordert, um den neu migrierten Anwendungsserverknoten mit dem Deployment Manager zu synchronisieren. Der Deployment Manager muss aktiv sein, um diese Synchronisation ausführen zu können.
Ist es möglich, eine Zelle auszuführen, wenn nur einige der Knoten migriert werden und andere nicht?
Ja, das ist möglich. WebSphere Application Server Version 7.0 oder höher kann mit Version 9.0 in derselben Zelle und in derselben logischen Partition (LPAR) koexistieren.
Kann ein gerade migrierter Deployment Manager von WebSphere Application Server for z/OS Version 9.0 weiterhin mit den Knoten mit Version 7.0 oder höher kommunizieren?
Gibt es eine Reihenfolge, die bei der Durchführung einer Migration mit mehreren Knoten zu beachten ist?
Können Zellen mit WebSphere Application Server for z/OS Version 9.0 mit anderen Zellen mit Version 7.0 oder höher koexistieren?