Condividi tramite

Eseguire la migrazione di applicazioni WebSphere ad Azure Macchine virtuali

  • Articolo

Questa guida descrive gli aspetti da tenere presenti quando si vuole eseguire la migrazione di un'applicazione tradizionale di WebSphere Application Server (WAS) esistente da eseguire in Azure Macchine virtuali. Per una panoramica delle soluzioni tradizionali WAS disponibili in Azure Marketplace, vedere Quali sono le soluzioni per eseguire la famiglia di prodotti IBM WebSphere in Azure?

Pre-migrazione

Per garantire una corretta migrazione, prima di iniziare completare i passaggi di valutazione e inventario descritti nelle sezioni seguenti.

Definire cosa si intende per "migrazione completata"

Questa guida e le offerte di Azure Marketplace corrispondenti rappresentano un punto di partenza per accelerare la migrazione dei carichi di lavoro tradizionali WAS ad Azure. È importante definire l'ambito dell'attività di migrazione. Ad esempio, si sta eseguendo un trasferimento "lift-and-shift" rigoroso dall'infrastruttura esistente alle macchine virtuali di Azure? In caso affermativo, si potrebbe essere tentati di adottare un modello di migrazione "lift-and-improve".

È preferibile attenersi il più strettamente possibile all'approccio "lift-and-shift", tenendo conto delle necessarie modifiche descritte in questa guida. Definire cosa si intende per "migrazione completata", in modo da sapere quando viene raggiunto questo traguardo. Dopo aver raggiunto il "completamento della migrazione", è possibile creare uno snapshot del Macchine virtuali come descritto in Creare uno snapshot di un disco rigido virtuale. Dopo aver verificato che è possibile eseguire correttamente il ripristino dallo snapshot, è possibile eseguire i miglioramenti senza temere di perdere lo stato di avanzamento della migrazione raggiunto finora.

Assicurarsi che la destinazione sia la destinazione appropriata per il lavoro di migrazione

Il primo passaggio di una migrazione corretta di un'applicazione WAS ad Azure consiste nel selezionare la destinazione di migrazione più appropriata.

WAS tradizionale funziona bene in Azure Macchine virtuali. La destinazione della macchina virtuale (VM) è la scelta più semplice, perché è molto simile a una distribuzione locale. L'esperienza amministrativa e di distribuzione per le macchine virtuali è analoga a quella in locale.

Un'altra opzione consiste nel eseguire la migrazione ai contenitori convertendo il carico di lavoro tradizionale WAS in contenitori dell'applicazione. È possibile eseguire la destinazione del contenitore in servizio Azure Kubernetes (AKS) e Azure Red Hat OpenShift. Il compromesso per questa facilità è il costo economico.

In generale, il costo al minuto per una soluzione basata su vm è più elevato rispetto ai contenitori. Anche se una soluzione basata su contenitori costa meno per l'esecuzione, è necessario vincolare l'applicazione in base ai requisiti della piattaforma di orchestrazione dei contenitori.

Se la riduzione al minimo delle modifiche è il fattore più importante per il lavoro di migrazione, prendere in considerazione una migrazione basata su vm. In questo caso, vedere Eseguire la migrazione di applicazioni WebSphere ad Azure Macchine virtuali.

Se è possibile tollerare la conversione dell'applicazione in modo che venga eseguita all'interno di contenitori per ridurre i costi di runtime, prendere in considerazione una migrazione basata sul servizio Azure Kubernetes o basata su Azure Red Hat OpenShift.

Per la migrazione basata sul servizio Azure Kubernetes, è possibile iniziare a usare il livello Gratuito. Ottenere la gestione gratuita dei cluster e pagare solo le macchine virtuali, l'archiviazione associata e le risorse di rete utilizzate. In questo caso, vedere Eseguire la migrazione di applicazioni WebSphere a servizio Azure Kubernetes.

