Razvili smo dizajn mreže podatkovnog centra koji omogućuje implementaciju računalnih klastera većih od 100 tisuća poslužitelja s vršnom propusnošću od preko jednog petabajta u sekundi.
Iz izvješća Dmitrija Afanasyeva saznat ćete o osnovnim načelima novog dizajna, topologijama skaliranja, problemima koji se s time javljaju, opcijama za njihovo rješavanje, značajkama usmjeravanja i skaliranja funkcija ravnine prosljeđivanja modernih mrežnih uređaja u "gusto povezanim" topologije s velikim brojem ECMP ruta. Osim toga, Dima je ukratko govorio o organizaciji vanjskog povezivanja, fizičkom sloju, sustavu kabliranja i načinima daljnjeg povećanja kapaciteta.
- Dobar dan svima! Zovem se Dmitry Afanasyev, mrežni sam arhitekt u Yandexu i prvenstveno projektiram mreže podatkovnih centara.
Moja će priča biti o ažuriranoj mreži Yandex podatkovnih centara. To je u velikoj mjeri evolucija dizajna koji smo imali, ali u isto vrijeme postoje neki novi elementi. Ovo je pregledna prezentacija jer je bilo puno informacija koje je trebalo upakirati u malo vremena. Počet ćemo odabirom logičke topologije. Zatim će biti pregled kontrolne ravnine i problema sa skalabilnošću podatkovne ravnine, izbor što će se događati na fizičkoj razini, a osvrnut ćemo se i na neke značajke uređaja. Dotaknimo se malo onoga što se događa u podatkovnom centru s MPLS-om, o čemu smo govorili prije nekog vremena.
Dakle, što 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 pohrane. Ako je bliže pozadini, tamo se pojavljuju infrastrukturna opterećenja i usluge, kao što je pohrana distribuiranih objekata, replikacija podataka i, naravno, trajni redovi čekanja. Jedna od glavnih vrsta radnih opterećenja je MapReduce i slični sustavi, obrada toka, strojno učenje itd.
Kakva je infrastruktura na kojoj se sve ovo događa? Opet, mi smo prilično tipični hiperskaler, iako smo možda malo bliži manje hiperskalerskoj strani spektra. Ali imamo sve atribute. Gdje god je to moguće, koristimo uobičajeni hardver i horizontalno skaliranje. Imamo potpuno udruživanje resursa: ne radimo s pojedinačnim strojevima, pojedinačnim regalima, već ih kombiniramo u veliki skup izmjenjivih resursa s nekim dodatnim uslugama koje se bave planiranjem i raspodjelom, te radimo s cijelim tim skupom.
Dakle, imamo sljedeću razinu - operativni sustav na razini računalnog klastera. Vrlo je važno da u potpunosti kontroliramo tehnologiju koju koristimo. Kontroliramo krajnje točke (hostove), mrežu i softverski skup.
Imamo nekoliko velikih podatkovnih centara u Rusiji i inozemstvu. Ujedinjeni su okosnicom koja koristi MPLS tehnologiju. Naša interna infrastruktura gotovo je u potpunosti izgrađena na IPv6, ali budući da moramo opsluživati vanjski promet koji još uvijek dolazi uglavnom preko IPv4, moramo nekako isporučiti zahtjeve koji dolaze preko IPv4 do frontend poslužitelja, a malo više ići na vanjski IPv4- Internet - za na primjer, za indeksiranje.
Posljednjih nekoliko iteracija dizajna mreže podatkovnih centara koristilo je višeslojne Clos topologije i samo su L3. Maloprije smo napustili L2 i odahnuli. Konačno, naša infrastruktura uključuje stotine tisuća računalnih (poslužiteljskih) instanci. Maksimalna veličina klastera prije nekog vremena bila je oko 10 tisuća poslužitelja. To je uglavnom zbog načina na koji ti isti operativni sustavi na razini klastera, planeri, raspodjela resursa itd. mogu funkcionirati. Budući da se napredak dogodio na strani infrastrukturnog softvera, ciljna veličina je sada oko 100 tisuća poslužitelja u jednom računalnom klasteru, a Imamo zadatak - biti u stanju izgraditi mrežne tvornice koje omogućuju učinkovito udruživanje resursa u takvom klasteru.
Što želimo od mreže podatkovnog centra? Prije svega, postoji mnogo jeftine i prilično ravnomjerno raspoređene propusnosti. Jer mreža je okosnica preko koje možemo udružiti resurse. Nova ciljna veličina je oko 100 tisuća poslužitelja u jednom klasteru.
Također, naravno, želimo skalabilnu i stabilnu kontrolnu razinu, jer na tako velikoj infrastrukturi puno glavobolja nastaje čak i zbog jednostavno slučajnih događaja, a ne želimo da nam i kontrolna razina donosi glavobolje. Istovremeno želimo minimizirati stanje u njemu. Što je stanje manje, to sve bolje i stabilnije funkcionira, te se lakše dijagnosticira.
Naravno, potrebna nam je automatizacija, jer je takvom infrastrukturom nemoguće upravljati ručno, i 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 onoj mjeri u kojoj se može pružiti.
S takvim veličinama podatkovnih centara i klastera, zadatak podrške inkrementalne implementacije i širenja bez prekida usluge postao je prilično akutan. Ako bi se na klasterima veličine od tisuću strojeva, možda blizu deset tisuća strojeva, oni još uvijek mogli razviti kao jedna operacija - odnosno, planiramo proširenje infrastrukture, a nekoliko tisuća strojeva se dodaje kao jedna operacija, tada klaster veličine stotinu tisuća strojeva ne nastaje odmah ovako, on se gradi tijekom određenog vremenskog razdoblja. I poželjno je da cijelo to vrijeme bude dostupno ono što je već ispumpano, infrastruktura koja je postavljena.
I jedan zahtjev koji smo imali i ostao: podrška za multitenancy, odnosno virtualizaciju ili segmentaciju mreže. Sada to ne trebamo raditi na razini mrežne strukture jer je dijeljenje otišlo na hostove, a to nam je skaliranje učinilo vrlo lakim. Zahvaljujući IPv6 i velikom adresnom prostoru, nismo morali koristiti duplicirane adrese u internoj infrastrukturi; sve su adrese već bile jedinstvene. A zahvaljujući činjenici da smo prenijeli filtriranje i mrežnu segmentaciju na hostove, ne moramo stvarati nikakve virtualne mrežne entitete u mrežama podatkovnih centara.
Vrlo važna stvar je ono što nam ne treba. Ako se neke funkcije mogu ukloniti iz mreže, to znatno olakšava život i, u pravilu, proširuje izbor dostupne opreme i softvera, čineći dijagnostiku vrlo jednostavnom.
Dakle, što je to što nam ne treba, čega smo se mogli odreći, ne uvijek s radošću u trenutku kada se to dogodilo, ali s velikim olakšanjem kada je proces završen?
Prije svega, napuštanje L2. Ne treba nam L2, ni pravi ni emulirani. Neiskorišten uglavnom zbog činjenice da kontroliramo hrpu aplikacija. Naše aplikacije su horizontalno skalabilne, rade s L3 adresiranjem, ne brinu se jako da je neka pojedinačna instanca nestala, jednostavno izbace novu, ne treba je izbaciti na staru adresu, jer postoji odvojena razina usluge otkrivanja i praćenja strojeva smještenih u klasteru. Ovaj zadatak ne delegiramo na mrežu. Posao mreže je isporuka paketa od točke A do točke B.
Također nemamo situacija da se adrese pomiču unutar mreže i to treba pratiti. U mnogim dizajnima to je obično potrebno za podršku mobilnosti VM-a. Ne koristimo mobilnost virtualnih strojeva u unutarnjoj infrastrukturi velikog Yandexa, a štoviše, vjerujemo da čak i ako se to učini, to se ne bi trebalo dogoditi s mrežnom podrškom. Ako se to doista mora učiniti, to treba učiniti na razini glavnog računala i gurnuti adrese koje mogu migrirati u preklapanja, kako ne bi dirala ili napravila previše dinamičkih promjena u sustavu usmjeravanja same podloge (transportne mreže) .
Još jedna tehnologija koju ne koristimo je multicast. Ako želite, mogu vam detaljno reći zašto. To znatno olakšava život, jer ako se netko bavio time i pogledao kako točno izgleda multicast control plane, u svim osim najjednostavnijim instalacijama, to je velika glavobolja. Štoviše, teško je pronaći implementaciju otvorenog koda koja dobro funkcionira, na primjer.
Konačno, dizajniramo svoje mreže tako da se ne mijenjaju previše. Možemo računati na činjenicu da je protok vanjskih događaja u sustavu usmjeravanja mali.
Koji problemi nastaju i koja se ograničenja moraju uzeti u obzir kada razvijamo mrežu podatkovnog centra? Trošak, naravno. Skalabilnost, razina do koje želimo rasti. Potreba za proširenjem bez zaustavljanja usluge. Propusnost, dostupnost. Vidljivost onoga što se događa na mreži za nadzorne sustave, za operativne timove. Podrška automatizaciji - opet, koliko god je to moguće, budući da se različiti zadaci mogu riješiti na različitim razinama, uključujući uvođenje dodatnih slojeva. Pa, [možda] ne ovisi o dobavljačima. Iako je u različitim povijesnim razdobljima, ovisno o tome koji dio gledate, tu samostalnost bilo lakše ili teže postići. Ako uzmemo presjek čipova mrežnih uređaja, onda je donedavno bilo vrlo uvjetno govoriti o neovisnosti od dobavljač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 razina. Zapravo, u ovom trenutku nema prave alternative. A Closova topologija je prilično dobra, čak i u usporedbi s raznim naprednim topologijama koje su sada više u području akademskog interesa, ako imamo velike radix prekidače.
Kako je višerazinska Clos mreža grubo strukturirana i kako se zovu različiti elementi u njoj? Prije svega ruža vjetrova, da se orijentišete gdje je sjever, gdje jug, gdje istok, gdje zapad. Mreže ovog tipa obično grade oni koji imaju vrlo velik promet zapad-istok. Što se ostalih elemenata tiče, na vrhu je virtualni prekidač sastavljen od manjih prekidača. Ovo je glavna ideja rekurzivne konstrukcije Closovih mreža. Uzimamo elemente s nekom vrstom radixa i povezujemo ih tako da ono što dobijemo možemo smatrati prekidačem s većim radixom. Ako je potrebno još više, postupak se može ponoviti.
U slučajevima, na primjer, s dvorazinskim Closom, kada je moguće jasno identificirati komponente koje su vertikalne u mom dijagramu, one se obično nazivaju ravninama. Kad bismo izgradili Clos s tri razine spine prekidača (svi nisu granični ili ToR prekidači i koji se koriste samo za tranzit), tada bi avioni izgledali složenije; dvorazinski izgledaju točno ovako. Blok ToR-a ili lisnih prekidača i kralježničkih prekidača prve razine koji su s njima povezani zovemo Pod. Spine prekidači razine spine-1 na vrhu Poda su vrh Poda, vrh Poda. Prekidači koji se nalaze na vrhu cijele tvornice su gornji sloj tvornice, Top of fabric.
Naravno, postavlja se pitanje: Clos mreže se grade već neko vrijeme, sama ideja uglavnom dolazi iz vremena klasične telefonije, TDM mreža. Možda se nešto bolje pojavilo, možda se nešto može učiniti bolje? 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šća na konferencijama kao što su SIGCOMM ili NSDI, možete pronaći prilično velik broj radova o alternativnim topologijama koje imaju bolja svojstva (jedna ili ona) od Closa.
Ali sve ove topologije imaju jedno zanimljivo svojstvo. Onemogućuje njihovu implementaciju u mrežama podatkovnih centara, koje pokušavamo izgraditi na standardnom hardveru i koji koštaju prilično razumne novce. U svim ovim alternativnim topologijama većina propusnosti nažalost nije dostupna najkraćim putovima. Stoga odmah gubimo mogućnost korištenja tradicionalne kontrolne ravnine.
Teoretski, rješenje problema je poznato. To su, primjerice, modifikacije stanja linka pomoću k-najkraćeg puta, ali, opet, ne postoje takvi protokoli koji bi bili implementirani u produkciji i široko dostupni na opremi.
Štoviše, budući da većina kapaciteta nije dostupna najkraćim putovima, moramo modificirati više od same kontrolne ravnine da odaberemo sve te staze (i usput, ovo je znatno više stanja u kontrolnoj ravnini). Još uvijek trebamo modificirati ravninu prosljeđivanja i, u pravilu, potrebne su najmanje dvije dodatne značajke. To je mogućnost donošenja svih odluka o prosljeđivanju paketa jednokratno, na primjer, na hostu. Zapravo, ovo je izvorno usmjeravanje, ponekad se u literaturi o mrežama međusobnog povezivanja to naziva odlukama o prosljeđivanju svih odjednom. A adaptivno 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 temelju informacija o najmanjem opterećenju reda čekanja. Na primjer, moguće su i druge opcije.
Dakle, smjer je zanimljiv, ali, nažalost, ne možemo ga sada primijeniti.
U redu, odlučili smo se za Closovu logičku topologiju. Kako ćemo to skalirati? Pogledajmo kako funkcionira i što se može učiniti.
U Clos mreži postoje dva glavna parametra koja možemo nekako mijenjati i dobiti određene rezultate: radiks elemenata i broj razina u mreži. Imam shematski dijagram kako oba utječu na veličinu. U idealnom slučaju, kombiniramo oboje.
Može se vidjeti da je konačna širina Closove mreže produkt svih razina sklopki kralježnice južnog radiksa, koliko veza imamo dolje, kako se ona grana. Ovako skaliramo veličinu mreže.
Što se tiče kapaciteta, posebno na ToR preklopnicima, postoje dvije mogućnosti skaliranja. Ili možemo, zadržavajući opću topologiju, koristiti brže veze ili možemo dodati više ravnina.
Ako pogledate proširenu verziju Clos mreže (u donjem desnom kutu) i vratite se na ovu sliku s Clos mrežom ispod...
... onda je ovo potpuno ista topologija, ali na ovom slajdu je kompaktnije sažeta i ravnine tvornice su postavljene jedna na drugu. To je isto.
Kako skaliranje Clos mreže izgleda u brojkama? Ovdje dajem podatke o tome koja se maksimalna širina mreže može dobiti, koji maksimalni broj rakova, ToR preklopnika ili lisnih preklopnika, ako nisu u regalima, možemo dobiti ovisno o tome koji radiks preklopnika koristimo za kralježničke razine, i koliko razina koristimo.
Evo koliko rakova možemo imati, koliko poslužitelja i koliko otprilike sve to može potrošiti na bazi 20 kW po rack-u. Malo prije sam spomenuo da ciljamo na veličinu klastera od oko 100 tisuća poslužitelja.
Vidi se da su u cijelom ovom dizajnu od interesa dvije i pol opcije. Postoji opcija s dva sloja kralježaka i sklopkama sa 64 priključka, što malo zaostaje. Zatim postoje savršeno prilagođene opcije za sklopke sa 128 ulaza (s radix 128) s dvije razine ili sklopke s radix 32 s tri razine. I u svim slučajevima, gdje ima više radixa i više slojeva, možete napraviti vrlo veliku mrežu, ali ako pogledate očekivanu potrošnju, obično postoje gigavati. Moguće je postaviti kabel, ali teško da ćemo dobiti toliko struje na jednom mjestu. 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 drugome.
Postoji još jedan važan parametar. Ako pogledate lijevi stupac, ondje je navedena korisna propusnost. Lako je vidjeti da se u Clos mreži značajan dio portova koristi za međusobno povezivanje preklopnika. Upotrebljiva propusnost, korisna traka, nešto je što se može dati vani, prema poslužiteljima. Naravno, govorim o uvjetnim portovima i konkretno o bendu. Linkovi unutar mreže su u pravilu brži od linkova prema poslužiteljima, ali po jedinici propusnosti, koliko god je možemo poslati prema našoj poslužiteljskoj opremi, ipak postoji nešto propusnosti unutar same mreže. I što više razina napravimo, veći su specifični troškovi pružanja ove trake prema van.
Štoviše, ni ovaj dodatni pojas nije potpuno isti. Dok su rasponi mali, možemo koristiti nešto poput DAC-a (direct attach copper, odnosno twinax kabeli), ili multimodnu optiku, koja košta čak više-manje razumne novce. Čim prijeđemo na veće raspone - u pravilu su to jednomodne optike, a trošak ove dodatne širine pojasa značajno raste.
I opet, vraćajući se na prethodni slajd, ako stvorimo Clos mrežu bez prekomjerne pretplate, onda je lako pogledati dijagram, vidjeti kako je mreža izgrađena - dodavanjem svake razine kralježničkih prekidača, ponavljamo cijelu traku koja je bila na dno. Plus razina - plus isti pojas, isti broj portova na preklopnicima kao što je bilo na prethodnoj razini i isti broj primopredajnika. Stoga je vrlo poželjno minimizirati broj razina prekidača kralježnice.
Na temelju ove slike jasno je da stvarno želimo izgraditi nešto poput prekidača s radiksom 128.
Ovdje je, u principu, sve isto kao što sam upravo rekao; ovo je slajd za razmatranje kasnije.
Koje mogućnosti možemo odabrati kao takve prekidače? Za nas je vrlo ugodna vijest da se sada takve mreže konačno mogu graditi na preklopnicima s jednim čipom. I ovo je jako cool, imaju puno lijepih značajki. Na primjer, nemaju gotovo nikakvu unutarnju strukturu. To znači da se lakše lome. Lome se na svakakve načine, ali na svu sreću puknu skroz. U modularnim uređajima postoji veliki broj grešaka (vrlo neugodnih), kada se sa stajališta susjeda i upravljačke ravnine čini da radi, ali je, na primjer, dio tkanine izgubljen i ne radi u punom kapacitetu. I promet do njega je uravnotežen na temelju činjenice da je potpuno funkcionalan, a možemo se preopteretiti.
Ili, na primjer, problemi nastaju s stražnjom pločom, jer unutar modularnog uređaja postoje i SerDes velike brzine - iznutra je stvarno složeno. Ili su znakovi između elemenata za prosljeđivanje 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 prodavaču teško dijagnosticirati.
I ima veliki broj scenarija kvara u kojima uređaj degradira, ali ne ispada u potpunosti iz topologije. Budući da je naša mreža velika, aktivno se koristi balansiranje između identičnih elemenata, mreža je vrlo pravilna, odnosno jedna staza na kojoj je sve u redu ne razlikuje se od druge staze, isplativije nam je jednostavno izgubiti dio uređaja iz topologije nego da dođemo u situaciju da neki od njih rade, ali neki ne rade.
Sljedeća lijepa značajka uređaja s jednim čipom je da se razvijaju bolje i brže. Oni također imaju veći kapacitet. Ako uzmemo velike sastavljene strukture koje imamo na krugu, tada je kapacitet po reck jedinici za portove iste brzine gotovo dvostruko bolji od modularnih uređaja. Uređaji izgrađeni oko jednog čipa osjetno su jeftiniji od modularnih i troše manje energije.
Ali, naravno, sve je to s razlogom, postoje i nedostaci. Prvo, radix je gotovo uvijek manji nego kod modularnih uređaja. Ako možemo dobiti uređaj izgrađen oko jednog čipa sa 128 priključaka, tada možemo dobiti modularni uređaj s nekoliko stotina priključaka sada bez ikakvih problema.
Riječ je o osjetno manjoj veličini tablica prosljeđivanja i, u pravilu, svega što se tiče skalabilnosti podatkovne ravnine. Plitki odbojnici. I, u pravilu, prilično ograničena funkcionalnost. Ali ispada da ako poznajete ova ograničenja i na vrijeme se pobrinete da ih zaobiđete ili jednostavno uzmete u obzir, onda to i nije tako strašno. To što je radix manji više nije problem na uređajima s radixom 128 koji su se konačno pojavili nedavno; možemo ugraditi dva sloja spinova. Ali još uvijek je nemoguće izgraditi nešto manje od dva što je nama zanimljivo. S jednom razinom dobivaju se vrlo male grozdove. Čak su ih i naši prethodni dizajni i zahtjevi premašivali.
Zapravo, ako je iznenada rješenje negdje na rubu, još uvijek postoji način da se poveća. Budući da su posljednja (ili prva), najniža razina na koju se spajaju poslužitelji ToR preklopnici ili leaf preklopnici, nismo obavezni na njih spojiti jedan rack. Stoga, ako rješenje zaostaje za otprilike polovicu, možete razmisliti o jednostavnoj upotrebi prekidača s velikim radixom na nižoj razini i povezivanju, na primjer, dva ili tri stalka 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 doseći otprilike dvostruko veću veličinu.
Ukratko, gradimo na topologiji s dvije razine kralježaka, s osam tvorničkih slojeva.
Što će biti s fizikom? Vrlo jednostavna kalkulacija. Ako imamo dvije razine kralježaka, onda imamo samo tri razine preklopnika, a očekujemo da će u mreži biti tri kabelska segmenta: od poslužitelja do lisnih preklopnika, do kralježnice 1, do kralježnice 2. Opcije koje možemo koriste se - to su twinax, multimode, single mode. I ovdje moramo razmotriti koja je traka dostupna, koliko će koštati, koje su fizičke dimenzije, koje raspone možemo pokriti i kako ćemo nadograditi.
Troškovno se sve može posložiti. Twinaxevi su znatno jeftiniji od aktivne optike, jeftiniji od multimodnih primopredajnika, ako se uzme po letu s 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š prikladan za rad s, vrlo velika pakiranja se dobivaju vlakna, a ako se fokusiramo na te tehnologije, dobivamo otprilike sljedeću hijerarhiju cijena.
Još jedna napomena: nažalost, nije baš moguće koristiti rastavljene 100 do 4x25 višemodne priključke. Zbog značajki dizajna SFP28 primopredajnika, nije mnogo jeftiniji od 28 Gbit QSFP100. A ovo rastavljanje za multimode ne radi baš dobro.
Još jedno ograničenje je to što se zbog veličine računalnih klastera i broja poslužitelja naši podatkovni centri pokazuju fizički velikima. To znači da će se barem jedan let morati obaviti s singlemodom. Opet, zbog fizičke veličine Podova, neće biti moguće provesti dva raspona twinaxa (bakrenih kabela).
Kao rezultat toga, ako optimiziramo cijenu i uzmemo u obzir geometriju ovog dizajna, dobivamo jedan raspon twinaxa, jedan raspon višemodnog i jedan raspon jednomodnog pomoću CWDM-a. Ovo uzima u obzir moguće putove nadogradnje.
Ovako to izgleda nedavno, kuda idemo i što je moguće. Barem je jasno kako se pomaknuti prema 50-gigabitnim SerDes-ovima za multimode i singlemode. Štoviše, ako pogledate što je u single-mode primopredajnicima sada iu budućnosti za 400G, često čak i kada 50G SerDes stigne s električne strane, 100 Gbps po traci već može ići na optiku. Stoga je sasvim moguće da umjesto na 50, dođe do prijelaza na 100 Gigabit SerDes i 100 Gbps per lane, jer se prema obećanjima mnogih dobavljača njihova dostupnost očekuje vrlo brzo. Razdoblje u kojem su 50G SerDes bili najbrži, čini se, neće biti dugo, jer prvi primjerci 100G SerDesa izlaze gotovo sljedeće godine. I nakon nekog vremena vjerojatno će vrijediti razuman novac.
Još jedna nijansa o izboru fizike. U principu, već sada možemo koristiti 400 ili 200 Gigabit portove koristeći 50G SerDes. Ali pokazalo se da to nema puno smisla, jer, kao što sam ranije rekao, želimo prilično veliki radix na prekidačima, unutar razumnih granica, naravno. Želimo 128. A ako imamo ograničen kapacitet čipa i povećamo brzinu veze, tada se radix prirodno smanjuje, nema čuda.
I možemo povećati ukupni kapacitet koristeći avione, i nema posebnih troškova, možemo dodati broj aviona. A ako izgubimo radix, morat ćemo uvesti dodatnu razinu, pa u sadašnjoj situaciji, s trenutnim maksimalnim raspoloživim kapacitetom po čipu, ispada da je učinkovitije koristiti 100-gigabitne portove, jer vam oni omogućuju da dobijemo veći radiks.
Sljedeće pitanje je kako je organizirana fizika, ali sa stajališta kabelske infrastrukture. Ispostavilo se da je organiziran na prilično smiješan način. Kabliranje između lisnih sklopki i kralježnica prve razine - tu nema mnogo veza, sve je izgrađeno relativno jednostavno. Ali ako uzmemo jednu ravninu, ono što se događa unutra je da trebamo spojiti sve bodlje prve razine sa svim bodljama druge razine.
Osim toga, u pravilu postoje neke želje kako bi trebao izgledati unutar podatkovnog centra. Na primjer, stvarno smo željeli spojiti kabele u snop i povući ih tako da jedan patch panel visoke gustoće ide u potpunosti u jedan patch panel, tako da nema zoološkog vrta u smislu duljina. Uspjeli smo riješiti ovaj problem. Ako u početku pogledate logičku topologiju, možete vidjeti da su ravnine neovisne, svaka se ravnina može izgraditi sama za sebe. Ali kada dodamo takav paket i želimo povući cijelu patch ploču u patch ploču, moramo miješati različite ravnine unutar jednog snopa i uvesti međustrukturu u obliku optičkih križnih veza kako bismo ih prepakirali od načina na koji su sastavljeni na jednom segmentu, kako će biti prikupljeni na drugom segmentu. Zahvaljujući tome, dobivamo lijepu značajku: sve složene komutacije ne idu dalje od regala. Kad treba nešto jako jako ispreplesti, "razviti ravnine", kako se to ponekad naziva u Closovim mrežama, sve je to koncentrirano unutar jednog stalka. Nemamo visoko rastavljeno, sve do pojedinačnih veza, prebacivanje između regala.
Ovako to izgleda sa stajališta logične organizacije kabelske infrastrukture. Na slici lijevo, raznobojni blokovi prikazuju blokove sklopki kralježnice prve razine, po osam komada, i četiri snopa kabela koji dolaze iz njih, koji idu i sijeku se sa snopovima koji dolaze iz blokova sklopki spine-2 .
Mali kvadrati označavaju raskrižja. U gornjem lijevom kutu je pregled svakog takvog raskrižja, ovo je zapravo 512 sa 512 port križni modul koji prepakira kabele tako da u potpunosti dolaze u jedan stalak, gdje postoji samo jedna spine-2 ravnina. A desno, sken ove slike je malo detaljniji u odnosu na nekoliko Podova na razini kralježnice-1, i kako je upakiran u unakrsno povezivanje, kako dolazi do razine kralježnice-2.
Ovako to izgleda. Još nepotpuno sastavljen stalak spine-2 (lijevo) i stalak za križno povezivanje. Nažalost, tamo se nema što vidjeti. Cijela ova struktura upravo se postavlja u jedan od naših velikih podatkovnih centara koji se proširuje. Ovo je u tijeku, izgledat će ljepše, bit će bolje popunjeno.
Važno pitanje: odabrali smo logičku topologiju i izgradili fiziku. Što će se dogoditi s kontrolnom ravninom? Iz operativnog iskustva je prilično dobro poznato, postoji niz izvješća da su protokoli stanja veze dobri, zadovoljstvo je raditi s njima, ali, nažalost, ne skaliraju se dobro na gusto povezanoj topologiji. A postoji jedan glavni čimbenik koji to sprječava - ovo je način na koji flooding funkcionira u protokolima stanja veze. Ako samo uzmete algoritam preplavljivanja i pogledate kako je naša mreža strukturirana, možete vidjeti da će biti vrlo veliki fanout na svakom koraku, i jednostavno će preplaviti kontrolnu ravninu ažuriranjima. Konkretno, takve se topologije vrlo slabo miješaju s tradicionalnim algoritmom preplavljivanja u protokolima stanja veze.
Izbor je koristiti BGP. Kako ga ispravno 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 minimalan broj prefiksa na mreži, korištenje agregacije ako je moguće i suzbijanje traženja putanje. Želimo vrlo pažljivu, vrlo kontroliranu distribuciju ažuriranja, ono što se zove valley free. Želimo da se ažuriranja implementiraju točno jednom dok prolaze kroz mrežu. Ako nastaju na dnu, idu prema gore, ne otvarajući se više od jednom. Ne bi trebalo biti cik-cak. Cik-cak je jako loš.
Da bismo to učinili, koristimo dizajn koji je dovoljno jednostavan za korištenje temeljnih BGP mehanizama. Odnosno, koristimo eBGP koji radi na lokalnoj vezi, a autonomni sustavi dodijeljeni su na sljedeći način: autonomni sustav na ToR-u, autonomni sustav na cijelom bloku spine-1 prekidača jednog Poda i opći autonomni sustav na cijelom vrhu od tkanine. Nije teško pogledati i vidjeti da nam čak i normalno ponašanje BGP-a daje distribuciju ažuriranja kakvu želimo.
Naravno, adresiranje i agregacija adresa moraju biti dizajnirani tako da budu kompatibilni s načinom na koji je izgrađeno usmjeravanje, tako da osigurava stabilnost kontrolne ravnine. L3 adresiranje u transportu vezano je uz topologiju jer je bez toga nemoguće postići agregaciju, bez koje će se pojedinačne adrese uvući u sustav usmjeravanja. I još jedna stvar je da se agregacija, nažalost, ne miješa baš dobro s multipathom, jer kad imamo multipath i imamo agregaciju, sve je u redu, kad je cijela mreža zdrava, nema kvarova u njoj. Nažalost, čim se pojave kvarovi u mreži i izgubi simetrija topologije, možemo doći do točke s koje je jedinica najavljena, s koje ne možemo ići dalje tamo gdje trebamo ići. Stoga je najbolje agregirati tamo gdje više nema više puta, u našem slučaju to su ToR preklopnici.
Zapravo, moguće je agregirati, ali pažljivo. Ako možemo napraviti kontroliranu raščlanjivanje kada dođe do kvarova na mreži. Ali ovo je prilično težak zadatak, čak smo se pitali je li to moguće učiniti, je li moguće dodati dodatnu automatizaciju i automate s konačnim stanjem koji bi ispravno izbacili BGP kako bi dobili željeno ponašanje. Nažalost, obrada kutnih slučajeva vrlo je neočita i složena, a ovaj zadatak nije dobro riješen pričvršćivanjem vanjskih privitaka na BGP.
Vrlo zanimljiv posao u tom pogledu obavljen je u okviru RIFT protokola, o čemu će biti riječi u sljedećem izvješću.
Još jedna važna stvar je kako se podatkovne ravni skaliraju u gustim topologijama, gdje imamo veliki broj alternativnih putova. U ovom slučaju koristi se nekoliko dodatnih struktura podataka: ECMP grupe, koje zauzvrat opisuju grupe Next Hop.
U normalno radnoj mreži, bez kvarova, kada idemo gore Clos topologijom, dovoljno je koristiti samo jednu grupu, jer sve što nije lokalno je standardno opisano, možemo ići gore. Kad idemo odozgo prema dolje prema jugu, tada sve staze nisu ECMP, one su staze s jednom stazom. Sve je u redu. Problem je, a posebnost klasične Closove topologije je da ako pogledamo vrh tkanine, bilo koji element, postoji samo jedan put do bilo kojeg elementa ispod. Ako se na tom putu dogode kvarovi, tada ovaj određeni element na vrhu tvornice postaje nevažeći upravo za one prefikse koji leže iza prekinutog puta. Ali za ostalo vrijedi, a mi moramo analizirati ECMP grupe i uvesti novo stanje.
Kako izgleda skalabilnost podatkovne ravnine na modernim uređajima? Ako radimo LPM (najduže podudaranje prefiksa), sve je prilično dobro, preko 100k prefiksa. Ako govorimo o Next Hop grupama, onda je sve gore, 2-4 tisuće. Ako govorimo o tablici koja sadrži opis sljedećih skokova (ili susjedstava), onda je to negdje od 16k do 64k. A to može postati problem. I tu dolazimo do zanimljive digresije: što se dogodilo s MPLS-om u podatkovnim centrima? U principu smo to htjeli napraviti.
Dogodile su se dvije stvari. Napravili smo mikrosegmentaciju na hostovima; više to nismo morali raditi na mreži. Nije bilo baš dobro s podrškom različitih dobavljač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 s ECMP-om. I zato.
Ovako izgleda ECMP struktura prosljeđivanja za IP. Velik broj prefiksa može koristiti istu grupu i isti blok Next Hops (ili susjedstva, to se može drugačije zvati u različitim dokumentima za različite uređaje). Poanta je da je to opisano kao odlazni port i na što treba prepisati MAC adresu kako bi se došlo do ispravnog sljedećeg skoka. Za IP sve izgleda jednostavno, možete koristiti vrlo velik broj prefiksa za istu grupu, isti blok Next Hops.
Klasična MPLS arhitektura podrazumijeva da se, ovisno o odlaznom sučelju, oznaka može prepisati na različite vrijednosti. Stoga moramo zadržati grupu i blok Next Hops za svaku ulaznu oznaku. A ovo, nažalost, ne mjeri.
Lako je vidjeti da smo u našem dizajnu trebali oko 4000 ToR prekidača, maksimalna širina bila je 64 ECMP staze, ako se odmaknemo od spine-1 prema spine-2. Jedva uđemo u jednu tablicu ECMP grupa, ako nestane samo jedan prefiks s ToR-om, a uopće ne uđemo u tablicu Next Hops.
Nije sve beznadno, jer arhitekture kao što je Segment Routing uključuju globalne oznake. Formalno, bilo bi moguće ponovno srušiti sve ove Next Hops blokove. Da biste to učinili, potrebna vam je operacija tipa zamjenskog znaka: uzmite oznaku i prepišite je u istu bez određene vrijednosti. No, nažalost, to nije baš prisutno u dostupnim implementacijama.
I konačno, moramo dovesti vanjski promet u podatkovni centar. Kako to učiniti? Prethodno je promet u Closovu mrežu uveden odozgo. To jest, postojali su rubni usmjerivači koji su se spajali na sve uređaje na vrhu tkanine. Ovo rješenje prilično dobro funkcionira na malim do srednjim veličinama. Nažalost, da bismo na ovaj način simetrično slali promet na cijelu mrežu, moramo istovremeno doći do svih elemenata Top of fabrica, a kada ih je više od stotinu, ispada da nam treba i veliki radix na rubnim usmjerivačima. Općenito, to košta jer su rubni usmjerivači funkcionalniji, priključci na njima bit će skuplji, a dizajn nije baš lijep.
Druga je mogućnost pokrenuti takav promet odozdo. Lako je provjeriti da je Closova topologija izgrađena na takav način da se promet koji dolazi odozdo, to jest sa strane ToR-a, ravnomjerno raspoređuje među razinama kroz cijeli Top of fabric u dvije iteracije, opterećujući cijelu mrežu. Stoga predstavljamo posebnu vrstu Poda, Edge Pod, koji omogućuje vanjsku povezanost.
Postoji još jedna opcija. To radi, na primjer, Facebook. Zovu ga Fabric Aggregator ili HGRID. Uvodi se dodatna kralježnička razina za povezivanje više podatkovnih centara. Ovaj dizajn je moguć ako nemamo dodatne funkcije ili promjene enkapsulacije na sučeljima. Ako su to dodatne dodirne točke, teško je. Tipično, postoji više funkcija i neka vrsta membrane koja odvaja različite dijelove podatkovnog centra. Takvu membranu nema smisla praviti velikom, ali ako je iz nekog razloga stvarno potrebna, onda ima smisla razmotriti mogućnost oduzimanja, što veće širine i prijenosa na domaćine. To rade, primjerice, mnogi operateri u oblaku. Imaju nadmetanja, kreću od domaćina.
Kakve mogućnosti razvoja vidimo? Prije svega, poboljšanje podrške za CI/CD cjevovod. Želimo letjeti onako kako testiramo i testirati način na koji letimo. Ovo ne funkcionira baš najbolje jer je infrastruktura velika i nemoguće ju je duplicirati za testove. Morate razumjeti kako uvesti elemente testiranja u proizvodnu infrastrukturu, a da je ne ispustite.
Bolji instrumenti i bolji nadzor gotovo nikad nisu suvišni. Cijelo pitanje je ravnoteža truda i povrata. Ako to možete dodati uz razuman trud, vrlo dobro.
Otvoreni operativni sustavi za mrežne uređaje. Bolji protokoli i bolji sustavi usmjeravanja, kao što je RIFT. Također je potrebno istraživanje korištenja boljih shema kontrole zagušenja i možda uvođenje, barem u nekim točkama, RDMA podrške unutar klastera.
Gledajući dalje u budućnost, trebamo napredne topologije i moguće mreže koje koriste manje režijskih troškova. Od svježih stvari, nedavno su se pojavile publikacije o fabric tehnologiji za HPC Cray Slingshot, koja se temelji na robnom Ethernetu, ali s mogućnošću korištenja puno kraćih zaglavlja. Kao rezultat, režijski troškovi su smanjeni.
Sve treba biti što jednostavnije, ali ne jednostavnije. Složenost je neprijatelj skalabilnosti. Jednostavnost i pravilne strukture naši su prijatelji. Ako se negdje možete proširiti, učinite to. I općenito, super je sada biti uključen u mrežne tehnologije. Događa se puno zanimljivih stvari. Hvala vam.
Izvor: www.habr.com