{"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\/no\/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 m\u00f8ter Elasticsearch. Men hva skjer n\u00e5r man \u00f8nsker \u00e5 lagre logger \"i s\u00e6rdeles store mengder\" med hjelp av det? Og samtidig uten \u00e5 oppleve smertefulle avbrudd p\u00e5 grunn av nedetid i en av flere datasentre? Hvilken arkitektur b\u00f8r man velge, og hvilke skjulte fallgruver kan man st\u00f8te p\u00e5?<\/p>\n<p><\/p>\n<p>Vi i Odnoklassniki bestemte oss for \u00e5 l\u00f8se logg-h\u00e5ndteringsproblemet med Elasticsearch, og n\u00e5 deler vi erfaringene v\u00e5re med Habr: b\u00e5de om arkitekturen og om fallgruvene.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Eg er Peter Zaitsev, og arbeider som systemadministrator i Odnoklassniki. Tidligere var jeg ogs\u00e5 administrator, og jobbet med Manticore Search, Sphinx search, Elasticsearch. Kanskje, hvis det dukker opp noen annen ...search, vil jeg sannsynligvis ogs\u00e5 jobbe med den. Jeg deltar ogs\u00e5 i flere open source-prosjekter p\u00e5 frivillig basis.<\/p>\n<p><\/p>\n<p>Da jeg begynte i Odnoklassniki, sa jeg ubetenksomt i intervjuet at jeg kunne jobbe med Elasticsearch. Etter \u00e5 ha blitt kjent med det og gjort noen enkle oppgaver, fikk jeg tildelt en stor oppgave med \u00e5 reformere logg-h\u00e5ndteringssystemet som eksisterte p\u00e5 det tidspunktet. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Krav<\/h2>\n<p><\/p>\n<p>Kravene til systemet ble formulert som f\u00f8lger:<\/p>\n<p><\/p>\n<ul>\n<li>Som frontend skulle Graylog brukes. Fordi selskapet allerede hadde erfaring med dette produktet, var b\u00e5de programmerere og testere kjent med det, og de syntes det var komfortabelt \u00e5 bruke.<\/li>\n<li>Datamengden: i gjennomsnitt 50-80 tusen meldinger per sekund, men hvis noe g\u00e5r galt, s\u00e5 er trafikken uten begrensning, og det kan v\u00e6re 2-3 millioner linjer per sekund.<\/li>\n<li>Etter \u00e5 ha diskutert med kundene kravene til hastigheten ved behandling av s\u00f8kesp\u00f8rsm\u00e5l, forsto vi at den typiske bruken av et slikt system er slik at folk s\u00f8ker logger fra applikasjonen sin de siste to dagene og ikke \u00f8nsker \u00e5 vente lenger enn ett sekund p\u00e5 resultatet av foresp\u00f8rselen. <\/li>\n<li>Administratorene insisterte p\u00e5 at systemet lett skulle kunne skaleres ved behov, uten \u00e5 kreve at de m\u00e5tte sette seg grundig inn i hvordan det var bygget opp. <\/li>\n<li>Den eneste oppgaven med vedlikehold som disse systemene trengte fra tid til annen var \u00e5 bytte ut noe maskinvare.<\/li>\n<li>I tillegg har Odnoklassniki en flott teknisk tradisjon: enhver tjeneste vi lanserer, m\u00e5 kunne h\u00e5ndtere et datasenter-nedbrudd (uventet, up\u00e5lagt og til enhver tid).<\/li>\n<\/ul>\n<p><\/p>\n<p>Det siste kravet i gjennomf\u00f8ringen av dette prosjektet har kostet oss mest, noe jeg vil fortelle mer om senere.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Milj\u00f8<\/h2>\n<p><\/p>\n<p>Vi jobber med fire datasentre, men Elasticsearch-nodene kan kun plasseres i tre (av en rekke ikke-tekniske grunner).<\/p>\n<p><\/p>\n<p>I disse fire datasentrene finnes det omtrent 18 000 ulike loggkilder \u2014 maskinvare, containere, virtuelle maskiner.<\/p>\n<p><\/p>\n<p>En viktig funksjon: klustret 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\/\">v\u00e5rt eget skyprodukt one-cloud<\/a><\/noindex>. Containerne garanteres 2 kjerner, tilsvarende 2.0Ghz v4 med mulighet for utnyttelse av de \u00f8vrige kjernene i tilfelle de er inaktive. <\/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 overordnede l\u00f8sningen s\u00e5 jeg i utgangspunktet slik ut:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP-er st\u00e5r bak A-posten til domenet Graylog, det er adressen som loggene sendes til.<\/li>\n<li>hver VIP fungerer som en LVS-balancer.<\/li>\n<li>Etter det blir loggene sendt til en Graylog-batteri, hvorav en del data g\u00e5r i GELF-format, og en del i syslog-format.<\/li>\n<li>Deretter skrives alt dette i store batcher til en gruppe med Elasticsearch-koordinatorer. <\/li>\n<li>Og de sender foresp\u00f8rslene om skriving og lesing til 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>Kanskje ikke alle har kjennskap til terminologien, derfor vil jeg gjerne stoppe litt opp ved den.<\/p>\n<p><\/p>\n<p>I Elasticsearch finnes det flere typer noder \u2014 master, koordinator, datanode. Det er ogs\u00e5 to andre typer for ulike konverteringer av logger og kommunikasjon mellom forskjellige klynger, men vi brukte kun de nevnte. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPinger alle nodene som er tilstede i klyngen, opprettholder et oppdatert kart over klyngen og sprer det mellom nodene, behandler hendelseslogikk, driver med diverse cluster wide housekeeping. <\/p>\n<p><\/p>\n<p><strong>Koordinator<\/strong><br \/>\nUtf\u00f8rer en eneste oppgave: tar imot foresp\u00f8rselene fra klientene for lesing eller skriving og ruter denne trafikken. N\u00e5r det er en skrivingsforesp\u00f8rsel, vil den sannsynligvis sp\u00f8rre master hvilken shard i den relevante indeksen den skal legge dette til, og videresende foresp\u00f8rselen videre. <\/p>\n<p><\/p>\n<p><strong>Datanode<\/strong><br \/>\nLagrer data, utf\u00f8rer s\u00f8kebegj\u00e6ringer og operasjoner p\u00e5 sharder som er plassert p\u00e5 den.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nDette er noe som ligner en sammensmelting av Kibana med Logstash i ELK-stakken. Graylog kombinerer b\u00e5de UI og loggbehandlingspipeline. Bak kulissene i Graylog fungerer Kafka og Zookeeper, som sikrer tilkoblingen av Graylog som en klynge. Graylog kan cache logger (Kafka) i tilfelle Elasticsearch ikke er tilgjengelig og gjenta mislykkede lese- og skriveforesp\u00f8rselene, gruppere og merke loggene etter angitte regler. Som Logstash har Graylog funksjonalitet for \u00e5 modifisere strenger f\u00f8r de skrives til Elasticsearch.<\/p>\n<p><\/p>\n<p>I tillegg har Graylog innebygd service discovery, som lar deg hente hele klyngeoversikten basert p\u00e5 en tilgjengelig Elasticsearch-node, og filtrere den etter et bestemt tag, noe som gir mulighet for \u00e5 sende foresp\u00f8rselene til bestemte containere.<\/p>\n<p><\/p>\n<p>Visuelt ser det omtrent slik ut:<\/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 skjermbilde fra en spesifikk instans. Her bygger vi et histogram basert p\u00e5 s\u00f8kesp\u00f8rsm\u00e5let og viser relevante linjer.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indexes<\/h2>\n<p><\/p>\n<p>N\u00e5r vi g\u00e5r tilbake til systemarkitekturen, vil jeg gjerne g\u00e5 n\u00e6rmere inn p\u00e5 hvordan vi bygde modellene for indekser for at alt skulle fungere riktig. <\/p>\n<p><\/p>\n<p>I det tidligere diagrammet er dette det laveste niv\u00e5et: Elasticsearch data noder.<\/p>\n<p><\/p>\n<p>En indeks er en stor virtuell enhet best\u00e5ende av Elasticsearch-shards. Hver av shardene i seg selv er intet annet enn en Lucene-indeks. Og hver Lucene-indeks best\u00e5r igjen av ett 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 prosjektplanleggingen antok vi at for \u00e5 tilfredsstille lesehastighetskravene ved store datamengder m\u00e5tte vi jevnt 'fordele' disse dataene over datanodene. <\/p>\n<p><\/p>\n<p>Dette resulterte i at antallet shards per indeks (med replikasjoner) m\u00e5tte v\u00e6re n\u00f8yaktig likt antallet datanoder. For det f\u00f8rste for \u00e5 oppn\u00e5 en replikasjonsfaktor p\u00e5 to (det vil si at vi kan miste halvparten av klyngen). Og for det andre for \u00e5 kunne behandle lese- og skriveforesp\u00f8rslene p\u00e5 minst halvparten av klyngen.<\/p>\n<p><\/p>\n<p>Vi bestemte f\u00f8rst lagringstiden til 30 dager.<\/p>\n<p><\/p>\n<p>Fordelingen av shards kan grafisk presenteres som f\u00f8lger:<\/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>Den m\u00f8rkegr\u00e5 rektangelen i sin helhet er indeksen. Den venstre r\u00f8de kvadraten i den er primary-sharden, den f\u00f8rste i indeksen. Den bl\u00e5 kvadraten er replica-sharden. De befinner seg i forskjellige datasentre.<\/p>\n<p><\/p>\n<p>N\u00e5r vi legger til en ny shard, g\u00e5r den til det tredje datasenteret. Til slutt f\u00e5r vi en struktur som gj\u00f8r det mulig \u00e5 miste et datasenter uten \u00e5 miste 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 satt rotasjonen av indekser, det vil si \u00e5 opprette en ny indeks og fjerne den eldste, til 48 timer (basert p\u00e5 bruken av indeksen: de siste 48 timene blir s\u00f8kt oftest).<\/p>\n<p><\/p>\n<p>Dette rotasjonsintervallet for indekser er knyttet til f\u00f8lgende \u00e5rsaker:<\/p>\n<p><\/p>\n<p>N\u00e5r en spesifikk datanode mottar en s\u00f8keforesp\u00f8rsel, er det mer gunstig med ytelse \u00e5 sp\u00f8rre en shard, hvis st\u00f8rrelsen er sammenlignbar med st\u00f8rrelsen p\u00e5 nodens heap. Dette gj\u00f8r at vi kan holde den \u2018hvite\u2019 delen av indeksen i heapen og raskt f\u00e5 tilgang til den. N\u00e5r det blir flere \u2018hvite deler\u2019, reduseres hastigheten p\u00e5 s\u00f8ket i indeksen.<\/p>\n<p><\/p>\n<p>N\u00e5r en node begynner \u00e5 utf\u00f8re en s\u00f8keforesp\u00f8rsel p\u00e5 en shard, tilordner den antall tr\u00e5der lik antall hypertr\u00e5dede kjerner p\u00e5 den fysiske maskinen. Hvis s\u00f8keforesp\u00f8rselen ber\u00f8rer et stort antall shards, \u00f8ker antallet tr\u00e5der proporsjonalt. Dette p\u00e5virker s\u00f8kehastigheten negativt og har en d\u00e5rlig effekt p\u00e5 indeksering av nye data. <\/p>\n<p><\/p>\n<p>For \u00e5 sikre n\u00f8dvendig s\u00f8k latenstid, bestemte vi oss for \u00e5 bruke SSD. For rask behandling av foresp\u00f8rslene, m\u00e5tte maskinene som kj\u00f8rte disse containerne ha minst 56 kjerner. Tallet 56 ble valgt som en betinget tilstrekkelig mengde, som definerer antallet tr\u00e5der som Elasticsearch vil generere i l\u00f8pet av drift. I Elasticsearch avhenger mange parametre for thread pool direkte av antallet tilgjengelige kjerner, noe som igjen direkte p\u00e5virker det n\u00f8dvendige antallet noder i klyngen etter prinsippet 'fewer cores \u2014 more nodes'. <\/p>\n<p><\/p>\n<p>Vi endte opp med at gjennomsnittlig veier en shard omtrent 20 gigabyte, og det er 360 shards per indeks. Dermed, hvis vi roterer dem hver 48. time, har vi 15 av dem. Hver indeks inneholder data for 2 dager.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Skrive- og leseordninger for data<\/h2>\n<p><\/p>\n<p>La oss se n\u00e6rmere p\u00e5 hvordan data skrives i dette systemet.<\/p>\n<p><\/p>\n<p>La oss si at vi mottar en foresp\u00f8rsel fra Graylog til koordinatoren. For eksempel, vi \u00f8nsker \u00e5 indeksere 2-3 tusen linjer. <\/p>\n<p><\/p>\n<p>Koordinatoren, etter \u00e5 ha mottatt en foresp\u00f8rsel fra Graylog, sp\u00f8r masteren: \u00abI foresp\u00f8rselen om indeksering var vi spesifikt angitt en indeks, men i hvilken shard dette skulle skrives \u2013 var ikke angitt\u00bb. <\/p>\n<p><\/p>\n<p>Masteren svarer: \u00abSkriv denne informasjonen i shard nummer 71\u00bb, deretter sendes den direkte til den relevante datanoden, hvor prim\u00e6r-shard nummer 71 befinner seg.<\/p>\n<p><\/p>\n<p>Deretter blir transaksjonsloggen replikert til replica-shard, som allerede ligger i et annet datasenter.<\/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 kommer en s\u00f8kforesp\u00f8rsel til koordinatoren. Koordinatoren videresender den etter indeksen, mens Elasticsearch, etter prinsippet om round-robin, fordeler foresp\u00f8rslene mellom prim\u00e6r-shard og replica-shard. <\/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>Nodene, som er 180 i antall, svarer ujevnt, og mens de svarer, samler koordinatoren informasjonen som allerede er \u00abspyttet ut\u00bb av raskere datanoder. N\u00e5r enten all informasjon er kommet, eller foresp\u00f8rselen har n\u00e5dd tidsgrensen, gir den alt direkte til klienten. <\/p>\n<p><\/p>\n<p>Hele dette systemet behandler i gjennomsnitt s\u00f8kforesp\u00f8rslene for de siste 48 timene p\u00e5 300-400ms, unntatt de foresp\u00f8rslene som har ledende wildcard.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\u00abSm\u00e5 detaljer\u00bb med Elasticsearch: Java-konfigurasjon<\/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 skulle fungere slik vi opprinnelig \u00f8nsket, brukte vi mye tid p\u00e5 \u00e5 finjustere forskjellige saker i klyngen. <\/p>\n<p><\/p>\n<p>Den f\u00f8rste delen av de oppdagede problemene var relatert til hvordan Java er forh\u00e5ndsinnstilt i Elasticsearch som standard. <\/p>\n<p><\/p>\n<p><strong>Problem \u00e9n<\/strong><br \/>\nVi observerte et sv\u00e6rt stort antall meldinger om at vi p\u00e5 niv\u00e5et Lucene, n\u00e5r bakgrunnsjobbene kj\u00f8rer, at sammensl\u00e5ingen av Lucene-segmenter avsluttes med en feil. I loggene var det synlig at dette var en OutOfMemoryError-feil. Gjennom telemetri s\u00e5 vi at heapen var frigjort, og det var ikke klart hvorfor denne operasjonen feilet. <\/p>\n<p><\/p>\n<p>Det viste seg at fusjoner av Lucene-indekser skjer utenfor heap-en. Containerne har ganske strenge begrensninger p\u00e5 forbrukte ressurser. Bare heap-en var innenfor disse ressursene (heap.size-verdien var omtrent lik RAM), og noen off-heap-operasjoner feilet med minneallokeringsfeil hvis de av en eller annen grunn ikke ble utf\u00f8rt innenfor de ~500MB som var igjen til grensen.<\/p>\n<p><\/p>\n<p>L\u00f8sningen var ganske triviale: vi \u00f8kte RAM-omfanget tilgjengelig for containeren, hvoretter vi glemte at slike problemer noensinne hadde oppst\u00e5tt.<\/p>\n<p><\/p>\n<p><strong>Det andre problemet<\/strong><br \/>\nOmtrent 4-5 dager etter oppstart av klyngen la vi merke til at datanodene begynte \u00e5 falle ut av klyngen periodisk og kom tilbake etter ca. 10-20 sekunder. <\/p>\n<p><\/p>\n<p>Da vi begynte \u00e5 unders\u00f8ke, fant vi ut at denne s\u00e5kalte off-heap minnet i Elasticsearch nesten ikke blir kontrollert i det hele tatt. N\u00e5r vi ga containeren mer minne, fikk vi muligheten til \u00e5 fylle direkte buffer-pooler med ulik informasjon, og det ble ryddet opp f\u00f8rst etter at explicit GC fra Elasticsearch ble kj\u00f8rt. <\/p>\n<p><\/p>\n<p>I noen tilfeller tok dette operasjonen en ganske lang tid, og i l\u00f8pet av den tiden klarte klustret \u00e5 merke denne noden som allerede ute av drift. Dette problemet er godt dokumentert. <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 begrenset Java sin mulighet til \u00e5 bruke hoveddelen av minnet utenfor heap til disse operasjonene. Vi satte en grense p\u00e5 16 gigabyte (-XX:MaxDirectMemorySize=16g), som resulterte i at explicit GC ble kalt betydelig oftere og kj\u00f8rte mye raskere, noe som igjen stabiliserte klustret.<\/p>\n<p><\/p>\n<p><strong>Det tredje problemet.<\/strong><br \/>\nHvis du tror at problemene med \u00abnoder som forlater klustret p\u00e5 de mest uventede tidspunktene\u00bb er over, tar du feil. <\/p>\n<p><\/p>\n<p>N\u00e5r vi konfigurerte arbeidet med indekser, valgte vi mmapfs for \u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">forkorte s\u00f8ketiden<\/a><\/noindex> etter ferske shards med h\u00f8y segmentering. Dette var en ganske grov feil, fordi ved bruk av mmapfs blir filen mappet inn i RAM, og deretter jobber vi med den mappede filen. Dette resulterte i at n\u00e5r GC fors\u00f8k \u00e5 stoppe tr\u00e5dene i applikasjonen, tok det veldig lang tid f\u00f8r vi kom til safepoint, og p\u00e5 veien dit slutter applikasjonen \u00e5 svare p\u00e5 masterens foresp\u00f8rsel om den fortsatt er aktiv. Dermed mener masteren at noden ikke lenger er tilstede i klustret. Etter fem til ti sekunder utf\u00f8res garbage collector, noden kommer tilbake, g\u00e5r inn igjen i klustret og begynner \u00e5 initialisere shards. Alt dette minnet sterkt om \u201cproduksjonen vi fortjente\u201d og var ikke egnet for noe seri\u00f8st.<\/p>\n<p><\/p>\n<p>For \u00e5 bli kvitt denne oppf\u00f8rselen, gikk vi f\u00f8rst over til standard niofs, og etter at vi hadde migrert fra femte til sjette versjon av Elastic, pr\u00f8vde vi hybridfs, hvor dette problemet ikke forekom. Du kan lese mer om lagringstyper. <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>Det fjerde problemet.<\/strong><br \/>\nDeretter var det et annet veldig interessant problem som vi brukte rekordlang tid p\u00e5 \u00e5 l\u00f8se. Vi jaktet p\u00e5 det i 2-3 m\u00e5neder, fordi m\u00f8nsteret var helt uforst\u00e5elig. <\/p>\n<p><\/p>\n<p>Noen ganger gikk koordinatorene v\u00e5re i Full GC, vanligvis etter lunsj, og kom aldri tilbake. P\u00e5 logsynkronisering av GC s\u00e5 det slik ut: alt g\u00e5r bra, bra, bra, s\u00e5 plutselig \u2014 alt ble d\u00e5rlig. <\/p>\n<p><\/p>\n<p>F\u00f8rst trodde vi at vi hadde en ond bruker som kj\u00f8rte en foresp\u00f8rsel som fikk koordinatoren til \u00e5 g\u00e5 ut av arbeidsmodus. Vi logget foresp\u00f8rslene lenge i et fors\u00f8k p\u00e5 \u00e5 finne ut hva som skjedde. <\/p>\n<p><\/p>\n<p>Det viste seg at n\u00e5r en bruker kj\u00f8rer en stor foresp\u00f8rsel, og den treffer en spesifikk Elasticsearch-koordinator, responderer noen noder tregere enn de andre. <\/p>\n<p><\/p>\n<p>Mens koordinatoren venter p\u00e5 svar fra alle nodene, akkumulerer den resultatene fra nodene som har svart. For GC betyr dette at bruksm\u00f8nsteret for heapen endrer seg raskt. Den GC-en vi brukte klarte ikke \u00e5 h\u00e5ndtere denne oppgaven. <\/p>\n<p><\/p>\n<p>Den eneste l\u00f8sningen vi fant for \u00e5 endre atferden til klyngen i en slik situasjon, var \u00e5 migrere til JDK13 og bruke s\u00f8ppelsamleren Shenandoah. Dette l\u00f8ste problemet, og koordinatorene v\u00e5re sluttet \u00e5 falle. <\/p>\n<p><\/p>\n<p>Her sluttet problemene med Java, og problemene med b\u00e5ndbredde begynte. <\/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 betyr at klyngen v\u00e5r fungerer stabilt, men at ytelsen er utilstrekkelig under topptider for indekserte dokumenter og ved man\u00f8vrering.<\/p>\n<p><\/p>\n<p>Det f\u00f8rste symptomet vi oppdaget: under visse \u00abeksplosjoner\u00bb i produksjon, n\u00e5r et stort antall logger genereres raskt, begynte Graylog \u00e5 vise feilmeldinger for indeksering es_rejected_execution. <\/p>\n<p><\/p>\n<p>Dette skjedde fordi thread_pool.write.queue p\u00e5 en datanode, f\u00f8r Elasticsearch f\u00e5r behandlet foresp\u00f8rselen om indeksering og sendt informasjon til shard p\u00e5 disk, kun kan cache 200 foresp\u00f8rslene som standard. Og <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">i dokumentasjonen for Elasticsearch<\/a><\/noindex> legges det lite vekt p\u00e5 denne parameteren. Det nevnes bare maks antall tr\u00e5der og standardst\u00f8rrelse.<\/p>\n<p><\/p>\n<p>Selvf\u00f8lgelig begynte vi \u00e5 justere denne verdien og fant ut f\u00f8lgende: spesielt i v\u00e5r oppsett kan det caches opp til 300 foresp\u00f8rseler ganske bra, mens h\u00f8yere verdier f\u00f8rer til at vi havner tilbake i Full GC.<\/p>\n<p><\/p>\n<p>I tillegg, ettersom dette er meldingsseksjoner som kommer innenfor \u00e9n foresp\u00f8rsel, m\u00e5tte Graylog ogs\u00e5 justeres slik at det ikke skrev ofte og i sm\u00e5 batcher, men i store batcher eller hvert 3. sekund, hvis batchen fortsatt ikke er full. I s\u00e5 fall blir informasjonen vi skriver i Elasticsearch tilgjengelig ikke etter to sekunder, men etter fem (som er helt akseptabelt for oss), men antallet retriever som m\u00e5 gj\u00f8res for \u00e5 presse gjennom en stor mengde informasjon reduseres.<\/p>\n<p><\/p>\n<p>Dette er s\u00e6rlig viktig n\u00e5r noe g\u00e5r galt og rapporterer frustrert, slik at vi ikke f\u00e5r en helt spammende Elastic, og etter en stund \u2014 ikke-fungerende Graylog-noder p\u00e5 grunn av fulle buffere.<\/p>\n<p><\/p>\n<p>I tillegg, n\u00e5r vi hadde disse eksplosjonene i produksjonen, fikk vi klager fra programmerere og testere: i det \u00f8yeblikket de virkelig trenger disse loggene, blir de levert til dem veldig sakte.<\/p>\n<p><\/p>\n<p>Vi begynte \u00e5 unders\u00f8ke. P\u00e5 den ene siden var det klart at b\u00e5de s\u00f8keforesp\u00f8rslene og foresp\u00f8rslene om indeksering egentlig kj\u00f8rte p\u00e5 de samme fysiske maskinene, og p\u00e5 en eller annen m\u00e5te ville det helt klart v\u00e6re visse nedganger. <\/p>\n<p><\/p>\n<p>Men dette kunne delvis omg\u00e5s ved at det i versjon seks av Elasticsearch kom en algoritme som tillater \u00e5 fordele foresp\u00f8rslene mellom relevante datanoder ikke p\u00e5 tilfeldig round-robin-prinsipp (containeren som tar seg av indeksering og holder primary-shard, kan v\u00e6re veldig opptatt, og der vil det ikke v\u00e6re mulighet for \u00e5 svare raskt), men \u00e5 sende denne foresp\u00f8rselen til en mindre belastet container med replica-shard, som vil svare mye raskere. Med andre ord, vi kom frem til use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>Bildet av lesingen begynner \u00e5 se slik ut:<\/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 algoritmen tillot en betydelig forbedring av sp\u00f8rringstiden i de \u00f8yeblikkene vi hadde en stor str\u00f8m av logger inn.<\/p>\n<p><\/p>\n<p>Til slutt var hovedproblemet \u00e5 trekke ut datasenteret uten komplikasjoner.<\/p>\n<p><\/p>\n<p>Hva vi \u00f8nsket fra klyngen umiddelbart etter tap av kontakt med ett DC: <\/p>\n<p><\/p>\n<ul>\n<li>Hvis v\u00e5r n\u00e5v\u00e6rende master befinner seg i det avkoblede datasenteret, vil det bli valgt p\u00e5 nytt og flytte rollen til en annen node i et annet DC.<\/li>\n<li>Masteren vil raskt kaste ut alle utilgjengelige noder fra klyngen.<\/li>\n<li>Basert p\u00e5 de gjenv\u00e6rende vil han forst\u00e5: i det tapte datasenteret hadde vi slike primary-sharder, han vil raskt promotere komplement\u00e6re replica-sharder i de gjenv\u00e6rende datasentrene, og v\u00e5r datainndeksering vil fortsette. <\/li>\n<li>Som et resultat av dette vil b\u00e5ndbredden til klyngen for skriving og lesing gradvis avta, men generelt vil alt fungere selv om det g\u00e5r sakte, men stabilt.<\/li>\n<\/ul>\n<p><\/p>\n<p>Som det viste seg, \u00f8nsket vi noe slikt:<\/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>Og vi fikk 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 gikk dette til? <\/p>\n<p><\/p>\n<p>I \u00f8yeblikket av datasenterets fall ble mesteren v\u00e5rt flaskehals.<\/p>\n<p><\/p>\n<p>Why?<\/p>\n<p><\/p>\n<p>Saken er at det i mesteren er en TaskBatcher, som ansvarlig for distribusjonen av bestemte oppgaver og hendelser i klyngen. Ethvert utfall av en node, enhver promovering av en sharde fra replica til primary, enhver oppgave for \u00e5 opprette en sharde et sted \u2014 alt dette g\u00e5r f\u00f8rst inn i TaskBatcher, hvor det behandles sekvensielt og i \u00e9n tr\u00e5d.<\/p>\n<p><\/p>\n<p>I \u00f8yeblikket av utgangen av et datasenter skjedde det at alle datanoder i de overlevende datasentrene f\u00f8lte det som sin plikt \u00e5 informere mesteren \"vi har mistet slike shard og slike datanoder\". <\/p>\n<p><\/p>\n<p>Samtidig sendte de overlevende datanodene all denne informasjonen til den n\u00e5v\u00e6rende mesteren og pr\u00f8vde \u00e5 vente p\u00e5 bekreftelse p\u00e5 at han hadde mottatt den. De ventet ikke p\u00e5 dette, da mesteren mottok oppgaver raskere enn han klarte \u00e5 svare. Noder gjentok foresp\u00f8rslene p\u00e5 timeout, mens mesteren i mellomtiden ikke engang pr\u00f8vde \u00e5 svare dem, men var helt oppslukt av oppgaven med \u00e5 sortere foresp\u00f8rslene etter prioritet.<\/p>\n<p><\/p>\n<p>I terminal form ble det slik at datanodene spammet mesteren til det punktet at han gikk inn i full GC. Etter dette ble rollen som mester overf\u00f8rt til en eller annen neste node, og det skjedde akkurat det samme med den, og til slutt kollapset klyngen helt. <\/p>\n<p><\/p>\n<p>Vi utf\u00f8rte m\u00e5linger, og f\u00f8r versjon 6.4.0, hvor dette ble fikset, var det tilstrekkelig \u00e5 ta ut bare 10 datanoder samtidig fra 360 for \u00e5 helt legge klyngen ned.<\/p>\n<p><\/p>\n<p>Det s\u00e5 omtrent slik ut:<\/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>Etter versjon 6.4.0, hvor denne skumle feilen ble fikset, sluttet datanodene \u00e5 drepe mesteren. Men han ble ikke \"smartere\" av den grunn. Nemlig: n\u00e5r vi tar ut 2, 3 eller 10 (hvilket som helst antall annet enn \u00e9n) datanoder, f\u00e5r mesteren et eller annet f\u00f8rste meldingen som forteller at node A har falt ut, og pr\u00f8ver \u00e5 fortelle dette til node B, node C, node D. <\/p>\n<p><\/p>\n<p>Og for \u00f8yeblikket kan dette bare tackles ved \u00e5 sette en tidsavbrudd p\u00e5 fors\u00f8kene om \u00e5 informere noen om noe, lik et sted rundt 20-30 sekunder, og dermed styre hastigheten p\u00e5 datasenterets utgang fra klustret.<\/p>\n<p><\/p>\n<p>I prinsippet passer dette inn i de kravene som opprinnelig ble stilt til det endelige produktet i prosjektets rammeverk, men i lys av \u00abren vitenskap\u00bb er dette en feil. En feil som forresten ble vellykket fikset av utviklerne i versjon 7.2.<\/p>\n<p><\/p>\n<p>Dessuten, n\u00e5r en datanode gikk ut, viste det seg at det var viktigere \u00e5 spre informasjonen om dens utgang enn \u00e5 informere hele klustret om at den hadde slike primary-shard (for \u00e5 promotere replica-shard i et annet datasenter til primary, slik at det kunne skrives informasjon).<\/p>\n<p><\/p>\n<p>Derfor, n\u00e5r alt \u00abhar roet seg\u00bb, markeres ikke de utg\u00e5tte datanodene som stale umiddelbart. Dermed m\u00e5 vi vente til alle pingene til de utg\u00e5tte datanodene har timed out, og f\u00f8rst deretter begynner klustret \u00e5 informere om at der og der m\u00e5 skrivingen av informasjon fortsette. Du kan lese mer om dette. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">her<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Som et resultat tar operasjonen \u00e5 trekke datasenteret v\u00e5rt i dag omtrent 5 minutter i rushtiden. For en s\u00e5 stor og treg maskin er det et ganske godt resultat.<\/p>\n<p><\/p>\n<p>Som et resultat kom vi til f\u00f8lgende l\u00f8sning:<\/p>\n<p><\/p>\n<ul>\n<li>Vi har 360 datanoder med disker p\u00e5 700 gigabyte.<\/li>\n<li>60 koordinatorer for ruting av trafikk mellom disse datanodene.<\/li>\n<li>40 mastere, som vi har igjen som et slags arv fra tidene f\u00f8r versjon 6.4.0 \u2014 for \u00e5 overleve trekkingen av datasenteret var vi moralsk forberedt p\u00e5 \u00e5 miste noen maskiner, for \u00e5 garantere at vi, selv i det d\u00e5rligste scenarioet, hadde kvorum av mastere.<\/li>\n<li>Enhver fors\u00f8kt kombinasjon av roller i en container st\u00f8ttet p\u00e5 at noden til slutt ville feile under belastning. <\/li>\n<li>Hele klustret bruker en heap.size p\u00e5 31 gigabyte: alle fors\u00f8k p\u00e5 \u00e5 redusere st\u00f8rrelsen f\u00f8rte til at tunge s\u00f8kesp\u00f8rsm\u00e5l med leading wildcard enten drepte noen noder, eller aktivere circuit breaker i Elasticsearch selv.<\/li>\n<li>I tillegg, for \u00e5 sikre s\u00f8keytelse, pr\u00f8vde vi \u00e5 holde antallet objekter i klustret s\u00e5 lavt som mulig, for \u00e5 behandle s\u00e5 f\u00e5 hendelser som mulig i det trange punktet vi hadde i masteren.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Til slutt om overv\u00e5kning<\/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 take down something somewhere, the cluster reports within 2-3 seconds that in data center A we have taken down nodes 2, 3, and 4 \u2014 this means that in other data centers, we absolutely cannot take down those nodes that still have shards in a single instance.<\/li>\n<li>Understanding the master's behavior, we pay close attention to the number of pending tasks. Because even one stuck task, if not timed out promptly, could theoretically be the reason we can't, for instance, promote a replica shard to primary, causing indexing to stop.<\/li>\n<li>We also closely monitor garbage collector delays, as we have already faced significant challenges with this during optimization.<\/li>\n<li>Rejections by threads, to understand in advance where the 'bottleneck' is.<\/li>\n<li>And the standard metrics, like heap, RAM, and I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>When building monitoring, it is essential to consider the peculiarities 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 capabilities and default values for searching, indexing, but completely omits thread_pool.management. These threads handle, among other things, requests like _cat\/shards and other similar ones that are convenient for writing monitoring. The larger the cluster, the more of these requests are executed in a given time, and the aforementioned thread_pool.management is not only absent from the official documentation, but it is also limited by default to 5 threads, which can be quickly utilized, after which monitoring ceases to function correctly.<\/p>\n<p><\/p>\n<p>In conclusion, I want to say: 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 quite complex, but nevertheless, we were able to fit our wishes into existing products, which did not need to be patched or rewritten for ourselves.<\/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\/no\/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=\"nn_NO\" \/>\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\/no\/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 cluster over 200 TB+ | ProHoster","description":"Many face Elasticsearch.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}