Die moderne web is amper ondenkbaar sonder media-inhoud: byna elke ouma het 'n slimfoon, almal is op sosiale netwerke, en diensstilstand is duur vir maatskappye. Vir u aandag, 'n transkripsie van die maatskappy se storie oor hoe sy die aflewering van foto's met behulp van 'n hardeware-oplossing georganiseer het, watter prestasieprobleme sy in die proses teëgekom het, wat dit veroorsaak het, en hoe hierdie probleme opgelos is met behulp van 'n sagteware-oplossing gebaseer op Nginx, terwyl fouttoleransie op alle vlakke verseker is (). Ons bedank die skrywers van die verhaal Oleg Efimova en Alexandra Dymova, wat hul ervaring by die konferensie gedeel het .
Kom ons begin met 'n klein inleiding oor hoe ons foto's berg en kas. Ons het 'n laag waar ons dit stoor, en 'n laag waar ons die foto's kas. Terselfdertyd, as ons 'n groot truuk wil bereik en die las op die berging wil verminder, is dit vir ons belangrik dat elke foto van 'n individuele gebruiker op een kasbediener lê. Andersins sal ons soveel keer soveel skywe moet installeer as wat ons meer bedieners het. Ons trefkoers is ongeveer 99%, dit wil sê, ons verminder die las op ons berging met 100 keer, en om dit te doen, 10 jaar gelede, toe dit alles gebou is, het ons 50 bedieners gehad. Gevolglik, om hierdie foto's te gee, het ons in werklikheid 50 eksterne domeine nodig gehad wat hierdie bedieners bedien.
Natuurlik het die vraag dadelik ontstaan: as een van ons bedieners afgaan en nie beskikbaar word nie, watter deel van die verkeer verloor ons? Ons het gekyk wat op die mark is en besluit om ’n stuk yster te koop sodat dit al ons probleme sal oplos. Die keuse het geval op die oplossing van die F5-netwerkmaatskappy (wat, terloops, NGINX, Inc nie so lank gelede gekoop het nie): BIG-IP Local Traffic Manager.
Wat hierdie stuk yster (LTM) doen: dit is 'n ysterroeteerder wat ysteroortolligheid van sy eksterne poorte maak en jou toelaat om verkeer te stuur op grond van die netwerktopologie, op sommige instellings, en gesondheidsondersoeke doen. Dit was vir ons belangrik dat hierdie stuk yster geprogrammeer kan word. Gevolglik kan ons die logika beskryf van hoe foto's van 'n sekere gebruiker van 'n spesifieke kas teruggestuur is. Soos wat lyk dit? Daar is 'n stuk hardeware wat na die internet kyk vir een domein, een ip, ssl-aflaai doen, http-versoeke ontleed, 'n kasnommer van IRule kies, waarheen om te gaan, en verkeer daarheen laat gaan. Terselfdertyd doen dit gesondheidsondersoeke, en in die geval van onbeskikbaarheid van 'n masjien, het ons dit so gemaak dat verkeer op daardie tydstip na een rugsteunbediener gegaan het. Vanuit die oogpunt van konfigurasie is daar natuurlik 'n paar nuanses, maar oor die algemeen is alles redelik eenvoudig: ons skryf 'n kaart voor, 'n sekere getal stem ooreen met ons IP op die netwerk, ons sê dat ons op poorte 80 sal luister en 443, ons sê dat as die bediener nie beskikbaar is nie, dan moet jy verkeer na die rugsteun laat gaan, in hierdie geval, die 35ste, en ons beskryf 'n klomp logika hoe hierdie argitektuur uitmekaar gehaal moet word. Die enigste probleem was dat die taal waarin die stuk yster geprogrammeer is, die Tcl-taal is. As iemand dit enigsins onthou ... hierdie taal is meer net skryf as 'n taal wat gerieflik is vir programmering:
Wat het ons gekry? Ons het 'n stuk hardeware gekry wat hoë beskikbaarheid van ons infrastruktuur verseker, al ons verkeer roeteer, gesondheidsondersoeke verskaf en net werk. Boonop werk dit al lank: oor die afgelope 10 jaar was daar geen klagtes daaroor nie. Teen die begin van 2018 het ons reeds sowat 80 80 foto's per sekonde gelewer. Dit is iewers ongeveer XNUMX gigabit se verkeer vanaf albei ons datasentrums.
Tog …
Aan die begin van 2018 het ons 'n lelike prentjie op die kaarte gesien: die tyd om foto's terug te gee het duidelik toegeneem. En dit het opgehou om ons te pas. Die probleem is dat hierdie gedrag net op die hoogtepunt van verkeer sigbaar was - vir ons maatskappy is dit die nag van Sondag tot Maandag. Maar die res van die tyd het die stelsel soos gewoonlik opgetree, geen tekens van breek nie.
Die probleem moes egter opgelos word. Ons het moontlike knelpunte geïdentifiseer en begin om dit uit te skakel. Eerstens het ons natuurlik die eksterne opskakels uitgebrei, 'n volledige hersiening van die interne opskakels uitgevoer en alle moontlike knelpunte gevind. Maar dit alles het nie 'n duidelike resultaat gegee nie, die probleem het nie verdwyn nie.
Nog 'n moontlike bottelnek was die uitvoering van die fotokas self. En ons het besluit dat die probleem dalk op hulle rus. Wel, ons het die werkverrigting uitgebrei - basies netwerkpoorte op fotokas. Maar weereens is geen duidelike verbetering gesien nie. Op die ou end het ons baie aandag gegee aan die werkverrigting van die LTM self, en hier het ons 'n hartseer prentjie op die grafieke gesien: die laai van alle SVE's begin glad verloop, maar lê dan skerp op die rak. Terselfdertyd hou LTM op om voldoende op gesondheidsondersoeke en uplinks te reageer en begin dit lukraak afskakel, wat lei tot ernstige prestasie-agteruitgang.
Dit wil sê, ons het die bron van die probleem geïdentifiseer, die bottelnek geïdentifiseer. Dit bly om te besluit wat ons gaan doen.
Die eerste ooglopende ding wat ons kan doen, is om die LTM self op een of ander manier te moderniseer. Maar daar is 'n paar nuanses hier, want hierdie yster is nogal uniek, jy sal nie na die naaste supermark gaan en dit koop nie. Dit is 'n aparte kontrak, 'n aparte lisensiekontrak, en dit sal baie tyd neem. Die tweede opsie is om vir jouself te begin dink, met jou eie oplossing vorendag te kom oor jou eie komponente, verkieslik deur 'n oopbronprogram te gebruik. Dit bly net om te besluit wat presies ons hiervoor sal kies en hoeveel tyd ons sal spandeer om hierdie probleem op te los, want gebruikers het nie foto's ontvang nie. Daarom is dit nodig om dit alles baie, baie vinnig te doen, kan 'n mens sê - gister.
Aangesien die taak geklink het soos "doen iets so vinnig as moontlik en gebruik die hardeware wat ons het", was die eerste ding wat ons gedink het net om sommige nie die kragtigste masjiene van voor af te verwyder nie, Nginx daar te sit, waarmee ons weet hoe om te werk, en probeer om dieselfde logika te implementeer as wat die stuk yster gebruik het. Dit wil sê, ons het ons stuk hardeware gelos, nog 4 bedieners geïnstalleer wat ons moes konfigureer, eksterne domeine vir hulle gemaak het in analogie met hoe dit 10 jaar gelede was ... Ons het 'n bietjie in beskikbaarheid verloor as hierdie masjiene sou val , maar, nietemin, het die probleem van ons gebruikers plaaslik opgelos.
Gevolglik bly die logika dieselfde: ons installeer Nginx, dit kan SSL-aflaai doen, ons kan op een of ander manier die roeteringslogika programmeer, gesondheidsondersoeke op die konfigurasies en eenvoudig die logika dupliseer wat ons voorheen gehad het.
Ons gaan sit om configs te skryf. Aanvanklik het dit gelyk of alles baie eenvoudig was, maar dit is ongelukkig baie moeilik om handleidings vir elke taak te vind. Daarom raai ons jou nie aan om bloot te google "hoe om Nginx vir foto's in te stel" nie: dit is beter om na die amptelike dokumentasie te verwys, wat sal wys watter instellings aangeraak moet word. Maar dit is beter om self 'n spesifieke parameter te kies. Wel, dan is alles eenvoudig: ons beskryf die bedieners wat ons het, ons beskryf die sertifikate ... Maar die interessantste ding is in werklikheid die roeteringslogika self.
Aanvanklik het dit vir ons gelyk asof ons eenvoudig ons ligging beskryf, ons fotokasnommer daarin pas, met ons hande of 'n kragopwekker beskryf hoeveel stroomop ons benodig, in elke stroomop dui ons die bediener aan waarheen verkeer moet gaan, en die rugsteunbediener - ingeval die hoofbediener nie beskikbaar is nie:
Maar, waarskynlik, as alles so eenvoudig was, sou ons net huis toe gaan en niks vertel nie. Ongelukkig, met die verstekinstellings van Nginx, wat oor die algemeen oor baie jare se ontwikkeling gemaak is en nie heeltemal vir hierdie geval nie ... die konfigurasie lyk soos volg: in die geval dat een of ander stroomop bediener 'n versoekfout of tydverwyderaar het, Nginx altyd skakel verkeer oor na die volgende een. Terselfdertyd, na die eerste mislukking, sal die bediener ook binne 10 sekondes afgeskakel word, beide per ongeluk en deur uitstel - dit kan nie eers op enige manier gekonfigureer word nie. Dit wil sê, as ons die uittelopsie in die stroomop-direktief verwyder of terugstel, sal die bediener afskakel, alhoewel Nginx nie hierdie versoek sal verwerk nie en reageer met een of ander nie-so-goeie fout.
Om dit te vermy, het ons twee dinge gedoen:
a) hulle het Nginx verbied om dit met die hand te doen - en ongelukkig is die enigste manier om dit te doen om eenvoudig die instellings vir maksimum mislukkings te stel.
b) ons het onthou dat ons in ander projekte 'n module gebruik wat jou toelaat om agtergrondgesondheidsondersoeke te doen - dienooreenkomstig het ons redelik gereelde gesondheidsondersoeke gedoen sodat ons minimale stilstand het in geval van 'n ongeluk.
Ongelukkig is dit ook nie al nie, want letterlik het die eerste twee weke van hierdie skema se werking gewys dat TCP-gesondheidsondersoek ook 'n onbetroubare ding is: nie Nginx, of Nginx in die D-toestand kan op die stroomop bediener geloods word nie, en in in hierdie geval sal die kern die verbinding aanvaar, die gesondheidsondersoek sal slaag, maar dit sal nie werk nie. Daarom het ons dit dadelik vervang met http se gesondheidstoets, 'n spesifieke een gemaak, wat, as dit reeds 200 gee, dan werk alles in hierdie skrif. U kan addisionele logika doen - byvoorbeeld, in die geval van kasbedieners, kyk of die lêerstelsel korrek gemonteer is:
En dit sal ons pas, behalwe dat die kring op die oomblik heeltemal herhaal het wat die stuk yster gedoen het. Maar ons wou beter doen. Voorheen het ons een rugsteunbediener gehad, en dit is waarskynlik nie baie goed nie, want as jy honderd bedieners het, is dit onwaarskynlik dat een rugsteunbediener die las sal hanteer wanneer verskeie tegelyk val. Daarom het ons besluit om die bespreking onder alle bedieners te versprei: ons het eenvoudig nog 'n aparte stroomop gemaak, alle bedieners daar aangeteken met sekere parameters in ooreenstemming met watter vrag hulle kan bedien, dieselfde gesondheidsondersoeke bygevoeg as wat ons voorheen gehad het:
Aangesien jy nie na 'n ander stroomop binne een stroomop kan gaan nie, was dit nodig om seker te maak dat as die hoofstroomop, waarin ons bloot die korrekte, nodige fotokas geskryf het, nie beskikbaar was nie, ons eenvoudig na terugval deur error_page gegaan het, van waar ons het na die rugsteun stroomop gegaan:
En deur letterlik vier bedieners by te voeg, het ons dit gekry: ons het 'n deel van die vrag vervang - van LTM na hierdie bedieners verwyder, dieselfde logika daar geïmplementeer met behulp van standaard hardeware en sagteware, het onmiddellik 'n bonus ontvang dat hierdie bedieners geskaal kan word, want hulle kan sit net soveel in as wat jy nodig het. Wel, die enigste negatiewe is dat ons hoë beskikbaarheid vir eksterne gebruikers verloor het. Maar in daardie tyd moes ek dit opoffer, want dit was nodig om die probleem dadelik op te los. So, ons het 'n deel van die vrag verwyder, dit was op daardie tydstip omtrent 40%, LTM het beter geword, en letterlik twee weke nadat die probleem begin het, het ons begin om nie 45k versoeke per sekonde te gee nie, maar 55k. Trouens, ons het met 20% gegroei - dit is duidelik die verkeer wat ons nie aan die gebruiker gegee het nie. En daarna het hulle begin dink oor hoe om die oorblywende probleem op te los - om hoë eksterne beskikbaarheid te verseker.
Ons het 'n pouse gehad waartydens ons bespreek het watter oplossing ons hiervoor sou gebruik. Daar was voorstelle om betroubaarheid met behulp van DNS te verseker, met behulp van 'n paar selfgeskrewe skrifte, dinamiese roeteringsprotokolle ... daar was baie opsies, maar dit het reeds duidelik geword dat vir 'n werklik betroubare terugkeer van foto's, jy 'n ander laag moet instel wat dit sal monitor. Ons het hierdie masjiene fotoregisseurs genoem. Die sagteware waarop ons staatgemaak het, was Keepalived:
Om mee te begin, waaruit Keepalived bestaan. Die eerste is die VRRP-protokol, wyd bekend aan netwerkers, geleë op netwerktoerusting wat fouttoleransie bied vir die eksterne IP-adres waaraan kliënte koppel. Die tweede deel is IPVS, IP virtuele bediener, om te balanseer tussen fotorouters en om fouttoleransie op hierdie vlak te bied. En die derde is gesondheidsondersoeke.
Kom ons begin met die eerste deel: VRRP - hoe lyk dit? Daar is 'n sekere virtuele IP, wat 'n inskrywing in dns badoocdn.com het, waar kliënte verbind. Op 'n sekere tydstip het ons 'n IP-adres op een bediener. Keepalived pakkies loop tussen bedieners deur die VRRP-protokol te gebruik, en as die meester van die radar verdwyn - die bediener het herlaai of iets anders, dan verhoog die rugsteunbediener hierdie IP-adres outomaties - geen handhandelinge is nodig nie. Meester en rugsteun verskil, hoofsaaklik prioriteit: hoe hoër dit is, hoe meer waarskynlik is dit dat die masjien die meester sal word. 'n Baie groot voordeel is dat jy nie IP-adresse op die bediener self hoef op te stel nie, dit is genoeg om dit in die konfigurasie te beskryf, en as die IP-adresse 'n paar pasgemaakte roetereëls benodig, word dit direk in die konfigurasie beskryf, in die dieselfde sintaksis as beskryf in die VRRP-pakket. Jy sal geen onbekende dinge ontmoet nie.
Hoe lyk dit in die praktyk? Wat gebeur as een van die bedieners afgaan? Sodra die meester verdwyn, hou ons rugsteun op om promosies te ontvang en word dit outomaties die meester. Na 'n geruime tyd het ons die meester herstel, herlaai, Keepalived verhoog - advertensies met 'n hoër prioriteit as die rugsteun kom, en die rugsteun draai outomaties terug, verwyder IP-adresse van homself, geen handhandelinge is nodig nie.
Ons het dus die fouttoleransie van die eksterne IP-adres verseker. Die volgende deel is om verkeer op een of ander manier te balanseer van 'n eksterne IP-adres na foto-routers wat dit reeds beëindig. Met balanseringsprotokolle is alles duidelik genoeg. Dit is óf 'n eenvoudige round-robin, óf 'n bietjie meer komplekse dinge, wrr, lysverbinding en so aan. Dit word basies in die dokumentasie beskryf, daar is niks besonders daaraan nie. Maar die afleweringsmetode ... Hier sal ons in meer besonderhede stilstaan - hoekom ons een van hulle gekies het. Dit is NAT, Direct Routing en TUN. Die feit is dat ons onmiddellik die opbrengs van 100 gigabit verkeer vanaf die werwe neergelê het. Dit is as jy dit uitvind, jy benodig 10 gigabit-kaarte, reg? 10 gigabit-kaarte in een bediener - dit is reeds verby, ten minste, ons konsep van "standaard toerusting". En toe onthou ons dat ons nie net 'n bietjie verkeer weggee nie, ons gee foto's weg.
Wat is die kenmerk? - 'n Groot verskil tussen inkomende en uitgaande verkeer. Inkomende verkeer is baie klein, uitgaande verkeer is baie groot:
As jy na hierdie grafieke kyk, kan jy sien dat op die oomblik sowat 200 Mb per sekonde aan die direkteur gestuur word, dit is die mees tipiese dag. Ons gee 4,500 1 MB per sekonde terug, die verhouding is ongeveer 22/22. Dit is reeds duidelik dat vir ons om ten volle uitgaande verkeer aan XNUMX werkende bedieners te verskaf, een genoeg is wat hierdie verbinding aanvaar. Hier kom die direkte roeteringsalgoritme, die roeteringsalgoritme, ons te hulp.
Soos wat lyk dit? Ons fotodirekteur dra volgens sy tabel verbindings oor na fotorouters. Maar foto-routers stuur omgekeerde verkeer direk na die internet, stuur dit na die kliënt, dit gaan nie terug deur die foto-direkteur nie, dus, met 'n minimum aantal masjiene, bied ons volle fouttoleransie en pomp van alle verkeer. In die konfigurasies lyk dit so: ons spesifiseer die algoritme, in ons geval is dit 'n eenvoudige rr, ons verskaf die direkte roeteringsmetode, en dan begin ons al die regte bedieners lys, hoeveel van hulle ons het. Wat hierdie verkeer sal bepaal. In die geval dat ons nog een of twee het, verskeie bedieners wat daar verskyn, ontstaan so 'n behoefte - ons voeg eenvoudig hierdie afdeling by die konfigurasie en moenie te veel bekommer nie. Van die kant van regte bedieners, vanaf die kant van 'n foto-roeteerder, vereis hierdie metode die mees minimale konfigurasie, dit word perfek beskryf in die dokumentasie, en daar is geen slaggate daar nie.
Wat veral aangenaam is, is dat so 'n oplossing nie 'n radikale verandering van die plaaslike netwerk impliseer nie, dit was vir ons belangrik, ons moes dit teen minimale koste oplos. As jy kyk na dan sal ons sien hoe dit lyk. Hier het ons 'n sekere virtuele bediener, op poort 443, luister, aanvaar 'n verbinding, alle werkende bedieners is gelys, en dit is duidelik dat die verbinding, plus of minus, dieselfde is. As ons na die statistieke op dieselfde virtuele bediener kyk, het ons inkomende pakkies, inkomende verbindings, maar absoluut geen uitgaande nie. Uitgaande verbindings gaan direk na die kliënt. Wel, ons het daarin geslaag om te wanbalanseer. Nou, wat gebeur as een van ons foto-routers misluk? Yster is immers yster. Dit kan in 'n pit paniek gaan, dit kan breek, die kragtoevoer kan uitbrand. Enigiets. Dit is waarvoor gesondheidsondersoeke is. Dit kan so eenvoudig wees soos om te kyk hoe die poort by ons oop is, of 'n paar meer ingewikkelde, tot 'n paar selfgeskrewe skrifte wat selfs die besigheidslogika sal kontroleer.
Ons het iewers in die middel gestop: ons het 'n https-versoek vir 'n spesifieke ligging, 'n skrip word geroep as dit met 'n 200ste antwoord reageer, ons glo dat alles goed is met hierdie bediener, dat dit lewendig is en redelik maklik aangeskakel kan word .
Hoe lyk dit weer in die praktyk. Die bediener afgeskakel, toelaatbaar vir instandhouding - flits die BIOS, byvoorbeeld. In die logs het ons dadelik 'n time-out, ons sien die eerste reël, dan word dit na drie pogings gemerk as "misluk", en dit word eenvoudig van die lys verwyder.
'n Tweede gedrag is ook moontlik, wanneer VS bloot op nul gestel is, maar in die geval van die terugstuur van 'n foto, werk dit nie goed nie. Die bediener styg, Nginx begin daar, onmiddellik gesondheidsondersoeke verstaan dat die verbinding deurgaan, dat alles in orde is, en die bediener verskyn in ons lys, en die las begin onmiddellik outomaties daarop toegepas word. Geen handhandelinge word van die diensadministrateur vereis nie. Snags het die bediener herlaai - die moniteringsafdeling bel ons nie snags hieroor nie. Hulle het jou laat weet wat gebeur het, alles is reg.
Dus, op 'n redelik eenvoudige manier, met die hulp van 'n klein aantal bedieners, het ons die probleem van eksterne fouttoleransie opgelos.
Dit bly om te sê dat dit alles natuurlik gemonitor moet word. Afsonderlik moet daarop gelet word dat Keepalivede, as 'n sagteware wat baie lank gelede geskryf is, 'n klomp maniere het om dit te monitor, beide met tjeks via DBus, SMTP, SNMP en standaard Zabbix. Boonop weet hy self hoe om briewe vir byna elke nies te skryf, en om eerlik te wees, het ons op 'n stadium selfs gedink om dit af te skakel, want hy skryf baie briewe vir enige verkeerskakelaar, insluiting, vir elke IP-shnik en so aan. Natuurlik, as daar baie bedieners is, kan jy jouself met hierdie briewe oorstroom. Deur standaardmetodes te gebruik, monitor ons nginx op foto-routers, en hardeware-monitering het nie verdwyn nie. Natuurlik sal ons nog twee dinge aanbeveel: eerstens, eksterne gesondheidsondersoeke en toeganklikheid, want selfs al werk alles, in werklikheid, is dit moontlik dat gebruikers nie foto's ontvang nie as gevolg van probleme met eksterne verskaffers of iets meer kompleks. Dit is altyd die moeite werd om iewers op 'n ander netwerk, in Amazon of iewers anders, 'n aparte masjien te hou wat u bedieners van buite kan ping, en dit is ook die moeite werd om óf anomalie-opsporing te gebruik, vir diegene wat goed is met moeilike masjienleer, óf eenvoudig monitering, ten minste om vas te stel of die versoeke skerp gedaal het, of omgekeerd, gegroei het. Dit is ook nuttig.
Om op te som: ons het in werklikheid die ysteroplossing, wat op 'n stadium nie meer by ons pas nie, vervang het met 'n redelik eenvoudige stelsel wat alles dieselfde doen, dit wil sê dit bied beëindiging van HTTPS-verkeer en verdere slim roetering met die nodige gesondheid -tjeks. Ons het die stabiliteit van hierdie stelsel verhoog, dit wil sê, ons het steeds 'n hoë beskikbaarheid vir elke laag, plus ons het die bonus gekry dat dit redelik maklik is om dit alles op elke laag te skaal, want dit is standaard hardeware met standaard sagteware, dit is , deur dit te doen, het ons onsself vereenvoudig om moontlike probleme te diagnoseer.
Waarmee het ons geëindig? Ons het 'n probleem gehad op die Januarie-vakansie van 2018. Gedurende die eerste ses maande, terwyl ons hierdie skema in werking gestel het en dit na alle verkeer uitgebrei het, om alle verkeer van LTM te verwyder, het ons slegs in verkeer in een datasentrum gegroei van 40 gigabit tot 60 gigabit, en terselfdertyd tyd vir die hele 2018 jaar kon amper drie keer meer foto's per sekonde gee.
Bron: will.com