Delen via

WebSphere-toepassingen migreren naar virtuele Azure-machines

  • Artikel

In deze handleiding wordt beschreven waar u rekening mee moet houden wanneer u een bestaande traditionele WebSphere Application Server-toepassing (WAS) wilt migreren om te worden uitgevoerd op virtuele Azure-machines. Zie Wat zijn oplossingen voor het uitvoeren van de IBM WebSphere-producten in Azure Voor een overzicht van beschikbare WAS-traditionele oplossingen in Azure?

Premigratie

Voltooi voordat u begint de evaluatie- en inventarisstappen die in de volgende secties worden beschreven om een geslaagde migratie te garanderen.

Definieer wat u bedoelt met een voltooide migratie

Deze handleiding en de bijbehorende Azure Marketplace-aanbiedingen zijn een startpunt om de migratie van uw traditionele WAS-workloads naar Azure te versnellen. Het is belangrijk om het bereik van uw migratie-inspanning te definiëren. Gaat u bijvoorbeeld een strikte lift-and-shift uitvoeren van uw bestaande infrastructuur naar Azure Virtual Machines? Als dat het geval is, komt u misschien in de verleiding om tijdens het migreren enige verbeteringen aan te brengen.

Het is beter om zo dicht mogelijk bij de pure lift-and-shift te blijven, waarmee u de benodigde wijzigingen doorvoert die in deze handleiding worden beschreven. Definieer wat u bedoelt met een voltooide migratie zodat u weet wanneer u deze mijlpaal hebt bereikt. Wanneer u de 'migratie voltooid' hebt bereikt, kunt u een momentopname van uw virtuele machines maken, zoals beschreven in Een momentopname van een virtuele harde schijf maken. Nadat u hebt geverifieerd dat u met succes kunt herstellen vanuit uw momentopname, kunt u de verbeteringen uitvoeren zonder dat u bang bent dat de migratievoortgang verloren gaat die u tot nu toe hebt bereikt.

Zorg ervoor dat het doel het juiste doel is voor uw migratie-inspanning

De eerste stap bij een geslaagde migratie van een WAS-toepassing naar Azure is het selecteren van het meest geschikte migratiedoel.

WAS is traditioneel goed uitgevoerd op virtuele Azure-machines. Het doel van de virtuele machine (VM) is de eenvoudigste keuze, omdat deze het meest lijkt op een on-premises implementatie. De beheer- en implementatie-ervaring voor virtuele machines is vergelijkbaar met wat u on-premises hebt.

Een andere optie is om naar containers te migreren door traditionele WAS-werkbelasting te converteren naar toepassingscontainers. U kunt het containerdoel uitvoeren op Azure Kubernetes Service (AKS) en Azure Red Hat OpenShift. De afweging voor dit gemak is economische kosten.

Over het algemeen zijn de kosten per minuut voor een vm-oplossing hoger in vergelijking met containers. Hoewel een oplossing op basis van containers minder kost om te worden uitgevoerd, moet u uw toepassing beperken tot aan de vereisten van het containerindelingsplatform.

Als het minimaliseren van de wijziging de belangrijkste factor is voor uw migratie-inspanning, kunt u een migratie op basis van een VM overwegen. In dit geval raadpleegt u WebSphere-toepassingen migreren naar Azure Virtual Machines.

Als u het converteren van uw toepassing tolereert om te worden uitgevoerd binnen containers om de runtimekosten te verlagen, kunt u een migratie op basis van AKS of Azure Red Hat OpenShift overwegen.

Voor migratie op basis van AKS kunt u de gratis laag gaan gebruiken. Ontvang gratis clusterbeheer en betaal alleen voor de virtuele machines, gekoppelde opslag en netwerkresources die worden gebruikt. Zie In dit geval WebSphere-toepassingen migreren naar Azure Kubernetes Service.

