Abbiamo sviluppato un design di rete per i data center che consente di implementare cluster di calcolo con più di 100.000 server, con una larghezza di banda di bisezione superiore a un petabyte al secondo.
Dalla relazione di Dmitry Afanasyev apprenderete i principi fondamentali del nuovo design, la scalabilità delle topologie, i problemi che sorgono, le soluzioni possibili, le peculiarità della routing e della scalabilità delle funzioni del forwarding plane nei moderni dispositivi di rete in topologie 'densamente connesse' con un grande numero di percorsi ECMP. Inoltre, Dima ha brevemente parlato dell'organizzazione della connettività esterna, del livello fisico, del sistema di cablaggio e dei modi per aumentare ulteriormente la capacità.
— Buongiorno a tutti! Mi chiamo Dmitry Afanasyev, sono architetto di rete in Yandex e mi occupo principalmente del design delle reti dei data center.
Il mio intervento riguarderà la rete aggiornata dei data center di Yandex. Questa è in larga misura un'evoluzione del design che avevamo, ma ci sono anche alcuni nuovi elementi. Si tratta di una presentazione di panoramica, poiché era necessario condensare molte informazioni in poco tempo. Inizieremo con la scelta della topologia logica. Poi daremo un'occhiata al control plane e ai problemi di scalabilità del data plane, la scelta di ciò che accadrà a livello fisico, esamineremo alcune caratteristiche dei dispositivi. Accenneremo anche a ciò che sta accadendo nel data center con MPLS, di cui abbiamo parlato qualche tempo fa.
Quindi, cos'è Yandex in termini di carichi e servizi? Yandex è un tipico hyprescaler. Se guardiamo agli utenti, si tratta innanzitutto dell'elaborazione delle richieste degli utenti. Ci sono anche vari servizi di streaming e fornitura di dati, perché abbiamo anche servizi di storage. Se ci avviciniamo al backend, compaiono carichi e servizi infrastrutturali, come sistemi di archiviazione a oggetti distribuiti, replicazione dei dati e, naturalmente, code persistenti. Uno dei principali tipi di carico è MapReduce e sistemi simili, elaborazione in streaming, machine learning, ecc.
Com'è strutturata l'infrastruttura su cui avviene tutto questo? Ancora una volta, siamo un iper-scalatore piuttosto tipico, anche se, forse, ci troviamo un po' più vicino a quel lato dello spettro dove si trovano gli iper-scalatori più piccoli. Ma abbiamo tutti gli attributi. Utilizziamo hardware di consumo e scalabilità orizzontale ovunque sia possibile. Abbiamo una politica di pooling delle risorse completamente sviluppata: non lavoriamo con singole macchine o rack separati, ma li uniamo in un grande pool di risorse intercambiabili con alcuni servizi aggiuntivi che si occupano della pianificazione e della allocazione, e lavoriamo con tutto questo pool.
Così abbiamo un livello successivo — un sistema operativo a livello di cluster di calcolo. È molto importante che controlliamo completamente il stack tecnologico che utilizziamo. Controlliamo gli endpoint (host), la rete e il stack software.
Abbiamo diversi grandi data center in Russia e all'estero. Sono collegati da una backbone che utilizza la tecnologia MPLS. La nostra infrastruttura interna è praticamente completamente costruita su IPv6, ma poiché dobbiamo gestire il traffico esterno, che ancora proviene principalmente da IPv4, dobbiamo in qualche modo instradare le richieste che arrivano tramite IPv4 verso il frontend-server, e un po' di tempo anche sul web esterno in IPv4 - ad esempio, per l'indicizzazione.
Le ultime iterazioni del design delle reti dei data center utilizzano topologie Clos multilivello e utilizzano solo L3. Abbiamo abbandonato L2 qualche tempo fa e abbiamo tirato un sospiro di sollievo. Infine, la nostra infrastruttura include centinaia di migliaia di istanze di calcolo (server). La dimensione massima del cluster qualche tempo fa era di circa 10.000 server. Questo è stato in gran parte determinato da come possono funzionare i sistemi operativi a livello di cluster, i pianificatori, l'allocazione delle risorse, ecc. Poiché c'è stato un progresso dal lato del software infrastrutturale, ora l'obiettivo è una dimensione di circa 100.000 server in un unico cluster di calcolo, e abbiamo la sfida di saper costruire fabbriche di rete che consentano di effettuare un pooling efficiente delle risorse in un tale cluster.
Cosa vogliamo dalla rete dei data center? Prima di tutto, vogliamo molta larghezza di banda a basso costo e distribuita in modo sufficientemente omogeneo. Perché la rete è la base che ci consente di effettuare il pooling delle risorse. La nuova dimensione target è di circa 100.000 server in un cluster.
Inoltre, vogliamo un control plane scalabile e stabile, perché su un'infrastruttura così grande sorgono molte preoccupazioni anche a causa di eventi casuali, e non vogliamo che il control plane ci dia ulteriore mal di testa. Allo stesso tempo, vogliamo minimizzare lo stato in esso. Meno stato c'è, meglio e più stabilmente tutto funziona, più semplice è la diagnostica.
Naturalmente, abbiamo bisogno di automazione, perché gestire manualmente un'infrastruttura del genere è impossibile ed era già impossibile da tempo. Abbiamo bisogno, per quanto possibile, di supporto alle operazioni e supporto CI/CD, nella misura in cui ciò possa essere garantito.
Con dimensioni così grandi dei data center e dei cluster, è diventata cruciale la questione del supporto per il deployment incrementale e l'espansione senza interruzione del servizio. Se per cluster di dimensioni pari a mille macchine, e forse vicine a diecimila macchine, era possibile eseguire il deployment come un'unica operazione—cioè pianifichiamo l'espansione dell'infrastruttura e aggiungiamo diverse migliaia di macchine come un'unica operazione—un cluster di dimensioni vicine a centomila macchine non si forma all'improvviso; viene costruito nel tempo. È auspicabile che, per tutto quel tempo, ciò che è già stato messo in funzione, cioè l'infrastruttura che è stata implementata, sia accessibile.
E un requisito che avevamo e che non abbiamo più: è il supporto per il multitenancy, cioè la virtualizzazione o segmentazione della rete. Ora non è necessario farlo a livello della rete, perché la segmentazione è stata trasferita sugli host, e questo ha notevolmente semplificato la scalabilità. Grazie a IPv6 e a un ampio spazio di indirizzamento, non abbiamo dovuto usare indirizzi duplicati nell'infrastruttura interna, perché tutta l'indirizzatura era già unica. E poiché abbiamo spostato il filtraggio e la segmentazione della rete sugli host, non c'è bisogno di creare entità di rete virtuali nelle reti dei data center.
Una cosa molto importante è ciò di cui non abbiamo bisogno. Se alcune funzioni possono essere rimosse dalla rete, questo semplifica notevolmente la vita e, in genere, amplia la scelta dell'hardware e del software disponibili, facilitando notevolmente la diagnostica.
Quindi, di cosa non abbiamo bisogno, da cosa abbiamo potuto rinunciare, non sempre con gioia nel momento in cui accadeva, ma con grande sollievo quando il processo si concludeva?
In primo luogo, abbiamo rinunciato all'L2. Non abbiamo bisogno dell'L2, né reale né emulato. Non viene utilizzato in misura significativa grazie al fatto che controlliamo lo stack delle applicazioni. Le nostre applicazioni si scalano orizzontalmente, funzionano con indirizzamento L3, non si preoccupano molto se un'istanza specifica si spegne, semplicemente ne lanciano una nuova, non è necessario che si attivi sul vecchio indirizzo, poiché c'è un livello separato di discovery dei servizi e monitoraggio delle macchine nel cluster. Non delegiamo questo compito alla rete. Il compito della rete è di consegnare pacchetti da punto A a punto B.
Non abbiamo neanche situazioni in cui gli indirizzi si spostano all'interno della rete e devono essere monitorati. In molti design, ciò è solitamente necessario per supportare la mobilità delle VM. Non utilizziamo la mobilità delle macchine virtuali nell'infrastruttura interna del grande Yandex e, inoltre, riteniamo che, anche se viene implementata, non dovrebbe avvenire a supporto della rete. Se è necessario farlo, deve essere gestito a livello degli host, e portare gli indirizzi che possono migrare in overlay, per non toccare e non apportare troppe modifiche dinamiche al sistema di routing della rete sottostante (rete di trasporto).
Un'altra tecnologia che non utilizziamo è il multicast. Posso spiegare dettagliatamente a chi fosse interessato il perché. Questo semplifica notevolmente la vita, perché, se qualcuno ha avuto a che fare con esso e ha osservato com'è il piano di controllo del multicast — in tutte le installazioni, tranne che nelle più semplici, è un grande mal di testa. Inoltre, è difficile trovare un'implementazione open source che funzioni bene, ad esempio.
Infine, progettiamo le nostre reti in modo che non subiscano troppi cambiamenti. Possiamo contare sul fatto che il flusso di eventi esterni nel sistema di routing è ridotto.
Quali problemi sorgono e quali limitazioni dobbiamo considerare quando sviluppiamo una rete di data center? Certamente i costi. La scalabilità, fino a quale livello vogliamo crescere. La necessità di espandere senza interrompere il servizio. La larghezza di banda, la disponibilità. La visibilità di ciò che accade nella rete, per i sistemi di monitoraggio, per i team operativi. Supporto per l'automazione — di nuovo, per quanto possibile, dato che vari compiti possono essere risolti a diversi livelli, incluse l'introduzione di ulteriori strati. E la non-[dipendenza]-dai fornitori. Anche se in diversi periodi storici, a seconda di quale segmento si osserva, questa indipendenza è stata più o meno raggiungibile. Se consideriamo il segmento dei chip di dispositivi di rete, fino a poco tempo fa parlare di indipendenza dai fornitori, se cercavamo anche chip ad alta velocità, era molto condizionato.
Quale topologia logica useremo per costruire la nostra rete? Sarà un Clos multilivello. In realtà, attualmente non ci sono vere alternative. La topologia Clos è sufficientemente valida, anche se la si confronta con varie topologie avanzate che ora sono più di interesse accademico, se abbiamo switch con un grande radix.
Come funziona più o meno una rete Clos multilivello e come sono chiamati i suoi vari componenti? In primo luogo, la rosa dei venti, per orientarsi, dove è il nord, il sud, l'est e l'ovest. Le reti di questo tipo vengono solitamente costruite da chi ha un traffico molto elevato da ovest a est. Per quanto riguarda gli altri elementi, in alto è mostrato uno switch virtuale composto da switch più piccoli. Questa è l'idea principale della costruzione ricorsiva delle reti Clos. Prendiamo elementi con un certo radix e li colleghiamo in modo che ciò che risulta possa essere considerato uno switch con un radix più grande. Se necessario, si può ripetere la procedura per ottenere ancora di più.
Nei casi, ad esempio, con i Clos a due livelli, quando è possibile distinguere chiaramente i componenti che nel mio schema sono verticali, vengono comunemente chiamati piani. Se costruissimo un Clos con tre livelli di spine switch (tutti quelli che non sono boundary e non ToR switch e che vengono utilizzati solo per il transito), i piani apparirebbero più complessi, i due livelli appaiono proprio così. Il blocco di switch ToR o leaf e gli switch spine di primo livello associati ad essi lo chiamiamo Pod. Gli switch spine di livello spine-1 in cima al Pod sono il top of Pod, la cima del Pod. Gli switch che si trovano nella parte superiore dell'intera fabbrica sono lo strato superiore della fabbrica, il Top of fabric.
Certo, sorge la domanda: le reti Clos vengono costruite già da un po', l'idea stessa proviene dai tempi della telefonia classica, delle reti TDM. È possibile che sia comparso qualcosa di meglio, è possibile fare qualcosa di meglio? Sia sì che no. Teoricamente sì, nella pratica nel prossimo futuro decisamente no. Perché esistono un certo numero di topologie interessanti, alcune delle quali sono persino utilizzate in produzione, ad esempio Dragonfly è utilizzata in applicazioni HPC; ci sono anche topologie interessanti come Xpander, FatClique, Jellyfish. Se guardi le relazioni nei convegni come SIGCOMM o NSDI negli ultimi tempi, puoi trovare un numero piuttosto elevato di lavori su topologie alternative, che presentano migliori proprietà (in un modo o nell'altro) rispetto ai Clos.
Ma tutte queste topologie hanno una caratteristica interessante. Questa impedisce la loro implementazione nelle reti dei data center che stiamo cercando di costruire su hardware commerciale e che costano abbastanza ragionevolmente. In tutte queste topologie alternative, gran parte della banda, sfortunatamente, non è disponibile sui percorsi più brevi. Pertanto, perdiamo immediatamente la possibilità di utilizzare il piano di controllo tradizionale.
Teoricamente la soluzione al problema è nota. Si tratta, ad esempio, di modifiche dello stato del link con l'uso di k-shortest path, ma, ancora una volta, non ci sono protocolli del genere che siano stati implementati in produzione e siano ampiamente disponibili sull'hardware.
Inoltre, poiché gran parte della capacità non è disponibile lungo i percorsi più brevi, dobbiamo modificare non solo il control plane affinché possa selezionare tutti questi percorsi (e, a proposito, questa è una funzione significativamente più complessa nel control plane). Dobbiamo anche modificare il forwarding plane, e in generale sono necessarie almeno due funzionalità aggiuntive. Questa è la capacità di prendere tutte le decisioni di forwarding dei pacchetti in un'unica volta, ad esempio, su un host. In effetti, questo è il source routing, talvolta nella letteratura sulle reti di interconnessione si parla di all-at-once forwarding decisions. E poi l'adaptive routing: questa è già una funzionalità necessaria sui nostri elementi di rete, che implica, ad esempio, scegliere il prossimo hop sulla base delle informazioni sulla coda con minore carico. Ad esempio, ci possono essere altre opzioni.
Quindi, la direzione è interessante, ma purtroppo, al momento, non possiamo applicarla.
Ok, ci siamo fermati sulla topologia logica Clos. Come la scaleremo? Vediamo come è strutturata e cosa si può fare.
Nella rete Clos ci sono due parametri principali che possiamo variare e ottenere risultati diversi: la radix degli elementi e il numero di livelli nella rete. Ho schematicamente descritto come entrambi influenzano le dimensioni. Idealmente si devono combinare entrambi.
È evidente che la larghezza finale della rete Clos è il prodotto della quantità di spine switch del radix meridionale per il numero di link che abbiamo verso il basso, come si ramifica. Ecco come scalamo le dimensioni della rete.
Per quanto riguarda la capacità, specialmente sugli switch ToR, ci sono due opzioni di scaling. Possiamo, mantenendo l'architettura generale, utilizzare link più veloci, oppure possiamo aggiungere un maggior numero di piani.
Se guardiamo la versione espansa della rete Clos (in basso a destra) e torniamo a questa immagine della rete Clos qui sotto...
... si tratta della stessa topologia, ma in questa slide è compattata in modo più efficiente e i piani della fabbrica sono sovrapposti. È esattamente la stessa cosa.
Come appare la scalabilità della rete Clos in numeri? Qui ho riportato dati riguardo alla larghezza massima che può avere la rete, quale sia il numero massimo di rack, switch ToR o switch leaf, se non si trovano nei rack, che possiamo ottenere a seconda della radix degli switch utilizzati per i livelli spine e del numero di livelli che utilizziamo.
Qui è indicato quante unità abbiamo a disposizione, quanti server e quanto possono consumare, considerando 20 kW per unità. Ho accennato prima che puntiamo a un cluster di circa 100.000 server.
È chiaro che in tutta questa struttura ci sono due e mezzo opzioni interessanti. C'è l'opzione con due strati di spine e switch con 64 porte, che è un po' insufficiente. Poi ci sono ottime opzioni per switch spine da 128 porte (con radix 128) con due livelli, oppure switch con radix 32 con tre livelli. In tutti i casi in cui c'è un radix maggiore e più livelli, è possibile realizzare una rete molto grande, ma se si guarda al consumo previsto, di solito si parla di gigawatt. I cavi possono essere posati, ma è difficile ottenere così tanta elettricità in un'unica sede. Guardando le statistiche, ci sono pochi data center con una potenza stimata superiore a 150 MW. Quelli oltre questo limite sono generalmente campus di data center, cioè diverse grandi strutture situate abbastanza vicine l'una all'altra.
C'è anche un parametro importante. Se guardi nella colonna di sinistra, troverai l'ampiezza di banda utilizzabile. Non è difficile notare che in una rete Clos una parte significativa delle porte viene utilizzata per collegare gli switch tra di loro. La ampiezza di banda utilizzabile è ciò che possiamo destinare all'esterno, verso i server. Naturalmente, sto parlando di porte condizionali e precisamente dell'ampiezza. Di solito, i collegamenti all'interno della rete sono più veloci rispetto ai collegamenti verso i server, ma per ogni unità di ampiezza che possiamo dare all'esterno verso la nostra attrezzatura server, ci sono ancora alcune ampiezze all'interno della rete stessa. E più livelli creiamo, maggiori sono i costi relativi per fornire quell'ampiezza all'esterno.
Inoltre, anche questa ampiezza aggiuntiva non è del tutto omogenea. Fino a quando le distanze sono brevi, possiamo utilizzare qualcosa come il DAC (direct attach copper, cioè cavi twinax) o la fibra multimodale, che hanno ancora dei costi relativamente ragionevoli. Quando passiamo a distanze più lunghe, di solito si parla di fibra monomodale, e il costo di questa ampiezza aggiuntiva aumenta notevolmente.
E di nuovo, tornando alla diapositiva precedente, se costruiamo una rete Clos senza risottoscrizione, è facile guardare lo schema, vedere come viene costruita la rete — aggiungendo ogni livello di spine switch, ripetiamo l'intera banda presente in basso. Più il livello — più tutta la stessa banda, altrettanto quanto c'era nel livello precedente, porte sugli switch, altrettanti transceiver. Pertanto, è molto auspicabile minimizzare il numero di livelli di spine switch.
Da questa immagine, è chiaro che ci piacerebbe molto costruire su qualcosa come switch con un radix di 128.
Qui, in linea di principio, è tutto lo stesso di quanto ho appena detto, questa diapositiva è piuttosto per una successiva considerazione.
Quali sono le opzioni che possiamo scegliere come tali switch? Una notizia molto piacevole per noi è che ora è finalmente possibile costruire tali reti su switch a chip singolo. Ed è fantastico, hanno molte caratteristiche interessanti. Ad esempio, hanno quasi assente una struttura interna. Questo significa che si rompono più facilmente. Si rompono, come è ovvio, ma, per fortuna, si rompono completamente. Negli apparecchi modulari ci sono molteplici difetti (molto spiacevoli), quando dal punto di vista dei vicini e del control plane sembra che funzioni, ma, ad esempio, è andata persa una parte della fabbrica, e non funziona a piena capacità. E il traffico viene bilanciato in base al fatto che sia completamente funzionale, e possiamo avere sovraccarico.
Oppure, ad esempio, ci sono problemi con il backplane, perché all'interno dell'apparecchio modulare ci sono anche SerDes ad alta velocità — è davvero complesso all'interno. Oppure le tabelle tra gli elementi di forwarding vengono sincronizzate o meno. In generale, qualsiasi apparecchio modulare performante, composto da un gran numero di elementi, contiene di solito la stessa rete Clos, solo che è molto difficile da diagnosticare. Spesso anche il fornitore stesso ha difficoltà a diagnosticarla.
E ha un numero elevato di scenari di guasto, nei quali il dispositivo degrada, ma non esce completamente dalla topologia. Poiché abbiamo una rete grande, viene utilizzato attivamente il bilanciamento tra elementi identici, la rete è molto regolare, cioè un percorso in cui tutto funziona bene non si distingue da un altro percorso, ci conviene semplicemente perdere alcuni dispositivi dalla topologia piuttosto che trovarci in una situazione in cui alcuni sembrano funzionare, mentre altri no.
Un'altra caratteristica piacevole dei dispositivi a chip unico è che evolvono meglio e più velocemente. Inoltre, di solito hanno una capacità migliore. Se prendiamo grandi strutture assemblate che abbiamo, rispetto a quelle circolari, la capacità per unità rack per porte alla stessa velocità risulta quasi il doppio migliore rispetto a quella dei dispositivi modulari. I dispositivi costruiti attorno a un singolo chip risultano significativamente più economici rispetto ai modulari e consumano meno energia.
Ma, ovviamente, non è così semplice, ci sono anche svantaggi. Innanzitutto, quasi sempre un radice più piccola rispetto ai dispositivi modulari. Se possiamo ottenere un dispositivo costruito attorno a un singolo chip con 128 porte, quello modulare possiamo ottenerlo con diverse centinaia di porte senza particolari problemi.
Questo rappresenta un notevole minor numero di dimensioni delle tabelle di forwarding e, di solito, tutto ciò che riguarda la scalabilità del data plane. Buffer poco profondi. E, di regola, funzionalità piuttosto limitata. Ma si scopre che se si conoscono queste limitazioni e si provvede in tempo a o superarle o semplicemente a tenerle in considerazione, non è così spaventoso. Il fatto che la radice sia minore, sui dispositivi recentemente apparsi con radice 128 non è già un problema, possiamo costruire su due strati di spine. E al di sotto di due non si può comunque costruire nulla di interessante per noi. Con un solo livello, si ottengono cluster veramente piccoli. Anche i nostri design e requisiti precedenti comunque li superavano.
In realtà, se per caso una soluzione è al limite, c'è un altro modo per scalare. Poiché l'ultimo (o il primo), il livello più basso a cui si collegano i server — i switch ToR o i leaf switch, non siamo obbligati a collegare un solo rack. Quindi, se la soluzione è insufficiente in qualche modo del doppio, si può considerare l'idea di utilizzare semplicemente un switch con un maggior numero di porte al livello inferiore e collegare, ad esempio, due o tre rack a un unico switch. Anche questa è un'opzione, ha i suoi costi, ma funziona e potrebbe rivelarsi una buona soluzione quando è necessario raddoppiare le dimensioni.
In sintesi, ci costruiamo su una topologia a due livelli di spine, con otto strati di fabric.
Cosa succederà alla fisica? Calcoli molto semplici. Se abbiamo due livelli di spine, significa che abbiamo in totale tre livelli di switch, e ci aspettiamo che nella rete ci siano tre segmenti di cavi: dai server ai leaf switch, alla spine 1, alla spine 2. Le opzioni che possiamo utilizzare sono: twinax, multimodale, monomodale. Qui bisogna considerare quale larghezza di banda è disponibile, quanto costerà, quale sarà la dimensione fisica, quali distanze possiamo coprire e come procederemo con gli aggiornamenti.
Per quanto riguarda i costi, tutto può essere organizzato in una linea. I twinax costano sensibilmente meno dell'ottica attiva, meno dei trasmettitori multimodali, se si considera il costo per lunghezza, un po' meno di una porta switch da 100 gigabit. E attenzione, costa meno dell'ottica monomodale, perché nelle lunghezze dove è richiesta l'ottica monomodale, nei data center per vari motivi è sensato utilizzare il CWDM, e lavorare con il single mode parallelo (PSM) non è molto conveniente, si ottengono grandi fasci di fibra, e se ci si ferma su queste tecnologie, risulta circa tale gerarchia di prezzi.
Un'altra osservazione: purtroppo, non è molto utile utilizzare i porti multimodali smontati da 100 a 4x25. A causa delle peculiarità della costruzione dei trasmettitori SFP28, non costano molto meno dei QSFP28 da 100 Gbit. E questo smontaggio per il multimodale non funziona molto bene.
Un'altra limitazione è legata alla dimensione dei cluster di calcolo; a causa del numero di server, i nostri data center risultano fisicamente grandi. Ciò significa che almeno un tratto dovrà essere realizzato con il single-mode. Anche in questo caso, a causa della dimensione fisica dei Pods, non sarà possibile percorrere due tratti twinax (con cavi in rame).
Di conseguenza, ottimizzando il prezzo e considerando la geometria di questa struttura, otteniamo un tratto twinax, un tratto multimodale e un tratto single-mode utilizzando CWDM. Questo tiene conto dei potenziali percorsi di aggiornamento.
Circa così si presenta ciò che era recente, dove stiamo andando e ciò che è possibile. Chiaramente, almeno, sappiamo come muoverci verso i SerDes da 50 gigabit sia per il multimode che per il single-mode. Inoltre, se consideriamo ciò che abbiamo attualmente nei trasmettitori single-mode e in prospettiva per il 400G, spesso anche quando arrivano SerDes da 50G dal lato elettrico, il lato ottico può già trasmettere 100 Gbps per lane. Pertanto, è abbastanza probabile che invece di passare a 50 si verifichi un passaggio ai SerDes da 100 gigabit e 100 Gbps per lane, poiché molti fornitori promettono che la loro disponibilità è attesa a breve. Il periodo in cui i SerDes da 50G erano i più veloci sembra non essere molto lungo, poiché i primi esemplari dei SerDes da 100G saranno presentati quasi l'anno prossimo. E dopo un po' di tempo, forse costeranno già cifre ragionevoli.
Un'altra questione relativa alla scelta della fisica. In linea di massima, già ora possiamo applicare porte da 400 o 200 gigabit utilizzando SerDes da 50G. Ma si scopre che non ha molto senso, perché, come ho detto in precedenza, desideriamo un radix sufficientemente grande sugli switch, nei limiti del ragionevole, naturalmente. Desideriamo 128. E se la capacità del chip è limitata e aumentiamo la velocità della connessione, il radix naturalmente diminuisce, non ci sono meraviglie.
Possiamo aumentare la capacità totale grazie ai piani, e in questo caso non ci sono costi aggiuntivi, è possibile aumentare il numero di piani. E se perdiamo il radix, dovremo introdurre un ulteriore livello, quindi secondo gli attuali calcoli, con l'attuale capacità massima disponibile per un chip, risulta che è più efficiente utilizzare porte da 100 gigabit, poiché queste consentono di ottenere un radix maggiore.
La prossima domanda è come è organizzata la fisica, ma già dal punto di vista dell'infrastruttura cablata. Si scopre che è organizzata in modo piuttosto interessante. Il cablaggio tra i leaf switch e gli spine switch di primo livello - ci sono non moltissimi link, si basa tutto su una struttura relativamente semplice. Ma se prendiamo un piano, ciò che accade all'interno - bisogna collegare tutti gli spine switch di primo livello con tutti gli spine switch di secondo livello.
In aggiunta, generalmente ci sono alcune preferenze riguardo a come dovrebbe apparire all'interno del data center. Ad esempio, volevamo davvero unire i cavi in un bundle e farli scorrere in modo che un patch panel ad alta densità si collegasse completamente a un altro patch panel, per evitare un 'zoo' di lunghezze. Siamo riusciti a risolvere questo problema. Se guardiamo inizialmente alla topologia logica, è evidente che i piani sono indipendenti, ogni piano può essere costruito autonomamente. Ma quando aggiungiamo tale bundling e vogliamo portare completamente un patch panel in un patch panel, dobbiamo mescolare diverse piani all'interno di un singolo bundle e introdurre una struttura intermedia sotto forma di cross-connect ottici, per ripacchettare come erano stati assemblati su un segmento in come saranno assemblati su un altro segmento. Grazie a questo, otteniamo una piacevole caratteristica: tutta la complessa commutazione non esce dai confini dei rack. Quando è necessario intrecciare molto, 'aprire i piani', come a volte viene denominato nelle reti Clos, tutto ciò è concentrato all'interno di un singolo rack. Non ci sono commutazioni molto elaborate, anche a livello di link individuali, tra i rack.
Ecco come appare dal punto di vista dell'organizzazione logica dell'infrastruttura cablata. Nell'immagine a sinistra, i blocchi colorati rappresentano i blocchi degli spine switch di primo livello, otto in tutto, e quattro bundle di cavi che partono da essi, che si incrociano con i bundle provenienti dai blocchi degli spine switch di secondo livello.
I piccoli quadrati indicano le intersezioni. In alto a sinistra c'è una disposizione di ogni intersezione, che è in realtà un modulo di cross-connect da 512 a 512 porte, che riordina i cavi in modo da arrivare completamente in un solo armadio, dove c'è solo un piano spine-2. A destra, la disposizione di questa immagine è leggermente più dettagliata in riferimento a diversi Pods a livello spine-1, e come viene imballato nel cross-connect, come arriva al livello spine-2.
Ecco come appare. Un armadio spine-2 non completamente assemblato (a sinistra) e un armadio di cross-connect. Sfortunatamente, non si vede molto. Tutta questa struttura si sta attualmente sviluppando in uno dei nostri grandi data center, che si sta espandendo. È un lavoro in corso, apparirà più bello, sarà meglio riempito.
Una domanda importante: abbiamo scelto la topologia logica, costruito la fisica. Cosa succederà al control plane? È abbastanza conosciuto dall'esperienza operativa che ci sono un certo numero di interventi, che i protocolli link state sono buoni, sono piacevoli da usare, ma sfortunatamente, su una topologia densamente collegata, non scalano bene. E c'è un fattore principale che ostacola questo: è come funziona il flooding nei protocolli link state. Se si prende semplicemente l'algoritmo di flooding, si guarda come è strutturata la nostra rete, si vede che ad ogni passo ci sarà un grande fanout, e inonderà semplicemente il control plane con aggiornamenti. Queste specifiche topologie con l'algoritmo tradizionale di flooding nei protocolli link state si mescolano molto male.
La scelta è utilizzare BGP. Come prepararlo correttamente è descritto nell'RFC 7938 riguardante l'uso di BGP nei grandi data center. Le idee di base sono semplici: il numero minimo di prefissi per host e in generale il numero minimo di prefissi nella rete, utilizzare aggregazione se possibile e sopprimere path hunting. Vogliamo una diffusione molto controllata e molto precisa degli aggiornamenti, quella che viene definita valley free. Vogliamo che gli aggiornamenti, passando per la rete, si sviluppino esattamente una volta. Se originano in basso, vanno su, si sviluppano non più di una volta. Non ci devono essere zig-zag. Gli zig-zag sono molto dannosi.
Per farlo, utilizziamo uno schema piuttosto semplice per sfruttare i meccanismi di base di BGP. Cioè utilizziamo eBGP, funzionante a livello di collegamento, e le autonome sono assegnate come segue: un'autonoma per il ToR, un'autonoma per l'intero blocco degli switch spine-1 di un Pod, e un'autonoma comune per tutto il Top of Fabric. Non è difficile osservare e verificare che anche un comportamento BGP normale ci fornisce quella diffusione degli aggiornamenti che desideriamo.
Naturalmente, dobbiamo progettare l'indirizzamento e l'aggregazione degli indirizzi in modo che sia compatibile con il modo in cui è costruita la rete, per garantire la stabilità del control plane. L'indirizzamento L3 nel trasporto è legato alla topologia, perché senza di essa non possiamo ottenere aggregazione; senza di essa, gli indirizzi singoli passeranno nel sistema di routing. E un'altra cosa è che l'aggregazione, sfortunatamente, non si mescola molto bene con il multi-path, perché quando abbiamo multi-path e aggregazione, tutto funziona bene quando l'intera rete è operativa, senza guasti. Purtroppo, non appena si verificano guasti nella rete e la simmetria della topologia viene persa, possiamo arrivare a un punto da cui è stato annunciato l'aggregato, da cui non possiamo proseguire verso dove ci serve. Pertanto, è meglio aggregare dove non c'è più multi-path, nel nostro caso si tratta degli switch ToR.
In realtà, è possibile aggregare, ma con cautela. Se possiamo effettuare una deaggregazione controllata in caso di guasti nella rete. Ma è un compito piuttosto complesso; abbiamo anche considerato se sarebbe possibile implementare dell'automazione aggiuntiva e stati finali che possano correttamente stimolare BGP per ottenere il comportamento desiderato. Sfortunatamente, la gestione dei casi particolari è molto non ovvia e complessa, e gestire questa questione tramite attrezzature esterne collegate a BGP non risolve bene il problema.
Un lavoro molto interessante è stato fatto in questo senso nel quadro del protocollo RIFT, di cui si parlerà nella prossima relazione.
Un'altra cosa importante è come si scalano i data plane in topologie dense, dove abbiamo un gran numero di percorsi alternativi. Viene utilizzata anche qualche struttura dati aggiuntiva: gruppi ECMP, che descrivono a loro volta i gruppi Next Hop.
In una rete funzionante normalmente, senza guasti, quando procediamo verso l'alto nella topologia Clos, è sufficiente utilizzare un solo gruppo, poiché tutto ciò che non è locale è descritto dal default, si può procedere verso l'alto. Quando ci muoviamo dall'alto verso il basso a sud, tutti i percorsi non ECMP sono percorsi a singolo cammino. Va tutto bene. Il problema, e la peculiarità della topologia Clos classica, è che se guardiamo al Top of fabric, ogni elemento ha un solo percorso fino a qualsiasi elemento in basso. Se lungo questo percorso ci sono guasti, quell'elemento specifico in cima alla fabric diventa non valido per quegli specifici prefissi che si trovano lungo il percorso rotto. Per gli altri è valido, e dobbiamo analizzare i gruppi ECMP e inserire un nuovo stato.
Come appare la scalabilità del data plane nei dispositivi moderni? Se facciamo LPM (longest prefix match), tutto funziona piuttosto bene, oltre 100k prefissi. Se parliamo dei gruppi Next Hop, la situazione è peggiore, con 2-4 mila. Se consideriamo la tabella che contiene la descrizione dei Next Hops (o adiacenze), siamo tra 16k e 64k. E questo può diventare un problema. Qui ci avviciniamo a un'interessante digressione: cosa è successo all'MPLS nei data center? Fondamentalmente, volevamo implementarlo.
Sono successe due cose. Abbiamo implementato la microsegmentazione sugli host, quindi non abbiamo più bisogno di farlo sulla rete. Non abbiamo avuto un buon supporto da diversi fornitori, specialmente con implementazioni aperte su white boxes con MPLS. Inoltre, l'MPLS, almeno nelle sue implementazioni tradizionali, sfortunatamente non si sposa bene con l'ECMP. Ecco perché.
Ecco come appare la struttura del forwarding ECMP per IP. Un gran numero di prefissi può utilizzare lo stesso gruppo e lo stesso blocco di Next Hops (o adiacenze, a seconda della documentazione su diversi dispositivi può essere chiamato in modi diversi). Il senso è che viene descritto come una porta di uscita e come riscrivere l'indirizzo MAC per arrivare al corretto Next Hop. Per IP, tutto appare semplice, è possibile utilizzare un numero molto elevato di prefissi su un unico gruppo, lo stesso blocco di Next Hops.
L'architettura classica dell'MPLS presuppone che, a seconda dell'interfaccia di uscita, il label possa essere riscritto in valori diversi. Pertanto, dobbiamo mantenere un gruppo e un blocco di Next Hops per ogni etichetta di ingresso. E questo, purtroppo, non scala.
Non è difficile vedere che nella nostra architettura avevamo bisogno di circa 4000 switch ToR, con una larghezza massima di 64 percorsi ECMP, se si passa da spine-1 a spine-2. Facciamo fatica a rimanere all'interno di una tabella di gruppi ECMP, se solo un prefisso con ToR esce, e in generale non riusciamo a entrare nella tabella Next Hops.
Niente è senza speranza, perché architetture come il Segment Routing implicano etichette globali. Formalmente, si potrebbero riunire di nuovo tutti questi blocchi Next Hops. Per questo serve un'operazione tipo wild card: prendere un'etichetta e riscriverla sulla stessa senza un valore specifico. Ma purtroppo, nelle implementazioni disponibili, questo non è molto presente.
Infine, dobbiamo introdurre il traffico esterno nel data center. Come fare? In passato, il traffico veniva portato nelle reti Clos dall'alto. C'erano router di confine che si collegavano a tutti i dispositivi in cima alla rete. Questa soluzione funziona abbastanza bene su piccole e medie dimensioni. Purtroppo, per introdurre il traffico in modo simmetrico nella rete, è necessario intervenire simultaneamente su tutti gli elementi in cima alla rete, e quando questi superano un centinaio, si scopre che abbiamo bisogno di un grande radix anche sui router di confine. In generale, questo comporta costi, perché i router di confine sono più funzionali, le porte sono più costose e il risultato non è molto estetico.
Un'altra opzione è portare questo traffico dal basso. Non è difficile capire che la topologia Clos è costruita in modo da distribuire uniformemente il traffico in arrivo dal basso, cioè dal lato ToR, su tutti i livelli dell'intera rete in due iterazioni, caricando l'intera rete. Pertanto, introduciamo un tipo speciale di Pod, Edge Pod, che garantisce la connettività esterna.
C'è un'altra opzione. Ad esempio, Facebook lo fa. Lo chiamano Fabric Aggregator o HGRID. Viene aggiunto un ulteriore livello di spine per connettere più data center. Questa configurazione è possibile se non abbiamo funzioni aggiuntive o cambiamenti di incapsulamento ai confini. Se ci sono, questi sono punti di contatto aggiuntivi, ed è complesso. Di solito, appaiono più funzioni e una sorta di membrana che separa le diverse parti del data center. Non è consigliabile rendere grande tale membrana, e se è davvero necessaria, ha senso considerare di spostarla, renderla il più ampia possibile e trasferirla sugli host. Questo è il modo in cui molti operatori cloud procedono. Loro hanno overlays, che iniziano dagli host.
Quali opportunità di sviluppo vediamo? In primo luogo, il miglioramento del supporto per il pipeline CI/CD. Vogliamo viaggiare come testiamo e testare come viaggiamo. Questo non sta funzionando molto bene, poiché l'infrastruttura è grande e non è possibile duplicarla per i test. È necessario comprendere come introdurre elementi di testing nell'infrastruttura operativa senza comprometterla.
Un miglior strumentazione e un miglior monitoraggio non sono mai superflui. L'intera questione è un equilibrio tra sforzi e risultati. Se è possibile aggiungere in modo ragionevole, è molto bene.
Sistemi operativi aperti per dispositivi di rete. I migliori protocolli e i migliori sistemi di instradamento, come RIFT. Sono necessarie anche ricerche sull'applicazione dei migliori schemi di controllo della congestione e, possibilmente, l'introduzione, almeno in alcuni punti, del supporto RDMA nei limiti del cluster.
Se guardiamo al futuro, sono necessarie topologie avanzate e forse reti che utilizzano un overhead minore. Tra le novità, ci sono state recentemente pubblicazioni sulla tecnologia delle fabbriche per HPC Cray Slingshot, basata su Ethernet commerciale, ma con l'opzione di utilizzare intestazioni molto più corte. Di conseguenza, l'overhead si riduce.
Tutto dovrebbe essere fatto il più semplice possibile, ma non più semplice. La complessità è nemica della scalabilità. La semplicità e le strutture regolari sono nostri amici. Se è possibile fare scale out da qualche parte, fatelo. E in generale, è un buon momento per lavorare sulle tecnologie di rete. Sta succedendo molto di interessante. Grazie.
Fonte: habr.com
