Sukūrėme duomenų centro tinklo dizainą, leidžiantį diegti didesnius nei 100 tūkstančių serverių skaičiavimo grupes, kurių didžiausias bisekcijos pralaidumas viršija vieną petabaitą per sekundę.
Iš Dmitrijaus Afanasjevo pranešimo sužinosite apie pagrindinius naujojo dizaino principus, mastelio keitimo topologijas, su tuo kylančias problemas, jų sprendimo galimybes, šiuolaikinių tinklo įrenginių peradresavimo plokštumos funkcijų maršruto parinkimo ir mastelio ypatybes „tankiai prijungtoje“. topologijos su daugybe ECMP maršrutų. Be to, Dima trumpai papasakojo apie išorinio ryšio organizavimą, fizinį sluoksnį, kabelių sistemą ir būdus toliau didinti pajėgumus.
- Laba diena visiems! Mano vardas Dmitrijus Afanasjevas, aš esu „Yandex“ tinklo architektas ir pirmiausia projektuoju duomenų centrų tinklus.
Mano istorija bus apie atnaujintą „Yandex“ duomenų centrų tinklą. Tai labai daug mūsų turimo dizaino evoliucijos, tačiau tuo pat metu yra keletas naujų elementų. Tai apžvalginis pristatymas, nes per trumpą laiką reikėjo supakuoti daug informacijos. Pradėsime nuo loginės topologijos pasirinkimo. Tada bus apžvelgta valdymo plokštuma ir problemos, susijusios su duomenų plokštumos masteliu, pasirinkimas, kas bus fiziniame lygmenyje, ir apžvelgsime kai kurias įrenginių savybes. Pakalbėkime apie tai, kas vyksta duomenų centre su MPLS, apie kurį kalbėjome prieš kurį laiką.
Taigi, kas yra „Yandex“ apkrovų ir paslaugų atžvilgiu? „Yandex“ yra tipiškas hiperskaleris. Jei žiūrime į vartotojus, pirmiausia apdorojame vartotojų užklausas. Taip pat įvairios srautinio perdavimo paslaugos bei duomenų perdavimas, nes turime ir saugojimo paslaugas. Jei arčiau backend, tada ten atsiranda infrastruktūros apkrovos ir paslaugos, pvz., paskirstyta objektų saugykla, duomenų replikacija ir, žinoma, nuolatinės eilės. Vienas iš pagrindinių darbo krūvių tipų yra MapReduce ir panašios sistemos, srautų apdorojimas, mašininis mokymasis ir kt.
Kaip yra infrastruktūra, ant kurios visa tai vyksta? Vėlgi, mes esame gana tipiškas hiperskaleris, nors galbūt esame šiek tiek arčiau mažesnės hiperskalerio spektro pusės. Bet mes turime visas savybes. Kur įmanoma, naudojame prekinę techninę įrangą ir horizontalųjį mastelį. Turime pilną išteklių telkimą: dirbame ne su atskiromis mašinomis, atskiromis stelažais, o sujungiame juos į didelį pakeičiamų išteklių telkinį su kai kuriomis papildomomis paslaugomis, kurios yra susijusios su planavimu ir paskirstymu bei dirbame su visu telkiniu.
Taigi turime kitą lygį – operacinę sistemą skaičiavimo klasterio lygyje. Labai svarbu visiškai kontroliuoti naudojamą technologijų krūvą. Valdome galinius taškus (host'us), tinklą ir programinės įrangos krūvą.
Turime keletą didelių duomenų centrų Rusijoje ir užsienyje. Juos vienija stuburas, kuriame naudojama MPLS technologija. Mūsų vidinė infrastruktūra beveik visiškai sukurta naudojant IPv6, bet kadangi turime aptarnauti išorinį srautą, kuris vis tiek daugiausia gaunamas per IPv4, turime kažkaip pateikti užklausas, gaunamas per IPv4 į priekinius serverius, o šiek tiek daugiau – į išorinį IPv4 internetą. Pavyzdžiui, indeksavimui.
Keliose pastarosiose duomenų centrų tinklo projektavimo iteracijose buvo naudojamos daugiasluoksnės Clos topologijos ir jos yra skirtos tik L3. Prieš kurį laiką palikome L2 ir lengviau atsidusome. Galiausiai, mūsų infrastruktūra apima šimtus tūkstančių skaičiavimo (serverio) egzempliorių. Maksimalus klasterio dydis prieš kurį laiką buvo apie 10 tūkstančių serverių. Taip yra daugiausia dėl to, kaip gali veikti tos pačios klasterio lygio operacinės sistemos, planuokliai, išteklių paskirstymas ir tt. Kadangi infrastruktūros programinės įrangos srityje padaryta pažanga, dabar tikslinis dydis yra apie 100 tūkst. serverių viename skaičiavimo klasteryje. Turime užduotį – sugebėti sukurti tinklo gamyklas, kurios leistų efektyviai telkti išteklius tokiame klasteryje.
Ko mes norime iš duomenų centrų tinklo? Visų pirma, yra daug pigaus ir gana tolygiai paskirstyto pralaidumo. Kadangi tinklas yra pagrindas, per kurį galime sutelkti išteklius. Naujas tikslinis dydis yra apie 100 tūkstančių serverių viename klasteryje.
Taip pat, žinoma, norime keičiamo dydžio ir stabilios valdymo plokštumos, nes tokioje didelėje infrastruktūroje daug galvos skausmo kyla net ir dėl tiesiog atsitiktinių įvykių, o mes nenorime, kad valdymo plokštuma sukeltų ir galvos skausmą. Tuo pačiu norime kuo labiau sumažinti joje esančią būseną. Kuo mažesnė būklė, tuo geriau ir stabiliau viskas veikia, tuo lengviau diagnozuoti.
Žinoma, mums reikia automatikos, nes rankiniu būdu tokios infrastruktūros valdyti neįmanoma, o jau kurį laiką tai neįmanoma. Mums reikia kiek įmanoma didesnio operatyvinio palaikymo ir CI/CD palaikymo tiek, kiek įmanoma.
Esant tokio dydžio duomenų centrams ir grupėms, laipsniško diegimo ir išplėtimo nenutrūkstant paslauga tapo gana aktuali. Jei tūkstančio mašinų klasteriuose, galbūt arti dešimties tūkstančių mašinų, jie vis tiek galėtų būti įdiegti kaip viena operacija – tai yra, planuojame infrastruktūros išplėtimą, o keli tūkstančiai mašinų pridedama kaip viena operacija, tada šimto tūkstančių mašinų klasteris neatsiranda iš karto taip, jis sukuriamas per tam tikrą laikotarpį. Ir norėtųsi, kad visą šį laiką būtų prieinama tai, kas jau buvo išsiurbta, ta infrastruktūra, kuri buvo įdiegta.
Ir vienas reikalavimas, kurį turėjome ir palikome: daugialypės nuomos palaikymas, tai yra virtualizavimas arba tinklo segmentavimas. Dabar mums nereikia to daryti tinklo struktūros lygmeniu, nes suskaidymas atiteko pagrindiniams kompiuteriams, o tai mums labai palengvino mastelio keitimą. Dėl IPv6 ir didelės adresų erdvės mums nereikėjo naudoti pasikartojančių adresų vidinėje infrastruktūroje, visi adresai jau buvo unikalūs. Ir dėl to, kad filtravimą ir tinklo segmentavimą perkėlėme į pagrindinius kompiuterius, mums nereikia kurti virtualių tinklo objektų duomenų centrų tinkluose.
Labai svarbus dalykas yra tai, ko mums nereikia. Jei kai kurias funkcijas galima pašalinti iš tinklo, tai labai palengvina gyvenimą ir, kaip taisyklė, išplečia turimos įrangos ir programinės įrangos pasirinkimą, todėl diagnostika tampa labai paprasta.
Taigi, ko mums nereikia, ko galėjome atsisakyti ne visada su džiaugsmu tuo metu, kai tai įvyko, bet su dideliu palengvėjimu, kai procesas baigiasi?
Visų pirma, L2 atsisakymas. Mums nereikia L2, nei tikrojo, nei imituoto. Nenaudojamas daugiausia dėl to, kad mes valdome programų krūvą. Mūsų programos yra horizontaliai keičiamos, jos veikia su L3 adresavimu, nelabai jaudinasi, kad kažkoks atskiras egzempliorius išėjo, tiesiog iškelia naują, jo nereikia išriedėti senu adresu, nes yra atskiras klasteryje esančių mašinų paslaugų aptikimo ir stebėjimo lygis. Mes neperduodame šios užduoties tinklui. Tinklo užduotis yra pristatyti paketus iš taško A į tašką B.
Mes taip pat neturime situacijų, kai adresai juda tinkle, ir tai reikia stebėti. Daugelyje dizainų tai paprastai reikalinga VM mobilumui palaikyti. Mes nenaudojame virtualių mašinų mobilumo didžiojo „Yandex“ vidinėje infrastruktūroje, be to, manome, kad net jei tai bus padaryta, tai neturėtų atsitikti su tinklo palaikymu. Jei jums tikrai reikia tai padaryti, turite tai padaryti pagrindinio kompiuterio lygiu ir perkelti adresus, kurie gali persikelti į perdangas, kad nepaliestumėte paties apatinio sluoksnio (transporto tinklo) maršruto parinkimo sistemos arba neatliktumėte per daug dinamiškų pakeitimų. .
Kita technologija, kurios nenaudojame, yra multicast. Jei nori, galiu detaliai papasakoti kodėl. Tai labai palengvina gyvenimą, nes jei kas nors su tuo susidorojo ir tiksliai pažiūrėjo, kaip atrodo multicast valdymo plokštuma, visose, išskyrus paprasčiausias, instaliacijas, tai yra didelis galvos skausmas. Be to, sunku rasti, pavyzdžiui, gerai veikiančią atvirojo kodo diegimą.
Galiausiai savo tinklus kuriame taip, kad jie per daug nesikeistų. Galime pasikliauti tuo, kad išorinių įvykių srautas maršruto parinkimo sistemoje yra mažas.
Kokios problemos iškyla ir į kokius apribojimus reikia atsižvelgti plėtojant duomenų centrų tinklą? Kaina, žinoma. Mastelio keitimas, lygis, iki kurio norime augti. Poreikis plėstis nestabdant paslaugos. Pralaidumas, prieinamumas. Matomumas, kas vyksta tinkle stebėjimo sistemoms, operatyvinėms komandoms. Automatikos palaikymas - vėlgi, kiek įmanoma, nes įvairias užduotis galima išspręsti skirtingais lygiais, įskaitant papildomų sluoksnių įvedimą. Na, [galbūt] nepriklauso nuo pardavėjų. Nors skirtingais istoriniais laikotarpiais, priklausomai nuo to, į kurį skyrių žiūrite, ši nepriklausomybė buvo lengviau arba sunkiau pasiekiama. Jei paimtume tinklo įrenginių lustų skerspjūvį, tai dar visai neseniai buvo labai sąlygiška kalbėti apie nepriklausomybę nuo pardavėjų, jei norėjome ir didelio pralaidumo lustų.
Kokią loginę topologiją naudosime kurdami tinklą? Tai bus kelių lygių uždarymas. Tiesą sakant, šiuo metu realių alternatyvų nėra. Ir Clos topologija yra gana gera, net lyginant su įvairiomis pažangiomis topologijomis, kurios dabar yra labiau akademinio susidomėjimo srityje, jei turime didelius radix jungiklius.
Kaip apytiksliai struktūruojamas kelių lygių Clos tinklas ir kaip jame vadinami skirtingi elementai? Visų pirma pakilo vėjas, orientuotis, kur šiaurė, kur pietai, kur rytai, kur vakarai. Tokio tipo tinklus dažniausiai kuria tie, kurie turi labai didelį vakarų-rytų srautą. Kalbant apie likusius elementus, viršuje yra virtualus jungiklis, surinktas iš mažesnių jungiklių. Tai yra pagrindinė rekursinio Clos tinklų kūrimo idėja. Mes paimame elementus su kažkokiu radiksu ir sujungiame juos taip, kad tai, ką gauname, būtų galima laikyti jungikliu su didesniu radiksu. Jei reikia dar daugiau, procedūrą galima kartoti.
Tais atvejais, pavyzdžiui, su dviejų lygių Clos, kai galima aiškiai nustatyti komponentus, kurie mano diagramoje yra vertikaliai, jie dažniausiai vadinami plokštumais. Jei statytume Clos su trijų lygių stuburo jungikliais (visi jie nėra ribiniai arba ToR jungikliai ir naudojami tik tranzitu), tada plokštumos atrodytų sudėtingesnės; dviejų lygių atrodo būtent taip. ToR arba lapų jungiklių bloką ir su jais susietus pirmojo lygio stuburo jungiklius vadiname Pod. Stuburo 1 lygio jungikliai, esantys Pod viršuje, yra Pod viršus, Pod viršus. Jungikliai, esantys visos gamyklos viršuje, yra viršutinis gamyklos sluoksnis, Audinio viršus.
Žinoma, kyla klausimas: Clos tinklai kuriami jau kurį laiką, pati idėja dažniausiai kilusi iš klasikinės telefonijos, TDM tinklų laikų. Gal atsirado kažkas geresnio, gal galima ką nors padaryti geriau? Taip ir ne. Teoriškai taip, praktiškai artimiausiu metu tikrai ne. Kadangi yra nemažai įdomių topologijų, kai kurios netgi naudojamos gamyboje, pavyzdžiui, Dragonfly naudojama HPC programose; Taip pat yra įdomių topologijų, tokių kaip Xpander, FatClique, Jellyfish. Neseniai pažvelgus į pranešimus tokiose konferencijose kaip SIGCOMM ar NSDI, galima rasti gana daug darbų apie alternatyvias topologijas, kurios turi geresnes savybes (vienas ar kitas) nei Clos.
Tačiau visos šios topologijos turi vieną įdomią savybę. Tai užkerta kelią jų diegimui duomenų centrų tinkluose, kuriuos bandome sukurti ant prekinės techninės įrangos ir kurie kainuoja gana protingus pinigus. Deja, visose šiose alternatyviose topologijose didžioji dažnių juostos pločio dalis nėra pasiekiama trumpiausiais keliais. Todėl iš karto prarandame galimybę naudotis tradicine valdymo plokštuma.
Teoriškai problemos sprendimas yra žinomas. Tai, pavyzdžiui, nuorodos būsenos modifikacijos naudojant k trumpiausią kelią, tačiau vėlgi, nėra tokių protokolų, kurie būtų įdiegti gamyboje ir plačiai prieinami įrangoje.
Be to, kadangi didžioji talpos dalis nepasiekiama trumpiausiais keliais, turime keisti ne tik valdymo plokštumą, kad pasirinktume visus tuos kelius (beje, tai yra žymiai didesnė valdymo plokštumos būsena). Dar reikia modifikuoti persiuntimo plokštumą ir, kaip taisyklė, reikalingos bent dvi papildomos funkcijos. Tai yra galimybė priimti visus sprendimus dėl paketų persiuntimo vieną kartą, pavyzdžiui, pagrindiniame kompiuteryje. Tiesą sakant, tai yra šaltinio maršruto parinkimas, kartais literatūroje apie sujungimo tinklus tai vadinama „viskas vienu metu“ persiuntimo sprendimais. O adaptyvusis maršruto parinkimas yra funkcija, kurios mums reikia tinklo elementuose, kuri susiveda, pavyzdžiui, į tai, kad kitą šuolį pasirenkame pagal informaciją apie mažiausią eilės apkrovą. Pavyzdžiui, galimi ir kiti variantai.
Taigi kryptis įdomi, bet, deja, dabar negalime jos pritaikyti.
Gerai, apsistojome ties Clos logine topologija. Kaip mes jį padidinsime? Pažiūrėkime, kaip tai veikia ir ką galima padaryti.
Clos tinkle yra du pagrindiniai parametrai, kuriuos galime kažkaip keisti ir gauti tam tikrus rezultatus: elementų radiksas ir lygių skaičius tinkle. Turiu scheminę schemą, kaip abu įtakoja dydį. Idealiu atveju deriname abu.
Matyti, kad galutinis Clos tinklo plotis yra visų lygių pietinio radikso stuburo jungiklių sandauga, kiek grandžių turime žemyn, kaip šakojasi. Taip padidiname tinklo dydį.
Kalbant apie talpą, ypač ant ToR jungiklių, yra dvi mastelio keitimo parinktys. Arba galime, išlaikydami bendrą topologiją, naudoti greitesnes nuorodas, arba galime pridėti daugiau plokštumų.
Jei pažvelgsite į išplėstą Clos tinklo versiją (apatiniame dešiniajame kampe) ir grįšite į šį paveikslėlį su žemiau esančiu Clos tinklu...
... tada tai lygiai tokia pati topologija, bet ant šios skaidrės ji sulenkta kompaktiškiau ir gamyklos plokštumos yra viena ant kitos. Tai tas pats.
Kaip Clos tinklo mastelio keitimas atrodo skaičiais? Čia pateikiu duomenis, kokį maksimalų tinklo plotį galima gauti, koks maksimalus stelažų, ToR jungiklių ar lapų jungiklių skaičius, jei jų nėra stelažuose, galime gauti priklausomai nuo to, kokį jungiklių radiksą naudojame stuburo lygiams, ir kiek lygių naudojame.
Štai kiek stelažų galime turėti, kiek serverių ir apytiksliai viso to gali sunaudoti, atsižvelgiant į 20 kW vienam stovui. Kiek anksčiau minėjau, kad siekiame apie 100 tūkstančių serverių klasterio dydžio.
Matyti, kad visame šiame projekte domina du su puse variantų. Yra galimybė su dviem sluoksniais spygliais ir 64 prievadų jungikliais, kurių šiek tiek trūksta. Tada yra puikiai tinkančių 128 prievadų (su radix 128) stuburo jungikliais su dviem lygiais arba jungikliams su radix 32 su trimis lygiais. Ir visais atvejais, kur yra daugiau radiksų ir daugiau sluoksnių, galite padaryti labai didelį tinklą, bet jei pažiūrėsite į numatomą suvartojimą, tai paprastai yra gigavatai. Kabelį nutiesti galima, bet vargu ar tiek elektros gausime vienoje aikštelėje. Jei pažvelgsite į statistiką ir viešus duomenų centrų duomenis, galite rasti labai nedaug duomenų centrų, kurių numatoma galia viršija 150 MW. Didesni dažniausiai yra duomenų centrų miesteliai, keli dideli duomenų centrai, esantys gana arti vienas kito.
Yra dar vienas svarbus parametras. Jei pažvelgsite į kairįjį stulpelį, ten pateikiamas naudojamas pralaidumas. Nesunku pastebėti, kad „Clos“ tinkle nemaža dalis prievadų yra naudojami komutatoriams sujungti vienas su kitu. Naudojamas pralaidumas, naudinga juosta, yra kažkas, kas gali būti suteikta išorėje, serverių link. Natūralu, kad kalbu apie sąlyginius prievadus ir konkrečiai apie grupę. Paprastai nuorodos tinkle yra greitesnės nei nuorodos į serverius, bet pralaidumo vienetui, kiek galime išsiųsti į savo serverio įrangą, pačiame tinkle vis tiek yra pralaidumo. Ir kuo daugiau lygių padarysime, tuo didesnės konkrečios šios juostelės pateikimo į išorę išlaidos.
Be to, net ir ši papildoma juosta nėra visiškai tokia pati. Nors tarpatramiai yra trumpi, galime naudoti kažką panašaus į DAC (tiesioginio prijungimo varinius, tai yra twinax kabelius) arba daugiamodę optiką, kuri kainuoja net daugiau ar mažiau pagrįstus pinigus. Kai tik pereiname prie ilgesnių intervalų – paprastai tai yra vieno režimo optika, o šio papildomo pralaidumo kaina pastebimai išauga.
Ir vėl, grįžtant prie ankstesnės skaidrės, jei sukursime Clos tinklą be perteklinio prenumeratos, tada lengva pažvelgti į schemą, pamatyti, kaip tinklas sukurtas - pridėdami kiekvieną stuburo jungiklių lygį, pakartojame visą juostelę, kuri buvo apačioje. Plius lygis – plius ta pati juosta, tiek pat prievadų jungikliuose, kiek buvo ankstesniame lygyje, ir tiek pat siųstuvų-imtuvų. Todėl labai pageidautina sumažinti stuburo jungiklių lygių skaičių.
Remiantis šiuo paveikslu, aišku, kad mes tikrai norime sukurti kažką panašaus į jungiklius, kurių radiksas yra 128.
Čia iš principo viskas yra taip pat, kaip ką tik sakiau; tai skaidrė, kurią reikės apsvarstyti vėliau.
Kokius variantus galime pasirinkti kaip tokius jungiklius? Mums labai džiugi žinia, kad dabar pagaliau tokius tinklus galima kurti ant vieno lusto komutatorių. Ir tai labai šaunu, jie turi daug gražių savybių. Pavyzdžiui, jie beveik neturi vidinės struktūros. Tai reiškia, kad jie lengviau lūžta. Jie lūžta įvairiais būdais, bet, laimei, lūžta visiškai. Moduliniuose įrenginiuose yra daug gedimų (labai nemalonu), kai kaimynų ir valdymo plokštumos požiūriu atrodo, kad veikia, bet, pavyzdžiui, dalis audinio pamesta ir jis neveikia visu pajėgumu. O srautas į jį subalansuotas remiantis tuo, kad jis pilnai veikia ir galime perkrauti.
Arba, pavyzdžiui, problemų kyla dėl galinės plokštės, nes modulinio įrenginio viduje taip pat yra didelės spartos „SerDes“ - viduje tai tikrai sudėtinga. Ženklai tarp persiuntimo elementų yra sinchronizuoti arba nesinchronizuoti. Paprastai bet kuriame produktyviame moduliniame įrenginyje, susidedančiame iš daugybės elementų, viduje yra tas pats Clos tinklas, tačiau jį labai sunku diagnozuoti. Dažnai net pačiam pardavėjui sunku diagnozuoti.
Ir jis turi daugybę gedimų scenarijų, kai įrenginys sugenda, bet visiškai neiškrenta iš topologijos. Kadangi mūsų tinklas didelis, aktyviai naudojamas balansavimas tarp identiškų elementų, tinklas labai taisyklingas, tai yra vienas kelias, kuriame viskas tvarkoje, niekuo nesiskiria nuo kito, mums labiau apsimoka tiesiog prarasti dalį įrenginius iš topologijos, nei atsidurti situacijoje, kai atrodo, kad kai kurie iš jų veikia, bet kai kurie ne.
Kita graži vieno lusto įrenginių savybė yra ta, kad jie tobulėja ir greičiau. Jie taip pat turi didesnį pajėgumą. Jei paimtume dideles surinktas konstrukcijas, kurias turime ant apskritimo, tai tokio paties greičio prievadų stovo vieneto talpa yra beveik dvigubai didesnė nei modulinių įrenginių. Įrenginiai, sukurti aplink vieną lustą, yra pastebimai pigesni nei moduliniai ir sunaudoja mažiau energijos.
Bet, žinoma, visa tai yra dėl priežasties, yra ir trūkumų. Pirma, radiksas beveik visada yra mažesnis nei modulinių įrenginių. Jei galime gauti įrenginį, pastatytą aplink vieną lustą su 128 prievadais, tai dabar be jokių problemų galime gauti modulinį su keliais šimtais prievadų.
Tai pastebimai mažesnis persiuntimo lentelių dydis ir, kaip taisyklė, viskas, kas susiję su duomenų plokštumos masteliu. Sekli buferiai. Ir, kaip taisyklė, gana ribotas funkcionalumas. Tačiau paaiškėja, kad jei žinote šiuos apribojimus ir laiku pasirūpinsite jų apeiti arba tiesiog į juos atsižvelgsite, tai nėra taip baisu. Tai, kad radiksas yra mažesnis, nebėra problema įrenginiuose, kurių radiksas yra 128, kurie pagaliau pasirodė neseniai, galime statyti dviem sluoksniais spygliuočių. Tačiau vis tiek neįmanoma sukurti nieko mažesnio nei du, kas mums būtų įdomu. Su vienu lygiu gaunami labai maži klasteriai. Netgi mūsų ankstesni dizainai ir reikalavimai vis tiek juos viršijo.
Tiesą sakant, jei staiga sprendimas yra kažkur ant slenksčio, vis tiek yra būdas padidinti mastelį. Kadangi paskutinis (arba pirmasis), žemiausias serverių prijungimo lygis yra ToR jungikliai arba lapų jungikliai, mes neprivalome prie jų prijungti vieno stovo. Todėl, jei sprendimas sumažėja maždaug per pusę, galite pagalvoti apie tiesiog jungiklį su dideliu radiksu apatiniame lygyje ir, pavyzdžiui, dviejų ar trijų stelažų sujungimą į vieną jungiklį. Tai taip pat yra galimybė, ji turi savo išlaidų, tačiau ji veikia gana gerai ir gali būti geras sprendimas, kai reikia pasiekti maždaug dvigubai didesnį dydį.
Apibendrinant galima pasakyti, kad mes remiame topologiją su dviejų lygių stuburais su aštuoniais gamykliniais sluoksniais.
Kas atsitiks su fizika? Labai paprasti skaičiavimai. Jei turime dviejų lygių stuburus, tai turime tik trijų lygių jungiklius ir tikimės, kad tinkle bus trys kabelių segmentai: nuo serverių iki lapinių jungiklių, iki 1-ojo, iki 2-o. Galimi variantai naudojimas yra - tai twinax, daugiamodis, vieno režimas. Ir čia reikia apsvarstyti, kokia juosta yra, kiek ji kainuos, kokie fiziniai matmenys, kokius tarpus galime padengti ir kaip atnaujinsime.
Kalbant apie kainą, viską galima surikiuoti. Twinax’ai yra žymiai pigesni už aktyviąją optiką, pigesni už daugiamodius siųstuvus-imtuvus, jei imti vienam skrydžiui nuo galo, kažkiek pigiau nei 100 gigabitų komutatoriaus prievadas. Ir atkreipkite dėmesį, tai kainuoja pigiau nei vieno režimo optika, nes skrydžiuose, kur reikalingas vienas režimas, duomenų centruose dėl daugelio priežasčių prasminga naudoti CWDM, o lygiagretus vieno režimo (PSM) darbas nėra labai patogus. su labai didelėmis pakuotėmis gaunami pluoštai, o jei orientuotumės į šias technologijas, gautume maždaug tokią kainų hierarchiją.
Dar viena pastaba: deja, nelabai įmanoma naudoti išardytus 100–4x25 daugiamodius prievadus. Dėl SFP28 siųstuvų-imtuvų dizaino ypatumų jis nėra daug pigesnis nei 28 Gbit QSFP100. Ir šis kelių režimų išmontavimas neveikia labai gerai.
Kitas apribojimas yra tas, kad dėl skaičiavimo klasterių dydžio ir serverių skaičiaus mūsų duomenų centrai pasirodo fiziškai dideli. Tai reiškia, kad bent vieną skrydį reikės atlikti su singlemodu. Vėlgi, dėl fizinio „Pods“ dydžio nebus įmanoma paleisti dviejų „Twinax“ (varinių kabelių) atkarpų.
Dėl to, jei optimizuosime pagal kainą ir atsižvelgsime į šios konstrukcijos geometriją, gausime vieną twinax, vieną daugiamodį ir vieną vienmodžių intervalą naudodami CWDM. Tai atsižvelgia į galimus atnaujinimo kelius.
Štai kaip atrodo pastaruoju metu, kur einame ir kas įmanoma. Bent jau aišku, kaip pereiti prie 50 gigabitų „SerDe“ tiek daugiamodiams, tiek vienmodžiams. Be to, pažiūrėjus, kas dabar ir ateityje bus vienmodžiuose siųstuvuose-imtuvuose 400G, dažnai net ir atėjus 50G SerDams iš elektros pusės, 100 Gbps per juostą jau gali atitekti optikai. Todėl visai gali būti, kad vietoj perėjimo prie 50 bus pereinama prie 100 Gigabit SerDes ir 100 Gbps per juostą, nes pagal daugelio pardavėjų pažadus jų prieinamumo tikimasi gana greitai. Laikotarpis, kai 50G SerDes buvo greičiausi, panašu, nebus labai ilgas, nes jau beveik kitais metais pasirodys pirmosios 100G SerDes kopijos. Ir po kurio laiko jie tikriausiai bus verti pagrįstų pinigų.
Dar vienas niuansas apie fizikos pasirinkimą. Iš principo jau galime naudoti 400 arba 200 Gigabit prievadus naudodami 50G SerDes. Bet pasirodo, kad tai nėra labai prasminga, nes, kaip sakiau anksčiau, norime gana didelio jungiklių radikso, žinoma, proto ribose. Norim 128. O jei pas mus ribota lusto talpa ir didiname nuorodų greitį, tai radiksas natūraliai mažėja, stebuklų nebūna.
Ir mes galime padidinti bendrą pajėgumą naudojant lėktuvus, ir nėra jokių specialių išlaidų, galime pridėti lėktuvų skaičių. O jei prarasime radiksą, turėsime įvesti papildomą lygį, todėl dabartinėje situacijoje, esant dabartinei didžiausiai turimai talpai vienam lustui, pasirodo, kad efektyviau naudoti 100 gigabitų prievadus, nes jie leidžia jums gauti didesnį radiksą.
Kitas klausimas – kaip organizuota fizika, bet kabelinės infrastruktūros požiūriu. Pasirodo, jis suorganizuotas gana juokingai. Kabeliai tarp lapinių jungiklių ir pirmo lygio spyglių - ten nėra daug grandžių, viskas pastatyta palyginti paprastai. Bet jei paimtume vieną plokštumą, viduje atsitinka taip, kad reikia sujungti visus pirmojo lygio stuburus su visais antrojo lygio stuburais.
Be to, paprastai yra keletas pageidavimų, kaip jis turėtų atrodyti duomenų centre. Pavyzdžiui, mes labai norėjome sujungti kabelius į ryšulį ir ištraukti juos taip, kad viena didelio tankio pataisų skydelis patektų į vieną skydelį, kad nebūtų zoologijos sodo pagal ilgius. Mums pavyko išspręsti šią problemą. Jei iš pradžių pažvelgsite į loginę topologiją, pamatysite, kad plokštumos yra nepriklausomos, kiekviena plokštuma gali būti pastatyta atskirai. Bet kai pridedame tokį sujungimą ir norime nuvilkti visą pataisų skydelį į pataisų skydelį, turime sumaišyti skirtingas plokštumas viename pakete ir įdiegti tarpinę struktūrą optinių kryžminių jungčių pavidalu, kad būtų galima perpakuoti juos iš to, kaip jie buvo surinkti. viename segmente , kaip jie bus renkami kitame segmente. Dėl to gauname gražią savybę: visas sudėtingas perjungimas neviršija stelažų. Kai reikia ką nors labai stipriai supinti, „išlankstyti plokštumas“, kaip kartais vadinama Clos tinkluose, visa tai susikaupia viename stove. Mes neturime labai išardytų, iki atskirų jungčių, perjungimo tarp stelažų.
Taip tai atrodo loginio kabelinės infrastruktūros organizavimo požiūriu. Kairėje esančiame paveikslėlyje ant įvairiaspalvių blokų pavaizduoti pirmojo lygio nugarinių jungiklių blokai, po aštuonis vienetus, ir keturi iš jų einantys kabelių ryšuliai, kurie eina ir susikerta su ryšuliais, gaunamais iš spine-2 jungiklių blokų. .
Maži kvadratėliai žymi sankryžas. Viršuje kairėje yra kiekvienos tokios sankryžos suskirstymas, tai iš tikrųjų yra 512 x 512 prievadų kryžminio jungimo modulis, kuris perpakuoja kabelius taip, kad jie visiškai patektų į vieną stovą, kur yra tik viena stuburo-2 plokštuma. O dešinėje šio paveikslėlio nuskaitymas yra šiek tiek išsamesnis, palyginti su keliais stuburo 1 lygyje esančiomis ankštimis ir kaip jis supakuotas kryžminėje jungtyje, kaip jis ateina į stuburo 2 lygį.
Štai kaip atrodo. Dar ne iki galo surinktas spine-2 stovas (kairėje) ir kryžminio sujungimo stovas. Deja, ten nelabai yra ką pamatyti. Visa ši struktūra šiuo metu yra įdiegta viename iš mūsų didelių duomenų centrų, kuris plečiamas. Tai nebaigtas darbas, jis atrodys gražiau, bus geriau užpildytas.
Svarbus klausimas: pasirinkome loginę topologiją ir sukūrėme fiziką. Kas atsitiks su valdymo plokštuma? Tai gana gerai žinoma iš eksploatacinės patirties, yra nemažai pranešimų, kad susieti būsenos protokolai yra geri, malonu su jais dirbti, bet, deja, jie netinkamai keičiasi tankiai sujungtoje topologijoje. Ir yra vienas pagrindinis veiksnys, kuris to neleidžia – taip užtvindymas veikia nuorodų būsenos protokoluose. Jei tiesiog paimtumėte užtvindymo algoritmą ir pažiūrėtumėte, kaip mūsų tinklas yra struktūrizuotas, pamatysite, kad kiekviename žingsnyje bus labai didelis fanoutas ir jis tiesiog užtvindys valdymo plokštumą atnaujinimais. Tiksliau, tokios topologijos labai prastai derinamos su tradiciniu užtvindymo algoritmu ryšio būsenos protokoluose.
Pasirinkimas yra naudoti BGP. Kaip tinkamai jį paruošti, aprašyta RFC 7938 apie BGP naudojimą dideliuose duomenų centruose. Pagrindinės idėjos yra paprastos: minimalus priešdėlių skaičius viename pagrindiniame kompiuteryje ir apskritai minimalus priešdėlių skaičius tinkle, jei įmanoma, naudokite agregaciją ir užblokuokite kelių paiešką. Mes norime labai kruopštaus, labai kontroliuojamo atnaujinimų platinimo, vadinamo „valley free“. Norime, kad naujinimai būtų įdiegti tiksliai vieną kartą, kai jie praeina per tinklą. Jei jie atsiranda apačioje, jie kyla aukštyn, išsiskleidžia ne daugiau kaip vieną kartą. Neturi būti jokių zigzagų. Zigzagai yra labai blogi.
Norėdami tai padaryti, naudojame dizainą, kuris yra pakankamai paprastas, kad būtų galima naudoti pagrindinius BGP mechanizmus. Tai yra, mes naudojame eBGP, veikiančią vietinėje nuorodoje, o autonominės sistemos yra priskiriamos taip: autonominė sistema ToR, autonominė sistema visame vieno Pod spine-1 jungiklių bloke ir bendra autonominė sistema visame viršuje. iš audinio. Nesunku pažvelgti ir pamatyti, kad net įprastas BGP elgesys suteikia mums norimų naujinimų platinimą.
Natūralu, kad adresavimas ir adresų agregavimas turi būti suprojektuoti taip, kad būtų suderinami su maršruto sudarymo būdu, kad būtų užtikrintas valdymo plokštumos stabilumas. L3 adresas transporte yra susietas su topologija, nes be jos neįmanoma pasiekti agregacijos, be to atskiri adresai pateks į maršruto parinkimo sistemą. Ir dar vienas dalykas, kad agregacija, deja, nelabai dera su multi-path, nes kai turime multi-path ir turime agregaciją, tai viskas gerai, kai visas tinklas sveikas, jame nėra jokių gedimų. Deja, kai tik tinkle atsiranda gedimų ir prarandama topologijos simetrija, galime pasiekti tašką, nuo kurio buvo paskelbtas agregatas, iš kurio negalime eiti toliau ten, kur reikia. Todėl geriausia agreguoti ten, kur daugiau nėra kelių kelių, mūsų atveju tai yra ToR jungikliai.
Tiesą sakant, agreguoti galima, bet atsargiai. Jei galime atlikti kontroliuojamą skaidymą, kai atsiranda tinklo gedimų. Bet tai gana sudėtinga užduotis, mes net galvojome, ar tai būtų įmanoma padaryti, ar galima pridėti papildomos automatikos ir baigtinių būsenų mašinų, kurios teisingai išmuštų BGP, kad gautų norimą elgesį. Deja, kampinių atvejų apdorojimas yra labai neaiškus ir sudėtingas, todėl ši užduotis nėra gerai išspręsta prijungus išorinius priedus prie BGP.
Labai įdomus darbas šiuo klausimu buvo atliktas pagal RIFT protokolą, kuris bus aptartas kitoje ataskaitoje.
Kitas svarbus dalykas yra tai, kaip duomenų plokštumos mastelis tankiose topologijose, kur turime daug alternatyvių kelių. Šiuo atveju naudojamos kelios papildomos duomenų struktūros: ECMP grupės, kurios savo ruožtu apibūdina Next Hop grupes.
Įprastai veikiančiame tinkle be gedimų, kai kylame Clos topologija aukštyn, užtenka naudoti tik vieną grupę, nes viskas, kas nėra lokali, yra aprašyta pagal nutylėjimą, galime kilti aukštyn. Kai einame iš viršaus į apačią į pietus, tada visi keliai nėra ECMP, jie yra vieno kelio takai. Viskas gerai. Bėda ta, kad klasikinės Clos topologijos ypatumas yra tas, kad jei žiūrėtume į audinio viršų, į bet kurį elementą, yra tik vienas kelias į bet kurį žemiau esantį elementą. Jei šiame kelyje atsiranda gedimų, šis konkretus elementas gamyklos viršuje tampa negaliojantis būtent tiems priešdams, kurie yra už nutrūkusio kelio. Tačiau likusiai daliai jis galioja, ir mes turime išanalizuoti ECMP grupes ir įvesti naują būseną.
Kaip duomenų plokštumos mastelio keitimas atrodo šiuolaikiniuose įrenginiuose? Jei darytume LPM (ilgiausias priešdėlio atitikimas), viskas gana gerai, virš 100 tūkst. Jei kalbame apie Next Hop grupes, tai viskas yra blogiau, 2-4 tūkst. Jei mes kalbame apie lentelę, kurioje yra Next Hops (arba gretimų vietų) aprašymas, tai yra kažkur nuo 16 64 iki XNUMX XNUMX. Ir tai gali tapti problema. Ir čia pasiekiame įdomų nukrypimą: kas atsitiko su MPLS duomenų centruose? Iš principo mes norėjome tai padaryti.
Įvyko du dalykai. Mes atlikome mikrosegmentavimą pagrindiniuose kompiuteriuose; mums nebereikėjo to daryti tinkle. Tai nebuvo labai gera naudojant skirtingų tiekėjų palaikymą, o tuo labiau - su atvirais diegimais baltose dėžutėse su MPLS. O MPLS, bent jau tradiciniai jos diegimai, deja, labai prastai dera su ECMP. Ir todėl.
Taip atrodo ECMP IP persiuntimo struktūra. Daugybė priešdėlių gali naudoti tą pačią grupę ir tą patį Next Hops bloką (arba gretimus, skirtinguose skirtingų įrenginių dokumentuose tai gali būti vadinama skirtingai). Esmė ta, kad tai apibūdinama kaip išeinantis prievadas ir į ką reikia perrašyti MAC adresą, kad patektumėte į tinkamą Next Hop. Dėl IP viskas atrodo paprasta, galite naudoti labai daug priešdėlių tai pačiai grupei, tam pačiam Next Hops blokui.
Klasikinė MPLS architektūra reiškia, kad, priklausomai nuo išeinančios sąsajos, etiketė gali būti perrašyta į skirtingas reikšmes. Todėl kiekvienai įvesties etiketei turime išlaikyti grupę ir Next Hops bloką. Ir tai, deja, nesikeičia.
Nesunku pastebėti, kad mūsų konstrukcijoje mums prireikė apie 4000 ToR jungiklių, didžiausias plotis buvo 64 ECMP keliai, jei nuo stuburo-1 pereisime link 2. Vos patenkame į vieną ECMP grupių lentelę, jei tik vienas priešdėlis su ToR išnyksta, o į Next Hops lentelę visai nepatenkame.
Tai nėra beviltiška, nes tokios architektūros kaip Segment Routing apima pasaulines etiketes. Formaliai būtų galima vėl sugriauti visus šiuos „Next Hops“ blokus. Norėdami tai padaryti, jums reikia laukinės kortelės tipo operacijos: paimkite etiketę ir perrašykite ją į tą pačią be konkrečios reikšmės. Bet, deja, to nėra labai prieinamuose diegimuose.
Ir galiausiai, į duomenų centrą turime nukreipti išorinį srautą. Kaip tai padaryti? Anksčiau srautas į Clos tinklą buvo įvestas iš viršaus. Tai yra, buvo krašto maršrutizatoriai, kurie buvo prijungti prie visų įrenginių, esančių audinio viršuje. Šis sprendimas gana gerai tinka mažiems ir vidutiniams dydžiams. Deja, norėdami tokiu būdu simetriškai siųsti srautą į visą tinklą, turime vienu metu pasiekti visus „Top of fabric“ elementus, o kai jų yra daugiau nei šimtas, paaiškėja, kad reikia ir didelio radikso. krašto maršrutizatoriai. Apskritai tai kainuoja, nes krašto maršrutizatoriai yra funkcionalesni, jų prievadai bus brangesni, o dizainas nėra labai gražus.
Kitas variantas – tokį srautą pradėti iš apačios. Nesunku patikrinti, ar „Clos“ topologija sukurta taip, kad srautas, einantis iš apačios, ty iš ToR pusės, būtų tolygiai paskirstytas tarp lygių per visą audinio viršutinę dalį dviem iteracijomis, apkraunant visą tinklą. Todėl pristatome specialų Pod tipą Edge Pod, kuris užtikrina išorinį ryšį.
Yra dar vienas variantas. Pavyzdžiui, tai daro „Facebook“. Jie tai vadina audinių agregatoriumi arba HGRID. Įvedamas papildomas stuburo lygis, skirtas sujungti kelis duomenų centrus. Toks dizainas įmanomas, jei sąsajose neturime papildomų funkcijų ar inkapsuliacijos pakeitimų. Jei tai yra papildomi kontaktiniai taškai, sunku. Paprastai yra daugiau funkcijų ir savotiška membrana, skirianti skirtingas duomenų centro dalis. Didelę tokią membraną daryti nėra prasmės, bet jei dėl kokių nors priežasčių ji tikrai reikalinga, tada prasminga apsvarstyti galimybę ją nuimti, padaryti kuo platesnę ir perduoti šeimininkams. Tai daro, pavyzdžiui, daugelis debesų operatorių. Jie turi perdangas, prasideda nuo šeimininkų.
Kokias plėtros galimybes matome? Visų pirma, patobulinti CI/CD konvejerio palaikymą. Mes norime skristi taip, kaip išbandome, ir išbandyti, kaip skrendame. Tai nelabai pavyksta, nes infrastruktūra didelė ir jos dubliuoti bandymams neįmanoma. Turite suprasti, kaip įdiegti testavimo elementus į gamybos infrastruktūrą jos nenumetant.
Geresni prietaisai ir geresnė stebėsena beveik niekada nėra nereikalingi. Visas klausimas yra pastangų ir grąžos balansas. Jei galite jį pridėti su protingomis pastangomis, labai gerai.
Atviros operacinės sistemos tinklo įrenginiams. Geresni protokolai ir geresnės maršruto parinkimo sistemos, pvz., RIFT. Taip pat reikia ištirti geresnių perkrovos kontrolės schemų naudojimą ir galbūt bent kai kuriais atvejais RDMA palaikymą klasteryje.
Žvelgiant į tolesnę ateitį, mums reikia pažangių topologijų ir galbūt tinklų, kurie naudoja mažiau pridėtinių sąnaudų. Neseniai pasirodė publikacijų apie HPC Cray Slingshot audinių technologiją, kuri yra pagrįsta prekiniu eternetu, tačiau su galimybe naudoti daug trumpesnes antraštes. Dėl to sumažėja pridėtinės išlaidos.
Viskas turėtų būti kuo paprastesnė, bet ne paprasčiau. Sudėtingumas yra mastelio priešas. Paprastumas ir taisyklingos struktūros yra mūsų draugai. Jei galite kur nors padidinti mastelį, padarykite tai. Ir apskritai puiku dabar dalyvauti tinklo technologijose. Vyksta daug įdomių dalykų. Ačiū.
Šaltinis: www.habr.com