ProHoster > Blogs > Administrācija > Kā mērogot datu centrus. Yandex pārskats

Kā mērogot datu centrus. Yandex pārskats

Mēs esam izstrādājuÅ”i datu centra tÄ«kla dizainu, kas ļauj izvietot skaitļoÅ”anas klasterus, kas ir lielāki par 100 tÅ«kstoÅ”iem serveru ar maksimālo bisekcijas joslas platumu, kas pārsniedz vienu petabaitu sekundē.

No Dmitrija Afanasjeva ziņojuma jÅ«s uzzināsit par jaunā dizaina pamatprincipiem, mērogoÅ”anas topoloÄ£ijām, ar to saistÄ«tām problēmām, to risināŔanas iespējām, mÅ«sdienu tÄ«kla ierīču pāradresācijas plaknes funkciju marÅ”rutÄ“Å”anas un mērogoÅ”anas iespējām ā€œblÄ«vi savienotāsā€ vietās. topoloÄ£ijas ar lielu skaitu ECMP marÅ”rutu. Turklāt Dima Ä«sumā stāstÄ«ja par ārējā savienojuma organizÄ“Å”anu, fizisko slāni, kabeļu sistēmu un veidiem, kā vēl vairāk palielināt jaudu.

Kā mērogot datu centrus. Yandex pārskats

- Labdien visiem! Mani sauc Dmitrijs Afanasjevs, es esmu Yandex tīkla arhitekts un galvenokārt projektēju datu centru tīklus.

Kā mērogot datu centrus. Yandex pārskats

Mans stāsts bÅ«s par atjaunināto Yandex datu centru tÄ«klu. Tas lielā mērā ir mÅ«su dizaina evolÅ«cija, taču tajā paŔā laikā ir daži jauni elementi. Å Ä« ir pārskata prezentācija, jo bija daudz informācijas, kas jāiepako nelielā laika posmā. Sāksim ar loÄ£iskās topoloÄ£ijas izvēli. Pēc tam bÅ«s pārskats par vadÄ«bas plakni un problēmām ar datu plaknes mērogojamÄ«bu, izvēle, kas notiks fiziskajā lÄ«menÄ«, un mēs apskatÄ«sim dažas ierīču funkcijas. Pieskarsimies nedaudz tam, kas notiek datu centrā ar MPLS, par ko mēs runājām pirms kāda laika.

Kā mērogot datu centrus. Yandex pārskats

Tātad, kas ir Yandex slodzes un pakalpojumu ziņā? Yandex ir tipisks hiperskalers. Ja mēs skatāmies uz lietotājiem, mēs galvenokārt apstrādājam lietotāju pieprasÄ«jumus. ArÄ« dažādi straumÄ“Å”anas pakalpojumi un datu pārraide, jo mums ir arÄ« uzglabāŔanas pakalpojumi. Ja tuvāk aizmugursistēmai, tad tur parādās infrastruktÅ«ras slodzes un pakalpojumi, piemēram, sadalÄ«ta objektu krātuve, datu replikācija un, protams, pastāvÄ«gas rindas. Viens no galvenajiem darba slodzes veidiem ir MapReduce un lÄ«dzÄ«gas sistēmas, straumju apstrāde, maŔīnmācÄ«Å”anās utt.

Kā mērogot datu centrus. Yandex pārskats

Kā ir ar infrastruktÅ«ru, uz kuras tas viss notiek? Atkal mēs esam diezgan tipisks hiperskalotājs, lai gan mēs, iespējams, esam nedaudz tuvāk spektra mazākajai hiperskalera pusei. Bet mums ir visas Ä«paŔības. Mēs izmantojam preču aparatÅ«ru un horizontālo mērogoÅ”anu, kur vien iespējams. Mums ir pilna resursu apvienoÅ”ana: mēs nestrādājam ar atseviŔķām maŔīnām, atseviŔķiem plauktiem, bet apvienojam tos lielā savstarpēji aizvietojamu resursu baseinā ar dažiem papildu pakalpojumiem, kas nodarbojas ar plānoÅ”anu un sadali, un strādājam ar visu Å”o kopu.

Tātad mums ir nākamais lÄ«menis ā€“ operētājsistēma skaitļoÅ”anas klastera lÄ«menÄ«. Ir ļoti svarÄ«gi, lai mēs pilnÄ«bā kontrolētu izmantojamo tehnoloÄ£iju kopumu. Mēs kontrolējam galapunktus (saimniekus), tÄ«klu un programmatÅ«ras steku.

Mums ir vairāki lieli datu centri Krievijā un ārvalstÄ«s. Tos vieno mugurkauls, kas izmanto MPLS tehnoloÄ£iju. MÅ«su iekŔējā infrastruktÅ«ra gandrÄ«z pilnÄ«bā ir veidota uz IPv6, taču, tā kā mums ir jāapkalpo ārējā trafika, kas joprojām galvenokārt nāk, izmantojot IPv4, mums kaut kādā veidā ir jānogādā pieprasÄ«jumi, kas tiek saņemti, izmantojot IPv4, uz priekÅ”gala serveriem un nedaudz vairāk jāiet uz ārējo IPv4 internetu. piemēram, indeksÄ“Å”anai.

Dažās pēdējās datu centru tÄ«kla projektu iterācijās ir izmantotas daudzslāņu Clos topoloÄ£ijas, un tās ir tikai L3. Pirms kāda laika izgājām no L2 un atviegloti uzelpojām. Visbeidzot, mÅ«su infrastruktÅ«rā ir simtiem tÅ«kstoÅ”u skaitļoÅ”anas (servera) gadÄ«jumu. Maksimālais klastera lielums pirms kāda laika bija aptuveni 10 tÅ«kstoÅ”i serveru. Tas lielā mērā ir saistÄ«ts ar to, kā var darboties tās paÅ”as klastera lÄ«meņa operētājsistēmas, plānotāji, resursu pieŔķirÅ”ana utt. Tā kā infrastruktÅ«ras programmatÅ«ras jomā ir panākts progress, tagad mērÄ·a lielums ir aptuveni 100 tÅ«kstoÅ”i serveru vienā skaitļoÅ”anas klasterÄ«, un Mums ir uzdevums ā€“ spēt uzbÅ«vēt tÄ«kla rÅ«pnÄ«cas, kas ļauj efektÄ«vi apvienot resursus Ŕādā klasterÄ«.

Kā mērogot datu centrus. Yandex pārskats

Ko mēs vēlamies no datu centru tÄ«kla? Pirmkārt, ir daudz lētu un diezgan vienmērÄ«gi sadalÄ«tu joslas platumu. Tā kā tÄ«kls ir mugurkauls, caur kuru mēs varam apvienot resursus. Jaunais mērÄ·a lielums ir aptuveni 100 tÅ«kstoÅ”i serveru vienā klasterÄ«.

Mēs, protams, vēlamies arÄ« mērogojamu un stabilu vadÄ«bas plakni, jo tik lielā infrastruktÅ«rā daudz galvassāpes rodas pat no vienkārÅ”i nejauÅ”iem notikumiem, un mēs nevēlamies, lai arÄ« vadÄ«bas plakne mums sagādā galvassāpes. Tajā paŔā laikā mēs vēlamies minimizēt stāvokli tajā. Jo mazāks stāvoklis, jo labāk un stabilāk viss darbojas, un jo vieglāk to diagnosticēt.

