Web modernoa ia pentsaezina da komunikabideen edukirik gabe: ia amona guztiek dute smartphone bat, denak sare sozialetan daude, eta mantentze-lanetan gelditzen diren denborak garestia dira enpresentzat. Hona hemen konpainiaren istorioaren transkripzioa Hardware irtenbide bat erabiliz argazkiak bidaltzea nola antolatu zuen, prozesuan zer errendimendu-arazo aurkitu zituen, zerk eragin zituen eta arazo horiek Nginx-en oinarritutako software-irtenbide bat erabiliz nola konpondu ziren, maila guztietan akatsen tolerantzia bermatuz (). Eskerrak ematen dizkiegu Oleg-en istorioaren egileei Efimova eta Alexandra Dymova, jardunaldian euren esperientzia kontatu zuten .
β Has gaitezen argazkiak gordetzeko eta gordetzeko moduari buruzko sarrera txiki batekin. Geruza bat dugu non gordetzeko, eta geruza bat non argazkiak cachean gordetzeko. Aldi berean, trikimailu-tasa altua lortu eta biltegiratzeko karga murriztu nahi badugu, garrantzitsua da guretzat erabiltzaile indibidual baten argazki bakoitza cacheko zerbitzari batean egotea. Bestela, zerbitzari gehiago ditugun adina aldiz disko gehiago instalatu beharko genuke. Gure trikimailu-tasa %99 ingurukoa da, hau da, gure biltegiaren karga 100 aldiz murrizten ari gara, eta horretarako, duela 10 urte, hau guztia eraikitzen ari zirenean, 50 zerbitzari genituen. Horren arabera, argazki hauek zerbitzatzeko, zerbitzari hauek zerbitzatzen dituzten kanpoko 50 domeinu behar genituen funtsean.
Jakina, berehala sortu zen galdera: gure zerbitzarietako bat jaisten bada eta erabilgarri geratzen ez bada, zer trafikoaren zati galtzen dugu? Merkatuan zegoena aztertu eta hardware pieza bat erostea erabaki genuen, gure arazo guztiak konpondu ahal izateko. F5 sareko konpainiaren (bide batez, duela gutxi erosi zuen NGINX, Inc) konponbidean izan zen aukera: BIG-IP Local Traffic Manager.
Hardware (LTM) honek zer egiten duen: bere kanpoko portuen burdina erredundantzia egiten duen burdinazko bideratzailea da eta sareko topologian oinarritutako trafikoa bideratzeko aukera ematen du, ezarpen batzuetan, eta osasun-egiaztapenak egiten ditu. Guretzat garrantzitsua zen hardware pieza hori programatu ahal izatea. Horren arabera, erabiltzaile jakin baten argazkiak cache zehatz batetik nola zerbitzatzen ziren logika deskriba genezake. Nolakoa da? Domeinu batean, IP batean Internetera begiratzen duen hardware zati bat dago, ssl deskargatzen duena, http eskaerak analizatzen dituena, IRule-ko cache-zenbaki bat hautatzen duena, nora joan eta trafikoa hara joaten uzten duena. Aldi berean, osasun egiaztapenak egiten ditu, eta makinaren bat erabilgarri ez badago, une horretan trafikoa babeskopiako zerbitzari batera joan dadin egin dugu. Konfigurazioaren ikuspuntutik, badaude, noski, Γ±abardura batzuk, baina orokorrean dena nahiko erraza da: txartel bat erregistratzen dugu, zenbaki jakin baten korrespondentzia gure IP sarean, 80 portuetan entzungo dugula esaten dugu. eta 443, zerbitzaria erabilgarri ez badago, trafikoa babeskopiara bidali behar duzula esaten dugu, kasu honetan 35.a, eta arkitektura hau nola desmuntatu behar den logika mordoa deskribatzen dugu. Arazo bakarra hardwarea programatu zen hizkuntza Tcl zela zen. Inork hau gogoratzen badu... lengoaia hau programatzeko komenigarria den hizkuntza baino idaztekoagoa da:
Zer lortu dugu? Gure azpiegituren erabilgarritasun handia bermatzen duen hardware pieza bat jaso genuen, gure trafiko guztia bideratzen duena, osasunerako onurak eskaintzen dituena eta funtzionatzen duena. Gainera, denbora luzez funtzionatzen du: azken 10 urteotan ez da horren inguruko kexarik egon. 2018aren hasieran, segundoko 80 argazki inguru bidaltzen genituen jada. Gure datu-zentroetatik 80 gigabit inguruko trafikoa da.
Hala ereβ¦
2018. urte hasieran, argazki itsusi bat ikusi genuen zerrendetan: argazkiak bidaltzeko behar zen denbora argi eta garbi handitu zen. Eta guri egokitu zitzaigun. Arazoa da jokabide hori trafikoaren gailurrean soilik ikusten zela - gure enpresarentzat igandetik astelehenerako gaua da. Baina gainerako denboran sistemak ohi bezala portatu zuen, porrot zantzurik gabe.
Hala ere, arazoa konpondu beharra zegoen. Botil-lepo posibleak identifikatu eta ezabatzen hasi ginen. Lehenik eta behin, noski, kanpoko goranzko estekak zabaldu genituen, barneko esteken ikuskaritza osoa egin genuen eta egon daitezkeen botila-lepo guztiak aurkitu genituen. Baina honek guztiak ez zuen emaitza agerikorik eman, arazoa ez zen desagertu.
Beste botikin posible bat argazki-katxeen errendimendua izan zen. Eta agian arazoa haiengan dagoela erabaki genuen. Beno, errendimendua zabaldu dugu, batez ere argazki-cacheetako sareko atakak. Baina berriro ere ez zen hobekuntza nabaririk ikusi. Azkenean, arreta handia jarri genion LTM-aren beraren errendimenduari, eta hemen irudi triste bat ikusi genuen grafikoetan: CPU guztien karga leunki joaten hasten da, baina bat-batean lautadara heltzen da. Aldi berean, LTM-k osasun-kontrolei eta goranzko estekei behar bezala erantzuteari uzten dio eta ausaz desaktibatzen hasten da, eta horrek errendimenduaren hondatze larria dakar.
Hau da, arazoaren iturria identifikatu dugu, botila-lepoa identifikatu dugu. Zer egingo dugun erabakitzea geratzen da.
Egin genezakeen lehenengo gauza, argiena, nolabait LTM bera modernizatzea da. Baina hemen Γ±abardura batzuk daude, hardware hau nahiko berezia delako, ez zarete hurbilen dagoen supermerkatura joan eta erosiko. Hau kontratu bereizia da, lizentzia kontratu bereizia, eta denbora asko beharko du. Bigarren aukera zure kabuz pentsatzen hastea da, zure konponbidea asmatu zure osagaiak erabiliz, ahal izanez gero sarbide irekiko programa bat erabiliz. Honetarako zer aukeratuko dugun eta arazo hau konpontzeko zenbat denbora emango dugun erabakitzea besterik ez da geratzen, erabiltzaileek ez baitzuten argazki nahikoa jasotzen. Horregatik, hori guztia oso-oso azkar egin behar dugu, esan liteke atzo batek.
Zereginak "ahalik eta azkarren egin zerbait eta daukagun hardwarea erabiliz" bezalakoa zenez, pentsatu genuen lehen gauza oso indartsu ez diren makina batzuk aurrealdetik kentzea izan zen, jarri Nginx hor, eta horrekin badakigu nola egiten dugun. lan egin eta saiatu hardwareak egiten zuen logika bera ezartzen. Hau da, hain zuzen ere, gure hardwarea utzi, konfiguratu behar genituen 4 zerbitzari gehiago instalatu, haientzako kanpoko domeinuak sortu, duela 10 urteko antzera... Makina hauek eroriz gero erabilgarritasun apur bat galdu genuen, baina are gutxiago, gure erabiltzaileen arazoa lokalean konpondu zuten.
Horren arabera, logikak berdin jarraitzen du: Nginx instalatzen dugu, SSL-deskarga egin dezake, bideratze-logika nolabait programatu dezakegu, osasun-egiaztapenak konfigurazioetan eta aurretik genuen logika bikoiztu besterik ez dugu.
Eser gaitezen konfigurazioak idazteko. Hasieran dena oso sinplea zela zirudien, baina, tamalez, oso zaila da zeregin bakoitzerako eskuliburuak aurkitzea. Hori dela eta, ez dugu gomendatzen "nola konfiguratu Nginx argazkietarako" Google-n sartzea: hobe da dokumentazio ofizialera jotzea, zeinak ukitu beharreko ezarpenak erakutsiko dituen. Baina hobe da parametro zehatza zuk zeuk aukeratzea. Bada, orduan dena sinplea da: ditugun zerbitzariak deskribatzen ditugu, ziurtagiriak deskribatzen ditugu... Baina interesgarriena, hain zuzen ere, bideratze-logika bera da.
Hasieran iruditu zitzaigun, besterik gabe, gure kokapena deskribatzen ari ginela, bertan dagoen gure argazki-cache-kopurua parekatuz, gure eskuak edo sorgailu bat erabiliz zenbat igoera behar ditugun deskribatzeko, gorako bakoitzean trafikoak zein zerbitzaritara behar duen adierazten dugu. joan, eta babeskopia zerbitzari bat - zerbitzari nagusia eskuragarri ez badago:
Baina, ziurrenik, dena hain sinplea balitz, etxera joango ginateke ezer esan gabe. Zoritxarrez, Nginx ezarpen lehenetsiekin, oro har, garapen urte askotan zehar egin ziren eta ez dira kasu honetarako guztiz egokiak... konfigurazioak honela dauka: gorako zerbitzariren batek eskaera-errore bat edo denbora-muga badu, Nginx-ek beti trafikoa hurrengora aldatzen du. Gainera, lehen hutsegitearen ondoren, 10 segundoren buruan zerbitzaria ere itzaliko da, akatsez eta denbora-mugaz - hau ezin da inola ere konfiguratu. Hau da, gorako zuzentarauan denbora-muga aukera kentzen edo berrezartzen badugu, Nginx-ek eskaera hau prozesatuko ez badu eta errore ez oso on batekin erantzungo badu ere, zerbitzaria itzali egingo da.
Hori ekiditeko, bi gauza egin ditugu:
a) Nginx-i hori eskuz egitea debekatu zioten - eta, zoritxarrez, hori egiteko modu bakarra hutsegite maximoen ezarpenak ezartzea da.
b) gogoratu dugu beste proiektu batzuetan aurrekarien osasun-azterketak egiteko aukera ematen digun modulu bat erabiltzen dugula; horregatik, osasun-kontrolak nahiko maiz egiten ditugula, istripua gertatuz gero geldialdi-denbora gutxienekoa izan dadin.
Zoritxarrez, hau ere ez da guztia, literalki eskema honen funtzionamenduaren lehen bi asteetan TCP osasun-egiaztapena ere fidagarria ez den gauza bat dela erakutsi baitute: gorako zerbitzarian agian ez da Nginx izango, edo Nginx D-egoeran, eta kasu honetan nukleoak konexioa onartuko du, osasun-egiaztapena gaindituko da, baina ez du funtzionatuko. Hori dela eta, berehala ordezkatu dugu osasun-egiaztapena http-rekin, zehatz bat egin dugu, 200 itzultzen badu, dena funtzionatzen du script honetan. Logika gehigarria egin dezakezu; adibidez, cachean dauden zerbitzarien kasuan, egiaztatu fitxategi-sistema behar bezala muntatuta dagoela:
Eta hau egokituko litzaiguke, momentuz zirkuituak hardwareak egindakoa guztiz errepikatu zuela izan ezik. Baina hobeto egin nahi genuen. Aurretik, babeskopia zerbitzari bat genuen, eta ziurrenik hau ez da oso ona, ehun zerbitzari badituzu, hainbatek aldi berean huts egiten dutenean, ziurrenik babeskopia zerbitzari batek nekez aurre egingo dio kargari. Hori dela eta, erreserba zerbitzari guztietan banatzea erabaki genuen: goranzko beste bereizi bat egin genuen, zerbitzari guztiak hor zerbitzari guztiak zerbitzatu dezaketen kargaren arabera parametro jakin batzuekin idatzi genituen, aurretik genituen osasun egiaztapen berberak gehitu genituen:
Ezinezkoa denez gorako beste batera joatea gorako baten barruan, ziurtatu behar zen goranzko nagusia, zeinetan beharrezkoa den argazki-cache zuzena grabatu genuena, ez bazegoela erabilgarri, error_page-tik pasatzea besterik ez genuela. nondik gorako babeskopiara joan ginen:
Eta literalki lau zerbitzari gehituz, hauxe da: kargaren zati bat ordezkatu genuen - LTMtik zerbitzari horietara kendu genuen, han logika bera ezarri genuen, hardware eta software estandarra erabiliz, eta berehala jaso genuen zerbitzari hauek ahal duten hobaria. eskalatu behar dira, behar adina hornitu daitezkeelako. Bada, negatibo bakarra kanpoko erabiltzaileentzako erabilgarritasun handia galdu dugula da. Baina momentu horretan hori sakrifikatu behar izan genuen, arazoa berehala konpontzea beharrezkoa zelako. Beraz, kargaren zati bat kendu genuen, % 40 ingurukoa zen garai hartan, LTM ondo sentitu zen, eta literalki arazoa hasi eta bi aste geroago, segundoko 45k eskaera ez bidaltzen hasi ginen, 55k baizik. Izan ere, % 20 hazi gara, hau da, argi eta garbi, erabiltzaileari eman ez diogun trafikoa. Eta ondoren, gainerako arazoa nola konpondu pentsatzen hasi ziren - kanpoko irisgarritasun handia bermatzea.
Geldialdi bat egin genuen, eta horretarako zein irtenbide erabiliko genuen eztabaidatu genuen. DNS erabiliz fidagarritasuna bermatzeko proposamenak zeuden, etxean idatzitako script batzuk erabiliz, bideratze dinamikoko protokoloak... aukera asko zeuden, baina jada argi geratu zen argazkiak benetan fidagarriak emateko, hau kontrolatuko duen beste geruza bat sartu behar dela. . Makina horiei argazki zuzendariak deitzen genien. Gu fidatu ginen softwarea Keepalived zen:
Hasteko, zertan datza Keepalived? Lehenengoa VRRP protokoloa da, saregileek oso ezaguna, bezeroak konektatzen diren kanpoko IP helbideari akatsen tolerantzia ematen dion sareko ekipoetan kokatua. Bigarren zatia IPVS da, IP zerbitzari birtuala, argazki-bideratzaileen artean orekatzeko eta maila honetan akatsen tolerantzia bermatzeko. Eta hirugarren - osasun kontrolak.
Has gaitezen lehen zatitik: VRRP - nolakoa da? IP birtual jakin bat dago, dns badoocdn.com-en sarrera bat duena, non bezeroak konektatzen diren. Uneren batean, IP helbide bat dugu zerbitzari batean. Keepalived paketeak zerbitzarien artean exekutatzen dira VRRP protokoloa erabiliz, eta maisua radartik desagertzen bada - zerbitzaria berrabiarazi egin da edo beste zerbait, orduan babeskopia zerbitzariak automatikoki jasotzen du IP helbide hau - ez da eskuzko ekintzarik behar. Maisuaren eta babeskopiaren arteko aldea lehentasuna da nagusiki: zenbat eta handiagoa izan, orduan eta aukera handiagoa izango da makina maisu bihurtzeko. Abantaila oso handia da ez duzula IP helbideak zerbitzarian bertan konfiguratu behar, nahikoa da konfigurazioan deskribatzea, eta IP helbideak bideratze-arau pertsonalizatu batzuk behar badituzu, hau zuzenean deskribatzen da konfigurazioan, erabiliz. VRRP paketean deskribatutako sintaxi bera. Ez duzu gauza ezezagun bat topatuko.
Nolakoa da hau praktikan? Zer gertatzen da zerbitzarietako batek huts egiten badu? Maisua desagertu bezain laster, gure babeskopiak iragarkiak jasotzeari uzten dio eta automatikoki maisu bihurtzen da. Denbora pixka bat igaro ondoren, maisua konpondu, berrabiarazi, Keepalived planteatu dugu - iragarkiak babeskopiak baino lehentasun handiagoarekin iristen dira eta babeskopia automatikoki atzera egiten du, IP helbideak kentzen ditu, ez da eskuzko ekintzarik egin behar.
Horrela, kanpoko IP helbidearen akatsen tolerantzia bermatu dugu. Hurrengo zatia kanpoko IP helbidetik dagoeneko amaitzen ari diren argazki bideratzaileetara arteko trafikoa orekatzea da. Dena nahiko argi dago orekatzeko protokoloekin. Hau round-robin sinplea da, edo gauza apur bat konplexuagoak, wrr, zerrenda konexioa eta abar. Hau funtsean dokumentazioan deskribatzen da, ez dago ezer berezirik. Baina entregatzeko modua... Hemen aztertuko dugu zergatik aukeratu dugun horietako bat. Hauek NAT, Direct Routing eta TUN dira. Kontua da berehala planifikatu genuela guneetatik 100 gigabit trafikoa ematea. Kalkulatzen baduzu, 10 gigabit txartelak behar dituzu, ezta? Zerbitzari bakarreko 10 gigabit txartelak dagoeneko gure "ekipamendu estandarraren" kontzeptuaren esparrutik kanpo daude. Eta orduan gogoratu ginen ez dugula trafiko pixka bat oparitzen, argazkiak oparitzen ditugula.
Zer da berezia? β Sarrerako eta irteerako trafikoaren arteko aldea izugarria. Sarrerako trafikoa oso txikia da, irteerako trafikoa oso handia da:
Grafiko hauei erreparatuz gero, ikus daiteke momentuz zuzendaria segundoko 200 MB inguru jasotzen ari dela, oso egun arrunta dela. 4,500 MB itzultzen ditugu segundoko, gure ratioa 1/22 da gutxi gorabehera. Dagoeneko argi dago 22 langile zerbitzariei irteerako trafikoa guztiz emateko, konexio hori onartzen duen bakarra behar dugula. Hona hemen bideratze zuzeneko algoritmoa gure laguntzan.
Nolakoa da? Gure argazki zuzendariak, bere taularen arabera, argazki-bideratzaileei konexioak transmititzen dizkie. Baina argazki bideratzaileek itzulera-trafikoa zuzenean Internetera bidaltzen dute, bezeroari bidaltzen diote, ez da argazki-zuzendaritik atzera egiten, horrela, gutxieneko makina kopuru batekin, akatsen tolerantzia osoa eta trafiko guztia ponpatzea bermatzen dugu. Konfigurazioetan honela ikusten da: algoritmoa zehazten dugu, gure kasuan rr soil bat da, bideratze metodo zuzena eman eta gero benetako zerbitzari guztiak zerrendatzen hasten gara, zenbat ditugun. Trafiko hori zehaztuko duena. Hor zerbitzari bat edo bi gehiago baditugu, edo hainbat zerbitzari baditugu, behar hori sortzen da - atal hau konfiguraziora gehitzen dugu eta ez kezkatu gehiegi. Benetako zerbitzarien aldetik, argazki-bideratzailearen aldetik, metodo honek konfigurazio minimoena eskatzen du, ezin hobeto deskribatzen da dokumentazioan eta ez dago tranparik.
Bereziki polita da horrelako irtenbide batek ez duela esan nahi sare lokalaren birmoldaketa erradikal bat; hori garrantzitsua zen guretzat; kostu minimoekin konpondu behar izan genuen. Begiratuz gero , orduan ikusiko dugu nolakoa den. Hemen zerbitzari birtual jakin bat dugu, 443 atakan, entzuten du, konexioa onartzen du, lanean ari diren zerbitzari guztiak zerrendatuta daude, eta konexioa berdina dela ikus dezakezu, eman edo hartu. Zerbitzari birtual bereko estatistikei erreparatzen badiegu, sarrerako paketeak ditugu, sarrerako konexioak, baina guztiz ez irteerakoak. Irteerako konexioak zuzenean bezeroarengana doaz. Ados, desorekatu ahal izan genuen. Orain, zer gertatzen da gure argazki bideratzaileetako batek huts egiten badu? Azken finean, burdina burdina da. Kernel izuan sartu daiteke, apurtu egin daiteke, elikadura hornidura erre daiteke. Edozer. Horregatik beharrezkoak dira osasun-kontrolak. Portua nola irekita dagoen egiaztatzea bezain sinpleak izan daitezke, edo zerbait konplexuagoa, negozioaren logika ere egiaztatuko duten etxean idatzitako script batzuk arte.
Erdian gelditu gara: https eskaera bat dugu kokapen zehatz batera, script-a deitzen da, 200. erantzun batekin erantzuten badu, zerbitzari honekin dena ondo dagoela uste dugu, bizirik dagoela eta nahiko aktibatu daitekeela. erraz.
Nola ikusten da hau, berriro ere, praktikan? Desaktibatu dezagun zerbitzaria mantentze-lanetarako - BIOS keinuka, adibidez. Erregistroetan, berehala denbora-muga bat dugu, lehen lerroa ikusten dugu, gero hiru saiakera egin ondoren "huts" gisa markatzen da eta zerrendatik kendu besterik ez da egiten.
Bigarren portaera-aukera bat ere posible da, VS besterik gabe zeroan ezartzen denean, baina argazkia itzultzen bada, honek ez du ondo funtzionatzen. Zerbitzaria etortzen da, Nginx hor hasten da, health-check-ek berehala ulertzen du konexioa funtzionatzen ari dela, dena ondo dagoela eta zerbitzaria gure zerrendan agertzen da, eta berehala hasten zaio karga aplikatzen. Ez da eskuzko ekintzarik behar betebehar-administratzailearengandik. Zerbitzaria gauez berrabiarazi da - monitorizazio sailak ez digu gauez honi buruz deitzen. Hori gertatu dela jakinarazten dizute, dena ondo dagoela.
Beraz, nahiko modu sinplean, zerbitzari kopuru txiki baten laguntzaz, kanpoko akatsen tolerantziaren arazoa konpondu genuen.
Esan behar dena da hori guztia, noski, jarraipena egin behar dela. Bereizita, kontuan izan behar da Keepalivede-k, aspaldi idatzitako software gisa, monitorizatzeko modu asko dituela, bai DBus, SMTP, SNMP eta Zabbix estandarraren bidez egiaztapenak erabiliz. Gainera, berak badaki ia doministiku bakoitzeko letrak idazten, eta egia esateko, noizbait itzaltzea ere pentsatu genuen, edozein trafiko aldatzeko, pizteko, IP konexio bakoitzeko gutun asko idazten baititu. eta abar . Jakina, zerbitzari asko baldin badaude, zure burua gainezka dezakezu letra hauekin. Nginx argazki-bideratzaileetan kontrolatzen dugu metodo estandarrak erabiliz, eta hardwarearen monitorizazioa ez da desagertu. Bi gauza gehiago gomendatuko genituzke, noski: lehenik, kanpoko osasun-kontrolak eta erabilgarritasuna, zeren eta dena funtzionatzen badu ere, izan ere, agian erabiltzaileek ez dituzte argazkirik jasotzen kanpoko hornitzaileekin dituzten arazoengatik edo zerbait konplexuagoagatik. Beti merezi du beste sare batean nonbait mantentzea, Amazonen edo beste nonbait, zure zerbitzariei ping-a egin diezaiekeen makina bereizi bat kanpotik, eta merezi du, gainera, anomalien detekzioa erabiltzea, ikasketa automatiko zaila egiten dakitenentzat, edo monitorizazio sinplea. , eskaerak asko jaitsi diren, edo, aitzitik, handitu diren jakiteko, behintzat. Baliagarria ere izan daiteke.
Labur dezagun: guk, hain zuzen, burdinezko irtenbidea ordezkatu genuen, noizbait komeni zitzaigun, nahiko sistema sinple batekin dena berdin egiten duena, hau da, HTTPS trafikoa amaitzea eta bideratze adimendun gehiago eskaintzen duena. beharrezko osasun-kontrolak. Sistema honen egonkortasuna areagotu dugu, hau da, oraindik ere erabilgarritasun handia dugu geruza bakoitzeko, gainera geruza bakoitzean dena eskalatzea nahiko erraza dela abantaila dugu, software estandarra duen hardware estandarra delako, hau da. , arazo posibleen diagnostikoa erraztu dugu.
Zerrekin bukatu dugu? 2018ko urtarrileko oporretan arazo bat izan genuen. Lehenengo sei hilabeteetan eskema hau martxan jarri genuen bitartean, trafiko guztietara zabaldu genuen LTMtik trafiko guztia kentzeko, datu-zentro batean trafikoa soilik hazi ginen 40 gigabitetatik 60 gigabitetara, eta aldi berean 2018 urte osoa segundoko ia hiru aldiz argazki gehiago bidaltzeko gai izan ziren.
Iturria: www.habr.com