Una piattaforma turistica multi-territorio porta con sé tre carichi che convivono male sullo stesso hardware: l’ingestione di dati culturali e geografici, i servizi web a traffico stagionale, l’elaborazione batch su mappe e metadati. Prima ancora di disegnare l’applicazione, la domanda da risolvere è quale strato di infrastruttura sappia isolare questi carichi senza legare il consorzio a un fornitore proprietario.

Contesto

Il quadro è il PON “Ricerca e Competitività” 2007-2013, che con l’Avviso 84/Ric. del 2 marzo 2012 ha aperto la linea “Smart Cities and Communities” e ha messo il patrimonio culturale tra le aree ammissibili (ponrec.it). Un consorzio che risponde a un bando del genere mette insieme molti soggetti — PMI, dipartimenti universitari, istituti di ricerca — ognuno con il proprio data center, le proprie competenze sistemistiche, i propri vincoli di portabilità. Il bando chiede esplicitamente soluzioni aperte, e questa richiesta ha conseguenze tecniche precise: lo strato di infrastruttura deve girare su hardware eterogeneo e deve restare ispezionabile dopo la fine del finanziamento.

La sperimentazione su più territori — Salerno, Prato, Pisa, Pistoia, il Piemonte — aggiunge un requisito che spesso si sottovaluta: la stessa immagine di servizio deve potersi istanziare in sedi diverse, gestite da gruppi diversi, senza riscrivere la procedura di deploy. È riproducibilità prima ancora che scala.

Architettura

A inizio 2014 il candidato naturale come strato Infrastructure-as-a-Service è OpenStack. La release Grizzly (2013.1, aprile 2013) tiene insieme sette progetti integrati: Nova per il compute, Swift per l’object storage, Glance per le immagini, Keystone per l’identità, Horizon per la dashboard, Cinder per il block storage, Quantum per il networking (release notes su wiki.openstack.org/wiki/ReleaseNotes/Grizzly). Per una piattaforma turistica pesano soprattutto Glance e Swift: Glance versiona le immagini di macchina da cui si istanziano i servizi, Swift conserva gli oggetti — fotografie geotaggate, dataset di metadati culturali, tile cartografiche — con le quote e il CORS introdotti proprio in Grizzly.

Lo schema che regge i tre carichi separa i piani in modo netto:

  • Compute effimero su Nova per i front-end web, dimensionato sul picco stagionale e ridotto fuori stagione, con KVM o Xen come hypervisor.
  • Storage durevole su Swift per gli asset culturali, replicato e indipendente dal ciclo di vita delle istanze di calcolo.
  • Identità centralizzata su Keystone, con i token PKI aggiunti in Grizzly, come unico punto di autenticazione tra i territori.

In Grizzly Nova introduce il modello di deployment a cells e l’isolamento no-db-compute, che scollega i nodi di calcolo dal resto del sistema: due meccanismi utili esattamente quando l’infrastruttura è distribuita su sedi amministrate da gruppi diversi. La prototipazione non deve vincolarsi a un’unica piattaforma: OpenNebula (4.4, novembre 2013) ed Eucalyptus restano alternative da valutare, entrambe con driver compatibili con l’API EC2 di Amazon. Eucalyptus implementa il supporto alle API AWS, compreso un componente di object storage compatibile con S3 (Walrus); OpenNebula porta un driver EC2 che sottomette richieste sia ad Amazon sia a Eucalyptus. La compatibilità EC2 pesa: lascia aperta la possibilità di appoggiarsi a capacità pubblica nei picchi stagionali senza riscrivere il piano di controllo.

Punto critico

La sostenibilità del progetto si gioca sullo storage degli asset culturali più che sul compute. Le fotografie geotaggate, i metadati delle opere, le tile cartografiche sopravvivono ai servizi: cambieranno i front-end, le campagne, magari i territori coinvolti, ma il dato resta. Tenerlo su Swift — un object store con quote e replica, indirizzabile via HTTP — vuol dire scegliere un formato di conservazione che non dipende né dalla singola applicazione né dal singolo data center.

Qui entra la questione dei formati. Sul versante del patrimonio culturale esistono già modelli e API consolidati: Europeana espone i propri dati con l’Europeana Data Model, serializzabile in N-Triples, Turtle, JSON-LD e altri dialetti RDF, e mette a disposizione API di accesso (pro.europeana.eu). Per i dati geografici, OpenStreetMap offre una base cartografica aperta e riusabile. Se gli asset stanno in Swift e sono descritti con questi modelli aperti, restano interrogabili e migrabili anche dopo la fine del progetto: è la differenza tra un prototipo di ricerca e un dato che qualcuno potrà ancora usare nel 2020.

Implicazioni

Separare compute effimero e storage durevole ha una conseguenza pratica: il dimensionamento smette di essere una scommessa. Il front-end web di una destinazione turistica ha un traffico fortemente stagionale; con Nova lo si scala su quel profilo e lo si comprime fuori stagione, senza toccare gli asset su Swift. Il consorzio paga — in hardware o in capacità pubblica compatibile EC2 — la curva reale del traffico, non il picco moltiplicato per il numero di territori.

La seconda conseguenza riguarda la governance di codice e dati a fine progetto. Uno stack costruito su componenti FLOSS con API documentate è riproducibile da chiunque abbia accesso alle immagini Glance e ai bucket Swift. Non c’è un fornitore da rinnovare per tenere acceso il sistema, e l’audit dell’infrastruttura non richiede accordi di riservatezza. Per un progetto finanziato con fondi pubblici questa proprietà vale quanto le prestazioni.

Limiti

A inizio 2014 OpenStack è una piattaforma giovane: Grizzly ha meno di un anno e l’esperienza operativa della comunità è ancora limitata, soprattutto fuori dai grandi operatori. L’upgrade tra una release e l’altra non è indolore, e il networking (Quantum) è il sottosistema meno maturo. Per un prototipo di ricerca questi rischi sono accettabili; per un esercizio in produzione continuativa andrebbero pesati contro la maggiore stabilità di alternative più conservative.

C’è poi un limite che nessuno strato di infrastruttura risolve: la qualità e l’interoperabilità dei dati culturali a monte. Se i metadati delle opere arrivano da fonti eterogenee senza un modello condiviso, scegliere Swift ed EDM tiene aperta la migrazione ma da solo non produce un grafo interrogabile. Quel lavoro sta a livello applicativo e di curatela, e con l’infrastruttura non lo si compra.

Questo stack confluisce nella proposta SMARTOUR del PON, dove noze cura l’architettura software della prototipazione cloud in partnership con 01 Sistemi: https://www.noze.it/insights/smartour-proposta/.

https://web.archive.org/web/20131117144636/http://www.ponrec.it/bandi/ https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly https://releases.openstack.org/grizzly/ https://pro.europeana.eu/page/linked-open-data https://www.openstreetmap.org/

Immagine di copertina: File di armadi rack pieni di server in una sala data center, con cavi e apparecchiature di rete in vista — foto di Hugovanmeijeren, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Cern_datacenter.jpg