{"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":"Elasticsearchi klaster \u00fcle 200 TB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Paljusid kogemusi on seotud Elasticsearchiga. Aga mis juhtub, kui soovid selle abil salvestada \u201esuuri\u201d logisid? Ja veel, kuidas ellu j\u00e4\u00e4da, kui \u00fcks mitmest andmekeskusest langeb v\u00e4lja? Milline arhitektuur peaks olema ja milliseid takistusi v\u00f5ivad ette tulla?<\/p>\n<p><\/p>\n<p>Klassikaaslased otsustasime kasutada Elasticsearchi logihalduse k\u00fcsimuste lahendamiseks ning n\u00fc\u00fcd jagame kogemusi Habraga: arhitektuuri ja takistuste kohta.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>\u042f \u2014 \u041f\u0451\u0442\u0440 \u0417\u0430\u0439\u0446\u0435\u0432, \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445. \u0414\u043e \u044d\u0442\u043e\u0433\u043e \u0442\u043e\u0436\u0435 \u0431\u044b\u043b \u0430\u0434\u043c\u0438\u043d\u043e\u043c, \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0441 Manticore Search, Sphinx search, Elasticsearch. \u0412\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0435\u0441\u043b\u0438 \u043f\u043e\u044f\u0432\u0438\u0442\u0441\u044f \u0435\u0449\u0451 \u043a\u0430\u043a\u043e\u0439-\u043d\u0438\u0431\u0443\u0434\u044c &#8230;search, \u0432\u0435\u0440\u043e\u044f\u0442\u043d\u043e \u0431\u0443\u0434\u0443 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0438 \u0441 \u043d\u0438\u043c. \u0422\u0430\u043a\u0436\u0435 \u0443\u0447\u0430\u0441\u0442\u0432\u0443\u044e \u0432 \u0440\u044f\u0434\u0435 \u043e\u043f\u0435\u043d\u0441\u043e\u0440\u0441\u043d\u044b\u0445 \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u043d\u0430 \u0434\u043e\u0431\u0440\u043e\u0432\u043e\u043b\u044c\u043d\u043e\u0439 \u043e\u0441\u043d\u043e\u0432\u0435.<\/p>\n<p><\/p>\n<p>Kui ma Klassikaaslaste juurde tulin, \u00fctlesin arvelt intervjuul, et oskan t\u00f6\u00f6tada Elasticsearchiga. P\u00e4rast harjumist ja m\u00f5ned lihtsad \u00fclesanded lahendades sain suure \u00fclesande logihaldus\u00fcsteemi reformimiseks, mis oli sel ajal olemas. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">N\u00f5uded<\/h2>\n<p><\/p>\n<p>S\u00fcsteemi n\u00f5uded olid s\u00f5nastatud j\u00e4rgmiselt:<\/p>\n<p><\/p>\n<ul>\n<li>Frontendina pidin kasutama Graylogi. Kuna ettev\u00f5ttes oli juba kogemus selle toote kasutamisega, siis programmilised ja testijad tundsid seda, see oli neile tuttav ja mugav.<\/li>\n<li>Andme maht: keskmiselt 50-80 tuhat s\u00f5numit sekundis, kuid kui midagi katki l\u00e4heb, siis liiklust ei piirata, see v\u00f5ib olla 2-3 miljonit rida sekundis.<\/li>\n<li>Kliendiga arutades t\u00f6\u00f6tluse kiirusn\u00f5udeid, m\u00f5istsime, et sellise s\u00fcsteemi t\u00fc\u00fcpiline kasutusmuster on j\u00e4rgmine: inimesed otsivad oma rakenduse logisid viimase kahe p\u00e4eva jooksul ja ei sooviks oodata vastust rohkem kui sekund. <\/li>\n<li>Adminnid n\u00f5udsid, et s\u00fcsteem oleks vajadusel kergesti skaaleeritav, ilma et nad peaksid s\u00fcgavale t\u00e4ielikult sisse minema, kuidas see toimib. <\/li>\n<li>Ainus hooldus\u00fclesanne, mis nendele s\u00fcsteemidele perioodiliselt vaja oli, oli mingi riistvara vahetamine.<\/li>\n<li>Lisaks on Odnoklassnikites ilus tehniline traditsioon: iga teenus, mille me k\u00e4ivitame, peab taluma andmekeskuse riket (\u00e4kilist, planeerimata ja absoluutselt igal ajal).<\/li>\n<\/ul>\n<p><\/p>\n<p>Selle projekti viimase n\u00f5udmise t\u00e4itmine n\u00f5udis meilt k\u00f5ige rohkem vaeva, millest r\u00e4\u00e4gin l\u00e4hemalt hiljem.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Keskkond<\/h2>\n<p><\/p>\n<p>Me t\u00f6\u00f6tame neljas andmekeskuses, kusjuures Elasticsearch'i andmeklastrid v\u00f5ivad asuda vaid kolmes (mitme mitte-tehnilise p\u00f5hjuse t\u00f5ttu).<\/p>\n<p><\/p>\n<p>Nendes neljas andmekeskuses asub ligikaudu 18 000 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 pilveproduktis one-cloud<\/a><\/noindex>. Konteineritele garanteeritakse 2 tuuma, mis on sarnased 2.0Ghz v4-le ning \u00fclej\u00e4\u00e4nud tuumade kasutamine, juhul kui need on seisakusse j\u00e4\u00e4nud. <\/p>\n<p><\/p>\n<p>Teisis\u00f5nu:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 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>Lahenduse \u00fcldine visioon paistis mulle alguses j\u00e4rgmine:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP-d seisavad Graylogi domeeni A-kirje taga, sellele aadressile saadetakse logid.<\/li>\n<li>iga VIP on LVS tasakaalustaja.<\/li>\n<li>P\u00e4rast seda j\u00f5uavad logid Graylogi s\u00fcsteemi, osa andmetest l\u00e4heb GELF-formaadis, osa syslog-formaadis.<\/li>\n<li>Edasi kirjutatakse see k\u00f5ik suurte partiidena Elasticsearch'i koordinaatorite s\u00fcsteemi. <\/li>\n<li>Need omakorda saadavad kirjutamis- ja lugemisemandid asjakohastele andmenoodidele. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 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>M\u00f5ned v\u00f5ivad terminoloogias mitte k\u00f5igega p\u00f5hjalikult tuttavad olla, seet\u00f5ttu tasub sellel peatumiseks natuke aega v\u00f5tta.<\/p>\n<p><\/p>\n<p>Elasticsearchis on mitu t\u00fc\u00fcpi s\u00f5lme \u2014 master, koordinaator, andmes\u00f5lm. On veel kaks muud t\u00fc\u00fcpi, mis on m\u00f5eldud erinevate logide t\u00f6\u00f6tlemiseks ja erinevate klastrite omavaheliseks suhtlemiseks, kuid me oleme kasutanud vaid nimetatud t\u00fc\u00fcpe. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nKontrollib k\u00f5iki klastris olevaid s\u00f5lmesid, toetab ajakohast klastrikaarti ja levitab seda s\u00f5lmede vahel, t\u00f6\u00f6tleb s\u00fcndmuste loogikat ning tegeleb erineva t\u00fc\u00fcpi klastrisiseste toimingutega. <\/p>\n<p><\/p>\n<p><strong>Koordinaator<\/strong><br \/>\nTeeb \u00fchte ainsat \u00fclesannet: v\u00f5tab vastu kliendilt p\u00e4ringud lugemiseks v\u00f5i kirjutamiseks ja suunab selle liikluse. Kui tegu on kirjutamisp\u00e4ringuga, k\u00fcsib ta suure t\u00f5en\u00e4osusega masterilt, millisesse shardi vastavat indeksi seda panna, ja suunab p\u00e4ringu edasi. <\/p>\n<p><\/p>\n<p><strong>Andmes\u00f5lm<\/strong><br \/>\nHoidab andmeid, t\u00e4idab v\u00e4ljast tulevaid otsingup\u00e4ringuid ja tehingute toiminguid, mis on seotud sellel asuvate shardidega.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nSee on midagi sarnast Kibana ja Logstashi sulandumisega ELK-virnas. Graylog \u00fchendab endas nii kasutajaliidese kui ka logide t\u00f6\u00f6tlemise torujuhtme. Graylogi taga t\u00f6\u00f6tavad Kafka ja Zookeeper, mis tagavad Graylogi sidususe klastrina. Graylog suudab vahem\u00e4llu salvestada logisid (Kafka) juhtudel, kui Elasticsearch ei ole kergesti ligip\u00e4\u00e4setav, ja kordab eba\u00f5nnestunud lugemis- ja kirjutamis\u00fclesandeid, r\u00fchmitades ja sildistades logisid vastavalt m\u00e4\u00e4ratud reeglitele. Nagu Logstash, omab Graylog ka funktsionaalsust stringide muutmiseks enne Elasticsearch'i salvestamist.<\/p>\n<p><\/p>\n<p>Lisaks on Graylogis sisseehitatud teenuse avastamine, mis v\u00f5imaldab \u00fche kergesti ligip\u00e4\u00e4setava Elasticsearch'i s\u00f5lme p\u00f5hjal saada kogu klastri kaardi ja filtreerida seda konkreetse sildi alusel, mis v\u00f5imaldab suunata p\u00e4ringud teatud konteineritele.<\/p>\n<p><\/p>\n<p>Visuaalselt n\u00e4eb see umbes v\u00e4lja nii:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>See on ekraanipilt konkreetsest instantsist. Siin ehitame otsingup\u00e4ringu p\u00f5hjal histogrammi ning kuvame asjakohaseid ridu.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indeksid<\/h2>\n<p><\/p>\n<p>Tagasi s\u00fcsteemi arhitektuuri juurde, tahaksin detailselt peatuda sellel, kuidas me index mudelit ehitasime, et k\u00f5ik see \u00f5igesti toimiks. <\/p>\n<p><\/p>\n<p>K\u00fcljendatud skeemil on see alumine tase: Elasticsearchi andmes\u00f5lmed.<\/p>\n<p><\/p>\n<p>Indeks on suur virtuaalne entiteet, mis koosneb Elasticsearch'i shard'idest. Iga shard iseenesest on vaid Lucene indeks. Iga Lucene indeks koosneb omakorda \u00fchest v\u00f5i enamast segmendist. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Disaini k\u00e4igus arvestasime, et suurte andmemahtude lugemiskiirusn\u00f5uete t\u00e4itmiseks on vajalik andmad \u00fchtlaselt \"jaotada\" andmed andmepunktide vahel. <\/p>\n<p><\/p>\n<p>See t\u00f5i meid j\u00e4reldusele, et indeksi shard'ide arv (koos replikatega) peab olema rangelt v\u00f5rdne andmepunktide arvuga. Esiteks, et tagada replikeerimise faktor, mis on kaks (st v\u00f5ime kaotada poole klastrist). Teiseks, et lugemis- ja kirjutamispeab t\u00f6\u00f6tlema v\u00e4hemalt poole klastrist.<\/p>\n<p><\/p>\n<p>K\u00e4ivitusaja m\u00e4\u00e4rasime esmalt 30 p\u00e4eva.<\/p>\n<p><\/p>\n<p>Shard'ide jaotus v\u00f5ib olla visuaalselt esitatud j\u00e4rgmiselt:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kogu tumehall ristk\u00fclik on indeks. Vasak punane ruut selles on p\u00f5hishard, indeksis esimene. Ja sinine ruut on kopeeritud shard. Need asuvad erinevates andmekeskustes.<\/p>\n<p><\/p>\n<p>Kui me lisame veel \u00fche shard'i, j\u00f5uab see kolmandasse andmekeskusesse. Ja l\u00f5puks saame me sellise struktuuri, mis v\u00f5imaldab andmekeskuse kadumist ilma, et andmete j\u00e4rjepidevus kannataks:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Indeksite rotatsiooni, st uue indeksi loomise ja k\u00f5ige vanema indeksi kustutamise, oleme seadnud 48 tunniks (indeksi kasutuse patterni kohaselt: viimase 48 tunni jooksul otsitakse enim).<\/p>\n<p><\/p>\n<p>Selline indeksi rotatsiooni intervall on seotud j\u00e4rgmiste p\u00f5hjustega:<\/p>\n<p><\/p>\n<p>Kui konkreetne andmevahe nodi saab otsingup\u00e4ringu, on j\u00f5udluse seisukohalt kasulikum, kui k\u00fcsitakse ainult \u00fchte shard'i, kui selle suurus on v\u00f5rreldav nodi m\u00e4lupanga suurusega. See v\u00f5imaldab hoida indeksi \"kuuma\" osa m\u00e4lupangas ja kiiresti sellele juurde p\u00e4\u00e4seda. Kui \"kuumi osi\" on palju, siis indeksi otsingukiirus halveneb.<\/p>\n<p><\/p>\n<p>Kui s\u00f5lm hakkab t\u00e4itma otsingup\u00e4ringut \u00fches shardis, eraldab ta f\u00fc\u00fcsilise masina h\u00fcperthreading tuumadele vastava arvu l\u00f5ime. Kui otsingup\u00e4ring h\u00f5lmab suurt hulka shard'e, kasvab l\u00f5imede arv proportsionaalselt. See m\u00f5jutab negatiivselt otsingu kiirus ja avaldab halba m\u00f5ju uute andmete indekseerimisele. <\/p>\n<p><\/p>\n<p>\u0427\u0442\u043e\u0431\u044b \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u044b\u0439 latency \u043f\u043e\u0438\u0441\u043a\u0430, \u043c\u044b \u0440\u0435\u0448\u0438\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c SSD. \u0414\u043b\u044f \u0431\u044b\u0441\u0442\u0440\u043e\u0439 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u043c\u0430\u0448\u0438\u043d\u044b, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0440\u0430\u0437\u043c\u0435\u0449\u0430\u043b\u0438\u0441\u044c \u044d\u0442\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b, \u0434\u043e\u043b\u0436\u043d\u044b \u0431\u044b\u043b\u0438 \u043e\u0431\u043b\u0430\u0434\u0430\u0442\u044c \u043f\u043e \u043c\u0435\u043d\u044c\u0448\u0435\u0439 \u043c\u0435\u0440\u0435 56 \u044f\u0434\u0440\u0430\u043c\u0438. \u0426\u0438\u0444\u0440\u0430 \u0432 56 \u0432\u044b\u0431\u0440\u0430\u043d\u0430 \u043a\u0430\u043a \u0443\u0441\u043b\u043e\u0432\u043d\u043e-\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u0430\u044f \u0432\u0435\u043b\u0438\u0447\u0438\u043d\u0430, \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u044e\u0449\u0430\u044f \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0442\u0440\u0435\u0434\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u0440\u043e\u0436\u0434\u0430\u0442\u044c Elasticsearch \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0440\u0430\u0431\u043e\u0442\u044b. \u0412 Elasitcsearch \u043c\u043d\u043e\u0433\u0438\u0435 \u043f\u0430\u0440\u0430\u043c\u0435\u0442\u0440\u044b thread pool \u043d\u0430\u043f\u0440\u044f\u043c\u0443\u044e \u0437\u0430\u0432\u0438\u0441\u044f\u0442 \u043e\u0442 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u044f\u0434\u0435\u0440, \u0447\u0442\u043e \u0432 \u0441\u0432\u043e\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u043f\u0440\u044f\u043c\u043e \u0432\u043b\u0438\u044f\u0435\u0442 \u043d\u0430 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0435 \u043a\u043e\u043b-\u0432\u043e \u043d\u043e\u0434 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443 &quot;\u043c\u0435\u043d\u044c\u0448\u0435 \u044f\u0434\u0435\u0440 \u2014 \u0431\u043e\u043b\u044c\u0448\u0435 \u043d\u043e\u0434&quot;. <\/p>\n<p><\/p>\n<p>Kokkuv\u00f5ttes selgus, et keskmiselt kaalub shard umbes 20 gigabaidi ning \u00fche indeksi kohta on 360 shard'i. Seet\u00f5ttu, kui me neid roteerime iga 48 tunni j\u00e4rel, on neid kokku 15. Iga indeks mahutab andmeid kahe p\u00e4eva jooksul.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Andmete salvestamise ja lugemise skeemid<\/h2>\n<p><\/p>\n<p>Vaatame, kuidas selles s\u00fcsteemis andmeid salvestatakse.<\/p>\n<p><\/p>\n<p>Oletame, et Graylogist tuleb koordinaatorisse mingi p\u00e4ring. N\u00e4iteks soovime indekseerida 2-3 tuhat rida. <\/p>\n<p><\/p>\n<p>Koordinaator, saades Graylogist p\u00e4ringu, k\u00fcsib meistrilt: \u201eIndekseerimise p\u00e4ringus on konkreetne indeks, kuid millisesse shard'i see kirjutada \u2014 seda pole t\u00e4psustatud\u201c. <\/p>\n<p><\/p>\n<p>Meister vastab: \u201eSalvesta see teave shard'i numbriga 71\u201c, p\u00e4rast mida saadetakse see otse asjakohasesse andme-s\u00f5lme, kus asub primary-shard numbriga 71.<\/p>\n<p><\/p>\n<p>P\u00e4rast seda replikatakse tehingute logi replica-shard'i, mis asub juba teises andmekeskuses.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 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 p\u00f5hjal, samas Elasticsearch jaotab p\u00e4ringud round-robin meetodil primary-shard'i ja replica-shard'i vahel. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>180 s\u00f5lme vastavad ebav\u00f5rdselt ja seni, kuni nad vastavad, kogub koordinaator teavet, mille juba kiiremad andme-s\u00f5lmed temasse \u201ev\u00e4lja s\u00fclitasid\u201c. P\u00e4rast seda, kui kas kogu teave on saabunud v\u00f5i p\u00e4ringu jaoks on saavutatud ajavahemik, edastab ta k\u00f5ik otse kliendile. <\/p>\n<p><\/p>\n<p>Selle s\u00fcsteemi keskmine vastamisaeg otsingup\u00e4ringutele viimase 48 tunni jooksul on 300\u2013400 ms, v\u00e4lja arvatud p\u00e4ringud, mis sisaldavad leading wildcard'it.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">Elasticsearchi \"Lilledega\": Java seadistamine<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuna soovime, et k\u00f5ik see t\u00f6\u00f6taks nii nagu algselt plaanisime, veetsime me v\u00e4ga palju aega erinevate asjade klastris h\u00e4\u00e4lestamisele. <\/p>\n<p><\/p>\n<p>Esimene leitud probleem oli seotud sellega, kuidas Elasticsearch on vaikimisi Java jaoks eelseadistatud. <\/p>\n<p><\/p>\n<p><strong>Probleem number \u00fcks<\/strong><br \/>\n\u041c\u044b \u043d\u0430\u0431\u043b\u044e\u0434\u0430\u043b\u0438 \u043e\u0447\u0435\u043d\u044c \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u0443 \u043d\u0430\u0441 \u043d\u0430 \u0443\u0440\u043e\u0432\u043d\u0435 Lucene, \u043a\u043e\u0433\u0434\u0430 \u0437\u0430\u043f\u0443\u0449\u0435\u043d\u044b background job&#8217;\u044b, \u043c\u0435\u0440\u0434\u0436\u0438 \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u043e\u0432 Lucene \u0437\u0430\u0432\u0435\u0440\u0448\u0430\u044e\u0442\u0441\u044f \u0441 \u043e\u0448\u0438\u0431\u043a\u043e\u0439. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u0432 \u043b\u043e\u0433\u0430\u0445 \u0431\u044b\u043b\u043e \u0432\u0438\u0434\u043d\u043e, \u0447\u0442\u043e \u044d\u0442\u043e OutOfMemoryError-\u043e\u0448\u0438\u0431\u043a\u0430. \u041f\u043e \u0442\u0435\u043b\u0435\u043c\u0435\u0442\u0440\u0438\u0438 \u043c\u044b \u0432\u0438\u0434\u0435\u043b\u0438, \u0447\u0442\u043e \u0445\u0438\u043f \u0441\u0432\u043e\u0431\u043e\u0434\u0435\u043d, \u0438 \u043d\u0435 \u0431\u044b\u043b\u043e \u043f\u043e\u043d\u044f\u0442\u043d\u043e, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u0430 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u044f \u043f\u0430\u0434\u0430\u0435\u0442. <\/p>\n<p><\/p>\n<p>Selgus, et Lucene indeksite \u00fchendamised toimuvad v\u00e4ljaspool heap'i. Ja konteinerid on \u00fcsna rangelt piiratud kasutatavate ressurssidega. Nendesse ressurssidesse mahtus ainult heap (heap.size v\u00e4\u00e4rtus oli ligikaudu v\u00f5rdne RAM-iga) ja m\u00f5ned off-heap operatsioonid kukkusid v\u00e4lja m\u00e4lu jagamise veaga, kui mingil p\u00f5hjusel ei mahtunud nad neid umbes 500 MB, mis olid limiidile l\u00e4hedal.<\/p>\n<p><\/p>\n<p>Probleem oli \u00fcsna lihtne: konteinerile antud RAM-i mahtu suurendati, p\u00e4rast mida unustasime, et sellised probleemid \u00fcldse eksisteerisid.<\/p>\n<p><\/p>\n<p><strong>Teine probleem<\/strong><br \/>\nUmbes 4\u20135 p\u00e4eva p\u00e4rast klastrite k\u00e4ivitamist m\u00e4rkisime, et andmenoodid hakkavad perioodiliselt klastrist v\u00e4lja langema ja tagasi tulema 10\u201320 sekundi p\u00e4rast. <\/p>\n<p><\/p>\n<p>Kui hakkasime uurima, selgus, et see off-heap m\u00e4lu Elasticsearchis ei ole praktiliselt \u00fcldse kontrollitud. Kui andsime konteinerile rohkem m\u00e4lu, saime v\u00f5imaluse t\u00e4ita otsepuud (direct buffer pools) erinevate andmetega, ning need puhastusid ainult p\u00e4rast seda, kui Elasticsearch k\u00e4ivitas explicit GC. <\/p>\n<p><\/p>\n<p>M\u00f5nel juhul toimus see operatsioon \u00fcsna pika aja jooksul, ja selle aja jooksul suutis klaster m\u00e4rgistada selle noodiga juba v\u00e4lja langenud. See 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\">siit<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Lahendus oli j\u00e4rgmine: piirasime Java v\u00f5imet kasutada peamise osa m\u00e4lu v\u00e4ljaspool heapsit nende operatsioonide jaoks. Piirasime selle 16 gigabaidini (-XX:MaxDirectMemorySize=16g), saavutades, et explicit GC kutsuti oluliselt sagedamini ja toimus oluliselt kiiremini, l\u00f5petades seel\u00e4bi klastrit destabiliseerimise.<\/p>\n<p><\/p>\n<p><strong>Kolmas probleem<\/strong><br \/>\nKui arvasite, et probleemid \"s\u00f5lmedega, mis lahkuvad klastrist k\u00f5ige ettearvamatumatel hetkedel\" on n\u00fc\u00fcdseks l\u00e4bi, eksite. <\/p>\n<p><\/p>\n<p>Indeksite t\u00f6\u00f6 seadistamisel valisime mmapfs, et <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">l\u00fchendada otsingu aega<\/a><\/noindex> v\u00e4rskete shardide puhul suure segmentatsiooniga. See oli \u00fcsna suurem viga, sest mmapfs-i kasutamisel kaardistatakse fail peam\u00e4llu ning seej\u00e4rel t\u00f6\u00f6tame juba mapped-failiga. Seet\u00f5ttu tekib olukord, kus \u00fcritades viimaseid niite peatada, l\u00e4heme me safepointi poole v\u00e4ga kaua, ja teel sinna lakkab rakendus reageerimast meistrilt k\u00fcsimistele, kas see on ikka veel aktiivne. Seet\u00f5ttu arvab master, et s\u00f5lm ei ole enam klastris. P\u00e4rast seda, umbes 5\u201310 sekundi p\u00e4rast, t\u00f6\u00f6tab pr\u00fcgikoristus, s\u00f5lm taastub, siseneb taas klastrisse ja alustab shardide initsialiseerimist. K\u00f5ik see meenutas tugevalt \u201ctoodet, mida me v\u00e4\u00e4rime\u201d ja ei sobinud t\u00f5sisemaks kasutamiseks.<\/p>\n<p><\/p>\n<p>Selle k\u00e4itumise l\u00f5petamiseks v\u00f5tsime k\u00f5igepealt kasutusele standardse niofs'i ning seej\u00e4rel, kui oleme Elastic'i viiendast versioonist kuuesse migrate'nud, proovime hybridfs'i, kus see probleem ei esinenud. T\u00fc\u00fcpide kohta saab rohkem lugeda storage'st. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">siit<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Neljas probleem<\/strong><br \/>\nSiis oli veel \u00fcks v\u00e4ga huvitav probleem, mida lahendasime rekordiliselt kaua. Me p\u00fc\u00fcdsime seda 2-3 kuud, kuna selle muster oli t\u00e4iesti arusaamatu. <\/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. Samas, kui logisime GC viivitusi, n\u00e4gi see v\u00e4lja selline: k\u00f5ik sujus h\u00e4sti, h\u00e4sti, h\u00e4sti, ja siis j\u00e4rsku \u2014 k\u00f5ik l\u00e4ks \u00e4kki halvaks. <\/p>\n<p><\/p>\n<p>Alguses arvasime, et meil on kuri kasutaja, kes k\u00e4ivitab mingisuguse p\u00e4ringu, mis l\u00f6\u00f6b koordinaatori t\u00f6\u00f6keskkonnast v\u00e4lja. Logisime p\u00e4ringuid v\u00e4ga kaua, p\u00fc\u00fcdes aru saada, mis toimub. <\/p>\n<p><\/p>\n<p>L\u00f5puks selgus, et hetkel, kui m\u00f5ni kasutaja k\u00e4ivitab v\u00e4ga suurep\u00e4ringu ja see j\u00f5uab konkreetsele Elasticsearchi koordinaatorile, vastavad m\u00f5ned noodid kauem kui teised. <\/p>\n<p><\/p>\n<p>Kuni sel hetkel, mil koordinaator ootab k\u00f5igi nodide vastust, kogub ta endasse tulemusi, mis on saadetud juba vastanud nodidelt. GC jaoks t\u00e4hendab see, et meie h\u00fcpoteekide kasutusmuster muutub v\u00e4ga kiiresti. Ja see GC, mida me kasutasime, ei suutnud selle \u00fclesandega toime tulla. <\/p>\n<p><\/p>\n<p>Ainus lahendus, mille me leidsime, et muuta klastrite k\u00e4itumist sellises olukorras, on migreerimine JDK13-le ja pr\u00fcgikoguja Shenandoah kasutamine. See lahendas probleemi, koordinaatorid ei kukkunud enam alla. <\/p>\n<p><\/p>\n<p>Sellega l\u00f5ppesid Java probleemid ja algasid ribalaiuse probleemid. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u201eMarjad\u201d Elasticsearchiga: ribalaius<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ribalaiuse probleemid t\u00e4hendavad, et meie klaster t\u00f6\u00f6tab stabiilselt, kuid dokumentide indekseerimise tipppunktide ajal ja man\u00f6\u00f6verdushetkedel on j\u00f5udlus ebapiisav.<\/p>\n<p><\/p>\n<p>Esimene m\u00e4rgatav s\u00fcmptom: m\u00f5ningate \u201eplahvatuste\u201d korral tootmises, kui genereeritakse \u00e4kki v\u00e4ga suur hulk logisid, hakkab Graylogis sageli ilmuma indekseermise viga es_rejected_execution. <\/p>\n<p><\/p>\n<p>See toimus seet\u00f5ttu, et thread_pool.write.queue \u00fches andmega nodis suudab enne Elasticsearchi indekseerimistaotluse t\u00f6\u00f6tlemist ja teabe jagusse kirjutamist vaikimisi vahem\u00e4lus hoida vaid 200 taotlust. Ja <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Elasticsearchi dokumentatsioonis<\/a><\/noindex> k\u00e4sitletakse seda parameetrit v\u00e4ga v\u00e4he. Mainitakse vaid l\u00f5pp-arvu teemasid ja vaikimisi suurust.<\/p>\n<p><\/p>\n<p>Muidugi hakkasime seda v\u00e4\u00e4rtust kohandama ning selgus j\u00e4rgmist: meie seadistuses vahem\u00e4lustatakse \u00fcsna h\u00e4sti kuni 300 taotlust, samas kui suurem v\u00e4\u00e4rtus toob meid tagasi Full GC-i.<\/p>\n<p><\/p>\n<p>Lisaks, kuna need on \u00fches taotluses saabuvad s\u00f5numipakid, pidi Graylogi seadistama nii, et see kirjutaks mitte liiga sageli ja v\u00e4ikeste pakettidega, vaid suurte pakettidega v\u00f5i iga kolme sekundi j\u00e4rel, kui pakett pole veel t\u00e4ielik. Sellisel juhul tundub, et teave, mida me Elasticsearchi kirjutame, on k\u00e4ttesaadav mitte kahe sekundi jooksul, vaid viie sekundi jooksul (mis sobib meile t\u00e4iesti), kuid v\u00e4heneb retrai arv, mis tuleb suure teabe paketi edastamiseks teha.<\/p>\n<p><\/p>\n<p>See on eriti oluline siis, kui meil on midagi kukkunud ja see teatatakse meeleheitlikult, et v\u00e4ltida t\u00e4ielikku sp\u00e4mmimist Elasticis, ja m\u00f5ne aja p\u00e4rast \u2014 mittetoimivad Graylogi noodid ummistunud puhvrite t\u00f5ttu.<\/p>\n<p><\/p>\n<p>Lisaks, kui meil olid need plahvatused tootmises, saime kaebusi programmeerijatelt ja testijatelt: hetkel, kui nad neid logisid t\u00f5eliselt vajavad, tullakse neid v\u00e4lja v\u00e4ga aeglaselt.<\/p>\n<p><\/p>\n<p>Hakkasime uurima. \u00dchest k\u00fcljest oli selge, et nii otsingup\u00e4ringud kui ka indekseerimisp\u00e4ringud t\u00f6\u00f6tavad p\u00f5him\u00f5tteliselt \u00fchel ja samal f\u00fc\u00fcsilisel masinal, seega mingil m\u00e4\u00e4ral on teatud langused v\u00e4ltimatud. <\/p>\n<p><\/p>\n<p>Kuid seda sai osaliselt v\u00e4ltida, kasutades \u0161esti versioonides Elasticsearchi ilmunud algoritmi, mis v\u00f5imaldab suunata p\u00e4ringud asjakohastele andmepunktide vahel mitte juhuslikult round-robin p\u00f5him\u00f5ttel (konteiner, mis tegeleb indekseerimisega ja hoiab primary-shard'i, v\u00f5ib olla v\u00e4ga h\u00f5ivatud, seal ei ole kiire vastuse v\u00f5imalust), vaid suunata see p\u00e4ring v\u00e4hem koormatud konteinerisse, millel on replica-shard, mis vastab oluliselt kiiremini. Teisis\u00f5nu, j\u00f5udsime use_adaptive_replica_selection: true juurde.<\/p>\n<p><\/p>\n<p>Lugemise pilt hakkab v\u00e4lja n\u00e4gema selline:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Selle algoritmile \u00fcleminek aitas oluliselt parandada p\u00e4ringu aega olukordades, kus meil oli suur logide kirjutamise voog.<\/p>\n<p><\/p>\n<p>L\u00f5ppkokkuv\u00f5ttes seisnes peamine probleem sujuvas andmekeskuse v\u00e4ljav\u00f5tmises.<\/p>\n<p><\/p>\n<p>Mida me ootasime klastrilt kohe p\u00e4rast \u00fchenduse kaotamist \u00fche DC-ga: <\/p>\n<p><\/p>\n<ul>\n<li>Kui meil on kadunud andmekeskuses praegune master, siis valitakse see \u00fcmber ja liigub rollina teisele s\u00f5lmele teises DC-s.<\/li>\n<li>Master eemaldab kiiresti klastrist k\u00f5ik k\u00e4ttesaamatud s\u00f5lmed.<\/li>\n<li>J\u00e4\u00e4nud p\u00f5hjal m\u00f5istab ta: kadunud andmekeskuses olid meil sellised peamised shardid, kiiresti promootib ta t\u00e4iendavad replica-shardid j\u00e4\u00e4nud andmekeskustes ja meil j\u00e4tkub andmete indekseerimine. <\/li>\n<li>Selle tulemusena hakkab meie klastrite kirjutamis- ja lugemisv\u00f5ime j\u00e4rk-j\u00e4rgult langema, 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=\"Elasticsearchi klaster \u00fcle 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aga saime j\u00e4rgmist:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 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 kokkuvarisemise hetkel oli meie kitsaskohaks master.<\/p>\n<p><\/p>\n<p>Miks?<\/p>\n<p><\/p>\n<p>Asja on selles, et masteris on TaskBatcher, mis vastutab teatud \u00fclesannete ja s\u00fcndmuste levitamise eest klastris. Iga nodi v\u00e4ljal\u00fclitamine, iga shardi edasiviimine replica-st primary-sse, igasugune shardi loomise \u00fclesanne \u2014 k\u00f5ik see l\u00e4heb esmalt TaskBatcherisse, kus see t\u00f6\u00f6deldakse j\u00e4rjestikku ja \u00fches voos.<\/p>\n<p><\/p>\n<p>\u00dche andmekeskuse v\u00e4ljaviimise hetkel juhtus, et k\u00f5ik eluj\u00f5ulised andmenoodid eluj\u00f5ulistes andmekeskustes pidid teatama masterile, et \"meil on kadunud sellised shardid ja sellised andmenoodid\". <\/p>\n<p><\/p>\n<p>Samal ajal saatsid eluj\u00f5ulised andmenoodid kogu selle teabe praegusele masterile ja proovsid oodata kinnitust, et ta on selle vastu v\u00f5tnud. Nad ei oodanud seda, sest master sai \u00fclesandeid kiiremini, kui ta oskas vastata. Noodid kordasid p\u00e4ringuid ajavahemiku l\u00f5ppedes, samal ajal kui master ei p\u00fc\u00fcdnud enam neile vastata, vaid oli t\u00e4ielikult p\u00fchendunud p\u00e4ringute sorteerimisele prioriteedi j\u00e4rgi.<\/p>\n<p><\/p>\n<p>Terminali vaates n\u00e4gi v\u00e4lja nii, et data-nodes saatis masterile nii palju, et ta l\u00e4ks full GC. P\u00e4rast seda kolis meie master j\u00e4rgmisse nodde, kus toimus sama asi, 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 probleem fikseeriti, piisab, kui eemaldada korraga vaid 10 data-node\u2019it 360-st, et klaster t\u00e4ielikult maas oleks.<\/p>\n<p><\/p>\n<p>See n\u00e4gi v\u00e4lja umbes nii:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 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 kohutav bugi parandati, l\u00f5petasid data-nodes masteri tapmise. Kuid see ei teinud teda \u201enutikamaks\u201c. Nimelt: kui me eemaldame 2, 3 v\u00f5i 10 (mille iganes arv, mis ei ole 1) data-node'it, saab master mingi esialgse s\u00f5numi, mis \u00fctleb, et node A on kadunud, ja p\u00fc\u00fcab sellest r\u00e4\u00e4kimiseks teavitada node B, node C, node D. <\/p>\n<p><\/p>\n<p>Praegu saab sellega v\u00f5idelda ainult seadistades aega, mille jooksul proovitakse kellelegi midagi selgitada, umbes 20-30 sekundit, ja seel\u00e4bi kontrollida data-center\u2019i eemaldamise kiirus klastrist.<\/p>\n<p><\/p>\n<p>P\u00f5him\u00f5tteliselt vastab see algselt projekti l\u00f5ppprodukti jaoks esitatud n\u00f5uetele, kuid puhta teaduse seisukohalt on see t\u00f5rge. Mis, muide, on arendajate poolt versioonis 7.2 edukalt parandatud.<\/p>\n<p><\/p>\n<p>Kuid kui mingi andme-node kukkus, selgus, et teavet selle kukkumise kohta on olulisem levitada kui kogu klastrile r\u00e4\u00e4kida, et sellel olid sellised esmased osad (et reklaamida replica-shard teises andmekeskuses esmaseks, kuhu saaks andmeid kirjutada).<\/p>\n<p><\/p>\n<p>Seet\u00f5ttu, kui k\u00f5ik \"rahutused\" on m\u00f6\u00f6das, ei m\u00e4rgistata v\u00e4ljatootud andme-nodesid kohe vananenuks. Seega peame ootama, kuni k\u00f5ik pinged v\u00e4ljatoodud andme-nodedele aeguvad, ja alles siis hakkab meie klaster r\u00e4\u00e4kima, et seal-seal-seal tuleb andmete salvestamine j\u00e4tkata. T\u00e4psemat teavet saab lugeda siit. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">siit<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Kokkuv\u00f5ttes v\u00f5tab andmeruumi v\u00e4ljutamine meil t\u00e4na tipptunnil aega umbes 5 minutit. Sellise suure ja kohmakas masina jaoks on see \u00fcsna hea tulemus.<\/p>\n<p><\/p>\n<p>Kokkuv\u00f5ttes j\u00f5udsime j\u00e4rgmise lahenduseni:<\/p>\n<p><\/p>\n<ul>\n<li>Meil on 360 andme-node'i, millel on 700 gigabaidi k\u00f5vakettad.<\/li>\n<li>60 koordinaatorit liikluse suunamiseks nende samade andmepunktide kaudu.<\/li>\n<li>40 meistrit, kes on j\u00e4\u00e4nud meile kui mingi p\u00e4rand versioonidest enne 6.4.0 - et ellu j\u00e4\u00e4da andmekeskuse sulgemisest, olime moraalselt valmis kaotama m\u00f5ned masinad, et tagada isegi halvimates stsenaariumides ustavus meistrite seas.<\/li>\n<li>Iga katse rollide \u00fchendamiseks \u00fches konteineris jooksis meie puhul kokku sellega, et varem v\u00f5i hiljem node purunes koormuse all. <\/li>\n<li>Kogu klastris kasutatakse heap.size-d, mis on 31 gigabaiti: k\u00f5ik katsed suurust v\u00e4hendada t\u00f5id kaasa, et raskete otsingup\u00e4ringute puhul, millel oli leading wildcard, kas tapeti m\u00f5ned node'id v\u00f5i tabas circuit breaker ise Elasticsearchis.<\/li>\n<li>Lisaks pingutasime otsingutulemuste tagamiseks hoidma klastris objektide arvu minimaalsena, et t\u00f6\u00f6delda v\u00f5imalikult v\u00e4he s\u00fcndmusi kitsas kohas, mis meil meistris \u00f5nnestus.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Viimaseks j\u00e4lgimisest<\/h2>\n<p><\/p>\n<p>Kuna k\u00f5ik see t\u00f6\u00f6taks nii, nagu oli planeeritud, j\u00e4lgime j\u00e4rgmist:<\/p>\n<p><\/p>\n<ul>\n<li>Iga andme taga s\u00f5lmib meie pilve, et see on olemas ja sellel on sellised shard\u2019id. Kui kustutame kuskil midagi, teatab klaster 2\u20133 sekundi jooksul, et keskuses A oleme kustutanud s\u00f5lmed 2, 3 ja 4 \u2014 see t\u00e4hendab, et teistes andmekeskustes ei saa me mingil juhul kustutada neid s\u00f5lmi, kus on j\u00e4\u00e4nud shard'id ainsuses.<\/li>\n<li>Teades meistri k\u00e4itumist, j\u00e4lgime v\u00e4ga t\u00e4helepanelikult pending-\u00fclesannete arvu. Sest isegi \u00fcks j\u00e4\u00e4k \u00fclesanne, kui seda \u00f5igel ajal ei taandata, v\u00f5ib teoreetiliselt kriitilises olukorras olla p\u00f5hjus, miks meil ei toimi n\u00e4iteks replica-shardi edastus primary'sse, mis peatab indekseerimise.<\/li>\n<li>Samuti j\u00e4lgime v\u00e4ga hoolikalt garbage collectori viivitusi, kuna meil on selle probleemiga juba olnud suuri raskusi optimeerimise k\u00e4igus.<\/li>\n<li>Thread\u2019ite tagasil\u00fckked, et m\u00f5ista ette, kus asub 'pudelikael'.<\/li>\n<li>Ja ka standardsed n\u00e4itajad, nagu heap, RAM ja I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Monitooringu loomisel tuleb kindlasti arvesse v\u00f5tta Elasticsearchi Thread Pooli omadusi. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Elasticsearchi dokumentatsioon<\/a><\/noindex> kirjeldab seadistamise v\u00f5imalusi ja vaikev\u00e4\u00e4rtusi otsimiseks, indekseerimiseks, kuid j\u00e4tab t\u00e4iesti t\u00e4helepanuta thread_pool.management. Need niidid t\u00f6\u00f6tlevad eelk\u00f5ige p\u00e4ringuid t\u00fc\u00fcpi _cat\/shards ja muid sarnaseid, mida on mugav kasutada j\u00e4lgimise kirjutamisel. Mida suurem klaster, seda rohkem selliseid p\u00e4ringuid tehakse aja\u00fchikus ning eelmainitud thread_pool.management on lisaks sellele, et seda ei ole ametlikus dokumentatsioonis esitatud, vaikimisi piiratud 5 niidiga, mis saab kiiresti ammendatud, p\u00e4rast mida j\u00e4lgimine lakkab korrektselt t\u00f6\u00f6tamast.<\/p>\n<p><\/p>\n<p>L\u00f5petuseks tahaks \u00f6elda: meil \u00f5nnestus! Oleme suutnud anda meie programmeerijatele ja arendajatele t\u00f6\u00f6riista, mis on praktiliselt igas olukorras v\u00f5imeline kiiresti ja usaldusv\u00e4\u00e4rselt andma teavet sellest, mis toimub tootmises.<\/p>\n<p><\/p>\n<p>Jah, see osutus \u00fcsna keeruliseks, aga sellegipoolest suutsime meie soovid mahutada juba olemasolevatesse toodetesse, mida ei pidanud enda jaoks parandama ja \u00fcmber kirjutama.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearchi klaster \u00fcle 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 4.9.10 - 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. \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\" \/>\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) 4.9.10\" \/>\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. \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\" \/>\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 klaster 200 TB+ | ProHoster","description":"Paljudel on kokku puutunud Elasticsearchiga. Aga mis juhtub, kui soovid selle abil hoida 'suures mahus' logisid? Ja veel, kuidas suudetakse valutult \u00fcle elada mis tahes mitmest andmekeskusest tekkiv rike? Kuidas peaks arhitektuur olema loodud ja millistele varjatud probleemidele pead t\u00e4helepanu p\u00f6\u00f6rama? Me Odnoklassnikutes otsustasime kasutada Elasticsearchi logihalduse lahendamiseks ja n\u00fc\u00fcd jagame Habras oma kogemusi:","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. \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","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"},"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}]}}