Cumu scala i centri di dati. Rapportu Yandex

Avemu sviluppatu un disignu di rete di centru di dati chì permette l'implementazione di clusters di informatica più grande di 100 mila servitori cù una larghezza di banda di bisezione di più di un petabyte per seconda.

Da u rapportu di Dmitry Afanasyev, amparate nantu à i principii basi di u novu disignu, a scala di topologie, i prublemi chì si sviluppanu cù questu, l'opzioni per risolviri, e caratteristiche di routing è scala di e funzioni di u pianu di spedizione di i dispositi di rete muderni in "densamente cunnessi". topologies cù un gran numaru di rotte ECMP. Inoltre, Dima hà parlatu brevemente di l'urganizazione di a cunnessione esterna, a capa fisica, u sistema di cablaggio è e manere di aumentà ancu a capacità.

Cumu scala i centri di dati. Rapportu Yandex

- Bona sera à tutti ! Mi chjamu Dmitry Afanasyev, sò un architettu di rete in Yandex è principalmente cuncepisce rete di centri di dati.

Cumu scala i centri di dati. Rapportu Yandex

A mo storia serà nantu à a reta aghjurnata di i centri di dati Yandex. Hè assai una evoluzione di u disignu chì avemu avutu, ma à u stessu tempu ci sò parechji elementi novi. Questa hè una presentazione generale perchè ci era assai infurmazione per esse imballata in una piccula quantità di tempu. Cumincià da sceglie una topulugia logica. Allora ci serà una visione generale di u pianu di cuntrollu è i prublemi cù a scalabilità di u pianu di dati, una scelta di ciò chì succederà à u livellu fisicu, è avemu da circà à qualchi funziunalità di i dispusitivi. Toccu un pocu nantu à ciò chì succede in un centru di dati cù MPLS, chì avemu parlatu qualchì tempu fà.

Cumu scala i centri di dati. Rapportu Yandex

Allora, chì hè Yandex in termini di carichi è servizii? Yandex hè un hyperscaler tipicu. Se guardemu à l'utilizatori, trattemu principalmente e dumande di l'utilizatori. Ancu diversi servizii di streaming è trasferimentu di dati, perchè avemu ancu servizii di almacenamento. Sè più vicinu à u backend, allora i carichi di l'infrastruttura è i servizii appariscenu quì, cum'è l'almacenamiento d'ogetti distribuiti, a replicazione di dati è, sicuru, fila persistenti. Unu di i tipi principali di carichi di travagliu hè MapReduce è sistemi simili, trasfurmazioni di flussu, apprendimentu machine, etc.

Cumu scala i centri di dati. Rapportu Yandex

Cumu hè l'infrastruttura sopra à quale tuttu questu succede? In novu, simu un iperscaler abbastanza tipicu, anche se simu forse un pocu più vicinu à u latu di iperscaler minore di u spettru. Ma avemu tutti l'attributi. Utilizemu hardware di merci è scala horizontale induve pussibule. Avemu una risorsa piena di risorsa: ùn avemu micca travagliatu cù macchine individuali, rack individuali, ma li combina in una grande piscina di risorse intercambiabili cù qualchi servizii supplementari chì trattanu di pianificazione è allocazione, è travaglià cù questa piscina sana.

Allora avemu u prossimu livellu - u sistema upirativu à u livellu di u cluster di computing. Hè assai impurtante chì cuntrullemu cumplettamente a pila di tecnulugia chì usemu. Cuntrollemu l'endpoints (ospiti), a rete è a pila di software.

Avemu parechji grandi centri di dati in Russia è à l'esteru. Sò uniti da una spina chì usa a tecnulugia MPLS. A nostra infrastruttura interna hè guasi cumpletamente custruita nantu à IPv6, ma postu chì avemu bisognu di serve u trafficu esternu chì vene sempre principarmenti annantu à IPv4, duvemu in qualchì modu furnisce e richieste chì venenu nantu à IPv4 à i servitori di frontend, è un pocu più andà à l'IPv4 esternu - Internet - per esempiu, per l'indexazione.

L'ultime iterazioni di i disinni di rete di centru di dati anu utilizatu topologie Clos multi-layer è sò solu L3. Avemu partutu da L2 un pocu di tempu fà è respira un suspiru di sollievu. Infine, a nostra infrastruttura include centinaie di millaie di istanze di computer (server). A dimensione massima di u cluster qualchì tempu fà era di circa 10 mila servitori. Questu hè in gran parte dovutu à cumu si ponu travaglià quelli stessi sistemi operativi à livellu di cluster, pianificatori, allocazione di risorse, etc.. Siccomu u prugressu hè accadutu da u latu di u software di l'infrastruttura, a dimensione di destinazione hè avà circa 100 mila servitori in un cluster di computing, è Avemu un compitu - per esse capace di custruisce fabbriche di rete chì permettenu una riunione efficiente di risorse in un tali cluster.

Cumu scala i centri di dati. Rapportu Yandex

Chì vulemu da una reta di centru di dati? Prima di tuttu, ci hè assai di larghezza di banda economica è abbastanza uniforme. Perchè a reta hè a spina dorsale per mezu di quale pudemu aghjunghje risorse. A nova dimensione di destinazione hè di circa 100 mila servitori in un cluster.

Avemu ancu, sicuru, vulemu un pianu di cuntrollu scalable è stabile, perchè nantu à una infrastruttura cusì grande, assai mal di testa nascenu ancu da avvenimenti simplici casuali, è ùn vulemu chì u pianu di cuntrollu ci porta ancu mal di testa. À u listessu tempu, vulemu minimizzà u statu in questu. A più chjuca hè a cundizione, u megliu è più stabile tuttu funziona, è più faciule hè di diagnosticà.

