Moderný web je bez mediálneho obsahu takmer nemysliteľný: takmer každá babička má smartfón, všetci sú na sociálnych sieťach a prestoje v údržbe sú pre firmy nákladné. Tu je prepis príbehu spoločnosti o tom, ako zorganizovala doručovanie fotografií pomocou hardvérového riešenia, s akými problémami s výkonom sa počas procesu stretla, čo ich spôsobilo a ako sa tieto problémy vyriešili pomocou softvérového riešenia založeného na Nginx, pričom sa zabezpečila odolnosť voči chybám na všetkých úrovniach (). Ďakujeme autorom Olegovho príbehu Efimovej a Alexandry Dymovej, ktoré sa na konferencii podelili o svoje skúsenosti .
— Začnime malým úvodom o tom, ako ukladáme a vyrovnávame fotografie. Máme vrstvu, kde ich ukladáme, a vrstvu, kde fotografie ukladáme do vyrovnávacej pamäte. Zároveň, ak chceme dosiahnuť vysoký trik a znížiť zaťaženie úložiska, je pre nás dôležité, aby každá fotografia jednotlivého používateľa bola na jednom cachovacom serveri. V opačnom prípade by sme museli nainštalovať toľkokrát viac diskov, koľko máme serverov. Naša miera trikov je okolo 99 %, to znamená, že 100-krát znižujeme zaťaženie nášho úložiska, a aby sme to dosiahli, pred 10 rokmi, keď sa to všetko stavalo, sme mali 50 serverov. Na poskytovanie týchto fotografií sme teda v podstate potrebovali 50 externých domén, ktoré tieto servery obsluhujú.
Prirodzene, okamžite vyvstala otázka: ak jeden z našich serverov vypadne a stane sa nedostupným, akú časť prevádzky stratíme? Pozreli sme sa, čo je na trhu a rozhodli sme sa kúpiť kus hardvéru, aby vyriešil všetky naše problémy. Voľba padla na riešenie spoločnosti F5-network (ktorá mimochodom nedávno kúpila NGINX, Inc): BIG-IP Local Traffic Manager.
Čo tento kus hardvéru (LTM) robí: je to železný smerovač, ktorý vytvára železnú redundanciu svojich externých portov a umožňuje vám smerovať prevádzku na základe topológie siete, na niektorých nastaveniach a vykonáva kontroly stavu. Bolo pre nás dôležité, aby sa tento kus hardvéru dal naprogramovať. Podľa toho by sme mohli opísať logiku toho, ako boli fotografie konkrétneho používateľa doručené z konkrétnej vyrovnávacej pamäte. Ako to vyzerá? Existuje kus hardvéru, ktorý sa pozerá na internet na jednej doméne, jednej IP, vykoná ssl offload, analyzuje http požiadavky, vyberie číslo vyrovnávacej pamäte z IRule, kam ísť a nechá tam ísť. Zároveň robí zdravotné kontroly a v prípade nedostupnosti nejakého stroja sme to vtedy spravili tak, že prevádzka išla na jeden záložný server. Z hľadiska konfigurácie, samozrejme, existujú určité nuansy, ale vo všeobecnosti je všetko celkom jednoduché: zaregistrujeme kartu, korešpondenciu určitého čísla s našou IP v sieti, hovoríme, že budeme počúvať na portoch 80 a 443, hovoríme, že ak je server nedostupný, potom musíte poslať prevádzku na záložný, v tomto prípade 35., a popíšeme veľa logiky, ako by sa mala táto architektúra rozobrať. Jediným problémom bolo, že jazyk, v ktorom bol hardvér naprogramovaný, bol Tcl. Ak si to niekto vôbec pamätá... tento jazyk je viac určený len na písanie ako jazyk vhodný na programovanie:
čo sme dostali? Dostali sme kus hardvéru, ktorý zaisťuje vysokú dostupnosť našej infraštruktúry, smeruje všetku našu premávku, poskytuje zdravotné výhody a jednoducho funguje. Navyše to funguje pomerne dlho: za posledných 10 rokov na to neboli žiadne sťažnosti. Začiatkom roka 2018 sme už posielali približne 80 80 fotografií za sekundu. To je niekde okolo XNUMX gigabitov prevádzky z oboch našich dátových centier.
Ale…
Začiatkom roka 2018 sme na grafoch videli škaredý obrázok: čas potrebný na odoslanie fotografií sa jednoznačne predĺžil. A prestalo nám to vyhovovať. Problém je v tom, že toto správanie bolo viditeľné len počas dopravnej špičky – pre našu spoločnosť je to noc z nedele na pondelok. Ale zvyšok času sa systém správal ako obvykle, žiadne známky zlyhania.
Napriek tomu bolo potrebné problém vyriešiť. Identifikovali sme možné úzke miesta a začali ich odstraňovať. V prvom rade sme samozrejme rozšírili externé uplinky, vykonali kompletný audit interných uplinkov a našli všetky možné úzke miesta. Ale to všetko neprinieslo zjavný výsledok, problém nezmizol.
Ďalším možným úzkym hrdlom bol výkon samotných fotokešiek. A rozhodli sme sa, že problém je možno v nich. Rozšírili sme výkon - hlavne sieťové porty na vyrovnávacích pamätiach fotografií. Ale opäť nebolo vidieť žiadne zjavné zlepšenie. Nakoniec sme venovali veľkú pozornosť výkonu samotného LTM a tu sme na grafoch videli smutný obrázok: záťaž na všetkých CPU začína ísť hladko, ale zrazu príde na plató. Zároveň LTM prestane adekvátne reagovať na zdravotné kontroly a uplinky a začne ich náhodne vypínať, čo vedie k vážnemu zníženiu výkonu.
To znamená, že sme identifikovali zdroj problému, identifikovali úzke miesto. Zostáva rozhodnúť, čo budeme robiť.
Prvá, najzrejmejšia vec, ktorú by sme mohli urobiť, je nejako zmodernizovať samotný LTM. Ale sú tu nejaké nuansy, pretože tento hardvér je celkom jedinečný, nepôjdete do najbližšieho supermarketu a nekúpite si ho. Toto je samostatná zmluva, samostatná licenčná zmluva a zaberie to veľa času. Druhou možnosťou je začať rozmýšľať nad sebou, prísť s vlastným riešením pomocou vlastných komponentov, najlepšie pomocou programu s otvoreným prístupom. Zostáva len rozhodnúť, čo presne si na to vyberieme a koľko času strávime riešením tohto problému, pretože používatelia nedostávali dostatok fotografií. Preto to všetko musíme urobiť veľmi, veľmi rýchlo, dalo by sa povedať včera.
Keďže úloha znela ako „urobte niečo čo najrýchlejšie a s použitím hardvéru, ktorý máme“, prvé, čo nás napadlo, bolo jednoducho odstrániť niektoré nie príliš výkonné stroje spredu, dať tam Nginx, s ktorým vieme pracovať a pokúsiť sa implementovať rovnakú logiku, akú robil hardvér. To znamená, že sme opustili náš hardvér, nainštalovali ďalšie 4 servery, ktoré sme museli nakonfigurovať, vytvorili pre ne externé domény, podobne ako to bolo pred 10 rokmi... Ak by tieto stroje spadli, trochu sme stratili dostupnosť, ale ešte menej, vyriešili problém našich používateľov lokálne.
Logika teda zostáva rovnaká: nainštalujeme Nginx, dokáže sťahovať SSL, môžeme nejako naprogramovať logiku smerovania, kontroly stavu v konfiguráciách a jednoducho duplikovať logiku, ktorú sme mali predtým.
Sadnime si k písaniu konfigurácií. Spočiatku sa zdalo, že všetko je veľmi jednoduché, ale, bohužiaľ, je veľmi ťažké nájsť manuály pre každú úlohu. Preto neodporúčame jednoducho googliť „ako nakonfigurovať Nginx pre fotografie“: je lepšie odkázať na oficiálnu dokumentáciu, ktorá ukáže, na ktoré nastavenia sa treba dotknúť. Ale je lepšie zvoliť konkrétny parameter sami. Potom je všetko jednoduché: popíšeme servery, ktoré máme, popíšeme certifikáty... Najzaujímavejšia vec je však v skutočnosti samotná logika smerovania.
Najprv sa nám zdalo, že jednoducho opisujeme našu polohu, porovnávame číslo našej vyrovnávacej pamäte s fotografiami v nej, rukami alebo generátorom opisujeme, koľko upstreamov potrebujeme, v každom upstreame uvádzame server, na ktorý má byť návštevnosť go a záložný server - ak hlavný server nie je k dispozícii:
Ale pravdepodobne, keby bolo všetko také jednoduché, jednoducho by sme išli domov a nič nepovedali. Bohužiaľ, s predvolenými nastaveniami Nginx, ktoré boli vo všeobecnosti vytvorené počas mnohých rokov vývoja a nie sú úplne vhodné pre tento prípad... konfigurácia vyzerá takto: ak má niektorý upstream server chybu požiadavky alebo časový limit, Nginx vždy prepne premávku na ďalšiu. Navyše po prvom zlyhaní sa do 10 sekúnd vypne aj server, a to omylom aj časovým limitom - to sa ani nedá nijako nakonfigurovať. To znamená, že ak odstránime alebo resetujeme možnosť časového limitu v upstream direktíve, potom, aj keď Nginx túto požiadavku nespracuje a odpovie nejakou nie veľmi dobrou chybou, server sa vypne.
Aby sme tomu zabránili, urobili sme dve veci:
a) zakázali to Nginx robiť manuálne - a bohužiaľ, jediný spôsob, ako to urobiť, je jednoducho nastaviť nastavenia max fails.
b) spomenuli sme si, že v iných projektoch používame modul, ktorý nám umožňuje robiť kontroly zdravotného stavu - podľa toho sme robili pomerne časté zdravotné kontroly, aby boli prestoje v prípade havárie minimálne.
Bohužiaľ, ani to nie je všetko, pretože doslova prvé dva týždne fungovania tejto schémy ukázali, že TCP health-check je tiež nespoľahlivá vec: na upstream serveri to nemusí byť Nginx, alebo Nginx v D-state a v v tomto prípade jadro prijme pripojenie, kontrola stavu prebehne, ale nebude fungovať. Preto sme to okamžite nahradili health-check http, urobili sme špecifický, ktorý ak vráti 200, tak všetko funguje v tomto skripte. Môžete urobiť ďalšiu logiku - napríklad v prípade serverov s vyrovnávacou pamäťou skontrolujte, či je súborový systém správne pripojený:
A toto by nám vyhovovalo, až na to, že momentálne obvod úplne zopakoval to, čo hardvér. Ale chceli sme to urobiť lepšie. Predtým sme mali jeden záložný server, a to pravdepodobne nie je veľmi dobré, pretože ak máte sto serverov, potom keď niekoľko zlyhá naraz, jeden záložný server pravdepodobne nezvládne záťaž. Preto sme sa rozhodli distribuovať rezerváciu na všetky servery: jednoducho sme vytvorili ďalší samostatný upstream, zapísali sme tam všetky servery s určitými parametrami podľa zaťaženia, ktoré môžu obsluhovať, pridali sme rovnaké zdravotné kontroly, aké sme mali predtým:
Keďže v rámci jedného protiprúdu sa nedá prejsť na iný proti prúdu, bolo potrebné sa uistiť, že ak hlavný protiprúd, do ktorého sme jednoducho zaznamenali správnu, potrebnú vyrovnávaciu pamäť fotografií, bol nedostupný, prešli sme jednoducho cez stránku error_page na návrat, od kde sme išli do zálohy proti prúdu:
A doslova pridaním štyroch serverov sme dostali toto: nahradili sme časť záťaže – odstránili sme ju z LTM na tieto servery, implementovali tam rovnakú logiku pomocou štandardného hardvéru a softvéru a okamžite sme dostali bonus, ktorý tieto servery dokážu škálovať, pretože ich možno jednoducho dodať toľko, koľko je potrebné. No jediné negatívum je, že sme prišli o vysokú dostupnosť pre externých používateľov. Toto sme ale v tej chvíli museli obetovať, pretože bolo potrebné problém okamžite riešiť. Takže sme odstránili časť záťaže, v tom čase to bolo asi 40 %, LTM sa cítil dobre a doslova dva týždne po začiatku problému sme začali posielať nie 45 tisíc žiadostí za sekundu, ale 55 tisíc. V skutočnosti sme narástli o 20 % – to je jednoznačne návštevnosť, ktorú sme používateľovi nepridali. A potom začali premýšľať o tom, ako vyriešiť zostávajúci problém - zabezpečiť vysokú externú dostupnosť.
Mali sme pauzu, počas ktorej sme diskutovali, aké riešenie na to použijeme. Boli návrhy na zabezpečenie spoľahlivosti pomocou DNS, pomocou niektorých podomácky písaných skriptov, dynamických smerovacích protokolov... možností bolo veľa, ale už sa ukázalo, že pre skutočne spoľahlivé doručovanie fotografií je potrebné zaviesť ďalšiu vrstvu, ktorá bude toto sledovať. Tieto stroje sme nazvali fotorežiséri. Softvér, na ktorý sme sa spoliehali, bol Keepalived:
Na začiatok, z čoho pozostáva Keepalived? Prvým je protokol VRRP, široko známy sieťovým pracovníkom, umiestnený na sieťovom zariadení, ktorý poskytuje odolnosť voči chybám pre externú IP adresu, ku ktorej sa klienti pripájajú. Druhou časťou je IPVS, IP virtuálny server, pre vyváženie medzi fotoroutrami a zabezpečenie odolnosti voči chybám na tejto úrovni. A do tretice – zdravotné kontroly.
Začnime prvou časťou: VRRP – ako to vyzerá? Existuje určitá virtuálna IP, ktorá má záznam v dns badoocdn.com, kde sa klienti pripájajú. V určitom okamihu máme IP adresu na jednom serveri. Udržiavacie pakety bežia medzi servermi prostredníctvom protokolu VRRP a ak master zmizne z radaru - server sa reštartuje alebo niečo iné, záložný server automaticky získa túto IP adresu - nie sú potrebné žiadne manuálne akcie. Rozdiel medzi masterom a zálohovaním je hlavne priorita: čím je vyššia, tým väčšia je šanca, že sa stroj stane masterom. Veľkou výhodou je, že IP adresy nemusíte konfigurovať na samotnom serveri, stačí ich popísať v konfigurácii a ak IP adresy potrebujú nejaké vlastné pravidlá smerovania, je to popísané priamo v konfigurácii pomocou rovnakú syntax, ako je popísaná v balíku VRRP. Nestretnete sa so žiadnymi neznámymi vecami.
Ako to vyzerá v praxi? Čo sa stane, ak jeden zo serverov zlyhá? Akonáhle master zmizne, naša záloha prestane dostávať reklamy a automaticky sa stane masterom. Po určitom čase sme opravili master, reštartovali, zvýšili Keepalived - reklamy prichádzajú s vyššou prioritou ako záloha a záloha sa automaticky vráti späť, odstráni IP adresy, nie je potrebné robiť žiadne manuálne akcie.
Takto sme zabezpečili odolnosť externej IP adresy voči chybám. Ďalšia časť je nejako vyvážiť prevádzku z externej IP adresy na fotoroutre, ktoré ju už ukončujú. S vyvažovacími protokolmi je všetko celkom jasné. Toto je buď jednoduchý round-robin, alebo trochu zložitejšie veci, wrr, spojenie so zoznamom a tak ďalej. Toto je v podstate popísané v dokumentácii, nie je tam nič zvláštne. Ale spôsob doručenia... Tu sa bližšie pozrieme na to, prečo sme si vybrali jeden z nich. Sú to NAT, Direct Routing a TUN. Faktom je, že sme okamžite plánovali dodať 100 gigabitov návštevnosti zo stránok. Ak odhadujete, potrebujete 10 gigabitových kariet, však? 10 gigabitových kariet v jednom serveri je už nad rámec aspoň nášho konceptu „štandardnej výbavy“. A potom sme si spomenuli, že nielen rozdávame nejakú návštevnosť, ale aj fotky.
čo je špeciálne? — Obrovský rozdiel medzi prichádzajúcou a odchádzajúcou premávkou. Prichádzajúca návštevnosť je veľmi malá, odchádzajúca návštevnosť veľmi veľká:
Ak sa pozriete na tieto grafy, môžete vidieť, že momentálne režisér dostáva približne 200 MB za sekundu, je to úplne obyčajný deň. Dávame späť 4,500 1 MB za sekundu, náš pomer je približne 22/22. Už teraz je jasné, že na plné poskytovanie odchádzajúcej prevádzky na XNUMX pracovných serverov potrebujeme iba jeden, ktorý akceptuje toto pripojenie. Tu nám prichádza na pomoc algoritmus priameho smerovania.
Ako to vyzerá? Náš fotorežisér podľa svojej tabuľky prenáša spojenia na fotoroutre. Fotoroutre však posielajú spätnú prevádzku priamo do internetu, posielajú ju klientovi, nevracajú sa späť cez fotoriaditeľa, teda pri minimálnom počte strojov zaisťujeme úplnú odolnosť voči poruchám a pumpovanie všetkej prevádzky. V konfiguráciách to vyzerá takto: zadáme algoritmus, v našom prípade je to jednoduchý rr, poskytneme metódu priameho smerovania a potom začneme vypisovať všetky skutočné servery, koľko ich máme. Ktorý určí túto premávku. Ak tam máme ešte jeden alebo dva servery, alebo niekoľko serverov, takáto potreba vzniká – túto sekciu jednoducho pridáme do konfigurácie a nemusíme sa príliš obávať. Zo strany reálnych serverov, zo strany fotoroutra si tento spôsob vyžaduje čo najmenšiu konfiguráciu, je dokonale popísaný v dokumentácii a neexistujú žiadne úskalia.
Obzvlášť pekné je, že takéto riešenie neznamená radikálny redizajn lokálnej siete, to bolo pre nás dôležité, museli sme to vyriešiť s minimálnymi nákladmi. Ak sa pozriete na , potom uvidíme ako to bude vyzerať. Tu máme určitý virtuálny server na porte 443, počúva, prijíma pripojenie, sú uvedené všetky fungujúce servery a vidíte, že pripojenie je rovnaké, daj alebo ber. Ak sa pozrieme na štatistiky na tom istom virtuálnom serveri, máme prichádzajúce pakety, prichádzajúce spojenia, ale absolútne žiadne odchádzajúce. Odchádzajúce spojenia idú priamo ku klientovi. Dobre, dokázali sme to vyvážiť. Čo sa stane, ak jeden z našich foto smerovačov zlyhá? Železo je predsa železo. Môže prejsť do jadrovej paniky, môže sa zlomiť, napájací zdroj môže vyhorieť. Čokoľvek. Preto sú potrebné zdravotné prehliadky. Môžu byť také jednoduché, ako kontrola, ako je port otvorený, alebo niečo zložitejšie, až po niektoré doma písané skripty, ktoré dokonca skontrolujú obchodnú logiku.
Zastavili sme sa niekde uprostred: máme https požiadavku na konkrétne miesto, volá sa skript, ak odpovie 200-tou odpoveďou, veríme, že s týmto serverom je všetko v poriadku, že žije a dá sa celkom zapnúť ľahko.
Ako to opäť vyzerá v praxi? Vypnime server kvôli údržbe - napríklad flashovanie BIOSu. V protokoloch máme okamžite časový limit, vidíme prvý riadok, potom je po troch pokusoch označený ako „neúspešný“ a jednoducho sa odstráni zo zoznamu.
Je tiež možná druhá možnosť správania, keď sa VS jednoducho nastaví na nulu, ale ak sa fotografia vráti, nefunguje to dobre. Server sa objaví, spustí sa tam Nginx, Health-check okamžite pochopí, že pripojenie funguje, že všetko je v poriadku a server sa objaví v našom zozname a okamžite sa naň začne aplikovať zaťaženie. Od správcu povinnosti sa nevyžadujú žiadne manuálne úkony. Server sa v noci reštartoval - oddelenie monitorovania nám o tom v noci nevolá. Informujú vás, že sa to stalo, všetko je v poriadku.
Takže pomerne jednoduchým spôsobom, s pomocou malého počtu serverov, sme vyriešili problém odolnosti voči externým chybám.
Ostáva len povedať, že toto všetko, samozrejme, treba sledovať. Samostatne je potrebné poznamenať, že Keepalivede, ako softvér napísaný už dávno, má veľa spôsobov, ako ho monitorovať, a to pomocou kontrol cez DBus, SMTP, SNMP a štandardný Zabbix. Navyše, on sám vie písať listy takmer na každé kýchnutie a pravdupovediac, v istom momente nás napadlo to aj vypnúť, pretože na každé prepínanie prevádzky, zapínanie, pre každé IP pripojenie píše veľa písmen, a tak ďalej . Samozrejme, ak existuje veľa serverov, môžete sa týmito listami zahltiť. Monitorujeme nginx na foto smerovačoch pomocou štandardných metód a monitorovanie hardvéru nezmizlo. Radi by sme, samozrejme, poradili ešte dve veci: po prvé, externé kontroly zdravotného stavu a dostupnosť, pretože aj keď všetko funguje, v skutočnosti používatelia fotografie nedostávajú kvôli problémom s externými poskytovateľmi alebo niečomu zložitejšiemu. Vždy sa oplatí ponechať niekde v inej sieti, v Amazone alebo niekde inde, samostatný stroj, ktorý môže pingovať vaše servery zvonku, a tiež sa oplatí použiť detekciu anomálií pre tých, ktorí vedia robiť zložité strojové učenie, alebo jednoduché monitorovanie. , prinajmenšom preto, aby bolo možné sledovať, či požiadavky prudko klesli, alebo naopak vzrástli. Môže to byť aj užitočné.
Zhrňme si to: v podstate sme nahradili okované riešenie, ktoré nám v istom momente prestalo vyhovovať, za celkom jednoduchý systém, ktorý robí všetko rovnako, teda zabezpečuje ukončenie HTTPS prevádzky a ďalšie inteligentné smerovanie s tzv. potrebné zdravotné prehliadky. Zvýšili sme stabilitu tohto systému, to znamená, že máme stále vysokú dostupnosť pre každú vrstvu, plus máme bonus, že je celkom jednoduché to všetko škálovať na každej vrstve, pretože ide o štandardný hardvér so štandardným softvérom, tzn. , zjednodušili sme diagnostiku možných problémov.
S čím sme skončili? Počas januárových sviatkov 2018 sme mali problém. Za prvých šesť mesiacov, čo sme túto schému uvádzali do prevádzky, sme ju rozšírili na všetku prevádzku, aby sme odstránili všetku prevádzku z LTM, narástli sme len v prevádzke v jednom dátovom centre zo 40 gigabitov na 60 gigabitov a zároveň celý rok 2018 dokázali poslať takmer trikrát viac fotografií za sekundu.
Zdroj: hab.com