LzLabs Software Defined Mainframe (SDM) riduce significativamente il rischio e la complessità del rehosting del carico di lavoro legacy eliminando la necessità di trovare, modificare e ricompilare il codice sorgente delle applicazioni legacy. Questo approccio consente il funzionamento di programmi eseguibili binari z/Architecture a velocità native in computer con architettura x86_64 che eseguono uno stack software di sistemi aperti, rendendo così possibile la modernizzazione di soluzioni legacy.
Architettura
Scaricare un file SVG di questa architettura.
Workflow
- L'accesso alle applicazioni LzLabs SDM avviene esattamente come per le normali applicazioni mainframe tramite un terminale 3270. È possibile usare l'emulatore di terminale desiderato. Per la gestione, l'amministrazione e altre attività, viene usato il client LzWorkbench. Il componente server viene eseguito nella macchina virtuale SDM.
- L'accesso alle porte è in genere configurato in base ai requisiti di sicurezza del cliente.
- Per un'implementazione sicura di SDM, è necessario implementare un front-end dei servizi Web costituito da:
- Gateway applicazione di Azure per le API CICS che accedono dal Web
- Azure Bastion per l'accesso sicuro per la gestione delle macchine virtuali
- Un'istanza di Azure Load Balancer
- È possibile configurare SDM per il failover con il peering di reti virtuali nelle aree di backup, ripristino di emergenza e secondarie di Azure. In questo modo è possibile migliorare la disponibilità di SDM per i carichi di lavoro di produzione perché Azure mantiene una replica coerente nel caso in cui la macchina virtuale iniziale passi in modalità offline.
- La macchina virtuale SDM nell'ambiente di produzione viene replicata e mantenuta sincronizzata nell'area di failover da Azure Site Recovery. Questo servizio mantiene le immagini del disco principale del sistema operativo per l'ambiente di produzione e del disco collegato sincronizzate con l'istanza di SDM nell'area secondaria. La sincronizzazione viene mantenuta per tutti i dischi collegati ad eccezione di quello responsabile dell'elaborazione del file di indice (vedere il punto 10). Site Recovery viene usato anche per mantenere tutte le altre immagini delle macchine virtuali sincronizzate con l'area secondaria.
- Il database in questa architettura è una soluzione PostgreSQL IaaS. Attualmente non è possibile usare il servizio Azure PostgreSQL ed è necessario usare PostgreSQL IaaS con SDM nelle distribuzioni. Ciò è dovuto a una limitazione in Azure PostgreSQL per l'elaborazione dei tipi di dati definiti dall'utente (UDT). L'istanza del database nell'area secondaria viene mantenuta aggiornata con il log delle transazioni write-ahead. Ciò consente il failover tra aree. Quando si verifica il failover, la modalità viene impostata come attiva. Lo stesso processo viene usato per mantenere la coerenza a livello di transazioni del database di failover di produzione nell'area di produzione. Grazie all'uso del log delle transazioni write-ahead per mantenere sincronizzate queste due repliche, il livello database offre disponibilità elevata. Nota: per ottenere prestazioni ottimali, la macchina virtuale del database e la macchina virtuale SDM devono trovarsi in un gruppo di posizionamento di prossimità di Azure.
- Per mantenere l'accesso sicuro al sistema, è necessario distribuire un front-end di servizi Web per l'area di ripristino di emergenza. Molti carichi di lavoro mainframe hanno un livello di servizi Web API per accedere alle transazioni CICS e ai dati DB2.
- Per l'integrazione delle identità RACF e Top Secret tramite le estensioni di Active Directory, LzVault fornisce funzionalità di autenticazione e autorizzazione in Azure per le regole di sicurezza di cui è stata eseguita la migrazione dal mainframe.
- Il server Barman è configurato nel livello dati. In questo modo vengono fornite repliche snapshot del database PostgreSQL per il ripristino temporizzato sia nell'area di produzione che nell'area secondaria.
- Come indicato al punto 5, il disco che gestisce l'elaborazione dei file indicizzati per SDM deve essere sincronizzato tra le aree usando una soluzione di mirroring del database. Ciò è necessario perché Azure Site Recovery non può garantire la coerenza delle transazioni necessaria per un database. Poiché l'elaborazione dei file indicizzati non avviene in PostgreSQL, è necessario usare una soluzione in grado di fornire questa funzionalità.
- Per rispondere alle esigenze di pianificazione dell'elaborazione dei processi batch, è necessario usare un'utilità di pianificazione come App per la logica di Azure o SMA.
- Per fornire disponibilità, ci sono due macchine virtuali SDM distribuite in un set di disponibilità di Azure. Azure Load Balancer fornisce servizi di bilanciamento del carico per le due macchine virtuali. Lo stato viene condiviso tra le due macchine virtuali usando un disco condiviso di Azure. Il disco viene replicato tramite DRDB nell'istanza di ripristino di emergenza.
Componenti
- Macchine virtuali di Azure offre uno dei diversi tipi di risorse di calcolo scalabili e su richiesta offerte da Azure. Una macchina virtuale di Azure offre la flessibilità della virtualizzazione senza che sia necessario acquistare e gestire l'hardware fisico in cui viene eseguita.
- Reti virtuali: il principale blocco predefinito per la rete privata in Rete virtuale di Azure. Il servizio Rete virtuale consente a numerosi tipi di risorse di Azure, tra cui le macchine virtuali, di comunicare in modo sicuro tra loro, con Internet e con le reti locali. Rete virtuale è simile a una rete tradizionale gestita nel data center, ma con i vantaggi aggiuntivi offerti dall'infrastruttura di Azure, tra cui ridimensionamento, disponibilità e isolamento.
- Azure Rete virtuale Interface è un controller di interfaccia di rete (NIC) che consente a una macchina virtuale di Azure di comunicare con Internet, altre risorse in Azure e con le risorse locali. Come illustrato nell'architettura, è possibile aggiungere altre schede di interfaccia di rete alla stessa macchina virtuale, consentendo alle macchine virtuali figlio Solaris di avere un dispositivo di interfaccia di rete e un indirizzo IP dedicati.
- Dischi SSD gestiti di Azure: volumi di archiviazione a livello di blocco gestiti da Azure e usati con Macchine virtuali di Azure. I tipi di dischi disponibili sono disco Ultra, SSD Premium, SSD Standard e HDD Standard. Per questa architettura, è consigliabile usare il tipo SSD Premium o disco Ultra SSD.
- Archiviazione di Azure e File di Azure: offrono condivisioni file completamente gestite nel cloud accessibili tramite il protocollo SMB (Server Message Block) standard del settore. Le condivisioni file di Azure possono essere montate simultaneamente da distribuzioni cloud o locali di Windows, macOS e Linux.
- Azure ExpressRoute consente di estendere le reti locali nel cloud Microsoft tramite una connessione privata fornita da un provider di connettività. Con ExpressRoute è possibile stabilire connessioni ai servizi cloud Microsoft, come Microsoft Azure e Office 365.
- Database SQL di Azure: un motore di database PaaS (Platform as a Service, piattaforma distribuita come servizio) completamente gestito che si occupa della maggior parte delle funzioni di gestione del database, ad esempio aggiornamento, applicazione di patch, backup e monitoraggio, senza l'intervento dell'utente. Il database SQL di Azure è sempre in esecuzione nella versione stabile più recente del motore di database di SQL Server e del sistema operativo con patch con disponibilità del 99,99%. Le funzionalità PaaS integrate nel database SQL di Azure consentono di concentrarsi sulle attività di ottimizzazione e amministrazione del database specifiche del dominio e cruciali per l'azienda.
Dettagli dello scenario
LzLabs Software Defined Mainframe (SDM) è una piattaforma di modernizzazione delle applicazioni mainframe e rehosting dei carichi di lavoro. SDM consente l'esecuzione di applicazioni mainframe legacy in sistemi aperti senza necessità di modifiche al codice sorgente, ricompilazione o conversione dei tipi di dati. SDM include anche funzionalità che consentono di modernizzare correttamente le applicazioni legacy passando a implementazioni e linguaggi contemporanei, senza compromettere l'integrità o il funzionamento del sistema nel suo complesso.
SDM riduce significativamente il rischio e la complessità del rehosting di carichi di lavoro legacy eliminando la necessità di trovare, modificare e ricompilare il codice sorgente delle applicazioni legacy. Questo approccio consente il funzionamento di programmi eseguibili binari z/Architecture a velocità native in computer con architettura x86_64 che eseguono uno stack software di sistemi aperti, rendendo così possibile la modernizzazione di soluzioni legacy.
Potenziali casi d'uso
- Codice sorgente non disponibile. LzLabs è una soluzione per i clienti che hanno carichi di lavoro mainframe ma non dispongono del codice sorgente per le applicazioni in esecuzione. Ciò può accadere se la soluzione è di tipo COTS (Customizable Off-the-Shelf) ed è stata acquistata da un fornitore di software indipendente che non ha fornito il codice sorgente. Poiché inoltre numerose di queste applicazioni basate su COBOL sono state scritte molto tempo fa, il codice sorgente potrebbe essere stato perso o essere introvabile. LzLabs risolve questo problema perché sono necessari solo i moduli di caricamento (file binari) per l'esecuzione in SDM.
- Codice sorgente a disposizione del cliente che vuole eseguire il rehosting. Il cliente potrebbe avere ancora il codice sorgente e semplicemente voler eseguire il rehosting dei carichi di lavoro mainframe per ridurre i costi e usufruire dei vantaggi di una piattaforma cloud come Azure. Il codice COBOL può essere gestito con SDM in un ambiente DevOps moderno.
- Failover. Per aumentare il tempo di attività ed evitare potenziali interruzioni della continuità aziendale, i clienti possono usare LzLabs SDM per un ambiente di failover. In questo caso, i moduli di caricamento vengono caricati in SDM e usati come ambiente secondario se l'ambiente di produzione smette di essere disponibile.
Considerazioni
Alla soluzione si applicano le considerazioni seguenti, basate su Well-Architected Framework di Azure.
Disponibilità
La disponibilità per il livello applicazione viene fornita con Site Recovery, come illustrato nel diagramma. Poiché LzLabs SDM usa PostgreSQL per il livello database, la disponibilità viene fornita con un log delle transazioni write-ahead. Ciò assicura che il database secondario sia coerente a livello di transazioni con il database di produzione.
Operazioni
L'ambiente di Azure nel diagramma viene gestito con i modelli e gli script di Azure Resource Manager portale di Azure. Ciò consente l'amministrazione degli asset (ad esempio il ridimensionamento) e la gestione della sicurezza e dell'accesso. La gestione dell'ambiente SDM effettivo viene fornita tramite lo strumento di amministrazione LzWorkbench. Ciò consente la creazione e la gestione degli ambienti di esecuzione in SDM.
Efficienza prestazionale
Quando si esegue la migrazione di carichi di lavoro mainframe in Azure, tenere presente che il rapporto MIPS per vCPU è compreso tra 50 e 150 MIPS per vCPU. Questo valore può variare a seconda del tipo di carico di lavoro. Sarà necessario profilare il carico di lavoro mainframe per gli ambienti online e batch e quindi ridimensionare le risorse di conseguenza.
Scalabilità
Attualmente, la soluzione per il ridimensionamento di SDM consiste nell'aumentare le prestazioni delle macchine virtuali aggiungendo più vCPU e memoria.
Sicurezza
L'accesso agli asset di Azure viene gestito tramite il portale di Azure e/o Azure Resource Manager. La sicurezza per SDM viene gestita usando il componente Vault di SDM. Questo componente consente di eseguire la migrazione della sicurezza e delle autorizzazioni da RACF o Top Secret in un ambiente basato su LDAP per la gestione in Azure.
Ottimizzazione dei costi
Per stimare il costo dei prodotti e delle configurazioni di Azure, visitare la pagina del calcolatore prezzi di Azure.
Per altre informazioni sui prezzi dei prodotti LzLabs Software Defined Mainframe e dei relativi servizi, visitare il sito Web LzLabs.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Jonathon Frost | Principal Software Engineer
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Per altre informazioni, contattare legacy2azure@microsoft.com
Vedere le risorse seguenti da LzLabs:
- Sito Web LzLabs
- Panoramica del prodotto LzLabs Software Defined Mainframe
- LzWorkbench
- Catalogo video di LzLabs
Vedere la documentazione seguente di Microsoft:
- Macchine virtuali Linux in Azure
- Documentazione di Rete virtuale di Azure
- Documentazione del modello di Azure Resource Manager
- Documentazione di Azure ExpressRoute
- White paper Demystifying mainframe to Azure migration
- Centro migrazione mainframe di Azure
- Panoramica della migrazione del mainframe
- Carichi di lavoro mainframe supportati in Azure
- Rehosting di mainframe in macchine virtuali di Azure
Risorse correlate
Vedere gli articoli correlati seguenti nel Centro architetture di Azure: