Fehlerbehebung bei der Migration

Während der Migration von einer älteren Version von WebSphere Application Server können Fehler auftreten.

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

Vorgehensweise

Wenn bei der Migration von einer früheren Version als Version 9.0 ein Fehler auftritt, überprüfen Sie Ihre Protokolldateien und alle weiteren verfügbaren Informationen.
  • Job schlägt im Prüfschritt fehl.

    Dies weist darauf hin, dass vor Beginn des Migrationsprozesses ein Konfigurationsfehler festgestellt wurde. Der Grund dafür können fehlerhafte Daten sein, die Sie beim Erstellen der Migrationsjobs eingegeben wurden, oder ein Konfigurationsproblem. Suchen Sie in der Protokollausgabe nach dem festgestellten Fehler, beheben Sie den Fehler und führen Sie die Migration erneut durch. Die Protokolle finden Sie im Verzeichnis temporäre_Verzeichnisposition/nnnnn, wobei temporäre_Verzeichnisposition für den Wert steht, den Sie beim Erstellen der Migrationsjobs angegeben haben (die Standardeinstellung ist /tmp/migrate). nnnnn steht für eine eindeutige Nummer, die während der Erstellung der Migrationsjobs generiert und angezeigt wurde und auch unter "JESOUT DDNAME" der Schritte "WROUT" und "WRERR" Ihres Stapeljobdatentstroms angezeigt wird.

  • Job schlägt nach dem Prüfschritt fehl.

    Falls im Migrationsjob nach dem Prüfschritt ein Fehler auftritt, können Sie den Migrationsjob erneut ausführen. Zuerst müssen Sie jedoch das Konfigurationsausgangsverzeichnis von WebSphere Application Server for z/OS, das im Schritt CRHOME erstellt wurde, löschen. Dieses Verzeichnis entspricht dem Ausgangsverzeichnis, das Sie beim Erstellen der Migrationsjobs eingegeben haben. Es ist außerdem in der JCL-Umgebungsvariablen für die Migration, V6_HomeDir, enthalten. Da die Migrationsprozedur ein neues Konfigurationsdateisystem für jeden migrierten Knoten erstellt, ist es ein Einfaches, die Konfiguration zu löschen und von Neuem zu beginnen.

  • Bei der Migration eines eingebundenen Knotens treten Fehler auf.

    Ein eingebundener Knoten ist der am schwierigsten zu migrierende Knoten, weil im Prinzip zwei Migrationen in einer durchgeführt werden. Ein eingebundener Knoten erfordert die Migration der Knotenkonfigurationsdaten, die im primären Repository des Deployment Manager enthalten sind, sowie der im eingebundenen Knoten enthaltenen Konfigurationsdaten. Für die Migration eines eingebundenen Knotens ist eine aktive Verbindung zum Deployment Manager erforderlich. Wenn die Sicherheit aktiviert ist, müssen Sie auf jeden Fall die Anweisungen ausführen, die beim Erstellen der Migrationsjobs generiert werden. Der Migrationsjob muss mit der Benutzer-ID eines WebSphere-Administrators übergeben werden, die ordnungsgemäß für den Abruf sicherer Verbindungen konfiguriert ist.

  • Job schlägt während der Anwendungsinstallationsphase der Migration fehl.

    Wenn Sie die Option auswählen, durch die die Unternehmensanwendungen, die in der Konfiguration von Version 7.0 oder höher vorhanden sind, vom Migrationsprozess in der neuen Konfiguration von Version 9.0 installiert werden, werden während der Migrationsphase der Anwendungsinstallation möglicherweise Fehlernachrichten angezeigt.

    Die Anwendungen, die in der Konfiguration von Version 7.0 oder höher vorhanden sind, enthalten möglicherweise ungültige Implementierungsinformationen (in der Regel ungültige XML-Dokumente, die in früheren Laufzeiten von WebSphere Application Server nicht ausreichend validiert wurden). Die Laufzeit verfügt jetzt über einen verbesserten Validierungsprozess bei der Anwendungsinstallation und installiert solche fehlerhaften EAR-Dateien nicht. Dies verursacht ein Fehlschlagen der Anwendungsinstallationsphase im Migrationsschritt WASPostUpgrade und erzeugt eine Fehlernachricht des Typs "E:". Dies ist ein schwerwiegender Migrationsfehler.

    Wenn die Migration auf diese Art und Weise während der Anwendungsinstallation fehlschlägt, können Sie eine der folgenden beiden Vorgehensweisen wählen:
    • Beheben Sie die Fehler in den Anwendungen von Version 7.0 oder höher und führen Sie die Migration anschließend erneut durch.
    • Setzen Sie die Migration fort und ignorieren Sie diese Fehler.
      1. Starten Sie den Migrationsjob im Schritt FINISHUP erneut, damit die übrigen Migrationsfunktionen ausgeführt werden können.

        Fügen Sie zu diesem Zweck den Parameter RESTART=FINISHUP zur Jobkarte hinzu und übergeben Sie den Job erneut.

      2. Anschließend können Sie die Fehler in den Anwendungen beheben und diese Anwendungen manuell, mithilfe der Administrationskonsole oder mit einem Installationsscript, in der neuen Konfiguration von Version 9.0 installieren.
  • Es treten Fehler wegen fehlendem Speicherplatz auf.

    Die Protokolle finden Sie im Verzeichnis temporäre_Verzeichnisposition/nnnnn, wobei temporäre_Verzeichnisposition für den Wert steht, den Sie beim Erstellen der Migrationsjobs angegeben haben (die Standardeinstellung ist /tmp/migrate). nnnnn steht für eine eindeutige Nummer, die während der Erstellung der Migrationsjobs generiert wurde. Normalerweise benötigen die Migrationsprotokolle nur wenig Speicherplatz. Die Protokolldateien können jedoch sehr groß werden, wenn Sie die Traceerstellung aktivieren. Es empfiehlt sich, die Traceerstellung nur dann zu aktivieren, wenn Fehler aufgetreten sind. Falls die Traceerstellung erforderlich ist, versuchen Sie, die Traceerstellung nur für den Prozessschritt zu aktivieren, in dem der Fehler aufgetreten ist. Auf diese Weise können Sie Speicherplatz sparen.

    Sie können die Traceerstellung aktivieren, wenn Sie die Migrationsjobs mit dem z/OS Migration Management Tool oder mit dem Befehl zmmt erstellen. Zum Aktivieren der Traceerstellung mit dem Befehl zmmt legen Sie für die folgenden Eigenschaften in der Antwortdatei einen gültigen Wert fest:

    • zmbEnablePreUpgradeTrace
    • zmbEnablePostUpgradeTrace
    • zmbEnableProfileTrace
    • zmbEnableScriptingTrace

    Legen Sie für die Eigenschaften zmbEnablePreUpgradeTrace und zmbEnablePostUpgradeTrace einen Wert zwischen 0 (keine Traceerstellung) und 4 (vollständige Traceerstellung) fest. Setzen Sie die Eigenschaften zmbEnableProfileTrace und zmbEnableScriptingTrace auf 0 (keine Traceerstellung) oder 1 (Traceerstellung aktivieren).

    Sie können außerdem die Werte der Variablen in der Migrations-JCL (Job Control Language) im JCL-Member BBOWMxEV in der DATA-Datei in geeigneten Werte ändern. Die DATA-Datei wird erstellt, wenn Sie mit dem z/OS Migration Management Tool oder mit dem Befehl zmmt eine Migrationsdefinition erstellen. Wenn Sie die JCL ändern, legen Sie für TraceState und profileTrace den Wert disabled oder enabled fest und für preUpGradeTrace und postUpGradeTrace einen Wert zwischen 0 (keine Traceerstellung) und 4 (vollständige Traceerstellung).
    Anmerkung: Der Membername für einen Deployment Manager lautet BBOWMDEV. Für einen eingebundenen Knoten lautet der Membername BBOWMMEV.

    Während der Migration wird eine Sicherungskopie der Konfiguration von Version 7.0 oder höher erstellt. Diese Sicherung ist die Quelle für die zu migrierenden Informationen. Der Standardpfad zur Sicherungskopie lautet /tmp/migrate/nnnnn. Diese Position kann beim Erstellen der Migrationsjobs geändert werden. Je nach Größe des zu migrierenden Knotens kann diese Sicherung sehr groß sein. Falls nicht genügend temporärer Speicherplatz verfügbar ist, müssen Sie die Position der Sicherung ändern.

  • Es treten Fehler wegen fehlendem Speicherplatz auf.
    Führen Sie die folgenden Schritte aus, um die Speicherbelegung zu optimieren:
    1. Bearbeiten Sie die Jobdatei, um zu verhindern, dass Anwendungsspeicherplatz gemeinsam genutzt wird und erhöhen Sie die Mindest- und Maximalgröße für den JVM-Heapspeicher.
      Nachfolgend wird ein Beispiel für die Bearbeitung des Jobs BBOWM3D für eine Deployment-Manager-Migration beschrieben, die einen Heapspeicher von 768 MB verwendet. Dies ist mehr als die Standardgröße von 256 MB.
      BPXBATCH SH + export _BPX_SHAREAS=NO; +
      export IBM_JAVA_OPTIONS="-Xms256M -Xmx768M"; + 
      /wit/bigtmp/bbomigrt2.sh WASPreUpgrade + 
      /wit/bigtmp/24173105/_ + 
      1>> /wit/bigtmp/24173105/BBOWMG3D.out +
      2>> /wit/bigtmp/24173105/BBOWMG3D.err; 
    2. Bearbeiten Sie das entsprechende Migrationsscript.

      Wenn Sie von einem System migrieren, auf dem Sie auf das schreibgeschützte Treiberdateisystem zugreifen können, bearbeiten Sie die Scripts WASPreUpgrade.sh und WASPostUpgrade.sh im Verzeichnis bin.

      Wenn Sie das schreibgeschützte Treibersystem nicht bearbeiten können, verwenden Sie die drei Migrationsjobs anstelle eines einzigen Migrationsjobs, sodass die Migration nach der Profilerstellung anhält und Sie die Profilscripts bearbeiten können. Die Ausführung des Migrationsjobs BBOWMG3* entspricht der Ausführung der folgenden drei Jobs in der genannten Reihenfolge:
      • BBOWMPRO
      • BBOWMPRE
      • BBOWMPOS
      Der Job BBOWMG3* und die drei einzelnen Jobs schließen einander aus. Führen Sie daher nur den Job BBOWMG3* oder die drei einzelnen Jobs, aber nicht alle Jobs aus.
    Der Job *PRO führt die Produktinstallation und die Profilerstellung durch. Nachdem dieser Job erfolgreich abgeschlossen wurde, haben Sie Zugriff auf das Profil von Version 9.0, das für die Migration verwendet wird. Wechseln Sie in das Installationsverzeichnis von Version 9.0 und anschließend in das entsprechende Verzeichnis ${WAS_HOME}/bin. An dieser Position finden Sie die Scripts WASPreUpgrade.sh und WASPostUpgrade.sh. Wenn es symlinks auf das schreibgeschützte Dateisystem gibt, entfernen Sie die symlinks und kopieren Sie die ursprünglichen Dateien vom schreibgeschützten Dateisystem an diese Position. Wenn Sie die tatsächlichen Migrationsscriptdateien im Verzeichnis ${WAS_HOME}/bin haben, bearbeiten Sie diese Dateien und ändern Sie die Zeilen für PJO (Performance Java™ Options), um die Heap-Einstellungen in einen für Ihr System entsprechenden Wert zu ändern. Beispiel:
    set PERFJAVAOPTION=-Xms256M -Xmx768M

    Sie können jetzt mit der Migration fortfahren. Wenn Sie entschieden haben, die drei einzelnen Jobs auszuführen, starten Sie den Job BBOWMPRE und nach erfolgreicher Ausführung (bei einem Rückkehrcode von Null) den Job BBOWMPOS. Wenn Sie die Kopie des schreibgeschützten Dateisystems der Migrationsscriptdateien bearbeitet haben, können Sie den entsprechenden Job BBOWMG3* ausführen.

  • Die zulässige Zeit für den Stapeljob wurde überschritten.

    Jede z/OS-Installation unterscheidet sich im Hinblick auf die Jobklassen und die Zeitlimits. Stellen Sie sicher, dass die gültigen Jobklassen und Zeitlimits für Ihre Jobkarte definiert sind.

  • Die Migration eines Deployment Manager oder eigenständigen Anwendungsservers wird durchgeführt, aber es werden keine Anwendungen installiert.
    Die Protokolldatei kann Nachrichten wie die folgenden enthalten:
    MIGR0339I: Die Anwendung WISO_wisoadmin_war.ear wird mit dem Befehl wsadmin implementiert.
    MIGR0241I: Ausgabe von wsadmin.
    Error: unable to allocate 268435456 bytes for GC in j9vmem_reserve_memory.
    JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap. 256M requested
    Could not create the Java virtual machine.

    Das Problem ist Folgendes: Das über bbomigrt2.sh gestartete Script WASPostUpgrade besitzt nicht genügend verbleibenden Adressraum, um die Java Virtual Machine (JVM) zu starten. Gewöhnlich weist dies darauf hin, dass der gestartete Prozess in demselben Adressraum wie die JVM von WASPostUpgrade ausgeführt wird.

    Sie können die Umgebungsvariable _BPX_SHAREAS verwenden, um dem zugrunde liegenden Prozess mitzuteilen, ob gestartete Prozesse denselben Adressraum wie der übergeordnete Prozess verwenden sollen. Der Standardwert (null) ist NO, aber Administratoren können diesen Wert in YES oder MUST ändern, um die Leistung zu steigern, weil der Adressraum bei Verzweigungs- oder Startaktionen nicht kopiert werden muss.

    Wenn auf Ihrem System das hier beschriebene Problem auftritt, führen Sie den Migrationsjob mit der Umgebungsvariablen _BPX_SHAREAS aus, die Sie explizit auf NO setzen. Sie können diese Variable entweder im Systemprofil (/etc/profile) oder im Benutzerprofil des Benutzers, der den Migrationsjob ausführt, setzen. Verwenden Sie den folgenden Eintrag, um diese Variable auf NO zu setzen:
    export _BPX_SHAREAS = NO 

    Nach Abschluss des Migrationsjobs können Sie das Profil aktualisieren und _BPX_SHAREAS auf den ursprünglichen Wert setzen.

  • Nach der Migration treten Fehler beim Serverstart auf.

    Überprüfen Sie die Anweisungen, die beim Erstellen der Migrationsjobs generiert werden. Vergewissern Sie sich, dass die JCL-Prozeduren ordnungsgemäß in die PROCLIB kopiert wurden, dass die RACF-Definitionen erstellt wurden und dass die Bibliotheken von Version 9.0 berechtigt wurden. Stellen Sie sicher, dass der Dämonprozess, der Ihrer Zelle zugeordnet ist, auf dem richtigen Stand ist. Der Dämonprozess muss den höchsten Versionsstand (von WebSphere Application Server for z/OS) aller Server haben, die er innerhalb der Zelle verwaltet.

    Nach der Migration auf eine Zelle mit Version 9.0, die Knoten enthält oder mit Knoten interagiert, die sich auf dem Stand von Version 7.0 oder höher, aber nicht auf dem Stand von Version 6.0.2.11 oder höher befinden, kann die Clusterfunktion möglicherweise nicht ausgeführt werden. Beim Start dieser Anwendungsserver von Version 7.0 oder höher werden möglicherweise folgende Fehler angezeigt:
    • Im FFDC-Protokoll (First Failure Data Capture) wird eine Fehlernachricht des Typs ClassNotFoundException angezeigt. Diese Ausnahme wird von der Methode RuleEtiquette.runRules ausgelöst und sieht aus wie das folgende Beispiel:
      Exception = java.lang.ClassNotFoundException
      Source = com.ibm.ws.cluster.selection.SelectionAdvisor.<init>
      probeid = 133
      Stack Dump = java.lang.ClassNotFoundException: rule.local.server
      at java.net.URLClassLoader.findClass(URLClassLoader.java(Compiled Code))
      at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:106)
      at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))
      at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))
      at java.lang.Class.forName1(Native Method)
      at java.lang.Class.forName(Class.java(Compiled Code))
      at com.ibm.ws.cluster.selection.rule.RuleEtiquette.runRules(RuleEtiquette.java:154)
      at com.ibm.ws.cluster.selection.SelectionAdvisor.handleNotification(SelectionAdvisor.java:153)
      at com.ibm.websphere.cluster.topography.DescriptionFactory$Notifier.run(DescriptionFactory.java:257)
      at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1462)
    • Möglicherweise wird eine Ausnahme des Typs java.io.IOException angezeigt, die ähnlich aussieht wie das folgende Beispiel:
      Exception = java.io.IOException
      Source = com.ibm.ws.cluster.topography.DescriptionManagerA. update probeid = 362
      Stack Dump = java.io.IOException
      at com.ibm.ws.cluster.topography.ClusterDescriptionImpl.importFromStream(ClusterDescriptionImpl.java:916)
      at com.ibm.ws.cluster.topography.DescriptionManagerA.update(DescriptionManagerA.java:360)
      Caused by: java.io.EOFException
      at java.io.DataInputStream.readFully(DataInputStream.java(Compiled Code))
      at java.io.DataInputStream.readUTF(DataInputStream.java(Compiled Code))
      at com.ibm.ws.cluster.topography.KeyRepositoryImpl.importFromStream(KeyRepositoryImpl.java:193)
    • Fehler vermeiden Fehler vermeiden: Nach der Migration auf WebSphere Application Server Version 9.0 kann der SIP-Proxy-JSR116-Datenverkehr (SIP = Session Initiation Protocol) mit Zeitlimitüberschreitungen bei Übertragungswiederholungen und Fehlernachrichten fehlschlagen. Wenn diese Fehlersituation vorliegt, kann folgende Fehlernachricht angezeigt werden:
      TCP Channel initialization failed. The socket bind failed for host and port 5060.
      Zum Beheben dieses Problems können Sie die Transportkette UDP_SIP_PROXY_CHAIN in der Datei "serverindex.xml" auf der Knotenebene des Servers, in der der Fehler aufgetreten ist, löschen.gotcha

