[AIX Solaris HP-UX Linux Windows]

Zellen mit dem Befehlszeilentool auf neue Hostmaschinen migrieren

Vorbereitende Schritte

Unterstützte Konfigurationen Unterstützte Konfigurationen:

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.

sptcfg

Sehen Sie sich die Informationen zur Migrationsplanung an. Weitere Informationen finden Sie auf der Webseite Knowledge Collection: Migration planning for WebSphere Application Server.

Tipp: Anstatt einzelne Parameter in Migrationsbefehlen anzugeben, können Sie den Parameter -properties Dateiname.properties angeben, um eine Eigenschaftendatei einzugeben. Weitere Informationen hierzu finden Sie im Artikel Migration mit Eigenschaften migrieren.

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.

Der Befehl "WASPreUpgrade" muss im WebSphere Application Server-Zielrelease ausgeführt werden. Die Quellenmaschine hat die neue Version des Befehls "WASPreUpgrade" nicht. Sie müssen eine der folgenden Aktionen ausführen:
  • 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).
Wenn Sie die ferne JAR-Migrationsdatei erstellt haben, können Sie sie auf der Quellenmaschine ausführen.
Anmerkung: OPTION 2 ist einfacher, da keine vollständige Installation erforderlich ist. Nachdem das Archiv erstellt wurde, kann es für viele Quellenmaschinen verwendet werden. Wenn sich die Ziel- und Quellenmaschine jedoch in verschiedenen Betriebssystemarchitekturen befinden, muss OPTION 1 ausgeführt werden, weil sich das ferne Migrationsarchiv nach der Betriebssystemarchitektur richtet.

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.

Fehler vermeiden Fehler vermeiden: Stellen Sie sicher, dass der Wert für die maximale Anzahl geöffneter Dateien 10000 oder höher ist. Wenn dieser Wert zu niedrig angegeben ist, kann dies zu einer Reihe von Migrationsfehlern führen. gotcha
Hinweis zur Umstellung Hinweis zur Umstellung: WebSphere Virtual Enterprise und Intelligent Management setzten bislang separate Migrationstools voraus. Sie werden jetzt aber im Rahmen der Standardmigrationsprozeduren migriert. trns
Einschränkung: Die ferne Migration unter IBM® i oder z/OS wird nicht unterstützt.

