Los 10 problemas más comunes en clusters de Elasticsearch

Los 10 problemas más comunes en clusters de Elasticsearch

En NowBit ofrecemos un servicio de diagnóstico para clientes que usan Elasticsearch, nuestro Elastic Quick Review. En éste artículo. consolidamos los hallazgos más comunes que hemos encontrado luego de ejecutar decenas de EQR:

1. Oversharding:

El Oversharding es un problema muy común en despliegues de Elasticsearch, para entenderlo, es necesario dar un resumen de la base del funcionamiento de un cluster de Elasticsearch.

En primer lugar, un cluster se compone de varios nodos de Elasticsearch (al menos 3 en entornos productivos), en un cluster puedes alojar uno o más índices, donde viven los datos (documentos en formato json) y finalmente, cada índice se compone de uno o más shards (de dos tipos: primarios y réplicas). Los shards son la unidad mínima de trabajo de Elasticsearch y son una instancia de Lucene (sobre lo que está escrito Elasticsearch), funcionando para ofrecer las capacidades que Elasticsearch ofrece.

Los shards tienen un costo, requieren CPU, memoria y almacenamiento para su funcionamiento, un problema de oversharing no es más que la incapacidad del hardware para soportar la cantidad de shards creados.

  • Causas principales:
    • Muchos shards de poco tamaño, causado por creación de shards a diario en casos de observabilidad y seguridad (logs y métricas).

      Shards de gran tamaño (más de 50GB), causado por la creación de indices únicos en casos de datos basados en el tiempo.

  • Estrategias de solución:
    • Consolidación de shads, de un tamaño no mayor a los 50GB.
    • Eliminación de índices automático a través de Index Lifecycle Management.
    • Congelamiento de índices históricos.

2. Cluster en estado amarillo o rojo:

Este es una situación más común de lo que se puedan imaginar y sucede porque los shards (de los que hablamos antes), no se están asignando correctamente:

  • Estado amarillo: Sucede cuando los shards tipo réplica no tienen nodos de Elasticsearch para instanciarse, en general es porque el cluster no tiene nodos suficientes para ello, pues un shard réplica nunca se instanciará donde está su dhard primario.

  • Estado rojo: Sucede porque un shard primario no se puede instanciar, esto puede ser grave, porque los datos no podrán ser leídos ni escritos.

  • Causas principales:
    • Para el estado amarillo, la causa principal es que hace falta adicionar nodos para las réplicas.

      Para el estado rojo, la causa principal es que algún nodo que funcionaba ya no está operativo o que los datos en disco perdieron su integridad y no son consistentes.

  • Estrategias de solución:
    • Es necesario un diagnóstico detallado para poder definir un plan de solución. Redimensionar el cluster en caso de cluster amarillo y recuperar datos a través de copias de respaldo para estado rojo, son las estretegias más comunes en ambos casos.

3. Login anónimo:

Muchos clientes utilizan la licencia Basic de Elasticsearch (gratuita) y tienen la idea errónea de que esa licencia no tiene características de seguridad (en versiones anteriores era así), por lo que no habilitan la autenticación lo que trae como consecuencia problemas de seguridad y en muchos casos, pérdida de datos fruto de ataques a clusters desprotegidos con acceso público.

  • Causas principales:
    • En un inicio, la característica de autenticación era licenciada y no se incluía en la licencia Basic, por lo que implementaciones de esta edición quedaron desprotegidas.

      Desconocimiento de las características incluidas en cada versión de Elasticsearch.

  • Estrategias de solución:
    • Actualizar al menos a la versión 7.2 y activar la seguridad básica Elasticsearch (RBAC). Para integración con gestores de identidades por LDAP, Active Directory, OAuth, SAML entre otros, es requerido licenciamiento Platinum como mínimo.

4. Campos mal definidos y deficiencias usando ECS:

La creciente adopción de los casos de uso de Elastic en términos de Observabilidad (Logging, Metrics, APM) y Seguridad (XDR y SIEM), hizo necesario que Elastic definiera un estándar de nomenclatura para los campos en los índices de Elasticsearch, esto se conoce como el Elastic Common Schema.

El ECM permite que la información sea procesada correctamente por las aplicaciones de Observabilidad y Seguridad incluidas en Kibana y simplifica la definición del mapping para las fuentes de datos que se ingestan y no tienen una integración a través del Elastic Agent o Beats. Dado que muchas compañías llevan ingestando datos desde antes de la existencia del ECS, es muy común encontrar casos como campos que son de tipo IP ingestados como string y similares; también hemos visto clientes que ingestan información para el SIEM, pero esos datos no se logran ver en la aplicación de Seguridad. Todo esto sucede por no utilizar ECS en la definición del mapping de campos.

  • Causas principales:
    • Desconocimiento de la existencia de los index templates logs* y metrics* cuando se realiza la ingesta de datos, pues estos templates tienen la definición de ECM construida y usar los templates simplifica la ingesta.

      Poco procesamiento de los datos a través de Logstash teniendo como premisa su homologación con la documentación del Elastic Common Schema.

  • Estrategias de solución:
    • Leer la documentación del Elastic Common Schema para familiarizarse con el mapping correcto y hacer uso de los index templates tanto definidos por Elastic, como construidos de forma personalizada para simplificar el mapping desde la ingesta de datos.

