Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Solución de problemas comunes de fallos en la asignación de shards de Elasticsearch

Aprenda a solucionar y resolver fallos comunes en la asignación de shards de Elasticsearch. Esta guía cubre la identificación de shards no asignados, el diagnóstico de problemas como errores de espacio en disco, indisponibilidad de nodos y filtrado de asignación, y proporciona soluciones prácticas y mejores prácticas para mantener un clúster de Elasticsearch saludable.

29 vistas

Solución de problemas comunes de fallos en la asignación de shards de Elasticsearch

Elasticsearch, un potente motor distribuido de búsqueda y análisis, depende en gran medida de su capacidad para distribuir datos a través de múltiples nodos utilizando shards (fragmentos). Cuando estos shards no se asignan, puede provocar la indisponibilidad de los datos, fallos en la búsqueda y un estado de clúster degradado. Comprender las causas comunes de los fallos de asignación de shards y saber cómo diagnosticarlos y resolverlos es crucial para mantener un entorno Elasticsearch estable y de alto rendimiento. Este artículo lo guiará a través de los problemas más frecuentes y proporcionará pasos prácticos para que sus shards vuelvan a un estado asignado.

Esta guía se centra en la solución práctica de problemas para entornos de producción de Elasticsearch. Cubriremos la identificación de shards no asignados, la comprensión de las razones comunes de los fallos, como el espacio en disco, las reglas de asignación y los problemas de los nodos, y proporcionaremos pasos claros para resolver estos problemas de manera eficiente. Al dominar estas técnicas, puede minimizar el tiempo de inactividad y garantizar la fiabilidad de su clúster de Elasticsearch.

Identificación de shards no asignados

El primer paso para la solución de problemas es identificar qué shards no están asignados y por qué. Elasticsearch proporciona varias herramientas para esto:

Uso de la API de estado del clúster

La API _cluster/health proporciona una visión general de alto nivel del estado de su clúster. Busque unassigned_shards en la respuesta. Un valor distinto de cero indica un problema.

GET _cluster/health

Fragmento de respuesta de ejemplo:

{
  "cluster_name": "my-es-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 10,
  "active_shards": 20,
  "relocating_shards": 0,
  "initializing_shards": 1,
  "unassigned_shards": 1,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "max_length_search_concurrency": 1000,
  "max_length_search_size": 10000,
  "active_shards_percent_as_number": 95.45454545454545
}

En este ejemplo, "status": "yellow" y "unassigned_shards": 1 indican que hay un shard no asignado. Un estado red (rojo) significa que uno o más shards primarios no están asignados, lo que afecta la disponibilidad de los datos. Un estado yellow (amarillo) significa que los shards de réplica no están asignados, pero los shards primarios sí lo están, por lo que sus datos siguen siendo buscables, pero no son totalmente redundantes.

Uso de la API de explicación de la asignación

Para obtener información detallada sobre por qué un shard específico no está asignado, la API _cluster/allocation/explain es invaluable. Puede proporcionar detalles del shard o permitir que analice el estado del clúster.

Para obtener una explicación de cualquier shard no asignado:

GET _cluster/allocation/explain

Para obtener una explicación para un shard específico (reemplace index_name y shard_id):

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

Causas comunes y soluciones

Varios factores pueden hacer que los shards no se asignen. Estas son las más comunes y cómo abordarlas:

1. Espacio en disco insuficiente

Esta es posiblemente la causa más frecuente de fallos en la asignación de shards. Cuando un nodo se queda sin espacio en disco, Elasticsearch evita que se le asignen nuevos shards para evitar la corrupción de datos y garantizar la estabilidad. También podría desalojar los shards existentes.

  • Síntoma: La Allocation Explain API a menudo reportará mensajes como "cannot allocate because disk usage [X%] exceeds the low watermark [Y%]" o "cannot allocate because disk usage [X%] exceeds the high watermark [Y%]".
  • Diagnóstico: Compruebe el uso del disco en sus nodos de datos. Puede usar la API _cat/allocation para una visión general rápida:
    bash GET _cat/allocation?v
    Busque nodos con porcentajes altos de uso de disco.
  • Soluciones:
    • Agregar más espacio en disco: La solución más sencilla es agregar más almacenamiento a los nodos afectados o reemplazar los discos existentes por otros más grandes.
    • Eliminar índices no utilizados: Identifique y elimine índices antiguos o innecesarios que estén consumiendo espacio en disco.
    • Ajustar las marcas de agua: Puede ajustar las marcas de agua de uso del disco (cluster.routing.allocation.disk.watermark.low, cluster.routing.allocation.disk.watermark.high, cluster.routing.allocation.disk.watermark.flood_stage) en su configuración elasticsearch.yml o dinámicamente a través de la API de configuración del clúster. Sin embargo, se recomienda precaución al ajustarlas, ya que están diseñadas para proteger su clúster. Reducirlas sin agregar capacidad puede generar problemas adicionales.
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.disk.watermark.low": "85%", "cluster.routing.allocation.disk.watermark.high": "90%", "cluster.routing.allocation.disk.watermark.flood_stage": "95%" } }
    • Agregar más nodos: Escale su clúster agregando más nodos de datos. Esto distribuye los datos y reduce la carga en los nodos individuales.
    • Forzar fusión o eliminar datos antiguos: Si tiene datos de series de tiempo, considere usar la API _forcemerge en índices más antiguos para reducir la cantidad de segmentos (lo que puede liberar espacio en disco) o use la gestión del ciclo de vida del índice (ILM) para eliminar datos antiguos automáticamente.

2. Nodo no disponible o reiniciándose

Si un nodo está caído, reiniciándose o experimentando problemas de red, cualquier shard que resida en ese nodo quedará sin asignar. Si es un shard primario, el estado del clúster se volverá rojo.

  • Síntoma: La Allocation Explain API indicará que el shard no se puede asignar porque el nodo no está disponible o está marcado como (excluded) debido a que está caído.
  • Diagnóstico: Use la API _cat/nodes para verificar el estado de sus nodos. Asegúrese de que todos los nodos esperados estén listados y en buen estado.
    bash GET _cat/nodes?v
    Compruebe los registros de Elasticsearch en el nodo afectado para detectar cualquier error o signo de apagado.
  • Soluciones:
    • Reiniciar el nodo: Si el nodo está inactivo, intente reiniciar el servicio de Elasticsearch.
    • Resolver problemas de red: Asegúrese de que el nodo pueda comunicarse con otros nodos del clúster.
    • Comprobar registros: Examine los registros de Elasticsearch para el nodo específico para identificar la causa raíz del fallo (p. ej., falta de memoria, errores de disco, problemas de JVM).
    • Aumentar index.unassigned.node_left.delayed_timeout: Si los nodos se unen y abandonan el clúster con frecuencia (p. ej., durante reinicios graduales), es posible que vea que los shards de réplica quedan sin asignar temporalmente. La configuración index.unassigned.node_left.delayed_timeout (valor predeterminado de 1 minuto) permite que Elasticsearch espere antes de marcar los shards en un nodo que se ha ido como no asignados, dándole tiempo al nodo para volver a unirse. Aumente este valor si es necesario, pero tenga en cuenta el impacto en el tiempo de recuperación.

3. Reglas de filtrado y reconocimiento de asignación

Elasticsearch le permite controlar dónde se asignan los shards utilizando varias reglas de asignación, como atributos de nodo y antiafinidades. Si estas reglas impiden la asignación, los shards pueden quedar sin asignar.

  • Síntoma: La Allocation Explain API informará que la asignación está deshabilitada para atributos específicos o que no hay nodos adecuados disponibles de acuerdo con las reglas configuradas.
  • Diagnóstico:
    • Verifique la configuración de su índice para index.routing.allocation.require.*, index.routing.allocation.include.*, index.routing.allocation.exclude.* y index.routing.allocation.total_shards_per_node.
    • Verifique la configuración a nivel de clúster para cluster.routing.allocation.enable (p. ej., all, primaries, new_primaries, none).
    • Verifique los atributos del nodo usando GET _cat/nodeattrs?v.
  • Soluciones:
    • Actualizar la configuración del índice: Elimine o ajuste las reglas restrictivas de enrutamiento de índices. Por ejemplo, para permitir la asignación a cualquier nodo:
      json PUT my-index/_settings { "index": { "routing": { "allocation": { "require": null, "include": null, "exclude": null } } } }
    • Actualizar la configuración del clúster: Habilite temporalmente la asignación si estaba deshabilitada:
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "all" } }
      Recuerde revertir esta configuración si solo estaba destinada a ser temporal.
    • Actualizar atributos del nodo: Asegúrese de que sus nodos tengan los atributos esperados definidos en elasticsearch.yml (p. ej., node.attr.zone: us-east-1) y que estos atributos se alineen con sus reglas de asignación. Después de cambiar elasticsearch.yml, los nodos deben reiniciarse para que los cambios surtan efecto.

4. Datos de shard corruptos (Raro)

