Migrazione Oracle RAC con ottimizzazione delle licenze e virtualizzazione

Nel settore della Grande Distribuzione Organizzata, la continuità operativa dei sistemi database è il pilastro su cui poggiano vendite, logistica e fatturazione. Il cliente, un importante player nel settore Retail, gestiva i propri database critici su un'infrastruttura Oracle RAC installata su server fisici. L'ambiente operativo presentava due vincoli principali:

1. Obsolescenza Hardware: la difficoltà nel reperire server fisici con un numero limitato di CPU, condizione necessaria per contenere i costi di licenza Oracle basati sul core-count.
2. Eterogeneità dei Sistemi: la coesistenza di diverse versioni di Oracle e molteplici database con funzioni distinte, dai sistemi di test alla produzione, fino al data warehouse e ai database specifici per la rete vendita. L'architettura iniziale prevedeva una connessione diretta degli application server ai listener Oracle SCAN del cluster fisico tramite alias DNS.
    

La sfida tecnica per Miriade consisteva nel migrare l'intero ecosistema verso un ambiente virtuale di nuova generazione, minimizzando i flussi della distribuzione e affrontando tre criticità.

1. Minimizzare il downtime, per ridurre al minimo il fermo degli utenti e degli applicativi durante il passaggio, data la natura 24/7 delle operazioni di vendita.
2. Ottimizzare i costi di licenza (Licensing) per evitare il rischio di un aumento esponenziale dei costi software, nel caso in cui non si fosse riusciti a limitare e certificare l'uso delle CPU tramite tecnologie di virtualizzazione approvate dal vendor.
3. Gestire l'incertezza sulle performance della nuova soluzione. Questa era una necessità sentita per garantire che il nuovo ambiente virtuale offrisse una reattività applicativa pari o superiore all'infrastruttura fisica ("bare metal"), evitando colli di bottiglia a livello di rete e storage.

L'intervento è stato pianificato basandolo su tre pilastri strategici. 

• La migrazione doveva avvenire con Near-Zero Downtime. Era necessario completare il passaggio dei database riducendo il fermo totale a finestre temporali estremamente ridotte.
• Uno degli obiettivi da raggiungere era l'efficientamento del Licensing, utilizzando la virtualizzazione per gestire in modo granulare le risorse CPU tramite hard partitioning delle stesse, ottimizzando l'investimento software.
• Infine, uno dei capisaldi era garantire stabilità e tuning post-migrazione, assicurando, così, che la nuova infrastruttura risolvesse eventuali criticità hardware latenti, garantendo performance stabili nel lungo periodo.

La strategia progettata da Miriade ha previsto la transizione verso server virtuali governati da Oracle Linux Virtualization Manager (OLVM), appoggiati a un nuovo storage ad altissime prestazioni. L'architettura ha comportato la creazione di tre macchine virtuali, due dedicate ai nodi del cluster e una configurata come Oracle Connection Manager (CMAN). Quest'ultimo ha agito come proxy intelligente, intercettando le connessioni dagli application server e reindirizzandole al database corretto. L'uso di CMAN ha permesso una migrazione "per step" (un database alla volta) totalmente trasparente per i client. Per i database più imponenti (su un totale di quasi 20 TB migrati), Miriade ha adottato una strategia puntuale mirata al restore di un backup ordinario senza fermare la produzione, seguito da allineamenti (recover) periodici. Il giorno dello switch-off, il disservizio per il database più critico è stato limitato a circa 15 minuti.

Durante la fase iniziale di testing, si è provveduto a mettere sotto stress l’ambiente di test al fine di evidenziare sin da subito eventuali problematiche di performance che non sarebbero passate inosservate successivamente alla migrazione. Segnaliamo alcuni punti di attenzione che vanno sempre tenuti in considerazione per avere performance ottimali:

• versioni in matrice di tutte le componenti del cluster, dischi, server, cavi di rete, GBIC, secondo quanto richiesto da Oracle nelle note ufficiali.
• Verifica degli errori su tutte le componenti, compreso il CRC (Cyclic Redundancy Check). È un controllo matematico che il sistema fa per verificare che i dati partiti dal punto A siano identici a quelli arrivati al punto B. Se il calcolo non torna, significa che il pacchetto dati si è danneggiato durante il viaggio lungo il cavo. Quando succede, il sistema deve scartare il pacchetto e chiederne uno nuovo. Questo rallenta tantissimo le prestazioni del cluster.
• Verifica del power management delle CPU.

La metodologia di migrazione

La metodologia di mugrazione ha seguito step:

• sospensione controllata degli applicativi e backup tramite la suite esterna di backup;
• ripristino (Restore) e allineamento (Recover) sulla nuova infrastruttura virtuale;.
• aggiornamento della configurazione CMAN per puntare al nuovo database - questo prevede la de-registrazione del database sulla precedente infrastruttura dal CMAN e la registrazione dello stesso database migrato sulla nuova infrastruttura;
• riavvio immediato dei servizi applicativi senza riconfigurazione dei client.

Essendo stati migrati un totale di 8 database, per un totale di quasi 20 TB di dati, le tempistiche di restore e recover sono state diverse.
Per i due database più grandi in termini di dimensioni è stata applicata una strategia leggermente diversa. Nello specifico, è stata eseguita la restore di un backup ordinario, senza fermare la produzione, e sono stati eseguiti successivamente dei recover periodici il giorno della migrazione in modo da minimizzare il disservizio, come si è scritto, con un downtime di circa 15 minuti per il database più critico.

Avendo effettuato una restore fisica del database, tramite l’utility RMAN, i piani di esecuzione delle query non sono variati, impedendo miglioramenti da questo punto di vista. Ciò nonostante, si sono rilevati miglioramenti sui tempi di esecuzione dei flussi legati al solo cambio di infrastruttura. Grazie al passaggio ad infrastruttura virtuale, è stato possibile fissare il numero di CPU e limitare i costi di licenza.
 

a migrazione ha richiesto un sapiente mix di tecnologie enterprise e tecniche di tuning infrastrutturale profondo.

• Oracle RAC (Real Application Clusters): motore database core per la massima affidabilità.
• Oracle Linux Virtualization Manager (OLVM): scelto per certificare l'hard partitioning e limitare legalmente i costi di licenza CPU.
• Oracle Connection Manager (CMAN): utilizzato come proxy vitale per smistare il traffico e garantire una migrazione fluida e senza interruzioni applicative.
• Oracle RMAN (Recovery Manager): per l'esecuzione di restore fisici che hanno mantenuto intatti i piani di esecuzione delle query.

Raccomandazioni

La migrazione di sistemi mission-critical richiede una progettazione infrastrutturale proattiva. Nel caso in esame è stato utile:

• adottare strumenti di orchestrazione come CMAN per gestire il traffico in modo fluido e trasparente agli applicativi durante lo switch.
• Non sottovalutare il Tuning Hardware e prestare attenzione a parametri come il risparmio energetico dei processori; le corrette versioni dei diversi componenti hardware coinvolti possono, infatti, avere impatti significativi sulle performance dei database in ambiente virtuale.
• Pianificare test rigorosi, utilizzando database di sviluppo/test per far emergere i limiti dell'infrastruttura prima di procedere con i sistemi di produzione.
• Mantenere un controllo costante sui wait events e sulle prestazioni di I/O per assicurare la stabilità operativa nel tempo.