{"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\/es\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Cl\u00faster de Elasticsearch de 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Muchas personas se enfrentan a Elasticsearch. Pero, \u00bfqu\u00e9 sucede cuando quieres usarlo para almacenar registros \"en grandes vol\u00famenes\"? \u00bfY c\u00f3mo sobrevivir sin problemas a la falla de cualquiera de varios centros de datos? \u00bfQu\u00e9 arquitectura deber\u00edas implementar y en qu\u00e9 trampas podr\u00edas caer?<\/p>\n<p><\/p>\n<p>En Odnoklassniki decidimos resolver la gesti\u00f3n de registros con ayuda de Elasticsearch y ahora compartimos nuestra experiencia con Habr: sobre la arquitectura y las trampas.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Soy P\u0451tr Zaitsev, trabajo como administrador de sistemas en Odnoklassniki. Antes tambi\u00e9n fui administrador, trabaj\u00e9 con Manticore Search, Sphinx search y Elasticsearch. Es posible que, si aparece alg\u00fan otro ...search, probablemente trabajar\u00e9 con \u00e9l tambi\u00e9n. Tambi\u00e9n participo en varios proyectos de c\u00f3digo abierto de forma voluntaria.<\/p>\n<p><\/p>\n<p>Cuando llegu\u00e9 a Odnoklassniki, imprudentemente dije en la entrevista que sab\u00eda trabajar con Elasticsearch. Despu\u00e9s de adaptarme y realizar algunas tareas sencillas, me asignaron una gran tarea de reformar el sistema de gesti\u00f3n de registros que exist\u00eda en ese momento. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Requisitos<\/h2>\n<p><\/p>\n<p>Los requisitos del sistema se formularon de la siguiente manera:<\/p>\n<p><\/p>\n<ul>\n<li>Se deb\u00eda utilizar Graylog como frontend. Porque en la empresa ya hab\u00eda experiencia utilizando este producto, los programadores y testers lo conoc\u00edan, les era familiar y conveniente.<\/li>\n<li>Volumen de datos: en promedio de 50 a 80 mil mensajes por segundo, pero si algo se rompe, el tr\u00e1fico no tiene l\u00edmites, esto puede llegar a ser de 2 a 3 millones de l\u00edneas por segundo.<\/li>\n<li>Al discutir con los clientes los requisitos de velocidad para el procesamiento de consultas, entendimos que el patr\u00f3n t\u00edpico de uso de este tipo de sistema es que las personas buscan los registros de su aplicaci\u00f3n de los \u00faltimos dos d\u00edas y no quieren esperar m\u00e1s de un segundo para el resultado de su consulta. <\/li>\n<li>Los administradores insistieron en que el sistema debe ser f\u00e1cilmente escalable cuando sea necesario, sin requerirles una comprensi\u00f3n profunda de c\u00f3mo est\u00e1 estructurado. <\/li>\n<li>La \u00fanica tarea de mantenimiento que estos sistemas requieren de forma peri\u00f3dica es cambiar alg\u00fan hardware.<\/li>\n<li>Adem\u00e1s, en Odnoklassniki hay una maravillosa tradici\u00f3n t\u00e9cnica: cualquier servicio que lancemos debe ser capaz de sobrevivir a la falla de un centro de datos (sorpresiva, no planificada y en cualquier momento).<\/li>\n<\/ul>\n<p><\/p>\n<p>El \u00faltimo requisito para la implementaci\u00f3n de este proyecto nos cost\u00f3 mucho esfuerzo, del cual hablar\u00e9 en detalle m\u00e1s adelante.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Entorno<\/h2>\n<p><\/p>\n<p>Contamos con cuatro centros de datos, siendo que las nodos de Elasticsearch solo pueden estar en tres (por varias razones no t\u00e9cnicas).<\/p>\n<p><\/p>\n<p>En estos cuatro centros de datos hay aproximadamente 18,000 fuentes de logs diferentes: hardware, contenedores, m\u00e1quinas virtuales.<\/p>\n<p><\/p>\n<p>Una caracter\u00edstica importante: el cl\u00faster se ejecuta en contenedores <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> no en m\u00e1quinas f\u00edsicas, sino en <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">nuestro producto en la nube one-cloud<\/a><\/noindex>. A los contenedores se les garantiza 2 n\u00facleos, equivalentes a 2.0Ghz v4, con la posibilidad de utilizar los n\u00facleos restantes en caso de inactividad. <\/p>\n<p><\/p>\n<p>En otras palabras:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de 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\">Topolog\u00eda<\/h2>\n<p><\/p>\n<p>La vista general de la soluci\u00f3n me parec\u00eda de la siguiente manera:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP se encuentran detr\u00e1s del registro A del dominio Graylog, que es la direcci\u00f3n a la que se env\u00edan los logs.<\/li>\n<li>cada VIP es un equilibrador de carga LVS.<\/li>\n<li>Despu\u00e9s de esto, los logs llegan a un conjunto de Graylog, parte de los datos se env\u00eda en formato GELF, parte en formato syslog.<\/li>\n<li>Luego, todo esto se escribe en grandes lotes en un conjunto de coordinadores de Elasticsearch. <\/li>\n<li>Y estos, a su vez, env\u00edan solicitudes de escritura y lectura a los nodos de datos relevantes. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de 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\">Terminolog\u00eda<\/h2>\n<p><\/p>\n<p>Es posible que no todos conozcan la terminolog\u00eda en detalle, as\u00ed que me gustar\u00eda detenerme un poco en ella.<\/p>\n<p><\/p>\n<p>En Elasticsearch hay varios tipos de nodos: master, coordinator, data node. Hay otros dos tipos para diferentes transformaciones de logs y comunicaci\u00f3n entre diferentes cl\u00fasteres, pero solo us\u00e1bamos los mencionados. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPinga todos los nodos presentes en el cl\u00faster, mantiene el mapa del cl\u00faster actualizado y lo distribuye entre los nodos, procesa la l\u00f3gica de eventos, se encarga de diversas tareas de mantenimiento a nivel de cl\u00faster. <\/p>\n<p><\/p>\n<p><strong>Coordinador<\/strong><br \/>\nRealiza una \u00fanica tarea: recibe solicitudes de los clientes para lectura o escritura y dirige este tr\u00e1fico. En caso de que la solicitud sea de escritura, es probable que consulte al master en qu\u00e9 shard del \u00edndice relevante debe colocarlo y redirija la solicitud. <\/p>\n<p><\/p>\n<p><strong>Nodo de datos<\/strong><br \/>\nAlmacena datos, ejecuta las solicitudes de b\u00fasqueda que llegan desde el exterior y operaciones sobre los shards ubicados en \u00e9l.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nEs algo as\u00ed como una combinaci\u00f3n de Kibana con Logstash en el stack ELK. Graylog integra tanto la interfaz de usuario como el pipeline de procesamiento de logs. Detr\u00e1s de Graylog funcionan Kafka y Zookeeper, que garantizan la conectividad de Graylog como un cl\u00faster. Graylog puede almacenar en cach\u00e9 los logs (Kafka) en caso de que Elasticsearch no est\u00e9 disponible y repetir las solicitudes de lectura y escritura fallidas, agrupar y etiquetar los logs seg\u00fan las reglas definidas. Al igual que Logstash, Graylog tiene la funcionalidad de modificar las cadenas antes de escribirlas en Elasticsearch.<\/p>\n<p><\/p>\n<p>Adem\u00e1s, Graylog cuenta con un servicio de descubrimiento integrado que permite, a partir de un nodo de Elasticsearch disponible, obtener todo el mapa del cl\u00faster y filtrarlo por una etiqueta espec\u00edfica, lo que permite dirigir las solicitudes a contenedores determinados.<\/p>\n<p><\/p>\n<p>Visualmente, esto se ve as\u00ed:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de 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 es una captura de pantalla de una instancia espec\u00edfica. Aqu\u00ed organizamos un histograma basado en una consulta de b\u00fasqueda y mostramos filas relevantes.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">\u00cdndices<\/h2>\n<p><\/p>\n<p>Volviendo a la arquitectura del sistema, me gustar\u00eda detenerme m\u00e1s en c\u00f3mo construimos el modelo de \u00edndices para que todo funcionara correctamente. <\/p>\n<p><\/p>\n<p>En el diagrama proporcionado anteriormente, este es el nivel m\u00e1s inferior: nodos de datos de Elasticsearch.<\/p>\n<p><\/p>\n<p>Un \u00edndice es una gran entidad virtual compuesta de shards de Elasticsearch. Cada uno de estos shards no es m\u00e1s que un \u00edndice de Lucene. Y cada \u00edndice de Lucene, a su vez, se compone de uno o m\u00e1s segmentos. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Al dise\u00f1ar, consideramos que para cumplir con el requisito de velocidad de lectura sobre un gran volumen de datos, necesit\u00e1bamos 'dispersar' estos datos uniformemente entre los nodos de datos. <\/p>\n<p><\/p>\n<p>Esto se tradujo en que el n\u00famero de shards por \u00edndice (con r\u00e9plicas) debe ser estrictamente igual al n\u00famero de nodos de datos. En primer lugar, para garantizar un factor de replicaci\u00f3n igual a dos (es decir, podemos perder la mitad del cl\u00faster). Y, en segundo lugar, para poder procesar solicitudes de lectura y escritura en al menos la mitad del cl\u00faster.<\/p>\n<p><\/p>\n<p>Primero definimos el tiempo de almacenamiento como 30 d\u00edas.<\/p>\n<p><\/p>\n<p>La distribuci\u00f3n de shards se puede representar gr\u00e1ficamente de la siguiente manera:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de 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 el rect\u00e1ngulo gris oscuro en su totalidad es el \u00edndice. El cuadrado rojo a la izquierda en \u00e9l es el shard primario, el primero en el \u00edndice. Y el cuadrado azul es el shard r\u00e9plica. Est\u00e1n ubicados en diferentes centros de datos.<\/p>\n<p><\/p>\n<p>Cuando a\u00f1adimos otro shard, se ubica en el tercer centro de datos. Y, al final, obtenemos una estructura como esta, que permite la p\u00e9rdida de un centro de datos sin perder la consistencia de los datos:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hicimos la rotaci\u00f3n de \u00edndices, es decir, la creaci\u00f3n de un nuevo \u00edndice y la eliminaci\u00f3n del m\u00e1s antiguo, igual a 48 horas (basado en el patr\u00f3n de uso del \u00edndice: las b\u00fasquedas se realizan m\u00e1s frecuentemente sobre las \u00faltimas 48 horas).<\/p>\n<p><\/p>\n<p>Este intervalo de rotaci\u00f3n de \u00edndices est\u00e1 relacionado con las siguientes razones:<\/p>\n<p><\/p>\n<p>Cuando un nodo de datos espec\u00edfico recibe una solicitud de b\u00fasqueda, es m\u00e1s ventajoso en t\u00e9rminos de rendimiento interrogar un solo shard, si su tama\u00f1o es comparable al tama\u00f1o de la memoria del nodo. Esto permite mantener la parte 'caliente' del \u00edndice en la memoria y acceder a ella r\u00e1pidamente. Cuando hay muchas partes 'calientes', la velocidad de b\u00fasqueda en el \u00edndice se degrada.<\/p>\n<p><\/p>\n<p>Cuando un nodo comienza a procesar una solicitud de b\u00fasqueda en un shard, asigna un n\u00famero de hilos igual al n\u00famero de n\u00facleos de hyper-threading de la m\u00e1quina f\u00edsica. Si la solicitud de b\u00fasqueda abarca un gran n\u00famero de shards, el n\u00famero de hilos aumenta proporcionalmente. Esto impacta negativamente en la velocidad de b\u00fasqueda y afecta adversamente la indexaci\u00f3n de nuevos datos. <\/p>\n<p><\/p>\n<p>Para asegurar la latencia necesaria de b\u00fasqueda, decidimos utilizar SSD. Para un procesamiento r\u00e1pido de consultas, las m\u00e1quinas donde se alojaban estos contenedores deb\u00edan tener al menos 56 n\u00facleos. La cifra de 56 se eligi\u00f3 como un valor condicionalmente suficiente, que determina la cantidad de hilos que generar\u00e1 Elasticsearch durante su funcionamiento. En Elasticsearch, muchos par\u00e1metros del thread pool dependen directamente de la cantidad de n\u00facleos disponibles, lo que a su vez influye directamente en la cantidad necesaria de nodos en el cl\u00faster seg\u00fan el principio de 'menos n\u00facleos \u2014 m\u00e1s nodos'. <\/p>\n<p><\/p>\n<p>Como resultado, obtuvimos que, en promedio, un shard pesa alrededor de 20 gigabytes, y hay 360 shards por \u00edndice. Por lo tanto, si los rotamos cada 48 horas, tenemos 15 en total. Cada \u00edndice almacena datos de 2 d\u00edas.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Esquemas de escritura y lectura de datos<\/h2>\n<p><\/p>\n<p>Vamos a analizar c\u00f3mo se registran los datos en este sistema.<\/p>\n<p><\/p>\n<p>Supongamos que tenemos una solicitud de Graylog que llega al coordinador. Por ejemplo, queremos indexar entre 2,000 y 3,000 filas. <\/p>\n<p><\/p>\n<p>El coordinador, al recibir una solicitud de Graylog, interroga a un maestro: \u00abEn la solicitud de indexaci\u00f3n se indic\u00f3 espec\u00edficamente el \u00edndice, pero no se especific\u00f3 en qu\u00e9 fragmento escribir\u00bb. <\/p>\n<p><\/p>\n<p>El maestro responde: \u00abEscribe esta informaci\u00f3n en el fragmento n\u00famero 71\u00bb, despu\u00e9s de lo cual se env\u00eda directamente al nodo de datos relevante, donde se encuentra el fragmento primario n\u00famero 71.<\/p>\n<p><\/p>\n<p>Despu\u00e9s de eso, el registro de transacciones se replica en el fragmento de r\u00e9plica, que ya se encuentra en otro centro de datos.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Desde Graylog, llega a trav\u00e9s del coordinador una solicitud de b\u00fasqueda. El coordinador la redirige por el \u00edndice, mientras que Elasticsearch reparte las solicitudes entre el fragmento primario y el fragmento de r\u00e9plica seg\u00fan el principio round-robin. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Los nodos, en un n\u00famero de 180, responden de manera desigual y, mientras ellos responden, el coordinador acumula informaci\u00f3n que los nodos de datos m\u00e1s r\u00e1pidos ya han \u00abescupido\u00bb dentro de \u00e9l. Despu\u00e9s de eso, cuando toda la informaci\u00f3n ha llegado o se alcanza el tiempo de espera de la solicitud, se entrega todo directamente al cliente. <\/p>\n<p><\/p>\n<p>Todo este sistema, en promedio, procesa las solicitudes de b\u00fasqueda de las \u00faltimas 48 horas en 300-400 ms, excluyendo aquellas solicitudes que tienen un comod\u00edn l\u00edder.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\u00abFlores\u00bb con Elasticsearch: configuraci\u00f3n de Java<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de 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 todo esto funcionara como esper\u00e1bamos originalmente, ajustamos durante mucho tiempo una variedad de cosas en el cl\u00faster. <\/p>\n<p><\/p>\n<p>La primera parte de los problemas detectados estaba relacionada con la configuraci\u00f3n predeterminada de Java en Elasticsearch. <\/p>\n<p><\/p>\n<p><strong>Problema uno<\/strong><br \/>\nVimos un gran n\u00famero de mensajes sobre que en nuestro nivel de Lucene, cuando se ejecutan trabajos en segundo plano, las fusiones de segmentos de Lucene finalizan con error. En los registros se pod\u00eda observar que era un error OutOfMemoryError. A partir de la telemetr\u00eda, vimos que el heap estaba libre, y no quedaba claro por qu\u00e9 fallaba esta operaci\u00f3n. <\/p>\n<p><\/p>\n<p>Result\u00f3 que las combinaciones de \u00edndices de Lucene ocurren fuera de la memoria heap. Y los contenedores est\u00e1n bastante estrictamente limitados en los recursos consumidos. En esos recursos solo pod\u00eda entrar la memoria heap (el valor de heap.size era aproximadamente igual a RAM), y algunas operaciones off-heap fallaban con el error de asignaci\u00f3n de memoria si por alguna raz\u00f3n no se ajustaban a los ~500 MB que quedaban hasta el l\u00edmite.<\/p>\n<p><\/p>\n<p>La soluci\u00f3n fue bastante trivial: aumentamos la cantidad de RAM disponible para el contenedor, despu\u00e9s de lo cual nos olvidamos de que alguna vez tuvimos tales problemas.<\/p>\n<p><\/p>\n<p><strong>El segundo problema<\/strong><br \/>\nAl cabo de 4-5 d\u00edas despu\u00e9s del inicio del cl\u00faster, notamos que los nodos de datos comienzan a salir peri\u00f3dicamente del cl\u00faster y vuelven a ingresar despu\u00e9s de 10-20 segundos. <\/p>\n<p><\/p>\n<p>Cuando empezamos a investigar, nos dimos cuenta de que esta memoria off-heap en Elasticsearch no se controla pr\u00e1cticamente de ninguna manera. Cuando le dimos m\u00e1s memoria al contenedor, pudimos llenar los grupos de buffers directos con informaci\u00f3n diversa, y se limpiaron solo despu\u00e9s de que se ejecutara un GC expl\u00edcito por parte de Elasticsearch. <\/p>\n<p><\/p>\n<p>En algunos casos, esta operaci\u00f3n tom\u00f3 bastante tiempo, y durante ese tiempo el cl\u00faster logr\u00f3 marcar este nodo como ya fuera de servicio. Este problema est\u00e1 bien documentado. <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">aqu\u00ed est\u00e1<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>La soluci\u00f3n fue la siguiente: limitamos la capacidad de Java para utilizar la mayor parte de la memoria fuera del heap para estas operaciones. La limitamos a 16 gigabytes (-XX:MaxDirectMemorySize=16g), logrando que el GC expl\u00edcito se llamara con mucha m\u00e1s frecuencia y se ejecutara mucho m\u00e1s r\u00e1pido, evitando as\u00ed desestabilizar el cl\u00faster.<\/p>\n<p><\/p>\n<p><strong>El tercer problema<\/strong><br \/>\nSi piensas que los problemas de 'nodos que abandonan el cl\u00faster en el momento m\u00e1s inesperado' han terminado aqu\u00ed, est\u00e1s equivocado. <\/p>\n<p><\/p>\n<p>Cuando configuramos el trabajo con los \u00edndices, optamos por mmapfs para <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">reducir el tiempo de b\u00fasqueda<\/a><\/noindex> en shards recientes con alta segmentaci\u00f3n. Esto result\u00f3 ser un error bastante grave, porque al usar mmapfs, el archivo se mapea en la memoria RAM, y despu\u00e9s trabajamos con el archivo mapeado. Debido a esto, cuando el GC intenta detener los hilos en la aplicaci\u00f3n, tardamos mucho en llegar al safepoint, y en el camino hacia \u00e9l, la aplicaci\u00f3n deja de responder a las solicitudes del maestro sobre si sigue activa. Como resultado, el maestro considera que el nodo ya no est\u00e1 presente en el cl\u00faster. Despu\u00e9s de unos 5-10 segundos, el recolector de basura hace su trabajo, el nodo revive, vuelve a entrar en el cl\u00faster y comienza la inicializaci\u00f3n de los shards. Todo esto recordaba mucho a 'la producci\u00f3n que merec\u00edamos' y no era adecuado para nada serio.<\/p>\n<p><\/p>\n<p>Para deshacernos de este comportamiento, primero cambiamos a niofs est\u00e1ndar, y luego, cuando migramos de las versiones cinco de Elastic a las seis, probamos hybridfs, donde este problema no se reproduc\u00eda. Puedes leer m\u00e1s sobre los tipos de almacenamiento. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">aqu\u00ed<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>El cuarto problema<\/strong><br \/>\nLuego hubo otro problema muy interesante que tratamos durante un tiempo r\u00e9cord. Lo estuvimos persiguiendo durante 2-3 meses porque su patr\u00f3n era completamente incomprensible. <\/p>\n<p><\/p>\n<p>A veces nuestros coordinadores entraban en Full GC, generalmente despu\u00e9s del almuerzo, y no volv\u00edan. En la registro de las demoras de GC, se ve\u00eda as\u00ed: todo iba bien, bien, bien, y luego de repente \u2014 todo se volv\u00eda malo. <\/p>\n<p><\/p>\n<p>Primero pensamos que ten\u00edamos un usuario malicioso que estaba ejecutando alg\u00fan tipo de consulta que sacaba al coordinador del modo de trabajo. Pasamos mucho tiempo registrando las consultas, tratando de averiguar qu\u00e9 estaba pasando. <\/p>\n<p><\/p>\n<p>Al final, descubrimos que en el momento en que un usuario ejecuta una gran consulta, y esta llega a un coordinador espec\u00edfico de Elasticsearch, algunas nodos responden m\u00e1s lento que otros. <\/p>\n<p><\/p>\n<p>Y el tiempo que el coordinador espera la respuesta de todos los nodos, acumula en s\u00ed mismo los resultados enviados por los nodos que ya han respondido. Para GC, esto significa que nuestro patr\u00f3n de uso de memoria se cambia muy r\u00e1pidamente. Y el GC que est\u00e1bamos utilizando no manejaba esta tarea. <\/p>\n<p><\/p>\n<p>La \u00fanica soluci\u00f3n que encontramos para cambiar el comportamiento del cl\u00faster en tal situaci\u00f3n fue migrar a JDK13 y utilizar el recolector de basura Shenandoah. Esto resolvi\u00f3 el problema, los coordinadores dejaron de caer. <\/p>\n<p><\/p>\n<p>Con esto, los problemas con Java terminaron y comenzaron los problemas de capacidad. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u00abFrutos\u00bb con Elasticsearch: capacidad<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Los problemas de capacidad significan que nuestro cl\u00faster funciona de manera estable, pero en picos de documentos indexados y durante maniobras, el rendimiento es insuficiente.<\/p>\n<p><\/p>\n<p>El primer s\u00edntoma encontrado: en algunas \u00abexplosiones\u00bb en producci\u00f3n, cuando se genera repentinamente una gran cantidad de registros, en Graylog empieza a aparecer frecuentemente el error de indexaci\u00f3n es_rejected_execution. <\/p>\n<p><\/p>\n<p>Esto ocurr\u00eda porque thread_pool.write.queue en un nodo de datos, antes de que Elasticsearch pudiera procesar la solicitud de indexaci\u00f3n y enviar la informaci\u00f3n al shard en el disco, por defecto solo puede almacenar en cach\u00e9 200 solicitudes. Y en <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">la documentaci\u00f3n de Elasticsearch<\/a><\/noindex> se menciona muy poco sobre este par\u00e1metro. Solo se indica el n\u00famero m\u00e1ximo de hilos y el tama\u00f1o por defecto.<\/p>\n<p><\/p>\n<p>Por supuesto, empezamos a ajustar este valor y descubrimos lo siguiente: en nuestra configuraci\u00f3n, se pueden almacenar en cach\u00e9 bastante bien hasta 300 solicitudes, y un valor mayor conlleva que nuevamente caigamos en Full GC.<\/p>\n<p><\/p>\n<p>Adem\u00e1s, dado que se trata de lotes de mensajes que llegan dentro de una sola solicitud, tambi\u00e9n fue necesario ajustar Graylog para que escribiera no con frecuencia y en peque\u00f1os lotes, sino en grandes lotes o cada 3 segundos, si el lote a\u00fan no est\u00e1 lleno. En tal caso, la informaci\u00f3n que escribimos en Elasticsearch se vuelve accesible no en dos segundos, sino en cinco (lo cual nos parece aceptable), pero se reduce el n\u00famero de reintentos que se deben hacer para empujar un gran lote de informaci\u00f3n.<\/p>\n<p><\/p>\n<p>Esto es especialmente importante en esos momentos en que algo se cae y lo informa con vehemencia, para no recibir un Elasticsearch completamente inundado de spam, y despu\u00e9s de un tiempo, nodos de Graylog que no funcionan debido a b\u00faferes saturados.<\/p>\n<p><\/p>\n<p>Adem\u00e1s, cuando ocurr\u00edan estas explosiones en producci\u00f3n, recib\u00edamos quejas de programadores y testers: en el momento en que realmente necesitaban esos logs, se les proporcionaban muy lentamente.<\/p>\n<p><\/p>\n<p>Comenzamos a investigar. Por un lado, estaba claro que tanto las consultas de b\u00fasqueda como las solicitudes de indexaci\u00f3n se procesan, en esencia, en las mismas m\u00e1quinas f\u00edsicas, y de alguna manera, habr\u00e1 ciertas ca\u00eddas. <\/p>\n<p><\/p>\n<p>Pero esto se pod\u00eda sortear parcialmente gracias a que en las versiones seis de Elasticsearch apareci\u00f3 un algoritmo que permite distribuir las solicitudes entre los nodos de datos relevantes no por un principio aleatorio de round-robin (el contenedor que se encarga de la indexaci\u00f3n y mantiene el primary-shard puede estar muy ocupado, y no habr\u00e1 posibilidad de responder r\u00e1pidamente), sino dirigir esta solicitud a un contenedor menos ocupado con un replica-shard, que responder\u00e1 significativamente m\u00e1s r\u00e1pido. En otras palabras, llegamos a use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>La imagen de lectura comienza a lucir as\u00ed:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La transici\u00f3n a este algoritmo permiti\u00f3 mejorar notablemente el tiempo de consulta en esos momentos en que ten\u00edamos un gran flujo de logs para escribir.<\/p>\n<p><\/p>\n<p>Finalmente, el principal problema era la salida sin dolor del centro de datos.<\/p>\n<p><\/p>\n<p>Lo que quer\u00edamos del cl\u00faster justo despu\u00e9s de la p\u00e9rdida de conexi\u00f3n con un DC: <\/p>\n<p><\/p>\n<ul>\n<li>Si nuestro master actual se encuentra en el centro de datos ca\u00eddo, ser\u00e1 recolocado y su rol pasar\u00e1 a otro nodo en otro DC.<\/li>\n<li>El maestro r\u00e1pidamente expulsar\u00e1 del cl\u00faster todos los nodos inaccesibles.<\/li>\n<li>Bas\u00e1ndose en los nodos restantes, entender\u00e1 que en el centro de datos perdido ten\u00edamos tales shards primarios, r\u00e1pidamente promocionar\u00e1 shards replicados complementarios en los centros de datos restantes y la indexaci\u00f3n de los datos continuar\u00e1. <\/li>\n<li>Como resultado de esto, la capacidad de escritura y lectura del cl\u00faster se degradar\u00e1 gradualmente; sin embargo, en general, todo seguir\u00e1 funcionando, aunque lentamente, de manera estable.<\/li>\n<\/ul>\n<p><\/p>\n<p>Como descubrimos, quer\u00edamos algo as\u00ed:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Y obtuvimos lo siguiente:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00bfC\u00f3mo ocurri\u00f3 esto? <\/p>\n<p><\/p>\n<p>En el momento de la ca\u00edda del centro de datos, el cuello de botella fue el maestro.<\/p>\n<p><\/p>\n<p>\u00bfPor qu\u00e9?<\/p>\n<p><\/p>\n<p>Resulta que en el maestro hay un TaskBatcher, responsable de la distribuci\u00f3n de ciertas tareas y eventos en el cl\u00faster. Cualquier salida de un nodo, cualquier promoci\u00f3n de un shard de r\u00e9plica a primario, cualquier tarea para crear alg\u00fan shard en alg\u00fan lugar, todo esto primero pasa por el TaskBatcher, donde se procesa secuencialmente y en un solo hilo.<\/p>\n<p><\/p>\n<p>En el momento de la salida de un centro de datos, suced\u00eda que todos los nodos de datos en los centros de datos sobrevivientes consideraban su deber informar al maestro \"hemos perdido tales shards y tales nodos de datos\". <\/p>\n<p><\/p>\n<p>Al mismo tiempo, los nodos de datos sobrevivientes enviaban toda esta informaci\u00f3n al maestro actual y trataban de esperar la confirmaci\u00f3n de que \u00e9l la hab\u00eda recibido. No la recib\u00edan, ya que el maestro recib\u00eda las tareas m\u00e1s r\u00e1pido de lo que pod\u00eda responder. Los nodos repet\u00edan las solicitudes debido al tiempo de espera, mientras el maestro ya no intentaba responderles y estaba completamente absorbido por la tarea de clasificar las solicitudes por prioridad.<\/p>\n<p><\/p>\n<p>En t\u00e9rminos terminales, los nodos de datos estaban enviando tanto spam al maestro que \u00e9l llegaba a un full GC. Despu\u00e9s de eso, el rol del maestro se trasladaba a alg\u00fan siguiente nodo, y con \u00e9l suced\u00eda exactamente lo mismo, y al final el cl\u00faster colapsaba por completo. <\/p>\n<p><\/p>\n<p>Hicimos mediciones, y hasta la versi\u00f3n 6.4.0, donde esto fue solucionado, bastaba con sacar simult\u00e1neamente solo 10 nodos de datos de 360 para colapsar completamente el cl\u00faster.<\/p>\n<p><\/p>\n<p>As\u00ed es como se ve\u00eda aproximadamente:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Despu\u00e9s de la versi\u00f3n 6.4.0, donde se arregl\u00f3 este bug problem\u00e1tico, los nodos de datos dejaron de matar al maestro. Pero eso no lo hizo \"m\u00e1s inteligente\". Es decir, cuando sacamos 2, 3 o 10 (cualquier cantidad distinta de uno) nodos de datos, el maestro recibe alg\u00fan primer mensaje que dice que el nodo A sali\u00f3 y trata de informar sobre esto al nodo B, nodo C, nodo D. <\/p>\n<p><\/p>\n<p>En este momento, esto solo se puede abordar estableciendo un tiempo de espera de aproximadamente 20 a 30 segundos para intentar contarle a alguien algo, gestionando as\u00ed la velocidad de salida del centro de datos del cl\u00faster.<\/p>\n<p><\/p>\n<p>En principio, esto se ajusta a los requisitos que se establecieron inicialmente para el producto final en el marco del proyecto, pero desde el punto de vista de la 'ciencia pura', es un error. Que, por cierto, fue corregido exitosamente por los desarrolladores en la versi\u00f3n 7.2.<\/p>\n<p><\/p>\n<p>De hecho, cuando un nodo de datos sal\u00eda, resultaba que difundir la informaci\u00f3n sobre su salida era m\u00e1s importante que contarle a todo el cl\u00faster que en \u00e9l se encontraban ciertos primary-shard (para promover un replica-shard en otro centro de datos a primary, donde se pod\u00eda escribir informaci\u00f3n).<\/p>\n<p><\/p>\n<p>Por lo tanto, una vez que todo 'ha pasado', los nodos de datos que han salido no se marcan como stale de inmediato. En consecuencia, tenemos que esperar hasta que todos los pings a los nodos de datos salidos se agoten y solo despu\u00e9s de esto nuestro cl\u00faster comienza a informar que en cierto lugar se debe continuar grabando informaci\u00f3n. Se puede leer m\u00e1s sobre esto. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">aqu\u00ed<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Como resultado, la operaci\u00f3n de salida del centro de datos hoy nos lleva alrededor de 5 minutos en hora pico. Para una m\u00e1quina tan grande y poco \u00e1gil, es un resultado bastante bueno.<\/p>\n<p><\/p>\n<p>Finalmente, llegamos a la siguiente soluci\u00f3n:<\/p>\n<p><\/p>\n<ul>\n<li>Tenemos 360 nodos de datos con discos de 700 gigabytes.<\/li>\n<li>60 coordinadores para enrutar el tr\u00e1fico a estos nodos de datos.<\/li>\n<li>40 maestros, que nos han quedado como un legado de las versiones anteriores a 6.4.0: para sobrevivir la salida del centro de datos, est\u00e1bamos moralmente preparados para perder algunas m\u00e1quinas, para garantizar que incluso en el peor escenario tuvi\u00e9ramos un qu\u00f3rum de maestros.<\/li>\n<li>Cualquier intento de combinar roles en un mismo contenedor se topaba con el hecho de que tarde o temprano el nodo fallaba bajo carga. <\/li>\n<li>En todo el cl\u00faster se utiliza un heap.size de 31 gigabytes: todos los intentos de reducir el tama\u00f1o conduc\u00edan a que en b\u00fasquedas pesadas con wildcard inicial ya sea se mataran algunos nodos o se activara el circuit breaker en Elasticsearch.<\/li>\n<li>Adem\u00e1s, para garantizar el rendimiento de b\u00fasqueda, tratamos de mantener la cantidad de objetos en el cl\u00faster lo m\u00e1s baja posible, para manejar la menor cantidad de eventos en el punto m\u00e1s cr\u00edtico, que se encontr\u00f3 en el maestro.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Por \u00faltimo, sobre la monitorizaci\u00f3n<\/h2>\n<p><\/p>\n<p>Para que todo esto funcione como se pens\u00f3, supervisamos lo siguiente:<\/p>\n<p><\/p>\n<ul>\n<li>Cada nodo de datos informa a nuestra nube que est\u00e1 presente y que tiene ciertos shards. Cuando apagamos algo en alg\u00fan lugar, el cl\u00faster informa en 2-3 segundos que hemos apagado los nodos 2, 3 y 4 en el centro A; esto significa que en otros centros de datos no podemos apagar aquellos nodos que a\u00fan tienen shards en un solo ejemplar.<\/li>\n<li>Conociendo el comportamiento del maestro, observamos atentamente la cantidad de tareas pendientes. Porque incluso una tarea atascada, si no se timeouta a tiempo, puede te\u00f3ricamente convertirse en la raz\u00f3n por la cual no se realizar\u00e1, por ejemplo, la promoci\u00f3n de un shard replica a primary, lo que detendr\u00eda la indexaci\u00f3n.<\/li>\n<li>Tambi\u00e9n miramos de cerca las demoras del recolector de basura, porque ya hemos tenido grandes dificultades con esto durante la optimizaci\u00f3n.<\/li>\n<li>Rechazos por hilos, para entender de antemano d\u00f3nde est\u00e1 el 'cuello de botella'.<\/li>\n<li>Y las m\u00e9tricas est\u00e1ndar, como heap, RAM y I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Al construir la supervisi\u00f3n, es indispensable considerar las caracter\u00edsticas del Thread Pool en Elasticsearch. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">La documentaci\u00f3n de Elasticsearch<\/a><\/noindex> describe las posibilidades de configuraci\u00f3n y los valores predeterminados para la b\u00fasqueda y la indexaci\u00f3n, pero omite por completo thread_pool.management. Estos hilos manejan, entre otros, solicitudes del tipo _cat\/shards y otras similares que son convenientes para escribir la supervisi\u00f3n. Cuanto m\u00e1s grande es el cl\u00faster, m\u00e1s de estas solicitudes se realizan por unidad de tiempo, y el mencionado thread_pool.management, adem\u00e1s de no estar representado en la documentaci\u00f3n oficial, est\u00e1 limitado por defecto a 5 hilos, lo que se agota muy r\u00e1pido, despu\u00e9s de lo cual la supervisi\u00f3n deja de funcionar correctamente.<\/p>\n<p><\/p>\n<p>Lo que quiero decir en conclusi\u00f3n es: \u00a1lo hemos logrado! Hemos conseguido dar a nuestros programadores y desarrolladores una herramienta que pr\u00e1cticamente en cualquier situaci\u00f3n puede proporcionar informaci\u00f3n r\u00e1pida y confiable sobre lo que est\u00e1 sucediendo en producci\u00f3n.<\/p>\n<p><\/p>\n<p>S\u00ed, result\u00f3 bastante complicado, pero aun as\u00ed, logramos encajar nuestras necesidades en los productos existentes que no tuvimos que parchear ni reescribir a medida.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cl\u00faster de Elasticsearch de 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Fuente: <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.2 - 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\/es\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\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\/es\/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\udd47Cl\u00faster de Elasticsearch de 200 TB+ | ProHoster","description":"Muchas personas se enfrentan a Elasticsearch.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}