{"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\/hr\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Kako se implementira visoka dostupnost web arhitekture na platformi Mail.ru Cloud Solutions","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kako
\n
\nBok, Habr! Ja sam Artyom Karamyshev, voditelj tima za sistemsko upravljanje. Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Tijekom protekle godine imali smo mnogo lansiranja novih proizvoda. \u017deljeli smo osigurati da se API usluge lako skaliraju, budu otporne na gre\u0161ke i spremne za brzi rast korisni\u010dkog optere\u0107enja. Na\u0161a platforma je realizirana na OpenStacku, a \u017eelim podijeliti koje smo probleme otpornosti komponenti morali rije\u0161iti kako bismo dobili otporan sustav. Mislim da \u0107e to biti zanimljivo onima koji tako\u0111er razvijaju proizvode na OpenStacku.<\/p>\n

Ukupna otpornost platforme sastoji se od otpornosti njenih komponenata. Tako \u0107emo postupno pro\u0107i kroz sve razine na kojima smo uo\u010dili rizike i rije\u0161ili ih.<\/p>\n

Video verziju ove pri\u010de, koja je proiza\u0161la iz izlaganja na konferenciji Uptime Day 4, organiziranoj ITSumma<\/a><\/noindex>, mo\u017eete pogledati na YouTube kanalu Uptime Community<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Otpornost fizi\u010dke arhitekture<\/h2>\n

\nJavni dio oblaka MCS trenutno se bazira u dva data centra razine Tier III, izme\u0111u kojih postoji vlastita tamna vlakna, rezervirana na fizi\u010dkoj razini raznim rutama, s propusno\u0161\u0107u od 200 Gbit\/s. Razina Tier III osigurava potrebnu razinu otpornosti fizi\u010dke infrastrukture. <\/p>\n

Tamno vlakno je rezervirano kako na fizi\u010dkom, tako i na logi\u010dkom nivou. Proces rezervacije kanala bio je iterativan, pojavili su se problemi, i konstantno pobolj\u0161avamo vezu izme\u0111u data centara. <\/p>\n

Na primjer, nedavno je prilikom radova u \u0161ahtu pored jednog od data centara bager probio cijev, unutar koje su se na\u0161li i glavni i rezervni opti\u010dki kabel. Na\u0161 otporan komunikacijski kanal s data centrom bio je ranjiv na jednom mjestu, u \u0161ahtu. Slijedom toga, izgubili smo dio infrastrukture. Izvukli smo zaklju\u010dke, poduzeli niz mjera, uklju\u010duju\u0107i postavljanje dodatne optike kroz susjedni \u0161aht.<\/p><\/blockquote>\n

\nU podatkovnim centrima postoje prisutne ta\u010dke pru\u017eatelja usluga, kojima emitujemo svoje prefikse putem BGP-a. Za svaki mre\u017eni pravac bira se najbolja metrika, \u0161to omogu\u0107ava da razli\u010diti klijenti imaju najbolje kvalitetne veze. Ako veza preko jednog pru\u017eatelja bude prekinuta, preusmjeravamo svoju routingu preko dostupnih pru\u017eatelja.<\/p>\n

U slu\u010daju kvara na radu pru\u017eatelja automatski se prebacujemo na sljede\u0107eg. U slu\u010daju kvara jednog od podatkovnih centara, imamo oglednu kopiju na\u0161ih usluga u drugom podatkovnom centru, koji preuzima sav teret.<\/p>\n

\"Kako
\nOtpornost fizi\u010dke infrastrukture<\/i><\/p>\n

\u0160to koristimo za otpornost na razini aplikacija<\/h2>\n

\nNa\u0161a usluga je izgra\u0111ena na nizu opensource komponenti. <\/p>\n

ExaBGP<\/b> \u2014 usluga koja implementira niz funkcija koriste\u0107i protokol dinami\u010dkog usmjeravanja temeljenog na BGP-u. Aktivno ga koristimo za ogla\u0161avanje na\u0161ih bijelih IP adresa, putem kojih korisnici pristupaju API-ju.<\/p>\n

Dalje, klijentski zahtjev se slao u HAProxy, koji je rje\u0161avao sljede\u0107e zadatke:<\/b> \u2014 visoko optere\u0107en balancer koji omogu\u0107ava postavljanje vrlo fleksibilnih pravila za ravnote\u017eu prometa na razli\u010ditim razinama OSI modela. Koristimo ga za balansiranje ispred svih usluga: baza podataka, posrednici poruka, API usluge, web usluge, na\u0161i unutarnji projekti \u2014 sve to stoji iza HAProxy.<\/p>\n

API aplikacija<\/b> \u2014 web aplikacija napisana na pythonu, putem koje korisnik upravlja svojom infrastrukturom, svojim uslugama.<\/p>\n

Worker aplikacija <\/b>(dalje jednostavno worker) \u2014 u uslugama OpenStack to je infrastrukturni demon koji omogu\u0107ava emitiranje API komandi na infrastrukturu. Na primjer, stvaranje diska doga\u0111a se upravo u workeru, dok se zahtjev za stvaranje \u0161alje u API aplikaciju. <\/p>\n

Standardna arhitektura OpenStack aplikacije<\/h2>\n

\nVe\u0107ina usluga razvijenih pod OpenStackom nastoji slijediti jedinstvenu paradigmu. Usluga se obi\u010dno sastoji od dva dijela: API-ja i radnika (backend izvr\u0161itelji). API je obi\u010dno WSGI aplikacija napisana u pythonu, koja se pokre\u0107e ili kao samostalni proces (daemon), ili uz pomo\u0107 postoje\u0107eg web servera Nginx ili Apache. API obra\u0111uje korisni\u010dke zahtjeve i proslje\u0111uje dodatne instrukcije radnoj aplikaciji. Proslje\u0111ivanje se vr\u0161i putem posrednika poruka, obi\u010dno RabbitMQ, dok se drugi slabo podr\u017eavaju. Kada poruke stignu do posrednika, njih obra\u0111uju radnici koji u slu\u010daju potrebe vra\u0107aju odgovor. <\/p>\n

Ova paradigma podrazumijeva izolirane zajedni\u010dke to\u010dke neuspjeha: RabbitMQ i bazu podataka. Me\u0111utim, RabbitMQ je izoliran unutar jedne usluge i prema ideji mo\u017ee biti pojedina\u010dan za svaku uslugu. Tako da u MCS-u maksimalno dijelimo ove usluge, za svaki poseban projekt kreiramo posebnu bazu, posebni RabbitMQ. Ovaj pristup ima tu prednost \u0161to u slu\u010daju kvara u nekim ranjivim to\u010dkama ne propada cijela usluga, ve\u0107 samo njezin dio.<\/p>\n

Broj radnih aplikacija nije ograni\u010den, tako da se API mo\u017ee lako horizontalno skalirati iza balancer\u00e2 radi pove\u0107anja performansi i otpornosti na kvarove.<\/p>\n

U nekim servisima potrebna je koordinacija unutar samog servisa \u2014 kada se odvijaju slo\u017eene me\u0111usobne operacije izme\u0111u API-ja i radnika. U ovom slu\u010daju koristi se jedinstveni centar za koordinaciju, klasterski sustav poput Redis, Memcache, etcd, koji omogu\u0107uje jednom radniku da ka\u017ee drugom da je taj zadatak dodijeljen njemu (\u00abti, molim te, ne uzimaj to\u00bb). Mi koristimo etcd. Obi\u010dno radnici aktivno komuniciraju s bazom podataka, \u010ditaju i pi\u0161u informacije. Kao bazu podataka koristimo mariadb koja se nalazi u multimaster klasteru.\n<\/p><\/blockquote>\n

\nTakva klasi\u010dna jedinstvena usluga organizirana je op\u0107eprihva\u0107enim na\u010dinom za OpenStack. Mo\u017ee se smatrati zatvorenim sustavom, za koji su na\u010dini skaliranja i otpornosti na kvarove dovoljno o\u010digledni. Na primjer, za otpornost na kvarove, API-ju je dovoljno postaviti balancer ispred njega. Skaliranje radnika posti\u017ee se pove\u0107anjem njihovog broja. <\/p>\n

Slaba to\u010dka cijele sheme su RabbitMQ i MariaDB. Njihova arhitektura zaslu\u017euje poseban \u010dlanak. U ovom \u010dlanku \u017eelim se fokusirati na otpornost API-ja.<\/p>\n

\"Kako
\nArhitektura Openstack Application. Balansiranje i otpornost oblaka platforme.<\/i><\/p>\n

U\u010dinite HAProxy balansirnik otpornim uz pomo\u0107 ExaBGP.<\/h2>\n

\nKako bi na\u0161i API-ji bili skalabilni, brzi i otporni, postavili smo ispred njih balansirnik. Odabrali smo HAProxy. Po mom mi\u0161ljenju, on ima sve potrebne karakteristike za na\u0161 zadatak: balansiranje na vi\u0161e razina OSI, upravlja\u010dko su\u010delje, fleksibilnost i skalabilnost, veliki broj metoda balansiranja, podr\u0161ku za tablice sesija.<\/p>\n

Prvi problem koji se morao rije\u0161iti je otpornost samog balansirnika. Samo postavljanje balansirnika tako\u0111er stvara to\u010dku otkaza: balansirnik se kvari - usluga pada. Da to ne bi bilo tako, koristili smo HAProxy zajedno sa ExaBGP.<\/p>\n

ExaBGP omogu\u0107uje implementaciju mehanizma provjere stanja usluge. Ovaj mehanizam koristili smo za provjeru funkcionalnosti HAProxy-a i u slu\u010daju problema isklju\u010divanje HAProxy usluge iz BGP-a. <\/p>\n

Shema ExaBGP+HAProxy.<\/b><\/p>\n

    \n
  1. Instaliramo potrebni softver, ExaBGP i HAProxy, na tri poslu\u017eitelja. <\/li>\n
  2. Na svakom od poslu\u017eitelja kreiramo loopback su\u010delje.<\/li>\n
  3. Na sva tri poslu\u017eitelja dodajemo istu javnu IP adresu na to su\u010delje.<\/li>\n
  4. Javna IP adresa ogla\u0161ava se na internetu putem ExaBGP-a. <\/li>\n<\/ol>\n

    \nOtpornost se posti\u017ee ogla\u0161avanjem iste IP adrese sa sva tri poslu\u017eitelja. S mre\u017ene strane, ista adresa dostupna je s tri razli\u010dita next hop-a. Usmjeriva\u010d vidi tri identi\u010dna puta, odabire onaj s najvi\u0161im prioritetom prema vlastitoj metriji (\u0161to je obi\u010dno ista opcija), i promet ide samo na jedan od poslu\u017eitelja. <\/p>\n

    U slu\u010daju problema s radom HAProxy-a ili kvara poslu\u017eitelja, ExaBGP prestaje ogla\u0161avati put, a promet se glatko prebacuje na drugi poslu\u017eitelj. <\/p>\n

    Tako smo postigli otpornost balansirnika.<\/p>\n

    \"Kako
    \nOtpornost HAProxy balansirnika.<\/i><\/p>\n

    Shema nije ispala savr\u0161ena: nau\u010dili smo rezervirati HAProxy, ali nismo nau\u010dili raspodjeljivati optere\u0107enje unutar usluga. Stoga smo ovu shemu malo pro\u0161irili: pre\u0161li smo na balansiranje izme\u0111u nekoliko javnih IP adresa.<\/p>\n

    DNS i BGP temeljen balansiranjem<\/h2>\n

    \nPitanje balansiranja optere\u0107enja ispred na\u0161ih HAProxy jo\u0161 uvijek nije rije\u0161eno. Me\u0111utim, mogu\u0107e ga je jednostavno rije\u0161iti, kao \u0161to smo to u\u010dinili i kod nas.<\/p>\n

    Za balansiranje tri servera potrebna su 3 javne IP adrese i stari dobri DNS. Svaka od tih adresa se definira na loopback su\u010delju svakog HAProxy-a i ogla\u0161ava se na internetu. <\/p>\n

    U OpenStack-u se za upravljanje resursima koristi katalog usluga, u kojem se definira endpoint API-ja svake od usluga. U ovom katalogu upisujemo naziv domene \u2014 public.infra.mail.ru, koji se rije\u0161ava putem DNS-a na tri razli\u010dite IP adrese. Kao rezultat toga, dobivamo raspodjelu optere\u0107enja izme\u0111u tri adrese putem DNS-a. <\/p>\n

    Me\u0111utim, budu\u0107i da prilikom ogla\u0161avanja javnih IP adresa ne upravljamo prioritetima odabira servera, to nije balansiranje. Obi\u010dno \u0107e se odabrati samo jedan server prema redoslijedu IP adrese, dok \u0107e druga dva stajati neiskori\u0161tena, jer nisu navedene nikakve metrike u BGP-u.<\/p>\n

    Po\u010deli smo ogla\u0161avati rute putem ExaBGP-a s razli\u010ditim metrima. Svaki balansirnik ogla\u0161ava sve tri javne IP adrese, ali jedna od njih, glavna za taj balansirnik, ogla\u0161ava se s minimalnom metrikom. Tako dok su svi tri balansirnika u radu, zahtjevi za prvom IP adresom odlaze na prvi balansirnik, zahtjevi za drugom na drugi, a za tre\u0107om na tre\u0107i.<\/p>\n

    \u0160to se doga\u0111a kada jedan od balansirnika padne? U slu\u010daju otkaza bilo kojeg balansirnika, njegova osnovna adresa jo\u0161 uvijek se ogla\u0161ava s dva druga, a promet izme\u0111u njih se preraspodjeljuje. Na taj na\u010din korisniku posredujemo putem DNS-a odmah nekoliko IP adresa. Kroz DNS balansiranje i razli\u010dite metrike dobivamo ravnomjernu raspodjelu optere\u0107enja na sve tri balansirnika. Istovremeno ne gubimo otpornost na otkazivanje.<\/p>\n

    \"Kako
    \nHAProxy balansiranje zasnovano na DNS-u + BGP<\/i><\/p>\n

    Interakcija izme\u0111u ExaBGP-a i HAProxy-a<\/h2>\n

    \nDakle, implementirali smo otpornost na slu\u010daj kraha servera, temeljen na prestanku ogla\u0161avanja ruta. Ali HAProxy mo\u017ee prestati raditi iz drugih razloga osim kvara servera: gre\u0161ke u administraciji, unutarnji kvarovi usluge. \u017delimo isklju\u010diti neispravan balansirnik iz optere\u0107enja i u tim slu\u010dajevima, potreban je drugi mehanizam. <\/p>\n

    Stoga, pro\u0161iruju\u0107i prethodnu shemu, implementirali smo heartbeat izme\u0111u ExaBGP i HAProxy. Ovo je softverska implementacija interakcije izme\u0111u ExaBGP i HAProxy, pri \u010demu ExaBGP koristi prilago\u0111ene skripte za provjeru statusa aplikacija.<\/p>\n

    Za to je potrebno konfigurirati health checker u ExaBGP koji mo\u017ee provjeravati status HAProxy. U na\u0161em slu\u010daju, postavili smo health backend u HAProxy, a s ExaBGP provjeravamo jednostavnim GET zahtjevom. Ako se oglas prestaje doga\u0111ati, tada HAProxy vjerojatno ne radi i nije potrebno ogla\u0161avati ga. <\/p>\n

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

    HAProxy Peers: sinkronizacija sesija <\/h2>\n

    \nSljede\u0107e \u0161to je trebala u\u010diniti je sinkronizacija sesija. Kada radimo kroz distribuirane balansere, te\u0161ko je organizirati pohranu informacija o sesijama klijenata. No, HAProxy je jedan od rijetkih balansira\u010da koji to mo\u017ee u\u010diniti zahvaljuju\u0107i funkcionalnosti Peers \u2014 mogu\u0107nosti prijenosa tablica sesija izme\u0111u razli\u010ditih HAProxy procesa. <\/p>\n

    Postoje razli\u010dite metode balansiranja: jednostavne, kao \u0161to su round-robin<\/a><\/noindex>, i napredne, kada se zapamti sesija klijenta i on svaki put dolazi na isti server kao i prije. \u017deljeli smo implementirati drugu opciju.<\/p>\n

    U HAProxy za pohranu sesija klijenata koristi se stick-tables mehanizam. Oni pohranjuju izvorne IP adrese klijenta, odabranu ciljanju adresu (backend) i odre\u0111ene administrativne informacije. Obi\u010dno se stick-tablice koriste za pohranu para source-IP + destination-IP, \u0161to je posebno korisno za aplikacije koje ne mogu prenijeti kontekst korisni\u010dke sesije prilikom prelaska na drugog balansira\u010da, primjerice \u2014 u RoundRobin na\u010dinu balansiranja.<\/p>\n

    Ako stick-tablicu nau\u010dimo da se kre\u0107e izme\u0111u razli\u010ditih HAProxy procesa (izme\u0111u kojih se doga\u0111a balansiranje), na\u0161i balansirali\u0107i \u0107e mo\u0107i raditi s jednom grupom stick-tablica. Ovo \u0107e omogu\u0107iti neprimjetno prebacivanje mre\u017ee klijenta u slu\u010daju pada jednog od balansira\u010da, a rad sa sesijama klijenata nastavit \u0107e se na istim backendima koji su bili odabrani ranije.<\/p>\n

    Za pravilno funkcioniranje mora biti rije\u0161en problem izvorne IP adrese balansira\u010da s kojeg je uspostavljena sesija. U na\u0161em slu\u010daju, to je dinami\u010dka adresa na loopback su\u010delju. <\/p>\n

    Ispravna funkcija peers posti\u017ee se samo pod odre\u0111enim uvjetima. To zna\u010di da TCP timeouti moraju biti dovoljno dugi ili prebacivanje mora biti dovoljno brzo kako bi se TCP sesija odr\u017eala. Ipak, to omogu\u0107uje neprimjetno prebacivanje. <\/p>\n

    Imamo u IaaS-u uslugu koja je izgra\u0111ena na istoj tehnologiji. To je Load Balancer kao usluga za OpenStack<\/a><\/noindex>, koja se zove Octavia. Oslanja se na dva procesa HAProxy, a podr\u0161ka za peers je prvotno ugra\u0111ena. U ovoj usluzi oni su se odli\u010dno pokazali.<\/p>\n

    Na slici je shematski prikaz prijenosa peers tablica izme\u0111u tri instance HAProxy, predlo\u017een je konfiguracijski primjer kako to mo\u017ee biti postavljeno:<\/p>\n

    \"Kako
    \nHAProxy Peers (synchronizacija sesija)<\/i><\/p>\n

    Ako \u0107ete implementirati sli\u010dnu shemu, rad je potrebno pa\u017eljivo testirati. Nije jamstvo da \u0107e to funkcionirati na isti na\u010din u 100% slu\u010dajeva. No, barem ne\u0107ete gubiti stick-tablice kada je potrebno zapamtiti source IP klijenta.<\/p>\n

    Ograni\u010denje broja istovremenih zahtjeva s istog klijenta<\/h2>\n

    \nBilo koje usluge koje su dostupne na otvorenom, uklju\u010duju\u0107i na\u0161e API-je, mogu biti podlo\u017ene lavinama zahtjeva. Razlozi mogu biti potpuno razli\u010diti, od gre\u0161aka korisnika do ciljanih napada. Periodi\u010dno nas DDoS-aju po IP adresama. Klijenti \u010desto grije\u0161e u svojim skriptama, prave nam mini-DDoS-ove.<\/p>\n

    U svakom slu\u010daju, potrebno je osigurati dodatnu za\u0161titu. O\u010dito rje\u0161enje je ograni\u010diti broj zahtjeva prema API-ju i ne tro\u0161iti procesorsko vrijeme na obradu zlonamjernih zahtjeva.<\/p>\n

    Za implementaciju takvih ograni\u010denja koristimo rate limits, organizirane na temelju HAProxy, uz pomo\u0107 istih stick-tablica. Postavljanje limita je prili\u010dno jednostavno i omogu\u0107uje ograni\u010davanje korisnika po broju zahtjeva prema API-ju. Algoritam pamti source IP s kojeg se \u0161alju zahtjevi i ograni\u010dava broj istovremenih zahtjeva s jednog korisnika. Naravno, izra\u010dunali smo prosje\u010dni profil optere\u0107enja API-ja za svaku uslugu i postavili limit otprilike 10 puta ve\u0107i od te vrijednosti. I dalje pomno pratimo situaciju i dr\u017eimo ruku na pulsu.<\/p>\n

    Kako to izgleda u praksi? Imamo klijente koji neprekidno koriste na\u0161e API-jeve za automatsko skaliranje. Kreiraju otprilike dvjesto do tristo virtualnih ma\u0161ina ujutro i bri\u0161u ih nave\u010der. Za OpenStack, kreiranje virtualne ma\u0161ine, zajedno s PaaS uslugama, uklju\u010duje najmanje 1000 API poziva, budu\u0107i da se interakcija izme\u0111u usluga tako\u0111er odvija putem API-ja. <\/p>\n

    Takvi prijenosi zadataka stvaraju prili\u010dno veliki optere\u0107enje. To optere\u0107enje smo procijenili, prikupili dnevne vrhunce, pove\u0107ali ih deseterostruko, i to je postalo na\u0161 rate-limit. Dr\u017eimo ruku na pulsu. \u010cesto uo\u010davamo robote i skener koji poku\u0161avaju provjeriti imamo li neke CGA skripte koje se mogu pokrenuti, a mi ih aktivno uklanjamo.<\/p>\n

    Kako neprimjetno a\u017eurirati kodnu bazu<\/h2>\n

    \nImplementiramo otpornost na gre\u0161ke i na razini procesa distribucije koda. Tijekom isporuka mo\u017ee do\u0107i do kvarova, ali njihov utjecaj na dostupnost usluga mo\u017ee se minimalizirati.<\/p>\n

    Neprekidno a\u017euriramo svoje usluge i moramo osigurati proces a\u017euriranja kodne baze bez efekta na korisnike. Ovaj problem rije\u0161ili smo koriste\u0107i mogu\u0107nosti upravljanja HAProxy-jem i implementiraju\u0107i Graceful Shutdown u na\u0161im uslugama.<\/p>\n

    Za rje\u0161avanje ovog problema potrebno je osigurati upravljanje ravnote\u017eom optere\u0107enja i \"ispravno\" ga\u0161enje usluga:<\/p>\n