Við höfum þróað nethönnun gagnavera sem gerir kleift að dreifa tölvuþyrpingum stærri en 100 þúsund netþjóna með hámarks bandbreidd tvískipta yfir eitt petabæt á sekúndu.
Frá skýrslu Dmitry Afanasyev munt þú læra um grundvallarreglur nýju hönnunarinnar, stærðarstærðfræði, vandamálin sem koma upp við þetta, möguleika til að leysa þau, eiginleika leiðar og skala framsendingarflugvélaraðgerðir nútíma nettækja í „þétttengdum“ staðfræði með miklum fjölda ECMP leiða. Að auki talaði Dima stuttlega um skipulag ytri tengingar, líkamlegt lag, kapalkerfið og leiðir til að auka enn frekar afkastagetu.
- Góðan daginn allir! Ég heiti Dmitry Afanasyev, ég er netarkitekt hjá Yandex og hanna fyrst og fremst netkerfi gagnavera.
Sagan mín mun fjalla um uppfært net Yandex gagnavera. Þetta er mjög mikil þróun hönnunarinnar sem við höfðum, en á sama tíma eru nokkrir nýir þættir. Þetta er yfirlitskynning vegna þess að það var mikið af upplýsingum sem átti að pakka niður á lítinn tíma. Við byrjum á því að velja rökrétta staðfræði. Síðan verður yfirlit yfir stjórnplanið og vandamál með sveigjanleika gagnaplans, val um hvað gerist á líkamlegu stigi og við skoðum nokkra eiginleika tækjanna. Við skulum snerta aðeins það sem er að gerast í gagnaveri með MPLS, sem við ræddum um fyrir nokkru síðan.
Svo, hvað er Yandex hvað varðar álag og þjónustu? Yandex er dæmigerður hyperscaler. Ef við skoðum notendur þá vinnum við fyrst og fremst úr notendabeiðnum. Einnig ýmsa streymisþjónustu og gagnaflutning því við erum líka með geymsluþjónustu. Ef það er nær bakendanum, þá birtast innviðahleðsla og þjónusta þar, svo sem dreifð geymslupláss, afritun gagna og auðvitað þrálátar biðraðir. Ein helsta tegund vinnuálags er MapReduce og svipuð kerfi, straumvinnsla, vélanám o.fl.
Hvernig eru innviðirnir sem allt þetta gerist ofan á? Aftur, við erum frekar dæmigerður ofurskali, þó við séum kannski aðeins nær minni ofstærðarhlið litrófsins. En við höfum alla eiginleika. Við notum vörubúnað og lárétta mælikvarða þar sem það er mögulegt. Við erum með fulla auðlindasamsetningu: við vinnum ekki með einstakar vélar, einstaka rekka, heldur sameinum þær í stóran hóp af skiptanlegum auðlindum með einhverri viðbótarþjónustu sem fjallar um skipulagningu og úthlutun, og vinnum með alla þessa laug.
Svo við höfum næsta stig - stýrikerfið á tölvuklasastigi. Það er mjög mikilvægt að við höfum fulla stjórn á tæknibunkanum sem við notum. Við stjórnum endapunktum (hýsingar), netkerfi og hugbúnaðarstafla.
Við erum með nokkur stór gagnaver í Rússlandi og erlendis. Þau eru sameinuð af burðarás sem notar MPLS tækni. Innri innviðir okkar eru nánast eingöngu byggðir á IPv6, en þar sem við þurfum að þjóna utanaðkomandi umferð sem kemur samt aðallega yfir IPv4, verðum við einhvern veginn að skila beiðnum sem koma yfir IPv4 til framenda netþjónanna, og aðeins meira fara á ytri IPv4- Internet - þ. til dæmis fyrir verðtryggingu.
Síðustu endurtekningar á nethönnun gagnavera hafa notað margra laga Clos svæðisfræði og eru eingöngu L3. Við fórum frá L2 fyrir stuttu og önduðum léttar. Að lokum inniheldur innviðir okkar hundruð þúsunda tölvutilvika (miðlara). Hámarks klasastærð fyrir nokkru var um 10 þúsund netþjónar. Þetta er að miklu leyti vegna þess hvernig þessi sömu stýrikerfi á klasastigi, tímaáætlun, úthlutun auðlinda osfrv. Við höfum verkefni - að geta byggt netverksmiðjur sem gera skilvirka auðlindasamsetningu í slíkum klasa.
Hvað viljum við fá af gagnaverakerfi? Í fyrsta lagi er mikið af ódýrri og nokkuð jafndreifðri bandbreidd. Vegna þess að netið er burðarásinn sem við getum sameinað auðlindir í gegnum. Nýja markstærðin er um 100 þúsund netþjónar í einum klasa.
Við viljum líka að sjálfsögðu skalanlegt og stöðugt stjórnkerfi, vegna þess að á svo stórum innviðum kemur mikill höfuðverkur jafnvel vegna einfaldlega tilviljunarkenndra atburða, og við viljum ekki að stjórnvélin valdi okkur líka höfuðverk. Jafnframt viljum við lágmarka ríkið í því. Því minni sem ástandið er, því betra og stöðugra virkar allt og því auðveldara er að greina það.
Auðvitað þurfum við sjálfvirkni, því það er ómögulegt að stjórna slíkum innviðum handvirkt og það hefur verið ómögulegt um nokkurt skeið. Við þurfum rekstrarstuðning eins og hægt er og CI/CD stuðning að því marki sem hægt er að veita.
Með slíkum stærðum gagnavera og klasa er verkefnið að styðja við stigvaxandi dreifingu og stækkun án truflunar á þjónustu orðið nokkuð bráð. Ef á klasa af stærð upp á þúsund vélar, kannski nálægt tíu þúsund vélum, væri samt hægt að rúlla þeim út sem eina aðgerð - það er að segja við erum að skipuleggja stækkun innviða og nokkur þúsund vélar bætast við sem ein aðgerð, þá myndast ekki þyrping af stærðinni hundrað þúsund vélar strax svona, hann er byggður á tilteknu tímabili. Og það er æskilegt að allan þennan tíma sé til staðar það sem þegar hefur verið dælt út, innviðirnir sem hafa verið teknir upp.
Og ein krafa sem við höfðum og skildum eftir: stuðningur við fjöleign, það er sýndarvæðingu eða netskiptingu. Nú þurfum við ekki að gera þetta á netkerfisstigi, vegna þess að klippingin hefur farið til gestgjafanna, og þetta hefur gert stærðarstærð mjög auðvelt fyrir okkur. Þökk sé IPv6 og miklu vistfangarými þurftum við ekki að nota tvöföld vistföng í innri innviði; öll vistföng voru þegar einstök. Og þökk sé þeirri staðreynd að við höfum tekið síun og netskiptingu til gestgjafanna, þurfum við ekki að búa til neinar sýndarneteiningar í netkerfum gagnavera.
Mjög mikilvægt atriði er það sem við þurfum ekki. Ef hægt er að fjarlægja sumar aðgerðir af netinu gerir þetta lífið miklu auðveldara og að jafnaði stækkar val á tiltækum búnaði og hugbúnaði, sem gerir greiningu mjög einfalda.
Svo, hvað er það sem við þurfum ekki, hverju höfum við getað gefið eftir, ekki alltaf með gleði á þeim tíma sem það gerðist, en með miklum létti þegar ferlinu er lokið?
Fyrst af öllu, að yfirgefa L2. Við þurfum ekki L2, hvorki raunverulegt né eftirlíkingu. Ónotað að miklu leyti vegna þess að við stjórnum forritastaflanum. Forritin okkar eru stigstærð lárétt, þau vinna með L3 heimilisfangi, þau hafa ekki miklar áhyggjur af því að eitthvert einstakt tilvik hafi farið út, þau rúlla einfaldlega út nýtt, það þarf ekki að rúlla út á gamla heimilisfangið, því það er sérstakt þjónustustig uppgötvun og eftirlit með vélum sem staðsettar eru í klasanum. Við framseljum þetta verkefni ekki til netsins. Hlutverk netsins er að afhenda pakka frá punkti A til punktar B.
Við höfum heldur ekki aðstæður þar sem heimilisföng færast innan netsins og það þarf að fylgjast með því. Í mörgum hönnunum er þetta venjulega nauðsynlegt til að styðja við hreyfanleika VM. Við notum ekki hreyfanleika sýndarvéla í innri innviði hins stóra Yandex, og þar að auki teljum við að jafnvel þótt þetta sé gert ætti það ekki að gerast með netstuðningi. Ef þú þarft virkilega að gera þetta þarftu að gera það á hýsingarstigi og ýta á vistföng sem geta flutt yfir í yfirlög, til að snerta ekki eða gera of miklar breytingar á leiðarkerfi undirlagsins sjálfs (flutningsnet) .
Önnur tækni sem við notum ekki er multicast. Ef þú vilt get ég sagt þér í smáatriðum hvers vegna. Þetta gerir lífið miklu auðveldara, því ef einhver hefur tekist á við það og skoðað nákvæmlega hvernig fjölvarpsstýringarvélin lítur út, í öllum nema einföldustu uppsetningum, þá er þetta mikill höfuðverkur. Og það sem meira er, það er erfitt að finna vel virka opinn uppspretta útfærslu, til dæmis.
Að lokum hönnum við netin okkar þannig að þau breytist ekki of mikið. Við getum treyst á þá staðreynd að flæði ytri atburða í leiðarkerfinu er lítið.
Hvaða vandamál koma upp og hvaða takmarkanir þarf að taka með í reikninginn þegar við þróum gagnaversnet? Kostnaður, auðvitað. Skalanleiki, stigið sem við viljum vaxa að. Þörfin fyrir að stækka án þess að stöðva þjónustuna. Bandbreidd, framboð. Sýnileiki á því sem er að gerast á netinu fyrir eftirlitskerfi, fyrir rekstrarteymi. Stuðningur við sjálfvirkni - aftur, eins mikið og mögulegt er, þar sem hægt er að leysa mismunandi verkefni á mismunandi stigum, þar á meðal kynning á viðbótarlögum. Jæja, ekki [hugsanlega] háð söluaðilum. Þó að á mismunandi sögulegum tímabilum, eftir því hvaða kafla þú horfir á, var þetta sjálfstæði auðveldara eða erfiðara að ná. Ef við tökum þverskurð af netbúnaðarflögum, þá var þar til nýlega mjög skilyrt að tala um sjálfstæði frá söluaðilum, ef við vildum líka flísar með mikilli afköst.
Hvaða rökfræðilega staðfræði munum við nota til að byggja upp netið okkar? Þetta verður multi-level Clos. Í raun eru engir raunverulegir kostir í augnablikinu. Og Clos staðfræðin er nokkuð góð, jafnvel í samanburði við ýmsa háþróaða staðfræði sem eru meira á sviði fræðilegs áhuga núna, ef við erum með stóra radix rofa.
Hvernig er fjölþrepa Clos netkerfi í grófum dráttum byggt upp og hvað heita mismunandi þættir í því? Fyrst af öllu, vindurinn hækkaði, til að stilla þig hvar er norður, hvar er suður, hvar er austur, hvar er vestur. Net af þessu tagi eru venjulega byggð af þeim sem hafa mjög mikla vest-austur umferð. Hvað varðar þá þætti sem eftir eru, efst er sýndarrofi settur saman úr smærri rofum. Þetta er meginhugmyndin um endurhverfa byggingu Clos netkerfa. Við tökum þætti með einhvers konar radix og tengjum þá saman þannig að það sem við fáum geti talist rofi með stærri radix. Ef þú þarft enn meira er hægt að endurtaka aðgerðina.
Í tilfellum, til dæmis með tveggja þrepa Clos, þegar hægt er að bera kennsl á hluti sem eru lóðréttir á skýringarmyndinni minni, eru þeir venjulega kallaðir flugvélar. Ef við myndum byggja Clos með þremur stigum hryggrofa (sem allir eru ekki marka- eða ToR rofar og eru aðeins notaðir til flutnings), þá myndu flugvélarnar líta flóknari út; tveggja þrepa líta nákvæmlega svona út. Við köllum blokk af ToR eða laufrofum og fyrsta stigs hryggrofa sem tengjast þeim Pod. Hryggrofar á hrygg-1 stigi efst á Pod eru efst á Pod, efst á Pod. Rofarnir sem eru staðsettir efst á allri verksmiðjunni eru efsta lag verksmiðjunnar, Top of efni.
Auðvitað vaknar spurningin: Clos net hafa verið byggð í nokkurn tíma, hugmyndin sjálf kemur almennt frá tímum klassískrar símtækni, TDM net. Kannski hefur eitthvað betra komið fram, kannski má gera eitthvað betur? Já og nei. Fræðilega séð já, í reynd á næstunni örugglega ekki. Vegna þess að það er fjöldi áhugaverðrar staðfræði, eru sumar þeirra jafnvel notaðar í framleiðslu, til dæmis er Dragonfly notað í HPC forritum; Það eru líka áhugaverðar staðfræði eins og Xpander, FatClique, Marglytta. Ef þú skoðar skýrslur á ráðstefnum eins og SIGCOMM eða NSDI nýlega, getur þú fundið nokkuð mikinn fjölda verka um aðra staðfræði sem hafa betri eiginleika (einn eða annan) en Clos.
En allar þessar staðfræði hafa einn áhugaverðan eiginleika. Það kemur í veg fyrir innleiðingu þeirra í netkerfum gagnavera, sem við erum að reyna að byggja á hrávörubúnaði og sem kosta nokkuð sanngjarna peninga. Í öllum þessum öðrum staðfræði er megnið af bandbreiddinni því miður ekki aðgengilegt með stystu leiðum. Þess vegna missum við strax tækifæri til að nota hefðbundna stjórnflugvél.
Fræðilega séð er lausn vandans þekkt. Þetta eru til dæmis breytingar á hlekkjastöðu með því að nota k-stytstu slóðina, en aftur, það eru engar slíkar samskiptareglur sem yrðu innleiddar í framleiðslu og víða aðgengilegar á búnaði.
Þar að auki, þar sem mest af afkastagetu er ekki aðgengileg um stystu leiðir, þurfum við að breyta meira en bara stjórnplaninu til að velja allar þessar leiðir (og við the vegur, þetta er verulega meira ástand í stjórnplaninu). Við þurfum enn að breyta framsendingarplaninu og að jafnaði þarf að minnsta kosti tvo eiginleika til viðbótar. Þetta er hæfileikinn til að taka allar ákvarðanir um framsendingu pakka í eitt skipti, til dæmis á gestgjafanum. Reyndar er þetta heimildaleið, stundum í bókmenntum um samtengingarnet er þetta kallað ákvörðun um framsendingu allt í einu. Og aðlögunarleið er aðgerð sem við þurfum á netþáttum, sem snýst til dæmis um það að við veljum næsta hopp út frá upplýsingum um minnsta álag á biðröðina. Sem dæmi eru aðrir valkostir mögulegir.
Þannig er stefnan áhugaverð, en því miður getum við ekki beitt henni núna.
Allt í lagi, við sættum okkur við rökfræðilega staðfræði Clos. Hvernig munum við skala það? Við skulum sjá hvernig það virkar og hvað er hægt að gera.
Í Clos neti eru tvær meginbreytur sem við getum einhvern veginn verið mismunandi og fengið ákveðnar niðurstöður: radix frumefna og fjöldi stiga í netinu. Ég er með skýringarmynd af því hvernig bæði hafa áhrif á stærðina. Helst sameinum við hvort tveggja.
Það má sjá að endanleg breidd Clos netsins er afrakstur allra stiga hryggrofa á suðurradix, hversu marga tengla við höfum niður, hvernig það greinir. Svona mælikvarða við stærð netsins.
Varðandi getu, sérstaklega á ToR rofa, þá eru tveir stærðarmöguleikar. Annaðhvort getum við notað hraðari hlekki, á meðan við höldum almennri staðfræði, eða við getum bætt við fleiri flugvélum.
Ef þú horfir á stækkaða útgáfuna af Clos netinu (neðst í hægra horninu) og ferð aftur á þessa mynd með Clos netinu fyrir neðan...
... þá er þetta nákvæmlega sama staðfræði, en á þessari rennibraut er hún þéttari saman og plön verksmiðjunnar eru lögð ofan á hvert annað. Það er það sama.
Hvernig lítur mælikvarði á Clos net út í tölum? Hér gef ég gögn um hvaða hámarksbreidd net er hægt að fá, hvaða hámarksfjölda rekka, ToR rofa eða laufrofa, ef þeir eru ekki í rekkum, getum við fengið eftir því hvaða radix rofa við notum fyrir hrygg -stig, og hversu mörg stig við notum.
Hér er hversu mörg rekki við getum haft, hversu marga netþjóna og um það bil hversu mikið þetta getur eytt miðað við 20 kW á rekki. Nokkru áðan minntist ég á að við stefnum á klasastærð upp á um 100 þúsund netþjóna.
Það má sjá að í allri þessari hönnun eru tveir og hálfur valkostur áhugaverður. Það er valkostur með tveimur lögum af hryggjum og 64-porta rofum, sem fellur aðeins niður. Þá eru fullkomlega viðeigandi valkostir fyrir 128 porta (með radix 128) hryggrofa með tveimur stigum, eða rofa með radix 32 með þremur stigum. Og í öllum tilfellum, þar sem það eru fleiri radixar og fleiri lög, geturðu búið til mjög stórt net, en ef þú horfir á væntanlega neyslu eru venjulega gígavött. Það er hægt að leggja kapal en ólíklegt er að við fáum svona mikið rafmagn á einum stað. Ef þú skoðar tölfræði og opinber gögn um gagnaver má finna mjög fá gagnaver með áætlaða afkastagetu yfir 150 MW. Þau stærri eru venjulega háskólasvæði gagnavera, nokkur stór gagnaver staðsett nokkuð nálægt hvort öðru.
Það er annar mikilvægur breytu. Ef þú skoðar vinstri dálkinn er nothæf bandbreidd skráð þar. Auðvelt er að sjá að í Clos neti er umtalsverður hluti portanna notaður til að tengja rofa hvert við annað. Nothæf bandbreidd, gagnleg ræma, er eitthvað sem hægt er að gefa utan, í átt að netþjónunum. Ég er náttúrulega að tala um skilyrtar hafnir og sérstaklega um hljómsveitina. Að jafnaði eru tengingar innan netsins hraðari en tengingar á netþjóna, en fyrir hverja einingu af bandbreidd, eins mikið og við getum sent það út á netþjónabúnaðinn okkar, er enn einhver bandbreidd innan netsins sjálfs. Og því fleiri borð sem við gerum, því meiri er sérstakur kostnaður við að útvega þessa rönd að utan.
Þar að auki er jafnvel þessi viðbótarhljómsveit ekki nákvæmlega sú sama. Þó að spannirnar séu stuttar getum við notað eitthvað eins og DAC (direct attach copper, það er twinax snúrur), eða multimode ljósfræði, sem kostar jafnvel meira og minna sanngjarnan pening. Um leið og við förum yfir í lengri breidd - að jafnaði eru þetta einhams ljósfræði og kostnaður við þessa viðbótarbandbreidd eykst áberandi.
Og aftur, aftur til fyrri glærunnar, ef við búum til Clos net án ofáskriftar, þá er auðvelt að skoða skýringarmyndina, sjá hvernig netið er byggt upp - bætum við hverju stigi hryggrofa, við endurtökum alla ræmuna sem var á botn. Aukastig - plús sama band, sama fjöldi tengi á rofum og var á fyrra stigi, og sama fjöldi senditækja. Þess vegna er mjög æskilegt að lágmarka fjölda stiga hryggrofa.
Miðað við þessa mynd er ljóst að við viljum virkilega byggja á einhverju eins og rofa með radix 128.
Hér er í grundvallaratriðum allt eins og það sem ég sagði bara; þetta er glæra til íhugunar síðar.
Hvaða valkostir eru það sem við getum valið sem slíkir rofar? Það eru mjög ánægjulegar fréttir fyrir okkur að nú er loksins hægt að byggja slík net á einflísarrofum. Og þetta er mjög flott, þeir hafa marga fína eiginleika. Til dæmis hafa þeir nánast enga innri uppbyggingu. Þetta þýðir að þeir brotna auðveldara. Þeir brotna á allskonar hátt en sem betur fer brotna þeir alveg. Í einingatækjum er mikill fjöldi galla (mjög óþægilegt), þegar frá sjónarhóli nágranna og stjórnborðs virðist það vera að virka, en til dæmis hefur hluti af efninu tapast og það virkar ekki á fullum afköstum. Og umferðin að henni er jöfn miðað við þá staðreynd að hún er fullvirk og við getum orðið fyrir ofhleðslu.
Eða, til dæmis, koma upp vandamál með bakplanið, því inni í einingatækinu eru einnig háhraða SerDes - það er mjög flókið að innan. Annað hvort eru merki milli framsendingarþátta samstillt eða ekki samstillt. Almennt séð inniheldur hvaða afkastamikill einingabúnaður sem samanstendur af miklum fjölda þátta, að jafnaði, sama Clos netið í sjálfu sér, en það er mjög erfitt að greina það. Oft er jafnvel erfitt fyrir seljandann sjálfan að greina.
Og það hefur mikinn fjölda bilunaratburðarása þar sem tækið rýrnar, en dettur ekki alveg út úr staðfræðinni. Þar sem netið okkar er stórt er jafnvægi á milli eins þátta virkt notað, netið er mjög reglulegt, það er að segja að ein leið þar sem allt er í lagi er ekkert frábrugðin hinum leiðinni, það er arðbærara fyrir okkur að missa einfaldlega eitthvað af tækin úr staðfræðinni en að lenda í aðstæðum þar sem sum þeirra virðast virka en sum ekki.
Næsti ágæti eiginleiki tækja með einum flís er að þau þróast betur og hraðar. Þeir hafa líka tilhneigingu til að hafa betri getu. Ef við tökum stóru samsettu mannvirkin sem við höfum á hring, þá er afkastageta á hverja rekkieiningu fyrir höfn með sama hraða næstum tvöfalt meiri en í einingatækjum. Tæki byggð í kringum einn flís eru áberandi ódýrari en einingatæki og eyða minni orku.
En auðvitað er þetta allt af ástæðu, það eru líka ókostir. Í fyrsta lagi er radix næstum alltaf minni en einingatækja. Ef við getum fengið tæki byggt í kringum einn flís með 128 höfnum, þá getum við fengið mát með nokkur hundruð höfnum núna án vandræða.
Þetta er áberandi minni stærð af framsendingartöflum og að jafnaði allt sem tengist sveigjanleika gagnaplans. Grunnir stuðpúðar. Og að jafnaði frekar takmörkuð virkni. En það kemur í ljós að ef þú þekkir þessar takmarkanir og gætir þess tímanlega að sniðganga þær eða einfaldlega taka tillit til þeirra, þá er þetta ekki svo skelfilegt. Sú staðreynd að radix er minni er ekki lengur vandamál í tækjum með radix 128 sem hafa loksins birst nýlega; við getum byggt í tvö lög af hryggjum. En það er samt ómögulegt að byggja neitt minna en tvö sem er áhugavert fyrir okkur. Með einu stigi fást mjög litlir klasar. Jafnvel fyrri hönnun okkar og kröfur fóru enn fram úr þeim.
Reyndar, ef skyndilega er lausnin einhvers staðar á barmi, þá er enn leið til að skala. Þar sem síðasta (eða fyrsta), lægsta stigið þar sem netþjónar eru tengdir eru ToR rofar eða laufrofar, þurfum við ekki að tengja einn rekki við þá. Þess vegna, ef lausnin fellur niður um helming, geturðu hugsað þér að nota einfaldlega rofa með stórum radix á neðra stigi og tengja til dæmis tvær eða þrjár rekki í einn rofa. Þetta er líka valkostur, það hefur sinn kostnað, en það virkar nokkuð vel og getur verið góð lausn þegar þú þarft að ná um tvöfaldri stærð.
Til að draga saman þá erum við að byggja á svæðisfræði með tveimur stigum hryggjar, með átta verksmiðjulögum.
Hvað verður um eðlisfræðina? Mjög einfaldir útreikningar. Ef við erum með tvö stig af hryggjum, þá höfum við aðeins þrjú stig af rofa, og við gerum ráð fyrir að það verði þrír kapalhlutar á netinu: frá netþjónum til laufrofa, til hryggs 1, til hryggs 2. Valkostirnir sem við getum notkun eru - þetta eru twinax, multimode, single mode. Og hér þurfum við að íhuga hvaða ræma er í boði, hversu mikið það mun kosta, hverjar líkamlegar stærðir eru, hvaða breiddir við getum náð og hvernig við munum uppfæra.
Hvað kostnað varðar er hægt að stilla öllu upp. Twinaxes eru umtalsvert ódýrari en virk ljósfræði, ódýrari en multimode senditæki, ef þú tekur það í hvert flug frá endanum, nokkuð ódýrari en 100 gígabita rofatengi. Og, vinsamlegast athugaðu, það kostar minna en sjónfræði með stakri stillingu, vegna þess að í flugi þar sem þörf er á stakri stillingu, í gagnaverum af ýmsum ástæðum er skynsamlegt að nota CWDM, á meðan samhliða einstilling (PSM) er ekki mjög þægilegt að vinna með, mjög stórar pakkningar fást trefjar, og ef við leggjum áherslu á þessa tækni, fáum við um það bil eftirfarandi verðstigveldi.
Ein athugasemd í viðbót: því miður er ekki mjög hægt að nota sundurtekin 100 til 4x25 multimode tengi. Vegna hönnunareiginleika SFP28 senditækja er hann ekki mikið ódýrari en 28 Gbit QSFP100. Og þetta í sundur fyrir multimode virkar ekki mjög vel.
Önnur takmörkun er sú að vegna stærðar tölvuklasanna og fjölda netþjóna reynast gagnaver okkar vera líkamlega stór. Þetta þýðir að að minnsta kosti eitt flug verður að fara fram með singlemod. Aftur, vegna líkamlegrar stærðar fræbelganna, verður ekki hægt að keyra tvö spann af twinax (koparkaplum).
Þar af leiðandi, ef við fínstillum fyrir verð og tökum tillit til rúmfræði þessarar hönnunar, fáum við eitt span af twinax, eitt span af multimode og eitt span af singlemode með CWDM. Þetta tekur tillit til mögulegra uppfærsluleiða.
Svona lítur þetta út að undanförnu, hvert við stefnum og hvað er mögulegt. Það er að minnsta kosti ljóst hvernig á að fara í átt að 50 gígabita SerDes fyrir bæði multimode og singlemode. Þar að auki, ef þú horfir á hvað er í einhams sendum nú og í framtíðinni fyrir 400G, oft jafnvel þegar 50G SerDes koma frá rafmagnshliðinni, geta 100 Gbps á hverja braut nú þegar farið í ljósfræði. Þess vegna er vel mögulegt að í stað þess að færa sig yfir í 50 verði skipt yfir í 100 Gigabit SerDes og 100 Gbps á akrein, því samkvæmt loforðum margra framleiðenda er búist við framboði þeirra nokkuð fljótlega. Tímabilið þegar 50G SerDes voru hraðastar, að því er virðist, verði ekki mjög langur, því fyrstu eintökin af 100G SerDes verða sett út á næsta ári. Og eftir nokkurn tíma þar á eftir verða þeir líklega sanngjarnir peningar virði.
Enn einn blæbrigði um val á eðlisfræði. Í grundvallaratriðum getum við nú þegar notað 400 eða 200 Gigabit tengi með 50G SerDes. En það kemur í ljós að þetta er ekki skynsamlegt, því eins og ég sagði áðan viljum við frekar stóran radix á rofana, auðvitað innan skynsamlegrar skynsemi. Við viljum 128. Og ef við höfum takmarkaða flísagetu og aukum tengihraðann, þá minnkar radix náttúrulega, það eru engin kraftaverk.
Og við getum aukið heildargetuna með því að nota flugvélar og það er enginn sérstakur kostnaður; við getum bætt við fjölda flugvéla. Og ef við missum radixinn, verðum við að kynna aukastig, þannig að við núverandi aðstæður, með núverandi hámarks tiltæka afkastagetu á hvern flís, kemur í ljós að það er skilvirkara að nota 100 gígabita tengi, því þau leyfa þér til að fá stærri radix.
Næsta spurning er hvernig eðlisfræði er skipulögð, en frá sjónarhóli kapalinnviða. Það kemur í ljós að það er skipulagt á frekar fyndinn hátt. Kaðall milli laufrofa og fyrsta stigs hryggjar - það eru ekki margir tenglar þar, allt er byggt tiltölulega einfaldlega. En ef við tökum eina flugvél, það sem gerist inni er að við þurfum að tengja allar hryggjar á fyrsta stigi við allar hryggjar á öðru stigi.
Auk þess eru að jafnaði nokkrar óskir um hvernig það ætti að líta út inni í gagnaverinu. Okkur langaði til dæmis mjög mikið að sameina snúrur í búnt og draga þá þannig að eitt þéttleikaplástursborð færi alfarið í eitt plásturspjald, þannig að það var enginn dýragarður miðað við lengd. Okkur tókst að leysa þetta vandamál. Ef þú skoðar rökfræðilega staðfræði í upphafi geturðu séð að flugvélarnar eru sjálfstæðar, hægt er að byggja hverja flugvél fyrir sig. En þegar við bætum við slíkri búnt og viljum draga allt plásturspjaldið inn í plásturspjald, verðum við að blanda saman mismunandi flötum inni í einum búnti og kynna millibyggingu í formi sjónrænna krosstenginga til að pakka þeim aftur frá því hvernig þeir voru settir saman. á einum hluta , hvernig þeim verður safnað á öðrum hluta. Þökk sé þessu fáum við góðan eiginleika: öll flókin skipting fer ekki út fyrir rekkana. Þegar þú þarft að flétta eitthvað mjög sterkt saman, „afbrjóta flugvélarnar,“ eins og það er stundum kallað í Clos-netum, þá er það allt saman safnað inni í einum rekki. Við erum ekki með mjög sundurlausa, allt að einstökum hlekkjum, til að skipta á milli rekka.
Svona lítur þetta út frá sjónarhóli rökrétts skipulags kapalmannvirkja. Á myndinni til vinstri sýna marglitu kubbarnir kubba af fyrsta stigi hryggrofa, átta stykki hver, og fjóra snúra sem koma frá þeim, sem fara og skerast búntana sem koma úr kubbum hrygg-2 rofa .
Litlir reitir gefa til kynna gatnamót. Efst til vinstri er sundurliðun á hverri slíkri gatnamótum, þetta er í raun 512 x 512 port krosstengieining sem pakkar snúrunum aftur þannig að þær koma alveg í eina rekki, þar sem aðeins er ein hrygg-2 plan. Og til hægri er skönnun af þessari mynd aðeins ítarlegri í tengslum við nokkra fræbelg á hrygg-1 stigi, og hvernig henni er pakkað í krosstengingu, hvernig það kemur að hrygg-2 stigi.
Svona lítur þetta út. Enn ekki fullkomlega samsettur spine-2 standurinn (vinstra megin) og krosstengistandurinn. Því miður er ekki mikið að sjá þar. Allt þetta skipulag er í notkun núna í einu af stóru gagnaverunum okkar sem er verið að stækka. Þetta er í vinnslu, það mun líta fallegra út, það verður útfyllt betur.
Mikilvæg spurning: við völdum rökræna staðfræði og byggðum eðlisfræðina. Hvað verður um stjórnflugvélina? Það er nokkuð vel þekkt af rekstrarreynslu, það er fjöldi skýrslna um að samskiptareglur um tengslaríki séu góðar, það er ánægjulegt að vinna með þær, en, því miður, mælist þær ekki vel á þétttengdri staðfræði. Og það er einn aðalþáttur sem kemur í veg fyrir þetta - þetta er hvernig flóð virka í samskiptareglum um tengiríki. Ef þú tekur bara flóðalgrímið og lítur á hvernig netið okkar er uppbyggt, geturðu séð að það verður mjög mikill fanout í hverju skrefi og það mun einfaldlega flæða stjórnplanið með uppfærslum. Nánar tiltekið blandast slík staðfræði mjög illa saman við hefðbundna flóðalgrímið í samskiptareglum um tengistöðu.
Valið er að nota BGP. Hvernig á að undirbúa það rétt er lýst í RFC 7938 um notkun BGP í stórum gagnaverum. Grunnhugmyndirnar eru einfaldar: lágmarksfjöldi forskeyta á hvern gestgjafa og almennt lágmarksfjöldi forskeyta á netinu, notaðu samsöfnun ef mögulegt er og bæla niður slóðaleit. Við viljum mjög varlega, mjög stjórnaða dreifingu á uppfærslum, það sem kallað er dallaus. Við viljum að uppfærslur séu sendar nákvæmlega einu sinni þegar þær fara í gegnum netið. Ef þeir eiga uppruna sinn í botninum fara þeir upp og brjótast ekki út oftar en einu sinni. Það ætti ekki að vera sikksakk. Sikksakk eru mjög slæm.
Til að gera þetta notum við hönnun sem er nógu einföld til að nota undirliggjandi BGP kerfi. Það er að segja, við notum eBGP sem keyrir á staðbundnum hlekkjum og sjálfstýrðum kerfum er úthlutað sem hér segir: sjálfstætt kerfi á ToR, sjálfstætt kerfi á allri blokkinni af hrygg-1 rofum á einum Pod, og almennu sjálfvirku kerfi á öllu Top af Efni. Það er ekki erfitt að líta og sjá að jafnvel venjuleg hegðun BGP gefur okkur dreifingu uppfærslna sem við viljum.
Að sjálfsögðu þarf að hanna aðsetur og samsöfnun aðseturs þannig að það sé samhæft við hvernig leið er byggt upp, þannig að það tryggi stöðugleika stjórnplansins. L3 vistföng í flutningi eru bundin við staðfræði, því án þess er ómögulegt að ná samansöfnun; án þess munu einstök vistföng læðast inn í leiðarkerfið. Og eitt í viðbót er að samsöfnun, því miður, blandast ekki mjög vel við multi-path, því þegar við erum með multi-path og við erum með aggregation, þá er allt í lagi, þegar allt netið er heilbrigt, þá eru engar bilanir í því. Því miður, um leið og bilanir birtast í netinu og samhverfa staðfræðinnar glatast, getum við komið að þeim stað sem einingin var tilkynnt frá, þaðan sem við getum ekki farið lengra þangað sem við þurfum að fara. Þess vegna er best að safna saman þar sem ekki er frekari fjölbrautir, í okkar tilviki eru þetta ToR rofar.
Reyndar er hægt að safna saman, en varlega. Ef við getum gert stjórnað sundurliðun þegar netbilanir eiga sér stað. En þetta er frekar erfitt verkefni, við veltum því meira að segja fyrir okkur hvort það væri hægt að gera þetta, hvort það væri hægt að bæta við auka sjálfvirkni og endanlegu ástandsvélum sem myndu rétt sparka í BGP til að fá æskilega hegðun. Því miður er afgreiðsla hornmála mjög óljós og flókin og þetta verkefni er ekki vel leyst með því að tengja utanaðkomandi viðhengi við BGP.
Mjög áhugavert starf í þessum efnum hefur farið fram innan ramma RIFT bókunarinnar sem fjallað verður um í næstu skýrslu.
Annar mikilvægur hlutur er hvernig gagnaflugvélar stækka í þéttum staðfræði, þar sem við höfum mikinn fjölda annarra leiða. Í þessu tilviki eru nokkur viðbótargagnaskipulag notuð: ECMP hópar, sem aftur lýsa Next Hop hópum.
Í venjulega starfandi neti, án bilana, þegar við förum upp Clos-topology, er nóg að nota aðeins einn hóp, því öllu sem er ekki staðbundið er lýst sjálfgefið, við getum farið upp. Þegar við förum frá toppi til botns til suðurs, þá eru ekki allir stígar ECMP, þeir eru einstígar. Allt er í lagi. Vandamálið er, og sérkenni hinnar klassísku Clos staðfræði er að ef við lítum á Efst á efni, á hvaða frumefni sem er, þá er aðeins ein leið að hvaða frumefni sem er fyrir neðan. Ef bilanir verða á þessari leið, þá verður þessi tiltekna þáttur efst í verksmiðjunni ógildur einmitt fyrir þau forskeyti sem liggja á bak við brotnu leiðina. En fyrir rest er það gilt og við verðum að flokka ECMP hópana og kynna nýtt ríki.
Hvernig lítur sveigjanleiki gagnaplans út í nútíma tækjum? Ef við gerum LPM (lengsta forskeyti passa), er allt nokkuð gott, yfir 100 þúsund forskeyti. Ef við erum að tala um Next Hop hópa þá er allt verra, 2-4 þús. Ef við erum að tala um töflu sem inniheldur lýsingu á Next Hops (eða adjacencies), þá er þetta einhvers staðar frá 16k til 64k. Og þetta getur orðið vandamál. Og hér komum við að áhugaverðri frávik: hvað varð um MPLS í gagnaverum? Í grundvallaratriðum vildum við gera það.
Tvennt gerðist. Við gerðum örskiptingu á vélunum; við þurftum ekki lengur að gera það á netinu. Það var ekki mjög gott með stuðningi frá mismunandi söluaðilum, og enn frekar með opnum útfærslum á hvítum kassa með MPLS. Og MPLS, að minnsta kosti hefðbundnar útfærslur þess, því miður, sameinast mjög illa ECMP. Og þess vegna.
Svona lítur ECMP-framsendingaruppbyggingin fyrir IP út. Mikill fjöldi forskeyta getur notað sama hópinn og sömu Next Hops blokkina (eða aðlægingar, þetta getur verið kallað öðruvísi í mismunandi skjölum fyrir mismunandi tæki). Málið er að þessu er lýst sem útgangi og hvað á að endurskrifa MAC vistfangið á til að komast í rétta Next Hop. Fyrir IP lítur allt einfalt út, þú getur notað mjög mikinn fjölda af forskeytum fyrir sama hóp, sama Next Hops blokk.
Klassíski MPLS arkitektúrinn gefur til kynna að hægt sé að endurskrifa merkið í mismunandi gildi, allt eftir útgefandi viðmóti. Þess vegna þurfum við að hafa hóp og Next Hops blokk fyrir hvert inntaksmerki. Og þetta, því miður, mælist ekki.
Það er auðvelt að sjá að í hönnun okkar þurftum við um 4000 ToR rofa, hámarksbreiddin var 64 ECMP brautir, ef við færum okkur frá hrygg-1 í átt að hrygg-2. Við komumst varla inn í eina töflu yfir ECMP hópa, ef aðeins eitt forskeyti með ToR hverfur, og við komumst alls ekki inn í Next Hops töfluna.
Það er ekki allt vonlaust, vegna þess að arkitektúr eins og Segment Routing felur í sér alþjóðleg merki. Formlega væri hægt að fella allar þessar Next Hops blokkir aftur. Til að gera þetta þarftu aðgerð með jokertákn: taktu merkimiða og endurskrifaðu það í þann sama án sérstaks gildis. En því miður er þetta ekki mjög til staðar í þeim útfærslum sem til eru.
Og að lokum þurfum við að koma utanaðkomandi umferð inn í gagnaverið. Hvernig á að gera það? Áður var umferð innleidd í Clos netið að ofan. Það er að segja að það voru brúnbeinar sem tengdust öllum tækjum á Top of efninu. Þessi lausn virkar nokkuð vel á litlum til meðalstærðum. Því miður, til þess að senda umferð samhverft á allt netið á þennan hátt, þurfum við að komast samtímis að öllum hlutum Top of efnisins og þegar þeir eru fleiri en hundrað kemur í ljós að við þurfum líka stóran radix á brúnbeini. Almennt kostar þetta peninga, vegna þess að brúnbeinir eru virkari, tengin á þeim verða dýrari og hönnunin er ekki mjög falleg.
Annar möguleiki er að hefja slíka umferð neðan frá. Auðvelt er að sannreyna að Clos staðfræðin sé byggð á þann hátt að umferð sem kemur neðan frá, það er frá ToR hliðinni, dreifist jafnt á borð um allt Top of efni í tveimur endurtekningum og hleður allt netið. Þess vegna kynnum við sérstaka tegund af Pod, Edge Pod, sem veitir ytri tengingu.
Það er einn kostur í viðbót. Þetta gerir Facebook til dæmis. Þeir kalla það Fabric Aggregator eða HGRID. Verið er að kynna viðbótar hryggstig til að tengja saman margar gagnaver. Þessi hönnun er möguleg ef við höfum ekki viðbótaraðgerðir eða breytingar á hjúpun á viðmótunum. Ef þeir eru viðbótarsnertipunktar er það erfitt. Venjulega eru fleiri aðgerðir og eins konar himna sem aðskilur mismunandi hluta gagnaversins. Það þýðir ekkert að gera slíka himnu stóra, en ef það er raunverulega þörf á henni af einhverjum ástæðum, þá er skynsamlegt að íhuga möguleikann á að taka hana í burtu, gera hana eins breiða og hægt er og flytja hana til hýslanna. Þetta er til dæmis gert af mörgum skýjafyrirtækjum. Þeir eru með yfirlögn, þeir byrja á gestgjöfunum.
Hvaða þróunarmöguleika sjáum við? Fyrst af öllu, að bæta stuðning við CI/CD leiðsluna. Við viljum fljúga eins og við prófum og prófa hvernig við fljúgum. Þetta gengur ekki mjög vel, því innviðirnir eru stórir og ómögulegt að afrita það fyrir prófanir. Þú þarft að skilja hvernig á að kynna prófunarþætti inn í framleiðsluinnviðina án þess að sleppa því.
Betri tækjabúnaður og betra eftirlit er nánast aldrei óþarfi. Öll spurningin er jafnvægi áreynslu og ávöxtunar. Ef þú getur bætt því við með hæfilegri fyrirhöfn, mjög gott.
Opið stýrikerfi fyrir nettæki. Betri samskiptareglur og betri leiðarkerfi, eins og RIFT. Einnig er þörf á rannsóknum á notkun betri þrengslaeftirlitskerfa og ef til vill innleiðingu, að minnsta kosti á einhverjum tímapunkti, á RDMA stuðningi innan klasans.
Þegar horft er lengra inn í framtíðina þurfum við háþróaða staðfræði og hugsanlega netkerfi sem nota minna kostnaður. Af ferskum hlutum hafa nýlega verið birtar útgáfur um efnistæknina fyrir HPC Cray Slingshot, sem byggir á hrávöru Ethernet, en með möguleika á að nota mun styttri hausa. Fyrir vikið minnkar kostnaðurinn.
Allt ætti að vera eins einfalt og mögulegt er, en ekki einfaldara. Flækjustig er óvinur sveigjanleika. Einfaldleiki og regluleg mannvirki eru vinir okkar. Ef þú getur útskalað einhvers staðar, gerðu það. Og almennt séð er frábært að taka þátt í nettækni núna. Það er margt áhugavert í gangi. Þakka þér fyrir.
Heimild: www.habr.com