En raras ocasiones, los datos de los shards pueden corromperse, lo que impide que Elasticsearch se inicie o asigne el shard. Esto es más común con problemas de disco subyacentes.

  • Síntoma: Los registros pueden mostrar errores relacionados con la lectura de datos de shards o la corrupción del índice. La Allocation Explain API podría no dar una razón clara o podría señalar un error de lectura.
  • Diagnóstico: Examine de cerca los registros de Elasticsearch en el nodo donde se espera que se encuentre el shard. Busque errores de E/S o mensajes de corrupción de datos.
  • Soluciones:
    • Restaurar desde instantánea (Snapshot): La solución más fiable es restaurar el índice afectado (o todo el clúster) a partir de una instantánea conocida y buena. Por eso las copias de seguridad periódicas son fundamentales.
    • Forzar la eliminación del Shard (Último recurso): Si no puede restaurar a partir de una instantánea y los datos no son críticos o pueden volver a indexarse, es posible que deba forzar la eliminación del shard corrupto. Esta es una operación avanzada y solo debe realizarse cuando comprenda las implicaciones. Por lo general, debe detener el nodo afectado, eliminar el directorio de datos del shard manualmente y luego reiniciar el nodo. Esto resultará en la pérdida de datos para ese shard. Consulte la documentación de Elasticsearch para conocer el procedimiento exacto para su versión.

5. Capacidad de reubicación insuficiente

Cuando un nodo abandona el clúster o surgen problemas de espacio en disco, Elasticsearch intenta reubicar los shards en otros nodos. Si no hay suficientes nodos adecuados o si el clúster ya está bajo una carga pesada, la reubicación de shards puede estancarse, lo que lleva a initializing_shards o unassigned_shards.

  • Síntoma: Los shards permanecen en estado initializing (inicializando) o relocating (reubicando) durante períodos prolongados, o los nuevos shards no se asignan.
  • Diagnóstico: Compruebe _cat/shards y _cat/allocation para ver el estado de los shards y el uso del disco. Supervise el estado del clúster y la utilización de CPU/E/S de los nodos.
  • Soluciones:
    • Agregar más nodos: Aumente la capacidad de su clúster agregando más nodos de datos.
    • Liberar recursos: Aborde cualquier cuello de botella de rendimiento en los nodos existentes (p. ej., CPU alta, E/S de disco lenta).
    • Ajustar la configuración de asignación de Shards: Puede ajustar configuraciones como cluster.routing.allocation.node_concurrent_recoveries (número de shards que se pueden recuperar simultáneamente en un nodo) y cluster.routing.allocation.node_concurrent_incoming_recoveries (número de shards que se pueden recuperar simultáneamente desde otro nodo). Sin embargo, tenga cuidado ya que aumentar estos valores puede ejercer más presión sobre el clúster.

Mejores prácticas para la prevención

  • Monitorear el espacio en disco: Supervise proactivamente el uso del disco en todos los nodos de datos. Configure alertas para cuando el uso del disco cruce umbrales predefinidos (p. ej., 80% o 85%).
  • Implementar la gestión del ciclo de vida del índice (ILM): Automatice la gestión de datos de series de tiempo, incluida la rotación, la reducción y la eliminación de índices antiguos. Esto ayuda a controlar el uso del espacio en disco.
  • Instantáneas periódicas (Snapshots): Asegúrese de tener una estrategia de respaldo sólida con instantáneas automáticas y periódicas de sus datos. Pruebe su proceso de restauración periódicamente.
  • Comprender las reglas de asignación: Planifique y configure cuidadosamente las reglas de asignación de shards en función de sus requisitos de hardware, datos y disponibilidad.
  • Hardware adecuado: Asegúrese de que sus nodos tengan suficiente capacidad de CPU, RAM y E/S para manejar la carga de trabajo y los procesos de recuperación de shards.
  • Monitoreo del estado del clúster: Verifique regularmente el estado de su clúster utilizando la API _cluster/health y visualícelo con herramientas como Stack Monitoring de Kibana.

Conclusión

Los fallos en la asignación de shards en Elasticsearch pueden ser un problema desalentador, pero al diagnosticar sistemáticamente el problema utilizando herramientas como la Cluster Health API y la Allocation Explain API, y al comprender las causas comunes como el espacio en disco, la disponibilidad de los nodos y las reglas de asignación, puede resolverlos eficazmente. El monitoreo proactivo y la adhesión a las mejores prácticas, como las copias de seguridad periódicas y la ILM, son clave para prevenir estos problemas en primer lugar y garantizar un clúster de Elasticsearch estable y saludable.