Savremeni web je gotovo nezamisliv bez medijskog sadržaja: skoro svaka baka ima pametni telefon, svi su na društvenim mrežama, a zastoji u održavanju su skupi za kompanije. Evo transkripta priče kompanije o tome kako je organizirala isporuku fotografija koristeći hardversko rješenje, na kakve je probleme u performansama naišla u procesu, šta ih je uzrokovalo i kako su ovi problemi riješeni korištenjem softverskog rješenja baziranog na Nginxu, uz osiguranje tolerancije grešaka na svim nivoima (). Zahvaljujemo se autorima Olegove priče Efimova i Alexandra Dymova, koje su podijelile svoja iskustva na konferenciji .
— Počnimo s malim uvodom o tome kako pohranjujemo i keširamo fotografije. Imamo sloj na kojem ih pohranjujemo i sloj u koji keširamo fotografije. Istovremeno, ako želimo postići visoku stopu trikova i smanjiti opterećenje pohrane, važno nam je da svaka fotografija pojedinog korisnika bude na jednom keš serveru. Inače bismo morali da instaliramo onoliko puta više diskova koliko imamo više servera. Naš trik rate je oko 99%, odnosno smanjujemo opterećenje na našem skladištu za 100 puta, a da bismo to uradili, prije 10 godina, kada se sve ovo gradilo, imali smo 50 servera. Shodno tome, da bismo servirali ove fotografije, trebalo nam je u suštini 50 vanjskih domena koje ovi serveri opslužuju.
Naravno, odmah se postavilo pitanje: ako se jedan od naših servera pokvari i postane nedostupan, koji dio prometa gubimo? Pogledali smo šta ima na tržištu i odlučili da kupimo deo hardvera kako bi rešio sve naše probleme. Izbor je pao na rešenje F5-mrežne kompanije (koja je, inače, nedavno kupila NGINX, Inc): BIG-IP Local Traffic Manager.
Ono što ovaj komad hardvera (LTM) radi: to je željezni ruter koji čini željenu redundantnost svojih vanjskih portova i omogućava vam da usmjeravate promet na osnovu topologije mreže, na nekim postavkama i vrši provjere zdravlja. Bilo nam je važno da se ovaj komad hardvera može programirati. U skladu s tim, mogli bismo opisati logiku kako su fotografije određenog korisnika servirane iz određene keš memorije. Kako izgleda? Postoji komad hardvera koji gleda na Internet na jednom domenu, jednom IP-u, vrši ssl offload, analizira http zahtjeve, bira broj keš memorije iz IRule-a, gdje da ide i pušta promet tamo. Istovremeno radi i zdravstvene provjere, a u slučaju da neka mašina bude nedostupna, tada smo napravili tako da promet ide na jedan backup server. Sa stanovišta konfiguracije, postoje, naravno, neke nijanse, ali općenito je sve prilično jednostavno: registriramo karticu, korespondenciju određenog broja našem IP-u na mreži, kažemo da ćemo slušati na portovima 80 i 443, kažemo da ako je server nedostupan, onda treba da pošaljete saobraćaj na rezervni, u ovom slučaju 35., a mi opisujemo gomilu logike kako ovu arhitekturu treba rastaviti. Jedini problem je bio što je jezik na kojem je hardver programiran bio Tcl. Ako se neko sjeća ovoga... ovaj jezik je više samo za pisanje nego jezik pogodan za programiranje:
Šta smo dobili? Dobili smo dio hardvera koji osigurava visoku dostupnost naše infrastrukture, usmjerava sav naš promet, pruža zdravstvene beneficije i jednostavno radi. Štaviše, radi prilično dugo: u proteklih 10 godina nije bilo pritužbi na to. Do početka 2018. već smo slali oko 80 fotografija u sekundi. Ovo je negdje oko 80 gigabita prometa iz oba naša data centra.
Kako god…
Početkom 2018. vidjeli smo ružnu sliku na top listama: vrijeme koje je bilo potrebno za slanje fotografija se očito povećalo. I to nam je prestalo. Problem je što je ovakvo ponašanje bilo vidljivo samo u špicu saobraćaja - za našu firmu je ovo noć sa nedjelje na ponedjeljak. Ali ostatak vremena sistem se ponašao kao i obično, bez znakova kvara.
Ipak, problem je morao biti riješen. Identificirali smo moguća uska grla i počeli ih otklanjati. Prije svega, naravno, proširili smo eksterne uplinkove, izvršili kompletnu reviziju internih uplinkova i pronašli sva moguća uska grla. Ali sve to nije dalo očigledan rezultat, problem nije nestao.
Još jedno moguće usko grlo bile su performanse samih foto keša. I odlučili smo da je problem možda u njima. Pa, proširili smo performanse – uglavnom mrežne portove na foto kešovima. Ali opet nije viđen očigledan napredak. Na kraju smo pomno pazili na performanse samog LTM-a i tu smo na grafovima vidjeli tužnu sliku: opterećenje na svim CPU-ima počinje glatko, ali onda odjednom dolazi do platoa. Istovremeno, LTM prestaje da adekvatno reaguje na zdravstvene provere i uplinkove i počinje nasumično da ih isključuje, što dovodi do ozbiljne degradacije performansi.
Odnosno, identifikovali smo izvor problema, identifikovali usko grlo. Ostaje da odlučimo šta ćemo uraditi.
Prva, najočiglednija stvar koju bismo mogli učiniti je da nekako moderniziramo sam LTM. Ali ovdje postoje neke nijanse, jer je ovaj hardver prilično jedinstven, nećete otići u najbliži supermarket i kupiti ga. Ovo je poseban ugovor, poseban ugovor o licenci, i biće potrebno dosta vremena. Druga opcija je da počnete da razmišljate svojom glavom, da smislite sopstveno rešenje koristeći sopstvene komponente, po mogućnosti koristeći program otvorenog pristupa. Ostaje samo da odlučimo šta ćemo tačno izabrati za ovo i koliko vremena ćemo potrošiti na rešavanje ovog problema, jer korisnici nisu dobijali dovoljno fotografija. Dakle, sve ovo moramo da uradimo veoma, veoma brzo, moglo bi se reći juče.
Pošto je zadatak zvučao kao „uradite nešto što je brže moguće i koristeći hardver koji imamo“, prvo što smo pomislili je da jednostavno uklonimo neke ne baš moćne mašine sa prednje strane, stavimo Nginx tamo, sa kojim znamo kako da raditi i pokušati implementirati svu istu logiku koju je ranije radio hardver. Naime, ostavili smo hardver, instalirali još 4 servera koje smo morali da konfigurišemo, kreirali vanjske domene za njih, slično kao pre 10 godina... Malo smo izgubili u dostupnosti ako su ove mašine pale, ali još manje, lokalno su riješili problem naših korisnika.
U skladu s tim, logika ostaje ista: instaliramo Nginx, on može napraviti SSL-offload, možemo nekako programirati logiku rutiranja, provjeriti zdravlje u konfiguracijama i jednostavno duplicirati logiku koju smo imali prije.
Hajde da sjednemo da pišemo konfiguracije. U početku se činilo da je sve vrlo jednostavno, ali, nažalost, vrlo je teško pronaći priručnike za svaki zadatak. Stoga ne preporučujemo jednostavno guglanje "kako konfigurirati Nginx za fotografije": bolje je pogledati službenu dokumentaciju koja će pokazati koje postavke treba dodirnuti. Ali bolje je da sami odaberete određeni parametar. Pa, onda je sve jednostavno: opisujemo servere koje imamo, opisujemo certifikate... Ali najzanimljivija stvar je, zapravo, sama logika rutiranja.
U početku nam se činilo da jednostavno opisujemo svoju lokaciju, poklapamo se s brojem naše foto keš memorije u njoj, koristeći ruke ili generator da opišemo koliko nam je uzvodno potrebno, u svakom uzvodnom dijelu označavamo server na koji bi trebao promet idi i rezervni server - ako glavni server nije dostupan:
Ali, vjerovatno, da je sve tako jednostavno, jednostavno bismo otišli kući i ništa ne bismo rekli. Nažalost, sa zadanim Nginx postavkama, koje su, generalno gledano, napravljene tokom mnogo godina razvoja i nisu u potpunosti prikladne za ovaj slučaj... konfiguracija izgleda ovako: ako neki upstream server ima grešku zahtjeva ili timeout, Nginx uvijek prebacuje saobraćaj na sljedeći. Štaviše, nakon prvog kvara, u roku od 10 sekundi server će se također isključiti, greškom i timeoutom - to se ni na koji način ne može konfigurirati. To jest, ako uklonimo ili resetujemo opciju timeout u upstream direktivi, tada će se, iako Nginx neće obraditi ovaj zahtjev i odgovoriti s nekom ne baš dobrom greškom, server ugasiti.
Da bismo ovo izbegli, uradili smo dve stvari:
a) zabranili su Nginxu da to radi ručno - i nažalost, jedini način da to učinite je da jednostavno postavite postavke za maksimalne greške.
b) sjetili smo se da u drugim projektima koristimo modul koji nam omogućava da radimo provjere zdravlja u pozadini – shodno tome, radili smo prilično česte zdravstvene provjere kako bi zastoji u slučaju nesreće bili minimalni.
Nažalost, ni to nije sve, jer su bukvalno prve dvije sedmice rada ove šeme pokazale da je TCP provjera zdravlja također nepouzdana stvar: na upstream serveru to možda nije Nginx, ili Nginx u D-stanju, a u u ovom slučaju kernel će prihvatiti vezu, provjera zdravlja će proći, ali neće raditi. Stoga smo ovo odmah zamijenili sa http-provjere zdravlja, napravili specifičan, koji, ako vrati 200, onda sve radi u ovoj skripti. Možete napraviti dodatnu logiku - na primjer, u slučaju servera za keširanje, provjerite da li je sistem datoteka ispravno montiran:
I ovo bi nam odgovaralo, osim što je trenutno kolo u potpunosti ponovilo ono što je hardver uradio. Ali htjeli smo bolje. Ranije smo imali jedan rezervni server, a to verovatno nije baš dobro, jer ako imate sto servera, onda kada nekoliko pokvari odjednom, jedan rezervni server se verovatno neće nositi sa opterećenjem. Stoga smo odlučili da rasporedimo rezervaciju na sve servere: jednostavno smo napravili još jednu zasebnu upstream, napisali sve servere tamo sa određenim parametrima u skladu sa opterećenjem koje mogu opsluživati, dodali iste zdravstvene provjere koje smo imali prije:
Budući da je nemoguće ići na drugi uzvodno unutar jednog uzvodnog, bilo je potrebno osigurati da ako glavni uzvodni, u koji smo jednostavno snimili ispravnu, neophodnu predmemoriju fotografija, nije bio dostupan, jednostavno smo prošli kroz error_page do rezervnog, od gdje smo otišli na rezervnu uzvodno:
I doslovno dodavanjem četiri servera, dobili smo ovo: zamijenili smo dio opterećenja - uklonili smo ga sa LTM-a na ove servere, implementirali istu logiku tamo, koristeći standardni hardver i softver, i odmah dobili bonus koji ovi serveri mogu biti skalirani, jer se mogu jednostavno isporučiti koliko god je potrebno. Pa, jedina negativna je ta što smo izgubili visoku dostupnost za vanjske korisnike. Ali u tom trenutku smo to morali žrtvovati, jer je bilo potrebno odmah riješiti problem. Dakle, uklonili smo dio opterećenja, bilo je oko 40% u to vrijeme, LTM se osjećao dobro, a bukvalno dvije sedmice nakon što je problem počeo, počeli smo slati ne 45k zahtjeva u sekundi, već 55k. U stvari, porasli smo za 20% - ovo je očito promet koji nismo dali korisniku. I nakon toga su počeli razmišljati o tome kako riješiti preostali problem - osigurati visoku vanjsku dostupnost.
Napravili smo pauzu tokom koje smo razgovarali koje rješenje ćemo za to koristiti. Bilo je prijedloga da se osigura pouzdanost korištenjem DNS-a, korištenjem nekih kućnih skripti, protokola za dinamičko usmjeravanje... bilo je mnogo opcija, ali je već postalo jasno da za zaista pouzdanu isporuku fotografija morate uvesti još jedan sloj koji će to pratiti . Ove mašine smo nazvali direktorima fotografija. Softver na koji smo se oslanjali je Keepalived:
Za početak, od čega se sastoji Keepalived? Prvi je VRRP protokol, nadaleko poznat mrežnim operaterima, koji se nalazi na mrežnoj opremi koja omogućava toleranciju grešaka na eksternu IP adresu na koju se klijenti povezuju. Drugi dio je IPVS, IP virtuelni server, za balansiranje između foto rutera i osiguranje tolerancije grešaka na ovom nivou. I treće - zdravstveni pregledi.
Počnimo s prvim dijelom: VRRP - kako to izgleda? Postoji određena virtuelna IP adresa, koja ima unos u dns badoocdn.com, gde se klijenti povezuju. U nekom trenutku imamo IP adresu na jednom serveru. Keepalived paketi se pokreću između servera koristeći VRRP protokol, a ako master nestane sa radara - server se ponovo pokrenuo ili nešto drugo, backup server automatski preuzima ovu IP adresu - nisu potrebne ručne radnje. Razlika između glavnog i rezervnog je uglavnom prioritet: što je veći, veća je šansa da mašina postane master. Veoma velika prednost je što ne morate konfigurisati IP adrese na samom serveru, dovoljno je da ih opišete u konfiguraciji, a ako IP adrese trebaju neka prilagođena pravila rutiranja, to je opisano direktno u konfiguraciji, koristeći ista sintaksa kao što je opisano u VRRP paketu. Nećete se susresti sa nepoznatim stvarima.
Kako to izgleda u praksi? Šta se dešava ako jedan od servera pokvari? Čim master nestane, naša rezervna kopija prestaje da prima reklame i automatski postaje master. Nakon nekog vremena, popravili smo master, ponovo pokrenuli, podigli Keepalived - reklame stižu sa većim prioritetom od rezervne kopije, a backup se automatski vraća, uklanja IP adrese, ne treba raditi nikakve ručne radnje.
Time smo osigurali otpornost na greške eksterne IP adrese. Sljedeći dio je nekako izbalansirati promet od vanjske IP adrese do foto rutera koji ga već prekidaju. Sa balansnim protokolima je sve sasvim jasno. Ovo je ili jednostavan kružni rad, ili malo složenije stvari, wrr, povezivanje liste i tako dalje. To je u osnovi opisano u dokumentaciji, nema ništa posebno. Ali način isporuke... Ovdje ćemo detaljnije pogledati zašto smo odabrali jedan od njih. To su NAT, Direct Routing i TUN. Činjenica je da smo odmah planirali da isporučimo 100 gigabita saobraćaja sa sajtova. Ako procijenite, trebate 10 gigabitnih kartica, zar ne? 10 gigabitnih kartica na jednom serveru već je van okvira, barem, našeg koncepta “standardne opreme”. A onda smo se sjetili da ne poklanjamo samo dio prometa, poklanjamo fotografije.
Šta je posebno? — Ogromna razlika između dolaznog i odlaznog saobraćaja. Dolazni saobraćaj je veoma mali, odlazni veoma veliki:
Ako pogledate ove grafikone, možete vidjeti da u ovom trenutku direktor prima oko 200 MB u sekundi, ovo je sasvim običan dan. Vraćamo 4,500 MB u sekundi, naš omjer je otprilike 1/22. Već je jasno da nam je za potpuno obezbjeđivanje odlaznog saobraćaja na 22 radna servera potreban samo jedan koji prihvata ovu vezu. Tu nam u pomoć priskače algoritam direktnog rutiranja.
Kako izgleda? Naš foto direktor, prema svojoj tabeli, prenosi veze na foto rutere. Ali foto ruteri šalju povratni saobraćaj direktno na Internet, šalju ga klijentu, ne vraća se nazad kroz foto direktor, tako da sa minimalnim brojem mašina obezbeđujemo potpunu toleranciju grešaka i pumpanje celokupnog saobraćaja. U konfiguracijama to izgleda ovako: specificiramo algoritam, u našem slučaju to je jednostavan rr, dajemo metodu direktnog rutiranja i onda počinjemo popis svih pravih servera, koliko ih imamo. Što će odrediti ovaj promet. Ako tamo imamo još jedan ili dva servera, ili nekoliko servera, javlja se takva potreba - samo dodamo ovaj odjeljak u konfiguraciju i ne brinite previše. Sa strane pravih servera, sa strane foto rutera, ova metoda zahtijeva najminimalnu konfiguraciju, savršeno je opisana u dokumentaciji i tu nema nikakvih zamki.
Ono što je posebno lijepo je da takvo rješenje ne podrazumijeva radikalan redizajn lokalne mreže, to nam je bilo važno, to smo morali riješiti uz minimalne troškove. Ako pogledate , onda ćemo vidjeti kako će to izgledati. Ovde imamo određeni virtuelni server, na portu 443, sluša, prihvata konekciju, svi serveri koji rade su izlistani, a vidi se da je veza ista. Ako pogledamo statistiku na istom virtuelnom serveru, imamo dolazne pakete, dolazne veze, ali apsolutno nema odlaznih. Odlazne veze idu direktno do klijenta. U redu, uspjeli smo to debalansirati. Sada, šta se dešava ako jedan od naših foto rutera pokvari? Na kraju krajeva, gvožđe je gvožđe. Može doći u paniku kernela, može se pokvariti, napajanje može izgorjeti. Bilo šta. Zbog toga su potrebni zdravstveni pregledi. One mogu biti jednostavne kao provjera otvorenosti porta ili nešto složenije, sve do nekih kućnih skripti koje će čak provjeriti poslovnu logiku.
Zaustavili smo se negdje na sredini: imamo https zahtjev za određenu lokaciju, skripta se zove, ako odgovori sa 200-tim odgovorom, vjerujemo da je sa ovim serverom sve u redu, da je živ i da se može uključiti lako.
Kako to, opet, izgleda u praksi? Isključimo server radi održavanja - flešovanje BIOS-a, na primjer. U logovima odmah imamo tajm-aut, vidimo prvi red, pa se nakon tri pokušaja označi kao “neuspješno” i jednostavno se briše sa liste.
Moguća je i druga opcija ponašanja, kada je VS jednostavno postavljen na nulu, ali ako se fotografija vrati, to ne funkcionira dobro. Server se pojavljuje, Nginx počinje tamo, Health-check odmah shvata da veza radi, da je sve u redu, i server se pojavljuje na našoj listi i opterećenje odmah počinje da se primenjuje na njega. Nisu potrebne nikakve ručne radnje od strane dežurnog administratora. Server se ponovo pokrenuo noću - odeljenje za nadzor nas ne zove u vezi sa ovim noću. Obavještavaju vas da se to dogodilo, sve je u redu.
Dakle, na prilično jednostavan način, uz pomoć malog broja servera, riješili smo problem vanjske tolerancije grešaka.
Ostaje samo da se kaže da sve ovo, naravno, treba pratiti. Odvojeno, treba napomenuti da Keepalivede, kao softver koji je davno napisan, ima gomilu načina da ga nadgleda, oba pomoću provjera preko DBus-a, SMTP-a, SNMP-a i standardnog Zabbixa. Plus, on sam zna da napiše slova za skoro svako kihanje, a da budem iskren, u jednom trenutku smo čak i pomislili da ga isključimo, jer piše mnogo slova za bilo kakvo prebacivanje saobraćaja, uključivanje, za svaku IP konekciju, i tako dalje. Naravno, ako ima puno servera, onda se možete preplaviti ovim slovima. Pratimo nginx na foto ruterima koristeći standardne metode, a nadzor hardvera nije nestao. Mi bismo, naravno, savjetovali još dvije stvari: prvo, eksterne zdravstvene preglede i dostupnost, jer čak i da sve funkcionira, zapravo, možda korisnici ne dobijaju fotografije zbog problema s vanjskim provajderima ili nečeg složenijeg. Uvijek je vrijedno držati negdje na drugoj mreži, u Amazonu ili negdje drugdje, zasebnu mašinu koja može pingovati vaše servere izvana, a također je vrijedno koristiti bilo detekciju anomalija, za one koji znaju kako napraviti lukavo strojno učenje, ili jednostavno praćenje , barem da bi se pratilo da li su zahtjevi naglo opali, ili, naprotiv, porasli. Također može biti korisno.
Da rezimiramo: mi smo, naime, željezno rješenje, koje nam je u jednom trenutku prestalo odgovarati, zamijenili prilično jednostavnim sistemom koji sve radi isto, odnosno omogućava prekid HTTPS prometa i dalje pametno rutiranje sa neophodne zdravstvene kontrole. Povećali smo stabilnost ovog sistema, odnosno i dalje imamo visoku dostupnost za svaki sloj, plus dobili smo i bonus da je prilično lako sve to skalirati na svakom sloju, jer je to standardni hardver sa standardnim softverom, tj. , pojednostavili smo dijagnosticiranje mogućih problema.
Šta smo završili? Imali smo problem tokom januarskih praznika 2018. U prvih šest mjeseci dok smo ovu šemu pustili u rad, proširili smo je na sav promet kako bismo uklonili sav promet sa LTM-a, samo u jednom data centru smo porasli promet sa 40 gigabita na 60 gigabita, a istovremeno za cijelu 2018. godinu uspjeli su poslati skoro tri puta više fotografija u sekundi.
izvor: www.habr.com