Razvili smo zasnovo omrežja podatkovnega centra, ki omogoča uvedbo računalniških gruč, večjih od 100 tisoč strežnikov, s pasovno širino najvišje bisekcije nad en petabajt na sekundo.
Iz poročila Dmitrija Afanasjeva boste spoznali osnovna načela nove zasnove, skalirne topologije, težave, ki se pri tem pojavljajo, možnosti za njihovo rešitev, značilnosti usmerjanja in skaliranja funkcij ravnine posredovanja sodobnih omrežnih naprav v "gosto povezanih" topologije z velikim številom poti ECMP. Poleg tega je Dima na kratko spregovoril o organizaciji zunanje povezljivosti, fizičnem sloju, kablovskem sistemu in načinih nadaljnjega povečanja zmogljivosti.
- Dober dan vsem! Moje ime je Dmitry Afanasyev, sem omrežni arhitekt pri Yandexu in predvsem načrtujem omrežja podatkovnih centrov.
Moja zgodba bo o posodobljenem omrežju podatkovnih centrov Yandex. To je v veliki meri razvoj dizajna, ki smo ga imeli, hkrati pa je nekaj novih elementov. To je pregledna predstavitev, ker je bilo treba v malo časa strniti veliko informacij. Začeli bomo z izbiro logične topologije. Nato bo sledil pregled nadzorne ravnine in težav s skalabilnostjo podatkovne ravnine, izbira, kaj se bo dogajalo na fizičnem nivoju, pogledali pa si bomo nekatere lastnosti naprav. Dotaknimo se še malo dogajanja v podatkovnem centru z MPLS, o katerem smo govorili pred časom.
Torej, kaj je Yandex v smislu obremenitev in storitev? Yandex je tipičen hiperskaler. Če gledamo uporabnike, obdelujemo predvsem zahteve uporabnikov. Tudi različne pretočne storitve in prenos podatkov, saj imamo tudi storitve shranjevanja. Če je bližje zaledju, se tam pojavijo infrastrukturne obremenitve in storitve, kot so shranjevanje porazdeljenih objektov, replikacija podatkov in seveda trajne čakalne vrste. Ena glavnih vrst delovnih obremenitev so MapReduce in podobni sistemi, obdelava tokov, strojno učenje itd.
Kakšna je infrastruktura, na kateri se vse to dogaja? Spet smo precej tipični hiperskalerji, čeprav smo morda nekoliko bližje manj hiperskalerski strani spektra. Imamo pa vse atribute. Kjer koli je to mogoče, uporabljamo standardno strojno opremo in horizontalno skaliranje. Imamo popolno združevanje virov: ne delamo s posameznimi stroji, posameznimi regali, ampak jih združujemo v velik bazen zamenljivih virov z nekaterimi dodatnimi storitvami, ki se ukvarjajo z načrtovanjem in alokacijo, ter delamo s tem celotnim bazenom.
Tako imamo naslednjo raven - operacijski sistem na ravni računalniške gruče. Zelo pomembno je, da v celoti nadzorujemo tehnološki sklad, ki ga uporabljamo. Nadzorujemo končne točke (gostitelje), omrežje in sklad programske opreme.
Imamo več velikih podatkovnih centrov v Rusiji in tujini. Združuje jih hrbtenica, ki uporablja tehnologijo MPLS. Naša notranja infrastruktura je skoraj v celoti zgrajena na IPv6, toda ker moramo služiti zunanjemu prometu, ki še vedno prihaja predvsem prek IPv4, moramo nekako dostaviti zahteve, ki prihajajo prek IPv4, do sprednjih strežnikov, nekaj več pa je treba prenesti na zunanji IPv4-internet - za na primer za indeksiranje.
Zadnjih nekaj iteracij zasnov omrežja podatkovnih centrov je uporabljalo večplastne topologije Clos in so samo L3. Pred časom smo zapustili L2 in si oddahnili. Nazadnje, naša infrastruktura vključuje več sto tisoč računalniških (strežniških) primerkov. Največja velikost gruče pred časom je bila približno 10 tisoč strežnikov. To je v veliki meri posledica tega, kako lahko delujejo ti isti operacijski sistemi na ravni gruče, načrtovalci, dodeljevanje virov itd.. Ker se je zgodil napredek na strani infrastrukturne programske opreme, je zdaj ciljna velikost približno 100 tisoč strežnikov v eni računalniški gruči in Imamo nalogo - biti sposobni zgraditi omrežne tovarne, ki omogočajo učinkovito združevanje virov v takšnem grozdu.
Kaj želimo od omrežja podatkovnih centrov? Najprej je veliko poceni in dokaj enakomerno porazdeljene pasovne širine. Ker je omrežje hrbtenica, prek katere lahko združujemo vire. Nova ciljna velikost je približno 100 tisoč strežnikov v enem grozdu.
Želimo si seveda tudi razširljive in stabilne nadzorne ravnine, saj na tako veliki infrastrukturi veliko preglavic povzročijo že zgolj naključni dogodki in ne želimo, da nam tudi krmilna ravnina povzroča preglavice. Hkrati pa želimo čim bolj zmanjšati stanje v njem. Manjše kot je stanje, bolje in stabilneje vse deluje, lažje ga je diagnosticirati.
Seveda potrebujemo avtomatizacijo, saj je tako infrastrukturo nemogoče upravljati ročno in je že nekaj časa nemogoče. Potrebujemo čim večjo operativno podporo in podporo CI/CD v obsegu, ki ga je mogoče zagotoviti.
Pri takšnih velikostih podatkovnih centrov in gruč je naloga podpore postopnega uvajanja in širitve brez prekinitve storitev postala precej pereča. Če bi jih na grozdih velikosti tisoč strojev, morda blizu deset tisoč strojev, še lahko razgrnili kot eno operacijo - torej načrtujemo širitev infrastrukture in dodamo več tisoč strojev kot eno operacijo, potem grozd velikosti sto tisoč strojev ne nastane takoj, kot je ta, zgrajen je v določenem časovnem obdobju. In zaželeno je, da je ves ta čas na voljo tisto, kar je že bilo izčrpano, infrastruktura, ki je bila razporejena.
In ena zahteva, ki smo jo imeli in je ostala: podpora za multitency, torej virtualizacijo ali segmentacijo omrežja. Zdaj nam tega ni treba narediti na ravni omrežne strukture, ker je razdeljevanje prešlo k gostiteljem, kar nam je poenostavilo skaliranje. Zahvaljujoč IPv6 in velikemu naslovnemu prostoru nam ni bilo treba uporabljati podvojenih naslovov v interni infrastrukturi, vse naslavljanje je bilo že unikatno. In zahvaljujoč dejstvu, da smo filtriranje in segmentacijo omrežja prenesli na gostitelje, nam v omrežjih podatkovnih centrov ni treba ustvarjati nobenih navideznih omrežnih entitet.
Zelo pomembna stvar je, česa ne potrebujemo. Če je mogoče nekatere funkcije odstraniti iz omrežja, to močno olajša življenje in praviloma razširi izbiro razpoložljive opreme in programske opreme, zaradi česar je diagnostika zelo preprosta.
Torej, kaj je tisto, česar ne potrebujemo, čemu smo se lahko odpovedali, ne vedno z veseljem takrat, ko se je to zgodilo, ampak z velikim olajšanjem, ko je proces končan?
Najprej opustitev L2. Ne potrebujemo L2, ne pravega ne emuliranega. Neuporabljeno predvsem zaradi dejstva, da nadziramo sklad aplikacij. Naše aplikacije so horizontalno razširljive, delujejo z naslavljanjem L3, ne skrbijo jih preveč, da je kakšna posamezna instanca ugasnila, enostavno postavijo novo, ni je treba uvesti na starem naslovu, ker obstaja ločena raven odkrivanja storitev in spremljanje strojev, ki se nahajajo v gruči. Te naloge ne prenesemo na omrežje. Naloga omrežja je dostaviti pakete od točke A do točke B.
Prav tako nimamo situacij, ko bi se naslovi premikali znotraj omrežja, in to je treba spremljati. V mnogih modelih je to običajno potrebno za podporo mobilnosti VM. Ne uporabljamo mobilnosti virtualnih strojev v notranji infrastrukturi velikega Yandexa in poleg tega verjamemo, da tudi če se to naredi, se to ne bi smelo zgoditi z omrežno podporo. Če je to res treba storiti, je treba to storiti na ravni gostitelja in potisniti naslove, ki se lahko preselijo v prekrivne elemente, da se ne dotaknete ali naredite preveč dinamičnih sprememb usmerjevalnega sistema podlage (prometnega omrežja) .
Druga tehnologija, ki je ne uporabljamo, je multicast. Če želite, vam lahko podrobno povem, zakaj. To zelo olajša življenje, ker če se je kdo ukvarjal s tem in pogledal, kako točno izgleda multicast nadzorna ravnina, v vseh, razen v najpreprostejših inštalacijah, je to velik glavobol. In še več, težko je najti na primer dobro delujočo odprtokodno izvedbo.
Končno oblikujemo naša omrežja tako, da se ne spreminjajo preveč. Računamo lahko na to, da je pretok zunanjih dogodkov v usmerjevalnem sistemu majhen.
Kakšne težave se pojavljajo in katere omejitve moramo upoštevati, ko razvijamo omrežje podatkovnih centrov? Stroški, seveda. Razširljivost, raven, do katere želimo rasti. Potreba po širitvi brez ustavljanja storitve. Pasovna širina, razpoložljivost. Vidnost dogajanja na omrežju za nadzorne sisteme, za operativne ekipe. Podpora avtomatizaciji - spet kolikor je mogoče, saj je mogoče različne naloge reševati na različnih ravneh, vključno z uvedbo dodatnih slojev. No, [morda] ni odvisen od prodajalcev. Čeprav je bilo v različnih zgodovinskih obdobjih, odvisno od tega, kateri del gledate, to samostojnost lažje ali težje doseči. Če vzamemo prerez čipov omrežnih naprav, potem je bilo do nedavnega zelo pogojno govoriti o neodvisnosti od prodajalcev, če smo želeli tudi čipe z visoko prepustnostjo.
Kakšno logično topologijo bomo uporabili za gradnjo našega omrežja? To bo večnivojski Clos. Pravzaprav trenutno ni pravih alternativ. In Closova topologija je precej dobra, tudi če jo primerjamo z različnimi naprednimi topologijami, ki so zdaj bolj v akademskem interesu, če imamo velika radix stikala.
Kako je v grobem strukturirano večnivojsko omrežje Clos in kako se v njem imenujejo različni elementi? Najprej se je dvignila roža vetra, da se orientiraš kje je sever, kje jug, kje vzhod, kje zahod. Tovrstna omrežja običajno gradijo tisti, ki imajo zelo velik promet v smeri zahod-vzhod. Kar zadeva preostale elemente, je na vrhu navidezno stikalo, sestavljeno iz manjših stikal. To je glavna ideja rekurzivne konstrukcije Closovih omrežij. Vzamemo elemente z nekakšnim radiksom in jih povežemo tako, da lahko to, kar dobimo, štejemo za stikalo z večjim radiksom. Če potrebujete še več, lahko postopek ponovite.
V primerih, na primer z dvonivojskim Closom, ko je mogoče jasno prepoznati komponente, ki so v mojem diagramu navpične, se običajno imenujejo ravnine. Če bi zgradili Clos s tremi nivoji hrbteničnih stikal (vsa niso mejna ali ToR stikala in se uporabljajo samo za tranzit), bi letala izgledala bolj kompleksno; dvonivojska izgledajo točno tako. Blok ToR ali listnih stikal in z njimi povezana hrbtenična stikala prve ravni imenujemo Pod. Spine stikala ravni spine-1 na vrhu Poda so vrh Poda, vrh Poda. Stikala, ki se nahajajo na vrhu celotne tovarne, so zgornja plast tovarne, vrh tkanine.
Seveda se postavlja vprašanje: Clos omrežja se gradijo že nekaj časa, sama ideja pa v glavnem izhaja iz časov klasične telefonije, TDM omrežij. Morda se je pojavilo kaj boljšega, morda se da kaj narediti bolje? Da in ne. Teoretično da, v praksi v bližnji prihodnosti zagotovo ne. Ker obstaja vrsta zanimivih topologij, se nekatere uporabljajo celo v proizvodnji, na primer Dragonfly se uporablja v aplikacijah HPC; Zanimive so tudi topologije, kot so Xpander, FatClique, Jellyfish. Če nedavno pogledate poročila na konferencah, kot sta SIGCOMM ali NSDI, lahko najdete precej veliko del o alternativnih topologijah, ki imajo boljše lastnosti (takšne ali drugačne) kot Clos.
Toda vse te topologije imajo eno zanimivo lastnost. Preprečuje njihovo implementacijo v omrežja podatkovnih centrov, ki jih skušamo zgraditi na standardni strojni opremi in ki stanejo precej razumnega denarja. V vseh teh alternativnih topologijah večina pasovne širine žal ni dostopna po najkrajših poteh. Zato takoj izgubimo možnost uporabe tradicionalne kontrolne ravnine.
Teoretično je rešitev problema znana. To so na primer modifikacije stanja povezave z uporabo k-najkrajše poti, vendar spet ni takih protokolov, ki bi bili implementirani v produkcijo in široko dostopni na opremi.
Poleg tega, ker večina zmogljivosti ni dostopna po najkrajših poteh, moramo spremeniti več kot le kontrolno ravnino, da izberemo vse te poti (in mimogrede, to je bistveno več stanja v kontrolni ravnini). Še vedno moramo spremeniti ravnino za posredovanje in praviloma sta potrebni vsaj dve dodatni funkciji. To je možnost, da vse odločitve o posredovanju paketov sprejmete enkrat, na primer na gostitelju. Pravzaprav je to izvorno usmerjanje, včasih se v literaturi o povezovalnih omrežjih to imenuje odločitev o posredovanju vseh naenkrat. In prilagodljivo usmerjanje je funkcija, ki jo potrebujemo na omrežnih elementih in se na primer zmanjša na dejstvo, da izberemo naslednji skok na podlagi informacije o najmanjši obremenitvi čakalne vrste. Na primer, možne so tudi druge možnosti.
Tako je smer zanimiva, a žal je trenutno ne moremo uporabiti.
V redu, odločili smo se za Closovo logično topologijo. Kako ga bomo merili? Poglejmo, kako deluje in kaj je mogoče storiti.
V omrežju Clos obstajata dva glavna parametra, ki ju lahko nekako spreminjamo in dobimo določene rezultate: radiks elementov in število nivojev v omrežju. Imam shematski diagram, kako oba vplivata na velikost. V idealnem primeru združimo oboje.
Vidimo lahko, da je končna širina Closove mreže produkt vseh nivojev hrbteničnih stikal južnega radiksa, koliko povezav imamo navzdol, kako se razveja. Tako povečamo velikost omrežja.
Kar zadeva zmogljivost, zlasti pri stikalih ToR, obstajata dve možnosti skaliranja. Ali lahko ob ohranjanju splošne topologije uporabimo hitrejše povezave ali pa dodamo več ravnin.
Če pogledate razširjeno različico omrežja Clos (v spodnjem desnem kotu) in se vrnete na to sliko z omrežjem Clos spodaj ...
... potem je to popolnoma enaka topologija, vendar je na tem diapozitivu strnjena bolj kompaktno in ravnine tovarne so postavljene druga na drugo. Enako je.
Kako je skaliranje omrežja Clos videti v številkah? Tukaj podajam podatke o tem, kakšno največjo širino omrežja je mogoče pridobiti, kakšno največje število omaric, stikal ToR ali listnih stikal, če niso v omarah, lahko dobimo glede na to, kateri radiks stikal uporabljamo za hrbtenične ravni, in koliko stopenj uporabljamo.
Evo, koliko rackov lahko imamo, koliko strežnikov in koliko približno lahko vse to porabi glede na 20 kW na rack. Malo prej sem omenil, da ciljamo na velikost grozda približno 100 tisoč strežnikov.
Vidi se, da sta v tej celotni zasnovi zanimivi dve možnosti in pol. Obstaja možnost z dvema slojema bodic in 64-portnimi stikali, ki pa malo zaostajajo. Potem so na voljo popolnoma ustrezne možnosti za 128-vratna (z radix 128) hrbtenična stikala z dvema nivojema ali stikala z radix 32 s tremi nivoji. In v vseh primerih, kjer je več radiksov in več plasti, lahko naredite zelo veliko omrežje, a če pogledate pričakovano porabo, je običajno gigavatov. Možno je položiti kabel, vendar je malo verjetno, da bomo dobili toliko električne energije na enem mestu. Če pogledate statistiko in javne podatke o podatkovnih centrih, lahko najdete zelo malo podatkovnih centrov z ocenjeno zmogljivostjo nad 150 MW. Večji so običajno kampusi podatkovnih centrov, več velikih podatkovnih centrov, ki se nahajajo precej blizu drug drugega.
Obstaja še en pomemben parameter. Če pogledate levi stolpec, je tam navedena uporabna pasovna širina. Preprosto je videti, da se v omrežju Clos velik del vrat uporablja za medsebojno povezovanje stikal. Uporabna pasovna širina, uporaben trak, je nekaj, kar je mogoče dati navzven, proti strežnikom. Seveda govorim o pogojnih pristaniščih in posebej o pasu. Povezave znotraj omrežja so praviloma hitrejše od povezav do strežnikov, a na enoto pasovne širine, kolikor jo lahko pošljemo ven naši strežniški opremi, ostane še nekaj pasovne širine znotraj samega omrežja. In več nivojev ko naredimo, večji so specifični stroški zagotavljanja tega traku navzven.
Še več, tudi ta dodatni pas ni povsem enak. Čeprav so razponi kratki, lahko uporabimo nekaj takega kot je DAC (direct attach copper, torej twinax kabli) ali večmodno optiko, ki stane še bolj ali manj razumen denar. Takoj, ko preidemo na daljše razpone - praviloma gre za enosmerno optiko in stroški te dodatne pasovne širine se opazno povečajo.
In spet, če se vrnemo na prejšnji diapozitiv, če ustvarimo omrežje Clos brez prevelike naročnine, potem je enostavno pogledati diagram, videti, kako je omrežje zgrajeno - dodajanje vsake ravni hrbteničnih stikal, ponovimo celoten trak, ki je bil na dno. Plus raven - plus isti pas, enako število vrat na stikalih, kot je bilo na prejšnji ravni, in enako število oddajnikov. Zato je zelo zaželeno zmanjšati število stopenj hrbteničnih stikal.
Na podlagi te slike je jasno, da resnično želimo graditi na nečem podobnem stikalom z radiksom 128.
Tukaj je načeloma vse enako, kot sem pravkar povedal, to je diapozitiv za razmislek kasneje.
Katere možnosti lahko izberemo kot taka stikala? Za nas je zelo prijetna novica, da je zdaj takšna omrežja končno mogoče graditi na enočipnih stikalih. In to je zelo kul, imajo veliko lepih funkcij. Na primer, nimajo skoraj nobene notranje strukture. To pomeni, da se lažje zlomijo. Lomijo se na najrazličnejše načine, a na srečo popolnoma. V modularnih napravah obstaja veliko število napak (zelo neprijetnih), ko se z vidika sosedov in nadzorne ravnine zdi, da deluje, vendar je na primer del tkanine izgubljen in ne deluje s polno zmogljivostjo. In promet do njega je uravnotežen na podlagi dejstva, da je popolnoma funkcionalen, in se lahko preobremenimo.
Ali pa se na primer pojavijo težave s hrbtno ploščo, ker so znotraj modularne naprave tudi hitri SerDes - znotraj je res zapleteno. Ali so znaki med elementi za posredovanje sinhronizirani ali pa niso sinhronizirani. Na splošno vsaka produktivna modularna naprava, sestavljena iz velikega števila elementov, praviloma vsebuje v sebi isto omrežje Clos, vendar ga je zelo težko diagnosticirati. Pogosto je celo prodajalec sam težko diagnosticirati.
In ima veliko število scenarijev napak, v katerih se naprava poslabša, vendar ne izpade popolnoma iz topologije. Ker je naše omrežje veliko, se aktivno uporablja ravnotežje med enakimi elementi, omrežje je zelo pravilno, to pomeni, da se ena pot, na kateri je vse v redu, ne razlikuje od druge poti, bolj se nam splača, da nekaj preprosto izgubimo. naprave iz topologije, kot da bi prišli v situacijo, ko se zdi, da nekatere od njih delujejo, nekatere pa ne.
Naslednja dobra lastnost naprav z enim čipom je, da se razvijajo bolje in hitreje. Ponavadi imajo tudi večjo zmogljivost. Če vzamemo velike sestavljene strukture, ki jih imamo na krogu, potem je zmogljivost na enoto regala za vrata enake hitrosti skoraj dvakrat boljša kot pri modularnih napravah. Naprave, zgrajene okoli enega samega čipa, so občutno cenejše od modularnih in porabijo manj energije.
Seveda pa je vse to z razlogom, obstajajo tudi slabosti. Prvič, radix je skoraj vedno manjši kot pri modularnih napravah. Če lahko dobimo napravo, zgrajeno okoli enega čipa s 128 vrati, potem lahko zdaj brez težav dobimo modularno z več sto vrati.
To je opazno manjša velikost posredovalnih tabel in praviloma vse, kar je povezano s skalabilnostjo podatkovne ravnine. Plitki odbojniki. In praviloma precej omejena funkcionalnost. A izkazalo se je, da če poznate te omejitve in pravočasno poskrbite, da jih zaobidete ali jih preprosto upoštevate, potem to ni tako strašljivo. To, da je radix manjši, ni več problem na napravah z radixom 128, ki so se končno pojavile pred kratkim, lahko vgradimo dve plasti bodic. Še vedno pa je nemogoče zgraditi kaj manjšega od dveh, kar je za nas zanimivo. Z eno stopnjo dobimo zelo majhne grozde. Tudi naše prejšnje zasnove in zahteve so jih še vedno presegale.
Pravzaprav, če je nenadoma rešitev nekje na robu, še vedno obstaja pot do obsega. Ker so zadnji (ali prvi), najnižji nivo, na katerem so povezani strežniki ToR stikala ali leaf switchi, nam nanje ni treba priključiti enega regala. Če torej rešitev zaostaja za približno polovico, lahko razmislite o preprosti uporabi stikala z velikim radixom na nižji ravni in povezovanju na primer dveh ali treh stojal v eno stikalo. Tudi to je možnost, ki ima svoje stroške, vendar deluje precej dobro in je lahko dobra rešitev, ko morate doseči približno dvakratno velikost.
Če povzamemo, gradimo na topologiji z dvema nivojema bodic z osmimi tovarniškimi plastmi.
Kaj bo s fiziko? Zelo preprosti izračuni. Če imamo dve ravni hrbtenice, imamo samo tri ravni stikal in pričakujemo, da bodo v omrežju trije kabelski segmenti: od strežnikov do listnih stikal, do hrbtenice 1, do hrbtenice 2. Možnosti, ki jih lahko uporaba so - to so twinax, multimode, single mode. In tu moramo razmisliti, kakšen trak je na voljo, koliko bo stal, kakšne so fizične dimenzije, kakšne razpone lahko pokrijemo in kako bomo nadgradili.
Stroškovno se da vse poravnati. Twinaxi so bistveno cenejši od aktivne optike, cenejši od multimodnih transiverjev, če vzameš na let od konca, nekaj cenejši od 100-gigabitnega switch porta. In upoštevajte, stane manj kot enosmerna optika, saj je na letih, kjer je potreben enotni način, v podatkovnih centrih iz več razlogov smiselna uporaba CWDM, medtem ko vzporedni enojni način (PSM) ni zelo primeren za delo z zelo velikimi paketi dobimo vlakna in če se osredotočimo na te tehnologije, dobimo približno naslednjo cenovno hierarhijo.
Še ena opomba: na žalost ni mogoče uporabiti razstavljenih 100 do 4x25 večmodnih vrat. Zaradi konstrukcijskih značilnosti oddajnikov SFP28 ni veliko cenejši od 28 Gbit QSFP100. In to razstavljanje za multimode ne deluje zelo dobro.
Druga omejitev je, da se zaradi velikosti računalniških gruč in števila strežnikov naši podatkovni centri izkažejo za fizično velike. To pomeni, da bo treba vsaj en let opraviti z singlemodom. Ponovno, zaradi fizične velikosti Pods, ne bo mogoče napeljati dveh razponov twinax (bakrenih kablov).
Posledično, če optimiziramo ceno in upoštevamo geometrijo te zasnove, dobimo en razpon twinaxa, en razpon večmodnega in en razpon enomodnega z uporabo CWDM. To upošteva možne poti nadgradnje.
Takole izgleda zadnje čase, kam gremo in kaj je možno. Jasno je vsaj, kako se premakniti k 50-gigabitnim SerDes za večmodne in enomodne. Še več, če pogledate, kaj je v enomodnih oddajnikih in oddajnikih zdaj in v prihodnosti za 400G, pogosto tudi, ko 50G SerDes prispejo z električne strani, lahko 100 Gbps na pas že gre v optiko. Zato je povsem možno, da bo namesto prehoda na 50 prišlo do prehoda na 100 Gigabit SerDes in 100 Gbps per lane, saj se po obljubah številnih ponudnikov njihova razpoložljivost pričakuje kmalu. Obdobje, ko so bili 50G SerDes najhitrejši, kot kaže, ne bo prav dolgo, saj prve kopije 100G SerDes prihajajo skoraj prihodnje leto. In čez nekaj časa bodo verjetno vredni razumnega denarja.
Še en odtenek pri izbiri fizike. Načeloma že lahko uporabljamo 400 ali 200 Gigabitna vrata z uporabo 50G SerDes. Toda izkazalo se je, da to nima velikega smisla, saj, kot sem rekel prej, želimo precej velik radix na stikalih, seveda v okviru razumnega. Želimo 128. In če imamo omejeno zmogljivost čipa in povečamo hitrost povezave, potem se radix seveda zmanjša, čudežev ni.
In z letali lahko povečamo skupno kapaciteto in ni posebnih stroškov, lahko dodamo število letal. In če izgubimo radix, bomo morali uvesti dodatno raven, tako da se v trenutni situaciji, pri trenutni največji razpoložljivi zmogljivosti na čip, izkaže, da je bolj učinkovito uporabljati 100-gigabitna vrata, saj ti omogočajo da bi dobili večji radiks.
Naslednje vprašanje je, kako je organizirana fizika, vendar z vidika kabelske infrastrukture. Izkazalo se je, da je organiziran na precej smešen način. Kabli med listnimi stikali in hrbtenicami prve stopnje - tam ni veliko povezav, vse je zgrajeno relativno preprosto. Toda če vzamemo eno ravnino, se znotraj zgodi, da moramo vse hrbtenice prve ravni povezati z vsemi hrbtenicami druge ravni.
Poleg tega je praviloma nekaj želja, kako naj bi izgledalo znotraj podatkovnega centra. Na primer, res smo želeli združiti kable v snop in jih potegniti tako, da bi ena povezovalna plošča z visoko gostoto v celoti šla v eno povezovalno ploščo, tako da ni bilo živalskega vrta v smislu dolžin. Ta problem nam je uspelo rešiti. Če na začetku pogledate logično topologijo, lahko vidite, da so ravnine neodvisne, vsako ravnino je mogoče zgraditi zase. Toda ko dodamo takšno združevanje in želimo celotno ploščo za povezovanje povleči v ploščo za povezovanje, moramo zmešati različne ravnine v enem svežnju in uvesti vmesno strukturo v obliki optičnih navzkrižnih povezav, da jih ponovno zapakiramo, kot so bile sestavljene na enem segmentu, kako bodo zbrani na drugem segmentu. Zahvaljujoč temu dobimo lepo lastnost: vsa zapletena preklapljanja ne presegajo stojal. Ko morate nekaj zelo močno preplesti, »razgrniti ravnine«, kot se temu včasih reče v Closovih omrežjih, je vse skoncentrirano znotraj enega stojala. Nimamo zelo razstavljenega, do posameznih povezav, preklapljanja med regali.
Tako je to videti z vidika logične organizacije kabelske infrastrukture. Na sliki na levi večbarvni bloki prikazujejo bloke hrbteničnih stikal prve stopnje, po osem kosov, in štiri snope kablov, ki prihajajo iz njih, ki gredo in sekajo s snopi, ki prihajajo iz blokov hrbteničnih stikal 2. .
Majhni kvadratki označujejo križišča. Zgoraj levo je razčlenitev vsakega takega križišča, to je pravzaprav modul navzkrižne povezave s 512 krat 512 vrati, ki prepakira kable, tako da pridejo popolnoma v eno omaro, kjer je samo ena ravnina spine-2. In na desni je skeniranje te slike nekoliko podrobnejše v zvezi z več Podi na ravni hrbtenice-1 in kako je zapakirano v navzkrižno povezavo, kako pride na raven hrbtenice-2.
Takole izgleda. Še ne povsem sestavljeno stojalo Spine-2 (na levi) in stojalo za križno povezavo. Na žalost tam ni kaj dosti videti. Ta celotna struktura je trenutno nameščena v enem od naših velikih podatkovnih centrov, ki se širi. To je delo v teku, izgledalo bo lepše, bolje bo zapolnjeno.
Pomembno vprašanje: izbrali smo logično topologijo in zgradili fiziko. Kaj se bo zgodilo s krmilnim letalom? Iz izkušenj z delovanjem je precej znano, obstajajo številna poročila, da so protokoli stanja povezave dobri, z njimi je užitek delati, vendar se na žalost ne prilagajajo dobro na gosto povezani topologiji. In obstaja en glavni dejavnik, ki to preprečuje - tako deluje poplavljanje v protokolih stanja povezave. Če samo vzamete algoritem poplavljanja in pogledate, kako je strukturirano naše omrežje, lahko vidite, da bo na vsakem koraku prišlo do zelo velikega odcepa, ki bo nadzorno ravnino preprosto preplavil s posodobitvami. Natančneje, takšne topologije se zelo slabo mešajo s tradicionalnim algoritmom preplavljanja v protokolih stanja povezave.
Izbira je uporaba BGP. Kako ga pravilno pripraviti, je opisano v RFC 7938 o uporabi BGP v velikih podatkovnih centrih. Osnovne ideje so preproste: minimalno število predpon na gostitelja in na splošno najmanjše število predpon v omrežju, uporaba združevanja, če je mogoče, in zatiranje iskanja poti. Želimo zelo previdno, zelo nadzorovano distribucijo posodobitev, tako imenovano brez doline. Želimo, da se posodobitve uvedejo točno enkrat, ko gredo skozi omrežje. Če izvirajo na dnu, gredo navzgor in se ne odprejo več kot enkrat. Ne sme biti cik-cak. Cik-cak je zelo slab.
Za to uporabljamo načrt, ki je dovolj preprost za uporabo osnovnih mehanizmov BGP. To pomeni, da uporabljamo eBGP, ki deluje na lokalni povezavi, avtonomni sistemi pa so dodeljeni na naslednji način: avtonomni sistem na ToR, avtonomni sistem na celotnem bloku stikal Spine-1 enega Poda in splošni avtonomni sistem na celotnem vrhu blaga. Ni težko videti in ugotoviti, da nam celo običajno vedenje BGP zagotavlja distribucijo posodobitev, ki jih želimo.
Seveda je treba naslavljanje in združevanje naslovov oblikovati tako, da je združljivo z načinom izgradnje usmerjanja, tako da zagotavlja stabilnost nadzorne ravnine. L3 naslavljanje v transportu je vezano na topologijo, saj brez tega ni mogoče doseči agregacije, brez katere se bodo posamezni naslovi prikradli v usmerjevalni sistem. In še ena stvar je ta, da se združevanje na žalost ne ujema najbolje z več potmi, ker ko imamo več poti in imamo združevanje, je vse v redu, ko je celotno omrežje zdravo, v njem ni okvar. Na žalost lahko takoj, ko se pojavijo okvare v omrežju in se izgubi simetrija topologije, pridemo do točke, s katere je bila enota najavljena, od koder ne moremo iti naprej, kamor moramo iti. Zato je najbolje agregirati tam, kjer ni več več poti, v našem primeru so to stikala ToR.
Pravzaprav je mogoče združiti, vendar previdno. Če lahko izvedemo nadzorovano razčlenitev, ko pride do napak v omrežju. Toda to je precej težka naloga, spraševali smo se celo, ali bi bilo to mogoče narediti, ali je mogoče dodati dodatno avtomatizacijo in končne avtomate, ki bi pravilno brcali BGP, da bi dosegli želeno obnašanje. Na žalost je obdelava vogalnih primerov zelo neočitna in zapletena in ta naloga ni dobro rešena s pripenjanjem zunanjih prilog na BGP.
Zelo zanimivo delo v zvezi s tem je bilo opravljeno v okviru protokola RIFT, o čemer bomo govorili v naslednjem poročilu.
Druga pomembna stvar je, kako se podatkovne ravnine skalirajo v gostih topologijah, kjer imamo veliko število alternativnih poti. V tem primeru se uporablja več dodatnih podatkovnih struktur: skupine ECMP, ki nato opisujejo skupine Next Hop.
V normalno delujočem omrežju, brez okvar, ko gremo navzgor po topologiji Clos, je dovolj, da uporabimo samo eno skupino, ker je vse, kar ni lokalno, privzeto opisano, lahko gremo navzgor. Ko gremo od vrha do dna proti jugu, potem vse poti niso ECMP, so poti z eno potjo. Vse je vredu. Težava in posebnost klasične Closove topologije je, da če pogledamo vrh tkanine, pri katerem koli elementu, obstaja le ena pot do katerega koli elementa spodaj. Če na tej poti pride do napak, potem ta določen element na vrhu tovarne postane neveljaven ravno za tiste predpone, ki ležijo za zlomljeno potjo. Toda za ostalo velja in moramo razčleniti skupine ECMP in uvesti novo stanje.
Kako izgleda razširljivost podatkovne ravnine na sodobnih napravah? Če naredimo LPM (najdaljše ujemanje predpon), je vse precej dobro, več kot 100k predpon. Če govorimo o skupinah Next Hop, potem je vse slabše, 2-4 tisoč. Če govorimo o tabeli, ki vsebuje opis Next Hops (ali adjacencies), potem je to nekje od 16k do 64k. In to lahko postane problem. In tu pridemo do zanimive digresije: kaj se je zgodilo z MPLS v podatkovnih centrih? Načeloma smo to želeli narediti.
Zgodili sta se dve stvari. Izvedli smo mikrosegmentacijo na gostiteljih; v omrežju nam tega ni bilo treba več izvajati. Ni bilo dobro s podporo različnih prodajalcev, še bolj pa z odprtimi implementacijami na belih škatlah z MPLS. In MPLS, vsaj njegove tradicionalne izvedbe, se na žalost zelo slabo kombinira z ECMP. In zato.
Tako izgleda struktura posredovanja ECMP za IP. Veliko število predpon lahko uporablja isto skupino in isti blok Next Hops (ali sosednje povezave, to se lahko imenuje drugače v različnih dokumentacijah za različne naprave). Bistvo je, da je to opisano kot odhodna vrata in na kaj prepisati naslov MAC, da pridemo do pravilnega naslednjega skoka. Za IP je vse videti preprosto, lahko uporabite zelo veliko število predpon za isto skupino, isti blok Next Hops.
Klasična arhitektura MPLS pomeni, da se lahko oznaka prepiše na različne vrednosti, odvisno od izhodnega vmesnika. Zato moramo ohraniti skupino in blok Next Hops za vsako vhodno oznako. In to, žal, ne obsega.
Preprosto je videti, da smo v naši zasnovi potrebovali približno 4000 stikal ToR, največja širina je bila 64 poti ECMP, če se premaknemo od spine-1 proti spine-2. Komaj pridemo v eno tabelo skupin ECMP, če izgine samo ena predpona s ToR, v tabelo Next Hops pa sploh ne pridemo.
Ni vse brezupno, saj arhitekture, kot je Segment Routing, vključujejo globalne oznake. Formalno bi bilo mogoče vse te bloke Next Hops znova zrušiti. Če želite to narediti, potrebujete operacijo tipa nadomestnega znaka: vzemite oznako in jo prepišite v isto brez določene vrednosti. A na žalost tega v razpoložljivih izvedbah ni zelo prisotno.
In končno, zunanji promet moramo pripeljati v podatkovni center. Kako narediti? Prej je bil promet v omrežje Clos uveden od zgoraj. To pomeni, da so obstajali robni usmerjevalniki, ki so se povezovali z vsemi napravami na vrhu tkanine. Ta rešitev deluje zelo dobro pri majhnih do srednje velikih. Na žalost moramo za simetrično pošiljanje prometa v celotno omrežje na ta način hkrati priti do vseh elementov Top of fabric, ko pa jih je več kot sto, se izkaže, da potrebujemo tudi veliko radix na robnih usmerjevalnikih. Na splošno to stane, ker so robni usmerjevalniki bolj funkcionalni, vrata na njih bodo dražja, dizajn pa ni zelo lep.
Druga možnost je, da takšen promet začnete od spodaj. Enostavno je preveriti, da je Closova topologija zgrajena tako, da je promet, ki prihaja od spodaj, to je s strani ToR, enakomerno porazdeljen med ravni po celotnem Top of fabric v dveh iteracijah, kar obremeni celotno omrežje. Zato uvajamo posebno vrsto Pod, Edge Pod, ki omogoča zunanjo povezljivost.
Obstaja še ena možnost. To počne na primer Facebook. Imenujejo ga Fabric Aggregator ali HGRID. Uvaja se dodatna raven hrbtenice za povezovanje več podatkovnih centrov. Ta zasnova je mogoča, če nimamo dodatnih funkcij ali sprememb enkapsulacije na vmesnikih. Če so dodatne stične točke, je težko. Običajno obstaja več funkcij in nekakšna membrana, ki ločuje različne dele podatkovnega centra. Takšne membrane nima smisla narediti velike, če pa je iz nekega razloga res potrebna, je smiselno razmisliti o možnosti, da jo odvzamemo, čim bolj razširimo in prenesemo na gostitelje. To počnejo na primer številni operaterji v oblaku. Imajo prekrivke, začnejo od gostiteljev.
Kakšne razvojne priložnosti vidimo? Najprej izboljšanje podpore za cevovod CI/CD. Želimo leteti tako, kot preizkušamo, in preizkušati, kot letimo. To se ne obnese najbolje, ker je infrastruktura velika in jo je nemogoče podvojiti za teste. Morate razumeti, kako v proizvodno infrastrukturo uvesti elemente testiranja, ne da bi jo opustili.
Boljša instrumentacija in boljši nadzor skoraj nikoli nista odveč. Celotno vprašanje je ravnotežje med trudom in donosom. Če ga lahko dodate z razumnim trudom, zelo dobro.
Odprti operacijski sistemi za omrežne naprave. Boljši protokoli in boljši sistemi usmerjanja, kot je RIFT. Potrebne so tudi raziskave o uporabi boljših shem za nadzor prezasedenosti in morda o uvedbi, vsaj na nekaterih točkah, podpore RDMA znotraj grozda.
Če pogledamo dlje v prihodnost, potrebujemo napredne topologije in po možnosti omrežja, ki porabijo manj režijskih stroškov. Od svežih stvari so bile pred kratkim objavljene objave o tehnologiji tkanine za HPC Cray Slingshot, ki temelji na blagovnem Ethernetu, vendar z možnostjo uporabe precej krajših glav. Posledično se režijski stroški zmanjšajo.
Vse mora biti čim bolj preprosto, vendar ne preprostejše. Kompleksnost je sovražnik razširljivosti. Enostavnost in pravilne strukture so naši prijatelji. Če se lahko nekje povečate, naredite to. In na splošno je zdaj super biti vključen v omrežne tehnologije. Dogaja se marsikaj zanimivega. Hvala vam.
Vir: www.habr.com