Per la migrazione basata su Azure Red Hat OpenShift, oltre ai costi di calcolo e infrastruttura, i nodi dell'applicazione hanno un altro costo per il componente licenze OpenShift. Questo costo viene fatturato in base al numero di nodi dell'applicazione e al tipo di istanza. Usare i prezzi on demand o le istanze riservate, a seconda delle esigenze del carico di lavoro e dell'azienda. In questo caso, vedere Eseguire la migrazione di applicazioni WebSphere ad Azure Red Hat OpenShift.

Le guide pratiche nella documentazione di Azure Red Hat OpenShift illustrano alcuni aspetti rilevanti per la migrazione. Per l'elenco completo delle guide pratiche, vedere la documentazione di Azure Red Hat OpenShift.

Determinare se le offerte predefinite di Azure Marketplace sono un buon punto di partenza

IBM e Microsoft hanno collaborato per portare un set di modelli di soluzioni di Azure in Azure Marketplace per offrire un punto di partenza solido per la migrazione ad Azure. Per l'elenco delle offerte, vedere Eseguire la famiglia di prodotti WebSphere e Liberty in Microsoft Azure e quindi scegliere quella più adatta alla distribuzione esistente. È possibile visualizzare l'elenco delle offerte nell'articolo Di panoramica Quali sono le soluzioni per eseguire la famiglia di prodotti IBM WebSphere in Azure?

Se nessuna delle offerte esistenti è un buon punto di partenza, è necessario riprodurre la distribuzione con le risorse della macchina virtuale di Azure. Per istruzioni dettagliate, vedere Esercitazione: Installare manualmente IBM WebSphere Application Server Network Deployment tradizionale in Azure Macchine virtuali. Per altre informazioni, vedere Che cos'è IaaS?

Determinare se la versione tradizionale WAS è compatibile

La versione tradizionale DI WAS esistente deve essere compatibile con la versione nelle offerte IaaS. Le informazioni sulla versione sono disponibili nella pagina di panoramica di IBM WebSphere Application Server Single Instance on Azure VM (Istanza singola di IBM WebSphere Application Server) in macchine virtuali di Azure e IBM WebSphere Application Server Cluster in macchine virtuali di Azure. Se la versione tradizionale WAS esistente non è compatibile con tale versione, è necessario riprodurre la distribuzione con le risorse IaaS di Azure. Per altre informazioni, vedere Che cos'è IaaS?

Inventario della capacità dei server

Documentare l'hardware (memoria, CPU, disco) dei server di produzione correnti oltre al numero medio e massimo di richieste e all'utilizzo delle risorse. La scelta delle dimensioni delle VM si deve basare su queste informazioni. Per altre informazioni, vedere Dimensioni dei servizi cloud.

Inventario di tutti i segreti

Prima della comparsa di tecnologie di tipo "configurazione come servizio", ad esempio Azure Key Vault, non esisteva un concetto ben definito di "segreti". Era invece disponibile un set disparato di impostazioni di configurazione assimilabili a quello che ora chiamiamo "segreti". Con i server app come WAS, questi segreti si trovano in molti archivi di configurazione e file di configurazione diversi. Controllare tutte le proprietà e i file di configurazione nei server di produzione per verificare la presenza di segreti e password. I file di configurazione contenenti password o credenziali possono trovarsi anche all'interno dell'applicazione. WAS archivia i dati di configurazione in diversi documenti in una gerarchia a catena di directory. La maggior parte dei documenti di configurazione include contenuto XML. Per altre informazioni, vedere Documenti di configurazione e Concetti di base di Azure Key Vault.

Inventario di tutti i certificati

Documentare tutti i certificati usati per gli endpoint SSL pubblici. È possibile visualizzare tutti i certificati nei server di produzione eseguendo il comando seguente:

keytool -list -v -keystore <path to keystore>

Per altre informazioni, vedere Gestione dei certificati dei documenti IBM in SSL

Verificare che la versione di Java supportata funzioni correttamente

