A grandi linee, un Data Center è costituito da un insieme di server, interconnessi tra loro da una rete. I server possono essere stand-alone (bare-metal server), ossia macchine fisiche dove risiedono più applicazioni, senza però alcun tipo di virtualizzazione, o server dove è possibile creare macchine virtuali tramite un Hypervisor, che può essere di nuova o vecchia generazione.

La differenza tra un Hypervisor di nuova generazione e uno di vecchia, è che i primi sono in grado di svolgere la funzione NVE (Network Virtualization Endpoint, che nel caso di incapsulamento VXLAN coincide con la funzione VTEP), mentre i secondi no. Ricordo le che la funzione NVE è quella che consente di incapsulare in ingresso e decapsulare in uscita, pacchetti/trame provenienti e destinati alle macchine virtuali definite sui server; un esempio è la funzione VTEP ampiamente illustrata in questo post. Ogni Data Center ha poi almeno un router gateway che consente l’interconnessione con altri Data Center, con l’Internet, con la rete di un ISP, ecc. . Lo schema generale è riassunto nella figura seguente.

Questo post focalizza l’attenzione sulla rete di interconnessione tra i vari server e router gateway, che per analogia con le vecchie centrali di commutazione, viene chiamata Fabric (vedi sezione successiva). Niente di cui aver timore, la Fabric è una banale rete di cui ogni networker che si rispetti conosce vita morte e miracoli. Perché scriverci un post allora ? La ragione è semplice, nei Data Center di ultima generazione è importante che la Fabric abbia una topologia che sia scalabile, che abbia la possibilità di distribuire in modo efficiente il traffico, semplice da gestire, stabile e con tempi di convergenza possibilmente bassi.

Sembrerebbe un libro dei sogni, ma se ci riflettete bene, le moderne reti degli ISP (almeno di un certo tipo e con determinate topologie) soddisfano già questi requisiti. Per cui, bisogna solo adattare queste reti alla realtà dei Data Center.

Il primo quesito che ci si deve porre circa la Fabric è questo: realizzare una Fabric L2 (= switched Ethernet) o L3 (= IP o IP+MPLS) ? E qui la mia risposta la conoscete già, il routing di Livello 3 è un must, scordatevi di realizzare reti puramente L2, a meno non siate così masochisti da voler dimezzare la banda disponibile a causa dello Spanning Tree , da incorrere in broadcast storm, ecc. ecc. (d’altra parte, avete mai visto un ISP che utilizza una rete L2 a livello geografico ?) .  E poi, lasciate perdere soluzioni ibride come l’utilizzo di TRILL o SPB, non sono sufficientemente testate sul campo, non sono utilizzate da tutti i costruttori e poi sono implementate in modo personalizzato (vedi CiscoFabricPath) impedendo l’interlavoro tra macchine di costruttori diversi (magari è proprio quello che i costruttori desiderano ...).
Semmai l’unico dubbio che rimane è se costruire Fabric di tipo solo IP o IP+MPLS. La tendenza è realizzare Fabric solo IP, anche se qualche costruttore (es. Juniper all’interno della sua QFabric) utilizza MPLS, ma in modo, per così dire, “nascosto”. Per questo da qui in poi farò riferimento alla Fabric chiamandola IP Fabric, per mettere in evidenza che tratterò Fabric solo IP.

L’argomento di questo post riguarda la topologia della IP Fabric. E qui entra in gioco Charles Clos. Parafrasando una nota frase di Manzoniana memoria, qualcuno potrebbe chiedersi “Clos, chi era costui ?”. Nessun problema, i più anziani, o meglio quelli che lavorano in questo settore da molti, molti anni, almeno quelli sufficienti a ricordare le vecchie centrali (telefoniche) di commutazione elettromeccaniche, sanno bene chi era Charles Clos. Divenne famoso, nel settore, perché fu il primo a proporre le reti di commutazione multistadio. Sotto farò qualche richiamo storico, che potete saltare, ma ricordate sempre che “la storia è maestra di vita”.

