Wéi Feeler-tolerant Webarchitektur an der Mail.ru Cloud Solutions Plattform implementéiert gëtt

Moien, Habr! Ech sinn den Artem Karamyshev, Chef vun der Systemadministratiounsteam Mail.Ru Cloud Solutions (MCS). Mir hu vill nei Produit lancéiert am leschte Joer. Mir wollten dofir suergen datt API-Servicer liicht skalierbar, Feelertolerant a prett fir séier Wuesstum an der Benotzerbelaaschtung sinn. Eis Plattform ass op OpenStack implementéiert, an ech wëll Iech soen wéi eng Komponent Feeler Toleranzproblemer mir hu misse léisen fir e Feelertolerant System ze kréien. Ech mengen dat wäert interessant sinn fir déi, déi och Produkter op OpenStack entwéckelen.

Déi allgemeng Feelertoleranz vun enger Plattform besteet aus der Widderstandsfäegkeet vu senge Komponenten. Also wäerte mir all Niveauen no an no duerchgoen, wou mir Risiken identifizéiert hunn an se zougemaach hunn.

Video Versioun vun dëser Geschicht, déi primär Quell vun deem war e Bericht op der Uptime Dag 4 Konferenz, organiséiert vun ITSumma, du kanns gesinn um Uptime Community YouTube Kanal.

Widderstandsfäegkeet vun der kierperlecher Architektur

Den ëffentlechen Deel vun der MCS-Wollek ass elo an zwee Tier III-Datenzentren baséiert, tëscht hinnen ass seng eege donkel Faser, reservéiert um kierperlechen Niveau vu verschiddene Strecken, mat engem Duerchgang vun 200 Gbit / s. Tier III bitt den néidegen Niveau vu Feelertoleranz fir déi kierperlech Infrastruktur.

Däischter Faser ass souwuel um kierperlechen wéi och logesche Niveau reservéiert. De Kanalreservatiounsprozess war iterativ, Problemer entstanen, a mir verbesseren permanent d'Kommunikatioun tëscht Datenzenteren.

Zum Beispill, net viru laanger Zäit, wärend der Aarbecht an enger Brunn bei engem vun den Datenzenteren, huet e Bagger e Päif gebrach, an an dëser Päif war souwuel en Haapt- an e Backup-opteschen Kabel. Eise Feeler-tolerante Kommunikatiounskanal mam Datenzenter huet sech op engem Punkt vulnérabel erausgestallt, an der Brunn. Deementspriechend hu mir en Deel vun der Infrastruktur verluer. Mir hunn Conclusiounen gezunn an eng Rei vun Aktiounen geholl, dorënner d'Installatioun vun zousätzlech Optik an der Nopeschbunn.

An Datenzentere ginn et Punkte vun der Präsenz vu Kommunikatiounsanbieter, un déi mir eis Präfixe iwwer BGP iwwerdroen. Fir all Netzwierkrichtung gëtt déi bescht Metrik ausgewielt, wat et erlaabt verschidde Clienten déi bescht Verbindungsqualitéit ze kréien. Wann d'Kommunikatioun duerch ee Provider erof geet, bauen mir eise Routing duerch déi verfügbare Fournisseuren op.

Wann e Provider feelt, wiessele mir automatesch op deen nächsten. Am Fall vun engem Ausfall vun engem vun den Datenzenter hu mir eng Spigelkopie vun eise Servicer am zweeten Rechenzentrum, déi déi ganz Laascht iwwerhuelen.

Widderstandsfäegkeet vu kierperlecher Infrastruktur

Wat mir fir Applikatioun-Niveau Feeler Toleranz benotzen

Eise Service ass op enger Zuel vun Opensource Komponente gebaut.

ExaBGP ass e Service deen eng Rei vu Funktiounen implementéiert mat dem BGP-baséierten dynamesche Routingprotokoll. Mir benotzen et aktiv fir eis whitelisted IP Adressen ze Reklamm duerch déi Benotzer Zougang zu der API kréien.

HAProxy ass en High-load Balancer deen Iech erlaabt ganz flexibel Traffic Balance Regelen op verschidden Niveauen vum OSI Modell ze konfiguréieren. Mir benotzen et fir all Servicer ze balanséieren: Datenbanken, Message Broker, API Servicer, Webservicer, eis intern Projeten - alles ass hannert HAProxy.

API Applikatioun - eng Webapplikatioun am Python geschriwwen, mat där de Benotzer seng Infrastruktur a säi Service geréiert.

Aarbechter Applikatioun (nodréiglech einfach Aarbechter) - an OpenStack Servicer ass dëst en Infrastruktur Daemon deen Iech erlaabt API Kommandoen an d'Infrastruktur ze iwwerdroen. Zum Beispill, Scheif Kreatioun geschitt am Aarbechter, an der Kreatioun Ufro geschitt an der Applikatioun API.

Standard OpenStack Applikatiounsarchitektur

Déi meescht Servicer, déi fir OpenStack entwéckelt ginn, probéieren en eenzegt Paradigma ze verfollegen. E Service besteet normalerweis aus 2 Deeler: API an Aarbechter (Backend Exekutoren). In der Regel ass eng API eng WSGI Applikatioun am Python, déi entweder als onofhängege Prozess (Daemon) gestart gëtt oder mat engem fäerdege Nginx oder Apache Webserver benotzt. D'API veraarbecht d'Benotzer Ufro a gitt weider Instruktiounen un d'Aarbechterapplikatioun fir Ausféierung. Den Transfer geschitt mat engem Message Broker, normalerweis RabbitMQ, déi aner si schlecht ënnerstëtzt. Wann Messagen de Broker erreechen, gi se vun den Aarbechter veraarbecht an, wann néideg, eng Äntwert zréck.

Dëst Paradigma beinhalt isoléiert gemeinsam Punkte vum Echec: RabbitMQ an d'Datebank. Awer RabbitMQ ass bannent engem Service isoléiert a kann an der Theorie individuell fir all Service sinn. Also bei MCS trennen mir dës Servicer sou vill wéi méiglech fir all eenzelne Projet, kreéiere mir eng separat Datebank, eng separat RabbitMQ. Dës Approche ass gutt, well am Fall vun engem Accident op e puer vulnerabel Punkten net de ganze Service brécht, mä nëmmen en Deel dovun.

D'Zuel vun den Aarbechterapplikatiounen ass onlimitéiert, sou datt d'API einfach horizontal hannert Balancer kann skaléieren fir d'Performance a Feelertoleranz ze erhéijen.

E puer Servicer erfuerderen Koordinatioun am Service wann komplex sequentiell Operatiounen tëscht APIen an Aarbechter optrieden. An dësem Fall gëtt en eenzegen Koordinatiounszenter benotzt, e Clustersystem wéi Redis, Memcache, etcd, wat et erlaabt engem Aarbechter engem aneren ze soen datt dës Aufgab him zougewisen ass ("W.e.g. huelt se net"). Mir benotzen etcd. Als Regel, schaffen Aarbechter aktiv mat der Datebank kommunizéieren, schreiwen a liesen Informatiounen vun do. Mir benotzen mariadb als Datebank, déi an engem Multimaster Cluster läit.

Dëse klassesche Single Service ass organiséiert op eng Manéier allgemeng akzeptéiert fir OpenStack. Et kann als zoue System ugesi ginn, fir deen d'Methoden vun der Skaléierung a Feelertoleranz zimlech offensichtlech sinn. Zum Beispill, fir API Feeler Toleranz ass et genuch e Balancer virun hinnen ze setzen. D'Skaléierung vun Aarbechter gëtt erreecht andeems se hir Zuel erhéijen.

De schwaache Punkt am ganze Schema ass RabbitMQ a MariaDB. Hir Architektur verdéngt en separaten Artikel An dësem Artikel wëll ech op API Feeler Toleranz konzentréieren.

Openstack Applikatioun Architektur. Balance a Feeler Toleranz vun der Cloud Plattform

Maachen den HAProxy Balancer Feeler-tolerant benotzt ExaBGP

Fir eis APIen skalierbar, séier a Feeler-tolerant ze maachen, setzen mir e Lastbalancer virun hinnen. Mir hunn HAProxy gewielt. Menger Meenung no huet et all déi néideg Charakteristiken fir eis Aufgab: Balance op verschiddene OSI Niveauen, e Management Interface, Flexibilitéit a Skalierbarkeet, eng grouss Zuel vu Balancemethoden, Ënnerstëtzung fir Sessiounstabellen.

Den éischte Problem, dee geléist gouf, war d'Feeltoleranz vum Balancer selwer. Einfach e Balancer z'installéieren erstellt och e Punkt vum Echec: de Balancer brécht an de Service crasht. Fir dëst ze verhënneren, hu mir HAProxy a Verbindung mat ExaBGP benotzt.

ExaBGP erlaabt Iech e Mechanismus ëmzesetzen fir den Zoustand vun engem Service ze kontrolléieren. Mir hunn dëse Mechanismus benotzt fir d'Funktionalitéit vun HAProxy ze kontrolléieren an, am Fall vu Probleemer, den HAProxy Service vu BGP auszeschalten.

ExaBGP+HAProxy Schema

1. Mir installéieren déi néideg Software, ExaBGP an HAProxy, op dräi Serveren.
2. Mir kreéieren eng Loopback Interface op all Server.
3. Op allen dräi Serveren ginn déi selwecht wäiss IP Adress un dës Interface zou.
4. Eng wäiss IP Adress gëtt um Internet iwwer ExaBGP ugekënnegt.

Feeler Toleranz gëtt erreecht andeems Dir déi selwecht IP Adress vun allen dräi Serveren annoncéiert. Aus engem Netzwierk Siicht ass déi selwecht Adress zougänglech vun dräi verschiddenen nächsten Hopfen. De Router gesäit dräi identesch Strecken, wielt déi héchst Prioritéit vun hinnen op Basis vu senger eegener Metrik (dëst ass normalerweis déiselwecht Optioun), an de Traffic geet nëmmen op ee vun de Serveren.

Am Fall vu Probleemer mat der Operatioun vun HAProxy oder e Serverfehler, hält ExaBGP op d'Streck ze verkënnegen, an de Verkéier wiesselt glat op en anere Server.

Sou hu mir Feeler Toleranz vum Balancer erreecht.

Feeler Toleranz vun HAProxy Balancer

De Schema huet sech als imperfekt erausgestallt: mir hu geléiert wéi HAProxy reservéiert gëtt, awer hunn net geléiert wéi d'Laascht an de Servicer verdeelt gëtt. Dofir hu mir dëse Schema e bëssen erweidert: mir sinn op d'Balance tëscht e puer wäiss IP Adressen geplënnert.

Balance baséiert op DNS plus BGP

D'Thema vun der Belaaschtung fir eis HAProxy bleift ongeléist. Et kann awer ganz einfach geléist ginn, wéi mir hei gemaach hunn.

Fir dräi Serveren ze balanséieren braucht Dir 3 wäiss IP Adressen a gutt al DNS. Jiddereng vun dësen Adressen gëtt op der Loopback Interface vun all HAProxy bestëmmt an um Internet ugekënnegt.

Am OpenStack, fir Ressourcen ze verwalten, gëtt e Serviceverzeichnis benotzt, deen den Endpunkt API vun engem bestëmmte Service spezifizéiert. An dësem Verzeechnes registréiere mir en Domain Numm - public.infra.mail.ru, deen iwwer DNS duerch dräi verschidden IP Adressen geléist gëtt. Als Resultat kréie mir Lastverdeelung tëscht dräi Adressen iwwer DNS.

Awer well wa mir wäiss IP Adressen annoncéieren, kontrolléiere mir d'Serverauswiel Prioritéite net, ass dëst nach net balancéiert. Typesch gëtt nëmmen ee Server ausgewielt op Basis vun der IP Adress Anciennitéit, an déi aner zwee sinn idle well keng Metriken am BGP spezifizéiert sinn.

Mir hunn ugefaang Strecken iwwer ExaBGP mat verschiddene Metriken ze schécken. All Balancer annoncéiert all dräi wäiss IP Adressen, awer ee vun hinnen, den Haapt fir dësen Balancer, gëtt mat der Minimum Metrik ugekënnegt. Also wann all dräi Balancer am Betrib sinn, rifft d'éischt IP Adress un den éischte Balancer, rifft op déi zweet an déi zweet an rifft op déi drëtt op déi drëtt.

