Abbiamo sviluppato un progetto di rete di data center che consente l'implementazione di cluster di elaborazione più grandi di 100mila server con una larghezza di banda di bisezione di picco di oltre un petabyte al secondo.
Dal rapporto di Dmitry Afanasyev imparerai i principi di base del nuovo design, il ridimensionamento delle topologie, i problemi che ne derivano, le opzioni per risolverli, le caratteristiche di instradamento e ridimensionamento delle funzioni del piano di inoltro dei moderni dispositivi di rete in "densamente connessi" topologie con un gran numero di percorsi ECMP. Inoltre, Dima ha parlato brevemente dell'organizzazione della connettività esterna, del livello fisico, del sistema di cablaggio e dei modi per aumentare ulteriormente la capacità.
- Buon pomeriggio a tutti! Mi chiamo Dmitry Afanasyev, sono un architetto di rete presso Yandex e progetto principalmente reti di data center.
La mia storia riguarderà la rete aggiornata dei data center Yandex. Si tratta di un'evoluzione del design che avevamo, ma allo stesso tempo ci sono alcuni nuovi elementi. Questa è una presentazione panoramica perché c'erano molte informazioni da raccogliere in un breve lasso di tempo. Inizieremo scegliendo una topologia logica. Poi ci sarà una panoramica del piano di controllo e dei problemi con la scalabilità del piano dati, una scelta di cosa accadrà a livello fisico e vedremo alcune caratteristiche dei dispositivi. Tocchiamo brevemente cosa succede in un data center con MPLS, di cui abbiamo parlato qualche tempo fa.
Allora, cos'è Yandex in termini di carichi e servizi? Yandex è un tipico hyperscaler. Se guardiamo agli utenti, elaboriamo principalmente le richieste degli utenti. Anche vari servizi di streaming e trasferimento dati, perché disponiamo anche di servizi di archiviazione. Se più vicino al back-end, lì compaiono i carichi e i servizi dell'infrastruttura, come l'archiviazione di oggetti distribuiti, la replica dei dati e, ovviamente, le code persistenti. Uno dei principali tipi di carichi di lavoro è MapReduce e sistemi simili, elaborazione di flussi, apprendimento automatico, ecc.
Come sono le infrastrutture su cui avviene tutto questo? Ancora una volta, siamo un hyperscaler piuttosto tipico, anche se forse siamo un po' più vicini al lato hyperscaler minore dello spettro. Ma abbiamo tutte le caratteristiche. Utilizziamo hardware di base e scalabilità orizzontale ove possibile. Disponiamo di un pooling completo delle risorse: non lavoriamo con singole macchine, singoli rack, ma li combiniamo in un ampio pool di risorse intercambiabili con alcuni servizi aggiuntivi che si occupano di pianificazione e allocazione e lavoriamo con l'intero pool.
Quindi abbiamo il livello successivo: il sistema operativo a livello del cluster informatico. È molto importante controllare completamente lo stack tecnologico che utilizziamo. Controlliamo gli endpoint (host), la rete e lo stack software.
Abbiamo diversi grandi data center in Russia e all'estero. Sono uniti da una dorsale che utilizza la tecnologia MPLS. La nostra infrastruttura interna è quasi interamente costruita su IPv6, ma poiché dobbiamo servire il traffico esterno che arriva ancora principalmente su IPv4, dobbiamo in qualche modo consegnare le richieste che arrivano su IPv4 ai server frontend e un po' di più andare all'IPv4 esterno - Internet - per ad esempio, per l'indicizzazione.
Le ultime iterazioni dei progetti di rete dei data center hanno utilizzato topologie Clos multistrato e sono solo L3. Abbiamo lasciato L2 qualche tempo fa e abbiamo tirato un sospiro di sollievo. Infine, la nostra infrastruttura include centinaia di migliaia di istanze di elaborazione (server). La dimensione massima del cluster qualche tempo fa era di circa 10mila server. Ciò è in gran parte dovuto al modo in cui possono funzionare gli stessi sistemi operativi, pianificatori, allocazione delle risorse, ecc. Abbiamo un compito: essere in grado di costruire fabbriche di rete che consentano un efficiente raggruppamento delle risorse in un tale cluster.
Cosa vogliamo da una rete di data center? Prima di tutto, c'è molta larghezza di banda economica e distribuita in modo abbastanza uniforme. Perché la rete è la spina dorsale attraverso la quale possiamo mettere in comune le risorse. La nuova dimensione target è di circa 100mila server in un cluster.
Ovviamente vogliamo anche un piano di controllo scalabile e stabile, perché su un'infrastruttura così grande nascono molti grattacapi anche da eventi semplicemente casuali, e non vogliamo che anche il piano di controllo ci porti grattacapi. Allo stesso tempo, vogliamo ridurre al minimo lo stato in esso contenuto. Più piccola è la condizione, migliore e più stabile è il funzionamento e più facile è la diagnosi.
Naturalmente abbiamo bisogno dell’automazione, perché gestire manualmente una simile infrastruttura è impossibile, ed è impossibile da tempo. Abbiamo bisogno di sostegno operativo quanto più possibile e di sostegno CI/CD nella misura in cui può essere fornito.
Con data center e cluster di tali dimensioni, il compito di supportare la distribuzione e l'espansione incrementale senza interruzione del servizio è diventato piuttosto impegnativo. Se su cluster di un migliaio di macchine, forse vicino a diecimila macchine, potessero ancora essere implementati come un'unica operazione - cioè stiamo pianificando un'espansione dell'infrastruttura e diverse migliaia di macchine verranno aggiunte come un'unica operazione, quindi un cluster delle dimensioni di centomila macchine non nasce immediatamente in questo modo, ma viene costruito in un periodo di tempo. Ed è auspicabile che per tutto questo tempo ciò che è già stato pompato, l'infrastruttura che è stata implementata, sia disponibile.
E un requisito che avevamo e abbiamo lasciato: il supporto per la multitenancy, ovvero la virtualizzazione o la segmentazione della rete. Ora non abbiamo più bisogno di farlo a livello di struttura della rete, perché lo sharding è andato agli host e questo ha reso la scalabilità molto semplice per noi. Grazie a IPv6 e ad un ampio spazio di indirizzi non abbiamo avuto bisogno di utilizzare indirizzi duplicati nell'infrastruttura interna; tutti gli indirizzi erano già univoci. E grazie al fatto che abbiamo applicato il filtraggio e la segmentazione della rete agli host, non abbiamo bisogno di creare entità di rete virtuale nelle reti dei data center.
Una cosa molto importante è ciò di cui non abbiamo bisogno. Se alcune funzioni possono essere rimosse dalla rete, ciò semplifica notevolmente la vita e, di norma, amplia la scelta delle apparecchiature e del software disponibili, rendendo la diagnostica molto semplice.
Allora, di cosa non abbiamo bisogno, a cosa abbiamo potuto rinunciare, non sempre con gioia nel momento in cui è accaduto, ma con grande sollievo una volta completato il processo?
Innanzitutto abbandonare L2. Non abbiamo bisogno della L2, né reale né emulata. Inutilizzato in gran parte perché controlliamo lo stack dell'applicazione. Le nostre applicazioni sono scalabili orizzontalmente, funzionano con l'indirizzamento L3, non sono molto preoccupati che qualche singola istanza sia uscita, semplicemente ne lanciano una nuova, non è necessario lanciarla al vecchio indirizzo, perché c'è un livello separato di rilevamento e monitoraggio del servizio delle macchine situate nel cluster. Non deleghiamo questo compito alla rete. Il compito della rete è consegnare i pacchetti dal punto A al punto B.
Inoltre non abbiamo situazioni in cui gli indirizzi si spostano all'interno della rete e questo deve essere monitorato. In molti progetti ciò è in genere 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 ciò venisse fatto, non dovrebbe avvenire con il supporto di rete. Se è davvero necessario farlo, deve essere fatto a livello di host e spingere gli indirizzi che possono migrare negli overlay, in modo da non toccare o apportare troppe modifiche dinamiche al sistema di routing dell'underlay stesso (rete di trasporto) .
Un'altra tecnologia che non utilizziamo è il multicast. Se vuoi posso spiegarti dettagliatamente il motivo. Questo rende la vita molto più semplice, perché se qualcuno se ne è occupato e ha guardato esattamente come appare il piano di controllo multicast, in tutte le installazioni tranne le più semplici, questo è un grosso grattacapo. Inoltre, ad esempio, è difficile trovare un'implementazione open source ben funzionante.
Infine, progettiamo le nostre reti in modo che non cambino troppo. Possiamo contare sul fatto che il flusso di eventi esterni nel sistema di routing è ridotto.
Quali problemi sorgono e quali restrizioni devono essere prese in considerazione quando sviluppiamo una rete di data center? Costo, ovviamente. Scalabilità, il livello a cui vogliamo crescere. La necessità di espandersi senza interrompere il servizio. Larghezza di banda, disponibilità. Visibilità di ciò che accade in rete per i sistemi di monitoraggio, per i team operativi. Supporto all'automazione: ancora una volta, per quanto possibile, poiché compiti diversi possono essere risolti a livelli diversi, inclusa l'introduzione di livelli aggiuntivi. Beh, non [forse] dipendente dai fornitori. Anche se in periodi storici diversi, a seconda della sezione in cui si guarda, questa indipendenza è stata più o meno facile da raggiungere. Se prendiamo uno spaccato dei chip dei dispositivi di rete, fino a poco tempo fa era molto condizionale parlare di indipendenza dai fornitori, se volevamo anche chip con un throughput elevato.
Quale topologia logica utilizzeremo per costruire la nostra rete? Questo sarà un Clos multi-livello. In realtà al momento non ci sono vere alternative. E la topologia Clos è abbastanza buona, anche se confrontata con varie topologie avanzate che ora sono più nell'area di interesse accademico, se disponiamo di grandi switch radix.
Come è strutturata approssimativamente una rete Clos multilivello e come vengono chiamati i diversi elementi al suo interno? Innanzitutto si alza il vento, per orientarsi dov'è il nord, dov'è il sud, dov'è l'est, dov'è l'ovest. Reti di questo tipo vengono solitamente realizzate da chi ha un traffico ovest-est molto ampio. Per quanto riguarda gli elementi rimanenti, in alto c'è un interruttore virtuale assemblato da interruttori più piccoli. Questa è l'idea principale della costruzione ricorsiva delle reti Clos. Prendiamo elementi con una sorta di radice e li colleghiamo in modo che ciò che otteniamo possa essere considerato come un interruttore con una radice più grande. Se ne hai bisogno ancora di più, la procedura può essere ripetuta.
Nei casi, ad esempio, con Clos a due livelli, quando è possibile identificare chiaramente i componenti che sono verticali nel mio diagramma, di solito vengono chiamati piani. Se dovessimo costruire un Clos con tre livelli di interruttori dorsale (che non sono interruttori di confine o ToR e che sono usati solo per il transito), allora gli aerei sembrerebbero più complessi; quelli a due livelli apparirebbero esattamente così. Chiamiamo Pod un blocco di ToR o interruttori a foglia e gli interruttori dorsale di primo livello ad essi associati. Gli interruttori della colonna vertebrale del livello della colonna vertebrale 1 nella parte superiore del Pod sono la parte superiore del Pod, la parte superiore del Pod. Gli interruttori che si trovano nella parte superiore dell'intera fabbrica sono lo strato superiore della fabbrica, la parte superiore del tessuto.
Naturalmente sorge la domanda: le reti Clos sono state costruite già da tempo, l'idea stessa risale generalmente ai tempi della telefonia classica, delle reti TDM. Forse è apparso qualcosa di meglio, forse si può fare qualcosa di meglio? Sì e no. Teoricamente sì, in pratica nel prossimo futuro sicuramente no. Poiché esistono numerose topologie interessanti, alcune di esse vengono utilizzate anche in produzione, ad esempio Dragonfly viene utilizzato nelle applicazioni HPC; Esistono anche topologie interessanti come Xpander, FatClique, Jellyfish. Se guardi i resoconti di conferenze come SIGCOMM o NSDI di recente, puoi trovare un numero abbastanza elevato di lavori su topologie alternative che hanno proprietà migliori (una o l'altra) rispetto a Clos.
Ma tutte queste topologie hanno una proprietà interessante. Ne impedisce l'implementazione nelle reti di data center, che stiamo cercando di costruire su hardware di base e che costano denaro abbastanza ragionevole. In tutte queste topologie alternative, la maggior parte della larghezza di banda purtroppo non è accessibile tramite i percorsi più brevi. Pertanto, perdiamo immediatamente l'opportunità di utilizzare il piano di controllo tradizionale.
Teoricamente la soluzione al problema è nota. Si tratta, ad esempio, di modifiche dello stato del collegamento utilizzando il percorso più breve k, ma, ancora una volta, non esistono protocolli di questo tipo che potrebbero essere implementati in produzione e ampiamente disponibili sulle apparecchiature.
Inoltre, poiché la maggior parte della capacità non è accessibile tramite i percorsi più brevi, dobbiamo modificare qualcosa di più del semplice piano di controllo per selezionare tutti questi percorsi (e tra l'altro, questo è uno stato significativamente maggiore nel piano di controllo). Dobbiamo ancora modificare il piano di inoltro e, di norma, sono necessarie almeno due funzionalità aggiuntive. Questa è la capacità di prendere tutte le decisioni sull'inoltro dei pacchetti una volta, ad esempio, sull'host. In realtà, questo è il source routing, a volte nella letteratura sulle reti di interconnessione questo viene chiamato decisioni di inoltro all-at-once. E il routing adattivo è una funzione di cui abbiamo bisogno sugli elementi della rete, che si riduce, ad esempio, al fatto che selezioniamo l'hop successivo in base alle informazioni sul carico minimo sulla coda. Ad esempio, sono possibili altre opzioni.
Pertanto, la direzione è interessante, ma, ahimè, non possiamo applicarla adesso.
Ok, abbiamo optato per la topologia logica Clos. Come lo ridimensioneremo? Vediamo come funziona e cosa si può fare.
In una rete Clos ci sono due parametri principali che possiamo in qualche modo variare e ottenere determinati risultati: la radice degli elementi e il numero di livelli nella rete. Ho un diagramma schematico di come entrambi influiscono sulle dimensioni. Idealmente, combiniamo entrambi.
Si può vedere che la larghezza finale della rete Clos è il prodotto di tutti i livelli degli interruttori della spina dorsale della radice meridionale, di quanti collegamenti abbiamo in basso, di come si ramifica. In questo modo aumentiamo le dimensioni della rete.
Per quanto riguarda la capacità, soprattutto sugli switch ToR, sono disponibili due opzioni di ridimensionamento. O possiamo, pur mantenendo la topologia generale, utilizzare collegamenti più veloci, oppure possiamo aggiungere più piani.
Se guardi la versione estesa della rete Clos (nell'angolo in basso a destra) e ritorni a questa immagine con la rete Clos qui sotto...
... allora questa è esattamente la stessa topologia, ma su questa diapositiva è collassata in modo più compatto e i piani della fabbrica sono sovrapposti l'uno all'altro. È lo stesso.
Che cosa significa in numeri il ridimensionamento di una rete Clos? Qui fornisco i dati su quale larghezza massima può essere ottenuta una rete, quale numero massimo di rack, switch ToR o switch a foglia, se non sono in rack, possiamo ottenere a seconda della radice degli switch che utilizziamo per i livelli della colonna vertebrale e quanti livelli utilizziamo.
Ecco quanti rack possiamo avere, quanti server e approssimativamente quanto tutto ciò può consumare sulla base di 20 kW per rack. Poco prima ho accennato al fatto che puntiamo a una dimensione del cluster di circa 100mila server.
Si può vedere che in tutto questo progetto sono interessanti due opzioni e mezza. C'è un'opzione con due strati di spine e switch a 64 porte, che non è all'altezza. Poi ci sono opzioni perfettamente adatte per switch spine a 128 porte (con Radix 128) a due livelli o switch con Radix 32 a tre livelli. E in tutti i casi, dove ci sono più radici e più strati, puoi realizzare una rete molto grande, ma se guardi il consumo previsto, in genere ci sono i gigawatt. È possibile stendere un cavo, ma è improbabile che riusciremo a ottenere così tanta elettricità in un unico sito. Se si esaminano le statistiche e i dati pubblici sui data center, è possibile trovare pochissimi data center con una capacità stimata superiore a 150 MW. Quelli più grandi sono solitamente campus di data center, diversi data center di grandi dimensioni situati abbastanza vicini l'uno all'altro.
C'è un altro parametro importante. Se guardi la colonna di sinistra, lì è elencata la larghezza di banda utilizzabile. È facile vedere che in una rete Clos una parte significativa delle porte viene utilizzata per connettere gli switch tra loro. La larghezza di banda utilizzabile, una striscia utile, è qualcosa che si può dare all'esterno, verso i server. Naturalmente sto parlando di port condizionali e nello specifico della banda. Di norma, i collegamenti all'interno della rete sono più veloci dei collegamenti verso i server, ma per unità di larghezza di banda, per quanto possiamo inviarla alle nostre apparecchiature server, rimane ancora una certa larghezza di banda all'interno della rete stessa. E più livelli creiamo, maggiore sarà il costo specifico per fornire questa striscia all'esterno.
Del resto anche questa banda aggiuntiva non è esattamente la stessa. Sebbene le campate siano brevi, possiamo usare qualcosa come DAC (cavi in rame ad attacco diretto, ovvero cavi twinax) o ottiche multimodali, che costano denaro ancora più o meno ragionevole. Non appena passiamo a campate più lunghe, di norma si tratta di ottiche monomodali e il costo di questa larghezza di banda aggiuntiva aumenta notevolmente.
E ancora, tornando alla diapositiva precedente, se creiamo una rete Clos senza abbonamento eccessivo, allora è facile guardare il diagramma, vedere come è costruita la rete: aggiungendo ogni livello di interruttori della colonna vertebrale, ripetiamo l'intera striscia che era al metter il fondo a. Livello Plus: più la stessa banda, lo stesso numero di porte sugli switch del livello precedente e lo stesso numero di ricetrasmettitori. Pertanto, è molto desiderabile ridurre al minimo il numero di livelli di interruttori della colonna vertebrale.
Sulla base di questa immagine, è chiaro che vogliamo davvero costruire su qualcosa come gli interruttori con una radice di 128.
Qui, in linea di principio, tutto è uguale a quello che ho appena detto, questa è una diapositiva da considerare più avanti.
Quali opzioni ci sono che possiamo scegliere come tali interruttori? È per noi una notizia molto piacevole che ora tali reti possano finalmente essere costruite su switch a chip singolo. E questo è molto interessante, hanno molte caratteristiche interessanti. Ad esempio, non hanno quasi nessuna struttura interna. Ciò significa che si rompono più facilmente. Si rompono in tutti i modi, ma fortunatamente si rompono completamente. Nei dispositivi modulari ci sono molti difetti (molto spiacevoli), quando dal punto di vista dei vicini e del piano di controllo sembra funzionare, ma, ad esempio, parte del tessuto è andata persa e non funziona a piena capacità. E il traffico verso di esso è bilanciato in base al fatto che è perfettamente funzionante e possiamo sovraccaricarci.
Oppure, ad esempio, sorgono problemi con il backplane, perché all'interno del dispositivo modulare ci sono anche SerDes ad alta velocità: all'interno è davvero complesso. I segni tra gli elementi di inoltro sono sincronizzati o non sincronizzati. In generale, qualsiasi dispositivo modulare produttivo costituito da un gran numero di elementi, di regola, contiene al suo interno la stessa rete Clos, ma è molto difficile da diagnosticare. Spesso è difficile fare una diagnosi anche per il venditore stesso.
Inoltre presenta un gran numero di scenari di guasto in cui il dispositivo si degrada, ma non esce completamente dalla topologia. Poiché la nostra rete è grande, viene utilizzato attivamente il bilanciamento tra elementi identici, la rete è molto regolare, cioè un percorso su cui tutto è in ordine non è diverso dall'altro percorso, è più redditizio per noi semplicemente perdere parte di i dispositivi dalla topologia piuttosto che finire in una situazione in cui alcuni di essi sembrano funzionare, ma altri no.
Un'altra caratteristica interessante dei dispositivi a chip singolo è che si evolvono meglio e più velocemente. Tendono anche ad avere una capacità migliore. Se prendiamo le grandi strutture assemblate che abbiamo in cerchio, la capacità per unità rack per porte della stessa velocità è quasi il doppio di quella dei dispositivi modulari. I dispositivi costruiti attorno a un singolo chip sono notevolmente più economici di quelli modulari e consumano meno energia.
Ma, ovviamente, tutto questo per una ragione, ci sono anche degli svantaggi. Innanzitutto la radice è quasi sempre più piccola di quella dei dispositivi modulari. Se riusciamo a ottenere un dispositivo costruito attorno a un chip con 128 porte, allora possiamo ottenerne uno modulare con diverse centinaia di porte senza problemi.
Si tratta di una dimensione notevolmente inferiore delle tabelle di inoltro e, di norma, di tutto ciò che riguarda la scalabilità del piano dati. Buffer poco profondi. E, di regola, funzionalità piuttosto limitata. Ma si scopre che se conosci queste restrizioni e ti prendi cura di aggirarle in tempo o semplicemente di tenerne conto, allora non è così spaventoso. Il fatto che la radice sia più piccola non è più un problema sui dispositivi con radice 128 apparsi finalmente di recente; possiamo costruire due strati di spine. Ma è ancora impossibile costruire qualcosa di più piccolo di due che sia interessante per noi. Con un livello si ottengono cluster molto piccoli. Anche i nostri progetti e requisiti precedenti li superavano.
In effetti, se all’improvviso la soluzione si trova a un passo dall’orlo, c’è ancora un modo per espandersi. Poiché l'ultimo (o il primo) livello più basso a cui sono collegati i server sono gli switch ToR o gli switch a foglia, non è necessario collegare loro un rack. Pertanto, se la soluzione è inferiore di circa la metà, si può pensare semplicemente di utilizzare uno switch con un grande radice al livello inferiore e collegare, ad esempio, due o tre rack in uno switch. Anche questa è un'opzione, ha i suoi costi, ma funziona abbastanza bene e può essere una buona soluzione quando è necessario raggiungere circa il doppio della dimensione.
Per riassumere, stiamo costruendo su una topologia con due livelli di spine, con otto strati di fabbrica.
Cosa accadrà alla fisica? Calcoli molto semplici. Se abbiamo due livelli di spine, allora abbiamo solo tre livelli di switch e ci aspettiamo che ci siano tre segmenti di cavo nella rete: dai server agli switch foglia, alla spina 1, alla spina 2. Le opzioni che possiamo gli usi sono: twinax, multimodale, monomodale. E qui dobbiamo considerare quale nastro è disponibile, quanto costerà, quali sono le dimensioni fisiche, quali campate possiamo coprire e come lo aggiorneremo.
In termini di costi, tutto può essere messo in fila. I twinax sono significativamente più economici dell'ottica attiva, più economici dei ricetrasmettitori multimodali, se lo prendi per volo dalla fine, un po' più economico di una porta switch da 100 gigabit. E, tieni presente, costa meno dell'ottica monomodale, perché sui voli in cui è richiesta la modalità singola, nei data center per una serie di motivi ha senso utilizzare CWDM, mentre la modalità singola parallela (PSM) non è molto comoda da lavorare con le fibre si ottengono pacchi molto grandi e, se ci concentriamo su queste tecnologie, otteniamo approssimativamente la seguente gerarchia di prezzi.
Ancora una nota: sfortunatamente, non è molto possibile utilizzare porte multimodali da 100 a 4x25 smontate. A causa delle caratteristiche di progettazione dei ricetrasmettitori SFP28, non è molto più economico di QSFP28 da 100 Gbit. E questo smontaggio per multimodale non funziona molto bene.
Un’altra limitazione è che, a causa delle dimensioni dei cluster informatici e del numero di server, i nostri data center risultano fisicamente grandi. Ciò significa che almeno un volo dovrà essere effettuato con un singlemod. Anche in questo caso, a causa delle dimensioni fisiche dei Pod, non sarà possibile far passare due campate di twinax (cavi in rame).
Di conseguenza, se ottimizziamo il prezzo e teniamo conto della geometria di questo progetto, otteniamo una campata di twinax, una campata di multimodale e una campata di monomodale utilizzando CWDM. Ciò tiene conto dei possibili percorsi di aggiornamento.
Ecco come appare di recente, dove stiamo andando e cosa è possibile fare. È chiaro, almeno, come procedere verso SerDes da 50 Gigabit sia per il multimodale che per il monomodale. Inoltre, se si guarda cosa c'è nei ricetrasmettitori monomodali ora e in futuro per 400G, spesso anche quando SerDes 50G arrivano dal lato elettrico, 100 Gbps per corsia possono già andare all'ottica. È quindi del tutto possibile che invece del passaggio a 50 si passi a SerDes da 100 Gigabit e 100 Gbps per corsia, perché secondo le promesse di molti fornitori, la loro disponibilità è prevista molto presto. Il periodo in cui i SerDes da 50G erano i più veloci, a quanto pare, non sarà molto lungo, perché le prime copie dei SerDes da 100G verranno lanciate quasi l'anno prossimo. E dopo qualche tempo probabilmente varranno una cifra ragionevole.
Un'altra sfumatura sulla scelta della fisica. In linea di principio possiamo già utilizzare porte da 400 o 200 Gigabit utilizzando SerDes 50G. Ma si scopre che questo non ha molto senso, perché, come ho detto prima, vogliamo una radice abbastanza grande sugli interruttori, entro limiti ragionevoli, ovviamente. Ne vogliamo 128. E se abbiamo una capacità limitata del chip e aumentiamo la velocità del collegamento, allora la radice diminuisce naturalmente, non ci sono miracoli.
E possiamo aumentare la capacità totale utilizzando gli aerei, e non ci sono costi speciali; possiamo aggiungere il numero di aerei. E se perdiamo la radice, dovremo introdurre un livello aggiuntivo, quindi nella situazione attuale, con l'attuale capacità massima disponibile per chip, risulta che è più efficiente utilizzare porte da 100 gigabit, perché ti consentono per ottenere una radice più grande.
La domanda successiva è come è organizzata la fisica, ma dal punto di vista dell’infrastruttura via cavo. Si scopre che è organizzato in un modo piuttosto divertente. Cablaggio tra gli interruttori a foglia e le spine del primo livello: non ci sono molti collegamenti lì, tutto è costruito in modo relativamente semplice. Ma se prendiamo un piano, quello che succede all'interno è che dobbiamo collegare tutte le spine del primo livello con tutte le spine del secondo livello.
Inoltre, di regola, ci sono alcuni desideri su come dovrebbe apparire all'interno del data center. Ad esempio, volevamo davvero unire i cavi in un fascio e tirarli in modo che un pannello di connessione ad alta densità entrasse interamente in un pannello di connessione, in modo che non ci fosse uno zoo in termini di lunghezze. Siamo riusciti a risolvere questo problema. Se inizialmente guardi la topologia logica, puoi vedere che i piani sono indipendenti, ogni piano può essere costruito da solo. Ma quando aggiungiamo un tale raggruppamento e vogliamo trascinare l'intero patch panel in un patch panel, dobbiamo mescolare diversi piani all'interno di un bundle e introdurre una struttura intermedia sotto forma di connessioni incrociate ottiche per riconfezionarli da come sono stati assemblati su un segmento, nel modo in cui verranno raccolti su un altro segmento. Grazie a ciò, otteniamo una caratteristica interessante: tutta la commutazione complessa non va oltre i rack. Quando è necessario intrecciare qualcosa in modo molto forte, "aprire gli aerei", come a volte viene chiamato nelle reti Clos, tutto è concentrato all'interno di un rack. Non abbiamo altamente smontato, fino ai singoli collegamenti, passando da un rack all'altro.
Ecco come appare dal punto di vista dell'organizzazione logica dell'infrastruttura via cavo. Nella foto a sinistra, i blocchi multicolori raffigurano blocchi di interruttori spine di primo livello, otto pezzi ciascuno, e quattro fasci di cavi provenienti da essi, che vanno ad incrociarsi con i fasci provenienti dai blocchi di interruttori spine-2 .
I piccoli quadrati indicano le intersezioni. In alto a sinistra c'è una ripartizione di ciascuna di queste intersezioni, si tratta in realtà di un modulo di connessione incrociata da 512 x 512 porte che reimballa i cavi in modo che arrivino completamente in un rack, dove c'è solo un piano spine-2. E a destra, una scansione di questa immagine è un po' più dettagliata in relazione a diversi Pod al livello spina 1 e a come è confezionato in una connessione incrociata, come arriva al livello spina 2.
Questo è quello che sembra. Il supporto spine-2 non ancora completamente assemblato (a sinistra) e il supporto cross-connect. Sfortunatamente, non c'è molto da vedere lì. L'intera struttura viene implementata proprio ora in uno dei nostri grandi data center che è in fase di espansione. Questo è un lavoro in corso, sembrerà più bello, sarà compilato meglio.
Una domanda importante: abbiamo scelto la topologia logica e costruito la fisica. Cosa accadrà al piano di controllo? È abbastanza noto dall'esperienza operativa, ci sono numerosi rapporti secondo cui i protocolli dello stato dei collegamenti sono buoni, è un piacere lavorare con loro, ma, sfortunatamente, non si adattano bene a una topologia densamente connessa. E c'è un fattore principale che lo impedisce: ecco come funziona il Flooding nei protocolli dello stato dei collegamenti. Se prendi semplicemente l'algoritmo di allagamento e guardi come è strutturata la nostra rete, puoi vedere che ci sarà un fanout molto ampio ad ogni passaggio e semplicemente inonderà il piano di controllo di aggiornamenti. Nello specifico, tali topologie si integrano molto male con il tradizionale algoritmo di Flooding nei protocolli dello stato dei collegamenti.
La scelta è utilizzare BGP. Come prepararlo correttamente è descritto nella RFC 7938 sull'uso di BGP nei grandi data center. Le idee di base sono semplici: numero minimo di prefissi per host e generalmente numero minimo di prefissi sulla rete, utilizzare l'aggregazione se possibile ed eliminare la ricerca del percorso. Vogliamo una distribuzione degli aggiornamenti molto attenta e molto controllata, quella che viene chiamata Valley Free. Vogliamo che gli aggiornamenti vengano distribuiti esattamente una volta mentre attraversano la rete. Se hanno origine dal basso, salgono svolgendosi non più di una volta. Non dovrebbero esserci zigzag. Gli zigzag sono pessimi.
Per fare ciò, utilizziamo un design sufficientemente semplice da utilizzare i meccanismi BGP sottostanti. Cioè, utilizziamo eBGP in esecuzione su link local e i sistemi autonomi vengono assegnati come segue: un sistema autonomo su ToR, un sistema autonomo sull'intero blocco di switch spine-1 di un Pod e un sistema autonomo generale sull'intero Top di Tessuto. Non è difficile osservare e vedere che anche il normale comportamento di BGP ci fornisce la distribuzione degli aggiornamenti che desideriamo.
Naturalmente, l'indirizzamento e l'aggregazione degli indirizzi devono essere progettati in modo che siano compatibili con il modo in cui è costruito il routing, in modo da garantire la stabilità del piano di controllo. L'indirizzamento L3 nei trasporti è legato alla topologia, perché senza di essa non è possibile ottenere l'aggregazione; senza di essa i singoli indirizzi si insinuano nel sistema di routing. E un'altra cosa è che l'aggregazione, sfortunatamente, non si mescola molto bene con il percorso multiplo, perché quando abbiamo il percorso multiplo e abbiamo l'aggregazione, tutto va bene, quando l'intera rete è sana, non ci sono guasti. Sfortunatamente, non appena si verificano guasti nella rete e si perde la simmetria della topologia, possiamo arrivare al punto da cui è stata annunciata l'unità, dal quale non possiamo andare oltre dove dobbiamo andare. Pertanto, è meglio aggregare dove non sono presenti ulteriori percorsi multipli, nel nostro caso si tratta di switch ToR.
In effetti è possibile aggregare, ma con attenzione. Se possiamo eseguire una disaggregazione controllata quando si verificano guasti di rete. Ma questo è un compito piuttosto difficile, ci siamo anche chiesti se sarebbe stato possibile farlo, se fosse possibile aggiungere ulteriore automazione e macchine a stati finiti che avrebbero kickato correttamente BGP per ottenere il comportamento desiderato. Sfortunatamente, l'elaborazione dei casi limite è molto complessa e non ovvia e questo compito non è ben risolto collegando allegati esterni a BGP.
Un lavoro molto interessante in questo senso è stato svolto nel quadro del protocollo RIFT, di cui si parlerà nel prossimo rapporto.
Un'altra cosa importante è il modo in cui i piani dati si adattano alle topologie dense, dove abbiamo un gran numero di percorsi alternativi. In questo caso vengono utilizzate diverse strutture dati aggiuntive: i gruppi ECMP, che a loro volta descrivono i gruppi Next Hop.
In una rete normalmente funzionante, senza guasti, quando saliamo nella topologia Clos, è sufficiente utilizzare un solo gruppo, perché tutto ciò che non è locale è descritto per impostazione predefinita, possiamo salire. Quando andiamo dall'alto verso il basso verso sud, tutti i percorsi non sono ECMP, sono percorsi a percorso unico. Va tutto bene. Il problema è, e la particolarità della classica topologia Clos, è che se guardiamo la parte superiore del tessuto, in qualsiasi elemento, esiste un solo percorso per qualsiasi elemento sottostante. Se si verificano guasti lungo questo percorso, questo particolare elemento in cima alla fabbrica diventa non valido proprio per quei prefissi che si trovano dietro il percorso interrotto. Ma per il resto è valido e dobbiamo analizzare i gruppi ECMP e introdurre un nuovo stato.
Che aspetto ha la scalabilità del piano dati sui dispositivi moderni? Se eseguiamo LPM (corrispondenza del prefisso più lungo), tutto va abbastanza bene, oltre 100 prefissi. Se parliamo di gruppi Next Hop, allora tutto è peggio, 2-4mila. Se stiamo parlando di una tabella che contiene una descrizione di Next Hops (o adiacenze), allora è compresa tra 16k e 64k. E questo può diventare un problema. E qui arriviamo a un'interessante digressione: cosa è successo all'MPLS nei data center? In linea di principio, volevamo farlo.
Sono successe due cose. Abbiamo effettuato la microsegmentazione sugli host; non avevamo più bisogno di farlo sulla rete. Non è andata molto bene con il supporto di diversi fornitori, e ancora di più con implementazioni aperte su white box con MPLS. E MPLS, almeno nelle sue implementazioni tradizionali, sfortunatamente, si combina molto male con ECMP. Ed ecco perché.
Ecco come appare la struttura di inoltro ECMP per IP. Un gran numero di prefissi può utilizzare lo stesso gruppo e lo stesso blocco Next Hops (o adiacenze, questo può essere chiamato diversamente in documentazione diversa per dispositivi diversi). Il punto è che questa viene descritta come la porta in uscita e su cosa riscrivere l'indirizzo MAC per ottenere il Next Hop corretto. Per IP tutto sembra semplice, puoi utilizzare un numero molto elevato di prefissi per lo stesso gruppo, lo stesso blocco Next Hops.
La classica architettura MPLS implica che, a seconda dell'interfaccia in uscita, l'etichetta può essere riscritta con valori diversi. Pertanto, dobbiamo mantenere un gruppo e un blocco Next Hops per ciascuna etichetta di input. E questo, ahimè, non è scalabile.
È facile vedere che nel nostro progetto avevamo bisogno di circa 4000 switch ToR, la larghezza massima era di 64 percorsi ECMP, se ci spostiamo da spine-1 verso spine-2. Entriamo a malapena in una tabella dei gruppi ECMP, se scompare solo un prefisso con ToR, e non entriamo affatto nella tabella Next Hops.
Non è tutto senza speranza, perché architetture come Segment Routing coinvolgono etichette globali. Formalmente, sarebbe possibile comprimere nuovamente tutti questi blocchi Next Hops. Per fare ciò, è necessaria un'operazione di tipo jolly: prendere un'etichetta e riscriverla nella stessa senza un valore specifico. Ma purtroppo questo non è molto presente nelle implementazioni disponibili.
Infine, dobbiamo portare il traffico esterno nel data center. Come farlo? In precedenza, il traffico veniva introdotto nella rete Clos dall'alto. Cioè, c'erano router periferici collegati a tutti i dispositivi nella parte superiore del tessuto. Questa soluzione funziona abbastanza bene su dimensioni medio-piccole. Purtroppo, per inviare il traffico simmetricamente all'intera rete in questo modo, dobbiamo arrivare contemporaneamente a tutti gli elementi del Top of fabric, e quando sono più di un centinaio, risulta che abbiamo bisogno anche di un grande radix sui router perimetrali. In generale, questo costa denaro, perché i router edge sono più funzionali, le porte su di essi saranno più costose e il design non è molto bello.
Un'altra opzione è avviare tale traffico dal basso. È facile verificare che la topologia Clos è costruita in modo tale che il traffico proveniente dal basso, cioè dal lato ToR, venga distribuito uniformemente tra i livelli lungo l'intero Top of fabric in due iterazioni, caricando l'intera rete. Pertanto, introduciamo un tipo speciale di Pod, Edge Pod, che fornisce connettività esterna.
C'è un'altra opzione. Questo è ciò che fa Facebook, per esempio. Lo chiamano Fabric Aggregator o HGRID. È stato introdotto un ulteriore livello della colonna vertebrale per connettere più data center. Questa progettazione è possibile se non disponiamo di funzioni aggiuntive o modifiche all'incapsulamento sulle interfacce. Se sono punti di contatto aggiuntivi, è difficile. In genere sono presenti più funzioni e una sorta di membrana che separa le diverse parti del data center. Non ha senso ingrandire una membrana del genere, ma se per qualche motivo è davvero necessaria, allora ha senso considerare la possibilità di portarla via, allargarla il più possibile e trasferirla agli ospiti. Ciò viene fatto, ad esempio, da molti operatori cloud. Hanno sovrapposizioni, iniziano dagli host.
Quali opportunità di sviluppo vediamo? Innanzitutto migliorare il supporto alla pipeline CI/CD. Vogliamo volare nel modo in cui testiamo e testiamo il modo in cui voliamo. Questo non funziona molto bene, perché l'infrastruttura è grande ed è impossibile duplicarla per i test. È necessario capire come introdurre elementi di test nell'infrastruttura di produzione senza eliminarla.
Una migliore strumentazione e un migliore monitoraggio non sono quasi mai superflui. L’intera questione è un equilibrio tra impegno e rendimento. Se riesci ad aggiungerlo con uno sforzo ragionevole, molto bene.
Sistemi operativi aperti per dispositivi di rete. Protocolli e sistemi di routing migliori, come RIFT. Sono inoltre necessarie ricerche sull’uso di migliori schemi di controllo della congestione e forse sull’introduzione, almeno in alcuni punti, del supporto RDMA all’interno del cluster.
Guardando al futuro, abbiamo bisogno di topologie avanzate e possibilmente di reti che utilizzino meno spese generali. Tra le novità, ci sono state recentemente pubblicazioni sulla tecnologia fabric per HPC Cray Slingshot, che si basa su Ethernet di base, ma con la possibilità di utilizzare header molto più brevi. Di conseguenza, il sovraccarico viene ridotto.
Tutto dovrebbe essere mantenuto il più semplice possibile, ma non più semplice. La complessità è nemica della scalabilità. La semplicità e le strutture regolari sono nostre amiche. Se puoi scalare da qualche parte, fallo. E in generale, è fantastico essere coinvolti nelle tecnologie di rete adesso. Stanno accadendo molte cose interessanti. Grazie.
Fonte: habr.com