{"id":52389,"date":"2019-11-07T00:00:00","date_gmt":"2019-11-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions"},"modified":"2020-02-18T14:00:05","modified_gmt":"2020-02-18T11:00:05","slug":"kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Hoe wordt een failover-webarchitectuur gerealiseerd in het Mail.ru Cloud Solutions-platform","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hoe
\n
\nHallo, Habr! Ik ben Artem Karashchev, teamleider van systeembeheer. Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Het afgelopen jaar hadden we veel nieuwe productlanceringen. We wilden dat API-services gemakkelijk schaalbaar, fouttolerant en voorbereid waren op snelle groei van het gebruikersverkeer. Ons platform is gebouwd op OpenStack, en ik wil vertellen over de probleemstukken rondom de fouttolerantie van componenten die we moesten aanpakken om een fouttolerant systeem te krijgen. Ik denk dat dit interessant zal zijn voor degenen die ook producten ontwikkelen op OpenStack.<\/p>\n

De algehele fouttolerantie van het platform is opgebouwd uit de weerbaarheid van zijn componenten. Dus we zullen geleidelijk alle niveaus doorlopen waarop we risico's hebben ontdekt en deze hebben aangepakt.<\/p>\n

De videoversie van dit verhaal, dat oorspronkelijk afkomstig is uit een presentatie op de Uptime day 4-conferentie georganiseerd door ITSumma<\/a><\/noindex>, kan worden bekeken op het YouTube-kanaal van Uptime Community.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Fouttolerantie van de fysieke architectuur<\/h2>\n

\nHet openbare deel van de MCS-cloud is nu gebaseerd in twee datacenters van Tier III-niveau, die met elkaar zijn verbonden via eigen donkere vezels, gereserveerd op fysiek niveau door verschillende routes, met een bandbreedte van 200 Gbit\/s. Tier III-niveau biedt het vereiste niveau van fouttolerantie voor de fysieke infrastructuur. <\/p>\n

Donkere vezels zijn gereserveerd op zowel fysiek als logisch niveau. Het proces van het reserveren van verbindingen was iteratief, er deden zich problemen voor en we blijven de verbinding tussen de datacenters voortdurend verbeteren. <\/p>\n

Bijvoorbeeld, niet zo lang geleden, tijdens werkzaamheden in een put nabij een van de datacenters, heeft een graafmachine een buis doorboord, waarin zowel de primaire als de secundaire optische kabel zich bevonden. Onze fouttolerante verbinding met het datacenter bleek op \u00e9\u00e9n punt in de put kwetsbaar te zijn. Daardoor hebben we een deel van de infrastructuur verloren. We hebben lessen getrokken, een aantal maatregelen genomen, waaronder het leggen van extra glasvezelkabels in de aangrenzende put.<\/p><\/blockquote>\n

\nIn datacenters zijn er punten van aanwezigheid van telecomproviders, aan wie we onze prefixen via BGP doorgeven. Voor elke netwerkrichting wordt de beste metriek gekozen, wat het mogelijk maakt om verschillende klanten de beste verbindingskwaliteit te bieden. Als de verbinding via \u00e9\u00e9n provider uitvalt, passen we onze routering aan via beschikbare providers.<\/p>\n

Bij een storing van de provider schakelen we automatisch over naar de volgende. In het geval van een storing in een van de datacenters hebben we een spiegelkopie van onze diensten in het tweede datacenter, dat de volledige belasting op zich neemt.<\/p>\n

\"Hoe
\nHogere beschikbaarheid van de fysieke infrastructuur<\/i><\/p>\n

Wat we gebruiken voor hogere beschikbaarheid op applicatieniveau<\/h2>\n

\nOnze service is opgebouwd uit een aantal open source-componenten. <\/p>\n

ExaBGP<\/b> \u2014 een service die een aantal functies implementeert met behulp van een protocol voor dynamische routering op basis van BGP. We gebruiken het actief om onze witte IP-adressen aan te kondigen, waardoor gebruikers toegang krijgen tot de API.<\/p>\n

HAProxy<\/b> \u2014 een hoogbelastbare load balancer die zeer flexibele verkeersbalanceringsregels op verschillende niveaus van het OSI-model mogelijk maakt. We gebruiken het voor de balanceringsfunctie voor al onze services: databases, message brokers, API-services, web-services, onze interne projecten \u2014 alles draait achter HAProxy.<\/p>\n