Il concetto di reti multistadio è stato ripreso, solo a livello topologico, nelle moderne architetture delle IP Fabric, che in onore di Charles Clos, sono chiamate Reti di Clos. E questo spiega il titolo di questo post: dalle Reti di Clos (multistadio nella commutazione telefonica elettromeccanica) si è passati (nuovamente) alle Reti di Clos (sempre multistadio nelle moderne topologie delle IP Fabric). Della serie "Nulla si crea, nulla si distrugge, tutto si trasforma" (Legge di conservazione della massa, Antoine-Laurent de Lavoisier, 1787).

 

Ai tempi della commutazione telefonica basata sulle centrali elettromeccaniche e sulla commutazione di circuito, uno dei problemi principali per una centrale telefonica era quello di creare un collegamento fisico tra un “filo” di ingresso e uno di uscita della centrale. Il problema veniva risolto attraverso una “matrice di commutazione”, ossia un accrocco presente all’interno della centrale, composto da un certo numero di relè elettromeccanici, che aveva il compito di creare il percorso fisico tra il filo di ingresso e il filo di uscita.

Per aumentare la scalabilità, Charles Clos propose in un celebre articolo, pubblicato sull’altrettanto celebre Bell System Technical Journal, di utilizzare invece che una singola grande matrice di commutazione, più matrici di commutazione di dimensione più piccola, interconnesse tra loro (vedi figura seguente, tratta da Wikipedia).
 

 
Il lavoro originale di Clos (per i più curiosi, lo trovate a questo link, ma vi avverto, non è di semplice lettura) non si limitava comunque a proporre una topologia multistadio, ma conteneva uno studio dettagliato sulle proprietà di blocco delle matrici stesse, ossia sulla probabilità che non fosse possibile trovare un percorso interno alla matrice, per collegare i fili di ingresso e uscita. Clos trovò anche una condizione che la topologia della matrice (rete) multistadio doveva soddisfare per divenire non bloccante, ossia la condizione affinché la probabilità di blocco interno della rete multistadio fosse nulla.

E qui mi fermo con la storia. Però vorrei farvi notare un’analogia. Prendete un router modulare con una scheda processore e tante linecard. Come avviene il collegamento tra un interfaccia (filo) di ingresso e una di uscita appartenenti a due diverse linecard ? Bene, il collegamento tra linecard viene realizzato attraverso quella che comunemente viene chiamata fabric, una componente del router che altro non è che una matrice di commutazione (di solito composta da pochi chip dedicati, poiché le linecard sono pochine). Vedete una qualche analogia tra questa Fabric e la IP Fabric dei Data Center ?

 

Considerate per un attimo la figura sopra della matrice di commutazione multistadio (in particolare nella figura la matrice è tristadio) e pensate di eseguire le seguenti due operazioni:

Sostituite a ciascuna di matrice di commutazione elementare un switch, con un numero di porte coincidente con il numero di “fili” di ingresso e di interconnessione. Ad esempio, la matrice di commutazione elementare in alto a sinistra della figura, sarà sostituita da un switch che avrà n fili in ingresso e m fili di interconnessione verso le m matrici di commutazione elementari al centro.

Ripiegate le uscite sugli ingressi (folded Clos network) e ruotate di 90° in senso antiorario il tutto (il senso di questa rotazione è solo formale, non servirebbe ma poiché c’è un linguaggio associato a questa modalità di rappresentazione, bisogna adeguarsi).

Il risultato è la figura seguente:

ossia, una topologia di rete molto semplice, comunemente nota come Leaf-and-Spine, o anche Rete di Clos a tre stadi. Gli switch in basso sono i Leaf e ciascuno di questi ha in totale n + m porte, di cui n lato accesso (dove normalmente sono attestati dei server) e m uplink verso gli switch in alto. Questi ultimi sono gli Spine e sono in numero di norma abbastanza inferiore ai Leaf.

Ciascuno Spine ha r porte downlink verso ciascuno degli r Leaf ed eventualmente un certo numero di (poche) porte uplink verso dei gateway che consentono il forwarding del traffico verso altri DataCenter, verso l’Internet, verso la rete di un ISP, ecc. .

