Razvili smo dizajn mreže centara podataka koji omogućava postavljanje računarskih klastera većih od 100 hiljada servera sa maksimalnom širinom opsega od preko jednog petabajta u sekundi.
Iz izvještaja Dmitrija Afanasjeva naučit ćete o osnovnim principima novog dizajna, topologijama skaliranja, problemima koji se javljaju s tim, mogućnostima za njihovo rješavanje, karakteristikama usmjeravanja i skaliranja funkcija ravni prosljeđivanja modernih mrežnih uređaja u „gusto povezanim“ topologije sa velikim brojem ECMP ruta. Osim toga, Dima je ukratko govorio o organizaciji eksternog povezivanja, fizičkom sloju, kablovskom sistemu i načinima daljeg povećanja kapaciteta.
- Dobar dan svima! Moje ime je Dmitrij Afanasjev, ja sam mrežni arhitekta u Yandexu i prvenstveno dizajniram mreže centara podataka.
Moja priča će biti o ažuriranoj mreži Yandex data centara. To je u velikoj mjeri evolucija dizajna koji smo imali, ali u isto vrijeme postoje i neki novi elementi. Ovo je pregledna prezentacija jer je bilo puno informacija koje je trebalo spakovati u malo vremena. Počećemo odabirom logičke topologije. Zatim će biti pregled kontrolne ravni i problema sa skalabilnosti ravni podataka, izbor šta će se desiti na fizičkom nivou, a mi ćemo pogledati neke karakteristike uređaja. Dotaknimo se malo onoga što se dešava u data centru sa MPLS-om, o čemu smo pričali prije nekog vremena.
Dakle, šta je Yandex u smislu opterećenja i usluga? Yandex je tipičan hiperskaler. Ako gledamo korisnike, prvenstveno obrađujemo zahtjeve korisnika. Također i razne streaming usluge i prijenos podataka, jer imamo i usluge skladištenja. Ako je bliže backendu, tada se tamo pojavljuju infrastrukturna opterećenja i usluge, kao što su skladištenje distribuiranih objekata, replikacija podataka i, naravno, trajni redovi. Jedan od glavnih tipova opterećenja su MapReduce i slični sistemi, obrada toka, mašinsko učenje itd.
Kakva je infrastruktura na kojoj se sve ovo dešava? Opet, mi smo prilično tipičan hiperskaler, iako smo možda malo bliži nižoj hiperskalerskoj strani spektra. Ali mi imamo sve atribute. Koristimo robni hardver i horizontalno skaliranje gdje god je to moguće. Imamo potpuno udruživanje resursa: ne radimo sa pojedinačnim mašinama, pojedinačnim regalima, već ih kombinujemo u veliki skup izmjenjivih resursa s nekim dodatnim uslugama koje se bave planiranjem i dodjelom, te radimo sa cijelim tim pulom.
Dakle, imamo sledeći nivo - operativni sistem na nivou računarskog klastera. Veoma je važno da u potpunosti kontrolišemo tehnološki stack koji koristimo. Kontrolišemo krajnje tačke (hostove), mrežu i softverski stog.
Imamo nekoliko velikih data centara u Rusiji i inostranstvu. Objedinjuje ih okosnica koja koristi MPLS tehnologiju. Naša interna infrastruktura je skoro u potpunosti izgrađena na IPv6, ali pošto moramo da opslužujemo eksterni saobraćaj koji i dalje dolazi uglavnom preko IPv4, moramo nekako da isporučimo zahteve koji dolaze preko IPv4 na frontend servere, a još malo ići na eksterni IPv4- Internet - za na primjer, za indeksiranje.
Posljednjih nekoliko iteracija dizajna mreža podatkovnih centara koristile su višeslojne Clos topologije i samo su L3. Maloprije smo napustili L2 i odahnuli. Konačno, naša infrastruktura uključuje stotine hiljada računarskih (serverskih) instanci. Maksimalna veličina klastera prije nekog vremena bila je oko 10 hiljada servera. Ovo je uglavnom zbog toga kako ti isti operativni sistemi na nivou klastera, raspoređivači, alokacija resursa itd. mogu da rade. Pošto se napredak dogodio na strani infrastrukturnog softvera, ciljna veličina je sada oko 100 hiljada servera u jednom računarskom klasteru, i Imamo zadatak - da budemo u mogućnosti da izgradimo mrežne fabrike koje omogućavaju efikasno udruživanje resursa u takvom klasteru.
Šta želimo od mreže data centara? Prije svega, postoji mnogo jeftinog i prilično ravnomjerno raspoređenog propusnog opsega. Zato što je mreža okosnica preko koje možemo udružiti resurse. Nova ciljna veličina je oko 100 hiljada servera u jednom klasteru.
Također, naravno, želimo skalabilnu i stabilnu kontrolnu ravan, jer na tako velikoj infrastrukturi mnoge glavobolje nastaju čak i iz prosto slučajnih događaja, a ne želimo da nam kontrolna ravan donosi i glavobolje. Istovremeno želimo da minimiziramo stanje u njemu. Što je stanje manje, sve radi bolje i stabilnije i lakše je dijagnosticirati.
Naravno, potrebna nam je automatizacija, jer je takvom infrastrukturom nemoguće upravljati ručno, a to je nemoguće već neko vrijeme. Potrebna nam je operativna podrška što je više moguće i CI/CD podrška u mjeri u kojoj je to moguće.
Sa takvim veličinama podatkovnih centara i klastera, zadatak podrške inkrementalnoj implementaciji i proširenju bez prekida usluge postao je prilično akutan. Ako bi se na klasterima veličine od hiljadu mašina, možda blizu deset hiljada mašina, ipak mogli uvesti kao jedna operacija - odnosno planiramo proširenje infrastrukture, a nekoliko hiljada mašina se dodaje kao jedna operacija, onda klaster veličine sto hiljada mašina ne nastaje odmah ovako, već se gradi u određenom vremenskom periodu. I poželjno je da sve ovo vrijeme ono što je već ispumpano, infrastruktura koja je raspoređena, bude dostupna.
I jedan uslov koji smo imali i ostavili: podrška za multitenancy, odnosno virtuelizaciju ili segmentaciju mreže. Sada to ne treba da radimo na nivou mrežnog tkiva, jer je šardovanje otišlo na hostove, a to nam je učinilo skaliranje veoma lakim. Zahvaljujući IPv6 i velikom adresnom prostoru, nismo morali da koristimo duple adrese u internoj infrastrukturi; svo adresiranje je već bilo jedinstveno. A zahvaljujući činjenici da smo filtriranje i segmentaciju mreže preuzeli na hostove, nema potrebe da kreiramo bilo kakve virtuelne mrežne entitete u mrežama data centara.
Veoma važna stvar je ono što nam ne treba. Ako se neke funkcije mogu ukloniti iz mreže, to znatno olakšava život, a po pravilu proširuje izbor dostupne opreme i softvera, čineći dijagnostiku vrlo jednostavnom.
Dakle, šta je to čega nam ne treba, čega smo mogli da se odreknemo, ne uvek sa radošću u trenutku kada se to dogodilo, ali sa velikim olakšanjem kada se proces završi?
Prije svega, napuštanje L2. Ne treba nam L2, ni pravi ni emulirani. Neiskorišteno uglavnom zbog činjenice da kontrolišemo stog aplikacija. Naše aplikacije su horizontalno skalabilne, rade sa L3 adresiranjem, ne brinu se mnogo da se neka pojedinačna instanca ugasila, jednostavno puste novu, ne treba je ubacivati na staru adresu, jer postoji zaseban nivo otkrivanja usluga i praćenja mašina koje se nalaze u klasteru. Ovaj zadatak ne delegiramo mreži. Zadatak mreže je da dostavi pakete od tačke A do tačke B.
Takođe nemamo situacije da se adrese kreću unutar mreže i to treba pratiti. U mnogim dizajnima ovo je obično potrebno za podršku mobilnosti VM-a. Ne koristimo mobilnost virtuelnih mašina u internoj infrastrukturi velikog Yandexa, i, osim toga, vjerujemo da čak i ako se to učini, to se ne bi trebalo dogoditi uz mrežnu podršku. Ako to zaista treba da se uradi, to treba da se uradi na nivou hosta, i potisne adrese koje mogu da migriraju u preklapanja, kako ne bi dirali ili napravili previše dinamičkih promena u sistemu rutiranja same podloge (transportne mreže) .
Druga tehnologija koju ne koristimo je multicast. Ako želite, mogu vam detaljno reći zašto. Ovo znatno olakšava život, jer ako se neko bavio time i pogledao kako tačno izgleda multicast kontrolna ravnina, u svim instalacijama osim u najjednostavnijim, to je velika glavobolja. I štoviše, teško je pronaći implementaciju otvorenog koda koja dobro funkcionira, na primjer.
Konačno, dizajniramo naše mreže tako da se ne mijenjaju previše. Možemo računati na činjenicu da je protok vanjskih događaja u sistemu rutiranja mali.
Koji problemi nastaju i koja ograničenja moramo uzeti u obzir kada razvijamo mrežu data centara? Cena, naravno. Skalabilnost, nivo do kojeg želimo rasti. Potreba za proširenjem bez zaustavljanja usluge. Propusni opseg, dostupnost. Vidljivost šta se dešava na mreži za nadzorne sisteme, za operativne timove. Podrška za automatizaciju - opet, koliko god je to moguće, budući da se različiti zadaci mogu rješavati na različitim nivoima, uključujući i uvođenje dodatnih slojeva. Pa, ne [moguće] ovisi o dobavljačima. Iako je u različitim historijskim periodima, ovisno o tome koji dio pogledate, ova nezavisnost bila lakše ili teže ostvariva. Ako uzmemo presjek čipova mrežnih uređaja, onda je donedavno bilo vrlo uvjetno govoriti o neovisnosti od proizvođača, ako smo htjeli i čipove visoke propusnosti.
Koju ćemo logičku topologiju koristiti za izgradnju naše mreže? Ovo će biti Clos na više nivoa. Zapravo, u ovom trenutku ne postoje prave alternative. A Clos topologija je prilično dobra, čak i u poređenju sa raznim naprednim topologijama koje su sada više u području akademskog interesa, ako imamo velike radiks prekidače.
Kako je Clos mreža na više nivoa grubo strukturirana i kako se u njoj nazivaju različiti elementi? Pre svega, ruža vetrova, da se orijentišete gde je sever, gde je jug, gde je istok, gde je zapad. Mreže ovog tipa obično grade oni koji imaju veoma veliki promet zapad-istok. Što se ostalih elemenata tiče, na vrhu je virtuelni prekidač sastavljen od manjih prekidača. Ovo je glavna ideja rekurzivne konstrukcije Clos mreža. Uzimamo elemente sa nekom vrstom radiksa i povezujemo ih tako da se ono što dobijemo može smatrati prekidačem sa većim radiksom. Ako vam treba još više, postupak se može ponoviti.
U slučajevima, na primjer, sa dva nivoa Clos, kada je moguće jasno identificirati komponente koje su vertikalne u mom dijagramu, one se obično nazivaju ravnima. Ako bismo napravili Clos sa tri nivoa kičmenih prekidača (svi nisu granični ili ToR prekidači i koji se koriste samo za tranzit), tada bi avioni izgledali složenije; oni na dva nivoa izgledaju upravo ovako. Blok ToR ili lista prekidača i prvi nivo kralježnih prekidača koji su povezani s njima nazivamo Pod. Prekidači za kičmu na nivou kičme-1 na vrhu Pod-a su vrh Pod-a, vrh Pod-a. Prekidači koji se nalaze na vrhu cijele fabrike su gornji sloj fabrike, Vrh tkanine.
Naravno, postavlja se pitanje: Clos mreže su građene već neko vrijeme, a sama ideja uglavnom dolazi iz vremena klasične telefonije, TDM mreža. Možda se pojavilo nešto bolje, možda se nešto bolje može uraditi? Da i ne. Teoretski da, u praksi u bliskoj budućnosti definitivno ne. Budući da postoji niz zanimljivih topologija, neke od njih se čak koriste u proizvodnji, na primjer, Dragonfly se koristi u HPC aplikacijama; Tu su i zanimljive topologije kao što su Xpander, FatClique, Jellyfish. Ako nedavno pogledate izvještaje sa konferencija poput SIGCOMM-a ili NSDI-a, možete pronaći prilično veliki broj radova o alternativnim topologijama koje imaju bolja svojstva (jedna ili ona) od Clos-a.
Ali sve ove topologije imaju jedno zanimljivo svojstvo. To onemogućava njihovu implementaciju u mreže data centara, koje pokušavamo izgraditi na robnom hardveru i koje koštaju prilično razumne novce. U svim ovim alternativnim topologijama, većina propusnog opsega nažalost nije dostupna najkraćim putevima. Stoga odmah gubimo priliku da koristimo tradicionalni upravljački plan.
Teoretski, rješenje problema je poznato. To su, na primjer, modifikacije stanja veze koristeći k-najkraći put, ali, opet, ne postoje takvi protokoli koji bi bili implementirani u produkciji i široko dostupni na opremi.
Štaviše, pošto većina kapaciteta nije dostupna preko najkraćih puteva, moramo modifikovati više od same kontrolne ravni da bismo izabrali sve te puteve (i usput, ovo je znatno više stanja u kontrolnoj ravni). Još uvijek moramo modificirati ravninu prosljeđivanja, a po pravilu su potrebne najmanje dvije dodatne funkcije. Ovo je mogućnost da se sve odluke o prosljeđivanju paketa donose jednokratno, na primjer, na hostu. U stvari, ovo je izvorno rutiranje, ponekad se u literaturi o interkonekcijskim mrežama to naziva odlukama o prosljeđivanju svih odjednom. A prilagodljivo usmjeravanje je funkcija koja nam je potrebna na mrežnim elementima, a koja se svodi, na primjer, na činjenicu da odabiremo sljedeći skok na osnovu informacija o najmanjem opterećenju na redu čekanja. Kao primjer, moguće su i druge opcije.
Dakle, smjer je zanimljiv, ali ga, nažalost, trenutno ne možemo primijeniti.
U redu, odlučili smo se za Clos logičku topologiju. Kako ćemo ga skalirati? Hajde da vidimo kako to funkcioniše i šta se može uraditi.
U Clos mreži postoje dva glavna parametra koja nekako možemo varirati i dobiti određene rezultate: radiks elemenata i broj nivoa u mreži. Imam shematski dijagram kako oboje utječu na veličinu. U idealnom slučaju, kombinujemo oboje.
Vidi se da je konačna širina Clos mreže proizvod svih nivoa kičmenih prekidača južnog radiksa, koliko linkova imamo dole, kako se grana. Ovako mjerimo veličinu mreže.
Što se tiče kapaciteta, posebno na ToR prekidačima, postoje dvije opcije skaliranja. Ili možemo, uz održavanje opće topologije, koristiti brže veze, ili možemo dodati više ravni.
Ako pogledate proširenu verziju Clos mreže (u donjem desnom uglu) i vratite se na ovu sliku sa Clos mrežom ispod...
... onda je ovo potpuno ista topologija, ali na ovom slajdu je kompaktnije skupljena i ravni tvornice su postavljene jedna na drugu. To je isto.
Kako izgleda skaliranje Clos mreže u brojevima? Ovdje dajem podatke o tome koju maksimalnu širinu se mreža može dobiti, koji maksimalan broj rekova, ToR prekidača ili lisnatih prekidača, ako nisu u rackovima, možemo dobiti ovisno o tome koji radix prekidača koristimo za nivoe kičme, i koliko nivoa koristimo.
Evo koliko rekova možemo imati, koliko servera i koliko otprilike sve to može da potroši na osnovu 20 kW po reku. Malo ranije sam spomenuo da ciljamo na veličinu klastera od oko 100 hiljada servera.
Vidi se da su u cijelom ovom dizajnu zanimljive dvije i po opcije. Postoji opcija sa dva sloja spinova i prekidačima sa 64 porta, što je malo manje. Zatim postoje savršeno prikladne opcije za 128-portne (sa radiksom 128) spin prekidače sa dva nivoa, ili prekidače sa radiksom 32 sa tri nivoa. I u svim slučajevima, gdje ima više radiksa i više slojeva, možete napraviti vrlo veliku mrežu, ali ako pogledate očekivanu potrošnju, obično ima gigavata. Moguće je položiti kabl, ali teško da ćemo dobiti toliko struje na jednoj lokaciji. Ako pogledate statistiku i javne podatke o podatkovnim centrima, možete pronaći vrlo malo podatkovnih centara s procijenjenim kapacitetom većim od 150 MW. Veći su obično kampusi podatkovnih centara, nekoliko velikih podatkovnih centara smještenih prilično blizu jedan drugom.
Postoji još jedan važan parametar. Ako pogledate lijevu kolonu, tamo je navedena korisna propusnost. Lako je vidjeti da se u Clos mreži značajan dio portova troši na međusobno povezivanje svičeva. Upotrebljivi propusni opseg, korisna traka, je nešto što se može dati vani, prema serverima. Naravno, govorim o uslovnim portovima i posebno o bendu. Linkovi unutar mreže su po pravilu brži od linkova prema serverima, ali po jedinici propusnog opsega, koliko god možemo poslati na našu serversku opremu, ipak postoji nešto propusnog opsega unutar same mreže. I što više nivoa napravimo, to su veći specifični troškovi za pružanje ove trake napolje.
Štaviše, čak ni ovaj dodatni bend nije potpuno isti. Iako su rasponi kratki, možemo koristiti nešto poput DAC-a (direktno priključivanje bakrenih, odnosno twinax kablova), ili višemodnu optiku, koja košta čak i više-manje razuman novac. Čim pređemo na veće raspone - u pravilu se radi o jednomodnoj optici, a cijena ovog dodatnog propusnog opsega primjetno raste.
I opet, vraćajući se na prethodni slajd, ako kreiramo Clos mrežu bez prekomjerne pretplate, onda je lako pogledati dijagram, vidjeti kako je mreža izgrađena - dodajući svaki nivo kičmenih prekidača, ponavljamo cijelu traku koja je bila na dnu. Plus nivo - plus isti opseg, isti broj portova na prekidačima kao što je bilo na prethodnom nivou i isti broj primopredajnika. Stoga je vrlo poželjno minimizirati broj nivoa prekidača kičme.
Na osnovu ove slike, jasno je da zaista želimo da gradimo nešto poput prekidača sa radiksom od 128.
Ovdje je u principu sve isto kao što sam upravo rekao, ovo je slajd za razmatranje kasnije.
Koje opcije postoje koje možemo izabrati kao takve prekidače? Za nas je vrlo ugodna vijest da se sada takve mreže konačno mogu graditi na prekidačima s jednim čipom. I ovo je jako cool, imaju puno lijepih karakteristika. Na primjer, nemaju gotovo nikakvu unutrašnju strukturu. To znači da se lakše lome. Pune se na razne načine, ali na sreću potpuno se lome. Kod modularnih uređaja postoji veliki broj kvarova (veoma neugodnih), kada se sa stanovišta susjeda i kontrolne ravni čini da radi, ali, na primjer, dio tkanine je izgubljen i ne radi punim kapacitetom. A promet do njega je uravnotežen na osnovu činjenice da je potpuno funkcionalan i da možemo biti preopterećeni.
Ili, na primjer, nastaju problemi sa stražnjom pločom, jer unutar modularnog uređaja postoje i brzi SerDes - unutra je stvarno složen. Znakovi između elemenata za prosljeđivanje su ili sinkronizirani ili nisu sinkronizirani. Općenito, svaki produktivni modularni uređaj koji se sastoji od velikog broja elemenata, u pravilu, sadrži istu Clos mrežu unutar sebe, ali je vrlo teško dijagnosticirati. Često je čak i samom prodavcu teško postaviti dijagnozu.
I ima veliki broj scenarija kvarova u kojima se uređaj degradira, ali ne ispada u potpunosti iz topologije. Pošto je naša mreža velika, aktivno se koristi balansiranje između identičnih elemenata, mreža je vrlo pravilna, odnosno jedan put na kojem je sve u redu se ne razlikuje od drugog puta, isplativije nam je jednostavno izgubiti nešto od uređaja iz topologije nego da dođu u situaciju da neki od njih rade, ali neki ne.
Sljedeća lijepa karakteristika uređaja s jednim čipom je da se razvijaju bolje i brže. Oni takođe imaju veći kapacitet. Ako uzmemo velike sklopljene strukture koje imamo u krugu, tada je kapacitet po jedinici reka za portove iste brzine gotovo dvostruko bolji od modularnih uređaja. Uređaji izgrađeni oko jednog čipa su znatno jeftiniji od modularnih i troše manje energije.
Ali, naravno, sve je to s razlogom, postoje i nedostaci. Prvo, radix je gotovo uvijek manji od onog kod modularnih uređaja. Ako možemo dobiti uređaj izgrađen oko jednog čipa sa 128 portova, onda možemo dobiti modularni sa nekoliko stotina portova sada bez ikakvih problema.
To je primjetno manja veličina prosljeđivanja tabela i, po pravilu, svega što se odnosi na skalabilnost u ravni podataka. Plitki puferi. I, u pravilu, prilično ograničena funkcionalnost. Ali ispostavilo se da ako poznajete ova ograničenja i na vrijeme vodite računa da ih zaobiđete ili jednostavno uzmete u obzir, onda to i nije tako strašno. Činjenica da je radix manji više nije problem na uređajima s radiksom od 128 koji su se nedavno pojavili; možemo ugraditi dva sloja bodlji. Ali još uvijek je nemoguće izgraditi nešto manje od dva što je nama zanimljivo. Sa jednim nivoom dobijaju se veoma mali klasteri. Čak su ih i naši prethodni dizajni i zahtjevi i dalje premašivali.
U stvari, ako je rješenje iznenada na rubu, još uvijek postoji način za skaliranje. Pošto su poslednji (ili prvi), najniži nivo na kome su serveri povezani, ToR prekidači ili lisni prekidači, od nas se ne traži da povezujemo jedan rack na njih. Stoga, ako rješenje padne za otprilike polovicu, možete razmišljati o jednostavnom korištenju prekidača s velikim radiksom na nižem nivou i povezivanju, na primjer, dva ili tri reka u jedan prekidač. Ovo je također opcija, ima svoje troškove, ali radi prilično dobro i može biti dobro rješenje kada trebate dostići otprilike duplo veću veličinu.
Da rezimiramo, gradimo topologiju sa dva nivoa bodlji, sa osam fabričkih slojeva.
Šta će biti sa fizikom? Vrlo jednostavne kalkulacije. Ako imamo dva nivoa spinova, onda imamo samo tri nivoa prekidača, a očekujemo da će u mreži biti tri segmenta kabla: od servera do lisnih prekidača, do kičme 1, do kičme 2. Opcije koje možemo upotreba su - to su twinax, multimode, single mode. I ovdje treba razmotriti koja traka je dostupna, koliko će koštati, koje su fizičke dimenzije, koje raspone možemo pokriti i kako ćemo nadograditi.
Što se tiče troškova, sve se može poravnati. Twinax-ovi su znatno jeftiniji od aktivne optike, jeftiniji od multimodnih primopredajnika, ako ih uzmete po letu od kraja, nešto jeftiniji od 100-gigabitnog switch porta. I, imajte na umu, košta manje od single mode optike, jer na letovima gdje je potreban single mode, u podatkovnim centrima iz više razloga ima smisla koristiti CWDM, dok paralelni single mode (PSM) nije baš zgodan za rad sa, dobijaju se vrlo velika pakovanja vlakana, a ako se fokusiramo na ove tehnologije, dobijamo otprilike sledeću hijerarhiju cena.
Još jedna napomena: nažalost, nije baš moguće koristiti rastavljene 100 do 4x25 multimode portove. Zbog karakteristika dizajna SFP28 primopredajnika, nije mnogo jeftiniji od 28 Gbit QSFP100. I ovo rastavljanje za multimode ne radi baš dobro.
Drugo ograničenje je to što se zbog veličine računarskih klastera i broja servera naši podatkovni centri ispostavljaju kao fizički veliki. To znači da će barem jedan let morati da se obavi sa singlemodom. Opet, zbog fizičke veličine Podova, neće biti moguće pokrenuti dva raspona twinaxa (bakrenih kablova).
Kao rezultat toga, ako optimiziramo za cijenu i uzmemo u obzir geometriju ovog dizajna, dobijamo jedan raspon twinaxa, jedan raspon multimodnog i jedan raspon singlemode koristeći CWDM. Ovo uzima u obzir moguće puteve nadogradnje.
Ovako to izgleda nedavno, kuda idemo i šta je moguće. Jasno je, barem, kako se preći na 50-Gigabit SerDes i za multimode i za singlemode. Štaviše, ako pogledate šta je u single-mode primopredajnicima sada iu budućnosti za 400G, često čak i kada 50G SerDes stignu sa električne strane, 100 Gbps po traci već može ići na optiku. Stoga je sasvim moguće da će umjesto prelaska na 50 doći do prelaska na 100 Gigabit SerDes i 100 Gbps po traci, jer se prema obećanjima mnogih dobavljača njihova dostupnost očekuje vrlo brzo. Period kada su 50G SerDes bili najbrži, čini se, neće biti dugo, jer prve kopije 100G SerDe-a izlaze skoro sljedeće godine. I nakon nekog vremena nakon toga vjerovatno će vrijediti razuman novac.
Još jedna nijansa o izboru fizike. U principu, već možemo koristiti 400 ili 200 Gigabit portova koristeći 50G SerDes. Ali ispostavilo se da to nema mnogo smisla, jer, kao što sam ranije rekao, želimo prilično veliki radiks na prekidačima, u razumnom roku, naravno. Želimo 128. A ako imamo ograničen kapacitet čipa i povećamo brzinu veze, onda se radix prirodno smanjuje, nema čuda.
A avionima možemo povećati ukupan kapacitet i nema posebnih troškova, možemo dodati broj aviona. A ako izgubimo radix, moraćemo da uvedemo dodatni nivo, pa se u trenutnoj situaciji, sa trenutno maksimalnim raspoloživim kapacitetom po čipu, ispostavlja da je efikasnije koristiti 100-gigabitne portove, jer vam oni omogućavaju da dobijete veći radiks.
Sledeće pitanje je kako je fizika organizovana, ali sa stanovišta kablovske infrastrukture. Ispostavilo se da je to organizirano na prilično smiješan način. Kabliranje između lisnatih prekidača i špica prvog nivoa - tu nema mnogo veza, sve je izgrađeno relativno jednostavno. Ali ako uzmemo jednu ravan, ono što se dešava unutra je da moramo povezati sve kičme prvog nivoa sa svim bodljama drugog nivoa.
Plus, po pravilu, postoje želje kako bi to trebalo da izgleda unutar data centra. Na primjer, zaista smo željeli spojiti kablove u snop i povući ih tako da jedan patch panel visoke gustine ide u potpunosti u jedan patch panel, tako da nema zoološkog vrta u smislu dužine. Uspjeli smo riješiti ovaj problem. Ako u početku pogledate logičku topologiju, možete vidjeti da su ravni neovisne, svaka ravan se može izgraditi za sebe. Ali kada dodamo takav paket i želimo da prevučemo ceo patch panel u patch panel, moramo da pomešamo različite ravni unutar jednog paketa i uvedemo međustrukturu u obliku optičkih unakrsnih veza da ih prepakujemo od načina na koji su sastavljeni. na jednom segmentu, kako će se prikupljati na drugom segmentu. Zahvaljujući tome, dobijamo zgodnu osobinu: sve složene komutacije ne idu dalje od rekova. Kada treba nešto jako snažno ispreplesti, „rasklopiti ravni“, kako se to ponekad naziva u Clos mrežama, sve je to koncentrisano unutar jednog stalka. Nemamo visoko rastavljene, sve do pojedinačnih karika, prebacivanje između rekova.
Ovako to izgleda sa stanovišta logične organizacije kablovske infrastrukture. Na slici lijevo, raznobojni blokovi prikazuju blokove kičmenih prekidača prvog nivoa, po osam komada, i četiri snopa kablova koji dolaze iz njih, koji idu i ukrštaju se sa snopovima koji dolaze iz blokova spine-2 prekidača. .
Mali kvadrati označavaju raskrsnice. U gornjem lijevom kutu je pregled svake takve raskrsnice, ovo je zapravo modul za unakrsnu vezu 512 x 512 portova koji ponovo pakuje kablove tako da u potpunosti dolaze u jedan rack, gdje postoji samo jedna spine-2 ravnina. A desno, skeniranje ove slike je malo detaljnije u odnosu na nekoliko Podova na nivou kičme-1, i kako je upakovano u cross-connect, kako dolazi do nivoa kičme-2.
Ovako to izgleda. Stalak za kičmu-2 (levo) i postolje za unakrsno povezivanje. Nažalost, tamo nema mnogo za vidjeti. Cijela ova struktura se trenutno postavlja u jedan od naših velikih centara podataka koji se proširuje. Ovo je rad u toku, izgledat će ljepše, bolje će se popunjavati.
Važno pitanje: izabrali smo logičku topologiju i izgradili fiziku. Šta će se desiti sa kontrolnim avionom? To je prilično dobro poznato iz radnog iskustva, postoji niz izvještaja da su protokoli stanja veze dobri, zadovoljstvo je raditi s njima, ali, nažalost, oni se loše skaliraju na gusto povezanoj topologiji. I postoji jedan glavni faktor koji to sprečava - ovako funkcioniše flooding u protokolima stanja veze. Ako samo uzmete algoritam floodinga i pogledate kako je naša mreža strukturirana, možete vidjeti da će na svakom koraku doći do vrlo velikog rastanka i jednostavno će preplaviti upravljački plan ažuriranjima. Konkretno, takve topologije se vrlo loše miješaju s tradicionalnim algoritmom poplave u protokolima stanja veze.
Izbor je korištenje BGP-a. Kako ga pravilno pripremiti opisano je u RFC 7938 o korištenju BGP-a u velikim podatkovnim centrima. Osnovne ideje su jednostavne: minimalan broj prefiksa po hostu i općenito minimalni broj prefiksa na mreži, korištenje agregacije ako je moguće i suzbijanje traženja puta. Želimo veoma pažljivu, veoma kontrolisanu distribuciju ažuriranja, ono što se zove bez doline. Želimo da se ažuriranja implementiraju tačno jednom kada prođu kroz mrežu. Ako potiču od dna, idu gore, ne otvarajući se više od jednom. Ne bi trebalo biti cik-cak. Zigzagovi su veoma loši.
Da bismo to učinili, koristimo dizajn koji je dovoljno jednostavan da koristi osnovne BGP mehanizme. Odnosno, koristimo eBGP koji radi na lokalnom linku, a autonomni sistemi su dodijeljeni na sljedeći način: autonomni sistem na ToR, autonomni sistem na cijelom bloku spine-1 prekidača jednog Poda i opći autonomni sistem na cijelom vrhu of Fabric. Nije teško pogledati i vidjeti da nam čak i normalno ponašanje BGP-a daje distribuciju ažuriranja koju želimo.
Naravno, adresiranje i agregiranje adresa moraju biti dizajnirani tako da budu kompatibilni sa načinom na koji je rutiranje izgrađeno, tako da osigurava stabilnost upravljačke ravni. L3 adresiranje u transportu je vezano za topologiju, jer bez toga je nemoguće postići agregaciju, bez toga će se pojedinačne adrese uvući u sistem rutiranja. I jos jedna stvar je da se agregacija, nazalost, ne mijesa najbolje sa multi-path, jer kada imamo multi-path i imamo agregaciju, sve je u redu, kada je cijela mreza zdrava, nema kvarova u njoj. Nažalost, čim se pojave kvarovi u mreži i izgubi simetrija topologije, možemo doći do tačke sa koje je jedinica najavljena, sa koje ne možemo ići dalje tamo gde treba. Stoga je najbolje agregirati tamo gdje više nema više putanja, u našem slučaju to su ToR prekidači.
U stvari, moguće je agregirati, ali pažljivo. Ako možemo da izvršimo kontrolisano razdvajanje kada dođe do kvarova na mreži. Ali ovo je prilično težak zadatak, čak smo se pitali da li bi to bilo moguće učiniti, da li je moguće dodati dodatnu automatizaciju i automate konačnih stanja koji bi ispravno izbacili BGP da bi dobili željeno ponašanje. Nažalost, obrada kutnih kućišta je vrlo neočigledna i složena, a ovaj zadatak nije dobro riješen pričvršćivanjem eksternih priloga na BGP.
U okviru RIFT protokola urađen je veoma interesantan posao u ovom pogledu, o čemu će biti reči u narednom izveštaju.
Još jedna važna stvar je kako se ravni podataka skaliraju u gustim topologijama, gdje imamo veliki broj alternativnih puteva. U ovom slučaju koristi se nekoliko dodatnih struktura podataka: ECMP grupe, koje zauzvrat opisuju sljedeće hop grupe.
U mreži koja normalno radi, bez kvarova, kada idemo gore Clos topologijom, dovoljno je koristiti samo jednu grupu, jer sve što nije lokalno je opisano po defaultu, možemo ići gore. Kada idemo od vrha do dna prema jugu, onda sve staze nisu ECMP, one su jednostruke staze. Sve je uredu. Problem je, a posebnost klasične Clos topologije je da ako pogledamo vrh tkanine, bilo koji element, postoji samo jedan put do bilo kojeg elementa ispod. Ako se kvarovi dogode na ovoj stazi, tada ovaj određeni element na vrhu tvornice postaje nevažeći upravo za one prefikse koji se nalaze iza prekinute putanje. Ali za ostalo vrijedi, i moramo raščlaniti ECMP grupe i uvesti novo stanje.
Kako izgleda skalabilnost u podatkovnoj ravni na modernim uređajima? Ako radimo LPM (najduži prefiks meč), sve je sasvim dobro, preko 100k prefiksa. Ako govorimo o Next Hop grupama, onda je sve gore, 2-4 hiljade. Ako govorimo o tablici koja sadrži opis Next Hops (ili susjedstva), onda je to negdje od 16k do 64k. I to može postati problem. I tu dolazimo do zanimljive digresije: šta se dogodilo sa MPLS-om u data centrima? U principu, htjeli smo to učiniti.
Desile su se dvije stvari. Napravili smo mikro-segmentaciju na hostovima; više nismo trebali to raditi na mreži. Nije bilo baš dobro s podrškom različitih proizvođača, a još više s otvorenim implementacijama na bijelim kutijama s MPLS-om. A MPLS, barem njegove tradicionalne implementacije, nažalost, vrlo se loše kombinira sa ECMP-om. I zato.
Ovako izgleda ECMP struktura prosljeđivanja za IP. Veliki broj prefiksa može koristiti istu grupu i isti blok Next Hops (ili susjedstva, ovo se može drugačije zvati u različitoj dokumentaciji za različite uređaje). Poenta je da se ovo opisuje kao odlazni port i na šta treba prepisati MAC adresu da bi se došlo do ispravnog Next Hop-a. Za IP sve izgleda jednostavno, možete koristiti jako veliki broj prefiksa za istu grupu, isti blok Next Hops.
Klasična MPLS arhitektura implicira da, u zavisnosti od izlaznog interfejsa, oznaka može biti prepisana na različite vrednosti. Stoga moramo zadržati grupu i blok Next Hops za svaku ulaznu oznaku. A ovo, nažalost, nije u skali.
Lako je vidjeti da nam je u našem dizajnu bilo potrebno oko 4000 ToR prekidača, maksimalna širina je bila 64 ECMP putanje, ako se udaljimo od kičme-1 prema kralježnici-2. Jedva ulazimo u jednu tabelu ECMP grupa, ako nestane samo jedan prefiks s ToR, a uopće ne uđemo u tablicu Next Hops.
Nije sve beznadežno, jer arhitekture poput Segment Routing uključuju globalne oznake. Formalno, bilo bi moguće ponovo srušiti sve ove blokove Next Hops. Da biste to učinili, potrebna vam je operacija tipa wild card: uzmite oznaku i prepišite je na istu bez određene vrijednosti. Ali, nažalost, to nije previše prisutno u dostupnim implementacijama.
I na kraju, moramo dovesti eksterni saobraćaj u data centar. Kako uraditi? Ranije je saobraćaj u Clos mrežu uveden odozgo. To jest, postojali su rubni usmjerivači koji su se povezivali sa svim uređajima na vrhu tkanine. Ovo rješenje radi prilično dobro na malim i srednjim veličinama. Nažalost, da bismo na ovaj način simetrično slali promet na cijelu mrežu, potrebno je istovremeno doći do svih elemenata Top tkanine, a kada ih ima više od stotinu ispada da nam je potreban i veliki radix na rubnim ruterima. Općenito, ovo košta, jer su rubni ruteri funkcionalniji, portovi na njima će biti skuplji, a dizajn nije baš lijep.
Druga opcija je pokretanje takvog prometa odozdo. Lako je provjeriti da je Clos topologija izgrađena na način da se promet koji dolazi odozdo, odnosno sa strane ToR-a, ravnomjerno raspoređuje među nivoima kroz cijeli Top tkanine u dvije iteracije, učitavajući cijelu mrežu. Stoga uvodimo poseban tip Poda, Edge Pod, koji pruža eksternu povezanost.
Postoji još jedna opcija. To, na primjer, radi Facebook. Zovu ga Fabric Aggregator ili HGRID. Uvodi se dodatni nivo kičme za povezivanje više data centara. Ovaj dizajn je moguć ako nemamo dodatne funkcije ili promjene enkapsulacije na sučeljima. Ako su to dodatne dodirne tačke, teško je. Obično postoji više funkcija i neka vrsta membrane koja razdvaja različite dijelove podatkovnog centra. Nema smisla praviti takvu membranu velikom, ali ako je iz nekog razloga zaista potrebna, onda ima smisla razmotriti mogućnost da je oduzmemo, učinimo što širom i prenesemo na domaćine. To rade, na primjer, mnogi operateri u oblaku. Imaju preklapanja, kreću od domaćina.
Koje razvojne mogućnosti vidimo? Prije svega, poboljšanje podrške za CI/CD cevovod. Želimo da letimo na način na koji testiramo i testiramo način na koji letimo. Ovo ne ide baš najbolje, jer je infrastruktura velika i nemoguće ju je duplirati za testove. Morate razumjeti kako uvesti elemente za testiranje u proizvodnu infrastrukturu, a da ih ne ispustite.
Bolja instrumentacija i bolji nadzor gotovo nikada nisu suvišni. Čitavo pitanje je balans truda i povrata. Ako možete to dodati uz razuman trud, vrlo dobro.
Otvoreni operativni sistemi za mrežne uređaje. Bolji protokoli i bolji sistemi rutiranja, kao što je RIFT. Takođe je potrebno istraživanje upotrebe boljih šema kontrole zagušenja i možda uvođenja, barem u nekim tačkama, RDMA podrške unutar klastera.
Gledajući dalje u budućnost, potrebne su nam napredne topologije i moguće mreže koje koriste manje opterećenja. Od svježih stvari, nedavno su bile objave o tehnologiji tkanine za HPC Cray Slingshot, koja je bazirana na robnom Ethernetu, ali s mogućnošću korištenja mnogo kraćih zaglavlja. Kao rezultat toga, režijski troškovi su smanjeni.
Sve treba biti što jednostavnije, ali ne jednostavnije. Složenost je neprijatelj skalabilnosti. Jednostavnost i pravilne strukture su naši prijatelji. Ako možete negdje skalirati, učinite to. I općenito, sjajno je sada se baviti mrežnim tehnologijama. Mnogo se zanimljivih stvari dešava. Hvala ti.
izvor: www.habr.com