- Home
- Altre rubriche
- La Nuvola
- Ultra affidabilità con la GARR Kubernetes cluster federation
Ultra affidabilità con la GARR Kubernetes cluster federation
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.
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
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.
Abbiamo esportato una “ricetta zero-everything” per la federazione di infrastrutture cloud private, allontanando progressivamente la complessità dall’utente finale
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.
Dai un voto da 1 a 5, ne terremo conto per scrivere i prossimi articoli.
Voto attuale:
-
il filo - inverno 2020Editoriale
-
Deep learning nella cura dei tumori: l’algoritmo che impara a farci star megliocaffè scientifico
-
Malattie cardiovascolari: controllare i fattori di rischio da oggi si puòcaffè scientifico
-
ICDI per la gestione dei dati clinicicaffè scientifico
-
Accesso aperto per far crescere la ricerca sanitariacaffè scientifico
-
Identità digitale: avanti tuttaservizi alla comunità
-
Trent’anni da nocchieriservizi alla comunità
-
Sinergia nelle scelte strategiche per una scuola al top!la voce della comunità
-
Dove poggiano le nuvolela voce della comunità
-
Terabit Network: in arrivo la nuova generazione di reteosservatorio della rete
-
LHC: risorse di calcolo miste per le sfide del futuroosservatorio della rete
-
Nella tana del Bianconiglio con le lambda alieneosservatorio della rete
-
In zero we trust!cybersecurity
-
Come verificare la sicurezza di una connessione HTTPScybersecurity
-
I mille volti ambigui del social engineeringcybersecurity
-
Ultra affidabilità con la GARR Kubernetes cluster federationla nuvola della ricerca e istruzione
-
Dentro KubeFedla nuvola della ricerca e istruzione
-
Il modello di servizi cloud all’Università di Milano-Bicoccala nuvola della ricerca e istruzione
-
Dalle stelle alle profondità marine con l’Open Sciencela nuvola della ricerca e istruzione
-
L’Europa punta sul cloud della ricercainternazionale
-
Horizon 2020: ultimo migliointernazionale
-
Verso le città del futuro, tra tecnologie smart e caos creativoieri, oggi, domani
-
Monitoring della rete: nuova versione per la suite GARRpillole di rete
-
Un’italiana in prima linea per l’open science in Europapillole di rete
-
EERAdata, punto di ingresso ai dati nel settore energia per la ricerca in Europala voce della comunità
-
Almanacco, dieci e vent’anni…la voce della comunità
-
L’INGV inaugura il Portale Dati Apertila voce della comunità
-
Caccia al tesoro astronomicala voce della comunità
Articoli nella rubrica
-
di Elis Bertazzon
-
di Matteo Di Fazio, Marco Lorini
-
di Enzo Ludovici
-
di Maddalena Vario
Archivio GARR NEWS
- Numero 29 - anno 2023
- Numero 28 - anno 2023
- Numero 27 - anno 2022
- Numero 26 - anno 2022
- Numero 25 - anno 2021
- Numero 24 - anno 2021
- Numero 23 - anno 2020
- Numero 22 - anno 2020
- Numero 21 - anno 2019
- Numero 20 - anno 2019
- Numero 19 - anno 2018
- Numero 18 - anno 2018
- Numero 17 - anno 2017
- Numero 16 - anno 2017
- Numero 15 - anno 2016
- Numero 14 - anno 2016
- Numero 13 - anno 2015
- Numero 12 - anno 2015
- Numero 11 - anno 2014
- Numero 10 - anno 2014
- Numero 9 - anno 2013
- Numero 8 - anno 2013
- Numero 7 - anno 2012
- Numero 6 - anno 2012
- Numero 5 - anno 2011
- Numero 4 - anno 2011
- Numero 3 - anno 2010
- Numero 2 - anno 2010
- Numero 1 - anno 2009
- Numero 0 - anno 2009