Strategie di migrazione delle applicazioni mainframe
Quando la maggior parte dei team esegue la migrazione delle applicazioni da ambienti mainframe ad Azure, in genere segue un approccio pragmatico: riutilizzare ovunque e quando possibile. Avvia quindi una distribuzione in più fasi in cui le applicazioni vengono riscritte o sostituite.
La migrazione delle applicazioni in genere prevede una o più delle seguenti strategie:
Rehost: spostare codice, programmi e applicazioni esistenti dal mainframe. Ricompilare il codice da eseguire in un emulatore mainframe ospitato in un'istanza cloud. Questo approccio in genere inizia con lo spostamento delle applicazioni in un emulatore basato sul cloud e quindi con la migrazione del database in un database basato sul cloud. Alcune attività di progettazione e refactoring sono necessarie con questa strategia, insieme alle conversioni di dati e file.
In alternativa, è possibile eseguire il rehosting mediante un provider di hosting tradizionale. Uno dei principali vantaggi del cloud è l'outsourcing della gestione dell'infrastruttura. Trovare un provider di data center che ospita i carichi di lavoro del mainframe. Questo modello può acquistare tempo, ridurre il blocco fornitore e produrre risparmi intermedi sui costi.
Ritiro: ritirare le applicazioni non più necessarie prima della migrazione.
Ricompilazione: alcune organizzazioni scelgono di riscrivere completamente i programmi usando tecniche moderne. Per i costi e la complessità superiori, questo approccio è meno comune rispetto al trasferimento in modalità lift-and-shift. Spesso dopo questo tipo di migrazione è opportuno iniziare a sostituire i moduli e il codice tramite motori di trasformazione del codice.
Sostituzione: questo approccio sostituisce le funzionalità del mainframe con funzionalità equivalenti nel cloud. Software as a Service (SaaS) è un'opzione. Con Saas si usa una soluzione creata in modo specifico per un problema aziendale, ad esempio finanza, risorse umane, produzione o pianificazione delle risorse aziendali. Inoltre, molte applicazioni specifiche del settore sono ora disponibili per risolvere i problemi che soluzioni mainframe personalizzate usate per risolvere in precedenza.
Per iniziare, pianificare i carichi di lavoro di cui si vuole eseguire la migrazione iniziale e quindi determinare i requisiti per lo spostamento di applicazioni associate, le codebase legacy e i database.
Emulazione di mainframe in Azure
I servizi di Azure possono emulare gli ambienti mainframe tradizionali. È quindi possibile riutilizzare il codice e le applicazioni mainframe esistenti. È possibile emulare componenti server comuni, ad esempio OLTP (Online Transaction Processing), batch e sistemi di inserimento dati.
Sistemi OLTP
Molti mainframe hanno sistemi OLTP che elaborano migliaia o milioni di aggiornamenti per un numero elevato di utenti. Queste applicazioni spesso usano software per l'elaborazione delle transazioni e la gestione di moduli e schermate, come sistemi CICS (Customer Information Control System), IMS (Information Management System) e TIP (Terminal Interface Processor).
Quando si spostano applicazioni OLTP in Azure, gli emulatori per i monitoraggi TP (MainFrame Transaction Processing) possono essere eseguiti come infrastruttura distribuita come servizio (IaaS) usando macchine virtuali (VM) in Azure. I server Web possono anche implementare la gestione dello schermo e la funzionalità del modulo. Combinare questo approccio con le API di database, ad esempio AdO (ActiveX Data Objects), Open Database Connessione ivity (ODBC) e Java Database Connessione ivity (JDBC) per l'accesso ai dati e le transazioni.
Aggiornamenti in batch con vincoli di tempo
Molti sistemi mainframe eseguono aggiornamenti mensili o annuali di milioni di record di account, come quelli usati nel settore bancario, nelle assicurazioni e nella Pubblica Amministrazione. I mainframe gestiscono questi tipi di carichi di lavoro offrendo sistemi di gestione dei dati con una velocità effettiva elevata. I processi batch mainframe sono in genere seriali e dipendono dalle operazioni di input e output al secondo (IOPS) fornite dal backbone mainframe per le prestazioni.
Gli ambienti batch basati sul cloud usano soluzioni di calcolo parallele e reti ad alta velocità per le prestazioni. Se è necessario ottimizzare le prestazioni dei batch, Azure offre numerose opzioni di calcolo, archiviazione e rete.
Sistemi di inserimento dati
I mainframe eseguono l'inserimento di batch di dati di grandi dimensioni da soluzioni per la vendita al dettaglio, i servizi finanziari, la produzione e di altro tipo. Con Azure è possibile usare semplici utilità della riga di comando, ad esempio AzCopy , per copiare dati da e verso una posizione di archiviazione. È anche possibile usare il servizio Azure Data Factory per inserire dati da archivi dati diversi e per creare e pianificare flussi di lavoro basati sui dati.
Oltre agli ambienti di emulazione, Azure fornisce funzionalità di piattaforma distribuita come servizio (PaaS) e servizi di analisi che possono migliorare gli ambienti mainframe esistenti.
Migrazione dei carichi di lavoro OLTP ad Azure
L'approccio lift-and-shift è un'opzione senza codice per eseguire rapidamente la migrazione delle applicazioni esistenti in Azure. Ogni applicazione esegue la migrazione così come è, che offre i vantaggi del cloud senza i rischi o i costi di apportare modifiche al codice. L'uso di un emulatore per il monitoraggio dell'elaborazione delle transazioni mainframe in Azure supporta questo approccio.
Soluzioni di monitoraggio dell'elaborazione delle transazioni sono disponibili da diversi produttori e possono essere eseguite in macchine virtuali, un'opzione di infrastruttura distribuita come servizio (IaaS) in Azure. I diagrammi seguenti illustrano le versioni precedenti e successive di un'applicazione online supportata da IBM DB2, un sistema di gestione di database relazionali (DBMS) in un mainframe IBM z/OS. DB2 per z/OS usa i file VSAM (Virtual Storage Access Method) per archiviare i dati e ISAM (Indexed Sequential Access Method) per i file flat. Questa architettura usa anche CICS per il monitoraggio delle transazioni.
In Azure gli ambienti di emulazione eseguono il gestore TP e i processi batch che usano JCL. Nel livello dati DB2 viene sostituito da database SQL di Azure, anche se è anche possibile usare Microsoft SQL Server, DB2 LUW o Oracle Database. Un emulatore supporta IMS, VSAM e SEQ. Gli strumenti di gestione dei sistemi del mainframe vengono sostituiti da servizi di Azure e software di altri fornitori, che vengono eseguiti in macchine virtuali.
I server Web implementano in genere la funzionalità di gestione dello schermo e immissione di moduli, che è possibile combinare con le API di database, ad esempio ADO, ODBC e JDBC per l'accesso ai dati e le transazioni. L'esatta gamma di componenti IaaS di Azure da usare dipende dal sistema operativo preferito. Ad esempio:
Macchine virtuali basate su Windows: IIS (Internet Information Server) con ASP.NET per la gestione delle schermate e la logica di business. Usare ADO.NET per l'accesso ai dati e le transazioni.
Macchine virtuali basate su Linux: server applicazioni basati su Java, ad esempio la gestione dello schermo dei processi Apache Tomcat e le funzionalità aziendali basate su Java. Usare JDBC per l'accesso ai dati e le transazioni.
Migrazione dei carichi di lavoro batch ad Azure
Le operazioni batch in Azure sono diverse dal tipico ambiente batch nei mainframe. I processi batch mainframe sono generalmente di natura seriale e dipendono dalle operazioni di I/O al secondo fornite dal backbone del mainframe per le prestazioni. Gli ambienti batch basati sul cloud usano soluzioni di calcolo parallele e reti ad alta velocità per le prestazioni.
Per ottimizzare le prestazioni batch con Azure, valutare le opzioni di calcolo, archiviazione, rete e monitoraggio indicate di seguito.
Calcolo
Usa:
Macchine virtuali con la massima velocità di clock. Le applicazioni mainframe sono spesso a thread singolo e le CPU mainframe hanno una velocità di clock elevata.
Macchine virtuali con grandi capacità di memoria per consentire la memorizzazione nella cache dei dati e delle aree di lavoro delle applicazioni.
Macchine virtuali con vCPU di maggiore densità per sfruttare i vantaggi dell'elaborazione multithread, se l'applicazione supporta più thread.
Elaborazione parallela, dal momento che Azure può essere facilmente ampliato per questo tipo di elaborazione, in modo da offrire maggiore potenza di calcolo per un'esecuzione batch.
Archiviazione
Usa:
Dischi SSD Premium di Azure o Archiviazione su disco Ultra per il numero massimo di operazioni di I/O al secondo disponibili.
Striping con più dischi per un aumento delle operazioni di I/O al secondo per ogni dimensione di archiviazione.
Partizionamento dell'archiviazione per distribuire le operazioni di I/O su più dispositivi di archiviazione di Azure.
Rete
- Usare Rete accelerata di Azure per ridurre al minimo la latenza.
Monitoraggio
- Usare gli strumenti di monitoraggio, Monitoraggio di Azure, Application Insights e i log di Azure. Questi strumenti consentono di monitorare le esecuzioni batch con prestazioni eccessiva e ridurre i colli di bottiglia.
Migrazione degli ambienti di sviluppo
Le architetture distribuite del cloud sono basate su un diverso set di strumenti di sviluppo, che offrono i vantaggi delle procedure e dei linguaggi di programmazione moderni. Per semplificare questa transizione, usare un ambiente di sviluppo con altri strumenti progettati per emulare gli ambienti IBM z/OS. L'elenco seguente illustra le opzioni offerte da Microsoft e altri fornitori:
| Componente | Opzioni di Azure |
|---|---|
| z/OS | Windows, Linux o UNIX |
| CICS | Servizi di Azure offerti da Micro Focus, Oracle, GT Software (Fujitsu), TmaxSoft, Raincode e NTT DATA o riscrittura con Kubernetes |
| IMS | Servizi di Azure offerti da Micro Focus e Oracle |
| Assembler | Servizi di Azure offerti da Raincode e TmaxSoft, COBOL, C o Java oppure mapping alle funzioni del sistema operativo |
| JCL | JCL, PowerShell o altri strumenti di scripting |
| COBOL | COBOL, C o Java |
| Natural | Natural, COBOL, C o Java |
| FORTRAN e PL/I | FORTRAN, PL/I, COBOL, C o Java |
| REXX e PL/I | REXX, PowerShell o altri strumenti di scripting |
Migrazione di database e dati
La migrazione delle applicazioni in genere comporta il rehosting del livello dati. È possibile eseguire la migrazione di SQL Server, open source e altri database relazionali a soluzioni completamente gestite in Azure. È possibile usare Istanza gestita di SQL di Azure, Database di Azure per PostgreSQL e Database di Azure per MySQL con Servizio Migrazione del database di Azure.
È ad esempio possibile eseguire la migrazione se il livello dati del mainframe utilizza:
IBM DB2 o un database IMS: usare database SQL di Azure, SQL Server, DB2 LUW o Oracle Database in Azure.
VSAM e altri file flat: usare i file flat ISAM (Indexed Sequential Access Method) per il database SQL di Azure, SQL Server, DB2 LUW o Oracle.
Generation Data Group (GDG): eseguire la migrazione a file in Azure con una convenzione di denominazione ed estensioni per i nomi di file con funzionalità simili ai GDG.
Il livello dati IBM include diversi altri componenti chiave di cui è necessario eseguire la migrazione. Ad esempio, quando si esegue la migrazione di un database, è anche necessario eseguire la migrazione di una raccolta di dati contenuti nei pool, ognuno dei quali contiene dbextent, costituiti da set di dati VSAM z/OS. La migrazione deve includere la directory che identifica i percorsi dei dati nei pool di archiviazione. Inoltre, il piano di migrazione deve prendere in considerazione il log del database, che contiene una registrazione delle operazioni eseguite nel database. Un database può avere uno, due (doppio o alternativo) oppure quattro log (doppio e alternativo).
La migrazione del database include anche questi componenti:
- Gestione database: fornisce l'accesso ai dati nel database. La funzionalità di gestione database viene eseguita in una specifica partizione in un ambiente z/OS.
- Richiedente applicazioni: accetta le richieste dalle applicazioni prima di passarle a un server applicazioni.
- Adattatore risorse online: include i componenti del richiedente applicazioni per l'uso nelle transazioni CICS.
- Adattatore risorse batch: implementa i componenti del richiedente applicazioni per le applicazioni batch z/OS.
- Interactive SQL (ISQL): viene eseguito come applicazione e interfaccia CICS e consente agli utenti di immettere istruzioni SQL o comandi di operatore.
- Applicazione CICS: viene eseguita sotto il controllo di CICS, usando le risorse e le origini dati disponibili in CICS.
- Applicazione batch: esegue la logica di elaborazione senza una comunicazione interattiva con gli utenti, ad esempio per generare aggiornamenti dei dati in blocco o report da un database.
Ottimizzare la scalabilità e la velocità effettiva per Azure
In generale, i mainframe aumentano, mentre il cloud aumenta. Per ottimizzare la scalabilità e la velocità effettiva delle applicazioni in stile mainframe in esecuzione in Azure, è importante comprendere in che modo i mainframe separano e isolano le applicazioni. Un mainframe z/OS usa una funzionalità denominata partizioni logiche (LPAR) per isolare e gestire le risorse per un'applicazione specifica in una singola istanza.
Ad esempio, un mainframe potrebbe usare una partizione logica (LPAR) per un'area CICS con i programmi COBOL associati e una LPAR distinta per DB2. Altri LPAR vengono spesso usati per gli ambienti di sviluppo, test e gestione temporanea.
In Azure è più comune l'uso di macchine virtuali distinte per lo stesso scopo. In genere, nelle architetture di Azure vengono distribuiti un set di macchine virtuali per il livello applicazione, un altro set di macchine virtuali per il livello dati, un ulteriore set per lo sviluppo e così via. È possibile ottimizzare ogni livello di elaborazione usando il tipo più adatto di macchine virtuali e funzionalità per tale ambiente.
Inoltre, ogni livello può anche fornire servizi di ripristino di emergenza appropriati. Ad esempio, le macchine virtuali di produzione e dei database possono richiedere il ripristino a caldo, mentre le macchine virtuali di test e sviluppo supportano il ripristino a freddo.
La figura seguente illustra una possibile distribuzione di Azure usando un sito primario e uno secondario. Nel sito primario, la produzione, la gestione temporanea e il test delle macchine virtuali vengono distribuite con disponibilità elevata. Il sito secondario è destinato al backup e al ripristino di emergenza.
Eseguire una migrazione a fasi ad Azure
Lo spostamento di soluzioni da un mainframe ad Azure potrebbe comportare una migrazione a fasi. Prima di tutto si spostano alcune applicazioni, mentre altre rimangono sul mainframe temporaneamente o in modo permanente. Questo approccio richiede in genere sistemi che consentono alle applicazioni e ai database di interagire tra il mainframe e Azure.
Uno scenario comune consiste nello spostare un'applicazione in Azure, mantenendo i dati usati dall'applicazione sul mainframe. Software specifico consente alle applicazioni in Azure di accedere ai dati dal mainframe. Fortunatamente, una vasta gamma di soluzioni garantisce l'integrazione tra Azure e gli ambienti mainframe esistenti, il supporto per gli scenari ibridi e la migrazione nel corso del tempo. Numerosi partner Microsoft, fornitori di software indipendenti e integratori di sistemi possono offrire tutta l'assistenza necessaria.
Un'opzione è Microsoft Host Integration Server. Questa soluzione fornisce l'architettura DRDA (Distributed Relational Database Architecture) necessaria per le applicazioni in Azure. Consente alle applicazioni di accedere ai dati in DB2 che rimangono nel mainframe. Altre opzioni per l'integrazione dei mainframe in Azure includono soluzioni di IBM, Attunity, Codit, altri fornitori e opzioni open source.
Soluzioni partner
Se si sta valutando una migrazione mainframe, l'ecosistema partner può essere utile.
Azure fornisce un'infrastruttura scalabile, collaudata e a disponibilità elevata per i sistemi attualmente in esecuzione su mainframe. Alcuni carichi di lavoro possono eseguire la migrazione con facilità relativa. È possibile eseguire il rehosting di altri carichi di lavoro che dipendono dal software di sistema legacy, ad esempio CICS e IMS. Usare le soluzioni partner ed eseguirne la migrazione ad Azure nel corso del tempo. Indipendentemente dalla scelta scelta, Microsoft e i nostri partner possono aiutarti a ottimizzare per Azure mantenendo al tempo stesso le funzionalità del software del sistema mainframe.
Altre informazioni
Per ulteriori informazioni, vedi le seguenti risorse: