{"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\/da\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Elasticsearch-klynge p\u00e5 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mange st\u00e5r over for Elasticsearch. Men hvad sker der, n\u00e5r man \u00f8nsker at opbevare logs \"i en s\u00e6rligt stor m\u00e6ngde\"? Uden smerte at overvinde fejlen i et af flere datacentre? Hvilken arkitektur b\u00f8r man v\u00e6lge, og hvilke f\u00e6lder skal man v\u00e6re opm\u00e6rksom p\u00e5?<\/p>\n<p><\/p>\n<p>Vi i Odnoklassniki har besluttet at l\u00f8se log-management-udfordringen med Elasticsearch, og nu deler vi vores erfaring med Habra: b\u00e5de om arkitektur og om faldgruber.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Jeg er Peter Zaitsev, jeg arbejder som systemadministrator hos Odnoklassniki. F\u00f8r dette var jeg ogs\u00e5 administrator, jeg har arbejdet med Manticore Search, Sphinx search, Elasticsearch. Hvis der kommer en anden type ...search, vil jeg sandsynligvis ogs\u00e5 arbejde med det. Jeg deltager ogs\u00e5 i en r\u00e6kke open source-projekter p\u00e5 frivillig basis.<\/p>\n<p><\/p>\n<p>Da jeg kom til Odnoklassniki, sagde jeg uovervejet til interviewet, at jeg kunne arbejde med Elasticsearch. Efter jeg havde v\u00e6nnet mig til det og lavet nogle enkle opgaver, fik jeg tildelt en stor opgave omkring reformering af log-management-systemet, som eksisterede p\u00e5 det tidspunkt. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Krav<\/h2>\n<p><\/p>\n<p>Kravene til systemet blev formuleret p\u00e5 f\u00f8lgende m\u00e5de:<\/p>\n<p><\/p>\n<ul>\n<li>Som frontend skulle Graylog anvendes. Fordi virksomheden allerede havde erfaring med dette produkt, var programm\u00f8rer og testere bekendte med det, og det var komfortabelt for dem.<\/li>\n<li>Data volumen: i gennemsnit 50-80 tusinde meddelelser i sekundet, men hvis noget g\u00e5r galt, s\u00e5 er trafik ikke begr\u00e6nset, det kan v\u00e6re 2-3 millioner linjer i sekundet.<\/li>\n<li>Efter at have diskuteret kravene til behandlingstiden for s\u00f8geforesp\u00f8rgsler med kunderne, inds\u00e5 vi, at det typiske brugsm\u00f8nster for et s\u00e5dant system er, at folk s\u00f8ger logs fra deres applikation over de sidste to dage og ikke vil vente mere end et sekund p\u00e5 resultatet af deres foresp\u00f8rgsel. <\/li>\n<li>Administratorerne insisterede p\u00e5, at systemet nemt skulle kunne skaleres, om n\u00f8dvendigt, uden at det kr\u00e6ver dybdeg\u00e5ende indsigt i, hvordan det fungerer. <\/li>\n<li>Den eneste vedligeholdelsesopgave, som disse systemer kr\u00e6vede j\u00e6vnligt, var at skifte noget hardware.<\/li>\n<li>Derudover har Odnoklassniki en fremragende teknisk tradition: enhver service, vi lancerer, skal kunne overleve et datacentrets nedbrud (uforudset, ikke-planlagt og n\u00e5r som helst).<\/li>\n<\/ul>\n<p><\/p>\n<p>Det seneste krav i implementeringen af dette projekt har givet os de st\u00f8rste udfordringer, som jeg vil fort\u00e6lle mere om senere.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Milj\u00f8<\/h2>\n<p><\/p>\n<p>Vi arbejder i fire datacentre, men Elasticsearch-datanoder kan kun v\u00e6re placeret i tre (af en r\u00e6kke ikke-tekniske grunde).<\/p>\n<p><\/p>\n<p>I disse fire datacentre findes der omkring 18.000 forskellige logkilder \u2013 hardware, containere, virtuelle maskiner.<\/p>\n<p><\/p>\n<p>En vigtig funktion: klusteret startes i containere <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> ikke p\u00e5 fysiske maskiner, men p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">vores egen cloud-product one-cloud<\/a><\/noindex>. Containerne garanteres 2 kerner, svarende til 2.0Ghz v4, med mulighed for at udnytte de \u00f8vrige kerner, hvis de st\u00e5r stille. <\/p>\n<p><\/p>\n<p>Med andre ord:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/073bffbfc3cff761bfabe0773b7f4ebc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"topologiya\">Topologi<\/h2>\n<p><\/p>\n<p>Den samlede l\u00f8sning s\u00e5 jeg oprindeligt s\u00e5ledes:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP'er st\u00e5r bag A-recorden for dom\u00e6net Graylog, som er adressen, hvor loggene sendes.<\/li>\n<li>hver VIP fungerer som en LVS-balance.<\/li>\n<li>Derefter lander loggene p\u00e5 en Graylog-batteri, hvor noget data sendes i GELF-format, mens andet sendes i syslog-format.<\/li>\n<li>Derefter skrives alt dette i store batches til en batteri af Elasticsearch-koordinatorer. <\/li>\n<li>Og de sender foresp\u00f8rgsler om skrivning og l\u00e6sning til de relevante datanoder. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/21efcdf6992a07e0c5e9b477c567cca9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"terminologiya\">Terminologi<\/h2>\n<p><\/p>\n<p>M\u00e5ske er ikke alle bekendt med terminologien, s\u00e5 jeg vil gerne tage et \u00f8jeblik til at gennemg\u00e5 den.<\/p>\n<p><\/p>\n<p>Der findes flere typer noder i Elasticsearch \u2013 master-, koordinator- og datanode. Der er ogs\u00e5 to andre typer til forskellige transformationer af logs og til forbindelse mellem forskellige klustre, men vi har kun brugt de n\u00e6vnte. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPinger alle noder i klustret, opretholder et opdateret kort over klustret og distribuerer det mellem noderne, h\u00e5ndterer events logik og udf\u00f8rer en r\u00e6kke forskellige cluster-brede opgaver. <\/p>\n<p><\/p>\n<p><strong>Koordinator<\/strong><br \/>\nUdf\u00f8rer \u00e9n opgave: modtager foresp\u00f8rgsler fra klienter om l\u00e6sning eller skrivning og ruter denne trafik. Hvis det er en skriveforesp\u00f8rgsel, vil den sandsynligvis sp\u00f8rge masteren, hvilken shard fra den relevante indeks den skal placere denne i, og videresende foresp\u00f8rgslen derfra. <\/p>\n<p><\/p>\n<p><strong>Datanode<\/strong><br \/>\nOpbevarer data, udf\u00f8rer s\u00f8geforesp\u00f8rgsler fra eksterne kilder, og operationer p\u00e5 de shards, som den har.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nDette er noget i stil med en sammensmeltning af Kibana med Logstash i ELK-stakken. Graylog kombinerer b\u00e5de UI og logbehandlingspipeline. Under hjelmen i Graylog arbejder Kafka og Zookeeper, som sikrer sammenh\u00e6ngen af Graylog som et cluster. Graylog kan cache logs (Kafka) i tilf\u00e6lde af, at Elasticsearch ikke er tilg\u00e6ngelig, og gentage mislykkedes l\u00e6se- og skriveanmodninger, gruppere og m\u00e6rke logs i henhold til fastsatte regler. Ligesom Logstash har Graylog funktionalitet til at modificere strenge, f\u00f8r de skrives til Elasticsearch.<\/p>\n<p><\/p>\n<p>Derudover har Graylog en indbygget service discovery, der g\u00f8r det muligt, baseret p\u00e5 en tilg\u00e6ngelig node af Elasticsearch, at f\u00e5 hele kortet af clustret og filtrere det efter et bestemt tag, hvilket giver mulighed for at dirigere foresp\u00f8rgsler til bestemte containere.<\/p>\n<p><\/p>\n<p>Visuelt ser det omtrent s\u00e5dan ud:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dette er et screenshot fra en specifik instans. Her bygger vi et histogram baseret p\u00e5 en s\u00f8geforesp\u00f8rgsel og viser relevante strenge.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indekser<\/h2>\n<p><\/p>\n<p>N\u00e5r vi vender tilbage til systemarkitekturen, vil jeg gerne fokusere p\u00e5, hvordan vi byggede indekseringsmodellen, s\u00e5 alt dette fungerer korrekt. <\/p>\n<p><\/p>\n<p>I det tidligere diagram er dette det laveste niveau: Elasticsearch data noder.<\/p>\n<p><\/p>\n<p>Et indeks er en stor virtuel enhed, der best\u00e5r af shards af Elasticsearch. Hver af shards er i sig selv blot en Lucene-indeks. Og hver Lucene-indeks best\u00e5r igen af et eller flere segmenter. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ved designet overvejede vi, at for at opfylde kravene til l\u00e6sehastighed ved store datam\u00e6ngder, var vi n\u00f8dt til j\u00e6vnt at \"fordele\" disse data over datanoderne. <\/p>\n<p><\/p>\n<p>Dette f\u00f8rte til, at antallet af shards p\u00e5 et indeks (med replika) skulle v\u00e6re strengt lig med antallet af datanoder. For det f\u00f8rste for at sikre en replication factor lig med to (dvs. vi kan miste halvdelen af clustret). For det andet for at behandle l\u00e6se- og skriveforesp\u00f8rgsler p\u00e5 mindst halvdelen af clustret.<\/p>\n<p><\/p>\n<p>Opbevaringstiden blev f\u00f8rst fastsat til 30 dage.<\/p>\n<p><\/p>\n<p>Fordelingen af shards kan repr\u00e6senteres grafisk p\u00e5 f\u00f8lgende m\u00e5de:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hele den m\u00f8rkegr\u00e5 rektangel er indekset. Den venstre r\u00f8de firkant i den er primary shard, den f\u00f8rste i indekset. Og den bl\u00e5 firkant er replica shard. De ligger i forskellige datacentre.<\/p>\n<p><\/p>\n<p>N\u00e5r vi tilf\u00f8jer endnu en shard, ender den i det tredje datacenter. Og i sidste ende f\u00e5r vi s\u00e5dan en struktur, der muligg\u00f8r tab af et datacenter uden tab af datakonsistens:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vi har sat roteringen af indekser, dvs. oprettelsen af et nyt indeks og sletningen af det \u00e6ldste, til 48 timer (baseret p\u00e5 m\u00f8nsteret for indeksbrug: de seneste 48 timer s\u00f8ges der oftest).<\/p>\n<p><\/p>\n<p>Denne rotationsinterval for indekserne skyldes f\u00f8lgende grunde:<\/p>\n<p><\/p>\n<p>N\u00e5r en s\u00f8geforesp\u00f8rgsel lander p\u00e5 en bestemt data-node, er det, med hensyn til ydeevne, mere fordelagtigt, at der foresp\u00f8rges p\u00e5 \u00e9n shard, hvis dens st\u00f8rrelse svarer til st\u00f8rrelsen af node-hukommelsen. Dette g\u00f8r det muligt at holde den \"varme\" del af indekset i hukommelsen og hurtigt f\u00e5 adgang til den. N\u00e5r der bliver mange \"varme dele\", forringes hastigheden af s\u00f8gningen i indekset.<\/p>\n<p><\/p>\n<p>N\u00e5r en node begynder at udf\u00f8re en s\u00f8geforesp\u00f8rgsel p\u00e5 en shard, tildeler den et antal tr\u00e5de svarende til antallet af hyper-tr\u00e5de p\u00e5 den fysiske maskine. Hvis s\u00f8geforesp\u00f8rgslen ber\u00f8rer mange shards, stiger antallet af tr\u00e5de proportionalt. Dette p\u00e5virker s\u00f8gehastigheden negativt og p\u00e5virker indeksering af nye data. <\/p>\n<p><\/p>\n<p>For at sikre den n\u00f8dvendige s\u00f8gelatens besluttede vi at bruge SSD. For hurtig behandling af foresp\u00f8rgsler m\u00e5tte maskinerne, som hostede disse containere, have mindst 56 kerner. Tallet 56 blev valgt som en betinget tilstr\u00e6kkelig st\u00f8rrelse, der definerer antallet af tr\u00e5de, som Elasticsearch vil generere under drift. I Elasticsearch afh\u00e6nger mange parametre i thread pool direkte af antallet af tilg\u00e6ngelige kerner, hvilket igen direkte p\u00e5virker det n\u00f8dvendige antal noder i klyngen efter princippet 'f\u00e6rre kerner - flere noder'. <\/p>\n<p><\/p>\n<p>I sidste ende viste det sig, at en shard vejer omkring 20 gigabyte i gennemsnit, og der er 360 shards pr. indeks. Hvis vi roterer dem hver 48 timer, har vi 15 stykker. Hvert indeks rummer data for 2 dage.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Skrive- og l\u00e6seskemaer for data<\/h2>\n<p><\/p>\n<p>Lad os se p\u00e5, hvordan data skrives i dette system.<\/p>\n<p><\/p>\n<p>Antag, at vi modtager en anmodning fra Graylog til koordinatoren. For eksempel \u00f8nsker vi at indeksere 2-3 tusinde r\u00e6kker. <\/p>\n<p><\/p>\n<p>Koordinatoren, der modtog en foresp\u00f8rgsel fra Graylog, sp\u00f8rger masteren: \"I indeksningsforesp\u00f8rgslen blev vi konkret angivet en indeks, men det er ikke angivet, hvilken shard dette skal skrives til.\" <\/p>\n<p><\/p>\n<p>Masteren svarer: \"Skriv denne information i shard nummer 71,\" hvorefter den sendes direkte til den relevante data-node, hvor primary-shard nummer 71 er placeret.<\/p>\n<p><\/p>\n<p>Herefter replikeres transaktionsloggen til replica-shard, som allerede er i et andet datacenter.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Fra Graylog ankommer en s\u00f8geforesp\u00f8rgsel til koordinatoren. Koordinatoren videresender den baseret p\u00e5 indekset, mens Elasticsearch fordeler foresp\u00f8rgslerne mellem primary-shard og replica-shard efter round-robin princippet. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>De 180 noder svarer uj\u00e6vnt, og mens de svarer, opsamler koordinatoren information, som allerede er 'spyttet ud' af hurtigere data-noder. N\u00e5r enten al information er modtaget, eller timeout for foresp\u00f8rgslen er n\u00e5et, returneres alt direkte til klienten. <\/p>\n<p><\/p>\n<p>Hele dette system behandler i gennemsnit s\u00f8geforesp\u00f8rgsler fra de seneste 48 timer p\u00e5 300-400 ms, undtagen de foresp\u00f8rgsler, der har leading wildcard.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\"Blomsterne\" fra Elasticsearch: konfiguration af Java<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>For at alt dette kunne fungere som vi oprindeligt \u00f8nskede, brugte vi meget tid p\u00e5 at justere forskellige aspekter i klusteret. <\/p>\n<p><\/p>\n<p>Den f\u00f8rste del af de problemer, vi opdagede, var relateret til, hvordan Java som standard er forudindstillet i Elasticsearch. <\/p>\n<p><\/p>\n<p><strong>Problem nummer \u00e9t<\/strong><br \/>\nVi oplevede et meget stort antal meddelelser om, at vi p\u00e5 Lucene-niveau, n\u00e5r baggrundsjobber blev k\u00f8rt, fuldf\u00f8rte segmentmergerne i Lucene med fejl. Loggen viste, at der var tale om en OutOfMemoryError-fejl. Gennem telemetri kunne vi se, at heap'en var fri, og det var uklart, hvorfor denne operation mislykkedes. <\/p>\n<p><\/p>\n<p>Det viste sig, at fusionerne af Lucene-indekser skete uden for heapen. Og containerne var ret strengt begr\u00e6nset i de ressourcer, de kunne bruge. I disse ressourcer fik kun heap plads (heap.size var omtrent lig RAM), mens nogle off-heap operationer fejlede med en hukommelsesallokeringsfejl, hvis de af en eller anden grund ikke kunne holde sig inden for de ~500MB, som var tilbage til gr\u00e6nsen.<\/p>\n<p><\/p>\n<p>L\u00f8sningen var ret triviel: m\u00e6ngden af RAM tilg\u00e6ngelig for containeren blev for\u00f8get, hvorefter vi glemte, at vi overhovedet havde s\u00e5danne problemer.<\/p>\n<p><\/p>\n<p><strong>Problem nummer to<\/strong><br \/>\nFire til fem dage efter opstarten af klusteret bem\u00e6rkede vi, at data-noder periodisk begyndte at falde ud af klusteret og derefter komme ind igen efter cirka 10-20 sekunder. <\/p>\n<p><\/p>\n<p>Da vi begyndte at unders\u00f8ge sagen, viste det sig, at denne s\u00e5kaldte off-heap hukommelse i Elasticsearch n\u00e6sten ikke bliver kontrolleret. Da vi tildelte containeren mere hukommelse, fik vi mulighed for at fylde direkte bufferpuljer med forskellige oplysninger, og de blev kun renset, n\u00e5r explicit GC fra Elasticsearch blev udl\u00f8st. <\/p>\n<p><\/p>\n<p>I nogle tilf\u00e6lde tog denne operation ret lang tid, og i mellemtiden n\u00e5ede klyngen at markere denne node som allerede ude. Dette problem er godt beskrevet <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">her<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>L\u00f8sningen var som f\u00f8lger: Vi begr\u00e6nsede Java's evne til at bruge st\u00f8rstedelen af hukommelsen uden for heap til disse operationer. Vi satte den til 16 gigabyte (-XX:MaxDirectMemorySize=16g), hvilket resulterede i, at explicit GC blev kaldt betydeligt oftere og arbejdede meget hurtigere, hvilket stoppede destabilisering af klyngen.<\/p>\n<p><\/p>\n<p><strong>Problem tre<\/strong><br \/>\nHvis du tror, at problemerne med \"noder, der forlader klyngen i de mest uventede \u00f8jeblikke\" er slut, tager du fejl. <\/p>\n<p><\/p>\n<p>Da vi konfigurerede arbejdet med indeksene, valgte vi mmapfs for at <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">reducere s\u00f8getiden<\/a><\/noindex> p\u00e5 friske shards med h\u00f8j segmentering. Dette var en ret grov fejl, fordi ved brug af mmapfs bliver filen kortlagt ind i hukommelsen, og derefter arbejder vi allerede med den kortlagte fil. Dette betyder, at ved fors\u00f8g p\u00e5 GC at stoppe tr\u00e5de i applikationen, tager det os meget lang tid at n\u00e5 safepoint, og undervejs stopper applikationen med at svare p\u00e5 masterens foresp\u00f8rgsler om, hvorvidt det er live. Derfor antager masteren, at noden ikke l\u00e6ngere er til stede i klyngen. Efter omkring 5-10 sekunder arbejder garbage collector, noden genopst\u00e5r, genoptager forbindelsen til klyngen og begynder at initialisere shards. Alt dette mindede meget om \"den produktion, vi fortjente\" og egner sig ikke til noget seri\u00f8st.<\/p>\n<p><\/p>\n<p>For at slippe af med en s\u00e5dan adf\u00e6rd skiftede vi f\u00f8rst til standard niofs, og derefter, da vi migrerede fra 5. versioner af Elastic til 6. versioner, pr\u00f8vede vi hybridfs, hvor dette problem ikke opstod. Du kan l\u00e6se mere om typerne af storage <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">her<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Problem fire<\/strong><br \/>\nDerefter var der endnu et meget interessant problem, som vi behandlede i rekorden lang tid. Vi jagede det i 2-3 m\u00e5neder, fordi m\u00f8nsteret var fuldst\u00e6ndig uklart. <\/p>\n<p><\/p>\n<p>Nogle gange gik vores koordinatorer ind i Full GC, normalt et sted efter frokost, og kom aldrig tilbage derfra. N\u00e5r vi loggede GC-forsinkelser, s\u00e5 det s\u00e5ledes ud: alt gik godt, godt, godt, og pludselig blev alt skarpt d\u00e5rligt. <\/p>\n<p><\/p>\n<p>F\u00f8rst troede vi, at vi havde en ond bruger, der startede en foresp\u00f8rgsel, der fik koordinatoren til at g\u00e5 ud af driftsmode. Vi loggede meget l\u00e6nge foresp\u00f8rgsler for at finde ud af, hvad der skete. <\/p>\n<p><\/p>\n<p>Det viste sig, at p\u00e5 det tidspunkt, hvor en bruger starter en meget stor foresp\u00f8rgsel, og den rammer en bestemt Elasticsearch koordinator, svarer nogle noder langsommere end andre. <\/p>\n<p><\/p>\n<p>Og den tid, det tager koordinatoren at vente p\u00e5 svar fra alle noder, akkumulerer han resultaterne, der er sendt fra allerede besvarede noder. For GC betyder det, at vores brugsm\u00f8nster for heapen \u00e6ndrer sig meget hurtigt. Den GC, vi brugte, kunne ikke h\u00e5ndtere denne opgave. <\/p>\n<p><\/p>\n<p>Den eneste l\u00f8sning, vi fandt for at \u00e6ndre klusterets adf\u00e6rd i en s\u00e5dan situation, var migration til JDK13 og brug af affaldssamleren Shenandoah. Det l\u00f8ste problemet, og vores koordinatorer holdt op med at falde. <\/p>\n<p><\/p>\n<p>P\u00e5 dette punkt sluttede problemerne med Java, og problemerne med b\u00e5ndbredde begyndte. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u00abB\u00e6r\u00bb med Elasticsearch: b\u00e5ndbredde<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Problemer med b\u00e5ndbredde betyder, at vores kluster fungerer stabilt, men ved spidser af antallet af indekserede dokumenter og i man\u00f8vrer er ydeevnen utilstr\u00e6kkelig.<\/p>\n<p><\/p>\n<p>Det f\u00f8rste symptom, vi m\u00f8dte: ved nogle \u00abeksplosioner\u00bb i produktionen, n\u00e5r der pludselig genereres en meget stor m\u00e6ngde logs, begynder Graylog ofte at vise fejlen indexing es_rejected_execution. <\/p>\n<p><\/p>\n<p>Dette skete, fordi thread_pool.write.queue p\u00e5 en datanode, f\u00f8r Elasticsearch kan behandle foresp\u00f8rgslen om indeksering og sende oplysninger til shard p\u00e5 disk, som standard kun kan cache 200 foresp\u00f8rgsler. Og i <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Elasticsearch-dokumentationen<\/a><\/noindex> siger meget lidt om denne parameter. Der angives kun det maksimale antal tr\u00e5de og standardst\u00f8rrelsen.<\/p>\n<p><\/p>\n<p>Selvf\u00f8lgelig gik vi til at justere denne v\u00e6rdi og fandt f\u00f8lgende: specifikt i vores ops\u00e6tning kan der caches ret godt op til 300 foresp\u00f8rgsler, mens en st\u00f8rre v\u00e6rdi vil f\u00f8re til, at vi igen havner i Full GC.<\/p>\n<p><\/p>\n<p>Desuden, da dette er beskeder, der modtages i \u00e9n enkelt foresp\u00f8rgsel, var det ogs\u00e5 n\u00f8dvendigt at justere Graylog, s\u00e5 den ikke skriver ofte og i sm\u00e5 batcher, men i store batcher eller \u00e9n gang hvert 3. sekund, hvis batchen stadig ikke er fuld. I s\u00e5 fald betyder det, at de oplysninger, vi skriver til Elasticsearch, bliver tilg\u00e6ngelige ikke efter to sekunder, men efter fem (hvilket vi er tilfredse med), men antallet af retries, der skal g\u00f8res for at skubbe en stor m\u00e6ngde information, reduceres.<\/p>\n<p><\/p>\n<p>Dette er is\u00e6r vigtigt i de \u00f8jeblikke, hvor noget er faldet et sted, og det g\u00f8r os opm\u00e6rksom p\u00e5 det, for at undg\u00e5 at f\u00e5 fuldst\u00e6ndig spammet Elastic, og efter noget tid \u2014 ikke-fungerende noder i Graylog p\u00e5 grund af fyldte buffere.<\/p>\n<p><\/p>\n<p>Desuden, da vi oplevede disse eksplosioner i produktionen, modtog vi klager fra programm\u00f8rer og testere: i det \u00f8jeblik, hvor de meget havde brug for disse logs, blev de givet til dem meget langsomt.<\/p>\n<p><\/p>\n<p>Vi begyndte at unders\u00f8ge sagen. P\u00e5 den ene side var det klart, at b\u00e5de s\u00f8geforesp\u00f8rgsler og indl\u00e6sningsanmodninger blev behandlet p\u00e5 stort set de samme fysiske maskiner, og der ville v\u00e6re bestemte nedgange under alle omst\u00e6ndigheder. <\/p>\n<p><\/p>\n<p>Men dette kunne delvist omg\u00e5s ved, at der i sjette version af Elasticsearch kom en algoritme, som g\u00f8r det muligt at fordele foresp\u00f8rgsler mellem relevante data-noder ikke efter tilf\u00e6ldig round-robin-princip (containere, der besk\u00e6ftiger sig med indeksering og har primary-shard, kan v\u00e6re meget belastede, og der vil ikke v\u00e6re mulighed for hurtigt at svare), men at dirigere denne foresp\u00f8rgsel til en mindre belastet container med replica-shard, som vil svare betydeligt hurtigere. Med andre ord kom vi til use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>Billedet af l\u00e6sningen begynder at se s\u00e5ledes ud:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Overgangen til denne algoritme har betydeligt forbedret foresp\u00f8rgselstiden i de \u00f8jeblikke, hvor vi havde en stor str\u00f8m af logs til skrivning.<\/p>\n<p><\/p>\n<p>Endelig var det prim\u00e6re problem at afslutte data-centret smertefrit.<\/p>\n<p><\/p>\n<p>Hvad vi \u00f8nskede fra klyngen lige efter tabet af forbindelsen til et datacenter: <\/p>\n<p><\/p>\n<ul>\n<li>Hvis vores nuv\u00e6rende master befinder sig i det afbrudte datacenter, vil den blive genvalgt og flytte sin rolle til en anden node i et andet datacenter.<\/li>\n<li>Masteren vil hurtigt fjerne alle utilg\u00e6ngelige noder fra klyngen.<\/li>\n<li>Baseret p\u00e5 de resterende vil han forst\u00e5: i det tabte datacenter havde vi s\u00e5danne primary shards, hurtigt promoverer komplement\u00e6re replica shards i de resterende datacentre, og vi vil forts\u00e6tte med at indeksere dataene. <\/li>\n<li>Som et resultat heraf vil vores b\u00e5ndbredde i klyngen til skrivning og l\u00e6sning gradvist degraderes, men generelt vil alt fungere, omend langsomt, men stabilt.<\/li>\n<\/ul>\n<p><\/p>\n<p>Som det viser sig, \u00f8nskede vi os noget i denne stil:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Men vi fik f\u00f8lgende:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvordan kunne dette ske? <\/p>\n<p><\/p>\n<p>P\u00e5 tidspunktet for datacenterets fald blev vores flaskehals masteren.<\/p>\n<p><\/p>\n<p>Hvorfor?<\/p>\n<p><\/p>\n<p>Det vigtigste er, at der i masteren er en TaskBatcher, der er ansvarlig for distributionen af bestemte opgaver og h\u00e6ndelser i klyngen. Enhver nodes udgang, enhver opgradering af shards fra replica til primary, enhver opgave til at oprette et eller andet shard - alt dette kommer f\u00f8rst ind i TaskBatcher, hvor det behandles sekventielt og i \u00e9t stream.<\/p>\n<p><\/p>\n<p>P\u00e5 tidspunktet for udgangen af et datacenter skete det, at alle datanoder i de overlevende datacentre f\u00f8lte, det var deres pligt at informere masteren 'vi har mistet s\u00e5danne shards og s\u00e5danne datanoder'. <\/p>\n<p><\/p>\n<p>Samtidig sendte de overlevende datanoder al denne information til den nuv\u00e6rende master og fors\u00f8gte at vente p\u00e5 bekr\u00e6ftelse om, at han havde modtaget det. De ventede ikke, da masteren modtog opgaver hurtigere, end han kunne svare. Noderne gentog deres foresp\u00f8rgsler ved timeout, mens masteren i mellemtiden ikke engang fors\u00f8gte at svare dem og var helt opslugt af opgaven med at sortere foresp\u00f8rgslerne efter prioriteter.<\/p>\n<p><\/p>\n<p>I et terminalt scenarie viste det sig, at datanoderne spammede masteren, til han gik i full GC. Efter dette flyttede vores rolle som master til en anden node, og med hende skete der helt det samme, og i sidste ende kollapsede klyngen fuldst\u00e6ndigt. <\/p>\n<p><\/p>\n<p>Vi foretog m\u00e5linger, og indtil version 6.4.0, hvor dette blev rettet, var det nok at f\u00e5 blot 10 datanoder ud af 360 til at l\u00e6gge klyngen helt ned.<\/p>\n<p><\/p>\n<p>Det s\u00e5 cirka s\u00e5dan ud:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Efter version 6.4.0, hvor de l\u00f8ste denne skr\u00e6mmende bug, holdt datanoderne op med at dr\u00e6be masteren. Men han blev ikke 'klogere' af den grund. N\u00e5r vi for eksempel fjerner 2, 3 eller 10 (hvilket som helst antal, der ikke er lig med \u00e9n) datanoder, modtager masteren en slags f\u00f8rste besked, der siger, at node A er g\u00e5et ud, og han fors\u00f8ger at informere node B, node C, node D om dette. <\/p>\n<p><\/p>\n<p>Og i \u00f8jeblikket kan dette kun tackles ved at indstille en timeout for fors\u00f8g p\u00e5 at fort\u00e6lle nogen om noget, svarende til cirka 20-30 sekunder, og dermed styre hastigheden, hvormed datacenteret forlader klyngen.<\/p>\n<p><\/p>\n<p>I princippet falder dette inden for de krav, der oprindeligt blev stillet til det endelige produkt i projektets rammer, men set fra et 'rent videnskabeligt' perspektiv er det en fejl. Som i \u00f8vrigt blev l\u00f8st af udviklerne i version 7.2.<\/p>\n<p><\/p>\n<p>N\u00e5r en datanode gik ned, viste det sig, at det var vigtigere at sprede informationen om dens nedbrud end at informere hele klyngen om, hvilke primary-shard der var p\u00e5 den (for at promovere replica-shard i et andet datacenter til primary, s\u00e5 der kunne skrives information til dem).<\/p>\n<p><\/p>\n<p>Derfor, n\u00e5r alt er 'overst\u00e5et', bliver de nedlagte datanoder ikke straks markeret som stale. Derfor er vi n\u00f8dt til at vente, til alle pingene til de nedlagte datanoder er timed out, og f\u00f8rst derefter begynder vores klynge at fort\u00e6lle, at der, der og der skal forts\u00e6ttes med at skrive information. Du kan l\u00e6se mere om det <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">her<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Som et resultat tager operationen med at tr\u00e6kke datacenteret i dag omkring 5 minutter i myldretiden. For en s\u00e5 stor og klodset maskine er det et ret godt resultat.<\/p>\n<p><\/p>\n<p>Som et resultat kom vi frem til f\u00f8lgende l\u00f8sning:<\/p>\n<p><\/p>\n<ul>\n<li>Vi har 360 datanoder med diske p\u00e5 700 gigabyte.<\/li>\n<li>60 koordinatorer til at routinge trafikken mellem de n\u00e6vnte datanoder.<\/li>\n<li>40 mestre, som vi har bevaret som en slags arv fra versioner f\u00f8r 6.4.0 \u2014 for at overleve nedtr\u00e6kningen af datacenteret, var vi mentalt forberedte p\u00e5 at miste nogle maskiner, for at have et fejlfrit kvorum af mestre, selv under det v\u00e6rste scenarie.<\/li>\n<li>Enhver fors\u00f8g p\u00e5 at kombinere roller p\u00e5 \u00e9n container st\u00f8dte p\u00e5 det faktum, at node p\u00e5 et eller andet tidspunkt ville bryde sammen under belastning. <\/li>\n<li>I hele klyngen anvendes heap.size p\u00e5 31 gigabyte: alle fors\u00f8g p\u00e5 at reducere st\u00f8rrelsen resulterede i, at tunge s\u00f8geforesp\u00f8rgsler med leading wildcard enten dr\u00e6bte nogle noder eller fik circuit breaker til at g\u00e5 ned i selve Elasticsearch.<\/li>\n<li>Desuden pr\u00f8vede vi at holde antallet af objekter i klyngen s\u00e5 lavt som muligt for at kunne behandle s\u00e5 f\u00e5 h\u00e6ndelser som muligt p\u00e5 det smaleste sted, som vi havde i mesteren.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Til sidst om overv\u00e5gning<\/h2>\n<p><\/p>\n<p>For everything to work as intended, we monitor the following:<\/p>\n<p><\/p>\n<ul>\n<li>Each data node reports to our cloud that it exists and has certain shards on it. When we shut something down somewhere, the cluster reports within 2-3 seconds that in center A we have shut down nodes 2, 3, and 4 \u2014 this means that in other data centers we cannot shut down the nodes on which there are unique shards.<\/li>\n<li>Knowing the master's behavior, we pay close attention to the number of pending tasks. Because even one hanging task, if not timed out in time, can theoretically become the reason why our promotion of a replica shard to primary might fail, affecting indexing.<\/li>\n<li>We also keep a close watch on garbage collector delays, as we have had significant issues with this during optimization.<\/li>\n<li>Rejects by threads to understand in advance where the 'bottleneck' is located.<\/li>\n<li>And the standard metrics, such as heap, RAM, and I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>When building monitoring, one must consider the features of the Thread Pool in Elasticsearch. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Elasticsearch documentation<\/a><\/noindex> describes the configuration options and default values for searching and indexing, but completely omits thread_pool.management. These threads process, among other things, requests like _cat\/shards and other similar requests that are convenient for monitoring. The larger the cluster, the more such requests are executed per unit of time, and the aforementioned thread_pool.management is not only absent from the official documentation, but is also limited by default to 5 threads, which quickly get utilized, after which monitoring stops working correctly.<\/p>\n<p><\/p>\n<p>What I want to say in conclusion: we did it! We managed to provide our programmers and developers with a tool that can quickly and reliably provide information about what is happening in production in almost any situation.<\/p>\n<p><\/p>\n<p>Yes, it turned out to be quite complex, but nevertheless, we were able to fit our requirements into existing products without having to patch or rewrite them.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-klynge p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Kilde: <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.5 - 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\/da\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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-klynge p\u00e5 200 TB+ | ProHoster","description":"Mange st\u00e5r over for Elasticsearch.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}