Migrera WebSphere-program till Azure Virtual Machines

  • Artikel

Den här guiden beskriver vad du bör känna till när du vill migrera ett befintligt websfärprogramserver (WAS) som ska köras på virtuella Azure-datorer. En översikt över tillgängliga traditionella WAS-lösningar på Azure Marketplace finns i Vad är lösningar för att köra IBM WebSphere-serien med produkter i Azure?

Före migrering

För att säkerställa en lyckad migrering slutför du de utvärderings- och inventeringssteg som beskrivs i följande avsnitt innan du börjar.

Definiera vad du menar vid "slutförd migrering"

Den här guiden och motsvarande Azure Marketplace-erbjudanden är en startpunkt för att påskynda migreringen av dina traditionella WAS-arbetsbelastningar till Azure. Det är viktigt att vi definierar din migreringsansträngnings omfattning. Genomför du exempelvis en strikt Lift and Shift-migrering från din befintliga infrastruktur till Azure Virtual Machines? Om så är fallet är du kanske frestad av att arbeta med ”lift and improve”-metoden när du migrerar.

Det är bättre att hålla sig så nära ren ”Lift and Shift”-lösning som möjligt, med tanke på de nödvändiga ändringar som beskrivs i den här vägledningen. Definiera vad du menar vid "slutförd migrering", så att du vet när du har nått denna milstolpe. När du har slutfört migreringen kan du ta en ögonblicksbild av dina virtuella datorer enligt beskrivningen i Skapa en ögonblicksbild av en virtuell hårddisk. När du har kontrollerat att du kan återställa från ögonblicksbilden kan du göra förbättringarna utan att vara rädd för att förlora migreringsframställningen som du har uppnått hittills.

Se till att målet är rätt mål för migreringsarbetet

Det första steget i en lyckad migrering av ett WAS-program till Azure är att välja det lämpligaste migreringsmålet.

WAS-traditionella körningar bra på Azure Virtual Machines. Målet för den virtuella datorn (VM) är det enklaste valet, eftersom det närmast liknar en lokal distribution. Den administrativa upplevelsen och distributionen för virtuella datorer motsvarar det du har lokalt.

Ett annat alternativ är att migrera till containrar genom att konvertera den traditionella WAS-arbetsbelastningen till programcontainrar. Du kan köra containermålet på Azure Kubernetes Service (AKS) och Azure Red Hat OpenShift. Kompromissen för denna lätthet är ekonomiska kostnader.

Generellt sett är kostnaden per minut för en VM-baserad lösning högre jämfört med containrar. Även om en containerbaserad lösning kostar mindre att köra måste du begränsa programmet så att det passar kraven för containerorkestreringsplattformen.

Om minimering av ändringar är den viktigaste faktorn för migreringen bör du överväga en VM-baserad migrering. I det här fallet kan du läsa Migrera WebSphere-program till Virtuella Azure-datorer.

Om du kan tolerera att konvertera ditt program till att köras i containrar för att minska körningskostnaden bör du överväga en AKS-baserad eller Azure Red Hat OpenShift-baserad migrering.

För AKS-baserad migrering kan du börja använda den kostnadsfria nivån. Få kostnadsfri klusterhantering och betala endast för de virtuella datorer, tillhörande lagrings- och nätverksresurser som förbrukas. I det här fallet kan du läsa Migrera WebSphere-program till Azure Kubernetes Service.

För Azure Red Hat OpenShift-baserad migrering, utöver beräknings- och infrastrukturkostnaderna, har programnoder en annan kostnad för OpenShift-licenskomponenten. Den här kostnaden debiteras baserat på antalet programnoder och instanstypen. Använd priser på begäran eller reserverade instanser, beroende på vilket som bäst uppfyller behovet av din arbetsbelastning och ditt företag. I det här fallet kan du läsa Migrera WebSphere-program till Azure Red Hat OpenShift.

Guiderna i Azure Red Hat OpenShift-dokumentationen beskriver några aspekter som är relevanta för migrering. Den fullständiga listan över instruktioner finns i Dokumentationen om Azure Red Hat OpenShift.

