Kuidas andmekeskusi skaleerida. Yandexi ettekanne

Oleme välja töötanud andmekeskuste võrgu disaini, mis võimaldab juurutada kompuuteriklastritega, mille suurus ületab 100 tuhat serverit ja maksimum bisection bandwidth on üle ühe petabaiti sekundis.

Dmitri Afanasevi ettekandest saate teada uue disaini põhialustest, topoloogiate skaleerimisest, tekkivatest probleemidest, võimalustest nende lahendamiseks, saatmisplaani funktsioonide marsruutimise ja skaleerimise eripärast, kaasaegsete võrguseadmete "tihedates" topoloogiates, kus on palju ECMP-marsroute. Lisaks rääkis Dima lühidalt välise ühenduvuse korraldusest, füüsilisest tasemest, kaabli süsteemist ja edasise mahutavuse suurendamise võimalustest.

— Tere kõigile! Minu nimi on Dmitri Afanasev, olen Yandexi võrguarhitekt ja tegelen peamiselt andmekeskuste võrkude disainiga.



Minu lugu räägib Yandexi andmekeskuste uuendatud võrgust. See on suuresti evolutsioon meie varasemast disainist, kuid samas on ka mõned uued elemendid. See on ülevaatlik esitlus, kuna tuli mahutada üsna palju teavet lühikesse aega. Alustame loogilise topoloogia valikust. Järgneb ülevaade juhtimistasemest ja probleemidest andmeplaani skaleeritavuses, otsustamine selle üle, mis toimub füüsilisel tasandil, ning vaatame mõningaid seadmete omadusi. Veidi puudutame ka seda, mis toimub andmekeskuses MPLS-i osas, millest oleme mõni aeg tagasi rääkinud.

Nii, mis on Yandex koormuste ja teenuste seisukohalt? Yandex on tüüpiline hüper-skaalija. Kui rääkida kasutajatest, siis toimub meil esmalt kasutajate päringute töötlemine. Samuti erinevad voogedastusteenused ja andmete edastamine, sest meil on ka salvestusteenused. Kui vaadata tagapool, siis ilmnevad seal infrastruktuuri koormused ja teenused, nagu jaotatud objektihoidlad, andmete replikatsioon ja muidugi ka püsikud. Üks peamisi koormuste tüüpe on MapReduce ja sellised süsteemid, voogedastus, masinõpe jne.

Kuidas on üles ehitatud infrastruktuur, mille peal see kõik toimub? Oleme täiesti tüüpiline hüperskaalaja, ehkki võib-olla oleme veidi lähemal sellele spektri poole, kus asuvad pisut väiksemad hüperskaalajad. Kuid meil on kõik vajalikud atribuudid. Kasutame kommoditeediga riistvara ja horisontaalset skaleerimist, kus iganes seda on võimalik rakendada. Meil on täielikult olemas ressursside jagamine: me ei tööta üksikute masinate või rackidega, vaid ühendame need suureks asendatavate ressursside basseiniks koos täiendavate teenustega, mis tegelevad selle planeerimise ja jaotamisega ning töötame kogu selle basseini peal.

Nii tekib meil järgmine tase - operatsioonisüsteem arvutusklastrite tasemel. On väga oluline, et kontrollime täielikult kasutatavat tehnoloogiat. Kontrollime lõpp-punkte (hosteid), võrku ja tarkvarakuhjat.

Meil on mitmeid suured andmekeskused Venemaal ja välismaal. Need on ühendatud MPLS-tehnoloogial põhineva backbone'i kaudu. Meie siseinfrastruktuur on peaaegu täielikult rajatud IPv6-le, kuid kuna peame teenindama välist liiklust, mis tuleb endiselt peamiselt IPv4 kaudu, peame kuidagi toimetama IPv4 kaudu saabuvad päringud frontend-serverite, ja natuke käima ka välises IPv4-internetis — näiteks indekseerimiseks.

Viimased mitmed andmekeskuste võrgu disaini iteratsioonid kasutavad mitmeastmelisi Clos-topoloogiaid ja rakendavad ainult L3. Oleme L2-st mõnda aega tagasi loobunud ja tunneka rahulolu. Lõpuks sisaldab meie infrastruktuur sadu tuhandeid arvutuslikke (serveri) instantsse. Klaster suurus oli mõnda aega tagasi umbes 10 000 serverit. See on suures osas tingitud sellest, kuidas töötavad just need klastritaseme operatsioonisüsteemid, planeerijad, ressursside jaotamine jne. Kuna infrastruktuuri tarkvara osas on toimunud edusamme, on praegune sihtmärk umbes 100 000 serverit ühes arvutuslikus klastris, ja meie ees seisab ülesanne - osata ehitada võrgu tehaseid, mis võimaldavad tõhusalt ressursse nende klastrite sees koguda.

Mida me siis tahame andmekeskuse võrgult? Esiteks, palju odavat ja piisavalt ühtlaselt jaotatud ribalaiust. Sest võrgu kaudu saame ressursse koguda. Uus sihtmärk on umbes 100 000 serverit ühes klastris.

Meie jaoks on oluline, et meil oleks skaleeritav ja usaldusväärne juhtimistasand (control plane), kuna suure infrastruktuuri puhul tekib piisavalt peavalu isegi lihtsalt juhuslike sündmuste tõttu, ja me ei soovi, et juhtimistasand meile veel peavalu valmistaks. Samuti tahame selle seisundit minimeerida. Mida vähem seisundi, seda paremini ja stabiilsemalt kõik töötab ning on kergem diagnoosida.

Loomulikult vajame automatiseerimist, sest sellise infrastruktuuri käsitsi haldamine on võimatu ja on olnud juba mõnda aega. Me vajame võimaluse korral operatiivtoetust ja CI/CD toe pakkumist, nii palju kui võimalik.

Nii suurte andmekeskuste ja klastri korral on juba teravalt tõstatunud küsimus inkrementaalse juurutamise ja laienemise toetu hõlbustamisest ilma teenuse katkemiseta. Kui tuhandest masinast koosnevates klastrites, võib-olla kümnest tuhandest masinast, sai süsteemi uued erinevad uuendused viia läbi ühe operatsioonina — mis tähendab, et plaanime infrastruktuuri laiendamist, ning mitu tuhat masinat lisatakse ühe operatsioonina, siis klaster, mille suurus on umbes sada tuhat masinat, ei tule järsku. See ehitatakse teatud aja jooksul. Ja oleks soovitav, et kogu see aeg oleks juba tehtud, see infrastruktuur, mis on juurutatud, kergesti kättesaadav.

Ja üks nõue, mis meil oli ja kadus: see on multitenantsuse tugi, ehk virtualiseerimine või võrgu segmentimine. Nüüd ei pea me seda tegema võrgu tehasete tasemel, kuna segmentimine läks hostide peale ning see on meile väga palju lihtsustanud skaleerimist. Tänu IPv6-le ja suurele aadressiruumile ei pidanud me sisemises infrastruktuuris kasutama dubleeritud aadresse, kõik aadressid olid nii või teisiti unikaalsed. Ja kuna me on võrgu filtreerimise ja segmentimise viinud hostidele, ei pea me looma mingisuguseid virtuaalseid võrguolekuid andmekeskuste võrkudes.

Eriti oluline on see, et me ei pea midagi. Kui mõned funktsioonid saab võrgu hulgast eemaldada, siis see väga lihtsustab elu ning tavaliselt laiendab saadaval oleva varustuse ja tarkvara valikut, lihtsustab oluliselt diagnostikat.

Nii et mida me ei vaja, millest me saime loobuda, mitte alati rõõmuga hetkel, kui see toimus, kuid suure kergendusega, kui protsess lõpetati?

Esiteks, loobume L2-st. Me ei vaja L2-d, ei reaalset ega emuleeritud. Seda ei kasutata suuresti, kuna kontrollime rakenduste steki. Meie rakendused skaleeruvad horisontaalselt, nad töötavad L3-aadressimisega ja neid ei muretse eriti, kui mõni eraldi instants ebaõnnestub, lihtsalt rakendatakse uus; sellel ei pea olema vanal aadressil, kuna on olemas eraldi teenuse avastamise ja jälgimise tase, mis tegeleb klastris olevate masinatega. Me ei pane seda ülesannet võrgu peale. Võrgu ülesanne on edastada pakette punktist A punkti B.

Meil ei esine olukordi, kus aadressid liiguvad võrgu sees ja seda tuleb jälgida. Paljudes disainides on see reeglina vajalik VM mobiilsuse toetamiseks. Me ei kasuta virtuaalmasinate mobiilsust suurte Yandexi sisemiste süsteemide jaoks ning usume, et isegi kui seda tehakse, ei peaks see toimuma võrgu toe abil. Kui on tõeliselt vajalik, tuleb see teha hostide tasandil ja suunata migreeritavad aadressid overlay'desse, et mitte segada ja teha liiga palju dünaamilisi muudatusi oma allveevõrgu (transportvõrgu) marsruutimissüsteemis.

Veel üks tehnoloogia, mida me ei kasuta, on multikast. Huvi korral saan rääkida selle kasutamise põhjustest. See muudab elu oluliselt lihtsamaks, kuna kui keegi on seda kogenud ja vaadanud, kuidas täpselt multikasti kontrollplaan välja näeb — kõigis instalatsioonides, välja arvatud kõige lihtsamates, on see suur peavalu. Veelgi enam, raske on leida hästi toimivat avatud lahendust, näiteks.

Ja lõpuks, me kujundame meie võrgud nii, et seal ei toimuks liiga palju muutusi. Saame usaldada, et väliste sündmuste voog marsruutimissüsteemis on väike.

Milliseid probleeme ja piiranguid tuleb arvesse võtta, kui me arendame andmekeskuse võrku? Muidugi, kulud. Skaalautuvus, see, kui kaugele me soovime kasvada. Vajadus laiendada ilma teenuse katkestamiseta. Läbivus, saadavus. Võrgu toimuvate sündmuste nähtavus jälgimissüsteemidele, operatiivsetele meeskondadele. Automaatimise tugi — jälle, nii palju kui võimalik, kuna erinevaid ülesandeid saab lahendada erinevatel tasanditel, sealhulgas lisakihtide tutvustamisega. Ja mitte-[võimaluse]-sõltuvus tarnijatest. Kuigi eri ajaloolistel perioodidel, sõltuvalt sellest, millisele lõikele vaadata, on see sõltumatus olnud kergem või raskem saavutatav. Kui võtame võrgu seadmete kiipide lõike, siis kuni viimase ajani oli hinnata sõltumatust tarnijatest, kui soovisime ka suure läbilaskevõimega kiipe, väga tingimuslikult.