NOTA: La rete di Clos della figura si chiama a tre stadi poiché a partire da un dispositivo collegato ad una porta di un Leaf, per raggiungere un qualsiasi altro dispositivo collegato ad una porta di un Leaf diverso, vengono attraversati tre apparati: Leaf di partenza, uno Spine e il Leaf di arrivo. In Data Center di grandi dimensioni, come ad esempio quelli realizzati da fornitori di servizi Cloud pubblici, è possibile estendere a 5 il numero di stadi, aggiungendo un terzo livello di apparati. Si noti che talvolta più che parlare di stadi si parla di Livelli. Ad esempio, la rete di Clos della figura è a due Livelli: i Leaf sono il Livello 2 e gli Spine il Livello 1.  Parlare di Livelli o di stadi è equivalente, direi che è solo un questione cosmetica. Infatti è chiaro che al Livello 2 corrispondono gli stadi 1 e 3 e al Livello 1 lo stadio 2. Un discorso analogo vale per le reti di Clos a 5 stadi (dove i Livelli sono 3 !).

A questo punto sorge spontanea la domanda: ma quali sono i vantaggi di una topologia di tipo Leaf-and-Spine ? Eccone alcuni:

È semplice e altamente scalabile. Pensate ad esempio ad una crescita del vostro DataCenter, che richiede un numero maggiore di porte di accesso rispetto a quelle disponibili. In sintesi, è necessario aggiungere un nuovo Leaf(o più di uno). Se gli Spine hanno porte downlink a sufficienza, tutto si risolve nell’acquistare uno o più switch che avranno il ruolo di Leaf, e connetterli agli Spine. Tutti gli altri Leaf non subiranno alcun cambiamento, né fisico, né in termini di configurazioni aggiuntive (in molti casi). (NOTA: questo tipo di scalabilità viene detto nella letteratura anglo-sassone “scale out”, a differenza della scalabilità di tipo “scale up” che invece consente di ampliare la capacità della rete aumentando la banda disponibile e la potenza degli apparati (e non il loro numero). Scusatemi se vi faccio queste precisazioni, ma spesso nei documenti in inglese trovate questi termini e adesso sapete quale è la differenza)

Consente una più agevole distribuzione del traffico tra i vari link. Infatti, dal punto di vista del routing di Livello 3, a meno che non alteriate le metriche delle interfacce, avete sempre a disposizione da ciascun Leaf, mpercorsi a minimo costo disponibili, verso ciascun altro Leaf. Ciò consente di effettuare un ECMP (Equal Cost Multi-Path, meglio noto come Load Balancing) del traffico inter-Leaf (che per analogia geografica viene spesso indicato come Est-Ovest) tra tutti gli m percorsi disponibili.

Consente l’utilizzo di switch in configurazione (fisica) fissa, che sono molto meno costosi di switch basati suchassiscon slot Questo aspetto sarà più chiaro nella prossima sezione, quando illustrerò un po’ di “aritmetica” associata alle topologie Leaf-and-Spine.

Consente una sostanziale riduzione di CAPEX e OPEX. Infatti, la possibilità di utilizzare switch in configurazione fissa, preferibilmente utilizzando lo stesso Hardware, consente notevoli economie di scala, con conseguente riduzione dei costi di deployment(CAPEX). Tenete conto che la parte networking di un Data Center incide per il 10-15% del costo complessivo, non molto, ma non trascurabile. Poi, avere una topologia semplice, apparati uguali e con configurazioni praticamente identiche riduce di molto anche le spese di esercizio (OPEX) del Data Center.

Come sempre, non sono però solo rose. Una topologia Leaf-and-Spine richiede un cablaggio più complesso e costoso. Inoltre, la scalabilità ha un suo limite, legato al numero delle porte disponibili. Si rischia di arrivare al punto di non avere più porte disponibili. Anche questo si capirà meglio nella prossima sezione. La soluzione in questo caso è aumentare il numero degli stadi (o dei Livelli), passando ad esempio da reti a tre stadi (due livelli) a reti a 5 stadi (tre livelli).

UN PO’ DI CONTI

Vediamo ora di fare un po’ di conti, con degli esempi reali. Ma prima di fare “i compiti di aritmetica” (perché di aritmetica si tratta) è bene avere chiari alcuni aspetti di progettazione, che condizionano il risultato finale. Il punto è: quali sono i dati di partenza ? Bene, due sono i dati da cui partire (poi comunque ne servono anche altri):