Ta reda på om de fördefinierade Azure Marketplace-erbjudandena är en bra utgångspunkt

IBM och Microsoft har samarbetat för att ta en uppsättning Azure-lösningsmallar till Azure Marketplace för att ge en bra startpunkt för migrering till Azure. Listan över erbjudanden finns i Kör WebSphere-serien med produkter och Liberty på Microsoft Azure och välj sedan den som bäst matchar din befintliga distribution. Du kan se listan över erbjudanden i översiktsartikeln Vad är lösningar för att köra IBM WebSphere-serien med produkter i Azure?

Om inget av de befintliga erbjudandena är en bra utgångspunkt måste du återskapa distributionen för hand med hjälp av Azure Virtual Machine-resurser. Du hittar den stegvisa vägledningen i Självstudie: Installera IBM WebSphere Application Server Network Deployment traditionellt på virtuella Azure-datorer manuellt. Mer information finns i Vad är IaaS?

Avgöra om den traditionella WAS-versionen är kompatibel

Din befintliga traditionella WAS-version måste vara kompatibel med versionen i IaaS-erbjudandena. Du hittar versionsinformationen från översiktssidan för IBM WebSphere Application Server Single Instance på en virtuell Azure-dator och IBM WebSphere Application Server Cluster på virtuella Azure-datorer. Om din befintliga traditionella WAS-version inte är kompatibel med den versionen måste du återskapa distributionen för hand med hjälp av Azure IaaS-resurser. Mer information finns i Vad är IaaS?

Lagerserverkapacitet

Dokumentera maskinvaran (minne, CPU, disk) för den aktuella eller de aktuella produktionsservrarna, så väl som genomsnittet och den högsta mängden begäranden och resursutnyttjande. Den här informationen måste upplysa om valet av VM-storlek. Mer information finns i Storlekar för Cloud Services.

Inventera alla hemligheter

Innan tekniker för konfiguration som en tjänst, till exempel Azure Key Vault, fanns det inget väldefinierat koncept för hemligheter. I stället hade du skilda uppsättningar konfigurationsinställningar som fungerade som det vi nu kallar hemligheter. Med appservrar som WAS finns dessa hemligheter i många olika konfigurationsfiler och konfigurationslager. Kontrollera alla egenskaper och konfigurationsfiler på produktionsservrarna efter hemligheter och lösenord. Konfigurationsfiler som innehåller lösenord eller autentiseringsuppgifter kan också finnas i ditt program. WAS lagrar konfigurationsdata i flera dokument i en sammanhängande hierarki med kataloger. De flesta konfigurationsdokument har XML-innehåll. Mer information finns i Konfigurationsdokument och Grundläggande begrepp i Azure Key Vault.

Inventera alla certifikat

Dokumentera alla certifikat som används för offentliga SSL-slutpunkter. Du kan visa alla certifikat på produktionsservrarna genom att köra följande kommando:

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

Mer information finns i IBM-dokumentcertifikathantering i SSL

Validera att Java-versionen som stöds fungerar som den ska

Användning av WAS på virtuella Azure-datorer kräver en specifik version av Java, så du måste bekräfta att programmet körs korrekt med den version som stöds.

IBM Java 8 levereras med WAS9-fördelningen. Vi rekommenderar att du använder JAVA JRE som tillhandahålls av IBM. Mer information finns i Java SE 8 i WebSphere Application Server traditionell V9.

Om du vill växla till en annan Java SDK följer du IBM-dokumentet Växla Java SDK i WebSphere Application Server.

Inventera JNDI-resurser

Inventera alla JNDI-resurser. Till exempel kan datakällor som databaser, ha ett associerat JNDI-namn som gör det möjligt för JPA att korrekt binda instanser av EntityManager till en viss databas. Mer information om JNDI-resurser och databaser finns i WebSphere Data Sources i IBM-dokumentationen. Andra JNDI-relaterade resurser som JMS asynkron meddelandekö kan kräva migrering eller omkonfiguration. Mer information om JMS-konfiguration finns i Använda JMS-resurser.

Granska profilkonfigurationen

