{"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\/sq\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Si realizohet nj\u00eb arkitektur\u00eb web me q\u00ebndrueshm\u00ebri n\u00eb platform\u00ebn Mail.ru Cloud Solutions","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Si
\n
\nP\u00ebrsh\u00ebndetje, Habr! Un\u00eb jam Artem Karamyshev, udh\u00ebheq\u00ebsi i ekipit t\u00eb administrat\u00ebs s\u00eb sistemeve Zgjidhjet e Reja t\u00eb Cloud Mail.Ru (MCS)<\/a><\/noindex>. N\u00eb vitin e kaluar kemi pasur shum\u00eb nisje t\u00eb produkteve t\u00eb reja. Ne desh\u00ebm q\u00eb sh\u00ebrbimet API t\u00eb ishin leht\u00ebsisht t\u00eb shkall\u00ebzueshme, t\u00eb ishin t\u00eb besueshme dhe t\u00eb gatshme p\u00ebr rritjen e shpejt\u00eb t\u00eb ngarkes\u00ebs s\u00eb p\u00ebrdoruesve. Platforma jon\u00eb \u00ebsht\u00eb realizuar n\u00eb OpenStack, dhe dua t\u00eb flas p\u00ebr problemet e q\u00ebndrueshm\u00ebris\u00eb s\u00eb komponent\u00ebve q\u00eb ne duhej t\u00eb zgjidhnim p\u00ebr t\u00eb arritur nj\u00eb sistem t\u00eb q\u00ebndruesh\u00ebm. Mendoj se kjo do t\u00eb jet\u00eb interesante p\u00ebr ata q\u00eb gjithashtu zhvillojn\u00eb produkte n\u00eb OpenStack.<\/p>\n

Q\u00ebndrueshm\u00ebria totale e platform\u00ebs p\u00ebrb\u00ebhet nga q\u00ebndrueshm\u00ebria e komponenteve t\u00eb saj. K\u00ebshtu q\u00eb ne do t\u00eb kalojm\u00eb gradualisht n\u00ebp\u00ebr t\u00eb gjitha nivelet, ku kemi zbuluar rreziqe dhe i kemi zgjidhur ato.<\/p>\n

Versionin n\u00eb video t\u00eb k\u00ebsaj historie, e cila \u00ebsht\u00eb burimi i raportit n\u00eb konferenc\u00ebn Uptime day 4, t\u00eb organizuar nga ITSumma<\/a><\/noindex>, mund ta shikoni n\u00eb kanalin YouTube t\u00eb Uptime Community<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Q\u00ebndrueshm\u00ebria e arkitektur\u00ebs fizike<\/h2>\n

\nPjesa publike e cloud-it MCS tani bazohet n\u00eb dy qendra t\u00eb t\u00eb dh\u00ebnave nivel Tier III, nd\u00ebrmjet t\u00eb cilave ka fibra t\u00eb err\u00ebt t\u00eb rezervuar, t\u00eb rezervuar n\u00eb nivelin fizik me rrug\u00eb t\u00eb ndryshme, me kapacitet prej 200 Gbit\/s. Niveli Tier III ofron nivelin e k\u00ebrkuar t\u00eb q\u00ebndrueshm\u00ebris\u00eb s\u00eb infrastruktur\u00ebs fizike. <\/p>\n

Fibra e err\u00ebt \u00ebsht\u00eb rezervuar si n\u00eb nivelin fizik ashtu edhe n\u00eb at\u00eb logjik. Procesi i rezervimit t\u00eb kanaleve ka qen\u00eb iterativ, kemi hasur n\u00eb probleme dhe ne vazhdimisht po p\u00ebrmir\u00ebsojm\u00eb lidhjen nd\u00ebrmjet qendrave t\u00eb t\u00eb dh\u00ebnave. <\/p>\n

P\u00ebr shembull, jo shum\u00eb koh\u00eb m\u00eb par\u00eb, gjat\u00eb punimeve n\u00eb nj\u00eb grop\u00eb pran\u00eb nj\u00eb prej qendrave t\u00eb t\u00eb dh\u00ebnave, ekskavatori e goditi nj\u00eb tub, brenda t\u00eb cilit ishin si kablloja optike kryesore ashtu edhe ajo rezerv\u00eb. Kanali yn\u00eb i q\u00ebndrueshm\u00ebris\u00eb me qendr\u00ebn e t\u00eb dh\u00ebnave doli t\u00eb ishte vulnerab\u00ebl n\u00eb nj\u00eb pik\u00eb, n\u00eb grop\u00eb. N\u00eb p\u00ebrputhje, humb\u00ebm pjes\u00eb t\u00eb infrastruktur\u00ebs. Ne nxorr\u00ebm p\u00ebrfundime, u nd\u00ebrmorr\u00ebm disa veprime, duke p\u00ebrfshir\u00eb vendosjen e optik\u00ebs shtes\u00eb n\u00eb grop\u00ebn p\u00ebrball\u00eb.<\/p><\/blockquote>\n

\nN\u00eb qendrat e t\u00eb dh\u00ebnave ka pika pranis\u00eb t\u00eb ofruesve t\u00eb komunikimit, t\u00eb cil\u00ebve ne u transmetojm\u00eb prefiksat tona n\u00ebp\u00ebrmjet BGP. P\u00ebr \u00e7do drejtim rrjeti zgjidhet metrika m\u00eb e mir\u00eb, \u00e7ka lejon ofrimin e cil\u00ebsis\u00eb m\u00eb t\u00eb mir\u00eb t\u00eb lidhjes p\u00ebr klient\u00ebt tan\u00eb t\u00eb ndrysh\u00ebm. N\u00ebse lidhja p\u00ebrmes nj\u00eb ofruesi ndalon, ne ristrukturojm\u00eb rrug\u00ebtimin ton\u00eb p\u00ebrmes ofruesve t\u00eb disponuesh\u00ebm.<\/p>\n

N\u00eb rast t\u00eb d\u00ebshtimit t\u00eb ofruesit, ne kalojm\u00eb automatikisht n\u00eb t\u00eb ardhshmin. N\u00eb rast t\u00eb d\u00ebshtimit t\u00eb nj\u00ebrit prej qendrave t\u00eb t\u00eb dh\u00ebnave, ne kemi nj\u00eb kopje pasqyr\u00eb t\u00eb sh\u00ebrbimeve tona n\u00eb qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave, t\u00eb cilat mbajn\u00eb t\u00eb gjith\u00eb ngarkes\u00ebn.<\/p>\n

\"Si
\nQ\u00ebndrueshm\u00ebria e infrastruktur\u00ebs fizike<\/i><\/p>\n

\u00c7far\u00eb p\u00ebrdorim p\u00ebr q\u00ebndrueshm\u00ebrin\u00eb n\u00eb nivelin e aplikacioneve<\/h2>\n

\nSh\u00ebrbimi yn\u00eb \u00ebsht\u00eb nd\u00ebrtuar mbi nj\u00eb s\u00ebr\u00eb komponent\u00ebsh opensource. <\/p>\n

ExaBGP<\/b> \u2014 sh\u00ebrbimi q\u00eb implementon nj\u00eb s\u00ebr\u00eb funksionesh duke p\u00ebrdorur protokollin e rrug\u00ebzimit dinamik mbi baz\u00ebn e BGP. Ne e p\u00ebrdorim aktivisht k\u00ebt\u00eb p\u00ebr t\u00eb shpallur adresat tona t\u00eb bardha IP, p\u00ebrmes t\u00eb cilave p\u00ebrdoruesit kan\u00eb qasje n\u00eb API.<\/p>\n

HAProxy<\/b> \u2014 nj\u00eb balancues i ngarkes\u00ebs me performanc\u00eb t\u00eb lart\u00eb, i cili mund\u00ebson konfigurimin e rregullave shum\u00eb fleksib\u00ebl t\u00eb balancimit t\u00eb trafikut n\u00eb nivele t\u00eb ndryshme t\u00eb modelit OSI. Ne e p\u00ebrdorim at\u00eb p\u00ebr balancimin para t\u00eb gjitha sh\u00ebrbimeve: bazat e t\u00eb dh\u00ebnave, broker\u00ebt e mesazheve, sh\u00ebrbimet API, sh\u00ebrbimet web, projektet tona t\u00eb brendshme \u2014 gjith\u00e7ka \u00ebsht\u00eb prapa HAProxy.<\/p>\n

API application<\/b> \u2014 nj\u00eb aplikacion web, i shkruar n\u00eb python, me t\u00eb cilin p\u00ebrdoruesi menaxhon infrastruktur\u00ebn e tij, sh\u00ebrbimin e tij.<\/p>\n

Worker application <\/b>(tani thjesht worker) \u2014 n\u00eb sh\u00ebrbimet OpenStack, kjo \u00ebsht\u00eb nj\u00eb demon infrastrukture, i cili mund\u00ebson transmetimin e komandave API n\u00eb infrastruktur\u00eb. P\u00ebr shembull, krijimi i nj\u00eb disku ndodh vet\u00ebm n\u00eb worker, nd\u00ebrsa k\u00ebrkesa p\u00ebr krijim ndodh n\u00eb API application. <\/p>\n

Arkitektura standarde e OpenStack Application<\/h2>\n

\nShumica e sh\u00ebrbimeve q\u00eb zhvillohen p\u00ebr OpenStack p\u00ebrpiqen t\u00eb ndjekin nj\u00eb paradig\u00ebm t\u00eb p\u00ebrbashk\u00ebt. Sh\u00ebrbimi zakonisht p\u00ebrb\u00ebhet nga 2 pjes\u00eb: API dhe worker-at (ekzekutor\u00ebt e backend). Rregullisht, API \u00ebsht\u00eb nj\u00eb aplikacion WSGI n\u00eb python, i cili ekzekutohet ose si nj\u00eb proces i pavarur (daemon), ose me ndihm\u00ebn e nj\u00eb serveri web t\u00eb gatsh\u00ebm si Nginx ose Apache. API p\u00ebrpunon k\u00ebrkes\u00ebn e p\u00ebrdoruesit dhe i d\u00ebrgon udh\u00ebzime t\u00eb m\u00ebtejshme aplikacionit worker. D\u00ebrgesa ndodh p\u00ebrmes nj\u00eb brokera mesazhe, zakonisht RabbitMQ, t\u00eb tjer\u00ebt mb\u00ebshteten dob\u00ebt. Kur mesazhet arrijn\u00eb n\u00eb broker, ato p\u00ebrpunohen nga worker-at dhe n\u00eb rast nevoje kthejn\u00eb p\u00ebrgjigje. <\/p>\n

Kjo paradig\u00ebm n\u00ebnkupton pika t\u00eb izoluara t\u00eb p\u00ebrbashk\u00ebta t\u00eb d\u00ebshtimit: RabbitMQ dhe baza e t\u00eb dh\u00ebnave. Por RabbitMQ \u00ebsht\u00eb i izoluara brenda nj\u00eb sh\u00ebrbimi dhe n\u00eb ide mund t\u00eb jet\u00eb individual p\u00ebr secilin sh\u00ebrbim. Prandaj, ne n\u00eb MCS e ndajm\u00eb sa m\u00eb shum\u00eb q\u00eb t\u00eb jet\u00eb e mundur k\u00ebto sh\u00ebrbime, krijojm\u00eb nj\u00eb baz\u00eb t\u00eb ve\u00e7ant\u00eb p\u00ebr \u00e7do projekt t\u00eb ve\u00e7ant\u00eb, nj\u00eb RabbitMQ t\u00eb ve\u00e7ant\u00eb. Ky qasje \u00ebsht\u00eb e mira sepse n\u00eb rast avarie n\u00eb disa pika t\u00eb prekshme, nuk d\u00ebshtoj\u00eb krejt sh\u00ebrbimi, por vet\u00ebm nj\u00eb pjes\u00eb e tij.<\/p>\n

Numri i aplikacioneve worker nuk \u00ebsht\u00eb kufizuar, k\u00ebshtu q\u00eb API mund t\u00eb shkall\u00ebzohet leht\u00ebsisht horizontalisht pas balancuesve p\u00ebr t\u00eb rritur performanc\u00ebn dhe q\u00ebndrueshm\u00ebrin\u00eb ndaj d\u00ebshtimeve.<\/p>\n

N\u00eb disa sh\u00ebrbime, \u00ebsht\u00eb e nevojshme koordinimi brenda sh\u00ebrbimit \u2014 kur ndodhin operacione komplekse dhe t\u00eb nj\u00ebpasnj\u00ebshme midis API-ve dhe pun\u00ebtor\u00ebve. N\u00eb k\u00ebt\u00eb rast, p\u00ebrdoret nj\u00eb qend\u00ebr e vetme koordinimi, nj\u00eb sistem klasteri si Redis, Memcache, etcd, i cili lejon nj\u00eb pun\u00ebtor t\u00eb thot\u00eb nj\u00eb tjetri se kjo detyr\u00eb \u00ebsht\u00eb e lidhur me t\u00eb (\u00abti, t\u00eb lutem, mos e merr\u00bb). Ne p\u00ebrdorim etcd. Si rregull, pun\u00ebtar\u00ebt komunikojn\u00eb aktivisht me baz\u00ebn e t\u00eb dh\u00ebnave, shkruajn\u00eb dhe lexojn\u00eb informacion prej saj. Si baz\u00eb t\u00eb dh\u00ebnash p\u00ebrdorim mariadb, e cila ndodhet n\u00eb nj\u00eb klaster multimaster.\n<\/p><\/blockquote>\n

\nKy sh\u00ebrbim klasik i vet\u00ebm \u00ebsht\u00eb organizuar n\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb zakonshme p\u00ebr OpenStack. Ai mund t\u00eb konsiderohet si nj\u00eb sistem i mbyllur, p\u00ebr t\u00eb cilin m\u00ebnyrat e shkall\u00ebzimit dhe q\u00ebndrueshm\u00ebris\u00eb jan\u00eb mjaft t\u00eb qarta. P\u00ebr shembull, p\u00ebr q\u00ebndrueshm\u00ebrin\u00eb, API mjafton t\u00eb ket\u00eb nj\u00eb balancues para tyre. Shkall\u00ebzimi i worker-ave arrihet duke rritur numrin e tyre. <\/p>\n

Pika e dob\u00ebt n\u00eb t\u00eb gjith\u00eb skem\u00ebn \u00ebsht\u00eb RabbitMQ dhe MariaDB. Arkitektura e tyre meriton nj\u00eb artikull t\u00eb ve\u00e7ant\u00eb. N\u00eb k\u00ebt\u00eb artikull do t\u00eb fokusohem te q\u00ebndrueshm\u00ebria e API-s\u00eb.<\/p>\n

\"Si
\nArkitektura e Openstack Application. Balancimi dhe q\u00ebndrueshm\u00ebria e platform\u00ebs cloud.<\/i><\/p>\n

E b\u00ebjm\u00eb balancuesin HAProxy t\u00eb q\u00ebndruesh\u00ebm me ndihm\u00ebn e ExaBGP.<\/h2>\n

\nP\u00ebr t\u00eb siguruar q\u00eb API-t\u00eb tona ishin t\u00eb shkall\u00ebzuara, t\u00eb shpejta dhe t\u00eb q\u00ebndrueshme, vendos\u00ebm nj\u00eb balancues para tyre. Zgjedhja jon\u00eb ishte HAProxy. Sipas mendimit tim, ai ka t\u00eb gjitha karakteristikat e nevojshme p\u00ebr detyr\u00ebn ton\u00eb: balancimi n\u00eb disa nivele OSI, nd\u00ebrfaqe menaxhimi, fleksibilitet dhe shkall\u00ebzim, nj\u00eb num\u00ebr i madh metodash balancimi, mb\u00ebshtetje p\u00ebr tabelat e sesioneve.<\/p>\n

Problemi i par\u00eb q\u00eb duhej zgjidhur ishte q\u00ebndrueshm\u00ebria e vet\u00eb balancuesit. Thjesht instalimi i balancuesit gjithashtu krijon nj\u00eb pik\u00eb d\u00ebshtimi: n\u00ebse balancuesi d\u00ebshtoi, sh\u00ebrbimi bie. P\u00ebr t\u00eb mos ndodhur kjo, ne p\u00ebrdor\u00ebm HAProxy s\u00eb bashku me ExaBGP.<\/p>\n

ExaBGP lejon realizimin e mekanizmit t\u00eb kontrollit t\u00eb gjendjes s\u00eb sh\u00ebrbimit. Ne e p\u00ebrdor\u00ebm k\u00ebt\u00eb mekaniz\u00ebm p\u00ebr t\u00eb kontrolluar funksionimin e HAProxy dhe, n\u00eb rast problemesh, p\u00ebr t\u00eb \u00e7aktivizuar sh\u00ebrbimin HAProxy nga BGP. <\/p>\n

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

    \n
  1. Instalojm\u00eb softin e nevojsh\u00ebm, ExaBGP dhe HAProxy, n\u00eb tre servera. <\/li>\n
  2. N\u00eb secilin prej server\u00ebve krijojm\u00eb nj\u00eb nd\u00ebrfaqe loopback.<\/li>\n
  3. N\u00eb t\u00eb tre serverat vendosim t\u00eb nj\u00ebjtin adres\u00eb IP t\u00eb bardh\u00eb n\u00eb k\u00ebt\u00eb nd\u00ebrfaqe.<\/li>\n
  4. Adresa IP e bardh\u00eb shpallet n\u00eb internet p\u00ebrmes ExaBGP. <\/li>\n<\/ol>\n

    \nQ\u00ebndrueshm\u00ebria arrihet duke shpallur t\u00eb nj\u00ebjt\u00ebn adres\u00eb IP nga t\u00eb tre serverat. Nga pik\u00ebpamja e rrjetit, e nj\u00ebjta adres\u00eb \u00ebsht\u00eb e aksesueshme nga tre hop-e t\u00eb ndryshme. Routeri sheh tre rrug\u00eb t\u00eb nj\u00ebjta, zgjedh sipas metrike t\u00eb tij m\u00eb prioritare (zakonisht kjo \u00ebsht\u00eb e nj\u00ebjta mund\u00ebsi), dhe trafiku kalon vet\u00ebm n\u00eb nj\u00eb nga serverat. <\/p>\n

    N\u00eb rast problemesh me pun\u00ebn e HAProxy ose d\u00ebshtimit t\u00eb serverit, ExaBGP pushton shpalljen e rrug\u00ebs, dhe trafiku kalon n\u00eb m\u00ebnyr\u00eb t\u00eb qet\u00eb n\u00eb serverin tjet\u00ebr. <\/p>\n

    K\u00ebshtu kemi arritur q\u00ebndrueshm\u00ebrin\u00eb e balancuesit.<\/p>\n

    \"Si
    \nQ\u00ebndrueshm\u00ebria e balancuesve HAProxy<\/i><\/p>\n

    Skema doli e paideale: ne m\u00ebsuam t\u00eb rezervojm\u00eb HAProxy, por nuk m\u00ebsuam t\u00eb shp\u00ebrndajm\u00eb ngarkes\u00ebn brenda sh\u00ebrbimeve. Prandaj, e zgjeruam pak k\u00ebt\u00eb skem\u00eb: kaluam n\u00eb balancimin midis disa adresave IP t\u00eb bardha.<\/p>\n

    Balancimi mbi baz\u00ebn e DNS plus BGP<\/h2>\n

    \nPyetja p\u00ebr balancimin e ngarkes\u00ebs p\u00ebrpara HAProxy ton\u00eb mbetet e pazgjidhur. Megjithat\u00eb, zgjidhja e saj \u00ebsht\u00eb mjaft e thjesht\u00eb, si\u00e7 b\u00ebm\u00eb dhe ne.<\/p>\n

    P\u00ebr balancimin e tre server\u00ebve nevojiten 3 adresa IP t\u00eb bardha dhe DNS i vjet\u00ebr. \u00c7do nj\u00eb nga k\u00ebto adresa p\u00ebrcaktohet n\u00eb interfacin loopback t\u00eb \u00e7do HAProxy dhe publikohet n\u00eb internet. <\/p>\n

    N\u00eb OpenStack, p\u00ebr menaxhimin e burimeve, p\u00ebrdoret nj\u00eb katalog sh\u00ebrbimesh n\u00eb t\u00eb cilin p\u00ebrcaktohet endpoint API i sh\u00ebrbimeve t\u00eb ndryshme. N\u00eb k\u00ebt\u00eb katalog ne shkruajm\u00eb emrin e domenit \u2014 public.infra.mail.ru, i cili rezolvohet p\u00ebrmes DNS me tre adresa IP t\u00eb ndryshme. Si rezultat, ne marrim shp\u00ebrndarjen e ngarkes\u00ebs nd\u00ebrmjet tre adresave p\u00ebrmes DNS. <\/p>\n

    Por pasi n\u00eb publikimin e adresave IP t\u00eb bardha ne nuk menaxhojm\u00eb prioritetet e zgjedhjes s\u00eb serverit, tani kjo nuk \u00ebsht\u00eb balancim. N\u00eb rregull, zakonisht do t\u00eb zgjidhet vet\u00ebm nj\u00eb server sipas rendit t\u00eb adres\u00ebs IP, nd\u00ebrsa dy t\u00eb tjerat do t\u00eb ngelin t\u00eb pap\u00ebrdorura, pasi nuk jan\u00eb p\u00ebrcaktuar metrika n\u00eb BGP.<\/p>\n

    Kemi filluar t\u00eb ndajm\u00eb rrug\u00ebt p\u00ebrmes ExaBGP me metrika t\u00eb ndryshme. Secili balancues publikon t\u00eb tre adresat IP t\u00eb bardha, por nj\u00ebri prej tyre, kryesor p\u00ebr k\u00ebt\u00eb balancues, publikohet me metrik\u00ebn m\u00eb t\u00eb ul\u00ebt. K\u00ebshtu q\u00eb p\u00ebr sa koh\u00eb q\u00eb t\u00eb tre balancuesit jan\u00eb n\u00eb funksion, k\u00ebrkesat p\u00ebr adres\u00ebn IP t\u00eb par\u00eb shkojn\u00eb te balancuesi i par\u00eb, k\u00ebrkesat p\u00ebr adres\u00ebn e dyt\u00eb shkojn\u00eb te i dyti, dhe p\u00ebr t\u00eb tretin te i treti.<\/p>\n

    \u00c7far\u00eb ndodh n\u00eb momentin kur nj\u00ebri nga balancuesit d\u00ebshton? N\u00eb rast t\u00eb ndalimit t\u00eb ndonj\u00eb balancuesi, adresa e tij kryesore akoma publikohet nga dy t\u00eb tjer\u00ebt, trafiku midis tyre ri-shp\u00ebrndahet. K\u00ebshtu, ne i ofrojm\u00eb p\u00ebrdoruesit p\u00ebrmes DNS disa adresa IP menj\u00ebher\u00eb. Duke p\u00ebrdorur balancimin me DNS dhe metrika t\u00eb ndryshme, ne arrijm\u00eb nj\u00eb shp\u00ebrndarje t\u00eb barabart\u00eb t\u00eb ngarkes\u00ebs mbi t\u00eb tre balancuesit. Dhe n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb nuk humbasim q\u00ebndrueshm\u00ebrin\u00eb.<\/p>\n

    \"Si
    \nBalancimi i HAProxy mbi baz\u00ebn e DNS + BGP<\/i><\/p>\n

    Nd\u00ebrveprimi midis ExaBGP dhe HAProxy<\/h2>\n

    \nPra, ne kemi implementuar q\u00ebndrueshm\u00ebri n\u00eb rast se serveri largohet, mbi baz\u00ebn e ndalimit t\u00eb publikimit t\u00eb rrug\u00ebve. Por HAProxy mund t\u00eb ndalet p\u00ebr arsye t\u00eb tjera, p\u00ebrve\u00e7 se d\u00ebshtimi i serverit: gabime administratoriale, d\u00ebshtime brenda sh\u00ebrbimit. Ne duam t\u00eb largojm\u00eb balancuesin e prishur nga ngarkesa edhe n\u00eb k\u00ebto raste, dhe na nevojitet nj\u00eb mekaniz\u00ebm tjet\u00ebr. <\/p>\n

    Prandaj, duke zgjeruar skem\u00ebn e m\u00ebparshme, ne kemi realizuar heartbeat midis ExaBGP dhe HAProxy. Kjo \u00ebsht\u00eb nj\u00eb realizim softuerik i nd\u00ebrveprimit midis ExaBGP dhe HAProxy, kur ExaBGP p\u00ebrdor skripte t\u00eb personalizuara p\u00ebr t\u00eb kontrolluar statusin e aplikacioneve.<\/p>\n

    P\u00ebr k\u00ebt\u00eb, n\u00eb konfigurimin e ExaBGP, \u00ebsht\u00eb e nevojshme t\u00eb konfigurohet nj\u00eb kontrollues sh\u00ebndeti, i cili mund t\u00eb kontrolloj\u00eb statusin e HAProxy. N\u00eb rastin ton\u00eb, ne konfigurim nj\u00eb sh\u00ebndet t\u00eb prapavij\u00ebs n\u00eb HAProxy, dhe nga ana e ExaBGP kontrollojm\u00eb me nj\u00eb k\u00ebrkes\u00eb t\u00eb thjesht\u00eb GET. N\u00ebse njoftimi ndalet, at\u00ebher\u00eb HAProxy, shum\u00eb mund\u00ebsisht, nuk funksionon, dhe nuk duhet ta njoftojm\u00eb. <\/p>\n

    \"Si
    \nKontrolli i Sh\u00ebndetit n\u00eb HAProxy<\/i><\/p>\n

    HAProxy Peers: sinkronizimi i seancave <\/h2>\n

    \nE ardhmja, q\u00eb duhej t\u00eb b\u00ebhej, ishte sinkronizimi i seancave. Kur punojm\u00eb p\u00ebrmes balancuesve t\u00eb shp\u00ebrndar\u00eb, \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb organizohet ruajtja e informacionit p\u00ebr seancat e klient\u00ebve. Por HAProxy \u00ebsht\u00eb nj\u00eb nga pak balancuesit q\u00eb e b\u00ebn k\u00ebt\u00eb p\u00ebrmes funksionalitetit Peers \u2014 mund\u00ebsia e kalimit t\u00eb tabelave t\u00eb seancave midis proceseve t\u00eb ndryshme t\u00eb HAProxy. <\/p>\n

    Ekzistojn\u00eb metoda t\u00eb ndryshme balancimi: t\u00eb thjeshta, si round-robin<\/a><\/noindex>, dhe t\u00eb avancuara, kur ruhet seanca e klientit dhe ai gjithmon\u00eb shkon n\u00eb serverin e nj\u00ebjt\u00eb, ashtu si\u00e7 ishte m\u00eb par\u00eb. Ne desh\u00ebm t\u00eb realizojm\u00eb variantin e dyt\u00eb.<\/p>\n

    N\u00eb HAProxy, p\u00ebr ruajtjen e seancave t\u00eb klient\u00ebve, ky mekaniz\u00ebm p\u00ebrdor stick-tables. Ato ruajn\u00eb adres\u00ebn IP origjinale t\u00eb klientit, adres\u00ebn e p\u00ebrzgjedhur t\u00eb targetit (b\u00ebhen) dhe disa informacione t\u00eb sh\u00ebrbimeve. Zakonisht, stick-tabelat p\u00ebrdoren p\u00ebr ruajtjen e \u00e7iftit source-IP + destination-IP, q\u00eb \u00ebsht\u00eb ve\u00e7an\u00ebrisht e dobishme p\u00ebr aplikacionet q\u00eb nuk mund t\u00eb kalojn\u00eb kontekstin e seanc\u00ebs s\u00eb p\u00ebrdoruesit kur kalojn\u00eb n\u00eb nj\u00eb balancues tjet\u00ebr, p\u00ebr shembull \u2014 n\u00eb modin e balancimit RoundRobin.<\/p>\n

    N\u00ebse stick-tabela m\u00ebsohet t\u00eb l\u00ebviz\u00eb midis proceseve t\u00eb ndryshme t\u00eb HAProxy (midis t\u00eb cil\u00ebve ndodh balancimi), balancuesit tan\u00eb do t\u00eb jen\u00eb n\u00eb gjendje t\u00eb punojn\u00eb me nj\u00eb grup stick-tabelash. Kjo do t\u00eb ofroj\u00eb mund\u00ebsin\u00eb e kalimeve pa nd\u00ebrprerje t\u00eb rrjetit t\u00eb klient\u00ebve n\u00eb rastin e r\u00ebnies s\u00eb nj\u00ebrit nga balancuesit, dhe puna me seancat e klient\u00ebve do t\u00eb vazhdoj\u00eb n\u00eb t\u00eb nj\u00ebjtat b\u00ebri q\u00eb ishin p\u00ebrzgjedhur m\u00eb par\u00eb.<\/p>\n

    P\u00ebr funksionimin e duhur, duhet t\u00eb zgjidhet problemi i adres\u00ebs IP burimore t\u00eb balancuesit, nga i cili \u00ebsht\u00eb vendosur seanca. N\u00eb rastin ton\u00eb, kjo \u00ebsht\u00eb nj\u00eb adres\u00eb dinamike n\u00eb nd\u00ebrfaqen loopback. <\/p>\n

    Puna funksionimi i peers arrin vet\u00ebm n\u00ebn kushte t\u00eb caktuara. Kjo do t\u00eb thot\u00eb se, koh\u00ebt e pritjes TCP duhet t\u00eb jen\u00eb mjaft t\u00eb m\u00ebdha ose kalimi duhet t\u00eb jet\u00eb mjaft i shpejt\u00eb, n\u00eb m\u00ebnyr\u00eb q\u00eb seanca TCP t\u00eb mos nd\u00ebrpritet. Megjithat\u00eb, kjo lejon kalimin pa probleme. <\/p>\n

    Ne kemi nj\u00eb sh\u00ebrbim n\u00eb IaaS t\u00eb nd\u00ebrtuar me t\u00eb nj\u00ebjt\u00ebn teknologji. Ky \u00ebsht\u00eb Load Balancer si sh\u00ebrbim p\u00ebr OpenStack<\/a><\/noindex>, i quajtur Octavia. Ai mb\u00ebshtetet n\u00eb dy procese HAProxy dhe ka nj\u00eb mb\u00ebshtetje t\u00eb integruar p\u00ebr peers. N\u00eb k\u00ebt\u00eb sh\u00ebrbim ata kan\u00eb treguar rezultate t\u00eb shk\u00eblqyera.<\/p>\n

    N\u00eb ilustrim \u00ebsht\u00eb paraqitur l\u00ebvizja e tabelave t\u00eb peers midis tre instancave t\u00eb HAProxy, me nj\u00eb konfigurim t\u00eb sugjeruar se si mund t\u00eb organizohet kjo:<\/p>\n

    \"Si
    \nHAProxy Peers (sinkronizimi i seancave)<\/i><\/p>\n

    N\u00ebse do t\u00eb zbatoni nj\u00eb skem\u00eb t\u00eb till\u00eb, duhet t\u00eb testoni kujdessh\u00ebm funksionimin e saj. Nuk ka garanci se kjo do t\u00eb funksionoj\u00eb n\u00eb t\u00eb nj\u00ebjt\u00ebn m\u00ebnyr\u00eb n\u00eb 100% t\u00eb rasteve. Por, s\u00eb paku, nuk do t\u00eb humbni tabelat stick kur duhet t\u00eb mbani mend IP-n\u00eb burimore t\u00eb klientit.<\/p>\n

    Kufizimi i numrit t\u00eb k\u00ebrkesave t\u00eb nj\u00ebkohshme nga nj\u00eb klient i vet\u00ebm<\/h2>\n

    \n\u00c7do sh\u00ebrbim q\u00eb \u00ebsht\u00eb n\u00eb akses t\u00eb hapur, p\u00ebrfshir\u00eb API-t\u00eb tona, mund t\u00eb jet\u00eb subjekt i p\u00ebrmbytjeve t\u00eb k\u00ebrkesave. Shkaqet e tyre mund t\u00eb jen\u00eb krejt\u00ebsisht t\u00eb ndryshme, nga gabimet e p\u00ebrdoruesve deri te sulmet e q\u00eblluara. Neher\u00eb DDoS-ojm\u00eb p\u00ebrmes adresave IP. Klient\u00ebt shpesh gabojn\u00eb n\u00eb skriptet e tyre, duke na b\u00ebr\u00eb mini-DDoS.<\/p>\n

    K\u00ebshtu ose ndryshe, duhet t\u00eb parashikojm\u00eb mbrojtje shtes\u00eb. Nj\u00eb zgjidhje e qart\u00eb \u00ebsht\u00eb t\u00eb kufizojm\u00eb numrin e k\u00ebrkesave n\u00eb API dhe t\u00eb mos e harxhojm\u00eb koh\u00ebn e procesorit p\u00ebr t\u00eb trajtuar k\u00ebrkesat keqdash\u00ebse.<\/p>\n

    P\u00ebr zbatimin e kufizimeve t\u00eb tilla, ne p\u00ebrdorim kufizime t\u00eb norm\u00ebs, t\u00eb organizuara mbi baz\u00ebn e HAProxy, me ndihm\u00ebn e tabelave stick. Kufijt\u00eb konfigurohen mjaft leht\u00eb dhe lejojn\u00eb kufizimin e p\u00ebrdoruesit n\u00eb numrin e k\u00ebrkesave n\u00eb API. Algoritmi mban mend IP-n\u00eb burimore nga e cila b\u00ebhen k\u00ebrkesat dhe kufizon numrin e k\u00ebrkesave t\u00eb nj\u00ebkohshme nga nj\u00eb p\u00ebrdorues i vet\u00ebm. Natyrisht, kemi llogaritur profilin mesatar t\u00eb ngarkes\u00ebs n\u00eb API p\u00ebr \u00e7do sh\u00ebrbim dhe kemi vendosur nj\u00eb limit \u2248 10 her\u00eb m\u00eb t\u00eb lart\u00eb se ky vler\u00eb. Ne vazhdojm\u00eb t\u00eb monitorojm\u00eb situat\u00ebn me kujdes, duke mbajtur dor\u00ebn n\u00eb pulsin e saj.<\/p>\n

    Si e duket kjo n\u00eb praktik\u00eb? Ne kemi klient\u00eb q\u00eb p\u00ebrdorin vazhdimisht API-t\u00eb tona p\u00ebr automatikimin e shkall\u00ebzimit. Ata krijojn\u00eb rreth dyqind deri n\u00eb treqind makina virtuale n\u00eb m\u00ebngjes dhe i fshijn\u00eb ato n\u00eb mbr\u00ebmje. P\u00ebr OpenStack, krijimi i nj\u00eb makine virtuale, s\u00eb bashku me sh\u00ebrbimet PaaS, k\u00ebrkon t\u00eb pakt\u00ebn 1000 k\u00ebrkesa API, p\u00ebr shkak se nd\u00ebrveprimi midis sh\u00ebrbimeve ndodh gjithashtu p\u00ebrmes API-s\u00eb. <\/p>\n

    K\u00ebto kalime detyrash shkaktojn\u00eb nj\u00eb ngarkes\u00eb mjaft t\u00eb madhe. Ne e kemi vler\u00ebsuar k\u00ebt\u00eb ngarkes\u00eb, kemi mbledhur pikat ditore, i kemi rritur ato dhjet\u00eb her\u00eb, dhe kjo u b\u00eb kufiri yn\u00eb i norm\u00ebs. Ne e mbajm\u00eb dor\u00ebn mbi pulsin. Shpesh shohim bota, skaner\u00eb q\u00eb p\u00ebrpiqen t\u00eb shohin n\u00ebse kemi ndonj\u00eb skripte CGA q\u00eb mund t\u00eb lancohen, dhe ne i eliminojm\u00eb ato n\u00eb m\u00ebnyr\u00eb aktive.<\/p>\n

    Si t\u00eb p\u00ebrdit\u00ebsoni baz\u00ebn e kodit pa u v\u00ebn\u00eb re nga p\u00ebrdoruesit<\/h2>\n

    \nNe zbatojm\u00eb q\u00ebndrueshm\u00ebrin\u00eb gjithashtu n\u00eb nivelin e proceseve t\u00eb shp\u00ebrndarjes s\u00eb kodit. Gjat\u00eb publikimeve ka d\u00ebshtime, por ndikimi i tyre n\u00eb disponueshm\u00ebrin\u00eb e sh\u00ebrbimeve mund t\u00eb minimizohet.<\/p>\n

    Ne vazhdojm\u00eb t\u00eb p\u00ebrdit\u00ebsojm\u00eb sh\u00ebrbimet tona dhe duhet t\u00eb sigurojm\u00eb procesin e p\u00ebrdit\u00ebsimit t\u00eb baz\u00ebs s\u00eb kodit pa ndikim p\u00ebr p\u00ebrdoruesit. Kjo detyr\u00eb u zgjidh duke p\u00ebrdorur mund\u00ebsit\u00eb e menaxhimit t\u00eb HAProxy dhe realizimin e Graceful Shutdown n\u00eb sh\u00ebrbimet tona.<\/p>\n

    P\u00ebr zgjidhjen e k\u00ebsaj detyre nevojitej t\u00eb sigurojm\u00eb menaxhimin e balancuesit dhe \"nderrimin e duhur\" t\u00eb sh\u00ebrbimeve:<\/p>\n