Kuidas me siis loome oma võrku loogilise topoloogia alusel? See saab olema mitmetasandiline Clos. Tegelikult ei ole praegu tõsiseltvõetavaid alternatiive. Clos-topoloogia on piisavalt hea, isegi võrreldes erinevate arenenud topoloogiatega, mis praegu on peamiselt akadeemilise huvi valdkonnas, kui meil on suure radikiga switchid.

Kuidas on mitmetasandiline Clos-võrk üles ehitatud ja kuidas nimetatakse selles erinevaid komponente? Esiteks, tuuleosa, et orienteeruda, kus on põhjas, kus lõunas, kus idas, kus läänes. Sellist tüüpi võrke ehitavad tavaliselt need, kellel on väga suur lääne-idatugevus. Mis puutub teistesse komponentidesse, siis ülalt on kujutatud virtuaalne switch, mis on koostatud väiksematest switchidest. See on Clos-võrkude rekursiivse ülesehitamise peamine idee. Võtame elemendid, millel on mingi radik, ja ühendame need nii, et saadud struktuuri saab pidada suure radikiga switchiks. Kui on vaja veel rohkem, saab protseduuri korrata.

Näiteks kahesplitiliste Clos'ide puhul, kus on selgelt eristatud komponente, mida minu skeemil esitatakse vertikaalselt, tuntakse neid tasanditena. Kui me ehitaksime Clos'i kolme tasemega spine-lülititega (kõik, mis ei ole piir- ega ToR-lülitid ja mida kasutatakse ainult transiidiks), siis näeksid tasandid keerulisemad välja; kahe tasemega on need just sellised. ToR- või leaf-lülitite plokk ja nendega seotud esimese taseme spine-lülitid on meil nimetatud Pod'ideks. Spine-lülitid tasemel spine-1 Pod'i tipus — see on Pod'i ülemine osa. Lülitid, mis asuvad kogu tehase üleval — need on tehase ülemine kiht, Top of fabric.

Muidugi tekib küsimus: Clos-võrgud on juba mõnda aega ehitatud, idea alus pärineb klassikalisest telefonivõrgust ja TDM-võrkudest. Võib-olla on midagi paremat ilmnenud, võib-olla saaks midagi paremini teha? Ja jah, ja ei. Teoreetiliselt jah, kuid praktikas ei. Seda seetõttu, et on mõned huvitavad topoloogiad, millest osa kasutatakse isegi tootmises, näiteks Dragonfly HPC-rakendustes; on ka huvitavaid topoloogiaid nagu Xpander, FatClique, Jellyfish. Kui vaadata viimasel ajal SIGCOMM või NSDI konverentsidel esitatud ettekandeid, võib avastada üsna palju töid alternatiivsete topoloogiate kohta, mis omavad paremaid omadusi (teatud või teiste) kui Clos.

Kuid kõigil neil topoloogiatel on üks huvitav omadus. See takistab nende juurutamist andmekeskuste võrkudes, mida üritame ehitada tavalisel riistvaral ja mis on piisavalt mõistliku hinnaga. Kõigis neis alternatiivsetes topoloogiates on kahjuks suur osa ribalaiust saadaval mitte kõige lühemate teede kaudu. Seetõttu jääme kohe ilma võimalusest kasutada traditsioonilist juhtimistaset.

Teoreetiliselt on ülesande lahendus teada. See on näiteks link state modifikatsioonid k-lüheima tee kasutamisega, kuid siiski ei ole selliseid protokolle, mis oleksid rakendatud tootmises ja laialdaselt saadaval varustuses.

Lisaks, kuna suurem osa mahutavusest ei ole saadaval lüheima teede kaudu, peame modifitseerima mitte ainult juhtimisplaani, et see valiks kõik need teed (ja muide, see on palju suurem olek juhtimisplaanis). Peame samuti modifitseerima edasiandmise plaani ning üldiselt on vajalik vähemalt kaks lisafunktsiooni. See on võimalus teha kõik edasiandmise otsused korraga, näiteks hostis. Tegelikult on see source routing, mõnikord nimetatakse seda interconnection networks'i kirjanduses all-at-once forwarding decisions. Ja veel on vajalik adapteeruv marsruutimine — see on juba funktsioon, mida vajame võrguelementidelt, mis hõlmab näiteks järgmise hüppe valimist, tuginedes kõige madalama järjekorra koormuse teabele. Näiteks võivad olla ka teised variandid.

Seega on suund huvitav, kuid kahjuks ei saa me seda praegu rakendada.

Okei, peatume Clos-loogilise topoloogia juures. Kuidas me seda laiendame? Vaatame, kuidas see on üles ehitatud ja mida saame teha.

Clos-võrgus on kaks peamist parameetrit, mida saame varieerida ja seeläbi erinevaid tulemusi saavutada: elementide radiks ja võrgutasemete arv. Mul on skeem, mis näitab, kuidas need mõjutavad suurust. Ideaalis kombineerime mõlemat.

On selgelt näha, et Clos-võrgu lõplik laius on spaini lülitite lõikes lääne radiks ja see, kui palju linke me allapoole omame, kuidas see hargneb. Siin on, kuidas me võrgu suurust laiendame.

Mis puudutab mahtu, eriti ToR-lülititega, siis on kaks võimalust laiendamiseks. Kas saame, säilitades üldise topoloogia, kasutada kiiremaid linke või saame lisada rohkem tasandeid.

Kui vaatame avatud Clos-võrgu versioonile (paremas alumises nurgas) ja tagasi sellele Clos-võrgu pildile…

… siis see on täpselt sama topoloogia, kuid sellel slaidil on see kokku volditud kompaktsemalt ja tehase tasandid on üksteise peale ladustatud. See on üks ja sama.

Kuidas näeb välja Clos-võrgu skaleerimine numbrites? Siin esitan andmed selle kohta, kui suure maksimaalse laiuse võib võrgu saavutada, kui palju riiuleid, ToR-lüliteid või lehtlüliteid, kui need ei asu riiulites, saame sõltuvalt sellest, millised on meie rootorilülitid, mida kasutatakse spine-tasemetel, ja kui palju tasemeid me sondeerime.

Siin on näidatud, kui palju riiuleid meil võib olla, kui palju servereid ning kui palju see kõik kokku võib tarbida, arvestades 20 kW riiuli kohta. Natuke varem mainisin, et meie eesmärk on umbes 100 000 serverist koosnev klaster.

On näha, et kogu selle struktuuri kontekstis pakuvad huvi kaks ja pool varianti. On variant kahe kihiga spainide ja 64-portiliste switchidega, mis on veidi madalamal tasemel. Seejärel on suurepäraselt sobivad variandid 128-portiliste (radix 128) spine-switchide jaoks kahel tasemel või 32 radix switchid kolme taseme osas. Igal juhul, kus on suurem radix ja rohkem tasemeid, on võimalik luua väga suur võrgu struktuur, kuid kui vaadata oodatavat tarbimist, on see tavaliselt gigavatid. Kaabli võib paigaldada, aga nii palju elektrit ühes kohas me tõenäoliselt ei saa. Kui vaadata statistikat, avalikke andmeid andmekeskuste kohta, siis on väga vähe andmekeskuseid, mille arvutatud võimsus ületab 150 MW. Kõik, mis sellest rohkem, on tavaliselt andmekeskuste kampused, kus asub mitu suurt andmekeskust, mis on piisavalt lähedal üksteisele.

On oluline see, et kui vaadata vasakut veergu, siis on seal näidatud kasutatav ribalaius. Pole raske märgata, et Clos-võrgus kulub märkimisväärne osa portidest, et ühendada lülitid omavahel. Kasutatav ribalaius - see, mida saab suunata väljapoole, serverite suunas. Loomulikult räägin tinglikest portidest ja just ribalaiusest. Üldjuhul on ühendused võrgu sees kiiremad kui ühendused serverite suunas, kuid iga ribalaius, mida saame suunata, kulutab osa ribalaiusest, mis on seesama võrgus. Mida rohkem tasandeid loome, seda suuremad on kulud selle ribalaiuse pakkumiseks väljapoole.

Peale selle pole isegi see täiendav ribalaius täiesti ühtlane. Kui vahemaa on lühike, saame kasutada midagi nagu DAC (direct attach copper ehk twinax-kaablid) või multimode optikat, mis on veel enam-vähem mõistlikus hinnaklassis. Kui liikume pikemate vahemaade juurde - tavaliselt on see single mode optika ning selle täiendava ribalaiuse maksumus tõuseb märkimisväärselt.

Ja nagu ma eelneval slaidil mainisin, kui me loome Clos-võrku ilma ümberregistreerimiseta, on lihtne vaadata skeemi ja näha, kuidas võrku ehitatakse – iga spain-lüliti taseme lisamisel korratakse kogu riba, mis oli allpool. Pluss taseme – pluss sama riba, veel nii palju, kui oli eelmisel tasemel, lülitite porte, veel nii palju transiiverit. Seetõttu on soovitatav minimaalne spain-lülitite tasemete arv.

Selle pildi põhjal on selge, et soovime ehitada midagi sarnast 128-radikaalsed lülitid.

Siin on põhimõtteliselt kõik see, mida ma just rääkisin, see slaid on pigem hilisemaks aruteluks.

Millised valikud on olemas, mida saame selliste lülitite jaoks valida? Meie jaoks on väga hea uudis, et nüüd on lõpuks võimalik selliseid võrke ehitada ühekiibiliste lülititega. See on tõesti hämmastav, nad omavad palju meeldivaid omadusi. Näiteks on nende sisemine struktuur peaaegu puudulik. See tähendab, et need murduvad lihtsamalt. Nad murduvad, ei saa sellest aru, kuid õnneks murduvad nad täielikult. Mooduliseadmetes on palju rikkeid (väga ebameeldivaid), kui naaber- ja juhtimistasandi vaatepunktist see näib töötavat, kuid näiteks on osa tehase võimetest kadunud ja see ei tööta täielikul mahul. Ja sellele suunatud liiklus tasakaalustatakse lähtuvalt sellest, et see on täielikult funktsionaalne, kuid me võime saada ülekoormuse.

Näiteks võivad bensiinimootorites tekkida probleemid tagasikutsumisega, sest moodultaolises seadmes on ka kõrge kiirus SerDes’id – see on tõeliselt keeruline. Või kas tabelid sünkroniseeritakse või mitte edastamise elementide vahel. Üldiselt sisaldab iga jõudlusega mooduliseade, mis koosneb suurest arvust elementidest, enda sees ikka sama Clos-võrku, ainult et seda on väga raske diagnoosida. Sageli on isegi tarnijal keeruline seda diagnoosida.

Ja sellel on palju rikke stsenaariume, kus seade degraneerub, kuid ei lange täielikult topoloogiast välja. Kuna meie võrk on suur, kasutatakse aktiivselt tasakaalustamist identsete elementide vahel, on võrk väga regulaarne, see tähendab, et üks tee, kus kõik on korras, ei erine teistest teedest, siis on meie jaoks kasulikum lihtsalt kaotada osa seadmeid topoloogiast, kui sattuda olukorda, kus mõned neist näiliselt töötavad, kuid ei tööta.

