Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Best practice
Questa sezione descrive una serie di best practice per affrontare le principali sfide legate alla ripiattaforma dei carichi di lavoro mainframe in ambienti cloud mantenendo il database su Db2 for z/OS.
Latenza di rete
Per prevedere con precisione l'impatto sulla latenza della separazione dell'applicazione dal database Db2 durante un processo di ripiattaforma, si consiglia di condurre una valutazione approfondita del numero di chiamate Db2 sia per le transazioni che per i processi batch. Questa valutazione deve essere eseguita utilizzando dati di traccia e deve includere i seguenti passaggi:
-
Raccogli dati di traccia: raccogli tracce dettagliate delle transazioni rappresentative e dei lavori in batch e assicurati che le tracce acquisiscano tutte le interazioni Db2, incluse le entrate e le uscite.
-
Analizza i dati di traccia: conta il numero di entrate e uscite Db2 per ogni transazione e processo batch e calcola il numero medio di interazioni Db2 per transazione e processo batch.
-
Misura i tempi di risposta attuali: verifica se l'accesso a Db2 è in linea con il contratto sul livello di servizio (SLA) dell'applicazione.
-
Stima della latenza di rete: determina la latenza di rete prevista tra l'applicazione riplatformata e il database Db2. Prendi in considerazione fattori come la distanza fisica, l'infrastruttura di rete e i potenziali colli di bottiglia.
-
Calcola l'impatto potenziale: per ogni transazione e processo batch, moltiplica il numero di entrate e uscite da Db2 per la latenza di rete stimata. Aggiungi questo tempo calcolato ai tempi di risposta correnti per prevedere il nuovo tempo di elaborazione totale.
-
Valuta i risultati: valuta se l'aumento di latenza previsto è accettabile per i requisiti aziendali e identifica eventuali transazioni o processi che potrebbero richiedere l'ottimizzazione o la riprogettazione per mitigare i problemi di latenza.
-
Prendi in considerazione le strategie di mitigazione: esplora opzioni come il pool di connessioni, la memorizzazione nella cache o il recupero di dati in batch per ridurre il numero di interazioni Db2 individuali. Valuta la possibilità di spostare i dati a cui si accede di frequente più vicino al livello dell'applicazione.
Seguendo questi passaggi, sarai in grado di prendere decisioni basate sui dati sulla fattibilità della tua strategia di replatforming e identificare eventuali problemi di prestazioni prima che abbiano un impatto sull'ambiente di produzione. Questo approccio contribuirà a garantire una transizione fluida mantenendo al contempo livelli di prestazioni accettabili per le applicazioni dipendenti dal database.
Sicurezza
-
Proteggi la build della tua applicazione: utilizza una sottorete privata nel cloud privato virtuale (VPC) da AWS CodeBuild eseguire per garantire l'isolamento e una maggiore sicurezza. Implementa un contesto affidabile Db2 dalla CodeBuild sottorete CIDR per un accesso sicuro al database durante il processo di creazione.
-
Proteggi il tuo ambiente di runtime: utilizza un contesto affidabile Db2 dalla sottorete di runtime CIDR per connessioni sicure al database.
-
Gestisci le credenziali del database in modo sicuro: implementa una pianificazione regolare di rotazione delle credenziali per ridurre al minimo il rischio di accesso non autorizzato. Archivia le credenziali Db2 in modo sicuro in. Gestione dei segreti AWS
-
Stabilisci la sicurezza della rete: implementa solide regole di segmentazione della rete e firewall per proteggere sia gli ambienti di compilazione che quelli di runtime. Utilizza la combinazione corretta di AWS Direct Connect e AWS Site-to-Site VPN per raggiungere il livello di sicurezza necessario.
-
Applica la crittografia: applica la crittografia per i dati in transito tra l'applicazione e Db2 for z/OS.
Governance delle applicazioni
-
Stabilisci una fonte affidabile: stabilisci la nuova gestione della configurazione del software (SCM), ad esempio, GitHub come unica fonte di verità per il codice dell'applicazione migrato. Ciò garantisce la coerenza ed elimina le discrepanze di versione tra gli ambienti cloud e mainframe durante il periodo di transizione.
-
Aggiorna il processo di gestione delle modifiche: aggiorna il processo di gestione delle modifiche per prendere in considerazione le modifiche al codice in questo nuovo paradigma a doppio ambiente. Questo processo dovrebbe includere:
-
Flussi di lavoro di approvazione chiari per le modifiche al codice.
-
Revisioni obbligatorie del codice prima di unirlo al ramo principale.
-
Procedure di distribuzione sincronizzate per garantire che entrambi gli ambienti ricevano aggiornamenti contemporaneamente.
-
Meccanismi di ripristino in caso di problemi in entrambi gli ambienti.
-
Elasticità
L'elasticità del cloud computing introduce un cambio di paradigma che altera in modo significativo la struttura dei costi e la gestione delle risorse del mainframe. A differenza dell'ambiente mainframe tradizionale, che ha capacità fissa e modelli di prezzo basati sui picchi, le piattaforme cloud offrono una scalabilità dinamica e un pay-as-you-go approccio che può potenzialmente portare a notevoli risparmi sui costi e a una migliore efficienza operativa.
In un ambiente cloud, le organizzazioni possono aumentare o diminuire le proprie risorse di elaborazione in tempo reale in base alla domanda effettiva, eliminando così la necessità di un overprovisioning per far fronte ai picchi di carico. Questa elasticità consente alle aziende di pagare solo per le risorse che consumano invece di investire in costose licenze hardware e software per gestire picchi di utilizzo occasionali.
Per informazioni dettagliate su come funzionano i prezzi AWS, consulta Prezzi.AWS
