Sodobnega spleta si brez medijskih vsebin skoraj ni mogoče zamisliti: skoraj vsaka babica ima pametni telefon, vsi so na družbenih omrežjih, izpadi vzdrževanja pa podjetja drago stanejo. Tukaj je prepis zgodbe podjetja o tem, kako je s strojno rešitvijo organizirala dostavo fotografij, na kakšne težave z delovanjem je pri tem naletela, kaj jih je povzročilo in kako so bile te težave rešene s programsko rešitvijo, ki temelji na Nginxu, ob zagotavljanju tolerance na napake na vseh ravneh (). Zahvaljujemo se avtorjem Olegove zgodbe Efimova in Alexandra Dymova, ki sta delili svoje izkušnje na konferenci .
— Začnimo z kratkim uvodom o tem, kako shranjujemo in predpomnimo fotografije. Imamo plast, kjer jih shranimo, in plast, kjer predpomnimo fotografije. Obenem pa je za nas pomembno, da je vsaka fotografija posameznega uporabnika na enem predpomnilniškem strežniku, če želimo doseči visoko stopnjo trikov in zmanjšati obremenitev pomnilnika. V nasprotnem primeru bi morali namestiti tolikokrat več diskov, kot imamo več strežnikov. Naš trick rate je okoli 99 %, se pravi, da 100-krat zmanjšamo obremenitev našega skladišča in da bi to naredili, smo pred 10 leti, ko se je vse to gradilo, imeli 50 strežnikov. V skladu s tem smo za strežbo teh fotografij v bistvu potrebovali 50 zunanjih domen, ki jih ti strežniki strežejo.
Seveda se je takoj pojavilo vprašanje: kakšen del prometa izgubimo, če kateri od naših strežnikov odpove in postane nedosegljiv? Pogledali smo, kaj je na trgu, in se odločili, da kupimo strojno opremo, ki bo rešila vse naše težave. Izbira je padla na rešitev omrežnega podjetja F5 (ki je, mimogrede, pred kratkim kupilo NGINX, Inc): BIG-IP Local Traffic Manager.
Kaj počne ta kos strojne opreme (LTM): je železni usmerjevalnik, ki naredi železno redundanco svojih zunanjih vrat in vam omogoča usmerjanje prometa na podlagi omrežne topologije, nekaterih nastavitev in izvaja preglede zdravja. Za nas je bilo pomembno, da je ta kos strojne opreme mogoče programirati. V skladu s tem bi lahko opisali logiko, kako so bile fotografije določenega uporabnika servirane iz določenega predpomnilnika. Kako izgleda? Obstaja kos strojne opreme, ki pregleduje internet na eni domeni, enem IP-ju, izvaja prenos ssl, razčlenjuje http zahteve, izbere številko predpomnilnika iz IRule, kam naj gre, in pusti promet tja. Hkrati dela preglede zdravja in v primeru nedosegljivosti kakšnega stroja smo takrat naredili tako, da je šel promet na en rezervni strežnik. Z vidika konfiguracije je seveda nekaj odtenkov, a na splošno je vse precej preprosto: registriramo kartico, korespondenco določene številke z našim IP v omrežju, rečemo, da bomo poslušali na vratih 80 in 443, rečemo, da če je strežnik nedosegljiv, potem morate poslati promet na rezervnega, v tem primeru 35., in opisujemo en kup logike, kako je treba to arhitekturo razstaviti. Edina težava je bila, da je bil jezik, v katerem je bila programirana strojna oprema, Tcl. Če se kdo tega sploh spomni ... ta jezik je bolj namenjen samo pisanju kot jeziku, ki je primeren za programiranje:
Kaj smo dobili? Prejeli smo kos strojne opreme, ki zagotavlja visoko razpoložljivost naše infrastrukture, usmerja ves naš promet, zagotavlja zdravstvene koristi in preprosto deluje. Poleg tega deluje precej dolgo: v zadnjih 10 letih ni bilo nobenih pritožb glede tega. V začetku leta 2018 smo pošiljali že približno 80k fotografij na sekundo. To je nekje 80 gigabitov prometa iz obeh naših podatkovnih centrov.
Ampak ...
V začetku leta 2018 smo na lestvicah videli grdo sliko: čas pošiljanja fotografij se je očitno povečal. In to nam je nehalo ustrezati. Težava je v tem, da je bilo to vedenje vidno le v času največjega prometa – za naše podjetje je to noč iz nedelje na ponedeljek. Toda preostali čas se je sistem obnašal kot običajno, brez znakov okvare.
Kljub temu je bilo treba problem rešiti. Identificirali smo morebitna ozka grla in jih začeli odpravljati. Najprej smo seveda razširili zunanje navzgornje povezave, opravili popolno revizijo notranjih navzgornjih povezav in našli vsa možna ozka grla. Toda vse to ni dalo očitnega rezultata, težava ni izginila.
Drugo možno ozko grlo je bilo delovanje samih predpomnilnikov fotografij. In odločili smo se, da je morda problem v njih. No, razširili smo zmogljivost - predvsem omrežna vrata na predpomnilnikih fotografij. Toda spet ni bilo opaziti očitnega izboljšanja. Na koncu smo bili pozorni na delovanje samega LTM-ja in tukaj smo na grafih videli žalostno sliko: obremenitev vseh procesorjev začne potekati gladko, nato pa nenadoma pride na plato. Hkrati se LTM preneha ustrezno odzivati na preglede zdravja in navzgornje povezave ter jih začne naključno izklapljati, kar povzroči resno poslabšanje delovanja.
Se pravi, identificirali smo izvor problema, prepoznali ozko grlo. Ostaja še odločitev, kaj bomo storili.
Prva, najbolj očitna stvar, ki bi jo lahko naredili, je, da nekako posodobimo sam LTM. Toda tukaj je nekaj odtenkov, ker je ta strojna oprema precej edinstvena, ne boste šli v najbližji supermarket in ga kupili. To je ločena pogodba, ločena licenčna pogodba, in trajalo bo veliko časa. Druga možnost je, da začnete razmišljati sami, pridete do lastne rešitve z lastnimi komponentami, po možnosti z odprto dostopnim programom. Ostaja le še odločitev, kaj točno bomo za to izbrali in koliko časa bomo porabili za reševanje tega problema, saj uporabniki niso prejeli dovolj fotografij. Zato moramo vse to narediti zelo, zelo hitro, lahko bi rekli včeraj.
Ker je naloga zvenela kot "naredite nekaj čim hitreje in z uporabo strojne opreme, ki jo imamo," smo najprej pomislili, da preprosto odstranimo nekaj manj zmogljivih strojev s sprednje strani, tja postavimo Nginx, s katerim Vemo, kako delati in poskušati implementirati vso isto logiko, kot jo je uporabljala strojna oprema. Se pravi, dejansko smo pustili našo strojno opremo, namestili še 4 strežnike, ki smo jih morali konfigurirati, jim ustvarili zunanje domene, podobno kot je bilo pred 10 leti... Malo smo izgubili na razpoložljivosti, če so ti stroji padli, ampak še manj pa so problem naših uporabnikov reševali lokalno.
V skladu s tem logika ostaja enaka: namestimo Nginx, lahko izvede SSL-offload, lahko nekako programiramo logiko usmerjanja, preverjanje stanja v konfiguracijah in preprosto podvojimo logiko, ki smo jo imeli prej.
Sedimo in napišemo konfiguracije. Sprva se je zdelo, da je vse zelo preprosto, a na žalost je zelo težko najti priročnike za vsako nalogo. Zato ne priporočamo, da preprosto googlate "kako konfigurirati Nginx za fotografije": bolje je, da se sklicujete na uradno dokumentacijo, ki bo pokazala, katere nastavitve se je treba dotakniti. Vendar je bolje, da sami izberete določen parameter. No, potem je vse preprosto: opišemo strežnike, ki jih imamo, opišemo certifikate ... Najbolj zanimiva pa je pravzaprav sama logika usmerjanja.
Sprva se nam je zdelo, da preprosto opisujemo našo lokacijo, primerjamo številko predpomnilnika fotografij v njej, z rokami ali generatorjem opisujemo, koliko upstreamov potrebujemo, v vsakem upstreamu označimo strežnik, na katerega naj poteka promet. go in rezervni strežnik - če glavni strežnik ni na voljo:
Verjetno pa bi, če bi bilo vse tako preprosto, preprosto šli domov in ne bi rekli ničesar. Na žalost s privzetimi nastavitvami Nginxa, ki so na splošno nastale v mnogih letih razvoja in niso povsem primerne za ta primer ... konfiguracija izgleda takole: če ima neki zgornji strežnik napako zahteve ali časovno omejitev, Nginx vedno preusmeri promet na naslednjega. Poleg tega bo po prvi napaki v 10 sekundah tudi strežnik izklopljen, tako po pomoti kot po časovni omejitvi - tega sploh ni mogoče konfigurirati na noben način. To pomeni, da če odstranimo ali ponastavimo možnost časovne omejitve v direktivi navzgor, potem se bo strežnik zaustavil, čeprav Nginx ne bo obdelal te zahteve in se bo odzval z neko ne zelo dobro napako.
Da bi se temu izognili, smo naredili dve stvari:
a) Nginxu so prepovedali, da to počne ročno - in na žalost je edini način, da to storite, preprosto nastavitev nastavitev največjega števila napak.
b) spomnili smo se, da v drugih projektih uporabljamo modul, ki nam omogoča preverjanje ozadja – temu primerno smo izvajali precej pogoste zdravstvene preglede, da bi bili izpadi v primeru nesreče minimalni.
Žal tudi to še ni vse, saj sta dobesedno prva dva tedna delovanja te sheme pokazala, da je tudi preverjanje stanja TCP nezanesljiva stvar: na zgornjem strežniku morda ni Nginx ali Nginx v D-stanju in v v tem primeru bo jedro sprejelo povezavo, zdravstveni pregled bo uspel, vendar ne bo deloval. Zato smo to takoj zamenjali z zdravstvenim pregledom http, naredili specifično, ki, če vrne 200, potem v tej skripti vse deluje. Lahko naredite dodatno logiko - na primer v primeru strežnikov za predpomnjenje preverite, ali je datotečni sistem pravilno nameščen:
In to bi nam ustrezalo, le da trenutno vezje popolnoma ponovi tisto, kar je naredila strojna oprema. Vendar smo želeli biti boljši. Prej smo imeli en rezervni strežnik in to verjetno ni zelo dobro, kajti če imate sto strežnikov, ko jih več hkrati odpove, en rezervni strežnik verjetno ne bo kos obremenitvi. Zato smo se odločili, da rezervacijo porazdelimo po vseh strežnikih: preprosto smo naredili še en ločen upstream, tam zapisali vse strežnike z določenimi parametri v skladu z obremenitvijo, ki jo lahko služijo, dodali enake preglede zdravja, kot smo jih imeli prej:
Ker je nemogoče iti na drug navzgor znotraj enega navzgor, se je bilo treba prepričati, da če glavni navzgor, v katerega smo preprosto posneli pravilen, potreben predpomnilnik fotografij, ni bil na voljo, smo preprosto šli skozi error_page za nadomestno, od kjer smo šli do varnostne kopije navzgor:
In z dobesednim dodajanjem štirih strežnikov smo dobili to: zamenjali smo del obremenitve – odstranili smo ga iz LTM na te strežnike, tam implementirali isto logiko z uporabo standardne strojne in programske opreme ter takoj prejeli bonus, da lahko ti strežniki skalirati, ker jih je mogoče preprosto dobaviti toliko, kot je potrebno. No, edina pomanjkljivost je, da smo izgubili visoko razpoložljivost za zunanje uporabnike. Toda v tistem trenutku smo morali to žrtvovati, saj je bilo treba problem rešiti takoj. Tako smo odstranili del obremenitve, takrat je bilo približno 40%, LTM se je počutil dobro in dobesedno dva tedna po začetku težave smo začeli pošiljati ne 45k zahtev na sekundo, ampak 55k. Pravzaprav smo zrasli za 20% - to je očitno promet, ki ga nismo dali uporabniku. In potem so začeli razmišljati, kako rešiti preostali problem - zagotoviti visoko zunanjo dostopnost.
Imeli smo nekaj premora, med katerim smo razpravljali, kakšno rešitev bi uporabili za to. Bili so predlogi, da bi zagotovili zanesljivost z uporabo DNS, s pomočjo nekaterih doma napisanih skript, dinamičnih protokolov usmerjanja ... možnosti je bilo veliko, vendar je že postalo jasno, da je za resnično zanesljivo dostavo fotografij treba uvesti še eno plast, ki bo to spremljal. Te stroje smo imenovali foto režiserji. Programska oprema, na katero smo se zanašali, je Keepalived:
Za začetek, kaj sestavlja Keepalived? Prvi je protokol VRRP, splošno znan omrežnikom, ki se nahaja na omrežni opremi, ki zagotavlja odpornost na napake zunanjega naslova IP, na katerega se odjemalci povezujejo. Drugi del je IPVS, IP virtualni strežnik, za uravnoteženje med foto usmerjevalniki in zagotavljanje tolerance napak na tem nivoju. In tretji - zdravstveni pregledi.
Začnimo s prvim delom: VRRP – kako izgleda? Obstaja določen virtualni IP, ki ima vnos v dns badoocdn.com, kjer se odjemalci povezujejo. V nekem trenutku imamo naslov IP na enem strežniku. Paketi Keepalived tečejo med strežniki s protokolom VRRP in če glavni izgine z radarja - se je strežnik znova zagnal ali kaj drugega, potem rezervni strežnik samodejno prevzame ta naslov IP - ročna dejanja niso potrebna. Razlika med glavnim in rezervnim je predvsem v prioriteti: višja kot je, večja je možnost, da stroj postane glavni. Zelo velika prednost je, da vam ni treba konfigurirati naslovov IP na samem strežniku, dovolj je, da jih opišete v konfiguraciji, in če naslovi IP potrebujejo pravila usmerjanja po meri, je to opisano neposredno v konfiguraciji z uporabo enaka sintaksa, kot je opisana v paketu VRRP. Ne boste naleteli na neznane stvari.
Kako to izgleda v praksi? Kaj se zgodi, če eden od strežnikov odpove? Takoj ko master izgine, naša varnostna kopija preneha prejemati oglase in samodejno postane master. Čez nekaj časa smo popravili master, znova zagnali, dvignili Keepalived - oglasi pridejo z višjo prioriteto kot varnostna kopija, varnostna kopija pa se samodejno obrne nazaj, odstrani naslove IP, ročnih dejanj ni treba storiti.
Tako smo zagotovili toleranco napak zunanjega IP naslova. Naslednji del je nekako uravnotežiti promet od zunanjega naslova IP do fotografskih usmerjevalnikov, ki ga že zaključujejo. S protokoli za izravnavo je vse povsem jasno. To je ali preprost krožni krog ali malo bolj zapletene stvari, wrr, povezava seznamov in tako naprej. To je v bistvu opisano v dokumentaciji, ni nič posebnega. Toda način dostave ... Tukaj si bomo podrobneje ogledali, zakaj smo izbrali enega od njih. To so NAT, Direct Routing in TUN. Dejstvo je, da smo takoj načrtovali dostavo 100 gigabitov prometa s strani. Če ocenite, potrebujete 10 gigabitne kartice, kajne? 10 gigabitnih kartic v enem strežniku že presega okvire vsaj našega koncepta »standardne opreme«. In potem smo se spomnili, da ne podarimo samo nekaj prometa, podarimo fotografije.
Kaj je posebnega? — Ogromna razlika med dohodnim in odhodnim prometom. Dohodni promet je zelo majhen, odhodni promet je zelo velik:
Če pogledate te grafe, lahko vidite, da trenutno direktor prejme približno 200 MB na sekundo, to je zelo običajen dan. Vrnemo 4,500 MB na sekundo, naše razmerje je približno 1/22. Že zdaj je jasno, da za popolno zagotavljanje odhodnega prometa na 22 delovnih strežnikov potrebujemo samo enega, ki sprejme to povezavo. Tu nam na pomoč priskoči algoritem neposrednega usmerjanja.
Kako izgleda? Naš fotografski direktor po svoji tabeli prenaša povezave na foto usmerjevalnike. Toda foto usmerjevalniki pošljejo povratni promet direktno na internet, ga pošljejo stranki, ne gre nazaj preko foto direktorja, tako da z minimalnim številom strojev zagotovimo popolno toleranco napak in črpanje vsega prometa. V konfiguracijah je videti takole: določimo algoritem, v našem primeru je to preprost rr, zagotovimo metodo neposrednega usmerjanja in nato začnemo naštevati vse prave strežnike, koliko jih imamo. Ki bo določal ta promet. Če imamo tam še enega ali dva strežnika ali več strežnikov, se pojavi takšna potreba - preprosto dodamo ta razdelek v konfiguracijo in ne skrbimo preveč. S strani pravih strežnikov, s strani fotografskega usmerjevalnika, ta metoda zahteva najbolj minimalno konfiguracijo, je popolnoma opisana v dokumentaciji in tam ni nobenih pasti.
Še posebej lepo pa je, da takšna rešitev ne pomeni radikalne prenove lokalnega omrežja, to je bilo za nas pomembno, to smo morali rešiti z minimalnimi stroški. Če pogledate , potem pa bomo videli kako to izgleda. Tukaj imamo določen navidezni strežnik, na vratih 443, posluša, sprejme povezavo, vsi delujoči strežniki so navedeni in vidite, da je povezava ne glede na to enaka. Če pogledamo statistiko na istem virtualnem strežniku, imamo dohodne pakete, dohodne povezave, vendar popolnoma nič odhodnih. Odhodne povezave gredo neposredno do odjemalca. V redu, uspelo nam je razravnotežiti. Kaj se zgodi, če eden od naših foto usmerjevalnikov odpove? Navsezadnje je železo železo. Lahko gre v paniko jedra, lahko se zlomi, napajalnik lahko pregori. Karkoli. Zato so potrebni zdravstveni pregledi. Lahko so tako preprosti, kot je preverjanje, kako so vrata odprta, ali kaj bolj zapletenega, do nekaterih doma napisanih skriptov, ki bodo celo preverile poslovno logiko.
Ustavili smo se nekje na sredini: imamo https zahtevo na določeno lokacijo, skripta se pokliče, če odgovori z 200. odgovorom, verjamemo, da je s tem strežnikom vse v redu, da je živ in ga je mogoče povsem vklopiti. zlahka.
Kako pa je to spet videti v praksi? Izklopimo strežnik zaradi vzdrževanja - na primer flashanje BIOS-a. V dnevnikih imamo takoj časovno omejitev, vidimo prvo vrstico, nato pa je po treh poskusih označena kot "neuspešno" in je preprosto odstranjena s seznama.
Možna je tudi druga možnost obnašanja, ko je VS preprosto nastavljen na nič, vendar če je fotografija vrnjena, to ne deluje dobro. Pojavi se strežnik, tam se zažene Nginx, zdravstveni pregled takoj razume, da povezava deluje, da je vse v redu, in strežnik se pojavi na našem seznamu in takoj se začne obremeniti. Od dežurnega skrbnika niso potrebna nobena ročna dejanja. Strežnik se je ponoči znova zagnal - oddelek za spremljanje nas ponoči o tem ne kliče. Obveščajo vas, da se je to zgodilo, vse je v redu.
Tako smo na dokaj preprost način, s pomočjo manjšega števila strežnikov, rešili problem zunanje tolerance napak.
Povedati je treba le še to, da je vse to seveda treba spremljati. Ločeno je treba opozoriti, da ima Keepalivede, kot programsko opremo, ki je bila napisana že zdavnaj, kup načinov za spremljanje, oba z uporabo preverjanj prek DBus, SMTP, SNMP in standardnega Zabbixa. Plus, sam zna pisati črke za skoraj vsak kihanje in po pravici povedano smo ga na neki točki celo pomislili izklopiti, saj napiše ogromno črk za vsako preklapljanje prometa, vklop, za vsako IP povezavo, in tako naprej . Seveda, če je veliko strežnikov, potem se lahko preobremenite s temi črkami. Nginx spremljamo na fotografskih usmerjevalnikih s standardnimi metodami, spremljanje strojne opreme pa ni izginilo. Svetovali bi seveda še dve stvari: najprej zunanje zdravstvene preglede in dostopnost, kajti tudi če vse deluje, dejansko morda uporabniki ne dobijo fotografij zaradi težav z zunanjimi ponudniki ali česa bolj kompleksnega. Vedno je vredno imeti nekje v drugem omrežju, v Amazonu ali kje drugje, ločen stroj, ki lahko pinga vaše strežnike od zunaj, prav tako pa je vredno uporabiti zaznavanje nepravilnosti za tiste, ki vedo, kako izvajati zapleteno strojno učenje, ali preprosto spremljanje , vsaj zato, da bi spremljali, ali so se zahteve močno zmanjšale ali, nasprotno, povečale. Lahko je tudi koristno.
Naj povzamemo: železno rešitev, ki nam v nekem trenutku ni več ustrezala, smo pravzaprav zamenjali z dokaj enostavnim sistemom, ki dela vse enako, torej omogoča zaključevanje HTTPS prometa in nadaljnje pametno usmerjanje z potrebne zdravstvene preglede. Povečali smo stabilnost tega sistema, se pravi, da imamo še vedno visoko razpoložljivost za vsako plast, poleg tega imamo bonus, da je vse to precej enostavno skalirati na vsaki plasti, ker gre za standardno strojno opremo s standardno programsko opremo, tj. , smo poenostavili diagnosticiranje morebitnih težav.
Kaj smo končali? Med januarskimi počitnicami 2018 smo imeli težave. V prvih šestih mesecih, ko smo to shemo zagnali, smo jo razširili na ves promet, da bi odstranili ves promet iz LTM, zrasli smo le v prometu v enem podatkovnem centru s 40 gigabitov na 60 gigabitov in hkrati za celotno leto 2018 lahko poslali skoraj trikrat več fotografij na sekundo.
Vir: www.habr.com