Considerazioni sulla migrazione

Note relative ai sistemi operativi AIX®, HP-UX, IBM® i, Linux®, Solaris e Windows

• Prima di eseguire la migrazione, verificare gli elementi obsoleti descritti nella guida " WebSphere Application Server " (Versione 9.0 ).

  Per ulteriori informazioni, consultare la sezione Funzionalità obsolete, stabilizzate, sostituite e rimosse.

• Il gestore di alta disponibilità (HAM) e le funzionalità del gruppo centrale sono inclusi in WebSphere Application Server versione 7.0 o successive.

  Per informazioni sulla configurazione e sulla topologia dei gruppi principali che potrebbero influire sulla migrazione dalla versione 7.0 o successive alla versione 9.0, consultare la sezione "Considerazioni sulla migrazione dei gruppi principali".

  Nota: nella maggior parte dei casi, il numero consigliato di server in un gruppo principale non dovrebbe superare i 50. Viene visualizzato un messaggio di avviso quando gli strumenti di migrazione aggiungono un server che supera il limite massimo consigliato.
• Gli strumenti di migrazione della configurazione non convertono le applicazioni né le rendono compatibili con una nuova versione dell'SDK Java. Prima di passare a un nuovo SDK Java, utilizza lo strumento di verifica della compatibilità ( WebSphere Application Server Migration Toolkit ) per verificare se le tue applicazioni richiedono modifiche e, una volta apportati gli aggiornamenti necessari, esegui i test sulle applicazioni. Vedi la raccolta di informazioni sulla migrazione di WebSphere : Migrazione a Liberty.

  Per ulteriori informazioni, consultare la sezione "Migrazione delle API e delle specifiche".

• Gli strumenti di migrazione creano una directory di backup della migrazione contenente una copia di backup della configurazione della versione precedente, la cui dimensione corrisponde a quella della directory di configurazione e delle applicazioni del profilo precedente, più i file di tracciamento. Inoltre, il sistema deve disporre di spazio sufficiente per il profilo di destinazione, che dopo la migrazione avrà le stesse dimensioni del profilo di origine.

  Lo spazio di archiviazione richiesto dal sistema per la directory di backup dipende dall'ambiente in uso e dallo strumento di migrazione utilizzato.

  • Posizione: directory di backup specificate come parametri dei comandi WASPreUpgrade e WASPostUpgrade
  • Quantità: per ottenere una stima delle risorse di archiviazione necessarie quando si utilizzano questi comandi, sommare le seguenti quantità.
    • Dimensioni dei seguenti elementi per tutti i profili presenti nella configurazione precedente:
      • profile_root/installableApps directory
      • profile_root/installedApps directory
      • profile_root/config directory
      • profile_root/properties directory
      • Librerie condivise a cui fanno riferimento i libraries.xml file di configurazione
      • File RAR (Resource Adapter Archive) citati nei file resources.xml di configurazione
    • Se la tracciatura è abilitata, assicurati di disporre di spazio sufficiente per i file di tracciatura, la cui quantità dipende dalle dimensioni e dalla complessità della tua configurazione.
• Se si utilizzano archivi dati isolati — in particolare, archivi dati non condivisi come i log delle transazioni per i database SIB e Apache Derby — e si esegue la migrazione da una versione precedente, i database e i log delle transazioni esistenti vengono salvati all'esecuzione del WASPreUpgrade comando. Qualsiasi modifica apportata al database dopo l'esecuzione del WASPreUpgrade comando non verrà riportata nell'ambiente di migrazione.
  • Se in questi archivi di dati locali sono memorizzate informazioni di importanza critica, è necessario spegnere in modo sicuro tutti i server che interagiscono con tali archivi prima di procedere alla migrazione. Tali server dovrebbero rimanere disattivati fino a quando la migrazione non sarà stata completata con successo o annullata.
  • Se si effettuano più tentativi di migrazione, a causa di un rollback imprevisto o per applicare delle correzioni, eseguire nuovamente il WASPreUpgrade comando in modo che eventuali modifiche apportate ai repository di dati isolati vengano riportate nell'ambiente migrato.
  Una volta completata la migrazione o dopo aver ripristinato la versione precedente, è possibile riavviare i server che interagiscono con questi archivi dati isolati.