Protams, mums ir nepiecieÅ”ama automatizācija, jo manuāli pārvaldÄ«t Ŕādu infrastruktÅ«ru nav iespējams, un tas jau kādu laiku nav bijis iespējams. Mums ir nepiecieÅ”ams pēc iespējas lielāks operatÄ«vais atbalsts un CI/CD atbalsts, ciktāl tas ir iespējams.

Ar Ŕāda izmēra datu centriem un klasteriem uzdevums atbalstÄ«t pakāpenisku izvietoÅ”anu un paplaÅ”ināŔanu bez pakalpojuma pārtraukuma ir kļuvis diezgan akÅ«ts. Ja klasteros ar tÅ«kstoÅ” maŔīnu lielumu, varbÅ«t tuvu desmit tÅ«kstoÅ”iem maŔīnu, tās tomēr varētu izvērst kā vienu darbÄ«bu - tas ir, mēs plānojam infrastruktÅ«ras paplaÅ”ināŔanu, un vairāki tÅ«kstoÅ”i maŔīnu tiek pievienoti kā viena darbÄ«ba, tad simttÅ«kstoÅ” maŔīnu liela klasteris nerodas uzreiz kā Å”is, tas tiek uzbÅ«vēts noteiktā laika periodā. Un vēlams, lai visu Å”o laiku bÅ«tu pieejams tas, kas jau ir izsÅ«knēts, infrastruktÅ«ra, kas ir izvērsta.

Un viena prasÄ«ba, kas mums bija un tika atstāta: atbalsts vairāku Ä«rÄ“Å”anai, tas ir, virtualizācijai vai tÄ«kla segmentācijai. Tagad mums tas nav jādara tÄ«kla auduma lÄ«menÄ«, jo sadalÄ«Å”ana ir nonākusi saimniekiem, un tas mums ir ļoti atvieglojis mērogoÅ”anu. Pateicoties IPv6 un lielajai adreÅ”u telpai, mums iekŔējā infrastruktÅ«rā nebija jāizmanto dublētās adreses; visa adrese jau bija unikāla. Un, pateicoties tam, ka filtrÄ“Å”anu un tÄ«kla segmentāciju esam nodevuÅ”i saimniekiem, mums datu centru tÄ«klos nav jāizveido nekādas virtuālās tÄ«kla entÄ«tijas.

Kā mērogot datu centrus. Yandex pārskats

Ä»oti svarÄ«ga lieta ir tas, kas mums nav vajadzÄ«gs. Ja dažas funkcijas var noņemt no tÄ«kla, tas ievērojami atvieglo dzÄ«vi un, kā likums, paplaÅ”ina pieejamā aprÄ«kojuma un programmatÅ«ras izvēli, padarot diagnostiku ļoti vienkārÅ”u.

Tātad, kas mums nav vajadzÄ«gs, no kā mēs esam spējuÅ”i atteikties, ne vienmēr ar prieku brÄ«dÄ«, kad tas notika, bet ar lielu atvieglojumu, kad process ir pabeigts?

Pirmkārt, atteikÅ”anās no L2. Mums nav vajadzÄ«gs L2, ne Ä«sts, ne emulēts. Nelietots lielā mērā tāpēc, ka mēs kontrolējam lietojumprogrammu steku. MÅ«su aplikācijas ir horizontāli mērogojamas, strādā ar L3 adresÄ“Å”anu, ļoti neuztraucas, ka kāda atseviŔķa instance ir izgājusi, vienkārÅ”i izrullē jaunu, to nevajag izrullēt uz veco adresi, jo ir klasterÄ« esoÅ”o iekārtu atseviŔķs pakalpojumu atklāŔanas un uzraudzÄ«bas lÄ«menis. Mēs nedeleģējam Å”o uzdevumu tÄ«klam. TÄ«kla uzdevums ir piegādāt paketes no punkta A uz punktu B.

Mums nav arÄ« situācijas, kad adreses pārvietotos tÄ«klā, un tas ir jāuzrauga. Daudzos dizainos tas parasti ir nepiecieÅ”ams, lai atbalstÄ«tu VM mobilitāti. Mēs neizmantojam virtuālo maŔīnu mobilitāti lielā Yandex iekŔējā infrastruktÅ«rā, un turklāt uzskatām, ka pat tad, ja tas tiek darÄ«ts, tam nevajadzētu notikt ar tÄ«kla atbalstu. Ja tas patieŔām ir jādara, tas jādara resursdatora lÄ«menÄ« un jānospiež adreses, kuras var migrēt pārklājumos, lai nepieskartos paÅ”a apakÅ”klāja marÅ”rutÄ“Å”anas sistēmai (transporta tÄ«kls) vai neveiktu tajā pārāk daudz dinamisku izmaiņu. .

Vēl viena tehnoloÄ£ija, ko mēs neizmantojam, ir multiraide. Ja vēlaties, varu pastāstÄ«t sÄ«kāk, kāpēc. Tas ievērojami atvieglo dzÄ«vi, jo, ja kāds ar to ir ticis galā un apskatÄ«jis, kā tieÅ”i izskatās multiraides vadÄ«bas plakne, visās, izņemot vienkārŔākajās instalācijās, ir lielas galvassāpes. Un vēl jo vairāk, ir grÅ«ti atrast, piemēram, labi funkcionējoÅ”u atvērtā pirmkoda ievieÅ”anu.

Visbeidzot, mēs veidojam savus tÄ«klus tā, lai tie pārāk daudz nemainÄ«tos. Varam rēķināties ar to, ka ārējo notikumu plÅ«sma marÅ”rutÄ“Å”anas sistēmā ir neliela.

Kā mērogot datu centrus. Yandex pārskats

Kādas problēmas rodas un kādi ierobežojumi jāņem vērā, attÄ«stot datu centru tÄ«klu? Izmaksas, protams. MērogojamÄ«ba, lÄ«menis, lÄ«dz kuram vēlamies augt. NepiecieÅ”amÄ«ba paplaÅ”ināties, neapturot pakalpojumu. Joslas platums, pieejamÄ«ba. TÄ«klā notiekoŔā redzamÄ«ba uzraudzÄ«bas sistēmām, operatÄ«vajām komandām. Automatizācijas atbalsts - atkal, cik vien iespējams, jo dažādus uzdevumus var atrisināt dažādos lÄ«meņos, ieskaitot papildu slāņu ievieÅ”anu. Nu, nav [iespējams] atkarÄ«gs no pārdevējiem. Lai gan dažādos vēstures periodos, atkarÄ«bā no tā, uz kuru sadaļu skatās, Ŕī neatkarÄ«ba bija vieglāk vai grÅ«tāk sasniedzama. Ja ņemam tÄ«kla ierīču mikroshēmu Ŕķērsgriezumu, tad vēl nesen bija ļoti nosacÄ«ti runāt par neatkarÄ«bu no pārdevējiem, ja gribējām arÄ« mikroshēmas ar lielu caurlaidspēju.

