Redigera

Använda LzLabs Software Defined Mainframe (SDM) i en distribution av virtuella Azure-datorer

Azure Virtual Machines
Azure Database for PostgreSQL
Azure Virtual Network
Azure Resource Manager

LzLabs Software Defined Mainframe (SDM) minskar avsevärt risken och komplexiteten för äldre arbetsbelastningsvärdar genom att eliminera behovet av att hitta, ändra och kompilera om källkoden för äldre program. Den här metoden gör det möjligt för binära körbara z/Architecture-program att köras i inbyggda hastigheter på x86_64 arkitekturdatorer som kör en open systems-programvarustack, vilket öppnar vägen till äldre modernisering.

Arkitektur

Diagram som visar arkitekturen och dataflödet som beskrivs i detalj av den tillhörande artikeltexten.Ladda ned en SVG-fil med den här arkitekturen.

Arbetsflöde

  1. LzLabs SDM-program nås precis som vanliga stordatorprogram via en 3270-terminal. Du kan använda valfri terminalemulator som du vill. LzWorkbench-klienten används för hantering, administration och andra aktiviteter. Serverkomponenten körs på den virtuella SDM-datorn.
  2. Portåtkomsten är vanligtvis konfigurerad för att anpassas efter kundens säkerhetskrav.
  3. För en säker implementering av SDM bör en klientdel för webbtjänster implementeras som består av:
  4. SDM kan konfigureras för redundans med VNet-peering (virtuellt nätverk) till säkerhetskopiering, haveriberedskap (DR) och sekundära Azure-regioner. Detta förbättrar tillgängligheten för SDM för produktionsarbetsbelastningar eftersom Azure behåller en konsekvent replik om den första virtuella datorn kopplas från.
  5. Den virtuella SDM-datorn i produktionsmiljön replikeras och synkroniseras i redundansregionen av Azure Site Recovery. Den här tjänsten håller os-huvuddisken för produktion och de anslutna diskavbildningarna synkroniserade med SDM för sekundär region. Den gör detta för alla anslutna diskar utom den disk som ansvarar för bearbetning av indexfiler (se objekt 10). Site Recovery används också för att synkronisera alla andra VM-avbildningar med den sekundära regionen.
  6. Databasen i den här arkitekturen är PostgreSQL IaaS. För närvarande går det inte att använda Azure PostgreSQL-tjänsten och PostgreSQL IaaS måste användas med SDM i distributioner. Detta beror på en begränsning i Azure PostgreSQL för bearbetning av användardefinierade datatyper (UDT). Databasinstansen i den sekundära regionen hålls uppdaterad med transaktionsloggen Skriv framåt. Detta möjliggör redundans mellan regioner. När redundansväxlingen inträffar ställs läget in på aktiv. Samma process används för att hålla produktionsredundansdatabasen transaktionsmässigt konsekvent inom produktionsregionen. Genom att använda transaktionsloggen Write Ahead (Skriv framåt) för att synkronisera dessa två repliker har databasnivån hög tillgänglighet. Observera: För bästa prestanda måste den virtuella databasdatorn och den virtuella SDM-datorn placeras i en närhetsplaceringsgrupp i Azure.
  7. En klientdel för webbtjänster måste distribueras för DR-regionen för att upprätthålla säker åtkomst till systemet. Många stordatorarbetsbelastningar har ett API-webbtjänstlager för åtkomst till CICS-transaktioner och DB2-data.
  8. LzVault tillhandahåller autentisering och auktorisering i Azure för de säkerhetsregler som migreras från stordatorn för RACF- och Top Secret-identitetsintegrering med Active Directory-tillägg.
  9. Barman-servern har konfigurerats på datanivån. Detta ger ögonblicksbildsrepliker av PostgreSQL-databasen för återställning till tidpunkt inom både produktionsregionen och den sekundära regionen.
  10. Som nämnts i objekt 5 måste disken som underhåller den indexerade filbearbetningen för SDM synkroniseras mellan regioner med hjälp av en lösning för databasspegling. Det beror på att Azure Site Recovery inte kan garantera den transaktionskonsekvens som behövs för en databas. Eftersom den indexerade filbearbetningen inte finns i PostgreSQL måste en lösning användas som kan tillhandahålla detta.
  11. För att hantera schemaläggningen av batchjobbsbearbetning måste en schemaläggare som Azure Logic Apps eller SMA användas.
  12. För att tillhandahålla tillgänglighet finns det två virtuella SDM-datorer som distribueras till en Azure-tillgänglighetsuppsättning. Azure Load Balancer tillhandahåller belastningsutjämningstjänster till de två virtuella datorerna. Tillståndet delas mellan de två virtuella datorerna med hjälp av en delad Azure-disk. Detta replikeras via DRDB till DR-instansen.

