Šiuolaikinis internetas beveik neįsivaizduojamas be žiniasklaidos turinio: beveik kiekviena močiutė turi išmanųjį telefoną, visi yra socialiniuose tinkluose, o priežiūros prastovos įmonėms kainuoja brangiai. Čia yra įmonės istorijos nuorašas apie tai, kaip ji organizavo nuotraukų pristatymą naudodama aparatūros sprendimą, su kokiomis našumo problemomis susidūrė proceso metu, kas jas sukėlė ir kaip šios problemos buvo išspręstos naudojant programinės įrangos sprendimą, pagrįstą Nginx, kartu užtikrinant atsparumą gedimams visais lygiais (). Dėkojame Olego istorijos autoriams Efimova ir Alexandra Dymova, kurios pasidalino savo patirtimi konferencijoje .
— Pradėkime nuo nedidelio įvado apie tai, kaip saugome ir talpiname nuotraukas. Turime sluoksnį, kuriame jas saugome, ir sluoksnį, kuriame talpiname nuotraukas. Tuo pačiu, jei norime pasiekti aukštą gudrybių rodiklį ir sumažinti saugyklos apkrovą, mums svarbu, kad kiekviena atskiro vartotojo nuotrauka būtų viename talpyklos serveryje. Priešingu atveju turėtume įdiegti tiek kartų daugiau diskų, kiek turėsime daugiau serverių. Mūsų gudrybių rodiklis yra apie 99%, tai yra, mes sumažiname saugyklos apkrovą 100 kartų, o norėdami tai padaryti, prieš 10 metų, kai visa tai buvo kuriama, turėjome 50 serverių. Atitinkamai, norint aptarnauti šias nuotraukas, mums reikėjo iš esmės 50 išorinių domenų, kuriuos aptarnauja šie serveriai.
Natūralu, kad iškart iškilo klausimas: jei vienas iš mūsų serverių sugenda ir tampa nepasiekiamas, kokią srauto dalį prarandame? Pažiūrėjome, kas yra rinkoje, ir nusprendėme nusipirkti aparatūros dalį, kad ji išspręstų visas mūsų problemas. Pasirinkimas krito F5 tinklo įmonės (kuri, beje, neseniai įsigijo NGINX, Inc.) sprendimą: BIG-IP Local Traffic Manager.
Ką daro ši aparatinė įranga (LTM): tai geležinis maršruto parinktuvas, kuris atlieka geležinį išorinių prievadų dubliavimą ir leidžia nukreipti srautą pagal tinklo topologiją, kai kuriuos nustatymus ir atlieka sveikatos patikrinimus. Mums buvo svarbu, kad šią aparatinę įrangą būtų galima užprogramuoti. Atitinkamai galėtume apibūdinti logiką, kaip konkretaus vartotojo nuotraukos buvo pateikiamos iš konkrečios talpyklos. Kaip tai atrodo? Yra aparatinės įrangos dalis, kuri žiūri į internetą viename domene, viename IP, iškrauna ssl, analizuoja http užklausas, pasirenka talpyklos numerį iš IRule, kur eiti ir leidžia srautui ten patekti. Tuo pačiu atlieka sveikatos patikras, o jei koks kompiuteris nepasiekiamas, tuo metu padarėme taip, kad srautas eitų į vieną atsarginį serverį. Konfigūracijos požiūriu, žinoma, yra tam tikrų niuansų, tačiau apskritai viskas yra gana paprasta: mes užregistruojame kortelę, tam tikro numerio atitikimą mūsų IP tinkle, sakome, kad klausysime 80 prievaduose. ir 443, sakome, kad jei serveris nepasiekiamas, reikia siųsti srautą į atsarginį, šiuo atveju į 35, ir aprašome krūvą logikos, kaip ši architektūra turėtų būti išardyta. Vienintelė problema buvo ta, kad kalba, kuria buvo užprogramuota aparatinė įranga, buvo Tcl. Jei kas nors tai atsimena... ši kalba yra daugiau tik rašymo, nei patogi programavimui:
Ką mes gavome? Gavome techninę įrangą, kuri užtikrina aukštą mūsų infrastruktūros prieinamumą, nukreipia visą srautą, teikia naudos sveikatai ir tiesiog veikia. Be to, jis veikia gana ilgą laiką: per pastaruosius 10 metų dėl to nebuvo skundų. 2018 metų pradžioje jau siųsdavome apie 80 tūkst. nuotraukų per sekundę. Tai yra maždaug 80 gigabitų srauto iš abiejų mūsų duomenų centrų.
Bet…
2018 metų pradžioje topuose išvydome bjaurų vaizdą: nuotraukų siuntimo laikas akivaizdžiai pailgėjo. Ir tai nustojo mums tikti. Bėda ta, kad toks elgesys buvo matomas tik eismo piko metu – mūsų kompanijai tai naktis iš sekmadienio į pirmadienį. Tačiau likusį laiką sistema veikė kaip įprasta, gedimo požymių nebuvo.
Nepaisant to, problema turėjo būti išspręsta. Nustatėme galimas kliūtis ir pradėjome jas šalinti. Pirmiausia, žinoma, išplėtėme išorines nuorodas, atlikome pilną vidinių nuorodų auditą ir nustatėme visas galimas kliūtis. Bet visa tai akivaizdaus rezultato nedavė, problema neišnyko.
Kita galima kliūtis buvo pačių nuotraukų talpyklų veikimas. Ir nusprendėme, kad galbūt problema priklauso jiems. Na, išplėtėme našumą – daugiausia tinklo prievadus nuotraukų talpyklose. Bet vėlgi akivaizdaus pagerėjimo nepastebėta. Pabaigoje daug dėmesio skyrėme paties LTM našumui ir čia grafikuose pamatėme liūdną vaizdą: visų procesorių apkrova pradeda sklandžiai, bet tada staiga pasiekia plynaukštę. Tuo pačiu metu LTM nustoja tinkamai reaguoti į sveikatos patikrinimus ir atsisiuntimus ir pradeda atsitiktinai juos išjungti, o tai sukelia rimtą našumo pablogėjimą.
Tai yra, mes nustatėme problemos šaltinį, nustatėme kliūtis. Belieka nuspręsti, ką darysime.
Pirmas, akivaizdžiausias dalykas, kurį galėtume padaryti, tai kažkaip modernizuoti patį LTM. Tačiau čia yra keletas niuansų, nes ši techninė įranga yra gana unikali, nenueisite į artimiausią prekybos centrą ir nenusipirksite. Tai yra atskira sutartis, atskira licencijos sutartis ir tai užtruks daug laiko. Antrasis variantas – pradėti mąstyti pačiam, sugalvoti savo sprendimą naudojant savo komponentus, geriausia naudojant atviros prieigos programą. Belieka apsispręsti, ką konkrečiai tam rinksimės ir kiek laiko skirsime šiai problemai spręsti, nes vartotojai negavo pakankamai nuotraukų. Todėl visa tai turime padaryti labai labai greitai, galima sakyti vakar.
Kadangi užduotis skambėjo taip: „Daryk ką nors kuo greičiau ir naudodamiesi turima aparatūra“, pirmiausia pagalvojome, kad tiesiog iš priekio reikia išimti kai kurias nelabai galingas mašinas, įdėti „Nginx“, su kuria mes žinome, kaip dirbti ir pabandyti įgyvendinti tą pačią logiką, kurią darydavo aparatinė įranga. Tai iš tikrųjų mes palikome savo aparatūrą, įdiegėme dar 4 serverius, kuriuos turėjome sukonfigūruoti, sukūrėme jiems išorinius domenus, panašius kaip prieš 10 metų... Šiek tiek praradome pasiekiamumą, jei šios mašinos nukris, bet dar mažiau, jie išsprendė mūsų vartotojų problemą vietoje.
Atitinkamai, logika išlieka ta pati: mes įdiegiame Nginx, jis gali atlikti SSL iškrovimą, galime kažkaip užprogramuoti maršruto logiką, patikrinti konfigūracijų būklę ir tiesiog dubliuoti logiką, kurią turėjome anksčiau.
Sėskime rašyti konfigūracijų. Iš pradžių atrodė, kad viskas labai paprasta, bet, deja, labai sunku rasti kiekvienos užduoties vadovus. Todėl nerekomenduojame tiesiog googlinti „kaip sukonfigūruoti Nginx nuotraukoms“: geriau kreiptis į oficialią dokumentaciją, kurioje bus parodyta, kuriuos nustatymus reikia paliesti. Bet konkretų parametrą geriau pasirinkti patiems. Na, tada viskas paprasta: aprašome serverius, kuriuos turime, aprašome sertifikatus... Bet įdomiausia, tiesą sakant, pati maršrutizavimo logika.
Iš pradžių mums atrodė, kad mes tiesiog aprašome savo buvimo vietą, suderiname joje esančios nuotraukų talpyklos numerį, rankomis ar generatoriumi apibūdiname, kiek mums reikia prieš srovę, kiekviename priešsrovyje nurodome serverį, į kurį turėtų būti srautas. go ir atsarginis serveris – jei pagrindinis serveris nepasiekiamas:
Bet, ko gero, jei viskas būtų taip paprasta, mes tiesiog eitume namo ir nieko nesakytume. Deja, su numatytaisiais Nginx nustatymais, kurie, apskritai, buvo daromi per daugelį kūrimo metų ir nėra visiškai tinkami šiam atvejui... konfigūracija atrodo taip: jei kokiame nors aukštesnio srauto serveryje yra užklausos klaida arba laikas, Nginx visada perjungia eismą į kitą. Be to, po pirmo gedimo per 10 sekundžių serveris taip pat bus išjungtas tiek per klaidą, tiek dėl skirtojo laiko - to net negalima sukonfigūruoti niekaip. Tai yra, jei pašalinsime arba iš naujo nustatysime skirtojo laiko parinktį iš ankstesnės krypties direktyvos, nors „Nginx“ neapdoros šios užklausos ir atsakys su ne itin gera klaida, serveris išsijungs.
Norėdami to išvengti, padarėme du dalykus:
a) jie uždraudė Nginx tai daryti rankiniu būdu - ir, deja, vienintelis būdas tai padaryti yra tiesiog nustatyti maksimalių nesėkmių nustatymus.
b) prisiminėme, kad kituose projektuose naudojame modulį, leidžiantį atlikti foninius sveikatos patikrinimus – atitinkamai gana dažnai tikrindavome sveikatą, kad prastovos įvykus nelaimei būtų minimalios.
Deja, tai irgi dar ne viskas, nes pažodžiui pirmosios dvi šios schemos veikimo savaitės parodė, kad TCP būklės patikrinimas taip pat yra nepatikimas dalykas: aukštesniajame serveryje tai gali būti ne Nginx arba Nginx D būsenoje, o Šiuo atveju branduolys priims ryšį, sveikatos patikrinimas bus sėkmingas, bet neveiks. Todėl iš karto pakeitėme į sveikatos patikrinimo http, padarėme konkretų, kuris, jei grąžina 200, tai viskas veikia šiame scenarijuje. Galite atlikti papildomą logiką – pavyzdžiui, talpykloje saugomų serverių atveju patikrinkite, ar failų sistema tinkamai sumontuota:
Ir tai mums tiktų, išskyrus tai, kad šiuo metu grandinė visiškai pakartojo tai, ką padarė aparatinė įranga. Bet mes norėjome padaryti geriau. Anksčiau turėjome vieną atsarginį serverį, ir tai tikriausiai nėra labai gerai, nes jei turite šimtą serverių, tada, kai sugenda keli vienu metu, vienas atsarginis serveris vargu ar susidoros su apkrova. Todėl nusprendėme paskirstyti rezervaciją visuose serveriuose: tiesiog padarėme dar vieną atskirą aukštesnę srovę, ten surašėme visus serverius su tam tikrais parametrais pagal apkrovą, kurią jie gali aptarnauti, pridėjome tuos pačius sveikatos patikrinimus, kuriuos turėjome anksčiau:
Kadangi neįmanoma pereiti į kitą prieš srovę per vieną prieš srovę, reikėjo įsitikinti, kad jei pagrindinė prieš srovę, kurioje tiesiog įrašėme teisingą, reikiamą nuotraukų talpyklą, nebuvo pasiekiama, tiesiog perėjome error_page, kad sugrįžtume, nuo kur mes nuėjome į atsarginę kopiją prieš srovę:
Ir tiesiogine prasme pridėję keturis serverius gavome štai ką: pakeitėme dalį apkrovos – pašalinome iš LTM į šiuos serverius, ten įdiegėme tą pačią logiką, naudodami standartinę aparatinę ir programinę įrangą, ir iškart gavome premiją, kurią gali šie serveriai. gali būti keičiami, nes jų galima tiesiog tiekti tiek, kiek reikia. Na, vienintelis neigiamas dalykas yra tai, kad praradome aukštą prieinamumą išoriniams vartotojams. Tačiau tą akimirką turėjome tai paaukoti, nes reikėjo nedelsiant išspręsti problemą. Taigi, mes pašalinome dalį apkrovos, tuo metu ji buvo apie 40%, LTM jautėsi gerai, o tiesiog po dviejų savaičių nuo problemos pradžios pradėjome siųsti ne 45 tūkst. užklausų per sekundę, o 55 tūkst. Tiesą sakant, mes išaugome 20% – tai akivaizdžiai srautas, kurio vartotojui nesuteikėme. O po to imta galvoti, kaip išspręsti likusią problemą – užtikrinti aukštą išorinį pasiekiamumą.
Turėjome pauzę, kurios metu aptarėme, kokį sprendimą tam naudosime. Buvo pasiūlymų užtikrinti patikimumą naudojant DNS, naudojant kai kuriuos namuose rašytus scenarijus, dinaminius maršruto parinkimo protokolus... buvo daug variantų, bet jau tapo aišku, kad norint tikrai patikimai pristatyti nuotraukas, reikia įvesti dar vieną sluoksnį, kuris tai stebės. . Šias mašinas vadinome nuotraukų režisieriais. Programinė įranga, kuria pasitikėjome, buvo „Keepalived“:
Pirmiausia, iš ko susideda „Keepalived“? Pirmasis yra VRRP protokolas, plačiai žinomas tinklo naudotojams, esantis tinklo įrangoje, kuri užtikrina išorinio IP adreso, prie kurio prisijungia klientai, gedimų toleranciją. Antroji dalis – IPVS, IP virtualus serveris, skirtas balansuoti tarp nuotraukų maršrutizatorių ir užtikrinti atsparumą gedimams šiame lygyje. Ir trečia – sveikatos patikrinimai.
Pradėkime nuo pirmosios dalies: VRRP – kaip tai atrodo? Yra tam tikras virtualus IP, turintis įrašą dns badoocdn.com, kur jungiasi klientai. Tam tikru metu viename serveryje turime IP adresą. Išlaikyti paketai tarp serverių vyksta naudojant VRRP protokolą, o jei master dingsta iš radaro – serveris persikrovė ar dar kažkas, tai atsarginis serveris automatiškai pasiima šį IP adresą – jokių rankinių veiksmų nereikia. Pagrindinis ir atsarginis skirtumas daugiausia yra prioritetinis: kuo jis didesnis, tuo didesnė tikimybė, kad mašina taps pagrindine. Labai didelis privalumas yra tai, kad nereikia konfigūruoti IP adresų pačiame serveryje, užtenka juos aprašyti konfigūracijoje, o jei IP adresams reikia kokių nors pasirinktinių maršruto parinkimo taisyklių, tai aprašyta tiesiogiai konfigūracijoje, naudojant ta pati sintaksė, kaip aprašyta VRRP pakete. Jūs nesusidursite su nepažįstamais dalykais.
Kaip tai atrodo praktikoje? Kas atsitiks, jei vienas iš serverių sugenda? Kai tik meistras dingsta, mūsų atsarginė nustoja gauti skelbimų ir automatiškai tampa meistru. Po kurio laiko sutaisėme masterį, perkrovėme, pakėlėme Keepalived - skelbimai ateina su didesniu prioritetu nei atsarginė kopija, o atsarginė automatiškai atsisuka atgal, pašalina IP adresus, nereikia atlikti jokių rankinių veiksmų.
Taigi, mes užtikrinome išorinio IP adreso atsparumą gedimams. Kita dalis yra kažkaip subalansuoti srautą iš išorinio IP adreso į nuotraukų maršrutizatorius, kurie jį jau nutraukia. Su balansavimo protokolais viskas gana aišku. Tai arba paprastas apsukimas, arba šiek tiek sudėtingesni dalykai, wrr, sąrašo ryšys ir pan. Tai iš esmės aprašyta dokumentacijoje, nėra nieko ypatingo. Bet pristatymo būdas... Čia mes atidžiau pažvelgsime, kodėl pasirinkome vieną iš jų. Tai yra NAT, tiesioginis maršrutas ir TUN. Faktas yra tas, kad iš karto planavome pristatyti 100 gigabitų srautą iš svetainių. Jei įvertinsite, jums reikia 10 gigabitų kortelių, tiesa? 10 gigabitų kortelių viename serveryje jau nepatenka į bent jau mūsų „standartinės įrangos“ koncepciją. Ir tada prisiminėme, kad mes ne tik atiduodame tam tikrą srautą, bet ir nuotraukas.
Kuo ypatingas? - Didžiulis skirtumas tarp įeinančio ir išeinančio srauto. Įeinantis srautas labai mažas, išeinantis labai didelis:
Pažiūrėjus į šiuos grafikus matyti, kad šiuo metu režisierius gauna apie 200 MB per sekundę, tai labai eilinė diena. Grąžiname 4,500 MB per sekundę, mūsų santykis yra maždaug 1/22. Jau aišku, kad norint visiškai užtikrinti išeinantį srautą į 22 darbuotojų serverius, mums reikia tik vieno, kuris priima šį ryšį. Čia mums į pagalbą ateina tiesioginio maršruto parinkimo algoritmas.
Kaip tai atrodo? Mūsų nuotraukų režisierius pagal savo lentelę perduoda ryšius su nuotraukų maršrutizatoriais. Bet foto maršrutizatoriai siunčia grįžtamąjį srautą tiesiai į internetą, siunčia jį klientui, jis negrįžta per nuotraukų režisierių, todėl su minimaliu mašinų skaičiumi užtikriname visišką gedimų toleranciją ir viso srauto pumpavimą. Konfigūracijose tai atrodo taip: nurodome algoritmą, mūsų atveju tai yra paprastas rr, pateikiame tiesioginio maršruto parinkimo metodą ir tada pradedame išvardyti visus tikrus serverius, kiek jų turime. Kas lems šį srautą. Jei turime dar vieną ar du serverius ar kelis serverius, toks poreikis iškyla – tiesiog pridedame šią skiltį prie konfigūracijos ir per daug nesijaudiname. Iš tikrų serverių pusės, iš nuotraukų maršrutizatoriaus pusės, šis metodas reikalauja minimaliausios konfigūracijos, jis puikiai aprašytas dokumentacijoje ir ten nėra jokių spąstų.
Ypač malonu tai, kad toks sprendimas nereiškia radikalaus vietinio tinklo pertvarkymo; tai mums buvo svarbu, mes turėjome tai išspręsti su minimaliomis išlaidomis. Jei pažvelgsite į , tada pamatysime, kaip tai atrodys. Čia mes turime tam tikrą virtualų serverį, prie 443 prievado, klauso, priima ryšį, visi veikiantys serveriai yra išvardyti ir matosi, kad ryšys yra, duok ar imk, tas pats. Jei pažiūrėtume į statistiką tame pačiame virtualiame serveryje, turime įeinančių paketų, įeinančių jungčių, bet visiškai jokių išeinančių. Išeinantys ryšiai eina tiesiai į klientą. Gerai, mums pavyko tai išbalansuoti. O kas nutiks, jei vienas iš mūsų nuotraukų maršrutizatorių sugenda? Juk geležis yra geležis. Jis gali patekti į branduolio paniką, jis gali sulūžti, gali perdegti maitinimo šaltinis. bet ko. Štai kodėl reikia pasitikrinti sveikatą. Jie gali būti tokie paprasti, kaip patikrinti, ar prievadas yra atidarytas, arba kažkas sudėtingesnio, iki kai kurių namuose parašytų scenarijų, kurie netgi patikrins verslo logiką.
Sustojome kažkur per vidurį: turime https užklausą į konkrečią vietą, iškviečiamas scenarijus, jei atsako 200-uoju atsakymu, manome, kad su šiuo serveriu viskas gerai, kad jis gyvas ir gali būti gana įjungtas lengvai.
Kaip tai vėlgi atrodo praktiškai? Išjunkime serverį priežiūrai – pvz., BIOS mirksintiems. Žurnaluose iš karto turime skirtąjį laiką, matome pirmą eilutę, tada po trijų bandymų ji pažymima kaip „nepavyko“ ir tiesiog pašalinama iš sąrašo.
Galimas ir antras elgsenos variantas, kai VS tiesiog nustatomas į nulį, bet jei nuotrauka grąžinama, tai neveikia gerai. Atsiranda serveris, ten paleidžiamas „Nginx“, sveikatos patikrinimas iš karto supranta, kad ryšys veikia, kad viskas gerai, ir serveris pasirodo mūsų sąraše, ir jam iškart pradedama taikyti apkrova. Jokių rankinių veiksmų iš budinčio administratoriaus nereikia. Naktį serveris persikrovė – stebėjimo skyrius mums dėl to naktį neskambina. Jie informuoja, kad taip atsitiko, viskas gerai.
Taigi, gana paprastu būdu, pasitelkę nedidelį skaičių serverių, išsprendėme išorinių gedimų tolerancijos problemą.
Belieka pasakyti, kad visa tai, žinoma, reikia stebėti. Atskirai reikia pažymėti, kad „Keepalivede“, kaip seniai parašyta programinė įranga, turi daugybę būdų jai stebėti, naudojant patikrinimus per DBus, SMTP, SNMP ir standartinį „Zabbix“. Be to, jis pats moka rašyti laiškus beveik kiekvienam čiauduliui, o tiesą pasakius, kažkada net sugalvojome jį išjungti, nes jis rašo daug laiškų bet kokiam srauto perjungimui, įjungimui, kiekvienam IP ryšiui, ir taip toliau . Aišku, jei serverių daug, tai galima ir priblokšti save šiais laiškais. Stebime nginx nuotraukų maršrutizatoriuose naudodami standartinius metodus, o aparatinės įrangos stebėjimas neišnyko. Žinoma, patartume dar du dalykus: pirma, išorinius sveikatos patikrinimus ir prieinamumą, nes net jei viskas veikia, galbūt vartotojai negauna nuotraukų dėl problemų su išoriniais tiekėjais ar dėl kažko sudėtingesnio. Visada verta pasilikti kur nors kitame tinkle, „Amazon“ ar kur kitur, atskirą mašiną, galinčią pinguoti jūsų serverius iš išorės, taip pat verta naudoti anomalijų aptikimą, tiems, kurie žino, kaip atlikti sudėtingą mašininį mokymąsi, arba paprastą stebėjimą. , bent jau siekiant atsekti, ar užklausų smarkiai sumažėjo, ar, priešingai, padaugėjo. Tai taip pat gali būti naudinga.
Apibendrinkime: iš tikrųjų mes pakeitėme geležinį sprendimą, kuris tam tikru momentu nustojo mums tikti, gana paprasta sistema, kuri daro viską taip pat, tai yra, ji užtikrina HTTPS srauto nutraukimą ir tolesnį išmanų maršruto parinkimą naudojant būtinus sveikatos patikrinimus. Mes padidinome šios sistemos stabilumą, tai yra, mes vis dar turime aukštą prieinamumą kiekvienam sluoksniui, be to, turime privalumą, kad yra gana lengva ją pakeisti kiekviename sluoksnyje, nes tai yra standartinė aparatinė įranga su standartine programine įranga, t. , supaprastinome galimų problemų diagnozavimą.
Kuo mes baigėsi? Per 2018 m. sausio mėnesio šventes iškilo problema. Per pirmus šešis mėnesius, kol pradėjome naudoti šią schemą, išplėtėme ją į visą srautą, kad pašalintume visą srautą iš LTM, srautas išaugome tik viename duomenų centre nuo 40 gigabitų iki 60 gigabitų ir tuo pačiu visus 2018 metus per sekundę pavyko išsiųsti beveik tris kartus daugiau nuotraukų.
Šaltinis: www.habr.com