Eseguire la migrazione di applicazioni WebSphere ad Azure Macchine virtuali

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 WAS tradizionali disponibili in Azure Marketplace, vedi Quali sono le soluzioni per eseguire la famiglia di prodotti WebSphere di IBM in Azure?

Prima della 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 tal caso, potresti essere tentato di introdurre un approccio di "lift and improve" durante la migrazione.

È 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. Una volta completata la migrazione, è possibile creare uno snapshot delle 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.

Assicuratevi che la destinazione sia quella appropriata per il processo 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 sulle Macchine virtuali di Azure. 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 il contenitore di destinazione 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, vedi Eseguire la migrazione delle applicazioni WebSphere in Macchine virtuali di Azure.

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 su AKS, puoi 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, vedi Eseguire la migrazione delle applicazioni WebSphere in 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. Utilizzare le tariffe on demand o le istanze riservate, in base a quale opzione soddisfa meglio le esigenze del carico di lavoro e dell'azienda. In questo caso, vedi Migrare le applicazioni WebSphere in 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 dettagliate, consulta 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, consultare Eseguire i prodotti della famiglia WebSphere e Liberty su Microsoft Azure, quindi scegliere quella che più si avvicina alla distribuzione attuale. È 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. È possibile trovare la guida dettagliata in Esercitazione: Installare manualmente IBM WebSphere Application Server Network Deployment tradizionale in Macchine virtuali di Azure. Per altre informazioni, vedi 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. È possibile trovare le informazioni sulla versione nella pagina Panoramica di IBM WebSphere Application Server Single Instance on Azure VM e IBM WebSphere Application Server Cluster on Azure VMs. Se la versione tradizionale WAS esistente non è compatibile con tale versione, è necessario riprodurre la distribuzione con le risorse IaaS di Azure. Per altre informazioni, vedi 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 per Cloud Services.

Esegui l'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 ulteriori 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 ulteriori informazioni, vedere il documento IBM Gestione dei certificati 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 ulteriori informazioni, consultare Java SE 8 in WebSphere Application Server traditional V9.

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

Inventario delle risorse JNDI

Creare un inventario di tutte le risorse JNDI. Ad esempio, le origini dati, quali i database, possono avere un nome JNDI associato che consente a JPA di associare correttamente le istanze di a un database specifico. Per ulteriori informazioni sulle risorse JNDI e sui database, vedere WebSphere Data Sources nella documentazione IBM. Altre risorse correlate a JNDI, ad esempio i broker di messaggi JMS, possono richiedere la migrazione o la riconfigurazione. Per ulteriori informazioni sulla configurazione di JMS, consultare Utilizzo 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 la IBM Console per configurare gli oggetti gestiti e i servizi di WAS e consentire a WAS di gestire la cartella profiles/profile-name. Per ulteriori informazioni, consultare Gestione dei profili su sistemi operativi distribuiti e IBM i.

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 della sessione, è possibile usare la memoria o un database per memorizzare i dati della sessione.
• Per le sessioni distribuite, è possibile salvare le sessioni in un database utilizzando la persistenza delle sessioni nel database.
• Per Dynamic cache, è possibile gestire i dati di sessione tramite 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 cache di Azure per Redis.

Per tutte queste opzioni, è consigliabile gestire il modo in cui WAS esegue la replica dello stato della sessione HTTP. Per ulteriori informazioni, consulta Amministrazione dei bean di sessione nella documentazione 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 ulteriori informazioni sui driver JDBC in WAS, consultare 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 utilizzate funzionalità a livello di sistema operativo, come , per fare in modo che i componenti WAS si avviino automaticamente 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 topic JMS, è necessario migrarle verso 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, vedi 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, vedi 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 occorrenza di o nei percorsi del file system con o se l'applicazione è in esecuzione su Windows.

Determinare se IBM Integration Bus è in uso

Se l'applicazione usa IBM Integration Bus, è necessario acquisire la configurazione di IBM Integration Bus. Per ulteriori informazioni, consultare 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.

Verifica se l'applicazione è confezionata come un EAR

Se l'applicazione è pacchettizzata come file EAR, assicurarsi di esaminare i file application.xml, ibm-application-bnd.xmi e ibm-application-ext.xmi e di rilevarne le configurazioni. Per ulteriori informazioni, vedere Creazione del pacchetto Enterprise Archive (EAR) in 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 serve contenuto statico, è necessario un percorso alternativo. È consigliabile spostare contenuto statico in Archiviazione BLOB di Azure e aggiungere Frontdoor di Azure per i download rapidi a livello globale. Per altre informazioni, vedere l'hosting di siti web statici su Archiviazione di Azure e Integrare un account di archiviazione di Azure con Frontdoor di Azure.

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:

• Poiché le origini dati sono server separati in un sistema WAS, è necessario considerarle come parte dell'analisi della topologia di rete. Per ulteriori informazioni, consultare Origini dati di WebSphere Application Server.
• Anche le origini di messaggistica sono server distinti. Per ulteriori informazioni, consultare Topologie di rete: interoperare utilizzando il provider di messaggistica WebSphere MQ.
• Il bilanciamento del carico è un requisito fondamentale. Il seguente riferimento riguarda l'aspetto WAS del bilanciamento del carico: clustering con bilanciamento del carico di WebSphere Application Server Network Deployment.

