Ne kemi zhvilluar një dizajn rrjeti për qendrat e të dhënave që lejon shtrirjen e klasterëve llogaritës me më shumë se 100,000 serverë dhe një bandwidth bisection më shumë se një petabayt në sekondë.
Nga raporti i Dmitry Afanasyev, do të mësoni rreth parimeve kryesore të dizajnit të ri, zgjerimit të topologjive, problemeve që lindin gjatë kësaj, mundësive për zgjidhje, veçorive të routing dhe zgjerimit të funksioneve të forwarding plane në pajisjet rrjetore moderne në topologji "me densitet të lartë" me numër të madh rrugësh ECMP. Përveç kësaj, Dima përmendi shkurt rreth organizimit të lidhshmërisë së jashtme, nivelit fizik, sistemit të kabllove dhe mënyrave të rritjes së mëtejshme të kapacitetit.
— Të gjithëve përshëndetje! Emri im është Dmitry Afanasyev, unë jam arkitekt rrjeti në Yandex dhe merrem kryesisht me dizajnin e rrjeteve të qendrave të të dhënave.
Historia ime do të jetë për rrjetin e rinovuar të qendrave të të dhënave të Yandex. Kjo është kryesisht një evolucion i dizajnit që kishim, por njëkohësisht ka disa elemente të reja. Kjo është një prezantim përmbledhës, pasi duhej të përfshiheshin shumë informacion në një kohë të shkurtër. Do të fillojmë me zgjedhjen e topologjisë logjike. Pastaj do të ketë një përmbledhje të control plane dhe problemeve me shkallëzimin e data plane, duke zgjedhur atë që do të ndodhë në nivelin fizik, dhe do të shikojmë disa veçori të pajisjeve. Pak do të flasim gjithashtu për atë që ndodh në qendrën e të dhënave me MPLS, për të cilin kemi folur disa kohë më parë.
Pra, çfarë është Yandex në aspektin e ngarkesave dhe shërbimeve? Yandex është një hiperskalues tipik. Nëse e shikojmë nga perspektiva e përdoruesve, në radhë të parë po përpunojmë kërkesat e përdoruesve. Gjithashtu, kemi shërbime të ndryshme streaming dhe ofrim të të dhënave, sepse kemi gjithashtu shërbime storage. Nëse shkojmë më afër bërthamës, aty shfaqen ngarkesat dhe shërbimet infrastrukturore, të tilla si depo objektive të shpërndara, replikimi i të dhënave dhe, sigurisht, radhët e qëndrueshme. Një nga llojet kryesore të ngarkesave është MapReduce dhe sisteme të ngjashme, përpunimi i vazhdueshëm, mësimi automatik etj.
Si e strukturuar infrastruktura mbi të cilën ndodhin të gjitha këto? Përsëri, ne jemi një hyperScaler tipik, ndoshta pak më afër atij ndryshimi ku ndodhen hyperScaler më të vegjël. Por ne kemi të gjitha atributet. Ne përdorim hardware të zakonshëm dhe shkallëzim horizontal sa herë që është e mundur. Ne kemi një përmbledhje të plotë të burimeve: nuk punojmë me makineri të veçanta, raftet e veçanta, por i bashkojmë ato në një pishinë të madhe burimesh të ndërrueshme me disa shërbime shtesë që merren me planifikimin dhe alokimin, dhe punojmë me të gjithë këtë pishinë.
Kështu, ne kemi nivelin e ardhshëm - sistemi operativ të nivelit të grumbullimit të llogaritjes. Është shumë e rëndësishme që ne kontrollojmë plotësisht grumbullin e teknologjive që përdorim. Ne kontrollojmë endpoint-at (host), rrjetin dhe grumbullin e programit.
Kemi disa qendra të mëdha të të dhënave në Rusi dhe jashtë saj. Ato lidhen me një backbone që përdor teknologjinë MPLS. Infrastruktura jonë e brendshme është ndërtuar pothuajse plotësisht mbi IPv6, por pasi na nevojitet të shërbejmë trafik të jashtëm, i cili ende arrin kryesisht përmes IPv4, ne duhet ta dërgojmë ndonjëherë kërkesat që vijnë përmes IPv4 deri te front-end.servera, dhe pak më tej të dalim në internetin e jashtëm IPv4 - për shembull, për indeksimin.
Iteracionet e fundit të dizajneve të rrjetit të qendrave të të dhënave përdorin topologji të shumëfishta Clos, dhe ato zbatojnë vetëm L3. Ne e kemi lënë L2 disa kohë më parë dhe kemi marrë një frymëzim të lehtësuar. Në fund, infrastruktura jonë përfshin qindra mijëra instanca llogaritëse (serverësh). Madhësia maksimale e grumbullit disa kohë më parë ishte rreth 10 mijë serverësh. Kjo është e përcaktuar në masë të madhe nga mënyra se si mund të funksionojnë ato sisteme operativë të nivelit të grumbullimit, planifikuesit, alokimi i burimeve etj. Pasi ka ndodhur progres në anën e softuerit të infrastrukturës, tani të synohet një madhësi prej rreth 100 mijë serverësh në një grumbull llogaritës, dhe kemi hasur përpjekjen për të ndërtuar fabrika rrjetesh që lejojnë një përmbledhje efikase të burimeve në një grumbull të tillë.
Çfarë duam ne nga rrjeti i qendrave të të dhënave? Në radhë të parë — shumë bandë të lirë dhe mjaft homogjenisht të shpërndarë. Sepse rrjeti është ajo bazë mbi të cilën mund të bëjmë grumbullimin e burimeve. Size-a e re e synuar — rreth 100 mijë serverë në një grup.
Po ashtu, natyrisht, duam një plan kontrolli të shkallëzueshëm dhe të qëndrueshëm, sepse në një infrastrukturë kaq të madhe, ndodhin mjaft probleme që shkaktohen edhe nga ngjarje të rastit, dhe ne nuk duam që plani i kontrollit të na sjellë më shumë dhimbje koke. Në të njëjtën kohë, duam të minimalizojmë gjendjen e tij. Sa më pak gjendje, aq më mirë dhe më qëndruese funksionon çdo gjë, më e lehtë për t'u diagnostikuar.
Sigurisht, na nevojitet automatizimi, sepse është e pamundur të menaxhosh një infrastrukturë të tillë manualisht, dhe kjo ka qenë e pamundur për një kohë. Na nevojitet, sa më shumë që të jetë e mundur, mbështetje operacionale dhe mbështetje CI/CD, në masën që mund të sigurohet.
Me përmasat e tilla të qendrave të të dhënave dhe grupeve, tashmë është bërë një detyrë urgjente mbështetje për shpërndarjen incremental dhe zgjerimin pa ndërprerje të shërbimit. Nëse në grupe me nga një mijë makinë, ndoshta afër dhjetë mijë makinash, mund të kryesh një operacion të vetëm — pra, planifikojmë zgjerimin e infrastrukturës dhe disa mijëra makina shtohen si një operacion, atëherë një grup me përmasa rreth 100 mijë makinash nuk shfaqet menjëherë ashtu, ai ndërtohet në njëkohësi. Dhe preferohet që gjatë gjithë kësaj kohe, ajo që është tashmë e instaluar, ajo infrastrukturë që është vendosur, të jetë e qasshme.
Dhe një kërkesë që kishim dhe që është hequr: është mbështetja për multitenancy, pra virtualizimin ose segmentimin e rrjetit. Tani nuk na nevojitet që ta bëjmë këtë në nivelin e fabrikës së rrjetit, sepse segmentimi është zhvendosur në hostet, dhe kjo na ka lehtësuar shumë shkallëzimin. Falë IPv6 dhe hapësirës së madhe adresuese, nuk na nevojitet të përdorim adresa të kopjuara në infrastrukturën tonë të brendshme, çdo adresë ishte dhe kështu e veçantë. Dhe falë faktit se filtrimi dhe segmentimi i rrjetit janë transferuar në hostet, nuk na nevojitet të krijojmë ndonjë entitet të virtualizuar rrjeti në rrjetet e qendrave të të dhënave.
Një gjë shumë e rëndësishme është ajo që ne nuk kemi nevojë. Nëse disa funksione mund të hiqen nga rrjeti, kjo e lehtëson jetën shumë dhe, si rregull, zgjeron zgjedhjen e pajisjeve dhe softuerëve të disponueshëm, duke e thjeshtuar shumë diagnostikimin.
Pra, çfarë nuk na nevojitet, për çfarë mund të heqim dorë, ndonjëherë jo me gëzim në momentin që ndodhte, por me një lehtësim të madh kur procesi përfundonte?
Së pari, heqja dorë nga L2. Ne nuk kemi nevojë për L2, as real ashtu si as i emuluar. Nuk përdoret në masë të madhe falë faktit se ne kontrollojmë grumbullin e aplikacioneve. Aplikacionet tona janë në shkallë horizontale, ato punojnë me adresimin L3, ato nuk shqetësohen shumë nëse ndonjë instancë e veçantë fiket, thjesht lëshojnë një të re, nuk ka nevojë të lëshohet në adresën e vjetër, sepse ekziston një nivel i veçantë për zbulimin e shërbimeve dhe monitorimin e makinave brenda klasterit. Ne nuk e ngarkojmë këtë detyrë në rrjet. Detyra e rrjetit është të dërgojë paketa nga pika A në pikën B.
Po ashtu, nuk kemi situata ku adresat lëvizin brenda rrjetit dhe kjo duhet të monitorohet. Në shumë dizajne, kjo zakonisht është e nevojshme për të mbështetur lëvizshmërinë e 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, mendojmë se, edhe nëse bëhet, kjo nuk duhet të ndodhë me mbështetje nga rrjeti. Nëse është shumë e nevojshme të bëhet, kjo duhet bërë në nivelin e hosteve, dhe të futen adresat që mund të migrojnë në overlay, në mënyrë që të mos preke dhe të krijohen shumë ndryshime dinamike në sistemin e ruterit të vetë rrjetit transportues.
Një teknologji tjetër që ne nuk e përdorim është multicast. Për ata që duan, mund të tregoj në detaje pse. Kjo e lehtëson shumë jetën, sepse, nëse dikush ka pasur të bëjë me të dhe ka parë si duket saktësisht plani i kontrollit të multicast-it – në të gjitha instalimet, përveç atyre më të thjeshta, kjo është një dhimbje e madhe koke. Dhe më shumë se kaq, është e vështirë të gjejmë një zbatim të hapur që funksionon mirë, p.sh.
Dhe në fund, ne e projektim rrjetin tonë që të mos ndodhin shumë ndryshime. Ne mund të presim që fluksi i ngjarjeve të jashtme në sistemin e ruterit është i vogël.
Cilat janë problemet dhe kufizimet që duhet të kemi parasysh kur zhvillojmë një rrjet qendrash të të dhënave? Sigurisht, çmimi. Shkallëzimi, deri në çfarë niveli duam të rritemi. Nevoja për zgjerim pa ndërprerë shërbimin. Gjerësia e brezit, disponueshmëria. Shikueshmëria e asaj që po ndodh në rrjet, për sistemet e monitorimit, për ekipet operuese. Mbështetje për automatizimin — përsëri, aq sa është e mundur, pasi detyra të ndryshme mund të zgjidhen në nivele të ndryshme, përfshirë futjen e shtresave të tjera. Edhe varen nga ofruesit. Megjithatë, në periudha të ndryshme historike, varësia nga ofruesit ka qenë më e lehtë ose më e vështirë për t'u arritur, në varësi të perspektivës që marrim. Nëse e marrim një pamje të çipave të pajisjeve rrjetore, deri në kohët e fundit, të flasësh për varësi nga ofruesit, sidomos nëse duam çipa me gjerësi të madhe brezi, ishte shumë subjektive.
Cila është topologjia logjike që do të ndërtojmë në rrjetin tonë? Kjo do të jetë një Clos me shumë nivele. Në të vërtetë, në këtë moment, nuk ka alternativa reale. Dhe topologjia Clos është mjaft e mirë, madje edhe kur e krahasojmë me topologji të avancuara të ndryshme, të cilat tani janë më shumë në sferën e interesit akademik, nëse kemi switch-e me një radix të lartë.
Si funksionon në përgjithësi një rrjet Clos me shumë nivele dhe si quhen elementet e ndryshme brenda tij? Së pari, rosa e erës, për të 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ë një trafikun shumë të madh nga perëndimi në lindje. Sa i përket elementeve të tjera, në pjesën e sipërme paraqitet një switch virtual, i ndërtuar nga switch-e më të vegjël. Kjo është ideja kryesore e ndërtimit rekursiv të rrjeteve Clos. Marrim elemente me ndonjë radix dhe i lidhim në mënyrë që ajo çfarë rezulton të merret si një switch me një radix më të madh. Nëse nevojitet akoma më shumë, procedura mund të përsëritet.
Në rastet, për shembull, me Clos me dy nivele, kur komponentët që janë vertikal në diagramin tim mund të identifikohen qartë, zakonisht quhen plane. Po të kishim ndërtuar një Clos me tre nivele switch-esh spine (të gjithë, që nuk janë të kufizuar dhe jo switch-e ToR, dhe që përdoren vetëm për transit), atëherë planet do të duken më komplekse, dy nivelet duken kështu. Blloku i switch-eve ToR ose leaf dhe switch-et spine të nivelit të parë të lidhura me ta i quajmë Pod. Switch-et spine të nivelit spine-1 në pjesën e sipërme të Pod-it — kjo është top of Pod, maja e Pod-it. Switch-et që ndodhen në krye të fabrikës — kjo është shtresa më e lartë e fabrikës, Top of fabric.
Natyrisht, lind pyetja: Rrjetet Clos po ndërtohen tashmë për një kohë, ideja vetë vjen nga koha e telefonisë klasike, rrjeteve TDM. A ka ndonjë gjë më të mirë që ka dalë, a mund të bëhet ndryshe? Po, dhe jo. Teoretikisht po, në praktikë në afatin e afërt sigurisht që jo. Sepse ka një numër të caktuar topologjish interesante, disa prej tyre përdoren madje në prodhim, për shembull, Dragonfly përdoret në aplikacionet HPC; ka gjithashtu topologji interesante si Xpander, FatClique, Jellyfish. Nëse shqyrtojmë referatet në konferenca si SIGCOMM ose NSDI vitet e fundit, mund të zbulojmë një numër të konsiderueshëm të punimeve mbi topologji alternative, të cilat kanë veti më të mira (në një farë mënyre) se Clos.
Por të gjitha këto topologji kanë një veçori interesante. Ajo pengon implementimin e tyre në rrjetet e qendrës së të dhënave, të cilat ne përpiqemi të ndërtojmë mbi harduer të zakonshëm dhe që kostojnë mjaft para. Në të gjitha këto topologji alternative, pjesa më e madhe e bandwidth-it, fatkeqësisht, nuk është e disponueshme përmes rrugëve më të shkurtra. Prandaj, ne menjëherë humbasim mundësinë për të përdorur plane tradicionale të kontrollit.
Teoretikisht, zgjidhja e problemit është e njohur. Kjo është, për shembull, modifikime të gjendjes së lidhjes me përdorimin e k-rrugëve më të shkurtra, por, përsëri, nuk ka protokolle të tilla që janë implementuar në prodhim dhe që janë në dispozicion masivisht në pajisje.
Për më tepër, duke qenë se shumica e kapacitetit nuk është e disponueshme përmes rrugëve më të shkurtra, na nevojitet të modifikojmë jo vetëm planin e kontrollit, për të zgjedhur të gjitha këto rrugë (dhe, për të thënë të vërtetën, kjo është një gjendje shumë më komplekse në planin e kontrollit). Na duhet gjithashtu të modifikojmë planin e transmetimit, dhe në përgjithësi kërkohen të paktën dy karakteristika shtesë. Kjo është aftësia për të marrë të gjitha vendimet e forwarding për paketat njëherësh, për shembull, në host. Në fakt, ky është routing i burimit, ndonjëherë në literaturën mbi rrjetet e interkoneksionit quhet vendime forwarding njëherëshe. Dhe gjithashtu routing adaptiv — kjo është tashmë një funksion që na nevojitet në elementet e rrjetit, që përmbledh, për shembull, se si ne zgjedhim hop-in e ardhshëm bazuar në informacionin mbi ngarkesën më të ulët të radhës. Si shembull, mund të ketë alternativa të tjera.
Pra, drejtimi është interesant, por, fatkeqësisht, aktualisht nuk mund ta aplikojmë.
Mirë, ndaluam në topologjinë logjike Clos. Si do ta zgjedhim atë? Le të shohim se si është e ndërtuar dhe çfarë mund të bëjmë.
Në një rrjet Clos ka dy parametra kryesorë, që ne mund t'i ndryshojmë dhe të marrim rezultate të ndryshme: radix i elementeve dhe numri i niveleve në rrjet. Kam paraqitur skematikisht se si të dyja ndikon në madhësinë. Në mënyrë ideale, ne kombinim dhe të dyja.
Është e qartë se gjerësia përfundimtare e rrjetit Clos është produkti mbi të gjitha nivelet e switch-eve spine për radix-in jugor, sa linjave kemi poshtë, si është ai degëzuar. Kështu ne e zgjedhim madhësinë e rrjetit.
Sa i përket kapacitetit, veçanërisht në switch-e të ToR, ka dy mundësi për zgjerim. Ose ne mund të përdorim linja më të shpejta, duke ruajtur topologjinë e përgjithshme, ose mund të shtojmë më shumë plane.
Nëse shikojmë variantin e zgjeruar të rrjetit Clos (në këndin e poshtëm të djathtë) dhe kthehemi në këtë imazh të rrjetit Clos në fund...
... atëherë kjo është pikërisht e njëjta topologji, por në këtë slajd është kompresuar më kompakt dhe planet e fabrikës janë mbivendosur njëra mbi tjetrën. Kjo është e njëjta gjë.
Si duket zgjerimi i rrjetit Clos në numra? Këtu kam paraqitur të dhëna për sa gjerësi maksimale mund të arrijë rrjeti, sa numër maksimal kabinetesh, switch-e ToR ose switch-e leaf, nëse ato nuk ndodhen në kabinet, mund të arrijmë në varësi të radix-it të switch-eve që përdoren për nivelet spine, dhe sa nivele përdorim.
Këtu është paraqitur sa mund të kemi raftet, sa servera dhe sa energji mund të konsumojë gjithsej, duke e llogaritur në 20 kW për raft. Pak më parë përmenda se ne synojmë për një klaster me rreth 100 mijë servera.
Është e qartë se në gjithë këtë strukturë, dy e gjysmë variante janë interesante. Ka një variant me dy nivele spajnesh dhe switch-e me 64 porte, i cili është paksa i mangët. Më pas, ka variante të shkëlqyera për switch-e me 128 porte (me radix 128) me dy nivele, ose switch-e me radix 32 me tre nivele. Në të gjitha rastet, kur ka më shumë radix dhe më shumë nivele, mund të krijoni një rrjet shumë të madh, por nëse e shikoni konsumin e pritur, zakonisht është në gigavat. Këtu mund të vendosni kabllin, por aq shumë energji në një vend nuk do të arrijmë të sigurojmë. Nëse shikoni statistikën, të dhënat publike për qendrat e të dhënave - shumë pak mund të gjeni qendra të dhënash me kapacitet llogaritës mbi 150 MW. Ajo që është mbi këtë, zakonisht janë kampus të qendrave të të dhënave, disa qendra të mëdha të dhënash të vendosura mjaft afër njëra-tjetrës.
Ka një parametr tjetër të rëndësishëm. Nëse shikoni kolonën e majtë, aty është përmendur bandwidth-i i përdorshëm. Nuk është e vështirë të vini re se në rrjetin Clos, një pjesë e konsiderueshme e porteve shkon për të lidhur switch-et me njëri-tjetrin. Bandwidth-i i përdorshëm - është ajo që mund të japim jashtë, në drejtim të serverëve. Natyrisht, po flas për porte konvencionale dhe pikërisht për bandwidth. Zakonisht, lidhjet brenda rrjetit janë më të shpejta se lidhjet në drejtim të serverëve, por për çdo njësi bandwidth-i, sa mund ta japim jashtë drejt pajisjeve tona server, ndihmohet nga sa më shumë bandwidth brenda vetë rrjetit. Dhe sa më shumë nivele të bëjmë, aq më shumë shpenzime specifike ka për ta ofruar këtë bandwidth jashtë.
Për më tepër, madje edhe kjo bandwidth shtesë nuk është krejt e njëjtë. Ndërsa shkëputjet janë të shkurtra, mund të përdorim diçka si DAC (copper direct attach, domethënë kabllot twinax), ose optikën multimode, të cilat janë akoma të arsyeshme në çmim. Sapo kalojmë në shkëputje më të gjata - zakonisht është optika single mode, dhe kostoja e kësaj bandwidth-i shtesë rritet ndjeshëm.
Dhe përsëri, duke u kthyer në slajdin e mëparshëm, në qoftë se ne krijojmë një rrjet Clos pa riprenotim, nuk është e vështirë të shohim diagramin, të shohim si ndërtohet rrjeti — duke shtuar çdo nivel të switch-ave spine, ne përsërisim të gjithë atë bandë që ishte në fund. Shtojca e nivelit — plus gjithashtu e njëjta bandë, po aq sa ishte në nivelin e mëparshëm, porte në switch-a, po aq transceiverësh. Prandaj, numri i niveleve të switch-ave spine është shumë i dëshirueshëm të minimalizohet.
Duke u nisur nga kjo figurë, është e qartë se ne e dëshirojmë të ndërtojmë mbi diçka si switch-a me radiks 128.
këtu në thelb është e njëjta gjë që unë sapo tregova; ky slajd është më shumë për shqyrtim më vonë.
Cilat janë mundësitë, çfarë mund të zgjedhim si këto switch-a? Një lajm shumë i këndshëm për ne është se tani këto rrjete më në fund mund të ndërtohen mbi switch-a njëçarësh. Dhe kjo është shumë e shkëlqyer, ata kanë një numër të madh karakteristikash të këndshme. Për shembull, ata thuajse nuk kanë strukturë të brendshme. Kjo do të thotë se janë më të lehtë për tu prishur. Ata prishen, si çdo gjë tjetër, por për fat të mirë, prishen krejtësisht. Në pajisjet modulare ka shumë defekte (shumë të pakëndshme), kur nga pikëpamja e fqinjëve dhe planeve të kontrollit ato duken si funksionale, por, për shembull, një pjesë e fabrikës është prishur dhe ato nuk funksionojnë në kapacitetin e plotë. Dhe trafiku në to balancohet duke u bazuar në faktin se ato janë plotësisht funksionale, dhe ne mund të përjetojmë mbingarkesë.
Ose, për shembull, ndodhin probleme me backplane-in, sepse brenda pajisjes modulare ka gjithashtu SerDes me shpejtësi të lartë — është vërtet një brendësi e komplikuar. Ose mes tabelave ndërmjet elementeve të forwarding-it nuk janë të sinkronizuara ose janë të sinkronizuara. Në përgjithësi, çdo pajisje modulare e prodhimit të lartë, e cila është përbërë nga një numër i madh elementësh, zakonisht përmban po atë rrjet Clos brenda saj, vetëm se është shumë e vështirë për t'u diagnostikuar. Shpesh edhe vetë shitësi ka vështirësi ta diagnostikojë.
Dhe ajo ka një numër të madh skenarësh dështimesh, në të cilat pajisja degradon, por nuk del plotësisht nga topologjia. Duke pasur parasysh se rrjeti ynë është i madh, balancon aktivisht midis elementeve identikë, rrjeti është shumë i rregullt, domethënë një rrugë, në të cilën gjithçka është në rregull, nuk ndryshon nga rruga tjetër, na jep më shumë përfitim thjesht të humbasim disa pajisje nga topologjia, sesa të përballen me situatën ku disa prej tyre duken se funksionojnë, por në të vërtetë nuk e bëjnë.
Një karakteristikë tjetër e këndshme e pajisjeve me një çip është se ato evoluojnë më mirë, më shpejt. Po ashtu, ato kanë tendencën të kenë kapacitet më të mirë. Nëse marrim struktura të mëdha të mbledhura që kemi, për rreth, kapaciteti për një njësi të rrethit në porte të të njëjtës shpejtësi është pothuajse dy herë më i mirë se sa ai i pajisjeve modulaire. Pajisjet e ndërtuara rreth një çipi janë dukshëm më të lira se ato modulare, dhe konsumojnë më pak energji.
Por, sigurisht, nuk është gjithçka kaq e lehtë, ka edhe disavantazhe. Së pari, pothuajse gjithmonë kanë një radiks më të vogël se sa pajisjet modulare. Nëse mund të marrim një pajisje të ndërtuar rreth një çipi me 128 porte, pajisja modulare mund të ketë disa qindra porte tani pa asnjë problem të madh.
Kjo është një përmasë dukshëm më e vogël e tabelave të përparimit dhe, si rregull, gjithçka që ka të bëjë me shkallëzueshmërinë e data plane. Bufra të cekëta. Dhe, si rregull, funksionaliteti është mjaft i kufizuar. Por doli se nëse e dimë këto kufizime dhe kujdesemi në kohë për t'i anashkaluar ose thjesht t'i marrim parasysh, atëherë kjo nuk është aq shqetësuese. Fakti që radiksi është më i vogël, në pajisjet e reja që kanë dalë me radiks 128, nuk është më një problem, ne mund të ndërtojmë në dy shtresa spina. Edhe me një nivel, klasterët shumë të vegjël formohen. Edhe dizajnet tona të mëparshme dhe kërkesat akoma i tejkalonin ato.
Në fakt, nëse ndonjëherë zgjidhja është në kufij, ka një mënyrë tjetër për t'u zgjeruar. Duke qenë se niveli më i ulët ku lidhen serverat — Switch-at ToR ose Switch-at leaf, ne nuk jemi të detyruar të lidhim një kabinet të vetëm. Prandaj, nëse zgjidhja është në gjendje të dobët, mund të mendojmë për përdorimin e një switch-i me më shumë radiks në nivelin e poshtëm dhe të lidhim, për shembull, dy-tre kabinete në një switch. Kjo është gjithashtu një mundësi; ka kostot e saj të veçanta, por funksionon mjaft mirë dhe mund të jetë një zgjidhje e mirë kur duhet të rrisim madhësinë në dyfish.
Për të përmbledhur, ne ndërtojmë një topologji me dy nivele spine, me tetë nivele të fabrikës.
Çfarë do ndodhë me fizikën? Llogaritje shumë të thjeshta. Nëse kemi dy nivele spine, atëherë kemi gjithsej tre nivele switch-esh, dhe presim që rrjeti të ketë tre segmente kabllosh: nga serverët te switch-at leaf, te spine 1, te spine 2. Mundësitë që mund të përdorim — janë twinax, multimode, single mode. Këtu duhet të merren parasysh, cili është kapaciteti i disponueshëm, sa do të kostojë, cilat janë përmasat fizike, çfarë distancash mund të kalojmë, dhe si do të bëjmë përmirësime.
Sa i përket kostos, gjithçka mund të organizohet në një radhitje. Twinax-i është ndjeshëm më i lirë se optika aktive, më i lirë se transmetuesit multimode, kur konsiderohet për kalimin nga fundi, disa më i lirë se porta 100-gigabit e switch-it. Dhe kujdes, është më i lirë se optika single mode, sepse në kalimet ku kërkohet single mode, në qendrat e të dhënave për një sërë arsyeh është e arsyeshme të përdoret CWDM, duke punuar me single mode të paralel (PSM) nuk është shumë e përshtatshme, bëhen shumë dërrasa të mëdha fibrash, dhe nëse ndalemi në këto teknologji, rezulton një hierarki e tillë çmimesh.
Një vërejtje tjetër: fatkeqësisht, nuk funksionon shumë mirë përdorimi i porteve 100 në 4x25 multimode të ndara. Për shkak të veçorive strukturore të transmituesve SFP28, ato nuk kushtojnë shumë më pak se QSFP28 për 100 Gbit. Dhe kjo ndarje për multimode nuk funksionon shumë mirë.
Një kufizim tjetër është se, për shkak të madhësisë së klasterëve kompjuterikë dhe numrit të serverëve, qendrat tona të të dhënave janë fizikisht të mëdha. Kjo do të thotë se të paktën një kalim do të duhet të bëhet me modin e vetëm. Përsëri, për shkak të madhësisë fisike të Pods, nuk është e mundur të kalosh dy kalime twinax me kabllo bakri.
Si përfundim, nëse optimizojmë për çmimin dhe marrim parasysh gjeometrinë e kësaj ndërtese, ne kemi një kalim me twinax, një kalim multimod dhe një kalim me mod vetëm duke përdorur CWDM. Kjo merr parasysh rrugët e mundshme për përmirësim.
Kjo është si duket, çfarë ka ndodhur së fundmi, ku po shkojmë dhe çfarë është e mundur. E qartë, së paku, se si të lëvizim drejt 50-gigabitëve SerDes për multimod dhe mod vetëm. Për më tepër, nëse shikojmë atë që është në transiverët me mod vetëm tani dhe për të ardhmen për 400G, shpesh ndodh që, kur arrijnë 50G SerDes nga ana elektrike, në optikë mund të kemi tashmë 100 Gbps për rrugë. Prandaj, është mjaft e mundur që, në vend të kalimit në 50, do të ndodhë kalimi në 100-gigabit SerDes dhe 100 Gbps për rrugë, sepse sipas premtimeve të shumë furnizuesve, disponueshmëria e tyre pritet që të jetë shumë shpejt. Periudha kur 50G SerDes ishin më të shpejtit, duket se do të jetë jo shumë e gjatë, sepse 100G SerDes do të shfaqen ndoshta vitin që vjen me të parat. Dhe pas një kohe pas kësaj, ndoshta do të kenë çmime të arsyeshme.
Një tjetër aspekt lidhur me zgjedhjen e fiziologjisë. Në parim, tani mund të përdorim porte 400 ose 200-gigabit duke përdorur 50G SerDes. Por rezulton se, nuk ka ndonjë kuptim të veçantë për këtë, sepse, siç tregova më parë, ne duam një radix të mjaftueshëm në switch-e, brenda arsyeshmërisë, natyrisht. Ne duam 128. Dhe nëse kapaciteti i çipit është i kufizuar dhe ne rrisim shpejtësinë e lidhjes, atëherë radix sigurisht do të ulet, nuk ka mrekulli.
Dhe ne mund ta rrisim kapacitetin total përmes planeve, dhe në të njëjtën kohë nuk ka asnjë kosto të veçantë, mund të shtojmë numrin e planeve. Dhe nëse humbasim radix, na duhen nivele të tjera, prandaj në raportet aktuale, me kapacitetin maksimal të disponueshëm për një çip, del se është më efikase të përdorim porte 100-gigabit, sepse ato lejojnë të arrijmë një radix më të madh.
Pyetja tjetër është se si është organizuar fizikisht, por tashmë nga këndvështrimi i infrastrukturës kabllore. Duket se është organizuar mjaft argëtuese. Kabllimi midis leaf-switch-ev dhe spine-ve të nivelit të parë – atje nuk ka shumë lidhje, gjithçka është e ndërtuar relativisht thjesht. Por, nëse marrim një plan, ajo që ndodh brenda – atje duhet të lidhim të gjithë spine-t e nivelit të parë me të gjithë spine-t e nivelit të dytë.
Plus, si rregull ka disa dëshira për atë si duhet të duket brenda datacenter-it. Për shembull, na pëlqente shumë të bashkonim kabllot në bundle dhe t'i tërhiqnim në mënyrë që një patch panel me densitet të lartë të shkonte krejtësisht në një patch panel, në mënyrë që të mos kishte një kaos në gjatësi. Arritëm ta zgjidhim këtë problem. Nëse shikojmë fillimisht topologjinë logjike, duket se planet janë të pavarura, çdo plan mund të ndërtohet vetë. Por kur shtojmë një bundling të tillë dhe duam të tërhiqnim krejtësisht patch panel-in në patch panel, duhet të përziejmë plane të ndryshme brenda një bundli dhe të sjellim një strukturë ndërmjetësore nën formën e lidhjeve optike, për të ripaketuar ato nga si ishin montuar në një segment, në si do të montoheshin në një segment tjetër. Falë kësaj, ne marrim një veçori të këndshme: e gjithë komunikimi kompleks nuk del përtej raftit. Kur nevojitet të ndërhyhet shumë për të përzjerë, "të kthesh planet", siç quhet ndonjëherë në rrjetet Clos, gjithçka përqendrohet brenda një rafti. Nuk kemi ndarje të komplikuara, deri në lidhje individuale, mes raftesh.
Keshtu duket nga këndvështrimi i organizatës logjike të infrastrukturës kabllore. Në imazhin në të majtë, blloqet me ngjyra përfaqësojnë blloqet e spine-switch-ev të nivelit të parë, nga tetë secila dhe katër bundle kabllosh që dalin nga ato dhe kalojnë me bundle që dalin nga blloqet e spine-2-switch-ev.
Këto katrorë të vegjël përfaqësojnë ndërprerjet. Në majtas lart është zhvilluar çdo një prej këtyre ndërprerjeve, që në të vërtetë është një modul i cross-connect me 512 në 512 porte, që ripakojë kabllot në mënyrë që të vijnë tërësisht në një raft, ku ka vetëm një plan të spine-2. Dhe djathtas është një shpjegim i kësaj figure, pak më i detajuar për disa Pods në nivelin spine-1, dhe si paketohen ato në cross-connect, si arrin në nivelin spine-2.
Kështu duket. Një raft të spine-2 që nuk është akoma plotësisht i ndërtuar (majtas) dhe rafti i cross-connect. Fatkeqësisht, nuk ka shumë për të parë. E gjithë kjo konstrukcioni po zhvillohet tani në një prej qendrave tona të mëdha të të dhënave që po zgjeron. Kjo është një punë në proces, do të duket më bukur, do të mbushet më mirë.
Një pyetje e rëndësishme: zgjidhëm topologjinë logjike, ndërtuam fizikën. Çfarë do të ndodhë me planin e kontrollit? Është mjaft mirë e njohur nga përvoja e operimit, ka një numër të caktuar paraqitjesh, që protokollet e gjendjes së lidhjes janë të mira, është kënaqësi të punosh me to, por, fatkeqësisht, në një topologji të ngjeshur ato nuk shkallëzohen mirë. Dhe ka një faktor kryesor që e pengon këtë — është mënyra se si funksionon flooding në protokollet e gjendjes së lidhjes. Nëse thjesht e marrim algoritmin e flooding, shohim se si është ndërtuar rrjeti ynë, kuptohet se çdo hap do të ketë një fanout shumë të madh, dhe do të mbushë thjesht planin e kontrollit me përditësime. Këto lloje topologjish pikërisht me algoritmin tradicional të flooding në protokollet e gjendjes së lidhjes përzihen shumë keq.
Zgjedhja — të përdorim BGP. Si të përgatisim atë siç duhet, është përshkruar në RFC 7938 për përdorimin e BGP në qendrat e mëdha të të dhënave. Idetë bazë janë të thjeshta: sa më pak prefikse në host dhe në përgjithësi sa më pak prefikse në rrjet, përdorni agregim nëse është e mundur, dhe shtypni hunting-in e rrugës. Ne dëshirojmë shpërndarje shumë të kujdesshme, shumë të kontrolluar të përditësimeve, ajo që quhet valley free. Ne duam që përditësimet, ndërsa kalojnë përmes rrjetit, të zhvillohen saktësisht një herë. Nëse origjinojnë poshtë, ngjiten lart, zhvillohen jo më shumë se një herë. Nuk duhet të ketë zigzake. Zigzakat janë shumë të këqija.
Për ta arritur këtë, ne përdorim një skemë mjaft të thjeshtë për të shfrytëzuar mekanizmat bazikë të BGP. Domethënë, ne përdorim eBGP që punon në link local, dhe sistemet autonome jepen ndryshe: një sistem autonom në ToR, një sistem autonom për të gjithë grupin e switch-ave spain-1 të një Pod-i, dhe një sistem autonom të përgjithshëm për tërë Top of Fabric. Nuk është e vështirë të shikosh dhe të sigurohesh se sjellja normale e BGP na ofron shpërndarjen e azhurnimeve që na nevojitet.
Natyrisht, nevojitet të dizajnojmë adresimin dhe agregimin e adresave në mënyrë që të jetë në përputhje me mënyrën se si është ndërtuar rrugëzimi, për të garantuar stabilitetin e kontrollit të planeve. L3 adresimi në transport është i lidhur me topologjinë, sepse pa të nuk është e mundur të arrihet agregimi; ndryshe, adresat individuale do të kalojnë në sistemin e rrugëzimit. Një gjë tjetër është se agregimi, fatkeqësisht, nuk përzihet shumë mirë me multi-path, sepse kur kemi multi-path dhe agregim, gjithçka është në rregull kur e gjithë rrjeti funksionon, pa rënie. Fatkeqësisht, sa herë që ndodhin probleme në rrjet dhe simetria e topologjisë humbet, ne mund të arrijmë në një pikë nga e cila është shpallur agregati, dhe nuk mund të kalojmë më tej atje ku na nevojitet. Prandaj, është më mirë të agregojmë atje ku nuk ka më multi-path, në rastin tonë, këto janë switch-at ToR.
Në të vërtetë, mund të agregojmë, por me kujdes. Nëse mund të realizojmë një dështim të kontrolluar gjatë përhapjes së defekteve në rrjet. Por kjo është një detyrë mjaft e komplikuar; ne madje kemi shqyrtuar nëse është e mundur të vendosim automatikë shtesë dhe automata përfundimtare që do të inkurajonin BGP-në për të arritur sjelljen e dëshiruar. Fatkeqësisht, trajtimi i rasteve kritike është shumë jo i qartë dhe kompleks, dhe lidhja me pajisje të jashtme në BGP nuk e zgjidh mirë këtë problem.
Një punë shumë interesante është bërë në këtë drejtim brenda protokollit RIFT, për të cilin do të flitet në prezantimin e ardhshëm.
Një gjë tjetër e rëndësishme është se si shkallëzohen data plane në topologjitë e 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 përshkruajnë përkatësisht grupet e Next Hop.
Në një rrjet që funksionon normalisht, pa ndërprerje, kur ne shkojmë përmes topologjisë Clos lart, mjafton të përdorim vetëm një grup, sepse gjithçka që nuk është lokale, përshkruhet nga defaulti, mund të shkojmë lart. Kur shkojmë nga lart poshtë në jug, të gjitha rrugët nuk janë ECMP, ato janë rrugë të vetme. E gjithë kjo është në rregull. Problemi është, dhe veçoria e klasike e topologjisë Clos është se nëse shikojmë në majën e fabrikës, nga çdo element, në çdo element poshtë ka një rrugë të vetme. Nëse gjatë kësaj rruge ndodhin ndërprerje, atëherë ky element specifik në majë të fabrikës bëhet i pavlefshëm për ato prefikse që ndodhen pas rrugës së prishur. Për të tjerët, ai është i vlefshëm, dhe na nevojitet të përdorim grupet ECMP dhe të introduktojmë një gjendje të re.
Si duket shkallëzueshmëria e data plane në pajisjet moderne? Nëse bëjmë LPM (përputhje më e gjatë prefiks), gjithçka është në rregull, mbi 100k prefikse. Nëse flasim për grupet Next Hop, atëherë gjendja është më e keqe, 2-4 mijë. Nëse flasim për tabelën që përmban përshkrimin e Next Hops (ose adjacencies), atëherë është diku nga 16k deri në 64k. Dhe kjo mund të bëhet një problem. Dhe këtu arrijmë në një shkëputje interesante: çfarë ndodhi me MPLS në qendrat e të dhënave? Në parim, ne do donim ta bëjmë.
Ndodhën dy gjëra. Ne bëmë mikro-segmentezim në hoste, kështu që nuk na nevojitet ta bëjmë në rrjet. Nuk ishte shumë mirë me mbështetje nga ofrues të ndryshëm dhe aq më keq me zbatimet e hapura në kuti të bardha me MPLS. Gjithashtu, MPLS, të paktën, zbatimet e tij tradicionale, fatkeqësisht, nuk funksionon shumë mirë me ECMP. Dhe ja pse.
Kjo është struktura e ECMP-forwarding për IP. Një numër i madh prefikse mund të përdorë të njëjtin grup dhe të njëjtin bllok Next Hops (ose adjacencies, në dokumentacion të ndryshëm për pajisje të ndryshme mund të quhet ndryshe). Kuptimi është se kjo përshkruhet si porta dalëse dhe për çfarë të rishkruhet adresa MAC, për të arritur në Next Hop të duhur. Për IP gjithçka duket e thjeshtë, mund të përdoret për një numër shumë të madh prefikse në të njëjtin grup, në të njëjtin bllok Next Hops.
Arkitektura klasike e MPLS parashikon — në varësi të interfaces dalës, etiketa mund të rishkruhet në vlera të ndryshme. Prandaj, na nevojitet të mbajmë për një grup dhe për bllokun e Next Hops për çdo etikët hyrëse. Dhe kjo, fatkeqësisht, nuk është e shkallëzueshme.
Nuk ka qenë e lehtë të kuptojmë se në ndërtimin tonë na duhen rreth 4000 switch-e ToR, me gjerësinë maksimale prej 64 rrugësh ECMP, nëse kalojmë nga spina-1 në spiina-2. Po ashtu, kemi vështirësi për t'u futur, tejet dhemshëm, në një tabelë grupesh ECMP, nëse vetëm një prefiks me ToR largohet, dhe nuk arrijmë dot të futemi në tabelën Next Hops.
Sidoqoftë, situata nuk është e paqartë, sepse arkitekturat si Segment Routing parashikojnë etiketa globale. Formalisht, mund të shkrimtojmë të gjitha këto blloqe Next Hops. Për këtë, nevojitet një operacion si wild card: të marrim etiketën dhe ta ripërshkruajmë me të njëjtën pa një vlerë të caktuar. Por, fatkeqësisht, në realizimet e disponueshme, kjo nuk është shumë e pranishme.
Dhe përfundimisht, na nevojitet të sjellim trafikun e jashtëm në qendrën e të dhënave. Si do ta bëjmë këtë? Më parë, trafiku i binte në rrjetet Clos nga lart. Pra, kishte routerë kufitarë që lidhnin me të gjitha pajisjet në Top of fabric. Ky zgjidhje funksionon mjaft mirë për madhësi të vogla dhe të mesme. Fatkeqësisht, për të sjellë trafikun në mënyrë simetrike në të gjithë rrjetin, duhet të arrijmë në të gjitha elementet e Top of fabric në të njëjtën kohë, dhe kur ata bëhen më shumë se njëqind, zbulojmë se na nevojitet një radiks i madh edhe në routerët kufitarë. Në të vërtetë, kjo ka kosto, sepse routerët kufitarë janë më funksionalë, portet tek ata do të jenë më të shtrenjta, dhe rezulton një ndërtim jo shumë i hijshëm.
Një variant tjetër është të sjellim trafikun nga poshtë. Nuk është e vështirë të kuptohet që topologjia Clos është ndërtuar në mënyrë që trafiku që hyn nga poshtë, pra nga ana e ToR, shpërndahet në mënyrë të barabartë në nivele në të gjithë Top of fabric brenda dy iteracioneve, duke ngarkuar të gjithë rrjetin. Prandaj, ne prezantojmë një tip të veçantë Pod, Edge Pod, që siguron lidhshmërinë e jashtme.
Ka është një opsion tjetër. Kështu, për shembull, vepron Facebook. Kjo quhet Fabric Aggregator ose HGRID. Këtu futet një nivel shtesë spine për të lidhur disa qendra të të dhënash. Kjo strukturë është e mundur nëse nuk kemi funksione shtesë ose ndërrim të inkapsulimit në skajet. Nëse ka, atëherë ka pika të tjera prekjeje, që e bëjnë situatën më të ndërlikuar. Zakonisht, lindin më shumë funksione dhe një lloj membrane që ndan pjesët e ndryshme të qendrës së të dhënave. Nuk është e rekomandueshme të bëhet një membranë shumë e madhe, por nëse është e nevojshme, ka kuptim të shqyrtohet mundësia e transferimit të saj, duke e bërë sa më të gjerë dhe duke e kaluar në hoste. Kështu veprojnë, për shembull, shumë operatorë të cloud-it. Ata kanë overlays, që fillojnë nga hostet.
Çfarë mundësish zhvillimi shohim? Në radhë të parë — përmirësimi i mbështetjes për pipeline-in CI/CD. Duam të fluturojmë ashtu si testojmë dhe të testojmë ashtu si fluturojmë. Kjo nuk funksionon shumë mirë, sepse infrastruktura është e madhe dhe nuk është e mundur ta kopjojmë atë për teste. Duhet të kuptojmë se si t'i integrojmë elementet e testimit në infrastrukturën operative pa e prishur atë.
Një instrumentim më i mirë, monitorim më i mirë është gjithmonë i dobishëm. E gjithë çështja është në ekuilibrin mes përpjekjeve dhe qëndrueshmërisë. Nëse mund të shtohet në mënyrë të arsyeshme — është shumë mirë.
Sistemat operative të hapura për pajisjet rrjet. Protokollet më të mira dhe sistemet më të mira të routing, për shembull RIFT. Gjithashtu, nevojiten hulumtime mbi përdorimin e skemave më të mira për kontrolin e congestion dhe, ndoshta, implementimi, së paku në disa pika, i mbështetjes RDMA brenda klasterit.
Nëse shohim nga një perspektivë më e largët, nevojiten topologji të avancuara dhe, ndoshta, rrjete me overhead më të ulët. Nga gjërat më të reja — kohët e fundit ishin publikime mbi teknologjinë fabrike për HPC Cray Slingshot, e cila është bazuar në Ethernet komod, por me opsionin për përdorimin e titujve shumë më të shkurtër. Si rezultat, overhead-u ulet.
Gjithçka duhet bërë sa më e thjeshtë që është e mundur, por jo më e thjeshtë. Kompleksiteti është një armik i shkallëzueshmërisë. Thjeshtësia dhe strukturat e rregullta janë miqtë tanë. Nëse është e mundur të bëni shkallëzim — bëjeni. Dhe, në përgjithësi, është një kohë e shkëlqyer për të punuar në teknologjitë rrjet. Po ndodhin shumë gjëra interesante. Faleminderit.
Burimi: habr.com