Il fattore di sovraccarico (oversubscription ratio) : è il rapporto tra la banda totale lato accesso e la banda totale degli uplinkdi un Leaf. Ad esempio, supponiamo di avere un switch con 48 porte da 10 Gibt/s da utilizzare lato accesso e 4 porte da 40 Gbit/s da utilizzare come uplink. Il fattore di sovraccarico è (10*48)/(4*40) = 3, di solito espresso come 3:1. Non ho fatto questo esempio a caso perché nella pratica corrente, il fattore di sovraccarico 3:1 è considerato il giusto bilanciamento tra costo e prestazioni (perché è ovvio che un fattore di sovraccarico basso comporta migliori prestazioni ma un costo più elevato; viceversa per un fattore di sovraccarico alto).

Il numero totale di porte di accesso necessarie. Questo consente di determinare il numero di Leafnecessari, nota la disponibilità di porte di accesso di ciascun Leaf.

Farò ora un paio di esempi, il primo per un Data Center di medie dimensioni, il secondo per un Data Center di grandi dimensioni, che mi consentirà anche di introdurre il concetto di Virtual Spine (vSpine).

Per il primo esempio, partiamo da questi dati:

Fattore di sovraccarico = 3:1.

Numero di porte di accesso necessarie = 700.

Disponibilità di switch Leaf con 48 porte di accesso a 10 Gbit/s e 4 porte uplink a 40 Gbit/s (di switch di questo tipo in commercio ne trovate a iosa).

Disponibilità di switch Spine con 24 porte a 40 Gbit/s (anche di switch di questo tipo in commercio ne trovate a iosa).

Il numero di Leaf necessari si calcola facendo il rapporto 700/48 e prendendo l’intero superiore. In questo caso viene fuori 15. Per avere un po’ di margine per future espansioni, supponiamo di “acquistare” 16 switch Leaf, per un totale di 48*16 = 768 porte di accesso.

Ora, per far si che il fattore di sovraccarico sia 3:1, utilizziamo le 4 porte uplink da 40 Gbit/s verso gli Spine. Ne consegue che abbiamo bisogno di 4 Spine. Poiché ciascun Spine è collegato a tutti i Leaf, delle 24 porte disponibili a 40 Gbit/s, se ne utilizzano 16, le altre sono a disposizione per eventuali collegamenti verso i gateway per l’interconnessione con altri Data Center, o per l’accesso a Internet, o per l’accesso ad altri servizi forniti da un ISP. Il risultato finale è riassunto nella figura seguente.

Vi lascio un piccolo esercizio. Supponendo di partire con questi dati:

Fattore di sovraccarico = 3:1.

Disponibilità di switch Leaf con 96 porte di accesso a 10 Gbit/s e 8 porte uplink a 40 Gbit/s (es. Juniper QFX5100-96S).

Disponibilità di switch Spine con 32 porte a 40 Gbit/s (es. Juniper QFX5100-24Q).

La domanda è la seguente: quale è il numero massimo di porte di accesso a 10 Gbit/s che è possibile realizzare ? (Risposta : 3,072 se utilizzate tutte le porte disponibili sugli Spine; se invece lasciate due porte libere sugli Spine per eventuali collegamenti verso una coppia di gateway, 2.880).

Ora voglio fare un esempio di un Data Center di grandi dimensioni. Invece di partire dal numero di porte necessarie, farò un calcolo simile all’esercizio che vi ho lasciato. L’obiettivo è costruire un Data Center che abbia disponibili almeno 40.000 porte di accesso a 10 Gbit/s.
Se utilizzassi una architettura a tre stadi (= due livelli) come quella dell’esempio precedente utilizzando la stessa tipologia di macchine, con 4 conti ci si rende conto che è mission impossible. Infatti, un rapido calcolo mostra che per avere più di 40.000 porte in accesso avrei bisogno di almeno 417 switch. Il problema però non è tanto questo (basta convincere il CFO a sganciare soldi a sufficienza !), ma è che ci vorrebbero Spine da almeno 417 porte, che in commercio non fa nessuno (o almeno, io non li ho mai visti). Come risolvere l’arcano ? Partiamo da una considerazione: quali proprietà deve avere uno Spine ? Bene, a grandi linee queste: deve avere un fattore di sovraccarico 1:1 e generalmente interfacce a 40 Gbit/s (in futuro magari a 100 Gbit/s).

