Zellen mit dem Befehlszeilentool auf neue Hostmaschinen migrieren
Vorbereitende Schritte

Dieser Artikel beschreibt die Migration von Profilkonfigurationen. Wenn Sie Ihre Anwendungen auf die aktuellste Version migrieren möchten, verwenden Sie WebSphere Application Server Migration Toolkit. Weitere Informationen finden Sie unter Migration Toolkit on WASdev.
sptcfgSehen Sie sich die Informationen zur Migrationsplanung an. Weitere Informationen finden Sie auf der Webseite Knowledge Collection: Migration planning for WebSphere Application Server.
Diese Angaben enthalten Informationen darüber, wie Zellen auf eine andere Maschine migriert werden. Informationen zur Migration von Zellen auf derselben Maschine finden Sie unter Zellen über die Befehlszeilentools migrieren.
Informationen zu diesem Vorgang
Nachfolgend wird beschrieben, wie jedes Profil in einer Zellenkonfiguration von einer früheren Version von WebSphere Application Server auf eine andere Hostmaschine mit WebSphere Application Server Version 9.0 migriert wird. Die Zellenkonfiguration setzt sich aus einem Deployment Manager mit einem oder mehreren Knoten, einem Web-Server und einem Anwendungsclient zusammen. Alle Ports werden in die neue Konfiguration migriert. Quellen- und Zielhost müssen nicht dasselbe Betriebssystem verwenden.
Wenn WebSphere Application Server Version 9.0 auf dem Quellenhost nicht installiert ist, müssen Sie auf dem Zielhost eine für das Betriebssystem auf der Quellenmaschine geeignete JAR-Datei (.jar) für die ferne Migration erstellen. Die JAR-Datei für die ferne Migration stellt das Tool "WASPreUpgrade" von Version 9.0 bereit, mit dem Sie das Migrationssicherungsverzeichnis für das Profil erstellen.
- OPTION 1: Installieren Sie die Zielproduktversion auf der Quellenmaschine.
- OPTION 2: Erstellen Sie die JAR-Migrationsdatei (bei der es sich eigentlich um den Befehl "WASPreUpgrade" und Dateien, die für die Unterstützung der Ausführung erforderlich sind, einschließlich Java, aus der Zielinstallation handelt).
Haben mehrere Quellenmaschinen dieselben Betriebssystemarchitekturen, aber andere Betriebssystemarchitekturen als die Zielmaschine, muss das Zielrelease nur auf einer einzigen Quellenmaschine installiert werden. Auf dieser Quellenmaschine kann die ferne JAR-Migrationsdatei erstellt und auf den anderen Quellenmaschinen verwendet werden.
In dieser Prozedur wird davon ausgegangen, dass die vorherige Konfiguration aktiv ist und alle Profile auf einen anderen Host migriert werden sollen.