Di sicuru, avemu bisognu di l'automatizazione, perchè hè impussibile di gestisce una tale infrastruttura manualmente, è hè impussibile per qualchì tempu. Avemu bisognu di supportu operativu quant'è pussibule è supportu CI / CD in quantu pò esse furnitu.

Cù tali dimensioni di centri di dati è clusters, u compitu di sustene l'implementazione incrementale è l'espansione senza interruzzione di serviziu hè diventatu abbastanza acutu. Sì nantu à clusters di una dimensione di mille macchine, forse vicinu à decemila machini, puderianu ancu esse lanciate cum'è una operazione - vale à dì, avemu pianificatu un espansione di l'infrastruttura, è parechji milla macchine sò aghjuntu cum'è una sola operazione, tandu un cluster di una grandezza di centu mila machini ùn nasce micca subitu cusì, hè custruitu annantu à un periudu di tempu. È hè desideratu chì tuttu questu tempu ciò chì hè digià statu pompatu, l'infrastruttura chì hè stata implementata, deve esse dispunibule.

È un requisitu chì avemu avutu è lasciatu: supportu per a multitenancy, vale à dì, a virtualizazione o a segmentazione di a rete. Avà ùn avemu micca bisognu di fà questu à u nivellu di tela di a rete, perchè u sharding hè andatu à l'ospiti, è questu hà fattu scaling assai faciule per noi. Grazie à l'IPv6 è à un grande spaziu di indirizzu, ùn avemu micca bisognu di utilizà indirizzi duplicati in l'infrastruttura interna; tutti l'indirizzu era digià unicu. È grazia à u fattu chì avemu pigliatu u filtru è a segmentazione di a rete à l'ospiti, ùn avemu micca bisognu di creà alcuna entità di rete virtuale in rete di data center.

Cumu scala i centri di dati. Rapportu Yandex

Una cosa assai impurtante hè ciò chì ùn avemu micca bisognu. Se alcune funzioni ponu esse sguassate da a reta, questu rende a vita assai più faciule, è, in regula, allarga l'scelta di l'equipaggiu è u software dispunibule, facendu diagnostichi assai simplice.

Allora, chì hè chì ùn avemu micca bisognu, chì avemu pussutu rinunzià, micca sempre cun gioia à u mumentu chì hè accadutu, ma cun grande sollievu quandu u prucessu hè cumpletu?

Prima di tuttu, abbandunà L2. Ùn avemu micca bisognu di L2, nè reale nè emulatu. Inutilizatu in gran parte per u fattu chì cuntrullemu a pila di applicazioni. I nostri appricazzioni sò scalabili orizzontalmente, travaglianu cù l'indirizzu L3, ùn sò micca assai preoccupati chì qualchì istanza individuale hè andata fora, simpricimenti lancianu una nova, ùn hè micca bisognu à esse lanciata à u vechju indirizzu, perchè ci hè un livellu separatu di scuperta di serviziu è monitoraghju di e macchine situate in u cluster. Ùn avemu micca delegatu stu compitu à a reta. U travagliu di a rete hè di furnisce i pacchetti da u puntu A à u puntu B.

Ùn avemu micca ancu situazioni induve l'indirizzi si movenu in a reta, è questu deve esse monitoratu. In parechji disinni, questu hè tipicamente necessariu per sustene a mobilità VM. Ùn aduprate micca a mobilità di e macchine virtuali in l'infrastruttura interna di u grande Yandex, è, in più, credemu chì ancu s'ellu hè fattu, ùn deve micca accade cù u supportu di a rete. S'ellu ci vole à fà veramente, deve esse fattu à u nivellu di l'ospiti, è spinghje l'indirizzi chì ponu migrà in overlays, per ùn toccu o fà troppu cambiamenti dinamichi à u sistema di routing di u sottumessu stessu (rete di trasportu) .

Una altra tecnulugia chì ùn avemu micca aduprà hè multicast. Se vulete, vi possu dì in dettagliu perchè. Questu rende a vita assai più faciule, perchè se qualchissia hà trattatu cù questu è hà vistu esattamente ciò chì u pianu di cuntrollu multicast pare, in tutte e installazioni più simplici, questu hè un grande mal di testa. E in più, hè difficiule di truvà una implementazione open source chì funziona bè, per esempiu.

Infine, cuncepemu e nostre rete per ùn cambià micca troppu. Pudemu cuntà u fattu chì u flussu di avvenimenti esterni in u sistema di routing hè chjucu.

Cumu scala i centri di dati. Rapportu Yandex

Chì prublemi nascenu è chì restrizioni deve esse cunsideratu quandu sviluppemu una reta di centru di dati? Costu, sicuru. Scalabilità, u livellu à quale vulemu cultivà. U bisognu di espansione senza piantà u serviziu. Larghezza di banda, dispunibilità. Visibilità di ciò chì succede in a reta per i sistemi di monitoraghju, per i gruppi operativi. Supportu di l'automatizazione - novu, quant'è pussibule, postu chì e diverse attività ponu esse risolte à diversi livelli, cumprese l'intruduzioni di strati supplementari. Ebbè, micca [possibilmente] dipende da i venditori. Ancu s'ellu in e diverse periodi storichi, secondu a sezione chì guardate, sta indipendenza era più faciule o più difficiuli di ottene. Se avemu pigliatu una sezione trasversale di chips di l'apparecchi di rete, allora finu à pocu tempu era assai cundiziunale per parlà di l'indipendenza di i venditori, se vulemu ancu chips cù un altu throughput.

Cumu scala i centri di dati. Rapportu Yandex

Chì topulugia logica useremu per custruisce a nostra reta? Questu serà un Clos multi-livellu. In fatti, ùn ci hè micca una vera alternativa à u mumentu. È a topulugia Clos hè abbastanza bona, ancu paragunata à diverse topologie avanzate chì sò più in l'area di interessu accademicu avà, se avemu grandi switch radix.

Cumu scala i centri di dati. Rapportu Yandex

Cumu hè una reta di Clos multi-livellu strutturata apprussimatamente è chì sò i sfarenti elementi chjamati in questu? Prima di tuttu, a rosa di u ventu, per orientà sè stessu induve hè u nordu, induve hè u sudu, induve hè u livante, induve hè u punente. Reti di stu tipu sò generalmente custruiti da quelli chì anu un trafficu assai grande à l'ouest-est. In quantu à l'elementi rimanenti, in cima hè un switch virtuale assemblatu da switches più chjuchi. Questa hè l'idea principale di a custruzzione recursiva di e rete Clos. Pigliamu elementi cù un tipu di radix è li cunnetta in modu chì ciò chì uttene pò esse cunsideratu cum'è un cambiamentu cù un radix più grande. Sè avete bisognu di più, a prucedura pò esse ripetuta.

In i casi, per esempiu, cù Clos à dui livelli, quandu hè pussibule identificà chjaramente cumpunenti chì sò verticali in u mo schema, sò generalmente chjamati piani. Se avemu da custruisce un Clos cù trè livelli di switches spine (tutti chì ùn sò micca cunfini o switch ToR è chì sò usati solu per u transitu), allora l'aerei pareranu più cumplessi; quelli di dui livelli sò esattamente cusì. Chjamemu un bloccu di ToR o interruttori di foglia è i switches spine di u primu livellu assuciatu cun elli un Pod. Spine switches di u livellu spine-1 à a cima di u Pod sò a cima di Pod, a cima di u Pod. I switches chì sò situati à a cima di tutta a fabbrica sò a capa superiore di a fabbrica, Top of fabric.

Cumu scala i centri di dati. Rapportu Yandex

Di sicuru, a quistione si pone: e rete Clos sò state custruite da qualchì tempu; l'idea stessa vene in generale da i tempi di a telefonia classica, e rete TDM. Forse qualcosa di megliu hè apparsu, forse qualcosa pò esse fattu megliu? Iè è nò. Teoricamente sì, in pratica in un futuru vicinu definitu micca. Perchè ci sò parechje topologies interessanti, alcune sò ancu usate in a produzzione, per esempiu, Dragonfly hè utilizatu in applicazioni HPC; Ci sò ancu topologies interessanti cum'è Xpander, FatClique, Jellyfish. Se guardate i rapporti in cunferenze cum'è SIGCOMM o NSDI recentemente, pudete truvà un numeru abbastanza grande di travaglii nantu à topologie alternative chì anu megliu proprietà (una o l'altru) chì Clos.

Ma tutte queste topologies anu una pruprietà interessante. Impedisce a so implementazione in e rete di centri di dati, chì avemu da pruvà à custruisce nantu à hardware di commodità è chì costanu soldi abbastanza raghjone. In tutte queste topologie alternative, a maiò parte di a larghezza di banda hè sfurtunatamenti micca accessibile per via di i camini più brevi. Dunque, perdemu subitu l'uppurtunità di utilizà u pianu di cuntrollu tradiziunale.

In teoria, a suluzione à u prublema hè cunnisciuta. Quessi sò, per esempiu, mudificazioni di u statu di u ligame chì utilizanu a strada più corta, ma, di novu, ùn sò micca tali protokolli chì seranu implementati in a produzzione è largamente dispunibili nantu à l'equipaggiu.

Inoltre, postu chì a maiò parte di a capacità ùn hè micca accessibile per via di i camini più brevi, avemu bisognu di mudificà più di u pianu di cuntrollu per selezziunà tutti quelli camini (è per via, questu hè significativamente più statu in u pianu di cuntrollu). Avemu sempre bisognu di mudificà u pianu di spedizione, è, in regula, almenu duie funzioni supplementari sò richieste. Questa hè a capacità di piglià tutte e decisioni nantu à l'invio di pacchetti una volta, per esempiu, nantu à l'ospite. In fatti, questu hè u routing di fonte, qualchì volta in a literatura nantu à e rete di interconnessione, questu hè chjamatu decisioni di spedizione all-at-once. È l'adattivu routing hè una funzione chì avemu bisognu nantu à l'elementi di a rete, chì si riduce, per esempiu, à u fattu chì selezziunà u prossimu hop basatu annantu à l'infurmazioni nantu à a minima carica in a fila. Per esempiu, altre opzioni sò pussibuli.

Cusì, a direzzione hè interessante, ma, sfortunatamente, ùn pudemu micca applicà avà.

Cumu scala i centri di dati. Rapportu Yandex

Va bè, avemu stallatu nantu à a topulugia logica Clos. Cumu l'avemu scala? Videmu cumu si travaglia è ciò chì si pò fà.

Cumu scala i centri di dati. Rapportu Yandex

In una reta di Clos ci sò dui paràmetri principali chì pudemu varià in qualchì manera è ottene certi risultati: a radica di elementi è u numeru di livelli in a reta. Aghju un schema schematicu di cumu i dui affettanu a dimensione. Ideale, combinemu i dui.

Cumu scala i centri di dati. Rapportu Yandex

Pò esse vistu chì a larghezza finali di a reta di Clos hè u pruduttu di tutti i livelli di spine switches di a radica miridiunali, quantu ligami avemu falà, cumu si ramu. Questu hè cumu scalemu a dimensione di a reta.

Cumu scala i centri di dati. Rapportu Yandex

In quantu à a capacità, in particulare nantu à i switch ToR, ci sò duie opzioni di scala. O pudemu, mantenendu a topologia generale, aduprà ligami più veloci, o pudemu aghjunghje più piani.

Se fighjate à a versione allargata di a reta Clos (in u cantonu in basso à destra) è torna à sta stampa cù a reta Clos sottu ...

Cumu scala i centri di dati. Rapportu Yandex

... allora questu hè esattamente a stessa topologia, ma nantu à questa slide hè colapsatu più compactu è i piani di a fabbrica sò superposti l'un à l'altru. Hè u listessu.

Cumu scala i centri di dati. Rapportu Yandex

Chì ci hè a scala di una reta Clos in numeri? Quì aghju furnitu dati nantu à quale larghezza massima pò esse acquistata una rete, quale numeru massimu di racks, switch ToR o switch di foglia, s'ellu ùn sò micca in rack, pudemu uttene secondu ciò chì radix di switches usemu per spine -levels, è quanti livelli avemu aduprà.

Eccu quanti racks pudemu avè, quanti servitori è apprussimatamente quantu tuttu questu pò cunsumà basatu annantu à 20 kW per rack. Un pocu prima aghju dettu chì avemu da scopu di un cluster size di circa 100 mila servitori.

Pò esse vistu chì in tuttu stu disignu, duie opzioni è mezu sò d'interessu. Ci hè una opzione cù dui strati di spine è switches 64-port, chì casca un pocu cortu. Allora ci sò l'opzioni perfettamente adattate per 128-port (cù radix 128) spine switches cù dui livelli, o switches with radix 32 cù trè livelli. È in tutti i casi, induve ci sò più radix è più strati, pudete fà una reta assai grande, ma si fighjate à u cunsumu previstu, tipicamente ci sò gigawatts. Hè pussibule di mette un cable, ma hè improbabile di ottene tanta electricità in un situ. Se guardate statistiche è dati publichi nantu à i centri di dati, pudete truvà assai pochi centri di dati cù una capacità stimata di più di 150 MW. I più grandi sò generalmente campus di data center, parechji grandi centri di dati situati abbastanza vicinu à l'altri.

Ci hè un altru paràmetru impurtante. Se guardate a colonna di manca, a larghezza di banda utilizable hè listata quì. Hè facilitu per vede chì in una reta di Clos una parte significativa di i porti sò utilizati per cunnette i switches à l'altri. A larghezza di banda utilizable, una striscia utile, hè qualcosa chì pò esse datu fora, versu i servitori. Naturalmente, parlu di porti cundiziunali è specificamente di a banda. In regula, i ligami in a reta sò più veloci cà i ligami versu i servitori, ma per unità di larghezza di banda, quantu pudemu mandà à u nostru equipamentu di u servitore, ci hè ancu una certa larghezza di banda in a reta stessa. E più livelli chì facemu, più grande u costu specificu di furnisce sta striscia à l'esternu.

Inoltre, ancu sta banda supplementaria ùn hè micca esattamente u listessu. Mentre i spans sò brevi, pudemu usà qualcosa cum'è DAC (coper attach direct, vale à dì, cables twinax), o ottiche multimode, chì costanu ancu più o menu ragiunate soldi. Appena ci movemu à spazii più longu - in regula, queste sò ottiche di modu unicu, è u costu di questa larghezza di banda supplementaria aumenta notevolmente.

È dinò, vultendu à a diapositiva precedente, se creamu una reta Clos senza oversubscription, allora hè faciule per fighjà u diagramma, vede cumu a reta hè custruita - aghjunghjendu ogni livellu di spine switches, ripetemu tutta a striscia chì era à u fondu. Plus level - più a listessa banda, u listessu numeru di porti nantu à i switches chì ci era à u livellu precedente, è u listessu numeru di transceivers. Per quessa, hè assai desideratu per minimizzà u numeru di livelli di spine switches.

Basatu annantu à sta stampa, hè chjaru chì vulemu veramente custruisce qualcosa cum'è switches cù una radice di 128.

Cumu scala i centri di dati. Rapportu Yandex

Quì, in principiu, tuttu hè u listessu di ciò chì aghju dettu; questu hè un slide per cunsiderà dopu.

Cumu scala i centri di dati. Rapportu Yandex

Chì opzioni ci sò chì pudemu sceglie cum'è tali switches? Hè una nutizia assai piacevule per noi chì avà tali rete ponu infine esse custruite nantu à switches unicu chip. È questu hè assai bellu, anu assai boni caratteristiche. Per esempiu, ùn anu quasi nisuna struttura interna. Questu significa chì si rompenu più facilmente. Si rompenu in ogni modu, ma per furtuna si rompenu cumplettamente. In i dispusitivi modulari ci sò un gran numaru di difetti (assai sgradevoli), quandu da u puntu di vista di i vicini è di u pianu di cuntrollu pare chì travaglia, ma, per esempiu, una parte di u tela hè stata persa è ùn hè micca travagliatu. a piena capacità. È u trafficu à questu hè equilibratu basatu annantu à u fattu chì hè cumplettamente funziunale, è pudemu avè sopracargatu.

O, per esempiu, i prublemi sò cun u backplane, perchè in u dispusitivu modulare ci sò ancu SerDes d'alta velocità - hè veramente cumplessu. O i segni trà l'elementi di spedizione sò sincronizati o micca sincronizati. In generale, ogni dispusitivu modulari pruduttivu custituitu da un gran numaru di elementi, cum'è regula, cuntene a stessa reta Clos in sè stessu, ma hè assai difficiuli di diagnostichi. Spessu hè difficiule ancu per u venditore stessu di diagnosticà.

È hà un gran numaru di scenarii di fallimentu in quale u dispusitivu si degrada, ma ùn cascà micca da a topologia cumpletamente. Siccomu a nostra reta hè grande, l'equilibriu trà elementi idèntici hè attivamente utilizatu, a reta hè assai regulare, vale à dì, una strada nantu à quale tuttu hè in ordine ùn hè micca sfarente da l'altru percorsu, hè più prufittuamente per noi di perde solu un pocu di i dispusitivi da a topulugia chè à finisce in una situazione induve certi di elli parenu travaglià, ma alcuni ùn sò micca.

