{"id":75796,"date":"2020-03-28T19:42:18","date_gmt":"2020-03-28T17:42:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb"},"modified":"2020-03-28T19:42:18","modified_gmt":"2020-03-28T17:42:18","slug":"klaster-elasticsearch-na-200-tb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Klastri Elasticsearch mbi 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Shum\u00eb njer\u00ebz p\u00ebrballen me Elasticsearch. Por \u00e7far\u00eb ndodh kur d\u00ebshiron ta p\u00ebrdor\u00ebsh p\u00ebr t\u00eb ruajtur log-et \"n\u00eb sasi t\u00eb m\u00ebdha\"? Dhe si mund t\u00eb p\u00ebrballosh d\u00ebshtimin e ndonj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave pa stres? Si duhet t\u00eb jet\u00eb arkitektura dhe cilat pengesa t\u00eb padukshme mund t\u00eb has\u00ebsh?<\/p>\n<p><\/p>\n<p>Ne n\u00eb Odnoklassniki vendos\u00ebm t\u00eb zgjidhim \u00e7\u00ebshtjen e menaxhimit t\u00eb log-eve me elasticsearch, dhe tani po ndajem p\u00ebrvoj\u00ebn ton\u00eb me Habra: jo vet\u00ebm p\u00ebr arkitektur\u00ebn, por edhe p\u00ebr pengesat.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Un\u00eb jam Pjet\u00ebr Zaitsev, punoj si administrator sistemesh n\u00eb Odnoklassniki. Para k\u00ebsaj kam qen\u00eb gjithashtu administrator, kam punuar me Manticore Search, Sphinx search, Elasticsearch. Ndoshta, n\u00ebse do t\u00eb shfaqet ndonj\u00eb search tjet\u00ebr, ndoshta do t\u00eb punoj edhe me t\u00eb. Gjithashtu, marr pjes\u00eb n\u00eb disa projekte open source n\u00eb m\u00ebnyr\u00eb vullnetar.<\/p>\n<p><\/p>\n<p>Kur b\u00ebra intervist\u00ebn p\u00ebr pun\u00eb n\u00eb Odnoklassniki, me guxim thash\u00eb se dinja t\u00eb punoja me Elasticsearch. Pas disa detyrave t\u00eb thjeshta, m\u00eb dhan\u00eb nj\u00eb sfid\u00eb t\u00eb madhe p\u00ebr reforma n\u00eb sistemin e menaxhimit t\u00eb log-eve q\u00eb ekzistonte n\u00eb at\u00eb koh\u00eb. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">K\u00ebrkesat<\/h2>\n<p><\/p>\n<p>K\u00ebrkesat p\u00ebr sistemin ishin formuluar si m\u00eb posht\u00eb:<\/p>\n<p><\/p>\n<ul>\n<li>Si frontend duhej t\u00eb p\u00ebrdorej Graylog. Sepse kompania kishte p\u00ebrvoj\u00eb me k\u00ebt\u00eb produkt, programuesit dhe tester\u00ebt e njihnin, e kishin t\u00eb njohur dhe t\u00eb p\u00ebrshtatsh\u00ebm.<\/li>\n<li>Sasia e t\u00eb dh\u00ebnave: mesatarisht 50-80 mij\u00eb mesazhe n\u00eb sekond\u00eb, por n\u00ebse ndodh ndonj\u00eb problem, trafiku nuk ka kufizim, mund t\u00eb arrij\u00eb 2-3 milion rreshta n\u00eb sekond\u00eb.<\/li>\n<li>Pas diskutimeve me klient\u00ebt mbi k\u00ebrkesat p\u00ebr shpejt\u00ebsin\u00eb e p\u00ebrpunimit t\u00eb k\u00ebrkesave, kuptuam se modeli i zakonsh\u00ebm i p\u00ebrdorimit t\u00eb nj\u00eb sistemi t\u00eb till\u00eb \u00ebsht\u00eb: njer\u00ebzit k\u00ebrkojn\u00eb log-et e aplikacionit t\u00eb tyre p\u00ebr dy dit\u00ebt e fundit dhe nuk duan t\u00eb presin m\u00eb shum\u00eb se nj\u00eb sekond\u00eb p\u00ebr rezultatet e k\u00ebrkes\u00ebs. <\/li>\n<li>Administratoret insistuan q\u00eb sistemi duhet t\u00eb ishte leht\u00ebsisht i shkall\u00ebzuesh\u00ebm, pa k\u00ebrkuar nj\u00eb shkall\u00eb t\u00eb thell\u00eb kuptimi se si ishte nd\u00ebrtuar. <\/li>\n<li>Q\u00eb detyra e vetme e mir\u00ebmbajtjes q\u00eb k\u00ebto sisteme k\u00ebrkonin her\u00eb pas here ishte t\u00eb ndryshohej ndonj\u00eb harduer.<\/li>\n<li>P\u00ebr m\u00eb tep\u00ebr, n\u00eb Odnoklassniki ekziston nj\u00eb tradit\u00eb teknike e shk\u00eblqyer: \u00e7do sh\u00ebrbim q\u00eb ne lan\u00e7ojm\u00eb duhet t\u00eb p\u00ebrballoj\u00eb d\u00ebshtimin e nj\u00eb qendre t\u00eb t\u00eb dh\u00ebnash (t\u00eb papritur, t\u00eb paplanifikuar dhe n\u00eb \u00e7do moment).<\/li>\n<\/ul>\n<p><\/p>\n<p>K\u00ebrkesa e fundit p\u00ebr realizimin e k\u00ebtij projekti ishte m\u00eb e v\u00ebshtir\u00eb, p\u00ebr t\u00eb cil\u00ebn do t\u00eb flas m\u00eb n\u00eb detaje m\u00eb von\u00eb.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Mjedisi<\/h2>\n<p><\/p>\n<p>Ne punojm\u00eb n\u00eb kat\u00ebr qendra t\u00eb t\u00eb dh\u00ebnave, nd\u00ebrkoh\u00eb q\u00eb nodet e t\u00eb dh\u00ebnave Elasticsearch mund t\u00eb ndodhen vet\u00ebm n\u00eb tri (p\u00ebr disa arsye jo teknike).<\/p>\n<p><\/p>\n<p>N\u00eb k\u00ebto kat\u00ebr qendra t\u00eb t\u00eb dh\u00ebnave ka rreth 18 mij\u00eb burime t\u00eb ndryshme log-esh \u2014 pajisje, konteiner\u00eb, makineri virtuale.<\/p>\n<p><\/p>\n<p>Nj\u00eb ve\u00e7ori e r\u00ebnd\u00ebsishme: ngritja e klasters b\u00ebhet n\u00eb konteiner\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> jo n\u00eb makinat fizike, por n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">produktin ton\u00eb cloud one-cloud<\/a><\/noindex>. Konteiner\u00ebve u garantohen 2 b\u00ebrthama, t\u00eb ngjashme me 2.0Ghz v4 me mund\u00ebsi t\u00eb riciklimit t\u00eb b\u00ebrthamave t\u00eb tjera n\u00eb rast pushimi. <\/p>\n<p><\/p>\n<p>Me fjal\u00eb t\u00eb tjera:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/073bffbfc3cff761bfabe0773b7f4ebc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"topologiya\">Topologjia<\/h2>\n<p><\/p>\n<p>Pamja e p\u00ebrgjithshme e zgjidhjes m\u00eb dukej fillimisht k\u00ebshtu:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP jan\u00eb pas A-record-it t\u00eb domenit Graylog, kjo \u00ebsht\u00eb adresa n\u00eb t\u00eb cil\u00ebn d\u00ebrgohen log-et.<\/li>\n<li>\u00e7do VIP p\u00ebrfaq\u00ebson nj\u00eb balancues LVS.<\/li>\n<li>Pasi q\u00eb log-et kalojn\u00eb n\u00eb nj\u00eb bateri Graylog, pjesa e t\u00eb dh\u00ebnave shkon n\u00eb formatin GELF, pjesa tjet\u00ebr n\u00eb formatin syslog.<\/li>\n<li>M\u00eb pas, t\u00eb gjitha k\u00ebto shkruhen n\u00eb grupe t\u00eb m\u00ebdha n\u00eb nj\u00eb bateri t\u00eb koordinatave Elasticsearch. <\/li>\n<li>Dhe ata, nga ana e tyre, d\u00ebrgojn\u00eb k\u00ebrkesat p\u00ebr t\u00eb shkruar dhe p\u00ebr t\u00eb lexuar tek nodet e t\u00eb dh\u00ebnave p\u00ebrkat\u00ebse. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/21efcdf6992a07e0c5e9b477c567cca9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"terminologiya\">Termat<\/h2>\n<p><\/p>\n<p>Ndoshta, jo t\u00eb gjith\u00eb jan\u00eb t\u00eb njohur me terminologjin\u00eb, k\u00ebshtu q\u00eb do doja t\u00eb ndalesha pak mbi t\u00eb.<\/p>\n<p><\/p>\n<p>N\u00eb Elasticsearch ka disa lloje nod\u00ebsh - master, coordinator, data node. Ka edhe dy lloje t\u00eb tjera p\u00ebr p\u00ebrpunime t\u00eb ndryshme log-esh dhe lidhjen e grupeve t\u00eb ndryshme mes tyre, por ne p\u00ebrdor\u00ebm vet\u00ebm llojet e p\u00ebrmendura. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPinguese t\u00eb gjith\u00eb nodet e pranishme n\u00eb klaster, mb\u00ebshtet hart\u00ebn e aktualizuar t\u00eb klasterit dhe e shp\u00ebrndan at\u00eb mes nod\u00ebve, trajton logjik\u00ebn e ngjarjeve, merret me nj\u00eb s\u00ebr\u00eb t\u00eb tashme t\u00eb mir\u00ebmbajtjes t\u00eb klaster\u00ebve. <\/p>\n<p><\/p>\n<p><strong>Koordinatori<\/strong><br \/>\nKryen nj\u00eb detyr\u00eb t\u00eb vetme: pranon k\u00ebrkesat nga klient\u00ebt p\u00ebr t\u00eb lexuar ose shkruar dhe drejton at\u00eb trafik. N\u00eb rast se k\u00ebrkesa \u00ebsht\u00eb p\u00ebr t\u00eb shkruar, shum\u00eb mund t\u00eb pyes\u00eb master-in se n\u00eb cilin shard t\u00eb indeksit p\u00ebrkat\u00ebs duhet ta vendos\u00eb k\u00ebt\u00eb, dhe do ta drejtoj\u00eb k\u00ebrkes\u00ebn m\u00eb tej. <\/p>\n<p><\/p>\n<p><strong>Data node<\/strong><br \/>\nRuan t\u00eb dh\u00ebnat, kryen k\u00ebrkesat e k\u00ebrkimeve q\u00eb mb\u00ebrrijn\u00eb nga jasht\u00eb dhe operacionet mbi shard-et q\u00eb ndodhen mbi t\u00eb.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nKy \u00ebsht\u00eb di\u00e7ka si nj\u00eb p\u00ebrzierje Kibana me Logstash n\u00eb grumbullin ELK. Graylog kombinon si UI ashtu edhe nj\u00eb proces p\u00ebr p\u00ebrpunimin e logs. N\u00ebn kapak, Graylog p\u00ebrdor Kafka dhe Zookeeper, t\u00eb cilat sigurojn\u00eb lidhjen e Graylog si klaster. Graylog \u00ebsht\u00eb n\u00eb gjendje t\u00eb ruaj\u00eb logs (Kafka) n\u00eb rast t\u00eb pap\u00ebrmbushjes s\u00eb Elasticsearch dhe t\u00eb p\u00ebrs\u00ebris\u00eb k\u00ebrkesat e d\u00ebshtuara p\u00ebr lexim dhe shkruajm\u00eb, grupuan dhe etiketuan logs sipas rregullave t\u00eb p\u00ebrcaktuara. Si Logstash, Graylog ka funksionalitetin p\u00ebr t\u00eb modifikuar stringjet p\u00ebrpara se t'i shkruaj\u00eb n\u00eb Elasticsearch.<\/p>\n<p><\/p>\n<p>P\u00ebrve\u00e7 k\u00ebsaj, n\u00eb Graylog ka nj\u00eb zbulim sh\u00ebrbimi t\u00eb integruar, duke lejuar q\u00eb mbi nj\u00eb nod\u00eb t\u00eb disponueshme Elasticsearch t\u00eb merret e gjith\u00eb harta e klasterit dhe t\u00eb filtrohet sipas nj\u00eb etikete t\u00eb caktuar, duke lejuar k\u00ebshtu d\u00ebrgimin e k\u00ebrkesave n\u00eb konteiner\u00eb specifik\u00eb.<\/p>\n<p><\/p>\n<p>Vizualisht, kjo duket af\u00ebrsisht k\u00ebshtu:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ky \u00ebsht\u00eb nj\u00eb ekranik nga nj\u00eb instanc\u00eb specifike. K\u00ebtu ne nd\u00ebrtuam nj\u00eb histogram\u00eb sipas k\u00ebrkes\u00ebs s\u00eb k\u00ebrkimit, duke nxjerr\u00eb stringjet relevante.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indeksat<\/h2>\n<p><\/p>\n<p>Duke u rikthyer n\u00eb arkitektur\u00ebn e sistemit, do t\u00eb doja t\u00eb fokusoja m\u00eb shum\u00eb n\u00eb m\u00ebnyr\u00ebn se si e nd\u00ebrtuam modelin e indekseve, n\u00eb m\u00ebnyr\u00eb q\u00eb gjith\u00e7ka t\u00eb funksiononte si\u00e7 duhet. <\/p>\n<p><\/p>\n<p>N\u00eb diagramin e treguar m\u00eb par\u00eb, ky \u00ebsht\u00eb niveli m\u00eb i ul\u00ebt: nodet e dh\u00ebnave Elasticsearch.<\/p>\n<p><\/p>\n<p>Indeksi \u00ebsht\u00eb nj\u00eb entitet i madh virtual, i p\u00ebrb\u00ebr\u00eb nga sharda Elasticsearch. Vet\u00eb \u00e7do shard nuk \u00ebsht\u00eb asgj\u00eb tjet\u00ebr ve\u00e7se nj\u00eb indeks Lucene. \u00c7do indeks Lucene, p\u00ebr m\u00eb tep\u00ebr, p\u00ebrb\u00ebhet nga nj\u00eb ose m\u00eb shum\u00eb segmente. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>P\u00ebr t\u00eb nd\u00ebrtuar sistemin, ne konsideruam se p\u00ebr t\u00eb p\u00ebrmbushur k\u00ebrkesat p\u00ebr shpejt\u00ebsin\u00eb e leximit n\u00eb nj\u00eb volum t\u00eb madh t\u00eb dh\u00ebnash, ne duhej t\u00eb \"shp\u00ebrndanim\" k\u00ebto t\u00eb dh\u00ebna n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb n\u00eb nodet e dh\u00ebnave. <\/p>\n<p><\/p>\n<p>Kjo \u00e7oi n\u00eb faktin se numri i shardeve p\u00ebr indeks (me replika) duhet t\u00eb ishte sakt\u00ebsisht i barabart\u00eb me numrin e nodet e dh\u00ebnave. S\u00eb pari, p\u00ebr t\u00eb siguruar nj\u00eb faktor replike t\u00eb barabart\u00eb me dy (dmth, ne mund t\u00eb humbasim gjysm\u00ebn e klasterit). Dhe, p\u00ebr m\u00eb tep\u00ebr, p\u00ebr t\u00eb p\u00ebrpunuar k\u00ebrkesat p\u00ebr lexim dhe shkruajm\u00eb, si t\u00eb pakt\u00ebn n\u00eb gjysm\u00ebn e klasterit.<\/p>\n<p><\/p>\n<p>Koha e ruajtjes e vendos\u00ebm fillimisht si 30 dit\u00eb.<\/p>\n<p><\/p>\n<p>Shp\u00ebrndarja e shardeve mund t\u00eb paraqitet vizualisht ashtu si m\u00eb posht\u00eb:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E gjith\u00eb drejtk\u00ebnd\u00ebshi i err\u00ebt \u00ebsht\u00eb indeksi. Kat\u00ebrkuqe e majt\u00eb brenda tij \u00ebsht\u00eb shard primar, i pari n\u00eb indeks. Nd\u00ebrsa kat\u00ebrkuqe blu \u00ebsht\u00eb shard replika. Ato ndodhen n\u00eb qendra t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave.<\/p>\n<p><\/p>\n<p>Kur ne shtojm\u00eb nj\u00eb shard tjet\u00ebr, ai shkon n\u00eb qendr\u00ebn e tret\u00eb t\u00eb t\u00eb dh\u00ebnave. Dhe, p\u00ebrfundimisht, ne marrim nj\u00eb struktur\u00eb t\u00eb till\u00eb, q\u00eb siguron mund\u00ebsin\u00eb p\u00ebr humbje t\u00eb DC pa humbje t\u00eb konsistenc\u00ebs s\u00eb t\u00eb dh\u00ebnave:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Rotacioni i indekseve, dmth krijimi i nj\u00eb indeksi t\u00eb ri dhe fshirja e atij m\u00eb t\u00eb vjet\u00ebr, e vendos\u00ebm t\u00eb ishte 48 or\u00eb (n\u00eb modelin e p\u00ebrdorimit t\u00eb indeksit: n\u00eb 48 or\u00ebt e fundit k\u00ebrkohet m\u00eb shpesh).<\/p>\n<p><\/p>\n<p>Ky interval rotacioni i indekseve \u00ebsht\u00eb i lidhur me arsyet e m\u00ebposhtme:<\/p>\n<p><\/p>\n<p>Kur nj\u00eb k\u00ebrkes\u00eb e k\u00ebrkimit mb\u00ebrrin n\u00eb nj\u00eb nod\u00eb t\u00eb caktuar t\u00eb t\u00eb dh\u00ebnave, nga pik\u00ebpamja e performanc\u00ebs \u00ebsht\u00eb m\u00eb e favorshme kur pyetet nj\u00eb shard, n\u00ebse madh\u00ebsia e tij \u00ebsht\u00eb e krahasueshme me madh\u00ebsin\u00eb e hipit t\u00eb nod\u00ebs. Kjo lejon q\u00eb pjesa \"e nxeht\u00eb\" e indeksit t\u00eb mbetet n\u00eb hip dhe t\u00eb qasemi shpejt n\u00eb t\u00eb. Kur ka shum\u00eb \" pjes\u00eb t\u00eb nxehta\", at\u00ebher\u00eb shpejt\u00ebsia e k\u00ebrkimit mbi indeks degradon.<\/p>\n<p><\/p>\n<p>Kur nj\u00eb nod\u00eb fillon t\u00eb p\u00ebrballoj\u00eb nj\u00eb k\u00ebrkes\u00eb t\u00eb k\u00ebrkimit n\u00eb nj\u00eb shard, ajo alokon numrin e fijeve q\u00eb \u00ebsht\u00eb e barabart\u00eb me numrin e b\u00ebrthamave t\u00eb hiperthreaded t\u00eb makineris\u00eb fizike. N\u00ebse k\u00ebrkesa e k\u00ebrkimit prek nj\u00eb num\u00ebr t\u00eb madh shardeve, at\u00ebher\u00eb numri i fijeve rritet proporcionalisht. Kjo reflekton negativisht mbi shpejt\u00ebsin\u00eb e k\u00ebrkimit dhe ndikon n\u00eb indekson e t\u00eb dh\u00ebnave t\u00eb reja. <\/p>\n<p><\/p>\n<p>P\u00ebr t\u00eb siguruar latency-n e nevojshme t\u00eb k\u00ebrkimit, vendos\u00ebm t\u00eb p\u00ebrdorim SSD. P\u00ebr p\u00ebrpunimin e shpejt\u00eb t\u00eb k\u00ebrkesave, makinat ku ishin vendosur k\u00ebto konteiner\u00eb duhej t\u00eb kishin t\u00eb pakt\u00ebn 56 b\u00ebrthama. Numri 56 \u00ebsht\u00eb zgjedhur si nj\u00eb vler\u00eb \u0443\u0441\u043b\u043e\u0432\u043d\u043e-\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u0430\u044f, q\u00eb p\u00ebrcakton numrin e thread-\u00ebve q\u00eb do t\u00eb krijoj\u00eb Elasticsearch gjat\u00eb funksionimit. N\u00eb Elasticsearch, shum\u00eb parametra t\u00eb thread pool-it varen drejtp\u00ebrdrejt nga numri i b\u00ebrthamave t\u00eb disponueshme, q\u00eb nga ana tjet\u00ebr ndikon drejtp\u00ebrdrejt n\u00eb numrin e nevojsh\u00ebm t\u00eb nodove n\u00eb kluster sipas parimit \"m\u00eb pak b\u00ebrthama \u2014 m\u00eb shum\u00eb nod\u00eb\". <\/p>\n<p><\/p>\n<p>Si rezultat, mesatarisht \u00e7do shard peshon diku rreth 20 gigabajt, dhe p\u00ebr 1 indeks kemi 360 sharde. S\u00eb fundmi, n\u00ebse ne i rotatojm\u00eb ato \u00e7do 48 or\u00eb, at\u00ebher\u00eb kemi 15 prej tyre. \u00c7do indeks p\u00ebrmban t\u00eb dh\u00ebna p\u00ebr 2 dit\u00eb.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Skemat e shkruajtjes dhe leximit t\u00eb t\u00eb dh\u00ebnave<\/h2>\n<p><\/p>\n<p>Le t\u00eb shohim se si t\u00eb dh\u00ebnat shkruhen n\u00eb k\u00ebt\u00eb sistem.<\/p>\n<p><\/p>\n<p>Supozoni se kemi nj\u00eb k\u00ebrkes\u00eb q\u00eb vjen nga Graylog n\u00eb koordinues. P\u00ebr shembull, ne duam t\u00eb indeksojm\u00eb 2-3 mij\u00eb stringje. <\/p>\n<p><\/p>\n<p>Koordinuesi, pas marrjes s\u00eb k\u00ebrkes\u00ebs nga Graylog, pyet masterin: \u00abN\u00eb k\u00ebrkes\u00ebn p\u00ebr indekson, na ishte specifikuar me sakt\u00ebsi indeksi, por nuk u specifikua n\u00eb cilin shard duhet shkruar\u00bb. <\/p>\n<p><\/p>\n<p>Master p\u00ebrgjigjet: \u00abShkruaj k\u00ebt\u00eb informacion n\u00eb shard num\u00ebr 71\u00bb, pas s\u00eb cil\u00ebs ai d\u00ebrgohet menj\u00ebher\u00eb n\u00eb nod\u00ebn p\u00ebrkat\u00ebse t\u00eb t\u00eb dh\u00ebnave, ku ndodhet primary-shard num\u00ebr 71.<\/p>\n<p><\/p>\n<p>Pas k\u00ebsaj, logu i transaksioneve replikohet n\u00eb replica-shard, i cili ndodhet tashm\u00eb n\u00eb nj\u00eb qend\u00ebr tjet\u00ebr t\u00eb t\u00eb dh\u00ebnave.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nga Graylog n\u00eb koordinatori arrin nj\u00eb k\u00ebrkes\u00eb p\u00ebr k\u00ebrkim. Koordinatori e redirekton at\u00eb n\u00ebp\u00ebrmjet indeksit, nd\u00ebrsa Elasticsearch distribuon k\u00ebrkesat midis primary-shard dhe replica-shard sipas parimit round-robin. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nodet n\u00eb num\u00ebr prej 180 p\u00ebrgjigjen n\u00eb m\u00ebnyr\u00eb t\u00eb pabarabart\u00eb, dhe nd\u00ebrsa ato p\u00ebrgjigjen, koordinatori grumbullon informacionin q\u00eb \u00ebsht\u00eb tashm\u00eb \u00abndezur\u00bb n\u00eb t\u00eb nga nodet m\u00eb t\u00eb shpejta t\u00eb t\u00eb dh\u00ebnave. Pas k\u00ebsaj, kur informacioni \u00ebsht\u00eb mbledhur ose \u00ebsht\u00eb arritur nj\u00eb skadim k\u00ebrkese, ai ia kthen gjith\u00e7ka direkt klientit. <\/p>\n<p><\/p>\n<p>I gjith\u00eb ky sistem, n\u00eb mesatare, p\u00ebrpunon k\u00ebrkesat p\u00ebr k\u00ebrkim p\u00ebr 48 or\u00ebt e fundit p\u00ebr 300-400ms, p\u00ebrjashtuar ato k\u00ebrkesa q\u00eb kan\u00eb wildcard t\u00eb udh\u00ebhequr.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\u00abLulet\u00bb me Elasticsearch: konfigurimi i Java-s<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>P\u00ebr t\u00eb b\u00ebr\u00eb q\u00eb gjith\u00e7ka t\u00eb funksionoj\u00eb ashtu si\u00e7 e d\u00ebshironim, ne kaluam shum\u00eb koh\u00eb duke konfiguruar gj\u00ebra t\u00eb ndryshme n\u00eb klaster. <\/p>\n<p><\/p>\n<p>Pjesa e par\u00eb e problemeve t\u00eb zbuluara kishte t\u00eb b\u00ebnte me m\u00ebnyr\u00ebn si \u00ebsht\u00eb parakonfiguruar Java n\u00eb Elasticsearch n\u00eb m\u00ebnyr\u00eb standarde. <\/p>\n<p><\/p>\n<p><strong>Problemi i par\u00eb<\/strong><br \/>\nNe kemi v\u00ebzhguar nj\u00eb num\u00ebr shum\u00eb t\u00eb madh mesazhesh p\u00ebr at\u00eb q\u00eb kemi n\u00eb nivelin Lucene, kur pun\u00ebt e background-it jan\u00eb aktive, p\u00ebrfundimet e mergj\u00ebve t\u00eb segmenteve Lucene p\u00ebrfundojn\u00eb me gabim. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, n\u00eb logje ishte e dukshme se kjo ishte nj\u00eb OutOfMemoryError. Nga telemetria, pam\u00eb se hapi ishte i lir\u00eb dhe nuk ishte e qart\u00eb pse kjo operacion bie. <\/p>\n<p><\/p>\n<p>U zbulua se bashkimet e indekseve Lucene ndodhin jasht\u00eb hapit. Dhe konteiner\u00ebt jan\u00eb ndjesh\u00ebm t\u00eb kufizuar n\u00eb burimet e harxhuara. N\u00eb k\u00ebto burime hynte vet\u00ebm hapi (vlera heap.size ishte af\u00ebrsisht e barabart\u00eb me RAM-in), dhe ndonj\u00eb operacion jasht\u00eb hapit d\u00ebshtonte me nj\u00eb gabim alokimi memorie, n\u00ebse ndonj\u00eb arsye nuk po p\u00ebrfshihej n\u00eb ato ~500MB q\u00eb mbeteshin deri n\u00eb limit.<\/p>\n<p><\/p>\n<p>Zgjidhja ishte mjaft triviale: ne rrit\u00ebm v\u00ebllimin e RAM-it t\u00eb disponuesh\u00ebm p\u00ebr konteinerin, pas s\u00eb cil\u00ebs harrova p\u00ebr at\u00eb probleme q\u00eb kishim.<\/p>\n<p><\/p>\n<p><strong>Problemi i dyt\u00eb<\/strong><br \/>\nPas rreth 4-5 dit\u00ebsh nga l\u00ebshimi i klasterit, ne v\u00ebzhguam se nodet e t\u00eb dh\u00ebnave filluan t\u00eb dalin periodikisht nga klasteri dhe t\u00eb ktheheshin brenda 10-20 sekondash. <\/p>\n<p><\/p>\n<p>Kur filluam t\u00eb hulumtonim, u zbulua se kjo memorie jasht\u00eb hapit n\u00eb Elasticsearch nuk kontrollohej pothuajse fare. Kur i dham\u00eb konteinerit m\u00eb shum\u00eb memorie, ne fituam mund\u00ebsin\u00eb p\u00ebr t\u00eb mbushur pool-it t\u00eb bufereve direkt me informacione t\u00eb ndryshme, dhe ajo u pastrua vet\u00ebm pasi ishte aktivizuar GC i qart\u00eb nga Elasticsearch. <\/p>\n<p><\/p>\n<p>N\u00eb disa raste, ky operacion ndodhte mjaft ngadal\u00eb, dhe gjat\u00eb atij koh\u00ebi klasteri arrinte t\u00eb etiketonte k\u00ebt\u00eb nod si t\u00eb dal\u00eb. Ky problem \u00ebsht\u00eb p\u00ebrshkruar mir\u00eb. <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">k\u00ebtu<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Zgjidhja ishte si vijon: ne kufizuam mund\u00ebsin\u00eb e Java-s p\u00ebr t\u00eb p\u00ebrdorur pjes\u00ebn m\u00eb t\u00eb madhe t\u00eb memories jasht\u00eb hapit p\u00ebr k\u00ebto operacione. Ne e kufizuam at\u00eb n\u00eb 16 gigabajt (-XX:MaxDirectMemorySize=16g), duke arritur q\u00eb GC i qart\u00eb t\u00eb aktivizohej shum\u00eb m\u00eb shpesh dhe t\u00eb p\u00ebrfundonte shum\u00eb m\u00eb shpejt, duke ndaluar k\u00ebshtu destabilizimin e klasterit.<\/p>\n<p><\/p>\n<p><strong>Problemi i tret\u00eb<\/strong><br \/>\nN\u00ebse mendoni se problemet me \u00abnodet q\u00eb braktisin klasterin n\u00eb momentin m\u00eb t\u00eb paparashikuar\u00bb p\u00ebrfundojn\u00eb k\u00ebtu, jeni t\u00eb gabuar. <\/p>\n<p><\/p>\n<p>Kur ne konfiguram pun\u00ebn me indekset, ne e ndal\u00ebm zgjedhjen ton\u00eb n\u00eb mmapfs p\u00ebr t\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">shkurtuar koh\u00ebn e k\u00ebrkimit<\/a><\/noindex> n\u00eb shard-at e fresk\u00ebt me segmentim t\u00eb madh. Kjo ishte nj\u00eb gabim mjaft i madh, sepse gjat\u00eb p\u00ebrdorimit t\u00eb mmapfs skedari mapohet n\u00eb kujtes\u00ebn operative dhe pastaj punojm\u00eb me skedarin e mapuar. P\u00ebr k\u00ebt\u00eb arsye ndodhte q\u00eb kur GC p\u00ebrpiqej t\u00eb ndalonte thread-et n\u00eb aplikacion, ne shkonim ngadal\u00eb n\u00eb safepoint, dhe gjat\u00eb rrug\u00ebs aty aplikacioni ndalonte s\u00eb p\u00ebrgjigjuri n\u00eb k\u00ebrkesat e master-it n\u00ebse ishte akoma aktiv. Si pasoj\u00eb, master-i mendonte se nodi nuk ishte m\u00eb i pranish\u00ebm n\u00eb klaster. Pas k\u00ebsaj, pas disa sekondash (5-10), garbage collector p\u00ebrfundonte, nodi rinovonte, hynte p\u00ebrs\u00ebri n\u00eb klaster dhe fillonte inicializimin e shard-ve. T\u00eb gjitha k\u00ebto ngjanin shum\u00eb me \u201cprodheksionin q\u00eb meritonim\u201d dhe nuk ishin t\u00eb p\u00ebrshtatshme p\u00ebr asgj\u00eb serioze.<\/p>\n<p><\/p>\n<p>P\u00ebr t\u00eb eliminuar nj\u00eb sjellje t\u00eb till\u00eb, ne s\u00eb pari kaluam n\u00eb mjeshtrin standard niofs, dhe m\u00eb pas, kur nga versionet e peshta Elastic u kaluam n\u00eb t\u00eb gjashtat, provuam hybridfs, ku ky problem nuk u riprodhua. M\u00eb shum\u00eb rreth llojeve t\u00eb ruajtjes mund t\u00eb lexoni. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">k\u00ebtu<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Problemi i kat\u00ebrt<\/strong><br \/>\nM\u00eb pas kishte edhe nj\u00eb problem shum\u00eb interesant, q\u00eb ne e trajtuam p\u00ebr nj\u00eb periudh\u00eb rekord t\u00eb gjat\u00eb. E kap\u00ebm at\u00eb p\u00ebr 2-3 muaj, sepse nuk ishte fare e qart\u00eb se cili ishte modeli i saj. <\/p>\n<p><\/p>\n<p>Her\u00eb pas here koordinatoret tan\u00eb shkonin n\u00eb Full GC, zakonisht pasdite rreth or\u00ebs 14:00, dhe nga aty nuk ktheheshin m\u00eb. Nd\u00ebrkoh\u00eb, kur regjistronim vonesat e GC, kjo dukej ndryshe: gjith\u00e7ka po shkonte mir\u00eb, mir\u00eb, mir\u00eb dhe pastaj nj\u00ebher\u00eb \u2014 gjith\u00e7ka ishte ndjer\u00eb keq. <\/p>\n<p><\/p>\n<p>N\u00eb fillim menduam se kishim nj\u00eb p\u00ebrdorues t\u00eb keq q\u00eb po d\u00ebrgonte ndonj\u00eb k\u00ebrkes\u00eb q\u00eb e \u00e7onte koordinuesin jasht\u00eb funksionit. Nd\u00ebrsa kaluam shum\u00eb koh\u00eb n\u00eb regjistrimin e k\u00ebrkesave p\u00ebr t\u00eb kuptuar se \u00e7far\u00eb po ndodhte. <\/p>\n<p><\/p>\n<p>N\u00eb fund u zbuluan se n\u00eb momentin q\u00eb ndonj\u00eb p\u00ebrdorues d\u00ebrgon nj\u00eb k\u00ebrkes\u00eb shum\u00eb t\u00eb madhe, dhe ajo e ndjek nj\u00eb koordinues t\u00eb ve\u00e7ant\u00eb Elasticsearch, disa nod\u00eb p\u00ebrgjigjen m\u00eb ngadal\u00eb se t\u00eb tjerat. <\/p>\n<p><\/p>\n<p>Dhe koha q\u00eb koordinuesi pret p\u00ebrgjigjet nga t\u00eb gjitha nodet, ndan n\u00eb vetvete rezultatet q\u00eb jan\u00eb d\u00ebrguar nga nodet q\u00eb kan\u00eb p\u00ebrgjigjur tashm\u00eb. Kjo p\u00ebr GC do t\u00eb thot\u00eb se modelet e p\u00ebrdorimit t\u00eb heap-it ndryshojn\u00eb shum\u00eb shpejt. Dhe ai GC q\u00eb ne po e p\u00ebrdornim, nuk e p\u00ebrballonte k\u00ebt\u00eb detyr\u00eb. <\/p>\n<p><\/p>\n<p>E vetmja zgjidhje q\u00eb gjet\u00ebm p\u00ebr t\u00eb ndryshuar sjelljen e klas\u00ebs n\u00eb nj\u00eb situat\u00eb t\u00eb till\u00eb ishte migrimi n\u00eb JDK13 dhe p\u00ebrdorimi i mbledh\u00ebsit t\u00eb mbeturinave Shenandoah. Kjo zgjidhi problemin, dhe koordinuesit tan\u00eb nuk ran\u00eb p\u00ebrs\u00ebri. <\/p>\n<p><\/p>\n<p>Me k\u00ebt\u00eb, problemet me Java p\u00ebrfunduan dhe filluan problemet me kapacitetin prej. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u00abFarat\u00bb me Elasticsearch: kapaciteti<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Problemet me kapacitetin do t\u00eb thot\u00eb se klasteri yn\u00eb punon me stabilitet, por gjat\u00eb pikave t\u00eb numrit t\u00eb dokumenteve q\u00eb po indeksohen dhe n\u00eb momentet e manovrave, performanca nuk \u00ebsht\u00eb e mjaftueshme.<\/p>\n<p><\/p>\n<p>Simptoma e par\u00eb e hasur: gjat\u00eb ndonj\u00eb \u00abeksplozimi\u00bb n\u00eb prodhim, kur gjenerohet papritur nj\u00eb num\u00ebr shum\u00eb i madh logesh, n\u00eb Graylog fillon t\u00eb shfaqet shpesh gabimi i indeksimit es_rejected_execution. <\/p>\n<p><\/p>\n<p>Kjo ndodhte sepse thread_pool.write.queue n\u00eb nj\u00eb nod\u00eb t\u00eb dh\u00ebnash deri n\u00eb momentin q\u00eb Elasticsearch mund t\u00eb p\u00ebrpunoj\u00eb k\u00ebrkes\u00ebn p\u00ebr indeksim dhe t\u00eb d\u00ebrgoj\u00eb informacionin n\u00eb shard n\u00eb disqet, p\u00ebr defaktore mund t\u00eb mbaj\u00eb n\u00eb cache vet\u00ebm 200 k\u00ebrkesa. Dhe n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">dokumentacionin Elasticsearch<\/a><\/noindex> p\u00ebr k\u00ebt\u00eb paramet\u00ebr flitet shum\u00eb pak. Tregohet vet\u00ebm numri maksimal i thread-\u00ebve dhe madh\u00ebsia e defaktore.<\/p>\n<p><\/p>\n<p>Natyrisht, shkuam t\u00eb rregullojm\u00eb k\u00ebt\u00eb vler\u00eb dhe zbuluam se konkretisht n\u00eb konfigurimin ton\u00eb, mund t\u00eb mbahen mir\u00eb deri n\u00eb 300 k\u00ebrkesa, nd\u00ebrsa vlera m\u00eb e lart\u00eb rrezikon q\u00eb ne t\u00eb kthehemi n\u00eb Full GC.<\/p>\n<p><\/p>\n<p>P\u00ebr m\u00eb tep\u00ebr, sepse k\u00ebto jan\u00eb grupe mesazhesh q\u00eb vijn\u00eb brenda nj\u00eb k\u00ebrkese, duhej gjithashtu t\u00eb rregullojm\u00eb Graylog q\u00eb ai t\u00eb shkruaj\u00eb jo shpesh dhe n\u00eb grupe t\u00eb vogla, por n\u00eb grupe t\u00eb m\u00ebdha ose \u00e7do 3 sekonda, n\u00ebse grupi akoma nuk \u00ebsht\u00eb plot. N\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb, informacioni q\u00eb ne shkruajm\u00eb n\u00eb Elasticsearch b\u00ebhet i disponuesh\u00ebm jo pas dy sekondash, por pas pes\u00eb (gj\u00eb q\u00eb na k\u00ebnaq), por zvog\u00eblon numrin e riprovimeve q\u00eb duhet t\u00eb b\u00ebjm\u00eb p\u00ebr t\u00eb d\u00ebrguar nj\u00eb grup t\u00eb madh informacioni.<\/p>\n<p><\/p>\n<p>Ky aspekt \u00ebsht\u00eb ve\u00e7an\u00ebrisht i r\u00ebnd\u00ebsish\u00ebm n\u00eb momentet kur ndodhin ndodhi t\u00eb tilla n\u00eb prodhim dhe na vijn\u00eb ankesa nga programuesit dhe testuesit: n\u00eb momentin q\u00eb u nevojiten k\u00ebto loge, ato u jepen shum\u00eb ngadal\u00eb.<\/p>\n<p><\/p>\n<p>Filluam t\u00eb shqyrtonim. Nga nj\u00ebra an\u00eb, ishte e qart\u00eb se k\u00ebrkesat e k\u00ebrkimit dhe ato t\u00eb indeksimit n\u00eb thelb po p\u00ebrpunoheshin n\u00eb t\u00eb nj\u00ebjtat makina fizike, dhe k\u00ebshtu m\u00ebnyrat e r\u00ebnie do t\u00eb ishin t\u00eb pranishme.<\/p>\n<p><\/p>\n<p>Por kjo mund t\u00eb shmangej pjes\u00ebrisht duke marr\u00eb parasysh se n\u00eb versionet e gjashta t\u00eb Elasticsearch kishte nj\u00eb algorit\u00ebm q\u00eb lejonte shp\u00ebrndarjen e k\u00ebrkesave midis nodave t\u00eb dh\u00ebnash p\u00ebrkat\u00ebse jo n\u00eb m\u00ebnyr\u00eb t\u00eb rast\u00ebsishme (kontaineri q\u00eb merret me indeksimin dhe mban primary-shard mund t\u00eb jet\u00eb shum\u00eb i ngarkuar, dhe nuk do t\u00eb ket\u00eb mund\u00ebsi t\u00eb p\u00ebrgjigjet shpejt), por t\u00eb d\u00ebrgoj\u00eb k\u00ebt\u00eb k\u00ebrkes\u00eb n\u00eb nj\u00eb kontenier m\u00eb pak t\u00eb ngarkuar me replica-shard, i cili do t\u00eb p\u00ebrgjigjej duksh\u00ebm m\u00eb shpejt. Me fjal\u00eb t\u00eb tjera, ne erdh\u00ebm te use_adaptive_replica_selection: true. <\/p>\n<p><\/p>\n<p>Pamja e leximit fillon k\u00ebshtu:<\/p>\n<p><\/p>\n<p>Kalimi n\u00eb k\u00ebt\u00eb algorit\u00ebm ndihmoi ndjesh\u00ebm n\u00eb p\u00ebrmir\u00ebsimin e koh\u00ebs s\u00eb k\u00ebrkimit n\u00eb ato momente kur kishte nj\u00eb fluks t\u00eb madh logesh p\u00ebr t'u shkruar.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>S\u00eb fundi, problemi kryesor ishte q\u00eb t\u00eb dilte nga data-center pa dhimbje.<\/p>\n<p><\/p>\n<p>\u00c7far\u00eb doja ne nga klasteri menj\u00ebher\u00eb pas humbjes s\u00eb lidhjes me nj\u00eb DC:<\/p>\n<p><\/p>\n<p>N\u00ebse aktuali master ndodhet n\u00eb data-centerin e humbur, ai do t\u00eb ri-zgjidhet dhe do t\u00eb kaloj\u00eb si rol n\u00eb nj\u00eb nod tjet\u00ebr n\u00eb nj\u00eb DC tjet\u00ebr. <\/p>\n<p><\/p>\n<ul>\n<li>Mjeshtri do t\u00eb p\u00ebrjashtoj\u00eb shpejt t\u00eb gjitha nodet e padisponueshme nga klasteri.<\/li>\n<li>Duke u bazuar n\u00eb ato q\u00eb kishim mbetur, do t\u00eb kuptonte shpejt: n\u00eb data-centerin e humbur kishim k\u00ebto primary-shard, dhe shpejt do t\u00eb promovonte replica-shard-et p\u00ebrkat\u00ebse n\u00eb data-centerin e mbetur, dhe ne do t\u00eb vazhdojm\u00eb indeksimin e t\u00eb dh\u00ebnave.<\/li>\n<li>Si rezultat i k\u00ebsaj, kapaciteti i klasterit p\u00ebr shkrim dhe lexim do t\u00eb degjenerohej ngadal\u00eb, por n\u00eb p\u00ebrgjith\u00ebsi gjith\u00e7ka do t\u00eb punonte ngadal\u00eb, por stabilisht. <\/li>\n<li>Si\u00e7 u zbulua, ne d\u00ebshironim di\u00e7ka t\u00eb till\u00eb:<\/li>\n<\/ul>\n<p><\/p>\n<p>Si rezultoi, ne donim ndonj\u00eb gj\u00eb t\u00eb till\u00eb:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>D\u00ebshira jon\u00eb rezultoi me k\u00ebt\u00eb:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Si ndodhi kjo? <\/p>\n<p><\/p>\n<p>Gjat\u00eb r\u00ebnies s\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave, problemi yn\u00eb ishte master-i.<\/p>\n<p><\/p>\n<p>Pse?<\/p>\n<p><\/p>\n<p>Problemi q\u00ebndron se n\u00eb master ka nj\u00eb TaskBatcher, i cili \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr shp\u00ebrndarjen e detyrave specifike dhe ngjarjeve n\u00eb klaster. \u00c7do dalje e nod\u00ebs, \u00e7do avancim i shard-it nga replica n\u00eb primary, \u00e7do detyr\u00eb p\u00ebr krijimin e ndonj\u00eb shard-i \u2014 gjith\u00e7ka kalon fillimisht n\u00eb TaskBatcher, ku p\u00ebrpunohen n\u00eb m\u00ebnyr\u00eb t\u00eb nj\u00ebpasnj\u00ebshme dhe n\u00eb nj\u00eb kanal.<\/p>\n<p><\/p>\n<p>Gjat\u00eb t\u00ebrheqjes s\u00eb nj\u00eb qendre t\u00eb dh\u00ebnash, dukej se t\u00eb gjitha nodet e t\u00eb dh\u00ebnave n\u00eb qendrat e mbijetuara e konsideronin si detyr\u00eb t\u00eb sajin t\u00eb informonin master-in \"ne kemi humbur k\u00ebto shard-e dhe k\u00ebto nodet e t\u00eb dh\u00ebnave\". <\/p>\n<p><\/p>\n<p>Nd\u00ebrkoh\u00eb, nodet e mbijetuara t\u00eb t\u00eb dh\u00ebnave i d\u00ebrgonin gjith\u00eb k\u00ebt\u00eb informacion master-it aktual dhe p\u00ebrpiqeshin t\u00eb prisnin konfirmimin q\u00eb ai e kishte pranuar. Ata nuk e prisnin k\u00ebt\u00eb, pasi master-i merrte detyra m\u00eb shpejt se sa mund t\u00eb p\u00ebrgjigjej. Nodat p\u00ebrs\u00ebrisnin k\u00ebrkesat p\u00ebr shkak t\u00eb koh\u00ebs s\u00eb skadimit nd\u00ebrsa master-i, n\u00eb at\u00eb koh\u00eb, as q\u00eb p\u00ebrpiqej t\u00eb p\u00ebrgjigjej dhe ishte plot\u00ebsisht i p\u00ebrfshir\u00eb n\u00eb detyr\u00ebn e renditjes s\u00eb k\u00ebrkesave sipas prioritetit.<\/p>\n<p><\/p>\n<p>N\u00eb form\u00ebn p\u00ebrfundimtare dukej se nodet e t\u00eb dh\u00ebnave po e bombardonin master-in deri sa ai shkonte n\u00eb full GC. Pas k\u00ebsaj, roli i master-it kalonte n\u00eb ndonj\u00eb nod tjet\u00ebr, dhe me t\u00eb ndodhte e nj\u00ebjta gj\u00eb, dhe n\u00eb fund klasteri shkat\u00ebrrohej plot\u00ebsisht. <\/p>\n<p><\/p>\n<p>Kemi b\u00ebr\u00eb matje dhe deri n\u00eb versionin 6.4.0, ku kjo u rregullua, na mjaftonte t\u00eb t\u00ebrhiqnim vet\u00ebm 10 nodet e t\u00eb dh\u00ebnave nga 360 p\u00ebr t\u00eb shkat\u00ebrruar plot\u00ebsisht klasterin.<\/p>\n<p><\/p>\n<p>Ishte duke u dukur k\u00ebshtu:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pas versionit 6.4.0, ku ky defekt i tmerrsh\u00ebm u rregullua, nodet e t\u00eb dh\u00ebnave ndaluan t\u00eb vrasin master-in. Por ai nuk u b\u00eb \"m\u00eb i zgjuar\" nga kjo. N\u00eb ve\u00e7anti: kur t\u00eb t\u00ebrhiqnim 2, 3 ose 10 (\u00e7do num\u00ebr tjet\u00ebr p\u00ebrve\u00e7 nj\u00eb) nodet e t\u00eb dh\u00ebnave, master-i merrte nj\u00eb mesazh t\u00eb par\u00eb, i cili thoshte q\u00eb nodi A kishte dal\u00eb dhe p\u00ebrpiqej ta tregonte k\u00ebt\u00eb p\u00ebr nodin B, nodin C, nodin D. <\/p>\n<p><\/p>\n<p>Dhe n\u00eb k\u00ebt\u00eb moment, mund ta luftojm\u00eb k\u00ebt\u00eb vet\u00ebm p\u00ebrmes vendosjes s\u00eb nj\u00eb koh\u00ebzgjatjeje p\u00ebr p\u00ebrpjekjet p\u00ebr t\u00eb treguar informacion p\u00ebr dik\u00eb, t\u00eb barabart\u00eb me rreth 20-30 sekonda, dhe k\u00ebshtu menaxhojm\u00eb shpejt\u00ebsin\u00eb e daljes s\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave nga klasteri.<\/p>\n<p><\/p>\n<p>N\u00eb parim, kjo p\u00ebrputhet me k\u00ebrkesat q\u00eb fillimisht u b\u00ebn\u00eb p\u00ebr produktin p\u00ebrfundimtar n\u00eb kuad\u00ebr t\u00eb projektit, por nga k\u00ebndv\u00ebshtrimi i \"shkenc\u00ebs s\u00eb past\u00ebr\" kjo \u00ebsht\u00eb nj\u00eb defekt. I cili, p\u00ebr fat t\u00eb mir\u00eb, u rregullua me sukses nga zhvilluesit n\u00eb versionin 7.2.<\/p>\n<p><\/p>\n<p>Kur nj\u00eb nod i caktuar i t\u00eb dh\u00ebnave dilte, dukej se ishte m\u00eb e r\u00ebnd\u00ebsishme t\u00eb shp\u00ebrndahej informacioni p\u00ebr daljen e tij sesa t\u00eb tregohej p\u00ebr t\u00eb gjith\u00eb klasterin se n\u00eb t\u00eb ishin disa primary-shard (p\u00ebr t\u00eb promovuar replica-shard-in n\u00eb nj\u00eb qend\u00ebr tjet\u00ebr t\u00eb t\u00eb dh\u00ebnave n\u00eb primary, dhe aty mund t\u00eb shkruhej informacioni).<\/p>\n<p><\/p>\n<p>Prandaj, kur gjith\u00e7ka \"ka kaluar\", nodet e dalura nuk jan\u00eb sh\u00ebnuar menj\u00ebher\u00eb si stale. N\u00eb p\u00ebrputhje me k\u00ebt\u00eb, jemi t\u00eb detyruar t\u00eb presim derisa t\u00eb skadojn\u00eb t\u00eb gjitha ping-et p\u00ebr nodet e dalura dhe vet\u00ebm at\u00ebher\u00eb klasteri yn\u00eb fillon t\u00eb tregoj\u00eb at\u00eb q\u00eb atje, atje dhe atje duhet t\u00eb vazhdoj\u00eb t\u00eb regjistroj\u00eb informacion. M\u00eb shum\u00eb mund t\u00eb lexoni p\u00ebr k\u00ebt\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">k\u00ebtu<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>N\u00eb p\u00ebrfundim, operacioni i daljes s\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave sot na z\u00eb rreth 5 minuta n\u00eb or\u00ebt e pikut. P\u00ebr nj\u00eb mas\u00eb kaq t\u00eb madhe dhe t\u00eb ngadalt\u00eb, kjo \u00ebsht\u00eb nj\u00eb p\u00ebrfundim mjaft i mir\u00eb.<\/p>\n<p><\/p>\n<p>N\u00eb fund arrit\u00ebm n\u00eb zgjidhjen e m\u00ebposhtme:<\/p>\n<p><\/p>\n<ul>\n<li>Kemi 360 nodet e t\u00eb dh\u00ebnave me disqe 700 gigabajt.<\/li>\n<li>60 koordinator\u00eb p\u00ebr routing t\u00eb trafikut n\u00eb k\u00ebto nodet e t\u00eb dh\u00ebnave.<\/li>\n<li>40 master-a, t\u00eb cilat na kan\u00eb mbetur si nj\u00eb trash\u00ebgimi nga versionet para 6.4.0 \u2014 p\u00ebr t\u00eb mbiquajtur daljen e qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave, ishim psikologjikisht t\u00eb gatsh\u00ebm t\u00eb humbnim disa makina, p\u00ebr t\u00eb garantuar madje edhe n\u00eb skenarin m\u00eb t\u00eb keq nj\u00eb kuorum master-i.<\/li>\n<li>\u00c7do p\u00ebrpjekje p\u00ebr t\u00eb kombinuar role n\u00eb nj\u00eb kontejner na p\u00ebrballi me faktin se p\u00ebrfundimisht ndonj\u00eb nod do t\u00eb prisheshin n\u00ebn ngarkes\u00eb. <\/li>\n<li>N\u00eb t\u00eb gjith\u00eb klasterin p\u00ebrdoret heap.size, e cila \u00ebsht\u00eb 31 gigabajt: \u00e7do p\u00ebrpjekje p\u00ebr t\u00eb ulur p\u00ebrmasat \u00e7onte n\u00eb faktin se n\u00eb k\u00ebrkesat e r\u00ebnda k\u00ebrkuese me wildcard, ndonj\u00ebher\u00eb do t\u00eb vriste ndonj\u00eb nod, ose do t\u00eb bllokohej breaker-i i qarkut n\u00eb vet\u00eb Elasticsearch.<\/li>\n<li>P\u00ebrve\u00e7 k\u00ebsaj, p\u00ebr t\u00eb siguruar performanc\u00ebn e k\u00ebrkimit, ne p\u00ebrpiqemi t\u00eb mbajm\u00eb numrin e objekteve n\u00eb klaster sa m\u00eb t\u00eb vog\u00ebl t\u00eb jet\u00eb e mundur, p\u00ebr t\u00eb p\u00ebrpunuar sa m\u00eb pak ngjarje n\u00eb vendin m\u00eb t\u00eb ngusht\u00eb, i cili doli t\u00eb ishte master-i.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">N\u00eb fund t\u00eb fundit, p\u00ebr monitorimin<\/h2>\n<p><\/p>\n<p>P\u00ebr ta b\u00ebr\u00eb k\u00ebt\u00eb t\u00eb funksionoj\u00eb si\u00e7 e kishim menduar, ne monitorojm\u00eb t\u00eb m\u00ebposhtmet:<\/p>\n<p><\/p>\n<ul>\n<li>\u00c7do nod i t\u00eb dh\u00ebnave raporton n\u00eb cloud-in ton\u00eb q\u00eb ekziston, dhe se n\u00eb t\u00eb gjenden k\u00ebto shard-e. Kur ne ndalojm\u00eb di\u00e7ka ndokund, klasteri brenda 2-3 sekondave raporton se n\u00eb qendr\u00ebn A kemi ndaluar nod\u00ebn 2, 3, dhe 4 \u2014 kjo do t\u00eb thot\u00eb se n\u00eb qendrat e tjera t\u00eb t\u00eb dh\u00ebnave nuk mund t\u00eb ndalojm\u00eb ato nodet mbi t\u00eb cilat mbeten shard-e t\u00eb vetme.<\/li>\n<li>Duke njohurit mbi sjelljen e mjeshtrit, ne i kushtojm\u00eb v\u00ebmendje t\u00eb madhe numrit t\u00eb detyrave t\u00eb pritura. Sepse edhe nj\u00eb detyr\u00eb e caktuar, n\u00ebse nuk p\u00ebrfundon n\u00eb koh\u00eb, teorikisht n\u00eb nj\u00eb situat\u00eb emergjente mund t\u00eb b\u00ebhet shkaku p\u00ebr t\u00eb cilin nuk do t\u00eb p\u00ebrfundoj\u00eb, p\u00ebr shembull, promovimi i replica-shard n\u00eb primary, duke mos e mund\u00ebsuar indeksonimin.<\/li>\n<li>Po ashtu, ne shikojm\u00eb me kujdes vonesat e garbage collector, sepse me k\u00ebt\u00eb kemi pasur v\u00ebshtir\u00ebsi t\u00eb m\u00ebdha gjat\u00eb optimizimit.<\/li>\n<li>Rejdhe p\u00ebr tread, p\u00ebr t\u00eb kuptuar paraprakisht ku ndodhet \"fqija e ngusht\u00eb\".<\/li>\n<li>Dhe metrikat standarde, si heap, RAM dhe I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Kur nd\u00ebrtojm\u00eb monitorimin, \u00ebsht\u00eb e domosdoshme t\u00eb merret parasysh karakteristikat e Thread Pool n\u00eb Elasticsearch. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Dokumentacioni i Elasticsearch<\/a><\/noindex> p\u00ebrshkruan mund\u00ebsit\u00eb e konfigurimit dhe vlerat e parazgjedhura p\u00ebr k\u00ebrkimin, indeksonimin, por nuk p\u00ebrmend fare thread_pool.management. K\u00ebto threads p\u00ebrpunojn\u00eb, p\u00ebr shembull, k\u00ebrkesat e tipit _cat\/shards dhe t\u00eb tjera t\u00eb ngjashme, t\u00eb cilat jan\u00eb t\u00eb dobishme p\u00ebr t\u00eb shkruar monitorimin. Sa m\u00eb i madh t\u00eb jet\u00eb klasteri, aq m\u00eb shum\u00eb k\u00ebrkesa t\u00eb tilla p\u00ebrpunohen n\u00eb nj\u00eb nj\u00ebsi kohe, dhe thread_pool.management i p\u00ebrmendur m\u00eb sip\u00ebr, p\u00ebrve\u00e7 faktit q\u00eb nuk \u00ebsht\u00eb i pranish\u00ebm n\u00eb dokumentacionin zyrtar, \u00ebsht\u00eb gjithashtu i limituar me 5 threads si parazgjedhje, t\u00eb cilat shfryt\u00ebzohen shum\u00eb shpejt, pas t\u00eb cilave monitorimi ndalon s\u00eb funksionuari sakt\u00eb.<\/p>\n<p><\/p>\n<p>Ajo q\u00eb d\u00ebshiroj t\u00eb them n\u00eb p\u00ebrfundim: ia dol\u00ebm! Ne arrit\u00ebm t'u ofrojm\u00eb programuesve dhe zhvilluesve tan\u00eb nj\u00eb mjet q\u00eb n\u00eb \u00e7do situat\u00eb \u00ebsht\u00eb n\u00eb gjendje t\u00eb ofroj\u00eb shpejt dhe sakt\u00eb informacion mbi gjith\u00e7ka q\u00eb ndodh n\u00eb prodhim.<\/p>\n<p><\/p>\n<p>Po, ishte mjaft e komplikuar, por megjithat\u00eb, ne arrit\u00ebm t'i p\u00ebrshtatim d\u00ebshirat tona n\u00eb produktet ekzistuese, t\u00eb cilat nuk ishin dashur t\u00eb patchohet dhe shkruhen p\u00ebrs\u00ebri p\u00ebr ne.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Klastri Elasticsearch mbi 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/494260\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435. \u041d\u043e \u0447\u0442\u043e \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442, \u043a\u043e\u0433\u0434\u0430 \u0445\u043e\u0447\u0435\u0448\u044c \u0441 \u0435\u0433\u043e \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438 \u00ab\u0432 \u043e\u0441\u043e\u0431\u043e \u043a\u0440\u0443\u043f\u043d\u043e\u043c \u043e\u0431\u044a\u0451\u043c\u0435\u00bb? \u0414\u0430 \u0435\u0449\u0451 \u0438 \u0431\u0435\u0437\u0431\u043e\u043b\u0435\u0437\u043d\u0435\u043d\u043d\u043e \u043f\u0435\u0440\u0435\u0436\u0438\u0432\u0430\u0442\u044c \u043e\u0442\u043a\u0430\u0437 \u043b\u044e\u0431\u043e\u0433\u043e \u0438\u0437 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u043e\u0432? \u041a\u0430\u043a\u043e\u0439 \u0441\u0442\u043e\u0438\u0442 \u0434\u0435\u043b\u0430\u0442\u044c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443, \u0438 \u043d\u0430 \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0435 \u043a\u0430\u043c\u043d\u0438 \u043d\u0430\u0442\u043a\u043d\u0451\u0448\u044c\u0441\u044f? \u041c\u044b \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0440\u0435\u0448\u0438\u043b\u0438 \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 elasticsearch \u0440\u0435\u0448\u0438\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441 \u043b\u043e\u0433-\u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442\u0430, \u0430 \u0442\u0435\u043f\u0435\u0440\u044c \u0434\u0435\u043b\u0438\u043c\u0441\u044f \u0441 \u0425\u0430\u0431\u0440\u043e\u043c \u043e\u043f\u044b\u0442\u043e\u043c: \u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":75797,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-75796","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043b\u0430\u0441\u0442\u0435\u0440 Elasticsearch \u043d\u0430 200 \u0422\u0411+ | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-03-28T17:42:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-28T17:42:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Klaster Elasticsearch mbi 200 TB+ | ProHoster","description":"Shumica p\u00ebrballet me Elasticsearch.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043b\u0430\u0441\u0442\u0435\u0440 Elasticsearch \u043d\u0430 200 \u0422\u0411+ | ProHoster","og:description":"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-28T17:42:18+00:00","article:modified_time":"2020-03-28T17:42:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"75796","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:49:32","updated":"2022-09-27 21:24:26","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}