• Non eseguire la migrazione di un nodo con server attivi se il SIB utilizza l'opzione di archiviazione su file per uno o tutti i motori di messaggistica.
  • Il WASPreUpgrade comando genera un'eccezione di file bloccato quando si tenta di copiare i file memorizzati su un server delle applicazioni attivo.
  • Il WASPreUpgrade comando copia un file bloccato, il che potrebbe compromettere la coerenza dei dati.
  Un archivio dati per il motore di messaggistica è un'opzione valida per una migrazione a caldo; tuttavia, se è necessario utilizzare un archivio file, i server non devono essere in esecuzione.
• Se si tenta di eseguire il WASPreUpgrade comando per la migrazione dalla versione 6.1 mentre il nodo e il server delle applicazioni che ospitano l'archivio dei file SIB sono ancora in esecuzione, potrebbe comparire un errore simile al seguente:

  C:\was80A\bin>WASPreUpgrade c:\bkupWAS6.1.0.17June30B C:\was61B 
  MIGR0385I: Salvataggio del profilo " AppSrv01 " in corso. 
  MIGR0215W: La funzione di migrazione non riesce a copiare il file e ad aprire il file di destinazione 
  c:\bkupWAS6.1.0.17June30B\migrated\C_\FSJune19\Log. 
  MIGR0272E: la funzione di migrazione non riesce a portare a termine il comando. 

  Se poi si spegne il server delle applicazioni e il nodo, il WASPreUpgrade comando viene completato.
• Prima di eseguire la migrazione di un database di Apache Derby, assicurarsi che tutti i server applicativi che ospitano applicazioni che utilizzano il database Apache Derby siano stati chiusi. In caso contrario, la migrazione dell' Apache Derby e non va a buon fine.
• È necessario tenere presente le seguenti regole relative alla migrazione dei domini di sicurezza:
  • Se si esegue la migrazione di un Deployment Manager che dispone di un dominio di sicurezza con ambito a livello di cella, gli strumenti di migrazione eseguono le seguenti operazioni:
    • Se non esiste già, la migrazione crea un dominio nella nuova configurazione denominato PassThroughToGlobalSecurity.
    • La migrazione aggiunge una mappatura dei cluster alla nuova configurazione per tutti i cluster presenti nella vecchia configurazione.
      • Per i cluster che prima della migrazione esistevano solo nella configurazione del deployment manager in versione 9.0, le mappature relative a PassThroughToGlobalSecurity non vengono modificate.
        • Se prima della migrazione esistono mappature per i cluster "Version 9.0 ", queste rimangono attive anche dopo la migrazione.
        • Se prima della migrazione non esistono mappature per i cluster " 9.0 ", queste continueranno a non esistere anche dopo la migrazione.
      • Se un cluster è presente sia nella configurazione precedente che in quella di "Version- 9.0 " prima della migrazione, il cluster nella nuova configurazione viene aggiunto al dominio PassThroughToGlobalSecurity e si comporta come il cluster nella versione precedente.
    • La migrazione aggiunge una mappatura degli autobus per tutti gli autobus presenti in una configurazione " 6.1.x " della versione migrata.

      Le mappature degli autobus vengono aggiornate seguendo le stesse regole previste per la mappatura dei cluster.

    • I server amministrativi (Deployment Manager) non vengono aggiunti al dominio PassThroughToGlobalSecurity.
  • Se si esegue la migrazione di un nodo federato che dispone di un dominio di sicurezza con ambito a livello di cella, gli strumenti di migrazione eseguono le seguenti operazioni:
    • Se non esiste già, la migrazione crea un dominio nella nuova configurazione denominato PassThroughToGlobalSecurity.
    • La migrazione aggiunge una mappatura a livello di server al dominio PassThroughToGlobalSecurity per tutti i server non in cluster presenti nella configurazione del vecchio nodo.
      • I server presenti sul nodo oggetto della migrazione che fanno parte di un cluster non ricevono voci nel dominio PassThroughToGlobalSecurity, poiché la questione è stata risolta tramite una mappatura del cluster durante la migrazione con Deployment Manager.

        Se hai rimosso quella mappatura, la migrazione mantiene tale comportamento.

      • I server amministrativi (agenti di nodo) non vengono aggiunti al dominio PassThroughToGlobalSecurity.

  Per ulteriori informazioni, consultare la sezione "Domini di sicurezza in un ambiente con versioni miste" della pagina "Domini di sicurezza multipli ".

