L’evoluzione del data centre viaggia su IP

IP Fabric: ecco come le reti per data centre convergono verso un modello di sviluppo delle applicazioni, nella direzione dei nuovi modelli distribuiti

Giancarlo Viola, Network Innovation Engineer/IP Specialist in GARR.

Negli ultimi anni le applicazioni hanno subito un vero e proprio processo di rivoluzione, che ha segnato il passaggio da un modello monolitico ad uno a microservizi. Questo cambio di paradigma ha avuto impatti importanti non solo sul livello applicativo e sugli aspetti di calcolo, ma anche sulla componente di rete del data centre modificando in maniera sostanziale gli equilibri di traffico e segnando i limiti dei tradizionali modelli Ethernet Fabric. Vediamo cosa è cambiato in questi anni, quali sono le soluzioni che si stanno affermando e cosa serve alle organizzazioni per far fronte a questo cambiamento.

Cambiano le direttrici di traffico

Nel tradizionale modello di data centre, il grosso del traffico era di tipo human-to-machine, mentre la componente machine-to-machine interna al data centre era del tutto marginale. Questo tipo di flusso era, da un punto di vista architetturale, veicolato su un modello di rete gerarchico a 3 livelli, ai cui estremi troviamo l’edge, il livello in cui avviene l’interfacciamento con la rete geografica, e le leaf, in cui avviene invece l’interfacciamento con i sistemi di calcolo e storage del data centre. Al livello intermedio (spine) avviene l’interconnessione interna ad alta capacità.

Con l’abbandono del modello monolitico a favore di architetture più modulari, le applicazioni sono state scomposte in tanti microservizi, la cui elaborazione è poi distribuita sulla molteplicità dei sistemi di calcolo del data centre. Questa distribuzione ha spostato di molto il rapporto tra le direttrici di traffico user-to-machine e machine-to-machine, con un aumento molto significativo di questa componente negli ultimi anni: secondo un recente studio realizzato da Facebook, in un data centre odierno la componente machine-to-machine sarebbe maggiore del traffico human-to-machine di addirittura tre ordini di grandezza.

Nuovi trend, nuovo modello

Questo spostamento delle direttrici di traffico ha evidenziato i limiti tecnologici del modello di tipo Ethernet Fabric, una architettura che non risulta più adeguata a supportare il grosso aumento del traffico interno al data centre provocato dalla disaggregazione e distribuzione delle applicazioni. Il primo e più importante limite di questa architettura rispetto ai nuovi trend di traffico è costituito dalla necessità di dover utilizzare il protocollo di risoluzione dei loop L2 spanning tree, un protocollo adatto a reti a bassa capacità, che non permette un utilizzo ottimale della capacità di rete e con tempi di convergenza nell’ordine dei 10 secondi in caso di guasti mal si adatta alle reti con capacità di trasporto dell’ordine dei 100 Gbps o superiore.

Un secondo limite è rappresentato dalla segregazione: la disaggregazione delle applicazioni infatti porta a un aumento dei domini segregati, ma col meccanismo delle VLAN abbiamo un limite insormontabile di 4.096 VLAN distinte. Più di 4.000 VLAN a disposizione possono sembrare tante, ma nella pratica vediamo che questo comincia ad essere un limite importante e molto reale.

Ultimo punto da prendere in considerazione, forse quello più rilevante sul lungo periodo per l’evoluzione del calcolo in rete, è che l’estensione geografica dei domini di Livello 2, che è una conseguenza del nuovo approccio a microservizi, è vincolata ai servizi L2VPN, VPLS, o lambda dedicate sulla rete DWDM, offerti dall’operatore, quindi è una soluzione meno flessibile e più laboriosa dal punto di vista dell’organizzazione che detiene il data centre distribuito.

La soluzione che si sta affermando nel mondo del calcolo scientifico e non solo, è il passaggio da un modello Ethernet Fabric a un modello IP Fabric. Nel modello IP Fabric ritroviamo i tre livelli edge, spine e leaf, ma quello che cambia è la tipologia di nodi che vengono utilizzati nella Fabric. Si passa da un modello di rete in cui gli apparati spine e leaf sono degli Ethernet switch, ad una Fabric nella quale queste categorie di apparati sono dei router. Un cambiamento che va ad aumentare il livello di integrazione tra la rete di data centre e quella geografica.