Kā mērogot datu centrus. Yandex pārskats

Kādu loÄ£isko topoloÄ£iju mēs izmantosim tÄ«kla izveidei? Å is bÅ«s daudzlÄ«meņu Clos. PatiesÄ«bā reālu alternatÄ«vu Å”obrÄ«d nav. Un Clos topoloÄ£ija ir diezgan laba, pat ja salÄ«dzina ar dažādām progresÄ«vām topoloÄ£ijām, kas Å”obrÄ«d ir vairāk akadēmisko intereÅ”u jomā, ja mums ir lieli radix slēdži.

Kā mērogot datu centrus. Yandex pārskats

Kā aptuveni ir strukturēts daudzlÄ«meņu Clos tÄ«kls un kā tajā tiek saukti dažādie elementi? Pirmkārt, vējÅ” pacēlās, lai orientētos kur ziemeļi, kur dienvidi, kur austrumi, kur rietumi. Šāda veida tÄ«klus parasti veido tie, kuriem ir ļoti liela rietumu-austrumu satiksme. Kas attiecas uz atlikuÅ”ajiem elementiem, augÅ”pusē ir virtuāls slēdzis, kas samontēts no mazākiem slēdžiem. Å Ä« ir galvenā Clos tÄ«klu rekursÄ«vās bÅ«vniecÄ«bas ideja. Mēs ņemam elementus ar kaut kādu radiksi un savienojam tos, lai to, ko mēs iegÅ«stam, varētu uzskatÄ«t par slēdzi ar lielāku radiksi. Ja nepiecieÅ”ams vēl vairāk, procedÅ«ru var atkārtot.

GadÄ«jumos, piemēram, ar divu lÄ«meņu Clos, kad ir iespējams skaidri noteikt komponentus, kas manā diagrammā ir vertikāli, tos parasti sauc par plaknēm. Ja mēs uzbÅ«vētu Clos ar trÄ«s lÄ«meņu mugurkaula slēdžiem (kas visi nav robežslēdži vai ToR slēdži un tiek izmantoti tikai tranzÄ«tam), tad lidmaŔīnas izskatÄ«tos sarežģītākas; divu lÄ«meņu slēdži izskatās tieÅ”i Ŕādi. Mēs saucam ToR vai lapu slēdžu bloku un ar tiem saistÄ«tos pirmā lÄ«meņa mugurkaula slēdžus par Pod. Spine-1 lÄ«meņa mugurkaula slēdži Pod augÅ”pusē ir Pod augÅ”daļa, Pod augÅ”daļa. Slēdži, kas atrodas visas rÅ«pnÄ«cas augÅ”pusē, ir rÅ«pnÄ«cas augŔējais slānis, auduma augÅ”daļa.

Kā mērogot datu centrus. Yandex pārskats

Protams, rodas jautājums: Clos tÄ«kli ir bÅ«vēti jau kādu laiku, pati ideja kopumā nāk no klasiskās telefonijas, TDM tÄ«klu laikiem. VarbÅ«t ir parādÄ«jies kas labāks, varbÅ«t kaut ko var izdarÄ«t labāk? Jā un nē. Teorētiski jā, praktiski tuvākajā laikā noteikti nē. Tā kā ir vairākas interesantas topoloÄ£ijas, dažas no tām tiek izmantotas pat ražoÅ”anā, piemēram, Dragonfly tiek izmantots HPC lietojumprogrammās; Ir arÄ« interesantas topoloÄ£ijas, piemēram, Xpander, FatClique, Jellyfish. Ja nesen aplÅ«kojat ziņojumus konferencēs, piemēram, SIGCOMM vai NSDI, jÅ«s varat atrast diezgan lielu skaitu darbu par alternatÄ«vām topoloÄ£ijām, kurām ir labākas Ä«paŔības (vienas vai citas) nekā Clos.

Bet visām Ŕīm topoloÄ£ijām ir viena interesanta Ä«paŔība. Tas novērÅ” to ievieÅ”anu datu centru tÄ«klos, kurus mēs cenÅ”amies veidot uz preču aparatÅ«ras un kas maksā diezgan saprātÄ«gu naudu. Visās Å”ajās alternatÄ«vajās topoloÄ£ijās lielākā daļa joslas platuma diemžēl nav pieejama pa Ä«sāko ceļu. Tāpēc mēs uzreiz zaudējam iespēju izmantot tradicionālo vadÄ«bas plakni.

Teorētiski problēmas risinājums ir zināms. Tās ir, piemēram, saites stāvokļa modifikācijas, izmantojot k-Ä«sāko ceļu, taču, atkal, nav tādu protokolu, kas bÅ«tu ieviesti ražoÅ”anā un plaÅ”i pieejami iekārtās.

Turklāt, tā kā lielākā daļa jaudas nav pieejama, izmantojot Ä«sākos ceļus, mums ir jāmaina ne tikai vadÄ«bas plakne, lai atlasÄ«tu visus Å”os ceļus (un, starp citu, tas ir ievērojami lielāks stāvoklis vadÄ«bas plaknē). Mums joprojām ir jāmaina pārsÅ«tÄ«Å”anas plakne, un, kā likums, ir nepiecieÅ”amas vismaz divas papildu funkcijas. Tā ir iespēja vienreiz pieņemt visus lēmumus par pakeÅ”u pārsÅ«tÄ«Å”anu, piemēram, resursdatorā. Faktiski tā ir avota marÅ”rutÄ“Å”ana, dažreiz literatÅ«rā par starpsavienojumu tÄ«kliem to sauc par visiem uzreiz pārsÅ«tÄ«Å”anas lēmumiem. Un adaptÄ«vā marÅ”rutÄ“Å”ana ir funkcija, kas mums ir nepiecieÅ”ama tÄ«kla elementos, kas, piemēram, ir atkarÄ«ga no tā, ka mēs izvēlamies nākamo lēcienu, pamatojoties uz informāciju par vismazāko slodzi rindā. Piemēram, ir iespējamas arÄ« citas iespējas.

LÄ«dz ar to virziens ir interesants, bet diemžēl Å”obrÄ«d to nevaram pielietot.

Kā mērogot datu centrus. Yandex pārskats

Labi, mēs izvēlējāmies Clos loģisko topoloģiju. Kā mēs to mērogosim? Apskatīsim, kā tas darbojas un ko var darīt.

Kā mērogot datu centrus. Yandex pārskats

Clos tīklā ir divi galvenie parametri, kurus mēs varam kaut kā mainīt un iegūt noteiktus rezultātus: elementu radikss un līmeņu skaits tīklā. Man ir shematiska diagramma, kā abi ietekmē izmēru. Ideālā gadījumā mēs apvienojam abus.

Kā mērogot datu centrus. Yandex pārskats

Redzams, ka Clos tÄ«kla gala platums ir visu dienvidu radiksa mugurkaula slēdžu lÄ«meņu reizinājums, cik saiÅ”u mums ir uz leju, kā tas atzarojas. Tādā veidā mēs mērogojam tÄ«kla lielumu.

Kā mērogot datu centrus. Yandex pārskats

AttiecÄ«bā uz jaudu, it Ä«paÅ”i uz ToR slēdžiem, ir divas mērogoÅ”anas iespējas. Vai nu mēs varam, saglabājot vispārējo topoloÄ£iju, izmantot ātrākas saites, vai arÄ« varam pievienot vairāk plakņu.

Ja paskatās uz Clos tÄ«kla paplaÅ”ināto versiju (labajā apakŔējā stÅ«rÄ«) un atgriezÄ«sies pie Ŕī attēla ar Clos tÄ«klu zemāk...

Kā mērogot datu centrus. Yandex pārskats

... tad Ŕī ir tieŔi tāda pati topoloģija, bet uz Ŕī slaida tā ir sabrukusi kompaktāk un rūpnīcas plaknes ir uzliktas viena uz otru. Tas ir tas pats.

Kā mērogot datu centrus. Yandex pārskats

Kā Clos tÄ«kla mērogoÅ”ana izskatās skaitļos? Å eit es sniedzu datus par to, kādu maksimālo tÄ«kla platumu var iegÅ«t, cik maksimālo plauktu, ToR slēdžu vai lapu slēdžu skaitu, ja tie nav statÄ«vi, mēs varam iegÅ«t atkarÄ«bā no tā, kādu slēdžu radiksi izmantojam mugurkaula lÄ«meņiem, un cik lÄ«meņus mēs izmantojam.

LÅ«k, cik daudz plauktu mums var bÅ«t, cik serveru un aptuveni cik tas viss var patērēt, pamatojoties uz 20 kW uz vienu statÄ«vu. Nedaudz agrāk es minēju, ka mēs tiecamies uz aptuveni 100 tÅ«kstoÅ”u serveru klastera lielumu.

Var redzēt, ka visā Å”ajā dizainā interesē divarpus iespējas. Ir iespēja ar diviem slāņiem muguriņiem un 64 portu slēdžiem, kas nedaudz atpaliek. Pēc tam ir lieliski piemērotas iespējas 128 portu (ar radix 128) mugurkaula slēdžiem ar diviem lÄ«meņiem vai slēdžiem ar radix 32 ar trim lÄ«meņiem. Un visos gadÄ«jumos, kur ir vairāk radiksi un vairāk slāņu, var izveidot ļoti lielu tÄ«klu, bet, ja skatās uz paredzamo patēriņu, tad tipiski ir gigavati. Kabeli var ievilkt, bet diez vai vienā vietā tik daudz elektrÄ«bas dabÅ«sim. AplÅ«kojot statistiku un publiskos datus par datu centriem, jÅ«s varat atrast ļoti maz datu centru, kuru aptuvenā jauda ir lielāka par 150 MW. Lielākie parasti ir datu centru pilsētiņas, vairāki lieli datu centri, kas atrodas diezgan tuvu viens otram.

Ir vēl viens svarÄ«gs parametrs. Ja skatāties uz kreiso kolonnu, tur ir norādÄ«ts izmantojamais joslas platums. Ir viegli redzēt, ka Clos tÄ«klā ievērojama daļa portu tiek izmantoti, lai savienotu slēdžus viens ar otru. Izmantojamais joslas platums, noderÄ«ga josla, ir kaut kas tāds, ko var pieŔķirt ārpusē, serveru virzienā. Protams, es runāju par nosacÄ«tajiem portiem un konkrēti par joslu. Parasti saites tÄ«klā ir ātrākas nekā saites uz serveriem, taču uz vienu joslas platuma vienÄ«bu, cik vien mēs varam to nosÅ«tÄ«t uz mÅ«su servera aprÄ«kojumu, paŔā tÄ«klā joprojām ir zināms joslas platums. Un jo vairāk lÄ«meņu mēs izgatavojam, jo ā€‹ā€‹lielākas ir Ŕīs svÄ«tras nodroÅ”ināŔanas Ä«paŔās izmaksas.

Turklāt pat Ŕī papildu josla nav gluži tāda pati. Lai gan laidumi ir Ä«si, mēs varam izmantot kaut ko lÄ«dzÄ«gu DAC (tieŔā savienojuma vara, tas ir, twinax kabeļi) vai daudzmodu optiku, kas maksā pat vairāk vai mazāk saprātÄ«gu naudu. TiklÄ«dz mēs pārejam uz garākiem laidumiem - parasti tā ir viena režīma optika, un Ŕīs papildu joslas platuma izmaksas ievērojami palielinās.

Un atkal, atgriežoties pie iepriekŔējā slaida, ja mēs izveidojam Clos tÄ«klu bez pārrakstÄ«Å”anās, tad ir viegli apskatÄ«t diagrammu, redzēt, kā tiek veidots tÄ«kls - pievienojot katru mugurkaula slēdžu lÄ«meni, mēs atkārtojam visu joslu, kas bija apakŔā. Plus lÄ«menis - plus tāda pati josla, tāds pats portu skaits slēdžos, kāds bija iepriekŔējā lÄ«menÄ«, un tikpat daudz raiduztvērēju. Tāpēc ir ļoti vēlams samazināt mugurkaula slēdžu lÄ«meņu skaitu.

Pamatojoties uz Å”o attēlu, ir skaidrs, ka mēs patieŔām vēlamies balstÄ«ties uz kaut ko lÄ«dzÄ«gu slēdžiem ar radiksu 128.

Kā mērogot datu centrus. Yandex pārskats

Å eit principā viss ir tas pats, ko es tikko teicu; Å”is ir slaids, kas jāapsver vēlāk.

Kā mērogot datu centrus. Yandex pārskats

Kādas ir iespējas izvēlēties kā Ŕādus slēdžus? Mums ir ļoti patÄ«kama ziņa, ka tagad Ŕādus tÄ«klus beidzot var bÅ«vēt uz vienas mikroshēmas slēdžiem. Un tas ir ļoti forÅ”i, tiem ir daudz jauku funkciju. Piemēram, tiem gandrÄ«z nav iekŔējās struktÅ«ras. Tas nozÄ«mē, ka tie saplÄ«st vieglāk. Viņi lÅ«zt visādi, bet par laimi saplÄ«st pavisam. Moduļu ierÄ«cēs ir liels kļūdu skaits (ļoti nepatÄ«kami), kad no kaimiņu un vadÄ«bas plaknes viedokļa Ŕķiet, ka tas darbojas, bet, piemēram, ir pazudusi daļa auduma un tas nedarbojas ar pilnu jaudu. Un satiksme uz to ir lÄ«dzsvarota, pamatojoties uz to, ka tas ir pilnÄ«bā funkcionāls, un mēs varam tikt pārslogoti.

Vai, piemēram, problēmas rodas ar aizmugurējo plakni, jo modulārās ierÄ«ces iekÅ”pusē ir arÄ« ātrgaitas SerDes - iekÅ”pusē tas ir patieŔām sarežģīti. Vai nu zÄ«mes starp pārsÅ«tÄ«Å”anas elementiem ir sinhronizētas vai nav sinhronizētas. Kopumā jebkura produktÄ«va modulāra ierÄ«ce, kas sastāv no liela skaita elementu, parasti satur to paÅ”u Clos tÄ«klu, taču to ir ļoti grÅ«ti diagnosticēt. Bieži vien pat paÅ”am pārdevējam ir grÅ«ti noteikt diagnozi.