Komponenter

  • Azure Virtual Machines (VM) är en av flera typer av skalbara beräkningsresurser på begäran som Azure erbjuder. En virtuell dator i Azure ger dig virtualiseringsflexibilitet utan att du behöver köpa och underhålla den fysiska maskinvara som den virtuella datorn körs på.
  • Virtuella nätverk (VNet) är den grundläggande byggstenen för ditt privata nätverk i Azure Virtual Network. Virtual Network gör det möjligt för många typer av Azure-resurser, inklusive virtuella datorer, att kommunicera säkert med varandra, Internet och lokala nätverk. Virtual Network liknar ett traditionellt nätverk som du skulle använda i ditt eget datacenter, men med de extra fördelarna med Azures infrastruktur, till exempel skalning, tillgänglighet och isolering.
  • Azure Virtual Network Interface (NIC) är ett nätverksgränssnitt som gör det möjligt för en virtuell Azure-dator att kommunicera med Internet, andra resurser i Azure och lokala resurser. Som du ser i den här arkitekturen kan du lägga till fler nätverkskort till samma virtuella dator, vilket gör att de underordnade virtuella Solaris-datorerna kan ha en egen dedikerad nätverksgränssnittsenhet och IP-adress.
  • Azure SSD-hanterade diskar är lagringsvolymer på blocknivå som hanteras av Azure och används med Azure Virtual Machines. De tillgängliga typerna av diskar är Ultra Disk, Premium SSD, Standard SSD och Standard Hårddiskar (HDD). För den här arkitekturen rekommenderar vi antingen Premium SSD eller Ultra Disk SSD.
  • Azure Storage och Azure Files erbjuder fullständigt hanterade filresurser i molnet som är tillgängliga via branschstandardprotokollet Server Message Block (SMB). Azure-filresurser kan monteras samtidigt av molndistributioner eller lokala distributioner av Windows, Linux och macOS.
  • Med Azure ExpressRoute kan du utöka dina lokala nätverk till Microsoft-molnet via en privat anslutning som underlättas av en anslutningsleverantör. Med ExpressRoute kan du upprätta anslutningar till Microsofts molntjänster, till exempel Microsoft Azure och Office 365.
  • Azure SQL Database är en fullständigt hanterad PaaS-databasmotor (plattform som en tjänst) som hanterar de flesta databashanteringsfunktioner utan inblandning av användaren, inklusive uppgradering, korrigering, säkerhetskopiering och övervakning. Azure SQL Database körs alltid på den senaste stabila versionen av SQL Server-databasmotorn och det korrigerade operativsystemet med 99,99 procents tillgänglighet. PaaS-funktioner som är inbyggda i Azure SQL Database gör att du kan fokusera på de domänspecifika databasadministrations- och optimeringsaktiviteter som är viktiga för ditt företag.

Scenarioinformation

LzLabs Software Defined Mainframe (SDM) är en plattform för arbetsbelastningsomvärdning och modernisering av stordatorprogram. SDM gör det möjligt för äldre stordatorprogram att köras på öppna system utan krav på ändringar i källkoden, omkompilering eller konvertering av datatyper. SDM har också funktioner som gör att äldre program på ett smidigt sätt kan moderniseras till moderna språk och implementeringar, utan att äventyra systemets integritet eller drift som helhet.