Allora l’idea è questa: costruire degli Spine virtuali (vSpine) costituiti a loro volta da reti di Clos a tre stadi, ma con fattore di sovraccarico 1:1. Quindi utilizzare questi Spine virtuali come fossero a tutti gli effetti degli Spine fisici.

Facciamo un po’ di conti. Supponiamo di utilizzare per gli Spine virtuali, switch con 32 porte da 40 Gbt/s (es. Juniper QFX5100-24Q con due slot aggiuntivi da 4x40 Gbit/s ciascuno). Domanda: quale è la rete di Clos a tre stadi con il numero massimo di porte di accesso a 40 Gbit/s, ipotizzando un fattore di sovraccarico 1:1 ? Vi lascio i conticini come esercizio. Il risultato è 512x40 Gbit/s. Ora, considerando questa rete di Clos come un unico Spine (e ciò è lecito, il fattore di sovraccarico è 1:1 e le porte sono a 40 Gbit/s), per il nostro Data Center è come se avessimo Spine (virtuali) con 512 porte a 40 Gbit/s, e quindi possiamo creare una rete di Clos con un massimo di 512 Leaf. Ipotizzando che ciascuno di questi abbia 96 porte a 10 Gbit/s, ecco qua che abbiamo realizzato una IP Fabric con 96x512 = 49.152 porte di accesso a 10 Gbit/s (una roba mostruosa, ma si può fare di meglio, basta avere sufficiente budget !). Il risultato finale è una rete di Clos a 5 stadi (3 livelli) ed è riassunto nella figura seguente.

 

 
Sempre per avere un’idea di quali dimensioni stiamo parlando, facciamo un conto rapido di quante macchine virtuali possiamo gestire con un simile mostro. Faccio un’ipotesi conservativa, per ciascun server fisico è possibile attivare 50 macchine virtuali (con lo sviluppo attuale dei server questo numero è sicuramente basso, ma come ho detto voglio essere conservativo). Inoltre, suppongo che ciascun server fisico abbia un doppio collegamento a 10 Gbit/s verso la IP Fabric. In totale posso quindi attestare 49.152/2 = 24.576 server fisici, e quindi attivare 24.576*50 = 1.228.800 macchine virtuali ! Quanti sono i Data Center che hanno bisogno di gestire un così elevato numero di macchine virtuali? E tenete conto che sono stato molto conservativo !

E tenete anche conto che la stragrande maggioranza dei Data Center non supera i 1.000 server (virtuali). E che con questi numeri potete costruirvi un Data Center con un solo rack da 42RU ! (leggetevi questo post, estremamente interessante). E considerate anche, come dice il mio amico Ivan Pepelnjak, uno dei maggiori esperti al mondo dinetworking, che per la stragrande maggioranza dei Data Center sono sufficienti solo 2 switch Top-of-Rack (vedi questo post) !

 

Questa potrebbe sembrare a prima vista una domanda sciocca. Ma come, con tutta l’esperienza che c’è sul campo del routing delle reti ISP, che sono molto più grandi di un Data Center anche di grandi dimensioni, perché dovremmo preoccuparci di quali protocolli di routing scegliere? Ebbene si, il problema potrebbe porsi nei Data Center di grandi dimensioni, dove i classici protocolli IGP (OSPF e IS-IS, gli altri nemmeno li considero) potrebbero portare a seri problemi di scalabilità. Che fare allora ?

Nei Data Center di dimensioni medio-piccole, dove la IP Fabric è costituita da poche decine di router, il problema non si pone, è possibile utilizzare un classico protocollo IGP come OSPF o IS-IS. Con qualche accorgimento progettuale, ben noto a chi lavora con i protocolli IGP (NOTA: la lista seguente è da considerarsi minimale, non certamente esaustiva):

Utilizzate OSPF in area singola o IS-IS a livello singolo. Se una IP Fabricha modeste dimensioni, ha poco senso partizionare il dominio di routing. Se da un lato la partizione aumenta la stabilità della IP Fabric, dall’altro aumenta la complessità dei LSDB e quindi di troubleshooting.

