{"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\/et\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Kuidas rakendatakse veakindlat veebiarhitektuuri Mail.ru Cloud Solutions platvormil.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\n
\nTere, Habr! Mina olen Artem Karamy\u0161ev, s\u00fcsteemiadministreerimise meeskonna juht Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Viimase aasta jooksul oleme k\u00e4ivitanud palju uusi tooteid. Soovisime saavutada, et API-teenused oleksid kergesti skaleeritavad, taluvuskatkestuste suhtes vastupidavad ja kiiresti kasvava kasutajakoormuse jaoks valmis. Meie platvorm p\u00f5hineb OpenStackil ning tahan r\u00e4\u00e4kida, milliseid taluvuskatkestuste probleeme pidime lahendama, et saada t\u00f6\u00f6kindel s\u00fcsteem. Arvan, et see huvitab ka neid, kes arendavad tooteid OpenStackil.<\/p>\n

Platvormi kogutaluvuskatkestus tuleneb selle komponentide vastupidavusest. Nii et l\u00e4heme j\u00e4rk-j\u00e4rgult l\u00e4bi k\u00f5ik tasemed, kus me avastasime riske ja lahendasime neid.<\/p>\n

Selle loo videoversiooni, mille algallikaks on ettekande Uptime day 4 konverentsil, korraldas ITSumma<\/a><\/noindex>, saab vaadata Uptime Community YouTube kanalilt<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

F\u00fc\u00fcsilise arhitektuuri taluvuskatkestus<\/h2>\n

\nMCSi avalikuks m\u00f5eldud pilv asub praegu kahes Tier III andmekeskuses, mille vahel on f\u00fc\u00fcsilisel tasandil erinevate marsruutide peal testitud tume kiud, mille l\u00e4bilaskev\u00f5ime on 200 Gbit\/s. Tier III tase tagab vajalikud f\u00fc\u00fcsilise infrastruktuuri t\u00f5rketaluvuse. <\/p>\n

Tume kiud on reserveeritud nii f\u00fc\u00fcsilisel kui ka loogilisel tasandil. Kanalite reserveerimise protsess oli iteratiivne, esines probleeme ja me t\u00e4iustame pidevalt andmekeskuste vahelist \u00fchendust. <\/p>\n

N\u00e4iteks hiljuti, kui t\u00f6\u00f6tati kaevanduses, mis asub \u00fche andmekeskuse l\u00e4hedal, l\u00f5hkus ekskavaator toru, milles asusid nii p\u00f5hja- kui varuoptilised kaablid. Meie andmekeskuse vaheline t\u00f5rketaluv kanal osutus \u00fches punktis, kaevanduses, haavatavaks. Seega kaotasime osa infrastruktuurist. Tehaseime j\u00e4reldusi, tegime mitmeid meetmeid, sealhulgas paigaldasime t\u00e4iendava optika naaberkaevandusse.<\/p><\/blockquote>\n

\nAndme \u0446\u0435\u043d\u0442rites on sidepakkujate kohaloleku punkte, kellele me edastame oma eelistusi BGP kaudu. Iga v\u00f5rgu suunas valitakse parim m\u00f5\u00f5dik, mis v\u00f5imaldab tagada erinevatele klientidele parimat \u00fchenduse kvaliteeti. Kui \u00fchendus \u00fche pakkujaga katkeb, muutume me oma marsruutimist kergesti teiste pakkujate kaudu.<\/p>\n

Teenusepakkuja rikkega juhtudel l\u00fclitume automaatselt j\u00e4rgmiseks. Kui \u00fcks andme keskus eba\u00f5nnestub, on meil teises andme keskuses peegellik koopia meie teenustest, mis v\u00f5tab kogu koormuse enda kanda.<\/p>\n

\"Kuidas
\nF\u00fc\u00fcsilise infrastruktuuri t\u00f5rgeteta t\u00f6\u00f6<\/i><\/p>\n

Mida me kasutame rakendustasandi t\u00f5rgeteta t\u00f6\u00f6 tagamiseks<\/h2>\n

\nMeie teenus p\u00f5hineb mitmetel avatud l\u00e4htekoodiga komponentidel. <\/p>\n

ExaBGP<\/b> \u2014 teenus, mis rakendab mitmeid funktsioone d\u00fcnaamilise marsruutimise protokolli abil BGP raames. Me kasutame seda aktiivselt, et kuulutada v\u00e4lja meie valge IP-aadresse, mille kaudu kasutajad p\u00e4\u00e4sevad juurde API-le.<\/p>\n

HAProxy<\/b> \u2014 k\u00f5rge koormusega laadimisjaotur, mis v\u00f5imaldab seadistada v\u00e4ga paindlikke liikluse jaotamise reegleid erinevatel OSI mudeli tasanditel. Me kasutame seda k\u00f5igi teenuste, nagu andmebaasid, s\u00f5numite vahetajad, API-teenused, veebi-teenused ning meie siseprojektid, tasakaalustamiseks \u2014 k\u00f5ik on HAProxy taga.<\/p>\n

API rakendus<\/b> \u2014 veebirakendus, mis on kirjutatud pythonis, mille abil kasutaja haldab oma infrastruktuuri ja teenuseid.<\/p>\n

T\u00f6\u00f6tleja rakendus <\/b>(edasi on lihtsalt t\u00f6\u00f6tleja) \u2014 OpenStack teenustes on see infrastruktuuri demon, mis v\u00f5imaldab edastada API k\u00e4ske infrastruktuurile. N\u00e4iteks luuakse ketas just t\u00f6\u00f6tlejas, samas kui luua soovitakse API rakenduses. <\/p>\n

OpenStack rakenduse standardarhitektuur<\/h2>\n

\nEnamik teenuseid, mis on v\u00e4lja t\u00f6\u00f6tatud OpenStacki jaoks, p\u00fc\u00fcavad j\u00e4rgida \u00fchtset paradigmat. Teenus koosneb tavaliselt kahest osast: API ja t\u00f6\u00f6tlusprotsessidest (t\u00f6\u00f6tajad). \u00dcldiselt on API WSGI-rakendus Pythonis, mis t\u00f6\u00f6tab kas iseseisva protsessina (daemon) v\u00f5i juba olemasoleva veebiserveri, nagu Nginx v\u00f5i Apache, kaudu. API t\u00f6\u00f6tleb kasutaja p\u00e4ringut ja edastab edasised juhised t\u00f6\u00f6tlusrakendusele. Edastamine toimub s\u00f5numibrokeri kaudu, milleks on tavaliselt RabbitMQ, teised on halvasti toetatud. Kui s\u00f5numid satuvad brookerisse, t\u00f6\u00f6tlevad neid t\u00f6\u00f6tajad ja vajadusel tagastavad vastuse. <\/p>\n

See paradigma eeldab eraldatud \u00fchiseid rikkepunkte: RabbitMQ ja andmebaasi. Ent RabbitMQ on isoleeritud \u00fche teenuse piires ja idee j\u00e4rgi v\u00f5ib see olla iga teenuse jaoks individuaalne. Seet\u00f5ttu jagame MCSis need teenused maksimaalselt, iga eraldi projekti jaoks loome eraldi andmebaasi ja eraldi RabbitMQ. See l\u00e4henemine on hea, kuna h\u00e4daolukorras m\u00f5nes haavatavas punktis ei riku kogu teenust, vaid ainult selle osa.<\/p>\n

Worker application'i arvu pole piiratud, seega saab API h\u00f5lpsasti horisontaalselt r\u00f6\u00f6puda koormuse tasakaalustajate tagaj\u00e4rjel, et suurendada j\u00f5udlust ja h\u00e4davajalikkust.<\/p>\n

M\u00f5nedes teenustes on teenuse sees vajalik koordineerimine \u2014 kui toimuvad keerulised j\u00e4rjestikused toimingud API-de ja t\u00f6\u00f6tlejate vahel. Sellisel juhul kasutatakse \u00fchte koordineerimiskeskust, klastris\u00fcsteemi nagu Redis, Memcache, etcd, mis v\u00f5imaldab \u00fchel t\u00f6\u00f6tlejatel teisele \u00f6elda, et see \u00fclesanne on tema vastutada (\"sa, palun, \u00e4ra tee seda\"). Me kasutame etcd-d. \u00dcldiselt suhtlevad t\u00f6\u00f6tlejad aktiivselt andmebaasiga, kirjutades ja lugedes sealt teavet. Andmebaasina kasutame mariadb-d, mis asub meil multimaster-klastris.\n<\/p><\/blockquote>\n

\nSelline klassikaline \u00fcksikteenus on korraldatud OpenStacki tavap\u00e4rasel viisil. Seda saab vaadelda kui isoleeritud s\u00fcsteemi, mille jaoks on piisavalt selged meetodid skaleerimise ja kriitilisuse tagamiseks. N\u00e4iteks kriitilisuse tagamiseks piisab API-de ette koormustasakaalustaja paigaldamisest. Worker'ite skaleerimine saavutatakse nende arvu suurendamise teel. <\/p>\n

Kogu s\u00fcsteemi n\u00f5rk koht on RabbitMQ ja MariaDB. Nende arhitektuur v\u00e4\u00e4rib eraldi artiklit. Selles artiklis tahan keskenduda API-le ja selle t\u00f5rkekindlusele.<\/p>\n

\"Kuidas
\nOpenStack rakenduse arhitektuur. Pilveplatvormi tasakaalustamine ja t\u00f5rkekindlus.<\/i><\/p>\n

Teeme HAProxy tasakaalustajast t\u00f5rkekindla ExaBGP abil.<\/h2>\n

\nKuna meie API-d peavad olema skaleeritavad, kiire ja t\u00f5rkekindlad, paigaldasime nende ette tasakaalustaja. Valisime HAProxy. Minu arvates omab see k\u00f5iki vajalikke omadusi meie \u00fclesande jaoks: tasakaalustamine mitmetel OSI tasemetel, haldusliides, paindlikkus ja skaleeritavus, suur hulk tasakaalustamismeetodeid, sessioonitabelite toetus.<\/p>\n

Esimene probleem, mille lahendamine oli vajalik, oli tasakaalustaja enda t\u00f5rkekindlus. Lihtne tasakaalustaja paigaldamine loob samuti t\u00f5rkepunkte: kui tasakaalustaja rikki l\u00e4heb \u2013 teenus kukub v\u00e4lja. Selle v\u00e4ltimiseks kasutasime HAProxy koos ExaBGP-ga.<\/p>\n

ExaBGP v\u00f5imaldab teenuse oleku kontrollimise mehhanismi rakendamist. Kasutasime seda mehhanismi HAProxy t\u00f6\u00f6kindluse kontrollimiseks ja probleemide korral HAProxy teenuse BGP-st v\u00e4ljal\u00fclitamiseks. <\/p>\n

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

    \n
  1. Paigaldame kolmele serverile vajaliku tarkvara, ExaBGP ja HAProxy. <\/li>\n
  2. Igal serveril loome loopback-liidese.<\/li>\n
  3. K\u00f5ikidel kolmel serveril m\u00e4\u00e4rame sellele liidesele sama avaliku IP-aadressi.<\/li>\n
  4. Avalikult IP-aadress anoneeritakse internetis l\u00e4bi ExaBGP. <\/li>\n<\/ol>\n

    \nKlienditeenuste t\u00f6\u00f6kindlus saavutatakse, anoneerides sama IP-aadressi k\u00f5igilt kolmest serverist. V\u00f5rgupoolest on sama aadress k\u00e4ttesaadav kolmest erinevast j\u00e4rgmise h\u00fcppena. Router n\u00e4eb kolme sama marsruuti, valib oma m\u00f5\u00f5dikutest l\u00e4htuvalt k\u00f5ige prioriteetsema (mis on tavaliselt sama valik) ja liiklus suunatakse ainult \u00fchte serverisse. <\/p>\n

    Probleemide korral HAProxy t\u00f6\u00f6ga v\u00f5i serveri rikke puhul l\u00f5petab ExaBGP marsruudi anoneerimise ja liiklus suunatakse sujuvalt teisele serverile. <\/p>\n

    Nii oleme saavutanud tasakaalustaja t\u00f6\u00f6kindluse.<\/p>\n

    \"Kuidas
    \nHAProxy tasakaalustajate t\u00f6\u00f6kindlus<\/i><\/p>\n

    Skeem ei osutunud ideaalseteks: me \u00f5ppisime HAProxy varundamisest, kuid mitte koormuse jaotamisest teenuste sees. Seet\u00f5ttu laiendasime skeemi veidi: l\u00e4ksime \u00fcle mitmete valgete IP-aadresside vahelisele tasakaalustamisele.<\/p>\n

    DNS ja BGP p\u00f5hine tasakaalustamine<\/h2>\n

    \nKoormuse tasakaalu k\u00fcsimus meie HAProxy ees j\u00e4i lahendamata. Siiski on sellelahendamine suhteliselt lihtne, nagu me seda enda juures tegime.<\/p>\n

    Kolme serveri tasakaalustamiseks on vajalik 3 valget IP-aadressi ja hea vana DNS. Iga\u00fcks neist aadressidest m\u00e4\u00e4ratakse igale HAProxy'le loopback-liideses ja kuulutatakse internetti. <\/p>\n

    OpenStackis kasutatakse ressursse haldava teenuste katalooge, kus m\u00e4\u00e4ratakse iga teenuse API l\u00f5pp-punkt. Selles kataloogis m\u00e4\u00e4rame domeeninime \u2014 public.infra.mail.ru, mis lahendatakse DNSi kaudu kolme erineva IP-aadressiga. Tulemuseks on koormuse jaotus kolme aadressi vahel DNSi kaudu. <\/p>\n

    Kuna me ei kontrolli serverite valimise prioriteete valgete IP-aadresside kuulutamisel, ei ole see tasakaalustus. \u00dcldiselt valitakse ainult \u00fcks server IP-aadressi vanuse j\u00e4rgi, samas kui kaks teist j\u00e4\u00e4vad ootama, kuna BGP-s ei ole mingeid m\u00f5\u00f5dikuid m\u00e4\u00e4ratud.<\/p>\n

    Oleme hakanud edastama marsruute ExaBGP kaudu erinevate m\u00f5\u00f5dikatega. Iga tasakaalustaja kuulutab k\u00f5ik kolm valget IP-aadressi, kuid \u00fcks neist, mis on antud tasakaalustaja jaoks peamine, kuulutatakse minimaalse m\u00f5\u00f5dikaga. Nii kaua, kui k\u00f5ik kolm tasakaalustajat on t\u00f6\u00f6korras, j\u00f5uavad p\u00e4ringud esimesse IP-aadressi esimesse tasakaalustajasse, teisesse teise ja kolmandasse kolmandasse.<\/p>\n

    Mis juhtub hetkel, kui \u00fcks tasakaalustaja kukub? Kui \u00fckski tasakaalustaja eba\u00f5nnestub, kuulutatakse tema p\u00f5hiadress ikka veel kahe teise kaudu, liiklus nende vahel jaotatakse \u00fcmber. Nii anname kasutajale DNS-i kaudu kohe mitu IP-aadressi. DNS-i tasakaalu ja erinevate m\u00f5\u00f5dikate kaudu saavutan tasakaalustatud koormuse jaotuse k\u00f5igi kolme tasakaalustaja vahel, samal ajal mitte kaotades rikke taluvust.<\/p>\n

    \"Kuidas
    \nHAProxy tasakaalustus DNS-i + BGP baasil<\/i><\/p>\n

    ExaBGP ja HAProxy vaheliseks suhtluseks<\/h2>\n

    \nNii oleme rakendanud talitluse katkestamise v\u00e4ltimist, mis p\u00f5hineb marsruutide anname l\u00f5petamisel. Kuid HAProxy v\u00f5ib sulgeda ka muudel p\u00f5hjustel, kui serveri rike: haldust\u00f5rked, teenuse sisemised probleemid. Soovime eemaldada purunenud koormaja koormusest ka nendes olukordades, ja selleks on vajalik teine mehhanism. <\/p>\n

    Seega, laiendades eelmist skeemi, rakendasime ExaBGP ja HAProxy vahelise heartbeat'i. See on tarkvaraline rakendus, mis v\u00f5imaldab ExaBGP-l kasutada kohandatud skripte rakenduste seisundi kontrollimiseks.<\/p>\n

    Selleks tuleb ExaBGP konfiguratsioonis seadistada health checker, mis suudab kontrollida HAProxy staatust. Meie juhul seadistasime HAProxy-s tervise tagamise taustteenuse, ning ExaBGP-l kontrollime seda lihtsa GET p\u00e4ringu kaudu. Kui anname haru l\u00f5petab, siis on HAProxy t\u00f5en\u00e4oliselt mittetoimiv ning selle reklaamimine ei ole vajalik. <\/p>\n

    \"Kuidas
    \nHAProxy tervisekontroll<\/i><\/p>\n

    HAProxy s\u00f5brad: sessioonide s\u00fcnkroniseerimine <\/h2>\n

    \nJ\u00e4rgmine samm, mis tuli ette v\u00f5tta, oli sessioonide s\u00fcnkroniseerimine. Jaotatud tasakaalustajate kaudu t\u00f6\u00f6tades on keeruline korraldada kliendi sessiooniteabe salvestamist. Kuid HAProxy on \u00fcks v\u00e4heseid tasakaalustajaid, mis suudab seda teha Peers funktsiooni kaudu \u2014 v\u00f5imalus edastada HAProxy erinevate protsesside vahel sessioonitabeleid. <\/p>\n

    On erinevaid tasakaalustamismeetodeid: lihtsad, nagu ring-levi<\/a><\/noindex>, ja t\u00e4iustatud, kus salvestatakse kliendi sessioon ja ta p\u00e4\u00e4seb igal korral samale serverile, kuhu ta enne j\u00f5udis. Soovisime teostada teist varianti.<\/p>\n

    HAProxy-s kasutatakse kliendi sessioonide salvestamiseks selle mehhanismi stick-tables. Need salvestavad kliendi algse IP-aadressi, valitud sihtaadressi (tagasi) ja teatud teenuseteabe. \u00dcksikasjalikult kasutatakse stick-tabeleid paaride source-IP + destination-IP s\u00e4ilitamiseks, mis on eriti kasulik rakenduste jaoks, mis ei suuda edastada kasutaja sessiooni konteksti teisele tasakaalustajale l\u00fclitamisel, n\u00e4iteks \u2014 RoundRobin'i tasakaalustamisre\u017eiimis.<\/p>\n

    Kui stick-tabelit \u00f5petada HAProxy erinevate protsesside vahel liikuma (mille vahel toimub tasakaalustamine), saavad meie tasakaalustajad t\u00f6\u00f6tada \u00fche stick-tabelite kogumiga. See v\u00f5imaldab sujuvat kliendi v\u00f5rgu vahetust, kui \u00fcks tasakaalustajatest viga l\u00e4heb, ning kliendi sessioonid j\u00e4tkuvad juba valitud backend-idel.<\/p>\n

    \u00d5ige t\u00f6\u00f6 tagamiseks peab olema lahendatud tasakaalustaja source IP-aadress, millelt sessioon on loodud. Meie puhul on see d\u00fcnaamiline aadress loopback-liideses. <\/p>\n

    Peers'i \u00f5ige t\u00f6\u00f6 saavutatakse vaid teatud tingimustes. See t\u00e4hendab, et TCP-taimerid peavad olema piisavalt suured v\u00f5i vahetus peab olema piisavalt kiire, et TCP-sessioon ei katkeks. Siiski v\u00f5imaldab see sujuvat vahetust. <\/p>\n

    Meil on IaaS-is teenus, mis on loodud sama tehnoloogia alusel. See Load Balancer kui teenus OpenStackile<\/a><\/noindex>, mida nimetatakse Octaviaks. See p\u00f5hineb kahel HAProxy protsessil ja sellel on esialgselt toetatud peers. Selles teenuses on nad end t\u00f5estanud.<\/p>\n

    Pildil on scheemaatiliselt kujutatud peers-tabelite liikumine kolme HAProxy eksemplari vahel, pakutud on konfiguratsioon, kuidas seda seadistada:<\/p>\n

    \"Kuidas
    \nHAProxy Peers (sessioonide s\u00fcnkroniseerimine)<\/i><\/p>\n

    Kui kavatsete rakendada samasugust skeemi, tuleb selle toimimist hoolikalt testida. Pole kindel, et see t\u00f6\u00f6tab 100% juhtudest samamoodi. Kuid v\u00e4hemalt ei kaota te stick-tabeleid, kui on vajalik meeles pidada kliendi source IP-d.<\/p>\n

    Klassi\u00fclesannete limiit \u00fchelt jaolt kliendilt<\/h2>\n

    \nK\u00f5ik teenused, mis on avalikult k\u00e4ttesaadavad, sealhulgas meie API-d, v\u00f5ivad olla vastuv\u00f5tlikud p\u00e4ringute laviinidele. Nende p\u00f5hjused v\u00f5ivad olla \u00e4\u00e4rmiselt erinevad, alates kasutajate vigadest kuni sihitud r\u00fcnnakuteni. Meid DDoS-itatakse perioodiliselt IP-aadresside kaudu. Klientidel on sageli oma skriptides vigu, tehes meile mini-DDoS-e.<\/p>\n

    Igatahes on vajalik ette n\u00e4htud lisakaitse. Ilmselge lahendus on piirata API p\u00e4ringute arvu ja mitte kulutada protsessorite aega kahjulike p\u00e4ringute t\u00f6\u00f6tlemiseks.<\/p>\n

    Sarnaste piirangute rakendamiseks kasutame rate limiite, mis on korraldatud HAProxy baasil, sama stick-tabelite abil. Limiite seadistatakse piisavalt lihtsalt ja need v\u00f5imaldavad piirata kasutajat API-p\u00e4ringute arvu j\u00e4rgi. Algoritm m\u00e4letab allika IP-aadressi, millelt p\u00e4ringud tulevad, ja piirab sama kasutaja samaaegsete p\u00e4ringute arvu. Loomulikult oleme arvutanud iga teenuse API keskmise koormusprofiili ning seadnud limiidiks \u2248 10 korda rohkem kui see v\u00e4\u00e4rtus. J\u00e4tkame siiani olukorra hoolikat j\u00e4lgimist, hoides k\u00e4e pulsil.<\/p>\n

    Kuidas see praktikas v\u00e4lja n\u00e4eb? Meil on kliente, kes kasutavad pidevalt meie API-sid automaatseks skaleerimiseks. Nad loovad umbes kakssada-kolmsada virtuaalmasinat hommikul ja eemaldavad need \u00f5htul. OpenStacki jaoks virtuaalmasina loomine koos PaaS-teenustega t\u00e4hendab v\u00e4hemalt 1000 API-p\u00e4ringut, kuna teenuste vaheline suhtlus toimub samuti API kaudu. <\/p>\n

    Selliste \u00fclesannete \u00fcmberjaotused tekitavad \u00fcsna suurt koormust. Me oleme selle koormuse hinnanud, kogunud p\u00e4evased tipud, suurendanud need k\u00fcmme korda ja see on saanud meie rate-limiidiks. Me j\u00e4lgime olukorda pidevalt. Sageli n\u00e4eme roboteid, skaneerijaid, kes p\u00fc\u00fcavad uurida, kas meil on m\u00f5ni CGA-skript, mida k\u00e4ivitada, ja me l\u00f5ikame need aktiivselt maha.<\/p>\n

    Kuidas uuendada koodibaasi kasutajatele m\u00e4rkamatult<\/h2>\n

    \nKasutame ka koodide juurutamise tasemel rikekindlust. Juurutamisel v\u00f5ivad tekkida vead, kuid nende m\u00f5ju teenuste k\u00e4ttesaadavusele on v\u00f5imalik minimeerida.<\/p>\n

    Uuendame pidevalt oma teenuseid ja peame tagama koodibaasi uuendamise protsessi kasutajatele m\u00e4rkamatult. Selle \u00fclesande lahendamine on v\u00f5imalik t\u00e4nu HAProxy juhtimise v\u00f5imalustele ja meie teenustes Graceful Shutdown rakendamisele.<\/p>\n

    Selle probleemi lahendamiseks oli vajalik tagada koormuse jaoturi juhtimine ja teenuste '\u00f5ige' v\u00e4ljal\u00fclitamine:<\/p>\n