Case study · Trasporti
Per i sistemi di controllo e monitoraggio di una nuova linea metropolitana, il cliente ha adottato Proxmox VE e Proxmox Backup Server: un cluster stretched distribuito tra due sale dati alle estremità della linea, con un terzo sito dedicato al quorum. L'intera infrastruttura opera in modalità air gapped, senza alcuna connettività verso reti pubbliche.
Il progetto in tre numeri
Due sale dati alle estremità della linea e un sito indipendente dedicato al quorum
Connessioni dai nodi verso reti pubbliche: attivazione e aggiornamenti avvengono offline
Del carico applicativo sostenibile da una sola sala dati, verificato in fase di dimensionamento
Sintesi del progetto
Il cliente è una multinazionale che progetta, costruisce e gestisce sistemi di trasporto pubblico e ferroviario a livello internazionale, con un portafoglio che comprende convogli ad alta velocità, metropolitane anche in configurazione senza conducente, tram e treni regionali a trazione ibrida, oltre a sistemi di segnalamento digitale, servizi di manutenzione e tecnologie per la mobilità sostenibile.
L'esercizio air gapped è soddisfatto mediante le funzionalità di attivazione delle sottoscrizioni e di aggiornamento offline disponibili con i livelli Standard e Premium.
Nota sulla riservatezza: il case study è pubblicato in forma anonima. Sono omessi la denominazione del cliente, la localizzazione dell'opera, i nomi di host e di cluster, gli indirizzamenti di rete e ogni altro elemento riconducibile all'infrastruttura specifica. I contenuti tecnici descrivono scelte architetturali e metodologiche di validità generale.
Il contesto
I sistemi che governano l'esercizio di una linea metropolitana appartengono alla categoria delle infrastrutture critiche. La supervisione del traffico, il monitoraggio degli impianti di stazione, la diagnostica del segnalamento e i sistemi di informazione al pubblico devono restare disponibili per l'intera durata del servizio, e la loro indisponibilità si traduce in impatti immediati sulla circolazione e sulla sicurezza dell'esercizio.
Tale contesto determina tre vincoli progettuali che concorrono a definire l'architettura.
Vincoli progettuali
Le sale dati sono collocate alle estremità della linea, condizione che consente di distribuire i sistemi su due siti fisicamente distinti, ma che introduce la necessità di gestire la consistenza dei dati tra sedi separate da una distanza significativa.
L'obiettivo di disponibilità fissato per l'infrastruttura richiede che il guasto totale di una delle due sale dati non determini l'interruzione dei servizi, con ripresa automatica dei carichi sul sito superstite.
Le politiche di sicurezza applicabili all'infrastruttura escludono qualsiasi connettività diretta verso Internet, inclusa quella normalmente impiegata per l'attivazione delle licenze software e per il reperimento degli aggiornamenti.
Criteri di selezione della piattaforma
Lo stack di clustering della piattaforma, unitamente allo storage distribuito Ceph, consente la realizzazione di un cluster unico distribuito su più siti senza componenti aggiuntive o licenze dedicate alla funzione di replica geografica.
La piattaforma dispone di uno strumento ufficiale per l'attivazione delle sottoscrizioni e per la distribuzione degli aggiornamenti su sistemi privi di connettività. La funzione è supportata dal produttore, non richiede procedure improvvisate e non comporta la rinuncia al canale di supporto.
Alta disponibilità, storage distribuito, backup e clustering sono disponibili in ogni configurazione. Il livello di sottoscrizione determina il canale di supporto e la disponibilità delle funzioni di gestione offline, non le capacità della piattaforma.
In un contesto di infrastruttura critica soggetta a valutazione di sicurezza, la disponibilità del codice sorgente costituisce un elemento di merito in sede di analisi e di audit.
Architettura implementata
Il cluster è distribuito su tre siti. Le due sale dati collocate alle estremità della linea ospitano ciascuna un numero pari di nodi di calcolo, mentre un terzo sito indipendente ospita il nodo destinato esclusivamente all'espressione del voto di quorum.
La configurazione risponde a un problema specifico delle architetture a due siti. Con una distribuzione paritetica su due sale, l'interruzione del collegamento tra le sedi produrrebbe due partizioni di pari peso, nessuna delle quali in grado di raggiungere la maggioranza. Il risultato sarebbe l'arresto di entrambe le partizioni oppure, in assenza di adeguate protezioni, la condizione di split brain, con due gruppi di nodi che operano contemporaneamente sugli stessi dati.
Il terzo sito risolve la condizione. Il nodo di quorum non ospita carichi di lavoro e non partecipa allo storage distribuito, ma esprime il voto che consente al sito superstite di raggiungere la maggioranza e di proseguire l'esercizio. La perdita di una sala dati determina quindi la ripresa dei servizi sul sito rimanente, senza intervento manuale e senza rischio di divergenza dei dati.
Architettura implementata
Lo storage è realizzato con Ceph in modalità RBD, con OSD distribuiti su tutti i nodi di calcolo delle due sale dati.
La replica dei dati è configurata in modo da mantenere copie su entrambi i siti, condizione necessaria affinché il sito superstite disponga di una copia completa e coerente dei dati in caso di perdita dell'altro.
Il traffico di replica dello storage e il traffico di cluster sono attestati su una rete dedicata, distinta da quella di produzione. La separazione garantisce che le operazioni di ribilanciamento non sottraggano banda ai sistemi in esercizio e che il traffico applicativo non interferisca con i tempi di risposta del livello di persistenza, parametro critico per la stabilità del quorum.
Architettura implementata
Le macchine virtuali che eseguono i sistemi di controllo e monitoraggio sono gestite dall'HA manager della piattaforma, con fencing hardware.
In caso di perdita di un nodo o di un intero sito, i carichi vengono riavviati automaticamente sui nodi disponibili. Le operazioni di manutenzione pianificata sono eseguite mediante migrazione a caldo delle macchine, senza interruzione dei servizi.
Il dimensionamento è stato condotto verificando la capacità del singolo sito di sostenere l'intero carico applicativo, e non soltanto la quota di propria competenza in condizioni ordinarie. La verifica costituisce il presupposto affinché la funzione di alta disponibilità risulti effettivamente esercitabile e non meramente configurata.
Architettura implementata
Proxmox Backup Server opera in configurazione air gapped, con replica degli archivi tra i siti su canale cifrato.
I backup sono incrementali con deduplica a livello di blocco, condizione che riduce l'occupazione dello storage di destinazione e contrae le finestre di esecuzione, consentendo una frequenza dei punti di ripristino elevata a parità di risorse impiegate.
La verifica pianificata controlla l'integrità degli archivi e segnala eventuali degradi prima che si manifestino in fase di ripristino. Le politiche di prune provvedono all'eliminazione automatica degli snapshot fuori retention. Le procedure di ripristino sono state collaudate prima del passaggio in esercizio, con verifica sia del restore integrale sia del recupero granulare, e sono sottoposte a test periodici.
L'esercizio in modalità air gapped
L'assenza di connettività verso reti pubbliche costituisce l'elemento più caratterizzante del progetto e il principale vincolo operativo da risolvere.
Un'infrastruttura priva di accesso a Internet incontra due difficoltà ricorrenti. La prima riguarda l'attivazione della sottoscrizione, che nel modello ordinario avviene mediante interrogazione dei sistemi del produttore. La seconda riguarda gli aggiornamenti, e in particolare le correzioni di sicurezza, il cui reperimento presuppone l'accesso ai repository ufficiali. In molte realtà il vincolo si traduce nella rinuncia alla sottoscrizione oppure nell'adozione di procedure non supportate.
La piattaforma dispone di uno strumento ufficiale che risolve entrambi gli aspetti. Il funzionamento prevede un sistema di appoggio dotato di connettività, esterno al perimetro protetto, sul quale sono registrate le chiavi di sottoscrizione dei sistemi isolati. Il sistema di appoggio ottiene dal produttore i dati di attivazione in forma firmata, che vengono esportati su supporto rimovibile o su condivisione interna e applicati sui nodi del perimetro protetto. Il medesimo sistema mantiene una copia locale del repository enterprise, sincronizzata per istantanee successive, che viene trasferita con la stessa modalità e utilizzata dai nodi come sorgente per gli aggiornamenti.
Le implicazioni sono rilevanti. I nodi dell'infrastruttura critica non stabiliscono in alcun momento connessioni verso l'esterno. Le sottoscrizioni risultano attive e i sistemi accedono al repository enterprise, con la conseguenza che il canale di supporto del produttore resta disponibile. Gli aggiornamenti sono applicati per istantanee coerenti e verificabili, condizione che consente il collaudo preventivo su ambiente di prova e l'allineamento simultaneo di tutti i nodi alla medesima versione. La gestione delle chiavi di sottoscrizione e la tracciabilità dei supporti impiegati rientrano nelle procedure documentate dell'infrastruttura.
La funzione richiede un livello di sottoscrizione Standard o Premium sui sistemi interessati, oltre alla sottoscrizione dedicata allo strumento di mirroring.
Obiettivi progettuali e riscontri
Indicazioni metodologiche
In una configurazione stretched a due sale dati, la maggioranza non è determinabile in caso di partizionamento. Il nodo di quorum indipendente è la componente che rende l'architettura effettivamente tollerante alla perdita di un sito, e la sua collocazione va progettata insieme al resto dell'infrastruttura, non aggiunta successivamente.
Lo storage distribuito e il protocollo di quorum sono sensibili ai tempi di risposta della rete di interconnessione. La caratterizzazione del collegamento, la sua ridondanza e la separazione dai domini di traffico applicativo precedono il dimensionamento dei nodi.
La capacità rilevante non è quella complessiva del cluster, ma quella di cui dispone il singolo sito quando deve sostenere l'intero carico. Un'alta disponibilità configurata su un'infrastruttura priva di margine è una funzione dichiarativa.
L'assenza di connettività non impone la rinuncia alla sottoscrizione né agli aggiornamenti di sicurezza. Esiste un percorso supportato dal produttore, che tuttavia richiede l'individuazione del sistema di appoggio, la definizione delle procedure di trasferimento e la loro integrazione nel processo di gestione delle configurazioni.
In un'infrastruttura isolata la verifica delle procedure di ripristino non può essere rinviata al momento del bisogno, poiché non è disponibile alcun canale di assistenza remota in tempo reale sui sistemi.
Considerazioni conclusive
Il progetto dimostra la praticabilità di un'infrastruttura di virtualizzazione basata su software libero in un contesto caratterizzato da requisiti di disponibilità elevati e da politiche di sicurezza che escludono qualsiasi connettività verso reti pubbliche.
Le funzionalità impiegate, dal clustering distribuito su più siti allo storage replicato, dall'alta disponibilità alla protezione dei dati, sono disponibili nella piattaforma senza componenti aggiuntive e senza differenziazione per livello di sottoscrizione.
Il vincolo di isolamento, che in molte realtà comporta la rinuncia al supporto del produttore o l'adozione di procedure non documentate, è stato risolto mediante uno strumento ufficiale, mantenendo l'infrastruttura aggiornata, le sottoscrizioni attive e il canale di assistenza disponibile.
Rackone, Proxmox Gold Partner e Authorized Training Partner, affianca enti pubblici, imprese e MSP nella progettazione, migrazione e gestione di piattaforme Proxmox VE, con esperienza su architetture distribuite su più siti, ambienti soggetti a vincoli di sicurezza e infrastrutture critiche.
