Il gruppo di disponibilità software offre una piattaforma mainframe 4GL molto diffusa basata sul linguaggio di programmazione naturale e sul database Adabas. Questo articolo fornisce un'architettura per le organizzazioni che usano computer mainframe che eseguono Adabas & Natural e che stanno cercando modi per modernizzare questi carichi di lavoro e spostarli nel cloud.
Architettura dei mainframe
Questo diagramma illustra un esempio di mainframe con i moduli Adabas e Natural di Software AG installati prima della migrazione ad Azure. Questo esempio mostra un'architettura IBM z/OS.
Scaricare un file di Visio di questa architettura.
Workflow
R. L'input si verifica su TCP/IP, inclusi TN3270 e HTTP(S). L'input nel mainframe usa protocolli mainframe standard.
B. La ricezione di applicazioni può essere batch o sistemi online.
C. Natural, COBOL, PL/I, Assembler o altri linguaggi compatibili vengono eseguiti in un ambiente abilitato.
D. I dati e i servizi di database comunemente usati sono sistemi di database gerarchici/di rete e tipi di database relazionali.
E. I servizi comuni includono l'esecuzione del programma, le operazioni di I/O, il rilevamento degli errori e la protezione all'interno dell'ambiente.
F. Il middleware e le utilità gestiscono servizi come archiviazione su nastro, accodamento, output e servizi Web all'interno dell'ambiente.
G. I sistemi operativi forniscono l'interfaccia tra il motore e il software in esecuzione.
H. Le partizioni sono necessarie per eseguire carichi di lavoro separati e separare i tipi di lavoro all'interno dell'ambiente.
Architettura di Azure
Questo diagramma illustra come eseguire la migrazione dell'architettura legacy ad Azure usando un approccio di refactoring per modernizzare il sistema:
Scaricare un file di Visio di questa architettura.
Workflow
Input. L'input si verifica in genere tramite Azure ExpressRoute da client remoti o tramite altre applicazioni attualmente in esecuzione in Azure. In entrambi i casi, le connessioni TCP/IP sono i mezzi principali di connessione al sistema. La porta TLS 443 consente l'accesso alle applicazioni basate sul Web. È possibile lasciare praticamente invariato il livello di presentazione delle applicazioni basate sul Web per ridurre al minimo il training degli utenti. In alternativa, è possibile aggiornare questo livello con framework di esperienza utente moderni in base alle esigenze. Per l'accesso amministratore alle macchine virtuali, è possibile usare gli host Azure Bastion per ottimizzare la sicurezza riducendo al minimo le porte aperte.
Accesso in Azure. In Azure l'accesso ai cluster di calcolo dell'applicazione viene fornito tramite un servizio di bilanciamento del carico di Azure. Questo approccio consente alle risorse di calcolo con scalabilità orizzontale di elaborare il lavoro di input. È possibile usare i servizi di bilanciamento del carico di livello 7 (livello applicazione) o livello 4 (livello di protocollo di rete). Tuttavia, il tipo di servizio di bilanciamento del carico usato dipende dal modo in cui l'input dell'applicazione raggiunge il punto di ingresso del cluster di calcolo. È consigliabile usare app Azure lication Gateway con funzionalità web application firewall per il traffico di livello 7.
Cluster di calcolo delle applicazioni. L'architettura supporta le applicazioni eseguite in un contenitore che può essere distribuito in servizio Azure Kubernetes (servizio Azure Kubernetes). I componenti di Adabas & Natural possono essere eseguiti all'interno di contenitori basati su Linux. È possibile riprogettare le applicazioni legacy in architetture moderne basate su contenitori e operare sul servizio Azure Kubernetes.
Emulazione del terminale ApplinX (Software AG). ApplinX è una tecnologia basata su server che fornisce connettività Web e integrazione in applicazioni di sistema di base senza richiedere modifiche alle applicazioni. Natural Online consente agli utenti online di connettersi alle applicazioni Naturali tramite un Web browser. Senza ApplinX, gli utenti devono connettersi con il software di emulazione del terminale tramite SSH. Entrambi i sistemi vengono eseguiti in contenitori.
EntireX (Software AG). EntireX consente di connettere facilmente i servizi eseguiti in Integration Server a programmi cruciali scritti in linguaggi come COBOL e Natural. Natural Business Services consente all'API di accedere alle funzioni aziendali programmate in Natural. Entrambi i sistemi vengono eseguiti in contenitori.
Adabas (Software AG). Adabas è un sistema di gestione di database NoSQL ad alte prestazioni. Il batch naturale è un componente dedicato per l'esecuzione di processi batch. I processi batch naturali, pianificati da un sistema di pianificazione dei processi batch scelto, devono essere eseguiti nello stesso nodo del database Adabas per evitare effetti sulle prestazioni.
Archiviazione. I servizi dati usano una combinazione di archiviazione ad alte prestazioni (SSD Ultra/Premium), archiviazione file (NetApp) e archiviazione standard (BLOB, archivio, backup) che possono essere ridondanti locali o con ridondanza geografica, a seconda dell'uso. I sistemi operativi node usano l'archiviazione su disco gestito. Tutti i dati persistenti, ad esempio file di database, log di protezione, dati dell'applicazione e backup, usano Azure NetApp Files. Il servizio Azure Kubernetes gestisce i volumi del sistema operativo archiviati in dischi gestiti. Tutti i dati critici per l'azienda dai database, inclusi ASSO, DATI, file DI LAVORO e log di protezione di Adabas, devono essere scritti in volumi separati in Azure NetApp Files.
CONNX. Il modulo CONNX per Adabas offre accesso in lettura/scrittura in tempo reale e altamente sicuro alle origini dati adabas su OS/390, z/OS, VSE, Linux, Solaris, HP-UX, AIX e Windows tramite .NET, ODBC, OLE DB e JDBC. CONNX offre un livello di virtualizzazione dei dati che usa connettori ad Adabas e altre origini dati, ad esempio database SQL di Azure, Database di Azure per PosgreSQL e Database di Azure per MySQL.
Componenti
Azure ExpressRoute estende le reti locali nel cloud Microsoft tramite una connessione privata facilitata da un provider di connettività. È possibile usare ExpressRoute per stabilire connessioni ai servizi cloud Microsoft come Azure e Office 365. In alternativa, o come backup, è possibile stabilire connessioni con Azure Gateway VPN. È tuttavia consigliabile usare ExpressRoute in modo che sia possibile connettersi all'ambiente di Azure tramite una connessione privata ad alta velocità con sicurezza avanzata.
Il servizio Azure Kubernetes è un servizio Kubernetes completamente gestito per la distribuzione e la gestione di applicazioni in contenitori. Il servizio Azure Kubernetes offre kubernetes serverless, integrazione continua integrata e recapito continuo (CI/CD) e sicurezza e governance di livello aziendale. In questo scenario, i contenitori Adabas e Natural vengono distribuiti nel servizio Azure Kubernetes.
Il servizio Azure Managed Disks offre volumi di archiviazione a livello di blocco gestiti da Azure e usati con le macchine virtuali di Azure. Sono disponibili vari tipi: dischi Ultra, SSD Premium, SSD Standard e HDD Standard. I dischi SSD vengono usati in questa architettura. In questo scenario, tutti i volumi del sistema operativo vengono archiviati nei dischi gestiti di Azure.
Azure NetApp Files offre condivisioni file di Azure di livello aziendale basate su NetApp. Azure NetApp Files semplifica la migrazione e l'esecuzione di applicazioni complesse basate su file senza modificare il codice. In questo scenario, tutti i dati persistenti, ad esempio i file di database, i log di protezione, i dati dell'applicazione e i file di backup, usano Azure NetApp Files.
Dettagli dello scenario
Le applicazioni in esecuzione su computer mainframe sono state al centro della maggior parte delle operazioni aziendali per quasi 50 anni. Anche se questi sistemi mainframe hanno fornito un'affidabilità notevole nel corso degli anni, sono diventati piuttosto problematici perché sono rigidi e, in alcuni casi, difficili da gestire e costose da gestire.
Molte organizzazioni cercano modi per modernizzare questi sistemi. Stanno cercando modi per liberare le risorse vincolate necessarie per gestire questi sistemi, controllarne i costi e ottenere maggiore flessibilità nelle interazioni con i sistemi.
Il gruppo di disponibilità software offre una piattaforma mainframe 4GL molto diffusa basata sul linguaggio di programmazione naturale e sul database Adabas.
Due dei modelli di razionalizzazione del cloud consentono di eseguire applicazioni Adabas & Natural in Azure: rehosting e refactoring. Questo articolo descrive come effettuare il refactoring di un'applicazione usando contenitori gestiti nel servizio Azure Kubernetes. Per altre informazioni, vedere Approccio basato su contenitori più avanti in questo articolo.
Potenziali casi d'uso
Questa architettura si applica a qualsiasi organizzazione che usa computer mainframe che eseguono Adabas & Natural e che prevede di modernizzare questi carichi di lavoro e di spostarli nel cloud.
Considerazioni
Approccio basato su contenitori
Per sfruttare al meglio la flessibilità, l'affidabilità e le funzionalità di Azure, è necessario riprogettare le applicazioni mainframe. È consigliabile riscrivere le applicazioni monolitiche come microservizi e usare un approccio basato su contenitori per la distribuzione. Un contenitore aggrega tutto il software necessario per l'esecuzione in un unico pacchetto eseguibile. Include il codice di un'applicazione insieme ai file di configurazione, alle librerie e alle dipendenze correlati necessari per eseguire l'app. Le applicazioni in contenitori sono rapide da distribuire e supportare procedure DevOps comuni, come l'integrazione continua (CI) e la distribuzione continua (CD).
I contenitori Adabas & Natural vengono eseguiti in pod, ognuno dei quali esegue un'attività specifica. I pod sono unità di uno o più contenitori che rimangono insieme nello stesso nodo e condividono risorse come il nome host e l'indirizzo IP. Poiché sono separati dalla piattaforma sottostante, i componenti nei pod vengono ridimensionati in modo indipendente e supportano una maggiore disponibilità. Un'applicazione in contenitori è anche portabile: viene eseguita in modo uniforme e coerente su qualsiasi infrastruttura.
I servizi in contenitori e i relativi componenti di rete e archiviazione associati devono essere orchestrati e gestiti. È consigliabile usare il servizio Azure Kubernetes, un servizio Kubernetes gestito che automatizza la gestione dei cluster e delle risorse. Si definisce il numero di nodi necessari e il servizio Azure Kubernetes si adatta ai contenitori nei nodi giusti per sfruttare al meglio le risorse. Il servizio Azure Kubernetes supporta anche implementazioni e rollback automatizzati, individuazione dei servizi, bilanciamento del carico e orchestrazione dell'archiviazione. Il servizio Azure Kubernetes supporta la riparazione automatica: se un contenitore non riesce, il servizio Azure Kubernetes ne avvia uno nuovo. Inoltre, è possibile archiviare in modo sicuro i segreti e le impostazioni di configurazione all'esterno dei contenitori.
Il diagramma dell'architettura in questo articolo illustra un'implementazione basata su contenitori di Adabas & Natural. Quando si configura il servizio Azure Kubernetes, si specificano le dimensioni delle macchine virtuali di Azure per i nodi, che definisce le CPU di archiviazione, la memoria e il tipo, ad esempio unità SSD (Solid State Drive) ad alte prestazioni o normali unità disco rigido (HDD). Naturale deve essere eseguito su tre o più istanze di VM (nodi) per aumentare la scalabilità e la disponibilità dell'interfaccia utente (Natural online più ApplinX) e il livello API (Servizi naturali più EntireX).
Nel livello dati, Adabas viene eseguito nel cluster del servizio Azure Kubernetes, che viene ridimensionato automaticamente in base all'uso delle risorse. È possibile eseguire più componenti di Adaba nello stesso pod o, per una maggiore scalabilità, il servizio Azure Kubernetes può distribuirli tra più nodi nel cluster. Adabas usa Azure NetApp Files, un servizio di archiviazione file a consumo a prestazioni elevate, per tutti i dati persistenti, ad esempio file di database, log di protezione, dati delle app e backup.
Inserire pod batch naturali nella stessa zona di disponibilità (data center) dei pod Adabas. È consigliabile usare i gruppi di posizionamento di prossimità per inserire adabas e pod batch naturali nello stesso pool di nodi all'interno della stessa zona di disponibilità.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.
Questa architettura è basata principalmente su Kubernetes, che include componenti di sicurezza come gli standard di sicurezza dei pod e i segreti. Azure offre funzionalità aggiuntive come Microsoft Entra ID, Microsoft Defender per contenitori, Criteri di Azure, Azure Key Vault, gruppi di sicurezza di rete e aggiornamenti del cluster orchestrati. I contenitori sottoposti a refactoring devono essere distribuiti in un cluster del servizio Azure Kubernetes privato con accesso in ingresso tramite un server API privato e indirizzi IP interni. Tutto il traffico in uscita deve essere instradato attraverso un livello firewall in uscita.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda la riduzione delle spese non necessarie e il miglioramento dell'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.
Usare il ridimensionamento automatico del cluster e il ridimensionamento automatico orizzontale dei pod per ridimensionare il numero di pod e nodi in base alle condizioni del traffico. I pod Adabas possono usare il ridimensionamento automatico orizzontale dei pod per l'ottimizzazione dei costi.
Usare il ridimensionamento automatico verticale dei pod per analizzare e impostare le risorse di CPU e memoria richieste dai pod. Questo approccio ottimizza l'allocazione delle risorse.
Scegliere le dimensioni della macchina virtuale appropriate per i pool di nodi, in base ai requisiti del carico di lavoro.
Creare più pool di nodi con dimensioni di vm diverse per carichi di lavoro specifici. Usare etichette di nodo, selettori di nodo e regole di affinità per ottimizzare l'allocazione delle risorse.
Scegliere i livelli di servizio e le dimensioni del pool di capacità corretti per Azure NetApp Files. Per consigli sulla gestione dei costi, vedere Modello di costo per Azure NetApp Files.
Usare la capacità riservata per Azure NetApp Files.
Per monitorare e ottimizzare i costi, usare strumenti di gestione dei costi come Azure Advisor, prenotazioni di Azure e piani di risparmio di Azure.
Per stimare i costi di utilizzo, usare il calcolatore dei costi di Azure.
Per migliorare il rilevamento e la gestione dei costi, usare i tag di Azure per associare le risorse del servizio Azure Kubernetes a carichi di lavoro specifici.
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.
Il refactoring supporta un'adozione del cloud più rapida. Promuove anche l'adozione dei principi di lavoro DevOps e Agile. È possibile usufruire della massima flessibilità delle opzioni di sviluppo e distribuzione di produzione.
Efficienza delle prestazioni
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.
Kubernetes offre un'utilità di scalabilità automatica del cluster. Il ridimensionamento automatico regola il numero di nodi in base alle risorse di calcolo richieste nel pool di nodi. Monitora il server API metriche ogni 10 secondi per eventuali modifiche necessarie nel numero di nodi. Se l'utilità di scalabilità automatica del cluster determina che è necessaria una modifica, il numero di nodi nel cluster servizio Azure Kubernetes viene aumentato o ridotto di conseguenza.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Marlon Johnson | Senior TPM
Contributor (Collaboratore):
- Francesco Simy Nazareth | Specialista della tecnologia
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Per ulteriori informazioni, contatta legacy2azure@microsoft.com.
Altre risorse:
- Adabas & Natural
- Servizio Azure Kubernetes
- Documentazione di Azure NetApp Files
- Rehosting di mainframe in macchine virtuali di Azure
- Spostare il calcolo del mainframe in Azure Macchine virtuali