Cumu scala i centri di dati. Rapportu Yandex

A prossima bella funzione di i dispositi unicu chip hè chì evoluzione megliu è più veloce. Anu ancu tendenu à avè una capacità megliu. Se pigliamu e grandi strutture assemblate chì avemu nantu à un circhiu, allura a capacità per unità di rack per i porti di a listessa velocità hè quasi duie volte più bona di quella di i dispositi modulari. I dispusitivi custruiti intornu à un chip unicu sò notevolmente più prezzu di quelli modulari è cunsuma menu energia.

Ma, sicuru, questu hè tuttu per una ragione, ci sò ancu disadvantages. Prima, u radix hè quasi sempre più chjucu cà quellu di i dispositi modulari. Se pudemu avè un dispositivu custruitu intornu à un chip cù porti 128, allora pudemu avè un modulare cù parechji centu porti avà senza prublemi.

Questa hè una dimensione notevolmente più chjuca di e tavule di spedizione è, in regula, tuttu ciò chì hè in relazione cù a scalabilità di u pianu di dati. Buffers superficiali. È, in regula, funziunalità piuttostu limitata. Ma si trova chì si cunnosci sti restrizioni è pigliate cura à tempu per aggiralli o simpricimenti piglialli in contu, allora questu ùn hè micca cusì spaventoso. U fattu chì a radix hè più chjuca ùn hè più un prublema nantu à i dispositi cù un radix di 128 chì sò finalmente apparsu recentemente; pudemu custruisce in dui strati di spine. Ma hè sempre impussibile di custruisce qualcosa più chjucu di dui chì hè interessante per noi. Cù un livellu, sò ottenuti clusters assai chjuchi. Ancu i nostri disinni precedenti è esigenze li superanu sempre.

In fatti, s'ellu di colpu a suluzione hè in un locu à u latu, ci hè sempre una manera di scala. Siccomu l'ultimu (o u primu), livellu più bassu induve i servitori sò cunnessi sò interruttori ToR o interruttori di foglia, ùn avemu micca bisognu di cunnette un rack à elli. Per quessa, se a suluzione ùn manca di circa a mità, pudete pensà à aduprà solu un interruttore cù una grande radica à u livellu più bassu è cunnetta, per esempiu, dui o trè racks in un switch. Questu hè ancu una opzione, hà i so costi, ma funziona abbastanza bè è pò esse una bona suluzione quandu avete bisognu à ghjunghje à circa duie volte di grandezza.

Cumu scala i centri di dati. Rapportu Yandex

Per sintetizà, simu custruendu nantu à una topulugia cù dui livelli di spine, cù ottu strati di fabbrica.

Cumu scala i centri di dati. Rapportu Yandex

Chì succede à a fisica? Calculi assai simplici. Se avemu dui livelli di spine, allora avemu solu trè livelli di switches, è aspettemu chì ci saranu trè segmenti di cable in a reta: da i servitori à i switches di foglia, à a spine 1, à a spine 2. L'opzioni chì pudemu. usu sò - questi sò twinax, multimode, single mode. È quì avemu bisognu di cunsiderà quale striscia hè dispunibule, quantu costarà, ciò chì e dimensioni fisiche sò, quali spazii pudemu copre, è cumu avemu da aghjurnà.

In termini di costu, tuttu pò esse allineatu. Twinaxes sò significativamente più prezzu di l'ottica attiva, più prezzu di i transceivers multimode, se pigliate per volu da a fine, un pocu più prezzu di un portu di switch 100-gigabit. E, per piacè nutate, custa menu di l'ottica di modu unicu, perchè in i voli induve u modu unicu hè necessariu, in i centri di dati per una quantità di ragioni, hè sensu à utilizà CWDM, mentri u modu unicu parallelu (PSM) ùn hè micca assai còmuda di travaglià. cun, pacchetti assai grande sò ottenuti fibre, è se avemu focu annantu à sti tecnulugii, avemu apprussimatamente a ghjerarchia di prezzu.

Una nota più: sfurtunatamenti, ùn hè micca assai pussibule di utilizà porti multimode disassemblati da 100 à 4x25. A causa di e caratteristiche di cuncepimentu di i transceivers SFP28, ùn hè micca assai più prezzu di 28 Gbit QSFP100. È questu disassemblamentu per multimode ùn viaghja micca bè.

Un'altra limitazione hè chì, per via di a dimensione di i clusters di l'informatica è u numeru di servitori, i nostri centri di dati risultanu esse fisicamenti grande. Questu significa chì almenu un volu duverà esse fattu cù un singlemod. In novu, per via di a dimensione fisica di i Pods, ùn serà micca pussibule di eseguisce dui span di twinax (cavi di cobre).

In u risultatu, se ottimisimu per u prezzu è piglià in contu a geometria di stu disignu, avemu un span di twinax, un span di multimode è un span di singlemode cù CWDM. Questu piglia in contu e pussibuli percorsi di aghjurnamentu.

Cumu scala i centri di dati. Rapportu Yandex

Questu hè ciò chì pare recentemente, induve andemu è ciò chì hè pussibule. Hè chjaru, almenu, cumu si avanza versu 50-Gigabit SerDes per u multimode è unicu. Inoltre, se fighjate ciò chì hè in transceivers monomode avà è in u futuru per 400G, spessu ancu quandu 50G SerDes arrivanu da u latu elettricu, 100 Gbps per via pò digià andà à l'ottica. Per quessa, hè abbastanza pussibule chì invece di trasfurmà à 50, ci sarà una transizione à 100 Gigabit SerDes è 100 Gbps per via, perchè secondu e prumesse di parechji venditori, a so dispunibilità hè prevista abbastanza prestu. U periodu quandu 50G SerDes eranu i più veloci, pare, ùn serà micca assai longu, perchè e prime copie di 100G SerDes seranu sparte quasi l'annu dopu. È dopu qualchì tempu dopu, probabilmente valeranu soldi raghjone.

