Risoluzione dei problemi di migrazione

• Il processo non riesce nella fase di verifica.

  Ciò indica che è stato rilevato un errore di configurazione prima dell'inizio del processo di migrazione. Ciò può essere dovuto a dati errati inseriti durante la creazione dei processi di migrazione o a un problema di configurazione. Controlla il log relativo all'errore rilevato, quindi correggi e riprova. I log si trovano in temporary_directory_location/nnnnn, dove temporary_directory_location è il valore specificato durante la creazione dei processi di migrazione (il valore predefinito è /tmp/migrate) e nnnnn è un numero univoco generato e visualizzato durante la creazione dei processi di migrazione, nonché visualizzato nel JESOUT DDNAME dei passaggi WROUT e WRERR del flusso del processo batch.

• Il processo non va a buon fine dopo la fase di verifica.

  In caso di errore nel processo di migrazione dopo la fase di verifica, è possibile rieseguire il processo di migrazione, ma prima è necessario eliminare l' WebSphere Application Server e per la directory home di configurazione z/OS® creata nella fase CRHOME. Corrisponde alla directory home immessa durante la creazione dei processi di migrazione ed è presente anche nella variabile di ambiente JCL (Job V6_HomeDirControl Language) della migrazione. Poiché la procedura di migrazione crea un nuovo file system di configurazione per ogni nodo migrato, è semplice eliminare la configurazione e ricominciare da zero.

• Si verificano problemi con la migrazione di un nodo federato.

  Un nodo federato è il nodo più complesso da migrare perché si tratta essenzialmente di due migrazioni unite in una sola. Un nodo federato richiede la migrazione delle informazioni di configurazione del nodo contenute nel repository primario del gestore di distribuzione, nonché delle informazioni di configurazione contenute nel nodo federato. La migrazione dei nodi federati richiede una connessione attiva al gestore di distribuzione. Se hai la sicurezza abilitata, è essenziale seguire le istruzioni generate al momento della creazione dei processi di migrazione. Il processo di migrazione deve essere inviato con un ID utente dell'amministratore di WebSphere che sia stato correttamente configurato per ottenere connessioni sicure.

• Il processo non riesce durante la fase di installazione dell'applicazione della migrazione.

  Se si seleziona l'opzione per il processo di migrazione che consente di installare le applicazioni aziendali presenti nella configurazione Version 7.0 o successive nella nuova configurazione Version 9.0, è possibile che vengano visualizzati messaggi di errore durante la fase di installazione delle applicazioni della migrazione.

  Le applicazioni presenti nella configurazione della versione 7.0 o successive potrebbero contenere informazioni di distribuzione errate, in genere documenti XML non validi che non sono stati sufficientemente convalidati nelle precedenti versioni di WebSphere Application Server runtime. Il runtime ora dispone di un processo di convalida dell'installazione delle applicazioni migliorato e non riuscirà a installare questi file EAR malformati. Ciò provoca un errore durante la fase di installazione dell'applicazione WASPostUpgrade e genera un messaggio di errore E. Si tratta di un errore di migrazione irrecuperabile.

  Se la migrazione non riesce in questo modo durante l'installazione dell'applicazione, è possibile procedere in uno dei seguenti modi:

  • Risolvi i problemi nelle applicazioni Version 7.0 o successive, quindi esegui nuovamente la migrazione.
  • Procedere con la migrazione e ignorare questi errori.
    1. Riavviare il processo di migrazione nella fase FINISHUP per consentire l'esecuzione delle restanti funzioni di migrazione.

       Per farlo, aggiungi il parametro RESTART=FINISHUP alla scheda di lavoro e invia nuovamente il lavoro.

    2. Successivamente, risolvere i problemi nelle applicazioni e quindi installarle manualmente nella nuova configurazione di 9.0 utilizzando la console amministrativa o uno script di installazione.