Wat geschitt wann ee vun de Balancer fällt? Wann all Balancer feelt, gëtt seng Haaptadress nach ëmmer vun deenen aneren zwee ugekënnegt, an de Verkéier gëtt tëscht hinnen ëmverdeelt. Sou gi mir de Benotzer e puer IP Adressen gläichzäiteg iwwer DNS. Andeems Dir duerch DNS a verschidde Metriken balancéiert, kréie mir eng gläichméisseg Verdeelung vun der Belaaschtung iwwer all dräi Balancer. A gläichzäiteg verléieren mir keng Feeler Toleranz.

Balancing HAProxy baséiert op DNS + BGP

Interaktioun tëscht ExaBGP an HAProxy

Also, mir implementéiert Feeler Toleranz am Fall wou de Server verléisst, baséiert op der Ukënnegung vun de Strecken ze stoppen. Awer HAProxy kann aus anere Grënn wéi Serverfehler zoumaachen: Administratiounsfehler, Feeler am Service. Mir wëllen och an dëse Fäll de gebrachene Balancer ënnert der Laascht ewechhuelen, a mir brauchen en anere Mechanismus.

Dofir, de fréiere Schema auszebauen, hu mir Häerzschlag tëscht ExaBGP an HAProxy ëmgesat. Dëst ass eng Softwareimplementatioun vun der Interaktioun tëscht ExaBGP an HAProxy, wann ExaBGP personaliséiert Scripte benotzt fir de Status vun Uwendungen ze kontrolléieren.

Fir dëst ze maachen, musst Dir e Gesondheetschecker an der ExaBGP Konfiguratioun konfiguréieren, deen den Status vun HAProxy iwwerpréift. An eisem Fall hu mir de Gesondheetsbackend an HAProxy konfiguréiert, a vun der ExaBGP Säit iwwerpréift mir mat enger einfacher GET Ufro. Wann d'Ukënnegung ophält ze geschéien, dann ass HAProxy héchstwahrscheinlech net funktionnéiert an et ass net néideg et ze annoncéieren.

HAProxy Gesondheetscheck

HAProxy Peers: Sessiounssynchroniséierung

Déi nächst Saach fir ze maachen war d'Sessiounen ze synchroniséieren. Wann Dir duerch verdeelt Balancer schafft, ass et schwéier d'Späichere vun Informatioun iwwer Client Sessiounen ze organiséieren. Awer HAProxy ass ee vun de wéinege Balancer déi dëst maache kënnen wéinst der Peers Funktionalitéit - d'Fäegkeet Sessiounstabellen tëscht verschiddenen HAProxy Prozesser ze transferéieren.

Et gi verschidde Balancemethoden: einfach wéi z.B Ronn-Robin, a verlängert, wann de Client senger Sëtzung erënnert, an all Kéier hien op déi selwecht Server Enn wéi virdrun. Mir wollten déi zweet Optioun ëmsetzen.

HAProxy benotzt Stick-Tables fir Client Sessiounen vun dësem Mechanismus ze retten. Si späicheren d'originell IP Adress vum Client, déi gewielte Ziladress (Backend) an e puer Serviceinformatioun. Typesch gi Stick Dëscher benotzt fir e Quell-IP + Destinatioun-IP Pair ze späicheren, wat besonnesch nëtzlech ass fir Uwendungen déi de Benotzersessiounskontext net kënnen transferéieren wann Dir op en anere Balancer wiesselt, zum Beispill am RoundRobin Balancemodus.

Wann e Stick Dësch geléiert gëtt tëscht verschiddenen HAProxy Prozesser ze réckelen (tëschent deem Balance geschitt), kënnen eis Balancer mat engem Pool vu Stick Dëscher schaffen. Dëst wäert et méiglech maachen d'Netzwierk vum Client nahtlos ze wiesselen, wann ee vun de Balancer klappt, d'Aarbecht mat Clientssessiounen weider op déiselwecht Backends, déi virdru gewielt goufen.

Fir eng korrekt Operatioun muss de Problem vun der Quell IP Adress vum Balancer, aus deem d'Sessioun gegrënnt gouf, geléist ginn. An eisem Fall ass dëst eng dynamesch Adress op der Loopback Interface.

