We hebben een datacenternetwerkontwerp ontwikkeld dat de inzet mogelijk maakt van computerclusters groter dan 100 servers met een piekbandbreedte van meer dan één petabyte per seconde.
Uit het rapport van Dmitry Afanasyev leer je over de basisprincipes van het nieuwe ontwerp, het schalen van topologieën, de problemen die hiermee gepaard gaan, opties om ze op te lossen, de kenmerken van routering en het schalen van de doorstuurvlakfuncties van moderne netwerkapparaten in “dicht verbonden” topologieën met een groot aantal ECMP-routes. Daarnaast sprak Dima kort over de organisatie van externe connectiviteit, de fysieke laag, het bekabelingssysteem en manieren om de capaciteit verder te vergroten.
- Goedenavond iedereen! Mijn naam is Dmitry Afanasyev, ik ben netwerkarchitect bij Yandex en ontwerp voornamelijk datacenternetwerken.
Mijn verhaal gaat over het bijgewerkte netwerk van Yandex-datacenters. Het is in hoge mate een evolutie van het ontwerp dat we hadden, maar tegelijkertijd zijn er enkele nieuwe elementen. Dit is een overzichtspresentatie omdat er in een korte tijd veel informatie moest worden verpakt. We beginnen met het kiezen van een logische topologie. Vervolgens zal er een overzicht zijn van het besturingsvlak en problemen met de schaalbaarheid van het datavlak, een keuze van wat er op fysiek niveau zal gebeuren, en zullen we enkele kenmerken van de apparaten bekijken. Laten we even ingaan op wat er gebeurt in een datacenter met MPLS, waar we het een tijdje geleden over hadden.
Dus, wat is Yandex in termen van ladingen en diensten? Yandex is een typische hyperscaler. Als we naar de gebruikers kijken, verwerken we vooral gebruikersverzoeken. Ook diverse streamingdiensten en dataoverdracht, want we hebben ook opslagdiensten. Als het dichter bij de backend ligt, verschijnen daar infrastructuurbelastingen en -diensten, zoals gedistribueerde objectopslag, gegevensreplicatie en, uiteraard, aanhoudende wachtrijen. Een van de belangrijkste soorten werklasten is MapReduce en soortgelijke systemen, streamverwerking, machine learning, enz.
Hoe is de infrastructuur waarop dit allemaal gebeurt? Nogmaals, we zijn een vrij typische hyperscaler, hoewel we misschien iets dichter bij de mindere hyperscaler-kant van het spectrum zitten. Maar we hebben alle attributen. Waar mogelijk maken we gebruik van commodity-hardware en horizontale schaling. We hebben volledige resourcepooling: we werken niet met individuele machines, individuele racks, maar combineren ze tot een grote pool van uitwisselbare resources met enkele aanvullende diensten die te maken hebben met planning en toewijzing, en werken met deze hele pool.
We hebben dus het volgende niveau: het besturingssysteem op computerclusterniveau. Het is heel belangrijk dat we de technologiestapel die we gebruiken volledig beheersen. Wij controleren de endpoints (hosts), het netwerk en de softwarestack.
We hebben verschillende grote datacenters in Rusland en in het buitenland. Ze zijn verenigd door een ruggengraat die gebruik maakt van MPLS-technologie. Onze interne infrastructuur is bijna volledig op IPv6 gebouwd, maar aangezien we extern verkeer moeten bedienen dat nog steeds voornamelijk via IPv4 komt, moeten we op de een of andere manier verzoeken die via IPv4 komen, aan de frontend-servers bezorgen, en een beetje meer gaan naar extern IPv4-internet. bijvoorbeeld voor indexering.
De laatste paar iteraties van datacenternetwerkontwerpen hebben meerlaagse Clos-topologieën gebruikt en zijn alleen L3. We verlieten L2 een tijdje geleden en haalden opgelucht adem. Ten slotte omvat onze infrastructuur honderdduizenden reken(server)instances. De maximale clustergrootte enige tijd geleden was ongeveer 10 servers. Dit is grotendeels te danken aan de manier waarop diezelfde besturingssystemen, planners, toewijzing van middelen, enz. op clusterniveau kunnen werken. Sinds er vooruitgang is geboekt op het gebied van infrastructuursoftware, is de beoogde omvang nu ongeveer 100 servers in één computercluster, We hebben een taak: netwerkfabrieken kunnen bouwen die een efficiënte bundeling van hulpbronnen in zo'n cluster mogelijk maken.
Wat willen we van een datacenternetwerk? Allereerst is er veel goedkope en redelijk uniform verdeelde bandbreedte. Omdat het netwerk de ruggengraat is waarmee we middelen kunnen bundelen. De nieuwe doelgrootte is ongeveer 100 servers in één cluster.
We willen natuurlijk ook een schaalbaar en stabiel besturingsvlak, omdat op zo'n grote infrastructuur veel kopzorgen ontstaan, zelfs door simpelweg willekeurige gebeurtenissen, en we willen niet dat het besturingsvlak ons ook hoofdpijn bezorgt. Tegelijkertijd willen we de staat daarin minimaliseren. Hoe kleiner de aandoening, hoe beter en stabieler alles werkt en hoe gemakkelijker het is om een diagnose te stellen.
Natuurlijk hebben we automatisering nodig, omdat het onmogelijk is om zo’n infrastructuur handmatig te beheren, en dat is al een tijdje onmogelijk. We hebben zoveel mogelijk operationele ondersteuning nodig en CI/CD-ondersteuning voor zover deze kan worden geboden.
Met zulke omvang van datacenters en clusters is de taak van het ondersteunen van incrementele implementatie en uitbreiding zonder onderbreking van de dienstverlening behoorlijk acuut geworden. Als clusters ter grootte van duizend machines, misschien bijna tienduizend machines, nog steeds als één operatie zouden kunnen worden uitgerold - dat wil zeggen, we plannen een uitbreiding van de infrastructuur, en er worden enkele duizenden machines toegevoegd als één operatie. dan ontstaat een cluster ter grootte van honderdduizend machines niet onmiddellijk op deze manier, maar wordt het in de loop van de tijd opgebouwd. En het is wenselijk dat al die tijd datgene wat al is weggepompt, de infrastructuur die is ingezet, beschikbaar is.
En één vereiste die we hadden en achterlieten: ondersteuning voor multitenancy, dat wil zeggen virtualisatie of netwerksegmentatie. Nu hoeven we dit niet op het niveau van de netwerkinfrastructuur te doen, omdat de sharding naar de hosts is gegaan, en dit heeft het schalen voor ons heel gemakkelijk gemaakt. Dankzij IPv6 en een grote adresruimte hoefden we geen dubbele adressen te gebruiken in de interne infrastructuur; alle adressering was al uniek. En dankzij het feit dat we filtering en netwerksegmentatie naar de hosts hebben doorgevoerd, hoeven we geen virtuele netwerkentiteiten in datacenternetwerken te creëren.
Een heel belangrijk ding is wat we niet nodig hebben. Als sommige functies uit het netwerk kunnen worden verwijderd, wordt het leven veel eenvoudiger en wordt in de regel de keuze aan beschikbare apparatuur en software vergroot, waardoor diagnostiek zeer eenvoudig wordt.
Dus wat hebben we niet nodig, wat hebben we kunnen opgeven, niet altijd met vreugde toen het gebeurde, maar met grote opluchting toen het proces voltooid was?
Allereerst het verlaten van L2. We hebben geen L2 nodig, noch echt, noch geëmuleerd. Ongebruikt, grotendeels vanwege het feit dat wij de applicatiestack beheren. Onze applicaties zijn horizontaal schaalbaar, ze werken met L3-adressering, ze zijn niet erg bezorgd dat een individuele instance uitgevallen is, ze rollen gewoon een nieuwe uit, deze hoeft niet op het oude adres uitgerold te worden, want er is een afzonderlijk niveau van servicedetectie en monitoring van machines in het cluster. Wij delegeren deze taak niet aan het netwerk. De taak van het netwerk is om pakketten van punt A naar punt B te bezorgen.
We hebben ook geen situaties waarin adressen binnen het netwerk bewegen, en dit moet worden gemonitord. In veel ontwerpen is dit doorgaans nodig om VM-mobiliteit te ondersteunen. We maken geen gebruik van de mobiliteit van virtuele machines in de interne infrastructuur van de grote Yandex, en bovendien zijn we van mening dat zelfs als dit wel gebeurt, dit niet mag gebeuren met netwerkondersteuning. Als je dit echt moet doen, moet je het op hostniveau doen en adressen pushen die naar overlays kunnen migreren, om het routeringssysteem van de underlay zelf (transportnetwerk) niet te raken of te veel dynamische wijzigingen aan te brengen. .
Een andere technologie die we niet gebruiken is multicast. Als je wilt, kan ik je in detail vertellen waarom. Dit maakt het leven veel gemakkelijker, want als iemand ermee te maken heeft gehad en heeft gekeken hoe het multicast-besturingsvlak er precies uitziet, in alle installaties behalve de eenvoudigste, is dit een grote hoofdpijn. En bovendien is het lastig om bijvoorbeeld een goed werkende open source-implementatie te vinden.
Ten slotte ontwerpen we onze netwerken zo dat ze niet te veel veranderen. We kunnen erop rekenen dat de stroom externe gebeurtenissen in het routeringssysteem klein is.
Welke problemen doen zich voor en met welke beperkingen moet rekening worden gehouden bij de ontwikkeling van een datacenternetwerk? Kosten natuurlijk. Schaalbaarheid, het niveau waarnaar we willen groeien. De noodzaak om uit te breiden zonder de service stop te zetten. Bandbreedte, beschikbaarheid. Zichtbaarheid van wat er op het netwerk gebeurt voor monitoringsystemen, voor operationele teams. Automatiseringsondersteuning - wederom zoveel mogelijk, omdat verschillende taken op verschillende niveaus kunnen worden opgelost, inclusief de introductie van extra lagen. Nou ja, niet [mogelijk] afhankelijk van leveranciers. Hoewel deze onafhankelijkheid in verschillende historische perioden, afhankelijk van welke sectie je bekijkt, gemakkelijker of moeilijker te bereiken was. Als we een dwarsdoorsnede van netwerkapparaatchips nemen, was het tot voor kort zeer voorwaardelijk om te praten over onafhankelijkheid van leveranciers, als we ook chips met een hoge doorvoer wilden.
Welke logische topologie gaan we gebruiken om ons netwerk op te bouwen? Dit wordt een Clos met meerdere niveaus. Eigenlijk zijn er op dit moment geen echte alternatieven. En de Clos-topologie is behoorlijk goed, zelfs in vergelijking met verschillende geavanceerde topologieën die nu meer op het gebied van academisch belang liggen, als we grote radixschakelaars hebben.
Hoe is een Clos-netwerk met meerdere niveaus grofweg opgebouwd en hoe worden de verschillende elementen daarin genoemd? Allereerst stak de wind op, om je te oriënteren waar het noorden is, waar het zuiden is, waar het oosten is, waar het westen is. Dit soort netwerken worden doorgaans gebouwd door degenen die een zeer groot west-oostverkeer hebben. Wat de overige elementen betreft, bevindt zich bovenaan een virtuele schakelaar die is samengesteld uit kleinere schakelaars. Dit is het hoofdidee van de recursieve constructie van Clos-netwerken. We nemen elementen met een bepaalde radix en verbinden ze zodat wat we krijgen kan worden beschouwd als een schakelaar met een grotere radix. Als u nog meer nodig heeft, kan de procedure worden herhaald.
In gevallen waarin het bijvoorbeeld mogelijk is om met Clos op twee niveaus duidelijk componenten te identificeren die verticaal zijn in mijn diagram, worden ze meestal vlakken genoemd. Als we een Clos zouden bouwen met drie niveaus van wervelkolomschakelaars (die allemaal geen grens- of ToR-schakelaars zijn en die alleen worden gebruikt voor doorvoer), dan zouden de vlakken er complexer uitzien; de vliegtuigen met twee niveaus zien er precies zo uit. We noemen een blok ToR- of leaf-schakelaars en de daaraan gekoppelde wervelkolomschakelaars van het eerste niveau een Pod. De wervelkolomschakelaars van het wervelkolom-1-niveau aan de bovenkant van de Pod zijn de bovenkant van de Pod, de bovenkant van de Pod. De schakelaars die zich bovenaan de gehele fabriek bevinden vormen de toplaag van de fabriek, Top of fabric.
Natuurlijk rijst de vraag: Clos-netwerken worden al een tijdje gebouwd; het idee zelf komt over het algemeen uit de tijd van de klassieke telefonie, TDM-netwerken. Misschien is er iets beters verschenen, misschien kan er iets beters gedaan worden? Ja en nee. Theoretisch wel, in de praktijk in de nabije toekomst zeker niet. Omdat er een aantal interessante topologieën zijn, worden sommige zelfs in productie gebruikt; Dragonfly wordt bijvoorbeeld gebruikt in HPC-toepassingen; Er zijn ook interessante topologieën zoals Xpander, FatClique, Jellyfish. Als je recentelijk naar de rapporten op conferenties als SIGCOMM of NSDI kijkt, kun je een vrij groot aantal werken vinden over alternatieve topologieën die (de een of de ander) betere eigenschappen hebben dan Clos.
Maar al deze topologieën hebben één interessante eigenschap. Het verhindert de implementatie ervan in datacenternetwerken, die we proberen te bouwen op basishardware en die redelijk geld kosten. In al deze alternatieve topologieën is het grootste deel van de bandbreedte helaas niet toegankelijk via de kortste paden. Daarom verliezen we onmiddellijk de mogelijkheid om het traditionele besturingsvlak te gebruiken.
Theoretisch is de oplossing voor het probleem bekend. Dit zijn bijvoorbeeld wijzigingen van de verbindingsstatus met behulp van het k-kortste pad, maar nogmaals, er zijn geen dergelijke protocollen die in productie zouden worden geïmplementeerd en algemeen beschikbaar zouden zijn op apparatuur.
Omdat het grootste deel van de capaciteit niet toegankelijk is via de kortste paden, moeten we bovendien meer dan alleen het besturingsvlak aanpassen om al die paden te selecteren (en dit is trouwens aanzienlijk meer status op het besturingsvlak). We moeten het doorstuurvlak nog aanpassen en in de regel zijn er minstens twee extra functies vereist. Dit is de mogelijkheid om alle beslissingen over het doorsturen van pakketten eenmalig te nemen, bijvoorbeeld op de host. In feite is dit bronroutering; in de literatuur over interconnectienetwerken wordt dit soms 'alles-in-één-doorstuurbeslissingen' genoemd. En adaptieve routering is een functie die we nodig hebben op netwerkelementen, wat er bijvoorbeeld op neerkomt dat we de volgende hop selecteren op basis van informatie over de minste belasting van de wachtrij. Er zijn bijvoorbeeld andere opties mogelijk.
De richting is dus interessant, maar helaas kunnen we deze nu niet toepassen.
Oké, we hebben gekozen voor de logische topologie van Clos. Hoe gaan we het opschalen? Laten we eens kijken hoe het werkt en wat er gedaan kan worden.
In een Clos-netwerk zijn er twee hoofdparameters die we op de een of andere manier kunnen variëren en bepaalde resultaten kunnen krijgen: de radix van elementen en het aantal niveaus in het netwerk. Ik heb een schematisch diagram van hoe beide de grootte beïnvloeden. Idealiter combineren we beide.
Het is duidelijk dat de uiteindelijke breedte van het Clos-netwerk het product is van alle niveaus van ruggengraatschakelaars van de zuidelijke radix, hoeveel links we naar beneden hebben, hoe het vertakt. Zo schalen we de omvang van het netwerk.
Wat betreft capaciteit, vooral op ToR-switches, zijn er twee schaalopties. Ofwel kunnen we, met behoud van de algemene topologie, snellere links gebruiken, ofwel kunnen we meer vlakken toevoegen.
Als je naar de uitgebreide versie van het Clos-netwerk kijkt (in de rechter benedenhoek) en terugkeert naar deze foto met het Clos-netwerk hieronder...
... dan is dit precies dezelfde topologie, maar op deze dia is deze compacter samengevouwen en zijn de vlakken van de fabriek over elkaar heen gelegd. Het is hetzelfde.
Hoe ziet het schalen van een Clos-netwerk er in cijfers uit? Hier geef ik gegevens over welke maximale breedte een netwerk kan worden verkregen, welk maximaal aantal racks, ToR-switches of leaf-switches, als ze zich niet in racks bevinden, kunnen we krijgen, afhankelijk van welke radix van switches we gebruiken voor wervelkolomniveaus, en hoeveel niveaus we gebruiken.
Hier ziet u hoeveel racks we kunnen hebben, hoeveel servers en hoeveel dit alles ongeveer kan verbruiken, gebaseerd op 20 kW per rack. Iets eerder vertelde ik dat we mikken op een clustergrootte van ongeveer 100 duizend servers.
Het is duidelijk dat in dit hele ontwerp twee en een halve optie interessant is. Er is een optie met twee lagen stekels en 64-poorts switches, die een beetje tekortschieten. Dan zijn er perfect passende opties voor 128-poorts (met radix 128) ruggengraatschakelaars met twee niveaus, of schakelaars met radix 32 met drie niveaus. En in alle gevallen, waar er meer radixen en meer lagen zijn, kun je een heel groot netwerk maken, maar als je naar het verwachte verbruik kijkt, gaat het meestal om gigawatts. Het is mogelijk om een kabel aan te leggen, maar het is onwaarschijnlijk dat we zoveel elektriciteit op één plek krijgen. Als je naar statistieken en openbare data over datacenters kijkt, kun je maar heel weinig datacenters vinden met een geschatte capaciteit van meer dan 150 MW. De grotere zijn meestal datacentercampussen, verschillende grote datacenters die vrij dicht bij elkaar liggen.
Er is nog een belangrijke parameter. Als u naar de linkerkolom kijkt, wordt daar de bruikbare bandbreedte vermeld. Het is gemakkelijk te zien dat in een Clos-netwerk een aanzienlijk deel van de poorten wordt gebruikt om switches met elkaar te verbinden. Bruikbare bandbreedte, een nuttige strip, is iets dat buiten, richting de servers, gegeven kan worden. Uiteraard heb ik het over voorwaardelijke poorten en specifiek over de band. In de regel zijn koppelingen binnen het netwerk sneller dan koppelingen naar servers, maar per bandbreedte-eenheid, hoeveel we deze ook naar onze serverapparatuur kunnen sturen, is er nog steeds enige bandbreedte binnen het netwerk zelf. En hoe meer niveaus we maken, hoe groter de specifieke kosten voor het aanbrengen van deze streep naar buiten.
Bovendien is zelfs deze extra band niet precies hetzelfde. Hoewel de overspanningen kort zijn, kunnen we zoiets als DAC (direct aangesloten koperen, dat wil zeggen twinax-kabels) of multimode-optica gebruiken, die zelfs min of meer redelijk geld kosten. Zodra we naar langere overspanningen gaan, zijn dit in de regel single-mode optica, en de kosten van deze extra bandbreedte stijgen merkbaar.
En nogmaals, terugkerend naar de vorige dia: als we een Clos-netwerk creëren zonder overabonnement, dan is het gemakkelijk om naar het diagram te kijken en te zien hoe het netwerk is opgebouwd - door elk niveau van wervelkolomschakelaars toe te voegen, herhalen we de hele strook die zich op de onderkant. Plus-niveau - plus dezelfde band, hetzelfde aantal poorten op schakelaars als op het vorige niveau, en hetzelfde aantal transceivers. Daarom is het zeer wenselijk om het aantal niveaus van ruggengraatschakelaars te minimaliseren.
Op basis van dit plaatje is het duidelijk dat we echt willen voortbouwen op zoiets als schakelaars met een radix van 128.
Hier is in principe alles hetzelfde als wat ik zojuist zei; dit is een slide om later over na te denken.
Welke opties zijn er die we als zodanig kunnen kiezen? Het is heel prettig nieuws voor ons dat dergelijke netwerken nu eindelijk op single-chip-switches kunnen worden gebouwd. En dit is erg cool, ze hebben veel leuke functies. Ze hebben bijvoorbeeld vrijwel geen interne structuur. Dit betekent dat ze gemakkelijker breken. Ze breken op allerlei manieren, maar gelukkig breken ze helemaal. In modulaire apparaten is er een groot aantal fouten (zeer onaangenaam), wanneer het vanuit het oogpunt van buren en het besturingsvlak lijkt te werken, maar bijvoorbeeld een deel van de stof verloren is gegaan en niet werkt op volle capaciteit. En het verkeer ernaartoe is gebalanceerd op basis van het feit dat het volledig functioneel is, en we kunnen overbelast raken.
Of er ontstaan bijvoorbeeld problemen met de backplane, omdat er in het modulaire apparaat ook snelle SerDes zitten - van binnen is het erg complex. De borden tussen de doorstuurelementen zijn gesynchroniseerd of niet gesynchroniseerd. Over het algemeen bevat elk productief modulair apparaat dat uit een groot aantal elementen bestaat, in de regel hetzelfde Clos-netwerk in zichzelf, maar het is erg moeilijk om een diagnose te stellen. Vaak is het zelfs voor de verkoper zelf moeilijk om een diagnose te stellen.
En het kent een groot aantal faalscenario's waarin het apparaat degradeert, maar niet volledig uit de topologie valt. Omdat ons netwerk groot is, wordt er actief gebruik gemaakt van balancering tussen identieke elementen, het netwerk is zeer regelmatig, dat wil zeggen dat het ene pad waarop alles in orde is niet verschilt van het andere pad, het is voor ons winstgevender om simpelweg een deel van ons netwerk te verliezen de apparaten uit de topologie dan om in een situatie terecht te komen waarin sommige ervan lijken te werken, maar andere niet.
Het volgende leuke kenmerk van apparaten met één chip is dat ze beter en sneller evolueren. Ze hebben doorgaans ook een betere capaciteit. Als we de grote geassembleerde structuren die we hebben op een cirkel nemen, dan is de capaciteit per rackeenheid voor poorten met dezelfde snelheid bijna twee keer zo goed als die van modulaire apparaten. Apparaten die rond één chip zijn gebouwd, zijn merkbaar goedkoper dan modulaire apparaten en verbruiken minder energie.
Maar dit heeft natuurlijk allemaal een reden, er zijn ook nadelen. Ten eerste is de radix vrijwel altijd kleiner dan die van modulaire apparaten. Als we een apparaat rond één chip met 128 poorten kunnen bouwen, kunnen we nu zonder problemen een modulair apparaat krijgen met enkele honderden poorten.
Dit is een merkbaar kleiner formaat van doorstuurtabellen en, in de regel, alles wat te maken heeft met de schaalbaarheid van het datavlak. Ondiepe buffers. En in de regel vrij beperkte functionaliteit. Maar het blijkt dat als je deze beperkingen kent en er op tijd voor zorgt dat je ze omzeilt of er gewoon rekening mee houdt, dit niet zo eng is. Dat de radix kleiner is, is op apparaten met een radix van 128 die eindelijk onlangs zijn verschenen geen probleem meer; we kunnen twee lagen stekels inbouwen. Maar het is nog steeds onmogelijk om iets kleiner dan twee te bouwen dat interessant voor ons is. Met één niveau worden zeer kleine clusters verkregen. Zelfs onze eerdere ontwerpen en eisen overtroffen deze nog steeds.
Als de oplossing opeens op het randje staat, is er nog steeds een manier om op te schalen. Omdat het laatste (of eerste), laagste niveau waarop servers zijn aangesloten ToR-switches of leaf-switches zijn, zijn we niet verplicht om er één rack op aan te sluiten. Daarom, als de oplossing ongeveer de helft tekortschiet, kunt u erover nadenken om eenvoudigweg een switch met een grote radix op het lagere niveau te gebruiken en bijvoorbeeld twee of drie racks in één switch aan te sluiten. Dit is ook een optie, het heeft zijn kosten, maar het werkt best goed en kan een goede oplossing zijn als je ongeveer twee keer zo groot moet worden.
Samenvattend bouwen we voort op een topologie met twee niveaus van stekels, met acht fabriekslagen.
Wat gaat er met de natuurkunde gebeuren? Zeer eenvoudige berekeningen. Als we twee niveaus van stekels hebben, dan hebben we slechts drie niveaus van schakelaars, en we verwachten dat er drie kabelsegmenten in het netwerk zullen zijn: van servers tot bladschakelaars, tot ruggengraat 1, tot ruggengraat 2. De opties die we kunnen hebben gebruik zijn - dit zijn twinax, multimode, single mode. En hier moeten we overwegen welke strip beschikbaar is, hoeveel het gaat kosten, wat de fysieke afmetingen zijn, welke overspanningen we kunnen overbruggen en hoe we zullen upgraden.
Qua kosten kan alles op een rij worden gezet. Twinaxen zijn aanzienlijk goedkoper dan actieve optica, goedkoper dan multimode transceivers, als je ze vanaf het einde per vlucht neemt, iets goedkoper dan een 100 gigabit switchpoort. En let op: het kost minder dan single-mode-optiek, omdat het op vluchten waar single-mode vereist is, in datacenters om een aantal redenen zinvol is om CWDM te gebruiken, terwijl parallelle single-mode (PSM) niet erg handig is om te werken hiermee worden zeer grote pakketten vezels verkregen, en als we ons op deze technologieën concentreren, krijgen we ongeveer de volgende prijshiërarchie.
Nog een opmerking: het is helaas niet erg mogelijk om gedemonteerde 100 tot 4x25 multimode-poorten te gebruiken. Vanwege de ontwerpkenmerken van SFP28-transceivers is het niet veel goedkoper dan 28 Gbit QSFP100. En deze demontage voor multimode werkt niet zo goed.
Een andere beperking is dat onze datacenters door de omvang van de rekenclusters en het aantal servers fysiek groot blijken te zijn. Dit betekent dat er minimaal één vlucht met een singlemod zal moeten worden gedaan. Nogmaals, vanwege de fysieke grootte van de Pods zal het niet mogelijk zijn om twee overspanningen van twinax (koperkabels) aan te leggen.
Als gevolg hiervan krijgen we, als we de prijs optimaliseren en rekening houden met de geometrie van dit ontwerp, één span twinax, één span multimode en één span singlemode met behulp van CWDM. Hierbij wordt rekening gehouden met mogelijke upgradepaden.
Dit is hoe het er de laatste tijd uitziet, waar we naartoe gaan en wat er mogelijk is. Het is in ieder geval duidelijk hoe we richting 50-Gigabit SerDes kunnen evolueren voor zowel multimode als singlemode. Als je bovendien kijkt naar wat er nu en in de toekomst in single-mode transceivers zit voor 400G, vaak zelfs als 50G SerDes van de elektrische kant arriveren, kan 100 Gbps per baan al naar optica gaan. Daarom is het heel goed mogelijk dat er in plaats van naar 50 te gaan, een overgang zal plaatsvinden naar 100 Gigabit SerDes en 100 Gbps per lane, omdat volgens de beloften van veel leveranciers de beschikbaarheid ervan vrij snel wordt verwacht. De periode waarin 50G SerDes het snelst was, lijkt niet heel lang meer te duren, want bijna volgend jaar worden de eerste exemplaren van 100G SerDes uitgerold. En na enige tijd zullen ze waarschijnlijk redelijk geld waard zijn.
Nog een nuance over de keuze van de natuurkunde. Met 400G SerDes kunnen we in principe al 200 of 50 Gigabit-poorten gebruiken. Maar het blijkt dat dit niet zoveel zin heeft, omdat we, zoals ik al eerder zei, een vrij grote radix op de schakelaars willen, uiteraard binnen redelijke grenzen. We willen 128. En als we een beperkte chipcapaciteit hebben en we de verbindingssnelheid verhogen, dan neemt de radix natuurlijk af, er zijn geen wonderen.
En we kunnen de totale capaciteit vergroten met behulp van vliegtuigen, en er zijn geen speciale kosten; we kunnen het aantal vliegtuigen toevoegen. En als we de radix verliezen, zullen we een extra niveau moeten introduceren, dus in de huidige situatie, met de huidige maximaal beschikbare capaciteit per chip, blijkt het efficiënter om 100 gigabit-poorten te gebruiken, omdat je daarmee om een grotere radix te krijgen.
De volgende vraag is hoe de natuurkunde is georganiseerd, maar dan vanuit het perspectief van de kabelinfrastructuur. Het blijkt dat het op een nogal grappige manier is georganiseerd. Bekabeling tussen bladschakelaars en stekels van het eerste niveau - er zijn niet veel verbindingen, alles is relatief eenvoudig gebouwd. Maar als we één vlak nemen, gebeurt er binnenin dat we alle stekels van het eerste niveau moeten verbinden met alle stekels van het tweede niveau.
Bovendien zijn er in de regel enkele wensen over hoe het er binnen in het datacenter uit moet zien. We wilden bijvoorbeeld heel graag kabels samenvoegen tot een bundel en deze zo trekken dat één high-density patchpaneel geheel in één patchpaneel zou gaan, zodat er qua lengtes geen dierentuin zou ontstaan. Wij zijn erin geslaagd dit probleem op te lossen. Als je in eerste instantie naar de logische topologie kijkt, kun je zien dat de vlakken onafhankelijk zijn, elk vlak kan op zichzelf worden gebouwd. Maar als we zo'n bundeling toevoegen en het hele patchpaneel in een patchpaneel willen slepen, moeten we verschillende vlakken binnen één bundel mixen en een tussenstructuur introduceren in de vorm van optische dwarsverbindingen om ze opnieuw te verpakken op de manier waarop ze zijn geassembleerd. op het ene segment, in de manier waarop ze op een ander segment worden verzameld. Hierdoor krijgen we een leuke feature: al het complexe schakelen gaat niet verder dan de racks. Wanneer je iets heel sterk met elkaar moet verweven, ‘de vlakken ontvouwen’, zoals het soms in Clos-netwerken wordt genoemd, is het allemaal geconcentreerd in één rek. We hebben geen sterk gedemonteerde, tot aan individuele schakels toe, schakelen tussen racks.
Zo ziet het er uit vanuit het oogpunt van de logische organisatie van de kabelinfrastructuur. Op de afbeelding aan de linkerkant tonen de veelkleurige blokken blokken van ruggengraatschakelaars van het eerste niveau, elk acht stuks, en vier bundels kabels die daaruit komen, die gaan en elkaar kruisen met de bundels die uit de blokken van ruggengraat-2-schakelaars komen. .
Kleine vierkantjes geven kruispunten aan. Linksboven ziet u een uitsplitsing van elk dergelijk kruispunt. Dit is eigenlijk een cross-connect-module van 512 bij 512 poorten die de kabels opnieuw verpakt, zodat ze volledig in één rek komen, waar er slechts één ruggengraat-2-vlak is. En aan de rechterkant is een scan van deze foto iets gedetailleerder met betrekking tot verschillende Pods op het wervelkolom-1-niveau, en hoe het is verpakt in een cross-connect, hoe het op het wervelkolom-2-niveau komt.
Dit is hoe het eruit ziet. De nog niet volledig gemonteerde Spine-2-standaard (links) en de Cross-Connect-standaard. Helaas is daar niet veel te zien. Deze hele structuur wordt momenteel ingezet in een van onze grote datacenters die wordt uitgebreid. Dit is een work in progress, het zal er mooier uitzien, het zal beter ingevuld worden.
Een belangrijke vraag: we kozen de logische topologie en bouwden de fysica. Wat gebeurt er met het besturingsvlak? Uit operationele ervaring is het vrij goed bekend dat er een aantal rapporten zijn die staatsprotocollen met elkaar verbinden. Het is een plezier om ermee te werken, maar helaas schalen ze niet goed op een dicht verbonden topologie. En er is één belangrijke factor die dit voorkomt: dit is hoe flooding werkt in linkstate-protocollen. Als je alleen maar het flooding-algoritme neemt en kijkt naar hoe ons netwerk is gestructureerd, kun je zien dat er bij elke stap een zeer grote fan-out zal zijn, en dat dit het controlevlak eenvoudigweg zal overspoelen met updates. Concreet gaan dergelijke topologieën zeer slecht samen met het traditionele flooding-algoritme in verbindingsstatusprotocollen.
De keuze is om BGP te gebruiken. Hoe je dit correct kunt voorbereiden, staat beschreven in RFC 7938 over het gebruik van BGP in grote datacenters. De basisideeën zijn eenvoudig: een minimaal aantal voorvoegsels per host en doorgaans een minimaal aantal voorvoegsels op het netwerk, gebruik indien mogelijk aggregatie en onderdruk het zoeken naar paden. We willen een zeer zorgvuldige, zeer gecontroleerde distributie van updates, wat dalvrij wordt genoemd. We willen dat updates precies één keer worden geïmplementeerd wanneer ze door het netwerk gaan. Als ze van onderaf ontstaan, gaan ze omhoog en ontvouwen ze zich niet vaker dan één keer. Er mogen geen zigzaglijnen zijn. Zigzags zijn erg slecht.
Om dit te doen, gebruiken we een ontwerp dat eenvoudig genoeg is om de onderliggende BGP-mechanismen te gebruiken. Dat wil zeggen dat we eBGP gebruiken die op link local draait, en autonome systemen worden als volgt toegewezen: een autonoom systeem op ToR, een autonoom systeem op het hele blok Spine-1-schakelaars van één Pod, en een algemeen autonoom systeem op de hele Top van stof. Het is niet moeilijk om te zien dat zelfs het normale gedrag van BGP ons de distributie van updates geeft die we willen.
Uiteraard moeten adressering en adresaggregatie zo worden ontworpen dat deze compatibel zijn met de manier waarop routering is opgebouwd, zodat deze de stabiliteit van het besturingsvlak garandeert. L3-adressering in transport is gebonden aan de topologie, omdat het zonder dit onmogelijk is om aggregatie te bereiken; zonder dit zullen individuele adressen in het routeringssysteem kruipen. En nog een ding is dat aggregatie helaas niet zo goed samengaat met multi-path, want als we multi-path hebben en we hebben aggregatie, is alles in orde, als het hele netwerk gezond is, zijn er geen fouten in. Helaas kunnen we, zodra er storingen in het netwerk optreden en de symmetrie van de topologie verloren gaat, op het punt komen van waaruit de eenheid werd aangekondigd, van waaruit we niet verder kunnen gaan naar waar we heen moeten. Daarom is het het beste om te aggregeren waar er geen multi-path meer is, in ons geval zijn dit ToR-switches.
In feite is het mogelijk om te aggregeren, maar zorgvuldig. Als we gecontroleerde disaggregatie kunnen uitvoeren wanneer er netwerkstoringen optreden. Maar dit is een behoorlijk moeilijke taak, we vroegen ons zelfs af of het mogelijk zou zijn om dit te doen, of het mogelijk was om extra automatisering toe te voegen, en eindige toestandsmachines die BGP correct zouden schoppen om het gewenste gedrag te krijgen. Helaas is het verwerken van hoekzaken niet voor de hand liggend en complex, en deze taak kan niet goed worden opgelost door externe bijlagen aan BGP toe te voegen.
Er is in dit opzicht zeer interessant werk verricht in het kader van het RIFT-protocol, dat in het volgende rapport zal worden besproken.
Een ander belangrijk ding is hoe datavlakken schalen in dichte topologieën, waar we een groot aantal alternatieve paden hebben. In dit geval worden verschillende aanvullende datastructuren gebruikt: ECMP-groepen, die op hun beurt Next Hop-groepen beschrijven.
In een normaal werkend netwerk, zonder fouten, is het voldoende om slechts één groep te gebruiken als we omhoog gaan in de Clos-topologie, omdat alles wat niet lokaal is standaard wordt beschreven, we kunnen omhoog gaan. Als we van boven naar beneden naar het zuiden gaan, zijn niet alle paden ECMP, maar enkelvoudige paden. Alles is in orde. Het probleem is, en het bijzondere van de klassieke Clos-topologie, is dat als we naar de bovenkant van de stof kijken, naar welk element dan ook, er maar één pad is naar elk element daaronder. Als er langs dit pad fouten optreden, wordt dit specifieke element bovenaan de fabriek ongeldig, precies voor de voorvoegsels die achter het gebroken pad liggen. Maar voor de rest is het geldig, en we moeten de ECMP-groepen ontleden en een nieuwe staat introduceren.
Hoe ziet de schaalbaarheid van het datavlak eruit op moderne apparaten? Als we LPM (langste voorvoegselmatch) doen, is alles redelijk goed, meer dan 100 voorvoegsels. Als we het hebben over Next Hop-groepen, dan is alles erger, 2-4 duizend. Als we het hebben over een tabel die een beschrijving van Next Hops (of aangrenzende gebieden) bevat, dan ligt dit ergens tussen de 16k en 64k. En dit kan een probleem worden. En hier komen we bij een interessante uitweiding: wat is er gebeurd met MPLS in datacenters? In principe wilden we het doen.
Er gebeurden twee dingen. We hebben microsegmentatie op de hosts uitgevoerd; we hoefden dit niet langer op het netwerk te doen. Het was niet erg goed met ondersteuning van verschillende leveranciers, en nog meer met open implementaties op witte dozen met MPLS. En MPLS, althans de traditionele implementaties ervan, combineert helaas zeer slecht met ECMP. En dat is waarom.
Dit is hoe de ECMP-doorstuurstructuur voor IP eruit ziet. Een groot aantal voorvoegsels kan dezelfde groep en hetzelfde Next Hops-blok gebruiken (of aangrenzende delen, dit kan in verschillende documentatie voor verschillende apparaten anders worden genoemd). Het punt is dat dit wordt beschreven als de uitgaande poort en waar het MAC-adres naartoe moet worden herschreven om bij de juiste Next Hop te komen. Voor IP ziet alles er eenvoudig uit, je kunt een zeer groot aantal voorvoegsels gebruiken voor dezelfde groep, hetzelfde Next Hops-blok.
De klassieke MPLS-architectuur impliceert dat, afhankelijk van de uitgaande interface, het label kan worden herschreven naar verschillende waarden. Daarom moeten we voor elk invoerlabel een groep en een Next Hops-blok behouden. En dit schaalt helaas niet.
Het is gemakkelijk in te zien dat we in ons ontwerp ongeveer 4000 ToR-switches nodig hadden, de maximale breedte was 64 ECMP-paden, als we van ruggengraat-1 naar ruggengraat-2 gaan. We komen nauwelijks in één tabel met ECMP-groepen terecht, als er maar één voorvoegsel met ToR verdwijnt, en we komen helemaal niet in de Next Hops-tabel terecht.
Het is niet allemaal hopeloos, omdat bij architecturen als Segment Routing mondiale labels betrokken zijn. Formeel zou het mogelijk zijn om al deze Next Hops-blokken weer in elkaar te laten vallen. Om dit te doen, hebt u een bewerking van het jokerteken nodig: neem een label en herschrijf het naar hetzelfde label zonder een specifieke waarde. Maar helaas is dit niet erg aanwezig in de beschikbare implementaties.
En ten slotte moeten we extern verkeer naar het datacenter brengen. Hoe je dat doet? Voorheen werd het verkeer van bovenaf in het Clos-netwerk geïntroduceerd. Dat wil zeggen, er waren edge-routers die verbinding maakten met alle apparaten aan de bovenkant van de stof. Deze oplossing werkt redelijk goed op kleine tot middelgrote maten. Om op deze manier verkeer symmetrisch naar het hele netwerk te sturen, moeten we helaas tegelijkertijd bij alle Top of fabric-elementen aankomen, en als het er meer dan honderd zijn, blijkt dat we ook een grote radix nodig hebben op de edgerouters. Over het algemeen kost dit geld, omdat edge-routers functioneler zijn, de poorten daarop duurder zullen zijn en het ontwerp niet erg mooi is.
Een andere optie is om dergelijk verkeer van onderaf te starten. Het is eenvoudig te verifiëren dat de Clos-topologie zo is opgebouwd dat verkeer dat van onderaf komt, dat wil zeggen van de ToR-kant, gelijkmatig wordt verdeeld over de niveaus door de hele Top of fabric in twee iteraties, waardoor het hele netwerk wordt belast. Daarom introduceren we een speciaal type Pod, Edge Pod, die externe connectiviteit biedt.
Er is nog een optie. Dit is bijvoorbeeld wat Facebook doet. Ze noemen het Fabric Aggregator of HGRID. Er wordt een extra ruggengraatniveau geïntroduceerd om meerdere datacenters met elkaar te verbinden. Dit ontwerp is mogelijk als we geen extra functies of inkapselingswijzigingen op de interfaces hebben. Als het extra contactpunten zijn, is het moeilijk. Meestal zijn er meer functies en is er een soort membraan dat de verschillende delen van het datacenter scheidt. Het heeft geen zin om zo'n membraan groot te maken, maar als het om de een of andere reden echt nodig is, dan is het zinvol om de mogelijkheid te overwegen om het weg te nemen, zo breed mogelijk te maken en over te dragen aan de gastheren. Dit wordt bijvoorbeeld door veel cloudoperators gedaan. Ze hebben overlays, ze beginnen bij de gastheren.
Welke ontwikkelingsmogelijkheden zien wij? Allereerst het verbeteren van de ondersteuning voor de CI/CD-pijplijn. We willen vliegen zoals we testen en testen zoals we vliegen. Dit lukt niet zo goed, omdat de infrastructuur groot is en het onmogelijk is om deze te dupliceren voor tests. U moet begrijpen hoe u testelementen in de productie-infrastructuur kunt introduceren zonder deze te laten vallen.
Betere instrumentatie en betere monitoring zijn vrijwel nooit overbodig. De hele vraag is een evenwicht tussen inspanning en rendement. Als je het met redelijke inspanning kunt toevoegen, heel goed.
Open besturingssystemen voor netwerkapparaten. Betere protocollen en betere routeringssystemen, zoals RIFT. Er is ook onderzoek nodig naar het gebruik van betere congestiecontrolesystemen en wellicht de introductie, althans op sommige punten, van RDMA-ondersteuning binnen het cluster.
Als we verder in de toekomst kijken, hebben we geavanceerde topologieën nodig en mogelijk netwerken die minder overhead gebruiken. Van de nieuwe dingen zijn er onlangs publicaties geweest over de fabric-technologie voor HPC Cray Slingshot, die is gebaseerd op commodity Ethernet, maar met de mogelijkheid om veel kortere headers te gebruiken. Als gevolg hiervan wordt de overhead verminderd.
Alles moet zo eenvoudig mogelijk worden gehouden, maar niet eenvoudiger. Complexiteit is de vijand van schaalbaarheid. Eenvoud en regelmatige structuren zijn onze vrienden. Als je ergens kunt uitschalen, doe dat dan. En over het algemeen is het geweldig om nu betrokken te zijn bij netwerktechnologieën. Er gebeuren veel interessante dingen. Bedankt.
Bron: www.habr.com