Vi har utvecklat en datacenternÀtverksdesign som tillÄter driftsÀttning av datorkluster större Àn 100 tusen servrar med en toppbandbredd pÄ över en petabyte per sekund.
FrÄn Dmitry Afanasyevs rapport kommer du att lÀra dig om de grundlÀggande principerna för den nya designen, skalningstopologier, problemen som uppstÄr med detta, alternativ för att lösa dem, funktionerna för att dirigera och skala vidarebefordransplanets funktioner för moderna nÀtverksenheter i "tÀtt anslutna" topologier med ett stort antal ECMP-rutter. Dessutom talade Dima kort om organisationen av extern anslutning, det fysiska lagret, kabelsystemet och sÀtt att ytterligare öka kapaciteten.
- God eftermiddag allihop! Jag heter Dmitry Afanasyev, jag Àr nÀtverksarkitekt pÄ Yandex och designar frÀmst datacenternÀtverk.
Min berÀttelse kommer att handla om det uppdaterade nÀtverket av Yandex datacenter. Det Àr mycket en utveckling av designen vi hade, men samtidigt finns det nÄgra nya element. Detta Àr en översiktspresentation eftersom det fanns mycket information som skulle packas in pÄ en kort tid. Vi börjar med att vÀlja en logisk topologi. Sedan kommer det att finnas en översikt över kontrollplanet och problem med dataplans skalbarhet, ett val av vad som ska hÀnda pÄ fysisk nivÄ, och vi kommer att titta pÄ nÄgra funktioner hos enheterna. LÄt oss beröra lite vad som hÀnder i ett datacenter med MPLS, som vi pratade om för en tid sedan.
SĂ„ vad Ă€r Yandex nĂ€r det gĂ€ller belastningar och tjĂ€nster? Yandex Ă€r en typisk hyperscaler. Om vi ââtittar pĂ„ anvĂ€ndarna behandlar vi i första hand anvĂ€ndarförfrĂ„gningar. Ăven olika streamingtjĂ€nster och dataöverföring, eftersom vi Ă€ven har lagringstjĂ€nster. Om det Ă€r nĂ€rmare backend, sĂ„ dyker det upp infrastrukturbelastningar och tjĂ€nster dĂ€r, sĂ„som distribuerad objektlagring, datareplikering och, naturligtvis, bestĂ€ndiga köer. En av huvudtyperna av arbetsbelastningar Ă€r MapReduce och liknande system, strömbehandling, maskininlĂ€rning, etc.
Hur Ă€r infrastrukturen ovanpĂ„ vilken allt detta hĂ€nder? Ă
terigen, vi Àr en ganska typisk hyperscaler, Àven om vi kanske Àr lite nÀrmare den mindre hyperscaler sidan av spektrumet. Men vi har alla egenskaper. Vi anvÀnder rÄvaruhÄrdvara och horisontell skalning dÀr det Àr möjligt. Vi har full resurspooling: vi arbetar inte med enskilda maskiner, enskilda rack, utan kombinerar dem till en stor pool av utbytbara resurser med nÄgra tillÀggstjÀnster som handlar om planering och allokering, och arbetar med hela denna pool.
SÄ vi har nÀsta nivÄ - operativsystemet pÄ datorklusternivÄ. Det Àr mycket viktigt att vi har full kontroll över teknikstacken som vi anvÀnder. Vi kontrollerar slutpunkterna (vÀrdarna), nÀtverket och mjukvarustacken.
Vi har flera stora datacenter i Ryssland och utomlands. De förenas av en ryggrad som anvÀnder MPLS-teknik. VÄr interna infrastruktur Àr nÀstan helt uppbyggd pÄ IPv6, men eftersom vi behöver betjÀna extern trafik som fortfarande huvudsakligen kommer över IPv4 mÄste vi pÄ nÄgot sÀtt leverera förfrÄgningar som kommer över IPv4 till frontend-servrarna, och lite mer gÄ till extern IPv4- Internet - för till exempel för indexering.
De senaste iterationerna av datacenternĂ€tverksdesigner har anvĂ€nt Clos-topologier i flera lager och Ă€r endast L3. Vi lĂ€mnade L2 för ett tag sedan och andades ut. Slutligen inkluderar vĂ„r infrastruktur hundratusentals dator (server) instanser. Den maximala klusterstorleken för en tid sedan var cirka 10 tusen servrar. Detta beror till stor del pĂ„ hur samma operativsystem pĂ„ klusternivĂ„, schemalĂ€ggare, resursallokering etc. kan fungera. Eftersom framsteg har skett pĂ„ sidan av infrastrukturprogramvaran Ă€r mĂ„lstorleken nu cirka 100 tusen servrar i ett datorkluster, och Vi har en uppgift â att kunna bygga nĂ€tverksfabriker som möjliggör effektiv resurssamling i ett sĂ„dant kluster.
Vad vill vi ha av ett datacenternÀtverk? För det första finns det mycket billig och ganska jÀmnt fördelad bandbredd. Eftersom nÀtverket Àr ryggraden genom vilken vi kan slÄ samman resurser. Den nya mÄlstorleken Àr cirka 100 tusen servrar i ett kluster.
Vi vill naturligtvis ocksÄ ha ett skalbart och stabilt kontrollplan, för pÄ en sÄ stor infrastruktur uppstÄr mycket huvudvÀrk Àven frÄn helt enkelt slumpmÀssiga hÀndelser, och vi vill inte att kontrollplanet ska ge oss huvudvÀrk ocksÄ. Samtidigt vill vi minimera staten i den. Ju mindre tillstÄndet Àr, desto bÀttre och stabilare fungerar allt, och desto lÀttare Àr det att diagnostisera.
SjÀlvklart behöver vi automatisering, för det Àr omöjligt att hantera en sÄdan infrastruktur manuellt, och det har varit omöjligt under en tid. Vi behöver operativt stöd sÄ mycket som möjligt och CI/CD-stöd i den mÄn det kan tillhandahÄllas.
Med sÄdana storlekar av datacenter och kluster har uppgiften att stödja inkrementell driftsÀttning och expansion utan avbrott i tjÀnsten blivit ganska akut. Om de pÄ kluster med en storlek pÄ tusen maskiner, kanske nÀra tiotusen maskiner, fortfarande skulle kunna rullas ut som en operation - det vill sÀga vi planerar en utbyggnad av infrastrukturen, och flera tusen maskiner lÀggs till som en operation, dÄ uppstÄr inte ett kluster av storleken hundra tusen maskiner omedelbart sÄ hÀr, det byggs över en tidsperiod. Och det Àr önskvÀrt att hela den hÀr tiden ska det som redan pumpats ut, den infrastruktur som har satts ut, finnas tillgÀnglig.
Och ett krav som vi hade och lÀmnade: stöd för multitenancy, det vill sÀga virtualisering eller nÀtverkssegmentering. Nu behöver vi inte göra detta pÄ nÀtverksstrukturnivÄ, eftersom skÀrningen har gÄtt till vÀrdarna, och detta har gjort skalningen vÀldigt lÀtt för oss. Tack vare IPv6 och ett stort adressutrymme behövde vi inte anvÀnda dubbletter av adresser i den interna infrastrukturen, all adressering var redan unik. Och tack vare att vi har tagit filtrering och nÀtverkssegmentering till vÀrdarna behöver vi inte skapa nÄgra virtuella nÀtverksenheter i datacenternÀtverk.
En mycket viktig sak Àr vad vi inte behöver. Om vissa funktioner kan tas bort frÄn nÀtverket gör detta livet mycket enklare och utökar i regel valet av tillgÀnglig utrustning och programvara, vilket gör diagnostiken mycket enkel.
SÄ vad Àr det vi inte behöver, vad har vi kunnat ge upp, inte alltid med glÀdje nÀr det hÀnde, men med stor lÀttnad nÀr processen Àr avslutad?
Först av allt, att överge L2. Vi behöver inte L2, varken verklig eller emulerad. OanvÀnd till stor del pÄ grund av att vi kontrollerar applikationsstacken. VÄra applikationer Àr horisontellt skalbara, de fungerar med L3-adressering, de Àr inte sÀrskilt oroliga för att nÄgon enskild instans har gÄtt ut, de rullar helt enkelt ut en ny, den behöver inte rullas ut pÄ den gamla adressen, eftersom det finns en separat servicenivÄ för upptÀckt och övervakning av maskiner som finns i klustret. Vi delegerar inte denna uppgift till nÀtverket. NÀtverkets uppgift Àr att leverera paket frÄn punkt A till punkt B.
Vi har inte heller situationer dÀr adresser rör sig inom nÀtverket, och detta behöver övervakas. I mÄnga konstruktioner behövs detta vanligtvis för att stödja VM-mobilitet. Vi anvÀnder inte mobiliteten för virtuella maskiner i den interna infrastrukturen i det stora Yandex, och dessutom anser vi att Àven om detta görs, bör det inte ske med nÀtverksstöd. Om det verkligen behöver göras mÄste det göras pÄ vÀrdnivÄ och pusha adresser som kan migrera till överlÀgg, för att inte röra eller göra för mÄnga dynamiska Àndringar i sjÀlva underlÀggets routingsystem (transportnÀtverket) .
En annan teknik som vi inte anvÀnder Àr multicast. Om du vill kan jag berÀtta i detalj varför. Detta gör livet mycket lÀttare, för om nÄgon har tagit itu med det och tittat pÄ exakt hur multicast-kontrollplanet ser ut, i alla utom de enklaste installationerna, Àr detta en stor huvudvÀrk. Och dessutom Àr det svÄrt att hitta en vÀl fungerande implementering med öppen kÀllkod, till exempel.
Slutligen designar vi vÄra nÀtverk sÄ att de inte förÀndras för mycket. Vi kan rÀkna med att flödet av externa hÀndelser i routingsystemet Àr litet.
Vilka problem uppstĂ„r och vilka begrĂ€nsningar mĂ„ste beaktas nĂ€r vi utvecklar ett datacenternĂ€tverk? Kostnad sĂ„klart. Skalbarhet, den nivĂ„ som vi vill vĂ€xa till. Behovet av att expandera utan att stoppa tjĂ€nsten. Bandbredd, tillgĂ€nglighet. Synlighet av vad som hĂ€nder pĂ„ nĂ€tverket för övervakningssystem, för operativa team. Automatiseringsstöd - igen, sĂ„ mycket som möjligt, eftersom olika uppgifter kan lösas pĂ„ olika nivĂ„er, inklusive införandet av ytterligare lager. Tja, inte [möjligen] beroende av leverantörer. Ăven om det i olika historiska perioder, beroende pĂ„ vilket avsnitt man tittar pĂ„, var denna sjĂ€lvstĂ€ndighet lĂ€ttare eller svĂ„rare att uppnĂ„. Om vi ââtar ett tvĂ€rsnitt av nĂ€tverksenhetschips, sĂ„ var det tills nyligen mycket villkorat att prata om oberoende frĂ„n leverantörer, om vi ocksĂ„ ville ha chips med hög genomströmning.
Vilken logisk topologi kommer vi att anvÀnda för att bygga vÄrt nÀtverk? Detta kommer att vara en Clos pÄ flera nivÄer. Det finns faktiskt inga riktiga alternativ för tillfÀllet. Och Clos-topologin Àr ganska bra, Àven jÀmfört med olika avancerade topologier som Àr mer inom omrÄdet av akademiskt intresse nu, om vi har stora radix-switchar.
Hur Àr ett Clos-nÀtverk pÄ flera nivÄer grovt uppbyggt och vad heter de olika elementen i det? Först och frÀmst steg vinden, för att orientera dig var Àr norr, var Àr syd, var Àr öst, var Àr vÀst. NÀt av denna typ byggs vanligtvis av de som har mycket stor vÀst-osttrafik. NÀr det gÀller de ÄterstÄende elementen, högst upp finns en virtuell switch sammansatt av mindre switchar. Detta Àr huvudidén med rekursiv konstruktion av Clos-nÀtverk. Vi tar element med nÄgon sorts radix och kopplar ihop dem sÄ att det vi fÄr kan betraktas som en switch med en större radix. Om du behöver Ànnu mer kan proceduren upprepas.
I fall, till exempel med tvĂ„-nivĂ„ Clos, nĂ€r det Ă€r möjligt att tydligt identifiera komponenter som Ă€r vertikala i mitt diagram, brukar de kallas plan. Om vi ââskulle bygga en Clos med tre nivĂ„er av ryggradsomkopplare (som alla inte Ă€r grĂ€ns- eller ToR-omkopplare och som endast anvĂ€nds för transitering), dĂ„ skulle planen se mer komplexa ut, tvĂ„nivĂ„s-omkopplare ser ut exakt sĂ„ hĂ€r. Vi kallar ett block av ToR- eller bladomkopplare och de första nivĂ„ns ryggradsomkopplare som Ă€r associerade med dem för en Pod. Ryggreglage pĂ„ ryggraden-1-nivĂ„n pĂ„ toppen av Pod Ă€r toppen av Pod, toppen av Pod. Strömbrytarna som sitter högst upp pĂ„ hela fabriken Ă€r fabrikens översta lager, Top of fabric.
Naturligtvis uppstÄr frÄgan: Clos-nÀtverk har byggts under en tid, sjÀlva idén kommer i allmÀnhet frÄn den klassiska telefonins tid, TDM-nÀtverk. Kanske har nÄgot bÀttre dykt upp, kanske nÄgot kan göras bÀttre? Ja och nej. Teoretiskt ja, i praktiken inom en snar framtid definitivt inte. Eftersom det finns ett antal intressanta topologier anvÀnds vissa av dem till och med i produktionen, till exempel anvÀnds Dragonfly i HPC-applikationer; Det finns ocksÄ intressanta topologier som Xpander, FatClique, Jellyfish. Om man tittar pÄ rapporter pÄ konferenser som SIGCOMM eller NSDI nyligen kan man hitta ett ganska stort antal arbeten om alternativa topologier som har bÀttre egenskaper (en eller annan) Àn Clos.
Men alla dessa topologier har en intressant egenskap. Det förhindrar att de implementeras i datacenternÀtverk, som vi försöker bygga pÄ rÄvaruhÄrdvara och som kostar ganska rimliga pengar. I alla dessa alternativa topologier Àr det mesta av bandbredden tyvÀrr inte tillgÀnglig via de kortaste vÀgarna. DÀrför förlorar vi omedelbart möjligheten att anvÀnda det traditionella kontrollplanet.
Teoretiskt Àr lösningen pÄ problemet kÀnd. Dessa Àr till exempel modifieringar av lÀnktillstÄnd med anvÀndning av k-kortaste vÀgen, men Äterigen, det finns inga sÄdana protokoll som skulle implementeras i produktionen och allmÀnt tillgÀngliga pÄ utrustning.
Dessutom, eftersom det mesta av kapaciteten inte Àr tillgÀnglig via de kortaste vÀgarna, mÄste vi modifiera mer Àn bara kontrollplanet för att vÀlja alla dessa vÀgar (och förresten, detta Àr betydligt mer tillstÄnd i kontrollplanet). Vi behöver fortfarande modifiera vidarebefordransplanet, och som regel krÀvs minst tvÄ ytterligare funktioner. Detta Àr möjligheten att fatta alla beslut om vidarebefordran av paket en gÄng, till exempel pÄ vÀrden. I sjÀlva verket Àr detta kÀlldirigering, ibland i litteraturen om sammankopplingsnÀtverk kallas detta beslut om att vidarebefordra allt pÄ en gÄng. Och adaptiv routing Àr en funktion som vi behöver pÄ nÀtverkselement, vilket till exempel kokar ner till att vi vÀljer nÀsta hopp utifrÄn information om minsta belastning pÄ kön. Som ett exempel Àr andra alternativ möjliga.
DÀrför Àr riktningen intressant, men tyvÀrr kan vi inte tillÀmpa den just nu.
Okej, vi bestÀmde oss för Clos logiska topologi. Hur ska vi skala det? LÄt oss se hur det fungerar och vad som kan göras.
I ett Clos-nÀtverk finns det tvÄ huvudparametrar som vi pÄ nÄgot sÀtt kan variera och fÄ vissa resultat: elementets radix och antalet nivÄer i nÀtverket. Jag har ett schematiskt diagram över hur bÄda pÄverkar storleken. Helst kombinerar vi bÄda.
Det kan ses att den slutliga bredden pÄ Clos-nÀtverket Àr produkten av alla nivÄer av ryggradsomkopplare i den södra radixen, hur mÄnga lÀnkar vi har nere, hur den förgrenar sig. SÄ hÀr skalar vi storleken pÄ nÀtverket.
NÀr det gÀller kapacitet, speciellt pÄ ToR-switchar, finns det tvÄ skalningsalternativ. Antingen kan vi, samtidigt som vi behÄller den allmÀnna topologin, anvÀnda snabbare lÀnkar, eller sÄ kan vi lÀgga till fler plan.
Om du tittar pÄ den utökade versionen av Clos-nÀtverket (i det nedre högra hörnet) och ÄtergÄr till den hÀr bilden med Clos-nÀtverket nedan...
... dÄ Àr detta exakt samma topologi, men pÄ den hÀr bilden Àr den kollapsad mer kompakt och fabrikens plan överlagras pÄ varandra. Det Àr samma.
Hur ser det ut att skala ett Clos-nÀtverk i siffror? HÀr ger jag data om vilken maximal bredd ett nÀtverk kan erhÄllas, vilket maximalt antal rack, ToR switchar eller leaf switchar, om de inte finns i rack, kan vi fÄ beroende pÄ vilken radix av switchar vi anvÀnder för ryggradsnivÄer, och hur mÄnga nivÄer vi anvÀnder.
HÀr Àr hur mÄnga rack vi kan ha, hur mÄnga servrar och ungefÀr hur mycket allt detta kan förbruka baserat pÄ 20 kW per rack. Lite tidigare nÀmnde jag att vi siktar pÄ en klusterstorlek pÄ cirka 100 tusen servrar.
Det kan ses att i hela denna design Àr tvÄ och ett halvt alternativ av intresse. Det finns ett alternativ med tvÄ lager ryggar och 64-portars switchar, vilket faller lite kort. Sedan finns det perfekt passande alternativ för 128-portars (med radix 128) ryggradsbrytare med tvÄ nivÄer, eller switchar med radix 32 med tre nivÄer. Och i alla fall, dÀr det finns fler radixer och fler lager, kan du göra ett vÀldigt stort nÀtverk, men om du tittar pÄ den förvÀntade förbrukningen sÄ finns det vanligtvis gigawatt. Det gÄr att dra en kabel, men vi fÄr knappast sÄ mycket el pÄ en plats. Om man tittar pÄ statistik och offentliga data om datacenter kan man hitta vÀldigt fÄ datacenter med en uppskattad kapacitet pÄ mer Àn 150 MW. De större Àr oftast datacentercampus, flera stora datacenter som ligger ganska nÀra varandra.
Det finns en annan viktig parameter. Om du tittar pÄ den vÀnstra kolumnen, Àr anvÀndbar bandbredd listad dÀr. Det Àr lÀtt att se att i ett Clos-nÀtverk anvÀnds en betydande del av portarna för att koppla switchar till varandra. AnvÀndbar bandbredd, en anvÀndbar remsa, Àr nÄgot som kan ges utanför, mot servrarna. Naturligtvis pratar jag om villkorliga portar och specifikt om bandet. LÀnkar inom nÀtverket Àr i regel snabbare Àn lÀnkar mot servrar, men per bandbreddsenhet, sÄ mycket som vi kan skicka ut det till vÄr serverutrustning, finns det fortfarande en del bandbredd inom sjÀlva nÀtverket. Och ju fler nivÄer vi gör, desto större blir den specifika kostnaden för att tillhandahÄlla denna rand till utsidan.
Dessutom Ă€r inte ens detta extra band exakt detsamma. Ăven om spĂ€nnvidden Ă€r kort, kan vi anvĂ€nda nĂ„got som DAC (direct attach copper, det vill sĂ€ga twinax-kablar), eller multimode-optik, som kostar till och med mer eller mindre rimliga pengar. SĂ„ fort vi gĂ„r över till lĂ€ngre spann - som regel Ă€r dessa single mode-optik, och kostnaden för denna extra bandbredd ökar mĂ€rkbart.
Och igen, för att ÄtergÄ till föregÄende bild, om vi skapar ett Clos-nÀtverk utan överabonnemang, dÄ Àr det lÀtt att titta pÄ diagrammet, se hur nÀtverket Àr byggt - genom att lÀgga till varje nivÄ av ryggradsvÀxlar, upprepar vi hela remsan som var vid botten. PlusnivÄ - plus samma band, samma antal portar pÄ switchar som det fanns pÄ föregÄende nivÄ, och samma antal sÀndtagare. DÀrför Àr det mycket önskvÀrt att minimera antalet nivÄer av ryggradsomkopplare.
Baserat pÄ den hÀr bilden Àr det tydligt att vi verkligen vill bygga pÄ nÄgot som vÀxlar med en radix pÄ 128.
HÀr Àr i princip allt detsamma som jag nyss sa, det hÀr Àr en bild för övervÀgande senare.
Vilka alternativ finns det som vi kan vÀlja som sÄdana switchar? Det Àr mycket trevliga nyheter för oss att nu kan sÄdana nÀtverk Àntligen byggas pÄ enchipsvÀxlar. Och det hÀr Àr vÀldigt coolt, de har mÄnga fina funktioner. Till exempel har de nÀstan ingen inre struktur. Det betyder att de lÀttare gÄr sönder. De gÄr sönder pÄ alla möjliga sÀtt, men som tur Àr gÄr de sönder helt. I modulÀra enheter finns det ett stort antal fel (mycket obehagligt), nÀr det ur grannarnas och kontrollplanets synvinkel verkar fungera, men till exempel en del av tyget har gÄtt förlorat och det fungerar inte vid full kapacitet. Och trafiken till den Àr balanserad utifrÄn det faktum att den Àr fullt fungerande, och vi kan bli överbelastade.
Eller till exempel uppstÄr problem med bakplanet, för inuti den modulÀra enheten finns det Àven höghastighets SerDes - det Àr verkligen komplext inuti. Antingen Àr skyltarna mellan vidarebefordrande element synkroniserade eller inte synkroniserade. I allmÀnhet innehÄller varje produktiv modulÀr enhet som bestÄr av ett stort antal element, som regel, samma Clos-nÀtverk i sig sjÀlv, men det Àr mycket svÄrt att diagnostisera. Ofta Àr det svÄrt för Àven sÀljaren sjÀlv att diagnostisera.
Och den har ett stort antal felscenarier dÀr enheten försÀmras, men inte faller helt ur topologin. Eftersom vÄrt nÀtverk Àr stort anvÀnds aktivt balansering mellan identiska element, nÀtverket Àr vÀldigt regelbundet, det vill sÀga att den ena vÀgen dÀr allt Àr i sin ordning inte skiljer sig frÄn den andra vÀgen, det Àr mer lönsamt för oss att helt enkelt förlora nÄgra av enheterna frÄn topologin Àn att hamna i en situation dÀr vissa av dem verkar fungera, men vissa av dem inte.
NĂ€sta trevliga egenskap hos enheter med ett chip Ă€r att de utvecklas bĂ€ttre och snabbare. De tenderar ocksĂ„ att ha bĂ€ttre kapacitet. Om vi ââtar de stora sammansatta strukturerna som vi har pĂ„ en cirkel, sĂ„ Ă€r kapaciteten per rackenhet för portar med samma hastighet nĂ€stan dubbelt sĂ„ bra som för modulĂ€ra enheter. Enheter byggda kring ett enda chip Ă€r mĂ€rkbart billigare Ă€n modulĂ€ra och förbrukar mindre energi.
Men det hĂ€r Ă€r förstĂ„s av en anledning, det finns ocksĂ„ nackdelar. För det första Ă€r radixen nĂ€stan alltid mindre Ă€n den för modulĂ€ra enheter. Om vi ââkan fĂ„ en enhet byggd kring ett chip med 128 portar, sĂ„ kan vi fĂ„ en modulĂ€r sĂ„dan med flera hundra portar nu utan problem.
Detta Ă€r en mĂ€rkbart mindre storlek pĂ„ vidarebefordringstabeller och, som regel, allt som har med dataplans skalbarhet att göra. Grunda buffertar. Och som regel ganska begrĂ€nsad funktionalitet. Men det visar sig att om du kĂ€nner till dessa restriktioner och tar hand om dem i tid för att kringgĂ„ dem eller helt enkelt tar hĂ€nsyn till dem, sĂ„ Ă€r detta inte sĂ„ skrĂ€mmande. Det faktum att radixen Ă€r mindre Ă€r inte lĂ€ngre ett problem pĂ„ enheter med en radix pĂ„ 128 som Ă€ntligen har dykt upp nyligen; vi kan bygga in tvĂ„ lager av ryggar. Men det Ă€r fortfarande omöjligt att bygga nĂ„got mindre Ă€n tvĂ„ som Ă€r intressant för oss. Med en nivĂ„ erhĂ„lls mycket smĂ„ kluster. Ăven vĂ„ra tidigare konstruktioner och krav övertrĂ€ffade dem fortfarande.
Faktum Àr att om lösningen plötsligt Àr nÄgonstans pÄ randen, finns det fortfarande ett sÀtt att skala. Eftersom den sista (eller första), lÀgsta nivÄn dÀr servrar Àr anslutna Àr ToR-switchar eller leaf-switchar, behöver vi inte ansluta ett rack till dem. DÀrför, om lösningen kommer under ungefÀr hÀlften, kan du tÀnka pÄ att helt enkelt anvÀnda en strömbrytare med en stor radix pÄ den lÀgre nivÄn och koppla till exempel tvÄ eller tre rack till en strömbrytare. Detta Àr ocksÄ ett alternativ, det har sina kostnader, men det fungerar ganska bra och kan vara en bra lösning nÀr man ska nÄ ungefÀr dubbelt sÄ stor.
För att sammanfatta bygger vi pÄ en topologi med tvÄ nivÄer av ryggar, med Ätta fabrikslager.
Vad kommer att hĂ€nda med fysiken? VĂ€ldigt enkla berĂ€kningar. Om vi ââhar tvĂ„ nivĂ„er av spines, sĂ„ har vi bara tre nivĂ„er av switchar, och vi förvĂ€ntar oss att det kommer att finnas tre kabelsegment i nĂ€tverket: frĂ„n servrar till leaf switchar, till spine 1, till spine 2. De alternativ som vi kan anvĂ€ndning Ă€r - dessa Ă€r twinax, multimode, single mode. Och hĂ€r mĂ„ste vi övervĂ€ga vilken remsa som finns tillgĂ€nglig, hur mycket den kommer att kosta, vad de fysiska mĂ„tten Ă€r, vilka spĂ€nnvidder vi kan tĂ€cka och hur vi ska uppgradera.
KostnadsmÀssigt gÄr allt att radas upp. Twinaxes Àr betydligt billigare Àn aktiv optik, billigare Àn multimode-sÀndtagare, om du tar det per flygning frÄn slutet, nÄgot billigare Àn en 100-gigabit switchport. Och observera, det kostar mindre Àn enkellÀgesoptik, eftersom det pÄ flygningar dÀr enkellÀge krÀvs, i datacenter av flera skÀl Àr vettigt att anvÀnda CWDM, medan parallellt enkellÀge (PSM) inte Àr sÀrskilt bekvÀmt att arbeta med, mycket stora förpackningar erhÄlls fibrer, och om vi fokuserar pÄ dessa teknologier fÄr vi ungefÀr följande prishierarki.
En anmÀrkning till: tyvÀrr Àr det inte sÀrskilt möjligt att anvÀnda demonterade 100 till 4x25 multimode-portar. PÄ grund av designfunktionerna hos SFP28-sÀndtagare Àr den inte mycket billigare Àn 28 Gbit QSFP100. Och denna demontering för multimode fungerar inte sÀrskilt bra.
En annan begrÀnsning Àr att pÄ grund av storleken pÄ datorklustren och antalet servrar visar sig vÄra datacenter vara fysiskt stora. Detta innebÀr att minst en flygning mÄste göras med en singlemod. à terigen, pÄ grund av den fysiska storleken pÄ Pods, kommer det inte att vara möjligt att köra tvÄ spann av twinax (kopparkablar).
Som ett resultat, om vi optimerar för pris och tar hÀnsyn till geometrin i denna design, fÄr vi ett span av twinax, ett span av multimode och ett span av singlemode med CWDM. Detta tar hÀnsyn till möjliga uppgraderingsvÀgar.
SÄ hÀr ser det ut nyligen, vart Àr vi pÄ vÀg och vad som Àr möjligt. Det Àr Ätminstone klart hur man gÄr mot 50-Gigabit SerDes för bÄde multimode och singlemode. Dessutom, om man tittar pÄ vad som finns i singelmodssÀndtagare nu och i framtiden för 400G, ofta Àven nÀr 50G SerDes kommer frÄn den elektriska sidan, kan 100 Gbps per körfÀlt redan gÄ till optik. DÀrför Àr det mycket möjligt att istÀllet för att flytta till 50 kommer det att ske en övergÄng till 100 Gigabit SerDes och 100 Gbps per körfÀlt, för enligt löften frÄn mÄnga leverantörer förvÀntas deras tillgÀnglighet ganska snart. Perioden dÄ 50G SerDes var snabbast verkar det inte bli sÀrskilt lÄng, eftersom de första exemplaren av 100G SerDes kommer att rullas ut nÀstan nÀsta Är. Och efter en tid efter det kommer de förmodligen att vara vÀrda rimliga pengar.
Ytterligare en nyans om valet av fysik. I princip kan vi redan anvÀnda 400 eller 200 Gigabit-portar med 50G SerDes. Men det visar sig att detta inte Àr sÄ meningsfullt, eftersom vi, som jag sa tidigare, vill ha en ganska stor radix pÄ switcharna, naturligtvis inom rimliga grÀnser. Vi vill ha 128. Och om vi har begrÀnsad chipkapacitet och vi ökar lÀnkhastigheten sÄ minskar naturligtvis radixen, det finns inga mirakel.
Och vi kan öka den totala kapaciteten med hjÀlp av flygplan, och det finns inga speciella kostnader, vi kan lÀgga till antalet plan. Och om vi tappar radixen mÄste vi införa en extra nivÄ, sÄ i den nuvarande situationen, med den nuvarande maximala tillgÀngliga kapaciteten per chip, visar det sig att det Àr mer effektivt att anvÀnda 100-gigabit-portar, eftersom de tillÄter dig för att fÄ en större radix.
NÀsta frÄga Àr hur fysiken Àr organiserad, men ur kabelinfrastrukturens synvinkel. Det visar sig att det Àr organiserat pÄ ett ganska roligt sÀtt. Kabeldragning mellan bladomkopplare och första-nivÄ-ryggar - det finns inte mÄnga lÀnkar dÀr, allt Àr byggt relativt enkelt. Men om vi tar ett plan, Àr det som hÀnder inuti att vi mÄste koppla ihop alla ryggar pÄ den första nivÄn med alla ryggar pÄ den andra nivÄn.
Dessutom finns det som regel nÄgra önskemÄl om hur det ska se ut inne i datacentret. Till exempel ville vi verkligen kombinera kablar till en bunt och dra dem sÄ att en högdensitetspatchpanel gick helt in i en patchpanel, sÄ att det inte blev nÄgon djurpark vad gÀller lÀngder. Vi lyckades lösa detta problem. Om man initialt tittar pÄ den logiska topologin kan man se att planen Àr oberoende, varje plan kan byggas för sig. Men nÀr vi lÀgger till en sÄdan buntning och vill dra hela patchpanelen till en patchpanel mÄste vi blanda olika plan inuti en bunt och introducera en mellanstruktur i form av optiska korskopplingar för att packa om dem frÄn hur de monterades pÄ ett segment, i hur de kommer att samlas in pÄ ett annat segment. Tack vare detta fÄr vi en trevlig funktion: all komplex omkoppling gÄr inte utöver racken. NÀr du behöver sammanflÀta nÄgot vÀldigt starkt, "vika ut planen", som det ibland kallas i Clos-nÀtverk, Àr det hela koncentrerat i ett rack. Vi har inte mycket demonterade, ner till enskilda lÀnkar, byte mellan stÀll.
SÄ hÀr ser det ut ur den logiska organisationen av kabelinfrastrukturen. PÄ bilden till vÀnster förestÀller de flerfÀrgade blocken block av ryggradsomkopplare pÄ första nivÄn, Ätta stycken vardera, och fyra buntar av kablar som kommer frÄn dem, som gÄr och korsar buntarna som kommer frÄn blocken av ryggrads-2-omkopplare .
SmÄ rutor indikerar korsningar. LÀngst upp till vÀnster Àr en uppdelning av varje sÄdan korsning, detta Àr faktiskt en 512 x 512 portar korskopplingsmodul som packar om kablarna sÄ att de kommer helt i ett rack, dÀr det bara finns ett spine-2-plan. Och till höger Àr en skanning av den hÀr bilden lite mer detaljerad i förhÄllande till flera Pods pÄ ryggrad-1-nivÄ, och hur den Àr förpackad i en korskoppling, hur det kommer till ryggrads-2-nivÄ.
SÄ hÀr ser det ut. Det Ànnu inte fÀrdigmonterade stativet Spine-2 (till vÀnster) och korskopplingsstativet. TyvÀrr finns det inte mycket att se dÀr. Hela den hÀr strukturen distribueras just nu i ett av vÄra stora datacenter som hÄller pÄ att byggas ut. Det hÀr Àr ett pÄgÄende arbete, det kommer att se snyggare ut, det kommer att fyllas i bÀttre.
En viktig frÄga: vi valde den logiska topologin och byggde fysiken. Vad kommer att hÀnda med kontrollplanet? Det Àr ganska vÀlkÀnt frÄn operativ erfarenhet, det finns ett antal rapporter som visar att lÀnktillstÄndsprotokoll Àr bra, det Àr ett nöje att arbeta med dem, men tyvÀrr kan de inte skalas bra pÄ en tÀtt sammankopplad topologi. Och det finns en huvudfaktor som förhindrar detta - det hÀr Àr hur översvÀmning fungerar i lÀnktillstÄndsprotokoll. Om du bara tar flooding-algoritmen och tittar pÄ hur vÄrt nÀtverk Àr uppbyggt kan du se att det blir en vÀldigt stor fanout vid varje steg, och det kommer helt enkelt att översvÀmma kontrollplanet med uppdateringar. Specifikt blandas sÄdana topologier mycket dÄligt med den traditionella översvÀmningsalgoritmen i lÀnktillstÄndsprotokoll.
Valet Àr att anvÀnda BGP. Hur man förbereder det korrekt beskrivs i RFC 7938 om anvÀndningen av BGP i stora datacenter. De grundlÀggande idéerna Àr enkla: minsta antal prefix per vÀrd och generellt minsta antal prefix pÄ nÀtverket, anvÀnd aggregering om möjligt och undertryck sökvÀg. Vi vill ha en mycket noggrann, mycket kontrollerad distribution av uppdateringar, det som kallas dalfri. Vi vill att uppdateringar ska distribueras exakt en gÄng nÀr de passerar nÀtverket. Om de har sitt ursprung i botten gÄr de upp och vecklas ut inte mer Àn en gÄng. Det ska inte finnas nÄgra sicksackar. Sicksack Àr vÀldigt dÄligt.
För att göra detta anvÀnder vi en design som Àr enkel nog att anvÀnda de underliggande BGP-mekanismerna. Det vill sÀga, vi anvÀnder eBGP som körs pÄ lokala lÀnkar och autonoma system tilldelas enligt följande: ett autonomt system pÄ ToR, ett autonomt system pÄ hela blocket av spine-1-omkopplare i en Pod, och ett allmÀnt autonomt system pÄ hela Top av tyg. Det Àr inte svÄrt att se och se att Àven det normala beteendet hos BGP ger oss den distribution av uppdateringar som vi vill ha.
Naturligtvis mÄste adressering och adressaggregation utformas sÄ att det Àr förenligt med hur routing Àr uppbyggt, sÄ att det sÀkerstÀller stabiliteten i kontrollplanet. L3-adressering i transport Àr knuten till topologin, för utan denna Àr det omöjligt att uppnÄ aggregering; utan detta kommer individuella adresser att krypa in i routingsystemet. Och en sak till Àr att aggregering, tyvÀrr, inte blandas sÀrskilt bra med multi-path, för nÀr vi har multi-path och vi har aggregering Àr allt bra, nÀr hela nÀtverket Àr friskt finns det inga fel i det. TyvÀrr, sÄ snart fel uppstÄr i nÀtverket och topologins symmetri gÄr förlorad, kan vi komma till den punkt frÄn vilken enheten tillkÀnnagavs, frÄn vilken vi inte kan gÄ lÀngre dit vi behöver gÄ. DÀrför Àr det bÀst att aggregera dÀr det inte finns nÄgra flervÀgar, i vÄrt fall Àr dessa ToR-switchar.
Det gĂ„r faktiskt att aggregera, men försiktigt. Om vi ââkan göra kontrollerad disaggregering nĂ€r nĂ€tverksfel uppstĂ„r. Men det hĂ€r Ă€r en ganska svĂ„r uppgift, vi undrade till och med om det skulle vara möjligt att göra detta, om det var möjligt att lĂ€gga till ytterligare automatisering och finita tillstĂ„ndsmaskiner som korrekt skulle sparka BGP för att fĂ„ önskat beteende. TyvĂ€rr Ă€r behandlingen av hörnĂ€renden mycket icke-uppenbar och komplex, och denna uppgift löses inte vĂ€l genom att bifoga externa bilagor till BGP.
Mycket intressant arbete i detta avseende har gjorts inom ramen för RIFT-protokollet, vilket kommer att diskuteras i nÀsta rapport.
En annan viktig sak Àr hur dataplan skalas i tÀta topologier, dÀr vi har ett stort antal alternativa vÀgar. I detta fall anvÀnds flera ytterligare datastrukturer: ECMP-grupper, som i sin tur beskriver Next Hop-grupper.
I ett normalt fungerande nÀtverk, utan fel, nÀr vi gÄr upp i Clos-topologin rÀcker det med att bara anvÀnda en grupp, eftersom allt som inte Àr lokalt beskrivs som standard, vi kan gÄ upp. NÀr vi gÄr frÄn topp till botten till söder, dÄ Àr inte alla stigar ECMP, de Àr enkelvÀgar. Allt Àr bra. Problemet Àr, och det speciella med den klassiska Clos-topologin Àr att om vi tittar pÄ toppen av tyget, pÄ vilket element som helst, sÄ finns det bara en vÀg till vilket element som helst nedanför. Om fel uppstÄr lÀngs den hÀr vÀgen, blir just detta element högst upp pÄ fabriken ogiltigt just för de prefix som ligger bakom den brutna vÀgen. Men för resten Àr det giltigt, och vi mÄste analysera ECMP-grupperna och införa en ny stat.
Hur ser dataplans skalbarhet ut pĂ„ moderna enheter? Om vi ââgör LPM (longest prefix match) Ă€r allt ganska bra, över 100k prefix. Om vi ââpratar om Next Hop-grupper sĂ„ Ă€r allt vĂ€rre, 2-4 tusen. Om vi ââpratar om en tabell som innehĂ„ller en beskrivning av Next Hops (eller adjacencies), sĂ„ Ă€r detta nĂ„gonstans frĂ„n 16k till 64k. Och detta kan bli ett problem. Och hĂ€r kommer vi till en intressant utvikning: vad hĂ€nde med MPLS i datacenter? I princip ville vi göra det.
TvÄ saker hÀnde. Vi gjorde mikrosegmentering pÄ vÀrdarna, vi behövde inte lÀngre göra det pÄ nÀtverket. Det var inte sÀrskilt bra med stöd frÄn olika leverantörer, och Ànnu mer med öppna implementeringar pÄ vita rutor med MPLS. Och MPLS, Ätminstone dess traditionella implementeringar, kombinerar tyvÀrr mycket dÄligt med ECMP. Och det Àr varför.
SÄ hÀr ser ECMP:s vidarebefordranstruktur för IP ut. Ett stort antal prefix kan anvÀnda samma grupp och samma Next Hops-block (eller adjacencies, detta kan kallas olika i olika dokumentation för olika enheter). PoÀngen Àr att detta beskrivs som den utgÄende porten och vad man ska skriva om MAC-adressen till för att komma till rÀtt Next Hop. För IP ser allt enkelt ut, du kan anvÀnda ett mycket stort antal prefix för samma grupp, samma Next Hops-block.
Den klassiska MPLS-arkitekturen innebÀr att etiketten, beroende pÄ det utgÄende grÀnssnittet, kan skrivas om till olika vÀrden. DÀrför mÄste vi ha en grupp och ett Next Hops-block för varje ingÄngsetikett. Och detta, tyvÀrr, skalar inte.
Det Àr lÀtt att se att i vÄr design behövde vi cirka 4000 ToR-switchar, den maximala bredden var 64 ECMP-banor, om vi gÄr bort frÄn ryggrad-1 mot ryggrad-2. Vi kommer knappt in i en tabell med ECMP-grupper, om bara ett prefix med ToR försvinner, och vi kommer inte in i Next Hops-tabellen alls.
Allt Àr inte hopplöst, eftersom arkitekturer som Segment Routing involverar globala etiketter. Formellt skulle det vara möjligt att kollapsa alla dessa Next Hops-block igen. För att göra detta behöver du en operation med jokertecken: ta en etikett och skriv om den till samma utan ett specifikt vÀrde. Men tyvÀrr Àr detta inte sÀrskilt nÀrvarande i de tillgÀngliga implementeringarna.
Och slutligen mÄste vi fÄ extern trafik till datacentret. Hur man gör det? Tidigare har trafik införts i Clos-nÀtet frÄn ovan. Det vill sÀga att det fanns kantroutrar som kopplade till alla enheter pÄ Top of fabric. Denna lösning fungerar ganska bra pÄ smÄ till medelstora storlekar. TyvÀrr, för att skicka trafik symmetriskt till hela nÀtverket pÄ detta sÀtt, mÄste vi komma fram samtidigt till alla delar av Top of-tyget, och nÀr det finns fler Àn hundra av dem visar det sig att vi ocksÄ behöver en stor radix pÄ kantroutrarna. I allmÀnhet kostar detta pengar, eftersom kantroutrar Àr mer funktionella, portarna pÄ dem blir dyrare och designen Àr inte sÀrskilt vacker.
Ett annat alternativ Àr att starta sÄdan trafik underifrÄn. Det Àr lÀtt att verifiera att Clos-topologin Àr byggd pÄ ett sÄdant sÀtt att trafik som kommer underifrÄn, det vill sÀga frÄn ToR-sidan, fördelas jÀmnt mellan nivÄerna över hela Top of-tyget i tvÄ iterationer, vilket laddar hela nÀtverket. DÀrför introducerar vi en speciell typ av Pod, Edge Pod, som ger extern anslutning.
Det finns ett alternativ till. Det Àr vad Facebook gör till exempel. De kallar det Fabric Aggregator eller HGRID. En extra ryggradsnivÄ införs för att ansluta flera datacenter. Denna design Àr möjlig om vi inte har ytterligare funktioner eller inkapslingsförÀndringar vid grÀnssnitten. Om de Àr ytterligare kontaktpunkter Àr det svÄrt. Vanligtvis finns det fler funktioner och ett slags membran som separerar olika delar av datacentret. Det Àr ingen mening att göra ett sÄdant membran stort, men om det verkligen behövs av nÄgon anledning, Àr det vettigt att övervÀga möjligheten att ta bort det, göra det sÄ brett som möjligt och överföra det till vÀrdarna. Detta görs till exempel av mÄnga molnoperatörer. De har överlÀgg, de utgÄr frÄn vÀrdarna.
Vilka utvecklingsmöjligheter ser vi? Först och frÀmst förbÀttra stödet för CI/CD-pipeline. Vi vill flyga som vi testar och testa hur vi flyger. Detta fungerar inte sÀrskilt bra, eftersom infrastrukturen Àr stor och det Àr omöjligt att duplicera den för tester. Du mÄste förstÄ hur man introducerar testelement i produktionsinfrastrukturen utan att tappa det.
BÀttre instrumentering och bÀttre övervakning Àr nÀstan aldrig överflödiga. Hela frÄgan Àr en balans mellan anstrÀngning och avkastning. Om du kan lÀgga till det med rimlig anstrÀngning, mycket bra.
Ăppna operativsystem för nĂ€tverksenheter. BĂ€ttre protokoll och bĂ€ttre routingsystem, som RIFT. Forskning behövs ocksĂ„ om anvĂ€ndningen av bĂ€ttre system för överbelastningskontroll och kanske införandet, Ă„tminstone vid vissa tillfĂ€llen, av RDMA-stöd inom klustret.
Ser vi lÀngre in i framtiden behöver vi avancerade topologier och möjligen nÀtverk som anvÀnder mindre overhead. Av de frÀscha sakerna har det nyligen kommit publikationer om tygteknologin för HPC Cray Slingshot, som Àr baserad pÄ rÄvaru-Ethernet, men med möjlighet att anvÀnda mycket kortare headers. Som ett resultat minskar omkostnader.
Allt ska hÄllas sÄ enkelt som möjligt, men inte enklare. Komplexitet Àr skalbarhetens fiende. Enkelhet och regelbundna strukturer Àr vÄra vÀnner. Om du kan skala ut nÄgonstans, gör det. Och i allmÀnhet Àr det bra att vara involverad i nÀtverksteknik nu. Det Àr mÄnga intressanta saker pÄ gÄng. Tack.
KĂ€lla: will.com