Am dezvoltat un design de rețea de centre de date care permite implementarea clusterelor de calcul mai mari de 100 de mii de servere cu o lățime de bandă de vârf de peste un petabyte pe secundă.
Din raportul lui Dmitry Afanasyev veți afla despre principiile de bază ale noului design, scalarea topologiilor, problemele care apar cu aceasta, opțiunile de rezolvare a acestora, caracteristicile de rutare și scalare a funcțiilor planului de redirecționare ale dispozitivelor de rețea moderne în „conectate dens” topologii cu un număr mare de rute ECMP . În plus, Dima a vorbit pe scurt despre organizarea conectivității externe, stratul fizic, sistemul de cablare și modalitățile de creștere a capacității.
- Buna ziua tuturor! Numele meu este Dmitry Afanasyev, sunt arhitect de rețea la Yandex și proiectez în primul rând rețele de centre de date.
Povestea mea va fi despre rețeaua actualizată de centre de date Yandex. Este foarte mult o evoluție a designului pe care l-am avut, dar în același timp există și câteva elemente noi. Aceasta este o prezentare de ansamblu, deoarece au fost multe informații care trebuiau împachetate într-o perioadă mică de timp. Vom începe prin a alege o topologie logică. Apoi va exista o privire de ansamblu asupra planului de control și a problemelor cu scalabilitatea planului de date, o alegere a ceea ce se va întâmpla la nivel fizic și vom analiza câteva caracteristici ale dispozitivelor. Să ne referim puțin la ceea ce se întâmplă într-un centru de date cu MPLS, despre care am vorbit cu ceva timp în urmă.
Deci, ce este Yandex în ceea ce privește încărcăturile și serviciile? Yandex este un hiperscaler tipic. Dacă ne uităm la utilizatori, procesăm în primul rând cererile utilizatorilor. De asemenea, diverse servicii de streaming și transfer de date, pentru că avem și servicii de stocare. Dacă este mai aproape de backend, atunci apar încărcările și serviciile de infrastructură, cum ar fi stocarea de obiecte distribuite, replicarea datelor și, desigur, cozile persistente. Unul dintre principalele tipuri de sarcini de lucru este MapReduce și sisteme similare, procesarea fluxului, învățarea automată etc.
Cum este infrastructura pe deasupra căreia se întâmplă toate acestea? Din nou, suntem un hiperscaler destul de tipic, deși poate suntem puțin mai aproape de partea mai mică a hiperscalerului a spectrului. Dar avem toate atributele. Folosim hardware de bază și scalare orizontală ori de câte ori este posibil. Avem o grupare completă de resurse: nu lucrăm cu mașini individuale, rafturi individuale, ci le combinăm într-un grup mare de resurse interschimbabile cu unele servicii suplimentare care se ocupă de planificare și alocare și lucrăm cu acest întreg grup.
Deci avem următorul nivel - sistemul de operare la nivelul clusterului de calcul. Este foarte important să controlăm pe deplin stiva de tehnologie pe care o folosim. Controlăm punctele finale (gazde), rețeaua și stiva de software.
Avem mai multe centre de date mari în Rusia și în străinătate. Ei sunt uniți de o coloană vertebrală care utilizează tehnologia MPLS. Infrastructura noastră internă este construită aproape în întregime pe IPv6, dar din moment ce trebuie să deservim traficul extern care încă vine în principal prin IPv4, trebuie să livrăm cumva cererile care vin prin IPv4 către serverele frontend și puțin mai mult să mergem la IPv4 extern - Internet - pentru de exemplu, pentru indexare.
Ultimele câteva iterații ale proiectelor de rețea de centre de date au folosit topologii Clos multistrat și sunt doar pentru L3. Am plecat de la L2 cu ceva timp în urmă și am răsuflat ușurați. În cele din urmă, infrastructura noastră include sute de mii de instanțe de calcul (server). Dimensiunea maximă a clusterului în urmă cu ceva timp era de aproximativ 10 mii de servere. Acest lucru se datorează în mare măsură modului în care aceleași sisteme de operare la nivel de cluster, programatori, alocarea de resurse etc. Avem o sarcină - să putem construi fabrici de rețea care să permită o punere în comun eficientă a resurselor într-un astfel de cluster.
Ce ne dorim de la o rețea de centre de date? În primul rând, există o mulțime de lățime de bandă ieftină și destul de uniform distribuită. Pentru că rețeaua este coloana vertebrală prin care putem pune în comun resursele. Noua dimensiune țintă este de aproximativ 100 de mii de servere într-un cluster.
De asemenea, ne dorim, desigur, un plan de control scalabil și stabil, pentru că pe o infrastructură atât de mare apar multe dureri de cap chiar și din evenimente pur și simplu aleatorii și nu vrem ca planul de control să ne aducă și dureri de cap. În același timp, dorim să minimizăm starea din el. Cu cât starea este mai mică, cu atât totul funcționează mai bine și mai stabil și cu atât este mai ușor de diagnosticat.
Desigur, avem nevoie de automatizare, pentru că este imposibil să gestionăm manual o astfel de infrastructură și este imposibil de ceva timp. Avem nevoie de sprijin operațional pe cât posibil și de suport CI/CD în măsura în care poate fi furnizat.
Cu asemenea dimensiuni de centre de date și clustere, sarcina de a sprijini implementarea și extinderea incrementală fără întrerupere a serviciului a devenit destul de acută. Dacă pe clustere de o dimensiune de o mie de mașini, poate aproape de zece mii de mașini, acestea ar putea fi încă lansate ca o singură operațiune - adică planificăm o extindere a infrastructurii și câteva mii de mașini sunt adăugate ca o singură operațiune, atunci un grup de o dimensiune de o sută de mii de mașini nu apare imediat așa, este construit pe o perioadă de timp. Și este de dorit ca în tot acest timp ceea ce a fost deja pompat, infrastructura care a fost implementată, să fie disponibil.
Și o cerință pe care am avut-o și am lăsat-o: suport pentru multitenancy, adică virtualizarea sau segmentarea rețelei. Acum nu trebuie să facem acest lucru la nivel de fabrică de rețea, deoarece sharding-ul a ajuns la gazde și acest lucru a făcut scalarea foarte ușoară pentru noi. Datorită IPv6 și unui spațiu mare de adrese, nu a fost nevoie să folosim adrese duplicate în infrastructura internă; toate adresele erau deja unice. Și datorită faptului că am dus filtrarea și segmentarea rețelei la gazde, nu este nevoie să creăm entități de rețea virtuală în rețelele de centre de date.
Un lucru foarte important este ceea ce nu avem nevoie. Dacă unele funcții pot fi eliminate din rețea, acest lucru face viața mult mai ușoară și, de regulă, extinde alegerea echipamentelor și software-ului disponibile, făcând diagnosticarea foarte simplă.
Deci, de ce nu avem nevoie, la ce am reușit să renunțăm, nu întotdeauna cu bucurie în momentul în care s-a întâmplat, dar cu mare ușurare când procesul este finalizat?
În primul rând, abandonarea L2. Nu avem nevoie de L2, nici real, nici emulat. Neutilizat în mare parte datorită faptului că controlăm stiva de aplicații. Aplicațiile noastre sunt scalabile orizontal, funcționează cu adresare L3, nu sunt foarte îngrijorați că o instanță individuală a dispărut, pur și simplu lansează una nouă, nu trebuie să fie lansată la vechea adresă, deoarece există o nivel separat de descoperire și monitorizare a mașinilor situate în cluster. Nu delegăm această sarcină rețelei. Sarcina rețelei este să livreze pachete de la punctul A la punctul B.
De asemenea, nu avem situații în care adresele se mișcă în cadrul rețelei, iar acest lucru trebuie monitorizat. În multe modele, acest lucru este de obicei necesar pentru a sprijini mobilitatea VM. Nu folosim mobilitatea mașinilor virtuale în infrastructura internă a marelui Yandex și, în plus, credem că, chiar dacă se face acest lucru, nu ar trebui să se întâmple cu suport de rețea. Dacă într-adevăr trebuie făcut, trebuie făcut la nivel de gazdă și împinge adrese care pot migra în suprapuneri, pentru a nu atinge sau a face prea multe modificări dinamice la sistemul de rutare al suportului în sine (rețeaua de transport) .
O altă tehnologie pe care nu o folosim este multicast. Dacă doriți, vă pot spune în detaliu de ce. Acest lucru face viața mult mai ușoară, deoarece dacă cineva s-a ocupat de asta și s-a uitat exact la cum arată planul de control multicast, în toate instalațiile, cu excepția celor mai simple, aceasta este o mare bătaie de cap. Și mai mult, este greu să găsești o implementare open source care să funcționeze bine, de exemplu.
În cele din urmă, ne proiectăm rețelele astfel încât să nu se schimbe prea mult. Putem conta pe faptul că fluxul de evenimente externe în sistemul de rutare este mic.
Ce probleme apar și ce restricții trebuie luate în considerare atunci când dezvoltăm o rețea de centre de date? Cost, desigur. Scalabilitate, nivelul la care dorim să creștem. Necesitatea extinderii fără a opri serviciul. Lățime de bandă, disponibilitate. Vizibilitatea a ceea ce se întâmplă în rețea pentru sistemele de monitorizare, pentru echipele operaționale. Suport de automatizare - din nou, pe cât posibil, deoarece diferite sarcini pot fi rezolvate la diferite niveluri, inclusiv introducerea de straturi suplimentare. Ei bine, nu depinde [posibil] de vânzători. Deși în diferite perioade istorice, în funcție de secțiunea la care te uiți, această independență a fost mai ușor sau mai greu de realizat. Dacă luăm o secțiune transversală a cipurilor dispozitivelor de rețea, atunci până de curând era foarte condiționat să vorbim despre independența față de vânzători, dacă ne doream și cipuri cu un randament ridicat.
Ce topologie logică vom folosi pentru a ne construi rețeaua? Acesta va fi un Clos cu mai multe niveluri. De fapt, nu există alternative reale în acest moment. Și topologia Clos este destul de bună, chiar și în comparație cu diverse topologii avansate care sunt mai mult în zona de interes academic acum, dacă avem comutatoare mari radix.
Cum este structurată aproximativ o rețea Clos pe mai multe niveluri și cum sunt numite diferitele elemente în ea? În primul rând, roza vânturilor, pentru a te orienta unde este nord, unde sud, unde est, unde vest. Rețelele de acest tip sunt construite de obicei de cei care au trafic vest-est foarte mare. În ceea ce privește elementele rămase, în partea de sus este un comutator virtual asamblat din întrerupătoare mai mici. Aceasta este ideea principală a construcției recursive a rețelelor Clos. Luăm elemente cu un fel de radix și le conectăm, astfel încât ceea ce obținem să poată fi considerat ca un comutator cu un radix mai mare. Dacă aveți nevoie de mai mult, procedura poate fi repetată.
În cazurile, de exemplu, cu Clos pe două niveluri, când este posibil să identifici clar componentele care sunt verticale în diagrama mea, acestea sunt de obicei numite plane. Dacă ar fi să construim un Clos cu trei nivele de comutatoare ale coloanei vertebrale (toate nu sunt comutatoare de frontieră sau ToR și care sunt folosite doar pentru tranzit), atunci avioanele ar arăta mai complexe; cele cu două niveluri arată exact așa. Numim un bloc de comutatoare ToR sau frunze și comutatoarele coloanei vertebrale de primul nivel asociate acestora un Pod. Comutatoarele coloanei vertebrale ale nivelului coloanei vertebrale-1 din partea de sus a Podului sunt partea de sus a Podului, partea de sus a Podului. Comutatoarele care sunt situate în partea de sus a întregii fabrici sunt stratul superior al fabricii, Top of fabric.
Desigur, se pune întrebarea: rețelele Clos sunt construite de ceva timp; ideea însăși vine în general din vremurile telefoniei clasice, rețele TDM. Poate a apărut ceva mai bun, poate se poate face ceva mai bine? Da și nu. Teoretic da, în practică în viitorul apropiat cu siguranță nu. Deoarece există o serie de topologii interesante, unele dintre ele sunt chiar folosite în producție, de exemplu, Dragonfly este folosit în aplicații HPC; Există și topologii interesante precum Xpander, FatClique, Jellyfish. Dacă te uiți la rapoarte de la conferințe precum SIGCOMM sau NSDI recent, poți găsi un număr destul de mare de lucrări pe topologii alternative care au proprietăți mai bune (una sau alta) decât Clos.
Dar toate aceste topologii au o proprietate interesantă. Împiedică implementarea lor în rețelele de centre de date, pe care încercăm să le construim pe hardware-ul de bază și care costă bani destul de rezonabili. În toate aceste topologii alternative, cea mai mare parte a lățimii de bandă nu este, din păcate, accesibilă prin cele mai scurte căi. Prin urmare, pierdem imediat oportunitatea de a folosi planul de control tradițional.
Teoretic, soluția problemei este cunoscută. Acestea sunt, de exemplu, modificări ale stării legăturii folosind k-cea mai scurtă cale, dar, din nou, nu există astfel de protocoale care să fie implementate în producție și disponibile pe scară largă pe echipamente.
Mai mult, deoarece cea mai mare parte a capacității nu este accesibilă prin cele mai scurte căi, trebuie să modificăm mai mult decât doar planul de control pentru a selecta toate acele căi (și, apropo, aceasta este semnificativ mai multă stare în planul de control). Mai trebuie să modificăm planul de redirecționare și, de regulă, sunt necesare cel puțin două caracteristici suplimentare. Aceasta este capacitatea de a lua toate deciziile cu privire la redirecționarea pachetelor o singură dată, de exemplu, pe gazdă. De fapt, aceasta este rutarea sursă, uneori în literatura de specialitate despre rețelele de interconectare aceasta se numește decizii de redirecționare totală. Iar rutarea adaptivă este o funcție de care avem nevoie pentru elementele de rețea, care se rezumă, de exemplu, la faptul că selectăm următorul hop pe baza informațiilor despre cea mai mică încărcare din coadă. De exemplu, sunt posibile și alte opțiuni.
Astfel, direcția este interesantă, dar, din păcate, nu o putem aplica chiar acum.
Bine, ne-am stabilit pe topologia logică Clos. Cum îl vom scala? Să vedem cum funcționează și ce se poate face.
Într-o rețea Clos există doi parametri principali pe care îi putem varia cumva și obținem anumite rezultate: radixul elementelor și numărul de niveluri din rețea. Am o diagramă schematică a modului în care ambele afectează dimensiunea. În mod ideal, le combinăm pe amândouă.
Se poate observa că lățimea finală a rețelei Clos este produsul tuturor nivelurilor de comutatoare ale coloanei vertebrale ale razei sudice, câte legături avem în jos, cum se ramifică. Acesta este modul în care mărim dimensiunea rețelei.
În ceea ce privește capacitatea, în special pe comutatoarele ToR, există două opțiuni de scalare. Fie putem, menținând topologia generală, să folosim legături mai rapide, fie putem adăuga mai multe planuri.
Dacă vă uitați la versiunea extinsă a rețelei Clos (în colțul din dreapta jos) și reveniți la această imagine cu rețeaua Clos de mai jos...
... atunci aceasta este exact aceeași topologie, dar pe acest slide este prăbușit mai compact și planurile fabricii sunt suprapuse unele peste altele. Este la fel.
Cum arată scalarea unei rețele Clos în cifre? Aici ofer date despre ce lățime maximă poate fi obținută o rețea, ce număr maxim de rafturi, comutatoare ToR sau comutatoare cu frunză, dacă nu sunt în rafturi, putem obține în funcție de ce radix de comutatoare folosim pentru nivelurile coloanei vertebrale și câte niveluri folosim.
Iată câte rack-uri putem avea, câte servere și aproximativ cât pot consuma toate acestea pe baza a 20 kW per rack. Puțin mai devreme am menționat că ne propunem o dimensiune a clusterului de aproximativ 100 de mii de servere.
Se poate observa că în întreg acest design sunt de interes două opțiuni și jumătate. Există o opțiune cu două straturi de coloane și comutatoare cu 64 de porturi, care este puțin scurtă. Apoi, există opțiuni perfect potrivite pentru comutatoare cu 128 de porturi (cu radix 128) cu două niveluri sau comutatoare cu radix 32 cu trei niveluri. Și în toate cazurile, unde există mai multe radixe și mai multe straturi, puteți face o rețea foarte mare, dar dacă vă uitați la consumul așteptat, de obicei există gigawați. Este posibil să puneți un cablu, dar este puțin probabil să obținem atât de multă electricitate la un loc. Dacă te uiți la statistici și datele publice despre centrele de date, poți găsi foarte puține centre de date cu o capacitate estimată de peste 150 MW. Cele mai mari sunt de obicei campusuri de centre de date, mai multe centre de date mari situate destul de aproape unul de celălalt.
Există un alt parametru important. Dacă vă uitați la coloana din stânga, lățimea de bandă utilizabilă este listată acolo. Este ușor de observat că într-o rețea Clos o parte semnificativă din porturi sunt folosite pentru a conecta comutatoarele între ele. Lățimea de bandă utilizabilă, o bandă utilă, este ceva ce poate fi dat afară, către servere. Desigur, vorbesc despre porturile condiționate și mai ales despre bandă. De regulă, legăturile din rețea sunt mai rapide decât legăturile către servere, dar pe unitatea de lățime de bandă, pe cât de mult le putem trimite către echipamentele noastre de server, există totuși o anumită lățime de bandă în rețea însăși. Și cu cât facem mai multe niveluri, cu atât costul specific al furnizării acestei dungi spre exterior este mai mare.
Mai mult, nici această bandă suplimentară nu este exact aceeași. În timp ce intervalele sunt scurte, putem folosi ceva de genul DAC (cupru cu atașare directă, adică cabluri twinax) sau optică multimodală, care costă bani și mai mult sau mai puțin rezonabili. De îndată ce trecem la intervale mai lungi - de regulă, acestea sunt optice cu un singur mod, iar costul acestei lățimi de bandă suplimentare crește considerabil.
Și din nou, revenind la slide-ul anterior, dacă creăm o rețea Clos fără supraabonament, atunci este ușor să ne uităm la diagramă, să vedem cum este construită rețeaua - adăugând fiecare nivel de comutatoare ale coloanei vertebrale, repetăm întreaga bandă care a fost la fund. Nivel plus - plus aceeași bandă, același număr de porturi pe comutatoare ca și la nivelul anterior și același număr de transceiver. Prin urmare, este foarte de dorit să se minimizeze numărul de niveluri de comutatoare ale coloanei vertebrale.
Pe baza acestei imagini, este clar că vrem cu adevărat să construim pe ceva de genul comutatoarelor cu o rază de 128.
Aici, în principiu, totul este la fel cu ceea ce tocmai am spus; acesta este un slide pentru a fi analizat mai târziu.
Ce opțiuni există pe care le putem alege ca astfel de comutatoare? Este o veste foarte plăcută pentru noi că acum astfel de rețele pot fi construite în sfârșit pe comutatoare cu un singur cip. Și asta este foarte tare, au o mulțime de caracteristici frumoase. De exemplu, nu au aproape nicio structură internă. Aceasta înseamnă că se sparg mai ușor. Se sparg în tot felul de feluri, dar din fericire se sparg complet. În dispozitivele modulare există un număr mare de defecte (foarte neplăcute), când din punctul de vedere al vecinilor și al planului de control pare să funcționeze, dar, de exemplu, o parte din țesătură s-a pierdut și nu funcționează la capacitate maximă. Iar traficul către acesta este echilibrat pe baza faptului că este complet funcțional și ne putem supraîncărca.
Sau, de exemplu, apar probleme cu backplane, deoarece în interiorul dispozitivului modular există și SerDes de mare viteză - este cu adevărat complex în interior. Fie semnele dintre elementele de expediere sunt sincronizate, fie nu sunt sincronizate. În general, orice dispozitiv modular productiv constând dintr-un număr mare de elemente, de regulă, conține aceeași rețea Clos în interiorul său, dar este foarte dificil de diagnosticat. Adesea este dificil chiar și pentru vânzătorul însuși să diagnosticheze.
Și are un număr mare de scenarii de defecțiune în care dispozitivul se degradează, dar nu iese complet din topologie. Deoarece rețeaua noastră este mare, echilibrarea între elemente identice este utilizată în mod activ, rețeaua este foarte regulată, adică o cale pe care totul este în ordine nu diferă de cealaltă cale, este mai profitabil pentru noi să pierdem pur și simplu o parte din dispozitivele din topologie decât să ajungă într-o situație în care unele dintre ele par să funcționeze, dar altele nu.
Următoarea caracteristică plăcută a dispozitivelor cu un singur cip este că evoluează mai bine și mai rapid. De asemenea, tind să aibă o capacitate mai bună. Dacă luăm structurile mari asamblate pe care le avem pe un cerc, atunci capacitatea pe unitate de rack pentru porturi cu aceeași viteză este aproape de două ori mai bună decât cea a dispozitivelor modulare. Dispozitivele construite în jurul unui singur cip sunt considerabil mai ieftine decât cele modulare și consumă mai puțină energie.
Dar, desigur, totul este dintr-un motiv, există și dezavantaje. În primul rând, radixul este aproape întotdeauna mai mic decât cel al dispozitivelor modulare. Dacă putem obține un dispozitiv construit în jurul unui cip cu 128 de porturi, atunci putem obține unul modular cu câteva sute de porturi acum fără probleme.
Aceasta este o dimensiune semnificativ mai mică a tabelelor de redirecționare și, de regulă, tot ceea ce are legătură cu scalabilitatea planului de date. Tampoane superficiale. Și, de regulă, funcționalitate destul de limitată. Dar se dovedește că dacă cunoașteți aceste restricții și aveți grijă la timp să le ocoliți sau pur și simplu să le luați în considerare, atunci acest lucru nu este atât de înfricoșător. Faptul că radixul este mai mic nu mai este o problemă pe dispozitivele cu o radix de 128 care au apărut în sfârșit recent; putem construi în două straturi de țepi. Dar este încă imposibil să construim ceva mai mic de doi care să fie interesant pentru noi. Cu un nivel, se obțin clustere foarte mici. Chiar și designurile și cerințele noastre anterioare le-au depășit.
De fapt, dacă dintr-o dată soluția este undeva pe un prag, mai există o modalitate de a scala. Deoarece ultimul (sau primul), cel mai de jos nivel la care sunt conectate serverele sunt comutatoarele ToR sau comutatoarele frunză, nu suntem obligați să conectăm un rack la acestea. Prin urmare, dacă soluția este scurtă cu aproximativ jumătate, vă puteți gândi să utilizați pur și simplu un comutator cu o rază mare la nivelul inferior și să conectați, de exemplu, două sau trei rafturi într-un singur comutator. Este și aceasta o opțiune, are costurile ei, dar funcționează destul de bine și poate fi o soluție bună atunci când trebuie să ajungeți cam de două ori mai mult.
Pentru a rezuma, construim pe o topologie cu două niveluri de țepi, cu opt straturi din fabrică.
Ce se va întâmpla cu fizica? Calcule foarte simple. Dacă avem două niveluri de coloane, atunci avem doar trei niveluri de comutatoare și ne așteptăm să existe trei segmente de cablu în rețea: de la servere la comutatoare de frunză, la coloana 1, la coloana 2. Opțiunile pe care le putem use are - acestea sunt twinax, multimode, single mode. Și aici trebuie să luăm în considerare ce bandă este disponibilă, cât va costa, care sunt dimensiunile fizice, ce intervale putem acoperi și cum vom face upgrade.
În ceea ce privește costul, totul poate fi aliniat. Twinax-urile sunt semnificativ mai ieftine decât optica activă, mai ieftine decât transceiver-urile multimode, dacă o luați pe zbor de la capăt, ceva mai ieftin decât un port switch de 100 gigabit. Și, vă rugăm să rețineți, costă mai puțin decât optica cu un singur mod, deoarece în zborurile în care este necesar modul unic, în centrele de date din mai multe motive este logic să utilizați CWDM, în timp ce modul unic paralel (PSM) nu este foarte convenabil de lucrat. cu, pachete foarte mari se obțin fibre, iar dacă ne concentrăm pe aceste tehnologii, obținem aproximativ următoarea ierarhie a prețurilor.
Încă o notă: din păcate, nu este foarte posibil să folosiți porturi multimode dezasamblate de la 100 la 4x25. Datorită caracteristicilor de design ale transceiver-urilor SFP28, acesta nu este cu mult mai ieftin decât 28 Gbit QSFP100. Și această dezasamblare pentru multimode nu funcționează foarte bine.
O altă limitare este că, din cauza dimensiunii clusterelor de calcul și a numărului de servere, centrele noastre de date se dovedesc a fi mari din punct de vedere fizic. Aceasta înseamnă că cel puțin un zbor va trebui făcut cu un singur mod. Din nou, din cauza dimensiunii fizice a Pod-urilor, nu va fi posibilă rularea a două trave de twinax (cabluri de cupru).
Ca rezultat, dacă optimizăm pentru preț și luăm în considerare geometria acestui design, obținem un interval de twinax, un interval de multimod și un interval de singlemode folosind CWDM. Acest lucru ia în considerare posibilele căi de upgrade.
Așa arată recent, încotro ne îndreptăm și ce este posibil. Este clar, cel puțin, cum să treceți către SerDes de 50 Gigabit atât pentru multimode, cât și pentru singlemode. Mai mult decât atât, dacă te uiți la ce este în transceiver-urile monomod acum și în viitor pentru 400G, de multe ori chiar și atunci când 50G SerDes ajung din partea electrică, 100 Gbps pe bandă pot merge deja la optică. Prin urmare, este foarte posibil ca în loc să treacă la 50, să existe o tranziție la 100 Gigabit SerDes și 100 Gbps pe bandă, deoarece conform promisiunilor multor furnizori, disponibilitatea lor este așteptată destul de curând. Perioada în care 50G SerDes au fost cele mai rapide, se pare, nu va fi foarte lungă, deoarece primele copii ale 100G SerDes vor fi lansate aproape anul viitor. Și după ceva timp după aceea, probabil că vor merita bani rezonabili.
Încă o nuanță despre alegerea fizicii. În principiu, putem folosi deja porturi de 400 sau 200 Gigabit folosind 50G SerDes. Dar se dovedește că acest lucru nu are prea mult sens, pentru că, așa cum am spus mai devreme, vrem o bază destul de mare pe comutatoare, în limitele rezonabile, desigur. Vrem 128. Și dacă avem o capacitate limitată de cip și creștem viteza legăturii, atunci radixul scade în mod natural, nu există miracole.
Și putem crește capacitatea totală folosind avioane și nu există costuri speciale; putem adăuga numărul de avioane. Iar dacă pierdem radix-ul, va trebui să introducem un nivel suplimentar, așa că în situația actuală, cu capacitatea maximă disponibilă actuală per cip, se dovedește că este mai eficient să folosești porturi de 100 de gigabiți, deoarece acestea îți permit pentru a obține un radix mai mare.
Următoarea întrebare este cum este organizată fizica, dar din punct de vedere al infrastructurii de cablu. Se dovedește că este organizat într-un mod destul de amuzant. Cablajul între comutatoarele de frunze și coloanele de nivel întâi - nu există multe legături acolo, totul este construit relativ simplu. Dar dacă luăm un singur avion, ceea ce se întâmplă în interior este că trebuie să conectăm toți țepii de la primul nivel cu toți țepii de la al doilea nivel.
În plus, de regulă, există câteva dorințe despre cum ar trebui să arate în interiorul centrului de date. De exemplu, ne-am dorit foarte mult să combinăm cablurile într-un pachet și să le tragem astfel încât un panou de corecție de mare densitate să intre în întregime într-un singur panou de corecție, astfel încât să nu existe grădină zoologică în ceea ce privește lungimile. Am reușit să rezolvăm această problemă. Dacă te uiți inițial la topologia logică, poți vedea că planurile sunt independente, fiecare plan poate fi construit pe cont propriu. Dar când adăugăm o astfel de grupare și dorim să glisăm întregul panou de corecție într-un panou de corecție, trebuie să amestecăm diferite planuri în interiorul unui pachet și să introducem o structură intermediară sub formă de conexiuni optice încrucișate pentru a le reambala din modul în care au fost asamblate. pe un segment, în modul în care vor fi colectate pe alt segment. Datorită acestui lucru, obținem o caracteristică frumoasă: toate comutările complexe nu depășesc rafturile. Când trebuie să împletești ceva foarte puternic, „desfășurați avioanele”, așa cum este numit uneori în rețelele Clos, totul este concentrat într-un singur rack. Nu avem foarte dezasamblate, până la legături individuale, comutare între rafturi.
Așa arată din punct de vedere al organizării logice a infrastructurii de cablu. În imaginea din stânga, blocurile multicolore înfățișează blocuri de comutatoare ale coloanei vertebrale de nivel întâi, câte opt bucăți fiecare și patru mănunchiuri de cabluri care vin din ele, care merg și se intersectează cu fasciculele care provin de la blocurile de comutatoare ale coloanei vertebrale-2. .
Pătratele mici indică intersecții. În stânga sus este o defalcare a fiecărei astfel de intersecții, acesta este de fapt un modul de conexiune încrucișată de 512 cu 512 porturi care reambalează cablurile astfel încât să vină complet într-un singur rack, unde există doar un singur plan spine-2. Și în dreapta, o scanare a acestei imagini este puțin mai detaliată în legătură cu mai multe Pod-uri la nivelul coloanei vertebrale-1 și cum este ambalată într-o conexiune încrucișată, cum vine vorba de nivelul coloanei vertebrale-2.
Așa arată. Suportul spine-2 care nu este încă complet asamblat (în stânga) și suportul de legătură încrucișată. Din păcate, nu sunt multe de văzut acolo. Întreaga structură este implementată chiar acum într-unul dintre centrele noastre mari de date care este extins. Aceasta este o lucrare în curs, va arăta mai frumos, va fi completată mai bine.
O întrebare importantă: am ales topologia logică și am construit fizica. Ce se va întâmpla cu avionul de control? Este destul de cunoscut din experiența de operare, există o serie de rapoarte care arată că protocoalele de stare de legătură sunt bune, este o plăcere să lucrez cu ele, dar, din păcate, nu se scalează bine pe o topologie dens conectată. Și există un factor principal care împiedică acest lucru - așa funcționează inundațiile în protocoalele de stare a legăturii. Dacă luați algoritmul de inundare și vă uitați la modul în care este structurată rețeaua noastră, puteți vedea că va exista un fanout foarte mare la fiecare pas și pur și simplu va inunda planul de control cu actualizări. Mai exact, astfel de topologii se amestecă foarte slab cu algoritmul tradițional de inundare în protocoalele de stare a legăturii.
Alegerea este să utilizați BGP. Cum să-l pregătiți corect este descris în RFC 7938 despre utilizarea BGP în centrele de date mari. Ideile de bază sunt simple: numărul minim de prefixe pe gazdă și, în general, numărul minim de prefixe în rețea, utilizați agregarea dacă este posibil și suprimați căutarea de căi. Ne dorim o distribuție foarte atentă, foarte controlată a actualizărilor, ceea ce se numește valley free. Dorim ca actualizările să fie implementate exact o dată pe măsură ce trec prin rețea. Dacă își au originea în partea de jos, se ridică, desfășându-se nu mai mult de o dată. Nu ar trebui să existe zig-zaguri. Zigzagurile sunt foarte rele.
Pentru a face acest lucru, folosim un design suficient de simplu pentru a folosi mecanismele BGP subiacente. Adică folosim eBGP care rulează pe link local, iar sistemele autonome sunt alocate după cum urmează: un sistem autonom pe ToR, un sistem autonom pe întregul bloc de comutatoare spine-1 al unui Pod și un sistem autonom general pe întregul Top de Fabric. Nu este greu să privim și să vedem că chiar și comportamentul normal al BGP ne oferă distribuția actualizărilor pe care o dorim.
Desigur, adresarea și agregarea adreselor trebuie proiectate astfel încât să fie compatibile cu modul în care este construită rutarea, astfel încât să asigure stabilitatea planului de control. Adresarea L3 în transport este legată de topologie, deoarece fără aceasta este imposibil să se realizeze agregare; fără aceasta, adresele individuale se vor strecura în sistemul de rutare. Și încă ceva este că agregarea, din păcate, nu se amestecă foarte bine cu multi-path, pentru că atunci când avem multi-path și avem agregare, totul este în regulă, când întreaga rețea este sănătoasă, nu există eșecuri în ea. Din păcate, de îndată ce apar defecțiuni în rețea și se pierde simetria topologiei, putem ajunge la punctul de la care a fost anunțată unitatea, de unde nu putem merge mai departe până unde trebuie să mergem. Prin urmare, cel mai bine este să agregați acolo unde nu există mai multe căi, în cazul nostru acestea sunt comutatoare ToR.
De fapt, se poate agrega, dar cu grijă. Dacă putem face o dezagregare controlată atunci când apar erori de rețea. Dar aceasta este o sarcină destul de dificilă, chiar ne-am întrebat dacă ar fi posibil să facem acest lucru, dacă ar fi posibil să se adauge automatizări suplimentare și mașini cu stări finite care să declanșeze corect BGP pentru a obține comportamentul dorit. Din păcate, procesarea cazurilor de colț este foarte neevidentă și complexă, iar această sarcină nu este bine rezolvată prin atașarea atașamentelor externe la BGP.
Lucrări foarte interesante în acest sens au fost făcute în cadrul protocolului RIFT, care va fi discutat în următorul raport.
Un alt lucru important este modul în care planurile de date se scalează în topologii dense, unde avem un număr mare de căi alternative. În acest caz, sunt utilizate mai multe structuri de date suplimentare: grupuri ECMP, care la rândul lor descriu grupuri Next Hop.
Într-o rețea care funcționează normal, fără defecțiuni, când urcăm topologia Clos, este suficient să folosim un singur grup, deoarece tot ceea ce nu este local este descris implicit, putem urca. Când mergem de sus în jos spre sud, atunci toate căile nu sunt ECMP, sunt căi cu o singură cale. Totul e bine. Problema este, iar particularitatea topologiei clasice Clos este că, dacă ne uităm la partea de sus a țesăturii, la orice element, există o singură cale către orice element de dedesubt. Dacă apar erori pe această cale, atunci acest element special din partea de sus a fabricii devine invalid tocmai pentru acele prefixe care se află în spatele căii întrerupte. Dar pentru restul este valabil și trebuie să analizăm grupurile ECMP și să introducem un nou stat.
Cum arată scalabilitatea planului de date pe dispozitivele moderne? Dacă facem LPM (cel mai lung prefix potrivire), totul este destul de bine, peste 100k prefixe. Dacă vorbim de grupuri Next Hop, atunci totul este mai rău, 2-4 mii. Dacă vorbim despre un tabel care conține o descriere a Next Hops (sau adiacențele), atunci acesta este undeva de la 16k la 64k. Și asta poate deveni o problemă. Și aici ajungem la o digresiune interesantă: ce s-a întâmplat cu MPLS în centrele de date? În principiu, am vrut să o facem.
Două lucruri s-au întâmplat. Am făcut micro-segmentare pe gazde; nu mai era nevoie să o facem în rețea. Nu a fost foarte bine cu suportul de la diferiți furnizori și cu atât mai mult cu implementările deschise pe cutii albe cu MPLS. Și MPLS, cel puțin implementările sale tradiționale, din păcate, se combină foarte slab cu ECMP. Si de aceea.
Așa arată structura de redirecționare ECMP pentru IP. Un număr mare de prefixe pot folosi același grup și același bloc Next Hops (sau adiacențele, acestea pot fi numite diferit în documentație diferită pentru dispozitive diferite). Ideea este că acesta este descris ca portul de ieșire și la ce să rescrie adresa MAC pentru a ajunge la Next Hop corect. Pentru IP totul pare simplu, puteți folosi un număr foarte mare de prefixe pentru același grup, același bloc Next Hops.
Arhitectura MPLS clasică presupune că, în funcție de interfața de ieșire, eticheta poate fi rescrisă la valori diferite. Prin urmare, trebuie să păstrăm un grup și un bloc Next Hops pentru fiecare etichetă de intrare. Și asta, din păcate, nu se scalează.
Este ușor de observat că în designul nostru aveam nevoie de aproximativ 4000 de comutatoare ToR, lățimea maximă era de 64 de căi ECMP, dacă ne îndepărtăm de la coloana-1 la coloana-2. Abia intrăm într-un singur tabel de grupuri ECMP, dacă dispare un singur prefix cu ToR și nu intrăm deloc în tabelul Next Hops.
Nu totul este fără speranță, deoarece arhitecturi precum Segment Routing implică etichete globale. Formal, ar fi posibil să prăbușim din nou toate aceste blocuri Next Hops. Pentru a face acest lucru, aveți nevoie de o operație de tip wild card: luați o etichetă și rescrieți-o în aceeași fără o anumită valoare. Dar, din păcate, acest lucru nu este foarte prezent în implementările disponibile.
Și, în sfârșit, trebuie să aducem trafic extern în centrul de date. Cum să o facă? Anterior, traficul era introdus în rețeaua Clos de sus. Adică, au existat routere de margine care se conectau la toate dispozitivele de pe partea de sus a fabricii. Această soluție funcționează destul de bine pe dimensiuni mici și medii. Din păcate, pentru a trimite traficul simetric către întreaga rețea în acest fel, trebuie să ajungem simultan la toate elementele Top of fabric, iar când sunt mai mult de o sută de ele, se dovedește că avem nevoie și de un mare radix pe routerele edge. În general, acest lucru costă bani, deoarece routerele edge sunt mai funcționale, porturile de pe ele vor fi mai scumpe, iar designul nu este foarte frumos.
O altă opțiune este să porniți un astfel de trafic de jos. Este ușor de verificat că topologia Clos este construită în așa fel încât traficul care vine de jos, adică din partea ToR, este distribuit uniform între niveluri pe întregul Top of fabric în două iterații, încărcând întreaga rețea. Prin urmare, introducem un tip special de Pod, Edge Pod, care oferă conectivitate externă.
Mai există o opțiune. Asta face Facebook, de exemplu. Ei îl numesc Fabric Aggregator sau HGRID. Se introduce un nivel suplimentar al coloanei vertebrale pentru a conecta mai multe centre de date. Acest design este posibil dacă nu avem funcții suplimentare sau modificări de încapsulare la interfețe. Dacă sunt puncte de contact suplimentare, este dificil. De obicei, există mai multe funcții și un fel de membrană care separă diferite părți ale centrului de date. Nu are rost să facem o astfel de membrană mare, dar dacă este într-adevăr necesară dintr-un anumit motiv, atunci este logic să luăm în considerare posibilitatea de a o îndepărta, făcând-o cât mai largă și transferând-o gazdelor. Acest lucru este făcut, de exemplu, de mulți operatori cloud. Au suprapuneri, încep de la gazde.
Ce oportunități de dezvoltare vedem? În primul rând, îmbunătățirea suportului pentru conducta CI/CD. Vrem să zburăm așa cum testăm și testăm felul în care zburăm. Acest lucru nu funcționează foarte bine, deoarece infrastructura este mare și este imposibil să o dublezi pentru teste. Trebuie să înțelegeți cum să introduceți elemente de testare în infrastructura de producție fără a le abandona.
O instrumentare mai bună și o monitorizare mai bună nu sunt aproape niciodată de prisos. Întreaga întrebare este un echilibru între efort și întoarcere. Dacă îl puteți adăuga cu efort rezonabil, foarte bine.
Sisteme de operare deschise pentru dispozitivele de rețea. Protocoale mai bune și sisteme de rutare mai bune, cum ar fi RIFT. De asemenea, este nevoie de cercetare în ceea ce privește utilizarea unor scheme mai bune de control al congestiei și poate introducerea, cel puțin în unele puncte, a suportului RDMA în cadrul clusterului.
Privind mai departe în viitor, avem nevoie de topologii avansate și, eventual, de rețele care utilizează mai puțină suprasarcină. Dintre lucrurile proaspete, au apărut recent publicații despre tehnologia fabricii pentru HPC Cray Slingshot, care se bazează pe Ethernet de marfă, dar cu opțiunea de a folosi anteturi mult mai scurte. Ca urmare, cheltuielile generale sunt reduse.
Totul trebuie menținut cât se poate de simplu, dar nu mai simplu. Complexitatea este inamicul scalabilității. Simplitatea și structurile regulate sunt prietenii noștri. Dacă poți să o extinzi undeva, fă-o. Și, în general, este grozav să fii implicat acum în tehnologiile de rețea. Se întâmplă o mulțime de lucruri interesante. Mulțumesc.
Sursa: www.habr.com