Voor migratie op basis van Azure Red Hat OpenShift, naast de kosten voor reken- en infrastructuur, hebben toepassingsknooppunten nog een andere kosten voor het OpenShift-licentieonderdeel. Deze kosten worden gefactureerd op basis van het aantal toepassingsknooppunten en het exemplaartype. Gebruik prijzen op aanvraag of gereserveerde instanties, afhankelijk van de behoeften van uw workload en bedrijf. Zie In dit geval WebSphere-toepassingen migreren naar Azure Red Hat OpenShift.

De handleidingen in de Documentatie van Azure Red Hat OpenShift hebben betrekking op enkele aspecten die relevant zijn voor migratie. Zie de Documentatie voor Azure Red Hat OpenShift voor de volledige lijst met handleidingen.

Bepalen of de vooraf gemaakte Azure Marketplace-aanbiedingen een goed uitgangspunt zijn

IBM en Microsoft hebben samengewerkt om een set Azure-oplossingssjablonen naar Azure Marketplace te brengen om een solide uitgangspunt te bieden voor migratie naar Azure. Zie Run the WebSphere family of products and Liberty on Microsoft Azure (De WebSphere-serie van producten en Liberty op Microsoft Azure uitvoeren) en kies vervolgens het product dat het meest overeenkomt met uw bestaande implementatie. U kunt de lijst met aanbiedingen bekijken in het overzichtsartikel Wat zijn oplossingen voor het uitvoeren van de IBM WebSphere-productenfamilie in Azure?

Als geen van de bestaande aanbiedingen een goed uitgangspunt is, moet u de implementatie handmatig reproduceren met behulp van Azure Virtual Machine-resources. U vindt de stapsgewijze instructies in zelfstudie: Ibm WebSphere Application Server Network Deployment handmatig installeren op virtuele Azure-machines. Zie Wat is IaaS voor meer informatie?

Bepalen of de traditionele WAS-versie compatibel is

Uw bestaande traditionele WAS-versie moet compatibel zijn met de versie in de IaaS-aanbiedingen. U vindt de versie-informatie op de overzichtspagina van IBM WebSphere Application Server Single Instance op Azure VM en IBM WebSphere Application Server Cluster op Virtuele Azure-machines. Als uw bestaande traditionele WAS-versie niet compatibel is met die versie, moet u de implementatie handmatig reproduceren met behulp van Azure IaaS-resources. Zie Wat is IaaS voor meer informatie?

Servercapaciteit inventariseren

Documenteer de hardware (geheugen, CPU, schijf) van de huidige productieserver(s), evenals het gemiddelde aantal en piekaantal aanvragen en het resourcegebruik. Deze informatie wordt gebruikt om de VM-grootte te bepalen. Zie Groottes voor Cloud Services voor meer informatie.

Alle geheimen inventariseren

Voor de ontwikkeling van 'configuratie als een service'-technologieën zoals Azure Key Vault, was er geen goed gedefinieerd concept voor 'geheimen'. In plaats daarvan had u een set uiteenlopende configuratie-instellingen die functioneerden als wat we nu 'geheimen' noemen. Met app-servers zoals WAS bevinden deze geheimen zich in veel verschillende configuratiebestanden en configuratiearchieven. Controleer alle eigenschaps- en configuratiebestanden op de productieserver(s) op geheimen en wachtwoorden. Mogelijk bevinden zich ook in uw toepassing configuratiebestanden met wachtwoorden of referenties. WAS slaat configuratiegegevens op in verschillende documenten in een trapsgewijze hiërarchie van mappen. De meeste configuratiedocumenten hebben XML-inhoud. Zie Configuratiedocumenten en basisconcepten van Azure Key Vault voor meer informatie.

Alle certificaten inventariseren

Documenteer alle certificaten die worden gebruikt voor openbare SSL-eindpunten. U kunt alle certificaten op de productieserver(s) weergeven door de volgende opdracht uit te voeren:

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

Zie het ibm-documentcertificaatbeheer in SSL voor meer informatie

Controleren of de ondersteunde Java-versie goed werkt

Voor het gebruik van WAS op Azure Virtual Machines is een specifieke versie van Java vereist. U moet dus controleren of uw toepassing correct wordt uitgevoerd met die ondersteunde versie.