L'uso di WAS in Azure Macchine virtuali richiede una versione specifica di Java, quindi è necessario verificare che l'applicazione venga eseguita correttamente usando tale versione supportata.

IBM Java 8 include la distribuzione WAS9. È consigliabile usare java JRE fornito da IBM. Per altre informazioni, vedere Java SE 8 in WebSphere Application Server tradizionale V9.

Se si vuole passare a un SDK Java diverso, seguire il documento IBM Switching the Java SDK in WebSphere Application Server (Passaggio a Java SDK in WebSphere Application Server).

Inventario delle risorse JNDI

Creare un inventario di tutte le risorse JNDI. Ad esempio, le origini dati, come i database, possono avere un nome JNDI associato che consente a JPA di associare correttamente le istanze di EntityManager a un database specifico. Per altre informazioni sulle risorse e i database JNDI, vedere WebSphere Data Sources (Origini dati WebSphere) nella documentazione di IBM. Altre risorse correlate a JNDI, ad esempio i broker di messaggi JMS, possono richiedere la migrazione o la riconfigurazione. Per altre informazioni sulla configurazione di JMS, vedere Uso delle risorse JMS.

Esaminare la configurazione del profilo

L'unità di configurazione principale in WAS è il profilo. Di conseguenza, il file di resources.xml contiene un'ampia gamma di configurazioni da considerare con attenzione per la migrazione. Il file include riferimenti a più file XML archiviati nelle sottodirectory. IBM consiglia di usare normalmente IBM Console per configurare gli oggetti e i servizi gestibili di WAS e consentire a WAS di gestire la cartella profiles/profile-name . Per altre informazioni, vedere Gestione dei profili nei sistemi operativi IBM i e distribuiti.

All'interno dell'applicazione

Esaminare il file deployment.xml e/o il file WEB-INF/web.xml .

Determinare se viene usata la replica delle sessioni

Se l'applicazione si basa sulla replica di sessione, sono disponibili le opzioni seguenti:

  • Per le sessioni HTTP, in base al livello di gestione delle sessioni, è possibile usare la memoria o un database per raccogliere i dati della sessione.
  • Per le sessioni distribuite, è possibile salvare le sessioni in un database usando la persistenza della sessione del database.
  • Per La cache dinamica è possibile gestire i dati della sessione nella replica da memoria a memoria o in un database.
  • Effettuare il refactoring dell'applicazione per l'uso di un database per la gestione delle sessioni.
  • Effettuare il refactoring dell'applicazione per esternalizzare la sessione nel servizio Azure Redis. Per altre informazioni, vedere Azure Cache for Redis.

Per tutte queste opzioni, è consigliabile gestire il modo in cui WAS esegue la replica dello stato della sessione HTTP. Per altre informazioni, vedere Amministrazione dei fagioli di sessione nella documentazione di IBM.

Documentare le origini dati

Se l'applicazione usa qualsiasi database, è necessario acquisire le informazioni seguenti:

  • Qual è il nome dell'origine dati?
  • Qual è la configurazione del pool di connessioni?
  • Dove è possibile trovare il file JAR del driver JDBC?

Per altre informazioni sui driver JDBC in WAS, vedere Uso dei driver JDBC con WebSphere Application Server.

Determinare se WAS è stato personalizzato

Determinare quali delle seguenti personalizzazioni sono state apportate e acquisire informazioni sulle attività eseguite.

  • Gli script di avvio sono stati cambiati? Tali script includono wsadmin, AdminControl, AdminConfig, AdminApp e AdminTask.
  • Sono stati passati parametri specifici alla JVM?
  • Sono stati aggiunti JAR al classpath del server?
  • Sono state usate funzionalità a livello di sistema operativo, ad esempio systemd per causare l'avvio automatico dei componenti WAS dopo il riavvio del server?

È necessario tenere conto delle considerazioni sulla migrazione a seconda delle risposte a queste domande.

Determinare se è necessaria una connessione all'ambiente locale

