Eingebundenen Knoten unter z/OS migrieren

Nachdem Sie den Deployment Manager migriert und erneut gestartet haben, können Sie die eigentliche Migration der eingebundenen Anwendungsserverknoten mit den JCL-Jobs durchführen, die Sie generiert haben. Mit dem Generieren der angepassten Migrationsjobs haben Sie auch angepasste Anweisungen für die Vorbereitung und Ausführung der Migrationsjobs in den BBOMMINS-Membern der CNTL-Datei erstellt, die zum Generieren der Jobs verwendet wurde. Folgen Sie diesen angepassten Anweisungen, um die Migration der eingebundenen Knoten auf Version 9.0 durchzuführen.

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
  • Nähere Informationen hierzu finden Sie in den Artikeln Übersicht über Migration, Koexistenz und Interoperabilität und Hinweise zur Migration.
  • Sie können die Verarbeitung nicht fortsetzen, wenn Sie keine JCL-Migrationsjobs generiert haben.
  • Die in diesen Anweisungen referenzierten Jobs BBOWMG1F, BBOWMG2F und BBOWMG3F müssen unter Verwendung einer WebSphere-Administrator-ID übergeben werden.

    Alle anderen Jobs müssen von einer Benutzer-ID übergeben werden, die das Dateisystem steuert.

  • Wenn Sie einen eingebundenen Knoten in einem anderen MVS-Image migrieren möchten, vergewissern Sie sich, dass Sie die Jobs in demselben System ausführen, in dem sich der Knoten selbst befindet.
  • Hinweis: Bei der Migration eines eingebundenen Knotens mit WebSphere Application Server Version 7.0 oder höher müssen Sie die folgenden Aktionen ausführen, wenn Sie in der Lage sein möchten, nach der Migration den ursprünglichen Zustand wiederherzustellen:
    1. Sichern Sie die vorhandene Konfiguration mit dem Befehl backupConfig oder einem von Ihnen bevorzugten Sicherungsdienstprogramm.
      • Führen Sie den Befehl backupConfig oder das von Ihnen bevorzugte Sicherungsdienstprogramm aus, um die Deployment-Manager-Konfiguration von Version 9.0 zu sichern.
      • Führen Sie den Befehl backupConfig oder das von Ihnen bevorzugte Dienstprogramm aus, um die Konfiguration des eingebundenen Knotens der Version 7.0 oder höher zu sichern.
      Wichtig: Notieren Sie unbedingt den genauen Namen und die Position der gesicherten Konfiguration.

      Weitere Informationen finden Sie im Artikel Befehl "backupConfig" in der Dokumentation.

    2. Migrieren Sie den eingebundenen Knoten.

    Bei Bedarf können Sie jetzt den migrierten eingebundenen Knoten wieder in den ursprünglichen Zustand zurückversetzen. Nähere Informationen finden Sie im Artikel Migration eines eingebundenen Knotens rückgängig machen.

Hilfe finden Sie im Artikel Fehlerbehebung bei der Migration.

Informationen zu diesem Vorgang

Hinweis zur Umstellung Hinweis zur Umstellung: Die folgenden Produkte haben zuvor unterschiedliche Migrationstools erfordert, sie werden jetzt jedoch im Rahmen der Standardmigrationsprozeduren migriert.
  • WebSphere Extended Deployment Compute Grid oder Feature Pack for Modern Batch
  • WebSphere Virtual Enterprise oder Intelligent Management
Weitere Informationen zu diesen Änderungen finden Sie unter Neuerungen für die Migration.trns