IBM Java 8 wordt geleverd met de WAS9-distributie. U wordt aangeraden de door IBM geleverde Java JRE te gebruiken. Zie Java SE 8 in traditionele V9 van WebSphere Application Server voor meer informatie.

Als u wilt overschakelen naar een andere Java SDK, volgt u het IBM-document Overschakelen van de Java SDK in WebSphere Application Server.

JNDI-resources inventariseren

Inventariseer alle JNDI-resources. Gegevensbronnen zoals databases kunnen bijvoorbeeld een gekoppelde JNDI-naam hebben waarmee JPA op de juiste wijze exemplaren van EntityManager aan een bepaalde database kan binden. Zie WebSphere-gegevensbronnen in de IBM-documentatie voor meer informatie over JNDI-resources en -databases. Andere JNDI-gerelateerde resources, zoals JMS-berichtenbrokers, moeten mogelijk worden gemigreerd of opnieuw worden geconfigureerd. Zie JMS-resources gebruiken voor meer informatie over de JMS-configuratie.

Uw profielconfiguratie controleren

De belangrijkste configuratie-eenheid in WAS is het profiel. Als zodanig bevat het resources.xml-bestand een schat aan configuraties die u zorgvuldig moet overwegen voor migratie. Het bestand bevat verwijzingen naar meer XML-bestanden die zijn opgeslagen in submappen. IBM adviseert dat u normaal gesproken de IBM-console moet gebruiken om de beheerbare objecten en services van WAS te configureren en WAS de map met profielen/profielnamen te laten onderhouden. Zie Profielen beheren op gedistribueerde en IBM i-besturingssystemen voor meer informatie.

Binnen uw toepassing

Inspecteer het deployment.xml-bestand en/of het WEB-INF-/web.xml-bestand .

Bepalen of sessiereplicatie wordt gebruikt

Als uw toepassing afhankelijk is van sessiereplicatie, hebt u de volgende opties:

  • Voor HTTP-sessies, op basis van het niveau van sessiebeheer, kunt u geheugen of een database gebruiken om sessiegegevens te verzamelen.
  • Voor gedistribueerde sessies kunt u sessies in een database opslaan met behulp van databasesessiepersistentie.
  • Voor dynamische cache kunt u sessiegegevens beheren in replicatie van geheugen naar geheugen of een database.
  • Herstructureer uw toepassing om een database te gebruiken voor sessiebeheer.
  • Herstructureer uw toepassing om de sessie te externaliseren naar Azure Redis Service. Zie Azure Cache voor Redis voor meer informatie.

Voor al deze opties is het een goed idee om te leren hoe WAS http-sessiestatusreplicatie doet. Zie Sessiebonen beheren in de IBM-documentatie voor meer informatie.

Gegevensbronnen documenteren

Als uw toepassing gebruikmaakt van databases, moet u de volgende informatie vastleggen:

  • Wat is de naam van de gegevensbron?
  • Wat is de configuratie van de verbindingsgroep?
  • Waar vind ik het JAR-bestand van het JDBC-stuurprogramma?

Zie JDBC-stuurprogramma's gebruiken met WebSphere Application Server voor meer informatie over JDBC-stuurprogramma's in WAS.

Bepalen of WAS is aangepast

Bepaal welke van de volgende aanpassingen zijn uitgevoerd en leg vast wat er is gebeurd.

  • Zijn de opstartscripts gewijzigd? Dergelijke scripts omvatten wsadmin, AdminControl, AdminConfig, AdminApp en AdminTask.
  • Zijn er specifieke parameters aan de JVM doorgegeven?
  • Zijn er JAR's toegevoegd aan het classpath van de server?
  • Zijn er voorzieningen op besturingssysteemniveau zoals systemd gebruikt om ERVOOR te zorgen dat WAS-onderdelen automatisch worden gestart nadat de server opnieuw is opgestart?

U moet rekening houden met migratieoverwegingen, afhankelijk van de antwoorden op deze vragen.

Bepalen of er een verbinding met on-premises services is vereist

Als voor uw toepassing toegang nodig is tot een van uw on-premises services, moet u een van de connectiviteitsservices van Azure inrichten. Zie Connect an on-premises network to Azure (Een on-premises netwerk verbinden met Azure) voor meer informatie. U moet uw toepassing ook herstructureren voor het gebruik van openbaar beschikbare API's in uw on-premises resources.

Bepalen of Java Message Service-wachtrijen (JMS) of -onderwerpen in gebruik zijn

Als uw toepassing JMS-wachtrijen of onderwerpen gebruikt, moet u deze migreren naar een extern gehoste JMS-server. Een strategie voor degenen die JMS gebruiken, is het gebruik van Azure Service Bus en het Advanced Message Queuing Protocol. Zie Java Message Service 1.1 gebruiken met Azure Service Bus Standard en AMQP 1.0 voor meer informatie.

Als u permanente JMS-archieven hebt geconfigureerd, moet u de configuratie vastleggen en toepassen na de migratie.

Als u IBM MQ gebruikt, kunt u deze software migreren naar Azure Virtual Machines en deze als zodanig gebruiken.

Microsoft heeft een oplossing voor het integreren van IBM MQ met Logic Apps. Zie Verbinding maken met een IBM MQ-server vanuit een werkstroom in Azure Logic Apps voor meer informatie.

Bepalen of u uw eigen aangepaste, gedeelde Java EE-bibliotheken gebruikt

Als u de functie Gedeelde Java EE-bibliotheek gebruikt, hebt u twee opties:

  • Herstructureer uw toepassingscode om alle afhankelijkheden van uw bibliotheken te verwijderen en de functionaliteit in plaats daarvan rechtstreeks in uw toepassing op te nemen.
  • Voeg de bibliotheken toe aan het klassepad van de server.

Bepalen of OSGi-bundels worden gebruikt

Als u OSGi-bundels hebt gebruikt die zijn toegevoegd aan de WAS, moet u de equivalente JAR-bestanden rechtstreeks toevoegen aan uw webtoepassing.

Bepalen of uw toepassing code bevat die specifiek is voor het besturingssysteem

Als uw toepassing code bevat met afhankelijkheden van het host-besturingssysteem, moet u deze herstructureren om deze afhankelijkheden te verwijderen. U moet bijvoorbeeld het gebruik van / of \ in bestandssysteempaden vervangen door File.Separator of Paths.get als uw toepassing wordt uitgevoerd in Windows.

Bepalen of IBM Integration Bus wordt gebruikt

Als uw toepassing IBM Integration Bus gebruikt, moet u vastleggen hoe IBM Integration Bus is geconfigureerd. Zie de documentatie van IBM Integration Bus voor meer informatie.

Bepalen of uw toepassing bestaat uit meerdere WAR's

Als uw toepassing bestaat uit meerdere WAR's, moet u deze allemaal behandelen als afzonderlijke toepassingen en deze handleiding voor al deze WAR's doorlopen.

Bepalen of uw toepassing is verpakt als een EAR

Als uw toepassing is verpakt als een EAR-bestand, moet u de bestanden application.xml, ibm-application-bnd.xmi en ibm-application-ext.xmi bekijken en hun configuraties vastleggen. Zie Het enterprise archive-pakket (EAR) bouwen op WebSphere voor meer informatie.

Alle externe processen en daemons identificeren die worden uitgevoerd op de productieservers

U moet alle processen die buiten de toepassingsserver worden uitgevoerd, zoals controledaemons, verwijderen of naar een andere locatie migreren.

Nagaan of en hoe het bestandssysteem wordt gebruikt

VM-bestandssystemen werken op dezelfde manier als on-premises bestandssystemen met betrekking tot persistentie, opstarten en afsluiten. Het is ook belangrijk om rekening te houden met de behoeften van uw bestandssysteem en om ervoor te zorgen dat de opslagruimte en prestaties van de VM's voldoende zijn.

Statische alleen-lezeninhoud

Als uw toepassing momenteel met statische inhoud werkt, hebt u hiervoor een alternatieve locatie nodig. U kunt statische inhoud verplaatsen naar Azure Blob Storage en Azure CDN toevoegen voor razendsnelle downloads wereldwijd. Zie statische websitehosting in Azure Storage en quickstart: Een Azure-opslagaccount integreren met Azure CDN voor meer informatie.

Dynamisch gepubliceerde statische inhoud

Als uw toepassing statische inhoud toestaat die wordt geüpload/geproduceerd door uw toepassing, maar onveranderbaar is nadat deze is gemaakt, kunt u Azure Blob Storage en Azure CDN gebruiken zoals hierboven beschreven, met een Azure-functie om uploads en CDN-vernieuwing te verwerken. U vindt een voorbeeldimplementatie voor gebruik in Statische inhoud uploaden en via CDN vooraf laden met Azure Functions.

De netwerktopologie bepalen

De huidige set Azure Marketplace-aanbiedingen is een startpunt voor uw migratie. Als de aanbieding niet betrekking heeft op aspecten van uw architectuur die u moet migreren, moet u de netwerktopologie van uw bestaande implementatie vastleggen. Vervolgens moet u die netwerktopologie in Azure reproduceren, zelfs nadat u de basisaanbieding met een van de oplossingssjablonen hebt opgesteld.

Netwerktopologie is een breed onderwerp, maar de volgende verwijzingen kunnen enkele richting geven aan uw migratie-inspanningen:

Account voor het gebruik van JCA-adapters en resourceadapters

Als uw bestaande toepassing gebruikmaakt van JCA-adapters of andere resourceadapters om verbinding te maken met andere bedrijfssystemen, moet u ervoor zorgen dat u de configuratie voor deze artefacten toepast op de WAS die wordt uitgevoerd in virtuele Azure-machines. Zie Relationele resourceadapters en JCA in de IBM-documentatie voor meer informatie.

Account voor verificatie en autorisatie

De meeste toepassingen hebben een soort verificatie en autorisatie. Als u OpenID gebruikt voor verificatie, kunt u OpenID-verbindingsverificatie configureren met Microsoft Entra-id. Zie OpenID Connect-verificatie met Microsoft Entra ID voor meer informatie.

Bepalen of WAS-clustering wordt gebruikt

Waarschijnlijk hebt u uw toepassing geïmplementeerd op meerdere WAS-servers om hoge beschikbaarheid te bereiken. U kunt deze clusters rechtstreeks vanuit uw on-premises installatie migreren naar WAS die wordt uitgevoerd in Azure Virtual Machines. Zie WebSphere Application Server Network Deployment in de IBM-documentatie voor meer informatie.

Account voor taakverdelingsvereisten

Taakverdeling is een essentieel onderdeel van het migreren van uw WAS-cluster naar Azure. De eenvoudigste oplossing is het gebruik van de ingebouwde ondersteuning voor Azure-toepassing Gateway of IBM HTTP Server die is opgegeven in de Azure Marketplace-aanbieding voor IBM WebSphere Application Server-cluster.

Zie Opties voor taakverdeling voor een overzicht van de mogelijkheden van Azure-toepassing Gateway in vergelijking met andere Azure-taakverdelingsoplossingen.

Bepalen of de functie Java EE Application Client wordt gebruikt

Als uw toepassing gebruikmaakt van de functie Java EE Application Client, moet deze ongewijzigd blijven werken na de migratie naar Azure Virtual Machines. Zie Java EE Client Application-modules gebruikenvoor meer informatie.

Migratie

Selecteer een WAS-aanbieding voor virtuele Azure-machines

De volgende aanbiedingen zijn beschikbaar voor WAS op virtuele Azure-machines.

