Ü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

Die folgenden Begriffe werden bei der Beschreibung der Migration häufig verwendet:
  • 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 ist der Prozess des Verschiebens einer Konfiguration von einem älteren Release in ein neues Release, sodass die neue Konfiguration ein möglichst ähnliches Verhalten wie die alte Konfiguration aufweist. Die Haupteinheit für die Migration ist das Profil, das in drei grundlegenden Schritten migriert wird:
  1. Snapshot des Quellenprofils der alten Installation erstellen
  2. Kompatibles Zielprofil in der neuen Installation erstellen
  3. Daten des Snapshots im Zielprofil zusammenführen

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.

Eine heterogene Zellenumgebung kann auf zwei Arten entstehen:
  1. Sie führen eine schrittweise Migration Ihres vorhandenen Systems durch.
    1. 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.
    2. 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.
  2. 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.
    1. Zunächst migrieren Sie den Deployment Manager auf Version 9.0. Der Deployment Manager muss den höchsten Knotenversionsstand haben.
    2. Anschließend können Sie Knoten mit Version 7.0 oder höher in die neue höchste Deployment-Manager-Version einbinden.
    Fehler vermeiden 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.

Fehler vermeiden Fehler vermeiden: Bei Ausführung in einer heterogenen Zellenumgebung können Clients plötzlich in eine Situation geraten, in der die Portinformationen der Cluster-Member des Zielclusters nicht mehr aktuell sind. Diese Situation tritt im Allgemeinen dann ein, wenn alle Cluster-Member dynamische Ports verwenden und während eines Zeitraums, in dem keine Anforderungen gesendet werden, erneut gestartet werden. Der Clientprozess versucht in diesem Fall, vom Node Agent neue Portdaten für die Cluster-Member zu erhalten, und leitet diese neuen Portdaten anschließend an die Member des Clusters weiter.

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.

gotcha

Wenn 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.

Beachten Sie die folgenden Punkte bei der Migration auf Version 9.0:
  • Alle Variablen, die zu anderen Anwendungen oder Produkten als WebSphere Application Server gehören, werden nicht migriert, sondern unverändert in die neue Umgebung übertragen. Prüfen Sie daher vor der Migration andere Produktupgrades, um sicherzustellen, dass alle diese Variablen nach der Migration weiterhin richtig sind.
  • Vergewissern Sie sich vor der Migration von Version 7.0 oder höher auf Version 9.0, dass keine Bereichseinschränkungen (z. B. IEFUSI-Begrenzungen) vorliegen. Diese Einschränkungen können unvorhersehbare JVM-Fehler (Java™ Virtual Machine) verursachen.
Wie verläuft der grundlegende Migrationsprozess?
  1. Installieren Sie den SMP/E-Code für WebSphere Application Server for z/OS Version 9.0.
    • Der SMP/E-Code enthält Installation Manager. Durch Installation des SMP/E-Codes erhalten Sie die Berechtigung, das WebSphere-Repository abzurufen und den WebSphere-Produktcode auf Ihrem System zu erstellen.
  2. Verwenden Sie z/OS Migration Management Tool oder den Befehl zmmt um die Migrationsdienstprogramme zu erstellen, die Sie für die Migration benötigen.
  3. Führen Sie diese Jobs aus.

    Eine neue Konfiguration von Version 9.0 wird erstellt, unabhängig von Ihrer vorhandenen Konfiguration von Version 7.0 oder höher, die auf den Konfigurationsdaten von Version 7.0 oder höher basiert.

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.

Abbildung, die zeigt, wie die bereitgestellten Dienstprogramme für die einzelnen Knoten in der Konfiguration ausgeführt werden.

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:

Tabelle 1. Migrationsdienstprogramme und die entsprechenden Einsatzmöglichkeiten. In der Tabelle sind die verschiedenen Migrationsdienstprogramme mit ihrem Zweck aufgeführt.
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:
  • BBOWMG3B
  • BBOWBPRO
  • BBOWBPRE
  • BBOWBPOS
Folgende Dienstprogramme für die Migration eines Deployment Manager:
  • BBOWMG3D
  • BBOWDPRO
  • BBOWDPRE
  • BBOWDPOS
