{"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 t\u00eb ruash log-e \"n\u00eb nj\u00eb mas\u00eb t\u00eb madhe\" me ndihm\u00ebn e tij? Ndonj\u00ebher\u00eb, si mund ta kalosh pa dhimbje d\u00ebshtimin e ndonj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave? Si duhet t\u00eb jet\u00eb arkitektura dhe cilat jan\u00eb pengesat q\u00eb 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 ndajm\u00eb me Habr p\u00ebrvoj\u00ebn ton\u00eb: p\u00ebr arkitektur\u00ebn dhe pengesat.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Un\u00eb jam Pjotr Zaitsev, punoj si administrator sistemi n\u00eb Odnoklassniki. Para k\u00ebsaj kam qen\u00eb gjithashtu admin, kam punuar me Manticore Search, Sphinx search, Elasticsearch. Ndoshta, n\u00ebse shfaqet ndonj\u00eb &#8230;search tjet\u00ebr, do t\u00eb punoj edhe me t\u00eb. Gjithashtu, marr pjes\u00eb n\u00eb disa projekte open-source n\u00eb m\u00ebnyr\u00eb vullnetarizmi.<\/p>\n<p><\/p>\n<p>Kur erdha n\u00eb Odnoklassniki, thash\u00eb me guxim n\u00eb intervist\u00ebn e pun\u00ebs se di t\u00eb punoj me Elasticsearch. Pasi e m\u00ebsova dhe b\u00ebra disa detyra t\u00eb thjeshta, m\u00eb dhan\u00eb nj\u00eb detyr\u00eb t\u00eb madhe p\u00ebr reformimin e sistemit t\u00eb 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 u formuluan si m\u00eb posht\u00eb:<\/p>\n<p><\/p>\n<ul>\n<li>Si frontend duhej t\u00eb p\u00ebrdorej Graylog. Sepse n\u00eb kompani tashm\u00eb kishte p\u00ebrvoj\u00eb me k\u00ebt\u00eb produkt, programuesit dhe testuesit e dinin, ishte i njohur dhe i leht\u00eb p\u00ebr t'u p\u00ebrdorur.<\/li>\n<li>V\u00ebllimi i t\u00eb dh\u00ebnave: n\u00eb mesatare 50-80 mij\u00eb mesazhe n\u00eb sekond\u00eb, por n\u00ebse di\u00e7ka thyhet, trafiku nuk \u00ebsht\u00eb i kufizuar, mund t\u00eb jet\u00eb 2-3 milion rreshta n\u00eb sekond\u00eb.<\/li>\n<li>Pas diskutimit t\u00eb k\u00ebrkesave me klient\u00ebt p\u00ebr shpejt\u00ebsin\u00eb e p\u00ebrpunimit t\u00eb k\u00ebrkesave n\u00eb k\u00ebrkim, ne kuptuam se modeli tipik i p\u00ebrdorimit t\u00eb k\u00ebtij sistemi \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 rezultatin e k\u00ebrkes\u00ebs s\u00eb formuluar. <\/li>\n<li>Admin\u00ebt Insistuan q\u00eb sistemi t\u00eb ishte i leht\u00eb p\u00ebr t'u shkall\u00ebzuar n\u00eb rast nevoje, pa k\u00ebrkuar prej tyre nj\u00eb kuptim t\u00eb thell\u00eb se si ishte nd\u00ebrtuar. <\/li>\n<li>P\u00ebrve\u00e7 k\u00ebsaj, n\u00eb Odnoklassniki ekziston nj\u00eb tradit\u00eb e shk\u00eblqyer teknike: \u00e7do sh\u00ebrbim q\u00eb nisim duhet t\u00eb p\u00ebrballoj\u00eb d\u00ebshtimin e qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave (papritur, pa planifikim dhe n\u00eb \u00e7do koh\u00eb).<\/li>\n<li>Gjithashtu, p\u00ebrve\u00e7 k\u00ebsaj, ka nj\u00eb tradit\u00eb t\u00eb shk\u00eblqyer teknike n\u00eb Odnoklassniki: \u00e7do sh\u00ebrbim q\u00eb ne nisem duhet t\u00eb p\u00ebrballoj\u00eb d\u00ebshtimin e qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave (papritur, pa plan dhe n\u00eb \u00e7do koh\u00eb).<\/li>\n<\/ul>\n<p><\/p>\n<p>K\u00ebrkesat m\u00eb t\u00eb fundit p\u00ebr realizimin e k\u00ebtij projekti na kan\u00eb kushtuar m\u00eb s\u00eb shumti, p\u00ebr t\u00eb cil\u00ebn do t\u00eb flas m\u00eb n\u00eb detaje.<\/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\u00ebrsa nodet e Elasticsearch mund t\u00eb vendosen vet\u00ebm n\u00eb tri (p\u00ebr disa arsye joteknike).<\/p>\n<p><\/p>\n<p>N\u00eb k\u00ebto kat\u00ebr qendra t\u00eb t\u00eb dh\u00ebnave ndodhen rreth 18,000 burime t\u00eb ndryshme t\u00eb log\u00ebve \u2014 pajisje, kontejner\u00eb, makina virtuale.<\/p>\n<p><\/p>\n<p>Nj\u00eb ve\u00e7ori e r\u00ebnd\u00ebsishme: nisja e klasterit ndodh n\u00eb kontejner\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> jo n\u00eb makina 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>. Konejner\u00ebve u garantohet 2 b\u00ebrthama, t\u00eb ngjashme me 2.0Ghz v4 me mund\u00ebsi p\u00ebr t\u00eb shfryt\u00ebzuar b\u00ebrtham\u00ebn tjet\u00ebr, n\u00eb rast se ato jan\u00eb t\u00eb papunuara. <\/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 \u00ebsht\u00eb dukur fillimisht si m\u00eb posht\u00eb:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP q\u00ebndrojn\u00eb pas A-record-it t\u00eb domenit Graylog, kjo \u00ebsht\u00eb adresa ku d\u00ebrgohen log\u00ebt.<\/li>\n<li>\u00e7do VIP \u00ebsht\u00eb nj\u00eb balancues LVS.<\/li>\n<li>Pas tij, log\u00ebt kalojn\u00eb n\u00eb nj\u00eb grumbull Graylog, disa t\u00eb dh\u00ebna jan\u00eb n\u00eb formatin GELF, disa n\u00eb formatin syslog.<\/li>\n<li>Pastaj, t\u00eb gjitha k\u00ebto shkruhen n\u00eb m\u00ebnyr\u00eb t\u00eb madhe n\u00eb nj\u00eb grumbull t\u00eb koordinatoreve Elasticsearch. <\/li>\n<li>Dhe ata, nga ana e tyre, d\u00ebrgojn\u00eb k\u00ebrkesa p\u00ebr shkruanie dhe lexim te nodet 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\">Terminologjia<\/h2>\n<p><\/p>\n<p>Ndoshta, jo t\u00eb gjith\u00eb jan\u00eb t\u00eb njohur me terminologjin\u00eb, prandaj do t\u00eb doja t\u00eb ndalesha pak mbi t\u00eb.<\/p>\n<p><\/p>\n<p>N\u00eb Elasticsearch ka disa lloje nodash \u2014 master, coordinator, data node. Ka edhe dy lloje t\u00eb tjera p\u00ebr transformime t\u00eb ndryshme t\u00eb log\u00ebve dhe lidhjen mes klastereve t\u00eb ndryshme, por ne kemi p\u00ebrdorur vet\u00ebm ato t\u00eb p\u00ebrmendura. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPingar \u00e7do nod n\u00eb klaster, mb\u00ebshtet hart\u00ebn aktuale t\u00eb klasterit dhe e shp\u00ebrndan at\u00eb mes nodave, p\u00ebrpunon logjik\u00ebn e ngjarjeve dhe merret me lloje t\u00eb ndryshme t\u00eb mir\u00ebmbajtjes n\u00eb nivel klasteri. <\/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 lexim ose shkruanie dhe organizon k\u00ebt\u00eb trafik. N\u00eb rast se k\u00ebrkesa \u00ebsht\u00eb p\u00ebr shkruanie, \u00ebsht\u00eb shum\u00eb e mundshme q\u00eb ai t\u00eb pyes\u00eb master-in se n\u00eb cilin shard t\u00eb indeksit p\u00ebrkat\u00ebs ta vendos\u00eb at\u00eb dhe ta ridrejtoj\u00eb k\u00ebrkes\u00ebn m\u00eb tej. <\/p>\n<p><\/p>\n<p><strong>Data node<\/strong><br \/>\nRuaj t\u00eb dh\u00ebnat, p\u00ebrpunon k\u00ebrkesat e k\u00ebrkimit q\u00eb vijn\u00eb nga jasht\u00eb dhe operacione mbi shard-et e vendosura aty.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nKjo \u00ebsht\u00eb di\u00e7ka si nj\u00eb p\u00ebrzierje Kibana me Logstash n\u00eb ELK-stack. Graylog kombinon UI dhe procesin e p\u00ebrpunimit t\u00eb skedar\u00ebve t\u00eb logjeve. N\u00ebn kapak, n\u00eb Graylog punojn\u00eb Kafka dhe Zookeeper, t\u00eb cilat sigurojn\u00eb lidhshm\u00ebrin\u00eb e Graylog si nj\u00eb klaster. Graylog mund t\u00eb ruaj\u00eb logjet (Kafka) p\u00ebr rastet kur Elasticsearch nuk \u00ebsht\u00eb i arritsh\u00ebm dhe t\u00eb p\u00ebrs\u00ebris\u00eb k\u00ebrkesat e d\u00ebshtuara p\u00ebr lexim dhe shkrim, duke grupuar dhe etiketuar logjet sipas rregullave t\u00eb vendosura. Ashtu 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\u00ebr m\u00eb tep\u00ebr, n\u00eb Graylog ka nj\u00eb zbules\u00eb sh\u00ebrbimi t\u00eb integruar, e cila lejon q\u00eb, mbi baz\u00ebn e nj\u00eb nj\u00ebsie t\u00eb disponueshme Elasticsearch, t\u00eb merret e gjith\u00eb karta e klasterit dhe ta filtroj\u00eb at\u00eb sipas nj\u00eb etikete t\u00eb caktuar, duke e b\u00ebr\u00eb t\u00eb mundur d\u00ebrgimin e k\u00ebrkesave n\u00eb konteiner\u00eb t\u00eb caktuar.<\/p>\n<p><\/p>\n<p>Vishevisht kjo duket 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>Kjo \u00ebsht\u00eb nj\u00eb screenshot nga nj\u00eb instanc\u00eb specifike. K\u00ebtu ne nd\u00ebrtojm\u00eb histogramin n\u00eb baz\u00eb t\u00eb k\u00ebrkes\u00ebs, duke shfaqur stringjet relevante.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indeksi<\/h2>\n<p><\/p>\n<p>Duke u kthyer n\u00eb arkitektur\u00ebn e sistemit, do t\u00eb doja t\u00eb ndalesha m\u00eb n\u00eb holl\u00ebsi mbi se si ne nd\u00ebrtuam modelin e indekseve, n\u00eb m\u00ebnyr\u00eb q\u00eb gjith\u00e7ka t\u00eb funksionoj\u00eb sakt\u00eb. <\/p>\n<p><\/p>\n<p>N\u00eb skem\u00ebn e p\u00ebrmendur m\u00eb par\u00eb, ky \u00ebsht\u00eb niveli m\u00eb i ul\u00ebt: Elasticsearch data nodes.<\/p>\n<p><\/p>\n<p>Indeksi \u00ebsht\u00eb nj\u00eb ent virtual i madh, q\u00eb p\u00ebrb\u00ebhet nga shardet e Elasticsearch. \u00c7do shard \u00ebsht\u00eb asgj\u00eb tjet\u00ebr, ve\u00e7se nj\u00eb indeks Lucene. Dhe \u00e7do indeks Lucene, nga ana e tij, 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>Gjat\u00eb projektimit, ne parashikuam se p\u00ebr t\u00eb p\u00ebrmbushur k\u00ebrkes\u00ebn p\u00ebr shpejt\u00ebsin\u00eb e leximit mbi nj\u00eb volum t\u00eb madh t\u00eb dh\u00ebnash, na duheshin t\u00eb \u2018shp\u00ebrndanim\u2019 k\u00ebto t\u00eb dh\u00ebna n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb n\u00eb data nodes. <\/p>\n<p><\/p>\n<p>Kjo rezultoi n\u00eb faktin se numri i shardeve p\u00ebr indeks (me replikat) duhet t\u00eb jet\u00eb strikt nj\u00ebsoj me numrin e data nodes. S\u00eb pari, p\u00ebr t\u00eb siguruar nj\u00eb faktor replikimi t\u00eb barabart\u00eb me dy (pra mund t\u00eb humbasim gjysm\u00ebn e klasterit). Dhe, s\u00eb dyti, p\u00ebr t\u00eb p\u00ebrpunuar k\u00ebrkesat p\u00ebr lexim dhe shkrim, si minimalisht, n\u00eb gjysm\u00ebn e klasterit.<\/p>\n<p><\/p>\n<p>Koha e ruajtjes fillimisht u p\u00ebrcaktua si 30 dit\u00eb.<\/p>\n<p><\/p>\n<p>Shp\u00ebrndarja e shard\u00ebve mund t\u00eb paraqitet grafike k\u00ebshtu:<\/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. Kuadrati i kuq n\u00eb t\u00eb majt\u00eb \u00ebsht\u00eb primary shard, i pari n\u00eb indeks. Nd\u00ebrsa kuadrati blu \u00ebsht\u00eb replica shard. Ato ndodhen n\u00eb data-centra t\u00eb ndrysh\u00ebm.<\/p>\n<p><\/p>\n<p>Kur ne shtojm\u00eb nj\u00eb shard tjet\u00ebr, ai shkon n\u00eb qendr\u00ebn e t\u00eb dh\u00ebnave t\u00eb tret\u00eb. Dhe, n\u00eb fund, ne marrim k\u00ebt\u00eb struktur\u00eb, e cila siguron mund\u00ebsin\u00eb e humbjes s\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>Rrotacioni i indekseve, pra krijimi i nj\u00eb indeksi t\u00eb ri dhe fshirja e indeksit m\u00eb t\u00eb vjet\u00ebr, e b\u00ebm\u00eb t\u00eb barabart\u00eb me 48 or\u00eb (sip\u00ebr baz\u00ebs s\u00eb p\u00ebrdorimit t\u00eb indeksit: p\u00ebr 48 or\u00ebt e fundit k\u00ebrkohet m\u00eb shpesh).<\/p>\n<p><\/p>\n<p>Ky interval rrotacioni i indekseve \u00ebsht\u00eb i lidhur me arsyet e m\u00ebposhtme:<\/p>\n<p><\/p>\n<p>Kur n\u00eb nj\u00eb nod\u00eb t\u00eb dh\u00ebnash vjen nj\u00eb k\u00ebrkes\u00eb k\u00ebrkimi, nga pik\u00ebpamja e performanc\u00ebs \u00ebsht\u00eb m\u00eb e favorshme kur pyetet nj\u00eb shard, n\u00ebse dimensioni i tij \u00ebsht\u00eb i krahasuesh\u00ebm me madh\u00ebsin\u00eb e hips s\u00eb nod\u00ebs. Kjo lejon mbajtjen e pjes\u00ebs \"t\u00eb nxeht\u00eb\" t\u00eb indeksit n\u00eb hip dhe qasjen ndaj saj me shpejt\u00ebsi. Kur b\u00ebhen shum\u00eb \"pjes\u00eb t\u00eb nxehta\", shpejt\u00ebsia e k\u00ebrkimit n\u00eb indeks degradohet.<\/p>\n<p><\/p>\n<p>Kur nj\u00eb nod\u00eb fillon t\u00eb ekzekutoj\u00eb nj\u00eb k\u00ebrkes\u00eb k\u00ebrkimi n\u00eb nj\u00eb shard, ajo ndan numrin e thredhjeve, t\u00eb barabart\u00eb me numrin e b\u00ebrthamave t\u00eb hyper-threaded t\u00eb makin\u00ebs fizike. N\u00ebse k\u00ebrkesa e k\u00ebrkimit prek nj\u00eb num\u00ebr t\u00eb madh shard-esh, at\u00ebher\u00eb numri i thredhjeve rritet n\u00eb proporcjon. Kjo reflektohet negativisht n\u00eb shpejt\u00ebsin\u00eb e k\u00ebrkimit dhe ndikon negativisht n\u00eb indeksimin e t\u00eb dh\u00ebnave t\u00eb reja. <\/p>\n<p><\/p>\n<p>P\u00ebr t\u00eb siguruar latencin\u00eb 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 n\u00eb t\u00eb cilat ishin vendosur k\u00ebto konteiner\u00eb duhet t\u00eb kishin t\u00eb pakt\u00ebn 56 b\u00ebrtham\u00eb. Numri 56 \u00ebsht\u00eb zgjedhur si nj\u00eb vler\u00eb kushtimisht e mjaftueshme q\u00eb p\u00ebrcakton numrin e thread-eve q\u00eb do t\u00eb gjeneronte Elasticsearch gjat\u00eb funksionimit. N\u00eb Elasticsearch, shum\u00eb parametra t\u00eb thread pool varen drejtp\u00ebrdrejt nga numri i b\u00ebrthamave t\u00eb disponueshme, q\u00eb nga ana e saj ndikon drejtp\u00ebrdrejt n\u00eb numrin e nevojsh\u00ebm t\u00eb node-ve n\u00eb klaster sipas parimit \"m\u00eb pak b\u00ebrthama \u2014 m\u00eb shum\u00eb node\". <\/p>\n<p><\/p>\n<p>Si rezultat, na doli se, n\u00eb mesatare, nj\u00eb shard ka rreth 20 gigabajt, dhe p\u00ebr 1 indeks ka 360 shard-e. Prandaj, n\u00ebse i rrotatojm\u00eb \u00e7do 48 or\u00eb, do t\u00eb kemi 15 prej tyre. \u00c7do indeks p\u00ebrfshin t\u00eb dh\u00ebnat 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 shqyrtojm\u00eb se si regjistrohen t\u00eb dh\u00ebnat n\u00eb k\u00ebt\u00eb sistem.<\/p>\n<p><\/p>\n<p>Supozoni se nga Graylog na vjen nj\u00eb k\u00ebrkes\u00eb n\u00eb koordinator. P\u00ebr shembull, duam t\u00eb indeksojm\u00eb 2-3 mij\u00eb rreshta. <\/p>\n<p><\/p>\n<p>Kordinatori, pasi merr nj\u00eb k\u00ebrkes\u00eb nga Graylog, pyet masterin: \"N\u00eb k\u00ebrkes\u00ebn p\u00ebr indeksim, ne specifikisht kemi treguar indeksin, por nuk \u00ebsht\u00eb e specifikuar se n\u00eb cilin shard duhet t\u00eb shkruajm\u00eb.\" <\/p>\n<p><\/p>\n<p>Masteri p\u00ebrgjigjet: \"Shkruaj k\u00ebt\u00eb informacion n\u00eb shard num\u00ebr 71\", pas t\u00eb cilit ajo d\u00ebrgohet drejtp\u00ebrdrejt 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 repliktohet n\u00eb replica-shard, i cili ndodhet tashm\u00eb n\u00eb nj\u00eb qend\u00ebr t\u00eb dh\u00ebnash tjet\u00ebr.<\/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 kordinatorin vjen nj\u00eb k\u00ebrkes\u00eb p\u00ebr k\u00ebrkim. Kordinatorin e redirecton at\u00eb sipas indeksit, nd\u00ebrsa Elasticsearch ndan k\u00ebrkesat midis primary-shard dhe replica-shard n\u00eb m\u00ebnyr\u00eb 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 paekuilibruar, dhe, nd\u00ebrsa ato p\u00ebrgjigjen, kordinatorin mbledh informacionin q\u00eb \u00ebsht\u00eb \"p\u00ebrshtatur\" n\u00eb t\u00eb nga nodet m\u00eb t\u00eb shpejta t\u00eb t\u00eb dh\u00ebnave. Pas k\u00ebsaj, kur ose t\u00eb gjith\u00eb informacioni ka ardhur, ose \u00ebsht\u00eb arritur kufiri i k\u00ebrkes\u00ebs, i jep t\u00eb gjitha drejtp\u00ebrdrejt klientit. <\/p>\n<p><\/p>\n<p>E gjith\u00eb kjo sistem mesatarisht p\u00ebrpunon k\u00ebrkesat p\u00ebr k\u00ebrkim p\u00ebr 48 or\u00ebt e fundit brenda 300-400ms, duke p\u00ebrjashtuar ato k\u00ebrkesa q\u00eb kan\u00eb leading wildcard.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\"Lule\" 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 si\u00e7 e donim fillimisht, ne e kemi rregulluar p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb nj\u00eb s\u00ebr\u00eb gj\u00ebrash n\u00eb klaster. <\/p>\n<p><\/p>\n<p>Pjesa e par\u00eb e problemeve t\u00eb zbuluara ishte e lidhur me m\u00ebnyr\u00ebn se si Java \u00ebsht\u00eb e parakonfiguruar nga Elasticsearch. <\/p>\n<p><\/p>\n<p><strong>Problemi i par\u00eb.<\/strong><br \/>\nKemi v\u00ebn\u00eb re nj\u00eb num\u00ebr shum\u00eb t\u00eb madh mesazhesh se kemi nivelin Lucene, kur jan\u00eb aktivizuar pun\u00ebt e sfondit, bashkimi i segmenteve Lucene p\u00ebrfundon me gabim. N\u00eb log-e u pa se kjo ishte nj\u00eb gabim OutOfMemoryError. Nga telemetria, ne pam\u00eb q\u00eb hipi ishte i lir\u00eb, dhe nuk ishte e qart\u00eb pse kjo operacion po d\u00ebshtonte. <\/p>\n<p><\/p>\n<p>Doli se bashkimet e indekseve Lucene ndodhnin jasht\u00eb hap\u00ebsir\u00ebs s\u00eb memories. Dhe kontejner\u00ebt ishin shum\u00eb ashp\u00ebr t\u00eb kufizuar n\u00eb burimet e p\u00ebrdorura. N\u00eb k\u00ebto burime hynte vet\u00ebm hapi (vlera heap.size ishte af\u00ebrsisht e barabart\u00eb me RAM-in), dhe disa operacione off-heap d\u00ebshtonin me gabim alokimi, n\u00ebse p\u00ebr nj\u00eb arsye t\u00eb ndonj\u00eb lloj nuk p\u00ebrputheshin n\u00eb ato ~500MB q\u00eb mbeteshin deri n\u00eb limit.<\/p>\n<p><\/p>\n<p>Zgjidhja ishte mjaft triviale: ne rrit\u00ebm sasin\u00eb e RAM-it t\u00eb disponuesh\u00ebm p\u00ebr kontejnerin, pas s\u00eb cil\u00ebs harrojm\u00eb p\u00ebr k\u00ebto probleme q\u00eb kemi pasur.<\/p>\n<p><\/p>\n<p><strong>Problemi i dyt\u00eb.<\/strong><br \/>\nPas 4-5 dit\u00ebsh nga aktivizimi i klasterit, ne v\u00ebzhguam se nodet e t\u00eb dh\u00ebnave fillojn\u00eb t\u00eb dalin periodikisht nga klasteri dhe t\u00eb hyjn\u00eb n\u00eb t\u00eb pas 10-20 sekondash. <\/p>\n<p><\/p>\n<p>Kur na filluam t\u00eb shqyrtonim, u sendeua se kjo memorie off-heap n\u00eb Elasticsearch nuk kontrollohet pothuajse fare. Kur i dham\u00eb kontejnerit m\u00eb shum\u00eb memorie, mor\u00ebm mund\u00ebsin\u00eb t\u00eb mbushnim direkt grupet e tampon\u00ebve me informacion t\u00eb ndrysh\u00ebm, dhe ajo u pastrua vet\u00ebm pasi kishte filluar GC eksplicit nga Elasticsearch. <\/p>\n<p><\/p>\n<p>N\u00eb disa raste, kjo operacion ndodhte mjaft ngadal\u00eb, dhe gjat\u00eb k\u00ebsaj kohe klasteri kishte arritur ta sh\u00ebnonte 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\">ja k\u00ebtu<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Zgjidhja ishte si m\u00eb posht\u00eb: ne kufizuam Java-n q\u00eb t\u00eb p\u00ebrdor\u00eb pjes\u00ebn m\u00eb t\u00eb madhe t\u00eb memories jasht\u00eb heap p\u00ebr k\u00ebto operacione. Ne e kufizuam deri n\u00eb 16 gigabajt (-XX:MaxDirectMemorySize=16g), duke arritur q\u00eb GC eksplicit t\u00eb thirrej shum\u00eb m\u00eb shpesh dhe t\u00eb punonte shum\u00eb m\u00eb shpejt, duke mos e destabilizuar k\u00ebshtu klasterin.<\/p>\n<p><\/p>\n<p><strong>Problemi i tret\u00eb<\/strong><br \/>\nN\u00ebse mendoni se problemet me \"nodet q\u00eb l\u00ebn\u00eb klasterin n\u00eb momentin m\u00eb t\u00eb papritur\" p\u00ebrfundojn\u00eb k\u00ebtu, jeni n\u00eb gabim. <\/p>\n<p><\/p>\n<p>Kur konfiguruam pun\u00ebn me indekset, ne vendos\u00ebm p\u00ebr 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 sharda t\u00eb fresk\u00ebta me segmentim t\u00eb madh. Kjo ishte nj\u00eb gabim mjaft i r\u00ebnd\u00eb, sepse me p\u00ebrdorimin e mmapfs, skedari mapohet n\u00eb memorien operuese, dhe pastaj ne punojm\u00eb me skedarin e mapuar. P\u00ebr k\u00ebt\u00eb arsye, kur GC p\u00ebrpiqet t\u00eb ndal\u00eb thread-et n\u00eb aplikacion, ne shkojm\u00eb shum\u00eb ngadal\u00eb n\u00eb safepoint, dhe n\u00eb rrugen drejt tij, aplikacioni ndalet t\u00eb p\u00ebrgjigjet ndaj k\u00ebrkesave t\u00eb masterit p\u00ebr t\u00eb kuptuar n\u00ebse \u00ebsht\u00eb akoma aktiv. P\u00ebr pasoj\u00eb, master-i mendon se nodi nuk \u00ebsht\u00eb m\u00eb n\u00eb klaster. Pas rreth 5-10 sekondave, garbage collector punon, nodi rikthehet, futet p\u00ebrs\u00ebri n\u00eb klaster dhe fillon inicializimin e shardave. Gjith\u00eb kjo shum\u00eb m\u00eb shum\u00eb i ngjante \"prodhimit q\u00eb e merituam\" dhe nuk ishte e p\u00ebrshtatshme p\u00ebr ndonj\u00eb gj\u00eb serioze.<\/p>\n<p><\/p>\n<p>P\u00ebr t\u00eb shp\u00ebtuar nga ky sjellje, ne s\u00eb pari kaluam n\u00eb standardin niofs, dhe m\u00eb pas, kur migruam nga versionet pes\u00eb t\u00eb Elastic n\u00eb t\u00eb gjashtat, provuam hybridfs, ku ky problem nuk u reproduktua. M\u00eb shum\u00eb p\u00ebr llojet e 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 \/>\nPastaj kishte nj\u00eb problem tjet\u00ebr shum\u00eb interesante, t\u00eb cilin e trajtuam p\u00ebr nj\u00eb koh\u00eb rekord. E kap\u00ebm at\u00eb p\u00ebr 2-3 muaj, sepse ishte krejt\u00ebsisht e paqart\u00eb m\u00ebnyra e saj. <\/p>\n<p><\/p>\n<p>Ndonj\u00ebher\u00eb koordinuesit tan\u00eb shkonin n\u00eb Full GC, zakonisht diku pas drek\u00ebs, dhe nga aty nuk ktheheshin m\u00eb. Gjat\u00eb regjistrimit t\u00eb vonesave t\u00eb GC, kjo dukej k\u00ebshtu: gjith\u00e7ka shkonte mir\u00eb, mir\u00eb, mir\u00eb, pastaj papritmas \u2013 dhe gjith\u00e7ka b\u00ebhej ndryshe. <\/p>\n<p><\/p>\n<p>Fillimisht menduam se kishim nj\u00eb p\u00ebrdorues t\u00eb keq q\u00eb po ekzekutonte nj\u00eb k\u00ebrkes\u00eb, e cila po nxirrte koordinuesin nga funksionimi. Kemi regjistruar gjat\u00eb p\u00ebr k\u00ebrkesat, duke u munduar t\u00eb zbulojm\u00eb \u00e7far\u00eb po ndodhte. <\/p>\n<p><\/p>\n<p>N\u00eb fund u zbulua se n\u00eb momentin kur ndonj\u00eb p\u00ebrdorues po ekzekutonte nj\u00eb k\u00ebrkes\u00eb t\u00eb madhe dhe ajo i kalonte n\u00eb nj\u00eb koordinues specifik Elasticsearch, disa nodet p\u00ebrgjigjeshin m\u00eb ngadal\u00eb se t\u00eb tjer\u00ebt. <\/p>\n<p><\/p>\n<p>Dhe koha q\u00eb koordinuesi priste p\u00ebrgjigjet nga t\u00eb gjitha nodet, ai mblidhnin rezultate t\u00eb d\u00ebrguara nga nodet q\u00eb kishin p\u00ebrfunduar. P\u00ebr GC, kjo do t\u00eb thot\u00eb se modeli i p\u00ebrdorimit t\u00eb heap-it ndryshonte shum\u00eb shpejt. Dhe ai GC q\u00eb ne p\u00ebrdor\u00ebm, nuk p\u00ebrballonte k\u00ebt\u00eb detyr\u00eb. <\/p>\n<p><\/p>\n<p>I vetmi zgjidhje q\u00eb gjet\u00ebm p\u00ebr t\u00eb ndryshuar sjelljen e klasit n\u00eb nj\u00eb situat\u00eb t\u00eb till\u00eb ishte migrimi n\u00eb JDK13 dhe p\u00ebrdorimi i mbledh\u00ebsit t\u00eb mbetjeve Shenandoah. Kjo e zgjidhi problemin, koordinuesit tan\u00eb nuk ran\u00eb m\u00eb. <\/p>\n<p><\/p>\n<p>Me k\u00ebt\u00eb problemin me Java e mbyll\u00ebm dhe filluam problemet me kapacitetin. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u00abFrutat\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 n\u00ebnkuptojn\u00eb se klasteri yn\u00eb funksionon me stabilitet, por n\u00eb pikun e numrit t\u00eb dokumenteve t\u00eb indeksuara dhe gjat\u00eb manovrave, performanca \u00ebsht\u00eb e pamjaftueshme.<\/p>\n<p><\/p>\n<p>Simptoma e par\u00eb e hasur: gjat\u00eb disa \u00abeksplodimeve\u00bb n\u00eb prodhim, kur gjenerohej papritur nj\u00eb num\u00ebr shum\u00eb i madh log\u00ebsh, n\u00eb Graylog shpesh shfaqej gabimi i indeksimit es_rejected_execution. <\/p>\n<p><\/p>\n<p>Kjo ndodhte p\u00ebr shkak se thread_pool.write.queue n\u00eb nj\u00eb nod\u00eb t\u00eb dh\u00ebnash, deri n\u00eb momentin kur Elasticsearch \u00ebsht\u00eb n\u00eb gjendje t\u00eb p\u00ebrpunoj\u00eb k\u00ebrkes\u00ebn p\u00ebr indeksimin dhe t\u00eb d\u00ebrgoj\u00eb informacionin n\u00eb shardin n\u00eb disk, sipas parazgjedhjes \u00ebsht\u00eb n\u00eb gjendje t\u00eb ruaj\u00eb 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 e Elasticsearch<\/a><\/noindex> p\u00ebr k\u00ebt\u00eb Paramet\u00ebr thuhet shum\u00eb pak. Tregohet vet\u00ebm numri maksimal i thread-\u00ebve dhe madh\u00ebsia e parazgjedhur.<\/p>\n<p><\/p>\n<p>Sigurisht, ne shkuam ta rregullojm\u00eb k\u00ebt\u00eb vler\u00eb dhe zbuluam k\u00ebt\u00eb: konkretisht n\u00eb konfigurimin ton\u00eb, ruhet mjaft mir\u00eb deri n\u00eb 300 k\u00ebrkesa, nd\u00ebrsa nj\u00eb vler\u00eb m\u00eb e madhe \u00ebsht\u00eb e rrezikshme sepse ne s\u00ebrish shkojm\u00eb n\u00eb Full GC.<\/p>\n<p><\/p>\n<p>P\u00ebr m\u00eb tep\u00ebr, duke qen\u00eb se k\u00ebto jan\u00eb grupe mesazhesh q\u00eb vijn\u00eb brenda nj\u00eb k\u00ebrkese, ishte e nevojshme t\u00eb rregullohej Graylog q\u00eb t\u00eb shkruante jo shpesh dhe me grupe t\u00eb vogla, por me grupe t\u00eb m\u00ebdha ose \u00e7do 3 sekonda, n\u00ebse grupi ende nuk \u00ebsht\u00eb plot. N\u00eb k\u00ebt\u00eb rast, informata q\u00eb shkruajm\u00eb n\u00eb Elasticsearch b\u00ebhet e \u0434\u043e\u0441\u0442\u0443\u043fshme jo brenda dy sekondave, por brenda pes\u00eb (\u00e7ka na p\u00ebrshtatet mjaft), por numri i ritrajeve q\u00eb duhet t\u00eb b\u00ebjm\u00eb p\u00ebr t\u00eb shtyr\u00eb nj\u00eb grup t\u00eb madh informacioni zvog\u00eblohet.<\/p>\n<p><\/p>\n<p>Kjo \u00ebsht\u00eb ve\u00e7an\u00ebrisht e r\u00ebnd\u00ebsishme n\u00eb ato momente kur ndodhi ndonj\u00eb problem dhe gj\u00ebra t\u00eb tilla p\u00ebr t\u00eb mos marr\u00eb nj\u00eb Elastic t\u00eb mbushur plot, dhe pas nj\u00eb kohe \u2014 node t\u00eb pa funksionueshme p\u00ebr shkak t\u00eb mbushjes s\u00eb bufer\u00ebve t\u00eb Graylog.<\/p>\n<p><\/p>\n<p>P\u00ebr m\u00eb tep\u00ebr, kur ndodhnin k\u00ebto shp\u00ebrthime n\u00eb prodhim, merrnim ankesa nga programuesit dhe testuesit: n\u00eb momentin q\u00eb u duhej shum\u00eb k\u00ebto log-e, ato jepeshin shum\u00eb ngadal\u00eb.<\/p>\n<p><\/p>\n<p>Filluam t\u00eb hetonim. Nga nj\u00ebra an\u00eb, ishte e qart\u00eb se k\u00ebrkesat e k\u00ebrkimit dhe k\u00ebrkesat p\u00ebr indeksim punonin, n\u00eb thelb, n\u00eb t\u00eb nj\u00ebjtat makina fizike, dhe n\u00eb \u00e7do rast do t\u00eb kishte disa ulje. <\/p>\n<p><\/p>\n<p>Por kjo mund t\u00eb evitohej pjes\u00ebrisht p\u00ebr shkak se n\u00eb versionet e gjashta t\u00eb Elasticsearch doli nj\u00eb algorit\u00ebm q\u00eb lejonte shp\u00ebrndarjen e k\u00ebrkesave midis data-node-ve p\u00ebrkat\u00ebse jo n\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb rast\u00ebsishme round-robin (kontejneri q\u00eb merret me indeksimin dhe mban primary-shard mund t\u00eb jet\u00eb shum\u00eb i ngarkuar, nuk do t\u00eb kishte mund\u00ebsi t\u00eb p\u00ebrgjigjej shpejt), por p\u00ebr t\u00eb drejtuar k\u00ebt\u00eb k\u00ebrkes\u00eb n\u00eb nj\u00eb kontejner m\u00eb pak t\u00eb ngarkuar me replica-shard, i cili do t\u00eb p\u00ebrgjigjej ndjesh\u00ebm m\u00eb shpejt. N\u00eb fjal\u00eb t\u00eb tjera, arrit\u00ebm n\u00eb use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>Pamja e leximit fillon t\u00eb duket k\u00ebshtu:<\/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>Kalimi n\u00eb k\u00ebt\u00eb algorit\u00ebm lejoj t\u00eb p\u00ebrmir\u00ebsohej ndjesh\u00ebm koha e k\u00ebrkimit n\u00eb ato momente kur kishte nj\u00eb fluks t\u00eb madh log-esh p\u00ebr t\u00eb shkruar.<\/p>\n<p><\/p>\n<p>S\u00eb fundmi, problemi kryesor ishte dalja pa dhimbje e datacenter-it.<\/p>\n<p><\/p>\n<p>\u00c7far\u00eb doja nga klasteri menj\u00ebher\u00eb pas humbjes s\u00eb lidhjes me nj\u00eb DC: <\/p>\n<p><\/p>\n<ul>\n<li>N\u00ebse n\u00eb datacenter-in e humbur ndodhet master aktual, ai do t\u00eb rivot\u00ebsohet dhe do t\u00eb kaloj\u00eb si rol n\u00eb nj\u00eb node tjet\u00ebr n\u00eb nj\u00eb DC tjet\u00ebr.<\/li>\n<li>Masteri do t\u00eb p\u00ebrjashtoj\u00eb shpejt nga klasteri t\u00eb gjitha node-t\u00eb e pa akses.<\/li>\n<li>Duke u baz\u00eb t\u00eb atyre q\u00eb kan\u00eb mbetur, ai do t\u00eb kuptoj\u00eb: n\u00eb qendr\u00ebn e t\u00eb dh\u00ebnave t\u00eb humbura kemi pasur k\u00ebto primary-shard, do t'i promovoj\u00eb shpejt shard-et e replikuara n\u00eb qendrat e mbetura t\u00eb t\u00eb dh\u00ebnave, dhe indeksoni t\u00eb dh\u00ebnat do t\u00eb vazhdoj\u00eb. <\/li>\n<li>Si rezultat, kapaciteti i shkrimit dhe leximit t\u00eb klasterit do t\u00eb degradoj\u00eb ngadal\u00eb, megjithat\u00eb n\u00eb p\u00ebrgjith\u00ebsi gjith\u00e7ka do t\u00eb funksionoj\u00eb, ndon\u00ebse me ngadal\u00ebsi, por me stabilitet.<\/li>\n<\/ul>\n<p><\/p>\n<p>Si\u00e7 doli, ne doja di\u00e7ka si kjo:<\/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>Dhe mor\u00ebm 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>N\u00eb momentin e r\u00ebnies s\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave, pika jon\u00eb e ngusht\u00eb ishte masteri.<\/p>\n<p><\/p>\n<p>Pse?<\/p>\n<p><\/p>\n<p>E gjith\u00eb \u00e7\u00ebshtja \u00ebsht\u00eb se n\u00eb master ka nj\u00eb TaskBatcher, q\u00eb \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr shp\u00ebrndarjen e detyrave dhe aktiviteteve t\u00eb caktuara n\u00eb klaster. \u00c7do dalje e nod\u00ebs, \u00e7do promovim i shard-it nga replica n\u00eb primary, \u00e7do detyr\u00eb p\u00ebr t\u00eb krijuar ndonj\u00eb shard diku \u2014 gjith\u00e7ka kalon fillimisht n\u00eb TaskBatcher, ku p\u00ebrpunohen nj\u00eb pas nj\u00eb dhe n\u00eb nj\u00eb rrjedh\u00eb.<\/p>\n<p><\/p>\n<p>N\u00eb momentin e daljes s\u00eb nj\u00eb qendre t\u00eb dh\u00ebnash, dukej se t\u00eb gjith\u00eb nodat e mbetura n\u00eb qendrat e mbetura t\u00eb dh\u00ebnash besonin se ishte detyra e tyre t'i thonin masterit 'ne humb\u00ebm k\u00ebto shard dhe k\u00ebto data-node.' <\/p>\n<p><\/p>\n<p>Nd\u00ebrsa node-t e mbetura d\u00ebrgonin t\u00eb gjith\u00eb k\u00ebt\u00eb informacion te masteri aktual dhe p\u00ebrpiqeshin t\u00eb prisnin konfirmimin se ai e kishte pranuar. Ata nuk prisnin k\u00ebt\u00eb, pasi masteri merrte detyrat m\u00eb shpejt se sa arrinte t\u00eb p\u00ebrgjigjej. Nodat p\u00ebrs\u00ebrisnin k\u00ebrkesat pas skadimit, nd\u00ebrsa masteri n\u00eb at\u00eb koh\u00eb nuk p\u00ebrpiqej as t\u00eb p\u00ebrgjigjej, por ishte plot\u00ebsisht i z\u00ebn\u00eb me detyr\u00ebn e renditjes s\u00eb k\u00ebrkesave sipas prioriteteve.<\/p>\n<p><\/p>\n<p>N\u00eb form\u00ebn e fundit, dukej se nodat e t\u00eb dh\u00ebnave po bombarduan masterin deri sa ai shkonte n\u00eb full GC. Pas k\u00ebsaj, roli i masterit kalonte n\u00eb ndonj\u00eb nod\u00eb tjet\u00ebr, me t\u00eb cil\u00ebn ndodhte krejt\u00ebsisht e nj\u00ebjta gj\u00eb, dhe p\u00ebrfundimisht klasteri shkat\u00ebrrohej plot\u00ebsisht. <\/p>\n<p><\/p>\n<p>Ne b\u00ebm\u00eb matje dhe deri n\u00eb versionin 6.4.0, ku ky problem u zgjidh, ishte mjaft p\u00ebr t\u00eb nxjerr\u00eb nj\u00ebkoh\u00ebsisht vet\u00ebm 10 data-node nga 360 q\u00eb t\u00eb bllokonim plot\u00ebsisht klasterin.<\/p>\n<p><\/p>\n<p>Kjo dukej n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb:<\/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 serioz u korrigjua, node-t e t\u00eb dh\u00ebnave nuk e vrisnin m\u00eb masterin. Por ai nuk b\u00ebhej 'm\u00eb i zgjuar' nga kjo. Sakt\u00ebsisht: kur ne nxjerrim 2, 3 ose 10 (\u00e7do num\u00ebr p\u00ebrve\u00e7 nj\u00eb) data-node, masteri merr nj\u00eb mesazh t\u00eb par\u00eb q\u00eb thot\u00eb se nodi A doli dhe p\u00ebrpiqet t\u00eb tregoj\u00eb p\u00ebr k\u00ebt\u00eb p\u00ebr nodin B, nodin C, nodin D. <\/p>\n<p><\/p>\n<p>Dhe n\u00eb momentin aktual, kjo mund t\u00eb luftohet vet\u00ebm duke vendosur nj\u00eb koh\u00eb t\u00eb caktuar p\u00ebr tentativat p\u00ebr t\u00eb treguar dikujt di\u00e7ka, q\u00eb \u00ebsht\u00eb rreth 20-30 sekonda, dhe k\u00ebshtu t\u00eb menaxhohet shpejt\u00ebsia 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 ishin fillimisht vendosur p\u00ebr produktin p\u00ebrfundimtar n\u00eb kuad\u00ebr t\u00eb projektit, por nga pik\u00ebpamja e 'shkenc\u00ebs s\u00eb past\u00ebr' kjo \u00ebsht\u00eb nj\u00eb defekt. Ky, p\u00ebr t\u00eb cilin, me t\u00eb v\u00ebrtet\u00eb, ishte rregulluar me sukses nga zhvilluesit n\u00eb versionin 7.2.<\/p>\n<p><\/p>\n<p>Gjithashtu, kur nj\u00eb nod i dh\u00ebnash dilte, rezultonte se p\u00ebrhapja e informacionit rreth daljes s\u00eb saj ishte m\u00eb e r\u00ebnd\u00ebsishme se t\u00eb tregoheshin t\u00eb gjith\u00eb klasterit se n\u00eb t\u00eb ishin k\u00ebto primary-shard (p\u00ebr t\u00eb promovuar replica-shard 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 shkuar', nodet e dalura nuk sh\u00ebnohen si stale menj\u00ebher\u00eb. P\u00ebr rrjedhoj\u00eb, ne jemi t\u00eb detyruar t\u00eb presim deri sa t\u00eb kalojn\u00eb t\u00eb gjitha pings p\u00ebr nodet e dalura dhe vet\u00ebm pas k\u00ebsaj klasteri yn\u00eb fillon t\u00eb tregoj\u00eb se atje, atje dhe atje duhet t\u00eb vazhdohet regjistrimi i informacionit. M\u00eb shum\u00eb detaje 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>M\u00eb n\u00eb fund, operacioni i daljes s\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave sot z\u00eb rreth 5 minuta n\u00eb or\u00ebt e pikut. P\u00ebr nj\u00eb makin\u00eb kaq t\u00eb madhe dhe t\u00eb ngadalt\u00eb, ky \u00ebsht\u00eb nj\u00eb rezultat mjaft i mir\u00eb.<\/p>\n<p><\/p>\n<p>M\u00eb n\u00eb fund, ne arrit\u00ebm n\u00eb zgjidhjen n\u00eb vazhdim:<\/p>\n<p><\/p>\n<ul>\n<li>Ne kemi 360 nodet e dh\u00ebnash me disqe 700 gigabajt.<\/li>\n<li>60 koordinator\u00eb p\u00ebr t\u00eb rregulluar trafikun n\u00eb k\u00ebto nodet e dh\u00ebnash.<\/li>\n<li>40 mastera, t\u00eb cilat na kan\u00eb mbetur si nj\u00eb trash\u00ebgimi nga versionet para 6.4.0 \u2013 p\u00ebr t\u00eb p\u00ebrballuar daljen e qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave, ne ishim psikologjikisht t\u00eb gatsh\u00ebm t\u00eb humbnim disa makina, p\u00ebr t\u00eb garantuar q\u00eb edhe n\u00eb skenarin m\u00eb t\u00eb keq t\u00eb kishim nj\u00eb kuorum masterash.<\/li>\n<li>\u00c7do p\u00ebrpjekje p\u00ebr t\u00eb bashkuar role n\u00eb nj\u00eb kontejner na hasi n\u00eb faktin se her\u00ebt a von\u00eb nodi thyhej n\u00ebn ngarkes\u00eb. <\/li>\n<li>N\u00eb t\u00eb gjith\u00eb klasterin p\u00ebrdoret heap.size, i barabart\u00eb me 31 gigabajt: t\u00eb gjitha p\u00ebrpjekjet p\u00ebr t\u00eb zvog\u00ebluar madh\u00ebsin\u00eb \u00e7oi n\u00eb at\u00eb q\u00eb n\u00eb k\u00ebrkesat e r\u00ebnda t\u00eb k\u00ebrkimit me wildcard t\u00eb paracaktuar ose vrasin disa nodet, ose thyen circuit breaker 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\u00ebrpiqeshim t\u00eb mbajm\u00eb numrin e objekteve n\u00eb klaster sa m\u00eb minimal 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 q\u00eb kemi arritur n\u00eb master.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">N\u00eb fund p\u00ebr monitorimin<\/h2>\n<p><\/p>\n<p>P\u00ebr t\u00eb siguruar q\u00eb gjith\u00e7ka t\u00eb funksionoj\u00eb si\u00e7 pritej, ne monitorojm\u00eb:<\/p>\n<p><\/p>\n<ul>\n<li>\u00c7do data-node raporton n\u00eb re se ajo ekziston dhe ka k\u00ebto sharda t\u00eb vendosur. Kur ne fikim di\u00e7ka, klasteri raporton pas 2-3 sekondash se ne n\u00eb qendr\u00ebn A kemi fikur node 2, 3, dhe 4 \u2014 kjo do t\u00eb thot\u00eb se n\u00eb qendrat e tjera t\u00eb t\u00eb dh\u00ebnave, ne nuk mund t\u00eb fikim ato nodes ku ka sharda t\u00eb vetme.<\/li>\n<li>Duke njohur karakterin e sjelljes s\u00eb master, ne monitorojm\u00eb me kujdes numrin e detyrave n\u00eb pritje. Sepse edhe nj\u00eb detyr\u00eb e ngecur, n\u00ebse nuk \u00ebsht\u00eb b\u00ebr\u00eb timeout n\u00eb koh\u00eb, teorikisht n\u00eb nj\u00eb situat\u00eb emergjente mund t\u00eb b\u00ebhet shkaku q\u00eb nuk do t\u00eb funksionoj\u00eb, le t\u00eb themi, promovimi i replica-shard n\u00eb primary, duke shkaktuar ndalimin e indeksimit.<\/li>\n<li>Po ashtu, ne shikojm\u00eb me v\u00ebmendje vonesat e garbage collector, sepse kemi pasur v\u00ebshtir\u00ebsi t\u00eb m\u00ebdha me k\u00ebt\u00eb gjat\u00eb optimizimit.<\/li>\n<li>T\u00eb rejektuarit sipas threadave, p\u00ebr t\u00eb kuptuar paraprakisht ku ndodhet \"ngushtica\".<\/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, patjet\u00ebr duhet t\u00eb marrim parasysh ve\u00e7orit\u00eb 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 paracaktuara p\u00ebr k\u00ebrkimin, indeksimin, por e hesht plot\u00ebsisht p\u00ebr thread_pool.management. K\u00ebto thread-e trajtojn\u00eb, p\u00ebr shembull, k\u00ebrkesat e tipit _cat\/shards dhe t\u00eb tjera t\u00eb ngjashme, q\u00eb jan\u00eb t\u00eb dobishme p\u00ebr shkrimin e monitorimit. Sa m\u00eb i madh t\u00eb jet\u00eb klasteri, aq m\u00eb shum\u00eb k\u00ebrkesa t\u00eb tilla kryhen brenda nj\u00eb nj\u00ebsie kohe, dhe thread_pool.management i p\u00ebrmendur m\u00eb lart jo vet\u00ebm q\u00eb nuk \u00ebsht\u00eb p\u00ebrfaq\u00ebsuar n\u00eb dokumentacionin zyrtar, por ka edhe nj\u00eb limit t\u00eb p\u00ebrcaktuar prej 5 thread-a, q\u00eb shpenzohet shum\u00eb shpejt, pas s\u00eb cil\u00ebs monitorimi ndalon s\u00eb funksionuari si\u00e7 duhet.<\/p>\n<p><\/p>\n<p>\u00c7far\u00eb do doja t\u00eb thosha p\u00ebrfundimisht: ne arrit\u00ebm! Ne arrit\u00ebm t'u japim programuesve dhe zhvilluesve tan\u00eb nj\u00eb mjet q\u00eb pothuajse n\u00eb \u00e7do situat\u00eb mund t\u00eb ofroj\u00eb shpejt dhe sakt\u00eb informacionin rreth asaj q\u00eb po ndodh n\u00eb prodhim.<\/p>\n<p><\/p>\n<p>Po, kjo u b\u00eb mjaft e komplikuar, por megjithat\u00eb, arrit\u00ebm t'i p\u00ebrshtatim d\u00ebshirat tona n\u00eb produktet ekzistuese q\u00eb nuk e kishim nevoj\u00eb t'i patch-ojm\u00eb ose t'i shkruajm\u00eb nga e para.<\/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.2 - 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.2\" \/>\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\udd47Klasteri Elasticsearch mbi 200 TB+ | ProHoster","description":"Shum\u00eb p\u00ebrballen 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}]}}