SDM minskar avsevärt risken och komplexiteten för äldre arbetsbelastningsvärdar genom att eliminera behovet av att hitta, ändra och kompilera om källkoden för äldre program. Den här metoden gör det möjligt för binära körbara z/Architecture-program att köras i inbyggda hastigheter på x86_64 arkitekturdatorer som kör en open systems-programvarustack, vilket öppnar vägen till äldre modernisering.

Potentiella användningsfall

  • Ingen källkod. LzLabs är en lösning för kunder som har stordatorarbetsbelastningar men inte har källkoden för de program som körs. Detta kan inträffa om lösningen var en anpassningsbar färdig lösning (COTS) som köpts från en oberoende programvaruleverantör som inte använde källkoden till IP-adressen. Eftersom många av dessa COBOL-baserade program skrevs för länge sedan kunde källkoden också ha gått förlorad eller felplacerad. LzLabs löser det här problemet eftersom allt som behövs är inläsningsmoduler (binärfiler) för körning i SDM.
  • Kunden har källkod och vill ha en ny värd. Kunden kanske fortfarande har källkoden och helt enkelt vill byta värd för sina stordatorarbetsbelastningar för att minska kostnaderna och dra nytta av fördelarna med en molnplattform som Azure. COBOL-koden kan underhållas i SDM i en modern DevOps-miljö.
  • Failover. För att öka drifttiden och undvika potentiella störningar i affärskontinuiteten kan kunderna använda LzLabs SDM för en redundansmiljö. I det här fallet läses in inläsningsmodulerna i SDM och används som en sekundär miljö om produktionsmiljön blir otillgänglig.

Överväganden

Följande överväganden, som baseras på Azure Well-Architected Framework, gäller för den här lösningen.

Tillgänglighet

Tillgänglighet för programnivån tillhandahålls med Site Recovery som visas i diagrammet. Eftersom LzLabs SDM utnyttjar PostgreSQL för databasnivån tillhandahålls tillgänglighet med en transaktionslogg för framåtskrivning. Detta säkerställer att den sekundära databasen är transaktionsmässigt konsekvent med produktionsdatabasen.

Operations

Azure-miljön i diagrammet hanteras antingen med mallar och skript för Azure Portal eller Azure Resource Manager (ARM). Detta möjliggör administration av tillgångar (till exempel storleksändring) och hantering av säkerhet och åtkomst. Hantering av den faktiska SDM-miljön tillhandahålls via administrationsverktyget för LzWorkbench. På så sätt kan du skapa och hantera körningsmiljöer i SDM.

Prestandaeffektivitet

När du migrerar stordatorarbetsbelastningar till Azure bör du tänka på att MIPS per vCPU-förhållandet varierar från 50 till 150 MIPS per vCPU. Detta kan variera beroende på typen av arbetsbelastning. Du måste profilera stordatorns arbetsbelastning för online- och batchmiljöer och sedan ändra storlek på resurserna därefter.

Skalbarhet

För närvarande är lösningen för att skala SDM att skala upp de virtuella datorerna genom att lägga till fler virtuella processorer och minne.

Säkerhet

Åtkomst till Azure-tillgångar hanteras via Azure Portal och/eller Azure Resource Manager. Säkerhet för SDM hanteras med hjälp av valvkomponenten i SDM. Detta migrerar säkerhet och behörigheter från RACF eller Topphemlighet till en LDAP-baserad miljö för hantering i Azure.

Kostnadsoptimering

Om du vill beräkna kostnaden för Azure-produkter och -konfigurationer går du till priskalkylatorn för Azure.

Mer information om priser för LzLabs Software Defined Mainframe-produkter och deras relaterade tjänster finns på LzLabs webbplats.

Deltagare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

  • Om du vill ha mer information kontaktar du legacy2azure@microsoft.com

Se följande resurser från LzLabs:

Se följande dokumentation från Microsoft:

Se följande relaterade artiklar i Azure Architecture Center: