{"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 arkitektura e that\u00eb e uebit 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 Karamychev, lideri i ekipit t\u00eb administrat\u00ebs s\u00eb sistemit. Zgjidhjet e Merrjes s\u00eb Mail.Ru (MCS)<\/a><\/noindex>. Gjat\u00eb vitit t\u00eb kaluar, ne kishim shum\u00eb lan\u00e7ime t\u00eb produkteve t\u00eb reja. Donim q\u00eb sh\u00ebrbimet API t\u00eb ishin t\u00eb lehta p\u00ebr t'u skaluar, t\u00eb q\u00ebndrueshme 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 un\u00eb d\u00ebshiroj t\u00eb tregoj se cilat probleme t\u00eb q\u00ebndrueshm\u00ebris\u00eb s\u00eb komponent\u00ebve na duhej t\u00eb zgjidhnim p\u00ebr t\u00eb pasur nj\u00eb sistem t\u00eb q\u00ebndruesh\u00ebm. Mendoj se do t\u00eb jet\u00eb interesante p\u00ebr ata q\u00eb gjithashtu zhvillojn\u00eb produkte n\u00eb OpenStack.<\/p>\n

Q\u00ebndrueshm\u00ebria e p\u00ebrgjithshme e platform\u00ebs p\u00ebrb\u00ebhet nga q\u00ebndrueshm\u00ebria e komponent\u00ebve t\u00eb saj. Pra, ne do t\u00eb kalojm\u00eb gradualisht p\u00ebrmes t\u00eb gjitha niveleve ku kemi zbuluar rreziqe dhe i kemi eliminuar ato.<\/p>\n

Versionin video t\u00eb k\u00ebsaj historie, e cila \u00ebsht\u00eb origjinarisht nj\u00eb raport 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 \u00ebsht\u00eb bazuar n\u00eb dy qendra t\u00eb t\u00eb dh\u00ebnave t\u00eb nivelit Tier III, midis t\u00eb cilave ka fibra t\u00eb err\u00ebt private, t\u00eb rezervuar n\u00eb nivelin fizik p\u00ebrmes rrug\u00ebve t\u00eb ndryshme, me nj\u00eb kapacitet kalimi prej 200 Gbit\/s. Niveli Tier III siguron nivelin e nevojsh\u00ebm t\u00eb q\u00ebndrueshm\u00ebris\u00eb s\u00eb infrastruktur\u00ebs fizike. <\/p>\n

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

P\u00ebr shembull, jo shum\u00eb koh\u00eb m\u00eb par\u00eb, gjat\u00eb pun\u00ebve n\u00eb nj\u00eb kanale af\u00ebr nj\u00eb nga qendrat e t\u00eb dh\u00ebnave, nj\u00eb ekskavator shkat\u00ebrroi nj\u00eb tub, brenda t\u00eb cilit ndodhej si kablli optik kryesor ashtu edhe ai rezerv\u00eb. Kanali yn\u00eb i q\u00ebndruesh\u00ebm i komunikimit me qendr\u00ebn e t\u00eb dh\u00ebnave doli t\u00eb ishte i ndjesh\u00ebm n\u00eb nj\u00eb pik\u00eb, n\u00eb kanal. Si pasoj\u00eb, ne humb\u00ebm nj\u00eb pjes\u00eb t\u00eb infrastruktur\u00ebs. Ne nxorr\u00ebm disa m\u00ebsime, nd\u00ebrmorr\u00ebm nj\u00eb s\u00ebr\u00eb veprimesh, duke p\u00ebrfshir\u00eb kalimin e optik\u00ebs shtes\u00eb p\u00ebrmes nj\u00eb kanali fqinje.<\/p><\/blockquote>\n

\nN\u00eb qendrat e t\u00eb dh\u00ebnave, ka pika pranimi t\u00eb ofruesve t\u00eb sh\u00ebrbimeve dhe ne transmetojm\u00eb prefiksat tan\u00eb p\u00ebrmes BGP. P\u00ebr \u00e7do drejtim rrjeti zgjidhet metrika m\u00eb e mir\u00eb, e cila lejon ofrimin e cil\u00ebsis\u00eb m\u00eb t\u00eb mir\u00eb t\u00eb lidhjes p\u00ebr klient\u00ebt tan\u00eb. N\u00ebse lidhja p\u00ebrmes nj\u00eb ofruesi nd\u00ebrpritet, ne ristrukturim rrug\u00ebtimin ton\u00eb p\u00ebrmes ofruesve t\u00eb tjer\u00eb t\u00eb disponuesh\u00ebm.<\/p>\n

N\u00eb rastin e nj\u00eb d\u00ebshtimi t\u00eb ofruesit, ne kalojm\u00eb automatikisht te ofruesi tjet\u00ebr. N\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00ebrit nga qendrat e t\u00eb dh\u00ebnave, ne kemi nj\u00eb kopje t\u00eb dyfisht\u00eb t\u00eb sh\u00ebrbimeve tona n\u00eb qendr\u00ebn tjet\u00ebr t\u00eb t\u00eb dh\u00ebnave, e cila merr t\u00eb gjith\u00eb ngarkes\u00ebn.<\/p>\n

\"Si
\nQ\u00ebndrueshm\u00ebria fizike e infrastruktur\u00ebs<\/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 disa komponent\u00eb opensource. <\/p>\n

ExaBGP<\/b> \u2014 nj\u00eb sh\u00ebrbim q\u00eb zbaton nj\u00eb s\u00ebr\u00eb funksionesh duke p\u00ebrdorur protokollin e rrug\u00ebtimit dinamik bazuar n\u00eb BGP. Ne e p\u00ebrdorim aktivisht at\u00eb p\u00ebr t\u00eb shpallur adresat tona IP t\u00eb bardha, p\u00ebrmes t\u00eb cilave p\u00ebrdoruesit qasen n\u00eb API.<\/p>\n

HAProxy<\/b> \u2014 nj\u00eb balancues ngarkese me kapacitet t\u00eb lart\u00eb, i cili lejon 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 e 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 mb\u00ebshtetet pas HAProxy.<\/p>\n

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

Worker application <\/b>(n\u00eb vazhdim thjesht worker) \u2014 n\u00eb sh\u00ebrbimet OpenStack, ky \u00ebsht\u00eb nj\u00eb demon infrastrukture, i cili lejon transmetimin e komandave API n\u00eb infrastruktur\u00eb. P\u00ebr shembull, krijimi i nj\u00eb disku ndodh sakt\u00ebsisht n\u00eb worker, nd\u00ebrsa k\u00ebrkesa p\u00ebr krijimin \u2014 n\u00eb aplikacionin API. <\/p>\n

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

\nShumica e sh\u00ebrbimeve q\u00eb zhvillohen p\u00ebr OpenStack p\u00ebrpiqen t\u00eb ndjekin nj\u00eb paradigm\u00eb t\u00eb vetme. Sh\u00ebrbimi zakonisht p\u00ebrb\u00ebhet nga 2 pjes\u00eb: API dhe worker\u2019\u00eb (ekzekutuesit e backend-it). Zakonisht, API \u00ebsht\u00eb nj\u00eb aplikacion WSGI n\u00eb Python, i cili ekzekutohet si nj\u00eb proces i ve\u00e7ant\u00eb (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 d\u00ebrgon udh\u00ebzime t\u00eb m\u00ebtejshme p\u00ebr ekzekutimin e aplikacionit t\u00eb worker\u2019it. Transferimi ndodh me ndihm\u00ebn e nj\u00eb brokeri t\u00eb mesazheve, zakonisht \u00ebsht\u00eb RabbitMQ, nd\u00ebrsa t\u00eb tjer\u00ebt p\u00ebrkrahen dob\u00ebt. Kur mesazhet arrijn\u00eb te brokeri, ato p\u00ebrpunohen nga worker\u2019\u00ebt dhe, n\u00eb rast nevoje, kthejn\u00eb p\u00ebrgjigjen. <\/p>\n

Kjo paradig\u00ebm n\u00ebnkupton pika t\u00eb izoluara t\u00eb p\u00ebrgjegj\u00ebsis\u00eb: RabbitMQ dhe baza e t\u00eb dh\u00ebnave. Megjithat\u00eb, RabbitMQ \u00ebsht\u00eb i izoluar brenda nj\u00eb sh\u00ebrbimi dhe, n\u00eb teori, mund t\u00eb jet\u00eb individual p\u00ebr \u00e7do sh\u00ebrbim. Pra, ne n\u00eb MCS e ndajm\u00eb maksimalisht k\u00ebto sh\u00ebrbime, p\u00ebr \u00e7do projekt t\u00eb ve\u00e7ant\u00eb krijojm\u00eb nj\u00eb baz\u00eb t\u00eb ve\u00e7ant\u00eb, nj\u00eb RabbitMQ t\u00eb ve\u00e7ant\u00eb. Ky qasje \u00ebsht\u00eb e mir\u00eb, sepse n\u00eb rast avarie n\u00eb disa pika t\u00eb ndjeshme, nuk shembet e gjith\u00eb sh\u00ebrbimi, por vet\u00ebm nj\u00eb pjes\u00eb e tij.<\/p>\n

Numri i aplikacioneve worker nuk ka asnj\u00eb kufizim, prandaj API mund t\u00eb shkall\u00ebzohet leht\u00ebsisht horizontalisht p\u00ebrmes balancuesve me q\u00ebllim rritjen e performanc\u00ebs dhe besueshm\u00ebris\u00eb.<\/p>\n

N\u00eb disa sh\u00ebrbime k\u00ebrkohet koordinim brenda sh\u00ebrbimit \u2014 kur ndodhin operacione t\u00eb nd\u00ebrlikuara sekondare midis API dhe worker\u2019\u00ebve. N\u00eb k\u00ebt\u00eb rast, p\u00ebrdoret nj\u00eb qend\u00ebr koordinimi e vetme, nj\u00eb sistem klaster si Redis, Memcache, etctd, i cili lejon nj\u00eb worker t\u00eb informoj\u00eb nj\u00eb tjet\u00ebr se kjo detyr\u00eb i \u00ebsht\u00eb caktuar atij (\"ti, t\u00eb lutem, mos e merr at\u00eb\"). Ne p\u00ebrdorim etcd. Zakonisht, worker\u2019\u00ebt komunikojn\u00eb aktivisht me baz\u00ebn e t\u00eb dh\u00ebnave, duke shkruar dhe lexuar informacionin nga aty. Si baz\u00eb t\u00eb dh\u00ebnash p\u00ebrdorim MariaDB, e cila ndodhet n\u00eb nj\u00eb klaster multimaster.\n<\/p><\/blockquote>\n

\nNj\u00eb sh\u00ebrbim klasik i vet\u00ebm \u00ebsht\u00eb organizuar n\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 jan\u00eb mjaft t\u00eb qarta metodat e shkall\u00ebzimit dhe besueshm\u00ebris\u00eb. P\u00ebr shembull, p\u00ebr besueshm\u00ebri, \u00ebsht\u00eb e mjaftueshme t\u00eb vendosni nj\u00eb balancues p\u00ebrpara API-ve. Shkall\u00ebzimi i worker\u2019\u00ebve arrihet p\u00ebrmes rritjes s\u00eb numrit t\u00eb tyre. <\/p>\n

Dob\u00ebsia e gjith\u00eb skem\u00ebs \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 n\u00eb q\u00ebndrueshm\u00ebrin\u00eb e API-ve.<\/p>\n

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

D\u00ebrgojm\u00eb balancuesin HAProxy n\u00eb nj\u00eb q\u00ebndrueshm\u00ebri me ndihm\u00ebn e ExaBGP.<\/h2>\n

\nP\u00ebr ta b\u00ebr\u00eb API-t\u00eb tona t\u00eb shkall\u00ebzuara, t\u00eb shpejta dhe t\u00eb q\u00ebndrueshme, vendos\u00ebm nj\u00eb balancues para tyre. Zgjedhim HAProxy. Sipas mendimit tim, ai ka t\u00eb gjitha karakteristikat e nevojshme p\u00ebr detyr\u00ebn ton\u00eb: balancimi n\u00eb nivele t\u00eb ndryshme OSI, nj\u00eb nd\u00ebrfaqe menaxhimi, fleksibilitet dhe shkall\u00ebzim, nj\u00eb num\u00ebr t\u00eb madh metodash balancimi dhe mb\u00ebshtetje p\u00ebr tabela sesionesh.<\/p>\n

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

ExaBGP lejon implementimin e nj\u00eb mekanizmi p\u00ebr kontrollin e q\u00ebndrueshm\u00ebris\u00eb s\u00eb sh\u00ebrbimit. P\u00ebrdor\u00ebm k\u00ebt\u00eb mekaniz\u00ebm p\u00ebr t\u00eb verifikuar 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. Krijojm\u00eb nj\u00eb nd\u00ebrfaqe loopback n\u00eb secilin nga serverat.<\/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 anonsohet n\u00eb internet p\u00ebrmes ExaBGP. <\/li>\n<\/ol>\n

    \nQ\u00ebndrueshm\u00ebria arrihet duke anonsuar t\u00eb nj\u00ebjt\u00ebn adres\u00eb IP nga t\u00eb tre serverat. Nga perspektiva e rrjetit, e nj\u00ebjta adres\u00eb \u00ebsht\u00eb e qasshme nga tre hop-e t\u00eb ndryshme. Ruter-i sheh tri rute t\u00eb nj\u00ebjta, zgjidh sipas metrik\u00ebs s\u00eb tij m\u00eb t\u00eb lart\u00eb (gjithmon\u00eb \u00ebsht\u00eb e nj\u00ebjta zgjedhje), dhe trafiku kalon vet\u00ebm n\u00eb nj\u00eb nga serverat. <\/p>\n

    N\u00eb rast problemesh me funksionimin e HAProxy ose d\u00ebshtimit t\u00eb serverit, ExaBGP ndalon anonsimin e rutes dhe trafiku kalon pa probleme n\u00eb nj\u00eb server tjet\u00ebr. <\/p>\n

    K\u00ebshtu arrit\u00ebm q\u00ebndrueshm\u00ebrin\u00eb e balancuesit.<\/p>\n

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

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

    Balancimi mbi DNS dhe BGP<\/h2>\n

    \nEnde nuk \u00ebsht\u00eb zgjidhur problemi i balancimit t\u00eb ngarkes\u00ebs p\u00ebr HAProxy ton\u00eb. Megjithat\u00eb, \u00ebsht\u00eb e mundur ta zgjidhim mjaft thjesht, ashtu si\u00e7 e b\u00ebm\u00eb edhe ne.<\/p>\n

    P\u00ebr balancimin e tre server\u00ebve do t\u00eb nevojiten 3 adresa IP t\u00eb bardha dhe e vjetra DNS. \u00c7do nj\u00eb nga k\u00ebto adresa p\u00ebrcaktohet n\u00eb nd\u00ebrfaqen loopback t\u00eb \u00e7do HAProxy dhe shpallet n\u00eb internet. <\/p>\n

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

    Por, pasi q\u00eb gjat\u00eb shpalljes s\u00eb adresave IP t\u00eb bardha nuk menaxhojm\u00eb prioritetet e zgjedhjes s\u00eb serverit, p\u00ebr momentin nuk \u00ebsht\u00eb balancim. 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 q\u00ebndrojn\u00eb t\u00eb pap\u00ebrdorura, pasi nuk jan\u00eb caktuar asnj\u00eb metrik\u00eb n\u00eb BGP.<\/p>\n

    Kemi filluar t\u00eb japim rrug\u00eb p\u00ebrmes ExaBGP me metrik\u00eb t\u00eb ndryshme. \u00c7do balancues shpall t\u00eb tre adresat IP t\u00eb bardha, por nj\u00ebra prej tyre, kryesore p\u00ebr k\u00ebt\u00eb balancues, shpallet me metrik\u00ebn m\u00eb t\u00eb ul\u00ebt. Prandaj, nd\u00ebrsa t\u00eb tre balancuesit jan\u00eb n\u00eb pun\u00eb, k\u00ebrkesat p\u00ebr adres\u00ebn e par\u00eb shkojn\u00eb te balancuesi i par\u00eb, k\u00ebrkesat p\u00ebr t\u00eb dyt\u00ebn te i dyti, dhe p\u00ebr t\u00eb tret\u00ebn te t\u00eb treti.<\/p>\n

    \u00c7far\u00eb ndodh n\u00eb momentin kur nj\u00eb nga balancuesit d\u00ebshton? N\u00eb rastin e d\u00ebshtimit t\u00eb cilitdo balancues, adresa e tij kryesore ende shpallet nga dy t\u00eb tjer\u00ebt, dhe trafiku midis tyre shp\u00ebrndahet. K\u00ebshtu, ne i japim p\u00ebrdoruesit p\u00ebrmes DNS disa adresa IP menj\u00ebher\u00eb. N\u00ebp\u00ebrmjet balancimit p\u00ebrmes DNS dhe metrik\u00ebs t\u00eb ndryshme ne marrim nj\u00eb shp\u00ebrndarje t\u00eb barabart\u00eb t\u00eb ngarkes\u00ebs mbi t\u00eb gjith\u00eb tre balancuesit. Dhe nj\u00ebkoh\u00ebsisht nuk humbasim disponueshm\u00ebrin\u00eb.<\/p>\n

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

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

    \nPra, ne kemi implementuar disponueshm\u00ebrin\u00eb n\u00eb rast se serveri largohet, mbi baz\u00ebn e nd\u00ebrprerjes s\u00eb shpalljes s\u00eb rrug\u00ebve. Por HAProxy mund t\u00eb ndaloj\u00eb edhe p\u00ebr arsye t\u00eb tjera p\u00ebrve\u00e7 d\u00ebshtimit t\u00eb serverit: gabime administrimi, \u00e7rregullime brenda sh\u00ebrbimit. Ne duam t\u00eb heqim balancuesin e prishur nga ngarkesa dhe n\u00eb k\u00ebto raste, dhe nevojitet nj\u00eb mekaniz\u00ebm tjet\u00ebr. <\/p>\n

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

    P\u00ebr k\u00ebt\u00eb, n\u00eb konfigurimin e ExaBGP \u00ebsht\u00eb e domosdoshme t\u00eb konfigurohet nj\u00eb health checker, i cili mund t\u00eb kontrolloj\u00eb statusin e HAProxy. N\u00eb rastin ton\u00eb, konfigurimi i backend-it sh\u00ebndet\u00ebsor n\u00eb HAProxy u p\u00ebrgatit, dhe nga ana e ExaBGP ne kontrollojm\u00eb me nj\u00eb k\u00ebrkes\u00eb t\u00eb thjesht\u00eb GET. N\u00ebse njoftimi ndalon, at\u00ebher\u00eb HAProxy, me sa duket, nuk funksionon, dhe nuk duhet t\u00eb njoftojm\u00eb at\u00eb. <\/p>\n

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

    Miqt\u00eb e HAProxy: sinkronizimi i seancave <\/h2>\n

    \nGjithashtu, gj\u00ebja e ardhshme q\u00eb duhej b\u00ebr\u00eb 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 mbi seancat e klient\u00ebve. Por HAProxy \u00ebsht\u00eb nj\u00eb nga pak balancuesit q\u00eb di ta b\u00ebj\u00eb k\u00ebt\u00eb p\u00ebr shkak t\u00eb funksionalitetit t\u00eb Peers \u2014 mund\u00ebsia p\u00ebr t\u00eb transmetuar mes proceseve t\u00eb ndryshme HAProxy tabelat e seancave. <\/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 \u00e7do her\u00eb shkon n\u00eb serverin e nj\u00ebjt\u00eb si m\u00eb par\u00eb. Ne donim t\u00eb realizonim variantin e dyt\u00eb.<\/p>\n

    N\u00eb HAProxy, p\u00ebr t\u00eb ruajtur seancat e klientit, p\u00ebrdoret mekanizmi i stick-tables. K\u00ebto ruajn\u00eb adres\u00ebn origjinale IP t\u00eb klientit, adres\u00ebn e p\u00ebrzgjedhur t\u00eb destinacionit (backend) dhe disa informacione t\u00eb sh\u00ebrbimit. Zakonisht, stick-tables p\u00ebrdoren p\u00ebr t\u00eb ruajtur \u00e7iftin source-IP + destination-IP, q\u00eb \u00ebsht\u00eb ve\u00e7an\u00ebrisht e dobishme p\u00ebr aplikacionet q\u00eb nuk mund t\u00eb transmetojn\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-table m\u00ebson t\u00eb l\u00ebviz\u00eb midis proceseve t\u00eb ndryshme HAProxy (nd\u00ebrmjet t\u00eb cilave ndodh balancimi), balancuesit tan\u00eb do t\u00eb mund t\u00eb punojn\u00eb me nj\u00eb grup t\u00eb vet\u00ebm stick-tables. Kjo do t\u00eb ofroj\u00eb mund\u00ebsin\u00eb e kalimit t\u00eb pand\u00ebrprer\u00eb t\u00eb rrjetit t\u00eb klientit n\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00eb nga balancuesve, duke vazhduar pun\u00ebn me seancat e klient\u00ebve n\u00eb backend-et e nj\u00ebjta 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 t\u00eb burimit 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 interfacin e loopback. <\/p>\n

    Funksioni i duhur i peers arrihet vet\u00ebm n\u00eb kushte t\u00eb caktuara. Kjo do t\u00eb thot\u00eb se TCP-t\u00eb duhet t\u00eb jen\u00eb mjaft t\u00eb gjata 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 ndjeshm\u00ebri. <\/p>\n

    Ne kemi n\u00eb IaaS nj\u00eb sh\u00ebrbim 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 bazohet n\u00eb dy procese HAProxy dhe ka fillimisht mb\u00ebshtetje p\u00ebr peers. N\u00eb k\u00ebt\u00eb sh\u00ebrbim ata kan\u00eb treguar rezultate t\u00eb shk\u00eblqyera.<\/p>\n

    N\u00eb imazh p\u00ebrshkruhet n\u00eb m\u00ebnyr\u00eb skematike l\u00ebvizja e tabelave t\u00eb peers midis tre instancave t\u00eb HAProxy, dhe \u00ebsht\u00eb paraqitur nj\u00eb konfigurim se si mund t\u00eb konfigurohet kjo:<\/p>\n

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

    N\u00ebse do t\u00eb implementoni nj\u00eb skem\u00eb t\u00eb till\u00eb, duhen testuar me kujdes. Nuk \u00ebsht\u00eb e sigurt q\u00eb do t\u00eb funksionoj\u00eb n\u00eb t\u00eb nj\u00ebjt\u00ebn form\u00eb n\u00eb 100% t\u00eb rasteve. Por, s\u00eb paku, nuk do t\u00eb humbni tabelat e stick kur duhet t\u00eb mbani mend adres\u00ebn IP t\u00eb burimit 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

    \nT\u00eb gjitha sh\u00ebrbimet q\u00eb jan\u00eb n\u00eb akses t\u00eb hapur, p\u00ebrfshir\u00eb API-t\u00eb tona, mund t\u00eb jen\u00eb n\u00ebn presionin e k\u00ebrkesave t\u00eb shumta. Shkaqet mund t\u00eb jen\u00eb t\u00eb ndryshme, nga gabimet e p\u00ebrdoruesve deri te sulmet e drejtuara q\u00ebllimisht. Ndonj\u00ebher\u00eb, p\u00ebrjetojm\u00eb sulme DDoS p\u00ebrmes adresave IP. Klient\u00ebt shpesh gabojn\u00eb n\u00eb skriptet e tyre, duke na b\u00ebr\u00eb mini-DDoS.<\/p>\n

    N\u00eb \u00e7do rast, \u00ebsht\u00eb e nevojshme t\u00eb parashikohet mbrojtje shtes\u00eb. Nj\u00eb zgjidhje e qart\u00eb \u00ebsht\u00eb kufizimi i numrit t\u00eb k\u00ebrkesave ndaj API-s\u00eb dhe mosshpenzimi i koh\u00ebs s\u00eb procesorit p\u00ebr trajtimin e k\u00ebrkesave t\u00eb d\u00ebmshme.<\/p>\n

    P\u00ebr t\u00eb realizuar k\u00ebto kufizime ne p\u00ebrdorim limite p\u00ebr shpejt\u00ebsin\u00eb, t\u00eb organizuara mbi baz\u00ebn e HAProxy, duke p\u00ebrdorur tabelat e stick. Limitet konfigurohen mjaft thjesht dhe lejojn\u00eb kufizimin e p\u00ebrdoruesve p\u00ebr numrin e k\u00ebrkesave ndaj API-s\u00eb. Algoritmi mban mend adres\u00ebn IP t\u00eb burimit nga e cila b\u00ebhen k\u00ebrkesat dhe kufizon numrin e k\u00ebrkesave t\u00eb nj\u00ebkohshme nga nj\u00eb p\u00ebrdorues. Natyrisht, ne kemi llogaritur profilin mesatar t\u00eb ngarkes\u00ebs n\u00eb API p\u00ebr \u00e7do sh\u00ebrbim dhe kemi vendosur limitin \u2248 10 her\u00eb m\u00eb t\u00eb madh se ky vler\u00eb. Ende po e ndjekim me kujdes situat\u00ebn dhe po mbajm\u00eb dor\u00ebn mbi puls.<\/p>\n

    Si e p\u00ebrjet\u00ebsohet kjo n\u00eb praktik\u00eb? Ne kemi klient\u00eb q\u00eb vazhdimisht shfryt\u00ebzojn\u00eb API-t\u00eb tona p\u00ebr automatizimin e shkall\u00ebzimit. Ata krijojn\u00eb rreth dyqind deri n\u00eb treqind makina virtuale n\u00eb m\u00ebngjes dhe i fshijn\u00eb ato deri n\u00eb mbr\u00ebmje. P\u00ebr OpenStack, krijimi i nj\u00eb makine virtuale, s\u00eb bashku me sh\u00ebrbimet PaaS, do t\u00eb k\u00ebrkonte t\u00eb pakt\u00ebn 1000 k\u00ebrkesa API, pasi komunikimi mes sh\u00ebrbimeve gjithashtu ndodh p\u00ebrmes API-ve. <\/p>\n

    K\u00ebto trasferime t\u00eb detyrave shkaktojn\u00eb nj\u00eb ngarkes\u00eb t\u00eb konsiderueshme. Ne e kemi vler\u00ebsuar k\u00ebt\u00eb ngarkes\u00eb, kemi mbledhur majat e p\u00ebrditshme, i kemi shumzuar ato me dhjet\u00eb, dhe kjo \u00ebsht\u00eb b\u00ebr\u00eb kufiri yn\u00eb i ritmit. Ne jemi gjithmon\u00eb t\u00eb v\u00ebmendsh\u00ebm. Shpesh shohim bots dhe skanera q\u00eb p\u00ebrpiqen t\u00eb na analizojn\u00eb, p\u00ebr t\u00eb par\u00eb n\u00ebse kemi ndonj\u00eb skript CGA q\u00eb mund t\u00eb aktivizojn\u00eb; ne i ndalim ato me fuqish\u00ebm.<\/p>\n

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

    \nNe realizojm\u00eb q\u00ebndrueshm\u00ebrin\u00eb edhe n\u00eb nivelin e proceseve t\u00eb shp\u00ebrndarjes s\u00eb kodit. Gjat\u00eb lan\u00e7imeve ndodhin d\u00ebshtime, por ndikimi i tyre n\u00eb disponueshm\u00ebrin\u00eb e sh\u00ebrbimeve mund t\u00eb minimizohet.<\/p>\n

    Ne vazhdimisht 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 shkaktuar efekte p\u00ebr p\u00ebrdoruesit. Kjo \u00e7\u00ebshtje u zgjidh duke p\u00ebrdorur mund\u00ebsit\u00eb e menaxhimit t\u00eb HAProxy dhe implementimin e Graceful Shutdown n\u00eb sh\u00ebrbimet tona.<\/p>\n

    P\u00ebr zgjidhjen e k\u00ebsaj \u00e7\u00ebshtjeje, duheshin siguruar menaxhimi i balancuesit dhe \"shk\u00ebputja e duhur\" e sh\u00ebrbimeve:<\/p>\n