Moderní datová centra mají nainstalované stovky aktivních zařízení pokrytých různými typy monitorování. Ale i ideální inženýr s dokonalým monitorováním v ruce bude schopen správně reagovat na výpadek sítě během několika minut. Ve zprávě na konferenci Next Hop 2020 jsem představil metodiku návrhu DC sítě, která má unikátní vlastnost – datové centrum se samo uzdraví v milisekundách. Přesněji řečeno, inženýr problém klidně opraví, zatímco služby si toho jednoduše nevšimnou.
Pro mnoho síťových inženýrů začíná síť datových center samozřejmě u ToR, u přepínače v racku. ToR má obvykle dva typy odkazů. Ty malé jdou na servery, další - je jich N krát více - jdou směrem k páteřím první úrovně, tedy k jejím uplinkům. Uplinky jsou obvykle považovány za rovnocenné a provoz mezi uplinky je vyvážený na základě hash z 5-ti, který zahrnuje proto, src_ip, dst_ip, src_port, dst_port. Tady žádné překvapení.
Dále, jak vypadá architektura plánu? Hřbety první úrovně nejsou vzájemně propojeny, ale jsou propojeny superspiny. Písmeno X bude zodpovědné za superspiny, je to skoro jako křížové propojení.
A je jasné, že na druhou stranu jsou tori spojeni se všemi páteřemi první úrovně. Co je na tomto obrázku důležité? Pokud máme interakci uvnitř racku, pak interakce samozřejmě prochází ToR. Pokud k interakci dochází uvnitř modulu, pak k interakci dochází prostřednictvím páteří první úrovně. Pokud je interakce intermodulární - jako zde ToR 1 a ToR 2 - pak interakce projde páteří první i druhé úrovně.
Teoreticky je taková architektura snadno škálovatelná. Pokud máme kapacitu portů, volné místo v datovém centru a předem položené vlákno, pak lze počet pruhů vždy zvýšit, a tím zvýšit celkovou kapacitu systému. Na papíře je to velmi snadné. V životě by to tak bylo. O tom ale dnešní příběh není.
Chci, aby byly vyvozeny správné závěry. Uvnitř datového centra máme mnoho cest. Jsou podmíněně nezávislé. Jedna cesta uvnitř datového centra je možná pouze uvnitř ToR. Uvnitř modulu máme počet cest rovný počtu pruhů. Počet drah mezi moduly se rovná součinu počtu rovin a počtu superspinů v každé rovině. Aby to bylo jasnější, abych získal představu o měřítku, uvedu čísla, která jsou platná pro jedno z datových center Yandex.
Existuje osm rovin, každé letadlo má 32 superspinů. Výsledkem je, že uvnitř modulu je osm cest a při intermodulové interakci je jich již 256.
To znamená, že pokud vyvíjíme Cookbook a snažíme se naučit, jak budovat datová centra odolná proti chybám, která se sama uzdraví, pak je planární architektura tou správnou volbou. Řeší problém škálování a teoreticky je to snadné. Existuje mnoho nezávislých cest. Otázkou zůstává: jak taková architektura přežije selhání? Dochází k různým selháním. A o tom teď budeme diskutovat.
Nechte jednu z našich superspine „onemocnět“. Zde jsem se vrátil k architektuře dvou rovin. Zůstaneme u těchto příkladů, protože s menším počtem pohyblivých částí bude jednoduše snazší vidět, co se děje. Ať X11 onemocní. Jak to ovlivní služby, které žijí uvnitř datových center? Hodně záleží na tom, jak vlastně selhání vypadá.
Pokud je porucha dobrá, je zachycena na úrovni automatizace stejného BFD, automatika šťastně umístí problematické spoje a izoluje problém, pak je vše v pořádku. Máme mnoho cest, provoz je okamžitě přesměrován na alternativní trasy a služby si ničeho nevšimnou. Tohle je dobrý scénář.
Špatný scénář je, pokud máme neustálé ztráty a automatizace si problému nevšimne. Abychom pochopili, jak to ovlivňuje aplikaci, budeme muset strávit trochu času diskusí o tom, jak TCP funguje.
Doufám, že touto informací nikoho nešokuji: TCP je protokol pro potvrzení přenosu. To znamená, že v nejjednodušším případě odesílatel odešle dva pakety a obdrží na ně kumulativní potvrzení: „Přijal jsem dva pakety.
Poté odešle další dva pakety a situace se bude opakovat. Předem se omlouvám za určité zjednodušení. Tento scénář je správný, pokud je okno (počet paketů v letu) dva. V obecném případě tomu tak samozřejmě nemusí být. Ale velikost okna neovlivňuje kontext předávání paketů.
Co se stane, když ztratíme paket 3? V tomto případě příjemce obdrží pakety 1, 2 a 4. A výslovně sdělí odesílateli pomocí možnosti SACK: „Víte, tři dorazily, ale prostřední se ztratil.“ Říká: "Ack 2, SACK 4."
V tuto chvíli odesílatel bez problémů zopakuje právě ztracený paket.
Pokud se ale ztratí poslední paket v okně, bude situace vypadat úplně jinak.
Příjemce obdrží první tři pakety a nejprve začne čekat. Díky některým optimalizacím v TCP stacku linuxového jádra bude čekat na spárovaný paket, pokud příznaky výslovně neindikují, že se jedná o poslední paket nebo něco podobného. Počká, dokud nevyprší časový limit Delayed ACK, a poté odešle potvrzení o prvních třech paketech. Nyní ale odesílatel počká. Neví, zda se čtvrtý balíček ztratil nebo má dorazit. A aby nedošlo k přetížení sítě, pokusí se počkat na výslovnou indikaci ztráty paketu nebo na vypršení časového limitu RTO.
Co je časový limit RTO? Toto je maximum RTT vypočítané zásobníkem TCP a nějakou konstantou. Co je to za konstantu, si nyní probereme.
Důležité ale je, že pokud budeme mít opět smůlu a čtvrtý paket se opět ztratí, tak se RTO zdvojnásobí. To znamená, že každý neúspěšný pokus znamená zdvojnásobení časového limitu.
Nyní se podívejme, čemu se tato základna rovná. Ve výchozím nastavení je minimální RTO 200 ms. Toto je minimální RTO pro datové balíčky. U paketů SYN je to jiné, 1 sekunda. Jak vidíte, i první pokus o opětovné odeslání paketů bude trvat 100krát déle než RTT uvnitř datového centra.
Nyní se vraťme k našemu scénáři. Co se děje se službou? Služba začne ztrácet pakety. Nechte službu mít nejprve podmíněně štěstí a něco ztratí uprostřed okna, pak obdrží SACK a znovu odešle pakety, které byly ztraceny.
Pokud se ale smůla bude opakovat, pak máme RTO. Co je zde důležité? Ano, v naší síti máme spoustu cest. Ale TCP provoz jednoho konkrétního TCP spojení bude i nadále procházet stejným poškozeným zásobníkem. Ztráty paketů za předpokladu, že tato naše kouzelná X11 sama nezhasne, nepovedou k proudění provozu do oblastí, které nejsou problematické. Snažíme se doručit balíček přes stejnou rozbitou sadu. To vede ke kaskádovému selhání: datové centrum je sada vzájemně se ovlivňujících aplikací a některá z TCP spojení všech těchto aplikací začnou degradovat – protože superspine ovlivňuje všechny aplikace, které existují uvnitř datového centra. Jak se říká: když jsi koně nepodkovál, kůň zkulhal; kůň kulhal - zpráva nebyla doručena; zpráva nebyla doručena - prohráli jsme válku. Pouze zde je počet v sekundách od okamžiku, kdy problém nastane, do stadia degradace, kterou služby začnou pociťovat. To znamená, že uživatelům může někde něco chybět.
Existují dvě klasická řešení, která se vzájemně doplňují. První jsou služby, které se snaží vložit stébla a vyřešit problém takto: „Pojďme něco vyladit v TCP stacku. Udělejme časové limity na úrovni aplikace nebo dlouhodobé relace TCP s interními kontrolami stavu." Problém je, že taková řešení: a) vůbec neškálují; b) jsou velmi špatně kontrolovány. To znamená, že i když služba náhodně nakonfiguruje zásobník TCP tak, aby byl lepší, za prvé je nepravděpodobné, že bude použitelný pro všechny aplikace a všechna datová centra, a za druhé, s největší pravděpodobností nepochopí, že to bylo provedeno. správně a co ne. To znamená, že to funguje, ale funguje to špatně a neškáluje se. A pokud dojde k problému se sítí, kdo za to může? Samozřejmě NOC. Co dělá NOC?
Mnoho služeb věří, že v práci NOC se něco takového děje. Ale abych byl upřímný, nejen to.
NOC v klasickém schématu se zabývá vývojem mnoha monitorovacích systémů. Jedná se o monitorování černé i bílé skříňky. O příkladu sledování páteře černé skříňky Alexander Klimenko na posledním Next Hop. Mimochodem, tento monitoring funguje. Ale i ideální sledování bude mít časovou prodlevu. Obvykle je to několik minut. Poté, co zhasne, inženýři ve službě potřebují čas, aby znovu zkontrolovali jeho fungování, lokalizovali problém a poté uhasili problémovou oblast. To znamená, že v nejlepším případě léčba problému trvá 5 minut, v nejhorším případě 20 minut, pokud není hned zřejmé, kde ke ztrátám dochází. Je jasné, že celou tu dobu – 5 nebo 20 minut – budou naše služby nadále trpět, což pravděpodobně není dobré.
Co byste opravdu rádi dostali? Máme tolik způsobů. A problémy vznikají právě proto, že toky TCP, které nemají štěstí, nadále používají stejnou trasu. Potřebujeme něco, co nám umožní používat více tras v rámci jednoho TCP spojení. Zdálo by se, že máme řešení. Existuje TCP, který se nazývá multipath TCP, tedy TCP pro více cest. Je pravda, že byl vyvinut pro úplně jiný úkol - pro smartphony, které mají několik síťových zařízení. Pro maximalizaci přenosu nebo vytvoření primárního/záložního režimu byl vyvinut mechanismus, který vytváří pro aplikaci transparentně více vláken (relací) a umožňuje mezi nimi přepínat v případě selhání. Nebo, jak jsem řekl, maximalizovat pruh.
Ale je tu nuance. Abychom pochopili, co to je, budeme se muset podívat na to, jak se zakládají vlákna.
Vlákna jsou instalována postupně. První vlákno je nainstalováno jako první. Následující vlákna jsou pak nastavena pomocí cookie, která již byla v rámci daného vlákna dohodnuta. A tady je problém.
Problém je v tom, že pokud se první vlákno nezaloží, druhé a třetí vlákno nikdy nevznikne. To znamená, že vícecestný TCP neřeší ztrátu paketu SYN v prvním toku. A pokud dojde ke ztrátě SYN, vícecestný TCP se změní na běžný TCP. To znamená, že v prostředí datového centra nám nepomůže vyřešit problém ztrát v továrně a naučit se používat více cest v případě poruchy.
Co nám může pomoci? Někteří z vás již z názvu uhodli, že důležitým polem v našem dalším příběhu bude pole záhlaví štítku toku IPv6. Ve skutečnosti se jedná o pole, které se objevuje ve v6, není ve v4, zabírá 20 bitů a o jeho použití se dlouho vedou spory. To je velmi zajímavé – docházelo ke sporům, něco se opravovalo v rámci RFC a zároveň se v linuxovém jádře objevila implementace, která nebyla nikde zdokumentována.
Zvu vás, abyste šel se mnou na malý průzkum. Pojďme se podívat na to, co se dělo v linuxovém jádře za posledních pár let.
rok 2014. Inženýr z jedné velké a respektované společnosti přidává k funkčnosti linuxového jádra závislost hodnoty flow label na hash socketu. Co se tu snažili opravit? To souvisí s RFC 6438, který pojednával o následujícím problému. Uvnitř datového centra je IPv4 často zapouzdřeno do IPv6 paketů, protože samotná továrna je IPv6, ale IPv4 se musí nějak dát ven. Dlouhou dobu byly problémy s přepínači, které se nedokázaly pod dvěma IP hlavičkami dostat na TCP nebo UDP a najít tam src_ports, dst_ports. Ukázalo se, že hash, pokud se podíváte na první dvě IP hlavičky, se ukázal být téměř opravený. Aby se tomu zabránilo a aby vyvážení tohoto zapouzdřeného provozu fungovalo správně, bylo navrženo přidat hash 5-ti zapouzdřeného paketu k hodnotě pole označení toku. Přibližně totéž bylo provedeno pro další schémata zapouzdření, pro UDP, pro GRE, druhý použil pole GRE Key. Tak či onak jsou zde cíle jasné. A alespoň v té době byly užitečné.
V roce 2015 přichází nový patch od stejného respektovaného inženýra. Je velmi zajímavý. Říká to následující - v případě negativní události směrování budeme hash randomizovat. Co je negativní směrovací událost? Toto je RTO, o kterém jsme hovořili dříve, to znamená, že ztráta ocasu okna je událost, která je skutečně negativní. Pravda, je poměrně těžké uhodnout, že to je ono.
2016, další renomovaná společnost, také velká. Rozebere poslední berličky a udělá to tak, že hash, který jsme dříve dělali náhodně, se nyní mění při každém opětovném přenosu SYN a po každém timeoutu RTO. A v tomto dopise je poprvé a naposledy uveden konečný cíl – zajistit, aby provoz v případě ztrát nebo přetížení kanálu měl možnost jemně přesměrovat a používat více cest. Samozřejmě, že poté bylo mnoho publikací, můžete je snadno najít.
I když ne, nemůžete, protože na toto téma nebyla vydána jediná publikace. Ale my víme!
A pokud úplně nerozumíte tomu, co se stalo, řeknu vám to teď.
Co se udělalo, jaké funkce byly přidány do jádra Linuxu? txhash se po každé události RTO změní na náhodnou hodnotu. To je velmi negativní výsledek směrování. Hash závisí na tomto txhash a štítek toku závisí na hash skb. Jsou zde některé výpočty funkcí, všechny detaily nelze umístit na jeden snímek. Pokud je někdo zvědavý, můžete si projít kód jádra a zkontrolovat.
Co je zde důležité? Hodnota pole popisku toku se po každém RTO změní na náhodné číslo. Jak to ovlivní náš nešťastný TCP stream?
Pokud dojde k SACK, nic se nezmění, protože se pokoušíme znovu odeslat známý ztracený paket. Zatím je vše dobré.
Ale v případě RTO, za předpokladu, že jsme k hashovací funkci na ToR přidali štítek toku, může provoz probíhat jinou cestou. A čím více pruhů, tím větší je šance, že najde cestu, která není ovlivněna poruchou na konkrétním zařízení.
Jeden problém zůstává - RTO. Samozřejmě existuje i jiná trasa, ale tím se ztrácí spousta času. 200 ms je hodně. Vteřina je naprosto divoká. Dříve jsem mluvil o časových limitech, kdy jsou služby konfigurovány. Vteřina je tedy časový limit, který je obvykle konfigurován službou na úrovni aplikace a v tomto bude služba dokonce relativně správná. Navíc opakuji, skutečná RTT v moderním datovém centru je kolem 1 milisekundy.
Co můžete dělat s časovými limity RTO? Timeout, který je zodpovědný za RTO v případě ztráty datových paketů, lze poměrně snadno nakonfigurovat z uživatelského prostoru: existuje utilita IP a jeden z jejích parametrů obsahuje stejný rto_min. Vzhledem k tomu, že RTO je samozřejmě potřeba upravit ne globálně, ale pro dané prefixy, vypadá takový mechanismus docela funkční.
Pravda, se SYN_RTO je všechno poněkud horší. Je přirozeně přibitý. Jádro má pevnou hodnotu 1 sekundy a to je vše. Z uživatelského prostoru se tam nedostanete. Existuje jen jeden způsob.
eBPF přichází na pomoc. Zjednodušeně řečeno se jedná o malé programy v jazyce C. Lze je vložit do háků na různá místa při provádění zásobníku jádra a zásobníku TCP, pomocí kterých můžete změnit velmi velké množství nastavení. Obecně je eBPF dlouhodobý trend. Místo ořezávání desítek nových sysctl parametrů a rozšiřování IP utility se pohyb posouvá směrem k eBPF a rozšiřování jeho funkčnosti. Pomocí eBPF můžete dynamicky měnit řízení zahlcení a různá další nastavení TCP.
Pro nás je ale důležité, že jím lze měnit hodnoty SYN_RTO. Kromě toho existuje veřejně zveřejněný příklad: . Co se zde udělalo? Příklad funguje, ale sám o sobě je velmi hrubý. Zde se předpokládá, že uvnitř datového centra porovnáváme prvních 44 bitů, pokud se shodují, pak jsme uvnitř datového centra. A v tomto případě změníme hodnotu časového limitu SYN_RTO na 4 ms. Stejný úkol lze provést mnohem elegantněji. Ale tento jednoduchý příklad ukazuje, že to je a) možné; b) poměrně jednoduché.
Co už víme? Skutečnost, že architektura roviny umožňuje škálování, se pro nás ukazuje jako extrémně užitečná, když povolíme štítek toku na ToR a získáme schopnost obtékat problémové oblasti. Nejlepší způsob, jak snížit hodnoty RTO a SYN-RTO, je použití programů eBPF. Otázkou zůstává: je bezpečné používat průtokový štítek pro vyvažování? A je tu nuance.
Předpokládejme, že máte ve své síti službu, která žije v anycastu. Bohužel nemám čas zabíhat do podrobností o tom, co je anycast, ale je to distribuovaná služba s různými fyzickými servery přístupnými přes stejnou IP adresu. A zde je možný problém: událost RTO může nastat nejen tehdy, když provoz prochází tkaninou. Může také nastat na úrovni vyrovnávací paměti ToR: když dojde k události incast, může k ní dojít i na hostiteli, když hostitel něco rozlije. Když dojde k události RTO a změní se označení toku. V tomto případě může provoz přejít do jiné instance anycast. Předpokládejme, že se jedná o stavový anycast, obsahuje stav připojení – může to být L3 Balancer nebo nějaká jiná služba. Pak nastává problém, protože po RTO dorazí TCP spojení na server, který o tomto TCP spojení nic neví. A pokud nemáme sdílení stavu mezi servery anycast, pak bude takový provoz zrušen a spojení TCP bude přerušeno.
Co zde můžete dělat? V řízeném prostředí, kde povolíte vyvažování označení toku, musíte při přístupu k serverům anycast zaznamenat hodnotu označení toku. Nejjednodušší způsob je provést to prostřednictvím stejného programu eBPF. Zde je ale velmi důležitý bod – co dělat, když neprovozujete síť datových center, ale jste telekomunikační operátor? To je také váš problém: počínaje určitými verzemi Juniper a Arista ve výchozím nastavení obsahují štítek toku ve svých hashovacích funkcích - upřímně řečeno, z důvodu, který mi není jasný. To může způsobit přerušení připojení TCP od uživatelů procházejících vaší sítí. Takže vřele doporučuji zkontrolovat nastavení routerů zde.
Tak či onak se mi zdá, že jsme připraveni přejít k experimentům.
Když jsme povolili flow label na ToR, připravili agenta eBPF, který nyní žije na hostitelích, rozhodli jsme se nečekat na další velké selhání, ale provádět řízené exploze. Vzali jsme ToR, který má čtyři uplinky, a na jednom z nich jsme nastavili dropy. Vylosovali si pravidlo a řekli – nyní ztrácíte všechny pakety. Jak můžete vidět vlevo, máme monitorování po paketech, které kleslo na 75 %, to znamená, že 25 % paketů je ztraceno. Vpravo jsou grafy služeb žijících za tímto ToR. V podstatě se jedná o grafy provozu rozhraní se servery uvnitř racku. Jak je vidět, klesly ještě níž. Proč klesly níže – ne o 25 %, ale v některých případech až 3–4krát? Pokud má TCP spojení smůlu, pokračuje ve snaze dosáhnout přes přerušené spojení. To je umocněno typickým chováním služby uvnitř DC – na jeden požadavek uživatele se vygeneruje N požadavků na interní služby a odpověď se dostane k uživateli, když odpoví všechny zdroje dat, nebo když v aplikaci dojde k vypršení časového limitu. úroveň, kterou je třeba ještě nakonfigurovat. To znamená, že všechno je velmi, velmi špatné.
Nyní stejný experiment, ale s povolenou hodnotou štítku toku. Jak vidíte, vlevo naše sledování šarže kleslo o stejných 25 %. To je naprosto správné, protože o retransmitech nic neví, posílá pakety a prostě počítá poměr počtu doručených a ztracených paketů.
A vpravo je servisní plán. Efekt problematického kloubu zde nenajdete. Ve stejných milisekundách proudil provoz z problémové oblasti na tři zbývající uplinky, které nebyly tímto problémem ovlivněny. Máme síť, která se léčí sama.
Toto je můj poslední snímek, čas na shrnutí. Nyní doufám, že víte, jak vybudovat samoopravnou síť datových center. Nebudete muset procházet archiv linuxového jádra a hledat tam speciální záplaty, víte, že štítek Flow v tomto případě problém řeší, ale musíte k tomuto mechanismu přistupovat opatrně. A ještě jednou zdůrazňuji, že pokud jste telekomunikační operátor, neměli byste používat flow label jako hashovací funkci, jinak narušíte relace svých uživatelů.
Síťoví inženýři musí projít koncepční změnou: síť nezačíná u ToR, nikoli u síťového zařízení, ale u hostitele. Poměrně nápadným příkladem je, jak používáme eBPF jak ke změně RTO, tak k opravě štítku toku směrem ke službám anycast.
Mechanika flow label je jistě vhodná i pro další aplikace v rámci řízeného administrativního segmentu. Může se jednat o provoz mezi datovými centry, nebo můžete takovou mechaniku použít speciálním způsobem pro řízení odchozího provozu. Ale o tom vám povím, doufám, příště. Velmi děkuji za Vaši pozornost.
Zdroj: www.habr.com