Come lo abbiamo fatto: infrastruttura critica sanitaria, due Data Center e il disaster recovery che non aspetta il disastro

Il contesto e la sfida

Ci sono sistemi informativi che possono permettersi una finestra di manutenzione. Poi ci sono quelli che governano la disponibilità di servizi critici per un'intera regione.

Il progetto riguardava il sistema informativo di una rete di medicina, verticale e di visibilità regionale (volutamente teniamo generico il riferimento al fine di poter scendere più nel dettaglio tecnico realizzativo senza esporre inforamzioni del Cliente): il gestionale che accompagna ogni attività medica, i servizi dipartimentali collegati, il bus d'integrazione verso i sistemi delle aziende sanitarie, il data warehouse per la programmazione e il governo clinico. Un ecosistema di oltre quarante macchine virtuali per sito, distribuite su tre ambienti — produzione, test e collaudo — con database Oracle mission critical (RAC e DataGuard) al centro di tutto.

Il requisito non era negoziabile: il servizio deve restare disponibile anche se un intero data center diventa irraggiungibile. "Ripartire in qualche giorno" non era una possibilità valutabile. L'unica era restare disponibili, ovvero piena e cruda Business Continuity.

La risposta non è stata un prodotto, ma un'architettura. E una scelta di metodo che ha guidato tutto il resto: due siti identici, configurati specularmente, in due città diverse della regione. Non un sito di produzione "vero" e un DR di serie B, ma due gemelli. Quando primario e secondario sono la stessa macchina, ogni procedura di ripristino diventa più corta, più prevedibile e — soprattutto — provabile.

Le criticità da cui siamo partiti

Progettare per la continuità significa prima di tutto elencare i modi in cui le cose si rompono. L'analisi iniziale ha messo in fila i punti di attenzione classici di queste infrastrutture:

• guasti hardware puntuali: un disco, un alimentatore, una scheda di rete, un intero nodo di virtualizzazione;
• guasti di rete: un cavo, uno switch, un router, un firewall;
• perdita del dato: il database che si corrompe, il backup che non è granulare abbastanza;
• il caso estremo: l'intero sito primario indisponibile, per giorni o settimane.

L'obiettivo dichiarato: arrivare a fine progetto potendo dire, guasto per guasto, chi lo assorbe e come. Vediamo come.

Due siti gemelli: l'hardware

Ogni sito è stato equipaggiato con tre server fisici Lenovo ThinkSystem SR630: due nodi dedicati alla virtualizzazione — CPU Intel Xeon Gold 6330 a 28 core e 768 GB di RAM ciascuno — e un terzo nodo a uso misto per virtualizzazione, management e monitoraggio, con Xeon Silver 4310T.

Quei 768 GB per nodo non sono sovradimensionamento: sono la condizione perché, alla caduta di un host, l'altro possa accogliere tutte le VM critiche migrate senza degrado. La resilienza intra-sito non si compra a listino, si dimensiona: è lo stesso capacity planning che mettiamo nella progettazione di server farm e data center.

La connettività è affidata a schede Broadcom a 25 Gbit/s (4 porte per server in active-backup, due canali ad alta disponibilità per le VLAN di servizio), che si attestano su una coppia di switch/router NVIDIA Mellanox con porte a 100 Gbit/s per ogni sito. Ogni server espone la propria BMC per il controllo remoto completo, anche a macchina spenta: quando il sito secondario è a decine di chilometri, "vado a vedere di persona" non è un piano di gestione.

Lo storage: le performance sono una politica, non un numero

Su entrambi i siti la persistenza è affidata a coppie di storage Lenovo DE4000H, con tre livelli di tierizzazione per tre lavori diversi: SSD SAS + NVME Cache per i database Oracle e i carichi mission critical, dischi SAS 10K per le VM applicative ad alte performance, dischi SATA capacitivi dedicati esclusivamente al backup.

La protezione segue la stessa logica a strati. RAID 6 su tutti i volume group — si tollerano due dischi guasti contemporaneamente senza fermarsi — più un hot-spare per ogni tipologia di disco. Doppio controller con 4+4 porte a 25 Gbit/s in bilanciamento e failover: lo storage resta operativo fino alla perdita della settima porta su otto.

Due dettagli che spesso mancano nei progetti "a listino": il multi-tiering automatico, cache per i dati caldi e i workload paralleli configurati direttamente sulle controller — profili di ottimizzazione distinti per database Oracle, hypervisor, VM applicative e job di backup. Lo stesso storage, quattro comportamenti diversi a seconda di chi lo interroga. La tierizzazione dei dischi ha un parallelo esatto nella protezione del dato: il continuum RPO–RTO con i sette tier di recuperabilità, dove ogni servizio va collocato nel punto giusto della curva.

Virtualizzazione open source dove conta

L'hypervisor scelto è Oracle Linux Virtualization Manager (OLVM), l'evoluzione enterprise del progetto open source oVirt, costruito su KVM — lo standard de facto della virtualizzazione Linux. Niente licenze per socket, niente lock-in su un ecosistema proprietario, e tutte le funzionalità che servono davvero: live migration, gestione centralizzata via Hosted Engine (a sua volta protetta: se cade l'host che la ospita, riparte automaticamente altrove), monitoraggio nativo con Grafana integrato. È lo stesso approccio — virtualizzazione aperta, nessun lock-in — su cui poggia il nostro private cloud e VDC.

Sopra, un parco di oltre quaranta VM Oracle Linux per sito e diverse Windows Server 2019: bilanciatori Apache in coppia, application server ridondati, il bus di integrazione WSO2 in doppia istanza, il data warehouse con lo strato di business intelligence. Ogni componente di produzione che può essere doppio, è doppio.

Il dato: perché Data Guard e non il mirroring dello storage

Qui sta una delle scelte tecniche più importanti del progetto, e vale la pena spiegarla perché è il punto dove molte architetture DR si giocano tutto.

Il database principale gira su Oracle Real Application Cluster: due nodi attivi che si proteggono a vicenda dentro il sito. Ma la replica tra i siti non è affidata al mirroring remoto dello storage, come si fa spesso. È affidata a Oracle Data Guard in configurazione physical standby: il sito secondario riceve i redo log del primario e li riapplica, blocco per blocco, mantenendo una copia fisica esatta e validata del database.

La differenza non è soltanto accademica. Il mirroring di una SAN replica blocchi che non sa interpretare: non può certificare che ciò che arriva a destinazione sia un database consistente, e la scoperta dell'inconsistenza avviene nel momento peggiore possibile — durante il failover. Data Guard valida ogni singolo pacchetto con i meccanismi nativi di Oracle e ricostruisce la sequenza corretta delle transazioni.

Nel giorno del disastro, la differenza è tra ripartire e sperare.

Le modalità di protezione (Maximum Performance, Availability, Protection) permettono poi di scegliere esplicitamente il compromesso tra prestazioni del primario e garanzia di zero perdita dati — una decisione di business resa configurabile. Per le istanze singole fuori dal RAC, lo stesso Data Guard garantisce l'allineamento verso il sito di DR.

Le VM applicative seguono una via più pragmatica: sincronizzazione file-level schedulabile, avendo cura di non replicare i file di configurazione che puntano ai database. Le macchine in DR restano così allineate e pronte all'attivazione, senza il rischio di accensioni accidentali contro il dato sbagliato.

Ansible completa l'opera permettendo l'orchestrazione di Playbook scritti ad adhoc per la conduzione dell'infrastruttura e il day-by-day.

Non è l'unico modo di disegnare la continuità fra due siti. In un Ente Regionale il sito secondario eroga servizi tutti i giorni invece di aspettare il disastro: è il modello both-active che abbiamo raccontato in 600+ applicazioni, un Ente Regionale e la continuità che si ripaga da sola.

La rete: a caccia di single point of failure

L'esercizio finale è stato passare al setaccio ogni anello della catena e chiedersi: se si rompe questo, chi lo sostituisce?

Doppie schede in teaming sui nodi. Doppi router Mellanox in port-channel per sito. Uplink verso gli switch dell'operatore di rete regionale aggregati in MLAG: il risultato è che si può perdere un cavo, uno switch o un intero router senza interruzione. Il traffico di frontiera è gestito dai firewall dell'operatore regionale, anch'essi collegati in doppia via.

Alla fine del setaccio resta un solo single point of failure per sito: il firewall di frontiera, che non è nel nostro perimetro. In caso di down del sito attivo che per gravità porta alla dichiarazione di DR, il traffico viene rediretto dall'operatore verso il data center secondario, dove l'intera infrastruttura — speculare, allineata, già in ascolto — è pronta a erogare (*). Che è esattamente ciò che un piano di continuità dovrebbe fare: non promettere l'assenza di guasti, ma non farsi mai trovare senza risposta. Con un'avvertenza: nessuna ridondanza si autogoverna. Perché il failover parta nel momento giusto serve qualcuno che veda l'evento per primo, ed è il mestiere di un NOC attivo 24×7×365.

(* Allo stato attuale dell'infrastruttura siamo in grado di gestire lo switch PDC -> SDC completo in 15 min)

Il backup: la granularità che cambia le domande

Il backup è organizzato a livelli indipendenti, con un sistema autonomo per ciascun sito. Le configurazioni logiche dell'hypervisor si salvano da sole. Le VM sono protette da Veeam Backup & Replication con salvataggi full e incrementali a livello di volume, indicizzati, organizzati in protection group omogenei, con possibilità di recupero del singolo file.

Ma il punto di svolta è sui database: il backup application-aware degli archive log Oracle ha una granularità che arriva a 5 minuti, con retention che può superare i 45 giorni per singola copia. È la differenza tra chiedersi "quanto abbiamo perso?" e chiedersi "a che minuto torniamo?".

E c'è un ultimo tassello, quello che chiude il cerchio: la doppia copia dei backup viene parallelizzata in tempo reale verso lo storage del sito di DR, dove un'installazione Veeam gemella è già integrata e pronta alla restore. Anche il backup, come tutto il resto, esiste due volte. Resta la regola che vale in ogni progetto: una copia non è una ripartenza, e l'unico modo per saperlo è cronometrare un restore vero — il motivo per cui il backup da solo non basta.

La lezione

La continuità operativa non si aggiunge, la si progetta. In questo caso nessun componente è stato scelto chiedendosi solo "quanto è veloce?" o "quanto costa?", ma sempre anche "cosa succede quando si rompe?". È un modo di lavorare che apparentemente costa di più, sulla carta, ma infinitamente meno il giorno in cui serve: analisi, progettazione, realizzazione e supporto sono le quattro fasi del nostro metodo, e ogni scelta resta verificabile insieme al cliente.