{"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\/pt\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Cluster Elasticsearch de 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Muitos se deparam com o Elasticsearch. Mas o que acontece quando voc\u00ea quer us\u00e1-lo para armazenar logs em \"grande volume\"? E como sobreviver sem dor a falhas em qualquer um dos v\u00e1rios data centers? Como deve ser a arquitetura e quais armadilhas voc\u00ea pode encontrar?<\/p>\n<p><\/p>\n<p>N\u00f3s, do Odnoklassniki, decidimos resolver a quest\u00e3o da gest\u00e3o de logs com o Elasticsearch e agora compartilhamos nossa experi\u00eancia com o Habr: tanto sobre a arquitetura quanto sobre as armadilhas.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Eu sou Petr Zaitsev, trabalho como administrador de sistemas no Odnoklassniki. Antes tamb\u00e9m fui administrador, trabalhei com Manticore Search, Sphinx Search, Elasticsearch. Se surgir mais algum tipo de search, provavelmente tamb\u00e9m vou trabalhar com ele. Tamb\u00e9m participo de v\u00e1rios projetos de c\u00f3digo aberto de forma volunt\u00e1ria.<\/p>\n<p><\/p>\n<p>Quando entrei para o Odnoklassniki, eu imprudentemente disse na entrevista que sabia trabalhar com Elasticsearch. Depois que me familiarizei e fiz algumas tarefas simples, me deram uma grande tarefa de reformula\u00e7\u00e3o do sistema de gest\u00e3o de logs existente at\u00e9 aquele momento. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Requisitos<\/h2>\n<p><\/p>\n<p>Os requisitos do sistema foram formulados da seguinte forma:<\/p>\n<p><\/p>\n<ul>\n<li>Como frontend, deveria ser utilizado o Graylog. Porque a empresa j\u00e1 tinha experi\u00eancia com esse produto, os programadores e testadores j\u00e1 o conheciam e achavam conveniente.<\/li>\n<li>Volume de dados: em m\u00e9dia, de 50 a 80 mil mensagens por segundo, mas se algo der errado, o tr\u00e1fego n\u00e3o tem limites, isso pode ser de 2 a 3 milh\u00f5es de linhas por segundo.<\/li>\n<li>Depois de discutir com os clientes os requisitos de velocidade de processamento de consultas, percebemos que o padr\u00e3o t\u00edpico de uso de um sistema assim \u00e9 que as pessoas procuram logs de sua aplica\u00e7\u00e3o dos \u00faltimos dois dias e n\u00e3o querem esperar mais de um segundo para os resultados de sua consulta. <\/li>\n<li>Os administradores insistiram que o sistema deveria facilmente escalar, se necess\u00e1rio, sem exigir que eles aprofundassem no funcionamento interno. <\/li>\n<li>Para que a \u00fanica tarefa de manuten\u00e7\u00e3o que esses sistemas precisavam periodicamente fosse trocar algum hardware.<\/li>\n<li>Al\u00e9m disso, no Odnoklassniki existe uma excelente tradi\u00e7\u00e3o t\u00e9cnica: qualquer servi\u00e7o que lan\u00e7amos deve sobreviver \u00e0 falha de um data center (repentina, n\u00e3o planejada e absolutamente a qualquer hora).<\/li>\n<\/ul>\n<p><\/p>\n<p>A \u00faltima exig\u00eancia na implementa\u00e7\u00e3o deste projeto nos custou muito, sobre o que falarei mais em detalhes.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Ambiente<\/h2>\n<p><\/p>\n<p>Trabalhamos em quatro data centers, com as nodos Elasticsearch podendo estar localizados apenas em tr\u00eas (por raz\u00f5es n\u00e3o t\u00e9cnicas).<\/p>\n<p><\/p>\n<p>Nestes quatro data centers, existem cerca de 18 mil diferentes fontes de logs \u2014 hardware, cont\u00eaineres, m\u00e1quinas virtuais.<\/p>\n<p><\/p>\n<p>Uma caracter\u00edstica importante: o cluster \u00e9 iniciado em cont\u00eaineres <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> n\u00e3o em m\u00e1quinas f\u00edsicas, mas na <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">nossa pr\u00f3pria solu\u00e7\u00e3o em nuvem one-cloud<\/a><\/noindex>. Os cont\u00eaineres t\u00eam garantidos 2 n\u00facleos, equivalentes a 2.0Ghz v4, com a possibilidade de usar os outros n\u00facleos em caso de inatividade. <\/p>\n<p><\/p>\n<p>Em outras palavras:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/073bffbfc3cff761bfabe0773b7f4ebc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"topologiya\">Topologia<\/h2>\n<p><\/p>\n<p>A vis\u00e3o geral da solu\u00e7\u00e3o inicialmente me parecia da seguinte forma:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIPs est\u00e3o por tr\u00e1s do registro A do dom\u00ednio Graylog, este \u00e9 o endere\u00e7o para onde os logs s\u00e3o enviados.<\/li>\n<li>cada VIP representa um balanceador LVS.<\/li>\n<li>Ap\u00f3s isso, os logs v\u00e3o para um conjunto de Graylog, parte dos dados \u00e9 no formato GELF, parte no formato syslog.<\/li>\n<li>Em seguida, tudo isso \u00e9 escrito em grandes lotes em um conjunto de coordenadores Elasticsearch. <\/li>\n<li>E estes, por sua vez, enviam solicita\u00e7\u00f5es de grava\u00e7\u00e3o e leitura para as nodos de dados relevantes. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/21efcdf6992a07e0c5e9b477c567cca9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"terminologiya\">Terminologia<\/h2>\n<p><\/p>\n<p>Talvez nem todos estejam familiarizados com a terminologia, por isso gostaria de fazer uma pequena pausa sobre isso.<\/p>\n<p><\/p>\n<p>No Elasticsearch, h\u00e1 v\u00e1rios tipos de nodos \u2014 master, coordinator, data node. Existem outros dois tipos para diferentes transforma\u00e7\u00f5es de logs e para a comunica\u00e7\u00e3o entre diferentes clusters, mas usamos apenas os mencionados. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nMonitora todos os nodos presentes no cluster, mant\u00e9m o mapa do cluster atualizado e o distribui entre os nodos, processa a l\u00f3gica de eventos e cuida da manuten\u00e7\u00e3o geral do cluster. <\/p>\n<p><\/p>\n<p><strong>Coordinator<\/strong><br \/>\nRealiza uma \u00fanica tarefa: aceita solicita\u00e7\u00f5es de clientes para leitura ou grava\u00e7\u00e3o e roteia esse tr\u00e1fego. Se for uma solicita\u00e7\u00e3o de grava\u00e7\u00e3o, provavelmente perguntar\u00e1 ao master em qual shard do \u00edndice relevante deve coloc\u00e1-la e redirecionar\u00e1 a solicita\u00e7\u00e3o. <\/p>\n<p><\/p>\n<p><strong>Data node<\/strong><br \/>\nArmazena dados, executa as consultas de busca que chegam externamente e opera\u00e7\u00f5es nos shards localizados nela.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\n\u00c9 algo como uma combina\u00e7\u00e3o do Kibana com o Logstash na pilha ELK. O Graylog combina a interface de usu\u00e1rio e o pipeline de processamento de logs. Por tr\u00e1s do Graylog, trabalham o Kafka e o Zookeeper, que garantem a conectividade do Graylog como um cluster. O Graylog \u00e9 capaz de armazenar logs em cache (Kafka) caso o Elasticsearch esteja indispon\u00edvel e repetir solicita\u00e7\u00f5es de leitura e grava\u00e7\u00e3o falhadas, agrupando e etiquetando logs de acordo com regras definidas. Assim como o Logstash, o Graylog possui funcionalidade para modificar strings antes de grav\u00e1-las no Elasticsearch.<\/p>\n<p><\/p>\n<p>Al\u00e9m disso, o Graylog possui uma descoberta de servi\u00e7os embutida, permitindo, com base em um \u00fanico n\u00f3 acess\u00edvel do Elasticsearch, obter todo o mapa do cluster e filtr\u00e1-lo por uma determinada tag, o que possibilita direcionar solicita\u00e7\u00f5es a cont\u00eaineres espec\u00edficos.<\/p>\n<p><\/p>\n<p>Visualmente, isso fica mais ou menos assim:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Esta \u00e9 uma captura de tela de uma inst\u00e2ncia espec\u00edfica. Aqui, constru\u00edmos um histograma a partir da consulta de pesquisa, mostrando as linhas relevantes.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">\u00cdndices<\/h2>\n<p><\/p>\n<p>Voltando \u00e0 arquitetura do sistema, gostaria de discutir em mais detalhes como constru\u00edmos o modelo de \u00edndices para que tudo funcionasse corretamente. <\/p>\n<p><\/p>\n<p>Na diagrama\u00e7\u00e3o apresentada anteriormente, este \u00e9 o n\u00edvel mais baixo: os n\u00f3s de dados do Elasticsearch.<\/p>\n<p><\/p>\n<p>Um \u00edndice \u00e9 uma grande entidade virtual composta por shards do Elasticsearch. Cada shard \u00e9, na verdade, um \u00edndice do Lucene. E cada \u00edndice do Lucene, por sua vez, consiste de um ou mais segmentos. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Na fase de projeto, consideramos que, para atender \u00e0 demanda de velocidade de leitura em um grande volume de dados, era necess\u00e1rio \"distribuir\" esses dados uniformemente entre os n\u00f3s de dados. <\/p>\n<p><\/p>\n<p>Isso resultou na necessidade de que o n\u00famero de shards por \u00edndice (junto com as r\u00e9plicas) fosse estritamente igual ao n\u00famero de n\u00f3s de dados. Em primeiro lugar, para garantir um fator de replica\u00e7\u00e3o igual a dois (ou seja, podemos perder metade do cluster). E, em segundo lugar, para que as solicita\u00e7\u00f5es de leitura e grava\u00e7\u00e3o fossem processadas, no m\u00ednimo, em metade do cluster.<\/p>\n<p><\/p>\n<p>Definimos o tempo de armazenamento inicialmente como 30 dias.<\/p>\n<p><\/p>\n<p>A distribui\u00e7\u00e3o dos shards pode ser representada graficamente da seguinte forma:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Todo o ret\u00e2ngulo cinza escuro representa completamente o \u00edndice. O quadrado vermelho \u00e0 esquerda \u00e9 o shard prim\u00e1rio, o primeiro do \u00edndice. E o quadrado azul \u00e9 o shard de r\u00e9plica. Eles est\u00e3o localizados em diferentes data centers.<\/p>\n<p><\/p>\n<p>Quando adicionamos mais um shard, ele vai para o terceiro data center. E, no final, temos essa estrutura, que garante a possibilidade de perder um DC sem perder a consist\u00eancia dos dados:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Fizemos a rota\u00e7\u00e3o de \u00edndices, ou seja, a cria\u00e7\u00e3o de um novo \u00edndice e a remo\u00e7\u00e3o do mais antigo, igual a 48 horas (com base no padr\u00e3o de uso do \u00edndice: os dados mais recentes s\u00e3o os mais frequentemente buscados).<\/p>\n<p><\/p>\n<p>Esse intervalo de rota\u00e7\u00e3o de \u00edndices est\u00e1 relacionado com os seguintes motivos:<\/p>\n<p><\/p>\n<p>Quando um n\u00f3 de dados espec\u00edfico recebe uma consulta de busca, do ponto de vista de desempenho, \u00e9 mais vantajoso consultar um \u00fanico shard, se seu tamanho for compar\u00e1vel ao tamanho da mem\u00f3ria do n\u00f3. Isso permite manter a parte \"quente\" do \u00edndice na mem\u00f3ria e acess\u00e1-la rapidamente. Quando h\u00e1 muitas partes \"quentes\", a velocidade de busca no \u00edndice se degrada.<\/p>\n<p><\/p>\n<p>Quando um n\u00f3 come\u00e7a a processar uma consulta de busca em um shard, ele aloca um n\u00famero de threads igual ao n\u00famero de n\u00facleos f\u00edsicos da m\u00e1quina com hyper-threading. Se a consulta de busca envolve um grande n\u00famero de shards, o n\u00famero de threads cresce proporcionalmente. Isso impacta negativamente na velocidade de busca e compromete a indexa\u00e7\u00e3o de novos dados. <\/p>\n<p><\/p>\n<p>Para garantir a lat\u00eancia necess\u00e1ria para a busca, decidimos usar SSD. Para um processamento r\u00e1pido das consultas, as m\u00e1quinas que hospedavam esses cont\u00eaineres precisavam ter pelo menos 56 n\u00facleos. O n\u00famero 56 foi escolhido como uma quantidade condicionalmente suficiente, que determina o n\u00famero de threads que o Elasticsearch ir\u00e1 gerar durante a opera\u00e7\u00e3o. Em Elasticsearch, muitos par\u00e2metros do thread pool dependem diretamente do n\u00famero de n\u00facleos dispon\u00edveis, o que, por sua vez, influencia diretamente a quantidade necess\u00e1ria de n\u00f3s no cluster sob o princ\u00edpio \"menos n\u00facleos \u2014 mais n\u00f3s\". <\/p>\n<p><\/p>\n<p>No final, temos uma m\u00e9dia de que cada shard pesa cerca de 20 gigabytes, e para 1 \u00edndice existem 360 shards. Portanto, se rotacionamos a cada 48 horas, temos 15 no total. Cada \u00edndice cont\u00e9m dados de 2 dias.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Esquemas de grava\u00e7\u00e3o e leitura de dados<\/h2>\n<p><\/p>\n<p>Vamos entender como os dados s\u00e3o gravados neste sistema.<\/p>\n<p><\/p>\n<p>Suponha que temos uma consulta vinda do Graylog para o coordenador. Por exemplo, queremos indexar de 2 a 3 mil linhas. <\/p>\n<p><\/p>\n<p>O Coordenador, ao receber um pedido do Graylog, questiona o mestre: \"No pedido de indexa\u00e7\u00e3o, especificamos claramente o \u00edndice, mas n\u00e3o foi indicado em qual shard isso deve ser escrito.\" <\/p>\n<p><\/p>\n<p>O Mestre responde: \"Grave essa informa\u00e7\u00e3o no shard n\u00famero 71\", ap\u00f3s o que ela \u00e9 enviada diretamente para o n\u00f3 de dados relevante, onde est\u00e1 o primary-shard n\u00famero 71.<\/p>\n<p><\/p>\n<p>Depois disso, o log de transa\u00e7\u00f5es \u00e9 replicado no replica-shard, que j\u00e1 est\u00e1 em outro data center.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Um pedido de busca chega do Graylog ao coordenador. O coordenador o redireciona pelo \u00edndice, enquanto o Elasticsearch distribui os pedidos entre o primary-shard e o replica-shard segundo o princ\u00edpio round-robin. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Os 180 n\u00f3s respondem de forma desigual, e enquanto eles respondem, o coordenador acumula informa\u00e7\u00f5es que j\u00e1 foram \"expelidas\" por n\u00f3s de dados mais r\u00e1pidos. Ap\u00f3s isso, quando todas as informa\u00e7\u00f5es chegam ou se o tempo limite do pedido \u00e9 atingido, ele as entrega diretamente ao cliente. <\/p>\n<p><\/p>\n<p>Todo esse sistema, em m\u00e9dia, processa os pedidos de busca dos \u00faltimos 48 horas em 300-400ms, excluindo os pedidos que usam wildcard \u00e0 frente.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\"FLores\" com Elasticsearch: configura\u00e7\u00e3o do Java<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Para que tudo funcionasse como inicialmente desej\u00e1vamos, passamos muito tempo ajustando a mais diversas configura\u00e7\u00f5es no cluster. <\/p>\n<p><\/p>\n<p>A primeira parte dos problemas descobertos estava relacionada a como o Java \u00e9 pr\u00e9-configurado por padr\u00e3o no Elasticsearch. <\/p>\n<p><\/p>\n<p><strong>Primeiro problema<\/strong><br \/>\nObservamos uma grande quantidade de mensagens sobre o que acontece no n\u00edvel do Lucene, quando os jobs em segundo plano est\u00e3o sendo executados, os merges de segmentos Lucene est\u00e3o falhando com erro. Nos logs, era vis\u00edvel que tratava-se de um erro OutOfMemoryError. Atrav\u00e9s da telemetria, vimos que o heap estava livre e n\u00e3o ficou claro por que essa opera\u00e7\u00e3o estava falhando. <\/p>\n<p><\/p>\n<p>Descobrimos que as mesclagens dos \u00edndices do Lucene ocorrem fora do heap. E os cont\u00eaineres t\u00eam restri\u00e7\u00f5es severas quanto aos recursos consumidos. Esses recursos inclu\u00edam apenas o heap (o valor do heap.size era aproximadamente igual \u00e0 RAM), e algumas opera\u00e7\u00f5es off-heap falhavam com o erro de aloca\u00e7\u00e3o de mem\u00f3ria, caso por algum motivo n\u00e3o se enquadrassem nos ~500MB restantes at\u00e9 o limite.<\/p>\n<p><\/p>\n<p>A corre\u00e7\u00e3o foi bastante trivial: aumentamos a quantidade de RAM dispon\u00edvel para o cont\u00eainer, ap\u00f3s o que esquecemos que tais problemas j\u00e1 existiram.<\/p>\n<p><\/p>\n<p><strong>Segundo problema<\/strong><br \/>\nCerca de 4-5 dias ap\u00f3s o in\u00edcio do ciclo de vida do cluster, notamos que os n\u00f3s de dados come\u00e7avam a cair periodicamente do cluster e a entrar novamente ap\u00f3s cerca de 10-20 segundos. <\/p>\n<p><\/p>\n<p>Ao investigarmos, descobrimos que a mem\u00f3ria off-heap no Elasticsearch n\u00e3o \u00e9 controlada de forma alguma. Quando fornecemos mais mem\u00f3ria ao cont\u00eainer, conseguimos preencher os pools de buffer direto com v\u00e1rias informa\u00e7\u00f5es, e ela s\u00f3 era limpa ap\u00f3s a execu\u00e7\u00e3o de um GC expl\u00edcito por parte do Elasticsearch. <\/p>\n<p><\/p>\n<p>Em alguns casos, essa opera\u00e7\u00e3o demorava bastante, e durante esse tempo o cluster acabava marcando esse n\u00f3 como j\u00e1 fora do ar. Esse problema est\u00e1 bem descrito <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">aqui<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>A solu\u00e7\u00e3o foi a seguinte: limitamos a capacidade do Java de usar a maior parte da mem\u00f3ria fora do heap para essas opera\u00e7\u00f5es. Limitamos isso a 16 gigabytes (-XX:MaxDirectMemorySize=16g), conseguindo que o GC expl\u00edcito fosse chamado com muito mais frequ\u00eancia e fosse executado muito mais r\u00e1pido, evitando assim desestabilizar o cluster.<\/p>\n<p><\/p>\n<p><strong>Terceiro problema<\/strong><br \/>\nSe voc\u00ea pensa que os problemas com \"n\u00f3s saindo do cluster no momento mais inesperado\" acabaram, voc\u00ea est\u00e1 enganado. <\/p>\n<p><\/p>\n<p>Ao configurar o trabalho com \u00edndices, escolhemos o mmapfs para <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">reduzir o tempo de busca<\/a><\/noindex> em shards novos com alta segmenta\u00e7\u00e3o. Essa foi uma escolha bastante equivocada, porque ao usar mmapfs o arquivo \u00e9 mapeado para a mem\u00f3ria RAM, e ent\u00e3o trabalhamos com o arquivo mapeado. Isso resulta em que, ao tentar o GC parar as threads na aplica\u00e7\u00e3o, levamos muito tempo at\u00e9 chegar ao safepoint, e durante esse trajeto a aplica\u00e7\u00e3o deixa de responder \u00e0s consultas do mestre sobre sua continuidade. Consequentemente, o mestre conclui que o n\u00f3 n\u00e3o est\u00e1 mais presente no cluster. Ap\u00f3s cerca de 5-10 segundos, o coletor de lixo \u00e9 acionado, o n\u00f3 revive, reentrou no cluster e come\u00e7a a inicializa\u00e7\u00e3o dos shards. Tudo isso lembrava muito \"a produ\u00e7\u00e3o que merecemos\" e n\u00e3o servia para nada s\u00e9rio.<\/p>\n<p><\/p>\n<p>Para eliminar esse comportamento, primeiramente migramos para o padr\u00e3o niofs, e depois, ao migrar das vers\u00f5es 5 do Elastic para as vers\u00f5es 6, experimentamos o hybridfs, onde esse problema n\u00e3o se reproduziu. Mais detalhes sobre os tipos de armazenamento podem ser lidos <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">aqui<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Quarto problema<\/strong><br \/>\nDepois houve um problema muito interessante, que levamos um tempo recorde para resolver. Levamos de 2 a 3 meses para identific\u00e1-lo, pois seu padr\u00e3o era absolutamente incompreens\u00edvel. <\/p>\n<p><\/p>\n<p>\u00c0s vezes, nossos coordenadores entravam em Full GC, geralmente depois do almo\u00e7o, e n\u00e3o voltavam mais. Ao registrar os atrasos do GC, isso aparecia assim: tudo ia bem, bem, bem, e de repente \u2014 tudo ficava muito mal. <\/p>\n<p><\/p>\n<p>No in\u00edcio, pensamos que t\u00ednhamos um usu\u00e1rio mal-intencionado que estava executando alguma consulta que tirava o coordenador do modo de opera\u00e7\u00e3o. Registramos as consultas por muito tempo, tentando descobrir o que estava acontecendo. <\/p>\n<p><\/p>\n<p>No final, descobrimos que, no momento em que algum usu\u00e1rio lan\u00e7ava uma grande consulta e ela chegava a um coordenador espec\u00edfico do Elasticsearch, alguns n\u00f3s respondiam mais devagar que os outros. <\/p>\n<p><\/p>\n<p>E durante o tempo em que o coordenador espera a resposta de todos os n\u00f3s, ele acumula os resultados que foram enviados pelos n\u00f3s que j\u00e1 responderam. Para o GC, isso significa que o padr\u00e3o de uso do heap muda rapidamente. E o GC que us\u00e1vamos n\u00e3o conseguia lidar com essa situa\u00e7\u00e3o. <\/p>\n<p><\/p>\n<p>A \u00fanica solu\u00e7\u00e3o que encontramos para alterar o comportamento do cluster nessa situa\u00e7\u00e3o foi migrar para o JDK13 e usar o coletor de lixo Shenandoah. Isso resolveu o problema, e os coordenadores pararam de falhar. <\/p>\n<p><\/p>\n<p>Com isso, os problemas com Java acabaram e come\u00e7aram os problemas com a largura de banda. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">Os \u2018frutos\u2019 do Elasticsearch: largura de banda<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Os problemas com a largura de banda significam que nosso cluster opera de forma est\u00e1vel, mas durante picos na quantidade de documentos indexados e em momentos de manobras, o desempenho \u00e9 insuficiente.<\/p>\n<p><\/p>\n<p>O primeiro sintoma observado: durante alguns \u2018explos\u00f5es\u2019 em produ\u00e7\u00e3o, quando um grande volume de logs \u00e9 gerado rapidamente, o Graylog come\u00e7a a apresentar com frequ\u00eancia o erro de indexa\u00e7\u00e3o es_rejected_execution. <\/p>\n<p><\/p>\n<p>Isso acontecia porque o thread_pool.write.queue em um dos n\u00f3s de dados, at\u00e9 que o Elasticsearch conseguisse processar a solicita\u00e7\u00e3o de indexa\u00e7\u00e3o e enviar a informa\u00e7\u00e3o para o shard no disco, por padr\u00e3o armazena apenas 200 solicita\u00e7\u00f5es na fila. E na <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">documenta\u00e7\u00e3o do Elasticsearch<\/a><\/noindex> h\u00e1 muito pouco mencionado sobre esse par\u00e2metro. Somente \u00e9 indicado o n\u00famero m\u00e1ximo de threads e o tamanho padr\u00e3o.<\/p>\n<p><\/p>\n<p>Claro, fomos ajustar esse valor e descobrimos o seguinte: especificamente na nossa configura\u00e7\u00e3o, \u00e9 poss\u00edvel armazenar com efici\u00eancia at\u00e9 300 solicita\u00e7\u00f5es, mas um valor maior coloca a gente de volta no Full GC.<\/p>\n<p><\/p>\n<p>Al\u00e9m disso, como se trata de lotes de mensagens que chegam em uma \u00fanica solicita\u00e7\u00e3o, foi necess\u00e1rio ajustar o Graylog para que ele registrasse n\u00e3o com frequ\u00eancia e em pequenos lotes, mas sim em grandes lotes ou a cada 3 segundos, se o lote ainda n\u00e3o estiver cheio. Dessa forma, a informa\u00e7\u00e3o que escrevemos no Elasticsearch se torna acess\u00edvel n\u00e3o em dois segundos, mas em cinco (o que nos satisfaz), mas o n\u00famero de retrials que precisamos fazer para empurrar um grande lote de informa\u00e7\u00f5es diminui.<\/p>\n<p><\/p>\n<p>Isso \u00e9 especialmente importante em momentos em que algo falha e avisa insistentemente sobre isso, para que n\u00e3o tenhamos um Elastic completamente lotado e, ap\u00f3s algum tempo, n\u00f3s tenhamos n\u00f3s do Graylog n\u00e3o funcionais devido a buffers lotados.<\/p>\n<p><\/p>\n<p>Al\u00e9m disso, quando ocorria essas explos\u00f5es em produ\u00e7\u00e3o, receb\u00edamos reclama\u00e7\u00f5es de programadores e testadores: no momento em que eles mais precisavam desses logs, eles eram entregues muito lentamente.<\/p>\n<p><\/p>\n<p>Come\u00e7amos a investigar. Por um lado, estava claro que tanto as consultas de busca quanto as consultas de indexa\u00e7\u00e3o estavam sendo processadas, essencialmente, nas mesmas m\u00e1quinas f\u00edsicas, e, de alguma forma, haveria certas quedas. <\/p>\n<p><\/p>\n<p>Mas isso poderia ser contornado parcialmente, uma vez que nas vers\u00f5es seis do Elasticsearch surgiu um algoritmo que permite distribuir consultas entre n\u00f3s de dados relevantes n\u00e3o de forma aleat\u00f3ria, round-robin (o container que lida com a indexa\u00e7\u00e3o e mant\u00e9m o primary-shard pode estar muito ocupado, n\u00e3o haver\u00e1 possibilidade de responder rapidamente), mas direcionar essa consulta para um container menos carregado com replica-shard, que responder\u00e1 significativamente mais r\u00e1pido. Em outras palavras, chegamos a use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>A situa\u00e7\u00e3o de leitura come\u00e7a a parecer assim:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A transi\u00e7\u00e3o para esse algoritmo melhorou significativamente o tempo de consulta nos momentos em que t\u00ednhamos um grande fluxo de logs para escrita.<\/p>\n<p><\/p>\n<p>Finalmente, o principal problema estava em desativar o data center sem dor.<\/p>\n<p><\/p>\n<p>O que desej\u00e1vamos do cluster imediatamente ap\u00f3s a perda de conex\u00e3o com um DC: <\/p>\n<p><\/p>\n<ul>\n<li>Se o master atual estiver no data center que falhou, ele ser\u00e1 reeleito e mudar\u00e1 como fun\u00e7\u00e3o para outro n\u00f3 em outro DC.<\/li>\n<li>O master rapidamente remover\u00e1 todos os n\u00f3s inacess\u00edveis do cluster.<\/li>\n<li>Com base nos shards restantes, ele entender\u00e1: no data center perdido, tivemos esses shards prim\u00e1rios, rapidamente promover\u00e1 os shards replica complementares nos data centers restantes, e nossa indexa\u00e7\u00e3o de dados continuar\u00e1. <\/li>\n<li>Como resultado, teremos uma degrada\u00e7\u00e3o suave na largura de banda do cluster para grava\u00e7\u00e3o e leitura, por\u00e9m, de maneira geral, tudo funcionar\u00e1, ainda que lentamente, mas de forma est\u00e1vel.<\/li>\n<\/ul>\n<p><\/p>\n<p>Como descobrimos, quer\u00edamos algo assim:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E recebemos o seguinte:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Como isso aconteceu? <\/p>\n<p><\/p>\n<p>No momento da queda do data center, o nosso gargalo foi o mestre.<\/p>\n<p><\/p>\n<p>Por qu\u00ea?<\/p>\n<p><\/p>\n<p>O fato \u00e9 que no mestre existe um TaskBatcher, respons\u00e1vel pela dissemina\u00e7\u00e3o de certas tarefas e eventos no cluster. Qualquer sa\u00edda de n\u00f3, qualquer promo\u00e7\u00e3o de shard de replica para prim\u00e1rio, qualquer tarefa de cria\u00e7\u00e3o de algum shard \u2014 tudo isso vai primeiro para o TaskBatcher, onde \u00e9 processado de forma sequencial e em um \u00fanico fluxo.<\/p>\n<p><\/p>\n<p>No momento da sa\u00edda de um data center, acontecia que todos os data nodes nos data centers sobreviventes achavam que era seu dever informar ao mestre \"perdemos esses shards e esses data nodes\". <\/p>\n<p><\/p>\n<p>Enquanto isso, os data nodes sobreviventes enviavam todas essas informa\u00e7\u00f5es para o mestre atual e tentavam aguardar a confirma\u00e7\u00e3o de que ele as recebeu. Eles n\u00e3o esperavam, pois o mestre recebia as tarefas mais rapidamente do que conseguia responder. Os n\u00f3s repetiam as solicita\u00e7\u00f5es por tempo limite, enquanto o mestre, nesse meio tempo, j\u00e1 n\u00e3o tentava mais responder a elas, mas estava completamente absorvido pela tarefa de ordenar as solicita\u00e7\u00f5es por prioridade.<\/p>\n<p><\/p>\n<p>De uma forma terminal, acontecia que os data nodes spammavam o mestre a tal ponto que ele entrava em full GC. Ap\u00f3s isso, o papel de mestre mudava para algum outro n\u00f3, com o qual acontecia exatamente a mesma coisa, e, no final, o cluster se desmoronava completamente. <\/p>\n<p><\/p>\n<p>Fizemos medi\u00e7\u00f5es e at\u00e9 a vers\u00e3o 6.4.0, onde isso foi corrigido, bastava tirar simultaneamente apenas 10 data nodes de 360 para derrubar completamente o cluster.<\/p>\n<p><\/p>\n<p>Ele parecia algo assim:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ap\u00f3s a vers\u00e3o 6.4.0, onde esse bug terr\u00edvel foi corrigido, os data nodes pararam de derrubar o mestre. Mas ele n\u00e3o se tornou \"mais inteligente\" por causa disso. Ou seja: quando retiramos 2, 3 ou 10 (qualquer n\u00famero diferente de um) data nodes, o mestre recebe uma primeira mensagem, que informa que o n\u00f3 A saiu, e tenta notificar sobre isso o n\u00f3 B, o n\u00f3 C, o n\u00f3 D. <\/p>\n<p><\/p>\n<p>At the moment, the only way to address this issue is by setting a timeout of about 20-30 seconds for attempts to share information and thus manage the speed of removing the data center from the cluster.<\/p>\n<p><\/p>\n<p>In principle, this aligns with the initial requirements set for the end product within the project, but from the perspective of 'pure science,' it is a bug. This bug was successfully fixed by the developers in version 7.2.<\/p>\n<p><\/p>\n<p>Moreover, when a certain data node exited, it turned out that disseminating information about its exit was more important than informing the entire cluster that there were specific primary shards on it (to promote a replica shard in another data center to primary, allowing data writing).<\/p>\n<p><\/p>\n<p>Therefore, once everything has 'calmed down', the exited data nodes are not immediately marked as stale. Consequently, we have to wait for all pings to the exited data nodes to timeout, and only after that does our cluster start informing about the need to continue writing information at various locations. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">aqui<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>As a result, the operation of removing the data center takes us about 5 minutes during peak hours. For such a large and unwieldy system, this is quite a good result.<\/p>\n<p><\/p>\n<p>Ultimately, we arrived at the following solution:<\/p>\n<p><\/p>\n<ul>\n<li>We have 360 data nodes with disks of 700 gigabytes.<\/li>\n<li>60 coordinators for routing traffic across these data nodes.<\/li>\n<li>40 masters, which we retained as some heritage from versions prior to 6.4.0 \u2014 to survive the removal of the data center, we were mentally prepared to lose a few machines to ensure a quorum of masters even in the worst-case scenario.<\/li>\n<li>Any attempts to combine roles on a single container faced the issue that, sooner or later, a node would fail under load. <\/li>\n<li>The entire cluster uses a heap size of 31 gigabytes: all attempts to reduce the size resulted in heavy search queries with leading wildcards either crashing some nodes or triggering the circuit breaker within Elasticsearch.<\/li>\n<li>Additionally, to maintain search performance, we tried to keep the number of objects in the cluster as minimal as possible to process as few events in the bottleneck we encountered with the master.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Lastly, regarding monitoring<\/h2>\n<p><\/p>\n<p>Para que tudo funcione como planejado, monitoramos o seguinte:<\/p>\n<p><\/p>\n<ul>\n<li>Cada data node comunica ao nosso cloud que ela est\u00e1 ativa e possui estes shards. Quando desligamos algo em algum lugar, o cluster relata em 2-3 segundos que no centro A desligamos os nodes 2, 3 e 4 \u2014 isso significa que em outros data centers n\u00e3o podemos desligar os nodes que t\u00eam shards \u00fanicos.<\/li>\n<li>Conhecendo o comportamento do master, observamos atentamente a quantidade de tarefas pendentes. Porque at\u00e9 mesmo uma \u00fanica tarefa pendente, se n\u00e3o for timeout a tempo, pode teoricamente, em uma situa\u00e7\u00e3o de emerg\u00eancia, ser a causa pela qual n\u00e3o conseguimos fazer, por exemplo, a promo\u00e7\u00e3o de um shard replica para primary, o que afetaria a indexa\u00e7\u00e3o.<\/li>\n<li>Al\u00e9m disso, observamos de perto os atrasos do garbage collector, pois j\u00e1 tivemos grandes dificuldades com isso durante a otimiza\u00e7\u00e3o.<\/li>\n<li>Rejei\u00e7\u00f5es por threads, para entender antecipadamente onde est\u00e1 o \"gargalo\".<\/li>\n<li>E as m\u00e9tricas padr\u00e3o, como heap, RAM e I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ao construir a monitoriza\u00e7\u00e3o, \u00e9 imprescind\u00edvel considerar as particularidades do Thread Pool no Elasticsearch. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">A documenta\u00e7\u00e3o do Elasticsearch<\/a><\/noindex> descreve as capacidades de configura\u00e7\u00e3o e os valores padr\u00e3o para busca, indexa\u00e7\u00e3o, mas omite completamente o thread_pool.management. Esses threads processam, em particular, solicita\u00e7\u00f5es do tipo _cat\/shards e outras semelhantes, que s\u00e3o convenientes para escrever monitoramento. Quanto maior o cluster, mais tais solicita\u00e7\u00f5es s\u00e3o executadas em um \u00fanico momento, e o thread_pool.management mencionado n\u00e3o s\u00f3 n\u00e3o \u00e9 apresentado na documenta\u00e7\u00e3o oficial, como ainda \u00e9 limitado a 5 threads por padr\u00e3o, o que se esgota rapidamente, ap\u00f3s o que a monitoriza\u00e7\u00e3o deixa de funcionar corretamente.<\/p>\n<p><\/p>\n<p>O que gostaria de dizer em conclus\u00e3o: conseguimos! Conseguimos fornecer aos nossos programadores e desenvolvedores uma ferramenta que, em praticamente qualquer situa\u00e7\u00e3o, pode rapidamente e com precis\u00e3o fornecer informa\u00e7\u00f5es sobre o que est\u00e1 acontecendo na produ\u00e7\u00e3o.<\/p>\n<p><\/p>\n<p>Sim, isso se tornou bastante complexo, mas, ainda assim, conseguimos encaixar nossas necessidades em produtos existentes, que n\u00e3o precisaram ser patchados ou reescritos para atend\u00ea-los.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Fonte: <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.3 - 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\/pt\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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\udd47Cluster Elasticsearch de 200 TB+ | ProHoster","description":"Muitos se deparam com Elasticsearch.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}