{"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\/sv\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Elasticsearch-kluster p\u00e5 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>M\u00e5nga st\u00f6ter p\u00e5 Elasticsearch. Men vad h\u00e4nder n\u00e4r man vill anv\u00e4nda det f\u00f6r att lagra loggar \"i en s\u00e4rskilt stor m\u00e4ngd\"? Och dessutom utan att k\u00e4nna av ett eventuellt misslyckande av n\u00e5got av flera datacenter? Hur b\u00f6r arkitekturen se ut, och vilka fallgropar kan man st\u00f6ta p\u00e5?<\/p>\n<p><\/p>\n<p>Vi p\u00e5 Odnoklassniki har beslutat att anv\u00e4nda Elasticsearch f\u00f6r att l\u00f6sa fr\u00e5gan om logghantering, och nu delar vi med oss av v\u00e5ra erfarenheter till Habr: b\u00e5de om arkitekturen och om fallgroparna.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Jag \u00e4r Peter Zaitsev, arbetande systemadministrat\u00f6r p\u00e5 Odnoklassniki. Innan dess var jag ocks\u00e5 administrat\u00f6r och arbetade med Manticore Search, Sphinx search och Elasticsearch. Kanske, om det dyker upp n\u00e5gon annan ...search, kommer jag sannolikt att arbeta med det ocks\u00e5. Jag deltar ocks\u00e5 i flera \u00f6ppen k\u00e4llkodsprojekt p\u00e5 frivillig basis.<\/p>\n<p><\/p>\n<p>N\u00e4r jag kom till Odnoklassniki sade jag of\u00f6rsiktigt p\u00e5 intervjun att jag kunde arbeta med Elasticsearch. Efter att ha kommit in i det och genomf\u00f6rt n\u00e5gra enklare uppgifter fick jag en stor uppgift att reformera det logghanteringssystem som fanns vid den tidpunkten. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Krav<\/h2>\n<p><\/p>\n<p>Krav p\u00e5 systemet formulerades p\u00e5 f\u00f6ljande s\u00e4tt:<\/p>\n<p><\/p>\n<ul>\n<li>Som frontend skulle Graylog anv\u00e4ndas. Eftersom f\u00f6retaget redan hade erfarenhet av att anv\u00e4nda denna produkt, k\u00e4nde programmerare och testare till den, den var bekant och bekv\u00e4m f\u00f6r dem.<\/li>\n<li>Datafl\u00f6det: i genomsnitt 50-80 tusen meddelanden per sekund, men om n\u00e5got g\u00e5r s\u00f6nder \u00e4r trafiken oreglerad, det kan bli 2-3 miljoner rader per sekund.<\/li>\n<li>Efter att ha diskuterat kraven p\u00e5 hastigheten f\u00f6r att bearbeta s\u00f6kfr\u00e5gor med best\u00e4llarna ins\u00e5g vi att det typiska anv\u00e4ndningsm\u00f6nstret f\u00f6r ett s\u00e5dant system \u00e4r att m\u00e4nniskor s\u00f6ker loggar f\u00f6r sin applikation f\u00f6r de senaste tv\u00e5 dagarna och inte vill v\u00e4nta l\u00e4ngre \u00e4n en sekund p\u00e5 resultatet av sin fr\u00e5ga. <\/li>\n<li>Administrat\u00f6rer insisterade p\u00e5 att systemet enkelt skulle kunna skalas om det beh\u00f6vdes, utan att det kr\u00e4vdes att de hade djup kunskap om hur det \u00e4r uppbyggt. <\/li>\n<li>S\u00e5 den enda uppgiften f\u00f6r underh\u00e5ll som systemet regelbundet kr\u00e4vde var att byta ut viss h\u00e5rdvara.<\/li>\n<li>Dessutom har Odnoklassniki en fantastisk teknisk tradition: varje tj\u00e4nst vi lanserar m\u00e5ste klara av att hantera ett datacenteravbrott (pl\u00f6tsligt, of\u00f6rutsett och vid vilken tidpunkt som helst).<\/li>\n<\/ul>\n<p><\/p>\n<p>Det senaste kravet i genomf\u00f6randet av detta projekt har kostat oss mest blod, vilket jag kommer att ber\u00e4tta mer om senare.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Milj\u00f6<\/h2>\n<p><\/p>\n<p>Vi arbetar p\u00e5 fyra datacenter, medan datanoder f\u00f6r Elasticsearch bara kan placeras i tre (av flera icke-tekniska anledningar).<\/p>\n<p><\/p>\n<p>I dessa fyra datacenter finns ungef\u00e4r 18 000 olika loggk\u00e4llor \u2014 h\u00e5rdvara, containrar, virtuella maskiner.<\/p>\n<p><\/p>\n<p>En viktig funktion: klustret startas i containrar <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> inte p\u00e5 fysiska maskiner, utan p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">v\u00e5r egen molnprodukt one-cloud<\/a><\/noindex>. Containrarna garanteras 2 k\u00e4rnor, motsvarande 2.0Ghz v4 med m\u00f6jlighet att anv\u00e4nda resterande k\u00e4rnor om de \u00e4r lediga. <\/p>\n<p><\/p>\n<p>Med andra ord:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster 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 \u00f6vergripande l\u00f6sningen s\u00e5g jag initialt ut p\u00e5 f\u00f6ljande s\u00e4tt:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP:ar st\u00e5r bakom A-posterna f\u00f6r dom\u00e4nen Graylog, det \u00e4r adressen dit loggarna skickas.<\/li>\n<li>varje VIP \u00e4r en LVS-belastningsbalanserare.<\/li>\n<li>Efter det kommer loggarna till ett batteri av Graylog, d\u00e4r en del av datan g\u00e5r i GELF-format och en annan del i syslog-format.<\/li>\n<li>D\u00e4refter skrivs allt detta i stora batchar till ett batteri av Elasticsearch-koordinatorer. <\/li>\n<li>Och de, i sin tur, skickar skriv- och l\u00e4sf\u00f6rfr\u00e5gningar till relevanta datanoder. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster 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>Kanske \u00e4r inte alla insatta i terminologin, s\u00e5 jag skulle vilja stanna vid den en stund.<\/p>\n<p><\/p>\n<p>I Elasticsearch finns det flera typer av noder \u2014 master, koordinator, datanod. Det finns ocks\u00e5 tv\u00e5 andra typer f\u00f6r olika loggtransformationer och f\u00f6r att l\u00e4nka ihop olika kluster, men vi anv\u00e4nde bara de n\u00e4mnda. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPingar alla noder n\u00e4rvarande i klustret, uppr\u00e4tth\u00e5ller en aktuell karta \u00f6ver klustret och sprider den mellan noderna, hanterar h\u00e4ndelselogik, sysslar med olika typer av cluster wide housekeeping. <\/p>\n<p><\/p>\n<p><strong>Koordinator<\/strong><br \/>\nUtf\u00f6r en enda uppgift: tar emot f\u00f6rfr\u00e5gningar fr\u00e5n kunder f\u00f6r l\u00e4sning eller skrivning och dirigerar denna trafik. Om det \u00e4r en skrivf\u00f6rfr\u00e5gan kommer den troligtvis att fr\u00e5ga master vilken shard av den relevanta indexen den ska l\u00e4gga detta i och vidarebefordra f\u00f6rfr\u00e5gningen. <\/p>\n<p><\/p>\n<p><strong>Datanod<\/strong><br \/>\nLagrar data, utf\u00f6r s\u00f6kf\u00f6rfr\u00e5gningar och operationer p\u00e5 de shards som finns d\u00e4r.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nDet h\u00e4r \u00e4r en slags sammanslagning av Kibana med Logstash i ELK-stacken. Graylog kombinerar b\u00e5de UI och en pipeline f\u00f6r logghantering. Under huven hos Graylog arbetar Kafka och Zookeeper, som m\u00f6jligg\u00f6r kommunikation mellan Graylog som en kluster. Graylog kan cacha loggar (Kafka) vid avbrott av Elasticsearch och repetera misslyckade l\u00e4s- och skrivf\u00f6rfr\u00e5gningar, gruppera och m\u00e4rka loggar enligt angivna regler. Precis som Logstash har Graylog funktionalitet f\u00f6r att modifiera str\u00e4ngar innan de skrivs till Elasticsearch.<\/p>\n<p><\/p>\n<p>Dessutom har Graylog inbyggd service discovery som g\u00f6r det m\u00f6jligt att f\u00e5 en \u00f6versikt \u00f6ver hela klustret baserat p\u00e5 en tillg\u00e4nglig Elasticsearch-nod och filtrera den efter en viss tagg, vilket ger m\u00f6jlighet att rikta f\u00f6rfr\u00e5gningar mot specifika containrar.<\/p>\n<p><\/p>\n<p>Visuellt ser det ut s\u00e5 h\u00e4r:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Detta \u00e4r en sk\u00e4rmdump fr\u00e5n en specifik instans. H\u00e4r bygger vi en histogram baserat p\u00e5 en s\u00f6kf\u00f6rfr\u00e5gan och visar relevanta rader.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Index<\/h2>\n<p><\/p>\n<p>N\u00e4r vi \u00e5terv\u00e4nder till systemets arkitektur skulle jag vilja g\u00e5 n\u00e4rmare in p\u00e5 hur vi byggde indexmodellen s\u00e5 att allt fungerade korrekt. <\/p>\n<p><\/p>\n<p>I det tidigare diagrammet \u00e4r detta den l\u00e4gsta niv\u00e5n: Elasticsearch datanoder.<\/p>\n<p><\/p>\n<p>Ett index \u00e4r en stor virtuell entitet som best\u00e5r av Elasticsearch-shards. Varje shard \u00e4r i sig inget annat \u00e4n ett Lucene-index. Och varje Lucene-index best\u00e5r i sin tur av ett eller flera segment. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vid designen r\u00e4knade vi med att f\u00f6r att uppfylla kravet p\u00e5 l\u00e4shastighet vid stora datam\u00e4ngder m\u00e5ste vi j\u00e4mnt \"sprida ut\" dessa data \u00f6ver datanoderna. <\/p>\n<p><\/p>\n<p>Det resulterade i att antalet shards per index (med repliker) m\u00e5ste vara strikt lika med antalet datanoder. F\u00f6r det f\u00f6rsta f\u00f6r att s\u00e4kerst\u00e4lla en replikationsfaktor p\u00e5 tv\u00e5 (det vill s\u00e4ga vi kan f\u00f6rlora h\u00e4lften av klustret). F\u00f6r det andra f\u00f6r att kunna hantera l\u00e4s- och skrivf\u00f6rfr\u00e5gningar med minst h\u00e4lften av klustret.<\/p>\n<p><\/p>\n<p>Vi definierade lagringstiden initialt som 30 dagar.<\/p>\n<p><\/p>\n<p>Distributionen av shards kan grafiskt representeras p\u00e5 f\u00f6ljande s\u00e4tt:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hela den m\u00f6rkgr\u00e5 rektangeln \u00e4r indexet i sin helhet. Den v\u00e4nstra r\u00f6da fyrkanten i den \u00e4r prim\u00e4rsharden, den f\u00f6rsta i indexet. Och den bl\u00e5 fyrkanten \u00e4r replica-sharden. De finns i olika datacenter.<\/p>\n<p><\/p>\n<p>N\u00e4r vi l\u00e4gger till en ytterligare shard hamnar den i det tredje datacentret. Och i slut\u00e4ndan f\u00e5r vi en s\u00e5dan struktur som m\u00f6jligg\u00f6r f\u00f6rlust av datacenter utan att f\u00f6rlora konsistensen av data:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster 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 st\u00e4llt in rotationen av index, det vill s\u00e4ga skapandet av ett nytt index och borttagning av det \u00e4ldsta, till 48 timmar (baserat p\u00e5 m\u00f6nstret f\u00f6r anv\u00e4ndning av indexet: de senaste 48 timmarna s\u00f6ks oftast).<\/p>\n<p><\/p>\n<p>Denna rotationsintervall f\u00f6r index \u00e4r kopplad till f\u00f6ljande orsaker:<\/p>\n<p><\/p>\n<p>N\u00e4r en specifik datanod f\u00e5r en s\u00f6kfr\u00e5ga \u00e4r det ur ett prestandaperspektiv f\u00f6rdelaktigt att fr\u00e5ga en shard om dess storlek \u00e4r j\u00e4mf\u00f6rbar med storleken p\u00e5 nodens heap. Detta till\u00e5ter att h\u00e5lla den \"heta\" delen av indexet i heapen och snabbt f\u00e5 \u00e5tkomst till den. N\u00e4r det blir m\u00e5nga \"heta delar\" degraderas s\u00f6khastigheten f\u00f6r indexet.<\/p>\n<p><\/p>\n<p>N\u00e4r en nod b\u00f6rjar hantera en s\u00f6kfr\u00e5ga p\u00e5 en shard tilldelar den ett antal tr\u00e5dar motsvarande antalet hypertr\u00e5dade k\u00e4rnor i den fysiska maskinen. Om s\u00f6kfr\u00e5gan ber\u00f6r ett stort antal shards \u00f6kar antalet tr\u00e5dar proportionellt. Detta p\u00e5verkar s\u00f6khastigheten negativt och har en negativ inverkan p\u00e5 indexeringen av nya data. <\/p>\n<p><\/p>\n<p>F\u00f6r att s\u00e4kerst\u00e4lla den n\u00f6dv\u00e4ndiga s\u00f6k-latensen beslutade vi att anv\u00e4nda SSD. F\u00f6r att snabbt bearbeta f\u00f6rfr\u00e5gningar m\u00e5ste maskinerna som hyste dessa containrar ha minst 56 k\u00e4rnor. Siffran 56 valdes som en villkorligt tillr\u00e4cklig m\u00e4ngd, som best\u00e4mmer antalet tr\u00e5dar som Elasticsearch kommer att generera under drift. I Elasticsearch beror m\u00e5nga inst\u00e4llningar f\u00f6r tr\u00e5dpool direkt p\u00e5 antalet tillg\u00e4ngliga k\u00e4rnor, vilket i sin tur direkt p\u00e5verkar det n\u00f6dv\u00e4ndiga antalet noder i klustret enligt principen \"f\u00e4rre k\u00e4rnor \u2014 fler noder\". <\/p>\n<p><\/p>\n<p>I slut\u00e4ndan verkar det som att en shard i genomsnitt v\u00e4ger omkring 20 gigabyte, och det finns 360 shards per index. Om vi roterar dem var 48:e timme har vi totalt 15 stycken. Varje index rymmer data f\u00f6r 2 dagar.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Skriva och l\u00e4sa data scheman<\/h2>\n<p><\/p>\n<p>L\u00e5t oss g\u00e5 igenom hur data skrivs i detta system.<\/p>\n<p><\/p>\n<p>Anta att vi f\u00e5r en f\u00f6rfr\u00e5gan fr\u00e5n Graylog till koordinatorn. Till exempel, vi vill indexera 2-3 tusen rader. <\/p>\n<p><\/p>\n<p>Koordinatorn f\u00e5r en f\u00f6rfr\u00e5gan fr\u00e5n Graylog och fr\u00e5gar mastern: \"I indexeringsf\u00f6rfr\u00e5gan angav vi specifikt index men inte vilken shard den ska skrivas till.\" <\/p>\n<p><\/p>\n<p>Mastern svarar: \"Skriv denna information i shard nummer 71\", varefter den direkt skickas till den relevanta data-noden d\u00e4r primary-shard nummer 71 finns.<\/p>\n<p><\/p>\n<p>D\u00e4refter replikerar transaktionsloggen till replica-shard som ligger i ett annat datacenter.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Fr\u00e5n Graylog kommer en s\u00f6kf\u00f6rfr\u00e5gan till koordinatorn. Koordinatorn vidarebefordrar den enligt index, d\u00e4r Elasticsearch via round-robin f\u00f6rdelar f\u00f6rfr\u00e5gningar mellan primary-shard och replica-shard. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Noderna, totalt 180 stycken, svarar oj\u00e4mnt, och medan de svarar samlar koordinatorn information som de snabbare data-noderna redan \"spottat ut\". N\u00e4r all information antingen kommit in eller tidsgr\u00e4nsen n\u00e5tts, skickar den allt direkt till klienten. <\/p>\n<p><\/p>\n<p>Hela detta system hanterar i genomsnitt s\u00f6kf\u00f6rfr\u00e5gningar fr\u00e5n de senaste 48 timmarna p\u00e5 300-400ms, med undantag f\u00f6r de f\u00f6rfr\u00e5gningar som har leading wildcard.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\"Sm\u00e5tt och gott\" med Elasticsearch: Java-inst\u00e4llningar<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>F\u00f6r att allt skulle fungera som vi fr\u00e5n b\u00f6rjan ville, finjusterade vi under en l\u00e5ng tid olika saker i klustret. <\/p>\n<p><\/p>\n<p>Den f\u00f6rsta delen av de uppt\u00e4ckta problemen var relaterade till hur Java \u00e4r f\u00f6rinst\u00e4lld i Elasticsearch. <\/p>\n<p><\/p>\n<p><strong>F\u00f6rsta problemet<\/strong><br \/>\nVi har sett ett mycket stort antal meddelanden om att vi p\u00e5 Lucene-niv\u00e5, n\u00e4r bakgrundsarbeten k\u00f6rs, misslyckas mergesegment av Lucene med ett fel. Det var ocks\u00e5 tydligt i loggarna att detta var ett OutOfMemoryError-fel. Genom telemetrin s\u00e5g vi att heapen var fri, och det var oklart varf\u00f6r denna operation misslyckas. <\/p>\n<p><\/p>\n<p>Det visade sig att Lucene-indexmerges \u00e4ger rum utanf\u00f6r heapen. Och containrarna \u00e4r ganska h\u00e5rt begr\u00e4nsade vad g\u00e4ller resurser. Dessa resurser rymde endast heapen (heap.size var ungef\u00e4r lika med RAM), och vissa off-heap-operationer misslyckades med minnesallokeringsfel om de av n\u00e5gon anledning inte passade inom de ~500MB som \u00e5terstod till gr\u00e4nsen.<\/p>\n<p><\/p>\n<p>Fixen var ganska trivial: vi \u00f6kade det tillg\u00e4ngliga RAM-minnet f\u00f6r containern och efter det gl\u00f6mde vi att vi ens hade s\u00e5dana problem.<\/p>\n<p><\/p>\n<p><strong>Det andra problemet<\/strong><br \/>\nFyra till fem dagar efter att klustret startades m\u00e4rkte vi att data-noderna b\u00f6rjade periodiskt falla ut ur klustret och komma tillbaka efter 10-20 sekunder. <\/p>\n<p><\/p>\n<p>N\u00e4r vi b\u00f6rjade unders\u00f6ka det visade det sig att denna off-heap minne i Elasticsearch knappt kontrolleras alls. N\u00e4r vi gav containern mer minne fick vi m\u00f6jlighet att fylla direkt buffertpoolerna med olika information, och den rensades endast efter att en explicit GC k\u00f6rdes fr\u00e5n Elasticsearch. <\/p>\n<p><\/p>\n<p>I vissa fall tog denna operation ganska l\u00e5ng tid, och under denna tid hann klustret m\u00e4rka denna nod som redan nedst\u00e4ngd. Detta problem \u00e4r v\u00e4l beskrivet. <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">h\u00e4r<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>L\u00f6sningen blev f\u00f6ljande: vi begr\u00e4nsade Java:s m\u00f6jlighet att anv\u00e4nda st\u00f6rsta delen av minnet utanf\u00f6r heapen f\u00f6r dessa operationer. Vi begr\u00e4nsade det till 16 gigabyte (-XX:MaxDirectMemorySize=16g), vilket resulterade i att explicit GC kallades betydligt oftare och genomf\u00f6rdes betydligt snabbare, vilket slutade med att klustret inte blev instabilt.<\/p>\n<p><\/p>\n<p><strong>Problem tre<\/strong><br \/>\nOm du tror att problem med 'noder som l\u00e4mnar klustret vid de mest ov\u00e4ntade \u00f6gonblicken' avslutades h\u00e4r, tar du fel. <\/p>\n<p><\/p>\n<p>N\u00e4r vi konfigurerade arbete med indexen valde vi mmapfs f\u00f6r att <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">minska s\u00f6ktiden<\/a><\/noindex> f\u00f6r nya shards med h\u00f6g segmentering. Detta var ett ganska grovt misstag, eftersom n\u00e4r man anv\u00e4nder mmapfs s\u00e5 mappas filen in i RAM, och vi arbetar sedan med den mappade filen. Detta g\u00f6r att n\u00e4r garbage collection f\u00f6rs\u00f6ker stoppa tr\u00e5darna i applikationen tar det mycket l\u00e5ng tid att n\u00e5 safepoint, och p\u00e5 v\u00e4gen dit slutar applikationen att svara p\u00e5 masterns f\u00f6rfr\u00e5gningar om huruvida den fortfarande lever. F\u00f6ljaktligen anser master att noden inte l\u00e4ngre finns i klustret. Efter cirka 5-10 sekunder genomf\u00f6rs garbage collector, noden \u00e5terupplivas, g\u00e5r \u00e5ter in i klustret och p\u00e5b\u00f6rjar initialisering av shards. Allt detta p\u00e5minde starkt om 'produktionen vi f\u00f6rtj\u00e4nade' och var ol\u00e4mpligt f\u00f6r n\u00e5got seri\u00f6st.<\/p>\n<p><\/p>\n<p>F\u00f6r att bli av med ett s\u00e5dant beteende gick vi f\u00f6rst \u00f6ver till standard nio-fs, och sedan, n\u00e4r vi migrerade fr\u00e5n femte versioner av Elastic till sj\u00e4tte, f\u00f6rs\u00f6kte vi hybridfs d\u00e4r detta problem inte \u00e5terkom. Mer om lagringstyper kan l\u00e4sas. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">h\u00e4r<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Problem fyra<\/strong><br \/>\nSedan fanns det ytterligare ett mycket intressant problem som vi behandlade rekordl\u00e4nge. Vi jagade det i 2-3 m\u00e5nader eftersom dess m\u00f6nster var helt oklart. <\/p>\n<p><\/p>\n<p>Ibland gick v\u00e5ra koordinatorer in i Full GC, vanligtvis n\u00e5gon g\u00e5ng efter lunch, och kom d\u00e4rifr\u00e5n inte tillbaka. Vid loggning av GC-f\u00f6rseningar s\u00e5g det ut s\u00e5 h\u00e4r: vi hade allt under kontroll, under kontroll, under kontroll, men sedan pl\u00f6tsligt \u2014 och allt gick snabbt d\u00e5ligt. <\/p>\n<p><\/p>\n<p>F\u00f6rst trodde vi att vi hade en illvillig anv\u00e4ndare som k\u00f6rde en f\u00f6rfr\u00e5gan som fick koordinatorn att sluta fungera. Vi loggade l\u00e4nge f\u00f6rfr\u00e5gningar f\u00f6r att ta reda p\u00e5 vad som h\u00e4nde. <\/p>\n<p><\/p>\n<p>Till slut visade det sig att vid den tidpunkt d\u00e5 en anv\u00e4ndare k\u00f6r en stor f\u00f6rfr\u00e5gan, och den hamnar p\u00e5 en specifik Elasticsearch-koordinator, svarar vissa noder l\u00e5ngsammare \u00e4n andra. <\/p>\n<p><\/p>\n<p>Och den tid som koordinatorn v\u00e4ntar p\u00e5 svar fr\u00e5n alla noder, samlar den resultaten som skickats fr\u00e5n de noder som redan svarat. F\u00f6r GC inneb\u00e4r det att v\u00e5rt m\u00f6nster f\u00f6r anv\u00e4ndning av heapen f\u00f6r\u00e4ndras snabbt. Och den GC vi anv\u00e4nde klarade inte av denna uppgift. <\/p>\n<p><\/p>\n<p>Den enda fix vi hittade f\u00f6r att \u00e4ndra klusterbeteendet i en s\u00e5dan situation var migration till JDK13 och anv\u00e4ndning av skr\u00e4puppsamlaren Shenandoah. Detta l\u00f6ste problemet, och v\u00e5ra koordinatorer slutade krascha. <\/p>\n<p><\/p>\n<p>Med detta slutade problemen med Java och problemen med genomstr\u00f6mning b\u00f6rjade. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\"B\u00e4r\" med Elasticsearch: genomstr\u00f6mning<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Problem med genomstr\u00f6mningen inneb\u00e4r att v\u00e5rt kluster fungerar stabilt, men under toppar av antalet indexerade dokument och vid manipulationer \u00e4r prestandan otillr\u00e4cklig.<\/p>\n<p><\/p>\n<p>Det f\u00f6rsta symptom vi m\u00e4rkte: vid vissa \"explosioner\" i produktionen, n\u00e4r det pl\u00f6tsligt genereras en mycket stor m\u00e4ngd loggar, dyker det ofta upp ett indexeringsfel i Graylog som heter es_rejected_execution. <\/p>\n<p><\/p>\n<p>Detta h\u00e4nde eftersom thread_pool.write.queue p\u00e5 en data-nod, innan Elasticsearch kan bearbeta indexeringsf\u00f6rfr\u00e5gan och skicka informationen till shard p\u00e5 disk, som standard kan cacha endast 200 f\u00f6rfr\u00e5gningar. Och i <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">dokumentationen f\u00f6r Elasticsearch<\/a><\/noindex> s\u00e4rskilt om denna parameter n\u00e4mns v\u00e4ldigt lite. Endast det maximala antalet tr\u00e5dar och den standardstorlek som n\u00e4mns.<\/p>\n<p><\/p>\n<p>Sj\u00e4lvklart b\u00f6rjade vi justera detta v\u00e4rde och kom fram till f\u00f6ljande: specifikt i v\u00e5r setup fungerar det ganska bra att cacha upp till 300 f\u00f6rfr\u00e5gningar, medan ett h\u00f6gre v\u00e4rde inneb\u00e4r att vi \u00e5ker tillbaka i Full GC.<\/p>\n<p><\/p>\n<p>Dessutom, eftersom detta \u00e4r meddelandepaket som anl\u00e4nder inom en enda beg\u00e4ran, beh\u00f6vde vi ocks\u00e5 justera Graylog s\u00e5 att det skriver inte ofta och med sm\u00e5 batcher, utan stora batcher eller en g\u00e5ng var tredje sekund om batchen fortfarande inte \u00e4r full. I s\u00e5 fall blir informationen vi skriver till Elasticsearch tillg\u00e4nglig inte efter tv\u00e5 sekunder, utan efter fem (vilket vi \u00e4r helt okej med), men antalet retrys som vi m\u00e5ste g\u00f6ra f\u00f6r att trycka igenom en stor m\u00e4ngd information minskar.<\/p>\n<p><\/p>\n<p>Detta \u00e4r s\u00e4rskilt viktigt i de stunder n\u00e4r n\u00e5got ov\u00e4ntat h\u00e4nder och det rapporteras intensivt, s\u00e5 att vi inte f\u00e5r en helt spamad Elastic, utan efter en tid \u2014 en icke-fungerande Graylog-nod p\u00e5 grund av \u00f6verfulla buffertar.<\/p>\n<p><\/p>\n<p>Dessutom, n\u00e4r dessa explosioner intr\u00e4ffade i produktionen, fick vi klagom\u00e5l fr\u00e5n programmerare och testare: just n\u00e4r de verkligen beh\u00f6ver dessa loggar, ges de ut mycket l\u00e5ngsamt.<\/p>\n<p><\/p>\n<p>Vi b\u00f6rjade unders\u00f6ka. \u00c5 ena sidan var det tydligt att b\u00e5de s\u00f6kfr\u00e5gor och indexeringsfr\u00e5gor k\u00f6rdes i praktiken p\u00e5 samma fysiska maskiner, och p\u00e5 ett eller annat s\u00e4tt skulle det alltid bli vissa nedg\u00e5ngar. <\/p>\n<p><\/p>\n<p>Men detta kunde delvis undvikas genom att den sj\u00e4tte versionen av Elasticsearch introducerade en algoritm som g\u00f6r att man kan f\u00f6rdela f\u00f6rfr\u00e5gningar mellan relevanta datanoder inte p\u00e5 ett slumpm\u00e4ssigt round-robin-s\u00e4tt (containern som hanterar indexering och h\u00e5ller primary-shard kan vara mycket upptagen, och d\u00e4r blir det ingen m\u00f6jlighet att svara snabbt), utan att dirigera denna beg\u00e4ran till en mindre belastad container med replica-shard som svarar betydligt snabbare. Med andra ord kom vi fram till use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>Bild av l\u00e4sningen b\u00f6rjar se ut s\u00e5 h\u00e4r:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00d6verg\u00e5ngen till denna algoritm gjorde att vi m\u00e4rkbart f\u00f6rb\u00e4ttrade fr\u00e5ga tiden n\u00e4r vi hade en stor m\u00e4ngd loggar att skriva.<\/p>\n<p><\/p>\n<p>Till sist var det st\u00f6rsta problemet att sm\u00e4rtfritt ta bort datacentret.<\/p>\n<p><\/p>\n<p>Vad vi ville ha fr\u00e5n klustret omedelbart efter att ha f\u00f6rlorat kontakten med ett datacenter: <\/p>\n<p><\/p>\n<ul>\n<li>Om v\u00e5r nuvarande master befinner sig i det bortfallande datacentret, s\u00e5 kommer det att v\u00e4ljas om och flyttas som roll till en annan nod i ett annat datacenter.<\/li>\n<li>Mastern kommer snabbt att ta bort alla otillg\u00e4ngliga noder fr\u00e5n klustret.<\/li>\n<li>Baserat p\u00e5 de kvarst\u00e5ende kommer han att f\u00f6rst\u00e5: i det f\u00f6rlorade datacentret hade vi s\u00e5dana primary-shardar, snabbt kommer han att fr\u00e4mja komplement\u00e4ra replica-shardar i de kvarst\u00e5ende datacentren, och vi kommer att forts\u00e4tta indexera data. <\/li>\n<li>Som ett resultat av detta kommer vi att uppleva en gradvis nedg\u00e5ng i klusterets bandbredd f\u00f6r skrivning och l\u00e4sning, men generellt kommer allt att fungera, \u00e4ven om det \u00e4r sakta, s\u00e5 stabilt.<\/li>\n<\/ul>\n<p><\/p>\n<p>Som det visade sig ville vi ha n\u00e5got s\u00e5dant h\u00e4r:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Och fick f\u00f6ljande:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hur kom det sig? <\/p>\n<p><\/p>\n<p>Vid tiden f\u00f6r datacentrets nedg\u00e5ng blev v\u00e5r flaskhals m\u00e4staren.<\/p>\n<p><\/p>\n<p>Varf\u00f6r?<\/p>\n<p><\/p>\n<p>Det hela handlar om att det finns en TaskBatcher i m\u00e4staren som ansvarar f\u00f6r att sprida specifika uppgifter, h\u00e4ndelser i klustret. Varje nodutfall, varje uppgradering av shard fr\u00e5n replica till primary, varje uppgift f\u00f6r att skapa n\u00e5gon shard n\u00e5gonstans \u2013 allt detta hamnar f\u00f6rst i TaskBatcher, d\u00e4r det behandlas sekventiellt och i en enda str\u00f6m.<\/p>\n<p><\/p>\n<p>Vid utfallet av ett datacenter h\u00e4nde det att alla datakluster i de \u00f6verlevande datacentren tyckte att det var deras plikt att informera m\u00e4staren \"vi har f\u00f6rlorat s\u00e5dana shardar och s\u00e5dana datanoder\". <\/p>\n<p><\/p>\n<p>Samtidigt skickade de \u00f6verlevande datanoderna all denna information till den aktuella m\u00e4staren och f\u00f6rs\u00f6kte v\u00e4nta p\u00e5 bekr\u00e4ftelse p\u00e5 att han hade mottagit den. De v\u00e4ntade inte p\u00e5 detta, eftersom m\u00e4staren fick uppgifter snabbare \u00e4n han kunde svara. Noderna upprepade sina f\u00f6rfr\u00e5gningar efter en tidsgr\u00e4ns, och m\u00e4staren f\u00f6rs\u00f6kte inte ens svara p\u00e5 dem under tiden utan var helt f\u00f6rsjunken i uppgiften att sortera f\u00f6rfr\u00e5gningar efter prioritet.<\/p>\n<p><\/p>\n<p>I ett terminalt l\u00e4ge h\u00e4nde det att datanoder spamade m\u00e4staren s\u00e5 mycket att han gick in i full GC. Efter detta flyttades m\u00e4starens roll till n\u00e5gon n\u00e4sta nod, och samma sak h\u00e4nde med den, och i slut\u00e4ndan kollapsade klustret helt. <\/p>\n<p><\/p>\n<p>Vi gjorde m\u00e4tningar och fram till version 6.4.0, d\u00e4r detta blev fixat, var det tillr\u00e4ckligt f\u00f6r oss att ta ner endast 10 datanoder fr\u00e5n 360 f\u00f6r att helt krossa klustret.<\/p>\n<p><\/p>\n<p>Det s\u00e5g ungef\u00e4r ut s\u00e5 h\u00e4r:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster 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, d\u00e4r denna hemska bugg blev fixad, slutade datanoderna att d\u00f6da m\u00e4staren. Men han blev inte \"smartare\" av detta. Det vill s\u00e4ga: n\u00e4r vi tar ner 2, 3 eller 10 (vilket antal som helst som inte \u00e4r ett) datanoder f\u00e5r m\u00e4staren n\u00e5got f\u00f6rsta meddelande som s\u00e4ger att nod A har g\u00e5tt ner och f\u00f6rs\u00f6ker ber\u00e4tta om detta f\u00f6r nod B, nod C, nod D. <\/p>\n<p><\/p>\n<p>Och f\u00f6r tillf\u00e4llet kan man bara hantera detta genom att s\u00e4tta en timeout f\u00f6r att f\u00f6rs\u00f6ka ber\u00e4tta n\u00e5got f\u00f6r n\u00e5gon, som ligger p\u00e5 omkring 20-30 sekunder, och p\u00e5 s\u00e5 s\u00e4tt styra hastigheten f\u00f6r datacenterets uttr\u00e4de ur klustret.<\/p>\n<p><\/p>\n<p>I princip \u00f6verensst\u00e4mmer detta med de krav som ursprungligen st\u00e4lldes p\u00e5 den slutliga produkten inom projektet, men sett ur ett \"rent vetenskapligt\" perspektiv \u00e4r det en bugg. Som f\u00f6r \u00f6vrigt framg\u00e5ngsrikt \u00e5tg\u00e4rdades av utvecklarna i version 7.2.<\/p>\n<p><\/p>\n<p>Dessutom, n\u00e4r en viss datanod gick ur drift, visade det sig att sprida information om dess uttr\u00e4de var viktigare \u00e4n att informera hela klustret om att det fanns vissa primary-shard p\u00e5 den (f\u00f6r att kunna uppgradera replica-shard i ett annat datacenter till primary, och d\u00e4r kunna skriva information).<\/p>\n<p><\/p>\n<p>D\u00e4rf\u00f6r, n\u00e4r allt \"har tystnat\", markeras de uttr\u00e4dande datanoderna inte som stale omedelbart. F\u00f6ljaktligen tvingas vi v\u00e4nta p\u00e5 att alla pings till de uttr\u00e4dande datanoderna timeoutar, innan v\u00e5rt kluster b\u00f6rjar ber\u00e4tta att d\u00e4r, d\u00e4r och d\u00e4r beh\u00f6ver vi forts\u00e4tta skriva information. Mer detaljerat kan man l\u00e4sa om detta <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">h\u00e4r<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Resultatet \u00e4r att operationen f\u00f6r att ta ut datacentret idag tar omkring 5 minuter under rusningstid. F\u00f6r en s\u00e5 stor och otymplig maskin \u00e4r det ett ganska bra resultat.<\/p>\n<p><\/p>\n<p>Till slut kom vi fram till f\u00f6ljande l\u00f6sning:<\/p>\n<p><\/p>\n<ul>\n<li>Vi har 360 datanoder med diskar p\u00e5 700 gigabyte.<\/li>\n<li>60 koordinatorer f\u00f6r att styra trafiken mellan dessa datanoder.<\/li>\n<li>40 master, som vi har kvar som en slags arv fr\u00e5n versioner f\u00f6re 6.4.0 - f\u00f6r att \u00f6verleva uttr\u00e4det av datacentret var vi moraliskt beredda att f\u00f6rlora n\u00e5gra maskiner, f\u00f6r att garantera att vi \u00e4ven vid det s\u00e4msta scenariot skulle ha quorum bland mastrarna.<\/li>\n<li>Alla f\u00f6rs\u00f6k att kombinera roller p\u00e5 en och samma container har k\u00f6rt fast i att f\u00f6rr eller senare har noden brutit samman under belastning. <\/li>\n<li>I hela klustret anv\u00e4nds en heap.size p\u00e5 31 gigabyte: alla f\u00f6rs\u00f6k att minska storleken ledde till att tunga s\u00f6kf\u00f6rfr\u00e5gningar med leading wildcard antingen d\u00f6dade vissa noder eller att circuit breaker slog till i sj\u00e4lva Elasticsearch.<\/li>\n<li>Dessutom, f\u00f6r att s\u00e4kerst\u00e4lla s\u00f6kprestanda har vi f\u00f6rs\u00f6kt h\u00e5lla antalet objekt i klustret s\u00e5 l\u00e5gt som m\u00f6jligt, f\u00f6r att bearbeta s\u00e5 f\u00e5 h\u00e4ndelser som m\u00f6jligt p\u00e5 den mest tr\u00e5nga punkten, vilket vi hade i mastern.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Till sist om \u00f6vervakningen<\/h2>\n<p><\/p>\n<p>F\u00f6r att allt detta ska fungera som t\u00e4nkt \u00f6vervakar vi f\u00f6ljande:<\/p>\n<p><\/p>\n<ul>\n<li>Varje datanod rapporterar till v\u00e5r molntj\u00e4nst att den finns, och att den har dessa shardar. N\u00e4r vi st\u00e4nger ner n\u00e5got, rapporterar klustret efter 2-3 sekunder att i datacenter A har vi st\u00e4ngt ner nod 2, 3 och 4 - detta inneb\u00e4r att vi p\u00e5 inga villkor kan st\u00e4nga ner de noder i andra datacenter d\u00e4r det finns shardar i en enda kopia.<\/li>\n<li>Genom att k\u00e4nna till beteendet hos mastern ser vi noga p\u00e5 antalet v\u00e4ntande uppgifter. F\u00f6r \u00e4ven en enda h\u00e4ngande uppgift, om den inte timeoutas i tid, kan teoretiskt sett i en krissituation bli orsaken till att v\u00e5r promotering av en replica-shard till primary inte fungerar, vilket i sin tur stoppar indexeringen.<\/li>\n<li>Vi \u00f6vervakar \u00e4ven noggrant f\u00f6rdr\u00f6jningarna hos garbage collector, eftersom vi redan har haft stora problem med detta vid optimering.<\/li>\n<li>Rejektionsstatistik f\u00f6r tr\u00e5dar f\u00f6r att p\u00e5 f\u00f6rhand f\u00f6rst\u00e5 var \"flaskhalsen\" befinner sig.<\/li>\n<li>Och de vanliga m\u00e4tv\u00e4rdena, som heap, RAM och I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Vid byggandet av \u00f6vervakningen m\u00e5ste man ta h\u00e4nsyn till egenskaperna hos Thread Pool i Elasticsearch. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Elasticsearch-dokumentationen<\/a><\/noindex> beskriver m\u00f6jligheterna f\u00f6r anpassning och standardv\u00e4rden f\u00f6r s\u00f6kning och indexering, men n\u00e4mner helt och h\u00e5llet inte thread_pool.management. Dessa tr\u00e5dar hanterar bland annat f\u00f6rfr\u00e5gningar av typen _cat\/shards och andra liknande, som \u00e4r praktiska att anv\u00e4nda vid skrivandet av \u00f6vervakning. Ju st\u00f6rre klustret \u00e4r, desto fler s\u00e5dana f\u00f6rfr\u00e5gningar utf\u00f6rs per tidsenhet, och den n\u00e4mnda thread_pool.management \u00e4r inte bara inte representerad i den officiella dokumentationen, utan den \u00e4r ocks\u00e5 begr\u00e4nsad till 5 tr\u00e5dar som standard, vilket snabbt utnyttjas, vilket g\u00f6r att \u00f6vervakningen slutar att fungera korrekt.<\/p>\n<p><\/p>\n<p>Som en avslutning vill jag s\u00e4ga: vi lyckades! Vi har kunnat ge v\u00e5ra programutvecklare och utvecklare ett verktyg som n\u00e4stan i vilken situation som helst snabbt och p\u00e5litligt kan ge information om vad som h\u00e4nder i produktion.<\/p>\n<p><\/p>\n<p>Ja, det blev ganska komplext, men \u00e4nd\u00e5 lyckades vi f\u00e5 in v\u00e5ra krav i redan existerande produkter utan att beh\u00f6va patcha eller skriva om dem.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-kluster p\u00e5 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>K\u00e4lla: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/494260\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435. \u041d\u043e \u0447\u0442\u043e \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442, \u043a\u043e\u0433\u0434\u0430 \u0445\u043e\u0447\u0435\u0448\u044c \u0441 \u0435\u0433\u043e \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438 \u00ab\u0432 \u043e\u0441\u043e\u0431\u043e \u043a\u0440\u0443\u043f\u043d\u043e\u043c \u043e\u0431\u044a\u0451\u043c\u0435\u00bb? \u0414\u0430 \u0435\u0449\u0451 \u0438 \u0431\u0435\u0437\u0431\u043e\u043b\u0435\u0437\u043d\u0435\u043d\u043d\u043e \u043f\u0435\u0440\u0435\u0436\u0438\u0432\u0430\u0442\u044c \u043e\u0442\u043a\u0430\u0437 \u043b\u044e\u0431\u043e\u0433\u043e \u0438\u0437 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u043e\u0432? \u041a\u0430\u043a\u043e\u0439 \u0441\u0442\u043e\u0438\u0442 \u0434\u0435\u043b\u0430\u0442\u044c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443, \u0438 \u043d\u0430 \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0435 \u043a\u0430\u043c\u043d\u0438 \u043d\u0430\u0442\u043a\u043d\u0451\u0448\u044c\u0441\u044f? \u041c\u044b \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0440\u0435\u0448\u0438\u043b\u0438 \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 elasticsearch \u0440\u0435\u0448\u0438\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441 \u043b\u043e\u0433-\u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442\u0430, \u0430 \u0442\u0435\u043f\u0435\u0440\u044c \u0434\u0435\u043b\u0438\u043c\u0441\u044f \u0441 \u0425\u0430\u0431\u0440\u043e\u043c \u043e\u043f\u044b\u0442\u043e\u043c: \u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":75797,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-75796","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\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\/sv\/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-kluster p\u00e5 200 TB+ | ProHoster","description":"M\u00e5nga st\u00e4lls inf\u00f6r Elasticsearch.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}