{"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\/hu\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Hogyan val\u00f3sul meg a hibamentes webarchitekt\u00fara a Mail.ru Cloud Solutions platformon.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hogyan
\n
\nHell\u00f3, Habr! Artem Karamyshev vagyok, a rendszeradminisztr\u00e1ci\u00f3s csapat vezet\u0151je. Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Az el\u0151z\u0151 \u00e9vben sok \u00faj term\u00e9k ind\u00edt\u00e1sa t\u00f6rt\u00e9nt. C\u00e9lunk az volt, hogy az API-szolg\u00e1ltat\u00e1sok k\u00f6nnyen m\u00e9retezhet\u0151ek, hibat\u0171r\u0151ek \u00e9s k\u00e9szen \u00e1lljanak a felhaszn\u00e1l\u00f3i terhel\u00e9s gyors n\u00f6veked\u00e9s\u00e9re. Platformunk az OpenStackra \u00e9p\u00fcl, \u00e9s szeretn\u00e9m elmondani, milyen hibat\u0171r\u0151s\u00e9ggel kapcsolatos probl\u00e9m\u00e1kat kellett megoldanunk ahhoz, hogy egy hibat\u0171r\u0151 rendszerhez jussunk. Azt hiszem, ez \u00e9rdekes lesz azok sz\u00e1m\u00e1ra is, akik szint\u00e9n OpenStack alap\u00fa term\u00e9keket fejlesztenek.<\/p>\n

A platform hibat\u0171r\u00e9se a komponenseinek stabilit\u00e1s\u00e1b\u00f3l \u00e1ll \u00f6ssze. \u00cdgy fokozatosan v\u00e9gigmegy\u00fcnk azokon a szinteken, ahol kock\u00e1zatokat \u00e9szlelt\u00fcnk \u00e9s megoldottuk \u0151ket.<\/p>\n

A t\u00f6rt\u00e9net vide\u00f3v\u00e1ltozat\u00e1t, amelynek forr\u00e1sa az Uptime Day 4 konferenci\u00e1n elhangzott el\u0151ad\u00e1s, ITSumma<\/a><\/noindex>, megtekinthet\u0151 az Uptime Community YouTube-csatorn\u00e1n.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

A fizikai architekt\u00fara hibat\u0171r\u00e9se<\/h2>\n

\nA MCS k\u00f6dnek jelenlegi nyilv\u00e1nos r\u00e9sze k\u00e9t Tier III szint\u0171 adatk\u00f6zpontban tal\u00e1lhat\u00f3, k\u00f6zt\u00fck saj\u00e1t s\u00f6t\u00e9t sz\u00e1lat biztos\u00edtunk, amely k\u00fcl\u00f6nb\u00f6z\u0151 \u00fatvonalakon, 200 Gbit\/s s\u00e1vsz\u00e9less\u00e9ggel van fenntartva. A Tier III szint biztos\u00edtja a fizikai infrastrukt\u00fara hibat\u0171r\u00e9s\u00e9hez sz\u00fcks\u00e9ges szintet. <\/p>\n

A s\u00f6t\u00e9t sz\u00e1lat mind fizikai, mind pedig logikai szinten fenntartj\u00e1k. A csatorn\u00e1k fenntart\u00e1si folyamata iterat\u00edv volt, felmer\u00fcltek probl\u00e9m\u00e1k, \u00e9s folyamatosan jav\u00edtjuk az adatk\u00f6zpontok k\u00f6z\u00f6tti kapcsolatot. <\/p>\n

P\u00e9ld\u00e1ul nemr\u00e9giben, amikor egy adatk\u00f6zpont k\u00f6zel\u00e9ben egy akn\u00e1ban dolgoztunk, egy g\u00e9p \u00e1s\u00e1sakor \u00e1tszak\u00edtott egy cs\u00f6vet, amelyben mind a f\u0151, mind a tartal\u00e9k optikai k\u00e1bel volt. A hibat\u0171r\u0151 kapcsolatunk az adatk\u00f6zponttal egy ponton sebezhet\u0151v\u00e9 v\u00e1lt, az akn\u00e1ban. Ennek megfelel\u0151en elvesztett\u00fck az infrastrukt\u00fara egy r\u00e9sz\u00e9t. Levontuk a k\u00f6vetkeztet\u00e9seket, int\u00e9zkedt\u00fcnk, t\u00f6bbek k\u00f6z\u00f6tt egy tov\u00e1bbi optikai k\u00e1belt fektett\u00fcnk le a szomsz\u00e9dos akn\u00e1ban.<\/p><\/blockquote>\n

\nA d\u00e1tk\u00f6zpontokban vannak a szolg\u00e1ltat\u00f3k jelenl\u00e9t\u00e9t jelz\u0151 pontok, amelyeknek a BGP-n kereszt\u00fcl k\u00f6zvet\u00edtj\u00fck a prefixeinket. Minden h\u00e1l\u00f3zati ir\u00e1nyhoz a legjobb metrik\u00e1t v\u00e1lasztjuk, ami lehet\u0151v\u00e9 teszi, hogy k\u00fcl\u00f6nb\u00f6z\u0151 \u00fcgyfelek a legjobb kapcsolatmin\u0151s\u00e9get \u00e9lvezhess\u00e9k. Ha az egyik szolg\u00e1ltat\u00f3 kapcsolata megszakad, \u00fajra\u00e9p\u00edtj\u00fck az \u00fatv\u00e1laszt\u00e1st a rendelkez\u00e9sre \u00e1ll\u00f3 szolg\u00e1ltat\u00f3kon kereszt\u00fcl.<\/p>\n

Ha a szolg\u00e1ltat\u00f3 m\u0171k\u00f6d\u00e9se le\u00e1ll, automatikusan \u00e1tv\u00e1ltunk a k\u00f6vetkez\u0151re. Ha az egyik adatk\u00f6zpont le\u00e1ll, van egy t\u00fck\u00f6rm\u00e1solatunk a szolg\u00e1ltat\u00e1sainkr\u00f3l a m\u00e1sodik adatk\u00f6zpontban, amely \u00e1tveszi az \u00f6sszes terhel\u00e9st.<\/p>\n

\"Hogyan
\nA fizikai infrastrukt\u00fara magas rendelkez\u00e9sre \u00e1ll\u00e1s\u00fa<\/i><\/p>\n

Mit haszn\u00e1lunk az alkalmaz\u00e1sok szintj\u00e9n a magas rendelkez\u00e9sre \u00e1ll\u00e1s biztos\u00edt\u00e1s\u00e1ra<\/h2>\n

\nSzolg\u00e1ltat\u00e1sunk sz\u00e1mos ny\u00edlt forr\u00e1sk\u00f3d\u00fa komponensre \u00e9p\u00fcl. <\/p>\n

ExaBGP<\/b> \u2014 olyan szolg\u00e1ltat\u00e1s, amely sz\u00e1mos funkci\u00f3t val\u00f3s\u00edt meg a BGP alap\u00fa dinamikus \u00fatv\u00e1laszt\u00e1si protokoll haszn\u00e1lat\u00e1val. Akt\u00edvan haszn\u00e1ljuk, hogy bejelents\u00fck a feh\u00e9r IP-c\u00edmeinket, amelyeken kereszt\u00fcl a felhaszn\u00e1l\u00f3k hozz\u00e1f\u00e9rnek az API-hoz.<\/p>\n

HAProxy<\/b> \u2014 nagy terhel\u00e9s\u0171 terhel\u00e9seloszt\u00f3, amely lehet\u0151v\u00e9 teszi a forgalom nagyon rugalmas szab\u00e1lyainak be\u00e1ll\u00edt\u00e1s\u00e1t az OSI modell k\u00fcl\u00f6nb\u00f6z\u0151 szintjein. Ezt haszn\u00e1ljuk az \u00f6sszes szolg\u00e1ltat\u00e1sunk, mint p\u00e9ld\u00e1ul adatb\u00e1zisok, \u00fczenetk\u00f6zvet\u00edt\u0151k, API-szolg\u00e1ltat\u00e1sok, webszolg\u00e1ltat\u00e1sok \u00e9s bels\u0151 projektjeink terhel\u00e9seloszt\u00e1s\u00e1ra \u2014 minden a HAProxy m\u00f6g\u00f6tt \u00e1ll.<\/p>\n

API alkalmaz\u00e1s<\/b> \u2014 webalkalmaz\u00e1s, amelyet Pythonban \u00edrtak, \u00e9s amellyel a felhaszn\u00e1l\u00f3 kezelheti az infrastrukt\u00far\u00e1j\u00e1t \u00e9s a szolg\u00e1ltat\u00e1s\u00e1t.<\/p>\n

Worker alkalmaz\u00e1s <\/b>(tov\u00e1bbiakban egyszer\u0171en worker) \u2014 az OpenStack szolg\u00e1ltat\u00e1sokban ez egy infrastrukt\u00fara d\u00e9mon, amely lehet\u0151v\u00e9 teszi az API-parancsok k\u00f6zvet\u00edt\u00e9s\u00e9t az infrastrukt\u00far\u00e1ra. P\u00e9ld\u00e1ul a lemez l\u00e9trehoz\u00e1sa a workerben t\u00f6rt\u00e9nik, m\u00edg a l\u00e9trehoz\u00e1si k\u00e9r\u00e9s az API alkalmaz\u00e1sban zajlik. <\/p>\n

OpenStack alkalmaz\u00e1s standard architekt\u00far\u00e1ja<\/h2>\n

\nA legt\u00f6bb szolg\u00e1ltat\u00e1s, amely OpenStack alatt k\u00e9sz\u00fcl, megpr\u00f3b\u00e1l egy egys\u00e9ges paradigm\u00e1t k\u00f6vetni. A szolg\u00e1ltat\u00e1s \u00e1ltal\u00e1ban k\u00e9t r\u00e9szb\u0151l \u00e1ll: API-b\u00f3l \u00e9s worker-ekb\u0151l (h\u00e1tt\u00e9rfeldolgoz\u00f3k). \u00c1ltal\u00e1ban az API egy Python alap\u00fa WSGI-app, amely vagy \u00f6n\u00e1ll\u00f3 folyamatk\u00e9nt (daemon) fut, vagy egy m\u00e1r megl\u00e9v\u0151 webkiszolg\u00e1l\u00f3, p\u00e9ld\u00e1ul Nginx vagy Apache seg\u00edts\u00e9g\u00e9vel. Az API feldolgozza a felhaszn\u00e1l\u00f3i k\u00e9r\u00e9seket, \u00e9s \u00e1tadja a tov\u00e1bbi utas\u00edt\u00e1sokat a worker alkalmaz\u00e1snak. Az \u00e1tad\u00e1st \u00fczenetbroker v\u00e9gzi, \u00e1ltal\u00e1ban RabbitMQ, a t\u00f6bbi kev\u00e9sb\u00e9 t\u00e1mogatott. Amikor az \u00fczenetek a brokerhez \u00e9rkeznek, azokat a worker-ek feldolgozz\u00e1k \u00e9s sz\u00fcks\u00e9g eset\u00e9n v\u00e1laszt adnak. <\/p>\n

Ez a paradigma elszigetelt k\u00f6z\u00f6s meghib\u00e1sod\u00e1si pontokat felt\u00e9telez: RabbitMQ \u00e9s az adatb\u00e1zis. Ugyanakkor a RabbitMQ egy szolg\u00e1ltat\u00e1son bel\u00fcl izol\u00e1lva van, \u00e9s elvileg egyedi lehet minden szolg\u00e1ltat\u00e1s sz\u00e1m\u00e1ra. Teh\u00e1t az MCS-n\u00e9l maxim\u00e1lisan sz\u00e9tv\u00e1lasztjuk ezeket a szolg\u00e1ltat\u00e1sokat, minden k\u00fcl\u00f6n projekt sz\u00e1m\u00e1ra k\u00fcl\u00f6n adatb\u00e1zist \u00e9s k\u00fcl\u00f6n RabbitMQ-t hozunk l\u00e9tre. Ez a megk\u00f6zel\u00edt\u00e9s el\u0151ny\u00f6s, mert ha valamilyen sebezhet\u0151 ponton hiba l\u00e9p fel, akkor nem az eg\u00e9sz szolg\u00e1ltat\u00e1s, hanem csak a r\u00e9sze hib\u00e1sodik meg.<\/p>\n

A worker alkalmaz\u00e1sok sz\u00e1ma semmilyen m\u00f3don nincs korl\u00e1tozva, \u00edgy az API k\u00f6nnyen horizont\u00e1lisan sk\u00e1l\u00e1zhat\u00f3 a terhel\u00e9seloszt\u00f3k m\u00f6g\u00f6tt a teljes\u00edtm\u00e9ny \u00e9s a hibat\u0171r\u00e9s n\u00f6vel\u00e9se \u00e9rdek\u00e9ben.<\/p>\n

N\u00e9h\u00e1ny szolg\u00e1ltat\u00e1sn\u00e1l sz\u00fcks\u00e9ges a koordin\u00e1ci\u00f3 a szolg\u00e1ltat\u00e1son bel\u00fcl - amikor bonyolult \u00f6sszetett m\u0171veletek zajlanak az API \u00e9s a munk\u00e1sok k\u00f6z\u00f6tt. Ilyen esetben egy k\u00f6zponti koordin\u00e1ci\u00f3s k\u00f6zpontot haszn\u00e1lunk, egy klaszterezett rendszert, mint p\u00e9ld\u00e1ul Redis, Memcache, etcd, amely lehet\u0151v\u00e9 teszi, hogy az egyik munk\u00e1s jelezze a m\u00e1siknak, hogy ez a feladat r\u00e1 van b\u00edzva (\u201ek\u00e9rlek, ne vedd el\u201d). Mi az etcd-t haszn\u00e1ljuk. \u00c1ltal\u00e1ban a munk\u00e1sok akt\u00edvan kommunik\u00e1lnak az adatb\u00e1zissal, olvasnak \u00e9s \u00edrnak onnan inform\u00e1ci\u00f3t. Az adatb\u00e1zisk\u00e9nt a mariadb-t haszn\u00e1ljuk, amely a multimaster klaszter\u00fcnkben tal\u00e1lhat\u00f3.\n<\/p><\/blockquote>\n

\nEz a klasszikus egyedi szolg\u00e1ltat\u00e1s az OpenStack sz\u00e1m\u00e1ra elterjedt m\u00f3don van megszervezve. Z\u00e1rt rendszerk\u00e9nt tekinthet\u0151, amely sz\u00e1m\u00e1ra a sk\u00e1l\u00e1z\u00e1s \u00e9s a hibat\u0171r\u00e9s m\u00f3dszerei nyilv\u00e1nval\u00f3ak. P\u00e9ld\u00e1ul az API hibat\u0171r\u00e9s\u00e9hez elegend\u0151, ha egy terhel\u00e9seloszt\u00f3t helyez\u00fcnk el\u00e9j\u00fck. A worker-ek sk\u00e1l\u00e1z\u00e1sa a sz\u00e1muk n\u00f6vel\u00e9s\u00e9vel \u00e9rhet\u0151 el. <\/p>\n

A RabbitMQ \u00e9s a MariaDB a rendszeren bel\u00fcli gyenge l\u00e1ncsok. \u00c9p\u00edtkez\u00e9s\u00fck k\u00fcl\u00f6n t\u00e9m\u00e1t \u00e9rdemel. Ebben a cikkben az API megb\u00edzhat\u00f3s\u00e1g\u00e1ra szeretn\u00e9k \u00f6sszpontos\u00edtani.<\/p>\n

\"Hogyan
\nOpenstack Application architekt\u00fara. A felh\u0151platform egyens\u00falyba \u00e1ll\u00edt\u00e1sa \u00e9s megb\u00edzhat\u00f3s\u00e1g\u00e1nak biztos\u00edt\u00e1sa.<\/i><\/p>\n

Hozzuk l\u00e9tre a HAProxy egyens\u00falyoz\u00f3t megb\u00edzhat\u00f3v\u00e1 az ExaBGP seg\u00edts\u00e9g\u00e9vel.<\/h2>\n

\nAhhoz, hogy API-jaink sk\u00e1l\u00e1zhat\u00f3ak, gyorsak \u00e9s megb\u00edzhat\u00f3ak legyenek, egy egyens\u00falyoz\u00f3t \u00e1ll\u00edtottunk el\u00e9j\u00fck. A HAProxy-ra esett a v\u00e1laszt\u00e1sunk. Szerintem rendelkezik minden sz\u00fcks\u00e9ges jellemz\u0151vel a feladatunkhoz: t\u00f6bb OSI szint\u0171 egyens\u00falyoz\u00e1s, kezel\u0151fel\u00fclet, rugalmass\u00e1g \u00e9s sk\u00e1l\u00e1zhat\u00f3s\u00e1g, sz\u00e1mos egyens\u00falyoz\u00e1si m\u00f3dszer, session t\u00e1bl\u00e1k t\u00e1mogat\u00e1s\u00e1val.<\/p>\n

Az els\u0151 probl\u00e9ma, amelyet meg kellett oldani, a balanc\u00e9r\u00e1l\u00f3 megb\u00edzhat\u00f3s\u00e1ga volt. Csak a balanc\u00e9r\u00e1l\u00f3 telep\u00edt\u00e9se is l\u00e9trehoz egy kies\u00e9si pontot: ha a balanc\u00e9r\u00e1l\u00f3 elromlik, a szolg\u00e1ltat\u00e1s megsz\u0171nik. Ennek elker\u00fcl\u00e9s\u00e9re a HAProxy-t egy\u00fctt haszn\u00e1ltuk az ExaBGP-vel.<\/p>\n

Az ExaBGP lehet\u0151v\u00e9 teszi a szolg\u00e1ltat\u00e1s \u00e1llapot\u00e1nak ellen\u0151rz\u00e9si mechanizmus\u00e1nak megval\u00f3s\u00edt\u00e1s\u00e1t. Ezt a mechanizmust arra haszn\u00e1ltuk, hogy ellen\u0151rizz\u00fck a HAProxy m\u0171k\u00f6d\u00e9s\u00e9t, \u00e9s probl\u00e9m\u00e1k eset\u00e9n le\u00e1ll\u00edtsuk a HAProxy szolg\u00e1ltat\u00e1st a BGP-b\u0151l. <\/p>\n

ExaBGP+HAProxy s\u00e9ma.<\/b><\/p>\n

    \n
  1. H\u00e1rom szerverre telep\u00edtj\u00fck a sz\u00fcks\u00e9ges szoftvert, az ExaBGP-t \u00e9s a HAProxy-t. <\/li>\n
  2. Minden egyes szerveren l\u00e9trehozzuk a loopback interf\u00e9szt.<\/li>\n
  3. Mindh\u00e1rom szerveren be\u00e1ll\u00edtjuk ugyanazt a nyilv\u00e1nos IP-c\u00edmet erre az interf\u00e9szre.<\/li>\n
  4. A nyilv\u00e1nos IP-c\u00edm az ExaBGP-n kereszt\u00fcl ker\u00fcl bejelent\u00e9sre az interneten. <\/li>\n<\/ol>\n

    \nA megb\u00edzhat\u00f3s\u00e1got az jelenti, hogy ugyanazt az IP-c\u00edmet hirdetj\u00fck h\u00e1rom k\u00fcl\u00f6nb\u00f6z\u0151 szerveren. H\u00e1l\u00f3zati szempontb\u00f3l ugyanaz a c\u00edm, h\u00e1rom k\u00fcl\u00f6nb\u00f6z\u0151 next hop-b\u00f3l \u00e9rhet\u0151 el. A router h\u00e1rom azonos \u00fatvonalat l\u00e1t, az \u00f6n\u00e1ll\u00f3 metrik\u00e1ja alapj\u00e1n v\u00e1lasztja ki a legpriorit\u00e1sosabbat (ez \u00e1ltal\u00e1ban ugyanaz a lehet\u0151s\u00e9g), \u00e9s a forgalom csak az egyik szerverre ir\u00e1nyul. <\/p>\n

    HAProxy m\u0171k\u00f6d\u00e9si probl\u00e9m\u00e1i vagy a szerver kies\u00e9se eset\u00e9n az ExaBGP le\u00e1ll\u00edtja az \u00fatvonal hirdet\u00e9s\u00e9t, \u00e9s a forgalom sim\u00e1n egy m\u00e1sik szerverre v\u00e1lt. <\/p>\n

    \u00cdgy siker\u00fclt el\u00e9rni a balanc\u00e9r\u00e1l\u00f3 megb\u00edzhat\u00f3s\u00e1g\u00e1t.<\/p>\n

    \"Hogyan
    \nHAProxy egyens\u00falyoz\u00f3k megb\u00edzhat\u00f3s\u00e1ga.<\/i><\/p>\n

    A s\u00e9ma nem t\u00f6k\u00e9letes: megtanultuk a HAProxy tartal\u00e9kos\u00edt\u00e1s\u00e1t, de nem tanultuk meg a terhel\u00e9s eloszt\u00e1s\u00e1t a szolg\u00e1ltat\u00e1sok k\u00f6z\u00f6tt. Ez\u00e9rt a s\u00e9m\u00e1t egy kicsit kib\u0151v\u00edtett\u00fck: \u00e1t\u00e1lltunk a t\u00f6bb nyilv\u00e1nos IP-c\u00edm k\u00f6z\u00f6tti egyens\u00falyoz\u00e1sra.<\/p>\n

    DNS-alap\u00fa terhel\u00e9seloszt\u00e1s + BGP<\/h2>\n

    \nA HAProxy el\u0151tt l\u00e9v\u0151 terhel\u00e9seloszt\u00e1s probl\u00e9m\u00e1ja tov\u00e1bbra is megoldatlan. Ugyanakkor ezt el\u00e9g egyszer\u0171en meg lehet oldani, ahogyan azt mi is tett\u00fck.<\/p>\n

    H\u00e1rom szerver terhel\u00e9seloszt\u00e1s\u00e1hoz 3 feh\u00e9r IP-c\u00edmre \u00e9s a r\u00e9gi, j\u00f3 DNS-re lesz sz\u00fcks\u00e9g. Mindegyik c\u00edmet a HAProxy-k loopback interf\u00e9sz\u00e9re kell be\u00e1ll\u00edtani, \u00e9s az interneten be kell jelenteni. <\/p>\n

    Az OpenStackben az er\u0151forr\u00e1sok kezel\u00e9s\u00e9hez szolg\u00e1ltat\u00e1s-katal\u00f3gust haszn\u00e1lunk, amelyben meghat\u00e1rozzuk az egyes szolg\u00e1ltat\u00e1sok API-j\u00e1nak v\u00e9gpontj\u00e1t. Ebben a katal\u00f3gusban megadjuk a domain nevet \u2014 public.infra.mail.ru, amely h\u00e1rom k\u00fcl\u00f6nb\u00f6z\u0151 IP-c\u00edmmel DNS-en kereszt\u00fcl felold\u00f3dik. Ennek eredm\u00e9nyek\u00e9nt terhel\u00e9seloszt\u00e1st kapunk a h\u00e1rom c\u00edm k\u00f6z\u00f6tt DNS-en kereszt\u00fcl. <\/p>\n

    A feh\u00e9r IP-c\u00edmek bejelent\u00e9sekor azonban nem kezelj\u00fck a szerver kiv\u00e1laszt\u00e1si priorit\u00e1sokat, ez nem min\u0151s\u00fcl terhel\u00e9seloszt\u00e1snak. \u00c1ltal\u00e1ban egyetlen szerver lesz kiv\u00e1lasztva az IP-c\u00edmek rangsora alapj\u00e1n, m\u00edg a m\u00e1sik k\u00e9t szerver inakt\u00edv marad, mivel a BGP-ben nincsenek megadva metrik\u00e1k.<\/p>\n

    Megkezdt\u00fck az ExaBGP-n kereszt\u00fcl t\u00f6rt\u00e9n\u0151 \u00fatvonalak hirdet\u00e9s\u00e9t k\u00fcl\u00f6nb\u00f6z\u0151 metrik\u00e1kkal. Minden terhel\u00e9seloszt\u00f3 h\u00e1rom feh\u00e9r IP-c\u00edmet jelent be, de ezek k\u00f6z\u00fcl az egyik, a terhel\u00e9seloszt\u00f3nk f\u0151 IP-c\u00edme, a legalacsonyabb metrik\u00e1val ker\u00fcl hirdet\u00e9sre. \u00cdgy am\u00edg mindh\u00e1rom terhel\u00e9seloszt\u00f3 m\u0171k\u00f6dik, az els\u0151 IP-c\u00edmre \u00e9rkez\u0151 k\u00e9r\u00e9sek az els\u0151 terhel\u00e9seloszt\u00f3ra \u00e9rkeznek, a m\u00e1sodik IP-c\u00edmre \u00e9rkez\u0151k a m\u00e1sodikra, a harmadik pedig a harmadikra.<\/p>\n

    Mi t\u00f6rt\u00e9nik abban a pillanatban, amikor az egyik terhel\u00e9seloszt\u00f3 le\u00e1ll? Ha b\u00e1rmelyik terhel\u00e9seloszt\u00f3 kiesik, a f\u0151 c\u00edm\u00e9t tov\u00e1bbra is a m\u00e1sik kett\u0151 hirdeti, \u00e9s a forgalom \u00fajra lesz elosztva k\u00f6z\u00f6tt\u00fck. \u00cdgy a DNS-en kereszt\u00fcl azonnal t\u00f6bb IP-c\u00edmet adunk a felhaszn\u00e1l\u00f3nak. A DNS-en t\u00f6rt\u00e9n\u0151 terhel\u00e9seloszt\u00e1s \u00e9s a k\u00fcl\u00f6nb\u00f6z\u0151 metrik\u00e1k r\u00e9v\u00e9n egyenletes terhel\u00e9seloszt\u00e1st kapunk az \u00f6sszes h\u00e1rom terhel\u00e9seloszt\u00f3n. Ezzel egy\u00fctt nem vesz\u00edtj\u00fck el a hib\u00e1t\u0171r\u00e9st.<\/p>\n

    \"Hogyan
    \nHAProxy terhel\u00e9seloszt\u00e1s DNS + BGP alap\u00fa<\/i><\/p>\n

    Interakci\u00f3 az ExaBGP \u00e9s HAProxy k\u00f6z\u00f6tt<\/h2>\n

    \nTeh\u00e1t, megval\u00f3s\u00edtottuk a hib\u00e1t\u0171r\u00e9st a szerver le\u00e1ll\u00e1sa eset\u00e9re az \u00fatvonalbejelent\u00e9sek meg\u00e1ll\u00edt\u00e1sa alapj\u00e1n. Azonban a HAProxy m\u00e1s okok miatt is le\u00e1llhat, mint a szerver meghib\u00e1sod\u00e1sa: adminisztr\u00e1ci\u00f3s hib\u00e1k, a szolg\u00e1ltat\u00e1son bel\u00fcli hib\u00e1k. Sz\u00fcks\u00e9g van egy m\u00e1sik mechanizmusra, hogy a hib\u00e1s terhel\u00e9seloszt\u00f3t elt\u00e1vol\u00edtsuk a terhel\u00e9s al\u00f3l ezekben az esetekben. <\/p>\n

    Ez\u00e9rt a kor\u00e1bbi s\u00e9m\u00e1t b\u0151v\u00edtve megval\u00f3s\u00edtottuk a heartbeat-et az ExaBGP \u00e9s a HAProxy k\u00f6z\u00f6tt. Ez a szoftveres megold\u00e1s lehet\u0151v\u00e9 teszi az ExaBGP \u00e9s a HAProxy k\u00f6z\u00f6tti interakci\u00f3t, amikor az ExaBGP testreszabott szkripteket haszn\u00e1l az alkalmaz\u00e1sok \u00e1llapot\u00e1nak ellen\u0151rz\u00e9s\u00e9re.<\/p>\n

    Ehhez az ExaBGP konfigur\u00e1ci\u00f3j\u00e1ban be kell \u00e1ll\u00edtani a health checkert, amely ellen\u0151rzi a HAProxy \u00e1llapot\u00e1t. Eset\u00fcnkben a HAProxy-ban health backend-et \u00e1ll\u00edtottunk be, m\u00edg az ExaBGP oldal\u00e1r\u00f3l egy egyszer\u0171 GET k\u00e9r\u00e9ssel ellen\u0151rz\u00fcnk. Ha a bejelent\u00e9s megsz\u0171nik, akkor val\u00f3sz\u00edn\u0171leg a HAProxy nem m\u0171k\u00f6dik, \u00e9s azt nem kell bejelenteni. <\/p>\n

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

    HAProxy Peers: \u00fcl\u00e9sek szinkroniz\u00e1l\u00e1sa <\/h2>\n

    \nA k\u00f6vetkez\u0151 l\u00e9p\u00e9s az \u00fcl\u00e9s szinkroniz\u00e1l\u00e1sa volt. A k\u00f6zpontos\u00edtott terhel\u00e9seloszt\u00f3k haszn\u00e1lata sor\u00e1n neh\u00e9zs\u00e9get jelent az \u00fcgyf\u00e9l\u00fcl\u00e9sek inform\u00e1ci\u00f3inak meg\u0151rz\u00e9se. Azonban a HAProxy az egyik kev\u00e9s terhel\u00e9seloszt\u00f3, amely lehet\u0151v\u00e9 teszi ezt a Peers funkci\u00f3j\u00e1n kereszt\u00fcl \u2014 lehet\u0151s\u00e9get biztos\u00edt k\u00fcl\u00f6nb\u00f6z\u0151 HAProxy folyamatok k\u00f6z\u00f6tti \u00fcl\u00e9s t\u00e1bl\u00e1k tov\u00e1bb\u00edt\u00e1s\u00e1ra. <\/p>\n

    K\u00fcl\u00f6nb\u00f6z\u0151 terhel\u00e9seloszt\u00e1si m\u00f3dszerek l\u00e9teznek: egyszer\u0171ek, mint p\u00e9ld\u00e1ul k\u00f6rforg\u00e1sos<\/a><\/noindex>, \u00e9s kiterjesztettek, amikor az \u00fcgyf\u00e9l\u00fcl\u00e9st megjegyzik, \u00e9s minden alkalommal ugyanarra a szerverre ir\u00e1ny\u00edtj\u00e1k, mint kor\u00e1bban. Mi a m\u00e1sodik v\u00e1ltozatot szerett\u00fck volna megval\u00f3s\u00edtani.<\/p>\n

    A HAProxy-ban az \u00fcgyf\u00e9l\u00fcl\u00e9sek meg\u0151rz\u00e9s\u00e9re stick-tables mechanizmusa szolg\u00e1l. Ezek meg\u0151rzik az \u00fcgyf\u00e9l eredeti IP-c\u00edm\u00e9t, a v\u00e1lasztott c\u00e9lc\u00edmet (backend) \u00e9s n\u00e9mi seg\u00e9dinform\u00e1ci\u00f3t. \u00c1ltal\u00e1ban a stick-t\u00e1bl\u00e1kat az IP-forr\u00e1s + IP-c\u00e9l p\u00e1r meg\u0151rz\u00e9s\u00e9re haszn\u00e1lj\u00e1k, ami k\u00fcl\u00f6n\u00f6sen hasznos az olyan alkalmaz\u00e1sok eset\u00e9n, amelyek nem tudj\u00e1k tov\u00e1bb\u00edtani a felhaszn\u00e1l\u00f3i \u00fcl\u00e9s kontextus\u00e1t egy m\u00e1sik terhel\u00e9seloszt\u00f3hoz val\u00f3 \u00e1tkapcsol\u00e1skor, p\u00e9ld\u00e1ul k\u00f6rk\u00f6r\u00f6s terhel\u00e9seloszt\u00e1s \u00fczemm\u00f3dban.<\/p>\n

    Ha a stick-t\u00e1bl\u00e1t megtan\u00edtjuk arra, hogy mozogjon a k\u00fcl\u00f6nb\u00f6z\u0151 HAProxy folyamatok k\u00f6z\u00f6tt (amelyek k\u00f6z\u00f6tti terhel\u00e9seloszt\u00e1s t\u00f6rt\u00e9nik), a terhel\u00e9seloszt\u00f3ink egy stick-t\u00e1bl\u00e1kb\u00f3l \u00e1ll\u00f3 egyes\u00edtett halmazzal tudnak dolgozni. Ez lehet\u0151v\u00e9 teszi az \u00fcgyf\u00e9l h\u00e1l\u00f3zat\u00e1nak z\u00f6kken\u0151mentes v\u00e1lt\u00e1s\u00e1t, ha az egyik terhel\u00e9seloszt\u00f3 meghib\u00e1sodik, az \u00fcgyf\u00e9l\u00fcl\u00e9sek a kor\u00e1bban v\u00e1lasztott backendeken folytat\u00f3dnak.<\/p>\n

    A helyes m\u0171k\u00f6d\u00e9s \u00e9rdek\u00e9ben meg kell oldani a terhel\u00e9seloszt\u00f3 forr\u00e1s IP-c\u00edm\u00e9nek probl\u00e9m\u00e1j\u00e1t, ahonnan az \u00fcl\u00e9s l\u00e9trej\u00f6tt. Eset\u00fcnkben ez dinamikus c\u00edm a loopback interf\u00e9szen. <\/p>\n

    A peers megfelel\u0151 m\u0171k\u00f6d\u00e9se csak bizonyos k\u00f6r\u00fclm\u00e9nyek k\u00f6z\u00f6tt val\u00f3sul meg. M\u00e1s sz\u00f3val, a TCP-id\u0151knek el\u00e9g hossz\u00faaknak kell lenni\u00fck, vagy a v\u00e1lt\u00e1soknak el\u00e9g gyorsnak, hogy a TCP-munkamenet ne szakadhasson meg. Ennek ellen\u00e9re lehet\u0151v\u00e9 teszi a z\u00f6kken\u0151mentes v\u00e1lt\u00e1st. <\/p>\n

    IaaS szolg\u00e1ltat\u00e1sunk hasonl\u00f3 technol\u00f3gi\u00e1n alapul. Ez a Load Balancer szolg\u00e1ltat\u00e1s OpenStackhez<\/a><\/noindex>, amelyet Octavia-nak h\u00edvnak. K\u00e9t HAProxy folyamatra \u00e9p\u00fcl, \u00e9s eleve tartalmazza a peers t\u00e1mogat\u00e1s\u00e1t. Ebben a szolg\u00e1ltat\u00e1sban kiv\u00e1l\u00f3an teljes\u00edtettek.<\/p>\n

    A k\u00e9pen diagramon l\u00e1that\u00f3 a peers t\u00e1bl\u00e1k mozgat\u00e1sa a h\u00e1rom HAProxy p\u00e9ld\u00e1ny k\u00f6z\u00f6tt, \u00e9s bemutat\u00e1sra ker\u00fclt a konfigur\u00e1ci\u00f3, hogy ezt hogyan lehet be\u00e1ll\u00edtani:<\/p>\n

    \"Hogyan
    \nHAProxy Peers (munkamenetek szinkroniz\u00e1l\u00e1sa)<\/i><\/p>\n

    Ha hasonl\u00f3 rendszert val\u00f3s\u00edtasz meg, a m\u0171k\u00f6d\u00e9s\u00e9t alaposan tesztelni kell. Nem garant\u00e1lt, hogy ez 100%-osan fog m\u0171k\u00f6dni. De legal\u00e1bb nem fogsz elvesz\u00edteni stick t\u00e1bl\u00e1kat, amikor eml\u00e9kezni kell a kliens forr\u00e1s IP-j\u00e9re.<\/p>\n

    A p\u00e1rhuzamos k\u00e9r\u00e9sek korl\u00e1toz\u00e1sa ugyanatt\u00f3l a kliens-t\u0151l<\/h2>\n

    \nB\u00e1rmely nyilv\u00e1nos el\u00e9rhet\u0151s\u00e9g\u0171 szolg\u00e1ltat\u00e1s, bele\u00e9rtve az API-jainkat, kaphat k\u00e9rd\u00e9sekkel kapcsolatos lavin\u00e1kat. Az okok teljesen k\u00fcl\u00f6nb\u00f6z\u0151ek lehetnek, a felhaszn\u00e1l\u00f3i hib\u00e1kt\u00f3l a c\u00e9lzott t\u00e1mad\u00e1sokig. Id\u0151r\u0151l id\u0151re DDoS t\u00e1mad\u00e1sok \u00e9rnek minket IP-c\u00edmek alapj\u00e1n. A kliensek gyakran hib\u00e1znak a scriptjeikben, mini-DDoS-t eredm\u00e9nyezve.<\/p>\n

    Ak\u00e1rhogy is, sz\u00fcks\u00e9ges a kieg\u00e9sz\u00edt\u0151 v\u00e9delem biztos\u00edt\u00e1sa. Nyilv\u00e1nval\u00f3 megold\u00e1s a k\u00e9r\u00e9sek sz\u00e1m\u00e1nak korl\u00e1toz\u00e1sa az API-hoz, hogy ne pazaroljuk a processzornyi id\u0151t a k\u00e1rt\u00e9kony k\u00e9r\u00e9sek feldolgoz\u00e1s\u00e1ra.<\/p>\n

    Az ilyen korl\u00e1toz\u00e1sok megval\u00f3s\u00edt\u00e1s\u00e1hoz rate limits-t alkalmazunk, amelyeket HAProxy alap\u00fa stick t\u00e1bl\u00e1k seg\u00edts\u00e9g\u00e9vel val\u00f3s\u00edtunk meg. A limitek be\u00e1ll\u00edt\u00e1sa meglehet\u0151sen egyszer\u0171, \u00e9s korl\u00e1tozza a felhaszn\u00e1l\u00f3t az API-hoz int\u00e9zett k\u00e9r\u00e9sek sz\u00e1m\u00e1ban. Az algoritmus megjegyzi a forr\u00e1s IP-t, ahonnan a k\u00e9relmek \u00e9rkeznek, \u00e9s korl\u00e1tozza a p\u00e1rhuzamos k\u00e9r\u00e9sek sz\u00e1m\u00e1t egy felhaszn\u00e1l\u00f3n\u00e1l. Term\u00e9szetesen sz\u00e1m\u00edt\u00e1sba vett\u00fck az API terhel\u00e9s\u00e9nek \u00e1tlagos profilj\u00e1t minden szolg\u00e1ltat\u00e1sn\u00e1l, \u00e9s k\u00f6r\u00fclbel\u00fcl 10-szer nagyobb limitet \u00e1ll\u00edtottunk be. Tov\u00e1bbra is figyelemmel k\u00eds\u00e9rj\u00fck a helyzetet, \u00e9s k\u00e9zben tartjuk a dolgokat.<\/p>\n

    Hogyan n\u00e9z ez ki a gyakorlatban? Vannak \u00fcgyfeleink, akik folyamatosan haszn\u00e1lj\u00e1k az API-jainkat az automatikus sk\u00e1l\u00e1z\u00e1s \u00e9rdek\u00e9ben. Reggel k\u00f6r\u00fclbel\u00fcl k\u00e9tsz\u00e1z-h\u00e1romsz\u00e1z virtu\u00e1lis g\u00e9pet hoznak l\u00e9tre, \u00e9s este k\u00f6zelebb elt\u00e1vol\u00edtj\u00e1k \u0151ket. Az OpenStack keretein bel\u00fcl egy virtu\u00e1lis g\u00e9p l\u00e9trehoz\u00e1sa, valamint PaaS szolg\u00e1ltat\u00e1sokkal egy\u00fctt, legal\u00e1bb 1000 API-k\u00e9r\u00e9s, mivel a szolg\u00e1ltat\u00e1sok k\u00f6z\u00f6tti interakci\u00f3 is API-n kereszt\u00fcl t\u00f6rt\u00e9nik. <\/p>\n

    Az ilyen feladatok \u00e1thelyez\u00e9se jelent\u0151s terhel\u00e9st okoz. Ezt a terhel\u00e9st felm\u00e9rt\u00fck, \u00f6sszegy\u0171jt\u00f6tt\u00fck a napi cs\u00facsokat, megemelt\u00fck \u0151ket t\u00edzszeres\u00e9re, \u00e9s ez lett a rate-limit\u00fcnk. Figyelemmel k\u00eds\u00e9rj\u00fck a helyzetet. Gyakran l\u00e1tunk botokat \u00e9s szkenner programokat, amelyek azt pr\u00f3b\u00e1lj\u00e1k kider\u00edteni, van-e CGA-szkript\u00fcnk, amit futtatni lehet, ezeket akt\u00edvan blokkoljuk.<\/p>\n

    Hogyan lehet \u00e9szrev\u00e9tlen\u00fcl friss\u00edteni a k\u00f3dalapot<\/h2>\n

    \nAz el\u00e9rhet\u0151s\u00e9g biztos\u00edt\u00e1sa \u00e9rdek\u00e9ben ugyan\u00fagy foglalkozunk a k\u00f3dkiad\u00e1s folyamatainak megb\u00edzhat\u00f3s\u00e1g\u00e1val. A kiad\u00e1sok sor\u00e1n el\u0151fordulhatnak hib\u00e1k, de ezek hat\u00e1s\u00e1t a szolg\u00e1ltat\u00e1sok el\u00e9rhet\u0151s\u00e9g\u00e9re minimaliz\u00e1lni lehet.<\/p>\n

    Folyamatosan friss\u00edtj\u00fck szolg\u00e1ltat\u00e1sainkat, \u00e9s biztos\u00edtanunk kell a k\u00f3dalap friss\u00edt\u00e9si folyamat\u00e1t felhaszn\u00e1l\u00f3i hat\u00e1sok n\u00e9lk\u00fcl. Ezt a feladatot siker\u00fclt megoldanunk a HAProxy kezel\u00e9si lehet\u0151s\u00e9geinek \u00e9s a Graceful Shutdown v\u00e9grehajt\u00e1s\u00e1nak felhaszn\u00e1l\u00e1s\u00e1val a szolg\u00e1ltat\u00e1sainkban.<\/p>\n

    Ehhez a feladathoz sz\u00fcks\u00e9ges a terhel\u00e9seloszt\u00f3 kezel\u00e9se \u00e9s a szolg\u00e1ltat\u00e1sok \"helyes\" le\u00e1ll\u00edt\u00e1sa:<\/p>\n