Ne kemi zhvilluar një dizajn të rrjetit të qendrës së të dhënave që lejon vendosjen e grupimeve kompjuterike më të mëdha se 100 mijë serverë me një gjerësi bande të përgjysmimit maksimal prej mbi një petabajt për sekondë.
Nga raporti i Dmitry Afanasyev do të mësoni për parimet themelore të dizajnit të ri, topologjitë e shkallëzimit, problemet që lindin me këtë, opsionet për zgjidhjen e tyre, veçoritë e drejtimit dhe shkallëzimit të funksioneve të planit përcjellës të pajisjeve moderne të rrjetit në "lidhje të dendur" topologjitë me një numër të madh rrugësh ECMP. Përveç kësaj, Dima foli shkurtimisht për organizimin e lidhjes së jashtme, shtresën fizike, sistemin e kabllove dhe mënyrat për të rritur më tej kapacitetin.
- Mirëdita të gjithëve! Emri im është Dmitry Afanasyev, unë jam një arkitekt rrjeti në Yandex dhe kryesisht projektoj rrjetet e qendrave të të dhënave.
Historia ime do të jetë në lidhje me rrjetin e përditësuar të qendrave të të dhënave Yandex. Është shumë një evolucion i dizajnit që kishim, por në të njëjtën kohë ka disa elementë të rinj. Ky është një prezantim i përgjithshëm sepse kishte shumë informacione për t'u paketuar në një sasi të vogël kohe. Ne do të fillojmë duke zgjedhur një topologji logjike. Më pas do të ketë një përmbledhje të planit të kontrollit dhe problemet me shkallëzimin e planit të të dhënave, një zgjedhje se çfarë do të ndodhë në nivelin fizik dhe do të shikojmë disa veçori të pajisjeve. Le të prekim pak se çfarë po ndodh në një qendër të dhënash me MPLS, për të cilën folëm disa kohë më parë.
Pra, çfarë është Yandex për sa i përket ngarkesave dhe shërbimeve? Yandex është një hipershkallues tipik. Nëse shikojmë përdoruesit, ne kryesisht përpunojmë kërkesat e përdoruesve. Gjithashtu shërbime të ndryshme streaming dhe transferim të dhënash, sepse kemi edhe shërbime ruajtjeje. Nëse më afër backend-it, atëherë ngarkesat dhe shërbimet e infrastrukturës shfaqen atje, të tilla si ruajtja e objekteve të shpërndara, përsëritja e të dhënave dhe, natyrisht, radhët e vazhdueshme. Një nga llojet kryesore të ngarkesave të punës është MapReduce dhe sisteme të ngjashme, përpunimi i transmetimit, mësimi i makinerive, etj.
Si është infrastruktura në krye të së cilës ndodh e gjithë kjo? Përsëri, ne jemi një hipershkallëzues mjaft tipik, megjithëse jemi ndoshta pak më afër anës më të vogël hipershkallëzuese të spektrit. Por ne i kemi të gjitha atributet. Ne përdorim pajisje të mallrave dhe shkallëzim horizontal kudo që është e mundur. Ne kemi bashkim të plotë të burimeve: ne nuk punojmë me makina individuale, rafte individuale, por i kombinojmë ato në një grup të madh burimesh të këmbyeshme me disa shërbime shtesë që kanë të bëjnë me planifikimin dhe shpërndarjen, dhe punojmë me të gjithë këtë grup.
Pra, ne kemi nivelin tjetër - sistemin operativ në nivelin e grupit kompjuterik. Është shumë e rëndësishme që ne të kontrollojmë plotësisht grumbullin e teknologjisë që përdorim. Ne kontrollojmë pikat përfundimtare (host-et), rrjetin dhe grumbullin e softuerit.
Ne kemi disa qendra të mëdha të të dhënave në Rusi dhe jashtë saj. Ata janë të bashkuar nga një shtyllë kurrizore që përdor teknologjinë MPLS. Infrastruktura jonë e brendshme është pothuajse tërësisht e ndërtuar në IPv6, por meqenëse ne duhet të shërbejmë trafikun e jashtëm që ende vjen kryesisht përmes IPv4, ne duhet disi të dorëzojmë kërkesat që vijnë përmes IPv4 te serverët frontend dhe pak më shumë të shkojmë te IPv4- Interneti i jashtëm - për shembull, për indeksimin.
Përsëritjet e fundit të modeleve të rrjetit të qendrave të të dhënave kanë përdorur topologji Clos me shumë shtresa dhe janë vetëm L3. U larguam nga L2 pak kohë më parë dhe morëm një psherëtimë të lehtësuar. Së fundi, infrastruktura jonë përfshin qindra mijëra instanca kompjuterike (server). Madhësia maksimale e grupit disa kohë më parë ishte rreth 10 mijë serverë. Kjo është kryesisht për shkak të mënyrës se si mund të funksionojnë të njëjtat sisteme operative të nivelit të grupimit, planifikuesit, shpërndarja e burimeve, etj.. Meqenëse përparimi ka ndodhur në anën e softuerit të infrastrukturës, madhësia e synuar tani është rreth 100 mijë serverë në një grup kompjuterik, dhe Ne kemi një detyrë - të jemi në gjendje të ndërtojmë fabrika rrjeti që lejojnë bashkimin efikas të burimeve në një grup të tillë.
Çfarë duam nga një rrjet qendrash të dhënash? Para së gjithash, ka shumë gjerësi bande të lirë dhe të shpërndarë në mënyrë të barabartë. Sepse rrjeti është shtylla kurrizore përmes së cilës ne mund të bashkojmë burimet. Madhësia e re e synuar është rreth 100 mijë serverë në një grup.
Ne gjithashtu, natyrisht, duam një plan kontrolli të shkallëzuar dhe të qëndrueshëm, sepse në një infrastrukturë kaq të madhe lindin shumë dhimbje koke edhe nga ngjarje thjesht të rastësishme, dhe ne nuk duam që avioni i kontrollit të na sjellë dhimbje koke gjithashtu. Në të njëjtën kohë, ne duam të minimizojmë gjendjen në të. Sa më e vogël të jetë gjendja, aq më mirë dhe më e qëndrueshme funksionon gjithçka dhe aq më e lehtë është të diagnostikohet.
Natyrisht, kemi nevojë për automatizim, sepse një infrastrukturë e tillë është e pamundur të menaxhohet me dorë dhe ka qenë e pamundur për disa kohë. Ne kemi nevojë për mbështetje operacionale sa më shumë që të jetë e mundur dhe mbështetje CI/CD në masën që mund të ofrohet.
Me madhësi të tilla qendrash të dhënash dhe grupesh, detyra e mbështetjes së vendosjes dhe zgjerimit në rritje pa ndërprerje të shërbimit është bërë mjaft e mprehtë. Nëse në grupe të një madhësie prej një mijë makinerish, ndoshta afër dhjetë mijë makinave, ato do të mund të shpërndaheshin sërish si një operacion - domethënë, ne po planifikojmë një zgjerim të infrastrukturës dhe disa mijëra makina shtohen si një operacion, atëherë një grup me një madhësi prej njëqind mijë makinash nuk lind menjëherë kështu, ai ndërtohet gjatë një periudhe kohore. Dhe është e dëshirueshme që gjatë gjithë kësaj kohe ajo që tashmë është pompuar, infrastruktura që është vendosur, të jetë në dispozicion.
Dhe një kërkesë që kishim dhe lamë: mbështetje për multitenancitetin, domethënë virtualizimin ose segmentimin e rrjetit. Tani nuk kemi nevojë ta bëjmë këtë në nivelin e pëlhurës së rrjetit, sepse copëtimi ka shkuar te hostet dhe kjo e ka bërë shkallëzimin shumë të lehtë për ne. Falë IPv6 dhe një hapësire të madhe adresash, nuk kishim nevojë të përdornim adresa të dyfishta në infrastrukturën e brendshme; i gjithë adresimi ishte tashmë unik. Dhe falë faktit që kemi marrë filtrimin dhe segmentimin e rrjetit tek hostet, nuk kemi nevojë të krijojmë asnjë entitet rrjeti virtual në rrjetet e qendrave të të dhënave.
Një gjë shumë e rëndësishme është ajo që nuk na nevojitet. Nëse disa funksione mund të hiqen nga rrjeti, kjo e bën jetën shumë më të lehtë dhe, si rregull, zgjeron zgjedhjen e pajisjeve dhe programeve të disponueshme, duke e bërë diagnostikimin shumë të thjeshtë.
Pra, çfarë nuk na duhet, çfarë kemi mundur të heqim dorë, jo gjithmonë me gëzim në kohën kur ndodhi, por me lehtësim të madh kur procesi përfundon?
Para së gjithash, duke braktisur L2. Ne nuk kemi nevojë për L2, as real dhe as të imituar. I papërdorur kryesisht për faktin se ne kontrollojmë grupin e aplikacionit. Aplikacionet tona janë të shkallëzueshme horizontalisht, ato punojnë me adresimin L3, ata nuk shqetësohen shumë që ndonjë shembull individual ka dalë jashtë, ata thjesht nxjerrin një të ri, nuk ka nevojë të shpërndahet në adresën e vjetër, sepse ekziston një nivel i veçantë i zbulimit dhe monitorimit të shërbimit të makinerive të vendosura në grup. Ne nuk ia delegojmë këtë detyrë rrjetit. Detyra e rrjetit është të dërgojë paketa nga pika A në pikën B.
Ne gjithashtu nuk kemi situata ku adresat lëvizin brenda rrjetit dhe kjo duhet të monitorohet. Në shumë modele kjo zakonisht nevojitet për të mbështetur lëvizshmërinë VM. Ne nuk përdorim lëvizshmërinë e makinave virtuale në infrastrukturën e brendshme të Yandex-it të madh dhe, për më tepër, besojmë se edhe nëse kjo bëhet, nuk duhet të ndodhë me mbështetjen e rrjetit. Nëse vërtet duhet të bëhet, duhet të bëhet në nivelin pritës dhe të shtyjë adresat që mund të migrojnë në mbivendosje, në mënyrë që të mos preken ose të mos bëhen shumë ndryshime dinamike në sistemin e rrugëzimit të vetë shtresës së poshtme (rrjeti i transportit) .
Një teknologji tjetër që ne nuk e përdorim është multicast. Nëse dëshironi, mund t'ju them në detaje pse. Kjo e bën jetën shumë më të lehtë, sepse nëse dikush është marrë me të dhe ka parë saktësisht se si duket rrafshi i kontrollit multicast, në të gjitha instalimet, përveç atyre më të thjeshta, kjo është një dhimbje koke e madhe. Dhe për më tepër, është e vështirë të gjesh një implementim me burim të hapur që funksionon mirë, për shembull.
Së fundi, ne i projektojmë rrjetet tona në mënyrë që ato të mos ndryshojnë shumë. Mund të mbështetemi në faktin se fluksi i ngjarjeve të jashtme në sistemin e rrugëzimit është i vogël.
Cilat probleme lindin dhe cilat kufizime duhet të merren parasysh kur zhvillojmë një rrjet qendrash të dhënash? Kosto, sigurisht. Shkallueshmëria, niveli në të cilin duam të rritemi. Nevoja për t'u zgjeruar pa ndërprerë shërbimin. Gjerësia e brezit, disponueshmëria. Dukshmëria e asaj që po ndodh në rrjet për sistemet e monitorimit, për ekipet operacionale. Mbështetja e automatizimit - përsëri, sa më shumë që të jetë e mundur, pasi detyra të ndryshme mund të zgjidhen në nivele të ndryshme, duke përfshirë futjen e shtresave shtesë. Epo, jo [ndoshta] i varur nga shitësit. Edhe pse në periudha të ndryshme historike, varësisht se në cilin seksion shikon, kjo pavarësi ishte më e lehtë ose më e vështirë për t'u arritur. Nëse marrim një seksion kryq të çipave të pajisjeve të rrjetit, atëherë deri vonë ishte shumë e kushtëzuar të flitej për pavarësinë nga shitësit, nëse donim edhe çipa me xhiro të lartë.
Çfarë topologjie logjike do të përdorim për të ndërtuar rrjetin tonë? Ky do të jetë një Clos me shumë nivele. Në fakt, nuk ka alternativa reale për momentin. Dhe topologjia Clos është mjaft e mirë, edhe kur krahasohet me topologji të ndryshme të avancuara që janë më shumë në fushën e interesit akademik tani, nëse kemi ndërprerës të mëdhenj radix.
Si është i strukturuar përafërsisht një rrjet Clos me shumë nivele dhe si quhen elementët e ndryshëm në të? Fillimisht u ngrit era, për t'u orientuar ku është veriu, ku është jugu, ku është lindja, ku është perëndimi. Rrjetet e këtij lloji zakonisht ndërtohen nga ata që kanë trafik shumë të madh perëndim-lindje. Sa për elementët e mbetur, në krye është një çelës virtual i montuar nga çelsat më të vegjël. Kjo është ideja kryesore e ndërtimit rekurziv të rrjeteve Clos. Ne marrim elementë me një lloj radix dhe i lidhim ato në mënyrë që ajo që marrim të konsiderohet si një ndërprerës me një radix më të madh. Nëse keni nevojë edhe më shumë, procedura mund të përsëritet.
Në rastet, për shembull, me Clos me dy nivele, kur është e mundur të identifikohen qartë komponentët që janë vertikalë në diagramin tim, ato zakonisht quhen plane. Nëse do të ndërtonim një Clos me tre nivele të ndërprerësve të shtyllës kurrizore (që të gjithë nuk janë çelësa kufitarë ose ToR dhe që përdoren vetëm për tranzit), atëherë aeroplanët do të dukeshin më kompleksë; ato me dy nivele duken pikërisht kështu. Ne e quajmë një bllok të ToR ose çelsave me gjethe dhe çelsat e shtyllës kurrizore të nivelit të parë të lidhur me to një Pod. Ndërprerësit e shtyllës kurrizore të nivelit të shtyllës kurrizore-1 në krye të Pod janë maja e Pod, maja e Pod. Çelësat që ndodhen në pjesën e sipërme të të gjithë fabrikës janë shtresa e sipërme e fabrikës, pjesa e sipërme e pëlhurës.
Natyrisht, lind pyetja: Rrjetet Clos janë ndërtuar prej disa kohësh, vetë ideja në përgjithësi vjen nga koha e telefonisë klasike, rrjetet TDM. Ndoshta diçka më e mirë është shfaqur, ndoshta diçka mund të bëhet më mirë? Po dhe jo. Teorikisht po, në praktikë në të ardhmen e afërt definitivisht jo. Për shkak se ka një numër topologjish interesante, disa prej tyre madje përdoren në prodhim, për shembull, Dragonfly përdoret në aplikacionet HPC; Ka edhe topologji interesante si Xpander, FatClique, Jellyfish. Nëse shikoni raportet në konferenca si SIGCOMM ose NSDI kohët e fundit, mund të gjeni një numër mjaft të madh punimesh mbi topologjitë alternative që kanë veti më të mira (një ose një tjetër) sesa Clos.
Por të gjitha këto topologji kanë një veti interesante. Ai parandalon zbatimin e tyre në rrjetet e qendrave të të dhënave, të cilat ne po përpiqemi t'i ndërtojmë në harduer të mallrave dhe që kushtojnë para mjaft të arsyeshme. Në të gjitha këto topologji alternative, shumica e gjerësisë së brezit për fat të keq nuk është e aksesueshme përmes shtigjeve më të shkurtra. Prandaj, ne humbasim menjëherë mundësinë për të përdorur planin tradicional të kontrollit.
Teorikisht, zgjidhja e problemit dihet. Këto janë, për shembull, modifikime të gjendjes së lidhjes duke përdorur k-shtegun më të shkurtër, por, përsëri, nuk ka protokolle të tilla që do të zbatoheshin në prodhim dhe të disponueshme gjerësisht në pajisje.
Për më tepër, meqenëse pjesa më e madhe e kapacitetit nuk është e aksesueshme përmes shtigjeve më të shkurtra, ne duhet të modifikojmë më shumë sesa thjesht rrafshin e kontrollit për të zgjedhur të gjitha ato shtigje (dhe meqë ra fjala, kjo është dukshëm më shumë gjendje në planin e kontrollit). Ne ende duhet të modifikojmë planin e përcjelljes dhe, si rregull, kërkohen të paktën dy veçori shtesë. Kjo është aftësia për të marrë të gjitha vendimet në lidhje me përcjelljen e paketave një herë, për shembull, në host. Në fakt, kjo është drejtimi i burimit, ndonjëherë në literaturën për rrjetet e ndërlidhjes kjo quhet vendime përcjellëse të gjitha përnjëherë. Dhe rutimi adaptiv është një funksion që na nevojitet në elementët e rrjetit, i cili zbret, për shembull, në faktin se ne zgjedhim hop-in tjetër bazuar në informacionin për ngarkesën më të vogël në radhë. Si shembull, opsione të tjera janë të mundshme.
Kështu, drejtimi është interesant, por, mjerisht, ne nuk mund ta zbatojmë atë tani.
Mirë, ne u vendosëm në topologjinë logjike Clos. Si do ta shkallëzojmë atë? Le të shohim se si funksionon dhe çfarë mund të bëhet.
Në një rrjet Clos ekzistojnë dy parametra kryesorë që ne mund t'i ndryshojmë disi dhe të marrim rezultate të caktuara: radiksi i elementeve dhe numri i niveleve në rrjet. Unë kam një diagram skematik se si ndikojnë të dyja në madhësi. Në mënyrë ideale, ne i kombinojmë të dyja.
Mund të shihet se gjerësia përfundimtare e rrjetit Clos është produkt i të gjitha niveleve të ndërprerësve të shtyllës kurrizore të radiksit jugor, sa lidhje kemi poshtë, si degëzohet. Kjo është mënyra se si ne shkallëzojmë madhësinë e rrjetit.
Për sa i përket kapacitetit, veçanërisht në çelësat ToR, ekzistojnë dy opsione shkallëzimi. Ose mundemi, duke ruajtur topologjinë e përgjithshme, të përdorim lidhje më të shpejta, ose mund të shtojmë më shumë plane.
Nëse shikoni versionin e zgjeruar të rrjetit Clos (në këndin e poshtëm djathtas) dhe kthehuni te kjo foto me rrjetin Clos më poshtë...
... atëherë kjo është saktësisht e njëjta topologji, por në këtë rrëshqitje është shembur më kompakt dhe aeroplanët e fabrikës janë mbivendosur mbi njëri-tjetrin. Eshte e njejta gje.
Si duket shkallëzimi i një rrjeti Clos në numra? Këtu unë jap të dhëna se çfarë gjerësie maksimale mund të merret një rrjet, çfarë numri maksimal të rafteve, çelësave ToR ose ndërprerësve të fletëve, nëse nuk janë në rafte, mund të marrim në varësi të bazës së ndërprerësve që përdorim për nivelet e shtyllës kurrizore, dhe sa nivele përdorim.
Ja sa rafte mund të kemi, sa serverë dhe përafërsisht sa mund të konsumojë e gjithë kjo bazuar në 20 kW për raft. Pak më herët e përmenda se synojmë për një madhësi grupi prej rreth 100 mijë serverësh.
Mund të shihet se në të gjithë këtë dizajn, dy opsione e gjysmë janë me interes. Ekziston një opsion me dy shtresa shtyllash dhe ndërprerës me 64 porta, i cili bie paksa. Pastaj ka opsione të përshtatshme për çelsat e shtyllës kurrizore me 128 porte (me radix 128) me dy nivele, ose çelësa me radix 32 me tre nivele. Dhe në të gjitha rastet, ku ka më shumë radixes dhe më shumë shtresa, mund të krijoni një rrjet shumë të madh, por nëse shikoni konsumin e pritur, zakonisht ka gigavat. Është e mundur të vendosim një kabllo, por nuk ka gjasa të marrim kaq shumë energji elektrike në një vend. Nëse shikoni statistikat dhe të dhënat publike për qendrat e të dhënave, mund të gjeni shumë pak qendra të dhënash me një kapacitet të vlerësuar prej më shumë se 150 MW. Ato më të mëdha janë zakonisht kampuset e qendrave të të dhënave, disa qendra të mëdha të të dhënave të vendosura mjaft afër njëra-tjetrës.
Ekziston një parametër tjetër i rëndësishëm. Nëse shikoni kolonën e majtë, gjerësia e brezit të përdorshëm është renditur atje. Është e lehtë të shihet se në një rrjet Clos një pjesë e konsiderueshme e porteve përdoren për të lidhur çelsat me njëri-tjetrin. Gjerësia e brezit të përdorshëm, një shirit i dobishëm, është diçka që mund të jepet jashtë, drejt serverëve. Natyrisht, po flas për portet e kushtëzuara dhe konkretisht për grupin. Si rregull, lidhjet brenda rrjetit janë më të shpejta se lidhjet drejt serverëve, por për njësi të gjerësisë së brezit, aq sa mund ta dërgojmë në pajisjen e serverit tonë, ka ende një gjerësi brezi brenda vetë rrjetit. Dhe sa më shumë nivele të bëjmë, aq më e madhe është kostoja specifike e sigurimit të këtij shiriti nga jashtë.
Për më tepër, edhe ky grup shtesë nuk është saktësisht i njëjtë. Ndërsa hapësirat janë të shkurtra, ne mund të përdorim diçka si DAC (lidhja direkte e bakrit, domethënë kabllot twinax), ose optika multimode, e cila kushton edhe më shumë ose më pak para të arsyeshme. Sapo kalojmë në hapësira më të gjata - si rregull, këto janë optikë me një modalitet, dhe kostoja e kësaj gjerësie bande shtesë rritet ndjeshëm.
Dhe përsëri, duke u kthyer në rrëshqitjen e mëparshme, nëse krijojmë një rrjet Clos pa mbiabonim, atëherë është e lehtë të shikojmë diagramin, të shohim se si është ndërtuar rrjeti - duke shtuar çdo nivel të çelsave të shtyllës kurrizore, ne përsërisim të gjithë shiritin që ishte në fund. Niveli plus - plus i njëjti brez, i njëjti numër portash në çelsat siç kishte në nivelin e mëparshëm dhe i njëjti numër marrësish. Prandaj, është shumë e dëshirueshme që të minimizohet numri i niveleve të ndërprerësve të shtyllës kurrizore.
Bazuar në këtë foto, është e qartë se ne me të vërtetë duam të ndërtojmë diçka si ndërprerës me një radix prej 128.
Këtu, në parim, gjithçka është e njëjtë me atë që sapo thashë; ky është një rrëshqitje për t'u konsideruar më vonë.
Çfarë opsionesh ekzistojnë që ne mund të zgjedhim si çelësa të tillë? Është një lajm shumë i këndshëm për ne që tani rrjete të tilla më në fund mund të ndërtohen në ndërprerës me një çip. Dhe kjo është shumë e lezetshme, ata kanë shumë karakteristika të këndshme. Për shembull, ata nuk kanë pothuajse asnjë strukturë të brendshme. Kjo do të thotë se ato thyhen më lehtë. Ata thyhen në të gjitha mënyrat, por për fat të mirë thyhen plotësisht. Në pajisjet modulare ka një numër të madh defektesh (shumë të pakëndshme), kur nga këndvështrimi i fqinjëve dhe rrafshit të kontrollit duket se funksionon, por, për shembull, një pjesë e pëlhurës ka humbur dhe nuk funksionon. me kapacitet të plotë. Dhe trafiku drejt tij është i balancuar bazuar në faktin se është plotësisht funksional dhe mund të mbingarkojmë.
Ose, për shembull, lindin probleme me planin e pasmë, sepse brenda pajisjes modulare ka edhe SerDes me shpejtësi të lartë - brenda është vërtet komplekse. Ose shenjat ndërmjet elementeve përcjellëse janë të sinkronizuara ose jo të sinkronizuara. Në përgjithësi, çdo pajisje modulare produktive e përbërë nga një numër i madh elementësh, si rregull, përmban të njëjtin rrjet Clos brenda vetes, por është shumë e vështirë për t'u diagnostikuar. Shpesh është e vështirë edhe për vetë shitësin të diagnostikojë.
Dhe ka një numër të madh të skenarëve të dështimit në të cilët pajisja degradon, por nuk bie plotësisht nga topologjia. Meqenëse rrjeti ynë është i madh, balancimi midis elementeve identike përdoret në mënyrë aktive, rrjeti është shumë i rregullt, domethënë, një rrugë në të cilën gjithçka është në rregull nuk ndryshon nga shtegu tjetër, është më e dobishme për ne që thjesht të humbasim disa nga pajisjet nga topologjia se sa të përfundojnë në një situatë ku disa prej tyre duket se funksionojnë, por disa prej tyre jo.
Tipari tjetër i këndshëm i pajisjeve me një çip është se ato zhvillohen më mirë dhe më shpejt. Ata gjithashtu priren të kenë kapacitet më të mirë. Nëse marrim strukturat e mëdha të montuara që kemi në një rreth, atëherë kapaciteti për njësi rafti për porte me të njëjtën shpejtësi është pothuajse dy herë më i mirë se ai i pajisjeve modulare. Pajisjet e ndërtuara rreth një çipi të vetëm janë dukshëm më të lira se ato modulare dhe konsumojnë më pak energji.
Por, sigurisht, kjo është e gjitha për një arsye, ka edhe disavantazhe. Së pari, radiksi është pothuajse gjithmonë më i vogël se ai i pajisjeve modulare. Nëse mund të marrim një pajisje të ndërtuar rreth një çipi me 128 porte, atëherë mund të marrim një modular me disa qindra porte tani pa asnjë problem.
Kjo është një madhësi dukshëm më e vogël e tabelave të përcjelljes dhe, si rregull, gjithçka që lidhet me shkallëzueshmërinë e planit të të dhënave. Tamponë të cekët. Dhe, si rregull, funksionalitet mjaft i kufizuar. Por rezulton se nëse i dini këto kufizime dhe kujdeseni në kohë t'i anashkaloni ato ose thjesht t'i merrni parasysh, atëherë kjo nuk është aq e frikshme. Fakti që radiksi është më i vogël nuk është më problem për pajisjet me një radix prej 128 që janë shfaqur më në fund kohët e fundit; ne mund të ndërtojmë në dy shtresa shtyllash. Por është ende e pamundur të ndërtosh diçka më të vogël se dy që është interesante për ne. Me një nivel, fitohen grupime shumë të vogla. Edhe modelet dhe kërkesat tona të mëparshme ende i tejkalonin ato.
Në fakt, nëse papritmas zgjidhja është diku në prag, ka ende një mënyrë për të shkallëzuar. Meqenëse niveli i fundit (ose i pari), më i ulët ku serverët janë të lidhur janë çelësat ToR ose çelësat e fletës, nuk na kërkohet të lidhim një raft me ta. Prandaj, nëse zgjidhja bie afërsisht përgjysmë, mund të mendoni thjesht për përdorimin e një ndërprerës me një bazë të madhe në nivelin më të ulët dhe për të lidhur, për shembull, dy ose tre rafte në një çelës. Ky është gjithashtu një opsion, ka kostot e veta, por funksionon mjaft mirë dhe mund të jetë një zgjidhje e mirë kur duhet të arrini rreth dyfishin e madhësisë.
Për ta përmbledhur, ne po ndërtojmë një topologji me dy nivele shtyllash, me tetë shtresa fabrike.
Çfarë do të ndodhë me fizikën? Llogaritje shumë të thjeshta. Nëse kemi dy nivele të shtyllave, atëherë kemi vetëm tre nivele të ndërprerësve dhe presim që të ketë tre segmente kabllore në rrjet: nga serverët te ndërprerësit e gjetheve, te shtylla 1, te shtylla 2. Opsionet që mund të përdorimi janë - këto janë twinax, multimode, single mode. Dhe këtu duhet të marrim parasysh se çfarë shiriti është i disponueshëm, sa do të kushtojë, cilat janë dimensionet fizike, cilat hapësira mund të mbulojmë dhe si do të përmirësojmë.
Për sa i përket kostos, gjithçka mund të rreshtohet. Twinaxes janë dukshëm më të lirë se optika aktive, më e lirë se transmetuesit multimodë, nëse e merrni për fluturim nga fundi, disi më lirë se një port switch 100 gigabit. Dhe, ju lutemi vini re, kushton më pak se optika me një modalitet, sepse në fluturimet ku kërkohet një modalitet i vetëm, në qendrat e të dhënave për një sërë arsyesh ka kuptim të përdoret CWDM, ndërsa modaliteti i vetëm paralel (PSM) nuk është shumë i përshtatshëm për të punuar. me, pako shumë të mëdha fitohen fibra, dhe nëse fokusohemi në këto teknologji, marrim përafërsisht hierarkinë e mëposhtme të çmimeve.
Një shënim tjetër: për fat të keq, nuk është shumë e mundur të përdoren porte të çmontuara multimode 100 deri në 4x25. Për shkak të veçorive të projektimit të transmetuesve SFP28, nuk është shumë më lirë se 28 Gbit QSFP100. Dhe kjo çmontim për multimode nuk funksionon shumë mirë.
Një kufizim tjetër është se për shkak të madhësisë së grupeve kompjuterike dhe numrit të serverëve, qendrat tona të të dhënave rezultojnë të jenë fizikisht të mëdha. Kjo do të thotë që të paktën një fluturim do të duhet të bëhet me një modalitet të vetëm. Përsëri, për shkak të madhësisë fizike të Pods, nuk do të jetë e mundur të ekzekutohen dy hapësira të twinax (kabllo bakri).
Si rezultat, nëse optimizojmë për çmimin dhe marrim parasysh gjeometrinë e këtij dizajni, marrim një hapësirë të twinax, një hapësirë të multimodeve dhe një hapësirë të vetme mode duke përdorur CWDM. Kjo merr parasysh shtigjet e mundshme të përmirësimit.
Kështu duket kohët e fundit, ku po shkojmë dhe çfarë është e mundur. Është e qartë, të paktën, se si të lëvizësh drejt SerDes 50 Gigabit si për multimode ashtu edhe për një modalitet. Për më tepër, nëse shikoni se çfarë është në transmetuesit me një modalitet tani dhe në të ardhmen për 400G, shpesh edhe kur SerDes 50G vijnë nga ana elektrike, 100 Gbps për korsi tashmë mund të shkojnë në optikë. Prandaj, është shumë e mundur që në vend të kalimit në 50, të ketë një kalim në 100 Gigabit SerDes dhe 100 Gbps për korsi, sepse sipas premtimeve të shumë shitësve, disponueshmëria e tyre pritet shumë shpejt. Periudha kur 50G SerDes ishin më të shpejtat, duket se nuk do të jetë shumë e gjatë, sepse kopjet e para të 100G SerDes do të dalin pothuajse vitin e ardhshëm. Dhe pas një kohe pas kësaj ata ndoshta do të vlejnë para të arsyeshme.
Një nuancë tjetër në lidhje me zgjedhjen e fizikës. Në parim, ne tashmë mund të përdorim porte 400 ose 200 Gigabit duke përdorur 50G SerDes. Por rezulton se kjo nuk ka shumë kuptim, sepse, siç thashë më herët, ne duam një radix mjaft të madh në çelsat, brenda arsyes, natyrisht. Ne duam 128. Dhe nëse kemi kapacitet të kufizuar të çipit dhe rrisim shpejtësinë e lidhjes, atëherë radiksi natyrshëm zvogëlohet, nuk ka mrekulli.
Dhe ne mund të rrisim kapacitetin total duke përdorur avionë, dhe nuk ka kosto të veçanta; mund të shtojmë numrin e avionëve. Dhe nëse humbim radix-in, do të na duhet të vendosim një nivel shtesë, kështu që në situatën aktuale, me kapacitetin maksimal aktual të disponueshëm për çip, rezulton se është më efikase të përdorim portat 100 gigabit, sepse ato ju lejojnë për të marrë një radiks më të madh.
Pyetja tjetër është se si është organizuar fizika, por nga pikëpamja e infrastrukturës kabllore. Rezulton se është organizuar në një mënyrë mjaft qesharake. Kablloja midis çelsave të gjetheve dhe shtyllave të nivelit të parë - nuk ka shumë lidhje atje, gjithçka është ndërtuar relativisht thjesht. Por nëse marrim një aeroplan, ajo që ndodh brenda është se duhet të lidhim të gjitha shtyllat e nivelit të parë me të gjitha shtyllat e nivelit të dytë.
Plus, si rregull, ka disa dëshira se si duhet të duket brenda qendrës së të dhënave. Për shembull, ne vërtet donim të kombinonim kabllot në një pako dhe t'i tërheqim ato në mënyrë që një panel patch me densitet të lartë të shkojë tërësisht në një panel patch, në mënyrë që të mos kishte kopsht zoologjik për sa i përket gjatësisë. Ne arritëm ta zgjidhim këtë problem. Nëse fillimisht shikoni topologjinë logjike, mund të shihni se aeroplanët janë të pavarur, çdo plan mund të ndërtohet më vete. Por kur shtojmë një grup të tillë dhe duam të tërheqim të gjithë panelin patch në një panel patch, duhet të përziejmë plane të ndryshme brenda një pako dhe të prezantojmë një strukturë të ndërmjetme në formën e lidhjeve optike të kryqëzuara për t'i ripaketuar ato nga mënyra se si janë montuar. në një segment, në mënyrën se si do të mblidhen në një segment tjetër. Falë kësaj, ne kemi një veçori të këndshme: i gjithë ndërrimi kompleks nuk shkon përtej rafteve. Kur ju duhet të ndërthurni diçka shumë fort, "shpalosni aeroplanët", siç quhet nganjëherë në rrjetet Clos, të gjitha përqendrohen brenda një rafti. Ne nuk kemi shumë të çmontuar, deri në lidhje individuale, kalim midis rafteve.
Kështu duket nga pikëpamja e organizimit logjik të infrastrukturës kabllore. Në figurën në të majtë, blloqet me shumë ngjyra paraqesin blloqe të çelsave të shtyllës kurrizore të nivelit të parë, tetë pjesë secila dhe katër tufa kabllosh që vijnë prej tyre, të cilat shkojnë dhe kryqëzohen me tufat që vijnë nga blloqet e çelësave të shtyllës kurrizore-2. .
Sheshe të vegjël tregojnë kryqëzime. Në pjesën e sipërme majtas është një ndarje e çdo kryqëzimi të tillë, ky është në fakt një modul i ndërlidhjes me porte 512 me 512 që ripaketon kabllot në mënyrë që ato të vijnë plotësisht në një raft, ku ka vetëm një aeroplan spine-2. Dhe në të djathtë, një skanim i kësaj fotografie është pak më i detajuar në lidhje me disa Pods në nivelin e shtyllës kurrizore-1, dhe se si është paketuar në një lidhje të kryqëzuar, si vjen deri te niveli i shtyllës kurrizore-2.
Kështu duket. Mbështetja e shtyllës kurrizore-2 ende e pa montuar plotësisht (në të majtë) dhe mbështetja e ndërlidhjes. Fatkeqësisht, nuk ka shumë për të parë atje. E gjithë kjo strukturë është duke u vendosur tani në një nga qendrat tona të mëdha të të dhënave që po zgjerohet. Kjo është një punë në vazhdim, do të duket më bukur, do të plotësohet më mirë.
Një pyetje e rëndësishme: ne zgjodhëm topologjinë logjike dhe ndërtuam fizikën. Çfarë do të ndodhë me avionin e kontrollit? Dihet mjaft mirë nga përvoja e funksionimit, ka një sërë raportesh që protokollet e gjendjes së lidhjes janë të mira, është kënaqësi të punosh me ta, por, për fat të keq, ato nuk shkallëzohen mirë në një topologji të lidhur dendur. Dhe ka një faktor kryesor që e pengon këtë - kjo është se si funksionon përmbytja në protokollet e gjendjes së lidhjes. Nëse thjesht merrni algoritmin e përmbytjes dhe shikoni se si është strukturuar rrjeti ynë, mund të shihni se do të ketë një fanout shumë të madh në çdo hap dhe thjesht do të vërshojë planin e kontrollit me përditësime. Në mënyrë të veçantë, topologji të tilla përzihen shumë dobët me algoritmin tradicional të përmbytjes në protokollet e gjendjes së lidhjes.
Zgjedhja është të përdorni BGP. Mënyra e përgatitjes së saktë përshkruhet në RFC 7938 në lidhje me përdorimin e BGP në qendrat e mëdha të të dhënave. Idetë themelore janë të thjeshta: numri minimal i prefikseve për host dhe përgjithësisht numri minimal i parashtesave në rrjet, përdorimi i grumbullimit nëse është e mundur dhe shtypja e gjuetisë së shtigjeve. Ne duam një shpërndarje shumë të kujdesshme, shumë të kontrolluar të përditësimeve, atë që quhet valley free. Ne duam që përditësimet të vendosen saktësisht një herë kur ato kalojnë nëpër rrjet. Nëse ato kanë origjinën në fund, ato ngjiten lart, duke u shpalosur jo më shumë se një herë. Nuk duhet të ketë zigzage. Zigzagët janë shumë të këqija.
Për ta bërë këtë, ne përdorim një dizajn që është mjaft i thjeshtë për të përdorur mekanizmat themelorë të BGP. Kjo do të thotë, ne përdorim eBGP që funksionon në lidhje lokale, dhe sistemet autonome caktohen si më poshtë: një sistem autonom në ToR, një sistem autonom në të gjithë bllokun e ndërprerësve spine-1 të një Pod dhe një sistem i përgjithshëm autonom në të gjithë Topin. prej pëlhure. Nuk është e vështirë të shikosh dhe të shohësh se edhe sjellja normale e BGP na jep shpërndarjen e përditësimeve që duam.
Natyrisht, adresimi dhe grumbullimi i adresave duhet të dizajnohen në mënyrë që të jetë në përputhje me mënyrën e ndërtimit të rrugëzimit, në mënyrë që të sigurojë stabilitetin e planit të kontrollit. Adresimi L3 në transport është i lidhur me topologjinë, sepse pa këtë është e pamundur të arrihet agregimi; pa këtë, adresat individuale do të zvarriten në sistemin e rrugëzimit. Dhe një gjë tjetër është se agregimi, për fat të keq, nuk përzihet shumë mirë me shumë rrugë, sepse kur kemi shumë rrugë dhe kemi grumbullim, gjithçka është në rregull, kur i gjithë rrjeti është i shëndetshëm, nuk ka dështime në të. Fatkeqësisht, sapo të shfaqen dështime në rrjet dhe të humbasë simetria e topologjisë, mund të arrijmë në pikën nga është shpallur njësia, nga e cila nuk mund të shkojmë më tej atje ku duhet të shkojmë. Prandaj, është më mirë të grumbullohet aty ku nuk ka më shumë rrugë, në rastin tonë këta janë ndërprerës ToR.
Në fakt, është e mundur të grumbullohet, por me kujdes. Nëse mund të bëjmë ndarje të kontrolluar kur ndodhin dështime të rrjetit. Por kjo është një detyrë mjaft e vështirë, ne madje pyetëm nëse do të ishte e mundur ta bënim këtë, nëse ishte e mundur të shtonim automatizim shtesë dhe makina të gjendjes së fundme që do të goditnin saktë BGP për të marrë sjelljen e dëshiruar. Fatkeqësisht, përpunimi i rasteve të qosheve është shumë jo i dukshëm dhe kompleks, dhe kjo detyrë nuk zgjidhet mirë duke bashkangjitur bashkëngjitjet e jashtme në BGP.
Një punë shumë interesante në këtë drejtim është bërë në kuadër të protokollit RIFT, e cila do të diskutohet në raportin e ardhshëm.
Një tjetër gjë e rëndësishme është se si shkallëzohen rrafshet e të dhënave në topologji të dendura, ku kemi një numër të madh rrugësh alternative. Në këtë rast, përdoren disa struktura të dhënash shtesë: grupet ECMP, të cilat nga ana e tyre përshkruajnë grupet Next Hop.
Në një rrjet normalisht që funksionon, pa dështime, kur ngjitemi në topologjinë Clos, mjafton të përdorim vetëm një grup, sepse gjithçka që nuk është lokale përshkruhet si parazgjedhje, mund të ngjitemi lart. Kur shkojmë nga lart poshtë në jug, atëherë të gjitha shtigjet nuk janë ECMP, ato janë shtigje të vetme. Cdo gje eshte ne rregull. Problemi është, dhe veçantia e topologjisë klasike Clos është se nëse shikojmë pjesën e sipërme të pëlhurës, në çdo element, ka vetëm një rrugë për çdo element më poshtë. Nëse ndodhin dështime përgjatë kësaj rruge, atëherë ky element i veçantë në krye të fabrikës bëhet i pavlefshëm pikërisht për ato parashtesa që qëndrojnë pas shtegut të thyer. Por për pjesën tjetër është e vlefshme, dhe ne duhet të analizojmë grupet ECMP dhe të prezantojmë një gjendje të re.
Si duket shkallëzueshmëria e planit të të dhënave në pajisjet moderne? Nëse bëjmë LPM (përputhja më e gjatë e prefiksit), gjithçka është mjaft mirë, mbi 100 mijë prefiksa. Nëse po flasim për grupet Next Hop, atëherë gjithçka është më keq, 2-4 mijë. Nëse po flasim për një tabelë që përmban një përshkrim të Next Hops (ose afërsi), atëherë kjo është diku nga 16k në 64k. Dhe kjo mund të bëhet problem. Dhe këtu kemi ardhur në një digresion interesant: çfarë ndodhi me MPLS në qendrat e të dhënave? Në parim, ne donim ta bënim atë.
Dy gjëra ndodhën. Ne bëmë mikro-segmentim në hostet; nuk kishim më nevojë ta bënim atë në rrjet. Nuk ishte shumë mirë me mbështetjen nga shitës të ndryshëm, dhe aq më tepër me implementimet e hapura në kutitë e bardha me MPLS. Dhe MPLS, të paktën zbatimet e tij tradicionale, për fat të keq, kombinohen shumë dobët me ECMP. Dhe kjo është arsyeja pse.
Kështu duket struktura e përcjelljes ECMP për IP. Një numër i madh parashtesash mund të përdorin të njëjtin grup dhe të njëjtin bllok Next Hops (ose afërsi, kjo mund të quhet ndryshe në dokumentacion të ndryshëm për pajisje të ndryshme). Çështja është se kjo përshkruhet si porti dalës dhe në çfarë duhet të rishkruhet adresa MAC në mënyrë që të arrihet në Hop-in e ardhshëm të saktë. Për IP gjithçka duket e thjeshtë, mund të përdorni një numër shumë të madh prefiksash për të njëjtin grup, të njëjtin bllok Next Hops.
Arkitektura klasike MPLS nënkupton që, në varësi të ndërfaqes dalëse, etiketa mund të rishkruhet në vlera të ndryshme. Prandaj, duhet të mbajmë një grup dhe një bllok Next Hops për çdo etiketë hyrëse. Dhe kjo, mjerisht, nuk shkallëzohet.
Është e lehtë të shihet se në dizajnin tonë na duheshin rreth 4000 ndërprerës ToR, gjerësia maksimale ishte 64 shtigje ECMP, nëse largohemi nga spine-1 drejt spine-2. Ne mezi futemi në një tabelë të grupeve ECMP, nëse vetëm një parashtesë me ToR largohet dhe nuk futemi fare në tabelën Next Hops.
Nuk është gjithçka e pashpresë, sepse arkitekturat si Segment Routing përfshijnë etiketa globale. Formalisht, do të ishte e mundur që të shemben përsëri të gjitha këto blloqe Next Hops. Për ta bërë këtë, ju nevojitet një operacion i llojit të kartës së egër: merrni një etiketë dhe rishkruajeni në të njëjtën pa një vlerë specifike. Por për fat të keq, kjo nuk është shumë e pranishme në implementimet e disponueshme.
Dhe së fundi, ne duhet të sjellim trafikun e jashtëm në qendrën e të dhënave. Si ta bëjmë atë? Më parë, trafiku u fut në rrjetin Clos nga lart. Kjo do të thotë, kishte ruterë të skajshëm që lidheshin me të gjitha pajisjet në pjesën e sipërme të pëlhurës. Kjo zgjidhje funksionon mjaft mirë në madhësi të vogla dhe të mesme. Fatkeqësisht, për të dërguar trafikun në mënyrë simetrike në të gjithë rrjetin në këtë mënyrë, duhet të arrijmë njëkohësisht në të gjithë elementët e pjesës së sipërme të pëlhurës, dhe kur ka më shumë se njëqind prej tyre, rezulton se kemi nevojë gjithashtu për një radix në ruterat e skajit. Në përgjithësi, kjo kushton, sepse ruterat e skajit janë më funksionalë, portat në to do të jenë më të shtrenjta dhe dizajni nuk është shumë i bukur.
Një tjetër mundësi është të filloni një trafik të tillë nga poshtë. Është e lehtë të verifikohet që topologjia Clos është ndërtuar në atë mënyrë që trafiku që vjen nga poshtë, domethënë nga ana ToR, shpërndahet në mënyrë të barabartë midis niveleve në të gjithë pjesën e sipërme të pëlhurës në dy përsëritje, duke ngarkuar të gjithë rrjetin. Prandaj, ne prezantojmë një lloj të veçantë Pod, Edge Pod, i cili siguron lidhje të jashtme.
Ekziston edhe një opsion. Kjo është ajo që bën Facebook, për shembull. Ata e quajnë atë Fabric Aggregator ose HGRID. Një nivel shtesë i shtyllës kurrizore është duke u futur për të lidhur qendra të shumta të të dhënave. Ky dizajn është i mundur nëse nuk kemi funksione shtesë ose ndryshime të kapsulimit në ndërfaqet. Nëse ato janë pika kontakti shtesë, është e vështirë. Në mënyrë tipike, ka më shumë funksione dhe një lloj membrane që ndan pjesë të ndryshme të qendrës së të dhënave. Nuk ka asnjë pikë për ta bërë një membranë të tillë të madhe, por nëse është me të vërtetë e nevojshme për ndonjë arsye, atëherë ka kuptim të merret në konsideratë mundësia për ta hequr atë, për ta bërë atë sa më të gjerë të jetë e mundur dhe për ta transferuar atë te nikoqirët. Kjo bëhet, për shembull, nga shumë operatorë cloud. Kanë mbivendosje, e nisin nga nikoqirët.
Çfarë mundësish zhvillimi shohim? Para së gjithash, përmirësimi i mbështetjes për tubacionin CI/CD. Ne duam të fluturojmë siç testojmë dhe testojmë mënyrën se si fluturojmë. Kjo nuk funksionon shumë mirë, sepse infrastruktura është e madhe dhe është e pamundur të dyfishohet për teste. Ju duhet të kuptoni se si të futni elementë testimi në infrastrukturën e prodhimit pa e hedhur atë.
Instrumentimi më i mirë dhe monitorimi më i mirë nuk janë pothuajse kurrë të tepërta. E gjithë pyetja është një ekuilibër i përpjekjeve dhe kthimit. Nëse mund ta shtoni me përpjekje të arsyeshme, shumë mirë.
Hapni sistemet operative për pajisjet e rrjetit. Protokolle më të mira dhe sisteme më të mira të rrugëtimit, siç është RIFT. Kërkohen gjithashtu kërkime për përdorimin e skemave më të mira të kontrollit të mbipopullimit dhe ndoshta futjen, të paktën në disa pika, të mbështetjes RDMA brenda grupit.
Duke parë më tej në të ardhmen, ne kemi nevojë për topologji të avancuara dhe ndoshta rrjete që përdorin më pak shpenzime. Nga gjërat e reja, kohët e fundit ka pasur botime rreth teknologjisë së pëlhurës për HPC Cray Slingshot, e cila bazohet në Ethernet të mallrave, por me opsionin e përdorimit të titujve shumë më të shkurtër. Si rezultat, shpenzimet e përgjithshme zvogëlohen.
Çdo gjë duhet mbajtur sa më e thjeshtë, por jo më e thjeshtë. Kompleksiteti është armiku i shkallëzueshmërisë. Thjeshtësia dhe strukturat e rregullta janë miqtë tanë. Nëse ju mund të bëni një shkallë të gjerë diku, bëjeni atë. Dhe në përgjithësi, është mirë të përfshihesh në teknologjitë e rrjetit tani. Po ndodhin shumë gjëra interesante. Faleminderit.
Burimi: www.habr.com