5. Explosión de mapping:

Esta es una situación común que genera problemas de desempeño e indisponibilidad y es una consecuencia usual del punto anterior. Aquí es necesario explicar un aspecto técnico: La razón por la cuál Elasticsearch es capaz de devolver datos prácticamente en tiempo real, es porque tiene un par de estructuras de datos que se cargan en memoria, la primera se llama inverted index y la segunda doc values.

El inverted index mantiene en memoria los datos analizados que se utilizan en los casos de uso de búsqueda a través de tokens. Los Doc Values mantienen en memoria los datos de tipo keyword o exactos, como los que se usan en filtros para casos de observabilidad y seguridad, por ejemplo.

El problema de explosión de mapping sucede cuando un índice tiene más de 1000 campos, aquí los shards del índice tienen un trabajo enorme colocando esa cantidad de campos en las dos estructuras de datos, lo que conlleva a un problema grave de desempeño en el cluster.

  • Causas principales:
    • Los campos que se ingestan cambian desde el origen, esto para el índice son campos nuevos que se adicionan al mapping inicial incrementando los campos totales del índice.

      Por defecto, Elasticsearch no restringe que si el mapping inicial cambia, los campos nuevos dejen de ser indexados (dynamic mapping), es decir, si un dato lleva 5 campos nuevos que antes no estaban en el índice, estos serán indexados y el mapping del índice tendrá 5 campos más.

  • Estrategias de solución:
    • Una vez definido el mapping que tendrá el índice (usando el ECS), deshabilitar el dynamic mapping por cada índice.
    • Validar que la fuente de datos no genere datos fuera del mapping y si lo hace, estos puedan ser omitidos usando Logstash o similares.

6. Cluster de menos de 3 nodos y Split Brain:

Una de las preguntas más comunes que realizan los clientes es: ¿por qué es necesario tener un cluster de al menos 3 nodos en ambientes productivos?, básicamente es por dos razones:

En primer lugar, la gestión de los nodos maestros en Elasticsearch funciona distinto a otras tecnologías, en Elasticsearch no puedes definir qué nodo será el maestro, sino cuáles son elegibles como maestros y la decisión de cuál será el maestro la realiza Elasticsearch mediante una votación entre los elegibles como maestros, para que la votación tenga quórum, se debe tener un número impar de nodos elegibles como maestros y el número impar más pequeño es 3.

En segundo lugar, imaginemos un caso común: Tienes un cluster de dos nodos, presentan una desconexión de red entre esos dos nodos y no tienes configurado un parámetro que valida la existencia de menos dos nodos maestros para el inicio del cluster. Lo que sucederá en este caso es que cada nodo subirá como un cluster independiente con datos parciales, esto, a su vez, causará pérdida de la información almacenada. A este comportamiento se le conoce como Split Brain.

La mejor forma de garantizar tolerancia a fallos y alta disponibilidad de los datos es tener al menos tres nodos en un entorno productivo.

  • Causas principales:
    • Utilizar cluster de menos de 3 nodos en entornos productivos.

      No configurar el parámetro que define los nodos maestros mínimos para levantar el cluster.

  • Estrategias de solución:
    • Implementar clusters con al menos 3 nodos de Elasticsearch para entornos productivos.
    • Habilitar el parámetro minimum_master_nodes en la configuración de Elasticsearch.

7. Ausencia de Snapshots:

Los snapshots son el mecanismo de copias de respaldo de la información almacenada en Elasticsearch; en muchos casos, los clientes tienen la percepción errada que las réplicas de la información en Elasticsearch es suficiente como estrategia de copia de seguridad, sin embargo, el objetivo de las réplicas es ofrecer alta disponibilidad y tolerancia a fallos.

Supongamos que se envía una actualización de datos y por error se modifican o eliminan datos, tanto los shard primarios como las réplicas tendrán datos errados; en ese caso, la única forma de recuperar la información será a través de la restauración de un snapshot.

Elasticsearch cada vez ofrece más alternativas para alojar snapshots: carpetas compartidas, HDFS de Hadoop, Amazon S3, Azure Storage, Google Cloud Storage, entre otros. Cualquiera de ellos puede ofrecer una solución rápida de copias de respaldo para los datos almacenados en Elasticsearch, esto incluye tanto los índices de datos, como índices de sistema en donde están los dashboards, búsquedas y demás parámetros propios del caso de uso.

  • Causas principales:
    • Desconocimiento de la simplicidad de implementación de los snapshots.

      Creencia errónea que las réplicas son suficientes para la seguridad de los datos.

  • Estrategias de solución:
    • Definición de una estrategia de copias de respaldo alineadas con los RPO y RTO de la compañía y la implementación de un repositorio de snapshots de acuerdo con los lineamientos de arquitectura de la compañía.

8. Ciclos de actualización demasiado largos:

Elastic tiene una política de versiones con lanzamientos en intervalos muy cortos; muchos clientes tienen políticas de administración de plataformas con actividades de actualización cada año o cada semestre, dado que Elastic lanza versiones en promedio cada dos meses, tener ciclos de actualización tan largos genera que a la hora de actualizar sea necesaria una migración porque la estructura de los índices, la compatibilidad de las visualizaciones, entre otros, ya no serán compatibles por lo que el proceso de actualización resulta ser tedioso y engorroso.

  • Causas principales:
    • Temor a realizar cambios por actualizaciones en periodos más cortos por los posibles incidentes que puedan generar y las certificaciones de cambios que se deban realizar.

      Desconocimiento del detalle del caso de uso y las implicaciones que podría tener una actualización.

  • Estrategias de solución:
    • Implementar un ambiente de pruebas de Elasticsearch homólogo al de producción, donde se puedan probar rápidamente las nuevas versiones y acortar los ciclos de actualización de Elastic.

9. Cluster no operativo por espacio en disco:

Por defecto, cuando el espacio ocupado es del 85% en los nodos de Elasticsearch, automáticamente el cluster coloca todos los índices en estado de solo lectura. Esto genera que el cluster queda inoperativo generando indisponibilidad absoluta.

  • Causas principales:
    • Ausencia de monitoreo y alertamiento de las variables de desempeño del cluster.

      Ausencia de políticas de Index Lifecycle Management (ILM), para garantizar eliminación automática de datos históricos.

  • Estrategias de solución:
    • Implementar mecanismos de monitoreo que permitan la identificación oportuna de variables de desempeño que puedan presentar inconvenientes futuros.
    • Gestión del ciclo de vida del índice a través de ILM acordes con lineamientos de retención e históricos.
    • Realizar actividades periódicas de planeación de capacidad para provisionar oportunamente los posibles crecimientos en la ingesta de datos.

10. Subutilización de las capacidades de Elasticsearch:

Aunque suene algo contradictorio sobre los puntos anteriores, aquí nos referimos más a los casos de uso. Muchas compañías incursionan en Elastic con un caso de uso específico entre los tres principales:

  • Búsqueda (Elastic Enterprise Search):
    • Búsqueda en aplicaciones (Elastic App Search)
    • Búsqueda en sitios web (Elastic Site Search)
    • Búsqueda en el sitio de trabajo (Elastic Workplace Search)
  • Observabilidad (Elastic Observability):
    • Logs
    • Métricas
    • APM (Application Performance Monitoring)
  • Seguridad (Elastic Security):
    • SIEM
    • Endpoint (XDR)

Es muy común que un cliente que usa Elastic en un caso de uso, no sepa que puede usar el mismo producto para cualquiera de los otros casos de uso. También es común que un cliente que adopta un caso de uso, no tenga claro que hay características de Elastic que pueden enriquecer su caso actual, algunos ejemplos:

  • Un cliente que utiliza Elastic para las búsquedas de su e-commerce no sabe que el monitoreo y observabilidad de toda la infraestructura de ese e-commerce puede ser monitoreada y observada por Elastic.
  • Un cliente que utiliza Elastic para centralizar los logs de sus plataformas tecnológicas no sabe que puede usar Elastic Machine Learning para encontrar anomalías y entrenar modelos para generar predicciones sobre los datos.
  • Causas principales:
    • La principal causa es desconocimiento principalmente generado porque las adopciones resuelven una problemática específica.

  • Estrategias de solución:
    • Aprovechar el material disponible de Elastic y NowBit para conocer más sobre las posibilidades al usar Elastic.

Si llegaste hasta aquí, agradecemos tu lectura y como recompensa, si usas Elastic en tu organización, podemos realizar de forma gratuita un Elastic Quick Review en tu despliegue, simplemente déjanos tus datos en nuestro formulario de contacto.

Finalmente, si alguno de éstos problemas te son familiares y necesitas apoyo para resolverlos, cuenta con nuestro apoyo, ponte en contacto con nosotros para ayudarte.

Compartir:

NowBit

  • 4 minutos de lectura

  • Sep 24, 2020