Det moderne web er næsten utænkeligt uden medieindhold: Næsten enhver bedstemor har en smartphone, alle er på sociale netværk, og nedetid i vedligeholdelse er dyrt for virksomheder. Her er en udskrift af virksomhedens historie om hvordan hun organiserede leveringen af fotos ved hjælp af en hardwareløsning, hvilke ydeevneproblemer hun stødte på i processen, hvad der forårsagede dem, og hvordan disse problemer blev løst ved hjælp af en softwareløsning baseret på Nginx, samtidig med at der sikres fejltolerance på alle niveauer (). Vi takker forfatterne af Olegs historie Efimova og Alexandra Dymova, som delte deres erfaringer på konferencen .
— Lad os starte med en lille introduktion om, hvordan vi gemmer og cacher billeder. Vi har et lag, hvor vi gemmer dem, og et lag, hvor vi cacher billederne. På samme tid, hvis vi ønsker at opnå en høj trick rate og reducere belastningen på lager, er det vigtigt for os, at hvert billede af en individuel bruger er på én caching server. Ellers ville vi skulle installere lige så mange gange flere diske, som vi har flere servere. Vores trickrate er omkring 99%, det vil sige, at vi reducerer belastningen på vores lager med 100 gange, og for at gøre dette, for 10 år siden, da alt dette blev bygget, havde vi 50 servere. For at kunne betjene disse billeder havde vi derfor i det væsentlige brug for 50 eksterne domæner, som disse servere betjener.
Spørgsmålet opstod naturligvis straks: Hvis en af vores servere går ned og bliver utilgængelig, hvilken del af trafikken mister vi så? Vi kiggede på, hvad der var på markedet, og besluttede at købe et stykke hardware, så det ville løse alle vores problemer. Valget faldt på løsningen fra F5-netværksfirmaet (som i øvrigt for nylig købte NGINX, Inc): BIG-IP Local Traffic Manager.
Hvad dette stykke hardware (LTM) gør: Det er en jernrouter, der gør jernredundans af sine eksterne porte og giver dig mulighed for at dirigere trafik baseret på netværkstopologien, på nogle indstillinger og udfører sundhedstjek. Det var vigtigt for os, at dette stykke hardware kunne programmeres. Derfor kunne vi beskrive logikken i, hvordan fotografier af en bestemt bruger blev serveret fra en bestemt cache. Hvordan ser det ud? Der er et stykke hardware, der ser på internettet på ét domæne, én IP, udfører ssl-offload, analyserer http-anmodninger, vælger et cachenummer fra IRule, hvor man skal hen og lader trafik gå derhen. Samtidig laver den sundhedstjek, og i tilfælde af at en eller anden maskine var utilgængelig, gjorde vi det på det tidspunkt, at trafikken gik til én backup-server. Fra et konfigurationssynspunkt er der selvfølgelig nogle nuancer, men generelt er alt ret simpelt: vi registrerer et kort, korrespondance af et bestemt nummer til vores IP på netværket, vi siger, at vi vil lytte på porte 80 og 443, siger vi, at hvis serveren ikke er tilgængelig, så skal du sende trafik til backup-en, i dette tilfælde den 35., og vi beskriver en masse logik om, hvordan denne arkitektur skal skilles ad. Det eneste problem var, at det sprog, som hardwaren var programmeret på, var Tcl. Hvis nogen overhovedet husker dette... dette sprog er mere skrivebeskyttet end et sprog, der er praktisk til programmering:
Hvad fik vi? Vi modtog et stykke hardware, der sikrer høj tilgængelighed af vores infrastruktur, dirigerer al vores trafik, giver sundhedsmæssige fordele og bare virker. Desuden virker det i ret lang tid: I løbet af de sidste 10 år har der ikke været nogen klager over det. I begyndelsen af 2018 sendte vi allerede omkring 80 billeder i sekundet. Dette er et sted omkring 80 gigabit trafik fra begge vores datacentre.
Imidlertid…
I begyndelsen af 2018 så vi et grimt billede på hitlisterne: den tid, det tog at sende billeder, var klart steget. Og det holdt op med at passe os. Problemet er, at denne adfærd kun var synlig under spidsbelastningen af trafikken - for vores virksomhed er dette natten fra søndag til mandag. Men resten af tiden opførte systemet sig som normalt, ingen tegn på fejl.
Ikke desto mindre skulle problemet løses. Vi identificerede mulige flaskehalse og begyndte at fjerne dem. Først og fremmest har vi selvfølgelig udvidet eksterne uplinks, gennemført en komplet revision af interne uplinks og fundet alle mulige flaskehalse. Men alt dette gav ikke et åbenlyst resultat, problemet forsvandt ikke.
En anden mulig flaskehals var udførelsen af selve fotocachene. Og vi besluttede, at problemet måske ligger hos dem. Nå, vi udvidede ydeevnen - primært netværksporte på fotocaches. Men igen blev der ikke set nogen tydelig forbedring. Til sidst var vi meget opmærksomme på selve LTM'ens ydeevne, og her så vi et trist billede på graferne: belastningen på alle CPU'er begynder at gå glat, men kommer så pludselig til et plateau. Samtidig holder LTM op med at reagere tilstrækkeligt på sundhedstjek og uplinks og begynder tilfældigt at slå dem fra, hvilket fører til alvorlig forringelse af ydeevnen.
Det vil sige, at vi har identificeret kilden til problemet, identificeret flaskehalsen. Det er tilbage at beslutte, hvad vi vil gøre.
Den første, mest åbenlyse ting, vi kunne gøre, er på en eller anden måde at modernisere selve LTM. Men der er nogle nuancer her, fordi denne hardware er ret unik, du vil ikke gå til det nærmeste supermarked og købe det. Dette er en separat kontrakt, en separat licenskontrakt, og det vil tage meget tid. Den anden mulighed er at begynde at tænke selv, komme med din egen løsning ved hjælp af dine egne komponenter, helst ved hjælp af et open access-program. Det eneste, der er tilbage, er at beslutte, hvad vi præcist vil vælge til dette, og hvor meget tid vi vil bruge på at løse dette problem, fordi brugerne ikke modtog nok billeder. Derfor er vi nødt til at gøre alt dette meget, meget hurtigt, kan man sige i går.
Da opgaven lød som "gør noget så hurtigt som muligt og brug den hardware, vi har," det første, vi tænkte, var simpelthen at fjerne nogle ikke særlig kraftfulde maskiner fra fronten, sætte Nginx der, som vi ved, hvordan man arbejde og prøv at implementere al den samme logik, som hardware plejede at gøre. Det vil sige, at vi faktisk forlod vores hardware, installerede 4 servere mere, som vi skulle konfigurere, oprettede eksterne domæner til dem, svarende til hvordan det var for 10 år siden... Vi mistede lidt i tilgængeligheden, hvis disse maskiner faldt, men endnu mindre, de løste vores brugeres problem lokalt.
Derfor forbliver logikken den samme: vi installerer Nginx, den kan udføre SSL-offload, vi kan på en eller anden måde programmere routinglogikken, sundhedstjek i konfigurationerne og simpelthen duplikere den logik, vi havde før.
Lad os sætte os ned for at skrive konfigurationer. Først så det ud til, at alt var meget enkelt, men desværre er det meget svært at finde manualer til hver opgave. Derfor anbefaler vi ikke blot at google "hvordan man konfigurerer Nginx til billeder": det er bedre at henvise til den officielle dokumentation, som viser, hvilke indstillinger der skal røres. Men det er bedre at vælge den specifikke parameter selv. Nå, så er alt simpelt: vi beskriver de servere, vi har, vi beskriver certifikaterne... Men det mest interessante er faktisk selve routing-logikken.
Først så det ud for os, at vi simpelthen beskrev vores placering, matchede nummeret på vores fotocache i den, brugte vores hænder eller en generator til at beskrive, hvor mange opstrøms vi har brug for, i hver opstrøm angiver vi den server, som trafikken skal til go, og en backup-server - hvis hovedserveren ikke er tilgængelig:
Men sandsynligvis, hvis alt var så enkelt, ville vi simpelthen gå hjem og ikke sige noget. Desværre, med standard Nginx-indstillingerne, som generelt blev lavet over mange års udvikling og ikke er helt egnede til dette tilfælde... ser konfigurationen sådan ud: hvis en opstrømsserver har en anmodningsfejl eller timeout, vil Nginx altid skifter trafik til den næste. Desuden, efter den første fejl, inden for 10 sekunder vil serveren også blive slukket, både ved en fejltagelse og ved timeout - dette kan ikke engang konfigureres på nogen måde. Det vil sige, at hvis vi fjerner eller nulstiller timeout-muligheden i upstream-direktivet, vil serveren lukke ned, selvom Nginx ikke behandler denne anmodning og vil svare med en ikke særlig god fejl.
For at undgå dette gjorde vi to ting:
a) de forbød Nginx at gøre dette manuelt - og desværre er den eneste måde at gøre dette på blot ved at indstille indstillingerne for max fejl.
b) vi huskede, at vi i andre projekter bruger et modul, der giver os mulighed for at lave baggrundssundhedstjek - derfor lavede vi ret hyppige sundhedstjek, så nedetiden i tilfælde af en ulykke ville være minimal.
Desværre er dette heller ikke alt, for bogstaveligt talt viste de første to ugers drift af denne ordning, at TCP-sundhedstjek også er en upålidelig ting: på opstrømsserveren er det muligvis ikke Nginx eller Nginx i D-tilstand, og i I dette tilfælde vil kernen acceptere forbindelsen, sundhedstjekket vil bestå, men vil ikke fungere. Derfor erstattede vi straks denne med sundhedstjek http, lavede en specifik, som, hvis den returnerer 200, så virker alt i dette script. Du kan lave yderligere logik - for eksempel, i tilfælde af cacheservere, skal du kontrollere, at filsystemet er monteret korrekt:
Og dette ville passe os, bortset fra at i øjeblikket gentog kredsløbet fuldstændig, hvad hardwaren gjorde. Men vi ville gerne gøre det bedre. Tidligere havde vi én backup-server, og det er nok ikke særlig godt, for hvis du har hundrede servere, så når flere fejler på én gang, er det usandsynligt, at én backup-server kan klare belastningen. Derfor besluttede vi at distribuere reservationen på tværs af alle servere: vi lavede simpelthen en anden separat upstream, skrev alle serverne der med visse parametre i overensstemmelse med den belastning, de kan betjene, tilføjede de samme sundhedstjek, som vi havde før:
Da det er umuligt at gå til en anden opstrøms inden for en opstrøms, var det nødvendigt at sikre, at hvis hovedopstrøms, hvor vi blot registrerede den korrekte, nødvendige fotocache, ikke var tilgængelig, gik vi simpelthen igennem fejlsiden til fallback, fra hvor vi gik til backup opstrøms:
Og ved bogstaveligt talt at tilføje fire servere, er dette, hvad vi fik: vi erstattede en del af belastningen - vi fjernede den fra LTM til disse servere, implementerede den samme logik der ved at bruge standard hardware og software og modtog straks den bonus, som disse servere kan skaleres, fordi de ganske enkelt kan levere så meget som nødvendigt. Nå, det eneste negative er, at vi har mistet høj tilgængelighed for eksterne brugere. Men i det øjeblik måtte vi ofre dette, for det var nødvendigt at løse problemet med det samme. Så vi fjernede en del af belastningen, det var omkring 40 % på det tidspunkt, LTM føltes godt, og bogstaveligt talt to uger efter problemet begyndte, begyndte vi at sende ikke 45 anmodninger i sekundet, men 55. Faktisk voksede vi med 20% - det er helt klart den trafik, som vi ikke gav til brugeren. Og efter det begyndte de at tænke på, hvordan man løser det resterende problem - for at sikre høj ekstern tilgængelighed.
Vi havde en pause, hvor vi diskuterede, hvilken løsning vi ville bruge til dette. Der var forslag til at sikre pålidelighed ved hjælp af DNS, ved hjælp af nogle hjemmeskrevne scripts, dynamiske routingprotokoller... der var mange muligheder, men det blev allerede klart, at for virkelig pålidelig levering af billeder, skal du introducere et andet lag, der vil overvåge dette . Vi kaldte disse maskiner fotodirektører. Den software, vi stolede på, var Keepalved:
Til at begynde med, hvad består Keepalved af? Den første er VRRP-protokollen, der er almindeligt kendt af netværkere, placeret på netværksudstyr, der giver fejltolerance over for den eksterne IP-adresse, som klienter forbinder til. Den anden del er IPVS, IP virtuel server, til balancering mellem fotoroutere og sikring af fejltolerance på dette niveau. Og for det tredje - sundhedstjek.
Lad os starte med første del: VRRP – hvordan ser det ud? Der er en vis virtuel IP, som har en indgang i dns badoocdn.com, hvor klienter forbinder. På et tidspunkt har vi en IP-adresse på én server. Keepalive-pakker kører mellem serverne ved hjælp af VRRP-protokollen, og hvis masteren forsvinder fra radaren - serveren er genstartet eller noget andet, så henter backup-serveren automatisk denne IP-adresse - ingen manuelle handlinger er påkrævet. Forskellen mellem master og backup er primært prioriteret: Jo højere den er, jo større er chancen for, at maskinen bliver en master. En meget stor fordel er, at du ikke behøver at konfigurere IP-adresser på selve serveren, det er nok at beskrive dem i konfigurationen, og hvis IP-adresserne har brug for nogle brugerdefinerede routing-regler, beskrives dette direkte i konfigurationen, vha. samme syntaks som beskrevet i VRRP-pakken. Du vil ikke støde på nogen ukendte ting.
Hvordan ser det ud i praksis? Hvad sker der, hvis en af serverne fejler? Så snart masteren forsvinder, stopper vores backup med at modtage reklamer og bliver automatisk en master. Efter nogen tid reparerede vi masteren, genstartede, hævede Keepalived - annoncer ankommer med en højere prioritet end sikkerhedskopien, og sikkerhedskopien vender automatisk tilbage, fjerner IP-adresser, ingen manuelle handlinger skal udføres.
Dermed har vi sikret den eksterne IP-adresses fejltolerance. Den næste del er på en eller anden måde at balancere trafikken fra den eksterne IP-adresse til de fotoroutere, der allerede afslutter den. Alt er helt klart med balanceringsprotokollerne. Dette er enten en simpel round-robin eller lidt mere komplekse ting, wrr, listeforbindelse og så videre. Dette er grundlæggende beskrevet i dokumentationen, der er ikke noget særligt. Men leveringsmetoden... Her skal vi se nærmere på, hvorfor vi valgte en af dem. Disse er NAT, Direct Routing og TUN. Faktum er, at vi straks planlagde at levere 100 gigabit trafik fra webstederne. Hvis du anslår, har du brug for 10 gigabit-kort, ikke? 10 gigabit-kort på én server er allerede uden for rammerne af i det mindste vores koncept med "standardudstyr". Og så huskede vi, at vi ikke bare giver noget trafik væk, vi giver billeder væk.
Hvad er specielt? — Enorme forskel mellem indgående og udgående trafik. Indgående trafik er meget lille, udgående trafik er meget stor:
Hvis man ser på disse grafer, kan man se, at i øjeblikket modtager instruktøren omkring 200 MB i sekundet, det er en ganske almindelig dag. Vi giver 4,500 MB tilbage i sekundet, vores forhold er cirka 1/22. Det er allerede klart, at for fuldt ud at levere udgående trafik til 22 arbejderservere, behøver vi kun én, der accepterer denne forbindelse. Det er her, den direkte routing-algoritme kommer os til hjælp.
Hvordan ser det ud? Vores fotodirektør sender ifølge hans tabel forbindelser til fotoroutere. Men fotoroutere sender returtrafik direkte til internettet, sender den til klienten, den går ikke tilbage gennem fotodirektøren, så vi sikrer med et minimum antal maskiner fuldstændig fejltolerance og pumpning af al trafik. I konfigurationerne ser det sådan ud: vi specificerer algoritmen, i vores tilfælde er det en simpel rr, giver den direkte routingmetode og begynder derefter at liste alle de rigtige servere, hvor mange af dem vi har. Hvilket vil bestemme denne trafik. Hvis vi har en eller to servere mere der, eller flere servere, opstår et sådant behov - vi tilføjer bare denne sektion til konfigurationen og bekymrer os ikke for meget. Fra siden af rigtige servere, fra siden af fotorouteren, kræver denne metode den mest minimale konfiguration, den er perfekt beskrevet i dokumentationen, og der er ingen faldgruber der.
Det, der især er rart, er, at en sådan løsning ikke indebærer en radikal redesign af det lokale netværk; dette var vigtigt for os; vi skulle løse dette med minimale omkostninger. Hvis man ser på , så får vi se hvordan det ser ud. Her har vi en vis virtuel server, på port 443, lytter, accepterer forbindelsen, alle fungerende servere er listet, og du kan se, at forbindelsen er, giv eller tag, den samme. Hvis vi ser på statistikken på den samme virtuelle server, har vi indgående pakker, indgående forbindelser, men absolut ingen udgående. Udgående forbindelser går direkte til klienten. Okay, vi var i stand til at ubalancere det. Hvad sker der nu, hvis en af vores fotoroutere fejler? Jern er jo jern. Det kan gå i kernepanik, det kan gå i stykker, strømforsyningen kan brænde ud. Hvad som helst. Det er derfor, der er behov for sundhedstjek. De kan være så enkle som at tjekke, hvordan porten er åben, eller noget mere komplekst, op til nogle hjemmeskrevne scripts, der endda vil tjekke forretningslogikken.
Vi stoppede et sted i midten: vi har en https-anmodning til en bestemt placering, scriptet kaldes, hvis det svarer med et svar nummer 200, tror vi, at alt er i orden med denne server, at den er i live og kan tændes ganske let.
Hvordan ser det igen ud i praksis? Lad os slukke for serveren for vedligeholdelse - flashing af BIOS, for eksempel. I loggene har vi straks en timeout, vi ser den første linje, så efter tre forsøg er den markeret som "mislykket", og den fjernes simpelthen fra listen.
En anden adfærdsmulighed er også mulig, når VS blot er sat til nul, men hvis billedet returneres, fungerer dette ikke godt. Serveren kommer op, Nginx starter der, sundhedstjek forstår straks, at forbindelsen fungerer, at alt er i orden, og serveren vises på vores liste, og belastningen begynder straks at blive påført den. Der kræves ingen manuelle handlinger fra vagtadministratoren. Serveren genstartede om natten - overvågningsafdelingen ringer ikke til os om dette om natten. De informerer dig om, at dette skete, alt er i orden.
Så på en ret simpel måde, ved hjælp af et lille antal servere, løste vi problemet med ekstern fejltolerance.
Det eneste, der skal siges, er, at alt dette selvfølgelig skal overvåges. Separat skal det bemærkes, at Keepalivede, som software skrevet for længe siden, har en masse måder at overvåge det på, både ved hjælp af checks via DBus, SMTP, SNMP og standard Zabbix. Plus, han ved selv, hvordan man skriver bogstaver for næsten hvert nys, og for at være ærlig, på et tidspunkt tænkte vi endda på at slå det fra, fordi han skriver en masse breve for enhver trafik, der skifter, tænder, for hver IP-forbindelse, og så videre . Selvfølgelig, hvis der er mange servere, så kan du overvælde dig selv med disse bogstaver. Vi overvåger nginx på fotoroutere ved hjælp af standardmetoder, og hardwareovervågning er ikke forsvundet. Vi vil selvfølgelig råde dig til to ting mere: For det første eksterne sundhedstjek og tilgængelighed, for selvom alt fungerer, modtager brugerne faktisk ikke billeder på grund af problemer med eksterne udbydere eller noget mere komplekst. Det er altid værd at holde et sted på et andet netværk, i Amazon eller et andet sted, en separat maskine, der kan pinge dine servere udefra, og det er også værd at bruge enten anomalidetektion for dem, der ved, hvordan man laver vanskelig maskinlæring eller simpel overvågning , i det mindste for at spore, om anmodningerne er faldet kraftigt, eller tværtimod er steget. Det kan også være nyttigt.
Lad os opsummere: vi har faktisk erstattet den jernbeklædte løsning, som på et tidspunkt holdt op med at passe os, med et ret simpelt system, der gør alt det samme, det vil sige, at det giver terminering af HTTPS-trafik og yderligere smart routing med nødvendige sundhedstjek. Vi har øget stabiliteten af dette system, det vil sige, at vi stadig har høj tilgængelighed for hvert lag, plus vi har den bonus, at det er ret nemt at skalere det hele på hvert lag, fordi det er standard hardware med standard software, dvs. , har vi forenklet diagnosticering af mulige problemer.
Hvad endte vi med? Vi havde et problem i januarferien 2018. I de første seks måneder, mens vi satte denne ordning i drift, udvidede vi den til al trafik for at fjerne al trafik fra LTM, vi voksede kun i trafikken i ét datacenter fra 40 gigabit til 60 gigabit, og samtidig for hele 2018-året kunne sende næsten tre gange flere billeder i sekundet.
Kilde: www.habr.com