Questo articolo descrive un approccio di migrazione per riformare i carichi di lavoro AIX nel cloud. È possibile usare Funzioni di Azure per un'architettura serverless o usare Azure Macchine virtuali per conservare un modello serverful.
Prendere in considerazione una strategia di migrazione ripiattaforma per i carichi di lavoro AIX per ottimizzare il ritorno sugli investimenti (ROI) quando si esegue la migrazione di applicazioni legacy ad Azure. Le migrazioni a ripiattaforma richiedono modifiche minime, ma offrono vantaggi nativi del cloud simili a una migrazione di refactoring.
I vantaggi di una migrazione a ripiattaforma includono:
- Costo totale di proprietà (TCO) ridotto.
- Miglioramento dell'agilità aziendale.
- Miglioramento della resilienza operativa.
Architettura (ripiattaforma)
Scaricare un file di Visio di questa architettura.
Workflow
Questo flusso di lavoro corrisponde all'architettura precedente.
Le richieste utente e le integrazioni api in ingresso vengono trasferite al gateway di app Azure lication su TCP/443 (HTTPS), che fornisce una funzionalità web application firewall (WAF). gateway applicazione invia le richieste, come richieste proxy inverso, a vari servizi ospitati in Red Hat JBoss Enterprise Application Platform (EAP).
Servizi Web Java interroga il database Oracle (TCP/1521). Il tempo di risposta della richiesta Web sincrona è inferiore a 50 millisecondi (ms).
Una richiesta asincrona, ad esempio la pianificazione di un'attività batch, inserisce un record in una tabella di database che funge da coda all'interno del livello applicazione.
Nota
In futuro, la coda di Azure Archiviazione sostituirà la tabella di database, in modo da poter sempre avere accesso ai processi di analisi in esecuzione.
Il processo cron, scritto nello script KornShell (ksh), viene convertito in Bash ed eseguito in un server Red Hat Enterprise Linux (RHEL) separato in Azure set di scalabilità di macchine virtuali. Il processo cron viene eseguito ogni 15 minuti, incluso l'avvio del sistema, per eseguire query sulla coda nel database Oracle. I processi vengono eseguiti uno alla volta per ogni host. set di scalabilità di macchine virtuali parallelizza i processi di analisi a esecuzione prolungata. Questa soluzione non richiede l'elaborazione batch off-peak per limitare l'effetto sulle prestazioni del sistema durante l'orario di ufficio.
Servizi di comunicazione di Azure invia avvisi di posta elettronica tramite lo strumento dell'interfaccia della riga di comando di Azure (documentazione). Identità gestite assegnate dal sistema di Azure, ad esempio , autenticare la macchina virtuale.Azure system-assigned managed identities, such as
az login --identity, authenticate the virtual machine (VM).I risultati del processo di analisi passano a una condivisione File di Azure tramite SMBv3 sicuro (TCP/445), che usa anche identità gestite assegnate dal sistema.
Componenti
Microsoft Entra ID elimina l'attendibilità basata sulla rete e fornisce identità gestite assegnate dal sistema, migliorando la sicurezza.
app Azure Servizio elimina la necessità di amministrare un sistema operativo e un server, aumentando così l'efficienza operativa e l'agilità aziendale.
gateway applicazione è un servizio completamente gestito e scalabile che fornisce funzionalità web application firewall e proxy inverso.
File di Azure fornisce report sui dati pubblicati tramite un servizio gestito.
Funzioni di Azure è una piattaforma di calcolo serverless basata su eventi usata per sviluppare codice in modo efficiente nel linguaggio di programmazione specificato.
Una macchina virtuale di Azure viene usata dai nodi di analisi del database Oracle e della firma di accesso condiviso.
Azure Compute Gallery compila e archivia le immagini per i nodi di analisi del database Oracle e della firma di accesso condiviso. Esistono due raccolte: una nell'area primaria e una nell'area di ripristino di emergenza.
Servizi di comunicazione invia messaggi di posta elettronica con un'utilità dell'interfaccia della riga di comando. Questo servizio sostituisce il
mailxcomando in AIX.
Alternative
Un'alternativa è un'architettura serverful completa che conserva tutti i componenti middleware così come è.
Questa soluzione è simile all'architettura originale, che soddisfa un simile mandato per il quale molte organizzazioni IT operano. Questa soluzione alternativa costa anche circa la stessa architettura originale, ma non offre i vantaggi offerti dall'architettura ripiattaforma. Ad esempio:
Risparmio di licenze: la soluzione alternativa mantiene WebSphere e aggiunge altri nodi RHEL.
Efficienza operativa: la soluzione alternativa mantiene lo stesso numero di server da gestire.
Agilità aziendale: con la soluzione alternativa, la creazione di report rimane limitata solo alle notti senza analisi di scalabilità automatica, tutto il giorno.
Dettagli dello scenario
Scegliere un modello serverless o serverful a seconda della portabilità delle applicazioni esistenti e della roadmap tecnologica e delle preferenze del flusso di lavoro del team.
Analogamente all'architettura originale, l'architettura ripiattaforma ha un database Oracle, ma è ripiattaforma in un sistema operativo RHEL in Azure Macchine virtuali. Per il servizio app Azure completamente gestito nell'architettura ripiattaforma, Red Hat JBoss EAP sostituisce l'applicazione WebSphere Java.
Architettura (originale)
Scaricare un file di Visio di questa architettura.
Workflow
Questo flusso di lavoro corrisponde all'architettura precedente.
Le richieste degli utenti e le integrazioni api in ingresso vengono trasferite al servizio di bilanciamento del carico F5 locale su TCP/443 (HTTPS) e quindi il proxy inverso a vari servizi Web Java ospitati da IBM WebSphere.
Servizi Web Java interroga il database Oracle tramite TCP/1521. Nella maggior parte dei casi, il tempo di risposta della richiesta Web sincrona è inferiore a 1 secondo (sec), ma più di 300 ms in base all'analisi dei test e dei log Web.
Una richiesta asincrona, ad esempio la pianificazione di un'attività batch, inserisce un record in una tabella di database Oracle che funge da coda all'interno del livello applicazione.
Un processo cron, scritto nello script ksh, esegue una query sulla coda nel database Oracle e seleziona i processi di analisi della firma di accesso condiviso da eseguire. Il cliente deve eseguire l'elaborazione batch di notte per limitare l'effetto sulle prestazioni del sistema durante l'orario di ufficio.
Gli avvisi di posta elettronica notificano agli utenti e agli amministratori tramite SMTP (TCP/25) i tempi di inizio e completamento del processo e i risultati dell'esito positivo o negativo.
I risultati del processo di analisi passano a un'unità condivisa tramite NFS (TCP+UDP/111.2049) per la raccolta tramite SMBv3 (TCP/445).
Dettagli dello scenario
Questa architettura originale valuta un'applicazione Java monolitica che viene eseguita in IBM WebSphere e valuta l'elaborazione batch dalla firma di accesso condiviso che esegue l'orchestrazione degli script ksh. Un database Oracle eseguito in un host AIX separato supporta entrambi i carichi di lavoro dell'applicazione.
Prendere in considerazione il carico di lavoro originale eseguito su AIX per determinare se una strategia di migrazione ripiattaforma è adatta al budget di migrazione. Tornare indietro dai risultati desiderati per determinare un percorso di migrazione trasformativo incentrato sulle applicazioni nel cloud. Assicurarsi che la maggior parte del codice dell'applicazione sia scritta in un linguaggio che supporta servizi nativi del cloud, ad esempio architetture serverless e agenti di orchestrazione contenitori.
In questo scenario Tidal Accelerator analizza il codice dell'applicazione Java e ne determina la compatibilità con JBoss EAP. All'inizio del progetto, Azure Pipelines o GitHub Actions viene usato per ricompilare l'applicazione come progetto pilota. Il cliente può quindi stabilire agilità dalle pipeline di integrazione continua e recapito continuo (CI/CD) in un servizio gestito, ad esempio app Azure Servizio. Il cliente non può ottenere questa funzionalità nell'ambiente WebSphere locale.
Questo esempio mantiene il database Oracle in questa fase a causa della quantità di PL/SQL individuata dall'acceleratore Tidal durante la fase di analisi. Le attività future del cliente includono la migrazione dal database Oracle in RHEL a un database di Database di Azure per PostgreSQL completamente gestito, l'adozione di Archiviazione di accodamento di Azure e l'esecuzione di processi sas completamente su richiesta. Questi sforzi si allineano alla roadmap tecnologica del cliente, ai cicli di sviluppo e alla direzione aziendale determinata nell'intervista al proprietario dell'applicazione. Lo screenshot seguente mostra un'intervista in Tidal Accelerator.
Potenziali casi d'uso
È possibile usare questa architettura per le migrazioni da AIX ad Azure che riguardano l'analisi dei dati, la gestione delle relazioni con i clienti (CRM), i livelli di integrazione del mainframe in una configurazione cloud ibrida e altre soluzioni software personalizzate negli scenari di gestione dell'inventario e del warehouse.
È possibile usare questa architettura per i carichi di lavoro delle applicazioni tradizionali con tecnologie come:
- Oracle Siebel
- E-Business Suite Oracle
- SAS
- IBM BPM
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.
Questa architettura usa Azure Site Recovery per eseguire il mirroring delle macchine virtuali di Azure del database in un'area secondaria di Azure per il failover rapido e il ripristino di emergenza in caso di errore di un'intera area di Azure. Analogamente, File di Azure usa l'archiviazione con ridondanza geografica.
I nodi di elaborazione dati usano dischi gestiti con ridondanza della zona (RA-ZRS) per garantire resilienza durante le interruzioni della zona. Durante un'interruzione dell'intera area, è possibile effettuare nuovamente il provisioning dei nodi di elaborazione dati in un'area diversa dall'immagine della macchina virtuale all'interno della raccolta di calcolo di Azure ridondante.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per la sicurezza.
Questa architettura adotta un approccio di infrastruttura non modificabile alle distribuzioni di applicazioni e analizza in modo proattivo il codice nelle pipeline di Azure per proteggere i dati sensibili nell'ambiente di produzione. Incorpora un approccio di spostamento a sinistra per l'analisi della sicurezza e le distribuzioni abilitate per la pipeline CI/CD per migliorare la conformità del software e ridurre il debito tecnico.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione costi.
Questa soluzione rimuove il maggior numero possibile di componenti serverful, riducendo così i costi operativi di oltre il 70%. Questa architettura riduce i costi di gestione delle licenze software e di calcolo.
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.
Il team del prodotto si supporta in Azure, riducendo il tempo di risoluzione per i ticket degli eventi imprevisti segnalati. Inoltre, il numero di rimbalzi per i ticket o il numero di ticket assegnati da un gruppo a un altro è zero perché un team di prodotto supporta l'intero stack di applicazioni in Azure.
Efficienza prestazionale
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.
Il cliente adotta app Azure Servizio, se possibile, in modo da poter aumentare e aumentare automaticamente i requisiti di calcolo per allinearsi alla domanda di applicazioni. Questa elasticità garantisce prestazioni coerenti dell'applicazione durante i periodi di picco. Questo approccio è anche conveniente.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
Richard Berry | Sr. Program Manager
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Per altre informazioni sull'uso di una soluzione Tidal Accelerator, contattare il team di Microsoft Tidal Cloud.
Per altre informazioni sulla migrazione ad Azure, contattare il team Legacy Migrations Engineering.