Tijdens de implementatie van een aanbieding wordt u gevraagd om de grootte van de virtuele machine voor uw WAS-knooppunten te kiezen. Het is belangrijk om alle aspecten van de grootte (geheugen, processor, schijf) bij uw keuze voor de VM-grootte te betrekken. Zie Grootten voor Cloud Services (klassiek) voor meer informatie.

  • IBM WebSphere Application Server Single Instance op Azure VM

    Met deze aanbieding worden de meeste standaardstappen geautomatiseerd voor het inrichten van één WebSphere-exemplaar op een virtuele Azure-machine. Er wordt een toepassingsserverprofiel gemaakt met de WAS-beheerconsole.

  • IBM WebSphere Application Server-cluster op Virtuele Azure-machines

    Met deze aanbieding worden de meeste standaardstappen geautomatiseerd voor het inrichten van een WebSphere-cluster op Azure-VM's. Er wordt een implementatiebeheerder gemaakt met de WAS-beheerconsole op een Virtuele Azure-machine en het vereiste aantal knooppuntagents op gescheiden Azure-VM's.

De aanbieding inrichten

Nadat u hebt geselecteerd met welke aanbieding u wilt beginnen, richt u die aanbieding in door de instructies te volgen in Het WebSphere Application Server-cluster (traditioneel) implementeren op virtuele Azure-machines.

De profielen migreren

Nadat u de aanbieding hebt ingericht, kunt u de profielconfiguratie bekijken. Zie Profielconcepten in de IBM-documentatie voor meer informatie.

De databases verbinden

Nadat u de profielen hebt gemigreerd, kunt u verbinding maken met de databases door de instructies te volgen in het configureren van de gegevensbron WebSphere Application Server in de IBM-documentatie.

Account voor sleutelarchieven

U moet rekening houden met de migratie van SSL-sleutelarchieven die door uw toepassing worden gebruikt. Zie Keystore-configuraties voor SSL in de IBM-documentatie voor meer informatie.

De JMS-bronnen verbinden

Nadat u de databases hebt verbonden, kunt u JMS configureren door de instructies te volgen voor het instellen van JMS in IBM WebSphere Application Server in de IBM-documentatie.

Account voor verificatie en autorisatie

De meeste toepassingen hebben een soort verificatie en autorisatie. Als u OpenID gebruikt voor verificatie, kunt u OpenID-verbindingsverificatie configureren met Microsoft Entra-id. Zie OpenID Connect-verificatie met Microsoft Entra ID voor meer informatie.

Account voor logboekregistratie

U kunt Elastic Stack configureren door de instructies te volgen in het analyseren van WebSphere Application Server-logboeken met Elastic Stack in de IBM-documentatie. Azure biedt ondersteuning voor Elastic. Zie Wat is Elastische integratie met Azure voor meer informatie ? U kunt de kennis in deze twee resources combineren om een voor Azure geoptimaliseerde logboekregistratieoplossing voor WAS op VM's te realiseren.

Uw toepassingen migreren

De technieken die worden gebruikt om toepassingen van het ontwikkelteam in de test-, faserings- en productieservers te implementeren variëren sterk per geval. In sommige gevallen is er een zeer ontwikkeld CI/CD-platform dat ertoe leidt dat de toepassingen worden geïmplementeerd op de WebSphere-toepassingsserver. In andere gevallen kan het proces meer handmatig zijn. Een voordeel van het gebruik van virtuele Azure-machines om traditionele toepassingen naar de cloud te migreren, is dat uw bestaande processen blijven werken.

U moet de netwerkbeveiligingsgroep configureren die door de aanbieding wordt ingericht om toegang vanuit uw CI/CD-pijplijn of handmatig implementatiesysteem toe te staan. Zie Netwerkbeveiligingsgroepen voor meer informatie.

Testen

U moet in-containertests configureren voor toepassingen om toegang te krijgen tot de nieuwe servers die worden uitgevoerd in Azure. Net als bij de problemen met CI/CD moet u ervoor zorgen dat uw tests toegang hebben tot de toepassingen die zijn geïmplementeerd in Azure. Zie Netwerkbeveiligingsgroepen voor meer informatie.

Postmigratie

Nadat u de migratiedoelstellingen hebt bereikt die u hebt gedefinieerd in de stap Voorafgaand aan de migratie, voert u een aantal end-to-end-acceptatietests uit om te controleren of alles werkt zoals verwacht. Zie de volgende aanbevelingen voor hulp bij een aantal mogelijke verbeteringen na de migratie: