Den här artikeln beskriver en migreringsmetod för att omplatforma dina AIX-arbetsbelastningar till molnet. Du kan använda Azure Functions för en serverlös arkitektur eller använda Azure Virtual Machines för att behålla en serverfull modell.
Överväg en strategi för omplattformsmigrering för AIX-arbetsbelastningar för att maximera avkastningen på investeringen (ROI) när du migrerar äldre program till Azure. Omplattformsmigreringar kräver minimala ändringar men ger molnbaserade fördelar som liknar en refaktormigrering.
Fördelarna med en omplatformmigrering är:
- En reducerad total ägandekostnad (TCO).
- Förbättrad flexibilitet i verksamheten.
- Förbättrad driftsåterhämtning.
Arkitektur (omplatformerad)
Ladda ned en Visio-fil med den här arkitekturen.
Arbetsflöde
Det här arbetsflödet motsvarar den föregående arkitekturen.
Användarbegäranden och inkommande API-integreringar överförs till Azure Application Gateway på TCP/443 (HTTPS), som tillhandahåller en waf-funktion (web application firewall). Application Gateway skickar begäranden, som omvända proxybegäranden, till olika tjänster som finns på Red Hat JBoss Enterprise Application Platform (EAP).
Java Web Services frågar Oracle-databasen (TCP/1521). Svarstiden för synkrona webbbegäranden är mindre än 50 millisekunder (ms).
En asynkron begäran, till exempel schemaläggning av en batchaktivitet, placerar en post i en databastabell som fungerar som en kö i programlagret.
Kommentar
I framtiden ersätter Azure Queue Storage databastabellen, så att du alltid kan ha åtkomst till analysjobb som körs.
Cron-jobbet, skrivet i KornShell-skript (ksh), portas till Bash och körs på en separat Red Hat Enterprise Linux-server (RHEL) i Azure Virtual Machine Scale Sets. Cron-jobbet körs var 15:e minut, inklusive vid systemstart, för att köra frågor mot kön i Oracle-databasen. Jobb körs en i taget per värd. Vm-skalningsuppsättningar parallelliserar tidskrävande analysjobb. Den här lösningen kräver inte batchbearbetning med låg belastning för att begränsa effekten på systemets prestanda under kontorstid.
Azure Communication Services skickar e-postaviseringar via Azure CLI-verktyget (docs). Azure systemtilldelade hanterade identiteter, till exempel
az login --identity, autentisera den virtuella datorn (VM).Analysjobbresultaten går till en Azure Files-resurs via säker SMBv3 (TCP/445), som också använder systemtilldelade hanterade identiteter.
Komponenter
Microsoft Entra-ID eliminerar nätverksbaserat förtroende och tillhandahåller systemtilldelade hanterade identiteter, vilket förbättrar säkerheten.
Azure App Service eliminerar behovet av att administrera ett operativsystem och en server, vilket ökar drifteffektiviteten och flexibiliteten i verksamheten.
Application Gateway är en fullständigt hanterad och skalbar tjänst som tillhandahåller brandvägg för webbprogram och funktioner för omvänd proxy.
Azure Files tillhandahåller datarapporter som publiceras via en hanterad tjänst.
Azure Functions är en händelsedriven, serverlös beräkningsplattform som används för att effektivt utveckla kod på det angivna programmeringsspråket.
En virtuell Azure-dator används av Oracle-databasen och SAS-analysnoderna.
Azure Compute Gallery skapar och lagrar avbildningar för Oracle-databasen och SAS-analysnoderna. Det finns två gallerier: en i den primära regionen och en i haveriberedskapsregionen.
Communication Services skickar e-postmeddelanden med ett CLI-verktyg. Den här tjänsten ersätter
mailxkommandot på AIX.
Alternativ
Ett alternativ är en komplett serverfull arkitektur som behåller alla mellanprogramskomponenter i befintligt format.
Den här lösningen liknar den ursprungliga arkitekturen, som uppfyller ett liknande mandat som många IT-organisationer arbetar under. Den här alternativa lösningen kostar också ungefär samma sak som den ursprungliga arkitekturen, men ger inte de fördelar som den omformaterade arkitekturen ger. Till exempel:
Licensbesparingar: Den alternativa lösningen behåller WebSphere och lägger till fler RHEL-noder.
Drifteffektivitet: Den alternativa lösningen behåller samma antal servrar som ska underhållas.
Affärsflexiitet: Med den alternativa lösningen är rapporteringen endast begränsad till nätter utan autoskalningsdriven heldagsanalys.
Information om scenario
Välj en serverlös eller serverfull modell beroende på portabiliteten för dina befintliga program och teamets arbetsflödesinställningar och tekniköversikt.
Precis som den ursprungliga arkitekturen har den omformaterade arkitekturen en Oracle-databas, men den är omplatformerad till ett RHEL-operativsystem på Azure Virtual Machines. För den fullständigt hanterade Azure App Service i den omformaterade arkitekturen ersätter Red Hat JBoss EAP WebSphere Java-programmet.
Arkitektur (original)
Ladda ned en Visio-fil med den här arkitekturen.
Arbetsflöde
Det här arbetsflödet motsvarar den föregående arkitekturen.
Användarbegäranden och inkommande API-integreringar överförs till den lokala F5-lastbalanseraren på TCP/443 (HTTPS) och sedan omvänd proxy till olika IBM WebSphere-värdbaserade Java-webbtjänster.
Java Web Services frågar Oracle-databasen via TCP/1521. I de flesta fall är den synkrona svarstiden för webbbegäran mindre än 1 sekund (sek) men mer än 300 ms enligt testning och webblogganalys.
En asynkron begäran, till exempel schemaläggning av en batchaktivitet, placerar en post i en Oracle-databastabell som fungerar som en kö i programlagret.
Ett cron-jobb, skrivet i ksh-skript, frågar kön i Oracle-databasen och hämtar SAS-analysjobb som ska köras. Kunden måste utföra batchbearbetning på natten för att begränsa effekten på systemets prestanda under kontorstid.
E-postaviseringar meddelar användare och administratörer via SMTP (TCP/25) om start- och slutförandetider för jobbet samt resultat av lyckade eller misslyckade jobb.
Analysjobbresultatet går till en delad enhet via NFS (TCP+UDP/111 2049) för insamling via SMBv3 (TCP/445).
Information om scenario
Den här ursprungliga arkitekturen utvärderar ett monolitiskt Java-program som körs på IBM WebSphere och utvärderar batchbearbetning från SAS som ksh-skript samordnar. En Oracle-databas som körs på en separat AIX-värd stöder båda programarbetsbelastningarna.
Överväg din ursprungliga arbetsbelastning som körs på AIX för att avgöra om en strategi för omplattformsmigrering passar din migreringsbudget. Arbeta bakåt från önskade resultat för att fastställa en transformerande, programcentrerad migreringsväg till molnet. Se till att det mesta av programkoden är skriven på ett språk som molnbaserade tjänster, till exempel serverlösa arkitekturer och containerorkestrerare, stöder.
I det här scenariot analyserade Tidal Accelerator Java-programkoden och fastställde dess kompatibilitet med JBoss EAP. Tidigt i projektet används Azure Pipelines eller GitHub Actions för att återskapa programmet som en pilot. Kunden kan sedan upprätta flexibilitet från CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans) i en hanterad tjänst, till exempel Azure App Service. Kunden kan inte få den här funktionen i sin lokala WebSphere-miljö.
Det här exemplet behåller Oracle-databasen i den här fasen på grund av mängden PL/SQL som Tidal Accelerator upptäckte under analysfasen. Kundens framtida ansträngningar omfattar migrering från Oracle-databasen på RHEL till en fullständigt hanterad Azure Database for PostgreSQL-databas, införande av Azure Queue Storage och körning av SAS-jobb på begäran. Dessa insatser överensstämmer med kundens tekniköversikt, utvecklingscykler och den affärsriktning som fastställdes i intervjun med programägaren. Följande skärmbild visar en intervju i Tidal Accelerator.
Potentiella användningsfall
Du kan använda den här arkitekturen för AIX till Azure-migreringar som omfattar dataanalys, hantering av kundrelationer (CRM), integreringslager för stordatorer i en hybridmolnkonfiguration och andra anpassade programvarulösningar i scenarier för lagerhantering.
Du kan använda den här arkitekturen för traditionella programarbetsbelastningar med tekniker som:
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Tillförlitlighet
Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.
Den här arkitekturen använder Azure Site Recovery för att spegla databasens virtuella Azure-datorer till en sekundär Azure-region för snabb redundans och haveriberedskap om en hel Azure-region misslyckas. På samma sätt använder Azure Files geo-redundant lagring.
Databearbetningsnoder använder zonredundanta (RA-ZRS) hanterade diskar för att ge återhämtning vid zonfel. Under ett avbrott i en hel region kan du återskapa databearbetningsnoder i en annan region än deras VM-avbildning i det redundanta Azure Compute-galleriet.
Säkerhet
Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.
Den här arkitekturen använder en oföränderlig infrastrukturmetod för programdistributioner och söker proaktivt igenom kod i Azure-pipelines för att skydda känsliga data i produktionen. Den innehåller en skift vänster-metod för säkerhetsgenomsökning och kör ofta CI/CD-pipelineaktiverade distributioner för att förbättra programvarans nuvarande efterlevnad och minska den tekniska skulden.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.
Den här lösningen tar bort så många serverfulla komponenter som möjligt, vilket minskar driftskostnaderna med mer än 70 %. Den här arkitekturen minskar kostnaderna för beräkning och programvarulicensiering.
Driftsäkerhet
Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.
Produktteamet stöder sig själva i Azure, vilket minskar lösningstiden för rapporterade incidentärenden. Dessutom är antalet studsar för biljetter, eller antalet biljetter som har tilldelats från en grupp till en annan, noll eftersom ett produktteam stöder hela programstacken i Azure.
Prestandaeffektivitet
Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Checklista för designgranskning för prestandaeffektivitet.
Kunden antar Azure App Service där det är möjligt så att de automatiskt kan skala upp och skala ut sina beräkningskrav så att de överensstämmer med programmets efterfrågan. Den här elasticiteten säkerställer konsekventa programprestanda under tider med hög belastning. Den här metoden är också kostnadseffektiv.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
Richard Berry| Sr. Program manager
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
Kontakta Microsoft Tidal Cloud-teamet om du vill ha mer information om hur du använder en tidvattenacceleratorlösning.
Mer information om hur du migrerar till Azure finns i teamet för äldre migreringstekniker.