Cumu scala i centri di dati. Rapportu Yandex

Una sfumatura più nantu à a scelta di a fisica. In principiu, pudemu digià aduprà porti 400 o 200 Gigabit cù 50G SerDes. Ma risulta chì questu ùn hè micca assai sensu, perchè, cum'è aghju dettu prima, vulemu una radica abbastanza grande nantu à i switches, in ragiuni, sicuru. Vulemu 128. E se avemu una capacità di chip limitata è aumentamu a velocità di u ligame, allura a radica naturalmente diminuite, ùn ci hè micca miraculi.

È pudemu aumentà a capacità tutale cù l'aviò, è ùn ci hè micca costu speciale; pudemu aghjunghje u numeru di piani. È se perdemu a radix, avemu da intruduce un livellu supplementu, cusì in a situazione attuale, cù a capacità massima dispunibule attuale per chip, risulta chì hè più efficaci à utilizà porti 100-gigabit, perchè permettenu di voi. pè ottene una radica più grande.

Cumu scala i centri di dati. Rapportu Yandex

A prossima quistione hè cumu a fisica hè urganizata, ma da u puntu di vista di l'infrastruttura di cable. Risulta chì hè urganizatu in una manera piuttostu divertente. Cabling trà foglia-switch è spine di primu livellu - ùn ci sò micca assai ligami, tuttu hè custruitu relativamente simplice. Ma s'è no pigghiamu un aviò, ciò chì succede in l'internu hè chì avemu bisognu di cunnette tutte e spine di u primu livellu cù tutte e spine di u sicondu livellu.

In più, in regula, ci sò parechji desideri per cumu si deve vede in u centru di dati. Per esempiu, avemu veramente vulutu cunghjuntà i cavi in ​​un fasciu è tirali in modu chì un pannellu di patch d'alta densità andava interamente in un pannellu di patch, perchè ùn ci era micca zoo in termini di lunghezze. Avemu riesciutu à risolve stu prublema. Sè vo circate inizialmente à a topologia logica, pudete vede chì i piani sò indipindenti, ogni pianu pò esse custruitu nantu à u so propiu. Ma quandu aghjustemu un tali bundling è vulemu trascinà tuttu u patch panel in un patch panel, avemu da mischjà diversi piani in un bundle è intruduce una struttura intermedia in forma di cunnessioni ottiche incruciate per rimballà da cumu sò stati assemblati. nantu à un segmentu, in cumu si saranu culletti nantu à un altru segmentu. Grazie à questu, avemu una bella funzione: tuttu u cambiamentu cumplessu ùn và più di i racks. Quandu avete bisognu di intrecciate qualcosa assai forte, "unfold the planes", cum'è qualchì volta hè chjamatu in e rete Clos, hè tuttu cuncentratu in un rack. Ùn avemu micca assai disassemblatu, finu à i ligami individuali, cambiendu trà rack.

Cumu scala i centri di dati. Rapportu Yandex

Questu hè cumu si vede da u puntu di vista di l'urganizazione logica di l'infrastruttura di cable. In a stampa di a manca, i blocchi multicolori rapprisentanu blocchi di switches spine di primu livellu, ottu pezzi ognunu, è quattru fasci di cables chì venenu da elli, chì vanu è si intersecanu cù i fasci chì venenu da i blocchi di spine-2 switches. .

Picculi quadrati indicanu intersezioni. In cima à manca hè una scomposizione di ogni intersezzione, questu hè in realtà un modulu di cunnessione incruciata di portu 512 per 512 chì repacks i cavi in ​​modu chì venenu cumpletamente in un rack, induve ci hè solu un pianu spine-2. È à a diritta, una scansione di sta stampa hè un pocu più detallata in relazione à parechji Pods à u livellu spine-1, è cumu hè imballatu in un cross-connect, cumu si tratta di u livellu spine-2.

Cumu scala i centri di dati. Rapportu Yandex

Questu hè ciò chì pare. U stand spine-2 micca ancora cumplettamente assemblatu (à a manca) è u stand cross-connect. Sfortunatamente, ùn ci hè micca assai da vede. Sta struttura intera hè stata implementata avà in unu di i nostri grandi centri di dati chì hè in espansione. Questu hè un travagliu in prugressu, serà più bellu, sarà cumpletu megliu.

Cumu scala i centri di dati. Rapportu Yandex

Una quistione impurtante: avemu sceltu a topologia logica è custruisce a fisica. Chì succede à u pianu di cuntrollu? Hè abbastanza cunnisciutu da l'esperienza operativa, ci sò una quantità di rapporti chì i protokolli statali di ligami sò boni, hè un piacè di travaglià cun elli, ma, sfurtunatamenti, ùn sò micca scalate bè nantu à una topulugia densamente cunnessa. È ci hè un fattore principalu chì impedisce questu - questu hè cumu funziona l'inundazioni in i protokolli di u ligame. Se solu pigliate l'algoritmu d'inundazioni è fighjate cumu a nostra reta hè strutturata, pudete vede chì ci sarà un fanout assai grande à ogni passu, è simpricimenti inundarà u pianu di cuntrollu cù l'aghjurnamenti. In particulare, tali topologie si mischianu assai male cù l'algoritmu tradiziunale di inundazione in i protokolli di u statu di ligame.

