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.
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.
Il nostro concetto di federazione è a molti livelli: si può accedere a tutti, ma è importante fornire una ricetta per ognuno di essi
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.
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).
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.
Abbiamo esportato una “ricetta zero-everything” per la federazione di infrastrutture cloud private, allontanando progressivamente la complessità dall’utente finale
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.
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.
Il contenuto di questo sito è rilasciato, tranne dove altrimenti indicato,
secondo i termini della licenza Creative Commons attribuzione - Non commerciale Condividi allo stesso modo 3.0 Italia
GARR News è edito da Consortium GARR, la rete italiana dell'università e della ricerca
GARR News n°23 - inverno 2020 - Tiratura: 9.000 copie - Chiuso in redazione: 20 dicembre 2020
Hanno collaborato a questo numero: Silvia Arezzini, Claudio Barchesi, Alex Barchiesi, Tommaso Boccali, Paolo Bolletta, Alberto Colla, Paola De Castro, Valeria De Paola, Matteo Di Fazio, Marco Falzetti, Marco Ferrazzoli, Marco Galliani, Mara Gualandi, Marco Incarbone, Alessandro Inzerilli, Emma Lazzeri, Marco Lorini, Enzo Ludovici, Luisa Minghetti, Laura Moretti, Stefano Moroni, Alberto Mura, Delia Passalacqua, Michele Petito, Claudio Pisa, Maurizio Polano, Vincenzo Puglia, Mariella Rauseo, Roberto Ricci, Matteo Robiglio, Giorgio Rossi, Valeria Rossi, Andrea Salvati, Eva Sciacca, Riccardo Smareglia, Elena Tremoli, Simona Venuti, Davide Vaghetti, Gloria Vuagnin, Federico Zambelli, Stefano Zani
Abbiamo 84 visitatori e nessun utente online