Vyvinuli jsme návrh sítě datového centra, který umožňuje nasazení výpočetních clusterů větších než 100 tisíc serverů s maximální šířkou pásma přes jeden petabajt za sekundu.
Ze zprávy Dmitrije Afanasyeva se dozvíte o základních principech nového designu, škálovacích topologiích, problémech, které s tím vznikají, možnostech jejich řešení, funkcích směrování a škálování funkcí předávací roviny moderních síťových zařízení v „hustě propojených“ topologie s velkým počtem cest ECMP . Kromě toho Dima krátce hovořil o organizaci externí konektivity, fyzické vrstvě, systému kabeláže a způsobech dalšího navyšování kapacity.
- Dobré odpoledne všichni! Jmenuji se Dmitrij Afanasyev, jsem síťový architekt ve společnosti Yandex a primárně navrhuji sítě datových center.
Můj příběh bude o aktualizované síti datových center Yandex. Je to do značné míry evoluce designu, který jsme měli, ale zároveň jsou zde některé nové prvky. Toto je přehledná prezentace, protože bylo potřeba zabalit mnoho informací do malého množství času. Začneme výběrem logické topologie. Dále zde bude přehled řídicí roviny a problémy se škálovatelností datové roviny, výběr toho, co se bude dít na fyzické úrovni, a podíváme se na některé vlastnosti zařízení. Pojďme se trochu dotknout toho, co se děje v datovém centru s MPLS, o kterém jsme mluvili před časem.
Co je tedy Yandex z hlediska zatížení a služeb? Yandex je typický hyperscaler. Pokud se podíváme na uživatele, zpracováváme především požadavky uživatelů. Také různé streamovací služby a přenos dat, protože máme i úložné služby. Pokud je blíže k backendu, objeví se tam zatížení infrastruktury a služby, jako je úložiště distribuovaných objektů, replikace dat a samozřejmě trvalé fronty. Jedním z hlavních typů zátěže je MapReduce a podobné systémy, zpracování streamů, strojové učení atd.
Jak je na tom infrastruktura, nad kterou se to všechno děje? Opět jsme docela typický hyperscaler, i když jsme možná trochu blíže menší hyperscaler straně spektra. Ale máme všechny atributy. Kdekoli je to možné, používáme komoditní hardware a horizontální škálování. Máme plné sdružování zdrojů: nepracujeme s jednotlivými stroji, jednotlivými stojany, ale kombinujeme je do velkého fondu zaměnitelných zdrojů s některými doplňkovými službami, které se zabývají plánováním a alokací, a pracujeme s celým tímto poolem.
Máme tu tedy další úroveň – operační systém na úrovni výpočetního clusteru. Je velmi důležité, abychom plně kontrolovali technologický stack, který používáme. Kontrolujeme koncové body (hosts), síť a softwarový stack.
Máme několik velkých datových center v Rusku i v zahraničí. Spojuje je páteř, která využívá technologii MPLS. Naše interní infrastruktura je téměř celá postavena na IPv6, ale protože potřebujeme obsluhovat externí provoz, který stále přichází hlavně přes IPv4, musíme nějakým způsobem doručovat požadavky přicházející přes IPv4 na frontend servery a trochu více jít na externí IPv4- Internet – např. například pro indexování.
Několik posledních iterací návrhů sítí datových center používalo vícevrstvé topologie Clos a jsou pouze L3. Před chvílí jsme opustili L2 a vydechli úlevou. A konečně naše infrastruktura zahrnuje stovky tisíc výpočetních (serverových) instancí. Maximální velikost clusteru před časem byla asi 10 tisíc serverů. To je z velké části způsobeno tím, jak mohou fungovat stejné operační systémy na úrovni clusteru, plánovače, alokace zdrojů atd. Vzhledem k tomu, že pokrok nastal na straně softwaru infrastruktury, cílová velikost je nyní asi 100 tisíc serverů v jednom počítačovém clusteru a Máme úkol – umět vybudovat síťové továrny, které umožní efektivní sdružování zdrojů v takovém clusteru.
Co chceme od sítě datových center? Za prvé, existuje spousta levné a poměrně rovnoměrně rozložené šířky pásma. Protože síť je páteří, jejímž prostřednictvím můžeme sdružovat zdroje. Nová cílová velikost je asi 100 tisíc serverů v jednom clusteru.
Chceme také samozřejmě škálovatelnou a stabilní řídicí rovinu, protože na tak velké infrastruktuře vzniká spousta bolestí hlavy i z jednoduše náhodných událostí a nechceme, aby nám řídicí rovina přinášela bolesti hlavy také. Zároveň v něm chceme minimalizovat stav. Čím menší je stav, tím lépe a stabilněji vše funguje a tím snáze se diagnostikuje.
Automatizaci samozřejmě potřebujeme, protože takovou infrastrukturu není možné řídit ručně a nějakou dobu to bylo nemožné. Potřebujeme co největší provozní podporu a podporu CI/CD v rozsahu, v jakém ji lze poskytnout.
S takovými velikostmi datových center a klastrů je úkol podporovat postupné zavádění a rozšiřování bez přerušení služeb poměrně akutní. Pokud by na clusterech o velikosti tisíce strojů, možná blízko deseti tisícům strojů, mohly být stále spuštěny jako jedna operace – to znamená, že plánujeme rozšíření infrastruktury a přibude několik tisíc strojů jako jedna operace, pak shluk o velikosti sto tisíc strojů nevznikne hned takhle, ale staví se za nějaký čas. A je žádoucí, aby po celou tu dobu bylo k dispozici to, co již bylo odčerpáno, infrastruktura, která byla nasazena.
A jeden požadavek, který jsme měli a nechali: podpora multitenancy, tedy virtualizace nebo segmentace sítě. Nyní to nemusíme dělat na úrovni síťové struktury, protože sharding přešel na hostitele, a to nám velmi usnadnilo škálování. Díky IPv6 a velkému adresnímu prostoru jsme nemuseli používat duplicitní adresy ve vnitřní infrastruktuře, veškeré adresování bylo již unikátní. A díky tomu, že jsme filtrování a segmentaci sítě přenesli na hostitele, nepotřebujeme v sítích datových center vytvářet žádné virtuální síťové entity.
Velmi důležitá věc je to, co nepotřebujeme. Pokud lze některé funkce odstranit ze sítě, značně to usnadňuje život a zpravidla rozšiřuje výběr dostupného vybavení a softwaru, což velmi zjednodušuje diagnostiku.
Co tedy nepotřebujeme, čeho jsme se dokázali vzdát, ne vždy s radostí v době, kdy se to stalo, ale s velkou úlevou, když je proces dokončen?
Za prvé, opuštění L2. Nepotřebujeme L2, ani skutečnou, ani emulovanou. Nevyužito z velké části kvůli tomu, že ovládáme zásobník aplikací. Naše aplikace jsou horizontálně škálovatelné, pracují s L3 adresováním, moc se nebojí, že odešla nějaká jednotlivá instance, jednoduše zavedou novou, nemusí se zavádět na staré adrese, protože tam je samostatná úroveň vyhledávání služeb a monitorování strojů umístěných v clusteru. Tento úkol nedelegujeme na síť. Úkolem sítě je doručovat pakety z bodu A do bodu B.
Také u nás nedochází k situacím, kdy by se adresy pohybovaly v rámci sítě, a to je potřeba hlídat. U mnoha návrhů je to obvykle potřeba pro podporu mobility virtuálních počítačů. Mobilitu virtuálních strojů v interní infrastruktuře velkého Yandexu nevyužíváme a navíc se domníváme, že i kdyby se tak stalo, nemělo by se to stát se síťovou podporou. Pokud je to skutečně nutné udělat, je třeba to provést na úrovni hostitele a odeslat adresy, které mohou migrovat do překryvů, aby se nedotýkaly nebo neprováděly příliš mnoho dynamických změn v systému směrování samotné podložky (dopravní síť) .
Další technologií, kterou nepoužíváme, je multicast. Jestli chceš, můžu ti podrobně říct proč. To značně usnadňuje život, protože pokud se s tím někdo zabýval a podíval se, jak přesně vypadá řídicí rovina multicastu ve všech instalacích kromě těch nejjednodušších, je to velký bolehlav. A navíc je těžké najít například dobře fungující open source implementaci.
Nakonec naše sítě navrhujeme tak, aby se příliš neměnily. Můžeme počítat s tím, že tok vnějších událostí ve směrovacím systému je malý.
Jaké problémy vznikají a jaká omezení je třeba vzít v úvahu, když vyvíjíme síť datových center? Náklady, samozřejmě. Škálovatelnost, úroveň, na kterou chceme růst. Potřeba expandovat bez zastavení služby. Šířka pásma, dostupnost. Viditelnost dění na síti pro monitorovací systémy, pro operační týmy. Podpora automatizace - opět v maximální možné míře, protože různé úkoly lze řešit na různých úrovních, včetně zavedení dalších vrstev. No, není [možná] závislý na prodejcích. I když v různých historických obdobích, v závislosti na tom, na který úsek se díváte, bylo této nezávislosti snazší nebo obtížnější dosáhnout. Když si vezmeme průřez čipy síťových zařízení, tak donedávna bylo velmi podmíněné mluvit o nezávislosti na prodejcích, pokud jsme chtěli i čipy s vysokou propustností.
Jakou logickou topologii použijeme k vybudování naší sítě? Toto bude víceúrovňový Clos. Ve skutečnosti v tuto chvíli neexistují žádné skutečné alternativy. A topologie Clos je docela dobrá, dokonce i ve srovnání s různými pokročilými topologiemi, které jsou nyní spíše v oblasti akademického zájmu, pokud máme velké radixové přepínače.
Jak je víceúrovňová síť Clos zhruba strukturována a jak se v ní nazývají různé prvky? Nejprve se zvedl vítr, abyste se zorientovali, kde je sever, kde jih, kde východ, kde západ. Sítě tohoto typu obvykle budují ti, kteří mají velmi velký provoz ze západu na východ. Pokud jde o zbývající prvky, nahoře je virtuální spínač sestavený z menších spínačů. To je hlavní myšlenka rekurzivní konstrukce sítí Clos. Vezmeme prvky s nějakým druhem radixu a spojíme je tak, že to, co dostaneme, lze považovat za přepínač s větším radixem. Pokud potřebujete ještě více, lze postup opakovat.
V případech, například u dvouúrovňových Clos, kdy je možné jasně identifikovat komponenty, které jsou v mém diagramu vertikální, se obvykle nazývají roviny. Pokud bychom postavili Clos se třemi úrovněmi páteřních spínačů (z nichž všechny nejsou hraniční nebo ToR spínače a které se používají pouze pro tranzit), pak by letadla vypadala složitější, dvouúrovňová vypadala přesně takto. Blok ToR nebo listových spínačů a k nim přiřazené páteřní spínače první úrovně nazýváme Pod. Páteřní spínače úrovně páteře-1 v horní části modulu jsou vršek modulu, vršek modulu. Spínače, které jsou umístěny v horní části celé továrny, jsou horní vrstvou továrny, Top of fabric.
Nabízí se samozřejmě otázka: Sítě Clos jsou již nějakou dobu budovány, samotná myšlenka obecně pochází z dob klasického telefonování, TDM sítí. Možná se objevilo něco lepšího, možná lze něco udělat lépe? Ano i ne. Teoreticky ano, v praxi v blízké budoucnosti rozhodně ne. Protože existuje řada zajímavých topologií, některé z nich se používají i ve výrobě, například Dragonfly se používá v HPC aplikacích; Nechybí ani zajímavé topologie jako Xpander, FatClique, Jellyfish. Pokud se podíváte na zprávy na konferencích jako SIGCOMM nebo NSDI v poslední době, můžete najít poměrně velké množství prací o alternativních topologiích, které mají lepší vlastnosti (jedno či druhé) než Clos.
Všechny tyto topologie mají ale jednu zajímavou vlastnost. Brání jejich implementaci v sítích datových center, které se snažíme stavět na komoditním hardwaru a které stojí celkem rozumné peníze. Ve všech těchto alternativních topologiích není bohužel většina šířky pásma dostupná nejkratšími cestami. Okamžitě proto ztrácíme možnost používat tradiční řídicí rovinu.
Teoreticky je řešení problému známé. Jedná se například o úpravy stavu linky pomocí k-shortest path, ale opět neexistují žádné takové protokoly, které by byly implementovány ve výrobě a široce dostupné na zařízení.
Navíc, protože většina kapacity není přístupná nejkratšími cestami, musíme upravit více než jen řídicí rovinu, abychom vybrali všechny tyto cesty (a mimochodem, v řídicí rovině je to podstatně více stavu). Musíme ještě upravit předávací rovinu a zpravidla jsou vyžadovány alespoň dvě další funkce. Jedná se o možnost učinit všechna rozhodnutí o předávání paketů jednorázově, například na hostiteli. Ve skutečnosti se jedná o směrování zdroje, někdy se to v literatuře o propojovacích sítích nazývá all-at-once forwarding Decisions. A adaptivní směrování je funkce, kterou potřebujeme na síťových prvcích, která se scvrkává například na to, že další skok vybíráme na základě informace o nejmenším zatížení fronty. Jako příklad jsou možné další možnosti.
Směr je tedy zajímavý, ale bohužel jej nyní nemůžeme použít.
Dobře, dohodli jsme se na logické topologii Clos. Jak to budeme škálovat? Pojďme se podívat, jak to funguje a co se dá dělat.
V síti Clos existují dva hlavní parametry, které můžeme nějak obměňovat a získávat určité výsledky: radix prvků a počet úrovní v síti. Mám schematický diagram, jak oba ovlivňují velikost. Ideálně kombinujeme obojí.
Je vidět, že konečná šířka sítě Clos je součinem všech úrovní páteřních přepínačů jižního radixu, kolik spojů máme dole, jak se větví. Takto škálujeme velikost sítě.
Pokud jde o kapacitu, zejména u přepínačů ToR, existují dvě možnosti škálování. Buď můžeme při zachování obecné topologie použít rychlejší spoje, nebo můžeme přidat další roviny.
Pokud se podíváte na rozšířenou verzi sítě Clos (v pravém dolním rohu) a vrátíte se na tento obrázek se sítí Clos níže...
... pak je to úplně stejná topologie, ale na tomto snímku je zhroucená kompaktněji a roviny továrny jsou na sebe navrstveny. To je to samé.
Jak vypadá škálování sítě Clos v číslech? Zde uvádím údaje o tom, jakou maximální šířku lze získat síť, jaký maximální počet racků, ToR přepínačů nebo listových přepínačů, pokud nejsou v rackech, můžeme získat podle toho, jaký radix přepínačů používáme pro páteřní úrovně a kolik úrovní používáme.
Zde je, kolik racků můžeme mít, kolik serverů a kolik to všechno může spotřebovat na základě 20 kW na rack. O něco dříve jsem zmínil, že cílíme na velikost clusteru zhruba 100 tisíc serverů.
Je vidět, že v celém tomto provedení je zájem o dvě a půl možnosti. K dispozici je možnost se dvěma vrstvami hřbetů a 64portovými přepínači, což je trochu málo. Pak jsou tu perfektně padnoucí možnosti pro 128portové (s radix 128) páteřní přepínače se dvěma úrovněmi nebo přepínače s radix 32 se třemi úrovněmi. A ve všech případech, kde je více radixů a více vrstev, můžete vytvořit velmi rozsáhlou síť, ale pokud se podíváte na očekávanou spotřebu, obvykle jsou tam gigawatty. Je možné položit kabel, ale je nepravděpodobné, že bychom získali tolik elektřiny na jednom místě. Pokud se podíváte na statistiky a veřejná data o datových centrech, najdete jen velmi málo datových center s odhadovanou kapacitou vyšší než 150 MW. Ty větší jsou obvykle kampusy datových center, několik velkých datových center umístěných docela blízko sebe.
Je tu ještě jeden důležitý parametr. Pokud se podíváte do levého sloupce, je tam uvedena využitelná šířka pásma. Je snadné vidět, že v síti Clos se významná část portů používá k vzájemnému propojení přepínačů. Použitelná šířka pásma, užitečný pás, je něco, co lze poskytnout venku, směrem k serverům. Přirozeně mluvím o podmíněných portech a konkrétně o kapele. Odkazy v rámci sítě jsou zpravidla rychlejší než odkazy na servery, ale na jednotku šířky pásma, pokud ji můžeme poslat do našeho serverového zařízení, stále existuje určitá šířka pásma v rámci samotné sítě. A čím více úrovní uděláme, tím vyšší budou specifické náklady na poskytnutí tohoto pruhu ven.
Navíc ani toto doplňkové pásmo není úplně stejné. Zatímco rozpětí jsou krátká, můžeme použít něco jako DAC (direct attachment měděné, tedy twinaxové kabely), nebo multimode optiku, která stojí ještě více či méně rozumné peníze. Jakmile přejdeme na delší rozpětí - zpravidla se jedná o optiku s jedním režimem a náklady na tuto dodatečnou šířku pásma znatelně rostou.
A znovu, když se vrátíme k předchozímu snímku, pokud vytvoříme síť Clos bez nadměrného předplatného, pak je snadné se podívat na schéma, vidět, jak je síť postavena - přidáním každé úrovně páteřních spínačů opakujeme celý pás, který byl na dno. Plus úroveň - plus stejné pásmo, stejný počet portů na přepínačích jako na předchozí úrovni a stejný počet transceiverů. Proto je vysoce žádoucí minimalizovat počet úrovní spínačů páteře.
Na základě tohoto obrázku je jasné, že opravdu chceme stavět na něčem, jako jsou přepínače s radixem 128.
Zde je v zásadě vše stejné, jak jsem právě řekl, toto je snímek ke zvážení později.
Jaké jsou možnosti, které si můžeme vybrat jako takové přepínače? Je pro nás velmi příjemnou zprávou, že nyní lze takové sítě konečně stavět na jednočipových přepínačích. A to je velmi cool, mají spoustu pěkných funkcí. Například nemají téměř žádnou vnitřní strukturu. To znamená, že se snadněji rozbijí. Rozbijí se všelijak, ale naštěstí se rozbijí úplně. U modulárních zařízení je velké množství závad (velmi nepříjemné), kdy se z pohledu sousedů a řídicí roviny zdá, že funguje, ale například se ztratila část tkaniny a nefunguje na plnou kapacitu. A provoz na něj je vyvážený na základě toho, že je plně funkční a můžeme se přetěžovat.
Nebo například nastávají problémy s backplane, protože uvnitř modulárního zařízení jsou také vysokorychlostní SerDes - to je uvnitř opravdu složité. Buď jsou znaky mezi předávacími prvky synchronizovány nebo nesynchronizovány. Obecně platí, že jakékoli produktivní modulární zařízení sestávající z velkého počtu prvků zpravidla obsahuje stejnou síť Clos uvnitř sebe, ale je velmi obtížné ji diagnostikovat. Často je obtížné i pro samotného prodejce diagnostikovat.
A má velké množství scénářů selhání, ve kterých zařízení degraduje, ale zcela nevypadne z topologie. Vzhledem k tomu, že naše síť je velká, aktivně se využívá balancování mezi identickými prvky, síť je velmi pravidelná, to znamená, že jedna cesta, na které je vše v pořádku, se neliší od cesty druhé, je pro nás výhodnější o část jednoduše přijít. zařízení z topologie, než aby se dostali do situace, kdy se zdá, že některá fungují, ale některá ne.
Další příjemnou vlastností jednočipových zařízení je, že se vyvíjejí lépe a rychleji. Mívají také lepší kapacitu. Pokud vezmeme velké sestavené struktury, které máme na kruhu, pak je kapacita na jednotku racku pro porty stejné rychlosti téměř dvakrát vyšší než u modulárních zařízení. Zařízení postavená na jediném čipu jsou znatelně levnější než modulární a spotřebovávají méně energie.
Ale to vše je samozřejmě z nějakého důvodu, jsou zde i nevýhody. Za prvé, radix je téměř vždy menší než u modulárních zařízení. Pokud se nám podaří získat zařízení postavené na jednom čipu se 128 porty, můžeme nyní bez problémů získat modulární zařízení s několika stovkami portů.
Jedná se o znatelně menší velikost předávacích tabulek a zpravidla vše, co souvisí se škálovatelností datové roviny. Mělké nárazníky. A zpravidla spíše omezená funkčnost. Ukazuje se však, že pokud tato omezení znáte a včas se postaráte o to, abyste je obešli nebo je prostě vzali v úvahu, pak to není tak děsivé. To, že je radix menší, už není problém na zařízeních s radixem 128, které se nedávno objevily, můžeme zabudovat dvě vrstvy hřbetů. Ale stále je nemožné postavit něco menšího než dva, co je pro nás zajímavé. S jednou úrovní se získají velmi malé shluky. I naše předchozí návrhy a požadavky je stále převyšovaly.
Ve skutečnosti, pokud je náhle řešení někde na hraně, stále existuje způsob, jak škálovat. Vzhledem k tomu, že poslední (nebo první), nejnižší úrovní, kde jsou servery připojeny, jsou přepínače ToR nebo listové přepínače, nemusíme k nim připojovat jeden rack. Pokud tedy řešení zaostává zhruba o polovinu, můžete uvažovat o prostém použití přepínače s velkým radixem na spodní úrovni a propojení například dvou nebo tří racků do jednoho přepínače. To je také možnost, má to své náklady, ale funguje to docela dobře a může to být dobré řešení, když potřebujete dosáhnout asi dvojnásobné velikosti.
Abychom to shrnuli, stavíme na topologii se dvěma úrovněmi páteře s osmi továrními vrstvami.
Co se stane s fyzikou? Velmi jednoduché výpočty. Máme-li dvě úrovně páteře, pak máme pouze tři úrovně přepínačů a očekáváme, že v síti budou tři kabelové segmenty: od serverů po listové přepínače, přes páteř 1 až po páteř 2. Možnosti, které můžeme použití jsou - jedná se o twinax, multimode, single mode. A zde musíme zvážit, jaký pás je k dispozici, kolik to bude stát, jaké jsou fyzické rozměry, jaká rozpětí můžeme pokrýt a jak budeme upgradovat.
Co se týče nákladů, vše se dá nalinkovat. Twinaxy jsou výrazně levnější než aktivní optika, levnější než multimódové transceivery, když to vezmete za let od konce, o něco levnější než 100gigabitový switch port. A mějte na paměti, že to stojí méně než optika s jedním režimem, protože na letech, kde je vyžadován jeden režim, má v datových centrech z mnoha důvodů smysl používat CWDM, zatímco paralelní režim s jedním režimem (PSM) není příliš vhodný pro práci. s velmi velkými balíky vláken, a pokud se zaměříme na tyto technologie, dostaneme přibližně následující cenovou hierarchii.
Ještě jedna poznámka: bohužel není moc možné použít rozložené 100 až 4x25 multimode porty. Vzhledem ke konstrukčním vlastnostem transceiverů SFP28 není o mnoho levnější než 28 Gbit QSFP100. A tato demontáž pro multimode moc nefunguje.
Dalším omezením je, že vzhledem k velikosti výpočetních clusterů a počtu serverů jsou naše datová centra fyzicky velká. To znamená, že alespoň jeden let bude muset být proveden s singlemodem. Opět, kvůli fyzické velikosti podů, nebude možné vést dvě rozpětí twinaxu (měděné kabely).
Ve výsledku, pokud optimalizujeme na cenu a vezmeme v úvahu geometrii tohoto návrhu, dostaneme jeden rozsah twinaxu, jeden rozsah multimode a jeden rozsah singlemode pomocí CWDM. To bere v úvahu možné cesty upgradu.
Tak to v poslední době vypadá, kam směřujeme a co je možné. Je přinejmenším jasné, jak přejít k 50gigabitovým SerDes pro multimode i singlemode. Navíc, když se podíváte na to, co je v singlemode transceiverech nyní a v budoucnu pro 400G, často i když 50G SerDes dorazí z elektrické strany, 100 Gbps na pruh už může jít do optiky. Je tedy dost možné, že místo přechodu na 50 dojde k přechodu na 100 Gigabit SerDes a 100 Gbps na pruh, protože podle slibů mnoha prodejců se jejich dostupnost očekává poměrně brzy. Období, kdy byly 50G SerDes nejrychlejší, zdá se, nebude příliš dlouhé, protože první kopie 100G SerDes budou uvedeny téměř příští rok. A po nějaké době poté budou pravděpodobně stát za rozumné peníze.
Ještě jedna nuance o výběru fyziky. V zásadě již můžeme používat 400 nebo 200 gigabitových portů pomocí 50G SerDes. Ale ukazuje se, že to nedává moc smysl, protože, jak jsem řekl dříve, chceme na přepínačích poměrně velký radix, samozřejmě v rozumných mezích. Chceme 128. A pokud máme omezenou kapacitu čipu a zvýšíme rychlost linky, tak ten radix přirozeně klesá, žádné zázraky se nekonají.
A můžeme zvýšit celkovou kapacitu pomocí letadel a nejsou žádné zvláštní náklady, můžeme přidat počet letadel. A pokud přijdeme o radix, budeme muset zavést další úroveň, takže v současné situaci se současnou maximální dostupnou kapacitou na čip ukazuje, že je efektivnější používat 100gigabitové porty, protože umožňují získat větší radix.
Další otázkou je, jak je organizována fyzika, ale z pohledu kabelové infrastruktury. Ukazuje se, že je to organizováno docela vtipným způsobem. Kabeláž mezi listovými přepínači a páteřáky první úrovně - tam není mnoho vazeb, vše je postaveno relativně jednoduše. Ale pokud vezmeme jednu rovinu, stane se uvnitř to, že potřebujeme propojit všechny páteře první úrovně se všemi páteřemi druhé úrovně.
Navíc jsou zde zpravidla nějaká přání, jak by to mělo uvnitř datového centra vypadat. Například jsme opravdu chtěli zkombinovat kabely do svazku a zatáhnout je tak, aby jeden patch panel s vysokou hustotou šel celý do jednoho patch panelu, takže z hlediska délek nevznikla žádná zoo. Tento problém se nám podařilo vyřešit. Pokud se zpočátku podíváte na logickou topologii, můžete vidět, že roviny jsou nezávislé, každá rovina může být postavena samostatně. Ale když přidáme takový svazek a chceme přetáhnout celý patch panel do patch panelu, musíme smíchat různé roviny uvnitř jednoho svazku a zavést mezilehlou strukturu ve formě optických křížových spojení, abychom je znovu zabalili z toho, jak byly sestaveny. v jednom segmentu, jak budou shromažďovány v jiném segmentu. Díky tomu získáme příjemnou vlastnost: veškeré složité přepínání nepřesahuje rámec stojanů. Když potřebujete něco velmi silně proplést, „rozvinout roviny“, jak se tomu někdy v sítích Clos říká, vše se soustředí v jednom racku. Nemáme vysoce rozebrané, až po jednotlivé články, přepínání mezi stojany.
Tak to vypadá z pohledu logické organizace kabelové infrastruktury. Na obrázku vlevo různobarevné bloky zobrazují bloky páteřních spínačů první úrovně, každý po osmi kusech, a čtyři svazky kabelů vycházející z nich, které jdou a protínají se svazky vycházejícími z bloků páteřních přepínačů-2. .
Malé čtverečky označují průsečíky. Vlevo nahoře je rozpis každého takového průsečíku, jedná se ve skutečnosti o 512 x 512 port cross-connect modul, který přebalí kabely tak, aby se zcela dostaly do jednoho racku, kde je pouze jedna páteř-2 rovina. A napravo je sken tohoto obrázku o něco podrobnější ve vztahu k několika modulům na úrovni páteře-1 a jak je zabalen do křížového spojení, jak se dostane k úrovni páteře-2.
Takhle to vypadá. Ještě ne zcela smontovaný stojan páteře-2 (vlevo) a křížový stojan. Bohužel tam toho moc k vidění není. Celá tato struktura je právě nyní nasazována v jednom z našich velkých datových center, které se rozšiřuje. Tohle je nedokončená práce, bude to vypadat lépe, bude se to lépe plnit.
Důležitá otázka: vybrali jsme logickou topologii a postavili fyziku. Co se stane s řídicím letadlem? Z provozních zkušeností je to docela dobře známé, existuje řada zpráv, že protokoly link state jsou dobré, je radost s nimi pracovat, ale bohužel se špatně škálují na hustě propojené topologii. A je tu jeden hlavní faktor, který tomu brání – takto funguje záplava v protokolech stavu spojení. Pokud si vezmete zaplavovací algoritmus a podíváte se, jak je naše síť strukturována, uvidíte, že na každém kroku bude velmi velký fanout a jednoduše to zaplaví řídicí rovinu aktualizacemi. Konkrétně se takové topologie velmi špatně mísí s tradičním zaplavovacím algoritmem v protokolech stavu spojení.
Na výběr je použít BGP. Jak jej správně připravit je popsáno v RFC 7938 o použití BGP ve velkých datových centrech. Základní myšlenky jsou jednoduché: minimální počet prefixů na hostitele a obecně minimální počet prefixů v síti, pokud je to možné, použijte agregaci a potlačte hledání cesty. Chceme velmi pečlivou, velmi kontrolovanou distribuci aktualizací, čemu se říká valley free. Chceme, aby aktualizace byly nasazeny přesně jednou při průchodu sítí. Pokud pocházejí ze dna, jdou nahoru a nerozvinou se více než jednou. Neměly by existovat žádné kličkování. Cikcak je velmi špatný.
K tomu používáme návrh, který je dostatečně jednoduchý, aby mohl používat základní mechanismy BGP. To znamená, že používáme eBGP běžící na link local a autonomní systémy jsou přiřazeny následovně: autonomní systém na ToR, autonomní systém na celém bloku spine-1 přepínačů jednoho Podu a obecný autonomní systém na celém Top z látky. Není těžké se podívat a vidět, že i normální chování BGP nám poskytuje distribuci aktualizací, které chceme.
Přirozeně, adresování a agregace adres musí být navrženy tak, aby byly kompatibilní se způsobem, jakým je směrování vytvořeno, aby byla zajištěna stabilita řídicí roviny. L3 adresování v transportu je svázáno s topologií, protože bez ní nelze dosáhnout agregace, bez toho se jednotlivé adresy vkrádají do směrovacího systému. A ještě jedna věc je, že agregace se bohužel moc nemíchá s vícecestnou, protože když máme vícecestnou a máme agregaci, je vše v pořádku, když je celá síť zdravá, nedochází v ní k výpadkům. Bohužel, jakmile se v síti objeví poruchy a ztratí se symetrie topologie, můžeme dojít k bodu, ze kterého byla jednotka oznámena, ze kterého nemůžeme jít dál, kam potřebujeme. Proto je nejlepší agregovat tam, kde není další multi-path, v našem případě to jsou ToR switche.
Ve skutečnosti je možné agregovat, ale opatrně. Pokud můžeme provést řízenou dezagregaci, když dojde k selhání sítě. Ale to je docela obtížný úkol, dokonce nás zajímalo, jestli by to bylo možné udělat, jestli by bylo možné přidat další automatizaci a konečné automaty, které by správně nakoply BGP, aby získal požadované chování. Zpracování rohových pouzder je bohužel velmi nesrozumitelné a složité a tento úkol není dobře vyřešen připojením externích příloh k BGP.
V rámci protokolu RIFT byla v tomto ohledu odvedena velmi zajímavá práce, o které bude pojednáno v příští zprávě.
Další důležitou věcí je, jak se datové roviny škálují v hustých topologiích, kde máme velké množství alternativních cest. V tomto případě se používá několik dalších datových struktur: ECMP skupiny, které zase popisují skupiny Next Hop.
V normálně fungující síti bez poruch, když jdeme nahoru po topologii Clos, stačí použít jen jednu skupinu, protože vše, co není lokální, je standardně popsáno, můžeme nahoru. Když jdeme shora dolů na jih, pak všechny cesty nejsou ECMP, jsou to jednotlivé cesty. Vše je v pořádku. Problém je a zvláštností klasické topologie Clos je to, že pokud se podíváme na vrchol tkaniny, na jakýkoli prvek, existuje pouze jedna cesta k libovolnému prvku níže. Pokud na této cestě dojde k selhání, pak se tento konkrétní prvek v horní části továrny stane neplatným právě pro ty předpony, které leží za přerušenou cestou. Ale pro zbytek to platí a musíme analyzovat skupiny ECMP a zavést nový stav.
Jak vypadá škálovatelnost datové roviny na moderních zařízeních? Pokud uděláme LPM (nejdelší shoda prefixů), vše je docela dobré, přes 100k prefixů. Pokud se bavíme o skupinách Next Hop, tak vše je horší, 2-4 tisíce. Pokud mluvíme o tabulce, která obsahuje popis Next Hops (nebo přilehlosti), pak je to někde od 16k do 64k. A to se může stát problémem. A tady se dostáváme k zajímavé odbočce: co se stalo s MPLS v datových centrech? V zásadě jsme to chtěli udělat.
Staly se dvě věci. Provedli jsme mikrosegmentaci na hostitelích, už jsme to nemuseli dělat na síti. Nebylo to příliš dobré s podporou od různých dodavatelů a ještě více s otevřenými implementacemi na bílých krabicích s MPLS. A MPLS, alespoň jeho tradiční implementace, se bohužel velmi špatně kombinuje s ECMP. A právě proto.
Takto vypadá struktura předávání ECMP pro IP. Velké množství prefixů může používat stejnou skupinu a stejný blok Next Hops (nebo sousedství, to může být v různé dokumentaci pro různá zařízení nazýváno odlišně). Jde o to, že toto je popsáno jako odchozí port a na co přepsat MAC adresu, abyste se dostali na správný Next Hop. Pro IP vše vypadá jednoduše, můžete použít velmi velký počet prefixů pro stejnou skupinu, stejný blok Next Hops.
Klasická architektura MPLS znamená, že v závislosti na odchozím rozhraní lze štítek přepsat na různé hodnoty. Proto musíme pro každý vstupní štítek zachovat skupinu a blok Next Hops. A to se bohužel neškáluje.
Je snadné vidět, že v našem návrhu jsme potřebovali asi 4000 přepínačů ToR, maximální šířka byla 64 cest ECMP, pokud se posuneme od páteře-1 směrem ke páteři-2. Sotva se dostaneme do jedné tabulky skupin ECMP, pokud zmizí pouze jedna předpona s ToR, a vůbec se nedostaneme do tabulky Next Hops.
Není to všechno beznadějné, protože architektury jako Segment Routing zahrnují globální značky. Formálně by bylo možné všechny tyto bloky Next Hops znovu sbalit. Chcete-li to provést, potřebujete operaci typu zástupný znak: vezměte štítek a přepište jej na stejný bez konkrétní hodnoty. To se ale bohužel v dostupných implementacích příliš nevyskytuje.
A nakonec musíme do datového centra přivést externí provoz. Jak to udělat? Dříve byl provoz zaveden do sítě Clos shora. To znamená, že existovaly okrajové směrovače, které se připojovaly ke všem zařízením v horní části tkaniny. Toto řešení funguje docela dobře na malých až středních velikostech. Bohužel, abychom takto symetricky posílali provoz do celé sítě, potřebujeme dorazit současně na všechny prvky Top of fabric, a když jich je více než sto, ukáže se, že potřebujeme i velký radix na okrajových routerech. Obecně to stojí peníze, protože okrajové směrovače jsou funkčnější, porty na nich budou dražší a design není příliš krásný.
Další možností je spustit takový provoz zdola. Je snadné ověřit, že topologie Clos je postavena tak, že provoz přicházející zespodu, tedy ze strany ToR, je rovnoměrně rozložen mezi úrovně po celém Top of fabric ve dvou iteracích, zatěžujících celou síť. Proto představujeme speciální typ Pod, Edge Pod, který poskytuje externí konektivitu.
Je tu ještě jedna možnost. To dělá například Facebook. Říkají tomu Fabric Aggregator nebo HGRID. Zavádí se další úroveň páteře pro propojení více datových center. Tento návrh je možný, pokud nemáme další funkce nebo změny zapouzdření na rozhraních. Pokud jsou to další dotykové body, je to obtížné. Typicky je zde více funkcí a jakási membrána oddělující různé části datového centra. Nemá smysl dělat takovou membránu velkou, ale pokud je to z nějakého důvodu opravdu potřeba, pak má smysl uvažovat o možnosti ji odvézt, udělat ji co nejširší a přenést na hostitele. Dělá to například mnoho cloudových operátorů. Mají přesilovky, začínají od domácích.
Jaké vidíme možnosti rozvoje? Za prvé, zlepšení podpory pro pipeline CI/CD. Chceme létat tak, jak testujeme a testujeme, jak létáme. To se moc nedaří, protože infrastruktura je velká a není možné ji pro testy duplikovat. Musíte pochopit, jak zavést testovací prvky do produkční infrastruktury, aniž byste ji opustili.
Lepší přístrojové vybavení a lepší monitorování nejsou téměř nikdy nadbytečné. Celá otázka je rovnováha mezi úsilím a návratem. Pokud to můžete přidat s rozumným úsilím, velmi dobře.
Otevřené operační systémy pro síťová zařízení. Lepší protokoly a lepší směrovací systémy, jako je RIFT. Je také zapotřebí výzkum v oblasti používání lepších schémat kontroly přetížení a možná zavedení, alespoň v některých bodech, podpory RDMA v rámci klastru.
Podíváme-li se dále do budoucnosti, potřebujeme pokročilé topologie a možná sítě, které využívají méně režie. Z novinek se v poslední době objevily publikace o technologii tkaniny pro HPC Cray Slingshot, která je založena na komoditním Ethernetu, ale s možností použití mnohem kratších hlaviček. V důsledku toho se režie snižuje.
Vše by mělo být co nejjednodušší, ale ne jednodušší. Složitost je nepřítelem škálovatelnosti. Jednoduchost a pravidelné struktury jsou našimi přáteli. Pokud můžete někde škálovat, udělejte to. A obecně je skvělé být nyní zapojen do síťových technologií. Děje se spousta zajímavých věcí. Děkuji.
Zdroj: www.habr.com