Järgmine meeldiv omadus ühekiibiliste seadmete puhul on, et need arenevad paremini ja kiiremini. Samuti on neil tavaliselt parem maht. Kui vaadata meie suuremaid kogumisi, siis on mahutavus rack-üksuse kohta samade kiirusportide puhul peaaegu kaks korda parem kui moodul-seadmetel. Ühe kiibi ümber ehitatud seadmed on märkimisväärselt odavamad kui moodul-seadmed ja tarbivad vähem energiat.

Aga loomulikult, see kõik ei tule tasuta – on ka puudusi. Esiteks on praktiliselt alati väiksem radikaal võrreldes moodul-seadmetega. Kui saame ühe kiibi kesksete seadmete puhul 128 porti, siis moodulite puhul saame juba praegu üsna kergesti mitusada porti.

See on märkimisväärselt väiksem suunamis tabelite maht ja üldiselt kõik, mis puudutab andmeplaadi skaleeritavust. Pinnapealsed puhvried. Ja üldiselt on funktsionaalsus üsna piiratud. Kuid selgub, et kui need piirangud teada ja õigel ajal hoolitseda nende ületamise või arvestamise eest, siis tegelikult ei ole see nii hirmutav. Radixi väiksemus ei ole probleemiks uutel, lõpuks ilmuvatel 128 radiks seadmetel, saame ehitada kahes kihis spinaid. Ja väiksema kui kaks ei saa me ikkagi midagi huvitavat ehitada. Ühe tasemega on tulemuseks täiesti väikesed klastrid. Isegi meie eelmised kujundused ja nõudmised ületasid need ikka veel.

Tegelikult, kui lahendus on kuskil piiril, on veel üks viis skaleerimiseks. Kuna viimane (või esimene), madalaim tase, kuhu serverid ühendatakse — ToR-lülitid või leaf-lülitid, ei pea me neid ühendama ainult ühe kapiga. Seetõttu, kui lahendus jääb kuskil kaks korda alla, võib mõelda suurema radiksiga lüliti kasutamisele alumisel tasemel ja näiteks ühendada kaks-kolm kappi ühe lülitiga. See on samuti variant, millel on oma kulud, kuid see töötab hästi ja võib osutuda heaks lahenduseks, kui on vajalik suurust kahekordistada.

Kokkuvõtteks, ehitame kahe taseme spinaalide topoloogia alusel, kaheksakihilise tehasega.

Mis juhtub füüsikaga? Väga lihtsad arvutused. Kui meil on kaks spinaa, siis on meil kokku kolm vahekäiku ja me ootame, et võrgus on kolm kaablisegmenti: serveritest kuni leaf-switch'ide, spina 1 ja spina 2. Valikud, mida saame kasutada, on twinax, multimood ja üksikrežiim. Siin tuleb arvestada, milline ribalaius on saadaval, kui palju see maksab, millised on füüsilised mõõtmed, milliste vahedega me saame edasi minna ja kuidas me plaanime uuendada.

Hinna osas saame kõik ritta seada. Twinax'id on tunduvalt odavamad kui aktiivne optika, odavamad kui multimood edastajad, kui arvestada lõigu hindadega, ja natuke odavamad kui 100-Gbps port vahetusest. Ja see, tähelepanu, on odavam kui üksikrežiimi optika, kuna kohtades, kus on vajalik üksikrežiim, on andmekeskustes mitmel põhjusel mõttekas kasutada CWDM-d. Parallelne üksikrežiim (PSM) ei ole väga mugav kasutada, tulemuseks on väga suured kiudpakid, ja kui jääda nende tehnoloogiate juurde, tekib umbes selline hinnahierarhia.

Veel üks tähelepanek: kahjuks ei ole 100 4x25 multimood ports hästi kasutatavad. SFP28 ülekandjate konstruktsiooni eripärade tõttu on nende maksumus vaid veidi odavam kui QSFP28 100 Gbit jaoks. Ja see lahendus multimoodile ei toimi eriti hästi.

Veel üks piirang on see, et meie andmekeskused on füüsiliselt suured, kuna arvutikluster on ulatuslik ja serverite hulk on suur. See tähendab, et vähemalt üks vahe tuleb teha sünkroonselt. Taaskord, füüsilise suuruse tõttu ei saa me läbi minna kaht twinax секtsioonit (vaste kaablitega).

Kokkuvõttes, kui optimeerida hinda ja arvestada selle konstruktsiooni geomeetriat, saame ühe vahe, mis kasutab twinaxi, ühe vahe multimoodiga ja ühe vahe sünkroonselt koos CWDM-iga. See arvestab võimalikke uuenduste teid.

Nii näeb välja näiteks see, millised on olnud viimased arengud, kuhu me liigume ja mis on võimalik. On selge, et suundume 50-gigabittiste SerDes'ide suunas nii multimoodilises kui ka ühe kompliidi režiimis. Veelgi enam, kui vaatame, mis on praegu ühe kompliidi transiiverites ja mida oodatakse 400G puhul, siis tihti, isegi kui 50G SerDes'id tulevad elektriliselt, minnakse optikas juba 100 Gbps lane'idesse. Seega on täiesti võimalik, et enne 50G üleminekut toimub üleminek 100-gigabittistele SerDes'idele ja 100 Gbps lane'idele, kuna paljude tootjate lubaduste kohaselt oodatakse nende kättesaadavust üsna varsti. Aeg, mil 50G SerDes'id olid kõige kiiremad, tundub, et ei tule olema väga pikk, kuna 100G SerDes'e hakatakse välja andma juba järgmisel aastal. Ja mõne aja pärast võivad need tõenäoliselt maksma minna mõistlikke summasid.