Se l'applicazione deve accedere ai servizi locali, è necessario effettuare il provisioning di uno dei servizi di connettività di Azure. Per altre informazioni, vedere Connettere una rete locale ad Azure. In alternativa, è necessario effettuare il refactoring dell'applicazione per usare le API disponibili pubblicamente esposte dalle risorse locali.

Determinare se sono in uso code o argomenti di JMS (Java Message Service)

Se l'applicazione usa code O argomenti JMS, è necessario eseguirne la migrazione a un server JMS ospitato esternamente. Una strategia per coloro che usano JMS consiste nell'usare bus di servizio di Azure e advanced Message Queuing Protocol. Per altre informazioni, vedere Usare Java Message Service 1.1 con bus di servizio di Azure standard e AMQP 1.0.

Se sono stati configurati archivi permanenti JMS, è necessario acquisire la configurazione e applicarla dopo la migrazione.

Se si usa IBM MQ, è possibile eseguire la migrazione di questo software ad Azure Macchine virtuali e usarlo così come sono.

Microsoft offre una soluzione per integrare IBM MQ con App per la logica. Per altre informazioni, vedere Connettersi a un server IBM MQ da un flusso di lavoro in App per la logica di Azure.

Determinare se si usano librerie Java EE condivise personalizzate

Se si usano librerie Java EE condivise, sono disponibili due opzioni:

  • Effettuare il refactoring del codice dell'applicazione per rimuovere tutte le dipendenze dalle librerie e incorporare la funzionalità direttamente nell'applicazione.
  • Aggiungere le librerie al classpath del server.

Determinare se vengono usati bundle OSGi

Se sono stati usati bundle OSGi aggiunti a WAS, è necessario aggiungere i file JAR equivalenti direttamente all'applicazione Web.

Determinare se l'applicazione contiene codice specifico del sistema operativo

Se l'applicazione contiene codice con dipendenze dal sistema operativo host, è necessario effettuare il refactoring per rimuovere tali dipendenze. Ad esempio, potrebbe essere necessario sostituire qualsiasi uso di o \ nei percorsi del / file system con File.Separator o Paths.get se l'applicazione è in esecuzione in Windows.

Determinare se IBM Integration Bus è in uso

Se l'applicazione usa IBM Integration Bus, è necessario acquisire la configurazione di IBM Integration Bus. Per altre informazioni, vedere la documentazione di IBM Integration Bus.

Determinare se l'applicazione è costituita da più WAR

Se l'applicazione è costituita da più WAR, è consigliabile considerarli come applicazioni distinte e seguire i rispettivi argomenti di questa guida.

Determinare se l'applicazione è assemblata come EAR

Se l'applicazione viene inserita in un pacchetto come file EAR, assicurarsi di esaminare i file application.xml, ibm-application-bnd.xmi e ibm-application-ext.xmi e acquisire le configurazioni. Per altre informazioni, vedere Building the enterprise archive (EAR) package on WebSphere (Building the enterprise archive package on WebSphere).

Identificare tutti i processi e daemon esterni in esecuzione nei server di produzione

Se sono in esecuzione processi all'esterno del server applicazioni, ad esempio daemon di monitoraggio, sarà necessario eliminarli o trasferirli altrove.

Determinare se e come viene usato il file system

I file system delle VM funzionano allo stesso modo di quelli locali in termini di persistenza, avvio e arresto. Ciononostante, è importante tenere presenti i requisiti dei file system e assicurarsi che le VM abbiano dimensioni dello spazio di archiviazione e prestazioni adeguate.

Contenuto statico di sola lettura

Se l'applicazione attualmente distribuisce contenuto statico, è necessario modificarne la posizione. Si può scegliere di spostare il contenuto statico in Archiviazione BLOB di Azure e di aggiungere la rete di distribuzione dei contenuti di Azure per accelerare i download a livello globale. Per altre informazioni, vedere Hosting di siti Web statici in Archiviazione di Azure e Avvio rapido: Integrare un account di archiviazione di Azure con Rete CDN di Azure.

