Migrazione Oracle. Come gestire Legacy e High Availability
In un settore frenetico come quello della Grande Distribuzione Organizzata (GDO), il sistema informativo è il motore che muove ogni cosa: dall'approvvigionamento ai magazzini, fino all'emissione dell'ultimo scontrino della giornata. Spesso, però, la criticità di questi processi porta a rimandare la manutenzione, fino a trovarsi con server accesi ininterrottamente da oltre 10 anni. È questa la sfida che abbiamo affrontato per Maxidi: rinnovare un’infrastruttura ormai obsoleta che ospitava un database Oracle estremamente critico.
Il vincolo: innovare senza stravolgere.
La particolarità del progetto? Il software gestionale di terze parti imponeva di mantenere laversione Oracle 11.2, non essendo certificato per versioni più recenti a causa di pesanti personalizzazioni del codice. Ci siamo trovati di fronte a un paradosso: installare un software "vecchio" su hardware e sistemioperativi di ultima generazione (Oracle Linux 7).
Il progetto ha affrontato sfide tecniche e procedurali significative.
- Obsolescenza e Bug: lavorare con Oracle 11.2 nel 2025 ha significato gestire bug critici, come errori nel Data Guard broker che modificavano autonomamente le destinazioni dei log, mettendo a rischio il Disaster Recovery.
- Incongruenze infrastrutturali: i server forniti dal cliente presentavano configurazioni disomogenee (ISO diverse, librerie mancanti) e dischi condivisi con path non allineati tra i nodi, rendendo impossibile l'installazione standard del Clusterware.
- Compatibilità OS: il sistema operativo Oracle Linux 7 aveva un kernel troppo recente per la vecchia versione del database, causando incompatibilità.
Switch in meno di un'ora
Il timore principale del cliente era il fermo macchina. Grazie a una strategia di migrazione "incascata", dove la nuova infrastruttura è stata inizialmente configurata come Standby della precedente, siamo riusciti a garantire un allineamento perfetto e continuo dei dati, riducendo ilmomento dello switch definitivo in un semplice cambio di puntamenti DNS.
La nostra soluzione è stata quella di realizzare un’architettura ad High Availability per garantire la massima sicurezza. Abbiamo dunque implementato quanto segue.
Un’architettura a 8 nodi con 4 nodi di Produzione e 4 nodi di Disaster Recovery. La nuova infrastruttura è stata installata inizialmente come Standby della precedente produzione, in modo tale da averne la copia esatta ed in continuo allineamento automatico. A questa è stato agganciato un altro Standby in cascata ed in perfetto allineamento.
La gestione massiva dei dati con l'ottimizzazione di 18 TB di dati tramite storage ASM. È stata configurata un'architettura ASM separando i dischi di voto (voting disks) dai dati (18TB), garantendo che un problema sui dati non compromettesse la stabilità dell'intero cluster.
Un "ingegneria su misura" che ha visto un downgrade controllato del kernel Linux per rendere compatibile il database 11.2 con le macchine moderne e risolto manualmente bugcritici del Data Guard Broker e incongruenze nei path dei dischi condivisi.
Infine abbiamo avuto cura nella gestione delle relazioni essendosi resa necessaria una complessa mediazione tra il cliente e il fornitore del software gestionale per allineare le esigenze di business con i vincoli tecnici.
- Database: Oracle Database 11g Release 2 Enterprise Edition).
- Sistema Operativo: Oracle Linux 7 (con kernel customizzato).
- High Availability: Oracle RAC Real Application Clusters) a 4 nodi + Disaster Recovery a 4 nodi.
- Storage: Oracle ASM Automatic Storage Management) e ACFS.