• Si verificano errori di spazio insufficiente.

  I log di migrazione si trovano in temporary_directory_location/nnnnn, dove temporary_directory_location è il valore specificato durante la creazione dei processi di migrazione (il valore predefinito è /tmp/migrate) e nnnnn è un numero univoco generato durante la creazione dei processi di migrazione. Normalmente, lo spazio richiesto per i log di migrazione è ridotto. Tuttavia, se si abilita il tracciamento, i file di log possono diventare molto grandi. La pratica migliore consiste nell'abilitare il tracciamento solo dopo che sono stati individuati dei problemi. Se è necessario eseguire il tracciamento, provare ad abilitare solo il tracciamento relativo alla fase del processo che si sta sottoponendo a debug. Questo contribuisce a ridurre lo spazio necessario.

  È possibile abilitare il tracciamento durante la creazione dei processi di migrazione utilizzando lo strumento di gestione della migrazione di z/OS o il zmmt comando. Per abilitare il tracciamento con il zmmt comando, impostare le seguenti proprietà su un valore possibile nel file di risposta:

  • zmbEnablePreUpgradeTrace
  • zmbEnablePostUpgradeTrace
  • zmbEnableProfileTrace
  • zmbEnableScriptingTrace

  Imposta zmbEnablePreUpgradeTrace e zmbEnablePostUpgradeTrace su un valore compreso tra 0 per nessuna tracciatura e 4 per tracciatura completa. Impostare zmbEnableProfileTrace e zmbEnableScriptingTrace su per disattivare il 0 tracciamento o 1 su per attivarlo.

  È inoltre possibile modificare le variabili nel linguaggio JCL (Job Control Language) di migrazione con valori appropriati nel membro JCL BB OWMxEV nel set di dati DATA creato quando si utilizza lo strumento di gestione della migrazione dell' z/OS o il zmmt comando per creare una definizione di migrazione. Quando si modifica il JCL, impostare TraceState e profileTrace su disabled o enabled, e impostare preUpGradeTrace e postUpGradeTrace su un valore compreso tra 0 per nessuna tracciatura e 4 per tracciatura completa.

  Nota: per un gestore di distribuzione, il nome del membro è BBOWMDEV; per un nodo federato, il nome del membro è BBOWMMEV.

  Durante la migrazione, viene creata una copia di backup della configurazione di Version 7.0 o versioni successive. Questo backup diventa la fonte delle informazioni oggetto della migrazione. La posizione predefinita per il backup è /tmp/migrate/nnnnn. Questa posizione può essere modificata durante la creazione dei processi di migrazione. A seconda delle dimensioni del nodo oggetto della migrazione, questo backup può essere di grandi dimensioni. Se lo spazio temporaneo non è sufficiente, è necessario trasferire questo backup.

• Si verificano errori di memoria insufficiente.
  Per migliorare l'utilizzo della memoria, eseguire le seguenti azioni:

  1. Modifica il file di lavoro per impedire la condivisione dello spazio dell'applicazione e aumenta il valore minimo e massimo dell'heap dell' JVM.
     Di seguito è riportato un esempio di come modificare il processo BBOWM3D per una migrazione di Deployment Manager in modo che utilizzi fino a 768 MB di heap, ovvero più del valore predefinito di 256.

     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. Modifica lo script di migrazione appropriato.

     Se stai effettuando la migrazione da un sistema in cui hai accesso al file system del driver in sola lettura, modifica gli script WASPreUpgrade.sh WASPostUpgrade.sh e nella bin directory.

     Se non è possibile modificare il sistema driver di sola lettura, utilizzare i tre processi di migrazione invece del singolo processo di migrazione, in modo che la migrazione si interrompa dopo la creazione del profilo e sia possibile modificare gli script del profilo. L'esecuzione del processo di migrazione " BBOWMG3* " equivale all'esecuzione dei tre processi seguenti nell'ordine indicato:

     • BBOWMPRO
     • BBOWMPRE
     • BBOWMPOS

     Il processo " BBOWMG3* " e i tre processi individuali sono mutuamente esclusivi: è possibile eseguire il singolo processo " BBOWMG3* " oppure i tre processi individuali, ma non entrambi contemporaneamente.

  Il lavoro *PRO esegue l'installazione del prodotto e la creazione del profilo. Una volta completato con successo questo processo, avrai accesso al profilo Version 9.0 che verrà utilizzato per la migrazione. Accedere alla directory di installazione di Version 9.0 e andare alla posizione ${WAS_HOME}/bin equivalente. Troverete gli script WASPreUpgrade.sh WASPostUpgrade.sh e in questa posizione. Se si tratta di collegamenti simbolici al file system di sola lettura, rimuovere i collegamenti simbolici e copiare i file originali dal file system di sola lettura in questa posizione. Dopo aver creato i file di script di migrazione effettivi in ${WAS_HOME}/bin, modificare tali file e cambiare le righe relative alle opzioni Java™ per le prestazioni, in modo da impostare le impostazioni dell'heap su un valore adeguato al proprio sistema. Ad esempio:

  set PERFJAVAOPTION=-Xms256M -Xmx768M

  Ora puoi continuare la migrazione. Se hai deciso di eseguire i tre singoli processi, avvia il processo BBOWMPRE e, una volta completato con successo ( RC=0 ), esegui il processo BBOWMPOS. Se hai modificato la copia di sola lettura dei file di script di migrazione nel file system, puoi eseguire il processo appropriato " BBOWMG3* ".