Veel on nüansse, mida arvesse võtta füüsika valimisel. Teoreetiliselt saame juba praegu rakendada 400- või 200-gigabitisе portsse, kasutades 50G SerDes'i. Kuid tundub, et see pole eriti mõistlik, kuna nagu ma varem rääkisin, soovime me oma lülitites piisavalt suurt radikssi, loomulikult mõistlikkuse piires. Soovime 128. Kui aga meil on kiibi maht piiratud ja me tõstame linki kiirusе, siis radikss loomulikult väheneb, imesid ei juhtu.

Kuid üldist mahtu saame suurendada tasapindade arvu kasvatamisega, ja sellega ei kaasne erilisi kulusid, tasapindade arvu on võimalik kasvatada. Kui aga me kaotame radikssi, peame sisse viima täiendava taseme, seega praeguste arvutuste puhul, praeguse maksimaalselt kättesaadava kiibi mahu juures, selgub, et tõhusam on kasutada 100-gigabitisi porte, kuna need võimaldavad saavutada suuremat radikssi.

Järgmine küsimus on see, kuidas on korraldatud füüsika, kuid juba kaabelinfrastruktuuri vaatenurgast. Selgub, et see on korraldatud üsna lõbusalt. Kabelliidesed leaf-lülitite ja esimese taseme spine'ide vahel — seal pole palju linke, kõik on suhteliselt lihtsalt üles ehitatud. Kuid kui võtame ühe tasandi, siis see, mis toimub seestpoolt — seal tuleb kõik esimese taseme spine'id ühendada kõigi teise taseme spine'idega.

Lisaks on tavaliselt teatud soovid selle kohta, kuidas see andmekeskuses välja peaks nägema. Näiteks soovisime väga, et kaablid oleksid kokku pandud ja juhitud nii, et üks kõrge tihedusega patch panel läheks täielikult ühte patch panelisse, et vältida pikkuste segadust. Me suutsime selle probleemi lahendada. Kui vaadata algselt loogilist topoloogiat, siis on näha, et tasandid on sõltumatud, iga tasand võib ehitada iseseisvalt. Kuid kui me lisame sellise bundling'i ja soovime täielikult patch paneli patch panelisse tõmmata, tuleb meil ühe bundli sees segada erinevaid tasandeid ja luua vahepealne konstruktsioon optiliste ristühenduste kujul, et ümber pakkida need sellest, kuidas nad ühes segmendis kokku pandi, selliseks, kuidas nad teises segmendis kokku pannakse. Tänu sellele saame me meeldiva omaduse: kogu keeruline ühendamine ei ulatu väljapoole rack'e. Kui midagi on väga tugevalt sassis, 'avada tasandeid', nagu mõnikord Clos-võrkudes öeldakse, siis on kõik koondatud ühe rack'i sisse. Meil ei ole tugevalt lahutatud, isegi individuaalsete linkide ulatuses, ühendusi rack'ide vahel.

Nii see välja näeb, kui vaadata kabeliinfrastruktuuri loogilist korraldust. Vasakul pildil tähistavad värvilised plokid esmaklasside spain lüliteid, kokku kaheksa, ning nendest lähtuvad neli köit, mis ristuvad teiste köidudega, mis tulevad spain-2 lülititest.

Väikesed ruudud tähistavad ristumiskohti. Vasakpoolne ülemine osa annab ülevaate iga ristumiskoha kohta, tegelikult on see 512 porti kross-konnekti moodul, mis pakendab kaableid nii, et need jõuavad täielikult ühte rack'i, kus on ainult üks spain-2 tasapind. Paremal on selle pildi detailsem ülevaade, rakendudes mitmele Pods spain-1 tasemel, ja kuidas see kross-konnektis pakitakse, kuidas see jõuab spain-2 tasemele.

Nii see välja näeb. Veel mitte täielikult kokku pandud spain-2 rack (vasakul) ja kross-konnekti rack. Kahjuks pole seal väga palju näha. Kogu konstruktsioon ehitatakse parajasti ühes meie suurtest andmekeskustest, mis laieneb. See on töö käimas, see näeb välja ilusam ja on paremini täidetud.

Oluline küsimus: oleme valinud loogilise topoloogia ja ehitanud füüsilise. Mis juhtub control plane'iga? Praktikast on teada, et on mõningaid ettekandeid, et link state protokollid on head, nendega on meeldiv töötada, kuid kahjuks ei skaleeru nad tihedalt interconnectitud topoloogiate puhul hästi. Ja on üks peamine tegur, mis seda takistab — see, kuidas flooding link state protokollides toimub. Kui võtta lihtsalt flooding algoritm ja vaadata, kuidas meie võrk on üles seatud, siis on selge, et igal sammul on väga suur fanout ja see lihtsalt joonistab control plane'i uuendustega üle. Just sellised topoloogiad koos traditsioonilise flooding algoritmiga link state protokollides segunevad väga kehvasti.

