Moderni web gotovo je nezamisliv bez medijskih sadržaja: gotovo svaka baka ima pametni telefon, svi su na društvenim mrežama, a zastoji u održavanju su skupi za tvrtke. Ovdje je prijepis priče tvrtke o tome kako je organizirala isporuku fotografija pomoću hardverskog rješenja, s kakvim se problemima u radu susrela pritom, što ih je uzrokovalo te kako su ti problemi riješeni pomoću softverskog rješenja temeljenog na Nginxu, uz osiguranje tolerancije na pogreške na svim razinama (). Zahvaljujemo 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 predmemoriramo fotografije. Imamo sloj gdje ih spremamo i sloj gdje fotografije spremamo u predmemoriju. 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 serveru za predmemoriju. Inače bismo morali instalirati onoliko puta više diskova koliko imamo više poslužitelja. Naš trick rate je oko 99%, odnosno smanjujemo opterećenje naše pohrane za 100 puta, a da bismo to uspjeli, prije 10 godina, kada se sve ovo gradilo, imali smo 50 servera. Sukladno tome, kako bismo poslužili ove fotografije, bilo nam je potrebno 50 vanjskih domena koje ti poslužitelji opslužuju.
Naravno, odmah se postavilo pitanje: ako jedan od naših poslužitelja padne i postane nedostupan, koji dio prometa gubimo? Pogledali smo što ima na tržištu i odlučili kupiti hardver koji će riješiti sve naše probleme. Izbor je pao na rješenje tvrtke F5-network (koja je, usput, nedavno kupila NGINX, Inc): BIG-IP Local Traffic Manager.
Što ovaj dio hardvera (LTM) radi: to je željezni usmjerivač koji čini željeznu redundantnost svojih vanjskih priključaka i omogućuje vam usmjeravanje prometa na temelju topologije mreže, na nekim postavkama i radi provjere ispravnosti. Bilo nam je važno da se ovaj dio hardvera može programirati. Sukladno tome, mogli bismo opisati logiku kako su fotografije određenog korisnika posluživane iz određene predmemorije. Kako izgleda? Postoji dio hardvera koji gleda Internet na jednoj domeni, jednoj IP adresi, vrši ssl offload, analizira http zahtjeve, odabire broj predmemorije iz IRule, kamo ići, i pušta promet tamo. Istovremeno radi provjere zdravlja, au slučaju nedostupnosti nekog stroja tada smo napravili tako da promet ide na jedan backup server. S gledišta konfiguracije, postoje, naravno, neke nijanse, ali općenito je sve vrlo jednostavno: registriramo karticu, korespondenciju određenog broja s našim IP-om na mreži, kažemo da ćemo slušati na portovima 80 i 443, kažemo da ako je server nedostupan, onda trebate slati promet na rezervni, u ovom slučaju 35., i opisujemo hrpu logike kako bi se ta arhitektura trebala rastaviti. Jedini problem je bio taj što je jezik na kojem je hardver programiran bio Tcl. Ako se itko ovoga uopće sjeća... ovaj jezik je više samo za pisanje nego jezik pogodan za programiranje:
Što smo dobili? Dobili smo dio hardvera koji osigurava visoku dostupnost naše infrastrukture, usmjerava sav naš promet, pruža zdravstvene prednosti i jednostavno radi. Štoviše, radi prilično dugo: u posljednjih 10 godina nije bilo pritužbi na to. Do početka 2018. već smo slali oko 80 tisuća fotografija u sekundi. To je negdje oko 80 gigabita prometa iz oba naša podatkovna centra.
Međutim…
Početkom 2018. vidjeli smo ružnu sliku na ljestvicama: vrijeme potrebno za slanje fotografija očito se povećalo. I prestalo nam je odgovarati. Problem je što je ovakvo ponašanje bilo vidljivo samo u najvećem prometu - za našu tvrtku to je noć s nedjelje na ponedjeljak. Ali ostatak vremena sustav se ponašao kao i obično, bez znakova kvara.
Ipak, problem je trebalo riješiti. Identificirali smo moguća uska grla i počeli ih otklanjati. Prije svega, naravno, proširili smo vanjske uplinkove, proveli kompletnu reviziju internih uplinkova i pronašli sva moguća uska grla. Ali sve to nije dalo očit rezultat, problem nije nestao.
Još jedno moguće usko grlo bila je izvedba samih spremnika fotografija. I odlučili smo da je možda problem u njima. Pa, proširili smo performanse - uglavnom mrežne priključke na predmemoriji fotografija. Ali ponovno nije vidljivo nikakvo očito poboljšanje. Na kraju smo obratili veliku pozornost na performanse samog LTM-a i ovdje smo vidjeli tužnu sliku na grafikonima: opterećenje svih CPU-a počinje ići glatko, ali onda iznenada dolazi na plato. U isto vrijeme, LTM prestaje adekvatno reagirati na provjere ispravnosti i uplinkove i počinje ih nasumično isključivati, što dovodi do ozbiljnog pada performansi.
Odnosno, identificirali smo izvor problema, identificirali usko grlo. Ostaje da odlučimo što ćemo.
Prva, najočitija stvar koju bismo mogli učiniti jest nekako modernizirati 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 licencni ugovor, i trebat će dosta vremena. Druga opcija je da počnete razmišljati svojom glavom, smislite vlastito rješenje koristeći vlastite komponente, po mogućnosti koristeći program otvorenog pristupa. Ostaje samo odlučiti što ćemo točno odabrati za to i koliko ćemo vremena potrošiti na rješavanje ovog problema, jer korisnici nisu dobivali dovoljno fotografija. Dakle, sve ovo moramo napraviti vrlo, vrlo brzo, moglo bi se reći jučer.
Budući da je zadatak zvučao kao "napravite nešto što je brže moguće i koristeći hardver koji imamo", prvo što smo pomislili bilo je jednostavno maknuti neke ne baš moćne strojeve s prednje strane, tamo staviti Nginx, s kojim Znamo kako raditi i pokušati implementirati svu istu logiku koju je radio hardver. To jest, zapravo smo ostavili hardver, instalirali još 4 poslužitelja koje smo morali konfigurirati, napravili im vanjske domene, slično kao prije 10 godina... Malo smo izgubili na dostupnosti ako ti strojevi padnu, ali još manje, riješili su problem naših korisnika lokalno.
Sukladno tome, logika ostaje ista: instaliramo Nginx, on može raditi SSL-offload, možemo nekako programirati logiku usmjeravanja, provjere zdravlja u konfiguracijama i jednostavno duplicirati logiku koju smo imali prije.
Sjednimo da napiš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 googlanje "kako konfigurirati Nginx za fotografije": bolje je pogledati službenu dokumentaciju koja će pokazati koje postavke treba dodirnuti. Ali bolje je sami odabrati određeni parametar. E, onda je sve jednostavno: opisujemo poslužitelje koje imamo, opisujemo certifikate... Ali najzanimljivija je, zapravo, sama logika usmjeravanja.
Isprva nam se činilo da jednostavno opisujemo svoju lokaciju, usklađujemo broj svoje predmemorije fotografija u njoj, rukama ili generatorom opisujemo koliko nam uzvodnih kanala treba, u svakom upstreamu označavamo poslužitelj na koji treba promet go i rezervni poslužitelj - ako glavni poslužitelj nije dostupan:
No, vjerojatno bismo, da je sve tako jednostavno, jednostavno otišli kući i ništa ne bismo rekli. Nažalost, sa zadanim Nginx postavkama, koje su, općenito, napravljene tijekom mnogo godina razvoja i nisu u potpunosti prikladne za ovaj slučaj... konfiguracija izgleda ovako: ako neki uzvodni poslužitelj ima pogrešku zahtjeva ili istek vremena, Nginx uvijek prebacuje promet na sljedeći. Štoviše, nakon prvog kvara, u roku od 10 sekundi poslužitelj će također biti isključen, greškom i timeoutom - to se čak ne može konfigurirati ni na koji način. To jest, ako uklonimo ili resetiramo opciju vremenskog ograničenja u upstream direktivi, tada, iako Nginx neće obraditi ovaj zahtjev i odgovorit će s nekom ne baš dobrom pogreškom, poslužitelj će se ugasiti.
Kako bismo to izbjegli, učinili smo dvije stvari:
a) zabranili su Nginxu da ovo radi ručno - i nažalost, jedini način da to učinite je da jednostavno postavite postavke maksimalnih neuspjeha.
b) sjetili smo se da u drugim projektima koristimo modul koji nam omogućuje provjeru pozadinskog stanja - sukladno tome, radili smo prilično česte provjere zdravlja kako bi zastoji u slučaju nezgode bili minimalni.
Nažalost, ni to nije sve, jer su doslovno prva dva tjedna rada ove sheme pokazala da je i provjera ispravnosti TCP-a nepouzdana stvar: na uzvodnom poslužitelju možda neće biti 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 s httpom za provjeru zdravlja, napravili specifičan koji, ako vrati 200, onda sve radi u ovoj skripti. Možete napraviti dodatnu logiku - na primjer, u slučaju poslužitelja za predmemoriju, provjerite je li datotečni sustav ispravno montiran:
I to bi nam odgovaralo, osim što je u ovom trenutku krug u potpunosti ponovio ono što je napravio hardver. Ali htjeli smo biti bolji. Ranije smo imali jedan rezervni poslužitelj, a to vjerojatno nije dobro, jer ako imate stotinu poslužitelja, onda kada nekoliko njih zakaže odjednom, jedan rezervni poslužitelj vjerojatno se neće nositi s opterećenjem. Stoga smo odlučili rasporediti rezervaciju na sve poslužitelje: jednostavno smo napravili još jedan odvojen uzvodno, tamo napisali sve poslužitelje s određenim parametrima u skladu s opterećenjem koje mogu poslužiti, dodali smo iste provjere zdravlja koje smo imali prije:
Budući da je nemoguće ići na drugi uzvodni tok unutar jednog uzvodnog toka, bilo je potrebno osigurati da ako glavni uzvodni tok, u koji smo jednostavno snimili ispravnu, potrebnu predmemoriju fotografija, nije dostupan, jednostavno smo prošli kroz error_page do rezervnog povratka, od gdje smo otišli do sigurnosne kopije uzvodno:
I doslovnim dodavanjem četiri poslužitelja dobili smo ovo: zamijenili smo dio opterećenja - uklonili smo ga s LTM-a na ove poslužitelje, tamo implementirali istu logiku, koristeći standardni hardver i softver, i odmah dobili bonus koji ti poslužitelji mogu biti skalirani, jer se mogu jednostavno opskrbiti onoliko koliko je potrebno. Pa, jedini nedostatak je to što smo izgubili visoku dostupnost za vanjske korisnike. Ali u tom trenutku morali smo to ž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 doslovno dva tjedna nakon što je problem počeo, počeli smo slati ne 45 tisuća zahtjeva u sekundi, već 55 tisuća. Dapače, porasli smo 20% - to je očito promet koji nismo dali korisniku. A nakon toga počeli su razmišljati kako riješiti preostali problem - osigurati visoku vanjsku dostupnost.
Imali smo stanku u kojoj smo razgovarali o tome koje bismo rješenje koristili za to. Bilo je prijedloga da se osigura pouzdanost korištenjem DNS-a, korištenjem nekih kućnih skripti, dinamičkih protokola usmjeravanja... bilo je mnogo opcija, ali već je postalo jasno da za istinski pouzdanu isporuku fotografija morate uvesti još jedan sloj koji će to nadzirati . Te smo strojeve zvali foto režiseri. Softver na koji smo se oslanjali bio je Keepalived:
Za početak, od čega se Keepalived sastoji? Prvi je VRRP protokol, nadaleko poznat mrežnima, koji se nalazi na mrežnoj opremi koja pruža toleranciju na pogreške vanjske IP adrese na koju se klijenti spajaju. Drugi dio je IPVS, IP virtualni poslužitelj, za balansiranje između foto rutera i osiguravanje tolerancije na pogreške na ovoj razini. I treće - zdravstveni pregledi.
Krenimo od prvog dijela: VRRP – kako to izgleda? Postoji određeni virtualni IP, koji ima unos u dns badoocdn.com, gdje se klijenti spajaju. U nekom trenutku imamo IP adresu na jednom poslužitelju. Keepalived paketi se pokreću između poslužitelja koristeći VRRP protokol, a ako glavni nestane s radara - poslužitelj se ponovno pokrenuo ili nešto treće, tada rezervni poslužitelj automatski preuzima ovu IP adresu - nisu potrebne nikakve ručne radnje. Razlika između mastera i backupa uglavnom je u prioritetu: što je veći, veća je šansa da stroj postane master. Vrlo velika prednost je što ne trebate konfigurirati IP adrese na samom poslužitelju, dovoljno ih je opisati u konfiguraciji, a ako IP adrese trebaju neka prilagođena pravila usmjeravanja, to je opisano izravno u konfiguraciji, pomoću ista sintaksa kao što je opisano u VRRP paketu. Nećete naići na nepoznate stvari.
Kako to izgleda u praksi? Što se događa ako jedan od poslužitelja zakaže? Čim master nestane, naša sigurnosna kopija prestaje primati reklame i automatski postaje master. Nakon nekog vremena smo popravili master, rebootali, podigli Keepalived - reklame stižu s većim prioritetom od backupa, a backup se automatski vraća, uklanja IP adrese, ne treba ništa ručno raditi.
Time smo osigurali toleranciju na pogreške vanjske IP adrese. Sljedeći dio je nekako uravnotežiti promet s vanjske IP adrese na foto usmjerivače koji je već prekidaju. S protokolima balansiranja sve je sasvim jasno. Ovo je ili jednostavan round-robin, ili malo složenije stvari, wrr, lista veza i tako dalje. To je u osnovi opisano u dokumentaciji, nema ništa posebno. Ali način dostave... Ovdje ćemo pobliže pogledati zašto smo odabrali jedan od njih. To su NAT, Direct Routing i TUN. Činjenica je da smo odmah planirali isporučiti 100 gigabita prometa sa stranica. Ako procijenite, trebate kartice od 10 gigabita, zar ne? 10 gigabitnih kartica u jednom serveru već je izvan okvira, barem, našeg koncepta “standardne opreme”. A onda smo se sjetili da mi ne poklanjamo samo promet, poklanjamo i fotografije.
Što je posebno? — Ogromna razlika između dolaznog i odlaznog prometa. Dolazni promet je vrlo mali, odlazni promet je vrlo velik:
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 po sekundi, naš omjer je otprilike 1/22. Već je jasno da za potpunu isporuku odlaznog prometa na 22 radna poslužitelja trebamo samo jedan koji prihvaća ovu vezu. Tu nam u pomoć dolazi algoritam izravnog usmjeravanja.
Kako izgleda? Naš foto direktor, prema svojoj tablici, prenosi veze na foto rutere. Ali foto ruteri šalju povratni promet direktno na Internet, šalju ga klijentu, ne ide natrag kroz foto direktor, tako da uz minimalan broj strojeva osiguravamo potpunu toleranciju na pogreške i pumpanje cjelokupnog prometa. U konfiguracijama to izgleda ovako: odredimo algoritam, u našem slučaju to je jednostavan rr, dajemo metodu izravnog usmjeravanja i zatim počnemo popisivati sve stvarne poslužitelje, koliko ih imamo. Što će odrediti ovaj promet. Ako tamo imamo još jedan ili dva poslužitelja, ili nekoliko poslužitelja, pojavi se takva potreba - samo dodamo ovaj odjeljak u konfiguraciju i ne brinemo previše. Sa strane stvarnih poslužitelja, sa strane foto-usmjerivača, ova metoda zahtijeva najminimalniju konfiguraciju, savršeno je opisana u dokumentaciji i tu nema nikakvih zamki.
Ono što je posebno lijepo je da ovakvo 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 , pa ćemo vidjeti kako će to izgledati. Ovdje imamo određeni virtualni server, na portu 443, sluša, prihvaća konekciju, svi radni serveri su izlistani, i vidite da je konekcija, manje-više, ista. Ako pogledamo statistiku na istom virtualnom poslužitelju, imamo dolazne pakete, dolazne veze, ali apsolutno nikakve odlazne. Odlazne veze idu izravno do klijenta. U redu, uspjeli smo to disbalansirati. Sada, što se događa ako jedan od naših fotografskih usmjerivača zakaže? Uostalom, željezo je željezo. Može pasti u kernel paniku, može se pokvariti, napajanje može pregorjeti. Bilo što. Zbog toga su potrebni zdravstveni pregledi. One mogu biti jednostavne kao što je provjera kako je port otvoren ili nešto složenije, sve do nekih kućnih skripti koje će čak provjeriti poslovnu logiku.
Stali smo negdje na pola puta: imamo https zahtjev prema određenoj lokaciji, poziva se skripta, ako odgovori 200. odgovorom, vjerujemo da je s tim serverom sve u redu, da je živ i da se može sasvim upaliti lako.
Kako to, opet, izgleda u praksi? Isključimo poslužitelj radi održavanja - flashanje BIOS-a, na primjer. U logovima odmah imamo timeout, vidimo prvi redak, zatim nakon tri pokušaja označava se kao "neuspjelo" i jednostavno se uklanja s popisa.
Moguća je i druga opcija ponašanja, kada je VS jednostavno postavljen na nulu, ali ako se fotografija vrati, to ne funkcionira dobro. Poslužitelj se pojavljuje, Nginx se tamo pokreće, provjera ispravnosti odmah razumije da veza radi, da je sve u redu, i poslužitelj se pojavljuje na našem popisu, a opterećenje se odmah počinje primjenjivati na njega. Dežurni administrator ne zahtijeva nikakve ručne radnje. Poslužitelj se ponovno pokrenuo noću - odjel za nadzor nas ne zove o tome noću. Javljaju vam da se to dogodilo, sve je u redu.
Dakle, na prilično jednostavan način, uz pomoć malog broja poslužitelja, riješili smo problem tolerancije vanjskih grešaka.
Ostaje samo reći da sve to, naravno, treba pratiti. Posebno treba napomenuti da Keepalivede, kao softver koji je davno napisan, ima hrpu načina za nadzor, oba koristeći provjere putem DBus-a, SMTP-a, SNMP-a i standardnog Zabbixa. Plus, on sam zna ispisati slova za skoro svaki kihanje, a da budem iskren, u nekom trenutku smo ga čak pomislili i isključiti, jer on ispiše puno slova za bilo kakvo prebacivanje prometa, paljenje, za svaku IP vezu, i tako dalje. Naravno, ako ima puno poslužitelja, onda se možete zatrpati ovim slovima. Pratimo nginx na foto ruterima standardnim metodama, a nadzor hardvera nije nestao. Mi bismo, naravno, savjetovali još dvije stvari: prvo, eksterne zdravstvene provjere i dostupnost, jer čak i da sve funkcionira, zapravo možda korisnici ne dobiju fotografije zbog problema s vanjskim pružateljima ili nečeg složenijeg. Uvijek se isplati držati negdje na drugoj mreži, u Amazonu ili negdje drugdje, zaseban stroj koji može pingati vaše poslužitelje izvana, a također se isplati koristiti ili detekciju anomalija, za one koji znaju raditi lukavo strojno učenje, ili jednostavno praćenje , barem kako bismo pratili jesu li zahtjevi naglo pali ili su se, naprotiv, povećali. Također može biti korisno.
Rezimirajmo: mi smo, zapravo, željezno rješenje, koje nam je u jednom trenutku prestalo odgovarati, zamijenili prilično jednostavnim sustavom koji radi sve isto, odnosno omogućuje terminaciju HTTPS prometa i daljnje pametno usmjeravanje s potrebne zdravstvene preglede. Povećali smo stabilnost ovog sustava, odnosno i dalje imamo visoku dostupnost za svaki sloj, plus imamo 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.
Što smo završili? Imali smo problem tijekom siječanjskih praznika 2018. U prvih šest mjeseci dok smo ovu shemu pustili u rad, proširili smo je na sav promet kako bismo maknuli sav promet iz LTM-a, porasli smo samo u prometu u jednom podatkovnom centru sa 40 gigabita na 60 gigabita, a istovremeno za cijelu 2018. godinu mogli slati gotovo tri puta više fotografija u sekundi.
Izvor: www.habr.com