{"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\/sl\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Elasticsearch grozd na 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>S \u0161tevilnimi se sre\u010duje Elasticsearch. Kaj se zgodi, ko \u017eeli\u0161 z njegovo pomo\u010djo shranjevati dnevni\u0161ke datoteke \u201ev izredno velikem obsegu\u201c? In kako brez te\u017eav prestati odpoved kateregakoli od ve\u010d podatkovnih centrov? Kak\u0161na arhitektura bi morala biti, in na katere pasti lahko naleti\u0161?<\/p>\n<p><\/p>\n<p>V Odnoklassniki smo se odlo\u010dili, da bomo s pomo\u010djo Elasticsearch re\u0161ili vpra\u0161anje upravljanja dnevnikov, zdaj pa delimo izku\u0161nje s Habr: tako o arhitekturi kot o pastih.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Sem jazdil na Pjotr Zajtsev, delam kot sistemski administrator v Odnoklassniki. Pred tem sem bil tudi administrator in delal sem z Manticore Search, Sphinx iskanje ter Elasticsearch. Morda, \u010de se bo pojavilo \u0161e kak\u0161no drugo \u2026 iskanje, bom verjetno delal tudi s tem. Poleg tega sodelujem v vrsti odprtokodnih projektov na prostovoljni osnovi.<\/p>\n<p><\/p>\n<p>Ko sem pri\u0161el v Odnoklassniki, sem nepreudarno dejal na razgovoru, da znam delati z Elasticsearch. Ko sem se ustalil in opravil nekaj preprostih nalog, so mi dali veliko nalogo o reformi sistema upravljanja dnevnikov, ki je obstoja takrat. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Zahteve<\/h2>\n<p><\/p>\n<p>Zahteve glede sistema so bile formulirane na naslednji na\u010din:<\/p>\n<p><\/p>\n<ul>\n<li>Kot frontend je moral biti uporabljen Graylog. Zato, ker je podjetje \u017ee imelo izku\u0161nje z uporabo tega izdelka, so ga programerji in testni in\u017eenirji poznali, bil jim je znan in udoben.<\/li>\n<li>Koli\u010dina podatkov: povpre\u010dno 50-80 tiso\u010d sporo\u010dil na sekundo, vendar pa, \u010de pride do napake, ni nobenih omejitev prometa, lahko je to 2-3 milijone vrstic na sekundo.<\/li>\n<li>Ko smo razpravljali o zahtevah naro\u010dnikov glede hitrosti obdelave iskalnih poizvedb, smo ugotovili, da je tipi\u010den vzorec uporabe takega sistema tak\u0161en: ljudje i\u0161\u010dejo dnevnike svojih aplikacij za zadnja dva dni in ne \u017eelijo \u010dakati na rezultat formulirane poizvedbe ve\u010d kot eno sekundo. <\/li>\n<li>Administratori so vztrajali pri tem, da se mora sistem po potrebi enostavno raz\u0161iriti, ne da bi od njih zahteval globoko razumevanje, kako deluje. <\/li>\n<li>Da je edina naloga vzdr\u017eevanja, ki so jo ti sistemi ob\u010dasno potrebovali, zamenjati kak\u0161no strojno opremo.<\/li>\n<li>Poleg tega v Odnoklassniki obstaja \u010dudovita tehni\u010dna tradicija: katerikoli servis, ki ga za\u017eenemo, mora prenesti odpoved podatkovnega centra (nenadno, nepri\u010dakovano in kadarkoli).<\/li>\n<\/ul>\n<p><\/p>\n<p>Zadnji zahtjev za implementaciju ovog projekta bio je najte\u017ei za nas, o \u010demu \u0107u jo\u0161 pri\u010dati detaljnije.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Okru\u017eenje<\/h2>\n<p><\/p>\n<p>Radimo na \u010detiri data centra, pri \u010demu se data \u010dvorovi Elasticsearch mogu nalaziti samo u tri (iz niza netehni\u010dkih razloga).<\/p>\n<p><\/p>\n<p>U ovim \u010detiri data centra se nalazi otprilike 18.000 razli\u010ditih izvora logova \u2014 hardver, kontejneri, virtualne ma\u0161ine.<\/p>\n<p><\/p>\n<p>Va\u017ena karakteristika: pokretanje klastera odvija se u kontejnerima <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> ne na fizi\u010dkim ma\u0161inama, ve\u0107 na <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">na\u0161em cloud proizvodu one-cloud<\/a><\/noindex>. Kontejnerima se garantiraju 2 jezgra, sli\u010dna 2.0Ghz v4, s mogu\u0107no\u0161\u0107u kori\u0161\u0107enja ostalih jezgara u slu\u010daju da su neaktivna. <\/p>\n<p><\/p>\n<p>Drugim re\u010dima:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/073bffbfc3cff761bfabe0773b7f4ebc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"topologiya\">Topologija<\/h2>\n<p><\/p>\n<p>Op\u0161ti izgled re\u0161enja mi se isprva video ovako:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP adrese su iza A-recorda domena Graylog, to je adresa na koju se \u0161alju logovi.<\/li>\n<li>svaki VIP predstavlja balansirnik LVS.<\/li>\n<li>Nakon njega, logovi dolaze do baterije Graylog, deo podataka ide u GELF formatu, deo u syslog formatu.<\/li>\n<li>Dalje se sve ovo u velikim serijama zapisuje u bateriju koordinatorskih \u010dvorova Elasticsearch. <\/li>\n<li>Oni, s druge strane, \u0161alju zahteve za upis i \u010ditanje relevantnim data \u010dvorovima. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/21efcdf6992a07e0c5e9b477c567cca9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"terminologiya\">Terminologija<\/h2>\n<p><\/p>\n<p>Mo\u017eda svi nisu detaljno upoznati sa terminologijom, pa bih se \u017eeleo malo zadr\u017eati na tome.<\/p>\n<p><\/p>\n<p>U Elasticsearch-u postoji nekoliko tipova \u010dvorova \u2014 master, coordinator, data node. Postoje i dva druga tipa za razli\u010dite transformacije logova i povezivanje razli\u010ditih klastera, ali smo koristili samo one navedene. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPinguje sve prisutne \u010dvorove u klasteru, odr\u017eava a\u017euriranu mapu klastera i \u0161iri je izme\u0111u \u010dvorova, obra\u0111uje event logiku, bavi se razli\u010ditim vrstama cluster wide posla. <\/p>\n<p><\/p>\n<p><strong>Coordinator<\/strong><br \/>\nObavlja jednu jedinu zadatak: prihvata zahteve klijenata za \u010ditanje ili upis i usmerava ovaj promet. U slu\u010daju da je zahtev za upis, verovatno \u0107e pitati master u koji shard relevantnog indeksa da ga smesti i preusmeriti zahtev dalje. <\/p>\n<p><\/p>\n<p><strong>Data node<\/strong><br \/>\n\u010cuva podatke, izvr\u0161ava pretra\u017eiva\u010dke zahteve koji dolaze spolja i operacije nad shardovima koji se na njoj nalaze.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nTo je nekak\u0161na me\u0161anica Kibane in Logstasha v ELK-steku. Graylog zdru\u017euje tako uporabni\u0161ki vmesnik kot tudi obdelovalni sistem za vrste dnevni\u0161kih zapisov. V ozadju Grayloga delujeta Kafka in Zookeeper, ki zagotavljata povezljivost Grayloga kot klasterja. Graylog lahko predpomni dnevni\u0161ke zapise (Kafka) v primeru, da Elasticsearch ni na voljo, in ponavlja neuspele poizvedbe za branje in pisanje ter grupira in ozna\u010duje dnevni\u0161ke zapise po dolo\u010denih pravilih. Kot Logstash ima Graylog funkcionalnost za spreminjanje nizov pred zapisovanjem v Elasticsearch.<\/p>\n<p><\/p>\n<p>Poleg tega Graylog vklju\u010duje vgrajeno odkrivanje storitev, ki na podlagi ene dostopne vozli\u0161\u010da Elasticsearch pridobi celotno karto klasterja in jo filtrira po dolo\u010denem ozna\u010devalcu, kar omogo\u010da usmerjanje poizvedb na dolo\u010dene kontejnere.<\/p>\n<p><\/p>\n<p>Vizualno to izgleda nekako tako:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>To je posnetek zaslona iz dolo\u010dene instance. Tukaj gradimo histogram na podlagi iskalnega poizvedovanja in prikazujemo relevantne nize.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indeksi<\/h2>\n<p><\/p>\n<p>Ko se vra\u010damo k arhitekturi sistema, bi rad podrobneje opisal, kako smo zgradili model indeksov, da je vse delovalo pravilno. <\/p>\n<p><\/p>\n<p>Na prej prikazani shemi je to najni\u017eja raven: Elasticsearch podatkovni vozli.<\/p>\n<p><\/p>\n<p>Indeks je velika virtualna entiteta, sestavljena iz shardov Elasticsearch. Vsak od shardov je v resnici ni\u010d drugega kot Lucene indeks. Vsak Lucene indeks pa je sestavljen iz enega ali ve\u010d segmentov. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pri na\u010drtovanju smo upo\u0161tevali, da moramo za zagotavljanje zahtev po hitrosti branja na velikih koli\u010dinah podatkov enakomerno 'razporediti' te podatke po podatkovnih vozli. <\/p>\n<p><\/p>\n<p>To se je izkazalo tako, da mora biti \u0161tevilo shardov na indeks (s podvoji) strogo enako \u0161tevilu podatkovnih vozli. Prvi\u010d, da se zagotovi faktor replikacije, ki je enak dvema (to pomeni, da lahko izgubimo polovico klasterja). In drugi\u010d, da se poizvedbe za branje in pisanje obdelujejo vsaj na polovici klasterja.<\/p>\n<p><\/p>\n<p>\u010cas shranjevanja smo najprej dolo\u010dili na 30 dni.<\/p>\n<p><\/p>\n<p>Porazdelitev shardov lahko grafi\u010dno prika\u017eemo takole:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Celoten temno sivi pravokotnik predstavlja indeks. Levi rde\u010d kvadrat v njem je primarni shard, prvi v indeksu. Svetlo moder kvadrat pa je replika shard. Nahajata se v razli\u010dnih podatkovnih centrih.<\/p>\n<p><\/p>\n<p>Ko\u6211\u4eec\u6dfb\u52a0\u53e6\u4e00\u4e2a\u5206\u7247\u65f6\uff0c\u5b83\u8fdb\u5165\u7b2c\u4e09\u4e2a\u6570\u636e\u4e2d\u5fc3\u3002\u6700\u7ec8\uff0c\u6211\u4eec\u5f97\u5230\u4e86\u8fd9\u6837\u7684\u7ed3\u6784\uff0c\u53ef\u4ee5\u5728\u4e0d\u635f\u5931\u6570\u636e\u4e00\u81f4\u6027\u7684\u60c5\u51b5\u4e0b\u5931\u53bb\u6570\u636e\u4e2d\u5fc3\uff1a<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u6211\u4eec\u5c06\u7d22\u5f15\u7684\u8f6e\u6362\uff0c\u5373\u521b\u5efa\u65b0\u7d22\u5f15\u548c\u5220\u9664\u6700\u65e7\u7d22\u5f15\u7684\u5468\u671f\u8bbe\u5b9a\u4e3a48\u5c0f\u65f6\uff08\u6839\u636e\u7d22\u5f15\u7684\u4f7f\u7528\u6a21\u5f0f\uff1a\u5728\u8fc7\u53bb48\u5c0f\u65f6\u5185\u88ab\u641c\u7d22\u7684\u9891\u7387\u6700\u9ad8\uff09\u3002<\/p>\n<p><\/p>\n<p>\u8fd9\u79cd\u7d22\u5f15\u8f6e\u6362\u7684\u65f6\u95f4\u95f4\u9694\u4e0e\u4ee5\u4e0b\u539f\u56e0\u6709\u5173\uff1a<\/p>\n<p><\/p>\n<p>\u5f53\u7279\u5b9a\u6570\u636e\u8282\u70b9\u63a5\u6536\u5230\u641c\u7d22\u8bf7\u6c42\u65f6\uff0c\u4ece\u6027\u80fd\u7684\u89d2\u5ea6\u6765\u770b\uff0c\u67e5\u8be2\u4e00\u4e2a\u5206\u7247\u66f4\u6709\u5229\uff0c\u524d\u63d0\u662f\u5b83\u7684\u5927\u5c0f\u4e0e\u8282\u70b9\u7684\u5806\u5185\u5b58\u5927\u5c0f\u76f8\u5f53\u3002\u8fd9\u4f7f\u5f97\u53ef\u4ee5\u5c06\u7d22\u5f15\u7684\u201c\u70ed\u201d\u90e8\u5206\u4fdd\u5b58\u5728\u5806\u4e2d\uff0c\u5e76\u8fc5\u901f\u8bbf\u95ee\u5b83\u3002\u5f53\u201c\u70ed\u201d\u90e8\u5206\u53d8\u591a\u65f6\uff0c\u7d22\u5f15\u641c\u7d22\u7684\u901f\u5ea6\u5c06\u4e0b\u964d\u3002<\/p>\n<p><\/p>\n<p>\u5f53\u8282\u70b9\u5f00\u59cb\u5728\u4e00\u4e2a\u5206\u7247\u4e0a\u6267\u884c\u641c\u7d22\u8bf7\u6c42\u65f6\uff0c\u5b83\u4f1a\u5206\u914d\u4e0e\u7269\u7406\u673a\u5668\u7684\u8d85\u7ebf\u7a0b\u6838\u6570\u91cf\u76f8\u7b49\u7684\u7ebf\u7a0b\u6570\u91cf\u3002\u5982\u679c\u641c\u7d22\u8bf7\u6c42\u6d89\u53ca\u5927\u91cf\u5206\u7247\uff0c\u5219\u7ebf\u7a0b\u6570\u91cf\u5c06\u6210\u6bd4\u4f8b\u589e\u52a0\u3002\u8fd9\u5bf9\u641c\u7d22\u901f\u5ea6\u6709\u4e0d\u5229\u5f71\u54cd\uff0c\u5e76\u4f1a\u5bf9\u65b0\u6570\u636e\u7684\u7d22\u5f15\u4ea7\u751f\u8d1f\u9762\u5f71\u54cd\u3002 <\/p>\n<p><\/p>\n<p>Da bi zagotovili potrebno latenco iskanja, smo se odlo\u010dili uporabiti SSD. Za hitro obdelavo poizvedb so morali imeti stroji, na katerih so bili name\u0161\u010deni ti kontejnerji, vsaj 56 jeder. \u0160tevilka 56 je bila izbrana kot pogojno zadostna koli\u010dina, ki dolo\u010da \u0161tevilo niti, ki jih bo ustvarjal Elasticsearch med delovanjem. V Elasticsearchu mnogi parametri thread pool neposredno odvisni od \u0161tevila razpolo\u017eljivih jeder, kar pa neposredno vpliva na potrebno \u0161tevilo vozli\u0161\u010d v gru\u010di po na\u010delu 'manj jeder - ve\u010d vozli\u0161\u010d'. <\/p>\n<p><\/p>\n<p>\u6700\u7ec8\u6211\u4eec\u5f97\u51fa\u4e86\u4e00\u4e2a\u7ed3\u8bba\uff0c\u5e73\u5747\u6bcf\u4e2a\u5206\u7247\u7684\u5927\u5c0f\u5927\u7ea6\u4e3a20GB\uff0c\u6bcf\u4e2a\u7d22\u5f15\u6709360\u4e2a\u5206\u7247\u3002\u56e0\u6b64\uff0c\u5982\u679c\u6211\u4eec\u6bcf48\u5c0f\u65f6\u8fdb\u884c\u4e00\u6b21\u8f6e\u6362\uff0c\u90a3\u4e48\u6211\u4eec\u5c06\u670915\u4e2a\u5206\u7247\u3002\u6bcf\u4e2a\u7d22\u5f15\u4fdd\u5b58\u4e86\u8fc7\u53bb\u4e24\u5929\u7684\u6570\u636e\u3002<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">\u6570\u636e\u7684\u5199\u5165\u548c\u8bfb\u53d6\u6a21\u5f0f<\/h2>\n<p><\/p>\n<p>\u8ba9\u6211\u4eec\u6765\u770b\u770b\u8fd9\u4e2a\u7cfb\u7edf\u4e2d\u6570\u636e\u662f\u5982\u4f55\u88ab\u5199\u5165\u7684\u3002<\/p>\n<p><\/p>\n<p>\u5047\u8bbe\u6211\u4eec\u4eceGraylog\u63a5\u6536\u5230\u67d0\u4e2a\u8bf7\u6c42\u5230\u534f\u8c03\u5668\u3002\u4f8b\u5982\uff0c\u6211\u4eec\u60f3\u7d22\u5f152000-3000\u884c\u3002 <\/p>\n<p><\/p>\n<p>Koordinator, ki je prejel pro\u0161njo od Graylog, povpra\u0161a mojstra: \u201eV pro\u0161nji za indeksacijo je bil konkretno naveden indeks, toda v katero shardo to zapisati \u2014 ni navedeno.\u201c <\/p>\n<p><\/p>\n<p>Mojster odgovori: \u201eZapi\u0161i te informacije v shard \u0161tevilka 71\u201c, nato se usmeri neposredno na ustrezno podatkovno vozli\u0161\u010de, kjer se nahaja primary-shard \u0161tevilka 71.<\/p>\n<p><\/p>\n<p>Nato se dnevnik transakcij replicira na replica-shard, ki se \u017ee nahaja v drugem podatkovnem centru.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Iz Grayloga v koordinator pride iskalna poizvedba. Koordinator jo preusmeri po indeksu, pri \u010demer Elasticsearch na principu round-robin porazdeli poizvedbe med primary-shard in replica-shard. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vozli\u0161\u010da v \u0161tevilu 180 odgovarjajo neenakomerno, in medtem ko odgovarjajo, koordinator zbira informacije, ki so jih \u017ee 'izpljunili' hitrej\u0161i podatkovni vozli. \u0160ele ko pride vsa informacija ali ko je dose\u017een \u010dasovni iztek poizvedbe, vse posreduje neposredno stranki. <\/p>\n<p><\/p>\n<p>Celotna ta sistem v povpre\u010dju obdeluje iskalne poizvedbe za zadnjih 48 ur za 300-400 ms, razen tistih poizvedb, ki vsebujejo leading wildcard.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\u201eCveti\u010dki\u201c z Elasticsearch: nastavitev Java<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Da bi vse to delovalo tako, kot smo prvotno \u017eeleli, smo zelo dolgo nastavljali najbolj razli\u010dne zadeve v grozdu. <\/p>\n<p><\/p>\n<p>Prvi del odkritih te\u017eav je bil povezan s tem, kako je v Elasticsearch privzeto nastavljena Java. <\/p>\n<p><\/p>\n<p><strong>Te\u017eava prva<\/strong><br \/>\nOpazili smo zelo veliko \u0161tevilo poro\u010dil, da imamo na ravni Lucene, ko so zagnane background job'i, zdru\u017eevanje segmentov Lucene kon\u010da z napako. Pri tem je bilo v dnevnikih vidno, da gre za OutOfMemoryError napako. Po telemetriji smo videli, da je hip prost, in ni bilo jasno, zakaj ta operacija naleti na te\u017eave. <\/p>\n<p><\/p>\n<p>Ugotovili smo, da se zdru\u017eevanje Lucene indeksov dogaja zunaj hipa. Posode so precej strogo omejene glede porabe virov. V te vire je vstopal samo hip (vrednost heap.size je bila pribli\u017eno enaka RAM-u), medtem ko so nekateri off-heap postopki padali z napako pri dodeljevanju pomnilnika, \u010de niso zaradi kakr\u0161nega koli razloga ustrezali tistim ~500MB, ki so ostali do omejitve.<\/p>\n<p><\/p>\n<p>Re\u0161itev je bila precej trivialna: dostopni obseg RAM za posodo smo pove\u010dali, nato pa smo pozabili, da smo imeli tak\u0161ne te\u017eave.<\/p>\n<p><\/p>\n<p><strong>Te\u017eava druga<\/strong><br \/>\n\u010cez 4-5 dni po zagonu grozda smo opazili, da se podatkovna vozli\u0161\u010da ob\u010dasno izklapljajo iz grozda in ponovno vstopajo v njem po 10-20 sekundah. <\/p>\n<p><\/p>\n<p>Ko smo se po\u010deli baviti problemom, otkrilo se da se off-heap memorija u Elasticsearch-u prakti\u010dno nikako ne kontrolira. Kada smo kontejneru dodali vi\u0161e memorije, dobili smo mogu\u0107nost da punimo direktne bafer pule razli\u010ditim informacijama, a ona se \u010di\u0161tila samo kada je eksplicitni GC pokrenut sa strane Elasticsearch-a. <\/p>\n<p><\/p>\n<p>U nekim slu\u010dajevima ova operacija je trajala prili\u010dno dugo, a tokom tog vremena klaster je uspeo da ozna\u010di ovu nodu kao ve\u0107 napustilu klaster. Ovaj problem je dobro opisan. <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">tukaj<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Re\u0161enje je bilo slede\u0107e: ograni\u010dili smo Java mogu\u0107nost da koristi ve\u0107inu memorije van heapa za te operacije. Ograni\u010dili smo je na 16 gigabajta (-XX:MaxDirectMemorySize=16g), postigav\u0161i da se eksplicitni GC poziva znatno \u010de\u0161\u0107e, a da se br\u017ee izvr\u0161ava, \u010dime se klaster vi\u0161e nije destabilizovao.<\/p>\n<p><\/p>\n<p><strong>Problem tri<\/strong><br \/>\nAko mislite da su problemi sa \"nodama koje napu\u0161taju klaster u najnepredvidivijim momentima\" ovde zavr\u0161eni, varate se. <\/p>\n<p><\/p>\n<p>Kada smo konfigurisali rad sa indeksima, odlu\u010dili smo se za mmapfs, kako bismo <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">skratili vreme pretrage<\/a><\/noindex> po sve\u017eim shard-ovima sa velikom segmentacijom. To je bila prili\u010dno gruba gre\u0161ka, jer se prilikom kori\u0161\u0107enja mmapfs datoteka mapi u radnu memoriju, a dalje radimo sa mapiranom datotekom. Zbog toga, prilikom poku\u0161aja GC-a da zaustavi niti u aplikaciji, jako dugo idemo do safepoint-a, a putem do njega aplikacija prestaje da odgovara na zahteve master-a o tome da li je jo\u0161 uvek \u017eiva. Samim tim, master smatra da nod vi\u0161e nije prisutan u klasteru. Nakon toga, za 5-10 sekundi pokre\u0107e se sakuplja\u010d sme\u0107a, noda o\u017eivljava, ponovo ulazi u klaster i zapo\u010dinje inicijalizaciju shard-ova. Sve to je veoma podse\u0107alo na \"proizvodnju koju smo zaslu\u017eili\" i nije bilo prikladno za bilo \u0161ta ozbiljno.<\/p>\n<p><\/p>\n<p>Da bismo se oslobodili takvog pona\u0161anja, prvo smo pre\u0161li na standardni niofs, a zatim, kada smo se sa petih verzija Elastic migrirali na \u0161este, probali smo hybridfs, gde se ovaj problem nije ponavljao. Vi\u0161e o tipovima skladi\u0161ta mo\u017eete pro\u010ditati. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">ovde<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Problem \u010detiri<\/strong><br \/>\nKasnije je do\u0161lo do jo\u0161 jednog veoma fascinantnog problema koji smo le\u010dili rekordno dugo. Uhvatili smo ga 2-3 meseca, jer njegov obrazac apsolutno nije bio jasan. <\/p>\n<p><\/p>\n<p>V\u010dasih so na\u0161i koordinatorji \u0161li v Full GC, obi\u010dajno nekje po kosilu, in se od tam niso ve\u010d vrnili. Pri tem je zaklepanju zamud GC to izgledalo tako: vse poteka dobro, dobro, dobro, nato pa kar naenkrat postane vse slabo. <\/p>\n<p><\/p>\n<p>Sprva smo mislili, da imamo zle uporabnike, ki izvajajo neko poizvedbo, ki vr\u017ee koordinatorja iz delovnega na\u010dina. Dolgo smo bele\u017eili poizvedbe, da bi ugotovili, kaj se dogaja. <\/p>\n<p><\/p>\n<p>Na koncu se je izkazalo, da ob trenutku, ko kateri koli uporabnik spro\u017ei zelo veliko poizvedbo, in ta pride na dolo\u010den koordinator Elasticsearch, nekatere vozli\u0161\u010da odgovarjajo dlje kot druga. <\/p>\n<p><\/p>\n<p>In tisto vreme, ki ga koordinator \u010daka na odgovore vseh vozli\u0161\u010d, zbira rezultate, ki jih po\u0161iljajo \u017ee odgovorjena vozli\u0161\u010da. Za GC to pomeni, da se na\u0161 vzorec uporabe heapa zelo hitro spremeni. In tisti GC, ki smo ga uporabljali, se s to nalogo ni spopadel. <\/p>\n<p><\/p>\n<p>Edina re\u0161itev, ki smo jo na\u0161li za spremembo vedenja klasterja v tak\u0161ni situaciji \u2014 migracija na JDK13 in uporaba zbiralnika odpadkov Shenandoah. To je re\u0161ilo te\u017eavo, na\u0161i koordinatorji so prenehali padati. <\/p>\n<p><\/p>\n<p>S tem so se te\u017eave z Javo kon\u010dale in za\u010dele so se te\u017eave s prepustnostjo. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u201eJagode\u201c z Elasticsearch: prepustnost<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Te\u017eave s prepustnostjo pomenijo, da na\u0161 klaster deluje stabilno, vendar pri vrhuncih \u0161tevila indeksiranih dokumentov in med manevri zmogljivost ni zadostna.<\/p>\n<p><\/p>\n<p>Prvi opa\u017eeni simptom: pri nekaterih \u201eeksplozijah\u201c na produkciji, ko se nenadoma generira zelo veliko koli\u010dino logov, se v Graylogu pogosto pojavlja napaka indeksiranja es_rejected_execution. <\/p>\n<p><\/p>\n<p>To se je dogajalo, ker thread_pool.write.queue na eni podatkovni vozli\u0161\u010du, preden je Elasticsearch uspel obdelati poizvedbo za indeksiranje in poslati informacije na shard na disk, po privzetku zna shraniti le 200 poizvedb. In <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">v dokumentaciji Elasticsearch<\/a><\/noindex> o tej vrednosti je zelo malo povedanega. Omenjeno je le najve\u010dje \u0161tevilo niti in privzeta velikost.<\/p>\n<p><\/p>\n<p>Seveda smo \u0161li prilagajati to vrednost in ugotovili naslednje: konkretno v na\u0161i nastavitvi se do 300 poizvedb zelo dobro shranjuje, ve\u010dja vrednost pa ogro\u017ea, da bomo ponovno za\u0161li v Full GC.<\/p>\n<p><\/p>\n<p>Poleg tega, ker gre za pakete sporo\u010dil, ki prispevajo znotraj enega zahtevka, je bilo treba \u0161e prilagoditi Graylog, da naj ne zapisuje pogosto in v majhnih paketih, temve\u010d v velikih paketih ali enkrat na 3 sekunde, \u010de paket \u0161e ni poln. V tem primeru torej informacije, ki jih v Elasticsearch zapisujemo, postanejo dostopne ne v dveh sekundah, temve\u010d v petih (kar nas povsem zadostuje), a se zmanj\u0161a \u0161tevilo ponovitev, ki jih je treba opraviti, da potisnemo velik paket informacij.<\/p>\n<p><\/p>\n<p>To je \u0161e posebej pomembno v trenutkih, ko nam kaj odpove nekje in to mo\u010dno sporo\u010da, da ne bi dobili popolnoma zasi\u010denega Elastica, in po dolo\u010denem \u010dasu \u2014 neoperativnih vozli\u0161\u010d Grayloga zaradi zama\u0161enih porabnikov.<\/p>\n<p><\/p>\n<p>Poleg tega, ko so se te eksplozije dogajale v produkciji, smo prejemali prito\u017ebe programerjev in testerjev: v trenutku, ko so nujno potrebovali te dnevni\u0161ke zapise, so bili dostavljeni zelo po\u010dasi.<\/p>\n<p><\/p>\n<p>Za\u010deli smo raziskovati. Na eni strani je bilo jasno, da tako iskalni zahtevki kot tudi zahtevki za indeksacijo dejansko delujejo na istih fizi\u010dnih strojih, zato bo na tak ali druga\u010den na\u010din pri\u0161lo do dolo\u010denih upadov zmogljivosti. <\/p>\n<p><\/p>\n<p>Toda temu se je bilo delno mogo\u010de izogniti, saj je v \u0161esti razli\u010dici Elasticsearch pri\u0161el algoritem, ki omogo\u010da razporejanje zahtevkov med relevantnimi podatkovnimi vozli\u0161\u010di, ne po naklju\u010dnem principu round-robin (konteiner, ki se ukvarja z indeksacijo in dr\u017ei primary-shard, je lahko zelo obremenjen, tam ne bo mo\u017enosti za hitro odgovoriti), temve\u010d usmeriti ta zahtevek na manj obremenjen konteiner z replica-shard, ki bo odgovoril precej hitreje. Z drugimi besedami, pri\u0161li smo do use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>Slika branja za\u010dne izgledati tako:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Prehod na ta algoritem je omogo\u010dil znatno izbolj\u0161anje \u010dasa poizvedbe v tistih trenutkih, ko je bil na\u0161 veliki tok dnevnikov za zapis.<\/p>\n<p><\/p>\n<p>Nazadnje, glavna te\u017eava je bila brez bole\u010dega izklopa podatkovnega centra.<\/p>\n<p><\/p>\n<p>Kaj smo \u017eeleli od klustra takoj po izgubi povezave z enim DC: <\/p>\n<p><\/p>\n<ul>\n<li>\u010ce je v odpadlem podatkovnem centru trenutni master, bo ponovno izbran in prestavljen kot vloga na drugo vozli\u0161\u010de v drugem DC.<\/li>\n<li>Master bo hitro izklju\u010dil iz klustra vsa nedostopna vozli\u0161\u010da.<\/li>\n<li>Na podlagi preostalih bo razumel: v izgubljenem podatkovnem centru smo imeli tak\u0161ne primary sharde, hitro bo promoviral komplementarne replica sharde v preostalih podatkovnih centrih in indeksacija podatkov se bo nadaljevala. <\/li>\n<li>Kot rezultat tega bo prepustnost klasterja za pisanje in branje postopoma degradirala, vendar bo na splo\u0161no vse delovalo, \u010deprav po\u010dasi, a stabilno.<\/li>\n<\/ul>\n<p><\/p>\n<p>Kot se je izkazalo, smo \u017eeleli nekaj takega:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In dobili smo tole:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kako je to mogo\u010de? <\/p>\n<p><\/p>\n<p>V trenutku padca podatkovnega centra je bila na\u0161o ozko grlo master.<\/p>\n<p><\/p>\n<p>Zakaj?<\/p>\n<p><\/p>\n<p>Gre za to, da v masterju obstaja TaskBatcher, ki je odgovoren za \u0161irjenje nekaterih nalog in dogodkov v klasterju. Vsak izlet vozli\u0161\u010da, vsako napredovanje sharda iz replica v primary, vsaka naloga za ustvarjanje kje kak\u0161nega sharda \u2014 vse to najprej pride v TaskBatcher, kjer se obravnava zaporedno in v enem toku.<\/p>\n<p><\/p>\n<p>V trenutku izpada enega podatkovnega centra je bilo tako, da so v pre\u017eivelih podatkovnih centrih vse podatkovne vozli\u0161\u010da menila, da morajo obvestiti masterja \u201eizgubili smo take in take sharde ter take in take podatkovne vozli\u0161\u010da\u201c. <\/p>\n<p><\/p>\n<p>Pri tem so pre\u017eivela podatkovna vozli\u0161\u010da po\u0161iljala vse te informacije trenutnemu masterju in posku\u0161ala \u010dakati na potrditev, da jo je sprejel. Te potrditve niso \u010dakali, saj je master prejel naloge hitreje, kot je lahko odgovarjal. Vozli\u0161\u010da so po \u010dasovnem limitu ponavljala zahtevke, master pa je v tem \u010dasu \u017ee samo posku\u0161al razporediti zahtevke po prioritetah.<\/p>\n<p><\/p>\n<p>Na koncu je izgledalo, da so podatkovna vozli\u0161\u010da spamala masterja do te mere, da je pre\u0161el v full GC. Po tem je vlogo masterja prevzelo kak\u0161no naslednje vozli\u0161\u010de, pri \u010demer se je zgodilo enako, in na koncu se je klaster popolnoma razpadel. <\/p>\n<p><\/p>\n<p>Izvajali smo meritve in do razli\u010dice 6.4.0, kjer je bila ta te\u017eava odpravljena, je bilo dovolj, da je hkrati izpademo le 10 podatkovnih vozli\u0161\u010d od 360, da bi popolnoma ustavili klaster.<\/p>\n<p><\/p>\n<p>Izgledalo je nekako tako:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Po razli\u010dici 6.4.0, kjer so popravili to grozno napako, podatkovna vozli\u0161\u010da niso ve\u010d ubijala masterja. A \u201ebolj pametnej\u0161i\u201c od tega ni postal. Namre\u010d: ko izklopimo 2, 3 ali 10 (katerokoli \u0161tevilo, razli\u010dno od enega) podatkovnih vozli\u0161\u010d, master prejme neko prvo sporo\u010dilo, ki pravi, da je vozli\u0161\u010de A izklopljeno, in posku\u0161a obvestiti vozli\u0161\u010de B, vozli\u0161\u010de C, vozli\u0161\u010de D. <\/p>\n<p><\/p>\n<p>Trenutno se s tim mo\u017eemo boriti samo postavljanjem vremenskog ograni\u010denja na poku\u0161aje nekome ne\u0161to re\u0107i, koje iznosi otprilike 20-30 sekundi, a time upravljamo brzinom izlaska data centra iz klastera.<\/p>\n<p><\/p>\n<p>U principu, ovo se uklapa u zahteve koji su prvobitno postavljeni za kona\u010dni proizvod u okviru projekta, ali sa stanovi\u0161ta '\u010diste nauke', ovo je gre\u0161ka. Koja je, ina\u010de, uspe\u0161no ispravljena od strane developera u verziji 7.2.<\/p>\n<p><\/p>\n<p>Naime, kada odre\u0111ena data-noda izlazi, ispostavlja se da je \u0161irenje informacija o njenom izlasku va\u017enije nego obave\u0161tavanje celog klastera da su na njoj bili takvi primarni \u0161ardovi (kako bi se promovisali replikacijski \u0161ardovi u drugom data centru u primarni, i mogla se pisati informacija).<\/p>\n<p><\/p>\n<p>Zato, kada se sve \u2018slegne\u2019, izlazne data-node se ne ozna\u010davaju odmah kao zastarele. Shodno tome, prisiljeni smo da \u010dekamo da svi pingovi odstoje prema izlaznim data-nodama i tek nakon toga na\u0161 klaster po\u010dinje obave\u0161tavati o tome gde je potrebno nastaviti pisanje informacija. O ovome mo\u017eete pro\u010ditati vi\u0161e <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">ovde<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Na kraju, operacija izlaska data centra nam danas traje oko 5 minuta u \u0161picu. Za ovako veliku i sporu ma\u0161inu, to je prili\u010dno dobar rezultat.<\/p>\n<p><\/p>\n<p>Na kraju smo do\u0161li do slede\u0107eg re\u0161enja:<\/p>\n<p><\/p>\n<ul>\n<li>Imamo 360 data-noda sa diskovima od 700 gigabajta.<\/li>\n<li>60 koordinatora za usmeravanje saobra\u0107aja po ovim data-nodama.<\/li>\n<li>40 mastera, koji su nam ostali kao neka vrsta nasle\u0111a iz vremena pre verzije 6.4.0 \u2014 da bismo pre\u017eiveli izlaz data centra, morali smo da budemo psihi\u010dki spremni da izgubimo nekoliko ma\u0161ina, kako bismo garantirali kvorum mastera \u010dak i u najgorem scenariju.<\/li>\n<li>Sve poku\u0161aje kombinovanja uloga na jednoj kontejnere zapravo su se suo\u010davale s tim da pre ili kasnije noda nije izdr\u017eavala optere\u0107enje. <\/li>\n<li>U celom klasteru koristi se heap.size koji iznosi 31 gigabajt: svi poku\u0161aji smanjenja veli\u010dine doveli su do toga da su te\u0161ki pretra\u017eiva\u010dki upiti sa leading wildcard ili ubijali neke nodove, ili bi se circuit breaker aktivirao unutar samog Elasticsearch-a.<\/li>\n<li>Pored toga, za obezbe\u0111ivanje performansi pretrage nastojali smo da odr\u017eimo broj objekata u klasteru na minimum kako bismo obradili \u0161to manje doga\u0111aja na najuskom mestu, koje smo imali na masteru.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Na kraju o monitoringu<\/h2>\n<p><\/p>\n<p>Da bi vse to delovalo, kot je bilo namenjeno, spremljamo naslednje:<\/p>\n<p><\/p>\n<ul>\n<li>Vsaka podatkovna vozli\u0161\u010da poro\u010da na\u0161em oblaku, da obstaja, in da so tam dolo\u010deni shardi. Ko nekje kaj ugasnemo, skupina po 2-3 sekundah poro\u010da, da smo v centru A ugasnili vozli\u0161\u010da 2, 3 in 4 \u2014 to pomeni, da v drugih podatkovnih centrih ne smemo ugasiti tistih vozli\u0161\u010d, na katerih so shardi v edinstvenem izvodu.<\/li>\n<li>Vedoci zna\u010daja delovanja glavne enote, zelo pozorno spremljamo \u0161tevilo \u010dakajo\u010dih nalog. Zelo en sam visoko obte\u017eeni nalog, \u010de se pravo\u010dasno ne izklopi, teoreti\u010dno lahko v izredni situaciji postane vzrok, da ne bomo mogli izvesti, recimo, promocije replica-sharda v primarni, zaradi \u010desar pride do zaustavitve indeksacije.<\/li>\n<li>Poleg tega zelo natan\u010dno spremljamo zamude garbage collectorja, ker smo se s tem \u017ee spopadli z resnimi te\u017eavami pri optimizaciji.<\/li>\n<li>Zavrnitve po niti, da bi vnaprej razumeli, kje se nahaja \"ozko grlo\".<\/li>\n<li>In tudi standardne metrike, kot so heap, RAM in I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Pri postavljanju monitoringa je nujno upo\u0161tevati posebnosti Thread Pool v Elasticsearchu. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Dokumentacija Elasticsearcha<\/a><\/noindex> opisuje mo\u017enosti nastavitve in privzete vrednosti za iskanje, indeksiranje, vendar popolnoma mol\u010di o thread_pool.management. Ti niti obravnavajo, med drugim, poizvedbe tipa _cat\/shards in druge podobne, ki jih je priro\u010dno uporabiti pri pisanju monitoringa. Tem ve\u010dji je klaster, tem ve\u010d tak\u0161nih poizvedb se izvede na enoto \u010dasa, medtem ko tisti thread_pool.management ni le, da ni predstavljen v uradni dokumentaciji, temve\u010d je tudi privzeto omejen na 5 niti, kar se zelo hitro izkoristi, po \u010demer monitoring preneha delovati pravilno.<\/p>\n<p><\/p>\n<p>Kar bi \u017eeleli povedati na koncu: uspelo nam je! Uspeli smo na\u0161im programerjem in razvijalcem zagotoviti orodje, ki je skoraj v vsaki situaciji sposobno hitro in zanesljivo zagotoviti informacije o dogajanju v produkciji.<\/p>\n<p><\/p>\n<p>Da, to se je izkazalo za precej zapleteno, vendar so se na\u0161e \u017eelje uspe\u0161no vklapljale v \u017ee obstoje\u010de izdelke, ki jih ni bilo treba popraviti in predelati.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch grozd na 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Izvor: <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.4 - 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\/sl\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\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\/sl\/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\udd47Elasticsearch klaster 200 TB+ | ProHoster","description":"Z Elasticsearchom se sre\u010duje mnogi.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}