Vorgehensweise

  1. 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.
    1. Wechseln Sie in das Verzeichnis Deployment-Manager-Profilstammverzeichnis/bin.
    2. Führen Sie den Befehl backupConfig mit den entsprechenden Parametern aus, und speichern Sie die aktuelle Profilkonfiguration in einer Datei. Beispiel:
      [Windows]
      Stammverzeichnis_des_Anwendungsservers_der_Vorgängerversion\v70dmgr01\bin\
      backupConfig.bat \Sicherung_alter_Host\v70dmgr01backupBeforeV90migration.zip
      -username Benutzername -password Kennwort -nostop
      [AIX][HP-UX][Linux][Solaris]
      Anwenungsserverstammverzeichnis_der_Vorgängerversion/v70dmgr01/bin/backupConfig.sh
      /Sicherung_alter_Host/v70dmgr01backupBeforeV90migration.zip -username
      Benutzername -password Kennwort -nostop
      Hierbei ist Sicherung_alter_Host die Position, an der die Konfigurationswiederherstellungspunkte gespeichert sind.
    3. Wechseln Sie für jeden Knoten in der Konfiguration in das Verzeichnis Stammverzeichnis_des_Knotenprofils/bin.
    4. Führen Sie den Befehl backupConfig mit den entsprechenden Parametern aus und speichern Sie die aktuelle Profilkonfiguration in einer Datei. Beispiel:
      [Windows]
      Stammverzeichnis_des_Anwendungsservers_der_Vorgängerversion\v70node01\bin\backupConfig.bat
      \Sicherung_alter_Host\v70node01backupBeforeV90migration.zip -username
       Benutzername -password Kennwort -nostop
      [AIX][HP-UX][Linux][Solaris]
      Stammverzeichnis_des_Anwendungsservers_der_Vorgängerversion/v70node01
      /bin/backupConfig.sh /Sicherung_alter_Host/v70node01rbackupBeforeV90migration.zip
      -username Benutzername -password Kennwort -nostop
  2. Installieren Sie WebSphere Application Server Network Deployment Version 9.0 auf jedem Zielhost in einem neuen Verzeichnis.

    Weitere Informationen finden Sie in der Installationsdokumentation.

  3. 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 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
    1. 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.
    2. Erstellen Sie die JAR-Datei (.jar) für die ferne Migration.
      1. Geben Sie an der Eingabeaufforderung Folgendes ein: cd $WAS_HOME/bin/migration/bin
      2. 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.
    3. Bereiten Sie das ferne System für den Befehl "WasPreUpgrade" vor.
      1. Senden Sie die JAR-Datei an das System, auf dem sich das Quellenprofil befindet.
      2. Extrahieren Sie die Datei in ein temporäres Verzeichnis.
      3. 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.

  4. 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 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:
    [Windows]
    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
    [AIX][HP-UX][Linux][Solaris]
    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
  5. 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.
    1. Führen Sie den Befehl WASPreUpgrade mit dem Parameter -machineChange true aus, um die aktuelle Deployment-Manager-Konfiguration in einem Migrationssicherungsverzeichnis zu speichern. Beispiel:
      [Windows]
      <Pfad zur JAR-Datei für die ferne Migration>\migration\bin\WASPreUpgrade.bat \Sicherung_alter_Host\v70toV90dmgr01
      \opt\WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <Pfad zur JAR-Datei für die ferne Migration>/migration/bin/WASPreUpgrade.sh /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.

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

  6. Archivieren Sie das mit dem Befehl WASPreUpgrade erstellte Sicherungsverzeichnis.
    Fehler vermeiden Fehler vermeiden: Verwenden Sie nicht das Windows-Archivierungstool, da es sich nicht für eine Migration von WebSphere Application Server eignet. gotcha
    1. 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/
    2. Verschieben Sie die archivierte Datei auf die Zielmaschine.
    3. Erstellen Sie ein Verzeichnis auf der Zielmaschine und extrahieren Sie die archivierte Datei in das neue Verzeichnis. Beispiel:
      mkdir /Sicherung_neuer_Host
      cd /Sicherung_neuer_Host
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      Hierbei ist Sicherung_neuer_Host das Verzeichnis, in das Sie Ihre Dateien migrieren.
  7. 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.

    1. Führen Sie den Befehl WASPostUpgrade aus, um die gesicherte Deployment-Manager-Konfiguration im neuen Deployment-Manager-Profil von Version 9.0 wiederherzustellen. Beispiel:
      [Windows]
      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
      [AIX][HP-UX][Linux][Solaris]
      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
      In diesem Beispiel ist Sicherung_neuer_Host das Verzeichnis, aus dem die Konfigurationsdateien des Quellenprofils migriert werden.

      [AIX Solaris HP-UX Linux Windows]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.

    2. 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 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
  8. 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 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
    1. Wechseln Sie in das Verzeichnis Deployment-Manager-Profilstammverzeichnis/bin.
    2. Führen Sie den Befehl backupConfig mit den geeigneten Parametern aus und speichern Sie die Profilkonfiguration von Version 9.0 in einer Datei. Beispiel:
      [Windows]
      Profilstammverzeichnis_von_Version_9\profiles\v70toV90dmgr01\
      bin\backupConfig.bat \Sicherung_neuer_Host\v70toV90dmgr01backupMigratedDmgrOnly.zip
      -username Benutzername -password Kennwort
      [AIX][HP-UX][Linux][Solaris]
      Profilstammverzeichnis_von_Version_9/profiles/v70toV90dmgr01/bin/backupConfig.sh /
      Sicherung_neuer_Host/v70toV90dmgr01backupMigratedDmgrOnly.zip -username
      Benutzername -password Kennwort
      Hierbei ist Sicherung_neuer_Host die Position, an der die Konfigurationswiederherstellungspunkte gespeichert sind.
  9. Stoppen und inaktivieren Sie den Deployment Manager auf dem alten Host.
    1. Stoppen Sie den Deployment Manager auf dem alten Host.
    2. 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
  10. Starten Sie den Deployment Manager von Version 9.0 auf dem neuen Host.
    1. Wechseln Sie in das neue Verzeichnis Version 9.0 Deployment-Manager-Profilstammverzeichnis/bin.
    2. Führen Sie den Befehl startManager aus.
    3. 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.
    4. Stellen Sie sicher, dass der Deployment Manager von Version 9.0 erfolgreich gestartet wird.
  11. 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.

    1. Stoppen Sie den Node Agent.
    2. 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.
    3. Führen Sie im Verzeichnis "bin" den Befehl syncNode aus. Beispiel:
      [Windows]
      Installationsstammverzeichnis_des_Node_Agent\bin\syncNode.bat myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      Installationsstammverzeichnis_des_Node_Agent/bin/syncNode.sh myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
    4. Starten Sie den Node Agent, wenn die Synchronisation erfolgreich war.
  12. Migrieren Sie Plug-ins für Web-Server.
    1. Stellen Sie sicher, dass der Deployment Manager von Version 9.0 aktiv ist.
    2. Führen Sie ein Upgrade der Version des Web-Server-Plug-ins durch, das in der Zelle verwendet wird.
    3. Sehen Sie sich die unterstützenden Informationen zu Typ und Version Ihres Web-Servers an.
  13. 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.

    1. Geben Sie alle zu migrierenden Client-Hosts an.
    2. Installieren Sie den Anwendungsclient von WebSphere Version 9.0.
    3. 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
    4. 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 
  14. 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 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
    1. Installieren Sie WebSphere Application Server Version 9.0 auf jedem Zielhost. Weitere Informationen finden Sie in der Dokumentation zur Installation einer Anwendungsserverumgebung.
    2. Erstellen Sie das Zielknotenprofil. Führen Sie den Befehl manageprofiles mit den entsprechenden Parametern aus, um ein neues verwaltetes Profil zu erstellen. Beispiel:
      [Windows]
      Installationsstammverzeichnis_von_Version_9\bin\manageprofiles.bat
      -create -profileName node1 -templatePath \opt\
      WebSphereV90\profileTemplates\managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
      [AIX][HP-UX][Linux][Solaris]
      Installationsstammverzeichnis_von_Version_9/bin/manageprofiles.sh
      -create -profileName node1 -templatePath 
      /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
    3. 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.
    4. 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:
      [Windows]
      <Pfad zur JAR-Datei für die ferne Migration>\migration\bin\WASPreUpgrade.bat \Sicherung_alter_Host\v70toV90node1
      \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <Pfad zur JAR-Datei für die ferne Migration>/migration/bin/WASPreUpgrade.sh /Sicherung_alter_Host/v70toV90node1
      /opt/WebSphereV70 -oldProfile 70node1 -machineChange true
    5. 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.

    6. Verwenden Sie ein Archivierungstool Ihrer Wahl, um eine komprimierte Datei des Sicherungsverzeichnisses zu erstellen, das mit dem Befehl "WASPreUpgrade" erstellt wurde. Beispiel:
      [AIX Solaris HP-UX Linux Windows]
      cd /Sicherung_alter_Host
      /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/
    7. Verschieben Sie die archivierte Datei auf die Zielmaschine.
    8. Erstellen Sie ein Verzeichnis auf der Zielmaschine und extrahieren Sie die archivierte Datei in das neue Verzeichnis. Beispiel:
      mkdir /Sicherung_neuer_Host
      cd /Sicherung_neuer_Host
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      In diesem Beispiel ist Sicherung_neuer_Host das Verzeichnis, aus dem die Profilkonfigurationsdateien migriert werden.
    9. Stoppen Sie die Anwendungsserver auf dem alten Knoten und stoppen Sie anschließend den Node Agent auf dem alten Knoten.
    10. 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
    11. Führen Sie den Befehl WASPostUpgrade aus, um die gesicherte Knotenkonfiguration im neuen verwalteten Profil von Version 9.0 wiederherzustellen. Beispiel:
      [Windows]
      Installationsstammverzeichnis_von_Version_9\bin\WASPostUpgrade.bat \
      Sicherung_neuer_Host\v70toV90node1 -profileName v70toV90node1
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -includeApps TRUE 
      -usernameBenutzername-passwordKennwort
      [AIX][HP-UX][Linux][Solaris]
      Installationsstammverzeichnis_von_Version_9/bin/WASPostUpgrade.sh /
      Sicherung_neuer_Host/v70toV90node1 -profileName v70toV90node1
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig 
      TRUE -includeApps TRUE 
      -usernameBenutzername-passwordKennwort

      [AIX Solaris HP-UX Linux Windows]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.

      [Windows]
      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
      [AIX][HP-UX][Linux][Solaris]
      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
    12. 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".

    13. 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.
    14. Starten Sie den migrierten Node Agent mit Version 9.0.
    15. Suchen Sie in der Datei SystemOut.log des Deployment Manager und des Knotens mit Version 9.0 nach Fehlernachrichten und Warnungen.
    16. Optional: Synchronisieren Sie die Zelle, wenn der automatische Synchronisationsprozess nicht aktiviert ist.
    17. Starten Sie die entsprechenden Anwendungsserver auf dem migrierten Knoten mit Version 9.0.
    18. Führen Sie den Befehl backupConfig aus und speichern Sie die Profilkonfiguration von Version 9.0 in einer Datei. Beispiel:
      [Windows]
      Profilstammverzeichnis_von_Version_9\v70toV90node1\bin\backupConfig.bat
      \Sicherung_neuer_Host\v70toV90node1.zip -username myuser
      -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      Profilstammverzeichnis_von_Version_9/v70toV90node1/bin/backupConfig.sh
      /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.
    19. 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:
      [Windows]
      Profilstammverzeichnis_von_Version_9\v70toV90dmgr01\bin\backupConfig.bat
      \Sicherung_neuer_Host\v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip
      -usernameBenutzername-passwordKennwort
      [AIX][HP-UX][Linux][Solaris]
      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.
    20. 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.


Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tmig_migrate_remote_commandline
Dateiname:tmig_migrate_remote_commandline.html