It moderne web is hast net te tinken sûnder media-ynhâld: hast elke beppe hat in smartphone, elkenien is op sosjale netwurken, en downtime yn ûnderhâld is kostber foar bedriuwen. Hjir is in transkripsje fan it ferhaal fan it bedriuw oer hoe't se de levering fan foto's organisearre mei in hardware-oplossing, hokker prestaasjesproblemen se yn it proses tsjinkaam, wat se feroarsake, en hoe't dizze problemen waarden oplost mei in software-oplossing basearre op Nginx, wylst se op alle nivo's fouttolerânsje garandearje (). Wy tankje de skriuwers fan it ferhaal fan Oleg Efimova en Alexandra Dymova, dy't har ûnderfining dielde op 'e konferinsje .
- Litte wy begjinne mei in lytse yntroduksje oer hoe't wy foto's opslaan en opslaan. Wy hawwe in laach wêr't wy se opslaan, en in laach wêr't wy de foto's cache. Tagelyk, as wy wolle berikke in hege trick taryf en ferminderjen de lading op opslach, is it wichtich foar ús dat elke foto fan in yndividuele brûker is op ien caching tsjinner. Oars soene wy safolle kearen mear skiven moatte ynstallearje as wy mear servers hawwe. Us trick rate is sawat 99%, dat is, wy ferminderje de lading op ús opslach mei 100 kear, en om dit te dwaan, 10 jier lyn, doe't dit alles waard boud, hienen wy 50 servers. Dêrom, om dizze foto's te tsjinjen, hawwe wy yn essinsje 50 eksterne domeinen nedich dy't dizze servers tsjinje.
Fansels kaam de fraach fuortendaliks op: as ien fan ús servers delgiet en net beskikber wurdt, hokker diel fan it ferkear ferlieze wy dan? Wy seagen nei wat der op 'e merk wie en besletten om in stikje hardware te keapjen sadat it al ús problemen soe oplosse. De kar foel op 'e oplossing fan it F5-netwurkbedriuw (dat trouwens koartlyn NGINX, Inc kocht): BIG-IP Local Traffic Manager.
Wat dit stik hardware (LTM) docht: it is in izeren router dy't izeren oerstallich makket fan har eksterne havens en kinne jo ferkear rûte basearre op 'e netwurktopology, op guon ynstellings, en docht sûnenskontrôles. It wie foar ús wichtich dat dit stik hardware koe wurde programmearre. Dêrtroch koene wy de logika beskriuwe fan hoe't foto's fan in spesifike brûker waarden betsjinne út in spesifike cache. Wêr liket it op? D'r is in stik hardware dat sjocht nei it ynternet op ien domein, ien IP, docht ssl-offload, parseart http-oanfragen, selektearret in cache-nûmer fan IRule, wêr't te gean, en lit ferkear dêr gean. Tagelyk docht it sûnenskontrôles, en yn it gefal dat guon masine net beskikber wie, makken wy it sa dat it ferkear nei ien reservekopytsjinner gie. Fanút in konfiguraasjepunt binne d'r fansels wat nuânses, mar yn 't algemien is alles frij simpel: wy registrearje in kaart, korrespondinsje fan in bepaald nûmer nei ús IP op it netwurk, wy sizze dat wy sille harkje op havens 80 en 443, wy sizze dat as de tsjinner is net beskikber, dan moatte stjoere ferkear nei de reservekopy ien, yn dit gefal de 35., en wy beskriuwe in boskje logika op hoe't dizze arsjitektuer moat wurde disassembled. It ienige probleem wie dat de taal wêryn de hardware programmearre wie Tcl. As immen dit überhaupt ûnthâldt ... dizze taal is mear skriuwtaal dan in taal dy't handich is foar programmearring:
Wat hawwe wy krigen? Wy krigen in stik hardware dat soarget foar hege beskikberens fan ús ynfrastruktuer, rûtes al ús ferkear, jout sûnens foardielen en gewoan wurket. Boppedat wurket it nochal lang: de ôfrûne 10 jier binne der gjin klachten oer. Oan it begjin fan 2018 stjoerden wy al sa'n 80k foto's per sekonde. Dit is earne om 80 gigabits fan ferkear fan ús beide datasintra.
Lykwols…
Oan it begjin fan 2018 seagen wy in ûnsjogge foto op 'e hitlisten: de tiid dy't it duorre om foto's te ferstjoeren wie dúdlik tanommen. En it stoppe ús te passen. It probleem is dat dit gedrach allinich sichtber wie yn 'e pyk fan ferkear - foar ús bedriuw is dit de nacht fan snein op moandei. Mar de rest fan 'e tiid gedrage it systeem as gewoanlik, gjin tekens fan mislearring.
Dochs moast it probleem oplost wurde. Wy identifisearre mooglike knyppunten en begûn te elimineren se. Alderearst hawwe wy fansels eksterne uplinks útwreide, in folsleine kontrôle fan ynterne uplinks útfierd en alle mooglike knyppunten fûn. Mar dit alles joech gjin dúdlik resultaat, it probleem ferdwûn net.
In oar mooglik knelpunt wie de útfiering fan de fotocaches sels. En wy besletten dat miskien it probleem by har leit. No, wy wreide de prestaasjes út - benammen netwurkhavens op fotocaches. Mar wer gjin dúdlike ferbettering waard sjoen. Oan 'e ein hawwe wy goed omtinken jûn oan de prestaasjes fan' e LTM sels, en hjir seagen wy in tryst byld op 'e grafiken: de lading op alle CPU's begjint soepel te gean, mar komt dan ynienen op in plato. Tagelyk stopet LTM adekwaat te reagearjen op sûnenskontrôles en uplinks en begjint se willekeurich út te skeakeljen, wat liedt ta serieuze prestaasjesdegradaasje.
Dat is, wy hawwe de boarne fan it probleem identifisearre, de knelpunt identifisearre. It bliuwt om te besluten wat wy sille dwaan.
It earste, meast foar de hân lizzende ding dat wy koenen dwaan is de LTM sels op ien of oare manier te modernisearjen. Mar d'r binne hjir wat nuânses, om't dizze hardware frij unyk is, jo sille net nei de tichtstbye supermerk gean en it keapje. Dit is in apart kontrakt, in apart lisinsjekontrakt, en it sil in protte tiid nimme. De twadde opsje is om foar josels te begjinnen te tinken, mei jo eigen oplossing te kommen mei jo eigen komponinten, leafst mei in iepen tagongsprogramma. Alles dat bliuwt is om te besluten wat wy hjirfoar sille kieze en hoefolle tiid wy sille besteegje oan it oplossen fan dit probleem, om't brûkers net genôch foto's krigen. Dêrom moatte wy dit alles hiel, hiel fluch dwaan, soe men juster sizze kinne.
Sûnt de taak klonk as "sa rap mooglik wat dwaan en de hardware brûke dy't wy hawwe," it earste ding dat wy tochten wie gewoan wat net heul krêftige masines fan 'e foarkant te ferwiderjen, Nginx dêr te setten, wêrmei wy witte hoe't wurkje en besykje alle deselde logika te ymplementearjen dy't hardware brûkte om te dwaan. Dat is, yn feite, wy ferlieten ús hardware, ynstallearre 4 mear tsjinners dy't wy moasten konfigurearje, makke eksterne domeinen foar harren, fergelykber mei hoe't it wie 10 jier lyn ... Wy ferlearen in bytsje yn beskikberens as dizze masines foelen, mar noch minder, se hawwe it probleem fan ús brûkers lokaal oplost.
Dêrtroch bliuwt de logika itselde: wy ynstallearje Nginx, it kin SSL-offload dwaan, wy kinne op ien of oare manier de routinglogika programmearje, sûnenskontrôles yn 'e konfiguraasjes en gewoan de logika duplisearje dy't wy earder hienen.
Litte wy sitte om konfiguraasjes te skriuwen. Earst like it dat alles hiel ienfâldich wie, mar spitigernôch is it heul lestich om hânboeken foar elke taak te finen. Dêrom riede wy net oan om gewoan te googelen "hoe kinne jo Nginx foar foto's konfigurearje": it is better om te ferwizen nei de offisjele dokumintaasje, dy't sil sjen litte hokker ynstellings moatte wurde oanrekke. Mar it is better om de spesifike parameter sels te kiezen. No, dan is alles ienfâldich: wy beskriuwe de servers dy't wy hawwe, wy beskriuwe de sertifikaten ... Mar it meast nijsgjirrige is, yn feite, de routinglogika sels.
Yn it earstoan like it ús dat wy gewoan ús lokaasje beskriuwe, it nûmer fan ús foto-cache dêryn oerienkomme, ús hannen of in generator brûke om te beskriuwen hoefolle streamopstreamen wy nedich binne, yn elke streamop jouwe wy de tsjinner oan wêrop it ferkear moat gean, en in reservekopytsjinner - as de haadtsjinner net beskikber is:
Mar, wierskynlik, as alles sa ienfâldich wie, soene wy gewoan nei hûs gean en neat sizze. Spitigernôch, mei de standert Nginx-ynstellingen, dy't, yn 't algemien, binne makke oer in protte jierren fan ûntwikkeling en binne net folslein geskikt foar dit gefal ... de konfiguraasje sjocht der sa út: as guon streamop-tsjinner in fersykflater of time-out hat, Nginx altyd skeakelt ferkear nei de folgjende. Boppedat, nei it earste mislearjen, binnen 10 sekonden de tsjinner wurdt ek útskeakele, sawol by fersin en troch time-out - dit kin net iens wurde konfigurearre op hokker wize. Dat is, as wy de timeout-opsje yn 'e streamoprjochting fuortsmite of weromsette, dan, hoewol Nginx dit fersyk net ferwurkje en sil reagearje mei wat net heul goede flater, sil de tsjinner ôfslute.
Om dit te foarkommen hawwe wy twa dingen dien:
a) se ferbean Nginx dit mei de hân te dwaan - en spitigernôch is de ienige manier om dit te dwaan is gewoan de ynstellings foar maksimale mislearrings yn te stellen.
b) wy ûnthâlde dat wy yn oare projekten in module brûke wêrmei wy eftergrûnsûnenskontrôles kinne dwaan - dêrom hawwe wy frij faak sûnenskontrôles dien, sadat de downtime yn it gefal fan in ûngelok minimaal soe wêze.
Spitigernôch is dit ek net alles, om't letterlik de earste twa wiken fan wurking fan dit skema oantoand dat TCP sûnenskontrôle ek in ûnbetrouber ding is: op 'e streamoptsjinner kin it net Nginx wêze, of Nginx yn D-state, en yn dit gefal sil de kernel de ferbining akseptearje, sûnenskontrôle sil passe, mar sil net wurkje. Dêrom hawwe wy dit fuortendaliks ferfongen troch sûnenskontrôle http, makke in spesifike, dy't, as it 200 weromkomt, dan wurket alles yn dit skript. Jo kinne ekstra logika dwaan - bygelyks, yn it gefal fan caching-tsjinners, kontrolearje dat it bestânsysteem goed is monteard:
En dit soe ús passe, útsein dat op it stuit it circuit folslein werhelle wat de hardware die. Mar wy woenen it better dwaan. Earder hienen wy ien reservekopytsjinner, en dit is wierskynlik net heul goed, om't as jo hûndert servers hawwe, dan as ferskate op ien kear mislearje, is ien reservekopytsjinner net wierskynlik om te gean mei de lading. Dêrom hawwe wy besletten om de reservearring oer alle servers te fersprieden: wy hawwe gewoan in oare aparte streamôfwert makke, alle servers dêr skreaun mei bepaalde parameters yn oerienstimming mei de lading dy't se kinne tsjinje, deselde sûnenskontrôles tafoege dy't wy earder hienen:
Om't it ûnmooglik is om binnen ien streamop nei in oare streamop te gean, wie it nedich om derfoar te soargjen dat as de haadstreamopstream, wêryn wy gewoan de juste, needsaaklike fotocache opnaam, net beskikber wie, wy gewoan troch de error_page gienen nei fallback, fan wêr't wy nei de reservekopy streamop gongen:
En troch letterlik fjouwer servers ta te foegjen, is dit wat wy krigen: wy hawwe in diel fan 'e lading ferfongen - wy hawwe it fan LTM nei dizze servers fuorthelle, deselde logika dêr ymplementearre, mei standert hardware en software, en krigen fuortendaliks de bonus dat dizze servers kinne wurde skaalfergrutting, om't se gewoan safolle kinne leverje as nedich. No, it ienige negatyf is dat wy hege beskikberens foar eksterne brûkers ferlern hawwe. Mar op dat stuit moasten wy dit opofferje, want it wie nedich om it probleem daliks op te lossen. Sa, wy fuorthelle in part fan 'e lading, it wie oer 40% op dat stuit, LTM fielde goed, en letterlik twa wiken neidat it probleem begûn, wy begûn te stjoeren net 45k fersiken per sekonde, mar 55k. Eins groeiden wy mei 20% - dit is dúdlik it ferkear dat wy de brûker net joegen. En dêrnei begûnen se nei te tinken oer hoe't it oerbleaune probleem op te lossen - om hege eksterne tagonklikens te garandearjen.
Wy hiene wat pauze, wêrby't wy bepraten hokker oplossing wy hjirfoar brûke soene. D'r wiene foarstellen om betrouberens te garandearjen mei DNS, mei guon thússkreaune skripts, dynamyske routingprotokollen ... d'r wiene in protte opsjes, mar it waard al dúdlik dat jo foar echt betroubere levering fan foto's in oare laach moatte ynfiere dy't dit kontrolearje sil . Wy neamden dizze masines foto direkteuren. De software wêrop wy fertrouden wie Keepalved:
Om te begjinnen, wat bestiet Keepalived út? De earste is it VRRP-protokol, breed bekend foar netwurkers, leit op netwurkapparatuer dy't fouttolerânsje leveret oan it eksterne IP-adres wêrmei kliïnten ferbine. It twadde diel is IPVS, IP firtuele tsjinner, foar balânsjen tusken foto routers en soargje foar fout tolerânsje op dit nivo. En tredde - sûnenskontrôles.
Litte wy begjinne mei it earste diel: VRRP - hoe sjocht it der út? D'r is in bepaalde firtuele IP, dy't in yngong hat yn 'e dns badoocdn.com, wêr't kliïnten ferbine. Op in stuit hawwe wy in IP-adres op ien server. Keepalved pakketten rinne tusken de servers mei it VRRP-protokol, en as de master ferdwynt fan 'e radar - de tsjinner is opnij opstart of wat oars, dan pakt de reservekopytsjinner dit IP-adres automatysk op - gjin hânmjittige aksjes binne nedich. It ferskil tusken master en reservekopy is benammen prioriteit: hoe heger it is, hoe grutter de kâns dat de masine wurdt in master. In heul grut foardiel is dat jo IP-adressen net op 'e tsjinner sels hoege te konfigurearjen, it is genôch om se te beskriuwen yn' e konfiguraasje, en as de IP-adressen wat oanpaste routingregels nedich binne, wurdt dit direkt beskreaun yn 'e konfiguraasje, mei help fan de deselde syntaksis as beskreaun yn it VRRP-pakket. Jo sille gjin ûnbekende dingen tsjinkomme.
Hoe sjocht dit der yn de praktyk út? Wat bart der as ien fan de tsjinners mislearret? Sadree't de master ferdwynt, hâldt ús reservekopy op mei it ûntfangen fan advertinsjes en wurdt automatysk in master. Nei in skoft hawwe wy de master reparearre, op 'e nij opstart, Keepalived ferhege - advertinsjes komme mei in hegere prioriteit dan de reservekopy, en de reservekopy draait automatysk werom, ferwideret IP-adressen, gjin hânmjittige aksjes hoege te dwaan.
Sa hawwe wy soarge foar de fouttolerânsje fan it eksterne IP-adres. It folgjende diel is om it ferkear op ien of oare manier te balansearjen fan it eksterne IP-adres nei de foto-routers dy't it al beëinigje. Alles is frij dúdlik mei de balânsprotokollen. Dit is of in ienfâldige round-robin, of wat mear komplekse dingen, wrr, list ferbining ensafuorthinne. Dit is yn prinsipe beskreaun yn 'e dokumintaasje, der is neat spesjaal. Mar de levering metoade ... Hjir sille wy nimme in tichterby wêrom't wy keas ien fan harren. Dit binne NAT, Direct Routing en TUN. It feit is dat wy fuortendaliks plannen om 100 gigabits fan ferkear fan 'e siden te leverjen. As jo skatte, do moatst 10 gigabit cards, rjochts? 10 gigabit-kaarten yn ien server is al bûten it berik fan, op syn minst, ús konsept fan "standert apparatuer". En doe betochten wy dat wy net samar wat ferkear jaan, wy jouwe foto's.
Wat is spesjaal? - Enorme ferskil tusken ynkommende en útgeande ferkear. Ynkommend ferkear is heul lyts, útgeand ferkear is heul grut:
As jo nei dizze grafiken sjogge, kinne jo sjen dat op it stuit de direkteur sa'n 200 MB per sekonde ûntfangt, dit is in heul gewoane dei. Wy jouwe 4,500 MB per sekonde werom, ús ferhâlding is sawat 1/22. It is al dúdlik dat om folslein útgeand ferkear te leverjen oan 22 arbeidersservers, wy mar ien nedich binne dy't dizze ferbining akseptearret. Dit is wêr't it algoritme foar direkte routing ús helpt.
Wêr liket it op? Us fotodirekteur stjoert neffens syn tabel ferbiningen nei foto-routers. Mar foto-routers stjoere weromferkear direkt nei it ynternet, stjoer it nei de kliïnt, it giet net werom troch de fotodirekteur, dus, mei in minimum oantal masines, soargje wy foar folsleine fouttolerânsje en pompen fan alle ferkear. Yn 'e konfiguraasjes sjocht it der sa út: wy spesifisearje it algoritme, yn ús gefal is it in ienfâldige rr, jouwe de direkte routingmetoade en begjinne dan alle echte servers te listjen, hoefolle fan har wy hawwe. Wat sil bepale dit ferkear. As wy dêr noch ien of twa servers hawwe, of ferskate servers, dan ûntstiet sa'n need - wy foegje dizze seksje gewoan ta oan 'e konfiguraasje en meitsje ús net te folle soargen. Fan 'e kant fan' e echte servers, fan 'e kant fan' e foto-router, fereasket dizze metoade de meast minimale konfiguraasje, it is perfekt beskreaun yn 'e dokumintaasje, en d'r binne gjin falkûlen.
Wat foaral moai is, is dat sa'n oplossing gjin radikale werynrjochting fan it lokale netwurk betsjuttet, dit wie wichtich foar ús, wy moasten dit oplosse mei minimale kosten; As jo sjogge nei , dan sille wy sjen hoe't it derút sjocht. Hjir hawwe wy in bepaalde firtuele tsjinner, op haven 443, harket, akseptearret de ferbining, alle wurkjende tsjinners wurde fermeld, en jo kinne sjen dat de ferbining is, jaan of nimme, itselde. As wy sjogge nei de statistiken op deselde firtuele tsjinner, wy hawwe ynkommende pakketten, ynkommende ferbinings, mar absolút gjin útgeande ones. Utgeande ferbiningen geane direkt nei de klant. Okee, wy koene it unbalansearje. No, wat bart der as ien fan ús foto-routers mislearret? Izer is ommers izer. It kin gean yn kernel panyk, it kin brekke, de macht oanbod kin burn out. Alles. Dêrom binne sûnenskontrôles nedich. Se kinne sa ienfâldich wêze as kontrolearjen hoe't de poarte iepen is, of wat komplekser, oant guon thússkreaune skripts dy't sels de saaklike logika sille kontrolearje.
Wy stoppe earne yn 't midden: wy hawwe in https-fersyk nei in spesifike lokaasje, it skript wurdt neamd, as it antwurdet mei in 200ste antwurd, leauwe wy dat alles goed is mei dizze tsjinner, dat it libbet en kin wurde ynskeakele maklik.
Hoe sjocht dit der wer út yn de praktyk? Litte wy de tsjinner útsette foar ûnderhâld - bygelyks it BIOS flashje. Yn 'e logs hawwe wy fuortendaliks in time-out, wy sjogge de earste rigel, dan nei trije besykjen wurdt it markearre as "mislearre", en it wurdt gewoan út 'e list fuortsmiten.
In twadde gedrachsopsje is ek mooglik, as VS gewoan op nul is ynsteld, mar as de foto weromkomt, wurket dit net goed. De tsjinner komt op, Nginx begjint dêr, sûnenskontrôle begrypt daliks dat de ferbining wurket, dat alles goed is, en de tsjinner ferskynt yn ús list, en de lading begjint daliks oan te passen. Gjin hânmjittige aksjes binne nedich fan 'e plichtbehearder. De tsjinner is nachts opnij opstart - de tafersjochôfdieling ropt ús hjir net nachts oer. Se ynformearje jo dat dit barde, alles is goed.
Dat, op in frij ienfâldige manier, mei help fan in lyts oantal servers, hawwe wy it probleem fan eksterne fouttolerânsje oplost.
It bliuwt allinich om te sizzen dat dit alles fansels kontrolearre wurde moat. Apart moat it opmurken wurde dat Keepalivede, as in lange tiid lyn skreaun software, in protte manieren hat om it te kontrolearjen, sawol mei kontrôles fia DBus, SMTP, SNMP, en standert Zabbix. Boppedat wit hy sels foar hast elke snee brieven skriuwe, en om earlik te wêzen, hawwe wy op in stuit sels tocht om it út te setten, want hy skriuwt in protte brieven foar elke ferkearswikseling, ynskeakelje, foar elke IP-ferbining, ensafuorthinne . Fansels, as d'r in protte tsjinners binne, dan kinne jo jo sels mei dizze letters oerweldigje. Wy kontrolearje nginx op foto-routers mei standertmetoaden, en hardwaremonitoring is net fuortgien. Wy soene fansels noch twa dingen advisearje: as earste eksterne sûnenskontrôles en beskikberens, want sels as alles wurket, trouwens, miskien krije brûkers miskien gjin foto's fanwege problemen mei eksterne providers of wat komplekser. It is altyd de muoite wurdich om earne op in oar netwurk, yn Amazon of earne oars, in aparte masine te hâlden dy't jo tsjinners fan bûten kin pinge, en it is ek de muoite wurdich om of anomaly-deteksje te brûken, foar dyjingen dy't wite hoe't se lestich masine learen kinne dwaan, as ienfâldige tafersjoch , alteast om te folgjen as oanfragen skerp binne ôfnaam, of, krekt oarsom, tanommen. It kin ek nuttich wêze.
Litte wy gearfetsje: wy hawwe trouwens de izerbeklaaide oplossing, dy't op in stuit net mear by ús past, ferfongen troch in frij ienfâldich systeem dat alles itselde docht, dat wol sizze it beëiniging fan HTTPS-ferkear en fierdere tûke routing leveret mei de needsaaklike sûnenskontrôles. Wy hawwe de stabiliteit fan dit systeem ferhege, dat is, wy hawwe noch in hege beskikberens foar elke laach, plus wy hawwe de bonus dat it frij maklik is om it allegear op elke laach te skaaljen, om't it standert hardware is mei standert software, dat is , wy hawwe ferienfâldige diagnoaze mooglike problemen.
Wat binne wy bedarre mei? Wy hienen in probleem yn de jannewarisfakânsje fan 2018. Yn 'e earste seis moannen wylst wy dit skema yn wurking sette, hawwe wy it útwreide nei alle ferkear om alle ferkear fan LTM te ferwiderjen, wy groeiden allinich yn ferkear yn ien datasintrum fan 40 gigabits nei 60 gigabits, en tagelyk foar it hiele jier 2018 koene hast trije kear mear foto's per sekonde stjoere.
Boarne: www.habr.com