Vorgehensweise

  1. Vergewissern Sie sich, dass die Anwendungsserver und der Node Agent für den eingebundenen Knoten, der migriert werden soll, gestoppt sind.

    Sie müssen den eingebundenen Knoten stoppen, bevor Sie fortfahren.

  2. Vergewissern Sie sich, dass der neu migrierte Deployment Manager aktiv ist.

    Damit der Anwendungsserverknoten ordnungsgemäß migriert werden kann, muss der Deployment Manager aktiv sein. Damit die Migration funktioniert, muss der Deployment Manager aktiv und an seinem SOAP-Port empfangsbereit sein.

    Tabelle 1. Deployment Manager ist aktiv. Setzen Sie nach der Durchführung einen Haken unter "Erledigt".
    Erledigt Eintrag
      Rufen Sie die Administrationskonsole des Deployment Manager von WebSphere Application Server Version 9.0 auf. Damit wird geprüft, ob der Deployment Manager aktiv ist.
    Tabelle 2. Anwendungsserver ist aktiv. Setzen Sie nach der Durchführung einen Haken unter "Erledigt".
    Erledigt Eintrag
      Stellen Sie sicher, dass die Codekopie von WebSphere Application Server Version 9.0 aktiv ist. Die Version wird im Teilfenster Willkommen der Administrationskonsole aufgeführt.
  3. Erstellen Sie ein neues Konfigurationsdateisystem für Version 9.0 und hängen Sie dieses an.

    Für die Durchführung der Migration setzt Version 9.0 voraus, dass ein Konfigurationsdateisystem für die neue Konfiguration vorhanden ist. Sie können den Job BBOMMHFS oder BBOMMZFS ausführen, um ein neues Konfigurationsdateisystem zu erstellen und anzuhängen. Das Dateisystem kann aber auch manuell angehängt werden. In jedem Fall müssen Sie ein Dateisystem für die Konfiguration von Version 9.0 erstellen und anhängen, um mit der Migration fortfahren zu können. Dieses Konfigurationsdateisystem ist das Ziel der Migration und Ihr Konfigurationsdateisystem für Version 7.0 oder höher ist die Quelle.

    BBOMMHFS und BBOMMZFS erstellen ein Mountpunktverzeichnis, ordnen das Dateisystem der Konfiguration zu und hängen das Dateisystem an dem Mountpunkt an, den Sie beim Generieren der Migrationsjobs angegeben haben.

    Vergewissern Sie sich, dass Sie die Dateien des Konfigurationsdateisystems manuell oder mithilfe von BBOMMHFS oder BBOMMZFS angelegt, erstellt und angehängt haben, bevor Sie fortfahren. Die WebSphere-Administrator-ID muss der Eigner des Mountpunkts sein und mindestens die Berechtigungen 755 haben. Die neuen Dateisystemstrukturen sollten in BPXPARM eingefügt werden, sodass sie beim nächsten IPL angehängt werden.

  4. Übergeben Sie BBOWMG1F und BBOWMG2F.
    Anmerkung: Wenn Sie keine XA-Connector verwenden, ist die Übergabe von BBOWMG1F und BBOWMG2F optional. Sie sollten jedoch beide Jobs übergeben, um sicherzustellen, dass Ihre Transaktionsprotokolle bereinigt werden.

    BBOWMG1F bewirkt, dass alle Server auf dem zu migrierenden eingebundenen Anwendungsserverknoten im PRR-Modus (Peer Restart and Recovery) gestartet werden. Der PRR-Verarbeitungsmodus löst alle ausstehenden Transaktionen auf, löscht die Transaktionsprotokolle und stoppt den Server. BBOWMG2F inaktiviert den PRR-Modus und versetzt alle Server wieder in den normalen Betriebsmodus.

    Führen Sie die folgenden Schritte aus, um die XA-Transaktionsprotokolle zu löschen:
    1. Stoppen Sie den Anwendungsserver.
    2. Übergeben Sie den Job BBOWMG1F und prüfen Sie, ob der Rückkehrcode 0 ist.
    3. Starten Sie den eingebundenen Anwendungsserver erneut und warten Sie, bis er die PRR-Verarbeitung automatisch durchführt und abschließt.
      Tipp: Nachdem die Transaktionen aufgelöst sind und der Server gestoppt ist, sollte ein Rückkehrcode von 0 angezeigt werden. Das folgende Beispiel zeigt einen erwartungsgemäßen Rückkehrcode für den Serverprozess an:
      BBOO0035W Aktueller Thread wird beendet. Ursache=C9C218D5
    4. Übergeben Sie den Job BBOWMG2F und prüfen Sie, ob der Rückkehrcode 0 ist.
  5. Kopieren Sie die generierten JCL-Prozeduren.

    Das Migrationsdienstprogramm BBOMMCP kopiert die generierten JCL-Prozeduren, damit die Server in der angegebenen Prozedurenbibliothek gestartet werden können. Die Konfiguration von Version 9.0 muss andere JCL-Prozeduren verwenden als diejenigen, die von der Konfiguration von Version 7.0 oder höher verwendet werden. Dieses Dienstprogramm aktualisiert die neue Konfiguration von Version 9.0, indem es die Namen in der ursprünglichen Konfiguration von Version 7.0 oder höher durch die neuen JCL-Namen ersetzt.

    Vorsicht: Dieses Dienstprogramm kopiert die generierte JCL in Ihre Prozedurenbibliothek. Wenn Sie beim Generieren der Migrationsjobs dieselben Namen wie in der Konfiguration der Version 7.0 oder höher verwendet wurden, überschreibt dieses Dienstprogramm die vorhandenen Prozeduren. Falls Sie dieselben Namen verwenden, sollten Sie die vorhandenen Prozeduren von Version 7.0 oder höher vor Ausführung dieses Dienstprogramms sichern, falls Sie die neue Konfiguration später rückgängig machen müssen.

    Übergeben Sie BBOMMCP und prüfen Sie, ob der Rückkehrcode 0 ist.

  6. Wenn Sie neue Prozedurnamen angegeben haben, aktualisieren Sie Ihre RACF-Profile des Typs STARTED für den Controller und Dämon.
    Das von den Controllerregionen verwendete Profil STARTED basiert auf dem Prozedurnamen und JOBNAME. Sie müssen sicherstellen, dass ein gültiges Profil STARTED vorhanden ist, sodass der gestarteten Task die richtige ID zugeordnet wird. Wenn Ihre JCL-Prozedur für den Controller der Version 7.0 oder höher beispielsweise den Namen AZACR hat und Sie für Version 9.0 AZ1ACR angegeben haben, müssen Sie ein Profil STARTED für diesen neuen Prozedurnamen erstellen:
                  neuer Controller -    dieselbe Identität in der Konfiguration
                                  des JCL-Namens der Version 7.0 oder höher
                        |                    |
     RDEFINE STARTED AZ1ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
    Anmerkung:
    • Verwenden Sie keine andere Benutzer-ID zum Starten. An die Benutzer-ID sind weitere Angaben geknüpft, sodass bei einer Änderung der Benutzer-ID noch weitere Änderungen erforderlich wären.
    • Wenn das ursprüngliche Profil STARTED ein generisches Profil war, z. B. STARTED AZ*.* ..., müssen Sie kein neues Profil STARTED erstellen.
    • Die STARTED-Profile der Servantregion basieren auf JOBNAME und nicht auf dem Prozedurnamen. Es gibt also kein Problem mit dem Servant, wenn Sie einen anderen Prozedurnamen verwenden.
    • Dämonprozesse und Node Agents sind Controller. Wenn Sie also andere Prozedurnamen für diese Controller verwenden, müssen Sie ein neues Profil STARTED erstellen.
  7. Löschen Sie den Protokolldatenstrom und definieren Sie ihn anschließend erneut.
    Führen Sie diesen Schritt nur aus, wenn Sie zuvor das XA-Partnerprotokoll für Transaktionen oder das Kompensationsprotokoll im Server von Version 7.0 oder höher so konfiguriert haben, dass ein Protokolldatenstrom verwendet wird.
    1. Stellen Sie sicher, dass der Knoten gestoppt wurde.
    2. Löschen Sie den Protokolldatenstrom und definieren Sie ihn anschließend erneut.

      Sie können die während der Anpassung von Version 7.0 oder höher erstellten Jobs BBOLOGSD und BBOLOGSA verwenden, wenn im Server die Verwendung des Protokolldatenstroms konfiguriert war.

      Das folgende Beispiel zeigt einen solchen Job:
      //RLSP1A  JOB 'xxxx,yyy,?','USERID',MSGCLASS=H,
      //         CLASS=J,MSGLEVEL=(1,1),REGION=4M,NOTIFY=&SYSUID
      //STEP1   EXEC PGM=IXCMIAPU
      //STEPLIB  DD   DSN=SYS1.MIGLIB,DISP=SHR
      //SYSPRINT DD SYSOUT=*
      //SYSIN    DD *
      
      DATA TYPE(LOGR) REPORT(YES) /* Standardeinstellung, damit Ausgabe des Jobs angezeigt wird */
       DELETE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
       DEFINE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
              LOWOFFLOAD(20)
              HIGHOFFLOAD(79)
              STG_DUPLEX(YES)                                       
              DUPLEXMODE(UNCOND)                                    
              STG_DATACLAS(OPERLOG)
              STG_SIZE(5000)
              HLQ(Q10RRS)
              LS_SIZE(5000)
              LS_DATACLAS(OPERLOG)
              STRUCTNAME(WAS_LOGRLS)
      /*

    Wenn Sie Knoten in einem Sysplex migrieren, führen Sie diese Prozedur für jeden eingebundenen Knoten aus, den Sie migrieren.

  8. Führen Sie eine der folgenden Aktionen aus:
    1. Übergeben Sie den Job BBOWMG3F.
      Achtung: Wenn Sie eine z/OS-Umgebung verwenden, in der viele TCP/IP-Stacks konfiguriert sind, muss möglicherweise die Umgebungsvariable "_BPXK_SETIBMOPT_TRANSPORT" hinzugefügt werden, um den Migrationsjob an den richtigen TCP/IP-Stack weiterzuleiten. Wenn Sie einen falschen Stack verwenden, löst das Ergebnis eine Ausnahme des Typs java.net.UnknownHostException aus, wodurch die nachfolgende wsadmin-Anmeldung fehlschlägt.
      In der JCL ist die Anweisung export _BPXK_SETIBMOPT_TRANSPORT=<stack.name> erforderlich, um den geeigneten Stack zu ermitteln. Ihre JCL kann ähnlich wie im folgenden Beispiel aussehen:
      //***************************************************************         
      //*                                                                       
      //* UPGRADE: Migration auf das neue Profil durchführen
      //*                                                                       
      //***************************************************************         
      //*                                                                       
      //*                                                                       
      //UPGRADE EXEC PGM=IKJEFT01,REGION=0M,COND=(4,LE)                         
      //SYSTSPRT DD SYSOUT=*                                                    
      //STDENV DD * // _CEE_RUNOPTS=TRAP(ON,NOSPIE) //*                         
      //SYSTSIN  DD *                                                           
        BPXBATCH SH +                                                           
        export _BPXK_SETIBMOPT_TRANSPORT=TCP; +                                 
        /tmp/migrate/bbomigrt2.sh WASPostUpgrade +                              
            /tmp/migrate/28133744/_      +                                      
        1>> /tmp/migrate/28133744/BBOWMG3F.out +                                
        2>> /tmp/migrate/28133744/BBOWMG3F.err;                                 
      /*                         

      BBOWMG3F ist der Job, der die physische Migration des Knotens der Version 7.0 oder höher auf Version 9.0 basierend auf den Informationen, die Sie beim Generieren der Migrationsjobs angegeben haben, durchführt. Übergeben Sie BBOWMG3F, vergewissern Sie sich, dass der Rückkehrcode 0 ist, und überprüfen Sie die Protokolldateien im temporären Migrationsverzeichnis im Dateisystem. Das temporäre Migrationsverzeichnis ist temporäre_Verzeichnisposition/nnnnn, wobei temporäre_Verzeichnisposition für das Verzeichnis steht, das als temporäre Verzeichnisposition angegeben wurde (standardmäßig /tmp/migrate), und nnnnn für den numerischen Wert steht, der als Migrationskennung beim Generieren der Migrationsjobs generiert wurde.

    2. Übergeben Sie die folgenden drei Jobs:
      1. Übergeben Sie den Job BBOWMPRO.

        BBOWMPRO erstellt das Ausgangs- und Standardprofil von WebSphere Application Server.

      2. Übergeben Sie den Job BBOWMPRE.

        BBOWMPRE führt den upgradevorbereitenden Prozess für die Migration aus.

      3. Übergeben Sie den Job BBOWMPOS.

        BBOWMPOS führt lediglich die upgradenachbereitenden und Abschlussprozesse (Änderung der Dateiberechtigung) für die Migration aus.

  9. Stellen Sie sicher, dass der alte Dämon gestoppt wurde.

    Vergewissern Sie sich, dass alle eingebundenen Knoten in derselben Zelle in dieser LPAR gestoppt wurden.

  10. Aktualisieren Sie bei Bedarf die JCL-Prozedur des Dämons.

    WebSphere Application Server for z/OS Version 9.0 erfordert, dass der Dämonprozess den höchsten Codestand aller Server hat, die in derselben LPAR verwaltet werden. Wenn der eingebundene Knoten gestartet wird, verwendet der Dämonprozess den Stand von Version 9.0.

    Nachdem Sie alle Knoten auf Version 9.0 migriert haben und bevor Sie die Bibliotheken der früheren Version vom System entfernen, müssen Sie die JCL-Prozedur des Dämonprozesses aktualisieren. Andernfalls schlägt der Start des Dämonprozesses fehl.

    Anmerkung:
    • Wenn Sie eine Migration von Version 6.1 auf Version 9.0 durchführen, muss der Dämon eine STEPLIB haben, die die SBBOLD2- und SBBOLPA-Dateien der Version 6.1 enthält.
    • Wenn eine Zelle mit Version 9.0 einen Server von Version 9.0 enthält, der mit einem Server von Version 6.1 in einer Zelle mit Version 6.1 auf demselben System wie die Zelle mit Version 9.0 kommuniziert, müssen Sie außerdem die SBBOLD2- und SBBOLPA-Dateien von Version 6.1 der STEPLIB des Dämons von Version 9.0 hinzufügen.
  11. Starten Sie den neuen eingebundenen Anwendungsserverknoten.
    1. Starten Sie den Node Agent.
      Die folgende Nachricht wird in der Konsole und im Jobprotokoll von BBON001 angezeigt:
      BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBON001
    2. Starten Sie den eingebundenen Anwendungsserver.

      Verwenden Sie den vorhandenen Befehl, den Sie zum Starten eines Anwendungsservers von Version 7.0 oder höher verwenden würden, aber ersetzen Sie den Prozedurnamen RACF STARTED durch den Wert, den Sie beim Generieren der Migrationsjobs als Namen für die Controllerprozedur in der Anzeige für den eingebundenen Knoten eingegeben haben. Dieser Befehl startet den eingebundenen Anwendungsserver von Version 9.0. Warten Sie, bis die Initialisierung des Servers abgeschlossen ist.

      Die folgende Nachricht wird in der Konsole und im Jobprotokoll von BBOS001 angezeigt:
      BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
  12. Vergewissern Sie sich, dass Ihre Konfiguration und Anwendungen ordnungsgemäß migriert wurden.

    Vergewissern Sie sich für Compute Grid oder Feature Pack for Modern Batch, dass der Job-Scheduler ordnungsgemäß migriert wurde und dass Sie Jobs den Servern zuteilen können, die Ihre Stapelanwendungen hosten.

    Greifen Sie nach dem Neustart des Deployment Manager über einen Web-Browser auf die Job-Management-Konsole zu, um die Job-Scheduler-Migration zu überprüfen.

    Gehen Sie wie folgt vor, um sicherzustellen, dass die Server, die Ihre Stapelanwendungen hosten, ordnungsgemäß funktionieren:
    1. Vergewissern Sie sich, dass die Stapelanwendungen im migrierten Server gestartet sind. Durchsuchen Sie die Serverprotokolle nach Fehlern.
    2. Vergewissern Sie sich, dass Sie dem migrierten Server Stapeljobs zuteilen können. Übergeben Sie hierzu einen Job über den migrierten Job-Scheduler-Server. Sie können den Job über die Job-Management-Konsole, das WSGrid-Dienstprogramm, die EJB-Schnittstelle oder die Web-Service-Schnittstelle übergeben.

Nächste Schritte

Nachdem Sie sichergestellt haben, dass die Migration auf Version 9.0 erfolgreich durchgeführt wurde und eine migrierte Konfiguration ordnungsgemäß funktioniert, müssen Sie die folgenden Elemente löschen:
  • Alle Einträge im Dateisystem der Quellenkonfiguration
  • Alle Einträge im Verzeichnis temporäre_Verzeichnisposition/nnnnn der Zielkonfiguration, wobei temporäre_Verzeichnisposition für das Verzeichnis steht, das als temporäre Verzeichnisposition angegeben wurde (standardmäßig /tmp/migrate), und nnnnn für den numerischen Wert steht, der als Migrationskennung beim Erstellen der Migrationsjobs angegeben wurde.
  • Datei bbomigrt2.sh

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_z_amn
Dateiname:tmig_z_amn.html