Risoluzione dei problemi di migrazione

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

  Ciò indica che è stato rilevato un errore di configurazione prima dell'avvio del processo di migrazione. Ciò può essere dovuto all'inserimento di dati errati durante la creazione dei processi di migrazione oppure a un problema di configurazione. Controlla il log per individuare l'errore rilevato, quindi correggilo ed esegui nuovamente l'operazione. I file di log si trovano in temporary_directory_location/nnnnn, dove temporary_directory_location è il valore specificato al momento della 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é riportato nel campo DDNAME di JESOUT delle fasi WROUT e WRERR del flusso di elaborazione batch.

• Il processo fallisce dopo la fase di verifica.

  Se il processo di migrazione non va a buon fine dopo la fase di verifica, è possibile rieseguirlo; tuttavia, è necessario prima eliminare la directory di configurazione WebSphere Application Server per z/OS® creata durante la fase CRHOME. V6_HomeDirCiò corrisponde alla directory home specificata al momento della creazione dei processi di migrazione ed è indicata anche nella variabile d'ambiente JCL (Job Control Language) relativa alla migrazione. Poiché la procedura di migrazione crea un nuovo file di configurazione per ogni nodo oggetto della migrazione, è molto semplice eliminare la configurazione e ricominciare da zero.

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

  Un nodo federato è il nodo più complesso da migrare, poiché si tratta essenzialmente di due migrazioni combinate 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 attivato le misure di sicurezza, è fondamentale seguire le istruzioni generate al momento della creazione dei processi di migrazione. Il processo di migrazione deve essere avviato utilizzando l'ID utente di un amministratore di WebSphere che sia stato configurato correttamente per stabilire connessioni sicure.

• Il processo si interrompe durante la fase di installazione dell'applicazione prevista dalla migrazione.

  Se si seleziona l'opzione che consente al processo di migrazione di installare le applicazioni aziendali presenti nella configurazione della versione 7.0 o successive nella nuova configurazione della versione 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 sottoposti a una verifica adeguata nei precedenti runtime di WebSphere Application Server. Il runtime dispone ora di un processo di convalida dell'installazione delle applicazioni migliorato e non consentirà l'installazione di questi file EAR non conformi. Ciò comporta un errore durante la fase di installazione dell'applicazione WASPostUpgrade e genera un messaggio di errore di tipo E. Si tratta di un errore di migrazione irreversibile.

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

  • Risolvi i problemi nelle applicazioni della versione 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 operazioni 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 installarle manualmente nella nuova configurazione di Version 9.0, utilizzando la console di amministrazione 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 al momento della creazione dei processi di migrazione (il valore predefinito è /tmp/migrate) e nnnnn è un numero univoco generato durante la creazione dei processi di migrazione. Di norma, lo spazio richiesto dai log di migrazione è minimo. Tuttavia, se si attiva il tracciamento, i file di log potrebbero diventare molto grandi. La prassi migliore consiste nell'abilitare la tracciatura solo dopo che sono stati individuati dei problemi. Se è necessario il tracciamento, cerca di abilitare solo il tracciamento relativo alla fase del processo che stai sottoponendo a debug. Ciò contribuisce a ridurre l'ingombro.

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

  • zmbEnablePreUpgradeTrace
  • zmbEnablePostUpgradeTrace
  • zmbEnableProfileTrace
  • zmbEnableScriptingTrace

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

  È inoltre possibile modificare le variabili nel Job Control Language (JCL) della migrazione, assegnando loro i valori appropriati nel membro JCL BB OWMxEV all'interno del set di dati DATA creato quando si utilizza lo strumento di gestione delle migrazioni di 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 disattivare la tracciatura) e 4 (per attivare la 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 impostazione può essere modificata al momento della creazione dei processi di migrazione. A seconda delle dimensioni del nodo oggetto della migrazione, questo backup potrebbe essere di grandi dimensioni. Se il tuo spazio temporaneo non è sufficiente, dovrai spostare questo backup.

• Si verificano errori di memoria insufficiente.
  Per ottimizzare l'utilizzo della memoria, procedere come segue:

  1. Modifica il file di lavoro per impedire la condivisione dello spazio di applicazione e aumenta i valori minimo e massimo dell'heap dell' JVM.
     Di seguito è riportato un esempio di come modificare il processo " BBOWM3D " per una migrazione tramite Deployment Manager, in modo che utilizzi fino a 768 MB di heap, ovvero più del valore predefinito di 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. Modifica lo script di migrazione corrispondente.

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

     Se non è possibile modificare il sistema driver in sola lettura, utilizzare i tre processi di migrazione anziché un unico processo, 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 singoli si escludono a vicenda: è possibile eseguire o il singolo processo « BBOWMG3* » oppure i tre processi singoli, ma non entrambi.

  Il processo *PRO esegue l'installazione del prodotto e la creazione del profilo. Una volta completata con successo questa operazione, avrai accesso al profilo "Version 9.0 " che verrà utilizzato per la migrazione. Accedi alla directory di installazione di Version 9.0 e e vai alla posizione corrispondente ${WAS_HOME}/bin . Troverete gli WASPreUpgrade.sh script e WASPostUpgrade.sh in questa posizione. Se si tratta di collegamenti simbolici che rimandano al file system di sola lettura, rimuovere i collegamenti simbolici e copiare i file originali dal file system di sola lettura in questa posizione. ${WAS_HOME}/binUna volta ottenuti i file di script di migrazione, modificali e modifica le righe relative alle opzioni di prestazione Java™ per impostare le configurazioni dell'heap su un valore adeguato al tuo sistema. Ad esempio:

  set PERFJAVAOPTION=-Xms256M -Xmx768M

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

• Il tempo previsto per il 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 adeguati nella scheda di lavoro.

• La migrazione di un deployment manager o di un server delle applicazioni autonomo viene completata, ma non viene installata alcuna applicazione.
  Il file di log potrebbe contenere messaggi simili ai seguenti:

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

  Il problema è che lo script WASPostUpgrade, avviato 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 viene eseguito nello stesso spazio di indirizzamento dell' WASPostUpgrade JVM.

  È possibile utilizzare la variabile d'ambiente _BPX_SHAREAS per indicare al processo sottostante se i processi generati debbano condividere o meno 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é in questo modo non è necessario copiare lo spazio di indirizzamento durante le operazioni di fork o spawn.

  Se il sistema presenta il problema qui descritto, eseguire il processo di migrazione impostando esplicitamente la variabile d'ambiente _BPX_SHAREAS su NO. È possibile configurare questa opzione sia nel profilo di sistema (/etc/profile) sia 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 l'operazione di migrazione, è possibile aggiornare il profilo per reimpostare _BPX_SHAREAS al suo valore originale.

• Dopo la migrazione si verificano degli errori durante l'avvio del server.

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

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

  • Potresti visualizzare un log di acquisizione dati del primo errore (FFDC) che riporta un messaggio di errore del tipo " ClassNotFoundException ". Questa eccezione viene generata dal metodo ` RuleEtiquette.runRules ` e ha un aspetto simile a quello dell'esempio seguente:

    Eccezione = java.lang.ClassNotFoundException
    Fonte = com.ibm.ws.cluster.selection.SelectionAdvisor.<init>
    ID sonda = 133
    Dump dello stack = java.lang.ClassNotFoundException: rule.local.server
    all'indirizzo java.net.URLClassLoader.findClass(URLClassLoader.java(Codice compilato))
    all'indirizzo com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader .java:106 )
    all'indirizzo java.lang.ClassLoader.loadClass(ClassLoader.java(Codice compilato))
    all'indirizzo java.lang.ClassLoader.loadClass(ClassLoader.java(Codice compilato))
    (Metodo " java.lang.Class.forName1(Native ")
    all'indirizzo 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' java.io.IOException e simile a quella riportata nell'esempio seguente:

    Eccezione = java.io.IOException
    Fonte = com.ibm.ws.cluster.topography.DescriptionManagerA. aggiorna probeid = 362
    Dump dello stack = 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 )
    Fonte: java.io.EOFException
    all'indirizzo java.io.DataInputStream.readFully(DataInputStream.java(Codice compilato))
    all'indirizzo java.io.DataInputStream.readUTF(DataInputStream.java(Codice compilato))
    all'indirizzo com.ibm.ws.cluster.topography.KeyRepositoryImpl.importFromStream(KeyRepositoryImpl .java:193 )

  • Prevenire i problemi: dopo la migrazione a una versione di WebSphere Application Server 9.0, il traffico del proxy SIP (Session Initiation Protocol) JSR116 potrebbe non funzionare correttamente, causando 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.  Impossibile stabilire la connessione per l'host e la porta 5060.

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

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

Se esegui la migrazione di un nodo alla versione 9.0 e poi ti accorgi di dover tornare alla versione 7.0 o successive, consulta la sezione "Rollback degli ambienti".

Per informazioni aggiornate fornite dal supporto di IBM® sui problemi noti e sulla loro risoluzione, consultare la pagina di supporto all'indirizzo IBM. IBM Il servizio di assistenza mette inoltre a disposizione dei documenti che ti consentono di risparmiare tempo nella raccolta delle informazioni necessarie per risolvere il problema. Prima di aprire una richiesta di assistenza (PMR), consulta la pagina di assistenza " 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 all'agente del nodo e possono essere eliminate in tutta sicurezza.