Un tam ir liels skaits atteices scenāriju, kuros ierÄ«ce pasliktinās, bet pilnÄ«bā neizkrÄ«t no topoloÄ£ijas. Tā kā mÅ«su tÄ«kls ir liels, tiek aktÄ«vi izmantota balansÄ“Å”ana starp identiskiem elementiem, tÄ«kls ir ļoti regulārs, tas ir, viens ceļŔ, kurā viss ir kārtÄ«bā, neatŔķiras no otra, mums izdevÄ«gāk ir vienkārÅ”i zaudēt daļu no ierÄ«ces no topoloÄ£ijas, nevis nonākt situācijā, kad dažas no tām it kā darbojas, bet dažas nedarbojas.

Kā mērogot datu centrus. Yandex pārskats

Nākamā jaukā vienas mikroshēmas ierīču iezīme ir tā, ka tās attīstās labāk un ātrāk. Viņiem mēdz būt arī labāka jauda. Ja ņemam lielās saliktās konstrukcijas, kas mums ir uz apļa, tad vienāda ātruma portiem kapacitāte uz statīva vienību ir gandrīz divas reizes lielāka nekā moduļu ierīcēm. Ierīces, kas veidotas ap vienu mikroshēmu, ir ievērojami lētākas nekā modulārās un patērē mazāk enerģijas.

Bet, protams, tam visam ir iemesls, ir arī trūkumi. Pirmkārt, radikss gandrīz vienmēr ir mazāks nekā moduļu ierīcēm. Ja mēs varam iegūt ierīci, kas uzbūvēta ap vienu mikroshēmu ar 128 portiem, tad tagad bez problēmām varam iegūt modulāru ar vairākiem simtiem portu.

Tas ir ievērojami mazāks pārsÅ«tÄ«Å”anas tabulu izmērs un, kā likums, viss, kas saistÄ«ts ar datu plaknes mērogojamÄ«bu. Sekli buferi. Un, kā likums, diezgan ierobežota funkcionalitāte. Bet izrādās, ka, ja jÅ«s zināt Å”os ierobežojumus un savlaicÄ«gi parÅ«pējaties, lai tos apietu vai vienkārÅ”i ņemtu vērā, tad tas nav tik biedējoÅ”i. Fakts, ka radikss ir mazāks, vairs nav problēma ierÄ«cēs ar radix 128, kas beidzot parādÄ«jās nesen; mēs varam veidot divus muguriņu slāņus. Bet joprojām nav iespējams izveidot kaut ko mazāku par diviem, kas mums bÅ«tu interesanti. Ar vienu lÄ«meni tiek iegÅ«tas ļoti mazas kopas. Pat mÅ«su iepriekŔējie dizaini un prasÄ«bas joprojām tos pārsniedza.

PatiesÄ«bā, ja pēkŔņi risinājums ir kaut kur uz robežas, joprojām ir veids, kā mērogot. Tā kā pēdējais (vai pirmais) zemākais lÄ«menis, kurā serveri ir savienoti, ir ToR slēdži vai lapu slēdži, mums nav jāpievieno viens statÄ«vs ar tiem. Tāpēc, ja risinājums atpaliek apmēram uz pusi, varat padomāt par vienkārÅ”u slēdža izmantoÅ”anu ar lielu radiksi zemākajā lÄ«menÄ« un, piemēram, divu vai trÄ«s statÄ«vu savienoÅ”anu vienā slēdžā. Å Ä« ir arÄ« iespēja, tai ir savas izmaksas, taču tas darbojas diezgan labi un var bÅ«t labs risinājums, ja jums ir jāsasniedz apmēram divas reizes lielāks izmērs.

Kā mērogot datu centrus. Yandex pārskats

Rezumējot, mēs balstāmies uz topoloģiju ar diviem muguriņu līmeņiem ar astoņiem rūpnīcas slāņiem.

Kā mērogot datu centrus. Yandex pārskats

Kas notiks ar fiziku? Ä»oti vienkārÅ”i aprēķini. Ja mums ir divu lÄ«meņu muguriņas, tad mums ir tikai trÄ«s slēdžu lÄ«meņi, un mēs sagaidām, ka tÄ«klā bÅ«s trÄ«s kabeļu segmenti: no serveriem lÄ«dz lapu slēdžiem, uz muguru 1, uz muguriņu 2. Iespējas, ko varam lietojums ir - tie ir twinax, multimode, single mode. Un Å”eit mums ir jāapsver, kāda sloksne ir pieejama, cik tas maksās, kādi ir fiziskie izmēri, kādus laidumus mēs varam aptvert un kā mēs uzlabosim.

Izmaksu ziņā visu var sarindot. Twinaxes ir ievērojami lētākas nekā aktÄ«vā optika, lētākas par daudzmodu raiduztvērējiem, ja to ņem uz lidojumu no beigām, nedaudz lētāk nekā 100 gigabitu komutācijas ports. Un, lÅ«dzu, ņemiet vērā, ka tas maksā mazāk nekā viena režīma optika, jo lidojumos, kur nepiecieÅ”ams viens režīms, datu centros vairāku iemeslu dēļ ir lietderÄ«gi izmantot CWDM, savukārt paralēlā viena režīma (PSM) nav Ä«paÅ”i ērti strādāt. ar, ļoti lielas pakas tiek iegÅ«tas Ŕķiedras, un, ja mēs koncentrējamies uz Ŕīm tehnoloÄ£ijām, mēs iegÅ«stam aptuveni Ŕādu cenu hierarhiju.

Vēl viena piezÄ«me: diemžēl nav ļoti iespējams izmantot izjauktus 100 lÄ«dz 4x25 daudzmodu portus. Pateicoties SFP28 raiduztvērēju dizaina iezÄ«mēm, tas nav daudz lētāks par 28 Gbit QSFP100. Un Ŕī daudzrežīmu demontāža nedarbojas ļoti labi.

Vēl viens ierobežojums ir tāds, ka skaitļoÅ”anas klasteru lieluma un serveru skaita dēļ mÅ«su datu centri izrādās fiziski lieli. Tas nozÄ«mē, ka vismaz viens lidojums bÅ«s jāveic ar singlemod. Atkal, Pods fiziskā izmēra dēļ nebÅ«s iespējams palaist divus twinax (vara kabeļus) laidumus.

Rezultātā, ja mēs optimizējam cenu un ņemam vērā Ŕī dizaina Ä£eometriju, mēs iegÅ«stam vienu twinax laidumu, vienu daudzmodu diapazonu un vienu vienmodu diapazonu, izmantojot CWDM. Tas ņem vērā iespējamos jaunināŔanas ceļus.

Kā mērogot datu centrus. Yandex pārskats

