Web-ul modern este aproape de neconceput fără conținut media: aproape fiecare bunica are un smartphone, toată lumea este pe rețelele sociale, iar timpul de nefuncționare în întreținere este costisitor pentru companii. Iată o transcriere a poveștii companiei despre modul în care a organizat livrarea fotografiilor folosind o soluție hardware, ce probleme de performanță a întâmpinat în proces, ce le-a cauzat și cum au fost rezolvate aceste probleme folosind o soluție software bazată pe Nginx, asigurând în același timp toleranța la erori la toate nivelurile (). Mulțumim autorilor povestirii lui Oleg Efimova și Alexandra Dymova, care și-au împărtășit experiența la conferință .
— Să începem cu o mică introducere despre cum stocăm și memorăm fotografiile. Avem un strat în care le stocăm și un strat în care punem în cache fotografiile. În același timp, dacă dorim să obținem o rată de trick mare și să reducem încărcarea stocării, este important pentru noi ca fiecare fotografie a unui utilizator individual să fie pe un server de cache. În caz contrar, ar trebui să instalăm de atâtea ori mai multe discuri cât avem mai multe servere. Rata noastră de șmecherie este de aproximativ 99%, adică reducem încărcarea stocării noastre de 100 de ori, iar pentru a face acest lucru, acum 10 ani, când se construiau toate acestea, aveam 50 de servere. În consecință, pentru a servi aceste fotografii, aveam nevoie în esență de 50 de domenii externe pe care aceste servere le servesc.
Desigur, imediat a apărut întrebarea: dacă unul dintre serverele noastre se defectează și devine indisponibil, ce parte din trafic pierdem? Ne-am uitat la ce era pe piață și am decis să cumpărăm o piesă de hardware, astfel încât să ne rezolve toate problemele. Alegerea a căzut pe soluția companiei de rețea F5 (care, de altfel, a cumpărat recent NGINX, Inc): BIG-IP Local Traffic Manager.
Ce face această piesă hardware (LTM): este un router de fier care face redundanță de fier a porturilor sale externe și vă permite să direcționați traficul pe baza topologiei rețelei, pe anumite setări și face verificări de sănătate. A fost important pentru noi ca această piesă hardware să poată fi programată. În consecință, am putea descrie logica modului în care fotografiile unui anumit utilizator au fost servite dintr-un anumit cache. Cu ce seamănă? Există o bucată de hardware care se uită la Internet pe un domeniu, un IP, descarcă ssl, analizează cererile http, selectează un număr de cache din IRule, unde să meargă și lasă traficul să meargă acolo. În același timp, efectuează verificări de sănătate și, în cazul în care o mașină nu este disponibilă, la acel moment am făcut astfel încât traficul să ajungă la un server de rezervă. Din punct de vedere al configurației, există, desigur, câteva nuanțe, dar în general totul este destul de simplu: înregistrăm un card, corespondența unui anumit număr cu IP-ul nostru în rețea, spunem că vom asculta pe porturile 80 și 443, spunem că dacă serverul este indisponibil, atunci trebuie să trimiteți trafic către cel de rezervă, în acest caz al 35-lea, și descriem o grămadă de logică despre cum ar trebui să fie dezasamblată această arhitectură. Singura problemă a fost că limbajul în care era programat hardware-ul era Tcl. Dacă cineva își amintește acest lucru... acest limbaj este mai mult scris decât un limbaj convenabil pentru programare:
Ce am primit? Am primit o piesă hardware care asigură o disponibilitate ridicată a infrastructurii noastre, direcționează întregul trafic, oferă beneficii pentru sănătate și doar funcționează. Mai mult decât atât, funcționează destul de mult timp: în ultimii 10 ani nu au existat plângeri în acest sens. Până la începutul lui 2018, trimiteam deja aproximativ 80 de fotografii pe secundă. Acesta este undeva în jur de 80 de gigabiți de trafic de la ambele centre de date.
In orice caz…
La începutul lui 2018, am văzut o poză urâtă pe topuri: timpul necesar pentru trimiterea fotografiilor a crescut în mod clar. Și a încetat să ne mai convină. Problema este că acest comportament era vizibil doar în perioada de vârf a traficului - pentru compania noastră aceasta este noaptea de duminică spre luni. Dar în restul timpului sistemul s-a comportat ca de obicei, fără semne de eșec.
Cu toate acestea, problema trebuia rezolvată. Am identificat posibile blocaje și am început să le eliminăm. În primul rând, desigur, am extins uplink-urile externe, am efectuat un audit complet al uplink-urilor interne și am găsit toate blocajele posibile. Dar toate acestea nu au dat un rezultat evident, problema nu a dispărut.
Un alt posibil blocaj a fost performanța cache-urilor foto în sine. Și am decis că, probabil, problema ține de ei. Ei bine, am extins performanța - în principal porturi de rețea pe cache-urile foto. Dar din nou nu s-a observat nicio îmbunătățire evidentă. În cele din urmă, am acordat o atenție deosebită performanței LTM-ului în sine și aici am văzut o imagine tristă pe grafice: sarcina de pe toate procesoarele începe să meargă fără probleme, dar apoi ajunge brusc la un platou. În același timp, LTM nu mai răspunde în mod adecvat la verificările de sănătate și uplink-urile și începe să le dezactiveze aleatoriu, ceea ce duce la o degradare gravă a performanței.
Adică am identificat sursa problemei, am identificat blocajul. Rămâne să decidem ce vom face.
Primul lucru, cel mai evident, pe care l-am putea face este să modernizăm cumva LTM-ul în sine. Dar există câteva nuanțe aici, deoarece acest hardware este destul de unic, nu vei merge la cel mai apropiat supermarket și îl vei cumpăra. Acesta este un contract separat, un contract de licență separat și va dura mult timp. A doua opțiune este să începeți să vă gândiți singur, să veniți cu propria soluție folosind propriile componente, de preferință folosind un program de acces deschis. Tot ce rămâne este să decidem ce anume vom alege pentru asta și cât timp vom petrece rezolvării acestei probleme, deoarece utilizatorii nu primeau suficiente fotografii. Prin urmare, trebuie să facem toate acestea foarte, foarte repede, s-ar putea spune ieri.
Întrucât sarcina suna ca „fă ceva cât mai repede posibil și utilizând hardware-ul pe care îl avem”, primul lucru la care ne-am gândit a fost să scoatem pur și simplu unele mașini nu foarte puternice din față, să punem Nginx acolo, cu care știm cum să facem lucrați și încercați să implementați aceeași logică pe care o făcea hardware-ul. Adică, de fapt, ne-am lăsat hardware-ul, le-am instalat încă 4 servere pe care a trebuit să le configuram, le-am creat domenii externe, la fel ca acum 10 ani... Am pierdut puțin din disponibilitate dacă aceste mașini au căzut, dar cu atât mai puțin, au rezolvat problema utilizatorilor noștri la nivel local.
În consecință, logica rămâne aceeași: instalăm Nginx, poate face SSL-offload, putem programa cumva logica de rutare, verificările de sănătate în configurații și pur și simplu duplicam logica pe care o aveam înainte.
Să ne așezăm să scriem configurațiile. La început părea că totul a fost foarte simplu, dar, din păcate, este foarte greu să găsești manuale pentru fiecare sarcină. Prin urmare, nu vă recomandăm să căutați pur și simplu pe Google „cum se configurează Nginx pentru fotografii”: este mai bine să vă referiți la documentația oficială, care va arăta ce setări trebuie atinse. Dar este mai bine să alegeți singur parametrul specific. Ei bine, atunci totul este simplu: descriem serverele pe care le avem, descriem certificatele... Dar cel mai interesant lucru este, de fapt, logica de rutare în sine.
La început ni s-a părut că descriem pur și simplu locația noastră, potrivind numărul cache-ului nostru de fotografii din ea, folosind mâinile noastre sau un generator pentru a descrie de câte amonte avem nevoie, în fiecare amonte indicăm serverul către care ar trebui să circule traficul. go, și un server de rezervă - dacă serverul principal nu este disponibil:
Dar, probabil, dacă totul ar fi atât de simplu, pur și simplu ne-am duce acasă și nu am spune nimic. Din păcate, cu setările implicite Nginx, care, în general, au fost făcute de-a lungul multor ani de dezvoltare și nu sunt în întregime potrivite pentru acest caz... configurația arată astfel: dacă un server din amonte are o eroare de solicitare sau timeout, Nginx întotdeauna comută traficul la următorul. Mai mult, după prima defecțiune, în 10 secunde serverul va fi și el oprit, atât din greșeală, cât și prin timeout - acesta nici măcar nu poate fi configurat în niciun fel. Adică, dacă eliminăm sau resetam opțiunea timeout din directiva upstream, atunci, deși Nginx nu va procesa această solicitare și va răspunde cu o eroare nu foarte bună, serverul se va închide.
Pentru a evita acest lucru, am făcut două lucruri:
a) au interzis lui Nginx să facă acest lucru manual - și, din păcate, singura modalitate de a face acest lucru este să setați pur și simplu setările maxime de eșecuri.
b) ne-am amintit că în alte proiecte folosim un modul care ne permite să facem controale de sănătate de fond - în consecință, am făcut controale de sănătate destul de frecvente, astfel încât timpul de nefuncționare în caz de accident să fie minim.
Din păcate, nici asta nu este totul, deoarece, literalmente, primele două săptămâni de funcționare ale acestei scheme au arătat că verificarea sănătății TCP este, de asemenea, un lucru nesigur: pe serverul din amonte este posibil să nu fie Nginx sau Nginx în stare D, iar în În acest caz, nucleul va accepta conexiunea, verificarea de sănătate va trece, dar nu va funcționa. Prin urmare, am înlocuit imediat acest lucru cu http de verificare a stării de sănătate, am făcut unul specific, care, dacă returnează 200, atunci totul funcționează în acest script. Puteți face logică suplimentară - de exemplu, în cazul serverelor de cache, verificați dacă sistemul de fișiere este montat corect:
Și asta ni s-ar potrivi, cu excepția faptului că în acest moment circuitul a repetat complet ceea ce a făcut hardware-ul. Dar am vrut să facem mai bine. Anterior, aveam un server de rezervă, iar acesta probabil nu este foarte bun, deoarece dacă aveți o sută de servere, atunci când mai multe eșuează simultan, este puțin probabil ca un server de rezervă să facă față sarcinii. Prin urmare, am decis să distribuim rezervarea pe toate serverele: pur și simplu am făcut un alt separat în amonte, am scris acolo toate serverele cu anumiți parametri în funcție de sarcina pe care o pot servi, am adăugat aceleași verificări de sănătate pe care le-am avut înainte:
Deoarece este imposibil să mergem la un alt în amonte în cadrul unuia din amonte, a fost necesar să ne asigurăm că, în cazul în care principalul în amonte, în care pur și simplu am înregistrat cache-ul foto corect, necesar, nu era disponibil, pur și simplu am trecut prin pagina de eroare la fallback, de la unde am mers la backup-ul în amonte:
Și, adăugând literalmente patru servere, iată ce am obținut: am înlocuit o parte din încărcare - am eliminat-o din LTM pe aceste servere, am implementat aceeași logică acolo, folosind hardware și software standard și am primit imediat bonusul pe care aceste servere îl pot. să fie scalate, deoarece pot fi pur și simplu furnizate atât cât este necesar. Ei bine, singurul negativ este că am pierdut disponibilitatea ridicată pentru utilizatorii externi. Dar în acel moment a trebuit să sacrificăm asta, pentru că era necesar să rezolvăm problema imediat. Deci, am eliminat o parte din încărcare, era de aproximativ 40% în acel moment, LTM s-a simțit bine și, literalmente, la două săptămâni după ce a început problema, am început să trimitem nu 45k cereri pe secundă, ci 55k. De fapt, am crescut cu 20% - acesta este în mod clar traficul pe care nu l-am oferit utilizatorului. Și după aceea au început să se gândească la cum să rezolve problema rămasă - pentru a asigura o accesibilitate externă ridicată.
Am avut o pauză, timp în care am discutat ce soluție vom folosi pentru asta. Au existat propuneri de asigurare a fiabilității folosind DNS, folosind niște scripturi scrise acasă, protocoale de rutare dinamică... erau multe opțiuni, dar deja a devenit clar că pentru livrarea cu adevărat fiabilă a fotografiilor, trebuie să introduceți un alt strat care să monitorizeze acest lucru. . Am numit aceste mașini directori foto. Software-ul pe care ne-am bazat a fost Keepalived:
Pentru început, în ce constă Keepalived? Primul este protocolul VRRP, larg cunoscut utilizatorilor de rețea, situat pe echipamentele de rețea care oferă toleranță la erori la adresa IP externă la care se conectează clienții. A doua parte este IPVS, server virtual IP, pentru echilibrarea între routerele foto și asigurarea toleranței la erori la acest nivel. Și al treilea - controale de sănătate.
Să începem cu prima parte: VRRP - cum arată? Există un anumit IP virtual, care are o intrare în dns badoocdn.com, unde clienții se conectează. La un moment dat, avem o adresă IP pe un server. Pachetele Keepalived rulează între servere folosind protocolul VRRP, iar dacă masterul dispare de pe radar - serverul a repornit sau altceva, atunci serverul de rezervă preia automat această adresă IP - nu sunt necesare acțiuni manuale. Diferența dintre master și backup este în principal prioritară: cu cât este mai mare, cu atât este mai mare șansa ca mașina să devină master. Un avantaj foarte mare este că nu trebuie să configurați adrese IP pe serverul propriu-zis, este suficient să le descrieți în configurație, iar dacă adresele IP au nevoie de niște reguli de rutare personalizate, acest lucru este descris direct în configurație, folosind aceeași sintaxă ca cea descrisă în pachetul VRRP. Nu vei întâlni lucruri necunoscute.
Cum arată asta în practică? Ce se întâmplă dacă unul dintre servere eșuează? De îndată ce masterul dispare, backup-ul nostru nu mai primește reclame și devine automat master. După ceva timp, am reparat masterul, am repornit, am ridicat Keepalived - reclamele sosesc cu o prioritate mai mare decât backup-ul, iar backup-ul se întoarce automat, elimină adresele IP, nu trebuie făcute acțiuni manuale.
Astfel, ne-am asigurat toleranța la erori a adresei IP externe. Următoarea parte este de a echilibra cumva traficul de la adresa IP externă la routerele foto care îl termină deja. Totul este destul de clar cu protocoalele de echilibrare. Acesta este fie un simplu round-robin, fie lucruri ceva mai complexe, wrr, conexiune listă și așa mai departe. Acest lucru este descris practic în documentație, nu există nimic special. Dar metoda de livrare... Aici vom arunca o privire mai atentă la motivul pentru care am ales unul dintre ele. Acestea sunt NAT, Direct Routing și TUN. Cert este că ne-am planificat imediat să livrăm 100 de gigabiți de trafic de pe site-uri. Dacă estimați, aveți nevoie de carduri de 10 gigabit, nu? Cardurile de 10 gigabit într-un singur server depășesc deja domeniul de aplicare, cel puțin, a conceptului nostru de „echipament standard”. Și apoi ne-am amintit că nu doar dăm puțin trafic, dăm fotografii.
Ce este special? — Diferență enormă între traficul de intrare și cel de ieșire. Traficul de intrare este foarte mic, traficul de ieșire este foarte mare:
Dacă te uiți la aceste grafice, poți vedea că în momentul de față regizorul primește aproximativ 200 MB pe secundă, aceasta este cea mai obișnuită zi. Revenim 4,500 MB pe secundă, raportul nostru este de aproximativ 1/22. Este deja clar că pentru a furniza pe deplin trafic de ieșire către 22 de servere de lucru, avem nevoie doar de unul care acceptă această conexiune. Aici ne vine în ajutor algoritmul de rutare directă.
Cu ce seamănă? Directorul nostru foto, conform tabelului său, transmite conexiuni către routerele foto. Dar routerele foto trimit traficul de retur direct pe Internet, îl trimit către client, nu se întoarce prin directorul foto, astfel, cu un număr minim de mașini, asigurăm toleranță completă la erori și pomparea întregului trafic. În configurații arată așa: specificăm algoritmul, în cazul nostru este un simplu rr, furnizăm metoda de rutare directă și apoi începem să listăm toate serverele reale, câte dintre ele avem. Ceea ce va determina acest trafic. Dacă mai avem unul sau două servere acolo, sau mai multe servere, apare o astfel de nevoie - doar adăugăm această secțiune la configurație și nu vă faceți griji prea mult. Din partea serverelor reale, din partea routerului foto, această metodă necesită cea mai minimă configurație, este descrisă perfect în documentație și nu există capcane acolo.
Ceea ce este deosebit de plăcut este că o astfel de soluție nu implică o reproiectare radicală a rețelei locale, acest lucru a fost important pentru noi; Daca te uiti la , apoi vom vedea cum arata. Aici avem un anumit server virtual, pe portul 443, ascultă, acceptă conexiunea, sunt listate toate serverele care funcționează și poți vedea că conexiunea este, da sau ia, aceeași. Dacă ne uităm la statisticile de pe același server virtual, avem pachete de intrare, conexiuni de intrare, dar absolut deloc cele de ieșire. Conexiunile de ieșire ajung direct la client. Bine, am reușit să-l dezechilibram. Acum, ce se întâmplă dacă unul dintre routerele noastre foto eșuează? La urma urmei, fierul este fier. Poate intra în panică nucleului, se poate rupe, sursa de alimentare se poate arde. Orice. De aceea sunt necesare controale de sănătate. Acestea pot fi la fel de simple ca verificarea modului în care este deschis portul sau ceva mai complex, până la unele scripturi scrise acasă care vor verifica chiar logica afacerii.
Ne-am oprit undeva la mijloc: avem o cerere https către o anumită locație, scriptul este apelat, dacă răspunde cu un răspuns al 200-lea, credem că totul este în regulă cu acest server, că este viu și poate fi pornit destul de mult uşor.
Cum arată asta, din nou, în practică? Să oprim serverul pentru întreținere - de exemplu, să flashăm BIOS-ul. În jurnale, avem imediat un timeout, vedem prima linie, apoi după trei încercări este marcată ca „eșuată” și pur și simplu este eliminată din listă.
O a doua opțiune de comportament este de asemenea posibilă, atunci când VS este pur și simplu setat la zero, dar dacă fotografia este returnată, aceasta nu funcționează bine. Serverul apare, Nginx pornește acolo, Health-check înțelege imediat că conexiunea funcționează, că totul este în regulă, iar serverul apare în lista noastră și încărcarea începe imediat să i se aplice. Nu sunt necesare acțiuni manuale din partea administratorului de serviciu. Serverul a repornit noaptea - departamentul de monitorizare nu ne sună despre asta noaptea. Ei vă anunță că acest lucru s-a întâmplat, totul este în regulă.
Deci, într-un mod destul de simplu, cu ajutorul unui număr mic de servere, am rezolvat problema toleranței la erori externe.
Tot ce rămâne de spus este că toate acestea, desigur, trebuie monitorizate. Separat, trebuie remarcat faptul că Keepalivede, așa cum software-ul scris cu mult timp în urmă, are o mulțime de modalități de a-l monitoriza, ambele folosind verificări prin DBus, SMTP, SNMP și Zabbix standard. În plus, el însuși știe să scrie scrisori pentru aproape fiecare strănut și, să fiu sincer, la un moment dat chiar ne-am gândit să-l oprim, pentru că scrie o mulțime de scrisori pentru orice comutare de trafic, pornire, pentru fiecare conexiune IP, și așa mai departe . Desigur, dacă există o mulțime de servere, atunci te poți copleși cu aceste scrisori. Monitorizăm nginx pe routere foto folosind metode standard, iar monitorizarea hardware nu a dispărut. Desigur, am mai sfătui două lucruri: în primul rând, verificări externe de sănătate și disponibilitate, pentru că, chiar dacă totul funcționează, de fapt, poate utilizatorii nu primesc fotografii din cauza unor probleme cu furnizorii externi sau ceva mai complex. Merită întotdeauna să păstrați undeva într-o altă rețea, în Amazon sau în altă parte, o mașină separată care să vă poată ping serverele din exterior și, de asemenea, merită să utilizați fie detectarea anomaliilor, pentru cei care știu să facă învățarea automată complicată, fie monitorizarea simplă. , cel puțin pentru a urmări dacă cererile au scăzut brusc sau, dimpotrivă, au crescut. Poate fi și util.
Să rezumam: noi, de fapt, am înlocuit soluția de fier, care la un moment dat a încetat să ni se potrivească, cu un sistem destul de simplu care face totul la fel, adică oferă terminarea traficului HTTPS și rutarea inteligentă ulterioară cu controalele medicale necesare. Am crescut stabilitatea acestui sistem, adică mai avem disponibilitate mare pentru fiecare strat, plus avem bonusul că este destul de ușor să-l scalați pe toate pe fiecare strat, deoarece este hardware standard cu software standard, adică , am simplificat diagnosticarea posibilelor probleme.
Cu ce am ajuns? Am avut o problemă în timpul sărbătorilor din ianuarie 2018. În primele șase luni, când am pus această schemă în funcțiune, am extins-o la tot traficul pentru a elimina tot traficul din LTM, am crescut doar traficul într-un singur centru de date de la 40 de gigabiți la 60 de gigabiți și, în același timp, pentru întregul an 2018 au putut trimite aproape de trei ori mai multe fotografii pe secundă.
Sursa: www.habr.com