I vantaggi di IP Fabric

I vantaggi di utilizzare meccanismi di livello 3 sono diversi: in primo luogo, i protocolli di routing (BGP, IS-IS, OSPF) implementano nativamente meccanismi di impegno dei link equal cost, quindi abbiamo a disposizione tutta la capacità della rete. Inoltre possiamo contare su tempi di convergenza più brevi in caso di guasti, grazie alle funzionalità di fast failure detection e local repair disponibili a livello 3, che permettono di abbassare sostanzialmente i tempi di convergenza (da 10s a 50 ms!). Soprattutto, il modello è molto più scalabile sia per far fronte ad una maggior richiesta di capacità di forwarding che di risorse computazionali. Aumentando il numero di nodi spine, ad esempio, aumenta la capacità di forwarding interna al data centre, e questo in ragione del fatto che nei modelli IP Fabric, diversamente a quanto accadeva all’interno del precedente modello di rete in cui spanning tree forzava il blocco di parte dei link della Fabric, si ha la piena disponibilità di tutti i link di collegamento tra i nodi spine e le leaf.

La possibilità di utilizzare meccanismi di L2 stretching basati sui protocolli EVPN (control plane) e VxLAN (forwarding plane), agevola l’estensione dei domini di Livello 2 (VLAN) tra tutti i nodi di rete del data centre, sia a livello locale che geografico. Ciò rende questo modello particolarmente utile alla realizzazione di modelli di integrazione tra data centre remoti (DCI), e questo in ragione anche della completa interoperabilità tra il piano di controllo della rete del data centre e quello della rete geografica di produzione. Andando a vedere l’evoluzione dei modelli di calcolo e, come dicevo all’inizio, del disegno delle applicazioni stesse possiamo cogliere tutta la rilevanza di questo aspetto: oggi il data centre non è più un oggetto monolitico localizzato in un posto specifico ma, pur mantenendo una sua unità dal punto di vista logico, può essere distribuito in molti siti ed è la stessa evoluzione della capacità delle reti a favorire questo processo.

A livello dei servizi, questo si traduce nella totale trasparenza dal punto di vista dell’utente, che li vede come un oggetto unico e può disinteressarsi della loro collocazione.

Ma il modello ha anche dei difetti...

Naturalmente ci sono anche degli svantaggi e i più accorti ne avranno già intuito uno in particolare da quello che dicevo a proposito della scalabilità: i router sono più costosi e complessi da gestire rispetto agli switch, quindi se è vero che la nostra infrastruttura virtualmente può crescere a piacere, questa crescita non è gratis.

Non è solo una questione economica: la Fabric IP richiede infatti l’abilitazione di diversi protocolli di Livello3 (ad esempio BGP, IGP, EVPN, VxLAN) e quindi ha una configurazione più complessa, che a sua volta richiede maggiori competenze nella gestione operativa, e quindi una curva di apprendimento non banale per le organizzazioni che intendono intraprendere questo cambiamento.

... e soluzioni per superarli

Per gestire questa maggiore complessità è però possibile - e anzi doveroso per le infrastrutture di una certa complessità - lasciar perdere la linea di comando e ricorrere sistematicamente all’automazione: nel caso dell’infrastruttura GARR, l’adozione di Ansible ha consentito la realizzazione di un modello in cui sono lo sviluppo ed il deployment dell’applicazione a pilotare direttamente la propria configurazione di rete. Il modello dichiarativo utilizzato da strumenti come Ansible è lo stesso che viene utilizzato da chi sviluppa i servizi: in questo modo, il deploy del servizio e della rete ad esso dedicata si avvicinano e possono essere pensati in modo organico. Questo non vuol dire che chi gestisce la rete potrà disinteressarsene ma certamente si traduce in una migliore integrazione tra i 2 livelli.