Het moderne internet is bijna ondenkbaar zonder media-inhoud: bijna elke grootmoeder heeft een smartphone, iedereen zit op sociale netwerken en stilstand in onderhoud is kostbaar voor bedrijven. Hier is een transcriptie van het verhaal van het bedrijf over hoe ze de levering van foto's organiseerde met behulp van een hardware-oplossing, welke prestatieproblemen ze daarbij tegenkwam, wat de oorzaak ervan was, en hoe deze problemen werden opgelost met behulp van een software-oplossing gebaseerd op Nginx, terwijl fouttolerantie op alle niveaus werd gewaarborgd (). Wij danken de auteurs van het verhaal van Oleg Efimova en Alexandra Dymova, die hun ervaringen op de conferentie deelden .
— Laten we beginnen met een korte introductie over hoe we foto's opslaan en in het cachegeheugen opslaan. We hebben een laag waarin we ze opslaan, en een laag waarin we de foto's in de cache opslaan. Als we tegelijkertijd een hoog trucpercentage willen bereiken en de belasting van de opslag willen verminderen, is het voor ons belangrijk dat elke foto van een individuele gebruiker op één cachingserver staat. Anders zouden we evenveel schijven moeten installeren als we meer servers hebben. Ons trucpercentage ligt rond de 99%, dat wil zeggen dat we de belasting van onze opslag met 100 keer verminderen. Om dit te kunnen doen, hadden we 10 jaar geleden, toen dit allemaal werd gebouwd, 50 servers. Om deze foto's te kunnen aanbieden, hadden we dus in wezen 50 externe domeinen nodig die deze servers bedienen.
Uiteraard rees meteen de vraag: als een van onze servers uitvalt en niet meer beschikbaar is, welk deel van het verkeer verliezen we dan? We keken naar wat er op de markt was en besloten een stuk hardware te kopen, zodat het al onze problemen zou oplossen. De keuze viel op de oplossing van het F5-netwerkbedrijf (dat trouwens onlangs NGINX, Inc kocht): BIG-IP Local Traffic Manager.
Wat dit stuk hardware (LTM) doet: het is een ijzeren router die ijzeren redundantie van zijn externe poorten maakt en u in staat stelt verkeer te routeren op basis van de netwerktopologie en bepaalde instellingen, en voert gezondheidscontroles uit. Voor ons was het belangrijk dat dit stukje hardware geprogrammeerd kon worden. Dienovereenkomstig zouden we de logica kunnen beschrijven van hoe foto's van een specifieke gebruiker vanuit een specifieke cache worden aangeboden. Hoe ziet het eruit? Er is een stuk hardware dat naar internet kijkt op één domein, één IP, SSL-offload doet, http-verzoeken parseert, een cachenummer uit IRule selecteert, waar het naartoe moet gaan, en verkeer daarheen laat gaan. Tegelijkertijd worden er gezondheidscontroles uitgevoerd, en in het geval dat een machine niet beschikbaar was, hebben we er destijds voor gezorgd dat het verkeer naar één back-upserver ging. Vanuit configuratieoogpunt zijn er natuurlijk enkele nuances, maar over het algemeen is alles vrij eenvoudig: we registreren een kaart, correspondentie van een bepaald nummer met ons IP-adres op het netwerk, we zeggen dat we zullen luisteren op poort 80 en 443 zeggen we dat als de server niet beschikbaar is, je verkeer naar de back-upserver moet sturen, in dit geval de 35e, en we beschrijven een aantal logica over hoe deze architectuur moet worden gedemonteerd. Het enige probleem was dat de taal waarin de hardware was geprogrammeerd Tcl was. Als iemand zich dit überhaupt herinnert... deze taal is meer alleen-schrijven dan een taal die handig is om te programmeren:
Wat hebben we gekregen? We hebben een stuk hardware ontvangen dat een hoge beschikbaarheid van onze infrastructuur garandeert, al ons verkeer routeert, gezondheidsvoordelen biedt en gewoon werkt. Bovendien werkt het behoorlijk lang: de afgelopen 10 jaar zijn er geen klachten over geweest. Begin 2018 stuurden we al ongeveer 80 foto's per seconde. Dit is ongeveer 80 gigabit aan verkeer vanuit onze beide datacenters.
Echter…
Begin 2018 zagen we een lelijk beeld op de hitlijsten: de tijd die nodig was om foto’s te sturen was duidelijk toegenomen. En het paste niet meer bij ons. Het probleem is dat dit gedrag alleen zichtbaar was tijdens de piek van het verkeer - voor ons bedrijf is dit de nacht van zondag op maandag. Maar de rest van de tijd gedroeg het systeem zich zoals gewoonlijk, zonder tekenen van falen.
Toch moest het probleem opgelost worden. We hebben mogelijke knelpunten geïdentificeerd en zijn begonnen deze weg te nemen. Allereerst hebben we natuurlijk de externe uplinks uitgebreid, een volledige audit van de interne uplinks uitgevoerd en alle mogelijke knelpunten gevonden. Maar dit alles leverde geen duidelijk resultaat op, het probleem verdween niet.
Een ander mogelijk knelpunt waren de prestaties van de fotocaches zelf. En we besloten dat het probleem misschien bij hen lag. Welnu, we hebben de prestaties uitgebreid - voornamelijk netwerkpoorten op fotocaches. Maar opnieuw werd er geen duidelijke verbetering gezien. Uiteindelijk hebben we goed gelet op de prestaties van de LTM zelf, en hier zagen we een treurig beeld in de grafieken: de belasting van alle CPU's begint soepel te verlopen, maar bereikt dan plotseling een plateau. Tegelijkertijd reageert LTM niet meer adequaat op gezondheidscontroles en uplinks en begint deze willekeurig uit te schakelen, wat tot ernstige prestatievermindering leidt.
Dat wil zeggen: we hebben de oorzaak van het probleem geïdentificeerd, het knelpunt geïdentificeerd. Het blijft de vraag wat we zullen doen.
Het eerste, meest voor de hand liggende wat we kunnen doen, is het LTM zelf op de een of andere manier moderniseren. Maar er zijn hier enkele nuances, omdat deze hardware vrij uniek is, je gaat niet naar de dichtstbijzijnde supermarkt om deze te kopen. Dit is een afzonderlijk contract, een afzonderlijk licentiecontract, en het zal veel tijd in beslag nemen. De tweede optie is om zelf te gaan nadenken, met je eigen componenten een eigen oplossing te bedenken, bij voorkeur met een open access programma. Het enige dat overblijft is om te beslissen wat we hiervoor precies zullen kiezen en hoeveel tijd we zullen besteden aan het oplossen van dit probleem, omdat gebruikers niet genoeg foto's ontvingen. Daarom moeten we dit allemaal heel, heel snel doen, zou je gisteren kunnen zeggen.
Omdat de taak klonk als "zo snel mogelijk iets doen en de hardware gebruiken die we hebben", dachten we eerst dat we simpelweg een aantal niet erg krachtige machines van de voorkant moesten verwijderen en daar Nginx moesten plaatsen, waarmee we weten hoe we moeten werk en probeer dezelfde logica te implementeren die hardware vroeger deed. Dat wil zeggen dat we in feite onze hardware hebben achtergelaten, nog 4 servers hebben geïnstalleerd die we moesten configureren, er externe domeinen voor hebben gemaakt, vergelijkbaar met hoe het 10 jaar geleden was... We verloren een beetje aan beschikbaarheid als deze machines vielen, maar nog minder, ze hebben het probleem van onze gebruikers lokaal opgelost.
Dienovereenkomstig blijft de logica hetzelfde: we installeren Nginx, het kan SSL-offload uitvoeren, we kunnen op de een of andere manier de routeringslogica programmeren, gezondheidscontroles in de configuraties uitvoeren en eenvoudigweg de logica dupliceren die we eerder hadden.
Laten we gaan zitten om configuraties te schrijven. In eerste instantie leek het erop dat alles heel eenvoudig was, maar helaas is het erg moeilijk om voor elke taak handleidingen te vinden. Daarom raden we niet aan om simpelweg te googlen “hoe Nginx voor foto’s te configureren”: het is beter om de officiële documentatie te raadplegen, die laat zien welke instellingen moeten worden aangeraakt. Maar het is beter om zelf de specifieke parameter te kiezen. Nou, dan is alles eenvoudig: we beschrijven de servers die we hebben, we beschrijven de certificaten... Maar het meest interessante is eigenlijk de routeringslogica zelf.
In eerste instantie leek het ons dat we eenvoudigweg onze locatie beschreven, overeenkomend met het nummer van onze fotocache daarin, met behulp van onze handen of een generator om te beschrijven hoeveel upstreams we nodig hebben, in elke upstream geven we de server aan waarnaar het verkeer moet gaan go, en een back-upserver - als de hoofdserver niet beschikbaar is:
Maar als alles zo eenvoudig was, zouden we waarschijnlijk gewoon naar huis gaan en niets zeggen. Helaas, met de standaard Nginx-instellingen, die over het algemeen gedurende vele jaren van ontwikkeling zijn gemaakt en niet helemaal geschikt zijn voor dit geval... ziet de configuratie er als volgt uit: als een upstream-server een verzoekfout of time-out heeft, zal Nginx altijd schakelt het verkeer naar de volgende. Bovendien wordt na de eerste storing binnen 10 seconden de server ook uitgeschakeld, zowel per ongeluk als door een time-out - dit kan op geen enkele manier worden geconfigureerd. Dat wil zeggen, als we de time-outoptie in de upstream-richtlijn verwijderen of opnieuw instellen, wordt de server uitgeschakeld, hoewel Nginx dit verzoek niet zal verwerken en zal reageren met een niet erg goede fout.
Om dit te voorkomen hebben we twee dingen gedaan:
a) ze verboden Nginx om dit handmatig te doen - en helaas is de enige manier om dit te doen het eenvoudigweg instellen van de maximale mislukte instellingen.
b) we herinnerden ons dat we in andere projecten een module gebruiken waarmee we achtergrondgezondheidscontroles kunnen uitvoeren. Daarom hebben we vrij frequent gezondheidscontroles uitgevoerd, zodat de uitvaltijd bij een ongeval minimaal zou zijn.
Helaas is dit nog niet alles, want letterlijk uit de eerste twee weken dat dit schema in werking was, bleek dat TCP-gezondheidscontrole ook een onbetrouwbaar iets is: op de upstream-server is het misschien niet Nginx, of Nginx in D-status, en in in dit geval zal de kernel de verbinding accepteren, de gezondheidscontrole zal slagen, maar zal niet werken. Daarom hebben we dit onmiddellijk vervangen door health-check http, en een specifieke gemaakt, die, als deze 200 retourneert, alles in dit script werkt. U kunt extra logica toepassen - controleer bijvoorbeeld in het geval van caching-servers of het bestandssysteem correct is aangekoppeld:
En dit zou ons goed uitkomen, behalve dat het circuit op dit moment volledig herhaalde wat de hardware deed. Maar wij wilden het beter doen. Voorheen hadden we één back-upserver, en dit is waarschijnlijk niet erg goed, want als je honderd servers hebt, is het onwaarschijnlijk dat één back-upserver de belasting aankan als er meerdere tegelijk uitvallen. Daarom hebben we besloten om de reservering over alle servers te verdelen: we hebben eenvoudigweg nog een aparte upstream gemaakt, alle servers daar geschreven met bepaalde parameters in overeenstemming met de belasting die ze kunnen bedienen, en dezelfde gezondheidscontroles toegevoegd die we eerder hadden:
Omdat het onmogelijk is om binnen één stroomopwaarts naar een andere stroomopwaarts te gaan, was het noodzakelijk om ervoor te zorgen dat als de hoofdstroomopwaarts, waarin we eenvoudigweg de juiste, noodzakelijke fotocache hadden vastgelegd, niet beschikbaar was, we eenvoudigweg door de error_page gingen om terug te vallen, van waar we stroomopwaarts naar de back-up gingen:
En door letterlijk vier servers toe te voegen, hebben we dit gekregen: we hebben een deel van de belasting vervangen - we hebben het van LTM naar deze servers verwijderd, daar dezelfde logica geïmplementeerd, met behulp van standaardhardware en -software, en onmiddellijk de bonus ontvangen die deze servers kunnen worden geschaald, omdat ze eenvoudigweg zoveel kunnen leveren als nodig is. Het enige negatieve is dat we de hoge beschikbaarheid voor externe gebruikers hebben verloren. Maar op dat moment moesten we dit opofferen, omdat het nodig was om het probleem onmiddellijk op te lossen. Dus we hebben een deel van de belasting verwijderd, het was toen ongeveer 40%, LTM voelde goed, en letterlijk twee weken nadat het probleem begon, begonnen we niet 45 verzoeken per seconde te verzenden, maar 55. We zijn zelfs met 20% gegroeid - dit is duidelijk het verkeer dat we niet aan de gebruiker hebben gegeven. En daarna begonnen ze na te denken over hoe ze het resterende probleem konden oplossen - om een hoge externe toegankelijkheid te garanderen.
We hadden een pauze waarin we bespraken welke oplossing we hiervoor zouden gebruiken. Er waren voorstellen om de betrouwbaarheid te garanderen met behulp van DNS, met behulp van enkele zelfgeschreven scripts, dynamische routeringsprotocollen... er waren veel opties, maar het werd al duidelijk dat je voor een echt betrouwbare levering van foto's een andere laag moet introduceren die dit zal monitoren . We noemden deze machines fotoregisseurs. De software waar we op vertrouwden was Keepalived:
Om te beginnen: waar bestaat Keepalived uit? Het eerste is het VRRP-protocol, algemeen bekend bij netwerkers, dat zich op netwerkapparatuur bevindt en fouttolerantie biedt voor het externe IP-adres waarmee clients verbinding maken. Het tweede deel is IPVS, een virtuele IP-server, voor het balanceren tussen fotorouters en het garanderen van fouttolerantie op dit niveau. En ten derde - gezondheidscontroles.
Laten we beginnen met het eerste deel: VRRP - hoe ziet het eruit? Er is een bepaald virtueel IP-adres, dat een vermelding heeft in de dns badoocdn.com, waar clients verbinding mee maken. Op een gegeven moment hebben we een IP-adres op één server. Keepalived-pakketten worden tussen de servers uitgevoerd met behulp van het VRRP-protocol, en als de master van de radar verdwijnt (de server is opnieuw opgestart of iets anders), dan pikt de back-upserver dit IP-adres automatisch op - er zijn geen handmatige acties vereist. Het verschil tussen master en backup heeft vooral prioriteit: hoe hoger het is, hoe groter de kans dat de machine een master wordt. Een heel groot voordeel is dat je geen IP-adressen op de server zelf hoeft te configureren; het is voldoende om ze in de configuratie te beschrijven, en als de IP-adressen aangepaste routeringsregels nodig hebben, wordt dit direct in de configuratie beschreven, met behulp van de dezelfde syntaxis als beschreven in het VRRP-pakket. Je zult geen onbekende dingen tegenkomen.
Hoe ziet dit er in de praktijk uit? Wat gebeurt er als een van de servers uitvalt? Zodra de master verdwijnt, ontvangt onze back-up geen advertenties meer en wordt hij automatisch een master. Na een tijdje hebben we de master gerepareerd, opnieuw opgestart, Keepalived verhoogd - advertenties komen met een hogere prioriteit aan dan de back-up, en de back-up keert automatisch terug, verwijdert IP-adressen, er hoeven geen handmatige acties te worden uitgevoerd.
Zo hebben we de fouttolerantie van het externe IP-adres gegarandeerd. Het volgende deel is om op de een of andere manier het verkeer van het externe IP-adres te balanceren naar de fotorouters die het al beëindigen. Alles is vrij duidelijk met de balanceringsprotocollen. Dit is een eenvoudige round-robin, of iets complexere dingen, wrr, lijstverbinding enzovoort. Dit wordt in principe beschreven in de documentatie, er is niets bijzonders. Maar de bezorgmethode... Hier gaan we dieper in op waarom we voor een van hen hebben gekozen. Dit zijn NAT, Direct Routing en TUN. Feit is dat we meteen van plan waren om 100 gigabit verkeer vanaf de sites te genereren. Als je schat dat je 10 gigabitkaarten nodig hebt, toch? 10 gigabitkaarten in één server vallen al buiten het bereik van, althans, ons concept van “standaarduitrusting”. En toen bedachten we dat we niet alleen wat verkeer weggeven, maar ook foto's.
Wat is er speciaal? — Enorm verschil tussen inkomend en uitgaand verkeer. Het inkomend verkeer is erg klein, het uitgaand verkeer is erg groot:
Als je naar deze grafieken kijkt, zie je dat op het moment dat de regisseur ongeveer 200 MB per seconde ontvangt, dit een heel gewone dag is. Wij geven 4,500 MB per seconde terug, onze verhouding is ongeveer 1/22. Het is al duidelijk dat we, om uitgaand verkeer volledig naar 22 werkservers te kunnen bieden, er maar één nodig hebben die deze verbinding accepteert. Dit is waar het directe routeringsalgoritme ons te hulp komt.
Hoe ziet het eruit? Onze fotoregisseur verzendt volgens zijn tabel verbindingen naar fotorouters. Maar fotorouters sturen retourverkeer rechtstreeks naar internet en sturen het naar de klant, het gaat niet terug via de fotoregisseur, dus met een minimum aantal machines zorgen we voor volledige fouttolerantie en het pompen van al het verkeer. In de configuraties ziet het er als volgt uit: we specificeren het algoritme, in ons geval is het een eenvoudige rr, geven de directe routeringsmethode op en beginnen dan alle echte servers op te sommen, hoeveel we er hebben. Dat zal dit verkeer bepalen. Als we daar nog een of twee servers hebben, of meerdere servers, ontstaat een dergelijke behoefte - we voegen deze sectie gewoon toe aan de configuratie en maken ons niet al te veel zorgen. Van de kant van echte servers, van de kant van de fotorouter, vereist deze methode de meest minimale configuratie, deze wordt perfect beschreven in de documentatie en er zijn geen valkuilen.
Wat vooral leuk is, is dat zo’n oplossing geen radicaal herontwerp van het lokale netwerk impliceert; dit was voor ons belangrijk; we moesten dit met minimale kosten oplossen. Als je kijkt , dan zullen we zien hoe het eruit ziet. Hier hebben we een bepaalde virtuele server, op poort 443, luistert, accepteert de verbinding, alle werkende servers worden vermeld en je kunt zien dat de verbinding, geven of nemen, hetzelfde is. Als we naar de statistieken op dezelfde virtuele server kijken, hebben we inkomende pakketten, inkomende verbindingen, maar absoluut geen uitgaande. Uitgaande verbindingen gaan rechtstreeks naar de client. Oké, we hebben het uit balans kunnen brengen. Wat gebeurt er als een van onze fotorouters uitvalt? Ijzer is tenslotte ijzer. Het kan in kernelpaniek terechtkomen, het kan kapot gaan, de stroomvoorziening kan doorbranden. Iets. Daarom zijn gezondheidscontroles nodig. Ze kunnen zo simpel zijn als controleren hoe de poort open is, of iets complexers, tot enkele zelfgeschreven scripts die zelfs de bedrijfslogica controleren.
We zijn ergens halverwege gestopt: we hebben een https-verzoek naar een specifieke locatie, het script wordt aangeroepen, als het reageert met een 200ste reactie, denken we dat alles in orde is met deze server, dat deze leeft en vrij kan worden ingeschakeld gemakkelijk.
Hoe ziet dit er wederom in de praktijk uit? Laten we de server uitschakelen voor onderhoud, bijvoorbeeld door het BIOS te flashen. In de logs hebben we onmiddellijk een time-out, we zien de eerste regel, waarna deze na drie pogingen als "mislukt" wordt gemarkeerd en eenvoudigweg uit de lijst wordt verwijderd.
Een tweede gedragsoptie is ook mogelijk, waarbij VS eenvoudigweg op nul wordt gezet, maar als de foto wordt geretourneerd, werkt dit niet goed. De server komt op, Nginx start daar, de health-check begrijpt onmiddellijk dat de verbinding werkt, dat alles in orde is, en de server verschijnt in onze lijst, en de belasting begint er onmiddellijk op te worden toegepast. Er zijn geen handmatige acties vereist van de dienstdoende beheerder. De server is 's nachts opnieuw opgestart - de monitoringafdeling belt ons 's nachts niet hierover. Ze informeren je dat dit is gebeurd, alles is in orde.
Dus op een vrij eenvoudige manier, met behulp van een klein aantal servers, hebben we het probleem van externe fouttolerantie opgelost.
Het enige dat nog gezegd moet worden, is dat dit alles uiteraard in de gaten moet worden gehouden. Los daarvan moet worden opgemerkt dat Keepalivede, zoals lang geleden geschreven software, een aantal manieren heeft om het te monitoren, beide met behulp van controles via DBus, SMTP, SNMP en standaard Zabbix. Bovendien weet hij zelf hoe hij brieven moet schrijven voor bijna elke niesbui, en om eerlijk te zijn, op een gegeven moment hebben we er zelfs aan gedacht om het uit te zetten, omdat hij veel brieven schrijft voor elk verkeersverkeer, inschakelen, voor elke IP-verbinding, enzovoort. Als er veel servers zijn, kun je jezelf natuurlijk overweldigen met deze brieven. We monitoren nginx op fotorouters met behulp van standaardmethoden, en hardwaremonitoring is niet verdwenen. We zouden uiteraard nog twee dingen adviseren: ten eerste externe gezondheidscontroles en beschikbaarheid, want zelfs als alles werkt, ontvangen gebruikers misschien geen foto's vanwege problemen met externe providers of iets complexers. Het is altijd de moeite waard om ergens op een ander netwerk, in Amazon of ergens anders, een aparte machine te bewaren die je servers van buitenaf kan pingen, en het is ook de moeite waard om anomaliedetectie te gebruiken, voor degenen die weten hoe ze lastige machine learning moeten doen, of eenvoudige monitoring , in ieder geval om na te gaan of de verzoeken sterk zijn gedaald of juist zijn toegenomen. Het kan ook nuttig zijn.
Laten we samenvatten: we hebben in feite de ijzersterke oplossing, die op een gegeven moment niet meer bij ons paste, vervangen door een vrij eenvoudig systeem dat alles hetzelfde doet, dat wil zeggen dat het voorziet in beëindiging van HTTPS-verkeer en verdere slimme routering met de noodzakelijke gezondheidscontroles. We hebben de stabiliteit van dit systeem vergroot, dat wil zeggen, we hebben nog steeds een hoge beschikbaarheid voor elke laag, plus we hebben de bonus dat het vrij eenvoudig is om alles op elke laag te schalen, omdat het standaardhardware is met standaardsoftware, dat wil zeggen , hebben we het diagnosticeren van mogelijke problemen vereenvoudigd.
Waar zijn we mee geëindigd? Tijdens de januarivakantie van 2018 hadden we een probleem. In de eerste zes maanden dat we dit systeem in gebruik namen, hebben we het uitgebreid naar al het verkeer om al het verkeer van LTM te verwijderen. We groeiden alleen in het verkeer in één datacenter van 40 gigabit naar 60 gigabit, en tegelijkertijd voor konden het hele jaar 2018 bijna drie keer meer foto's per seconde verzenden.
Bron: www.habr.com