Valiku tegemiseks on kasutada BGP-d. Selle õigeks seadistamiseks on kirjeldatud RFC 7938, mis käsitleb BGP kasutamist suurtes andmekeskustes. Põhijooned on lihtsad: minimaalne eelliste arv hostis ja kogu võrgus, kasutada agregatsiooni, kui see on võimalik, ja vähendada path hunting'i. Soovime väga ettevaatlikku ja väga kontrollitud uuenduste levitamist, mida nimetatakse valley free'iks. Soovime, et uuendused kulgeksid läbi võrgu ainult korra. Kui need originaalsetest allikatest tulevad, siis liiguvad nad ülespoole ja neid levitatakse mitte rohkem kui üks kord. Zigezage ei tohi esineda. Zigezage peavad olema välistatud.

Selleks kasutame üsna lihtsat skeemi, et rakendada BGP põhimõtteid. Me kasutame eBGP-d, mis töötab link local tasemel, ja autonoomsed süsteemid määratakse järgmiselt: autonoomne süsteem ToR-i jaoks, autonoomne süsteem kogu spine-1-lülitite bloki jaoks ühe Pod'i sees ning üldine autonoomne süsteem kogu Top of Fabric'i jaoks. On lihtne vaadata ja veenduda, et isegi normaalne BGP käitumine annab meile soovitud uuenduste leviku.

Muidugi, on vajalik kujundada aadressimine ja aadresside kogumine nii, et see oleks kooskõlas marsruutimise struktuuriga, et tagada control plane'i stabiilsus. L3 aadressimine transpordis on seotud topoloogiaga, kuna ilma selleta ei ole võimalik saavutada kogumist; vastasel juhul satuvad individuaalsed aadressid marsruutimisüsteemi. Veel üks asi on see, et kogumine ei segune kahjuks hästi multi-path'iga, sest kui meil on multi-path ja kogumine, on kõik korras, kui kogu võrk töötab tõrgeteta. Kahjuks, niipea kui võrgus ilmnevad tõrked ja topoloogia sümmeetria kaob, võime jõuda punkti, kust agregaat on teada antud, kust edasi minna ei saa sinna, kuhu meil vaja on. Seetõttu on parim koguda seal, kus ei ole rohkem multi-path'i, meie puhul ToR-lülitites.

Tegelikult on aggregeerimine võimalik, kuid ettevaatlikult. Kui suudame teha kontrollitud deaggregeerimist, kui võrgu talitlushäired tekivad. Kuid see on piisavalt keeruline ülesanne, oleme isegi proovinud hinnata, kas see on võimalik, kas saab paigaldada täiendavat automaatikat ja lõppautomaatide süsteeme, mis suudaksid korralikult BGP-d juhtida, et saavutada soovitud käitumine. Kahjuks on äärealade juhtimine väga ebaselge ja keeruline, ning selle ülesande lahendamine BGP välise varustuse ühendamise kaudu ei toimi hästi.

Selles osas on RIFT protokolli raames tehtud väga huvitavat tööd, millest räägitakse järgmises ettekandes.

Teine oluline aspekt on see, kuidas skaleeruvad andmeväljad tihedate topoloogiate puhul, kus meil on suur hulk alternatiivseid teid. Selleks kasutatakse mitmeid täiendavaid andmestruktuure: ECMP grupid, mis kirjeldavad omakorda järgmise hüppe gruppe.

Tavaliselt toimivas võrgus, kus ei esine häireid ja kui liigelda Clos-topoloogias ülespoole, piisab ainult ühe grupi kasutamisest, sest kõik, mis ei ole lokaalne, on kirjeldatud vaikeväärtusena ning saab liikuda üles. Kui liigelda ülemisest allapoole lõuna suunas, siis kõik teed, mis ei lähe ECMP kaudu, on ühetaktinisid. Kõik on hea. Probleem ja Clos-topoloogia klassikaline eripära on see, et kui vaadata kangi ülaosa, siis igal elemendil on ainus tee igasse elemendi alla. Kui mööda seda teed tekivad tõrked, siis see konkreetne element kangi ülaosas muutub ebakõlblikuks just nende prefixide jaoks, mis asuvad katkenud tee taga. Kuid teiste jaoks on see kehtiv ja me peame lahti võtma ECMP grupid ning sisse viima uue oleku.

Kuidas näeb välja andmeplaneedi skaleeritavus kaasaegsetes seadmetes? Kui me teeme LPM-i (pikima eelprefiksi vaste), siis kõik on üsna hästi, üle 100 000 eelprefiksi. Kui räägime Next Hop grupidest, siis olukord on halvem, 2-4 tuhat. Kui räägime tabelist, mis sisaldab Next Hops'i (või naabruses asuvaid), siis see on kuskil 16 000 kuni 64 000. Ja see võib tekkida probleem. Ja siit jõuame huvitava tähelepanekuni: mis juhtus MPLS-iga andmekeskustes? Põhimõtteliselt soovisime seda rakendada.

Juhtus kaks asja. Me tegime mikrosegmentatsiooni hostides, seega ei olnud meil vaja seda teha võrgus. Erinevate tootjate toe osas polnud olukord eriti hea, rääkimata avatud rakendustest valgete kastide puhul koos MPLS-iga. Ja veel, MPLS, vähemalt selle traditsioonilised rakendused, kahjuks ei sobi üldse ECMP-iga. Ja just selle pärast.

See, kuidas ECMP-suunamise struktuur IP jaoks välja näeb. Palju eelvõtteid võib kasutada sama rühma ja sama Next Hops (või adjacencies, erinevates seadmete dokumentatsioonides võib see erinevalt nimetada). Idee on, et see kirjeldatakse kui väljundport ja kuhu MAC-aadress ümber kirjutada, et jõuda õige Next Hopi juurde. IP jaoks näeb kõik välja lihtne, seda saab kasutada väga suure hulga eelvõtete jaoks ühe ja sama grupi peale, ühe ja sama Next Hops bloki juures.

Klassikaline MPLS-arkitektuur tähendab, et sõltuvalt väljundliidese märgist võib see kirjutada kokku erinevatele väärtustele. Seetõttu peame hoidma iga sisenemärgi jaoks grupi ja Next Hops'i bloki. Kahjuks ei ole see skaleeritav.

Ei ole keeruline näha, et meie konstruktsiooni jaoks vajasime umbes 4000 ToR-lülitit, maksimaalne laius — 64 ECMP rada, kui liikuda spina-1-st spina-2 suunas. Me mahume napilt ühte ECMP-gruppide tabelisse, kui ainult üks eelvõte ToR-i kaudu lahkub, ja ei mahu üldse Next Hops tabelisse.

Kõik pole lootusetu, sest Segment Routingi arhidektuuri puhul kasutatakse globaalset silti. Ahnest võiksime taas kõik need järgnevate hopside plokid kokku panna. Selleks on vajalik selline toiming nagu wildcard: võtta silt ja kirjutada see samale, ilma konkreetse väärtuseta. Kahjuks ei ole see aga kergesti kergesti kätte saadavates teostustes väga olemas.

Ja lõpuks, peame andma andmekeskusele välist liiklust. Kuidas seda teha? Varem toodi liiklus Clos-võrkudesse ülevalt. See tähendab, et olid piiriruuterid, mis olid ühendatud kõigi seadmetega Top of fabric. See lahendus töötab täiesti hästi väikestes ja keskmistes suurustes. Kahjuks, et liiklust sarnasel viisil kogu võrku tuua, tuleb jõuda samal ajal kõigisse Top of fabric'i elementidesse, ja kui neid muutub rohkem kui sada, selgub, et vajame suurt radikaali ka piiriruuterite peal. Üldiselt maksab see raha, sest piiriruuterid on funktsionaalsemad, nende pordid on kallimad, ja see moodustab mitte väga ilusa konstruktsiooni.

Teine variant on liikluse suunamine alt üles. Ei ole raske veenduda, et Clos-topoloogia on üles ehitatud nii, et alt tulev liiklus, st ToR-i poolt, jagatakse tasemete vahel ühtlaselt kogu Top of fabric'is kahe iteratsiooni jooksul, koormates kogu võrku. Seetõttu tutvustame me spetsiaalset tüüpi Pod'i, Edge Pod'i, mis tagavad välise ühenduvuse.

On veel üks võimalus. Näiteks teeb seda Facebook. Nad nimetavad seda Fabric Aggregator või HGRID. Sisse tuuakse lisaspainiserveri tase, et ühenduda mitme andmekeskusega. Selline konstruktsioon on võimalik, kui meil ei ole liitumiskohtades täiendavaid funktsioone või kapseldusmuutusi. Kui need on olemas, siis tegemist on täiendavate puutepunktidega, mis muudavad asja keerulisemaks. Reeglina tekib rohkem funktsioone ja mingi membraan, mis eraldab erinevaid osi andmekeskusest. Sellise membraani suur tegemine ei ole mõistlik, aga kui see on mingil põhjusel väga vajalik, siis on mõistlik kaaluda selle eemaldamist, teha see võimalikult laiekes ja viia hostidesse. Nii teeb näiteks paljud pilveteenuse pakkujad. Neil on overlayd, mis algavad hostidest.

Millised arenguvõimalused meie arvates on? Esiteks - CI/CD torujuhtme toetamise parendamine. Soovime lennata nii, nagu me katsetame, ja testida nii, nagu me lendame. See ei õnnestu just kõige paremini, kuna infrastruktuur on suur ja seda ei saa katsetamiseks dubleerida. Peame välja mõtlema, kuidas testimiselemente tööinfrastruktuuri lisada, ilma et see kokku kukuks.

Parim töötlus, parim monitoorium on enamasti kunagi liig. Küsimus on tasakaalus jõudude ja tulemuste vahel. Kui mõistlike jõududega saab midagi lisada - siis on see suurepärane.

Avaoperatsioonisüsteemid võrguseadmetele. Parimad protokollid ja parimad marsruutimissüsteemid, näiteks RIFT. Samuti on vajalikud uuringud parimate ummikute juhtimise skeemide rakendamise kohta ja võib-olla teatud punktides RDMA toe hõlmamine klastrite vahel.

Kui vaadata kaugemasse tulevikku, on vajalikud arenenud topoloogiad ja võib-olla võrgud, mis kasutavad väiksemat overhead'i. Viimase aja uudistest — hiljuti ilmusid avaldused HPC Cray Slingshot tehase tehnoloogiast, mis põhineb commodity Ethernet'il, kuid pakub võimalust kasutada palju lühemaid pealkirju. Selle tulemusena väheneb overhead.

Kõik tuleb teha nii lihtsaks kui võimalik, kuid mitte lihtsamaks. Komplexsus on skaleeritavuse vaenlane. Lihtsus ja regulaarne struktuur on meie sõbrad. Kui on võimalus kuskil skaalat tõsta — tehke seda. Üldiselt on nüüd suurepärane tegutseda võrgu tehnoloogiate vallas. Toimub palju huvitavat. Aitäh.

Allikas: habr.com