API-toepassing<\/b> \u2014 een webtoepassing, geschreven in Python, waarmee de gebruiker zijn infrastructuur en services beheert.<\/p>\n

Worker-toepassing <\/b>(hierna gewoon worker) \u2014 in OpenStack-services is dit een infrastructuurdaemon die API-commando's naar de infrastructuur vertaalt. Bijvoorbeeld, de creatie van een schijf gebeurt daadwerkelijk in de worker, terwijl het verzoek om creatie plaatsvindt in de API-toepassing. <\/p>\n

Standaardarchitectuur van OpenStack-toepassing<\/h2>\n

\nDe meeste diensten die voor OpenStack worden ontwikkeld, proberen een uniforme paradigma te volgen. Een service bestaat doorgaans uit twee delen: API en workers (achtergrondprocessen). De API is meestal een WSGI-toepassing in Python, die wordt uitgevoerd als een zelfstandige proces (daemon) of met behulp van een kant-en-klaar webserver zoals Nginx of Apache. De API verwerkt de gebruikersaanvragen en geeft verdere instructies door aan de worker-toepassing. Deze overdracht gebeurt via een berichtenbroker, meestal RabbitMQ, de andere worden slecht ondersteund. Wanneer berichten de broker bereiken, worden ze door de workers verwerkt en, indien nodig, antwoorden teruggestuurd. <\/p>\n

Dit paradigma impliceert ge\u00efsoleerde gemeenschappelijke faalpunten: RabbitMQ en de database. RabbitMQ is echter ge\u00efsoleerd binnen een enkele service en kan in principe voor elke service afzonderlijk zijn. Daarom splitsen we bij MCS deze services zoveel mogelijk; voor elk afzonderlijk project cre\u00ebren we een aparte database en een aparte RabbitMQ. Deze aanpak is gunstig omdat in geval van een storing in kwetsbare punten niet de gehele service faalt, maar alleen een deel ervan.<\/p>\n

Het aantal worker-toepassingen is onbeperkt, waardoor de API gemakkelijk horizontaal kan worden geschaald achter load balancers, wat de prestaties en de fouttolerantie verhoogt.<\/p>\n

In sommige diensten is co\u00f6rdinatie binnen de service noodzakelijk \u2014 wanneer er complexe opeenvolgende bewerkingen plaatsvinden tussen API's en workers. In dit geval wordt een centraal co\u00f6rdinatiepunt gebruikt, een clustersysteem zoals Redis, Memcache, of etcd, dat het mogelijk maakt voor \u00e9\u00e9n worker om tegen een andere te zeggen dat deze taak aan hem is toegewezen (\"jij hoeft deze niet op te pakken\"). Wij gebruiken etcd. Gewoonlijk communiceren workers actief met de database, waarbij ze informatie schrijven en lezen. Voor de database gebruiken we MariaDB, die zich in een multimaster-cluster bevindt.\n<\/p><\/blockquote>\n

\nEen klassieke enkele service is georganiseerd op de gebruikelijke manier voor OpenStack. Het kan worden beschouwd als een afgesloten systeem, waarvan de manieren voor schaalvergroting en fouttolerantie vrij duidelijk zijn. Bijvoorbeeld, voor fouttolerantie is het voldoende om een load balancer voor de API te plaatsen. De schaalvergroting van workers wordt bereikt door hun aantal te verhogen. <\/p>\n

Het zwakke punt in het hele systeem zijn RabbitMQ en MariaDB. Hun architectuur verdient een apart artikel. In dit artikel wil ik me richten op de fault-tolerantie van de API.<\/p>\n

\"Hoe
\nOpenstack Application Architectuur. Balanceren en fault-tolerantie van het cloudplatform.<\/i><\/p>\n

We maken de HAProxy load balancer fault-tolerant met behulp van ExaBGP.<\/h2>\n

\nOm onze API's schaalbaar, snel en fault-tolerant te maken, hebben we een load balancer voor hen geplaatst. We kozen voor HAProxy. Naar mijn mening heeft het alle noodzakelijke eigenschappen voor onze taak: balancering op meerdere OSI-niveaus, een beheerdersinterface, flexibiliteit en schaalbaarheid, een groot aantal balanceringsmethoden en ondersteuning voor sessietabellen.<\/p>\n

