Vyvinuli sme návrh siete dátového centra, ktorý umožňuje nasadenie výpočtových klastrov väčších ako 100 tisíc serverov so špičkovou šírkou pásma viac ako jeden petabajt za sekundu.
Zo správy Dmitrija Afanasyeva sa dozviete o základných princípoch nového dizajnu, škálovacích topológiách, problémoch, ktoré s tým vznikajú, možnostiach ich riešenia, vlastnostiach smerovania a škálovania funkcií smerovacej roviny moderných sieťových zariadení v „husto prepojených“ topológie s veľkým počtom ECMP trás . Okrem toho Dima stručne hovoril o organizácii externej konektivity, fyzickej vrstve, systéme kabeláže a spôsoboch ďalšieho zvyšovania kapacity.
- Pekné popoludnie všetkým! Volám sa Dmitrij Afanasyev, som sieťový architekt v Yandex a primárne navrhujem siete dátových centier.
Môj príbeh bude o aktualizovanej sieti dátových centier Yandex. Je to do značnej miery evolúcia dizajnu, ktorý sme mali, ale zároveň sú tu niektoré nové prvky. Toto je prehľadná prezentácia, pretože v krátkom čase bolo potrebné vtesnať veľa informácií. Začneme výberom logickej topológie. Ďalej bude prehľad o riadiacej rovine a problémoch so škálovateľnosťou dátovej roviny, výber toho, čo sa bude diať na fyzickej úrovni a pozrieme sa na niektoré vlastnosti zariadení. Poďme sa trochu dotknúť toho, čo sa deje v dátovom centre s MPLS, o ktorom sme hovorili pred časom.
Čo je teda Yandex z hľadiska zaťaženia a služieb? Yandex je typický hyperscaler. Ak sa pozrieme na používateľov, primárne spracovávame požiadavky používateľov. Taktiež rôzne streamovacie služby a prenos dát, pretože máme aj úložné služby. Ak je bližšie k backendu, potom sa tam objavia záťaže infraštruktúry a služby, ako napríklad distribuované ukladanie objektov, replikácia údajov a samozrejme trvalé fronty. Jedným z hlavných typov pracovných zaťažení je MapReduce a podobné systémy, spracovanie prúdov, strojové učenie atď.
Aká je infraštruktúra, nad ktorou sa to všetko deje? Opäť sme celkom typický hyperscaler, aj keď sme možno trochu bližšie k menšej hyperscaler strane spektra. Ale máme všetky atribúty. Používame komoditný hardvér a horizontálne škálovanie všade tam, kde je to možné. Máme plné združovanie zdrojov: nepracujeme s jednotlivými strojmi, jednotlivými stojanmi, ale spájame ich do veľkého fondu vymeniteľných zdrojov s niektorými doplnkovými službami, ktoré sa zaoberajú plánovaním a prideľovaním, a pracujeme s celým týmto fondom.
Máme tu teda ďalšiu úroveň – operačný systém na úrovni výpočtového klastra. Je veľmi dôležité, aby sme plne kontrolovali technologický zásobník, ktorý používame. Kontrolujeme koncové body (hostiteľov), sieť a softvérový zásobník.
Máme niekoľko veľkých dátových centier v Rusku aj v zahraničí. Spája ich chrbtica, ktorá využíva technológiu MPLS. Naša interná infraštruktúra je takmer celá postavená na IPv6, ale keďže potrebujeme obsluhovať externú prevádzku, ktorá stále prichádza hlavne cez IPv4, musíme nejakým spôsobom doručovať požiadavky prichádzajúce cez IPv4 na frontend servery a trochu viac ísť na externý IPv4- Internet – napr. napríklad na indexovanie.
Niekoľko posledných iterácií návrhov sietí dátových centier využívalo viacvrstvové topológie Clos a sú len L3. Pred chvíľou sme opustili L2 a vydýchli sme si. Napokon, naša infraštruktúra zahŕňa státisíce výpočtových (serverových) inštancií. Maximálna veľkosť klastra pred časom bola asi 10 tisíc serverov. Je to do značnej miery spôsobené tým, ako môžu fungovať tie isté operačné systémy na úrovni klastra, plánovače, prideľovanie zdrojov atď. Keďže pokrok nastal na strane softvéru infraštruktúry, cieľová veľkosť je teraz približne 100 tisíc serverov v jednom výpočtovom klastri a Máme úlohu – byť schopní vybudovať sieťové továrne, ktoré umožnia efektívne združovanie zdrojov v takomto klastri.
Čo chceme od siete dátových centier? V prvom rade je tu veľa lacnej a pomerne rovnomerne rozloženej šírky pásma. Pretože sieť je chrbtovou kosťou, prostredníctvom ktorej môžeme združovať zdroje. Nová cieľová veľkosť je približne 100 tisíc serverov v jednom klastri.
Chceme tiež, samozrejme, škálovateľnú a stabilnú riadiacu rovinu, pretože na takej veľkej infraštruktúre vzniká veľa bolestí hlavy dokonca aj z jednoducho náhodných udalostí a nechceme, aby nám kontrolná rovina prinášala aj bolesti hlavy. Zároveň v ňom chceme minimalizovať stav. Čím je stav menší, tým lepšie a stabilnejšie všetko funguje a tým ľahšie sa diagnostikuje.
Samozrejme, potrebujeme automatizáciu, pretože manažovať takúto infraštruktúru je nemožné a už nejaký čas je to nemožné. Potrebujeme čo najväčšiu operačnú podporu a podporu CI/CD v rozsahu, v akom sa dá poskytnúť.
Pri takýchto veľkostiach dátových centier a klastrov sa úloha podpory postupného nasadzovania a rozširovania bez prerušenia služby stala dosť akútnou. Ak by sa na klastroch s veľkosťou tisíc strojov, možno blízko desaťtisíc strojov, dali stále zaviesť ako jednu operáciu – to znamená, že plánujeme rozšírenie infraštruktúry a niekoľko tisíc strojov pribudne ako jedna operácia, potom zhluk veľkosti stotisíc strojov nevznikne takto hneď, ale buduje sa za určitý čas. A je žiaduce, aby po celý ten čas bolo k dispozícii to, čo už bolo odčerpané, infraštruktúra, ktorá bola nasadená.
A jedna požiadavka, ktorú sme mali a odišli: podpora multitenancy, teda virtualizácie či segmentácie siete. Teraz to už nemusíme robiť na úrovni štruktúry siete, pretože sharding prešiel na hostiteľov, čo nám veľmi uľahčilo škálovanie. Vďaka IPv6 a veľkému adresnému priestoru sme nemuseli používať duplicitné adresy vo vnútornej infraštruktúre, všetko adresovanie bolo už jedinečné. A vďaka tomu, že sme filtrovanie a segmentáciu siete preniesli na hostiteľov, nepotrebujeme vytvárať žiadne virtuálne sieťové entity v sieťach dátových centier.
Veľmi dôležitá vec je to, čo nepotrebujeme. Ak je možné niektoré funkcie odstrániť zo siete, značne to uľahčuje život a spravidla rozširuje výber dostupných zariadení a softvéru, čím sa diagnostika veľmi zjednodušuje.
Čo je to, čo nepotrebujeme, čoho sme sa dokázali vzdať, nie vždy s radosťou v čase, keď sa to stalo, ale s veľkou úľavou, keď je proces dokončený?
V prvom rade opustenie L2. Nepotrebujeme L2, ani skutočnú, ani emulovanú. Nepoužívané z veľkej časti kvôli tomu, že kontrolujeme zásobník aplikácií. Naše aplikácie sú horizontálne škálovateľné, pracujú s adresovaním L3, nemajú veľké obavy, že odišla nejaká individuálna inštancia, jednoducho zavedú novú, nie je potrebné ju zavádzať na starej adrese, pretože existuje samostatná úroveň zisťovania služieb a monitorovania strojov umiestnených v klastri. Túto úlohu nedelegujeme na sieť. Úlohou siete je doručovať pakety z bodu A do bodu B.
Nemáme ani situácie, že by sa adresy pohybovali v rámci siete a treba to sledovať. V mnohých návrhoch je to zvyčajne potrebné na podporu mobility VM. Mobilitu virtuálnych strojov v internej infraštruktúre veľkého Yandexu nevyužívame a navyše veríme, že aj keby sa tak stalo, nemalo by sa to stať so sieťovou podporou. Ak to naozaj potrebujete urobiť, musíte to urobiť na úrovni hostiteľa a odoslať adresy, ktoré môžu migrovať do prekrytí, aby ste sa nedotkli alebo nevykonali príliš veľa dynamických zmien v systéme smerovania samotnej podložky (dopravnej siete) .
Ďalšou technológiou, ktorú nepoužívame, je multicast. Ak chcete, môžem vám podrobne povedať prečo. Vďaka tomu je život oveľa jednoduchší, pretože ak sa s tým niekto zaoberal a pozrel sa na to, ako presne vyzerá rovina riadenia multicastu, vo všetkých, okrem tých najjednoduchších inštalácií, je to veľká bolesť hlavy. A čo viac, je ťažké nájsť napríklad dobre fungujúcu open source implementáciu.
Nakoniec naše siete navrhujeme tak, aby sa príliš nemenili. Môžeme počítať s tým, že tok vonkajších udalostí v smerovacom systéme je malý.
Aké problémy vznikajú a aké obmedzenia musíme brať do úvahy pri vývoji siete dátových centier? Náklady, samozrejme. Škálovateľnosť, úroveň, na ktorú chceme rásť. Potreba expandovať bez zastavenia služby. Šírka pásma, dostupnosť. Viditeľnosť toho, čo sa deje v sieti pre monitorovacie systémy, pre operačné tímy. Podpora automatizácie - opäť v maximálnej možnej miere, pretože rôzne úlohy možno riešiť na rôznych úrovniach vrátane zavedenia ďalších vrstiev. No, nie [možno] závislé od predajcov. Hoci v rôznych historických obdobiach, v závislosti od toho, na ktorú sekciu sa pozeráte, bola táto nezávislosť ľahšie alebo ťažšie dosiahnuteľná. Ak si vezmeme prierez čipmi sieťových zariadení, tak donedávna bolo veľmi podmienené hovoriť o nezávislosti od dodávateľov, ak sme chceli aj čipy s vysokou priepustnosťou.
Akú logickú topológiu použijeme na vybudovanie našej siete? Toto bude viacúrovňový Clos. V skutočnosti v súčasnosti neexistujú žiadne skutočné alternatívy. A topológia Clos je celkom dobrá, dokonca aj v porovnaní s rôznymi pokročilými topológiami, ktoré sú teraz viac v oblasti akademického záujmu, ak máme veľké radixové prepínače.
Ako je približne štruktúrovaná viacúrovňová sieť Clos a ako sa v nej nazývajú rôzne prvky? V prvom rade sa zdvihol vietor, aby ste sa zorientovali kde je sever, kde juh, kde východ, kde západ. Siete tohto typu zvyčajne budujú tí, ktorí majú veľmi veľkú západo-východnú premávku. Čo sa týka zvyšných prvkov, v hornej časti je virtuálny spínač zostavený z menších spínačov. Toto je hlavná myšlienka rekurzívnej konštrukcie sietí Clos. Vezmeme prvky s nejakým radixom a spojíme ich tak, že to, čo dostaneme, môžeme považovať za prepínač s väčším radixom. Ak potrebujete ešte viac, postup je možné zopakovať.
V prípadoch, napríklad pri dvojúrovňových Clos, keď je možné jasne identifikovať komponenty, ktoré sú v mojom diagrame vertikálne, sa zvyčajne nazývajú roviny. Ak by sme postavili Clos s tromi úrovňami chrbticových spínačov (všetky nie sú hraničné alebo ToR spínače a ktoré sa používajú iba na tranzit), potom by lietadlá vyzerali zložitejšie; dvojúrovňové vyzerajú presne takto. Blok ToR alebo listových spínačov a k nim priradených chrbtových spínačov prvej úrovne nazývame Pod. Chrbticové spínače úrovne chrbtice-1 v hornej časti modulu sú horná časť modulu, horná strana modulu. Prepínače, ktoré sú umiestnené v hornej časti celej továrne, sú vrchnou vrstvou továrne, Top of fabric.
Samozrejme vyvstáva otázka: Clos siete sú už nejaký čas vybudované, samotná myšlienka vo všeobecnosti pochádza z čias klasického telefonovania, TDM sietí. Možno sa objavilo niečo lepšie, možno sa dá niečo urobiť lepšie? Áno a nie. Teoreticky áno, v praxi v blízkej budúcnosti určite nie. Pretože existuje množstvo zaujímavých topológií, niektoré z nich sa dokonca používajú vo výrobe, napríklad Dragonfly sa používa v aplikáciách HPC; Existujú aj zaujímavé topológie ako Xpander, FatClique, Jellyfish. Ak sa pozriete na správy na konferenciách ako SIGCOMM alebo NSDI v poslednej dobe, môžete nájsť pomerne veľké množstvo prác o alternatívnych topológiách, ktoré majú lepšie vlastnosti (jedno či druhé) ako Clos.
Ale všetky tieto topológie majú jednu zaujímavú vlastnosť. Bráni ich implementácii v sieťach dátových centier, ktoré sa snažíme postaviť na komoditnom hardvéri a ktoré stoja celkom rozumné peniaze. Vo všetkých týchto alternatívnych topológiách väčšina šírky pásma bohužiaľ nie je dostupná cez najkratšie cesty. Okamžite preto prichádzame o možnosť využívať tradičnú riadiacu rovinu.
Teoreticky je riešenie problému známe. Ide napríklad o úpravy stavu spojenia pomocou k-shortest path, ale opäť neexistujú žiadne protokoly, ktoré by boli implementované vo výrobe a široko dostupné na zariadeniach.
Navyše, keďže väčšina kapacity nie je prístupná cez najkratšie cesty, musíme upraviť viac než len riadiacu rovinu, aby sme vybrali všetky tieto cesty (a mimochodom, toto je podstatne väčší stav v riadiacej rovine). Musíme ešte upraviť smerovaciu rovinu a spravidla sú potrebné aspoň dve ďalšie funkcie. Toto je schopnosť robiť všetky rozhodnutia o preposielaní paketov jednorazovo, napríklad na hostiteľovi. V skutočnosti ide o smerovanie zdroja, niekedy sa to v literatúre o prepojovacích sieťach nazýva „all-at-once forwarding decision“. A adaptívne smerovanie je funkcia, ktorú potrebujeme na sieťových prvkoch, čo sa scvrkáva napríklad na to, že ďalší skok vyberáme na základe informácie o najmenšom zaťažení fronty. Ako príklad sú možné ďalšie možnosti.
Smer je teda zaujímavý, ale, bohužiaľ, momentálne ho nemôžeme uplatniť.
Dobre, dohodli sme sa na logickej topológii Clos. Ako to budeme škálovať? Pozrime sa, ako to funguje a čo sa dá urobiť.
V sieti Clos existujú dva hlavné parametre, ktoré môžeme nejako meniť a získať určité výsledky: radix prvkov a počet úrovní v sieti. Mám schematický diagram toho, ako obe ovplyvňujú veľkosť. Ideálne je kombinovať oboje.
Je vidieť, že konečná šírka siete Clos je súčinom všetkých úrovní spine switchov južného radixu, koľko spojov máme dole, ako sa vetví. Takto škálujeme veľkosť siete.
Pokiaľ ide o kapacitu, najmä na prepínačoch ToR, existujú dve možnosti škálovania. Buď môžeme pri zachovaní všeobecnej topológie použiť rýchlejšie prepojenia, alebo môžeme pridať ďalšie roviny.
Ak sa pozriete na rozšírenú verziu siete Clos (v pravom dolnom rohu) a vrátite sa na tento obrázok so sieťou Clos nižšie...
... potom je to presne tá istá topológia, ale na tejto snímke je zložená kompaktnejšie a roviny továrne sú na seba navrstvené. To je to isté.
Ako vyzerá škálovanie siete Clos v číslach? Tu uvádzam údaje o tom, akú maximálnu šírku je možné získať sieť, aký maximálny počet stojanov, ToR prepínačov alebo listových spínačov, ak nie sú v stojanoch, môžeme získať podľa toho, aký radix prepínačov používame pre úrovne chrbtice a koľko úrovní používame.
Tu je koľko rackov môžeme mať, koľko serverov a koľko to všetko môže spotrebovať na základe 20 kW na rack. Trochu skôr som spomenul, že sa zameriavame na veľkosť klastra asi 100 tisíc serverov.
Je vidieť, že v celom tomto dizajne je záujem o dve a pol možnosti. K dispozícii je možnosť s dvoma vrstvami chrbtov a 64-portovými prepínačmi, čo je trochu málo. Potom sú tu perfektne padnúce možnosti pre 128-portové (s radix 128) spinové spínače s dvoma úrovňami alebo prepínače s radix 32 s tromi úrovňami. A vo všetkých prípadoch, kde je viac radixov a viac vrstiev, môžete vytvoriť veľmi veľkú sieť, ale ak sa pozriete na očakávanú spotrebu, zvyčajne sú tam gigawatty. Je možné položiť kábel, ale je nepravdepodobné, že by sme dostali toľko elektriny na jednom mieste. Ak sa pozriete na štatistiky a verejné údaje o dátových centrách, nájdete len veľmi málo dátových centier s odhadovanou kapacitou viac ako 150 MW. Väčšie sú zvyčajne areály dátových centier, niekoľko veľkých dátových centier umiestnených celkom blízko seba.
Je tu ešte jeden dôležitý parameter. Ak sa pozriete na ľavý stĺpec, je tam uvedená použiteľná šírka pásma. Je ľahké vidieť, že v sieti Clos sa významná časť portov používa na vzájomné prepojenie prepínačov. Použiteľná šírka pásma, užitočný pásik, je niečo, čo možno poskytnúť vonku, smerom k serverom. Prirodzene, hovorím o podmienených portoch a konkrétne o kapele. Odkazy v rámci siete sú spravidla rýchlejšie ako spojenia smerom k serverom, ale na jednotku šírky pásma, nakoľko to dokážeme poslať do nášho serverového zariadenia, stále existuje určitá šírka pásma v samotnej sieti. A čím viac úrovní urobíme, tým vyššie budú špecifické náklady na poskytnutie tohto pruhu vonku.
Navyše ani toto doplnkové pásmo nie je úplne rovnaké. Kým sú rozpätia krátke, môžeme použiť niečo ako DAC (direct attachment med, teda twinax káble), alebo multimode optiku, ktorá stojí ešte viac či menej rozumné peniaze. Akonáhle prejdeme na dlhšie rozpätia - spravidla ide o optiku s jedným režimom a náklady na túto dodatočnú šírku pásma sa výrazne zvyšujú.
A znova, keď sa vrátime k predchádzajúcej snímke, ak vytvoríme sieť Clos bez nadmerného predplatenia, potom je ľahké pozrieť sa na diagram, vidieť, ako je sieť postavená - pridaním každej úrovne prepínačov chrbtice zopakujeme celý pás, ktorý bol na dno. Plus úroveň - plus rovnaké pásmo, rovnaký počet portov na prepínačoch ako na predchádzajúcej úrovni a rovnaký počet transceiverov. Preto je veľmi žiaduce minimalizovať počet úrovní spínačov chrbtice.
Na základe tohto obrázku je jasné, že naozaj chceme stavať na niečom ako sú spínače s radixom 128.
Tu je v zásade všetko rovnaké, ako som práve povedal; toto je snímka na zváženie neskôr.
Aké sú možnosti, ktoré si môžeme vybrať ako také prepínače? Je pre nás veľmi príjemnou správou, že teraz môžu byť takéto siete konečne postavené na jednočipových switchoch. A to je veľmi cool, majú veľa pekných funkcií. Napríklad nemajú takmer žiadnu vnútornú štruktúru. To znamená, že sa ľahšie rozbijú. Rozbijú sa všelijako, no našťastie sa rozbijú úplne. V modulárnych zariadeniach je veľké množstvo porúch (veľmi nepríjemné), keď sa z pohľadu susedov a riadiacej roviny zdá, že funguje, ale napríklad sa stratila časť tkaniny a nefunguje pri plnej kapacite. A návštevnosť je vyvážená na základe toho, že je plne funkčná a môžeme sa preťažiť.
Alebo napríklad vznikajú problémy so zadnou doskou, pretože vo vnútri modulárneho zariadenia sú aj vysokorýchlostné SerDes - vo vnútri je to skutočne zložité. Buď sú znaky medzi prvkami preposielania synchronizované alebo nie sú synchronizované. Vo všeobecnosti každé produktívne modulárne zariadenie pozostávajúce z veľkého počtu prvkov spravidla obsahuje rovnakú sieť Clos, ale je veľmi ťažké ju diagnostikovať. Často je ťažké diagnostikovať aj samotného predajcu.
A má veľké množstvo scenárov zlyhania, v ktorých sa zariadenie degraduje, ale úplne nevypadne z topológie. Keďže naša sieť je veľká, aktívne sa využíva balansovanie medzi rovnakými prvkami, sieť je veľmi pravidelná, to znamená, že jedna cesta, na ktorej je všetko v poriadku, sa nelíši od druhej cesty, je pre nás výhodnejšie jednoducho stratiť časť zariadenia z topológie, než aby sa dostali do situácie, keď sa zdá, že niektoré fungujú, ale niektoré nie.
Ďalšou príjemnou vlastnosťou jednočipových zariadení je, že sa vyvíjajú lepšie a rýchlejšie. Majú tiež lepšiu kapacitu. Ak vezmeme veľké zostavené štruktúry, ktoré máme na kruhu, potom je kapacita na jednotku racku pre porty rovnakej rýchlosti takmer dvakrát vyššia ako kapacita modulárnych zariadení. Zariadenia postavené na jednom čipe sú výrazne lacnejšie ako modulárne a spotrebúvajú menej energie.
Ale, samozrejme, je to všetko z nejakého dôvodu, existujú aj nevýhody. Po prvé, radix je takmer vždy menší ako u modulárnych zariadení. Ak dokážeme získať zariadenie postavené na jednom čipe so 128 portami, potom môžeme bez problémov získať modulárne zariadenie s niekoľkými stovkami portov.
Ide o citeľne menší rozmer preposielacích tabuliek a spravidla všetko, čo súvisí so škálovateľnosťou dátovej roviny. Plytké nárazníky. A spravidla dosť obmedzená funkčnosť. Ukazuje sa však, že ak poznáte tieto obmedzenia a včas sa postaráte o ich obídenie alebo ich jednoducho zohľadníte, nie je to také strašidelné. Skutočnosť, že radix je menší, už nie je problém na zariadeniach s radixom 128, ktoré sa nedávno objavili, môžeme zabudovať dve vrstvy chrbtov. Ale stále nie je možné postaviť niečo menšie ako dve, čo je pre nás zaujímavé. S jednou úrovňou sa získajú veľmi malé zhluky. Aj naše predchádzajúce návrhy a požiadavky ich stále prevyšovali.
V skutočnosti, ak je zrazu riešenie niekde na hrane, stále existuje spôsob, ako ho škálovať. Keďže poslednou (alebo prvou), najnižšou úrovňou, kde sa pripájajú servery, sú prepínače ToR alebo listové prepínače, nemusíme k nim pripájať jeden rack. Ak teda riešenie zaostáva približne o polovicu, môžete uvažovať o jednoduchom použití prepínača s veľkým radixom na spodnej úrovni a spojením napríklad dvoch alebo troch stojanov do jedného spínača. Toto je tiež možnosť, má to svoje náklady, ale funguje to celkom dobre a môže byť dobrým riešením, keď potrebujete dosiahnuť približne dvojnásobnú veľkosť.
Aby sme to zhrnuli, staviame na topológii s dvoma úrovňami chrbtov s ôsmimi výrobnými vrstvami.
Čo sa stane s fyzikou? Veľmi jednoduché výpočty. Ak máme dve úrovne chrbtov, potom máme iba tri úrovne prepínačov a očakávame, že v sieti budú tri káblové segmenty: od serverov po listové prepínače, po chrbticu 1 po chrbticu 2. Možnosti, ktoré môžeme použitie sú - jedná sa o twinax, multimode, single mode. A tu musíme zvážiť, aký pás je k dispozícii, koľko to bude stáť, aké sú fyzické rozmery, aké rozpätia môžeme pokryť a ako budeme aktualizovať.
Čo sa týka nákladov, všetko sa dá zosúladiť. Twinaxy sú podstatne lacnejšie ako aktívna optika, lacnejšie ako multimódové transceivery, ak to vezmete na let od konca, o niečo lacnejšie ako 100-gigabitový switch port. Upozorňujeme, že to stojí menej ako optika s jedným režimom, pretože pri letoch, kde sa vyžaduje jeden režim, má v dátových centrách z mnohých dôvodov zmysel používať CWDM, zatiaľ čo paralelný režim s jedným režimom (PSM) nie je príliš vhodný na prácu. s veľmi veľkými baleniami sa získavajú vlákna, a ak sa zameriame na tieto technológie, dostaneme približne nasledujúcu cenovú hierarchiu.
Ešte jedna poznámka: žiaľ, nie je veľmi možné použiť rozložené 100 až 4x25 multimódové porty. Vzhľadom na konštrukčné vlastnosti transceiverov SFP28 nie je oveľa lacnejší ako 28 Gbit QSFP100. A táto demontáž pre multimode nefunguje veľmi dobre.
Ďalším obmedzením je, že vzhľadom na veľkosť výpočtových klastrov a počet serverov sú naše dátové centrá fyzicky veľké. To znamená, že aspoň jeden let bude musieť byť vykonaný s singlemodom. Opäť, kvôli fyzickej veľkosti modulov, nebude možné spustiť dva rozpätia twinaxu (medené káble).
Výsledkom je, že ak optimalizujeme cenu a vezmeme do úvahy geometriu tohto dizajnu, dostaneme jeden rozsah twinaxu, jeden rozsah multimode a jeden rozsah singlemode pomocou CWDM. Toto zohľadňuje možné cesty inovácie.
Takto to v poslednej dobe vyzerá, kam smerujeme a čo je možné. Prinajmenšom je jasné, ako prejsť na 50-gigabitové SerDes pre multimode aj singlemode. Navyše, ak sa pozriete na to, čo je v single-mode transceiveroch teraz a v budúcnosti pre 400G, často aj keď 50G SerDes príde z elektrickej strany, 100 Gbps na pruh už môže ísť do optiky. Preto je dosť možné, že namiesto prechodu na 50 dôjde k prechodu na 100 Gigabit SerDes a 100 Gbps na pruh, pretože podľa prísľubov mnohých predajcov sa ich dostupnosť očakáva pomerne skoro. Zdá sa, že obdobie, keď boli 50G SerDes najrýchlejšie, nebude veľmi dlhé, pretože prvé kópie 100G SerDes vychádzajú takmer budúci rok. A po nejakom čase potom budú pravdepodobne stáť za rozumné peniaze.
Ešte jedna nuansa o výbere fyziky. V zásade už môžeme použiť 400 alebo 200 gigabitové porty pomocou 50G SerDes. Ukazuje sa však, že to nedáva veľký zmysel, pretože, ako som už povedal, chceme, samozrejme, pomerne veľký radix na prepínačoch. Chceme 128. A ak máme obmedzenú kapacitu čipu a zvýšime rýchlosť linky, tak radix prirodzene klesá, žiadne zázraky sa nekonajú.
A môžeme zvýšiť celkovú kapacitu pomocou lietadiel a neexistujú žiadne špeciálne náklady; môžeme pridať počet lietadiel. A ak prídeme o radix, budeme musieť zaviesť dodatočnú úroveň, takže v súčasnej situácii pri súčasnej maximálnej dostupnej kapacite na čip sa ukazuje, že je efektívnejšie využívať 100-gigabitové porty, pretože umožňujú získať väčší radix.
Ďalšia otázka je, ako je organizovaná fyzika, ale z pohľadu káblovej infraštruktúry. Ukazuje sa, že je to organizované dosť vtipným spôsobom. Kabeláž medzi listovými prepínačmi a chrbticami prvej úrovne - nie je tam veľa prepojení, všetko je postavené relatívne jednoducho. Ale ak vezmeme jednu rovinu, vo vnútri sa stane to, že musíme spojiť všetky tŕne prvej úrovne so všetkými tŕňmi druhej úrovne.
Navyše, spravidla existujú nejaké želania, ako by to malo vyzerať vo vnútri dátového centra. Napríklad sme naozaj chceli skombinovať káble do zväzku a potiahnuť ich tak, aby jeden prepojovací panel s vysokou hustotou prešiel celý do jedného prepojovacieho panela, takže z hľadiska dĺžok neexistovala žiadna zoologická záhrada. Tento problém sa nám podarilo vyriešiť. Ak sa na začiatku pozriete na logickú topológiu, môžete vidieť, že roviny sú nezávislé, každá rovina môže byť postavená samostatne. Ale keď pridáme takýto zväzok a chceme pretiahnuť celý patch panel do patch panelu, musíme zmiešať rôzne roviny vo vnútri jedného zväzku a zaviesť medzištruktúru vo forme optických krížových spojení, aby sme ich prebalili z toho, ako boli zostavené. v jednom segmente , ako sa budú zhromažďovať v inom segmente. Vďaka tomu získame príjemnú vlastnosť: všetko zložité prepínanie nepresahuje stojany. Keď potrebujete niečo veľmi silno prepojiť, „rozvinúť roviny“, ako sa to niekedy v sieťach Clos nazýva, všetko sa sústredí v jednom stojane. Nemáme veľmi rozobraté, až po jednotlivé články, prepínanie medzi stojanmi.
Takto to vyzerá z pohľadu logickej organizácie káblovej infraštruktúry. Na obrázku vľavo viacfarebné bloky zobrazujú bloky chrbtových spínačov prvej úrovne, každý osem kusov, a štyri zväzky káblov, ktoré z nich vychádzajú a pretínajú sa so zväzkami vychádzajúcich z blokov spine-2 vypínačov. .
Malé štvorce označujú priesečníky. Vľavo hore je rozpis každej takejto križovatky, je to vlastne modul krížového prepojenia portov 512 x 512, ktorý prebaľuje káble tak, aby sa dostali úplne do jedného stojana, kde je iba jedna rovina chrbtice-2. A napravo je sken tohto obrázku trochu podrobnejší vo vzťahu k niekoľkým modulom na úrovni chrbtice-1 a ako je zabalený v krížovom spojení, ako sa dostane k úrovni chrbtice-2.
Takto to vyzerá. Ešte nie úplne zmontovaný stojan na chrbticu-2 (vľavo) a stojan na krížové pripojenie. Žiaľ, nie je tam toho veľa k videniu. Celá táto štruktúra sa práve teraz nasadzuje v jednom z našich veľkých dátových centier, ktoré sa rozširuje. Toto je rozpracovaná, bude to vyzerať krajšie, bude sa to lepšie vypĺňať.
Dôležitá otázka: vybrali sme logickú topológiu a postavili fyziku. Čo sa stane s riadiacou rovinou? Z prevádzkových skúseností je celkom dobre známe, existuje množstvo správ, že protokoly stavu prepojenia sú dobré, je radosť s nimi pracovať, ale, žiaľ, neškálujú dobre na husto prepojenej topológii. A je tu jeden hlavný faktor, ktorý tomu bráni – takto funguje záplava v protokoloch stavu spojenia. Ak si vezmete zaplavovací algoritmus a pozriete sa na to, ako je naša sieť štruktúrovaná, môžete vidieť, že na každom kroku bude veľmi veľký fanout a jednoducho to zaplaví riadiacu rovinu aktualizáciami. Konkrétne sa takéto topológie veľmi zle miešajú s tradičným zaplavovacím algoritmom v protokoloch stavu spojenia.
Na výber je použiť BGP. Ako ho správne pripraviť je popísané v RFC 7938 o použití BGP vo veľkých dátových centrách. Základné myšlienky sú jednoduché: minimálny počet prefixov na hostiteľa a všeobecne minimálny počet prefixov v sieti, ak je to možné, použite agregáciu a potlačte hľadanie cesty. Chceme veľmi starostlivú, veľmi kontrolovanú distribúciu aktualizácií, čo sa nazýva valley free. Chceme, aby aktualizácie boli nasadené presne raz, keď prechádzajú sieťou. Ak pochádzajú zospodu, stúpajú nahor a nerozvinú sa viac ako raz. Nemali by existovať žiadne cikcaky. Cikcaky sú veľmi zlé.
Aby sme to dosiahli, používame dizajn, ktorý je dostatočne jednoduchý na použitie základných mechanizmov BGP. To znamená, že používame eBGP bežiaci na link local a autonómne systémy sú priradené nasledovne: autonómny systém na ToR, autonómny systém na celom bloku spine-1 spínačov jedného Podu a všeobecný autonómny systém na celej Top z látky. Nie je ťažké vidieť a vidieť, že aj normálne správanie BGP nám poskytuje distribúciu aktualizácií, ktoré chceme.
Prirodzene, adresovanie a agregácia adries musia byť navrhnuté tak, aby boli kompatibilné so spôsobom, akým je smerovanie vybudované, aby bola zabezpečená stabilita riadiacej roviny. L3 adresovanie v transporte je viazané na topológiu, pretože bez nej nie je možné dosiahnuť agregáciu, bez nej sa jednotlivé adresy vkradnú do smerovacieho systému. A ešte jedna vec je, že agregácia sa, žiaľ, veľmi nemieša s viaccestnou, pretože keď máme viaccestnú a máme agregáciu, všetko je v poriadku, keď je celá sieť zdravá, nedochádza v nej k výpadkom. Žiaľ, akonáhle sa v sieti objavia výpadky a stratí sa symetria topológie, môžeme prísť do bodu, z ktorého bola jednotka ohlásená, z ktorého už nemôžeme ísť ďalej tam, kam potrebujeme. Preto je najlepšie agregovať tam, kde nie je ďalšia viaccestná cesta, v našom prípade sú to ToR prepínače.
V skutočnosti je možné agregovať, ale opatrne. Ak dokážeme vykonať riadenú dezagregáciu, keď dôjde k zlyhaniu siete. Je to však dosť náročná úloha, dokonca nás zaujímalo, či by to bolo možné urobiť, či by bolo možné pridať ďalšiu automatizáciu a konečné automaty, ktoré by správne nakopli BGP, aby získal požadované správanie. Žiaľ, spracovanie rohových puzdier je veľmi nejasné a zložité a táto úloha nie je dobre vyriešená pripojením externých príloh k BGP.
V rámci protokolu RIFT sa v tomto smere vykonala veľmi zaujímavá práca, o ktorej sa bude diskutovať v nasledujúcej správe.
Ďalšou dôležitou vecou je, ako sa dátové roviny škálujú v hustých topológiách, kde máme veľké množstvo alternatívnych ciest. V tomto prípade sa používa niekoľko dodatočných dátových štruktúr: ECMP skupiny, ktoré zase popisujú skupiny Next Hop.
V normálne fungujúcej sieti bez porúch, keď ideme hore po topológii Clos, stačí použiť iba jednu skupinu, pretože všetko, čo nie je lokálne, je štandardne popísané, môžeme ísť hore. Keď ideme zhora nadol na juh, potom všetky cesty nie sú ECMP, sú to jednotlivé cesty. Všetko je v poriadku. Problém je a zvláštnosťou klasickej topológie Clos je to, že ak sa pozrieme na vrch látky, na akýkoľvek prvok, existuje len jedna cesta k akémukoľvek prvku pod ním. Ak na tejto ceste dôjde k poruchám, potom sa tento konkrétny prvok v hornej časti továrne stane neplatným práve pre tie predpony, ktoré ležia za prerušenou cestou. Ale pre zvyšok to platí a musíme analyzovať skupiny ECMP a zaviesť nový štát.
Ako vyzerá škálovateľnosť dátovej roviny na moderných zariadeniach? Ak urobíme LPM (najdlhšia zhoda prefixov), všetko je celkom dobré, viac ako 100 2 prefixov. Ak sa bavíme o skupinách Next Hop, tak všetko je horšie, 4-16 tisíc. Ak hovoríme o tabuľke, ktorá obsahuje popis Next Hops (alebo priľahlých), potom je to niekde od 64k do XNUMXk. A to sa môže stať problémom. A tu sa dostávame k zaujímavej odbočke: čo sa stalo s MPLS v dátových centrách? V princípe sme to chceli urobiť.
Stali sa dve veci. Urobili sme mikrosegmentáciu na hostiteľoch, už sme to nemuseli robiť na sieti. Nebolo to veľmi dobré s podporou od rôznych dodávateľov a ešte viac s otvorenými implementáciami na bielych boxoch s MPLS. A MPLS, prinajmenšom jeho tradičné implementácie, sa bohužiaľ veľmi zle kombinuje s ECMP. A preto.
Takto vyzerá štruktúra preposielania ECMP pre IP. Veľký počet prefixov môže používať rovnakú skupinu a rovnaký blok Next Hops (alebo susediace miesta, ktoré sa môžu v rôznych dokumentoch pre rôzne zariadenia nazývať odlišne). Ide o to, že toto je popísané ako odchádzajúci port a na čo prepísať MAC adresu, aby ste sa dostali na správny Next Hop. Pre IP všetko vyzerá jednoducho, môžete použiť veľmi veľký počet prefixov pre rovnakú skupinu, rovnaký blok Next Hops.
Klasická architektúra MPLS znamená, že v závislosti od odchádzajúceho rozhrania môže byť štítok prepísaný na rôzne hodnoty. Preto musíme pre každý vstupný štítok ponechať skupinu a blok Next Hops. A toto sa, žiaľ, neškáluje.
Je ľahké vidieť, že v našom návrhu sme potrebovali asi 4000 ToR prepínačov, maximálna šírka bola 64 ciest ECMP, ak sa vzdialime od chrbtice-1 smerom k chrbtici-2. Sotva sa dostaneme do jednej tabuľky skupín ECMP, ak zmizne len jedna predpona s ToR, a vôbec sa nedostaneme do tabuľky Next Hops.
Nie je to všetko beznádejné, pretože architektúry ako Segment Routing zahŕňajú globálne značky. Formálne by bolo možné znova zrútiť všetky tieto bloky Next Hops. Na to potrebujete operáciu typu divoký znak: vezmite štítok a prepíšte ho na rovnaký bez konkrétnej hodnoty. Ale bohužiaľ to nie je príliš prítomné v dostupných implementáciách.
A nakoniec musíme do dátového centra priviesť externú prevádzku. Ako to spraviť? Predtým bola prevádzka zavedená do siete Clos zhora. To znamená, že existovali okrajové smerovače, ktoré sa pripájali ku všetkým zariadeniam v hornej časti tkaniny. Toto riešenie funguje celkom dobre na malých až stredných veľkostiach. Žiaľ, aby sme takto posielali prevádzku symetricky do celej siete, musíme naraz doraziť na všetky prvky Top of fabric a keď ich je viac ako sto, ukáže sa, že potrebujeme aj veľký radix na okrajové smerovače. Vo všeobecnosti to stojí peniaze, pretože okrajové smerovače sú funkčnejšie, porty na nich budú drahšie a dizajn nie je príliš krásny.
Ďalšou možnosťou je spustiť takúto premávku zdola. Je ľahké overiť, že topológia Clos je postavená tak, že prevádzka prichádzajúca zospodu, teda zo strany ToR, je rovnomerne rozdelená medzi úrovne v rámci celej Top of fabric v dvoch iteráciách, čím sa zaťažuje celá sieť. Preto uvádzame špeciálny typ Pod, Edge Pod, ktorý poskytuje externú konektivitu.
Je tu ešte jedna možnosť. To robí napríklad Facebook. Nazývajú to Fabric Aggregator alebo HGRID. Zavádza sa ďalšia úroveň chrbtice na prepojenie viacerých dátových centier. Tento dizajn je možný, ak nemáme ďalšie funkcie alebo zmeny zapuzdrenia na rozhraniach. Ak sú to ďalšie dotykové body, je to ťažké. Typicky existuje viac funkcií a akási membrána oddeľujúca rôzne časti dátového centra. Nemá zmysel robiť takú membránu veľkou, ale ak je to z nejakého dôvodu skutočne potrebné, potom má zmysel zvážiť možnosť odniesť ju, urobiť ju čo najširšou a preniesť na hostiteľov. Robia to napríklad mnohí cloudoví operátori. Majú presilovky, začínajú od domácich.
Aké možnosti rozvoja vidíme? V prvom rade zlepšenie podpory CI/CD potrubia. Chceme lietať tak, ako testujeme a testujeme, ako lietame. To sa veľmi nedarí, pretože infraštruktúra je veľká a na testy je nemožné ju duplikovať. Musíte pochopiť, ako zaviesť testovacie prvky do produkčnej infraštruktúry bez toho, aby ste ju zahodili.
Lepšie prístrojové vybavenie a lepšie monitorovanie nie sú takmer nikdy zbytočné. Celá otázka spočíva v rovnováhe úsilia a návratnosti. Ak to môžete pridať s primeraným úsilím, veľmi dobre.
Otvorené operačné systémy pre sieťové zariadenia. Lepšie protokoly a lepšie smerovacie systémy, ako napríklad RIFT. Je tiež potrebný výskum využitia lepších schém kontroly preťaženia a možno aj zavedenie, aspoň v niektorých bodoch, podpory RDMA v rámci zoskupenia.
Ak sa pozrieme ďalej do budúcnosti, potrebujeme pokročilé topológie a prípadne siete, ktoré využívajú menej réžie. Z čerstvých vecí sa nedávno objavili publikácie o technológii tkaniny pre HPC Cray Slingshot, ktorá je založená na komoditnom Ethernete, no s možnosťou použitia oveľa kratších hlavičiek. V dôsledku toho sa režijné náklady znížia.
Všetko by malo byť čo najjednoduchšie, ale nie jednoduchšie. Zložitosť je nepriateľom škálovateľnosti. Jednoduchosť a pravidelné štruktúry sú našimi priateľmi. Ak môžete niekde urobiť škálovanie, urobte to. A vo všeobecnosti je skvelé byť teraz zapojený do sieťových technológií. Deje sa veľa zaujímavých vecí. Ďakujem.
Zdroj: hab.com