• Il tempo massimo per l'esecuzione del processo batch è stato superato.

  Ogni installazione di z/OS è diversa per quanto riguarda le classi di lavoro e i limiti di tempo. Assicurati di aver specificato classi di lavoro e valori di timeout appropriati sulla tua scheda di lavoro.

• La migrazione di un gestore di distribuzione o di un server applicativo autonomo viene completata, ma nessuna applicazione viene installata.
  Il file di log potrebbe mostrare messaggi simili ai seguenti:

  MIGR0339I: L'applicazione WISO_wisoadmin_war.ear viene distribuita utilizzando il comando wsadmin.
  MIGR0241I: Output di wsadmin.
  Errore: impossibile allocare 268435456 byte per GC in j9vmem_reserve_memory.
  JVMJ9VM015W Errore di inizializzazione per la libreria j9gc23(2 ): Impossibile istanziare l'heap. 256M richiesto
  Impossibile creare la macchina virtuale Java.

  Il problema è che lo script WASPostUpgrade lanciato da bbomigrt2.sh non dispone di spazio di indirizzamento sufficiente per inizializzare la Java Virtual Machine ( JVM ). In genere, ciò indica che il processo generato è in esecuzione nello stesso spazio di indirizzamento dell' WASPostUpgrade JVM.

  È possibile utilizzare la variabile di ambiente _BPX_SHAREAS per indicare al processo sottostante se i processi generati devono condividere lo stesso spazio di indirizzamento del processo padre. Il valore predefinito (null) è NO, ma gli amministratori possono modificarlo in YES o MUST per ottenere un miglioramento delle prestazioni, poiché lo spazio di indirizzamento non deve essere copiato durante le azioni di fork o spawn.

  Se il sistema presenta il problema descritto qui, eseguire il processo di migrazione impostando esplicitamente la variabile di ambiente _BPX_SHAREAS su NO. È possibile impostare questa opzione nel profilo di sistema (/etc/profile) o nel profilo utente dell'utente che esegue il processo di migrazione. Utilizza la seguente voce per impostare questa variabile su NO:

  export _BPX_SHAREAS = NO 

  Una volta completata la migrazione, è possibile aggiornare il profilo per reimpostare _BPX_SHAREAS al suo valore originale.