Tā tas izskatās pēdējā laikā, kurp virzāmies un kas ir iespējams. Vismaz ir skaidrs, kā virzÄ«ties uz 50 gigabitu SerDes gan daudzmodiem, gan vienmodiem. Turklāt, ja paskatās, kas ir vienmoda raiduztvērējos tagad un nākotnē 400G, bieži pat tad, kad no elektriskās puses pienāk 50G SerDes, 100 Gbps uz joslu jau var aiziet uz optiku. Tāpēc ir pilnÄ«gi iespējams, ka tā vietā, lai pārietu uz 50, notiks pāreja uz 100 Gigabit SerDes un 100 Gbps uz joslu, jo saskaņā ar daudzu pārdevēju solÄ«jumiem to pieejamÄ«ba ir gaidāma diezgan drÄ«z. Laika posms, kad 50G SerDes bija ātrākie, Ŕķiet, nebÅ«s Ä«paÅ”i ilgs, jo pirmie 100G SerDe eksemplāri iznāk gandrÄ«z nākamgad. Un pēc kāda laika pēc tam tie, iespējams, bÅ«s saprātÄ«gas naudas vērti.

Kā mērogot datu centrus. Yandex pārskats

Vēl viena nianse par fizikas izvēli. Principā mēs jau varam izmantot 400 vai 200 Gigabit portus, izmantojot 50G SerDes. Bet izrādās, ka tam nav lielas jēgas, jo, kā jau teicu iepriekÅ”, mēs vēlamies diezgan lielu slēdžu radiksi, protams, saprāta robežās. Gribam 128. Un ja mums ir ierobežota čipu ietilpÄ«ba un paaugstinām linka ātrumu, tad radikss dabiski samazinās, brÄ«numu nav.

Un mēs varam palielināt kopējo jaudu, izmantojot lidmaŔīnas, un nav Ä«paÅ”u izmaksu, mēs varam pievienot lidmaŔīnu skaitu. Un, ja pazaudēsim radix, nāksies ieviest papildu lÄ«meni, tāpēc paÅ”reizējā situācijā ar paÅ”reizējo maksimālo pieejamo jaudu uz vienu mikroshēmu, izrādās, ka efektÄ«vāk ir izmantot 100 gigabitu portus, jo tie ļauj jums lai iegÅ«tu lielāku radiksu.

Kā mērogot datu centrus. Yandex pārskats

Nākamais jautājums ir par to, kā tiek organizēta fizika, bet no kabeļu infrastruktÅ«ras viedokļa. Izrādās, tas ir organizēts diezgan jocÄ«gi. Kabeļi starp lapu slēdžiem un pirmā lÄ«meņa muguriņām - tur nav daudz saiÅ”u, viss ir uzbÅ«vēts salÄ«dzinoÅ”i vienkārÅ”i. Bet, ja mēs ņemam vienu plakni, iekŔā notiek tas, ka mums ir jāsavieno visi pirmā lÄ«meņa muguriņas ar visiem otrā lÄ«meņa muguriņiem.

Turklāt, kā likums, ir dažas vēlmes, kā tam vajadzētu izskatÄ«ties datu centra iekÅ”ienē. Piemēram, mēs ļoti vēlējāmies apvienot kabeļus saiŔķī un savilkt tos tā, lai viens augsta blÄ«vuma plākstera panelis pilnÄ«bā ietilptu vienā plākstera panelÄ«, lai garumu ziņā nebÅ«tu zoodārza. Mums izdevās atrisināt Å”o problēmu. Ja sākotnēji paskatās uz loÄ£isko topoloÄ£iju, var redzēt, ka plaknes ir neatkarÄ«gas, katru plakni var uzbÅ«vēt atseviŔķi. Bet, kad mēs pievienojam Ŕādu komplektÄ“Å”anu un vēlamies visu ielāpu paneli ievilkt ielāpu panelÄ«, mums ir jāsajauc dažādas plaknes vienā komplektā un jāievieÅ” starpstruktÅ«ra optisku Ŕķērssavienojumu veidā, lai tās pārsaiņotu no tā, kā tās tika saliktas. vienā segmentā , kā tie tiks apkopoti citā segmentā. Pateicoties tam, mēs iegÅ«stam jauku funkciju: visa sarežģītā pārslēgÅ”ana nepārsniedz statÄ«vus. Kad vajag kaut ko ļoti stipri savÄ«t, ā€œatlocÄ«t plaknesā€, kā to dažkārt sauc Clos tÄ«klos, tas viss ir koncentrēts vienā statÄ«vā. Mums nav ļoti izjauktu, lÄ«dz pat atseviŔķām saitēm, pārslēgÅ”anās starp statÄ«viem.

Kā mērogot datu centrus. Yandex pārskats

Tā tas izskatās no kabeļu infrastruktÅ«ras loÄ£iskās organizācijas viedokļa. Attēlā pa kreisi uz daudzkrāsainiem blokiem ir attēloti pirmā lÄ«meņa mugurkaula slēdžu bloki, katrs astoņi gabali, un četri no tiem nākoÅ”ie kabeļu saiŔķi, kas iet un krustojas ar saiŔķiem, kas nāk no mugurkaula-2 slēdžu blokiem. .

Mazie kvadrāti norāda krustojumus. AugŔējā kreisajā stÅ«rÄ« ir katra Ŕāda krustojuma sadalÄ«jums, patiesÄ«bā tas ir 512 x 512 portu Ŕķērssavienojuma modulis, kas pārpako kabeļus tā, lai tie pilnÄ«bā nonāktu vienā statÄ«vā, kur ir tikai viena mugurkaula 2 plakne. Un labajā pusē Ŕī attēla skenÄ“Å”ana ir nedaudz detalizētāka attiecÄ«bā uz vairākiem podiem mugurkaula-1 lÄ«menÄ« un to, kā tas ir iesaiņots Ŕķērssavienojumā, kā tas attiecas uz mugurkaula-2 lÄ«meni.

Kā mērogot datu centrus. Yandex pārskats

Tas izskatās Ŕādi. Vēl nav pilnÄ«bā samontēts spine-2 statÄ«vs (kreisajā pusē) un Ŕķērssavienojuma statÄ«vs. Diemžēl tur nav daudz ko redzēt. Visa Ŕī struktÅ«ra Å”obrÄ«d tiek izvietota vienā no mÅ«su lielajiem datu centriem, kas tiek paplaÅ”ināts. Tas ir nepabeigts darbs, tas izskatÄ«sies skaistāk, tas bÅ«s labāk aizpildÄ«ts.

Kā mērogot datu centrus. Yandex pārskats

SvarÄ«gs jautājums: mēs izvēlējāmies loÄ£isko topoloÄ£iju un izveidojām fiziku. Kas notiks ar vadÄ«bas plakni? Tas ir diezgan labi zināms no darbÄ«bas pieredzes, ir vairāki ziņojumi, ka saiÅ”u stāvokļa protokoli ir labi, ar tiem ir patÄ«kami strādāt, bet diemžēl tie nav labi mērogoti blÄ«vi savienotā topoloÄ£ijā. Un ir viens galvenais faktors, kas to novērÅ” - Ŕādi notiek applÅ«Å”ana saites stāvokļa protokolos. Ja jÅ«s vienkārÅ”i izmantojat applÅ«Å”anas algoritmu un paskatās, kā ir strukturēts mÅ«su tÄ«kls, jÅ«s varat redzēt, ka katrā solÄ« bÅ«s ļoti liels izplÅ«dums, un tas vienkārÅ”i pārpludinās vadÄ«bas plakni ar atjauninājumiem. Konkrēti, Ŕādas topoloÄ£ijas ļoti slikti sajaucas ar tradicionālo applÅ«Å”anas algoritmu saites stāvokļa protokolos.