• La procedura per disattivare la richiesta delle credenziali è cambiata.

  Per disattivare la richiesta delle credenziali nella versione 9.0, configurare l' ipc.client.props per disattivare la richiesta delle credenziali prima di eseguire la migrazione dalla versione 6.1 alla versione 9.0.

• Durante la migrazione, alcuni metadati dell'applicazione potrebbero essere ripristinati ai valori predefiniti, causando un funzionamento dell'applicazione diverso da quello previsto.

  Se hai installato un'applicazione nel tuo vecchio ambiente con l'opzione "Usa metadati dai file binari" impostata su "true" e, durante tale installazione o un successivo aggiornamento dell'applicazione, hai apportato una modifica ai metadati dell'applicazione (come, ad esempio, i riferimenti alle risorse JNDI o le voci del database), tale modifica potrebbe andare persa durante la migrazione.

  Quando l'opzione "Usa metadati dai file binari" è impostata su "vero", il codice amministrativo aggiorna solo i metadati nel file EAR binario. Questa opzione non è supportata in una cella mista; pertanto, viene automaticamente impostata su "false" durante la migrazione. In questo caso, i metadati estesi presenti nelle directory di configurazione hanno la precedenza sui valori contenuti nel file EAR binario. Ciò fa sì che i valori presenti nel file EAR originale abbiano la precedenza su eventuali modifiche apportate dall'utente.

  Per risolvere il problema, eseguire una delle seguenti operazioni:

  • Prima di procedere alla migrazione, aggiorna le applicazioni nell'ambiente precedente e imposta l'opzione "Usa metadati dai file binari" su "false". Assicurati che le applicazioni funzionino correttamente con questa nuova impostazione, quindi esegui la migrazione.
  • Una volta completata la migrazione, aggiorna le applicazioni e correggi i metadati come necessario per garantire il corretto funzionamento delle applicazioni.
• Dopo aver utilizzato gli strumenti di migrazione per passare a una versione di WebSphere Application Server ( 9.0 ), potrebbe essere necessario eseguire alcune operazioni che non vengono effettuate automaticamente dagli strumenti di migrazione.
  • Controlla le impostazioni di sicurezza relative al protocollo LTPA (Lightweight Third-Party Authentication) eventualmente utilizzate in una versione di WebSphere Application Server pari a 7.0 o successive e verifica che le impostazioni di sicurezza relative alla versione 9.0 siano configurate correttamente.

    Per ulteriori informazioni, consultare la sezione "Autenticazione leggera di terze parti".

  • Controlla il WASPostUpgrade.log file nella logs directory per maggiori dettagli sugli oggetti JSP ( JavaServer s Pages) che gli strumenti di migrazione non hanno trasferito.

    Se la versione 9.0 non supporta un livello per il quale sono stati configurati oggetti JSP, gli strumenti di migrazione riconoscono tali oggetti nell'output e li registrano nel log.

  • Controlla le impostazioni della Java™ Virtual Machine ( JVM ) per verificare che la dimensione dell'heap sia di almeno 50, in modo da migliorare le prestazioni all'avvio.

    Per ulteriori informazioni, consultare le impostazioni della macchina virtuale Java.

    Se in precedenza hai utilizzato una dimensione dell'heap inferiore, puoi utilizzare la dimensione predefinita di 50.

  • Verifica i risultati della migrazione automatica del database Apache Derby e esegui manualmente la migrazione di eventuali database Apache Derby che non sono stati trasferiti automaticamente dagli strumenti.

    Per ulteriori informazioni, consultare la sezione "Migrazione dei database di Apache Derby ".