U web mudernu hè quasi impensable senza cuntenutu media: quasi ogni nanna hà un smartphone, tutti sò nantu à e rete soziale, è u tempu d'inattività in mantenimentu hè costu per l'imprese. Eccu una trascrizione di a storia di a cumpagnia nantu à cumu hà urganizatu a consegna di foto utilizendu una suluzione hardware, quali prublemi di rendiment hà scontru in u prucessu, ciò chì li hà causatu, è cumu questi prublemi sò stati risolti utilizendu una soluzione software basata in Nginx, assicurendu a tolleranza di difetti à tutti i livelli (). Ringraziemu l'autori di a storia di Oleg Efimova è Alexandra Dymova, chì anu spartutu a so sperienza in a cunferenza .
- Cuminciamu cù una piccula introduzione nantu à cumu guardemu è cachemu e foto. Avemu una capa induve l'avemu guardatu, è una capa induve cachemu e foto. À u listessu tempu, se vulemu ottene un altu ritmu di truccu è riduce a carica nantu à u almacenamentu, hè impurtante per noi chì ogni foto di un utilizatore individuale hè in un servitore di caching. Altrimenti, avissimu a stallà tanti volte più dischi quant'è avemu più servitori. U nostru ritmu di truccu hè di circa 99%, vale à dì, riducemu a carica nantu à u nostru almacenamentu per 100 volte, è per fà questu, 10 anni fà, quandu tuttu questu era custruitu, avemu avutu 50 servitori. Per quessa, per serve queste foto, avemu bisognu essenzialmente 50 domini esterni chì questi servitori serve.
Naturalmente, a quistione hè subitu subitu: se unu di i nostri servitori falà è diventa indisponibile, chì parte di u trafficu perdemu? Avemu vistu ciò chì era nantu à u mercatu è decisu di cumprà un pezzu di hardware per risolve tutti i nostri prublemi. A scelta hè cascata nantu à a suluzione di a cumpagnia di a rete F5 (chì, per via, hà acquistatu pocu tempu NGINX, Inc): BIG-IP Local Traffic Manager.
Ciò chì face stu pezzu di hardware (LTM): hè un router di ferru chì face a redundanza di ferru di i so porti esterni è vi permette di indirizzà u trafficu basatu annantu à a topologia di a rete, in certi paràmetri, è face cuntrolli di salute. Era impurtante per noi chì stu pezzu di hardware puderia esse programatu. In cunsiquenza, pudemu descriverà a logica di cumu e fotografie di un utilizatore specificu sò servite da una cache specifica. Chì pare ? Ci hè un pezzu di hardware chì guarda l'Internet nantu à un duminiu, una IP, ùn ssl offload, analizà e richieste http, selezziunate un numeru di cache da IRule, induve andà, è permette u trafficu. À u listessu tempu, face cuntrolli di salute, è in casu chì una macchina ùn sia micca dispunibile, à quellu tempu avemu fattu cusì chì u trafficu andò à un servitore di salvezza. Da un puntu di vista di cunfigurazione, ci sò, sicuru, qualchi sfumature, ma in generale tuttu hè abbastanza simplice: registremu una carta, currispundenza di un certu numaru à a nostra IP nantu à a reta, dicemu chì avemu da sente à i porti 80. è 443, dicemu chì se u servitore ùn hè micca dispunibile, allora avete bisognu di mandà u trafficu à a copia di salvezza, in questu casu u 35, è avemu discrittu una mansa di logica nantu à cumu questa architettura deve esse disassemblata. L'unicu prublema era chì a lingua in quale u hardware era programatu era Tcl. Se qualchissia si ricorda di questu... sta lingua hè più di scrittura solu chè una lingua cunvene per a prugrammazione:
Chì avemu avutu ? Avemu ricevutu un pezzu di hardware chì assicura una alta dispunibilità di a nostra infrastruttura, rotte tuttu u nostru trafficu, furnisce benefici per a salute è travaglia solu. Inoltre, travaglia per un bellu pezzu: in l'ultimi 10 anni ùn ci hè statu nisuna lagnanza. À u principiu di 2018, avemu digià mandatu circa 80k foto per seconda. Questu hè intornu à 80 gigabits di trafficu da i nostri dui centri di dati.
Tuttavia…
À u principiu di 2018, avemu vistu una stampa brutta nantu à i charts: u tempu chì hà pigliatu per mandà e foto era chjaramente aumentatu. È hà cessatu di cunvene à noi. U prublema hè chì stu cumpurtamentu era visibile solu durante u piccu di u trafficu - per a nostra cumpagnia hè a notte da dumenica à luni. Ma u restu di u tempu u sistema si cumportò cum'è di solitu, senza segni di fallimentu.
Tuttavia, u prublema avia da esse risolta. Avemu identificatu i pussibuli colli di bottiglia è cuminciamu à eliminà. Prima di tuttu, sicuru, avemu allargatu i uplinks esterni, realizatu un auditu cumpletu di uplinks internu, è truvamu tutti i colli di bottiglia pussibuli. Ma tuttu questu ùn hà micca datu un risultatu evidenti, u prublema ùn hè micca sparitu.
Un altru scontru pussibile era a prestazione di i cache di foto stessi. È avemu decisu chì forse u prublema hè cun elli. Ebbè, avemu allargatu u rendiment - principalmente porti di rete nantu à cache di foto. Ma di novu ùn hè statu vistu una migliione evidenti. À a fine, avemu attentu assai à u funziunamentu di u LTM stessu, è quì avemu vistu una stampa triste nantu à i gràfici: a carica nantu à tutti i CPU cumencia à andà bè, ma poi di colpu vene à un plateau. À u listessu tempu, LTM cessà di risponde in modu adattatu à i cuntrolli di salute è uplinks è cumencia à disattivà aleatoriamente, chì porta à una seria degradazione di u rendiment.
Questu hè, avemu identificatu a fonte di u prublema, identificatu u collu di buttiglia. Resta da decide ciò chì faremu.
U primu, a cosa più ovvia chì pudemu fà hè di mudernizà in qualchì modu u LTM stessu. Ma ci sò qualchi sfumature quì, perchè stu hardware hè abbastanza unicu, ùn andate micca in u supermercatu più vicinu è cumprà. Questu hè un cuntrattu separatu, un cuntrattu di licenza separatu, è duverà assai tempu. A seconda opzione hè di cumincià à pensà per sè stessu, vene cù a vostra propria suluzione cù i vostri propri cumpunenti, preferibile cù un prugramma d'accessu apertu. Tuttu ciò chì resta hè di decide ciò chì esattamente scegliemu per questu è quantu tempu passeremu per risolve stu prublema, perchè l'utilizatori ùn anu micca ricevutu abbastanza foto. Dunque, avemu bisognu di fà tuttu questu assai, assai prestu, unu puderia dì ieri.
Siccomu u compitu sonava cum'è "fà qualcosa u più prestu pussibule è aduprendu u hardware chì avemu", a prima cosa chì avemu pensatu era solu di caccià alcune macchine micca assai putenti da u fronte, mette Nginx quì, cù quale sapemu cumu fà. travaglià è pruvate à implementà tutte a listessa logica chì u hardware hà fattu. Hè, in fattu, avemu lasciatu u nostru hardware, installatu 4 servitori più chì avemu avutu à cunfigurà, creatu domini esterni per elli, simili à cumu era 10 anni fà... Avemu persu un pocu di dispunibilità si sti machini cascanu, ma ancu menu, anu risoltu u prublema di i nostri utilizatori in u locu.
In cunsiquenza, a logica resta a stessa: installemu Nginx, pò fà SSL-offload, pudemu in qualchì modu programà a logica di routing, cuntrolli di salute in i cunfigurazioni è simpricimenti duplicà a logica chì avemu avutu prima.
Sedemu à scrive cunfigurazioni. À u principiu, pareva chì tuttu era assai simplice, ma, sfurtunatamenti, hè assai difficiule di truvà manuali per ogni compitu. Dunque, ùn ricumandemu micca solu di google "cumu cunfigurà Nginx per e foto": hè megliu riferite à a documentazione ufficiale, chì mostrarà quale paràmetri deve esse toccu. Ma hè megliu di sceglie u paràmetru specificu stessu. Eppo, allora tuttu hè simplice : discrimu i servitori chì avemu, discrimu i certificati... Ma u più interessante hè, in fattu, a logica di routing stessu.
À u principiu, ci hè parsu chì eramu simpricimenti discrittendu u nostru locu, currispunendu u numeru di a nostra cache di foto in questu, usendu e nostre mani o un generatore per descriverà quanti upstreams avemu bisognu, in ogni upstream indichemu u servitore à quale u trafficu deve esse. vai, è un servitore di salvezza - se u servitore principale ùn hè micca dispunibule:
Ma, prubabilmente, s'ellu tuttu era cusì simplice, andemu solu in casa senza dì nunda. Sfurtunatamente, cù i paràmetri predeterminati di Nginx, chì, in generale, sò stati fatti annantu à parechji anni di sviluppu è ùn sò micca adattati per questu casu ... a cunfigurazione pare cusì: se qualchì servitore upstream hà un errore di dumanda o timeout, Nginx sempre. cambia u trafficu à u prossimu. Inoltre, dopu à u primu fallimentu, in 10 seconde, u servitore serà ancu disattivatu, sia per errore sia per timeout - questu ùn pò mancu esse cunfiguratu in ogni modu. Vale à dì, se sguassemu o resettate l'opzione di timeout in a direttiva upstream, allora, ancu se Nginx ùn processerà micca sta dumanda è risponderà cù qualchì errore micca assai bonu, u servitore si chjuderà.
Per evitari, avemu fattu duie cose:
a) anu pruibitu à Nginx di fà questu manualmente - è sfurtunatamenti, l'unicu modu per fà questu hè solu di stabilisce i paràmetri max fails.
b) avemu ricurdatu chì in altri prughjetti usemu un modulu chì ci permette di fà cuntrolli di salute di fondo - per quessa, avemu fattu cuntrolli di salute abbastanza frequenti in modu chì i tempi di inattività in casu d'accidentu seranu minimi.
Sfortunatamente, questu ùn hè micca tuttu, perchè literalmente e prime duie simane di u funziunamentu di stu schema dimustravanu chì u cuntrollu di salute TCP hè ancu una cosa inaffidabile: nantu à u servitore upstream pò esse micca Nginx, o Nginx in D-state, è in u D-state. stu casu, u kernel accettà a cunnessione, u cuntrollu di salute passa, ma ùn funziona micca. Per quessa, avemu rimpiazzatu immediatamente questu cù http di cuntrollu di salute, hà fattu un specificu, chì, se torna 200, allora tuttu funziona in questu script. Pudete fà una logica supplementaria - per esempiu, in u casu di i servitori di caching, verificate chì u sistema di schedari hè muntatu bè:
È questu ci cunvene, salvu chì à u mumentu u circuitu hà ripetutu cumplettamente ciò chì u hardware hà fattu. Ma vulemu fà megliu. Nanzu, avemu avutu un servitore di salvezza, è questu hè probabilmente micca assai bonu, perchè s'è vo avete un centu servitori, allora quandu parechji fallenu à una volta, un servitore di salvezza hè improbabile di affruntà a carica. Dunque, avemu decisu di distribuisce a riservazione in tutti i servitori: avemu fattu solu un altru upstream separatu, hà scrittu tutti i servitori quì cù certi parametri in cunfurmità cù a carica chì ponu serve, aghjunghjenu i stessi cuntrolli di salute chì avemu avutu prima:
Siccomu hè impussibile di andà in un altru upstream in un upstream, era necessariu di assicurà chì se u principale upstream, in quale avemu simpricimenti arregistratu a cache di foto curretta, necessaria, ùn era micca dispunibile, avemu solu andatu à traversu l'error_page à fallback, da induve andemu à a copia di salvezza upstream:
È aghjustendu literalmente quattru servitori, questu hè ciò chì avemu avutu: avemu rimpiazzatu una parte di a carica - l'avemu sguassata da LTM à questi servitori, implementatu a listessa logica quì, utilizendu hardware è software standard, è immediatamente ricevutu u bonus chì questi servitori ponu. esse scalati, perchè ponu esse simpliciamente furnisce quant'è necessariu. Eppo, l'unicu negativu hè chì avemu persu una alta dispunibilità per l'utilizatori esterni. Ma à quellu mumentu avemu avutu a sacrificà questu, perchè era necessariu di risolve u prublema immediatamente. Allora, avemu sguassatu una parte di a carica, era circa 40% in quellu tempu, LTM si sentia bè, è literalmente duie simane dopu chì u prublema hà cuminciatu, avemu cuminciatu à mandà micca 45k richieste per seconda, ma 55k. In fatti, avemu crisciutu da 20% - questu hè chjaramente u trafficu chì ùn avemu micca datu à l'utilizatori. E dopu avè cuminciatu à pensà à cumu risolve u prublema restante - per assicurà una alta accessibilità esterna.
Avemu avutu qualchì pausa, durante a quale avemu discututu quale suluzione avemu aduprà per questu. Ci sò stati pruposti per assicurà a affidabilità utilizendu DNS, utilizendu certi script scritti in casa, protokolli di routing dinamichi ... ci era parechje opzioni, ma hè digià diventatu chjaru chì per una consegna veramente affidabile di e foto, avete bisognu di introduci un altru stratu chì monitorerà questu. . Avemu chjamatu sti machini direttori di foto. U software chì avemu basatu era Keepalived:
Per principià, in chì consiste Keepalived? U primu hè u protokollu VRRP, assai cunnisciutu da i networkers, situatu nantu à l'equipaggiu di a rete chì furnisce a toleranza di difetti à l'indirizzu IP esternu à quale i clienti cunnetta. A seconda parte hè IPVS, servitore virtuale IP, per equilibriu trà i router di foto è assicurà a tolleranza di difetti à questu livellu. E terzu - cuntrolli di salute.
Cuminciamu cù a prima parte: VRRP - chì pare? Ci hè una certa IP virtuale, chì hà una entrata in u dns badoocdn.com, induve i clienti cunnette. À un certu puntu in u tempu, avemu un indirizzu IP in un servitore. I pacchetti Keepalived correnu trà i servitori chì utilizanu u protokollu VRRP, è se u maestru sparisce da u radar - u servitore hà riavviatu o qualcosa d'altru, allora u servitore di salvezza piglia automaticamente stu indirizzu IP - ùn hè micca necessariu azzione manuale. A diffarenza trà u maestru è a copia di salvezza hè principarmenti priurità: più altu hè, più grande hè a probabilità chì a macchina diventerà un maestru. Un vantaghju assai grande hè chì ùn avete micca bisognu di cunfigurà l'indirizzi IP nantu à u servitore stessu, hè abbastanza per discrivili in a cunfigurazione, è se l'indirizzi IP necessanu alcune regule di routing persunalizati, questu hè descrittu direttamente in a cunfigurazione, usendu u listessa sintassi cum'è descritta in u pacchettu VRRP. Ùn scontru micca cose scunnisciute.
Cosa hè questu in pratica? Chì succede se unu di i servitori falla? Appena u maestru sparisce, a nostra copia di salvezza cessà di riceve publicità è diventa automaticamente un maestru. Dopu qualchì tempu, avemu riparatu u maestru, riavviatu, risuscitatu Keepalived - l'annunzii ghjunghjenu cù una priorità più altu ch'è a copia di salvezza, è a copia di salvezza torna automaticamente, sguassate l'indirizzi IP, ùn ci hè micca bisognu di azzione manuale.
Cusì, avemu assicuratu a toleranza di difetti di l'indirizzu IP esternu. A prossima parte hè di equilibrà in qualchì modu u trafficu da l'indirizzu IP esternu à i routers di foto chì sò digià terminatu. Tuttu hè abbastanza chjaru cù i protokolli di equilibriu. Questu hè o un simplice round-robin, o cose un pocu più cumplessu, wrr, lista di cunnessione è cusì. Questu hè basamente descrittu in a documentazione, ùn ci hè nunda di speciale. Ma u metudu di consegna... Quì avemu da piglià un ochju più vicinu à perchè avemu sceltu unu di elli. Questi sò NAT, Direct Routing è TUN. U fattu hè chì avemu prughjettatu immediatamente di furnisce 100 gigabits di trafficu da i siti. Se stimate, avete bisognu di carte di 10 gigabit, nò? 10 carte gigabit in un servitore hè digià fora di u scopu di, almenu, u nostru cuncettu di "equipaggiu standard". È tandu avemu ricurdatu chì ùn avemu micca solu dà un pocu di trafficu, demu e foto.
Chì ci hè speciale? - Enorme differenza trà u trafficu in entrata è in uscita. U trafficu in entrata hè assai chjucu, u trafficu in uscita hè assai grande:
Se fighjate à sti grafici, pudete vede chì in u mumentu u direttore riceve circa 200 MB per seconda, questu hè un ghjornu assai ordinariu. Riturnemu 4,500 MB per seconda, u nostru rapportu hè di circa 1/22. Hè digià chjaru chì per furnisce cumplettamente u trafficu in uscita à i servitori di u travagliu 22, avemu solu bisognu di quellu chì accetta sta cunnessione. Questu hè induve l'algoritmu di routing direttu vene à u nostru aiutu.
Chì pare ? U nostru direttore di foto, secondu a so tavula, trasmette cunnessione à i routers di foto. Ma i routers di foto mandanu u trafficu di ritornu direttamente à Internet, u mandanu à u cliente, ùn torna micca per u direttore di foto, cusì, cù un numeru minimu di machini, assicuremu a tolleranza cumpleta di difetti è u pumping di tuttu u trafficu. In i cunfigurazioni s'assumiglia à questu: spicificà l'algoritmu, in u nostru casu hè un rr simplice, furnisce u metudu di routing direttu è poi cumincià à listà tutti i servitori veri, quanti di elli avemu. Chì determinarà stu trafficu. Se avemu unu o dui servitori più quì, o parechji servitori, una tale necessità nasce - solu aghjunghje sta sezione à a cunfigurazione è ùn vi preoccupate micca troppu. Da u latu di i servitori veri, da u latu di u router di foto, stu metudu hè bisognu di a cunfigurazione più minima, hè perfettamenti descritta in a documentazione, è ùn ci sò micca chjappi.
Ciò chì hè particularmente piacevule hè chì una suluzione ùn implica micca un redesignu radicali di a reta lucale, questu era impurtante per noi chì avemu avutu per risolve questu cù costi minimi; S'è vo guardate , allora videremu ciò chì pare. Quì avemu un certu servitore virtuale, in u portu 443, ascolta, accetta a cunnessione, tutti i servitori di travagliu sò listati, è pudete vede chì a cunnessione hè, dà o pigliate, u listessu. Se fighjemu e statistiche nantu à u stessu servitore virtuale, avemu pacchetti in entrata, cunnessione in entrata, ma assolutamente micca in uscita. I cunnessione in uscita vanu direttamente à u cliente. Va bè, avemu pussutu sbilanciallu. Avà, chì succede se unu di i nostri routers di foto falla? Dopu tuttu, u ferru hè ferru. Pò andà in u panicu di u kernel, pò rompe, l'alimentazione elettrica pò brusgià. Qualcosa. Hè per quessa chì i cuntrolli di salute sò necessarii. Puderanu esse simplicità cum'è cuntrollà cumu u portu hè apertu, o qualcosa di più cumplessu, finu à qualchi script scritti in casa chì ancu verificate a logica cummerciale.
Avemu firmatu in un locu à mezu: avemu una dumanda https à un locu specificu, u script hè chjamatu, se risponde cù una risposta 200, credemu chì tuttu hè bè cù stu servitore, chì hè vivu è pò esse attivatu abbastanza. facilmente.
Cumu questu, di novu, vede in pratica? Spegnemu u servitore per mantenimentu - lampendu u BIOS, per esempiu. In i logs avemu subitu un timeout, vedemu a prima linea, dopu trè tentativi hè marcatu cum'è "fallutu", è hè simplicemente eliminatu da a lista.
Una seconda opzione di cumportamentu hè ancu pussibule, quandu VS hè simplicemente pusatu à cero, ma se a foto hè tornata, questu ùn hè micca bè. U servitore vene, Nginx principia quì, u cuntrollu di salute capisce immediatamente chì a cunnessione hè travagliatu, chì tuttu hè bè, è u servitore appare in a nostra lista, è a carica immediatamente principia à esse appiicata. Nisuna azzione manuale hè necessaria da l'amministratore di u duvere. U servitore riavviatu di notte - u dipartimentu di surviglianza ùn ci chjama micca nantu à questu di notte. Vi informanu chì questu hè accadutu, tuttu hè bè.
Allora, in una manera abbastanza simplice, cù l'aiutu di un picculu numeru di servitori, avemu risoltu u prublema di a toleranza di difetti esterni.
Tuttu ciò chì resta à dì hè chì tuttu questu, sicuru, deve esse monitoratu. Separatamente, deve esse nutatu chì Keepalivede, cum'è u software scrittu assai tempu fà, hà una mansa di manere di monitorà, sia utilizendu cuntrolli via DBus, SMTP, SNMP è Zabbix standard. In più, ellu stessu sapi scrive lettere per quasi ogni starnutu, è per esse onestu, in un certu puntu avemu ancu pensatu di disattivà, perchè scrive assai lettere per ogni cambiamentu di trafficu, accende, per ogni cunnessione IP. eccetera . Di sicuru, s'ellu ci sò assai servitori, allura vi pò sopravvivere cù sti littri. Monitoremu nginx nantu à i router di foto cù metudi standard, è u monitoraghju hardware ùn hè micca andatu. Avemu, sicuru, cunsigliemu duie cose più: prima, cuntrolli di salute esterni è dispunibilità, perchè ancu s'ellu tuttu funziona, in fattu, forse l'utilizatori ùn ricevenu micca foto per via di prublemi cù i fornituri esterni o qualcosa di più cumplessu. Hè sempre vale a pena di mantene in un altru reta, in Amazon o in un altru locu, una macchina separata chì pò ping i vostri servitori da l'esternu, è vale ancu a pena aduprà sia a rilevazione di anomalie, per quelli chì sà cumu fà l'apprendimentu automaticu complicatu, o un seguimentu simplice. , Almenu per seguità se e richieste sò cascate bruscamente, o, à u cuntrariu, anu aumentatu. Pò esse ancu utile.
Riassumemu: avemu, in fattu, rimpiazzatu a suluzione di ferru, chì à un certu puntu hà cessatu di cunvene à noi, cù un sistema abbastanza simplice chì face tuttu u listessu, vale à dì, furnisce a terminazione di u trafficu HTTPS è più routing intelligente cù u i cuntrolli di salute necessarii. Avemu aumentatu a stabilità di stu sistema, vale à dì, avemu sempre una alta dispunibilità per ogni strata, in più avemu u bonus chì hè abbastanza faciule per scala tuttu nantu à ogni strata, perchè hè hardware standard cù software standard, vale à dì. , avemu simplificatu u diagnosticu pussibuli prublemi.
Chì avemu finitu ? Avemu avutu un prublema durante e vacanze di ghjennaghju di u 2018. In i primi sei mesi mentre mettemu stu schema in opera, l'avemu allargatu à tuttu u trafficu per caccià tuttu u trafficu da LTM, avemu cultivatu solu in u trafficu in un centru di dati da 40 gigabits à 60 gigabits, è à u stessu tempu per l'annu sanu 2018 anu pussutu mandà guasi trè volte più foto per seconda.
Source: www.habr.com