Considerare 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 ulteriori informazioni, consultare adattatori di risorse relazionali e JCA nella documentazione IBM.

Tenere conto dell'autenticazione e dell'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, vedi Autenticazione OpenID Connect con Microsoft Entra ID.

Verificare se viene utilizzato 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 ulteriori informazioni, consultare WebSphere Application Server Network Deployment nella documentazione IBM.

Tenere conto dei requisiti di 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 integrato per gateway applicazione di Azure o IBM HTTP Server fornito dall'offerta di Azure Marketplace per IBM WebSphere Application Server Cluster.

Per un riepilogo delle funzionalità di Gateway applicazione di Azure 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 ulteriori informazioni, vedere Utilizzo dei moduli applicazione client Java EE.

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, ti viene chiesto di scegliere la dimensione della macchina virtuale per i nodi WAS. Nella scelta delle dimensioni delle VM, è importante considerare tutti gli aspetti, ossia memoria, processore e disco. Per ulteriori informazioni, vedere Dimensioni per i servizi cloud (versione classica).

• IBM WebSphere Application Server istanza singola in una VM di Azure

  Questa offerta automatizza la maggior parte dei passaggi boilerplate per effettuare il provisioning di una singola istanza di WebSphere in una macchina virtuale di Azure. Crea un profilo server applicazioni con la console di amministrazione WAS.

• IBM WebSphere Application Server Cluster su VM di Azure

  Questa offerta automatizza la maggior parte dei passaggi boilerplate per effettuare il provisioning di un cluster WebSphere nelle macchine virtuali di Azure. Crea un gestore di distribuzione con la console di amministrazione WAS in una macchina virtuale di Azure e il numero necessario di agenti del nodo in macchine virtuali di Azure separate.

Configura l'offerta

Dopo aver selezionato l'offerta con cui iniziare, eseguire il provisioning di tale offerta seguendo le istruzioni in Distribuire il cluster di WebSphere Application Server (tradizionale) in Macchine virtuali di Azure.

Eseguire la migrazione dei profili

Dopo aver effettuato il provisioning dell'offerta, è possibile esaminare la configurazione del profilo. Per ulteriori informazioni, consultare Concetti sui profili nella documentazione IBM.

Connettere i database

Dopo aver eseguito la migrazione dei profili, 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 ulteriori informazioni, consultare Configurazioni dell'archivio chiavi per SSL nella documentazione IBM.

Connettere le origini dati JMS

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

Tenere conto dell'autenticazione e dell'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, vedi Autenticazione OpenID Connect con Microsoft Entra ID.

Account per la registrazione dei log

È possibile configurare Elastic Stack seguendo le istruzioni riportate in Analisi dei log di WebSphere Application Server con Elastic Stack nella documentazione IBM. Azure offre supporto per Elastic. Per altre informazioni, vedere Che cos'è l'integrazione di Elastic con Azure? È possibile combinare le informazioni contenute in queste due risorse per ottenere una soluzione di logging ottimizzata per Azure per WAS nelle VM.

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 che viene predisposto dall'offerta per consentire l'accesso dalla pipeline CI/CD o dal sistema di distribuzione manuale. Per altre informazioni, vedi Gruppi di sicurezza di rete.

Verifica

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, vedi Gruppi di sicurezza di rete.

Post-migrazione

Dopo aver raggiunto gli obiettivi di migrazione definiti nella fase di pre-migrazione, esegui alcuni test di accettazione completi per verificare che tutto funzioni come previsto. Per indicazioni su alcuni potenziali miglioramenti post-migrazione, vedere le raccomandazioni seguenti:

• Usare Archiviazione di Azure per gestire il contenuto statico montato nelle macchine virtuali. Per ulteriori informazioni, vedere Collegare o scollegare un disco dati per una macchina virtuale di lab in Azure DevTest Labs.

• Distribuire le applicazioni nel cluster WAS migrato con Azure DevOps. Per altre informazioni, vedi Introduzione alla documentazione di Azure DevOps.

• Se hai distribuito WAS traditional con gateway applicazione di Azure, potresti voler eseguire ulteriori configurazioni su gateway applicazione di Azure. Per altre informazioni, vedi Panoramica della configurazione del Gateway applicazione.

• Ottimizzare la topologia di rete con servizi avanzati di bilanciamento del carico. Per ulteriori informazioni, vedere Uso dei servizi di bilanciamento del carico in Azure.

• Usare identità gestite di Azure per i segreti gestiti e assegnare l'accesso basato sui ruoli alle risorse di Azure. Per altre informazioni, vedi Che cosa sono le identità gestite per le risorse di Azure?

• Integrare l'autenticazione e l'autorizzazione di WAS Java EE con Microsoft Entra ID. Per altre informazioni, vedi Guida introduttiva all'integrazione di Microsoft Entra ID con applicazioni.

• Usare Azure Key Vault per archiviare qualsiasi informazione che funga da "segreto". Per altre informazioni, vedi concetti di base di Azure Key Vault.