Het eerste probleem dat moest worden opgelost, was de fault-tolerantie van de load balancer zelf. Gewoon het installeren van een load balancer cre\u00ebert ook een enkel punt van falen: als de load balancer uitvalt, valt de service uit. Om dit te voorkomen, gebruikten we HAProxy samen met ExaBGP.<\/p>\n

ExaBGP maakt het mogelijk om een mechanism voor service statuscontrole te implementeren. We gebruikten dit mechanisme om de werking van HAProxy te controleren en in geval van problemen de HAProxy-service uit te schakelen vanuit BGP. <\/p>\n

Schema ExaBGP+HAProxy<\/b><\/p>\n

    \n
  1. We installeren de benodigde software, ExaBGP en HAProxy, op drie servers. <\/li>\n
  2. Op elke server cre\u00ebren we een loopback-interface.<\/li>\n
  3. Op alle drie de servers configureren we dezelfde publieke IP-adres voor deze interface.<\/li>\n
  4. Het publieke IP-adres wordt op internet geannonceerd via ExaBGP. <\/li>\n<\/ol>\n

    \nFault-tolerantie wordt bereikt door hetzelfde IP-adres vanaf alle drie de servers aan te kondigen. Vanuit het netwerk gezien is hetzelfde adres beschikbaar via drie verschillende next hops. De router ziet drie identieke routes en kiest op basis van zijn eigen metric de meest prioritaire (dit is meestal dezelfde optie), en het verkeer gaat alleen naar een van de servers. <\/p>\n

    Bij problemen met de werking van HAProxy of de uitval van een server, stopt ExaBGP met het aankondigen van de route en schakelt het verkeer soepel over naar een andere server. <\/p>\n

    Op deze manier hebben we fault-tolerantie voor de load balancer bereikt.<\/p>\n

    \"Hoe
    \nFault-tolerantie van HAProxy load balancers.<\/i><\/p>\n

    Het schema is niet ideaal: we hebben geleerd om HAProxy te redunderen, maar we hebben niet geleerd om de belasting binnen de services te verdelen. Daarom hebben we dit schema iets uitgebreid: we zijn overgestapt op balanceren tussen meerdere publieke IP-adressen.<\/p>\n

    DNS-gebaseerde load balancing plus BGP<\/h2>\n

    \nDe kwestie van load balancing voor onze HAProxy is nog niet opgelost. Het kan echter vrij eenvoudig worden opgelost, zoals wij dat ook hebben gedaan.<\/p>\n

    Voor de load balancing van drie servers zijn 3 publieke IP-adressen en de goede oude DNS nodig. Elk van deze adressen wordt toegewezen aan de loopback-interface van elke HAProxy en wordt op internet geannonceerd. <\/p>\n

    In OpenStack wordt een service catalogus gebruikt voor het beheer van middelen, waarin de API-endpoint van elke service wordt gedefinieerd. In deze catalogus vermelden we de domeinnaam \u2014 public.infra.mail.ru, die via DNS wordt geresolleerd naar drie verschillende IP-adressen. Hierdoor krijgen we een load balancing tussen de drie adressen via DNS. <\/p>\n

    Maar omdat we bij het adverteren van publieke IP-adressen de prioriteiten voor de serverkeuze niet beheren, is dit nog geen load balancing. Gewoonlijk wordt slechts \u00e9\u00e9n server gekozen op basis van de senioriteit van het IP-adres, terwijl de andere twee inactief blijven, omdat er geen metrics in BGP zijn opgegeven.<\/p>\n

    We zijn begonnen met het adverteren van routes via ExaBGP met verschillende metrics. Elke load balancer annonceert alle drie de publieke IP-adressen, maar \u00e9\u00e9n ervan, de belangrijkste voor deze load balancer, wordt aangekondigd met de laagste metric. Dus zolang alle drie de load balancers operationeel zijn, komen verzoeken naar het eerste IP-adres terecht bij de eerste load balancer, verzoeken naar het tweede bij de tweede, en naar het derde bij de derde.<\/p>\n

    Wat gebeurt er op het moment dat een van de load balancers uitvalt? Bij het falen van een load balancer wordt het basisadres nog steeds geannonceerd door de twee andere, waardoor het verkeer tussen hen wordt herverdeeld. Op deze manier bieden we de gebruiker via DNS meerdere IP-adressen tegelijk aan. Door load balancing via DNS en verschillende metrics krijgen we een uniforme verdeling van de belasting over de drie load balancers en behouden we tegelijkertijd de fouttolerantie.<\/p>\n

    \"Hoe
    \nHAProxy load balancing gebaseerd op DNS + BGP<\/i><\/p>\n

    Interactie tussen ExaBGP en HAProxy<\/h2>\n

    \nDus we hebben fouttolerantie ge\u00efmplementeerd voor het geval een server uitvalt, op basis van het stoppen met het adverteren van routes. Maar HAProxy kan om andere redenen uitvallen dan een server die defect raakt: beheersfouten, storingen binnen de service. We willen de defecte load balancer uit de belasting halen, zelfs in deze gevallen, en daar hebben we een ander mechanisme voor nodig. <\/p>\n

    Daarom hebben we, door de vorige opzet uit te breiden, een heartbeat tussen ExaBGP en HAProxy ge\u00efmplementeerd. Dit is een software-implementatie van de interactie tussen ExaBGP en HAProxy, waarbij ExaBGP aangepaste scripts gebruikt om de status van applicaties te controleren.<\/p>\n

    Hiervoor moet in de ExaBGP-configuratie een health checker worden ingesteld die de status van HAProxy kan controleren. In ons geval hebben we een health backend in HAProxy ingesteld, en aan de kant van ExaBGP controleren we dit met een eenvoudige GET-aanroep. Als de aankondiging stopt, betekent dit dat HAProxy waarschijnlijk niet werkt en dat het niet nodig is om deze aan te kondigen. <\/p>\n

    \"Hoe
    \nHAProxy Health Check<\/i><\/p>\n

    HAProxy Peers: sessie-synchronisatie <\/h2>\n

    \nHet volgende wat moest gebeuren, was het synchroniseren van sessies. Het is moeilijk om informatie over klantensessies op te slaan bij het gebruik van gedistribueerde load balancers. Maar HAProxy is een van de weinige load balancers die dit kan dankzij de Peers-functie, waarmee sessietabellen tussen verschillende HAProxy-processen kunnen worden doorgegeven. <\/p>\n

    Er zijn verschillende balanceringsmethoden: eenvoudige, zoals ronddraaien<\/a><\/noindex>, en geavanceerde methoden waarbij de sessie van de klant wordt bewaard, zodat deze elke keer naar dezelfde server gaat als eerder. Wij wilden de tweede optie implementeren.<\/p>\n

    In HAProxy wordt voor het behouden van klantensessies gebruikgemaakt van stick-tables. Deze slaan het originele IP-adres van de klant, het gekozen doeladres (backend) en bepaalde administratieve informatie op. Gewoonlijk worden stick-tabellen gebruikt om het paar source-IP + destination-IP op te slaan, wat vooral nuttig is voor applicaties die geen gebruikerssessie-context kunnen doorgeven wanneer ze overschakelen naar een andere load balancer, bijvoorbeeld in RoundRobin-balanceringsmodus.<\/p>\n

    Als we de stick-tabel leren verplaatsen tussen verschillende HAProxy-processen (waar tussen de balans plaatsvindt), kunnen onze load balancers met \u00e9\u00e9n pool van stick-tabellen werken. Dit maakt naadloze netwerkoverschakeling voor de klant mogelijk wanneer een van de load balancers uitvalt, en de verwerking van klantensessies kan doorgaan op dezelfde backends die eerder waren gekozen.<\/p>\n

    Voor een correcte werking moet het probleem met het source IP-adres van de load balancer waarmee de sessie is ingesteld, worden opgelost. In ons geval is dit een dynamisch adres op de loopback-interface. <\/p>\n

    De juiste werking van peers wordt alleen onder bepaalde omstandigheden bereikt. Dit betekent dat TCP-timeouts groot genoeg moeten zijn of dat de overschakeling voldoende snel moet zijn, zodat de TCP-sessie niet verbroken raakt. Desondanks maakt dit een naadloze overschakeling mogelijk. <\/p>\n

    Bij ons in IaaS hebben we een service die op dezelfde technologie is gebouwd. Dit is Load Balancer als een service voor OpenStack<\/a><\/noindex>, genaamd Octavia. Het is gebaseerd op een set van twee HAProxy-processen, waarin van huis uit ondersteuning voor peers is ingebouwd. In deze service hebben ze zich uitstekend bewezen.<\/p>\n

    Op de afbeelding is schematisch de verplaatsing van peers-tabellen tussen drie HAProxy-instanties weergegeven, met een voorgestelde configuratie voor hoe dit kan worden ingesteld:<\/p>\n

    \"Hoe
    \nHAProxy Peers (sessiesynchronisatie)<\/i><\/p>\n

    Als je een dergelijk schema gaat implementeren, moet je de werking zorgvuldig testen. Het is niet gegarandeerd dat het in precies dezelfde vorm 100% van de tijd werkt. Maar in ieder geval zul je de stick-tabellen niet verliezen wanneer je het source IP van de client moet onthouden.<\/p>\n

    Beperking van het aantal gelijktijdige verzoeken van dezelfde klant<\/h2>\n

    \nElke service die openbaar toegankelijk is, inclusief onze API's, kan worden blootgesteld aan een instroom van verzoeken. De redenen hiervoor kunnen heel divers zijn, van gebruikersfouten tot gerichte aanvallen. We worden periodiek DDoS-aanvallen via IP-adressen. Klanten maken vaak fouten in hun scripts, wat ons mini-DDoS-aanvallen oplevert.<\/p>\n

    Hoe dan ook, het is noodzakelijk om aanvullende bescherming te overwegen. Een voor de hand liggende oplossing is om het aantal verzoeken aan de API te beperken en geen processorcapaciteit te verspillen aan het verwerken van kwaadaardige verzoeken.<\/p>\n

    Voor het implementeren van dergelijke beperkingen gebruiken we rate limits, georganiseerd op basis van HAProxy, met behulp van dezelfde stick-tabellen. De limieten zijn eenvoudig in te stellen en stellen ons in staat om de gebruiker te beperken op het aantal verzoeken aan de API. Het algoritme onthoudt het source IP van waaruit verzoeken worden gedaan en beperkt het aantal gelijktijdige verzoeken van \u00e9\u00e9n gebruiker. Uiteraard hebben we het gemiddelde belastingprofiel van de API voor elke service berekend en een limiet ingesteld die ongeveer 10 keer zo hoog is als deze waarde. We blijven de situatie nauwlettend in de gaten houden en blijven alert.<\/p>\n

    Hoe ziet het eruit in de praktijk? We hebben klanten die voortdurend gebruikmaken van onze API's voor automatische schaling. Ze cre\u00ebren 's ochtends ongeveer tweehonderd tot driehonderd virtuele machines en verwijderen ze 's avonds weer. Voor OpenStack vergt het maken van een virtuele machine, inclusief PaaS-diensten, minimaal 1000 API-aanroepen, aangezien de interactie tussen de diensten ook via API's verloopt. <\/p>\n

    Dergelijk geknutselt met taken veroorzaakt een aanzienlijke belasting. We hebben deze belasting ge\u00ebvalueerd, de dagelijkse pieken verzameld, en deze met tien vermenigvuldigd, en dat is onze rate-limiet geworden. We houden vinger aan de pols. Vaak zien we bots en scanners die ons proberen te bekijken om te zien of we CGA-scripts hebben die kunnen worden uitgevoerd; we snijden ze actief af.<\/p>\n

    Hoe de codebasis onopgemerkt voor gebruikers bij te werken<\/h2>\n

    \nWe implementeren ook failover op het niveau van het uitrollen van code. Bij uitrol kunnen er fouten optreden, maar hun impact op de beschikbaarheid van diensten kan geminimaliseerd worden.<\/p>\n

    We updaten voortdurend onze diensten en moeten het proces van het bijwerken van de codebasis waarborgen zonder effect voor gebruikers. Deze uitdaging hebben we opgelost met behulp van de beheermogelijkheden van HAProxy en de implementatie van Graceful Shutdown in onze diensten.<\/p>\n

    Voor het oplossen van deze taak was het nodig om het beheer van de load balancer en het 'juiste' uitschakelen van diensten te waarborgen:<\/p>\n