Oleme välja töötanud andmekeskuse võrgukujunduse, mis võimaldab kasutusele võtta arvutusklastreid, mis on suuremad kui 100 tuhat serverit, mille maksimaalne poolitamise ribalaius on üle ühe petabaidi sekundis.
Dmitri Afanasjevi aruandest saate teada uue kujunduse põhiprintsiipidest, skaleerimise topoloogiatest, sellega kaasnevatest probleemidest, nende lahendamise võimalustest, tänapäevaste võrguseadmete marsruutimise ja edastustasandi funktsioonide skaleerimisest "tihedalt ühendatud" topoloogiad suure hulga ECMP marsruutidega. Lisaks rääkis Dima põgusalt välisühenduvuse korraldusest, füüsilisest kihist, kaabeldussüsteemist ja võimalustest võimsust veelgi suurendada.
- Tere pärastlõunat kõigile! Minu nimi on Dmitri Afanasjev, olen Yandexi võrguarhitekt ja projekteerin peamiselt andmekeskuste võrke.
Minu lugu räägib Yandexi andmekeskuste uuendatud võrgust. See on suuresti meie kujunduse edasiarendus, kuid samal ajal on mõned uued elemendid. See on ülevaatlik esitlus, sest väikesesse aega tuli palju infot pakkida. Alustuseks valime loogilise topoloogia. Seejärel antakse ülevaade juhttasandist ja andmetasandi skaleeritavusega seotud probleemidest, tehakse valik, mis füüsilisel tasandil toimuma hakkab ning vaatleme mõningaid seadmete omadusi. Räägime veidi MPLS-iga andmekeskuses toimuvast, millest me mõni aeg tagasi rääkisime.
Niisiis, mis on Yandex koormuste ja teenuste osas? Yandex on tüüpiline hüperskaalaer. Kui vaatame kasutajaid, siis töötleme peamiselt kasutajate taotlusi. Samuti erinevad voogedastusteenused ja andmeedastus, sest meil on ka salvestusteenused. Kui taustaprogrammile lähemal, ilmuvad sinna infrastruktuuri koormused ja teenused, nagu hajutatud objektide salvestusruum, andmete replikatsioon ja loomulikult püsivad järjekorrad. Üks peamisi töökoormuse tüüpe on MapReduce jms süsteemid, vootöötlus, masinõpe jne.
Kuidas on lood infrastruktuuriga, mille peal see kõik toimub? Jällegi, me oleme üsna tüüpiline hüperskaleerija, kuigi oleme võib-olla veidi lähemal spektri väiksemale hüperskaleerijale. Kuid meil on kõik omadused. Võimaluse korral kasutame riistvara ja horisontaalset skaleerimist. Meil on täielik ressursside ühendamine: me ei tööta üksikute masinate, üksikute riiulitega, vaid ühendame need suureks vahetatavateks ressurssideks koos mõne lisateenusega, mis tegelevad planeerimise ja jaotusega ning töötame kogu selle kogumiga.
Seega on meil järgmine tase – operatsioonisüsteem andmetöötlusklastri tasemel. On väga oluline, et me oma kasutatavat tehnoloogiapakki täielikult kontrolliksime. Me juhime lõpp-punkte (hostid), võrku ja tarkvara pinu.
Meil on mitu suurt andmekeskust Venemaal ja välismaal. Neid ühendab MPLS-tehnoloogiat kasutav selgroog. Meie sisemine infrastruktuur on peaaegu täielikult üles ehitatud IPv6-le, kuid kuna peame teenindama välist liiklust, mis tuleb endiselt peamiselt IPv4 kaudu, peame kuidagi edastama IPv4 kaudu saabuvad päringud esiserveritesse ja natuke rohkem suunama välisele IPv4-Internetile. näiteks indekseerimiseks.
Viimased paar andmekeskuste võrgukujunduse iteratsiooni on kasutanud mitmekihilisi Clos-topoloogiaid ja on ainult L3-le. Lahkusime L2-st mõni aeg tagasi ja hingasime kergendatult. Lõpuks sisaldab meie infrastruktuur sadu tuhandeid arvutus- (serveri) eksemplare. Maksimaalne klastri suurus oli mõni aeg tagasi umbes 10 tuhat serverit. See on suuresti tingitud sellest, kuidas need samad klastri tasemel operatsioonisüsteemid, planeerijad, ressursside jaotamine jne toimivad. Kuna taristutarkvara poolel on toimunud edusammud, siis nüüd on eesmärgiks seatud umbes 100 tuhat serverit ühes andmeklastris. Meil on ülesanne – suutma ehitada sellises klastris tõhusat ressursside koondamist võimaldavaid võrgutehaseid.
Mida me andmekeskuste võrgult tahame? Esiteks on palju odavat ja üsna ühtlaselt jaotatud ribalaiust. Sest võrk on selgroog, mille kaudu saame ressursse koondada. Uus sihtsuurus on umbes 100 tuhat serverit ühes klastris.
Loomulikult tahame ka skaleeritavat ja stabiilset juhttasapinda, sest nii suure taristu puhul tekib palju peavalu isegi lihtsalt juhuslikest sündmustest ja me ei taha, et juhttasand ka meile peavalu tooks. Samas tahame selles olekut minimeerida. Mida väiksem on seisund, seda paremini ja stabiilsemalt kõik toimib ning seda lihtsam on diagnoosida.
Loomulikult vajame automatiseerimist, sest sellist taristut on võimatu käsitsi hallata ja see on juba mõnda aega olnud võimatu. Vajame operatiivtuge nii palju kui võimalik ja CI/CD tuge niivõrd, kuivõrd seda on võimalik pakkuda.
Sellise suurusega andmekeskuste ja klastrite puhul on järkjärgulise juurutamise ja laiendamise toetamise ülesanne ilma teenust katkestamata muutunud üsna teravaks. Kui tuhande masina suurustes klastrites, võib-olla ligi kümne tuhande masinaga, saaks need siiski ühe operatsioonina kasutusele võtta - see tähendab, et plaanime infrastruktuuri laiendamist ja ühe toiminguna lisandub mitu tuhat masinat, siis saja tuhande masina suurune klaster kohe niimoodi ei teki, see ehitatakse mingi aja jooksul. Ja on soovitav, et kogu selle aja oleks olemas see, mis on juba välja pumbatud, infrastruktuur, mis on kasutusele võetud.
Ja üks nõue, mis meil oli ja jätsime: mitme üürilepingu tugi, see tähendab virtualiseerimine või võrgu segmenteerimine. Nüüd ei pea me seda võrgukanga tasemel tegema, sest killustamine on läinud hostidele ja see on muutnud skaleerimise meie jaoks väga lihtsaks. Tänu IPv6-le ja suurele aadressiruumile ei pidanud me sisemises infrastruktuuris dubleerivaid aadresse kasutama, kõik aadressid olid juba kordumatud. Ja tänu sellele, et oleme võtnud filtreerimise ja võrgu segmenteerimise hostidesse, ei pea me andmekeskuste võrkudes mingeid virtuaalseid võrguolemeid looma.
Väga oluline on see, mida me ei vaja. Kui mõne funktsiooni saab võrgust eemaldada, muudab see elu palju lihtsamaks ning reeglina laiendab saadaolevate seadmete ja tarkvara valikut, muutes diagnostika väga lihtsaks.
Niisiis, mis on see, mida me ei vaja, millest oleme saanud loobuda, mitte alati rõõmuga, kui see juhtus, vaid suure kergendusega, kui protsess on lõppenud?
Esiteks L2-st loobumine. Me ei vaja L2-d, ei päris ega emuleeritud. Kasutamata suuresti seetõttu, et kontrollime rakenduste pinu. Meie rakendused on horisontaalselt skaleeritavad, töötavad L3 adresseerimisega, nad ei muretse väga, et mõni üksik eksemplar on välja läinud, nad lihtsalt rulluvad välja uue, seda pole vaja vanal aadressil välja rullida, sest seal on klastris paiknevate masinate eraldi teenuse avastamise ja jälgimise tase. Me ei delegeeri seda ülesannet võrgule. Võrgu ülesanne on toimetada paketid punktist A punkti B.
Meil ei ole ka olukordi, kus aadressid liiguvad võrgu sees ja seda tuleb jälgida. Paljude kujunduste puhul on see tavaliselt vajalik VM-i mobiilsuse toetamiseks. Me ei kasuta virtuaalmasinate mobiilsust suure Yandexi sisemises infrastruktuuris ja pealegi usume, et isegi kui seda tehakse, ei tohiks see võrgutoega juhtuda. Kui seda on tõesti vaja teha, tuleb seda teha hosti tasemel ja edastada aadressid, mis võivad ülekateteks migreeruda, et mitte puudutada või teha liiga palju dünaamilisi muudatusi aluskatte enda marsruutimissüsteemis (transpordivõrk). .
Teine tehnoloogia, mida me ei kasuta, on multisaade. Kui soovite, võin teile üksikasjalikult öelda, miks. See teeb elu palju lihtsamaks, sest kui keegi on sellega tegelenud ja vaadanud täpselt, kuidas multisaate juhtimistasand kõigis peale kõige lihtsamate paigalduste välja näeb, on see suur peavalu. Ja veelgi enam, näiteks hästi toimivat avatud lähtekoodiga teostust on raske leida.
Lõpuks kujundame oma võrgud nii, et need ei muutuks liiga palju. Võime loota, et väliste sündmuste voog marsruutimissüsteemis on väike.
Millised probleemid tekivad ja milliste piirangutega tuleb andmekeskuste võrgu arendamisel arvestada? Kulud muidugi. Skaleeritavus, tase, milleni tahame kasvada. Vajadus laieneda ilma teenust peatamata. Ribalaius, saadavus. Nähtavus võrgus toimuvast seiresüsteemidele, operatiivmeeskondadele. Automatiseerimise tugi - jällegi nii palju kui võimalik, kuna erinevaid ülesandeid saab lahendada erinevatel tasanditel, sealhulgas lisada täiendavaid kihte. Noh, ei sõltu [võimalik] müüjatest. Kuigi erinevatel ajalooperioodidel, olenevalt sellest, millist lõiku vaadata, oli seda iseseisvust lihtsam või raskem saavutada. Kui võtta läbilõige võrguseadmete kiipidest, siis kuni viimase ajani oli väga tinglik rääkida sõltumatust müüjatest, kui tahtsime ka suure läbilaskevõimega kiipe.
Millist loogilist topoloogiat kasutame oma võrgu ehitamiseks? Sellest saab mitmetasandiline Clos. Tegelikult reaalseid alternatiive praegu ei ole. Ja Clos-topoloogia on üsna hea, isegi kui võrrelda erinevate arenenud topoloogiatega, mis on praegu rohkem akadeemilise huvi valdkonnas, kui meil on suured radix-lülitid.
Kuidas on mitmetasandiline Clos-võrk umbkaudu üles ehitatud ja kuidas selle erinevaid elemente nimetatakse? Esiteks tõusis tuul, et orienteeruda, kus on põhja, kus on lõuna, kus on ida, kus on lääs. Seda tüüpi võrke ehitavad tavaliselt need, kellel on väga suur lääne-ida liiklus. Ülejäänud elementide osas on ülaosas virtuaalne lüliti, mis on kokku pandud väiksematest lülititest. See on Clos-võrkude rekursiivse ehitamise peamine idee. Võtame mingisuguse radiksiga elemendid ja ühendame need omavahel nii, et seda, mida saame, võib pidada suurema radiksiga lülitiks. Kui vajate veelgi rohkem, võib protseduuri korrata.
Juhtudel, näiteks kahetasandilise Clos-i puhul, kui on võimalik selgelt tuvastada minu diagrammil vertikaalsed komponendid, nimetatakse neid tavaliselt tasapindadeks. Kui me ehitaksime Closi kolmetasandiliste selgroolülititega (mis kõik ei ole piiri- ega ToR-lülitid ja mida kasutatakse ainult transiidiks), näeksid lennukid välja keerukamad, kahetasandilised näevad välja täpselt sellised. ToR- või lehelülitite plokki ja nendega seotud esimese taseme selgroolülitiid nimetame Pod. Podi ülaosas asuvad selgroo-1 taseme selgroolülitid on Podi ülaosa, Podi ülaosa. Lülitid, mis asuvad kogu tehase ülaosas, on tehase pealmine kiht, Top of kangas.
Muidugi tekib küsimus: Clos võrke on ehitatud juba mõnda aega, idee ise on üldiselt pärit klassikalise telefoniside, TDM võrkude ajast. Äkki on midagi paremat ilmunud, äkki saab midagi paremini teha? Jah ja ei. Teoreetiliselt jah, praktikas lähiajal kindlasti mitte. Kuna on mitmeid huvitavaid topoloogiaid, siis mõnda neist kasutatakse isegi tootmises, näiteks kasutatakse Dragonflyt HPC rakendustes; Samuti on huvitavaid topoloogiaid nagu Xpander, FatClique, Jellyfish. Kui vaadata hiljuti aruandeid konverentsidel nagu SIGCOMM või NSDI, võib leida üsna palju töid alternatiivsetest topoloogiatest, millel on paremad omadused (ühed või teised) kui Clos.
Kuid kõigil neil topoloogiatel on üks huvitav omadus. See takistab nende rakendamist andmekeskuste võrkudes, mida proovime ehitada kaubariistvarale ja mis maksavad üsna mõistlikku raha. Kõigis neis alternatiivsetes topoloogiates pole enamikule ribalaiusest kahjuks ligi pääseda lühimaid teid pidi. Seetõttu kaotame kohe võimaluse kasutada traditsioonilist juhtimistasandit.
Teoreetiliselt on probleemi lahendus teada. Need on näiteks lingi oleku modifikatsioonid k-lühima tee abil, kuid jällegi pole selliseid protokolle, mis oleksid tootmises juurutatud ja seadmetes laialdaselt kättesaadavad.
Veelgi enam, kuna enamikule võimsusest ei pääse ligi kõige lühemate teede kaudu, peame kõigi nende teede valimiseks muutma enamat kui lihtsalt juhttasandit (ja muide, see on juhttasandil oluliselt suurem olek). Peame endiselt muutma suunamistasandit ja reeglina on vaja vähemalt kahte lisafunktsiooni. See on võimalus teha kõik otsused pakettide edastamise kohta ühekordselt, näiteks hostis. Tegelikult on see lähtemarsruutimine, mõnikord nimetatakse seda sidumisvõrke käsitlevas kirjanduses kõikehõlmavateks edastamisotsusteks. Ja adaptiivne marsruutimine on funktsioon, mida vajame võrguelementidel ja mis taandub näiteks sellele, et valime järgmise hüppe järjekorra vähima koormuse teabe põhjal. Näiteks on võimalikud muud võimalused.
Seega on suund huvitav, kuid paraku ei saa me seda praegu rakendada.
Olgu, otsustasime Closi loogilise topoloogiaga. Kuidas me seda skaleerime? Vaatame, kuidas see töötab ja mida saab teha.
Clos-võrgus on kaks peamist parameetrit, mida saame kuidagi varieerida ja teatud tulemusi saada: elementide radiks ja tasandite arv võrgus. Mul on skemaatiline diagramm selle kohta, kuidas mõlemad suurust mõjutavad. Ideaalis kombineerime mõlemad.
On näha, et Clos võrgu lõplik laius on lõunaradixi kõigi lülide lülide tasemete korrutis, mitu linki meil on allapoole, kuidas see hargneb. Nii suurendame võrgu suurust.
Seoses võimsusega, eriti ToR-lülitite puhul, on kaks skaleerimisvalikut. Kas saame üldist topoloogiat säilitades kasutada kiiremaid linke või lisada rohkem tasapindu.
Kui vaatate Closi võrgu laiendatud versiooni (alumises paremas nurgas) ja naasete selle pildi juurde koos allpool oleva Closi võrguga...
... siis see on täpselt sama topoloogia, aga sellel slaidil on see kompaktsemalt kokku lükatud ja tehase tasapinnad asetsevad üksteise peale. See on sama.
Kuidas näeb Clos-võrgu skaleerimine numbrites välja? Siin annan andmed selle kohta, millise võrgu maksimaalse laiuse võib saada, kui palju racke, ToR-lüliteid või lehtlüliteid, kui neid pole riiulites, saame sõltuvalt sellest, millist lülitite radiksit kasutame selgroolülide jaoks ja mitut taset me kasutame.
Siin on, mitu riiulit meil võib olla, kui palju servereid ja kui palju see kõik umbes 20 kW riiuli kohta tarbida võib. Veidi varem mainisin, et sihime klastri suuruseks umbes 100 tuhat serverit.
On näha, et kogu selle disaini puhul pakuvad huvi kaks ja pool võimalust. Valikus on kahe kihiga spinn ja 64-pordilised lülitid, mis jääb veidi alla. Siis on täiesti sobivad valikud 128-pordiliste (radix 128-ga) kahetasandiliste selgroolülitite jaoks või kolmetasandiliste radix 32-ga lülitite jaoks. Ja kõigil juhtudel, kus on rohkem radikse ja rohkem kihte, saab teha väga suure võrgu, aga kui vaadata eeldatavat tarbimist, siis tüüpiliselt on seal gigavatte. Kaablit on võimalik vedada, aga nii palju elektrit ühes kohas me tõenäoliselt ei saa. Kui vaadata andmekeskuste statistikat ja avalikke andmeid, siis võib väga vähe leida andmekeskusi, mille hinnanguline võimsus on üle 150 MW. Suuremad on tavaliselt andmekeskuste ülikoolilinnakud, mitu suurt andmekeskust, mis asuvad üksteisele üsna lähedal.
On veel üks oluline parameeter. Kui vaatate vasakpoolset veergu, on seal loetletud kasutatav ribalaius. On hästi näha, et Clos võrgus kulub märkimisväärne osa pordidest kommutaatorite omavaheliseks ühendamiseks. Kasutatav ribalaius, kasulik riba, on midagi, mida saab anda väljapoole, serverite poole. Loomulikult räägin ma tingimusportidest ja konkreetselt bändist. Reeglina on võrgusisesed lingid kiiremad kui lingid serverite poole, kuid ribalaiuse ühiku kohta, nii palju kui suudame seda oma serveriseadmetele välja saata, on võrgus endas siiski ribalaiust. Ja mida rohkem taset teeme, seda suuremad on erikulud selle riba väljastpoolt varustamiseks.
Veelgi enam, isegi see lisabänd pole täpselt sama. Kuigi vahekaugused on lühikesed, saame kasutada midagi sellist nagu DAC (direct attach vask, see tähendab twinax kaablid) või multimode optika, mis maksavad isegi enam-vähem mõistlikku raha. Niipea, kui liigume pikematele vahemikele - reeglina on see üherežiimiline optika ja selle täiendava ribalaiuse maksumus suureneb märgatavalt.
Ja jälle, naastes eelmise slaidi juurde, kui loome Clos-võrgu ilma ületellimuseta, on lihtne vaadata diagrammi, vaadata, kuidas võrk on üles ehitatud - lisades iga selgroolüliti taseme, kordame kogu riba, mis oli põhja. Pluss tase - pluss sama riba, sama palju porte lülititel, mis oli eelmisel tasemel, ja sama palju transiivereid. Seetõttu on väga soovitav minimeerida selgroolülitite tasemete arvu.
Selle pildi põhjal on selge, et me tõesti tahame ehitada midagi sellist nagu lülitid radiksiga 128.
Siin on põhimõtteliselt kõik sama, mis ma just ütlesin; see on slaid, mida hiljem kaaluda.
Milliseid valikuid saame sellisteks lülititeks valida? Meie jaoks on väga meeldiv uudis, et nüüd saab lõpuks selliseid võrke ehitada ühe kiibi lülititele. Ja see on väga lahe, neil on palju toredaid funktsioone. Näiteks pole neil peaaegu mingit sisemist struktuuri. See tähendab, et need purunevad kergemini. Need lähevad igat moodi katki, aga õnneks purunevad täielikult. Moodulseadmetes on suur hulk vigu (väga ebameeldiv), kui naabrite ja juhttasandi seisukohast tundub, et see töötab, kuid näiteks on osa kangast kadunud ja see ei tööta täisvõimsusel. Ja liiklus sinna on tasakaalustatud selle põhjal, et see on täielikult töökorras ja me võime saada ülekoormatud.
Või näiteks tekivad probleemid tagaplaadiga, sest moodulseadme sees on ka kiired SerDed - see on tõesti keeruline sees. Edastuselementide vahelised märgid on sünkroonitud või mitte. Üldiselt sisaldab iga suurest hulgast elementidest koosnev tootlik modulaarne seade enda sees reeglina sama Clos-võrku, kuid seda on väga raske diagnoosida. Sageli on isegi müüjal endal raske diagnoosida.
Ja sellel on suur hulk rikkestsenaariume, mille korral seade laguneb, kuid ei lange topoloogiast täielikult välja. Kuna meie võrk on suur, kasutatakse aktiivselt tasakaalustamist identsete elementide vahel, võrk on väga regulaarne, st üks tee, millel kõik on korras, ei erine teisest teest, on kasulikum lihtsalt kaotada osa seadmed topoloogiast, kui sattuda olukorda, kus osa neist näib töötavat, aga osa mitte.
Ühe kiibiga seadmete järgmine kena omadus on see, et need arenevad paremini ja kiiremini. Samuti on neil tavaliselt parem suutlikkus. Kui võtta suured kokkupandud konstruktsioonid, mis meil on ringi peal, siis on ühe rack-üksuse võimsus sama kiirusega portide puhul peaaegu kaks korda suurem kui moodulseadmetel. Ühe kiibi ümber ehitatud seadmed on märgatavalt odavamad kui modulaarsed ja tarbivad vähem energiat.
Kuid loomulikult on see kõik põhjusega, on ka puudusi. Esiteks on radix peaaegu alati väiksem kui moodulseadmetel. Kui saame 128 pordiga ühe kiibi ümber ehitatud seadme, siis mitmesaja pordiga modulaarse saame nüüd probleemideta.
See on märgatavalt väiksem edastamistabelite suurus ja reeglina kõik andmetasandi skaleeritavusega seonduv. Madalad puhvrid. Ja reeglina üsna piiratud funktsionaalsus. Kuid selgub, et kui teate neid piiranguid ja hoolitsete õigeaegselt, et neist mööda hiilida või nendega lihtsalt arvestada, siis pole see nii hirmutav. Asjaolu, et radix on väiksem, pole hiljuti lõpuks ilmunud 128-ga seadmete puhul enam probleem, saame ehitada kahte kihti ogasid. Kuid ikkagi on võimatu ehitada midagi väiksemat kui kaks, mis oleks meie jaoks huvitav. Ühe tasemega saadakse väga väikesed klastrid. Isegi meie varasemad kujundused ja nõuded ületasid neid ikkagi.
Tegelikult on nii, et kui äkki on lahendus kuskil äärel, on ikkagi võimalus skaleerida. Kuna viimane (või esimene) madalaim tase, kus serverid on ühendatud, on ToR-lülitid või lehtlülitid, ei pea me nendega ühte riiulit ühendama. Seega, kui lahendus jääb umbes poole võrra alla, võib mõelda lihtsalt suure radiksiga lüliti kasutamisele madalamal tasemel ja näiteks kahe või kolme riiuli ühendamisele ühte lülitisse. See on ka võimalus, sellel on oma kulud, kuid see töötab üsna hästi ja võib olla hea lahendus, kui peate saavutama umbes kaks korda suurema suuruse.
Kokkuvõtteks tugineme topoloogiale, millel on kaks taset ja kaheksa tehasekihti.
Mis saab füüsikast? Väga lihtsad arvutused. Kui meil on kaks taset lülitid, siis on meil ainult kolm taset lülitid ja eeldame, et võrgus on kolm kaablisegmenti: serveritest lehtlülititeni, spine 1, spine 2. Valikud, mida saame kasutamine on - need on twinax, multimode, single mode. Ja siin peame arvestama, milline riba on saadaval, kui palju see maksab, millised on füüsilised mõõtmed, milliseid vahemikke saame katta ja kuidas uuendame.
Kulude poolest saab kõik ritta panna. Twinaxid on oluliselt soodsamad kui aktiivoptika, odavamad kui multimode transiiverid, kui võtta otsast peale lendu, siis mõnevõrra odavam kui 100-gigabitine switchi port. Ja pange tähele, see maksab vähem kui üherežiimiline optika, sest lendudel, kus on vaja üherežiimilist režiimi, on andmekeskustes mitmel põhjusel otstarbekas kasutada CWDM-i, samas kui paralleelse üherežiimiga (PSM) pole eriti mugav töötada. koos, saadakse väga suured pakendid kiud ja kui me keskendume nendele tehnoloogiatele, saame ligikaudu järgmise hinnahierarhia.
Veel üks märkus: kahjuks ei ole väga võimalik kasutada lahtivõetud 100–4x25 mitmerežiimilisi porte. SFP28 transiiverite disainiomaduste tõttu pole see palju odavam kui 28 Gbit QSFP100. Ja see multirežiimi lahtivõtmine ei tööta eriti hästi.
Teine piirang on see, et arvutusklastrite suuruse ja serverite arvu tõttu osutuvad meie andmekeskused füüsiliselt suureks. See tähendab, et vähemalt üks lend tuleb sooritada singlemodiga. Jällegi, Podide füüsilise suuruse tõttu ei ole võimalik juhtida kahte twinaxi (vaskkaablit).
Selle tulemusel, kui optimeerime hinna järgi ja võtame arvesse selle konstruktsiooni geomeetriat, saame CWDM-i kasutades ühe vahemiku twinaxi, ühe mitmerežiimilise ja ühe üherežiimilise ulatuse. See võtab arvesse võimalikke uuendusteid.
Selline näeb välja viimasel ajal, kuhu liigume ja mis on võimalik. Vähemalt on selge, kuidas liikuda 50-gigabitise SerDe poole nii mitme- kui ka üherežiimilise režiimi jaoks. Veelgi enam, kui vaadata, mis on ühemoodilistes transiiverites praegu ja tulevikus 400G jaoks, siis sageli isegi siis, kui elektri poolelt saabuvad 50G SerDe-d, võib 100 Gbps rea kohta juba optikale minna. Seetõttu on täiesti võimalik, et 50-le kolimise asemel läheb üleminek 100 Gigabit SerDele ja 100 Gbps sõiduraja kohta, sest paljude müüjate lubaduste kohaselt on nende saadavust oodata üsna pea. Tundub, et periood, mil 50G SerDes olid kiireimad, ei saa olema väga pikk, sest 100G SerDede esimesed eksemplarid jõuavad turule peaaegu järgmisel aastal. Ja mõne aja pärast on need tõenäoliselt väärt raha.
Üks nüanss veel füüsika valiku kohta. Põhimõtteliselt saame 400G SerDesid kasutades kasutada juba 200 või 50 Gigabiti porti. Kuid selgub, et sellel pole erilist mõtet, sest nagu ma varem ütlesin, tahame lülititele üsna suurt radiksit, muidugi mõistlikkuse piires. Tahame 128. Ja kui meil on kiibi maht piiratud ja lingi kiirust tõstame, siis radix loomulikult väheneb, imet pole.
Ja koguvõimsust saame suurendada lennukite abil ning erikulusid pole, saame lennukite arvu lisada. Ja kui me radixi kaotame, peame kehtestama täiendava taseme, nii et praeguses olukorras, praeguse maksimaalse saadaoleva kiibi võimsuse juures, selgub, et tõhusam on kasutada 100-gigabitisi porte, sest need võimaldavad teil suurema radiksi saamiseks.
Järgmine küsimus on, kuidas on füüsika korraldatud, aga kaablitaristu seisukohalt. Selgub, et see on korraldatud üsna naljakalt. Lehtlülitite ja esmatasandi spinade vaheline kaabeldus - seal pole palju linke, kõik on suhteliselt lihtsalt üles ehitatud. Aga kui me võtame ühe tasapinna, siis sees juhtub see, et peame ühendama kõik esimese tasandi ogad kõigi teise tasandi ogadega.
Lisaks on reeglina mõned soovid, kuidas see andmekeskuse sees välja peaks nägema. Näiteks tahtsime väga ühendada kaablid kimpu ja tõmmata need nii, et üks suure tihedusega plaastri paneel läks tervenisti ühte patch-paneeli, nii et pikkuste poolest pole loomaaeda. Meil õnnestus see probleem lahendada. Kui esialgu vaadata loogilist topoloogiat, siis on näha, et tasapinnad on sõltumatud, iga tasapinda saab ise ehitada. Kuid kui lisame sellise komplekti ja tahame lohistada kogu plaastri paneeli paigapaneeliks, peame segama ühe kimbu sees erinevaid tasapindasid ja juurutama vahestruktuuri optiliste ristühenduste kujul, et need uuesti kokku pakkida. ühel segmendil , kuidas neid teises segmendis kogutakse. Tänu sellele saame kena funktsiooni: kogu keerukas ümberlülitamine ei ulatu riiulitest kaugemale. Kui teil on vaja midagi väga tugevalt põimida, "tasandid lahti voltida", nagu seda mõnikord Closi võrkudes nimetatakse, on see kõik koondunud ühte riiulisse. Meil ei ole riiulite vahel vahetamist väga lahti võetud, kuni üksikute linkideni välja.
Nii näeb see välja kaablitaristu loogilise korralduse seisukohalt. Vasakpoolsel pildil on mitmevärvilistel plokkidel kujutatud esimese taseme spine-lülitite plokid, millest igaüks on kaheksa tükki, ja neli nendest tulevat kaablikimpu, mis lähevad ja ristuvad spine-2 lülitite plokkidest tulevate kimpudega. .
Väikesed ruudud tähistavad ristmikke. Vasakpoolses ülanurgas on iga sellise ristmiku jaotus, see on tegelikult 512 x 512 pordi ristühendusmoodul, mis pakib kaablid ümber nii, et need jõuaksid täielikult ühte riiulisse, kus on ainult üks spine-2 tasapind. Ja paremal on selle pildi skaneerimine veidi üksikasjalikum seoses mitme selgroo-1 tasemel asuva Podiga ja kuidas see on pakendatud ristühendusse, kuidas see jõuab selgroo-2 tasemele.
See näeb välja selline. Veel täielikult kokku panemata spine-2 alus (vasakul) ja ristühendusalus. Kahjuks pole seal palju vaadata. Kogu seda struktuuri juurutatakse praegu ühes meie suures andmekeskuses, mida laiendatakse. See on pooleli, see näeb kenam välja, see on paremini täidetud.
Oluline küsimus: valisime loogilise topoloogia ja ehitasime füüsika. Mis saab juhttasandist? Töökogemusest on üsna hästi teada, on mitmeid teateid, et lingiolekuprotokollid on head, nendega on rõõm töötada, kuid paraku ei skaleeru need tihedalt ühendatud topoloogias hästi. Ja on üks peamine tegur, mis seda takistab – nii toimib üleujutus lingi oleku protokollides. Kui võtate lihtsalt üleujutusalgoritmi ja vaatate, kuidas meie võrk on üles ehitatud, näete, et igal sammul tekib väga suur fanout ja see ujutab juhttasandi lihtsalt uuendustega üle. Täpsemalt, sellised topoloogiad segunevad väga halvasti traditsioonilise üleujutusalgoritmiga lingi oleku protokollides.
Valik on kasutada BGP-d. Kuidas seda õigesti ette valmistada, on kirjeldatud standardis RFC 7938 BGP kasutamise kohta suurtes andmekeskustes. Põhiideed on lihtsad: minimaalne eesliidete arv hosti kohta ja üldiselt minimaalne eesliidete arv võrgus, võimalusel kasutage liitmist ja keelake tee otsimine. Soovime väga hoolikat ja kontrollitud värskenduste levitamist, mida nimetatakse oruvabaks. Soovime, et värskendused juurutaks täpselt üks kord, kui need läbivad võrku. Kui need pärinevad põhjast, tõusevad nad üles, avanedes mitte rohkem kui üks kord. Siksakke ei tohiks olla. Siksakid on väga halvad.
Selleks kasutame kujundust, mis on piisavalt lihtne, et kasutada aluseks olevaid BGP-mehhanisme. See tähendab, et me kasutame eBGP-d, mis töötab kohalikul lingil ja autonoomsed süsteemid on määratud järgmiselt: autonoomne süsteem ToR-is, autonoomne süsteem ühe Podi spine-1 lülitite kogu plokil ja üldine autonoomne süsteem kogu ülaosas. kangast. Pole raske vaadata ja näha, et isegi BGP tavaline käitumine annab meile soovitud värskenduste levitamise.
Loomulikult tuleb adresseerimine ja aadresside koondamine kavandada nii, et see ühilduks marsruutimise ülesehitusega, nii et see tagaks juhttasandi stabiilsuse. L3 aadressimine transpordis on seotud topoloogiaga, sest ilma selleta pole agregeerimist võimalik saavutada, ilma selleta hiilivad üksikud aadressid marsruutimissüsteemi. Ja veel üks asi on see, et liitmine kahjuks väga hästi ei segune mitme teega, sest kui meil on multi-tee ja meil on liitmine, siis on kõik hästi, kui kogu võrk on terve, pole selles tõrkeid. Kahjuks niipea, kui võrgus ilmnevad tõrked ja topoloogia sümmeetria kaob, võime jõuda punktini, kust üksus kuulutati välja, kust me ei saa enam minna sinna, kuhu vaja. Seetõttu on kõige parem liita seal, kus enam mitut teed pole, meie puhul on need ToR-lülitid.
Tegelikult on võimalik liita, kuid hoolikalt. Kui suudame võrgutõrgete ilmnemisel teha kontrollitud jaotamist. Kuid see on üsna keeruline ülesanne, mõtlesime isegi, kas seda oleks võimalik teha, kas on võimalik lisada täiendavat automatiseerimist ja lõplikke olekumasinaid, mis soovitud käitumise saavutamiseks BGP-d õigesti lööksid. Kahjuks on nurgakorpuste töötlemine väga ebaselge ja keeruline ning seda ülesannet ei lahenda BGP-le väliste manuste kinnitamine.
Väga huvitavat tööd on selles osas tehtud RIFT protokolli raames, millest tuleb juttu järgmises aruandes.
Teine oluline asi on see, kuidas andmetasandid skaleeruvad tihedates topoloogiates, kus meil on palju alternatiivseid teid. Sel juhul kasutatakse mitmeid täiendavaid andmestruktuure: ECMP grupid, mis omakorda kirjeldavad Next Hop gruppe.
Normaalselt töötavas võrgus, ilma tõrgeteta, kui me läheme Clos topoloogias üles, piisab ainult ühe grupi kasutamisest, sest kõik, mis pole lokaalne, on vaikimisi kirjeldatud, saame tõusta. Kui me läheme ülalt alla lõunasse, siis kõik teed ei ole ECMP, need on ühe tee teed. Kõik on korras. Probleem on selles, et klassikalise Clos topoloogia eripära on see, et kui me vaatame kanga ülaosa, siis ükskõik millise elemendi juurde, on ainult üks tee mis tahes allpool oleva elemendini. Kui sellel teel tekivad tõrked, muutub see konkreetne tehase ülaosas olev element kehtetuks just nende eesliidete puhul, mis asuvad katkenud tee taga. Kuid ülejäänud osas see kehtib ja me peame ECMP rühmad sõeluma ja uue oleku kasutusele võtma.
Kuidas näeb välja andmetasandi skaleeritavus kaasaegsetes seadmetes? Kui teeme LPM-i (longest prefix match), on kõik päris hästi, üle 100k eesliite. Kui me räägime Next Hop gruppidest, siis kõik on hullem, 2-4 tuhat. Kui me räägime tabelist, mis sisaldab Next Hopsi (või külgnemiste) kirjeldust, siis see on kuskil 16k kuni 64k. Ja sellest võib saada probleem. Ja siit jõuame huvitava kõrvalepõikeni: mis juhtus MPLS-iga andmekeskustes? Põhimõtteliselt tahtsime seda teha.
Juhtus kaks asja. Tegime hostides mikrosegmenteerimise; meil polnud enam vaja seda võrgus teha. See ei olnud eriti hea erinevate tarnijate toega ja veelgi enam MPLS-iga valgetel kastidel avatud rakendustega. Ja MPLS, vähemalt selle traditsioonilised teostused, ühendab kahjuks väga halvasti ECMP-ga. Ja sellepärast.
Selline näeb välja IP ECMP edastamise struktuur. Suur hulk eesliiteid võib kasutada sama rühma ja sama Next Hops plokki (või kõrvutisi, seda võib erinevate seadmete dokumentatsioonis nimetada erinevalt). Asi on selles, et seda kirjeldatakse kui väljaminevat porti ja seda, kuhu MAC-aadress ümber kirjutada, et õigesse Next Hopi jõuda. IP puhul tundub kõik lihtne, sama rühma jaoks saab kasutada väga palju eesliiteid, sama Next Hops plokki.
Klassikaline MPLS-arhitektuur tähendab, et olenevalt väljuvast liidesest saab sildi ümber kirjutada erinevatele väärtustele. Seetõttu peame iga sisendsildi jaoks säilitama rühma ja Next Hops ploki. Ja see paraku ei ulatu.
On lihtne näha, et meie disainis vajasime umbes 4000 ToR-lülitit, maksimaalne laius oli 64 ECMP rada, kui liikuda selgroo-1-st spine-2 suunas. Vaevalt jõuame ühte ECMP rühmade tabelisse, kui ainult üks ToR-iga eesliide kaob, ja me ei pääse üldse tabelisse Next Hops.
Kõik pole lootusetu, sest sellised arhitektuurid nagu Segment Routing hõlmavad globaalseid silte. Formaalselt oleks võimalik kõik need Next Hopsi plokid uuesti kokku tõmmata. Selleks on vaja metsikkaardi tüüpi toimingut: võtke silt ja kirjutage see ilma konkreetse väärtuseta samaks. Kuid kahjuks pole seda saadaolevates rakendustes kuigi palju.
Ja lõpuks peame tooma andmekeskusesse välise liikluse. Kuidas seda teha? Varem toodi liiklus Closi võrku ülevalt. See tähendab, et seal olid servaruuterid, mis ühendasid kõigi kanga ülaosas olevate seadmetega. See lahendus töötab üsna hästi väikeste ja keskmiste suurustega. Kahjuks selleks, et liiklust sellisel viisil sümmeetriliselt kogu võrku saata, peame jõudma üheaegselt kõigi kanga Top of elementide juurde ja kui neid on üle saja, siis selgub, et vajame ka suurt radix äärel ruuterid. Üldiselt maksab see raha, sest servaruuterid on funktsionaalsemad, nende pordid on kallimad ja disain pole eriti ilus.
Teine võimalus on alustada sellist liiklust altpoolt. Lihtne on kontrollida, kas Clos topoloogia on üles ehitatud nii, et altpoolt ehk ToR-i poolelt tulev liiklus jaotub ühtlaselt tasandite vahel kogu Top of kangas kahes iteratsioonis, koormates kogu võrku. Seetõttu tutvustame spetsiaalset Podi tüüpi Edge Pod, mis pakub välist ühenduvust.
Üks variant on veel. Seda teeb näiteks Facebook. Nad kutsuvad seda Fabric Aggregatoriks või HGRIDiks. Mitme andmekeskuse ühendamiseks võetakse kasutusele täiendav selgroog. See disain on võimalik, kui meil pole liidestes lisafunktsioone ega kapseldamise muudatusi. Kui need on täiendavad puutepunktid, on see keeruline. Tavaliselt on andmekeskuse erinevaid osi eraldavaid funktsioone rohkem ja omamoodi membraan. Sellist membraani pole mõtet suureks teha, aga kui seda tõesti mingil põhjusel vaja läheb, siis on mõttekas kaaluda võimalust see ära võtta, võimalikult laiaks teha ja hostidele üle kanda. Seda teevad näiteks paljud pilveoperaatorid. Neil on ülekatted, nad algavad hostidest.
Milliseid arenguvõimalusi me näeme? Esiteks CI/CD torujuhtme toe parandamine. Me tahame lennata nii, nagu me katsetame, ja katsetada, kuidas me lendame. See ei õnnestu kuigi hästi, sest infrastruktuur on suur ja seda pole võimalik katseteks dubleerida. Peate mõistma, kuidas testimise elemente tootmisinfrastruktuuri sisse viia, ilma et seda maha kukuks.
Parem aparatuur ja parem järelevalve pole peaaegu kunagi üleliigsed. Kogu küsimus on jõupingutuste ja tulude tasakaal. Kui saate selle mõistliku pingutusega lisada, on väga hea.
Avatud operatsioonisüsteemid võrguseadmetele. Paremad protokollid ja paremad marsruutimissüsteemid, näiteks RIFT. Samuti on vaja uurida paremate ummikute kontrolli skeemide kasutamist ja võib-olla vähemalt mõnes punktis RDMA toe kasutuselevõttu klastris.
Vaadates kaugemale tulevikku, vajame täiustatud topoloogiaid ja võib-olla ka võrke, mis kasutavad vähem üldkulusid. Värsketest asjadest on viimasel ajal ilmunud väljaandeid HPC Cray Slingshoti kangatehnoloogia kohta, mis põhineb tarbe-Ethernetil, kuid võimalusega kasutada palju lühemaid päiseid. Selle tulemusena vähenevad üldkulud.
Kõik peaks olema võimalikult lihtne, kuid mitte lihtsam. Keerukus on mastaapsuse vaenlane. Lihtsus ja korrapärased struktuurid on meie sõbrad. Kui saate kuskilt skaleerida, tehke seda. Ja üldiselt on tore olla nüüd võrgutehnoloogiatega seotud. Toimub palju huvitavat. Aitäh.
Allikas: www.habr.com