{"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\/cs\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Jak se realizuje odoln\u00e1 webov\u00e1 architektura v platform\u011b Mail.ru Cloud Solutions.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Jak
\n
\nAhoj, Habr! Jsem Artem Karamy\u0161ev, vedouc\u00ed t\u00fdmu spr\u00e1vy syst\u00e9m\u016f. Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Za posledn\u00ed rok jsme spustili mnoho nov\u00fdch produkt\u016f. Cht\u011bli jsme zajistit, aby API slu\u017eby snadno \u0161k\u00e1lovaly, byly odoln\u00e9 v\u016f\u010di v\u00fdpadk\u016fm a p\u0159ipraven\u00e9 na rychl\u00fd n\u00e1r\u016fst u\u017eivatelsk\u00e9ho zat\u00ed\u017een\u00ed. Na\u0161e platforma je postavena na OpenStacku a chci se pod\u011blit o to, jak\u00e9 probl\u00e9my s odolnost\u00ed komponent\u016f jsme museli vy\u0159e\u0161it, abychom z\u00edskali odoln\u00fd syst\u00e9m. Mysl\u00edm, \u017ee to bude zaj\u00edmat i ty, kte\u0159\u00ed vyv\u00edjej\u00ed produkty na OpenStacku.<\/p>\n

Celkov\u00e1 odolnost platformy vych\u00e1z\u00ed z odolnosti jej\u00edch komponent. Tak\u017ee postupn\u011b projdeme v\u0161emi \u00farovn\u011bmi, na kter\u00fdch jsme zjistili rizika a odstranili je.<\/p>\n

Videoverzi tohoto p\u0159\u00edb\u011bhu, jej\u00edm\u017e prvotn\u00edm zdrojem byl p\u0159\u00edsp\u011bvek na konferenci Uptime day 4, po\u0159\u00e1dan\u00e9 ITSumma<\/a><\/noindex>, si m\u016f\u017eete prohl\u00e9dnout na YouTube kan\u00e1lu Uptime Community.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Odolnost fyzick\u00e9 architektury<\/h2>\n

\nVe\u0159ejn\u00e1 \u010d\u00e1st cloudu MCS nyn\u00ed s\u00eddl\u00ed ve dvou datov\u00fdch centrech \u00farovn\u011b Tier III, mezi kter\u00fdmi je vlastn\u00ed temn\u00e1 vl\u00e1kna, rezervovan\u00e1 na fyzick\u00e9 \u00farovni r\u016fzn\u00fdmi trasami, s propustnost\u00ed 200 Gbit\/s. \u00darove\u0148 Tier III zaji\u0161\u0165uje pot\u0159ebnou \u00farove\u0148 odolnosti fyzick\u00e9 infrastruktury. <\/p>\n

Temn\u00e1 vl\u00e1kna jsou rezervov\u00e1na jak na fyzick\u00e9, tak na logick\u00e9 \u00farovni. Proces rezervace kan\u00e1l\u016f byl iterativn\u00ed, objevovaly se probl\u00e9my a neust\u00e1le zlep\u0161ujeme spojen\u00ed mezi datov\u00fdmi centry. <\/p>\n

Nap\u0159\u00edklad ned\u00e1vno p\u0159i pr\u00e1ci v \u0161acht\u011b vedle jednoho z datov\u00fdch center vykop\u00e1vac\u00ed stroj prorazil trubku, uvnit\u0159 t\u00e9to trubky se nach\u00e1zely jak hlavn\u00ed, tak z\u00e1lo\u017en\u00ed optick\u00e9 kabely. Na\u0161e odoln\u00e1 komunika\u010dn\u00ed linka s datov\u00fdm centrem se uk\u00e1zala b\u00fdt zraniteln\u00e1 na jednom m\u00edst\u011b, v \u0161acht\u011b. Bohu\u017eel jsme ztratili \u010d\u00e1st infrastruktury. Pou\u010dili jsme se, podnikli jsme \u0159adu krok\u016f, v\u010detn\u011b polo\u017een\u00ed dodate\u010dn\u00e9 optiky kolem sousedn\u00ed \u0161achty.<\/p><\/blockquote>\n

\nV datov\u00fdch centrech jsou um\u00edst\u011bn\u00ed poskytovatel\u016f komunikace, kter\u00fdm p\u0159en\u00e1\u0161\u00edme na\u0161e prefixy p\u0159es BGP. Pro ka\u017ed\u00fd s\u00ed\u0165ov\u00fd sm\u011br se vyb\u00edr\u00e1 nejlep\u0161\u00ed metrika, co\u017e umo\u017e\u0148uje zajistit r\u016fzn\u00fdm klient\u016fm nejlep\u0161\u00ed kvalitu p\u0159ipojen\u00ed. Pokud dojde k v\u00fdpadku p\u0159ipojen\u00ed p\u0159es jednoho poskytovatele, p\u0159izp\u016fsobujeme na\u0161i routingu dostupn\u00fdm poskytovatel\u016fm.<\/p>\n

V p\u0159\u00edpad\u011b v\u00fdpadku poskytovatele automaticky p\u0159ep\u00edn\u00e1me na dal\u0161\u00edho. V p\u0159\u00edpad\u011b v\u00fdpadku jednoho z datov\u00fdch center m\u00e1me zrcadlovou kopii na\u0161ich slu\u017eeb ve druh\u00e9m datov\u00e9m centru, kter\u00e9 p\u0159eb\u00edraj\u00ed ve\u0161ker\u00e9 zat\u00ed\u017een\u00ed.<\/p>\n

\"Jak
\nOdolnost fyzick\u00e9 infrastruktury<\/i><\/p>\n

Co pou\u017e\u00edv\u00e1me pro odolnost na \u00farovni aplikac\u00ed<\/h2>\n

\nNa\u0161e slu\u017eba je postavena na \u0159ad\u011b komponent\u016f opensource. <\/p>\n

ExaBGP<\/b> \u2014 slu\u017eba, kter\u00e1 implementuje \u0159adu funkc\u00ed pomoc\u00ed protokolu dynamick\u00e9ho sm\u011brov\u00e1n\u00ed zalo\u017een\u00e9ho na BGP. Aktivn\u011b ji pou\u017e\u00edv\u00e1me k oznamov\u00e1n\u00ed na\u0161ich b\u00edl\u00fdch IP adres, p\u0159es kter\u00e9 u\u017eivatel\u00e9 z\u00edsk\u00e1vaj\u00ed p\u0159\u00edstup k API.<\/p>\n

D\u00e1le klientsk\u00fd dotaz vch\u00e1zel do HAProxy, kter\u00e9 \u0159e\u0161ilo n\u00e1sleduj\u00edc\u00ed \u00fakoly:<\/b> \u2014 vysoce zat\u00ed\u017een\u00fd vyva\u017eova\u010d, kter\u00fd umo\u017e\u0148uje nastavovat velmi flexibiln\u00ed pravidla vyva\u017eov\u00e1n\u00ed provozu na r\u016fzn\u00fdch \u00farovn\u00edch modelu OSI. Pou\u017e\u00edv\u00e1me ho k vyva\u017eov\u00e1n\u00ed p\u0159ed v\u0161emi slu\u017ebami: datab\u00e1zemi, zprost\u0159edkovateli zpr\u00e1v, API slu\u017ebami, webov\u00fdmi slu\u017ebami, na\u0161imi intern\u00edmi projekty \u2014 v\u0161echno stoj\u00ed za HAProxy.<\/p>\n

API aplikace<\/b> \u2014 webov\u00e1 aplikace napsan\u00e1 v pythonu, pomoc\u00ed kter\u00e9 u\u017eivatel spravuje svou infrastrukturu, sv\u016fj servis.<\/p>\n

Worker aplikace <\/b>(d\u00e1le jen worker) \u2014 v slu\u017eb\u00e1ch OpenStack je to infrastrukturn\u00ed d\u00e9mon, kter\u00fd umo\u017e\u0148uje p\u0159en\u00e1\u0161et API p\u0159\u00edkazy na infrastrukturu. Nap\u0159\u00edklad, vytvo\u0159en\u00ed disku prob\u00edh\u00e1 pr\u00e1v\u011b v workeru, zat\u00edmco po\u017eadavek na vytvo\u0159en\u00ed \u2014 v API aplikaci. <\/p>\n

Standardn\u00ed architektura OpenStack aplikace<\/h2>\n

\nV\u011bt\u0161ina slu\u017eeb vyv\u00edjen\u00fdch pro OpenStack se sna\u017e\u00ed dodr\u017eovat jednotnou paradigmu. Slu\u017eba obvykle sest\u00e1v\u00e1 ze dvou \u010d\u00e1st\u00ed: API a worker\u016f (vykonavatel\u00e9 backendu). Obecn\u011b je API WSGI aplikace v Pythonu, kter\u00e1 b\u011b\u017e\u00ed bu\u010f jako samostatn\u00fd proces (daemon), nebo pomoc\u00ed ji\u017e p\u0159ipraven\u00e9ho webov\u00e9ho serveru Nginx, Apache. API zpracov\u00e1v\u00e1 po\u017eadavek u\u017eivatele a p\u0159ed\u00e1v\u00e1 dal\u0161\u00ed instrukce k vykon\u00e1n\u00ed aplikaci worker. P\u0159ed\u00e1v\u00e1n\u00ed prob\u00edh\u00e1 pomoc\u00ed zprost\u0159edkovatele zpr\u00e1v, obvykle RabbitMQ, ostatn\u00ed jsou podporov\u00e1ny \u0161patn\u011b. Kdy\u017e zpr\u00e1vy doraz\u00ed do zprost\u0159edkovatele, zpracov\u00e1vaj\u00ed je worke\u0159i a v p\u0159\u00edpad\u011b pot\u0159eby vr\u00e1t\u00ed odpov\u011b\u010f. <\/p>\n

Tato paradigma p\u0159edpokl\u00e1d\u00e1 izolovan\u00e9 spole\u010dn\u00e9 body selh\u00e1n\u00ed: RabbitMQ a datab\u00e1zi. RabbitMQ je izolov\u00e1n v r\u00e1mci jedn\u00e9 slu\u017eby a v ide\u00e1ln\u00edm p\u0159\u00edpad\u011b m\u016f\u017ee b\u00fdt individu\u00e1ln\u00ed pro ka\u017edou slu\u017ebu. V MCS tedy co nejv\u00edce odd\u011blujeme tyto slu\u017eby, pro ka\u017ed\u00fd samostatn\u00fd projekt vytv\u00e1\u0159\u00edme samostatnou datab\u00e1zi, samostatn\u00fd RabbitMQ. Tento p\u0159\u00edstup je dobr\u00fd v tom, \u017ee v p\u0159\u00edpad\u011b havarie na n\u011bjak\u00fdch zraniteln\u00fdch m\u00edstech se neporu\u0161\u00ed cel\u00e1 slu\u017eba, ale pouze jej\u00ed \u010d\u00e1st.<\/p>\n

Po\u010det aplikac\u00ed worker nen\u00ed ni\u010d\u00edm omezen, proto m\u016f\u017ee API snadno horizont\u00e1ln\u011b \u0161k\u00e1lovat za load balancingem za \u00fa\u010delem zv\u00fd\u0161en\u00ed v\u00fdkonu a odolnosti proti selh\u00e1n\u00ed.<\/p>\n

V n\u011bkter\u00fdch slu\u017eb\u00e1ch je nutn\u00e1 koordinace uvnit\u0159 slu\u017eby \u2014 kdy\u017e doch\u00e1z\u00ed k slo\u017eit\u00fdm sekven\u010dn\u00edm operac\u00edm mezi API a pracovn\u00edky. V tomto p\u0159\u00edpad\u011b se pou\u017e\u00edv\u00e1 jednotn\u00e9 centrum koordinace, klastrov\u00fd syst\u00e9m jako Redis, Memcache, etcd, kter\u00fd umo\u017e\u0148uje jednomu pracovn\u00edkovi \u0159\u00edct druh\u00e9mu, \u017ee tato \u00faloha je p\u0159id\u011blena jemu (\u201ety, pros\u00edm, ji neber\u201c). Pou\u017e\u00edv\u00e1me etcd. Obvykle pracovn\u00edci aktivn\u011b komunikuj\u00ed s datab\u00e1z\u00ed, zapisuj\u00ed a \u010dtou z n\u00ed informace. Jako datab\u00e1zi pou\u017e\u00edv\u00e1me mariadb, kter\u00e1 m\u00e1me v multimaster klastru.\n<\/p><\/blockquote>\n

\nTakov\u00e1 klasick\u00e1 samostatn\u00e1 slu\u017eba je organizov\u00e1na obvykl\u00fdm zp\u016fsobem pro OpenStack. M\u016f\u017ee b\u00fdt pova\u017eov\u00e1na za uzav\u0159en\u00fd syst\u00e9m, pro kter\u00fd jsou dost jasn\u00e9 zp\u016fsoby \u0161k\u00e1lov\u00e1n\u00ed a odolnosti proti selh\u00e1n\u00ed. Nap\u0159\u00edklad pro odolnost proti selh\u00e1n\u00ed je dosta\u010duj\u00edc\u00ed um\u00edstit p\u0159ed API load balancer. \u0160k\u00e1lov\u00e1n\u00ed worker\u016f se dosahuje zv\u00fd\u0161en\u00edm jejich po\u010dtu. <\/p>\n

Hlavn\u00ed slabinou cel\u00e9ho syst\u00e9mu jsou RabbitMQ a MariaDB. Jejich architektura si zaslou\u017e\u00ed samostatn\u00fd \u010dl\u00e1nek. V tomto \u010dl\u00e1nku se chci zam\u011b\u0159it na odolnost API.<\/p>\n

\"Jak
\nArchitektura OpenStack Application. Vyva\u017eov\u00e1n\u00ed a odolnost cloudov\u00e9 platformy.<\/i><\/p>\n

Zaji\u0161\u0165ujeme odolnost vyva\u017eova\u010de HAProxy pomoc\u00ed ExaBGP.<\/h2>\n

\nAby na\u0161e API byla \u0161k\u00e1lovateln\u00e1, rychl\u00e1 a odoln\u00e1, nasadili jsme p\u0159ed n\u011b vyva\u017eova\u010d. Zvolili jsme HAProxy. Podle m\u00e9ho n\u00e1zoru m\u00e1 v\u0161echny nezbytn\u00e9 vlastnosti pro n\u00e1\u0161 \u00fakol: vyva\u017eov\u00e1n\u00ed na n\u011bkolika \u00farovn\u00edch OSI, ovl\u00e1dac\u00ed rozhran\u00ed, flexibilitu a \u0161k\u00e1lovatelnost, velk\u00e9 mno\u017estv\u00ed metod vyva\u017eov\u00e1n\u00ed, podporu tabulek sezen\u00ed.<\/p>\n

Prvn\u00ed probl\u00e9m, kter\u00fd bylo t\u0159eba vy\u0159e\u0161it, byla odolnost samotn\u00e9ho vyva\u017eova\u010de. Pouh\u00e9 nasazen\u00ed vyva\u017eova\u010de tak\u00e9 vytv\u00e1\u0159\u00ed kritick\u00e9 m\u00edsto: pokud se vyva\u017eova\u010d porouch\u00e1, slu\u017eba spadne. Abychom tomu p\u0159ede\u0161li, pou\u017eili jsme HAProxy spole\u010dn\u011b s ExaBGP.<\/p>\n

ExaBGP umo\u017e\u0148uje implementovat mechanismus kontroly stavu slu\u017eby. Tento mechanismus jsme pou\u017eili k ov\u011b\u0159ov\u00e1n\u00ed funk\u010dnosti HAProxy a v p\u0159\u00edpad\u011b probl\u00e9m\u016f jsme vypli slu\u017ebu HAProxy z BGP. <\/p>\n

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

    \n
  1. Na t\u0159i servery nainstalujeme pot\u0159ebn\u00fd software, ExaBGP a HAProxy. <\/li>\n
  2. Na ka\u017ed\u00e9m ze server\u016f vytvo\u0159\u00edme loopback rozhran\u00ed.<\/li>\n
  3. Na v\u0161ech t\u0159ech serverech nastav\u00edme na toto rozhran\u00ed stejnou ve\u0159ejnou IP adresu.<\/li>\n
  4. Ve\u0159ejn\u00e1 IP adresa je inzerov\u00e1na na internetu p\u0159es ExaBGP. <\/li>\n<\/ol>\n

    \nOdolnosti dosahujeme inzerov\u00e1n\u00edm stejn\u00e9 IP adresy ze v\u0161ech t\u0159\u00ed server\u016f. Z pohledu s\u00edt\u011b je stejn\u00e1 adresa dostupn\u00e1 ze t\u0159\u00ed r\u016fzn\u00fdch next hop\u016f. Sm\u011brova\u010d vid\u00ed t\u0159i toto\u017en\u00e9 trasy, vyb\u00edr\u00e1 podle sv\u00e9 metriky tu nejprioritn\u011bj\u0161\u00ed (to b\u00fdv\u00e1 obvykle stejn\u00fd variant) a provoz sm\u011b\u0159uje pouze na jeden ze server\u016f. <\/p>\n

    V p\u0159\u00edpad\u011b probl\u00e9m\u016f s funkcionalitou HAProxy nebo v\u00fdpadku serveru ExaBGP p\u0159est\u00e1v\u00e1 inzerovat trasu a provoz se plynule p\u0159epne na jin\u00fd server. <\/p>\n

    T\u00edmto zp\u016fsobem jsme dos\u00e1hli odolnosti vyva\u017eova\u010de.<\/p>\n

    \"Jak
    \nOdolnost vyva\u017eova\u010d\u016f HAProxy.<\/i><\/p>\n

    Sch\u00e9ma se uk\u00e1zalo jako nedokonal\u00e9: nau\u010dili jsme se rezervovat HAProxy, ale nenau\u010dili jsme se rozd\u011blovat z\u00e1t\u011b\u017e v r\u00e1mci slu\u017eeb. Proto jsme tuto sch\u00e9ma m\u00edrn\u011b roz\u0161\u00ed\u0159ili: p\u0159e\u0161li jsme na vyva\u017eov\u00e1n\u00ed mezi n\u011bkolika ve\u0159ejn\u00fdmi IP adresami.<\/p>\n

    DNS zalo\u017een\u00e1 vyv\u00e1\u017eenost plus BGP<\/h2>\n

    \nOt\u00e1zka vyv\u00e1\u017een\u00ed z\u00e1t\u011b\u017ee p\u0159ed na\u0161imi HAProxy st\u00e1le z\u016fst\u00e1v\u00e1 nevyr\u011b\u0161ena. Nicm\u00e9n\u011b, je mo\u017en\u00e9 ji \u0159e\u0161it pom\u011brn\u011b jednodu\u0161e, jak jsme ud\u011blali u n\u00e1s.<\/p>\n

    Pro vyv\u00e1\u017een\u00ed t\u0159\u00ed server\u016f bude pot\u0159eba 3 ve\u0159ejn\u00e9 IP adresy a star\u00fd dobr\u00fd DNS. Ka\u017ed\u00e1 z t\u011bchto adres je p\u0159i\u0159azena k loopback rozhran\u00ed ka\u017ed\u00e9ho HAProxy a je ozn\u00e1mena na internetu. <\/p>\n

    V OpenStacku se pro spr\u00e1vu zdroj\u016f pou\u017e\u00edv\u00e1 katalog slu\u017eeb, ve kter\u00e9m se zad\u00e1v\u00e1 endpoint API ur\u010dit\u00e9 slu\u017eby. V tomto katalogu uv\u00e1d\u00edme dom\u00e9nov\u00e9 jm\u00e9no \u2014 public.infra.mail.ru, kter\u00e9 se pomoc\u00ed DNS p\u0159ekl\u00e1d\u00e1 na t\u0159i r\u016fzn\u00e9 IP adresy. V d\u016fsledku toho z\u00edsk\u00e1v\u00e1me rozlo\u017een\u00ed z\u00e1t\u011b\u017ee mezi t\u0159emi adresami prost\u0159ednictv\u00edm DNS. <\/p>\n

    Ale proto\u017ee p\u0159i ozn\u00e1men\u00ed ve\u0159ejn\u00fdch IP adres ne\u0159\u00edd\u00edme priority volby serveru, zat\u00edm to nen\u00ed vyv\u00e1\u017een\u00ed. Obvykle bude vybr\u00e1n pouze jeden server podle star\u0161\u00edho IP adresy, zat\u00edmco dva dal\u0161\u00ed budou ne\u010dinn\u00e9, proto\u017ee v BGP nejsou specifikov\u00e1ny \u017e\u00e1dn\u00e9 metriky.<\/p>\n

    Za\u010dali jsme p\u0159en\u00e1\u0161et trasy p\u0159es ExaBGP s r\u016fznou metrikou. Ka\u017ed\u00fd vyva\u017eova\u010d ozn\u00e1m\u00ed v\u0161echny t\u0159i ve\u0159ejn\u00e9 IP adresy, ale jedna z nich, hlavn\u00ed pro dan\u00fd vyva\u017eova\u010d, je ozn\u00e1mena s minim\u00e1ln\u00ed metrikou. Tak\u017ee zat\u00edmco v\u0161echny t\u0159i vyva\u017eova\u010de jsou v provozu, po\u017eadavky na prvn\u00ed IP adresu sm\u011b\u0159uj\u00ed na prvn\u00ed vyva\u017eova\u010d, po\u017eadavky na druhou na druh\u00fd, na t\u0159et\u00ed na t\u0159et\u00ed.<\/p>\n

    Co se stane v okam\u017eiku, kdy jeden z vyva\u017eova\u010d\u016f sel\u017ee? P\u0159i selh\u00e1n\u00ed jak\u00e9hokoli vyva\u017eova\u010de je jeho hlavn\u00ed adresa st\u00e1le ozn\u00e1mena z dvou dal\u0161\u00edch, provoz mezi nimi je p\u0159erozd\u011blen. Takto okam\u017eit\u011b nab\u00edz\u00edme u\u017eivateli p\u0159es DNS n\u011bkolik IP adres. Pomoc\u00ed vyv\u00e1\u017een\u00ed na z\u00e1klad\u011b DNS a r\u016fzn\u00e9 metriky p\u0159ib\u00fdv\u00e1me rovnom\u011brn\u011b rozlo\u017eenou z\u00e1t\u011b\u017e na v\u0161echny t\u0159i vyva\u017eova\u010de. A z\u00e1rove\u0148 neztr\u00e1c\u00edme odolnost proti selh\u00e1n\u00ed.<\/p>\n

    \"Jak
    \nVyva\u017eov\u00e1n\u00ed HAProxy na b\u00e1zi DNS + BGP<\/i><\/p>\n

    Interakce mezi ExaBGP a HAProxy<\/h2>\n

    \nTak\u017ee jsme implementovali odolnost v p\u0159\u00edpad\u011b v\u00fdpadku serveru na z\u00e1klad\u011b ukon\u010den\u00ed ozn\u00e1men\u00ed tras. Ale HAProxy m\u016f\u017ee selhat i z dal\u0161\u00edch d\u016fvod\u016f, ne\u017e je v\u00fdpadek serveru: chyby spr\u00e1vy, selh\u00e1n\u00ed uvnit\u0159 slu\u017eby. Chceme vy\u0159adit nefunk\u010dn\u00ed vyva\u017eova\u010d z provozu i v t\u011bchto p\u0159\u00edpadech a pot\u0159ebujeme jin\u00fd mechanismus. <\/p>\n

    Proto tedy, roz\u0161\u00ed\u0159en\u00edm p\u0159edchoz\u00edho syst\u00e9mu jsme implementovali heartbeat mezi ExaBGP a HAProxy. Toto je softwarov\u00e1 \u0440\u0435\u0430\u043bizace interakce mezi ExaBGP a HAProxy, kdy ExaBGP pou\u017e\u00edv\u00e1 vlastn\u00ed skripty pro kontrolu stavu aplikac\u00ed.<\/p>\n

    K tomu je pot\u0159eba v konfigura\u010dn\u00edm souboru ExaBGP nastavit health checker, kter\u00fd bude moci kontrolovat stav HAProxy. V na\u0161em p\u0159\u00edpad\u011b jsme nastavili health backend v HAProxy a z ExaBGP kontrolujeme jednoduch\u00fdm GET po\u017eadavkem. Pokud se ozn\u00e1men\u00ed p\u0159estane uskute\u010d\u0148ovat, znamen\u00e1 to, \u017ee HAProxy pravd\u011bpodobn\u011b nefunguje a nelze jej ozn\u00e1mit. <\/p>\n

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

    HAProxy Peers: synchronizace relac\u00ed <\/h2>\n

    \nDal\u0161\u00ed, co bylo pot\u0159eba ud\u011blat, bylo synchronizovat relace. P\u0159i pr\u00e1ci p\u0159es distribuovan\u00e9 vyva\u017eova\u010de je obt\u00ed\u017en\u00e9 uspo\u0159\u00e1dat uchov\u00e1v\u00e1n\u00ed informac\u00ed o relac\u00edch klient\u016f. Ale HAProxy je jedn\u00edm z m\u00e1la vyva\u017eova\u010d\u016f, kter\u00e9 to um\u00ed d\u00edky funkci Peers \u2014 mo\u017enosti p\u0159ed\u00e1vat mezi r\u016fzn\u00fdmi procesy HAProxy tabulky relac\u00ed. <\/p>\n

    Existuj\u00ed r\u016fzn\u00e9 metody vyva\u017eov\u00e1n\u00ed: jednoduch\u00e9, jako je round-robin<\/a><\/noindex>, a pokro\u010dil\u00e9, kdy je relace klienta zapamatov\u00e1na a on se v\u017edy dostane na ten stejn\u00fd server, co p\u0159edt\u00edm. My jsme cht\u011bli implementovat druhou variantu.<\/p>\n

    V HAProxy se pro uchov\u00e1v\u00e1n\u00ed relac\u00ed klienta pou\u017e\u00edv\u00e1 mechanismus stick-tables. Ty uchov\u00e1vaj\u00ed p\u016fvodn\u00ed IP adresu klienta, zvolenou c\u00edlovou adresu (backend) a n\u011bjak\u00e9 pomocn\u00e9 informace. Obvykle se stick-tables pou\u017e\u00edvaj\u00ed pro ulo\u017een\u00ed p\u00e1ru source-IP + destination-IP, co\u017e je zvl\u00e1\u0161\u0165 u\u017eite\u010dn\u00e9 pro aplikace, kter\u00e9 nemohou p\u0159edat kontext relace u\u017eivatele p\u0159i p\u0159ep\u00edn\u00e1n\u00ed na jin\u00fd vyva\u017eova\u010d, nap\u0159\u00edklad \u2014 v re\u017eimu vyva\u017eov\u00e1n\u00ed RoundRobin.<\/p>\n

    Pokud se stick-table nau\u010d\u00ed pohybovat mezi r\u016fzn\u00fdmi procesy HAProxy (mezi kter\u00fdmi prob\u00edh\u00e1 vyva\u017eov\u00e1n\u00ed), na\u0161i vyva\u017eova\u010di budou moci pracovat s jedn\u00edm pool kontroln\u00edch tabulek. To umo\u017en\u00ed bezprobl\u00e9mov\u00e9 p\u0159ep\u00edn\u00e1n\u00ed s\u00edt\u011b klienta p\u0159i v\u00fdpadku jednoho z vyva\u017eova\u010d\u016f, pr\u00e1ce s relacemi klient\u016f bude pokra\u010dovat na t\u011bch stejn\u00fdch backendech, kter\u00e9 byly zvoleny d\u0159\u00edve.<\/p>\n

    Pro spr\u00e1vnou funkci je t\u0159eba vy\u0159e\u0161it probl\u00e9m s IP adresou vyva\u017eova\u010de, ze kter\u00e9ho byla relace nav\u00e1z\u00e1na. V na\u0161em p\u0159\u00edpad\u011b jde o dynamickou adresu na loopback rozhran\u00ed. <\/p>\n

    Spr\u00e1vn\u00e1 funkce peers je dosa\u017eiteln\u00e1 pouze za ur\u010dit\u00fdch podm\u00ednek. To znamen\u00e1, \u017ee TCP timeouty mus\u00ed b\u00fdt dostate\u010dn\u011b dlouh\u00e9, nebo p\u0159ep\u00edn\u00e1n\u00ed mus\u00ed b\u00fdt dostate\u010dn\u011b rychl\u00e9, aby TCP relace nedo\u0161lo k p\u0159eru\u0161en\u00ed. P\u0159esto to umo\u017e\u0148uje bezprobl\u00e9mov\u00e9 p\u0159ep\u00edn\u00e1n\u00ed. <\/p>\n

    V na\u0161em IaaS m\u00e1me slu\u017ebu, kter\u00e1 je postavena na stejn\u00e9 technologii. To je Load Balancer jako slu\u017eba pro OpenStack<\/a><\/noindex>, kter\u00e1 se naz\u00fdv\u00e1 Octavia. Je postavena na dvou procesech HAProxy, ve kter\u00e9 je od za\u010d\u00e1tku zakotvena podpora peers. Tato slu\u017eba se osv\u011bd\u010dila.<\/p>\n

    Na obr\u00e1zku je schematicky zn\u00e1zorn\u011bno p\u0159esouv\u00e1n\u00ed peers tabulek mezi t\u0159emi instancemi HAProxy, je navr\u017een\u00e1 konfigurace, jak to lze nastavit:<\/p>\n

    \"Jak
    \nHAProxy Peers (synchronizace relac\u00ed)<\/i><\/p>\n

    Pokud budete realizovat stejn\u00fd syst\u00e9m, je t\u0159eba pe\u010dliv\u011b testovat jeho funk\u010dnost. Nen\u00ed zaru\u010deno, \u017ee to bude fungovat ve stejn\u00e9 podob\u011b ve 100 % p\u0159\u00edpad\u016f. Ale aspo\u0148 nebudete ztr\u00e1cet stick tabulky, kdy\u017e je t\u0159eba si pamatovat source IP klienta.<\/p>\n

    Omezen\u00ed po\u010dtu sou\u010dasn\u00fdch po\u017eadavk\u016f od jednoho a toho sam\u00e9ho klienta<\/h2>\n

    \nJak\u00e9koliv slu\u017eby, kter\u00e9 jsou ve\u0159ejn\u011b dostupn\u00e9, v\u010detn\u011b na\u0161ich API, mohou b\u00fdt vystaveny lavin\u00e1m po\u017eadavk\u016f. D\u016fvody mohou b\u00fdt zcela r\u016fzn\u00e9, od chyb u\u017eivatel\u016f, po c\u00edlen\u00e9 \u00fatoky. Pravideln\u011b jsme DDoS-ov\u00e1ni podle IP adres. Klienti \u010dasto d\u011blaj\u00ed chyby ve sv\u00fdch skriptech, co\u017e zp\u016fsobuje mini-DDoSy.<\/p>\n

    Tak \u010di onak je nutn\u00e9 p\u0159edv\u00eddat dodate\u010dnou ochranu. O\u010dividn\u00fdm \u0159e\u0161en\u00edm se st\u00e1v\u00e1 omezen\u00ed po\u010dtu po\u017eadavk\u016f na API a neztr\u00e1cen\u00ed procesorov\u00e9ho \u010dasu na zpracov\u00e1n\u00ed \u0161kodliv\u00fdch po\u017eadavk\u016f.<\/p>\n

    Pro realizaci t\u011bchto omezen\u00ed pou\u017e\u00edv\u00e1me rate limits, organizovan\u00e9 na z\u00e1klad\u011b HAProxy, pomoc\u00ed stejn\u00fdch stick tabulek. Limity se nastavuj\u00ed pom\u011brn\u011b jednodu\u0161e a umo\u017e\u0148uj\u00ed omezit u\u017eivatele podle po\u010dtu po\u017eadavk\u016f na API. Algoritmus si pamatuje source IP, ze kter\u00e9 jsou po\u017eadavky prov\u00e1d\u011bny, a omezuje po\u010det sou\u010dasn\u00fdch po\u017eadavk\u016f od jednoho u\u017eivatele. Samoz\u0159ejm\u011b jsme vypo\u010d\u00edtali pr\u016fm\u011brn\u00fd profil z\u00e1t\u011b\u017ee na API pro ka\u017edou slu\u017ebu a nastavili limit p\u0159ibli\u017en\u011b 10kr\u00e1t vy\u0161\u0161\u00ed ne\u017e tato hodnota. Nad\u00e1le pe\u010dliv\u011b sledujeme situaci a m\u00e1me ruku na tepn\u011b.<\/p>\n

    Jak to vypad\u00e1 v praxi? M\u00e1me klienty, kte\u0159\u00ed neust\u00e1le vyu\u017e\u00edvaj\u00ed na\u0161e API pro automatick\u00e9 \u0161k\u00e1lov\u00e1n\u00ed. Vytv\u00e1\u0159ej\u00ed asi dv\u011b st\u011b a\u017e t\u0159i sta virtu\u00e1ln\u00edch stroj\u016f bl\u00ed\u017ee k r\u00e1nu a odstra\u0148uj\u00ed je bl\u00ed\u017ee k ve\u010deru. Pro OpenStack vytvo\u0159en\u00ed virtu\u00e1ln\u00edho stroje, je\u0161t\u011b s PaaS slu\u017ebami, znamen\u00e1 minim\u00e1ln\u011b 1000 API po\u017eadavk\u016f, proto\u017ee interakce mezi slu\u017ebami tak\u00e9 prob\u00edh\u00e1 prost\u0159ednictv\u00edm API. <\/p>\n

    Takov\u00e9 p\u0159esuny \u00faloh generuj\u00ed pom\u011brn\u011b velk\u00e9 zat\u00ed\u017een\u00ed. T\u00edmto zat\u00ed\u017een\u00edm jsme se zab\u00fdvali, shrom\u00e1\u017edili jsme denn\u00ed \u0161pi\u010dky, kter\u00e9 jsme zv\u00fd\u0161ili desetin\u00e1sobn\u011b, a to se stalo na\u0161\u00edm rate limitem. Dr\u017e\u00edme ruku na tepu. \u010casto vid\u00edme boty a skenery, kter\u00e9 se sna\u017e\u00ed zjistit, zda m\u00e1me n\u011bjak\u00e9 CGA skripty, kter\u00e9 by bylo mo\u017en\u00e9 spustit; aktivn\u011b je likvidujeme.<\/p>\n

    Jak nezpozorovan\u011b aktualizovat k\u00f3dovou z\u00e1kladnu<\/h2>\n

    \nImplementujeme odolnost v\u016f\u010di chyb\u00e1m tak\u00e9 na \u00farovni proces\u016f nasazen\u00ed k\u00f3du. P\u0159i nasazov\u00e1n\u00ed doch\u00e1z\u00ed k selh\u00e1n\u00edm, ale jejich vliv na dostupnost slu\u017eeb lze minimalizovat.<\/p>\n

    Neust\u00e1le aktualizujeme sv\u00e9 slu\u017eby a mus\u00edme zajistit proces aktualizace k\u00f3dov\u00e9 z\u00e1kladny bez dopadu na u\u017eivatele. Tohoto \u00fakolu jsme dos\u00e1hli vyu\u017eit\u00edm mo\u017enosti spr\u00e1vy HAProxy a implementac\u00ed Graceful Shutdown v na\u0161ich slu\u017eb\u00e1ch.<\/p>\n

    Pro \u0159e\u0161en\u00ed tohoto \u00fakolu bylo t\u0159eba zajistit spr\u00e1vu load balanceru a \"spr\u00e1vn\u00e9\" vypnut\u00ed slu\u017eeb:<\/p>\n