Korrekt Aarbecht vu Kollegen gëtt nëmmen ënner bestëmmte Konditiounen erreecht. Dat ass, TCP Timeouts musse grouss genuch sinn oder d'Schalter muss séier genuch sinn, sou datt d'TCP Sessioun keng Zäit huet fir opzehalen. Wéi och ëmmer, et erlaabt nahtlos Wiessel.

An IaaS hu mir e Service gebaut mat der selwechter Technologie. Dëst Load Balancer als Service fir OpenStack, déi Octavia genannt gëtt. Et baséiert op zwee HAProxy Prozesser an enthält ufanks Ënnerstëtzung fir Peer. Si hu sech excellent an dësem Service bewisen.

D'Bild weist schematesch d'Bewegung vu Peer Dëscher tëscht dräi HAProxy Instanzen, eng Konfiguratioun gëtt proposéiert wéi dëst konfiguréiert ka ginn:

HAProxy Peers (Sitzungssynchroniséierung)

Wann Dir dee selwechte Schema implementéiert, muss seng Operatioun suergfälteg getest ginn. Et ass net e Fakt datt et an der selwechter Form 100% vun der Zäit funktionnéiert. Awer op d'mannst wäert Dir keng Stick Dëscher verléieren wann Dir un d'Quell IP vum Client erënnere musst.

Limitéiert d'Zuel vu simultan Ufroe vum selwechte Client

All Servicer déi ëffentlech verfügbar sinn, inklusiv eis APIen, kënne vu Lawinen vun Ufroen ënnerleien. D'Grënn fir si kënne ganz ënnerschiddlech sinn, vu Benotzerfehler bis geziilt Attacken. Mir ginn periodesch DDoSed vun IP Adressen. Clienten maachen dacks Feeler an hire Scripten a ginn eis Mini-DDoSs.

Op déi eng oder aner Manéier muss zousätzlech Schutz gesuergt ginn. Déi offensichtlech Léisung ass d'Zuel vun den API-Ufroen ze limitéieren an d'CPU Zäit net ze verschwenden fir béiswëlleg Ufroen ze veraarbecht.

Fir esou Restriktiounen ëmzesetzen, benotze mir Tariflimiten, organiséiert op Basis vun HAProxy, mat de selwechte Sticktabellen. Limiten opzestellen ass zimmlech einfach an erlaabt Iech de Benotzer duerch d'Zuel vun den Ufroen un d'API ze limitéieren. Den Algorithmus erënnert un d'Quell-IP aus där Ufroe gemaach ginn a limitéiert d'Zuel vu simultan Ufroe vun engem Benotzer. Natierlech hu mir den duerchschnëttleche API-Laaschtprofil fir all Service berechent an eng Limit vun ≈ 10 Mol dëse Wäert gesat. Mir iwwerwaachen d'Situatioun weider an halen de Fanger um Puls.

Wéi gesäit dat an der Praxis aus? Mir hunn Clienten déi eis Autoscaling APIs déi ganzen Zäit benotzen. Si kreéieren ongeféier zwee bis dräihonnert virtuell Maschinnen moies a läschen se am Owend. Fir OpenStack, eng virtuell Maschinn erstellen, och mat PaaS Servicer, erfuerdert op d'mannst 1000 API Ufroen, well Interaktioun tëscht Servicer och duerch d'API geschitt.

Esou Transfert vun Aufgaben verursaacht eng zimlech grouss Laascht. Mir hunn dës Belaaschtung bewäert, deeglech Peaks gesammelt, se zéngfach erhéicht, an dëst gouf eis Tauxlimit. Mir halen de Fanger um Puls. Mir gesinn dacks Bots a Scanner déi probéieren eis ze kucken fir ze kucken ob mir CGA Scripten hunn déi kënne lafen, mir schneiden se aktiv.

Wéi Dir Är Codebase aktualiséieren ouni datt d'Benotzer bemierken

Mir implementéieren och Feeler Toleranz um Niveau vun de Code Deployment Prozesser. Et kënne Feeler wärend der Rollout sinn, awer hiren Impakt op d'Disponibilitéit vun de Service kann miniméiert ginn.

Mir aktualiséieren eis Servicer permanent a musse suergen datt d'Codebase aktualiséiert gëtt ouni d'Benotzer ze beaflossen. Mir hunn et fäerdeg bruecht dëse Problem mat de Gestiounsfäegkeeten vun HAProxy an der Implementatioun vu Graceful Shutdown an eise Servicer ze léisen.

Fir dëse Problem ze léisen, war et néideg d'Kontroll vum Balancer an de "korrekte" Ausschaltung vun de Servicer ze garantéieren:

• Am Fall vun HAProxy gëtt d'Kontroll duerch eng Statistikdatei gemaach, déi am Wesentlechen e Socket ass an an der HAProxy Config definéiert ass. Dir kënnt Kommandoen iwwer stdio schécken. Awer eisen Haaptkonfiguratiounskontrollinstrument ass méiglech, sou datt et en agebaute Modul huet fir HAProxy ze managen. Déi mir aktiv benotzen.
• Déi meescht vun eisen API- an Engine-Servicer ënnerstëtzen graziéis Shutdown-Technologien: wann se auszeschalten, waarden se op déi aktuell Aufgab fir ze kompletéieren, sief et eng http-Ufro oder eng Servicetask. Datselwecht geschitt mam Aarbechter. Et weess all d'Aufgaben déi et mécht an endet wann et alles erfollegräich ofgeschloss huet.

Dank dësen zwee Punkte gesäit de séchere Algorithmus fir eis Deployment esou aus.

1. Den Entwéckler montéiert en neie Package vu Code (fir eis ass dëst RPM), testt et an der Dev-Ëmfeld, testt et an der Bühn, a léisst et am Bühnrepository.
2. Den Entwéckler setzt d'Aufgab fir d'Deployment mat der detailléierter Beschreiwung vun den "Artefakte": d'Versioun vum neie Package, eng Beschreiwung vun der neier Funktionalitéit an aner Detailer iwwer d'Deployment wann néideg.
3. De Systemadministrator fänkt den Update un. Lancéiert d'Ansible Playbook, wat am Tour déi folgend mécht:
   • Huelt e Package aus dem Stage Repository a benotzt et fir d'Versioun vum Package am Produktrepository ze aktualiséieren.
   • Kompiléiert eng Lëscht vu Backends vum aktualiséierten Service.
   • Schalt den éischte Service deen an HAProxy aktualiséiert gëtt a waart op seng Prozesser fäerdeg ze lafen. Dank engem graziéisen Shutdown si mir zouversiichtlech datt all aktuell Clientsufroen erfollegräich ofgeschloss ginn.
   • Nodeems d'API an d'Aarbechter komplett gestoppt sinn, an HAProxy ausgeschalt ass, gëtt de Code aktualiséiert.
   • Ansible leeft Servicer.
   • Fir all Service gi bestëmmte "Griffen" gezunn, déi Eenheetstestung op enger Rei vu virdefinéierte Schlësseltester ausféieren. Eng Basiskontroll vum neie Code fënnt statt.
   • Wa keng Feeler am virege Schrëtt fonnt goufen, gëtt de Backend aktivéiert.
   • Loosst eis op den nächste Backend goen.
4. Nodeems all Backends aktualiséiert ginn, ginn funktionell Tester gestart. Wann se fehlen, da kuckt den Entwéckler all nei Funktionalitéit déi hien erstallt huet.

Dëst fäerdeg den Ofbau.

Service Update Zyklus

Dëse Schema géif net funktionnéieren wa mir keng Regel hätten. Mir ënnerstëtzen souwuel déi al an nei Versiounen am Kampf. Am Viraus, an der Etapp vun der Softwareentwécklung, ass festgeluecht datt och wann et Ännerungen an der Servicedatenbank sinn, se de fréiere Code net briechen. Als Resultat gëtt de Codebasis graduell aktualiséiert.

Konklusioun

Meng eege Gedanken iwwer eng Feeler-tolerant WEB Architektur deelen, wëll ech nach eng Kéier seng Schlësselpunkte notéieren:

• kierperlech Feeler Toleranz;
• Reseau Feeler Toleranz (Balancer, BGP);
• Feeler Toleranz vun der Software benotzt an entwéckelt.

Stabil Uptime jiddereen!

Source: will.com