Vorgehensweise
- Sichern Sie den Deployment Manager und alle alten Knoten. Sollte während der Migration ein Fehler auftreten,
speichern Sie die Konfiguration des Deployment Manager und der Knoten in einer Datei,
die Sie später für Wiederherstellungszwecke verwenden können.
- Wechseln Sie in das Verzeichnis Deployment-Manager-Profilstammverzeichnis/bin.
- Führen Sie den Befehl backupConfig mit den entsprechenden Parametern aus, und speichern Sie die aktuelle Profilkonfiguration in einer Datei. Beispiel:
Stammverzeichnis_des_Anwendungsservers_der_Vorgängerversion\v70dmgr01\bin\ backupConfig.bat \Sicherung_alter_Host\v70dmgr01backupBeforeV90migration.zip -username Benutzername -password Kennwort -nostop
Hierbei ist Sicherung_alter_Host die Position, an der die Konfigurationswiederherstellungspunkte gespeichert sind.Anwenungsserverstammverzeichnis_der_Vorgängerversion/v70dmgr01/bin/backupConfig.sh /Sicherung_alter_Host/v70dmgr01backupBeforeV90migration.zip -username Benutzername -password Kennwort -nostop
- Wechseln Sie für jeden Knoten in der Konfiguration in das Verzeichnis Stammverzeichnis_des_Knotenprofils/bin.
- Führen Sie den Befehl backupConfig mit den entsprechenden Parametern aus und speichern Sie die aktuelle Profilkonfiguration in einer Datei. Beispiel:
Stammverzeichnis_des_Anwendungsservers_der_Vorgängerversion\v70node01\bin\backupConfig.bat \Sicherung_alter_Host\v70node01backupBeforeV90migration.zip -username Benutzername -password Kennwort -nostop
Stammverzeichnis_des_Anwendungsservers_der_Vorgängerversion/v70node01 /bin/backupConfig.sh /Sicherung_alter_Host/v70node01rbackupBeforeV90migration.zip -username Benutzername -password Kennwort -nostop
- Installieren Sie
WebSphere Application Server Network Deployment
Version 9.0 auf jedem Zielhost in einem neuen Verzeichnis.
Weitere Informationen finden Sie in der Installationsdokumentation.
- Erstellen Sie die ferne JAR-Migrationsdatei. Diese
JAR-Datei (.jar) enthält die Dateien, die erforderlich sind, um den Befehl
WASPreUpgrade auf einem System auszuführen, auf dem WebSphere Application Server
Version 9.0 nicht installiert ist.
Fehler vermeiden: Sie müssen die JAR-Datei für die ferne Migration auf demselben Betriebssystem erstellen, auf dem die Quelle installiert ist. Weil das generierte Archiv betriebssystemspezifischen Code enthält, kann es nur in dieser Architektur ausgeführt werden. gotcha
- Ermitteln Sie das Betriebssystem und die Architektur des Quellenprofils. Wenn das Betriebssystem und die Architektur des Quellenprofils vom Betriebssystem oder von der Architektur des Zielprofils abweichen, müssen Sie WebSphere Application Server Version 9.0 auf einem System installieren, das mit dem Quellenprofil übereinstimmt, bevor Sie die JAR-Datei für die ferne Migration erstellen. Nachdem die JAR-Datei für die ferne Migration erstellt wurde, kann diese auf jedem System ausgeführt werden, das mit dem Betriebssystem und der Architektur übereinstimmt.
- Erstellen Sie die JAR-Datei (.jar) für die ferne Migration.
- Geben Sie an der Eingabeaufforderung Folgendes ein: cd $WAS_HOME/bin/migration/bin
- Führen Sie zum Erstellen der JAR-Datei den folgenden Befehl aus: createRemoteMigrJar.bat(sh) -targetDir <Verzeichnis der JAR-Datei für die ferne Migration> . Dadurch wird die folgende Datei erstellt: WAS_V90_Betriebssystem.Arch_RemoteMigrSupport.jar, z. B. WAS_V90_windows.amd64_RemoteMigrSupport.jar.
- Bereiten Sie das ferne System für den Befehl "WasPreUpgrade" vor.
- Senden Sie die JAR-Datei an das System, auf dem sich das Quellenprofil befindet.
- Extrahieren Sie die Datei in ein temporäres Verzeichnis.
- Wechseln Sie in das Verzeichnis bin an der temporären Position.
Jetzt sind die Vorbereitungen abgeschlossen, um den Befehl WASPreUpgrade für das Quellenprofil auszuführen. Führen Sie diesen Befehl jedoch erst dann aus, wenn Sie in einem späteren Schritt dazu aufgefordert werden.
- Erstellen Sie das Deployment-Manager-Zielprofil. Das Deployment-Manager-Zielprofil ist ein neues Deployment-Manager-Profil, das als Ziel für die Migration verwendet wird.
Fehler vermeiden: Die Zellen- und Knotennamen von Version 9.0 müssen mit den Zellen- und Knotennamen in der vorherigen Konfiguration übereinstimmen. Wenn Sie Zellen und Knoten mit neuen Zellen- und Knotennamen erstellen, schlägt die Migration fehl. gotcha
Führen Sie den Befehl manageprofiles mit den entsprechenden Parametern aus, um ein Deployment-Manager-Profil zu erstellen.
Beispiel:Installationsstammverzeichnis_von_Version_9\bin\manageprofiles.bat -create -profileName v70toV90dmgr01 -templatePath \opt\WebSphereV90\profileTemplates\ management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName -hostName mydmgrhost.company.com
Installationsstammverzeichnis_von_Version_9/bin/manageprofiles.sh -create -profileName v70toV90dmgr01 -templatePath /opt/WebSphereV90/profileTemplates/ management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName -hostName mydmgrhost.company.com
- Speichern Sie die aktuelle Deployment-Manager-Konfiguration im Migrationssicherungsverzeichnis. Damit die aktuelle Deployment-Manager-Konfiguration im Migrationssicherungsverzeichnis
gespeichert wird, führen Sie den Befehl WASPreUpgrade aus. Der Befehl WASPreUpgrade ändert nicht die alte Konfiguration.
- Führen Sie den Befehl
WASPreUpgrade mit dem Parameter
-machineChange true aus, um die aktuelle Deployment-Manager-Konfiguration in einem Migrationssicherungsverzeichnis
zu speichern. Beispiel:
<Pfad zur JAR-Datei für die ferne Migration>\migration\bin\WASPreUpgrade.bat \Sicherung_alter_Host\v70toV90dmgr01 \opt\WebSphereV70 -oldProfile 70dmgr01 -machineChange true
Hierbei ist Sicherung_alter_Host das Verzeichnis, in das die Profilkonfigurationsdateien zwecks Vorbereitung für die Migration auf den neuen Host kopiert wurden.<Pfad zur JAR-Datei für die ferne Migration>/migration/bin/WASPreUpgrade.sh /Sicherung_alter_Host/v70toV90dmgr01 /opt/WebSphereV70 -oldProfile 70dmgr01 -machineChange true
Wenn Sie eine Migration von Version 8.0 auf Version 9.0 durchführen und als Profil einen Deployment Manager verwenden, wird das Profil von Version 8.0 während der Ausführung des Befehls WASPreUpgrade gestoppt. Der Deployment Manager wird nur dann vor Ausführung von WASPreUpgrade gestartet, wenn Sie in der Befehlszeile -keepDmgrEnabled true festlegen oder wenn Sie die entsprechende Option im Migrationsassistenten angeben.
Fehler vermeiden: Wenn Sie "-machineChange true" angeben, müssen Sie den Job-Manager-URL für alle Ressourcen (z. B. für andere Deployment Manager oder Anwendungsserver) aktualisieren, die nach der Migration von der Job-Manager-Funktion des Deployment Manager von Version 8.0 gesteuert werden.gotcha
- Prüfen Sie die Warnungen und Fehler in der Konsolenausgabe und in den
WASPreUpgrade-Protokollen. Nach Ausführung des
Befehls WASPreUpgrade suchen Sie in der Konsolenausgabe nach Nachrichten
des Typs Failed with errors oder Completed with warnings.
Prüfen Sie anschließend die folgenden Protokolldateien auf Warnungen oder Fehler:
- Sicherung_alter_Host/v70toV90dmgr01/logs/WASPreMigrationSummary.log
- Sicherung_alter_Host/v70toV90dmgr01/logs/WASPreUpgrade.Zeitmarke.log
- Sicherung_alter_Host/v70toV90dmgr01/logs/WASPreUpgrade.trace
Falls Fehler vorhanden sind, beheben Sie diese und führen Sie den Befehl WASPreUpgrade erneut aus. Prüfen Sie, ob sich die Warnungen auf Migrations- oder Laufzeitaktivitäten in Version 9.0 auswirken.
Wurde der Befehl erfolgreich ausgeführt, ist es nicht erforderlich, in den Protokollen nach Fehlern oder Warnungen zu suchen.
- Führen Sie den Befehl
WASPreUpgrade mit dem Parameter
-machineChange true aus, um die aktuelle Deployment-Manager-Konfiguration in einem Migrationssicherungsverzeichnis
zu speichern. Beispiel:
- Archivieren Sie das mit dem Befehl WASPreUpgrade erstellte Sicherungsverzeichnis.
Fehler vermeiden: Verwenden Sie nicht das Windows-Archivierungstool, da es sich nicht für eine Migration von WebSphere Application Server eignet. gotcha
- Verwenden Sie ein Archivierungstool Ihrer Wahl, um eine komprimierte Datei des Sicherungsverzeichnisses zu erstellen. Beispiel:
cd /Sicherung_alter_Host /opt/WebSphereV70/java/bin/jar -cf v70toV90dmgr01.jar v70toV90dmgr01/
- Verschieben Sie die archivierte Datei auf die Zielmaschine.
- Erstellen Sie ein Verzeichnis auf der Zielmaschine und extrahieren Sie die archivierte Datei in das neue Verzeichnis. Beispiel:
Hierbei ist Sicherung_neuer_Host das Verzeichnis, in das Sie Ihre Dateien migrieren.mkdir /Sicherung_neuer_Host cd /Sicherung_neuer_Host /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
- Verwenden Sie ein Archivierungstool Ihrer Wahl, um eine komprimierte Datei des Sicherungsverzeichnisses zu erstellen. Beispiel:
- Stellen Sie die ursprüngliche Deployment-Manager-Konfiguration wieder her.
Führen Sie den Befehl WASPostUpgrade im Verzeichnis bin des neuen Deployment-Manager-Profils aus, um die vorherige Deployment-Manager-Konfiguration, die im Migrationssicherungsverzeichnis gespeichert wurde, wiederherzustellen. Wenn Sie die im Beispiel gezeigten Optionen verwenden, werden alle Ports migriert und alle Anwendungen installiert.
- Führen Sie den Befehl
WASPostUpgrade aus, um die gesicherte Deployment-Manager-Konfiguration
im neuen Deployment-Manager-Profil von Version 9.0 wiederherzustellen. Beispiel:
Installationsstammverzeichnis_von_Version_9\bin\WASPostUpgrade.bat \ Sicherung_neuer_Host\v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile 70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE -keepDmgrEnabled TRUE -username myuser -password mypass
In diesem Beispiel ist Sicherung_neuer_Host das Verzeichnis, aus dem die Konfigurationsdateien des Quellenprofils migriert werden.Installationsstammverzeichnis_von_Version_9/bin/WASPostUpgrade.sh / Sicherung_neuer_Host/v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile 70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE -keepDmgrEnabled TRUE -username myuser -password mypass
Wenn Sie das alte Profil nach der Migration weiterhin verwenden möchten, geben Sie den Parameter -clone TRUE an. Wenn Sie für den Deployment Manager eine Klonmigration angeben, müssen Sie alle zugehörigen eingebundenen Knoten ebenfalls klonen.
- Prüfen Sie die Warnungen und Fehler in der Konsolenausgabe und in den
WASPostUpgrade-Protokollen. Nach Ausführung des
Befehls WASPostUpgrade suchen Sie in der Konsolenausgabe nach Nachrichten
des Typs Failed with errors oder Completed with warnings.
Prüfen Sie anschließend die folgenden Protokolldateien auf Warnungen oder Fehler:
- Sicherung_neuer_Host/v70toV90dmgr01/logs/WASPostMigrationSummary.log
- Sicherung_neuer_Host/v70toV90dmgr01/logs/WASPostUpgrade.Name_des_Zielprofils.Zeitmarke.log
- Sicherung_neuer_Host/v70toV90dmgr01/logs/WASPostUpgrade.Name_des_Zielprofils.trace
Falls Fehler vorhanden sind, beheben Sie diese und führen Sie den Befehl WASPostUpgrade erneut aus. Prüfen Sie, ob sich die Warnungen auf Migrations- oder Laufzeitaktivitäten in Version 9.0 auswirken.
Wenn die Konfiguration ordnungsgemäß migriert wurde, aber keine Anwendungen installiert wurden, können Sie den Befehl WASMigrationAppInstaller ausführen, damit nur die Anwendungen installiert werden, die nicht migriert wurden. Weitere Informationen hierzu finden Sie im Artikel Befehl "WASMigrationAppInstaller".
Wurde der Befehl erfolgreich ausgeführt, ist es nicht erforderlich, in den Protokollen nach Fehlern oder Warnungen zu suchen.
Fehler vermeiden: Nachdem der Befehl WASPostUpgrade erfolgreich abgeschlossen wurde, starten Sie nicht den neuen Deployment Manager. Sie müssen zuerst einige weitere Schritte durchführen, bevor Sie den neuen Deployment Manager starten können. gotcha
- Führen Sie den Befehl
WASPostUpgrade aus, um die gesicherte Deployment-Manager-Konfiguration
im neuen Deployment-Manager-Profil von Version 9.0 wiederherzustellen. Beispiel:
- Speichern Sie die migrierte Deployment-Manager-Konfiguration von Version 9.0
in einer Datei. Führen Sie hierzu den Befehl backupConfig für den Deployment Manager von Version 9.0 aus.
Fehler vermeiden: Wenn Sie ein Knotenmigrationsproblem feststellen, können Sie die Zellenkonfiguration bis zu dem Punkt, bevor das Problem eintrat, wiederherstellen. Sie können Fehlerbehebungsmaßnahmen anwenden und die Knotenmigration erneut versuchen. gotcha
- Wechseln Sie in das Verzeichnis Deployment-Manager-Profilstammverzeichnis/bin.
- Führen Sie den Befehl backupConfig mit den geeigneten Parametern aus und speichern Sie die Profilkonfiguration von Version 9.0 in einer Datei. Beispiel:
Profilstammverzeichnis_von_Version_9\profiles\v70toV90dmgr01\ bin\backupConfig.bat \Sicherung_neuer_Host\v70toV90dmgr01backupMigratedDmgrOnly.zip -username Benutzername -password Kennwort
Hierbei ist Sicherung_neuer_Host die Position, an der die Konfigurationswiederherstellungspunkte gespeichert sind.Profilstammverzeichnis_von_Version_9/profiles/v70toV90dmgr01/bin/backupConfig.sh / Sicherung_neuer_Host/v70toV90dmgr01backupMigratedDmgrOnly.zip -username Benutzername -password Kennwort
- Stoppen und inaktivieren Sie den Deployment Manager auf dem alten Host.
- Stoppen Sie den Deployment Manager auf dem alten Host.
- Inaktivieren Sie den Deployment Manager auf dem alten Host. Um den Deployment Manager zu inaktivieren, müssen Sie die zugehörige Datei serverindex.xml wie nachfolgend beschrieben umbenennen:
- Alter Name
- $PROFILE_ROOT/config/cells/Zellenname/nodes/Deployment-Manager-Knotenname/serverindex.xml
- Neuer Name
- $PROFILE_ROOT/config/cells/Zellenname/nodes/Deployment-Manager-Knotenname/serverindex.xml_disabled
- Starten Sie den Deployment Manager von Version 9.0 auf dem neuen Host.
- Wechseln Sie in das neue Verzeichnis Version 9.0 Deployment-Manager-Profilstammverzeichnis/bin.
- Führen Sie den Befehl startManager aus.
- Suchen Sie in der Datei SystemOut.log nach Warnungen und Fehlern, während der Deployment Manager aktiv ist. Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.Überprüfen Sie die Warnungen, um festzustellen, ob sich diese auf Migrations- oder Laufzeitaktivitäten auswirken, wenn der Deployment Manager von Version 9.0 gestartet wird.
- Stellen Sie sicher, dass der Deployment Manager von Version 9.0 erfolgreich gestartet wird.
- Synchronisieren Sie die alten Knoten manuell mit dem neuen Deployment Manager von Version 9.0.
Stellen Sie sicher, dass der Deployment Manager von Version 9.0 auf dem neuen Host aktiv ist. Sie müssen Sie an der Maschine anmelden, auf der sich die alten Knoten befinden und den Befehl syncNode ausführen.
- Stoppen Sie den Node Agent.
- Rufen Sie die Host- und Portnummer des Deployment Manager ab, und aktualisieren Sie die Datei Profilstammverzeichnis_des_Node_Agent/properties/wsadmin.properties. Ändern Sie den Wert für com.ibm.ws.scripting.host in den des neuen Hosts. Ändern Sie den Wert für com.ibm.ws.scripting.port in den des neuen Ports.
- Führen Sie im Verzeichnis "bin" den Befehl syncNode aus. Beispiel:
Installationsstammverzeichnis_des_Node_Agent\bin\syncNode.bat myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
Installationsstammverzeichnis_des_Node_Agent/bin/syncNode.sh myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
- Starten Sie den Node Agent, wenn die Synchronisation erfolgreich war.
- Migrieren Sie Plug-ins für Web-Server.
- Stellen Sie sicher, dass der Deployment Manager von Version 9.0 aktiv ist.
- Führen Sie ein Upgrade der Version des Web-Server-Plug-ins durch, das in der Zelle verwendet wird.
- Sehen Sie sich die unterstützenden Informationen zu Typ und Version Ihres Web-Servers an.
- Migrieren Sie Anwendungsclientinstallationen.
Wenn der WebSphere-Application-Quellenclient ein Client der Version 7.0 ist, müssen Sie auch die Befehle WASPreUpgrade und WASPostUpgrade ausführen, um die vorhandenen Sicherheitseinstellungen zu migrieren.
- Geben Sie alle zu migrierenden Client-Hosts an.
- Installieren Sie den Anwendungsclient von WebSphere Version 9.0.
- Führen Sie den Befehl
Version 9.0
WASPreUpgrade aus, um die Sicherheitseinstellungen des
Anwendungsclients in einem Migrationssicherungsverzeichnis zu speichern. Beispiel:
/opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup_client/v70clientToV90 /opt/AppClientV70
- Führen Sie den Befehl WASPostUpgrade von Version 9.0 aus, um
die Sicherheitseinstellungen des Anwendungsclients
im neuen Client von Version 9.0 wiederherzustellen. Beispiel:
/opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup_client/v70clientToV90
- Migrieren Sie Knoten. Wichtig: Diese Schritte gelten nur für Migrationen zwischen verschiedenen Maschinen. Wenn Sie auf einem Knoten keine maschinenübergreifende Migration ausführen, lesen Sie die Informationen zur Migration von Knoten unter Zellen mit den Befehlszeilentools migrieren. Stellen Sie sicher, dass der Deployment Manager von Version 9.0 aktiv ist. Führen Sie für jeden Knoten, den Sie auf Version 9.0 migrieren möchten, die folgenden Schritte aus.
Fehler vermeiden: Damit die Migration erfolgreich verläuft, müssen Sie denselben Knotennamen, aber einen anderen temporären Zellennamen für alle Knoten verwenden, die Sie auf Version 9.0 oder höher migrieren. gotcha
- Installieren Sie WebSphere Application Server Version 9.0 auf jedem Zielhost. Weitere Informationen finden Sie in der Dokumentation zur Installation einer Anwendungsserverumgebung.
- Erstellen Sie das Zielknotenprofil. Führen Sie den Befehl manageprofiles mit den entsprechenden Parametern aus, um ein neues verwaltetes Profil zu erstellen. Beispiel:
Installationsstammverzeichnis_von_Version_9\bin\manageprofiles.bat -create -profileName node1 -templatePath \opt\ WebSphereV90\profileTemplates\managed -nodeName currentNode1Name -cellName currentCellName -hostName mynode1host.company.com
Installationsstammverzeichnis_von_Version_9/bin/manageprofiles.sh -create -profileName node1 -templatePath /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name -cellName currentCellName -hostName mynode1host.company.com
- Verwenden Sie die JAR-Datei für die ferne Migration, die Sie für die Deployment-Manager-Migration erstellt haben,
um den Befehl WASPreUpgrade auf der aktuellen Maschine im Knoten verfügbar zu machen. Anmerkung: Dieser Schritt muss nur dann ausgeführt werden, wenn sich der Quellenknoten und der Deployment Manager nicht auf derselben Maschine befinden. Er kann nur ausgeführt werden, wenn beide Maschinen dieselbe Architektur haben.Weitere Informationen hierzu finden Sie in Schritt 3 dieses Szenarios, JAR-Datei für die ferne Migration erstellen.
- Führen Sie den Befehl
WASPreUpgrade mit dem Parameter
-machineChange true aus, um die Konfiguration des aktuellen Knotens
in einem Migrationssicherungsverzeichnis
zu speichern.
Wählen Sie ein neues Verzeichnis für die Sicherungsdateien aus. Beispiel:
<Pfad zur JAR-Datei für die ferne Migration>\migration\bin\WASPreUpgrade.bat \Sicherung_alter_Host\v70toV90node1 \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
<Pfad zur JAR-Datei für die ferne Migration>/migration/bin/WASPreUpgrade.sh /Sicherung_alter_Host/v70toV90node1 /opt/WebSphereV70 -oldProfile 70node1 -machineChange true
- Suchen Sie in der Konsolenausgabe von WASPreUpgrade nach Fehlernachrichten und Warnungen. Es werden möglicherweise Nachrichten ähnlich den folgenden angezeigt: "Fehlgeschlagen mit Fehlern" oder "Abgeschlossen mit Warnungen". Suchen Sie außerdem in den folgenden Protokolldateien nach Fehlernachrichten und Warnungen:
- Sicherung_alter_Host/v70toV90node1/logs/WASPreMigrationSummary.log
- Sicherung_alter_Host/v70toV90node1/logs/WASPreUpgrade.Zeitmarke.log
- Sicherung_alter_Host/v70toV90node1/logs/WASPreUpgrade.trace
Wenn der Befehl WASPreUpgrade ordnungsgemäß ausgeführt wurde, müssen Sie nicht in den Protokolldateien nach Fehlernachrichten und Warnungen suchen.
- Verwenden Sie ein Archivierungstool Ihrer Wahl, um eine komprimierte Datei des Sicherungsverzeichnisses zu erstellen, das mit dem Befehl "WASPreUpgrade" erstellt wurde. Beispiel:
cd /Sicherung_alter_Host /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/
- Verschieben Sie die archivierte Datei auf die Zielmaschine.
- Erstellen Sie ein Verzeichnis auf der Zielmaschine und extrahieren Sie die archivierte Datei in das neue Verzeichnis. Beispiel:
In diesem Beispiel ist Sicherung_neuer_Host das Verzeichnis, aus dem die Profilkonfigurationsdateien migriert werden.mkdir /Sicherung_neuer_Host cd /Sicherung_neuer_Host /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
- Stoppen Sie die Anwendungsserver auf dem alten Knoten und stoppen Sie anschließend den Node Agent auf dem alten Knoten.
- Stoppen und inaktivieren Sie den Knoten auf dem alten Host. Stellen Sie sicher, dass der Knoten auf dem alten Host nicht verwendet wird. Um den Knoten zu inaktivieren,
müssen Sie die zugehörige Datei serverindex.xml wie nachfolgend beschrieben umbenennen:
- Alter Name
- $PROFILE_ROOT/config/cells/Zellenname/nodes/Knotenname/serverindex.xml
- Neuer Name
- $PROFILE_ROOT/config/cells/Zellenname/nodes/Knotenname/serverindex.xml_disabled
- Führen Sie den Befehl WASPostUpgrade aus, um die gesicherte Knotenkonfiguration
im neuen verwalteten Profil von Version 9.0
wiederherzustellen. Beispiel:
Installationsstammverzeichnis_von_Version_9\bin\WASPostUpgrade.bat \ Sicherung_neuer_Host\v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -usernameBenutzername-passwordKennwort
Installationsstammverzeichnis_von_Version_9/bin/WASPostUpgrade.sh / Sicherung_neuer_Host/v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -usernameBenutzername-passwordKennwort
Wenn Sie den Deployment Manager geklont haben, müssen Sie alle eingebundenen Knoten ebenfalls klonen. Geben Sie den Parameter -clone TRUE und den neuen Hostnamen und SOAP- bzw. RMI-Port des Deployment Manager an. Klonen Sie eingebundene Knoten nur, wenn der Deployment Manager geklont wurde.
Installationsstammverzeichnis_von_Version_9\bin\WASPostUpgrade.bat \ Sicherung_neuer_Host\v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -username myuser -password mypass -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
Installationsstammverzeichnis_von_Version_9/bin/WASPostUpgrade.sh / Sicherung_neuer_Host/v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -username myuser -password mypass -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
- Suchen Sie in der Konsolenausgabe von WASPostUpgrade nach den nachfolgend genannten Nachrichten. Es werden möglicherweise Nachrichten ähnlich den folgenden angezeigt: "Fehlgeschlagen mit Fehlern" oder "Abgeschlossen mit Warnungen". Suchen Sie außerdem in den folgenden Protokolldateien nach Fehlernachrichten und Warnungen:
- Sicherung_neuer_Host/v70toV90node1/logs/WASPostMigrationSummary.log
- Sicherung_neuer_Host/v70toV90node1/logs/WASPostUpgrade.Name_des_Zielprofils.Zeitmarke.log
- Sicherung_neuer_Host/v70toV90node1/logs/WASPostUpgrade.Name_des_Zielprofils.trace
Anmerkung: Wenn die Ausführung des Befehls WASPostUpgrade fehlschlägt, müssen Sie den Deployment Manager von Version 9.0 aus der Sicherungskonfigurationsdatei wiederherstellen. Wenn bei der Verarbeitung des Befehls WASPostUpgrade der Befehl syncNode ausgeführt wurde, weiß der Deployment Manager, dass der Knoten migriert wurde. Der Knoten kann erst dann erneut migriert werden, wenn der Deployment Manager im Zustand vor der Migration des Knotens wiederhergestellt wurde.Wenn die Konfiguration ordnungsgemäß migriert wurde, aber keine Anwendungen installiert wurden, können Sie den Befehl WASMigrationAppInstaller ausführen, damit nur die Anwendungen installiert werden, die nicht migriert wurden. Weitere Informationen hierzu finden Sie im Artikel Befehl "WASMigrationAppInstaller".
- Suchen Sie in der Datei SystemOut.log im Deployment Manager von Version 9.0 nach Fehlernachrichten und Warnungen. Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
- Starten Sie den migrierten Node Agent mit Version 9.0.
- Suchen Sie in der Datei SystemOut.log des Deployment Manager und des Knotens mit Version 9.0 nach Fehlernachrichten und Warnungen.
- Optional: Synchronisieren Sie die Zelle, wenn der automatische Synchronisationsprozess nicht aktiviert ist.
- Starten Sie die entsprechenden Anwendungsserver auf dem migrierten Knoten mit Version 9.0.
- Führen Sie den Befehl backupConfig aus und speichern Sie die Profilkonfiguration von Version 9.0 in einer Datei. Beispiel:
Profilstammverzeichnis_von_Version_9\v70toV90node1\bin\backupConfig.bat \Sicherung_neuer_Host\v70toV90node1.zip -username myuser -password mypass -nostop
Verwenden Sie jedes Mal, wenn Sie den Befehl backupConfig auf einem bestimmten Knoten ausführen, eine neuen Namen für die Sicherungsdatei.Profilstammverzeichnis_von_Version_9/v70toV90node1/bin/backupConfig.sh /Sicherung_neuer_Host/v70toV90node1.zip -username myuser -password mypass -nostop
- Speichern Sie die Deployment-Manager-Konfiguration mit dem Befehl backupConfig. Wechseln Sie auf dem Deployment-Manager-Host von Version 9.0
in das Verzeichnis Deployment-Manager-Profilstammverzeichnis/bin.
Führen Sie den Befehl backupConfig aus und speichern Sie die Profilkonfiguration von Version 9.0 in einer Datei. Beispiel:
Profilstammverzeichnis_von_Version_9\v70toV90dmgr01\bin\backupConfig.bat \Sicherung_neuer_Host\v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -usernameBenutzername-passwordKennwort
Profilstammverzeichnis_von_Version_9/v70toV90dmgr01/bin/backupConfig.sh /Sicherung_neuer_Host/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -usernameBenutzername-passwordKennwort
Anmerkung: Sichern Sie für jeden migrierten Knoten die Deployment-Manager-Konfiguration von Version 9.0 in einer neuen Sicherungsdatei. - Wiederholen Sie diese Schritte für zusätzliche Knoten.
Ergebnisse
Sie haben die Zellenkonfigurationen mit Migrationstools von einer Vorgängerversion von WebSphere Application Server auf neue Hostmaschinen migriert, auf denen WebSphere Application Server Version 9.0 ausgeführt wird.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=tmig_migrate_remote_commandline
Dateiname:tmig_migrate_remote_commandline.html