• Si verificano errori durante l'avvio del server dopo la migrazione.

  Rivedi le istruzioni generate durante la creazione dei processi di migrazione. Verificare che le procedure JCL siano state copiate correttamente nella PROCLIB, che siano state create le definizioni dell' RACF® e e che le librerie Version 9.0 siano state autorizzate. Assicurati che il processo daemon associato alla tua cella sia al livello appropriato. Il processo daemon deve essere al livello più alto WebSphere Application Server per il livello di versione di z/OS di tutti i server che gestisce all'interno della cella.

  Dopo la migrazione a una cella versione 9.0 che contiene o interagisce con nodi versione 7.0 o successive che non sono alla versione 6.0.2.11 o successive, la funzione cluster potrebbe non funzionare correttamente. All'avvio dei server applicativi versione 7.0 o successive, potrebbero verificarsi i seguenti problemi:

  • È possibile che venga visualizzato un registro FFDC (First Failure Data Capture) che mostra un messaggio di errore " ClassNotFoundException " (Impossibile eseguire il controllo di integrità del file di log FFDC). Questa eccezione viene generata dal metodo RuleEtiquette.runRules e appare simile all'esempio seguente:

    Eccezione = java.lang.ClassNotFoundException
    Fonte = com.ibm.ws.cluster.selection.SelectionAdvisor.<init>
    probeid = 133
    Stack Dump = java.lang.ClassNotFoundException: rule.local.server
    java.net.URLClassLoader.findClass(URLClassLoader.java (Codice compilato))
    all'indirizzo com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader .java:106 )
    java.lang.ClassLoader.loadClass(ClassLoader.java (Codice compilato))
    java.lang.ClassLoader.loadClass(ClassLoader.java (Codice compilato))
    al metodo java.lang.Class.forName1(Native )
    java.lang.Class.forName(Class.java (Codice compilato))
    all'indirizzo com.ibm.ws.cluster.selection.rule.RuleEtiquette.runRules(RuleEtiquette .java:154 )
    all'indirizzo com.ibm.ws.cluster.selection.SelectionAdvisor.handleNotification(SelectionAdvisor .java:153 )
    all'indirizzo com.ibm.websphere.cluster.topography.DescriptionFactory$Notifier.run( DescriptionFactory.java:257 )
    all'indirizzo com.ibm.ws.util.ThreadPool$Worker.run( ThreadPool.java:1462 )

  • Potresti vedere un file java.io.IOException simile al seguente esempio:

    Eccezione = java.io.IOException
    Fonte = com.ibm.ws.cluster.topography.DescriptionManagerA. aggiornamento probeid = 362
    Stack Dump = java.io.IOException
    all'indirizzo com.ibm.ws.cluster.topography.ClusterDescriptionImpl.importFromStream(ClusterDescriptionImpl .java:916 )
    all'indirizzo com.ibm.ws.cluster.topography.DescriptionManagerA.update( DescriptionManagerA.java:360 )
    Causato da: java.io.EOFException
    java.io.DataInputStream.readFully(DataInputStream.java (Codice compilato))
    java.io.DataInputStream.readUTF(DataInputStream.java (Codice compilato))
    all'indirizzo com.ibm.ws.cluster.topography.KeyRepositoryImpl.importFromStream(KeyRepositoryImpl .java:193 )

  • Evitare problemi: dopo la migrazione a WebSphere Application Server Versione 9.0, il traffico del proxy SIP (Session Initiation Protocol) JSR116 potrebbe non funzionare correttamente, con timeout di ritrasmissione e messaggi di errore. Quando si verifica questo errore, potrebbe essere visualizzato il seguente messaggio di errore:

    TCP Inizializzazione del canale non riuscita.  Il binding del socket non è riuscito per l'host e la porta 5060.

    Per risolvere questo problema, è possibile eliminare la catena di trasporto UDP_SIP_PROXY_CHAIN nel file serverindex.xml a livello di nodo del server in cui si è verificato l'errore.

Dopo la migrazione, controlla attentamente l'output del processo e i file di log per verificare la presenza di eventuali errori.

Se si esegue la migrazione di un nodo alla versione 9.0 e poi si scopre che è necessario ripristinare la versione 7.0 o successive, leggere Ripristino degli ambienti.

Per informazioni aggiornate disponibili dal supporto IBM® sui problemi noti e la loro risoluzione, consultare la pagina di supporto IBM. IBM Il supporto tecnico dispone anche di documenti che possono aiutarti a risparmiare tempo nella raccolta delle informazioni necessarie per risolvere questo problema. Prima di aprire un PMR, leggi la pagina di supporto dell' IBM.

Le nuove porte registrate su un agente di nodo migrato alla versione 9.0 includono: 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. Queste porte non sono necessarie per l'agente di nodo e possono essere eliminate in tutta sicurezza.