Det moderne nettet er nesten utenkelig uten medieinnhold: nesten hver bestemor har en smarttelefon, alle er på sosiale nettverk, og nedetid i vedlikehold er kostbart for bedrifter. Her er en utskrift av selskapets historie om hvordan hun organiserte leveringen av bilder ved hjelp av en maskinvareløsning, hvilke ytelsesproblemer hun møtte i prosessen, hva som forårsaket dem, og hvordan disse problemene ble løst ved hjelp av en programvareløsning basert på Nginx, samtidig som hun sikret feiltoleranse på alle nivåer (). Vi takker forfatterne av Olegs historie Efimova og Alexandra Dymova, som delte sin erfaring på konferansen .
— La oss starte med en liten introduksjon om hvordan vi lagrer og cacher bilder. Vi har et lag der vi lagrer dem, og et lag hvor vi cacher bildene. Samtidig, hvis vi ønsker å oppnå en høy triksrate og redusere belastningen på lagring, er det viktig for oss at hvert bilde av en individuell bruker ligger på én caching-server. Ellers må vi installere like mange ganger flere disker som vi har flere servere. Trikset vårt er rundt 99 %, det vil si at vi reduserer belastningen på lagringen vår med 100 ganger, og for å gjøre dette, for 10 år siden, da alt dette ble bygget, hadde vi 50 servere. For å kunne vise disse bildene trengte vi derfor i hovedsak 50 eksterne domener som disse serverne betjener.
Naturligvis oppsto spørsmålet umiddelbart: hvis en av våre servere går ned og blir utilgjengelig, hvilken del av trafikken mister vi? Vi så på hva som var på markedet og bestemte oss for å kjøpe en maskinvare slik at den skulle løse alle problemene våre. Valget falt på løsningen til F5-nettverksselskapet (som forresten nylig kjøpte NGINX, Inc): BIG-IP Local Traffic Manager.
Hva denne maskinvaren (LTM) gjør: det er en jernruter som gjør jernredundans for sine eksterne porter og lar deg rute trafikk basert på nettverkstopologien, på enkelte innstillinger, og utfører helsesjekker. Det var viktig for oss at denne maskinvaren kunne programmeres. Følgelig kan vi beskrive logikken i hvordan fotografier av en spesifikk bruker ble servert fra en spesifikk cache. Hvordan ser det ut? Det er en maskinvare som ser på Internett på ett domene, en IP, laster av ssl, analyserer http-forespørsler, velger et hurtigbuffernummer fra IRule, hvor den skal gå og lar trafikken gå dit. Samtidig gjør den helsesjekker, og i tilfelle en eller annen maskin var utilgjengelig, gjorde vi på den tiden det slik at trafikken gikk til én backupserver. Fra et konfigurasjonssynspunkt er det selvfølgelig noen nyanser, men generelt er alt ganske enkelt: vi registrerer et kort, korrespondanse med et visst nummer til IP-en vår på nettverket, vi sier at vi vil lytte på porter 80 og 443, sier vi at hvis serveren ikke er tilgjengelig, må du sende trafikk til backup-en, i dette tilfellet den 35., og vi beskriver en haug med logikk for hvordan denne arkitekturen skal demonteres. Det eneste problemet var at språket som maskinvaren ble programmert på var Tcl. Hvis noen husker dette i det hele tatt... dette språket er mer skrivebeskyttet enn et språk som er praktisk for programmering:
Hva fikk vi? Vi mottok en maskinvare som sikrer høy tilgjengelighet av infrastrukturen vår, ruter all trafikken vår, gir helsemessige fordeler og bare fungerer. Dessuten fungerer det ganske lenge: i løpet av de siste 10 årene har det ikke vært noen klager på det. I begynnelsen av 2018 sendte vi allerede rundt 80 80 bilder per sekund. Dette er et sted rundt XNUMX gigabit trafikk fra begge datasentrene våre.
Men…
I begynnelsen av 2018 så vi et stygt bilde på listene: tiden det tok å sende bilder hadde klart økt. Og det sluttet å passe oss. Problemet er at denne oppførselen bare var synlig under trafikktopp - for vårt selskap er dette natt fra søndag til mandag. Men resten av tiden oppførte systemet seg som vanlig, ingen tegn til feil.
Likevel måtte problemet løses. Vi identifiserte mulige flaskehalser og begynte å eliminere dem. Først og fremst utvidet vi selvfølgelig eksterne oppkoblinger, gjennomførte en fullstendig revisjon av interne oppkoblinger og fant alle mulige flaskehalser. Men alt dette ga ikke et åpenbart resultat, problemet forsvant ikke.
En annen mulig flaskehals var ytelsen til selve fotocachene. Og vi bestemte oss for at problemet kanskje ligger hos dem. Vel, vi utvidet ytelsen - hovedsakelig nettverksporter på fotocacher. Men igjen ble det ikke sett noen åpenbar forbedring. Til slutt fulgte vi nøye med på ytelsen til selve LTM, og her så vi et trist bilde på grafene: belastningen på alle CPUer begynner å gå jevnt, men kommer plutselig til et platå. Samtidig slutter LTM å svare tilstrekkelig på helsesjekker og oppkoblinger og begynner å slå dem av tilfeldig, noe som fører til alvorlig ytelsesforringelse.
Det vil si at vi har identifisert kilden til problemet, identifisert flaskehalsen. Det gjenstår å bestemme hva vi skal gjøre.
Den første, mest åpenbare tingen vi kan gjøre er å på en eller annen måte modernisere selve LTM. Men det er noen nyanser her, fordi denne maskinvaren er ganske unik, du vil ikke gå til nærmeste supermarked og kjøpe den. Dette er en egen kontrakt, en egen lisenskontrakt, og det vil ta mye tid. Det andre alternativet er å begynne å tenke selv, komme opp med din egen løsning ved å bruke dine egne komponenter, helst ved å bruke et åpen tilgangsprogram. Alt som gjenstår er å bestemme nøyaktig hva vi skal velge for dette og hvor mye tid vi vil bruke på å løse dette problemet, fordi brukerne ikke mottok nok bilder. Derfor må vi gjøre alt dette veldig, veldig raskt, kan man si i går.
Siden oppgaven hørtes ut som "gjør noe så raskt som mulig og bruk maskinvaren vi har," var det første vi tenkte å ganske enkelt fjerne noen ikke veldig kraftige maskiner fra fronten, sette Nginx der, som vi vet hvordan vi arbeid og prøv å implementere all den samme logikken som maskinvaren pleide å gjøre. Det vil si at vi faktisk forlot maskinvaren vår, installerte 4 servere til som vi måtte konfigurere, laget eksterne domener for dem, lik hvordan det var for 10 år siden... Vi mistet litt i tilgjengelighet hvis disse maskinene falt, men enda mindre, de løste problemet med brukerne våre lokalt.
Følgelig forblir logikken den samme: vi installerer Nginx, den kan gjøre SSL-offload, vi kan på en eller annen måte programmere rutinglogikken, helsesjekker i konfigurasjonene og ganske enkelt duplisere logikken vi hadde før.
La oss sette oss ned for å skrive konfigurasjoner. Først så det ut til at alt var veldig enkelt, men dessverre er det veldig vanskelig å finne manualer for hver oppgave. Derfor anbefaler vi ikke bare å google "hvordan konfigurere Nginx for bilder": det er bedre å referere til den offisielle dokumentasjonen, som viser hvilke innstillinger som bør berøres. Men det er bedre å velge den spesifikke parameteren selv. Vel, da er alt enkelt: vi beskriver serverne vi har, vi beskriver sertifikatene... Men det mest interessante er faktisk selve rutingslogikken.
Først virket det for oss som om vi ganske enkelt beskrev plasseringen vår, matchet nummeret på bildebufferen vår i den, brukte hendene eller en generator for å beskrive hvor mange oppstrøms vi trenger, i hver oppstrøm angir vi serveren som trafikken skal til go, og en backupserver - hvis hovedserveren ikke er tilgjengelig:
Men, sannsynligvis, hvis alt var så enkelt, ville vi rett og slett gå hjem og ikke si noe. Dessverre, med standard Nginx-innstillingene, som generelt ble laget over mange års utvikling og ikke er helt egnet for dette tilfellet... ser konfigurasjonen slik ut: hvis en oppstrømsserver har en forespørselsfeil eller tidsavbrudd, vil Nginx alltid bytter trafikk til neste. Dessuten, etter den første feilen, innen 10 sekunder vil serveren også bli slått av, både ved en feiltakelse og ved tidsavbrudd - dette kan ikke engang konfigureres på noen måte. Det vil si at hvis vi fjerner eller tilbakestiller tidsavbruddsalternativet i oppstrømsdirektivet, vil serveren slå seg av, selv om Nginx ikke vil behandle denne forespørselen og vil svare med en ikke særlig god feil.
For å unngå dette gjorde vi to ting:
a) de forbød Nginx å gjøre dette manuelt - og dessverre er den eneste måten å gjøre dette på å stille inn innstillingene for maksimal feil.
b) vi husket at vi i andre prosjekter bruker en modul som lar oss gjøre bakgrunnshelsesjekker - følgelig gjorde vi ganske hyppige helsesjekker slik at nedetiden i tilfelle en ulykke skulle bli minimal.
Dessverre er ikke dette alt heller, for bokstavelig talt viste de to første ukene av driften av denne ordningen at TCP helsesjekk også er en upålitelig ting: på oppstrømsserveren er det kanskje ikke Nginx, eller Nginx i D-tilstand, og i I dette tilfellet vil kjernen godta tilkoblingen, helsesjekk vil passere, men vil ikke fungere. Derfor erstattet vi umiddelbart dette med helsesjekk http, laget en spesifikk, som, hvis den returnerer 200, så fungerer alt i dette skriptet. Du kan gjøre ytterligere logikk - for eksempel, i tilfelle av caching-servere, sjekk at filsystemet er riktig montert:
Og dette ville passe oss, bortsett fra at for øyeblikket gjentok kretsen fullstendig det maskinvaren gjorde. Men vi ville gjøre det bedre. Tidligere hadde vi én backup-server, og dette er nok ikke veldig bra, for hvis du har hundre servere, så når flere feiler på en gang, er det lite sannsynlig at en backup-server takler belastningen. Derfor bestemte vi oss for å distribuere reservasjonen på alle servere: vi gjorde ganske enkelt en annen separat oppstrøms, skrev alle serverne der med visse parametere i samsvar med belastningen de kan betjene, la til de samme helsesjekkene som vi hadde før :
Siden det er umulig å gå til en annen oppstrøms innenfor en oppstrøms, var det nødvendig å sørge for at hvis hovedoppstrøms, der vi bare registrerte riktig, nødvendig bildebuffer, ikke var tilgjengelig, gikk vi ganske enkelt gjennom error_page til fallback, fra hvor vi gikk til sikkerhetskopien oppstrøms:
Og ved å bokstavelig talt legge til fire servere, er dette hva vi fikk: vi erstattet en del av lasten - vi fjernet den fra LTM til disse serverne, implementerte den samme logikken der, ved å bruke standard maskinvare og programvare, og mottok umiddelbart bonusen som disse serverne kan skaleres, fordi de ganske enkelt kan tilføres så mye som nødvendig. Vel, det eneste negative er at vi har mistet høy tilgjengelighet for eksterne brukere. Men i det øyeblikket måtte vi ofre dette, fordi det var nødvendig å løse problemet umiddelbart. Så vi fjernet en del av belastningen, den var omtrent 40 % på den tiden, LTM føltes bra, og bokstavelig talt to uker etter at problemet begynte, begynte vi å sende ikke 45k forespørsler per sekund, men 55k. Faktisk vokste vi med 20 % - dette er helt klart trafikken vi ikke ga brukeren. Og etter det begynte de å tenke på hvordan de skulle løse det gjenværende problemet - for å sikre høy ekstern tilgjengelighet.
Vi hadde en pause, der vi diskuterte hvilken løsning vi ville bruke for dette. Det var forslag for å sikre pålitelighet ved bruk av DNS, bruk av noen hjemmeskrevne skript, dynamiske rutingprotokoller ... det var mange alternativer, men det ble allerede klart at for virkelig pålitelig levering av bilder, må du introdusere et annet lag som vil overvåke dette . Vi kalte disse maskinene fotoregissører. Programvaren vi stolte på var Keepalved:
Til å begynne med, hva består Keepalved av? Den første er VRRP-protokollen, allment kjent for nettverksbrukere, plassert på nettverksutstyr som gir feiltoleranse til den eksterne IP-adressen som klienter kobler seg til. Den andre delen er IPVS, IP virtuell server, for å balansere mellom fotorutere og sikre feiltoleranse på dette nivået. Og for det tredje - helsesjekker.
La oss starte med den første delen: VRRP – hvordan ser det ut? Det er en viss virtuell IP, som har en oppføring i dns badoocdn.com, hvor klienter kobler til. På et tidspunkt har vi en IP-adresse på én server. Keepalive-pakker kjører mellom serverne ved hjelp av VRRP-protokollen, og hvis masteren forsvinner fra radaren - serveren har startet på nytt eller noe annet, så henter backupserveren automatisk denne IP-adressen - ingen manuelle handlinger er nødvendig. Forskjellen mellom master og backup er hovedsakelig prioritert: Jo høyere den er, desto større er sjansen for at maskinen blir en master. En veldig stor fordel er at du ikke trenger å konfigurere IP-adresser på selve serveren, det er nok å beskrive dem i konfigurasjonen, og hvis IP-adressene trenger noen tilpassede rutingsregler, beskrives dette direkte i konfigurasjonen, ved å bruke samme syntaks som beskrevet i VRRP-pakken. Du vil ikke møte noen ukjente ting.
Hvordan ser dette ut i praksis? Hva skjer hvis en av serverne svikter? Så snart masteren forsvinner, slutter backupen vår å motta reklame og blir automatisk en master. Etter en tid reparerte vi masteren, restartet, hevet Keepalived - annonser kommer med høyere prioritet enn sikkerhetskopien, og sikkerhetskopien vender automatisk tilbake, fjerner IP-adresser, ingen manuelle handlinger trenger å gjøres.
Dermed har vi sikret feiltoleransen til den eksterne IP-adressen. Den neste delen er å på en eller annen måte balansere trafikken fra den eksterne IP-adressen til fotoruterne som allerede avslutter den. Alt er ganske klart med balanseprotokollene. Dette er enten en enkel round-robin, eller litt mer komplekse ting, wrr, listeforbindelse og så videre. Dette er i utgangspunktet beskrevet i dokumentasjonen, det er ikke noe spesielt. Men leveringsmetoden... Her skal vi se nærmere på hvorfor vi valgte en av dem. Disse er NAT, Direct Routing og TUN. Faktum er at vi umiddelbart planla å levere 100 gigabit trafikk fra sidene. Hvis du anslår, trenger du 10 gigabit-kort, ikke sant? 10 gigabit-kort på én server er allerede utenfor rammen av, i det minste, konseptet vårt med "standardutstyr". Og så husket vi at vi ikke bare gir bort litt trafikk, vi gir bort bilder.
Hva er spesielt? — Enorme forskjell på innkommende og utgående trafikk. Innkommende trafikk er veldig liten, utgående trafikk er veldig stor:
Hvis du ser på disse grafene, kan du se at for øyeblikket mottar regissøren omtrent 200 MB per sekund, dette er en helt vanlig dag. Vi gir tilbake 4,500 MB per sekund, vårt forhold er omtrent 1/22. Det er allerede klart at for å fullt ut gi utgående trafikk til 22 arbeiderservere, trenger vi bare en som godtar denne tilkoblingen. Det er her den direkte rutingsalgoritmen kommer til hjelp.
Hvordan ser det ut? Vår fotodirektør, ifølge tabellen hans, overfører tilkoblinger til fotorutere. Men fotorutere sender returtrafikk direkte til Internett, sender den til klienten, den går ikke tilbake gjennom fotodirektøren, og med et minimum antall maskiner sikrer vi derfor fullstendig feiltoleranse og pumping av all trafikk. I konfigurasjonene ser det slik ut: vi spesifiserer algoritmen, i vårt tilfelle er det en enkel rr, gir den direkte rutingmetoden og begynner så å liste opp alle de virkelige serverne, hvor mange av dem vi har. Som vil avgjøre denne trafikken. Hvis vi har én eller to flere servere der, eller flere servere, oppstår et slikt behov - vi legger bare til denne delen til konfigurasjonen og bekymrer deg ikke for mye. Fra siden av ekte servere, fra siden av fotoruteren, krever denne metoden den mest minimale konfigurasjonen, den er perfekt beskrevet i dokumentasjonen, og det er ingen fallgruver der.
Det som er spesielt hyggelig er at en slik løsning ikke innebærer en radikal redesign av det lokale nettverket; dette var viktig for oss; vi måtte løse dette med minimale kostnader. Hvis du ser på , så får vi se hvordan det ser ut. Her har vi en viss virtuell server, på port 443, lytter, aksepterer tilkoblingen, alle fungerende servere er oppført, og du kan se at tilkoblingen er, gi eller ta, den samme. Hvis vi ser på statistikken på samme virtuelle server, har vi innkommende pakker, innkommende forbindelser, men absolutt ingen utgående. Utgående forbindelser går direkte til klienten. Ok, vi klarte å ubalanse det. Nå, hva skjer hvis en av våre fotorutere svikter? Tross alt er jern jern. Det kan gå i kjernepanikk, det kan gå i stykker, strømforsyningen kan brenne ut. Hva som helst. Det er derfor helsesjekker er nødvendig. De kan være så enkle som å sjekke hvordan porten er åpen, eller noe mer komplekst, opp til noen hjemmeskrevne skript som til og med vil sjekke forretningslogikken.
Vi stoppet et sted i midten: vi har en https-forespørsel til et bestemt sted, skriptet kalles, hvis det svarer med et svar nummer 200, tror vi at alt er bra med denne serveren, at den er i live og kan slås på ganske Enkelt.
Hvordan ser dette ut i praksis igjen? La oss slå av serveren for vedlikehold - flashing av BIOS, for eksempel. I loggene har vi umiddelbart en timeout, vi ser den første linjen, så etter tre forsøk er den merket som "mislyktes", og den blir ganske enkelt fjernet fra listen.
Et annet atferdsalternativ er også mulig, når VS ganske enkelt er satt til null, men hvis bildet returneres, fungerer ikke dette bra. Serveren kommer opp, Nginx starter der, helsesjekk forstår umiddelbart at tilkoblingen fungerer, at alt er bra, og serveren vises i listen vår, og belastningen begynner umiddelbart å bli brukt på den. Ingen manuelle handlinger kreves fra vaktadministratoren. Serveren startet på nytt om natten - overvåkingsavdelingen ringer oss ikke om dette om natten. De informerer deg om at dette skjedde, alt er i orden.
Så, på en ganske enkel måte, ved hjelp av et lite antall servere, løste vi problemet med ekstern feiltoleranse.
Alt som gjenstår å si er at alt dette selvfølgelig må overvåkes. Separat bør det bemerkes at Keepalivede, som programvare skrevet for lenge siden, har en rekke måter å overvåke det på, både ved å bruke sjekker via DBus, SMTP, SNMP og standard Zabbix. I tillegg vet han selv hvordan han skal skrive bokstaver for nesten hvert nys, og for å være ærlig, på et tidspunkt tenkte vi til og med å slå den av, fordi han skriver mange brev for enhver trafikkbytte, slå på, for hver IP-tilkobling, og så videre. Selvfølgelig, hvis det er mange servere, kan du overvelde deg selv med disse bokstavene. Vi overvåker nginx på fotorutere ved å bruke standardmetoder, og maskinvareovervåking har ikke gått bort. Vi vil selvfølgelig anbefale to ting til: For det første eksterne helsesjekker og tilgjengelighet, for selv om alt fungerer, faktisk, kanskje brukere ikke mottar bilder på grunn av problemer med eksterne leverandører eller noe mer komplekst. Det er alltid verdt å ha et sted på et annet nettverk, i Amazon eller et annet sted, en egen maskin som kan pinge serverne dine fra utsiden, og det er også verdt å bruke enten anomalideteksjon, for de som vet hvordan man gjør vanskelig maskinlæring, eller enkel overvåking , i det minste for å spore om forespørsler har falt kraftig, eller tvert imot, økt. Det kan også være nyttig.
La oss oppsummere: vi erstattet faktisk den jernkledde løsningen, som på et tidspunkt sluttet å passe oss, med et ganske enkelt system som gjør alt det samme, det vil si at det gir terminering av HTTPS-trafikk og videre smart ruting med nødvendige helsesjekker. Vi har økt stabiliteten til dette systemet, det vil si at vi fortsatt har høy tilgjengelighet for hvert lag, pluss at vi har bonusen at det er ganske enkelt å skalere alt på hvert lag, fordi det er standard maskinvare med standard programvare, dvs. , har vi forenklet diagnostisering av mulige problemer.
Hva endte vi opp med? Vi hadde et problem i løpet av januarferien 2018. I de første seks månedene mens vi tok i bruk denne ordningen utvidet vi den til all trafikk for å fjerne all trafikk fra LTM, vi vokste kun i trafikk i ett datasenter fra 40 gigabit til 60 gigabit, og samtidig for hele 2018-året kunne sende nesten tre ganger flere bilder per sekund.
Kilde: www.habr.com