Suchen Sie nach der Migration in der Jobausgabe und den Protokolldateien sorgfältig nach Fehlern.

Anmerkung: WebSphere Application Server stellt ein IPCS-Verb-Exit (Interactive Problem Control System) als Unterstützung bei der Formatierung von Informationen aus Speicherauszügen von WebSphere Application Server-Prozessen bereit. Dieses Verb-Exit hatte den Namen CBDATA und dieser Name ist in Version 7.0 oder höher ein Aliasname des echten Modulnamens. In Version 9.0 wurde dieser Aliasname entfernt. In Version 9.0 und höher müssen Sie daher anstelle des Aliasnamens den echten Namen dieses Verb-Exits verwenden, d. h. BBORDATA.

Wenn Sie einen Knoten auf Version 9.0 migrieren und anschließend feststellen, dass Sie ihn wieder auf Version 7.0 oder höher zurücksetzen müssen, lesen Sie den Artikel Umgebungen zurücksetzen.

Aktuelle Informationen des IBM® Support zu bekannten Problemen und ihrer Behebung finden Sie auf der Webseite des IBM Support. Der IBM Support hat Dokumente, mit denen Sie Zeit bei der Erfassung der für die Lösung des Problems erforderlichen Informationen sparen können. Bevor Sie einen PMR öffnen, lesen Sie die Informationen auf der Webseite des IBM Support.

Zu den neuen Ports, die auf einem migrierten Node Agent von Version 9.0 registriert sind, gehören folgende: WC_defaulthost, WC_defaulthost_secure, WC_adminhost, WC_adminhost_secure SIB_ENDPOINT_ADDRESS, SIB_ENDPOINT_SECURE_ADDRESS ,SIB_MQ_ENDPOINT_ADDRESS, SIB_MQ_ENDPOINT_SECURE_ADDRESS. Diese Ports werden vom Node Agent nicht benötigt und können gefahrlos gelöscht werden.

Nächste Schritte

Wenn Ihr Problem nicht aufgeführt ist, wenden Sie sich an den IBM Support.


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