Izvēle ir izmantot BGP. Kā to pareizi sagatavot, ir aprakstÄ«ts RFC 7938 par BGP izmantoÅ”anu lielos datu centros. Pamatidejas ir vienkārÅ”as: minimālais prefiksu skaits uz vienu resursdatoru un parasti minimālais prefiksu skaits tÄ«klā, ja iespējams, izmantojiet apkopoÅ”anu un apturiet ceļu meklÄ“Å”anu. Mēs vēlamies ļoti rÅ«pÄ«gu, ļoti kontrolētu atjauninājumu izplatÄ«Å”anu, ko sauc par brÄ«vu ieleju. Mēs vēlamies, lai atjauninājumi tiktu izvietoti tieÅ”i vienreiz, kad tie iziet cauri tÄ«klam. Ja tie rodas apakŔā, tie iet uz augÅ”u, izvērÅ”oties ne vairāk kā vienu reizi. Nevajadzētu bÅ«t zigzagiem. Zigzagi ir ļoti slikti.

Lai to izdarÄ«tu, mēs izmantojam dizainu, kas ir pietiekami vienkārÅ”s, lai izmantotu pamatā esoÅ”os BGP mehānismus. Tas nozÄ«mē, ka mēs izmantojam eBGP, kas darbojas vietējā saitē, un autonomās sistēmas tiek pieŔķirtas Ŕādi: autonoma sistēma uz ToR, autonoma sistēma visam viena Pod spine-1 slēdžu blokam un vispārēja autonoma sistēma visā augÅ”pusē. no Auduma. Nav grÅ«ti paskatÄ«ties un redzēt, ka pat parastā BGP darbÄ«ba nodroÅ”ina mums vajadzÄ«go atjauninājumu izplatÄ«Å”anu.

Kā mērogot datu centrus. Yandex pārskats

Protams, adresācija un adreÅ”u apkopoÅ”ana ir jāveido tā, lai tā bÅ«tu savietojama ar veidu, kā tiek veidota marÅ”rutÄ“Å”ana, lai tā nodroÅ”inātu vadÄ«bas plaknes stabilitāti. L3 adresÄ“Å”ana transportā ir piesaistÄ«ta topoloÄ£ijai, jo bez tās nav iespējams panākt agregāciju, bez tā atseviŔķas adreses iezagsies marÅ”rutÄ“Å”anas sistēmā. Un vēl viena lieta ir tāda, ka agregācija diemžēl ne pārāk labi sajaucas ar daudzceļu, jo, kad mums ir daudzceļŔ un mums ir agregācija, viss ir kārtÄ«bā, kad viss tÄ«kls ir vesels, tajā nav nekādu kļūmju. Diemžēl, tiklÄ«dz tÄ«klā parādās kļūmes un topoloÄ£ijas simetrija zÅ«d, mēs varam nonākt lÄ«dz punktam, no kura tika paziņots par vienÄ«bu, no kuras mēs nevaram tikt tālāk uz vietu, kur mums jāiet. Tāpēc vislabāk ir apkopot tur, kur vairs nav vairāku ceļu, mÅ«su gadÄ«jumā tie ir ToR slēdži.

Kā mērogot datu centrus. Yandex pārskats

Faktiski ir iespējams apkopot, bet uzmanÄ«gi. Ja mēs varam veikt kontrolētu sadalÄ«Å”anu, kad rodas tÄ«kla kļūmes. Bet tas ir diezgan sarežģīts uzdevums, mēs pat domājām, vai to bÅ«tu iespējams izdarÄ«t, vai ir iespējams pievienot papildu automatizāciju un ierobežotu stāvokļu maŔīnas, kas pareizi iedarbinātu BGP, lai iegÅ«tu vēlamo uzvedÄ«bu. Diemžēl stÅ«ra lietu apstrāde ir ļoti nepārprotama un sarežģīta, un Å”o uzdevumu nevar labi atrisināt, pievienojot BGP ārējos pielikumus.

Ä»oti interesants darbs Å”ajā sakarā ir veikts RIFT protokola ietvaros, par ko tiks runāts nākamajā ziņojumā.

Kā mērogot datu centrus. Yandex pārskats

Vēl viena svarīga lieta ir tas, kā datu plaknes mērogojas blīvās topoloģijās, kur mums ir liels skaits alternatīvu ceļu. Šajā gadījumā tiek izmantotas vairākas papildu datu struktūras: ECMP grupas, kas savukārt apraksta Next Hop grupas.

Normāli strādājoŔā tÄ«klā bez kļūmēm, kad ejam uz augÅ”u pa Clos topoloÄ£iju, pietiek izmantot tikai vienu grupu, jo pēc noklusējuma ir aprakstÄ«ts viss, kas nav lokāls, mēs varam tikt uz augÅ”u. Kad mēs ejam no augÅ”as uz leju uz dienvidiem, tad visi ceļi nav ECMP, tie ir viena ceļa ceļi. Viss ir kārtÄ«bā. Problēma ir tāda, ka klasiskās Clos topoloÄ£ijas Ä«patnÄ«ba ir tāda, ka, ja mēs skatāmies uz auduma augÅ”daļu, uz jebkuru elementu, ir tikai viens ceļŔ uz jebkuru zemāk esoÅ”o elementu. Ja Å”ajā ceļā rodas kļūmes, tad Å”is konkrētais elements rÅ«pnÄ«cas augÅ”pusē kļūst nederÄ«gs tieÅ”i tiem prefiksiem, kas atrodas aiz salauztā ceļa. Bet pārējiem tas ir spēkā, un mums ir jāparsē ECMP grupas un jāievieÅ” jauns stāvoklis.

Kā mÅ«sdienu ierÄ«cēs izskatās datu plaknes mērogojamÄ«ba? Ja taisām LPM (garāko prefiksu sakritÄ«bu), viss ir diezgan labi, virs 100k prefiksu. Ja runājam par Next Hop grupām, tad viss ir sliktāk, 2-4 tÅ«kst. Ja mēs runājam par tabulu, kurā ir Next Hops (vai blakus esoÅ”o) apraksts, tad tas ir kaut kur no 16 k lÄ«dz 64 k. Un tas var kļūt par problēmu. Un Å”eit mēs nonākam pie interesantas novirzes: kas notika ar MPLS datu centros? Principā mēs to gribējām darÄ«t.

Kā mērogot datu centrus. Yandex pārskats

Notika divas lietas. Mēs veicām mikrosegmentÄ“Å”anu saimniekdatoros; mums vairs nebija nepiecieÅ”ams to darÄ«t tÄ«klā. Tas nebija Ä«paÅ”i labs ar dažādu pārdevēju atbalstu un vēl jo vairāk ar atvērtām implementācijām baltās kastēs ar MPLS. Un MPLS, vismaz tās tradicionālās implementācijas, diemžēl ļoti slikti apvienojas ar ECMP. Un tāpēc.

Kā mērogot datu centrus. Yandex pārskats

Šādi izskatās ECMP pārsÅ«tÄ«Å”anas struktÅ«ra IP. Liels skaits prefiksu var izmantot vienu un to paÅ”u grupu un vienu un to paÅ”u Next Hops bloku (vai blakus esoŔās vietas, to dažādās dokumentācijās dažādām ierÄ«cēm var saukt atŔķirÄ«gi). Lieta tāda, ka tas ir aprakstÄ«ts kā izejoÅ”ais ports un uz ko pārrakstÄ«t MAC adresi, lai nokļūtu pareizajā Next Hop. AttiecÄ«bā uz IP viss izskatās vienkārÅ”i, jÅ«s varat izmantot ļoti lielu skaitu prefiksu vienai grupai, tam paÅ”am Next Hops blokam.

Kā mērogot datu centrus. Yandex pārskats

Klasiskā MPLS arhitektÅ«ra nozÄ«mē, ka atkarÄ«bā no izejoŔā interfeisa etiÄ·eti var pārrakstÄ«t uz dažādām vērtÄ«bām. Tāpēc mums ir jāsaglabā grupa un Next Hops bloks katrai ievades etiÄ·etei. Un tas, diemžēl, nav mērogs.

Ir viegli redzēt, ka mÅ«su dizainā mums bija nepiecieÅ”ami aptuveni 4000 ToR slēdži, maksimālais platums bija 64 ECMP ceļi, ja mēs virzāmies prom no mugurkaula-1 uz mugurkaula-2. Mēs tik tikko iekļūstam vienā ECMP grupu tabulā, ja pazÅ«d tikai viens prefikss ar ToR, un mēs vispār neiekļūstam tabulā Next Hops.

Kā mērogot datu centrus. Yandex pārskats

Tas nav bezcerÄ«gi, jo tādās arhitektÅ«rās kā Segment Routing ir globālas etiÄ·etes. Formāli bÅ«tu iespējams atkal sabrukt visus Å”os Next Hops blokus. Lai to izdarÄ«tu, nepiecieÅ”ama aizstājējzÄ«mes tipa darbÄ«ba: paņemiet etiÄ·eti un pārrakstiet to uz to paÅ”u bez noteiktas vērtÄ«bas. Bet diemžēl pieejamajās implementācijās tas nav Ä«paÅ”i klāt.

Un, visbeidzot, datu centrā ir jāieved ārējā trafika. Kā to izdarÄ«t? IepriekÅ” satiksme tika ievadÄ«ta Clos tÄ«klā no augÅ”as. Tas nozÄ«mē, ka bija malu marÅ”rutētāji, kas savienojās ar visām ierÄ«cēm auduma augÅ”daļā. Å is risinājums diezgan labi darbojas maziem un vidējiem izmēriem. Diemžēl, lai Ŕādā veidā simetriski nosÅ«tÄ«tu trafiku visam tÄ«klam, mums vienlaicÄ«gi ir jānonāk pie visiem auduma augÅ”daļas elementiem, un, kad to ir vairāk nekā simts, izrādās, ka mums ir nepiecieÅ”ams arÄ« liels radix uz malas marÅ”rutētājiem. Kopumā tas maksā naudu, jo malu marÅ”rutētāji ir funkcionālāki, porti uz tiem bÅ«s dārgāki, un dizains nav Ä«paÅ”i skaists.

Vēl viena iespēja ir sākt Ŕādu satiksmi no apakÅ”as. Ir viegli pārbaudÄ«t, vai Clos topoloÄ£ija ir veidota tā, ka satiksme, kas nāk no apakÅ”as, tas ir, no ToR puses, tiek vienmērÄ«gi sadalÄ«ta pa lÄ«meņiem visā auduma augÅ”daļā divās iterācijās, noslogojot visu tÄ«klu. Tāpēc mēs ievieÅ”am Ä«paÅ”u Pod veidu Edge Pod, kas nodroÅ”ina ārējo savienojumu.

Ir vēl viens variants. To dara, piemēram, Facebook. Viņi to sauc par auduma apkopotāju vai HGRID. Tiek ieviests papildu mugurkaula lÄ«menis, lai savienotu vairākus datu centrus. Å is dizains ir iespējams, ja mums nav papildu funkciju vai iekapsulÄ“Å”anas izmaiņu saskarnēs. Ja tie ir papildu saskares punkti, tas ir grÅ«ti. Parasti ir vairāk funkciju un sava veida membrāna, kas atdala dažādas datu centra daļas. Nav jēgas tādu membrānu taisÄ«t lielu, bet, ja tā nez kādēļ tieŔām ir vajadzÄ«ga, tad ir jēga apsvērt iespēju to atņemt, taisÄ«t pēc iespējas platāku un nodot saimniekiem. To dara, piemēram, daudzi mākoņu operatori. Viņiem ir pārklājumi, viņi sākas no saimniekiem.

Kā mērogot datu centrus. Yandex pārskats

Kādas attÄ«stÄ«bas iespējas mēs redzam? Pirmkārt, uzlabojot atbalstu CI/CD konveijeram. Mēs vēlamies lidot tā, kā mēs pārbaudām, un pārbaudÄ«t, kā mēs lidojam. Tas neizdodas Ä«paÅ”i labi, jo infrastruktÅ«ra ir liela un to dublēt testiem nav iespējams. Jums ir jāsaprot, kā ieviest testÄ“Å”anas elementus ražoÅ”anas infrastruktÅ«rā, to neizlaižot.

Labāka instrumentācija un labāka uzraudzība gandrīz nekad nav lieka. Viss jautājums ir līdzsvars starp centieniem un atdevi. Ja varat to pievienot ar saprātīgu piepūli, ļoti labi.

Atvērtās operētājsistēmas tÄ«kla ierÄ«cēm. Labāki protokoli un labākas marÅ”rutÄ“Å”anas sistēmas, piemēram, RIFT. Ir nepiecieÅ”ami arÄ« pētÄ«jumi par labāku sastrēgumu kontroles shēmu izmantoÅ”anu un, iespējams, vismaz dažos punktos RDMA atbalsta ievieÅ”anu klasterÄ«.

Skatoties tālākā nākotnē, mums ir vajadzīgas uzlabotas topoloģijas un, iespējams, tīkli, kas patērē mazāk pieskaitāmās izmaksas. No jaunākajām lietām nesen ir publicētas publikācijas par auduma tehnoloģiju HPC Cray Slingshot, kas ir balstīta uz preču Ethernet, bet ar iespēju izmantot daudz īsākas galvenes. Tā rezultātā tiek samazinātas pieskaitāmās izmaksas.

Kā mērogot datu centrus. Yandex pārskats

Visam jābÅ«t pēc iespējas vienkārŔākam, bet ne vienkārŔākam. SarežģītÄ«ba ir mērogojamÄ«bas ienaidnieks. VienkārŔība un regulāras struktÅ«ras ir mÅ«su draugi. Ja kaut kur varat veikt mērogoÅ”anu, dariet to. Un vispār tagad ir lieliski iesaistÄ«ties tÄ«kla tehnoloÄ£ijās. Notiek daudz interesantu lietu. Paldies.

Avots: www.habr.com

Pievieno komentāru