Huvudkonfigurationsenheten i WAS är profilen. Därför innehåller filen resources.xml en mängd konfigurationer som du noggrant måste överväga för migrering. Filen innehåller referenser till fler XML-filer som lagras i underkataloger. IBM rekommenderar att du normalt använder IBM-konsolen för att konfigurera WAS:s hanterbara objekt och tjänster och tillåter ATT WAS underhåller mappen profiler/profilnamn . Mer information finns i Hantera profiler på distribuerade operativsystem och IBM i-operativsystem.

I ditt program

Granska filen deployment.xml och/eller WEB-INF/web.xml .

Fastställ om sessionsreplikering används

Om programmet förlitar sig på sessionsreplikering har du följande alternativ:

  • För HTTP-sessioner, enligt nivån för sessionshantering, kan du använda minne eller en databas för att samla in sessionsdata.
  • För distribuerade sessioner kan du spara sessioner i en databas med hjälp av databassessionens beständighet.
  • För dynamisk cache kan du hantera sessionsdata i replikering från minne till minne eller en databas.
  • Omstrukturera ditt program att använda en databas för sessionshantering.
  • Omstrukturera ditt program att externalisera sessionen till Azure Redis-tjänsten. Mer information finns i Azure Cache for Redis.

För alla dessa alternativ är det en bra idé att behärska hur WAS utför HTTP-sessionstillståndsreplikering. Mer information finns i Administrera sessionsbönor i IBM-dokumentationen.

Dokumentets datakällor

Om ditt program använder några databaser måste du samla in följande information:

  • What is the datakällans namn?
  • Vad är konfigurationen för anslutningspoolen?
  • Var hittar jag JAR-filen för JDBC-drivrutinen?

Mer information om JDBC-drivrutiner i WAS finns i Använda JDBC-drivrutiner med WebSphere Application Server.

Avgöra om WAS har anpassats

Fastställ vilken av följande anpassningar som har gjorts och registrera vad som har gjorts.

  • Har startskripten ändrats? Sådana skript omfattar wsadmin, AdminControl, AdminConfig, AdminApp och AdminTask.
  • Finns det några speciella parametrar som skickas till JVM?
  • Har JAR lagts till i server-classpath?
  • Har operativsystemnivåanläggningar som systemd använts för att få WAS-komponenter att starta automatiskt efter en omstart av servern?

Du måste ta hänsyn till migreringsöverväganden beroende på svaren på dessa frågor.

Avgör om en anslutning till lokalt behövs

Om ditt program behöver har åtkomst till någon av dina lokala tjänster måste du etablera en av Azures anslutningstjänster. Mer information finns i Ansluta ett lokalt nätverk till Azure. Alternativt måste du omstrukturera programmet för att använda allmänt tillgängliga API:er som dina lokala resurser exponerar.

Ta reda på om JMS-köer eller -ämnen (Java Message Service) används

Om ditt program använder JMS-köer eller ämnen måste du migrera dem till en externT värdbaserad JMS-server. En strategi för dem som använder JMS är att använda Azure Service Bus och Advanced Message Queuing Protocol. Mer information finns i Använda Java Message Service 1.1 med Azure Service Bus Standard och AMQP 1.0.

Om du har konfigurerat JMS-beständiga butiker måste du avbilda deras konfiguration och tillämpa den efter migreringen.

Om du använder IBM MQ kan du migrera den här programvaran till Azure Virtual Machines och använda den som den är.

Microsoft har en lösning för att integrera IBM MQ med Logic Apps. Mer information finns i Ansluta till en IBM MQ-server från ett arbetsflöde i Azure Logic Apps.

Fastställ om du använder dina egna anpassade Delade Java EE-bibliotek

Om du använder funktionen med Delade Java EE-bibliotek så har du två alternativ:

  • Återför programkoden för att ta bort alla beroenden i dina bibliotek, och inkludera i stället funktionerna direkt i programmet.
  • Lägg till biblioteken till server-classpath.

Ta reda på om OSGi-paket används

Om du använde OSGi-paket som lagts till i WAS måste du lägga till motsvarande JAR-filer direkt i webbappen.

Ta reda på om ditt program innehåller en operativsystemsspecifik kod

Om ditt program innehåller någon kod med beroenden på värdoperativsystemet måste du omstrukturera det för att ta bort dessa beroenden. Du kan till exempel behöva ersätta all användning av / eller \ i filsystemsökvägar med File.Separator eller Paths.get om programmet körs i Windows.

Avgöra om IBM Integration Bus används

Om ditt program använder IBM Integration Bus måste du samla in hur IBM Integration Bus har konfigurerats. Mer information finns i IBM Integration Bus-dokumentationen.

Ta reda på om ditt program består av flera WAR

Om ditt program består av flera WAS så ska du behandla vart och ett av dem som separarata program och gå igenom den här guiden för varje.

Ta reda på om ditt program är paketerat som EAR

Om ditt program paketeras som en EAR-fil bör du undersöka filerna application.xml, ibm-application-bnd.xmi och ibm-application-ext.xmi och avbilda deras konfigurationer. Mer information finns i Skapa enterprise archive-paketet (EAR) på WebSphere.

Identifiera alla externa processer och daemons som körs på produktionsservrarna

Om du har processer som körs utanför programservern, som övervaknings-daemons så behöver du eliminera dem eller migrera dem någon annanstans.

Kontrollera om och hur filsystemet används

VM-filsystem fungerar på samma sätt som lokala filsystem med avseende på kvarhållning, start och avstängning. Dock är det viktigt att vara medveten om dina filsystemsbehov och se till att de virtuella datorerna har tillräckligt med lagringsutrymme och prestanda.

Skrivskyddat statiskt innehåll

Om ditt program för tillfället hanterar statiskt innehåll behöver du en alternativ plats för det. Du kanske kan tänka dig att flytta det statiska innehållet till Azure Blob Storage och lägga till Azure CDN för blixtsnabba nedladdningar globalt. Mer information finns i Värd för statiska webbplatser i Azure Storage och snabbstart: Integrera ett Azure Storage-konto med Azure CDN.

Dynamiskt publicerat statiskt innehåll

Om ditt program tillåter att statiskt innehåll laddas upp/skapas av ditt program, men inte kan ändras efter att det har skapats, så kan du använda Azure Blob Storage och Azure CDN enligt beskrivningen ovan, med en Azure-funktion för hantering av överföringar och CDN-uppdateringar. Vi har tillhandahållit en exempelimplementering som du kan använda i Överföra och CDN-för inläsa statiskt innehåll med Azure Functions.

Ta reda på nätverkstopologin

Den aktuella uppsättningen Azure Marketplace-erbjudanden är en startpunkt för migreringen. Om erbjudandet inte omfattar aspekter av din arkitektur som du behöver migrera måste du samla in nätverkstopologin för din befintliga distribution. Sedan måste du återskapa nätverkstopologin i Azure, även efter att du har ställt upp det grundläggande erbjudandet med en av lösningsmallarna.

Nätverkstopologi är ett brett ämne, men följande referenser kan ge en viss riktning till migreringsarbetet:

Konto för användning av JCA-kort och resurskort

Om ditt befintliga program använder JCA-kort eller andra resurskort för att ansluta till andra företagssystem kontrollerar du att du tillämpar konfigurationen för dessa artefakter på WAS som körs på virtuella Azure-datorer. Mer information finns i Relationsresurskort och JCA i IBM-dokumentationen.

Konto för autentisering och auktorisering

De flesta program har någon form av autentisering och auktorisering. Om du använder OpenID för autentisering kan du konfigurera OpenID Connect-autentisering med Microsoft Entra-ID. Mer information finns i OpenID Connect-autentisering med Microsoft Entra-ID.

Avgöra om WAS-klustring används

Troligtvis har du distribuerat ditt program på flera WAS-servrar för att uppnå hög tillgänglighet. Du kan migrera dessa kluster direkt från din lokala installation till WAS som körs i Azure Virtual Machines. Mer information finns i WebSphere Application Server Network Deployment i IBM-dokumentationen.

Konto för belastningsutjämningskrav

Belastningsutjämning är en viktig del av migreringen av DITT WAS-kluster till Azure. Den enklaste lösningen är att använda det inbyggda stödet för Azure Application Gateway eller IBM HTTP Server som tillhandahålls i Azure Marketplace-erbjudandet för IBM WebSphere Application Server Cluster.

En sammanfattning av funktionerna i Azure Application Gateway jämfört med andra Azure-belastningsutjämningslösningar finns i Alternativ för belastningsutjämning.

Ta reda på om funktionen Java EE-programklient används

Om programmet använder funktionen Java EE-programklient, bör den fortsätta att fungera oförändrad efter migrering till Azure Virtual Machines. Mer information finns i Använda Java EE-klientprogrammoduler.

Migrering

Välj ett was traditional på Azure Virtual Machines-erbjudande

Följande erbjudanden är tillgängliga för WAS på virtuella Azure-datorer.

Under distributionen av ett erbjudande uppmanas du att välja storleken på den virtuella datorn för dina WAS-noder. Det är viktigt att du tar hänsyn till alla storleksaspekter (minne, processor, disk) när du väljer virtuell datorstorlek. Mer information finns i Storlekar för Cloud Services (klassisk).

Få tillgång till erbjudandet

När du har valt vilket erbjudande du ska börja med etablerar du erbjudandet genom att följa anvisningarna i Distribuera WebSphere Application Server-kluster (traditionellt) på Azure Virtual Machines.

Migrera profilerna

När du har etablerat erbjudandet kan du undersöka profilkonfigurationen. Mer information finns i Profilbegrepp i IBM-dokumentationen.

Anslut databaserna

När du har migrerat profilerna kan du ansluta databaserna genom att följa anvisningarna i Konfigurera WebSphere Application Server-datakällan i IBM-dokumentationen.

KeyStores-konto

Du måste ha ett konto för migreringen av de eventuella SSL KeyStores som programmet använder. Mer information finns i Keystore-konfigurationer för SSL i IBM-dokumentationen.

Anslut JMS-källorna

När du har anslutit databaserna kan du konfigurera JMS genom att följa anvisningarna i Konfigurera JMS i IBM WebSphere Application Server i IBM-dokumentationen.

Konto för autentisering och auktorisering

De flesta program har någon form av autentisering och auktorisering. Om du använder OpenID för autentisering kan du konfigurera OpenID Connect-autentisering med Microsoft Entra-ID. Mer information finns i OpenID Connect-autentisering med Microsoft Entra-ID.

Loggningskonto

Du kan konfigurera Elastic Stack genom att följa anvisningarna i Analysera WebSphere Application Server-loggar med Elastic Stack i IBM-dokumentationen. Azure tillhandahåller stöd för Elastic. Mer information finns i Vad är elastisk integrering med Azure? Du kan kombinera kunskapen i dessa två resurser för att uppnå en Azure-optimerad loggningslösning för WAS på virtuella datorer.

Migrera dina program

De tekniker som används för att distribuera program från utvecklingsteamet till test-, mellanlagrings- och produktionsservrarna varierar kraftigt från fall till fall. I vissa fall finns det en mycket utvecklad CI/CD-plattform som resulterar i att programmen distribueras till WebSphere Application Server. I andra fall är processen mer manuell. En fördel med att använda Azure Virtual Machines för att migrera traditionella WAS-program till molnet är att dina befintliga processer fortsätter att fungera.

Du måste konfigurera den nätverkssäkerhetsgrupp som erbjudandet tillhandahåller för att tillåta åtkomst från ci/CD-pipelinen eller det manuella distributionssystemet. Mer information finns i Nätverkssäkerhetsgrupper.

Testning

Du måste konfigurera alla tester i containern mot program för att få åtkomst till de nya servrar som körs i Azure. Precis som med CI/CD-problemen måste du se till att de nödvändiga nätverkssäkerhetsreglerna tillåter dina tester att komma åt de program som distribueras till Azure. Mer information finns i Nätverkssäkerhetsgrupper.

Efter migreringen

När du har nått de migreringsmål som du definierade i steget före migreringen, så utför några godkännandetester från slutpunkt till slutpunkt för att se att allt fungerar som förväntat. Vägledning om några potentiella förbättringar efter migreringen finns i följande rekommendationer: