{"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\/et\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Elasticsearch klaster 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Elasticsearch on paljude jaoks tuttav. Kuid mis juhtub, kui soovid selle abil salvestada logisid \u00absuures mahus\u00bb? Ja veel, kuidas taluda k\u00f5igi mitme andmekeskuse t\u00f5rkeid? Milline arhitektuur peaks olema, ja milliste peidetud probleemide ees seisad?<\/p>\n<p><\/p>\n<p>Me Odnoklassnikis otsustasime, et kasutame elasticsearchi, et lahendada logihalduse jautet, ja n\u00fc\u00fcd jagame oma kogemusi Habros: nii arhitektuuri kui ka peidetud probleemide kohta.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Mina nimi on Peeter Zaitsev, t\u00f6\u00f6tan s\u00fcsteemiadministraatorina Odnoklassnikutes. Enne seda olin samuti administraator, t\u00f6\u00f6tades Manticore Searchi, Sphinx Searchi ja Elasticsearchiga. Kui tekib veel m\u00f5ni \u2026 otsing, siis t\u00f5en\u00e4oliselt hakkan ka sellega tegelema. Osalen samuti mitmetes avatud l\u00e4htekoodiga projektides vabatahtlikuna.<\/p>\n<p><\/p>\n<p>Kui ma tulin Odnoklassnikisse, \u00fctlesin usinalt intervjuul, et oskan t\u00f6\u00f6tada Elasticsearchiga. P\u00e4rast sellega harjumist ja m\u00f5ne lihtsa \u00fclesande tegemist anti mulle suur \u00fclesanne reformeerida tollane logihalduss\u00fcsteem. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">N\u00f5uded<\/h2>\n<p><\/p>\n<p>S\u00fcsteemi n\u00f5uded formuleeriti j\u00e4rgmiselt:<\/p>\n<p><\/p>\n<ul>\n<li>Frontendina pidi olema kasutusel Graylog. Sest ettev\u00f5ttes oli juba selle toote kasutamise kogemus, arendajad ja testijad teadsid seda, see oli neile tuttav ja mugav.<\/li>\n<li>Andmemaht: keskmiselt 50-80 tuhat s\u00f5numit sekundis, kuid kui midagi l\u00e4heb katki, siis liiklus ei ole millegagi piiratud, see v\u00f5ib olla 2-3 miljonit rida sekundis.<\/li>\n<li>Kliendiga n\u00f5udlusi arutades j\u00f5udsime arusaamisele, et t\u00fc\u00fcpiline mustern\u00e4ide sellise s\u00fcsteemi kasutamisest on j\u00e4rgmine: inimesed otsivad enda rakenduse logisid viima kahe p\u00e4eva jooksul ja ei soovi, et ootavad rohkem kui \u00fche sekundi. <\/li>\n<li>Administraatorid r\u00f5hutasid, et s\u00fcsteem peab olema vajadusel h\u00f5lpsasti skaleeritav, n\u00f5udmata s\u00fcgavat arusaamist selle toimimisest. <\/li>\n<li>Ainus hooldus\u00fclesanne, mis nendele s\u00fcsteemidele perioodiliselt vajalik oli, oli vahetada m\u00f5nd riistvara.<\/li>\n<li>Lisaks on Odnoklassnikis suurep\u00e4rane tehniline traditsioon: iga teenus, mille me k\u00e4ivitame, peab taluma andmekeskuse t\u00f5rke (\u00e4kki, planeerimata ja igal ajal).<\/li>\n<\/ul>\n<p><\/p>\n<p>Selle projekti viimase n\u00f5ude t\u00e4itmine n\u00f5udis meilt k\u00f5ige suuremat vaeva, millest r\u00e4\u00e4gin l\u00e4hemalt.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Keskkond<\/h2>\n<p><\/p>\n<p>Me t\u00f6\u00f6tame neljas andmekeskuses, samas v\u00f5ivad Elasticsearchi andmenood asuda ainult kolmes (mitmete mitte-tehniliste p\u00f5hjuste t\u00f5ttu).<\/p>\n<p><\/p>\n<p>Nendes neljas andmekeskuses asub umbes 18 tuhat erinevat logiallikat \u2014 riistvara, konteinerid, virtuaalmasinad.<\/p>\n<p><\/p>\n<p>Oluline omadus: klastrite k\u00e4ivitamine toimub konteinerites <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> mitte f\u00fc\u00fcsilistel masinatel, vaid <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">oma pilve tootel one-cloud<\/a><\/noindex>. Korrustele garanteeritakse 2 tuuma, mis on v\u00f5rdsed 2,0 GHz v4-ga, v\u00f5imalusega kasutada \u00fclej\u00e4\u00e4nud tuumasid, kui need on vabad. <\/p>\n<p><\/p>\n<p>Teisis\u00f5nu:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/073bffbfc3cff761bfabe0773b7f4ebc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"topologiya\">Topoloogia<\/h2>\n<p><\/p>\n<p>Lahendi \u00fcldine v\u00e4limus n\u00e4gi mulle algselt v\u00e4lja j\u00e4rgmine:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP-d seisavad domeeni Graylog A-kirje taga, sellele aadressile saadetakse logid.<\/li>\n<li>iga VIP esindab LVS-i koormuse tasakaalustajat.<\/li>\n<li>P\u00e4rast seda j\u00f5uavad logid Graylogi akusse, osa andmetest tuleb GELF formaadis, osa syslog formaadis.<\/li>\n<li>Edasi kirjutatakse k\u00f5ik need suurtel partidel Elasticsearchi koordinaatorite akusse. <\/li>\n<li>Need, omakorda, saadavad kirjutamise ja lugemise p\u00e4ringud asjakohastele andmeoordadele. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/21efcdf6992a07e0c5e9b477c567cca9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"terminologiya\">Terminoloogia<\/h2>\n<p><\/p>\n<p>V\u00f5ib-olla ei tunne k\u00f5ik terminoloogiat kuigi h\u00e4sti, seet\u00f5ttu tahaksin sellega pisut peatuda.<\/p>\n<p><\/p>\n<p>Elasticsearchis on mitmeid t\u00fc\u00fcpe noode \u2014 master, koordinaator, andmenood. On veel kaks muud t\u00fc\u00fcpi erinevate logide muutmiseks ja erinevate klastrite omavaheliseks sidumiseks, kuid me kasutasime ainult loetletud. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPingib k\u00f5ik klastris olevad nood, toetab kehtivat klastrikaarti ja levitab seda noode vahel, k\u00e4sitleb s\u00fcndmuse loogikat, tegeleb igasuguse klastrisisese hooldusega. <\/p>\n<p><\/p>\n<p><strong>Koordinaator<\/strong><br \/>\nT\u00e4idab \u00fchte ainukest \u00fclesannet: aktsepteerib kliendip\u00e4ringuid lugemise v\u00f5i kirjutamise jaoks ja suunab selle liikluse. Kui p\u00e4ring on kirjutamise kohta, siis k\u00fcsib see t\u00f5en\u00e4oliselt masterilt, millisesse sobivasse indeksi shard'i seda paigutada, ja suunab p\u00e4ringu edasi. <\/p>\n<p><\/p>\n<p><strong>Andmenood<\/strong><br \/>\nHoidab andmeid, t\u00e4idab v\u00e4ljastpoolt saabuvaid otsingup\u00e4ringuid ja teoseid asuvatelt shardidelt.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nSee, this is somewhat like a blend of Kibana with Logstash in the ELK stack. Graylog combines both UI and log processing pipeline. Under the hood, Kafka and Zookeeper work within Graylog, providing connectivity for Graylog as a cluster. Graylog can cache logs (Kafka) in case Elasticsearch becomes unavailable and retry failed read and write requests, grouping and tagging logs according to specified rules. Similar to Logstash, Graylog has functionality for modifying strings before writing them to Elasticsearch.<\/p>\n<p><\/p>\n<p>Additionally, Graylog features built-in service discovery, allowing you to obtain the entire cluster map based on one available Elasticsearch node and filter it by a specific tag, enabling requests to be directed to specific containers.<\/p>\n<p><\/p>\n<p>Visually, it looks something like this:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>This is a screenshot from a specific instance. Here we build a histogram based on a search query, displaying relevant entries.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indeksid<\/h2>\n<p><\/p>\n<p>Returning to the system architecture, I would like to take a closer look at how we constructed the index model to ensure everything operates correctly. <\/p>\n<p><\/p>\n<p>In the previously provided diagram, this is the lowest level: Elasticsearch data nodes.<\/p>\n<p><\/p>\n<p>An index is a large virtual entity consisting of Elasticsearch shards. Each of these shards is, in fact, a Lucene index. And each Lucene index, in turn, consists of one or more segments. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>During the design phase, we estimated that to meet the requirement for read speed on a large volume of data, we needed to evenly 'spread' this data across the data nodes. <\/p>\n<p><\/p>\n<p>This led to the fact that the number of shards per index (with replicas) should be strictly equal to the number of data nodes. Firstly, to ensure a replication factor of two (meaning we can lose half of the cluster). Secondly, to handle read and write requests on at least half of the cluster.<\/p>\n<p><\/p>\n<p>We initially defined the retention time as 30 days.<\/p>\n<p><\/p>\n<p>The distribution of shards can be graphically represented as follows:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>The entire dark gray rectangle is the index. The left red square in it is the primary shard, the first one in the index. And the blue square is the replica shard. They are located in different data centers.<\/p>\n<p><\/p>\n<p>Kui me lisame veel \u00fche shard'i, l\u00e4heb see kolmandasse andmekeskusesse. L\u00f5puks saame sellise struktuuri, mis tagab andmete j\u00e4rjepidevuse, isegi kui \u00fcks andmekeskus kaob.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Indeksite roteerimine, st uue indeksi loomine ja k\u00f5ige vanema kustutamine, on seatud 48 tunni peale (indeksi kasutusmuster: viimase 48 tunni jooksul otsitakse k\u00f5ige sagedamini).<\/p>\n<p><\/p>\n<p>Sellise indeksi roteerimise intervalliga seonduvad j\u00e4rgmised p\u00f5hjused:<\/p>\n<p><\/p>\n<p>Kui konkreetne andmenood saadab otsingup\u00e4ringu, on j\u00f5udluse seisukohalt kasulikum k\u00fcsida \u00fchte shard'i, kui selle suurus on v\u00f5rdsustatav s\u00f5lme m\u00e4lu suurusega. See v\u00f5imaldab hoida indeksi \"kuuma\" osa m\u00e4lu ja kiiresti sellele p\u00e4\u00e4seda. Kui \"kuumi osi\" on liiga palju, halveneb indeksi otsingu kiirus.<\/p>\n<p><\/p>\n<p>Kui s\u00f5lm hakkab m\u00f5nel shard'il otsingup\u00e4ringut t\u00e4itma, eraldab ta niipalju l\u00f5ime, kui palju on f\u00fc\u00fcsilise masina h\u00fcper-t\u00f6\u00f6tleva tuuma. Kui otsingup\u00e4ring puudutab palju shard'e, suureneb l\u00f5imede arv proportsionaalselt. See m\u00f5jutab negatiivselt otsingukiirus ja halvendab uute andmete indekseerimist. <\/p>\n<p><\/p>\n<p>Kuna olime vajalikku otsingul\u00e4bivust tagama, otsustasime kasutada SSD-sid. Et kiiresti t\u00f6\u00f6delda p\u00e4ringute arvutite, millel need konteinerid paiknesid, pidi olema v\u00e4hemalt 56 tuuma. Numbriks 56 valiti tinglikult piisav suurus, mis m\u00e4\u00e4rab treads'i arvu, mida Elasticsearch t\u00f6\u00f6protsessi k\u00e4igus genereerib. Elasticsearchis s\u00f5ltuvad paljude thread pooli parameetrite otsekohe saadaval olevate tuumade arvust, mis omakorda m\u00f5jutab otseselt vajalike s\u00f5lmede arvu klastris p\u00f5him\u00f5ttega 'v\u00e4hem tuumi \u2014 rohkem s\u00f5lmi'. <\/p>\n<p><\/p>\n<p>Kokkuv\u00f5ttes selgus, et keskmine shard kaalub umbes 20 gigabaiti, ja 1 indeksi kohta on 360 shard'i. Seega, kui me neid roteerime iga 48 tunni j\u00e4rel, on meil neid 15 t\u00fckki. Iga indeks sisaldab andmeid 2 p\u00e4eva jooksul.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Andmete kirjutamise ja lugemise skeemid<\/h2>\n<p><\/p>\n<p>Vaatame, kuidas selles s\u00fcsteemis andmeid kirjutatakse.<\/p>\n<p><\/p>\n<p>Oletame, et meil on Graylogist koordinaatorisse saabumas m\u00f5ni p\u00e4ring. N\u00e4iteks soovime indekseerida 2-3 tuhat rida. <\/p>\n<p><\/p>\n<p>Koordinaator, saades Graylogilt p\u00e4ringu, k\u00fcsib mest\u00e9rit: \"Indekseerimise p\u00e4ringus oli meil konkreetselt m\u00e4\u00e4ratud indeks, kuid kuhu shard'i see kirjutada - ei olnud m\u00e4rgitud.\" <\/p>\n<p><\/p>\n<p>Meister vastab: \"Salvesta see teave shard'i numero 71\", mille j\u00e4rel see suunatakse otse asjakohasesse andme-Node'i, kus asub primary-shard numero 71.<\/p>\n<p><\/p>\n<p>Seej\u00e4rel kopeeritakse tehingu logi replica-shard'ile, mis asub juba teises andmepunktis.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Graylogist tuleb koordinaatorisse otsingup\u00e4ring. Koordinaator suunab selle indeksi kaudu, samas kui Elasticsearch jagab p\u00e4ringud round-robin p\u00f5him\u00f5ttel primary-shard'i ja replica-shard'i vahel. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>180 Node'i vastavad eba\u00fchtlaselt ja seni, kuni nad vastavad, kogub koordinaator teavet, mille juba \"v\u00e4lja s\u00fclitasid\" kiiremad andme-Node'id. P\u00e4rast seda, kui kogu teave on saabunud v\u00f5i p\u00e4ringu puhul on saavutatud timeout, edastab ta k\u00f5ik otse kliendile. <\/p>\n<p><\/p>\n<p>Kogu see s\u00fcsteem t\u00f6\u00f6tleb keskmiselt viimase 48 tunni otsingup\u00e4ringud 300-400 ms jooksul, v\u00e4lja arvatud need p\u00e4ringud, kus on leading wildcard.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\"Lilled\" Elasticsearchiga: Java seadistamine<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuna k\u00f5ik see t\u00f6\u00f6le hakkaks nagu me algselt soovisime, seadistasime me v\u00e4ga kaua erinevaid asju klastris. <\/p>\n<p><\/p>\n<p>Esimene osa avastatud probleemidest oli seotud sellega, kuidas Elasticsearchis on vaikimisi eelnevalt seadistatud Java. <\/p>\n<p><\/p>\n<p><strong>Esimene probleem<\/strong><br \/>\nOleme n\u00e4inud v\u00e4ga suurt hulka registreeringuid, et meil on Lucene'i tasemel, kui taustat\u00f6\u00f6d on k\u00e4ivitatud, Lucene'i segmentide m\u00e4rgendamised l\u00f5petatakse t\u00f5rgetega. Samuti oli logides n\u00e4ha, et tegemist on OutOfMemoryError-iga. Telemeetria p\u00f5hjal n\u00e4gime, et hunnik on vaba ja ei olnud selge, miks see operatsioon eba\u00f5nnestub. <\/p>\n<p><\/p>\n<p>Selgus, et Lucene indeksi merge toimub v\u00e4ljaspool heap'i. Ja konteinerid on \u00fcsna rangeid piiranguid tarbitavatele ressurssidele. Nendesse ressurssidesse mahtus ainult heap (heap.size v\u00e4\u00e4rtus oli ligikaudu sama kui RAM), samas kui teatud off-heap'i operatsioonid kukkusid m\u00e4lu jaotamise t\u00f5rkega, kui nad mingil p\u00f5hjusel ei mahtunud nendesse ~500 MB, mis j\u00e4id piirangust.<\/p>\n<p><\/p>\n<p>Parandus oli \u00fcsna triviaalne: konteinerile saadaval olev RAM-i maht suurenes, p\u00e4rast mida unustasime, et sellised probleemid olid meil kunagi olnud.<\/p>\n<p><\/p>\n<p><strong>Teine probleem<\/strong><br \/>\nUmbes 4-5 p\u00e4eva p\u00e4rast klastrite k\u00e4ivitamist m\u00e4rkasime, et andme-Node'id hakkavad perioodiliselt klastrist v\u00e4lja kukkuma ja tulema tagasi umbes 10-20 sekundi p\u00e4rast. <\/p>\n<p><\/p>\n<p>Kui me s\u00fcvenesime, selgus, et see off-heap m\u00e4lu Elasticsearchis ei ole praktiliselt \u00fcldse kontrollitav. Kui andsime konteinerile rohkem m\u00e4lu, saime v\u00f5imaluse t\u00e4ita otsepuutepankade erinevat teavet ja see puhastati alles p\u00e4rast seda, kui Elasticsearch k\u00e4ivitas selges\u00f5nalise GC. <\/p>\n<p><\/p>\n<p>M\u00f5nel juhul kestis see toiming \u00fcsna kaua ja selle aja jooksul m\u00e4rkis klaster selle s\u00f5lme juba v\u00e4lja langenuks. Probleem on h\u00e4sti kirjeldatud. <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">siin<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Lahendus oli j\u00e4rgmine: piirasime Java v\u00f5imalust kasutada peamise osa m\u00e4lu v\u00e4ljastpoolt heap'i nende operatsioonide jaoks. Piirasime seda kuni 16 gigabaidini (-XX:MaxDirectMemorySize=16g), saavutades nii, et selges\u00f5naline GC kutsuti v\u00e4lja m\u00e4rgatavalt sagedamini ning t\u00f6\u00f6tas m\u00e4rgatavalt kiiremini, l\u00f5petades klastrit destabiliseerimise.<\/p>\n<p><\/p>\n<p><strong>Kolmas probleem<\/strong><br \/>\nKui arvate, et probleemid \"s\u00f5lmedega, mis lahkuvad klastrist k\u00f5ige etten\u00e4matumal hetkel\" on sellega lahenenud, siis eksite. <\/p>\n<p><\/p>\n<p>Kui me konfigureerisime indekseerimist, valisime mmapfs, et <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">l\u00fchendada otsinguaega<\/a><\/noindex> v\u00e4rskete shardide k\u00f5rge segmentatsiooniga. See oli \u00fcsna t\u00f5sine viga, sest mmapfs-i kasutamisel kaardistatakse fail vahem\u00e4lu, ja seej\u00e4rel t\u00f6\u00f6tame juba kaardistatud failiga. Seet\u00f5ttu osutame, et \u00fcritades GC-l peatada rakenduses niidid, kulus meil safepunkti j\u00f5udmiseks v\u00e4ga kaua aega, ja selles protsessis lakkas rakendus vastamast meistri p\u00e4ringutele, et kas see on veel elus. Vastavalt sellele arvab meister, et s\u00f5lm ei ole enam meie klastris kohal. Seej\u00e4rel, umbes 5-10 sekundi p\u00e4rast t\u00f6\u00f6tab garbage collector, s\u00f5lm taastub, siseneb taas klastrisse ja alustab shardide algatamist. K\u00f5ik see meenutas tugevalt \"toodet, mille me v\u00e4\u00e4risime\" ja ei sobinud millekski t\u00f5sisemaks.<\/p>\n<p><\/p>\n<p>Sellest k\u00e4itumisest vabanemiseks l\u00e4ksime esmalt \u00fcle standardsele niofs-ile ja hiljem, kui Elastic viiendatest versioonidest kuuesse migreerisime, proovisime hybridfs-i, kus see probleem ei kordunud. T\u00fc\u00fcpide ladustamise kohta saab rohkem lugeda. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">siin<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Neljas probleem<\/strong><br \/>\nSiis oli veel \u00fcks v\u00e4ga huvitav probleem, mida me ravisime rekordiliselt kaua. Kartsime seda 2-3 kuud, kuna selle mustrit oli t\u00e4iesti v\u00f5imatu m\u00f5ista. <\/p>\n<p><\/p>\n<p>M\u00f5nikord l\u00e4ksid meie koordinaatorid Full GC-sse, tavaliselt p\u00e4rast l\u00f5unat, ja sealt nad enam ei naasnud. Samuti n\u00e4gi GC viivituste logimisel v\u00e4lja nii: meil l\u00e4heb k\u00f5ik h\u00e4sti, h\u00e4sti, h\u00e4sti, ja siis plaan \u2014 ja k\u00f5ik muutub j\u00e4rsult halvemaks. <\/p>\n<p><\/p>\n<p>Alguses arvasime, et meil on kuri kasutaja, kes k\u00e4ivitab mingi p\u00e4ringu, mis t\u00f5ukab koordinaatori t\u00f6\u00f6moodulist v\u00e4lja. Logisime p\u00e4ringuid v\u00e4ga kaua, p\u00fc\u00fcdes aru saada, mis toimub. <\/p>\n<p><\/p>\n<p>Kokkuv\u00f5ttes selgus, et hetkel, kui m\u00f5ni kasutaja k\u00e4ivitab v\u00e4ga suure p\u00e4ringu ja see satub m\u00f5nele konkreetsele Elasticsearchi koordinaatorile, vastavad m\u00f5ned s\u00f5lmed kauem kui teised. <\/p>\n<p><\/p>\n<p>Ja see aeg, mille koordinaator ootab k\u00f5igi s\u00f5lmede vastuseid, kogub ta tulemused, mis on saadud juba vastanud s\u00f5lmedelt. GC jaoks t\u00e4hendab see, et meie m\u00e4lu kasutuse muster muutub v\u00e4ga kiiresti. Ja seda GC-d, mida me kasutasime, ei suutnud selle \u00fclesandega toime tulla. <\/p>\n<p><\/p>\n<p>Ainus parandamine, mille me leidsime, et muuta klastri k\u00e4itumist sellises olukorras, oli migratsioon JDK13-le ja Shenandoah pr\u00fcgikogumise kasutamine. See lahendas probleemi, koordinaatorid ei kukkunud enam. <\/p>\n<p><\/p>\n<p>Sellega l\u00f5ppesid Java probleemid, kuid algasid l\u00e4bilaskev\u00f5ime probleemid. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">Elasticsearchi \"marjad\": l\u00e4bilaskev\u00f5ime<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>L\u00e4bilaskev\u00f5ime probleemid t\u00e4hendavad, et meie klaster t\u00f6\u00f6tab stabiilselt, kuid indeksite arvu tipphetkedel ja man\u00f6\u00f6verdusmomentidel ei ole j\u00f5udlus piisav.<\/p>\n<p><\/p>\n<p>Esimene kohatud s\u00fcmptom: tootmises toimuvate <\/p>\n<p><\/p>\n<p>snapshots <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Graylogis hakkab sageli ilmuma esitusville viga es_rejected_execution.<\/a><\/noindex> See juhtus sellep\u00e4rast, et thread_pool.write.queue \u00fchel andmes\u00f5lmel, enne kui Elasticsearch suudab indekseerimise p\u00e4ringu t\u00f6\u00f6delda ja informatsiooni diskile kirjutada, suudab vaikimisi vahem\u00e4llu salvestada ainult 200 p\u00e4ringut. Ja<\/p>\n<p><\/p>\n<p>Elasticsearchi dokumentatsioonis sellest parameetrist r\u00e4\u00e4gitakse v\u00e4ga v\u00e4he. K\u00e4sitletakse ainult ekstreemne arv teid ja vaikimisi suurust. Loomulikult otsustasime seda v\u00e4\u00e4rtust muuta ja selgus, et meie seadistuses suudab vahem\u00e4llu salvestada p\u00e4ris h\u00e4sti kuni 300 p\u00e4ringut, samas kui suurem v\u00e4\u00e4rtus toob meid tagasi Full GC-sse.<\/p>\n<p><\/p>\n<p>Lisaks, kuna need on s\u00f5numipaketid, mis saabuvad \u00fche p\u00e4ringu raames, pidime Graylogi seadistama nii, et see kirjutaks mitte sageli ja v\u00e4ikeste partiitena, vaid suurte partiitena v\u00f5i iga kolme sekundi j\u00e4rel, kui partii ei ole ikka veel t\u00e4is. Sellisel juhul muutub teave, mille me Elasticsearch'i kirjutame, k\u00e4ttesaadavaks mitte kahe, vaid viie sekundi p\u00e4rast (mis meid t\u00e4iesti rahuldab), ent v\u00e4heneb ka retrai arv, mida tuleb teha, et edastada suur partii teavet.<\/p>\n<p><\/p>\n<p>See on eriti oluline hetkedel, kui meil midagi kuskil kokku kukub ja sellest agaralt teatatakse, et mitte saada t\u00e4ielikult sp\u00e4mmitud Elasticut, ega saada hiljem \u2014 mitte t\u00f6\u00f6tavaid Graylogi node'e ummistunud puhvriketaste t\u00f5ttu.<\/p>\n<p><\/p>\n<p>Lisaks, kui meil toimusid need plahvatused tootmises, saime kaebusi programmeerijatelt ja testijatelt: just siis, kui nad neid logisid v\u00e4ga vajavad, v\u00e4ljastatakse need neile v\u00e4ga aeglaselt.<\/p>\n<p><\/p>\n<p>Hakkasime uurima. \u00dchel poolt oli selge, et nii otsingup\u00e4ringud kui ka indekseerimisperioodid t\u00f6\u00f6tavad p\u00f5him\u00f5tteliselt sama f\u00fc\u00fcsilise riistvara peal, ja mingil moel on teatavad langused v\u00e4ltimatud. <\/p>\n<p><\/p>\n<p>Ent seda oli osaliselt v\u00f5imalik v\u00e4ltida, kuna Elasticsearch'i kuuendas versioonis ilmus algoritm, mis v\u00f5imaldab jagada p\u00e4ringud asjakohaste andmennodesse mitte juhuslikult round-robin (konteiner, mis tegeleb indekseerimisega ja hoiab primary-shardi, v\u00f5ib olla v\u00e4ga h\u00f5ivatud, seal ei ole v\u00f5imalust kiiresti vastata), vaid suunata see p\u00e4ring v\u00e4hem h\u00f5ivatud konteinerisse, millel on replica-shard, mis vastab oluliselt kiiremini. Teisis\u00f5nu, j\u00f5udsime user_adaptive_replica_selection: true juurde.<\/p>\n<p><\/p>\n<p>Lugemise pilt hakkab v\u00e4lja n\u00e4gema nii:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Selle algoritmi kasutuselev\u00f5tt v\u00f5imaldas oluliselt parandada p\u00e4ringuaega hetkedel, kui meil toimus suur logide kirjutamise voog.<\/p>\n<p><\/p>\n<p>L\u00f5puks seisnes peamine probleem andmekeskuse valutus v\u00e4ljal\u00fclitamises.<\/p>\n<p><\/p>\n<p>Mida me soovisime klastrilt kohe p\u00e4rast \u00fchenduse kaotamist \u00fche andmekeskusega: <\/p>\n<p><\/p>\n<ul>\n<li>Kui meie kadunud andmekeskuses asub praegune master, siis ta valitakse uuesti ja liigub rollina teisele node'ile teises andmekeskuses.<\/li>\n<li>Master viskab kiiresti k\u00f5ik k\u00e4ttesaamatud node'id klastrist v\u00e4lja.<\/li>\n<li>P\u00f5hinedes allesj\u00e4\u00e4nud infole, m\u00f5istab ta: kadunud andmekeskuses oli meil sellised primary-shardid, kiiresti promoverib ta komplementaarsed replica-shardid allesj\u00e4\u00e4nud andmekeskustes, ja meie andmete indekseerimine j\u00e4tkub. <\/li>\n<li>Selle tulemusena hakkab meie klastrite kirjutamis- ja lugemisv\u00f5imekus sujuvalt aeglustuma, kuid \u00fcldiselt t\u00f6\u00f6tab k\u00f5ik aeglaselt, kuid stabiilselt.<\/li>\n<\/ul>\n<p><\/p>\n<p>Kuidas selgus, soovisime midagi sellist:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja saime j\u00e4rgmist:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuidas see juhtus? <\/p>\n<p><\/p>\n<p>Andmekeskuse hukkumise hetkel oli kitsaskohaks meie master.<\/p>\n<p><\/p>\n<p>Miks?<\/p>\n<p><\/p>\n<p>Asi on selles, et masteril on TaskBatcher, mis vastutab teatud \u00fclesannete ja s\u00fcndmuste levitamise eest klastris. Iga nodi v\u00e4ljal\u00fclitamine, iga shard'i edasiviimine replica'st primary'sse, iga \u00fclesanne, mis puudutab shard'i loomist, j\u00f5uab esmalt TaskBatcherisse, kus see t\u00f6\u00f6deldakse j\u00e4rjestikku ja \u00fches voos.<\/p>\n<p><\/p>\n<p>Andmekeskuse v\u00e4ljaviimisel tundus, et k\u00f5ik elluj\u00e4\u00e4nud andmenodid pidasid oma kohuseks teatada masterile, 'meil on kadunud sellised shardid ja sellised andmenodid'. <\/p>\n<p><\/p>\n<p>Samal ajal saatsid elluj\u00e4\u00e4nud andmenodid kogu selle info senisele masterile ja \u00fcritasid oodata kinnitust, et ta oli selle vastu v\u00f5tnud. Nad ei saanud seda oodata, kuna master sai \u00fclesandeid kiiremini kui j\u00f5udis vastata. Noodid kordasid p\u00e4ringuid aja\u00fclevahe t\u00f5ttu ja samal ajal ei p\u00fc\u00fcdnud master neile isegi vastata, olles t\u00e4ielikult h\u00f5ivatud p\u00e4ringute prioriteetide j\u00e4rjestamise \u00fclesandega.<\/p>\n<p><\/p>\n<p>L\u00f5ppkokkuv\u00f5ttes tundus, et andmenod spammisid masterit piisavalt, et ta l\u00e4ks t\u00e4ielikku GC-d. P\u00e4rast seda kolis master j\u00e4rgmisele nodile, kellel juhtus t\u00e4pselt sama, ja l\u00f5puks lagunes klaster t\u00e4ielikult. <\/p>\n<p><\/p>\n<p>Me tegime m\u00f5\u00f5tmisi ja enne versiooni 6.4.0, kus see oli parandatud, piisab meile, kui viia korraga v\u00e4lja vaid 10 andmenodi 360-st, et klaster t\u00e4ielikult maapinda l\u00fckata.<\/p>\n<p><\/p>\n<p>See n\u00e4gi v\u00e4lja umbes nii:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>P\u00e4rast versiooni 6.4.0, kus see ebameeldiv viga parandati, peatusid andmenod masteri tapmisest. Kuid \"nutikam\" ta sellest ei saanud. Nimelt: kui me viime v\u00e4lja 2, 3 v\u00f5i 10 (mis tahes arv, mis erineb \u00fchest) andmenodist, saab master mingi esialgse s\u00f5numi, mis \u00fctleb, et nodi A on v\u00e4lja l\u00fclitatud, ja p\u00fc\u00fcab r\u00e4\u00e4kida nodist B, nodist C, nodist D. <\/p>\n<p><\/p>\n<p>Ja praegust on sellega v\u00f5imalik toime tulla vaid seadmisega, kus kellaaegade vahe on 20-30 sekundit, et hallata andmekeskuse klastrist v\u00e4lja viimise kiirus.<\/p>\n<p><\/p>\n<p>P\u00f5him\u00f5tteliselt vastab see algselt toodud n\u00f5uetele l\u00f5pptoote kohta projekti raames, kuid puhta teaduse seisukohalt on see viga. Mis, muide, on edukalt parandatud arendajate poolt versioonis 7.2.<\/p>\n<p><\/p>\n<p>Ja kui mingi andmenode v\u00e4ljus, selgus, et teavet tema v\u00e4ljumise kohta edastada on olulisem kui \u00f6elda kogu klastrile, et tal olid sellised primary-shard (et reklaamida replica-shard teises andmekeskuses primaarseks, et sinna saaks kirjutada teavet).<\/p>\n<p><\/p>\n<p>Seet\u00f5ttu, kui k\u00f5ik on juba \u00abrahunenud\u00bb, ei m\u00e4rgita v\u00e4ljunud andmenodeid kohe stale'iks. Seega peame ootama, kuni k\u00f5ik pinged v\u00e4ljunud nodede peale aegan\u00f5udmiseks m\u00f6\u00f6duvad, ja alles seej\u00e4rel hakkab meie klaster r\u00e4\u00e4kima, et seal, seal ja seal tuleb andmete kirjutamisega j\u00e4tkata. Pikemalt saab sellest lugeda <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">siin<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Seega, andmekeskuse v\u00e4ljaviimise operatsioon kestab meil t\u00e4na umbes 5 minutit tipptunnil. Sellise suure ja kohmakana on see \u00fcsna hea tulemus.<\/p>\n<p><\/p>\n<p>Seega j\u00f5udsime j\u00e4rgmise lahenduseni:<\/p>\n<p><\/p>\n<ul>\n<li>Meil on 360 andmenode, kus on 700 gigabaidi kettad.<\/li>\n<li>60 koordinaatorit liikluse suunamiseks nende andmenode vahel.<\/li>\n<li>40 meistrit, mis on meile j\u00e4\u00e4nud kui mingi p\u00e4rand versioonidest enne 6.4.0 \u2014 et \u00fcle elada andmekeskuse v\u00e4ljaviimist, olime moraalselt valmis kaotama m\u00f5ned masinad, et tagada isegi halva stsenaariumi korral meistrite kvoorum.<\/li>\n<li>Mistahes katsetused rollide \u00fchendamiseks \u00fches konteineris l\u00f5ppesid sellega, et varem v\u00f5i hiljem lakkas node koormuse all t\u00f6\u00f6tamast. <\/li>\n<li>Kogu klastris kasutatakse heap.size v\u00e4\u00e4rtuses 31 gigabaiti: k\u00f5ik katsed v\u00e4hendada suurust viisid selleni, et raskete otsingup\u00e4ringute puhul, kus on leading wildcard, tapeti m\u00f5ned nodede, v\u00f5i katkestati circuit breaker ise Elasticsearchis.<\/li>\n<li>Lisaks, et tagada otsingu j\u00f5udlus, p\u00fc\u00fcdsime hoida klastris objektide arvu minimaalne, et t\u00f6\u00f6delda v\u00f5imalikult v\u00e4he s\u00fcndmusi kitsas kohas, mis meil meistris tekkis.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">L\u00f5petuseks vaatame j\u00e4lgimist.<\/h2>\n<p><\/p>\n<p>Kuna k\u00f5ik see t\u00f6\u00f6tas nagu planeeritud, j\u00e4lgime j\u00e4rgmist:<\/p>\n<p><\/p>\n<ul>\n<li>Iga andmekeskuse node teatab meie pilve, et see on olemas ja et seal on sellised shardid. Kui me kustutame midagi kuskil, raporteerib klaster 2-3 sekundi p\u00e4rast, et keskuses A kustutasime node 2, 3 ja 4 \u2014 see t\u00e4hendab, et teistes andmekeskustes ei tohi mingil juhul kustutada neid node, millel on shardid ainukeses eksemplaris.<\/li>\n<li>Tundnud meistrite k\u00e4itumise iseloomu, vaatame v\u00e4ga hoolikalt pending-\u00fclesannete arvu. Sest isegi \u00fcks peatunud \u00fclesanne, kui see \u00f5igeaegselt mitte ajutuks j\u00e4\u00e4da, v\u00f5ib teoreetiliselt mingis \u00e4\u00e4rmuslikus olukorras olla see p\u00f5hjus, miks meie, n\u00e4iteks, ei soorita replica-shardi t\u00f5statamist primaarseks, millega seonduvalt seisab indekseerimine.<\/li>\n<li>Samuti vaatame v\u00e4ga t\u00e4pselt garbage collector'i viivitusi, sest meil on olnud sellega juba suuri raskusi optimeerimisel.<\/li>\n<li>Threadide refuse, et eelnevalt m\u00f5ista, kus asub \u201epudelikael\u201d.<\/li>\n<li>Ja ka standardm\u00f5\u00f5dikud, nagu heap, RAM ja I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>J\u00e4lgimise seadmisel tuleb tingimata arvesse v\u00f5tta Thread Pooli erip\u00e4ra Elasticsearch'is. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Elasticsearchi dokumentatsioon<\/a><\/noindex> kirjeldab seadistamise ja vaikev\u00e4\u00e4rtuste v\u00f5imalusi otsinguks, indekseerimiseks, kuid j\u00e4tab t\u00e4ielikult t\u00e4helepanuta thread_pool.management. Need threadid t\u00f6\u00f6tlevad, sealhulgas, p\u00e4ringud nagu _cat\/shards ja teised sarnased, mida on mugav kasutada j\u00e4lgimise kirjutamisel. Mida suurem on klaster, seda rohkem selliseid p\u00e4ringuid t\u00e4idetakse aja\u00fchikus, ning eelnevalt mainitud thread_pool.management ei ole mitte ainult esitatud ametlikus dokumentatsioonis, vaid on ka vaikev\u00e4\u00e4rtusena piiratud 5 threadiga, mis kaob v\u00e4ga kiiresti, p\u00e4rast mida j\u00e4lgimine l\u00f5petab korrektselt t\u00f6\u00f6tamise.<\/p>\n<p><\/p>\n<p>L\u00f5petuseks tahaksin \u00f6elda: meil on see \u00f5nnestunud! Oleme suutnud anda meie programmeerijatele ja arendajatele t\u00f6\u00f6riista, mis peaaegu igas olukorras suudab kiiresti ja usaldusv\u00e4\u00e4rselt pakkuda teavet selle kohta, mis toimub tootmises.<\/p>\n<p><\/p>\n<p>Jah, see osutus \u00fcsna keeruliseks, kuid ometi suutsime meie soovid paigutada juba olemasolevatesse toodetesse, mida ei olnud vaja oma vajadustele kohandada ega \u00fcmber kirjutada.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch klaster 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Allikas: <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.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\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\/et\/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'i klaster 200 TB+ | ProHoster","description":"Elasticsearch'iga puutuvad kokku paljud.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}