A scelta hè di utilizà BGP. Cumu preparà currettamente hè descrittu in RFC 7938 nantu à l'usu di BGP in grandi centri di dati. L'idee basi sò simplici: u minimu numeru di prefissi per host è in generale u minimu numeru di prefissi nantu à a reta, utilizate l'agregazione se pussibule, è supprime a caccia di caminu. Vulemu una distribuzione assai attenta, assai cuntrullata di l'aghjurnamenti, ciò chì hè chjamatu valley free. Vulemu chì l'aghjurnamenti sò implementati esattamente una volta mentre passanu per a reta. S'elli sò urigginati in u fondu, cullà, si sviluppanu micca più di una volta. Ùn deve esse micca zigzag. Zigzags sò assai cattivi.

Per fà questu, usemu un disignu chì hè abbastanza simplice per utilizà i miccanismi BGP sottostanti. Vale à dì, usemu eBGP in esecuzione nantu à u ligame locale, è i sistemi autonomi sò attribuiti cusì: un sistema autonomu nantu à ToR, un sistema autonomu nantu à tuttu u bloccu di spine-1 switches di un Pod, è un sistema autonomu generale in tuttu u Top. di Tissu. Ùn hè micca difficiule di vede è vede chì ancu u cumpurtamentu normale di BGP ci dà a distribuzione di l'aghjurnamenti chì vulemu.

Cumu scala i centri di dati. Rapportu Yandex

Naturalmente, l'indirizzu è l'agregazione di l'indirizzu anu da esse cuncepitu in modu chì hè cumpatibile cù a manera di u routing hè custruitu, in modu chì assicura a stabilità di u pianu di cuntrollu. L'indirizzu L3 in u trasportu hè ligatu à a topulugia, perchè senza questu hè impussibile di ottene l'agregazione; senza questu, l'indirizzi individuali si infilaranu in u sistema di routing. È una cosa più hè chì l'agregazione, sfurtunatamenti, ùn si mischia assai bè cù multi-path, perchè quandu avemu multi-path è avemu aggregazione, tuttu hè bè, quandu tutta a reta hè sana, ùn ci hè micca fallimentu in questu. Sfurtunatamente, quandu i fallimenti appariscenu in a reta è a simetria di a topologia hè persa, pudemu ghjunghje à u puntu da quale l'unità hè stata annunziata, da quale ùn pudemu micca andà più in là induve avemu bisognu. Per quessa, hè megliu aggregate induve ùn ci hè più multi-path, in u nostru casu, questi sò switch ToR.

Cumu scala i centri di dati. Rapportu Yandex

In fatti, hè pussibule aggregate, ma cun cura. Se pudemu fà una disaggregazione cuntrullata quandu i fallimenti di a rete sò. Ma questu hè un compitu abbastanza difficiule, avemu ancu dumandatu s'ellu saria pussibule di fà questu, s'ellu era pussibile aghjunghje l'automatizazione supplementu, è e macchine di stati finiti chì avarianu currettamente BGP per ottene u cumpurtamentu desideratu. Sfurtunatamente, u processu di i casi di u cantonu hè assai micca ovvi è cumplessu, è questu compitu ùn hè micca bè risoltu da l'attacheti esterni à BGP.

Un travagliu assai interessante in questu sensu hè statu fattu in u quadru di u protocolu RIFT, chì serà discututu in u prossimu rapportu.

Cumu scala i centri di dati. Rapportu Yandex

Un'altra cosa impurtante hè cumu i piani di dati scalanu in topologies densi, induve avemu un gran numaru di camini alternattivi. In questu casu, parechje strutture di dati supplementari sò aduprate: gruppi ECMP, chì à u turnu descrizanu gruppi Next Hop.

In una reta di travagliu nurmale, senza fiaschi, quandu andemu in a topologia di Clos, hè abbastanza per aduprà solu un gruppu, perchè tuttu ciò chì ùn hè micca lucale hè descrittu per difettu, pudemu cullà. Quandu andemu da cima à fondu à u sudu, allora tutti i camini ùn sò micca ECMP, sò camini unichi. Tuttu hè bè. U prublema hè, è a peculiarità di a topulugia Clos classica hè chì s'è no guardemu à u Top of fabric, à ogni elementu, ci hè solu una strada per ogni elementu sottu. Se i fallimenti accadenu longu à sta strada, allora questu elementu particulari in cima di a fabbrica diventa invalidu precisamente per quelli prefissi chì si trovanu daretu à u percorsu rottu. Ma per u restu hè validu, è avemu da analizà i gruppi ECMP è intruduce un novu statu.

Chì ci hè a scalabilità di u pianu di dati in i dispositi muderni? Se facemu LPM (partita di prefissu più longu), tuttu hè abbastanza bè, più di 100k prefissi. Se parlemu di i gruppi Next Hop, allora tuttu hè peghju, 2-4 mila. Se parlemu di una tavula chì cuntene una descrizzione di Next Hops (o adiacencies), allora questu hè da 16k à 64k. È questu pò diventà un prublema. E quì ghjunghjemu à una digressione interessante: chì hè accadutu à MPLS in i centri di dati? In principiu, ci vulia à fà.

Cumu scala i centri di dati. Rapportu Yandex

Dui cose sò accaduti. Avemu fattu a micro-segmentazione nantu à l'ospiti; ùn avemu più bisognu di fà in a reta. Ùn era micca assai bè cù supportu di diversi venditori, è ancu più cù implementazioni aperti nantu à scatuli bianchi cù MPLS. E MPLS, almenu e so implementazioni tradiziunali, sfurtunatamenti, combina assai male cù ECMP. È hè per quessa.

Cumu scala i centri di dati. Rapportu Yandex

Questu hè ciò chì a struttura di trasmissione ECMP per IP pare. Un gran numaru di prefissi ponu utilizà u stessu gruppu è u listessu blocu Next Hops (o adiacenza, questu pò esse chjamatu in modu diversu in documentazioni differenti per i dispusitivi differenti). U puntu hè chì questu hè scrittu cum'è u portu in uscita è ciò chì riscrive l'indirizzu MAC per ghjunghje à u Next Hop currettu. Per IP tuttu pare simplice, pudete aduprà un gran numaru di prefissi per u stessu gruppu, u listessu blocu Next Hops.

Cumu scala i centri di dati. Rapportu Yandex

L'architettura MPLS classica implica chì, secondu l'interfaccia in uscita, l'etichetta pò esse riscritta à valori diffirenti. Dunque, avemu bisognu di mantene un gruppu è un bloccu Next Hops per ogni etichetta di input. È questu, alas, ùn scala micca.

Hè facilitu per vede chì in u nostru disignu avemu bisognu di circa 4000 switch ToR, a larghezza massima era 64 percorsi ECMP, si alluntanassi da a spine-1 versu a spine-2. Appena entremu in una tavula di gruppi ECMP, se solu un prefissu cù ToR si ne va, è ùn entremu micca in u tavulu Next Hops.

Cumu scala i centri di dati. Rapportu Yandex

Ùn hè micca tuttu senza speranza, perchè architetture cum'è Segment Routing implicanu etichette globale. Formalmente, saria pussibule di colapsà di novu tutti questi blocchi Next Hops. Per fà questu, avete bisognu di una operazione di tipu salvaticu: pigliate una etichetta è scrivite à u listessu senza un valore specificu. Ma sfurtunatamenti, questu ùn hè micca assai presente in l'implementazioni dispunibili.

È infine, avemu bisognu di portà u trafficu esternu in u centru di dati. Cumu fà? Nanzu, u trafficu hè statu introduttu in a reta di Clos da sopra. Vale à dì, ci eranu routers di punta chì cunnessu à tutti i dispositi nantu à a cima di u tissu. Sta suluzione funziona abbastanza bè nantu à e dimensioni chjuche è mediu. Sfurtunatamente, per mandà u trafficu simmetricamente à tutta a reta in questu modu, avemu bisognu à ghjunghje simultaneamente à tutti l'elementi di u Top di tela, è quandu ci sò più di un centu di elli, ci hè ancu chì avemu bisognu di un grande. radix nantu à i router di punta. In generale, questu custa soldi, perchè i router di punta sò più funziunali, i porti nantu à elli seranu più caru, è u disignu ùn hè micca assai bellu.

Un'altra opzione hè di inizià tali trafficu da quì sottu. Hè facilitu per verificà chì a topulugia Clos hè custruita in tale manera chì u trafficu chì vene da quì sottu, vale à dì, da u latu ToR, hè ancu distribuitu trà i livelli in tuttu u Top di tela in dui iterazioni, carrichendu tutta a reta. Dunque, introducemu un tipu speciale di Pod, Edge Pod, chì furnisce una cunnessione esterna.

Ci hè una altra opzione. Questu hè ciò chì Facebook faci, per esempiu. U chjamanu Fabric Aggregator o HGRID. Un livellu spine supplementu hè statu introduttu per cunnette parechji centri di dati. Stu disignu hè pussibule s'ellu ùn avemu micca funzioni supplementari o cambiamenti di incapsulazione à l'interfaccia. Se sò punti di toccu supplementari, hè difficiule. Di genere, ci sò più funzioni è una spezia di membrana chì separa e diverse parti di u centru di dati. Ùn ci hè nunda di fà una tale membrana grande, ma s'ellu hè veramente necessariu per una certa ragione, allora hè sensu di cunsiderà a pussibilità di piglià, facendu u più largu pussibule è trasfiriu à l'ospiti. Questu hè fattu, per esempiu, da parechji operatori di nuvola. Hanu overlays, partenu da l'ospiti.

Cumu scala i centri di dati. Rapportu Yandex

Chì opportunità di sviluppu vedemu? Prima di tuttu, migliurà u supportu per u pipeline CI/CD. Vulemu volà a manera di pruvà è pruvà a manera di vola. Questu ùn viaghja micca bè, perchè l'infrastruttura hè grande è hè impussibile di duplicà per i testi. Avete bisognu di capiscenu cumu intruduce elementi di teste in l'infrastruttura di produzzione senza abbandunà.

Una strumentazione megliu è un monitoraghju megliu ùn sò quasi mai superflui. A quistione sana hè un equilibriu di sforzu è ritornu. Se pudete aghjunghje cun sforzu raghjone, assai bè.

Sistemi operativi aperti per i dispositi di rete. Protokolli megliu è sistemi di routing megliu, cum'è RIFT. A ricerca hè ancu necessaria in l'usu di megliu schemi di cuntrollu di congestioni è forse l'intruduzioni, almenu in certi punti, di supportu RDMA in u cluster.

Fighjendu più in u futuru, avemu bisognu di topologie avanzate è possibbilmente rete chì utilizanu menu overhead. Di e cose fresche, ci sò stati recentemente publicazioni nantu à a tecnulugia di tela per HPC Cray Slingshot, chì hè basatu annantu à Ethernet commodity, ma cù l'opzione di utilizà intestazioni assai più brevi. In u risultatu, u overhead hè ridutta.

Cumu scala i centri di dati. Rapportu Yandex

Tuttu deve esse guardatu u più simplice pussibule, ma micca più simplice. A cumplessità hè u nemicu di a scalabilità. A simplicità è e strutture rigulari sò i nostri amichi. Se pudete fà scala in qualchì locu, fate. È in generale, hè grande per esse implicatu in tecnulugia di rete avà. Ci sò assai cose interessanti chì passanu. Grazie.

Source: www.habr.com

Add a comment