Contenuto statico pubblicato dinamicamente

Se l'applicazione consente contenuto statico caricato/prodotto dall'applicazione ma non modificabile dopo la creazione, è possibile usare Archiviazione BLOB di Azure e la rete di distribuzione dei contenuti di Azure, come descritto sopra, con una funzione di Azure per gestire i caricamenti e l'aggiornamento della rete CDN. Nell'articolo Caricamento e precaricamento nella rete CDN di contenuto statico con Funzioni di Azure è riportata un'implementazione di esempio che è possibile usare.

Determinare la topologia di rete

Il set corrente di offerte di Azure Marketplace è un punto di partenza per la migrazione. Se l'offerta non copre gli aspetti dell'architettura di cui è necessario eseguire la migrazione, è necessario acquisire la topologia di rete della distribuzione esistente. È quindi necessario riprodurre la topologia di rete in Azure, anche dopo aver alzato l'offerta di base con uno dei modelli di soluzione.

La topologia di rete è un argomento generale, ma i riferimenti seguenti possono dare una direzione alle attività di migrazione:

  • Il riferimento seguente enumera gli argomenti di alto livello relativi alla migrazione della topologia di rete in Azure: topologie di distribuzione di rete del server applicazioni WebSphere.
  • Poiché le origini dati sono server separati in un sistema WAS, è necessario considerarle come parte dell'analisi della topologia di rete. Per altre informazioni, vedere Origini dati del server applicazioni WebSphere.
  • Anche le origini di messaggistica sono server distinti. Per altre informazioni, vedere Topologie di rete: Interoperabilità tramite il provider di messaggistica WebSphere MQ.
  • Il bilanciamento del carico è un requisito fondamentale. Il riferimento seguente illustra il lato WAS del bilanciamento del carico: Clustering con bilanciamento del carico della distribuzione di rete webSphere Application Server.

Account per l'uso di adattatori JCA e adattatori di risorse

Se l'applicazione esistente usa adattatori JCA o altri adattatori di risorse per connettersi ad altri sistemi aziendali, assicurarsi di applicare la configurazione per questi artefatti all'interfaccia WAS in esecuzione in Azure Macchine virtuali. Per altre informazioni, vedere Adapter di risorse relazionali e JCA nella documentazione di IBM.

Includere l'autenticazione e l'autorizzazione

La maggior parte delle applicazioni include una forma di autenticazione e autorizzazione. Se si usa OpenID per l'autenticazione, è possibile configurare l'autenticazione openID connect con Microsoft Entra ID. Per altre informazioni, vedere Autenticazione di OpenID Connect con Microsoft Entra ID.

Determinare se viene usato il clustering WAS

Molto probabilmente, l'applicazione è stata distribuita in più server WAS per ottenere una disponibilità elevata. È possibile eseguire la migrazione di questi cluster direttamente dall'installazione locale a WAS in esecuzione in Azure Macchine virtuali. Per altre informazioni, vedere WebSphere Application Server Network Deployment nella documentazione di IBM.

Includere i requisiti per il bilanciamento del carico

Il bilanciamento del carico è una parte essenziale della migrazione del cluster WAS ad Azure. La soluzione più semplice consiste nell'usare il supporto predefinito per app Azure lication Gateway o IBM HTTP Server fornito nell'offerta Azure Marketplace per IBM WebSphere Application Server Cluster.

Per un riepilogo delle funzionalità di app Azure lication Gateway rispetto ad altre soluzioni di bilanciamento del carico di Azure, vedere Opzioni di bilanciamento del carico.

Determinare se viene usata la funzionalità Java EE Application Client

Se l'applicazione usa la funzionalità Java EE Application Client, dovrebbe continuare a funzionare inalterata dopo la migrazione alle macchine virtuali di Azure. Per altre informazioni, vedere Uso dei moduli di Java EE Application Client.

Migrazione

Selezionare un'offerta di Macchine virtuali WAS tradizionale in Azure

Le offerte seguenti sono disponibili per WAS in Azure Macchine virtuali.

Durante la distribuzione di un'offerta, viene chiesto di scegliere le dimensioni della macchina virtuale per i nodi WAS. Nella scelta delle dimensioni delle VM, è importante considerare tutti gli aspetti, ossia memoria, processore e disco. Per altre informazioni, vedere Dimensioni per Servizi cloud (versione classica).

Effettuare il provisioning dell'offerta

Dopo aver selezionato l'offerta da cui iniziare, effettuare il provisioning dell'offerta seguendo le istruzioni riportate in Distribuire il cluster server applicazioni WebSphere (tradizionale) in Azure Macchine virtuali.

Eseguire la migrazione dei profili

Dopo aver effettuato il provisioning dell'offerta, è possibile esaminare la configurazione del profilo. Per altre informazioni, vedere Concetti relativi ai profili nella documentazione di IBM.

Connettere i database

Dopo aver eseguito la migrazione dei profili, è possibile connettere i database seguendo le istruzioni riportate in Configurazione dell'origine dati del server applicazioni WebSphere nella documentazione di IBM.

Tenere conto degli archivi chiavi

È necessario tenere conto della migrazione di eventuali archivi chiavi SSL usati dall'applicazione. Per altre informazioni, vedere Configurazioni dell'archivio chiavi per SSL nella documentazione di IBM.

Connettere le origini JMS

Dopo aver connesso i database, è possibile configurare JMS seguendo le istruzioni riportate in Configurazione di JMS in IBM WebSphere Application Server nella documentazione di IBM.

Includere l'autenticazione e l'autorizzazione

La maggior parte delle applicazioni include una forma di autenticazione e autorizzazione. Se si usa OpenID per l'autenticazione, è possibile configurare l'autenticazione openID connect con Microsoft Entra ID. Per altre informazioni, vedere Autenticazione di OpenID Connect con Microsoft Entra ID.

Tenere conto della registrazione

È possibile configurare Elastic Stack seguendo le istruzioni riportate in Analisi dei log del server applicazioni WebSphere con Elastic Stack nella documentazione di IBM. Azure offre supporto per Elastic. Per altre informazioni, vedere Che cos'è l'integrazione elastica con Azure? È possibile combinare le conoscenze in queste due risorse per ottenere una soluzione di registrazione ottimizzata per Azure per WAS nelle macchine virtuali.

Migrazione delle applicazioni

Le tecniche usate per distribuire le applicazioni dai computer di sviluppo ai server di test, staging e produzione variano enormemente da un caso all'altro. In alcuni casi, esiste una piattaforma CI/CD altamente evoluta che comporta la distribuzione delle applicazioni nel server applicazioni WebSphere. In altri casi, il processo può essere maggiormente manuale. Uno dei vantaggi offerti dall'uso di Azure Macchine virtuali per eseguire la migrazione di applicazioni tradizionali WAS nel cloud è che i processi esistenti continuano a funzionare.

È necessario configurare il gruppo di sicurezza di rete di cui viene effettuato il provisioning dell'offerta per consentire l'accesso dalla pipeline CI/CD o dal sistema di distribuzione manuale. Per altre informazioni, vedere Gruppi di sicurezza di rete.

Test

Per accedere ai nuovi server in esecuzione in Azure, è necessario configurare tutti i test in contenitori rispetto alle applicazioni. Come per i problemi di CI/CD, è necessario assicurarsi che le regole di sicurezza di rete necessarie consentano ai test di accedere alle applicazioni distribuite in Azure. Per altre informazioni, vedere Gruppi di sicurezza di rete.

Post-migrazione

Una volta raggiunti gli obiettivi di migrazione definiti nel passaggio di pre-migrazione, eseguire alcuni test di accettazione end-to-end per verificare che tutto funzioni come previsto. Per indicazioni su alcuni potenziali miglioramenti post-migrazione, vedere le raccomandazioni seguenti: