Ecco come verrà realizzata un’infrastruttura multi-region per offrire affidabilità e trasparenza ai servizi degli utenti

L’infrastruttura container, sviluppata sulla piattaforma GARR Cloud in questi ultimi anni accanto alla più tradizionale infrastruttura OpenStack, propone un approccio più agile alla virtualizzazione che, invece di simulare tutto l’hardware come nelle macchine virtuali, avviene al livello del kernel del sistema operativo.

Alex Barchiesi lavora in GARR come senior cloud architect and engineer

Per gestire l’orchestrazione delle applicazioni multiutente in questo ambiente, la piattaforma GARR cloud utilizza Kubernetes, lo strumento più diffuso per l’automazione del dispiegamento di container mentre, per gestire installazione e configurazione, sfrutta gli stessi strumenti di automazione che usa per gestire la cloud, ossia MaaS e Juju. MaaS (Metal as a Service) rende disponibili i server fisici o virtuali sui quali Juju installa in maniera automatica e scalabile i componenti della piattaforma OpenStack e Kubernetes. Ne abbiamo parlato con Alex Barchiesi, senior cloud architect e engineer al GARR.

Qual è il principale punto di forza dell’approccio scelto dalla piattaforma GARR Cloud?

Abbiamo esportato una “ricetta zero-everything” per la federazione di infrastrutture cloud private, allontanando progressivamente la complessità dall’utente finale, senza necessariamente cedere la proprietà dell’infrastruttura, dei dati e delle competenze verso provider commerciali. Allo stesso tempo abbiamo fatto in modo di fornire un’architettura di riferimento completa a vari livelli (IaaS, PaaS, DaaS), in modo da poter aggiungere risorse a quella che un giorno ci auguriamo possa diventare un’unica cloud nazionale della ricerca.

Come ci siete riusciti?

Abbiamo creato uno stack di automazione dichiarativo piuttosto che procedurale che permette di passare in modo estremamente rapido dal livello fisico al livello applicativo. È basato su Juju e MaaS ed è agnostico verso il back end (da server fisici a macchine virtuali messe a disposizione da qualunque provider, anche commerciale).

I container sembrano essere il nuovo paradigma del cloud. Si potrebbe pensare di federare in futuro anche questo livello?

Certamente. Come spiegavo, il nostro concetto di federazione è a molti livelli. Si può accedere a qualunque livello, ma è importante fornire una ricetta per ognuno di essi.

Si parte dal livello Infrastructure as a Service, che vuol dire federare le infrastrutture per chi non vuole abbandonare le competenze di cloud, vuol mantenere la proprietà sulla propria piattaforma HW e allo stesso tempo beneficiare di una architettura di riferimento maturata dalle necessità di anni di ricerca fatta in GARR, utilizzando esclusivamente software open-source (vedi OpenStack). Si può fare a livello Deployment as a Service, ovvero indipendentemente dall’infrastruttura sottostante, attraverso la condivisione di cataloghi di deployment dichiarativi, che possono fare perno su qualunque cloud di backend e, ovviamente, anche sulla IaaS federata.

Al momento, siamo nella fase di test per un ulteriore passaggio: federazione di Platform as a Service per arrivare a qualcosa di unico: una federazione di orchestratori di container. Quando l’abbiamo pensata abbiamo notato che si poteva ambire a far sì che il deployment delle applicazioni di un utente potesse essere migrato in modo trasparente dal suo data centre a quelli federati ed eventualmente a quelli commerciali. Abbiamo chiamato questa feature Ultra HA (alta affidabilità); per ora sembra molto promettente, ma dipenderà dai casi d’uso. Sicuramente ogni livello federativo può essere un punto di partenza, ma non va dimenticato che ognuno è necessario per fare da base al successivo.

Come è nata l’idea della federazione di orchestratori di Container?

Ci siamo resi conto che, pur avendo implementato un sistema sicuro e affidabile, la percezione dell’affidabilità delle applicazioni che gli utenti decidono di installare in cloud è spesso sovrastimata e manca la concreta percezione che queste risorse possano davvero andare offline in caso di errore applicativo. Quello che concretamente abbiamo fatto è stato sconfinare un po’ verso il workload utente per aumentare ulteriormente questa alta affidabilità, spostandola parzialmente dal livello utente a quello infrastrutturale. Il sistema di automazione che abbiamo progettato può replicare qualunque numero di cluster Kubernetes in maniera estremamente rapida e, grazie allo strumento che va sotto il nome di KubeFed, possiamo unificarli e gestirli come se fossero un singolo cluster. A KubeFed associamo un meccanismo di gestione di record DNS, denominato ExternalDNS, che ci permette di completare il quadro per ottenere un’architettura in alta affidabilità. Come dicevamo, l’abbiamo chiamata ultra HA platform e questo perché fornisce una HA nativa a livello di multisito, anche usando come backend cloud provider terzi, fornendo così a Juju dei backend AWS, Google Cloud, Azure o altri provider commerciali al posto di risorse HW proprie.

Dopo IaaS, PaaS e DaaS, quale sarà il prossimo livello?

A breve vedremo apparire FaaS (Function as a Service) e numerosi altri modelli seguiranno e potranno essere realizzati, ma solo se nella ricerca italiana continueremo a mantenere le competenze necessarie (che hanno permesso sino ad oggi di progredire insieme e di sperimentare sempre nuove soluzioni), la sovranità sulle infrastrutture (che permettono alle suddette competenze di svilupparsi in modo impossibile altrimenti) ed uno sguardo verso le tecnologie mainstream, che inevitabilmente sono dominate dai grandi player, per integrarle e sfruttarne le possibilità, senza vederle necessariamente come avverse.

In particolare, questo è quello che abbiamo fatto con la scelta iniziale di poggiare su due progetti mainstream la nostra cloud: OpenStack e Canonical oppure con la scelta di Kubernetes. Ciò ci ha ci permesso di avere a disposizione cataloghi enormi che raccolgono le realtà più eterogenee, de facto in uno standard che non avrebbe senso pensare di reinventare.