Moderní web je bez mediálního obsahu téměř nemyslitelný: téměř každá babička má chytrý telefon, všichni jsou na sociálních sítích a výpadky v údržbě jsou pro firmy nákladné. Zde je přepis příběhu společnosti o tom, jak organizovala doručování fotografií pomocí hardwarového řešení, s jakými problémy s výkonem se během procesu setkala, co je způsobilo a jak byly tyto problémy vyřešeny pomocí softwarového řešení založeného na Nginx při zajištění odolnosti proti chybám na všech úrovních (). Děkujeme autorům Olegova příběhu Efimova a Alexandra Dymova, které se na konferenci podělily o své zkušenosti .
— Začněme malým úvodem o tom, jak ukládáme a vyrovnáváme fotografie. Máme vrstvu, kde je ukládáme, a vrstvu, kde fotky ukládáme do mezipaměti. Zároveň, pokud chceme dosáhnout vysokého trikového tempa a snížit zatížení úložiště, je pro nás důležité, aby každá fotografie jednotlivého uživatele byla na jednom cachovacím serveru. Jinak bychom museli instalovat tolikrát disků, kolik máme serverů. Náš trik se pohybuje kolem 99 %, to znamená, že 100krát snižujeme zatížení našeho úložiště, a abychom toho dosáhli, před 10 lety, kdy se to všechno stavělo, jsme měli 50 serverů. Abychom mohli obsluhovat tyto fotografie, potřebovali jsme v podstatě 50 externích domén, které tyto servery obsluhují.
Přirozeně okamžitě vyvstala otázka: pokud jeden z našich serverů vypadne a stane se nedostupným, o jakou část provozu přijdeme? Podívali jsme se, co je na trhu, a rozhodli jsme se koupit kus hardwaru, aby vyřešil všechny naše problémy. Volba padla na řešení společnosti F5-network (která mimochodem nedávno koupila NGINX, Inc): BIG-IP Local Traffic Manager.
Co tento kus hardwaru (LTM) dělá: je to železný router, který vytváří železnou redundanci svých externích portů a umožňuje směrovat provoz na základě topologie sítě, na některých nastaveních a provádí kontroly stavu. Bylo pro nás důležité, aby se tento kus hardwaru dal naprogramovat. Podle toho bychom mohli popsat logiku toho, jak byly fotografie konkrétního uživatele podávány z konkrétní cache. Jak to vypadá? Existuje kus hardwaru, který se dívá na internet na jedné doméně, jedné IP, provádí ssl offload, analyzuje http požadavky, vybírá číslo mezipaměti z IRule, kam má jít, a nechává tam provoz. Zároveň dělá zdravotní kontroly a v případě nedostupnosti nějakého stroje jsme to tenkrát udělali tak, že provoz šel na jeden záložní server. Z hlediska konfigurace samozřejmě existují určité nuance, ale obecně je vše docela jednoduché: registrujeme kartu, korespondenci určitého čísla s naší IP v síti, říkáme, že budeme poslouchat na portech 80 a 443, říkáme, že pokud je server nedostupný, musíte poslat provoz na záložní server, v tomto případě 35., a popíšeme spoustu logiky, jak by měla být tato architektura rozebrána. Jediným problémem bylo, že jazyk, ve kterém byl hardware naprogramován, byl Tcl. Pokud si to někdo pamatuje... tento jazyk je spíše určený pouze pro zápis než jazyk vhodný pro programování:
co jsme dostali? Dostali jsme kus hardwaru, který zajišťuje vysokou dostupnost naší infrastruktury, směruje veškerý náš provoz, poskytuje zdravotní výhody a prostě funguje. Navíc funguje poměrně dlouho: za posledních 10 let na něj nebyly žádné stížnosti. Na začátku roku 2018 jsme již posílali asi 80 tisíc fotek za sekundu. To je někde kolem 80 gigabitů provozu z obou našich datových center.
Ale…
Začátkem roku 2018 jsme na grafech viděli ošklivý obrázek: čas potřebný k odeslání fotek se zřetelně prodloužil. A přestalo nám to vyhovovat. Problém je v tom, že toto chování bylo viditelné pouze během dopravní špičky - pro naši společnost je to noc z neděle na pondělí. Ale po zbytek času se systém choval jako obvykle, žádné známky selhání.
Přesto bylo nutné problém vyřešit. Identifikovali jsme možná úzká hrdla a začali je odstraňovat. V první řadě jsme samozřejmě rozšířili externí uplinky, provedli kompletní audit interních uplinků a našli všechna možná úzká hrdla. Ale to vše nepřineslo zřejmý výsledek, problém nezmizel.
Dalším možným úzkým hrdlem byl výkon samotných fotokešek. A rozhodli jsme se, že problém je možná v nich. No, rozšířili jsme výkon - hlavně síťové porty na mezipaměti fotografií. Ale opět nebylo vidět žádné zjevné zlepšení. Výkonu samotného LTM jsme nakonec věnovali velkou pozornost a zde jsme viděli na grafech smutný obrázek: zátěž všech CPU začíná jít plynule, ale pak najednou přijde na plató. Současně LTM přestane adekvátně reagovat na zdravotní kontroly a uplinky a začne je náhodně vypínat, což vede k vážnému snížení výkonu.
To znamená, že jsme identifikovali zdroj problému, identifikovali úzké místo. Zbývá se rozhodnout, co budeme dělat.
První, nejzřejmější věc, kterou bychom mohli udělat, je nějak modernizovat samotný LTM. Ale jsou zde některé nuance, protože tento hardware je zcela jedinečný, nepůjdete do nejbližšího supermarketu a nekoupíte ho. Jedná se o samostatnou smlouvu, samostatnou licenční smlouvu a zabere to spoustu času. Druhou možností je začít přemýšlet sám za sebe, přijít s vlastním řešením pomocí vlastních komponent, nejlépe pomocí programu s otevřeným přístupem. Zbývá se pouze rozhodnout, co přesně k tomu vybereme a kolik času strávíme řešením tohoto problému, protože uživatelé nedostávali dostatek fotografií. Proto to všechno musíme udělat velmi, velmi rychle, dalo by se říci včera.
Jelikož úkol zněl jako „udělejte něco co nejrychleji a s použitím hardwaru, který máme“, první věc, kterou jsme si mysleli, bylo jednoduše odstranit některé nepříliš výkonné stroje zepředu, dát tam Nginx, se kterým víme, jak pracovat a pokusit se implementovat stejnou logiku, jakou dělal hardware. To znamená, že jsme opustili náš hardware, nainstalovali další 4 servery, které jsme museli nakonfigurovat, vytvořili pro ně externí domény, podobně jako to bylo před 10 lety... Trochu jsme ztratili dostupnost, kdyby tyto stroje spadly, ale ještě méně, vyřešili problém našich uživatelů lokálně.
Logika tedy zůstává stejná: nainstalujeme Nginx, může provádět SSL-offload, můžeme nějak naprogramovat logiku směrování, kontroly stavu v konfiguracích a jednoduše duplikovat logiku, kterou jsme měli předtím.
Pojďme si sednout k psaní konfigurací. Zpočátku se zdálo, že je vše velmi jednoduché, ale bohužel je velmi obtížné najít manuály pro každý úkol. Proto nedoporučujeme jednoduše googlovat „jak nakonfigurovat Nginx pro fotografie“: je lepší odkázat na oficiální dokumentaci, která ukáže, jaká nastavení je třeba sáhnout. Ale je lepší zvolit konkrétní parametr sami. Pak je vše jednoduché: popíšeme servery, které máme, popíšeme certifikáty... Ale nejzajímavější je ve skutečnosti samotná logika směrování.
Zpočátku se nám zdálo, že jednoduše popisujeme naši polohu, shodujeme se s číslem naší foto cache v ní, rukama nebo generátorem popíšeme, kolik upstreamů potřebujeme, v každém upstreamu uvedeme server, na který by měl provoz go a záložní server - pokud hlavní server není k dispozici:
Ale pravděpodobně, kdyby bylo všechno tak jednoduché, prostě bychom šli domů a nic neříkali. Bohužel s výchozím nastavením Nginx, které bylo obecně vytvořeno během mnoha let vývoje a není pro tento případ zcela vhodné... konfigurace vypadá takto: pokud má některý upstream server chybu požadavku nebo časový limit, Nginx vždy přepne provoz na další. Navíc po prvním selhání dojde do 10 sekund také k vypnutí serveru, a to jak omylem, tak timeoutem - to ani nelze nijak konfigurovat. To znamená, že pokud odstraníme nebo resetujeme možnost časového limitu v upstream direktivě, pak, přestože Nginx tento požadavek nezpracuje a odpoví nějakou nepříliš dobrou chybou, server se vypne.
Abychom tomu zabránili, udělali jsme dvě věci:
a) zakázali to Nginx dělat ručně - a bohužel jediný způsob, jak to udělat, je jednoduše nastavit nastavení maximálního selhání.
b) pamatovali jsme si, že v jiných projektech používáme modul, který nám umožňuje provádět kontroly stavu na pozadí - podle toho jsme prováděli poměrně časté kontroly stavu, aby prostoje v případě nehody byly minimální.
Bohužel ani to není vše, protože doslova první dva týdny provozu tohoto schématu ukázaly, že TCP health-check je také nespolehlivá věc: na upstream serveru to nemusí být Nginx nebo Nginx ve stavu D a v v tomto případě jádro přijme připojení, kontrola stavu projde, ale nebude fungovat. Proto jsme to okamžitě nahradili health-check http, udělali jsme konkrétní, které pokud vrátí 200, tak vše funguje v tomto skriptu. Můžete provést další logiku - například v případě serverů s mezipamětí zkontrolujte, zda je souborový systém správně připojen:
A to by se nám hodilo, až na to, že momentálně obvod úplně zopakoval to, co hardware. Ale chtěli jsme to udělat lépe. Dříve jsme měli jeden záložní server, a to pravděpodobně není příliš dobré, protože pokud máte sto serverů, pak když několik selže najednou, je nepravděpodobné, že by jeden záložní server zvládl zátěž. Proto jsme se rozhodli rozdělit rezervaci na všechny servery: jednoduše jsme vytvořili další samostatný upstream, zapsali tam všechny servery s určitými parametry podle zatížení, které mohou obsluhovat, přidali stejné kontroly stavu, jaké jsme měli předtím:
Vzhledem k tomu, že v rámci jednoho proti proudu nelze přejít na jiný proti proudu, bylo nutné zajistit, aby v případě nedostupnosti hlavního proti proudu, do kterého jsme jednoduše zaznamenali správnou, potřebnou foto cache, jsme jednoduše prošli chybovou_stránkou na záložní, od kde jsme šli do zálohy proti proudu:
A doslova přidáním čtyř serverů jsme dostali toto: nahradili jsme část zátěže – odstranili jsme ji z LTM na tyto servery, implementovali tam stejnou logiku pomocí standardního hardwaru a softwaru a okamžitě jsme získali bonus, který tyto servery umí škálovat, protože je lze jednoduše dodat tolik, kolik je potřeba. No, jediné negativum je, že jsme ztratili vysokou dostupnost pro externí uživatele. Tohle jsme ale v tu chvíli museli obětovat, protože bylo nutné problém okamžitě řešit. Takže jsme odstranili část zátěže, v té době to bylo asi 40 %, LTM se cítil dobře a doslova dva týdny poté, co problém začal, jsme začali posílat ne 45 tisíc požadavků za sekundu, ale 55 tisíc. Ve skutečnosti jsme narostli o 20 % – to je jednoznačně návštěvnost, kterou jsme uživateli nedali. A poté začali přemýšlet o tom, jak vyřešit zbývající problém - zajistit vysokou externí dostupnost.
Měli jsme pauzu, během které jsme diskutovali, jaké řešení k tomu použijeme. Objevily se návrhy na zajištění spolehlivosti pomocí DNS, pomocí některých podomácku psaných skriptů, dynamických směrovacích protokolů... možností bylo mnoho, ale už se ukázalo, že pro skutečně spolehlivé doručování fotografií je potřeba zavést další vrstvu, která bude toto sledovat. Nazvali jsme tyto stroje fotorežiséry. Software, na který jsme se spoléhali, byl Keepalived:
Pro začátek, z čeho se Keepalived skládá? Prvním je protokol VRRP, široce známý síťařům, umístěný na síťovém zařízení, který poskytuje odolnost vůči chybám na externí IP adrese, ke které se klienti připojují. Druhou částí je IPVS, IP virtuální server, pro balancování mezi fotoroutery a zajištění odolnosti proti chybám na této úrovni. A za třetí – zdravotní prohlídky.
Začneme první částí: VRRP – jak to vypadá? Existuje určitá virtuální IP, která má záznam na dns badoocdn.com, kam se klienti připojují. V určitém okamžiku máme IP adresu na jednom serveru. Pakety Keepalved běží mezi servery pomocí protokolu VRRP, a pokud master zmizí z radaru - server se restartoval nebo něco jiného, pak záložní server automaticky vyzvedne tuto IP adresu - nejsou vyžadovány žádné ruční akce. Rozdíl mezi masterem a zálohou je hlavně priorita: čím vyšší je, tím větší je šance, že se stroj stane masterem. Velkou výhodou je, že IP adresy nemusíte konfigurovat na samotném serveru, stačí je popsat v konfiguraci, a pokud IP adresy potřebují nějaká vlastní pravidla směrování, je to popsáno přímo v konfiguraci pomocí stejná syntaxe, jaká je popsána v balíčku VRRP. Nesetkáte se s žádnými neznámými věcmi.
Jak to vypadá v praxi? Co se stane, když jeden ze serverů selže? Jakmile master zmizí, naše záloha přestane přijímat reklamy a automaticky se stane masterem. Po nějaké době jsme master opravili, restartovali, zvýšili Keepalived – reklamy přicházejí s vyšší prioritou než záloha a záloha se automaticky vrátí, odstraní IP adresy, není třeba provádět žádné ruční akce.
Tím jsme zajistili odolnost externí IP adresy proti chybám. Další částí je nějak vyrovnat provoz z externí IP adresy na fotoroutery, které to už ukončují. S vyvažovacími protokoly je vše zcela jasné. To je buď jednoduchý round-robin, nebo trochu složitější věci, wrr, připojení seznamu a tak dále. To je v podstatě popsáno v dokumentaci, není tam nic zvláštního. Ale způsob doručení... Zde se blíže podíváme na to, proč jsme si vybrali jeden z nich. Jsou to NAT, Direct Routing a TUN. Faktem je, že jsme okamžitě plánovali dodat 100 gigabitů provozu z webů. Pokud odhadujete, potřebujete 10 gigabitových karet, ne? 10 gigabitových karet v jednom serveru je již nad rámec přinejmenším našeho pojetí „standardního vybavení“. A pak jsme si vzpomněli, že nejen rozdáváme nějaký provoz, ale rozdáváme fotky.
co je speciální? — Obrovský rozdíl mezi příchozím a odchozím provozem. Příchozí provoz je velmi malý, odchozí provoz je velmi velký:
Když se podíváte na tyto grafy, můžete vidět, že v tuto chvíli režisér přijímá asi 200 MB za sekundu, je to úplně obyčejný den. Vracíme 4,500 MB za sekundu, náš poměr je přibližně 1/22. Již nyní je jasné, že k plnému zajištění odchozího provozu na 22 pracovních serverů potřebujeme pouze jeden, který toto připojení akceptuje. Zde nám přichází na pomoc algoritmus přímého směrování.
Jak to vypadá? Náš fotorežisér podle své tabulky přenáší spojení na fotoroutery. Fotoroutery ale odesílají zpětný provoz přímo do internetu, posílají ho klientovi, nevrací se přes fotorežisér, takže s minimálním počtem strojů zajišťujeme kompletní chybovou odolnost a pumpování veškerého provozu. V konfiguracích to vypadá takto: zadáme algoritmus, v našem případě je to jednoduchý rr, poskytneme metodu přímého směrování a pak začneme vypisovat všechny skutečné servery, kolik jich máme. Což bude určovat tento provoz. Pokud tam máme jeden nebo dva další servery nebo několik serverů, taková potřeba vyvstane - tuto sekci prostě přidáme do konfigurace a moc se nestaráme. Ze strany skutečných serverů, ze strany fotorouteru vyžaduje tato metoda minimální konfiguraci, je perfektně popsána v dokumentaci a nejsou zde žádná úskalí.
Obzvláště příjemné je, že takové řešení neznamená radikální redesign lokální sítě, to bylo pro nás důležité, museli jsme to vyřešit s minimálními náklady. Pokud se podíváte na , tak uvidíme, jak to bude vypadat. Zde máme určitý virtuální server, na portu 443, naslouchá, přijímá připojení, jsou uvedeny všechny fungující servery a můžete vidět, že připojení je, dát nebo vzít, stejné. Pokud se podíváme na statistiky na stejném virtuálním serveru, máme příchozí pakety, příchozí spojení, ale absolutně žádná odchozí. Odchozí spojení jdou přímo ke klientovi. Dobře, dokázali jsme to vyvážit. Co se stane, když jeden z našich fotorouterů selže? Železo je přece železo. Může dojít k panice jádra, může se rozbít, napájecí zdroj může vyhořet. Cokoliv. To je důvod, proč jsou nutné zdravotní prohlídky. Mohou být tak jednoduché, jako je kontrola, jak je port otevřený, nebo něco složitějšího, až po některé doma psané skripty, které dokonce zkontrolují obchodní logiku.
Zastavili jsme se někde uprostřed: máme https požadavek na konkrétní místo, volá se skript, pokud odpoví 200. odpovědí, věříme, že je s tímto serverem vše v pořádku, že žije a dá se docela zapnout snadno.
Jak to opět vypadá v praxi? Vypněte server kvůli údržbě - například flashování BIOSu. V protokolech máme okamžitě timeout, vidíme první řádek, po třech pokusech je označen jako „neúspěšný“ a je jednoduše odstraněn ze seznamu.
Je také možná druhá možnost chování, kdy je VS jednoduše nastaveno na nulu, ale pokud je fotografie vrácena, nefunguje to dobře. Server se spustí, spustí se tam Nginx, Health-check okamžitě pochopí, že připojení funguje, že je vše v pořádku a server se objeví v našem seznamu a okamžitě se na něj začne aplikovat zatížení. Od správce povinnosti nejsou vyžadovány žádné ruční zásahy. Server se v noci restartoval - monitorovací oddělení nám o tom v noci nevolá. Informují vás, že se to stalo, vše je v pořádku.
Takže poměrně jednoduchým způsobem, s pomocí malého počtu serverů, jsme vyřešili problém odolnosti vůči externím chybám.
Nezbývá než říci, že to vše je samozřejmě potřeba sledovat. Samostatně je třeba poznamenat, že Keepalivede, jako software napsaný před dlouhou dobou, má spoustu způsobů, jak jej sledovat, a to jak pomocí kontrol přes DBus, SMTP, SNMP a standardní Zabbix. Navíc on sám umí psát písmena skoro na každé kýchnutí a popravdě řečeno, v určité chvíli nás i napadlo to vypnout, protože píše spoustu písmen pro jakékoli přepínání provozu, zapínání, pro každé IP připojení, a tak dále. Samozřejmě, pokud existuje mnoho serverů, můžete se těmito písmeny zahltit. Monitorujeme nginx na foto routerech pomocí standardních metod a monitorování hardwaru nezmizelo. My bychom samozřejmě poradili ještě dvě věci: za prvé externí kontroly stavu a dostupnost, protože i když vše funguje, ve skutečnosti možná uživatelé nedostávají fotografie kvůli problémům s externími poskytovateli nebo kvůli něčemu složitějšímu. Vždy se vyplatí ponechat někde v jiné síti, v Amazonu nebo někde jinde, samostatný stroj, který může pingnout vaše servery zvenčí, a také se vyplatí používat buď detekci anomálií pro ty, kteří vědí, jak dělat složité strojové učení, nebo jednoduché monitorování , alespoň proto, aby bylo možné sledovat, zda požadavky prudce klesly, nebo naopak vzrostly. Může to být také užitečné.
Shrňme si to: okované řešení, které nám v určité chvíli přestalo vyhovovat, jsme v podstatě nahradili celkem jednoduchým systémem, který dělá vše stejně, tedy zajišťuje ukončení HTTPS provozu a další chytré směrování s nezbytné zdravotní prohlídky. Zvýšili jsme stabilitu tohoto systému, to znamená, že máme stále vysokou dostupnost pro každou vrstvu, plus máme bonus, že je celkem snadné to všechno škálovat na každé vrstvě, protože jde o standardní hardware se standardním softwarem, tzn. , zjednodušili jsme diagnostiku možných problémů.
S čím jsme to skončili? Během lednových prázdnin 2018 jsme měli problém. Za prvních šest měsíců, co jsme toto schéma zprovoznili, jsme jej rozšířili na veškerý provoz, abychom odstranili veškerý provoz z LTM, rostli jsme pouze v provozu v jednom datovém centru ze 40 gigabitů na 60 gigabitů a zároveň pro celý rok 2018 dokázali poslat téměř třikrát více fotografií za sekundu.
Zdroj: www.habr.com