INGV e GARR, insieme per una sala sismica in cloud

Quando si parla di monitoraggio sismico e vulcanologico la velocità di comunicazione e la garanzia di business continuity sono elementi chiave per una pronta collaborazione con gli enti di protezione civile e la comunità scientifica. Per questo motivo l’INGV ha deciso di adottare un’infrastruttura cloud che permetta una sinergia in real-time tra le sale sismiche di Napoli, Roma e Catania, con l’intento di creare un’unica sala virtuale perfettamente ridondata e capace di reagire in caso di indisponibilità in una o più sale. Come? Adottando il modello della Cloud GARR e personalizzandolo: ce lo racconta Giovanni Scarpato dell’INGV di Napoli.

credit: INGV on Flickr

Ci può dire da dove siete partiti?

Il nostro istituto ha tre sale di monitoraggio: a Roma, Napoli e Catania. La prima riceve i segnali sismici in tempo reale dalle stazioni su tutto il territorio nazionale, mentre le altre due sorvegliano le zone vulcaniche: Vesuvio e Campi Flegrei da una parte e Etna e Isole Eolie dall’altra. Insieme, queste infrastrutture formano la Rete Sismica Nazionale. Attualmente, il monitoraggio avviene nelle singole sale sismiche e, quando necessario, dalla sala interessata viene trasmessa la cosiddetta comunicazione formale, cioè l’interazione con gli enti da allertare in caso di sisma o anomalie delle aree vulcaniche: enti territoriali, il Dipartimento di Protezione Civile, o ENAC e ENAV per quanto riguarda l’aviazione. I dati che vengono acquisiti dalle sale hanno diverse funzioni: servono nell’immediato per gli aspetti di protezione civile, ma anche nel lungo periodo per poter creare modelli e serie di studio. L’obiettivo di INGV è di unificare le sale sismiche con il modello di cloud federata GARR, per dare accesso in modo rapido e trasparente alla fonte di dati ai ricercatori, ma anche per poter contare su uno strumento di business continuity. È infatti necessario garantire la continuità del monitoraggio, anche nel caso di indisponibilità di una delle sale, per esempio a causa di un’evacuazione. Abbiamo così pensato ad un approccio in cloud, per la sua intrinseca capacità di dare accesso ai dati e alla potenza di calcolo a prescindere dall’ubicazione dell’hardware. Appena venuti a conoscenza della federazione Cloud GARR abbiamo pensato che un’architettura simile potesse essere la soluzione giusta. Essendo già connessi alla rete e fruitori delle attività di formazione GARR, ci è venuto spontaneo chiedere aiuto per capire come creare da noi una mini-federazione con lo stesso modello.

Potrebbe descriverci questo modello?

Per ciascuna sala sismica, abbiamo creato una regione cloud (cioè un ambiente virtuale, basato su OpenStack e corrispondente ad un data centre fisico), rendendola un’infrastruttura verticale che offre servizi di calcolo e storage. Le tre regioni sono state quindi federate, cioè interconnesse, in modo che i singoli data centre possano comunicare tra loro e ci diano la possibilità di scambiare i sistemi di acquisizione dei dati tra una regione e l’altra. In pratica, si delega allo strato infrastrutturale tutto ciò che normalmente si fa a livello applicativo (ossia macchina per macchina). Grazie a questo livello infrastrutturale su cui lavorano le varie applicazioni, nel momento in cui una (o due) delle sale dovesse risultare indisponibile, l’infrastruttura consente di continuare le attività sulle altre, essendo i dati ed i sistemi di acquisizione ed elaborazione costantemente sincronizzati. In questo senso si può parlare di un’unica sala di monitoraggio e non più di tre sale separate. Ciò è reso possibile dall’utilizzo di diversi meccanismi della suite OpenStack, tra cui Swift, per ottenere un object storage distribuito, e Glance, per la sincronizzazione tra le regioni delle “immagini” degli applicativi. Questi meccanismi permettono che i server di acquisizione e calcolo virtualizzati siano disponibili su tutte le regioni in una modalità active-standby.

Quale tipo di supporto ha fornito GARR nel rispondere alle vostre esigenze?

Il gruppo CSD GARR ci ha accompagnati per mano nel disegnare questa architettura e nella fase di deployment, con un vero training on the job. L’architettura è molto simile alla Cloud GARR, con alcune differenze specifiche, quali lo storage a oggetti distribuito e sincronizzato sulle regioni. In particolare, una sfida era data dai sensori di rilevamento che, posti nelle aree da monitorare, comunicano ciascuno con un IP definito, corrispondente ad una delle sale sismiche. Per mantenere l’acquisizione dei dati anche in caso di indisponibilità di quella sala, abbiamo utilizzato il meccanismo di storage basato su Swift unito a una caratteristica della rete GARR: la possibilità, in caso di necessità, di spostare l’IP legato al sensore su un altro server. Tutto ciò, unito alla possibilità data dall’architettura della federazione di avere le virtual machine “in attesa” sulle altre regioni fa sì che, se una regione va in fault, posto che l’infrastruttura sottostante di routing continui ad essere attiva, una delle altre due potrà prendere in carico le sue attività con una interruzione minima nel flusso dei dati. Un altro elemento importante è che questa infrastruttura è stata concepita con un approccio open source, in modo da evitare il vendor lock-in, garantendo, così una soluzione tecnologicamente, ma anche economicamente sostenibile per INGV.

Quali tempi prevedete per questo progetto?

credit: INGV on Flickr

Purtroppo, a causa dell’emergenza Covid-19, i tempi per terminare il progetto si sono un po’ allungati: contavamo di concludere la fase prototipale per giugno, fortunatamente però ci è stata concessa la proroga fino a fine anno. L’idea è di arrivare per allora ad avere i sistemi in produzione in parallelo con quelli in cloud, per poi decidere gli eventuali switch off.

Attualmente l’infrastruttura è in funzione e siamo in fase di replicazione dei sistemi nel cloud. Stiamo lavorando sulla parte applicativa e poi passeremo alla governance, cioè le linee guida per capire come fare a scambiare i sistemi in caso di necessità. Ora abbiamo su cloud il sistema d’acquisizione di una telecamera visibile a Napoli (monitoraggio sui Campi Flegrei) più parte del sistema di acquisizione dei dati sismici con analisi in tempo reale per il monitoraggio delle aree vulcaniche napoletane e sposteremo in cloud anche il database delle localizzazioni degli eventi sismici. La sezione di Catania sta predisponendo un sistema di videosorveglianza (video streaming termico in real-time di Etna e Stromboli). La sezione di Roma sta facendo lo stesso con il sistema di acquisizione per il monitoraggio della sismicità nazionale. Il passo successivo sarà quello di rendere i dati interscambiabili tra le varie sedi in modo semi-automatico, così da garantire, in caso di indisponibilità di una sala, che non solo l’acquisizione dai sensori continui sulle altre sale, ma anche che i dati della sala “interrotta” siano presenti nelle altre sale.

Oltre alla business continuity, ci sono altri benefici connessi a un’infrastruttura di questo tipo?

Certamente. Avere dei repository dei prodotti della ricerca sui dati di monitoraggio e avere a disposizione una nuvola di dati ha come primo beneficio la massima affidabilità possibile ma anche una maggiore disponibilità di dati per la ricerca e dell’accesso ad essi, il che andrà a beneficio della comunità scientifica.