Folgende Dienstprogramme für die Migration eingebundener Knoten:
  • BBOWMG3F
  • BBOWMPRO
  • BBOWMPRE
  • BBOWMPOS

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?

Ja. Ein Deployment Manager, der auf Version 9.0 der Codeversion migriert wurde, kann einen Knoten mit Version 7.0 oder höher verwalten. In der Administrationskonsole vorgenommene Änderungen werden auf den Knoten angewendet. Beachten Sie die folgenden Punkte:
  • Wenn ein Deployment Manager auf Version 9.0 migriert wird, wird eine neue Primärkonfiguration von Version 9.0 erstellt. Die Primärkonfiguration von Version 7.0 oder höher ist weiterhin vorhanden. Wenn der Deployment Manager von Version 9.0 jedoch Änderungen an der Konfiguration vornimmt, gelten diese für die neue Primärkonfiguration von Version 9.0. Obwohl es weiterhin möglich ist, den Code von Version 7.0 oder höher zu verwenden, sind alle Änderungen, die in Version 9.0 vorgenommen werden, nicht mehr sichtbar, wenn der ältere Code wiederhergestellt wird.
  • Ein Deployment Manager von Version 7.0 oder höher besitzt nicht die erforderliche Funktionalität, um einen Knoten mit Version 9.0 zu verwalten.

Gibt es eine Reihenfolge, die bei der Durchführung einer Migration mit mehreren Knoten zu beachten ist?

Ja. Halten Sie bei der Migration die folgende Reihenfolge ein:
  1. Migrieren Sie den Deployment Manager immer zuerst.
  2. Anwendungsserverknoten in demselben System wie der Deployment Manager oder in anderen MVS-Images (Multiple Virtual Storage) können anschließend migriert werden.

Können Zellen mit WebSphere Application Server for z/OS Version 9.0 mit anderen Zellen mit Version 7.0 oder höher koexistieren?

Ja. Zellen mit WebSphere Application Server for z/OS Version 9.0 können mit anderen Zellen mit Version 7.0 oder höher in einem Sysplex oder einem MVS-Image koexistieren. Die folgenden Einschränkungen sind zu beachten:
  • Eine Zelle kann Server von Version 7.0 oder höher enthalten.
  • Eine Zelle kann z/OS-Knoten und Knoten mit anderen Plattformen enthalten. Der Deployment Manager muss aber auf dem Stand der höchsten Version in der Zelle sein und alle Knoten auf Plattformen, die sich von der Plattform unterscheiden, auf der sich der Deployment Manager befindet, müssen auf dem Stand von Version 7.0 oder höher sein.
  • Ein Server auf einem z/OS-Knoten kann nicht mit einem Server auf einem Knoten mit einer anderen Plattform in einem Cluster enthalten sein.
  • Eine LPAR kann mehrere Knoten aus derselben Zelle enthalten.
  • Jede LPAR verfügt über maximal einen Dämon pro Zelle mit Servern in dieser LPAR, unabhängig davon, wie viele Knoten von dieser Zelle für die betreffende LPAR konfiguriert sind.
  • Ein Dämon muss für eine bestimmte LPAR denselben oder einen höheren Versionsstand haben wie die Server in dieser LPAR, die in der Zelle des Dämons enthalten sind, unabhängig vom Knoten.
  • Alle Server in demselben Knoten müssen denselben Versionsstand haben.
  • Der Deployment Manager muss denselben oder einen höheren Versionsstand haben wie die Server in der Zelle.
  • Der Controller und seine Servants müssen denselben Versionsstand haben.
  • Es ist nicht zulässig, dass mehrere Zellen denselben Kurznamen haben.
  • Es gibt andere Punkte, die für eigenständige Zellen zu berücksichtigen sind, unabhängig davon, ob sie verschiedene Codeversionen haben. Beispielsweise müssen Sie einen eigenständigen Mountpunkt für das Konfigurationsdateisystem sowie eigenständige JCL-Prozeduren verwenden.

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-zos&topic=cmig_overview
Dateiname:cmig_overview.html