Utilizzate un piano di numerazione semplice e coerente. Ad esempio, utilizzate per tutti gli indirizzi IP dell’infrastruttura della IP Fabric, indirizzi (privati) della RFC 1918, possibilmente tratti da una unica grande subnet IP. Per le Loopback utilizzate maschere /32 nel caso IPv4 e /128 nel caso IPv6, per i collegamenti punto-punto maschere /30 o meglio /31 nel caso IPv4 e /64 o /127 nel caso IPv6 (su  quest’ultima scelta i pareri non sono concordi, ma è una discussione di lana caprina !).

Annunciate solo ciò che serve, e cercate di evitare una grande quantità di redistribuzioni di subnetesterne nel dominio di routing. Potreste incorrere in seri problemi di scalabilità. Questo è il vero punto debole di OSPF e IS-IS.

Mantenete le configurazioni semplici, ma eleganti. Ad esempio, definite le interfacce di Loopback come passive, definite tutti i collegamenti Leaf-Spine come punto-punto (NOTA: questi collegamenti sono Ethernet, e se non comunicate al processo di routing di considerarli come punto-punto, di default su questi collegamenti vengono eletti DR e BDR nel caso di OSPF e DIS nel caso di IS-IS, cosa perfettamente inutile (a dire il vero anche un po’ dannosa) nei collegamenti punto-punto). Inoltre, non alterate le metriche di default, ne potrebbero risentire le proprietà di Load Balancing.

Per i Data Center di grandi dimensioni, dove la IP Fabric è costituita da centinaia di L3-switch (ossia, router con molte interfacce Ethernet), il discorso cambia. Ma prima di approfondirlo, dobbiamo chiederci: quali caratteristiche dovrebbe avere un protocollo di routing in una IP Fabric di grandi dimensioni ? Bene, questo è un elenco:

Essere scalabile in termini di gestione dei prefissi IP, ossia poter gestire senza problemi tabelle di decine di migliaia di prefissi IP.

Avere una implementazione semplice, stabile e supportata da tutti i principali costruttori, così da consentire l’interlavoro senza problemi.

Minimizzare l’ambito di propagazione di un fuori servizio di un nodo o di un link, in modo da avere una rete più stabile ed avere tempi di convergenza molto contenuti (dell’ordine delle decine di msec).

Consentire un minimo di gestione del traffico, preferibilmente attraverso un controllo diretto del Next-Hop, utilizzando metriche facilmente manipolabili.

Consentire in modo semplice il multipath (o ECMP o Load balancing, tutti sinonimi).

Infine, dovrebbe poter funzionare senza l’ausilio di altri protocolli di routing.

Bene, a questo punto la domanda sorge spontanea: quale è il protocollo che soddisfa tutti questi requisiti ? La risposta è semplice (e per qualche verso un po’ inaspettata): il caro vecchio BGP. Ebbene si, nei Data Center di grandi dimensioni si va facendo strada l’idea di utilizzare il BGP come (unico e solo) protocollo IGP, tanto che si parla di retiIGP-free. La proposta è partita da quel genio del Networking che è Petr Lapukhov che è co-autore di questo draft IETF in cui descrive vari aspetti motivazionali e decisionali legati all’utilizzo di BGP come unico e solo protocollo di routing di una IP Fabric. Ma su questo ritornerò in un prossimo post, questo termina qui.

CONCLUSIONI

Le IP Fabric dei moderni Data Center utilizzano topologie mutuate dalle matrici di commutazione multistadio delle vecchie centrali telefoniche elettromeccaniche (corsi e ricorsi della storia), proposte da Charles Clos nei primi anni 50 del secolo scorso. Le topologie multistadio hanno il vantaggio di essere semplici e molto scalabili e sono diventate ormai lo standard de facto delle IP Fabric nei Data Center. In funzione della grandezza del Data Center, vengono utilizzate topologie a tre stadi (due livelli)  o a cinque stadi (tre livelli). Un aspetto interessante riguarda il protocollo IGP. Come ho scritto nell’ultima sezione di questo post, per le IP Fabric dei Data Center di grandi dimensioni è stato proposto l’utilizzo, in maniera un po’ atipica rispetto alle nostre (almeno alle mie) concezioni, del solo protocollo BGP. Approfondirò questo interessante argomento in un prossimo post.

Coming up next... il Capitolo 11 del libro su IS-IS (e il Capitolo 10 che fine ha fatto ?).