Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Problemas de asignación de shards en Elasticsearch: Causas y soluciones

Solucione problemas comunes de fallos en la asignación de shards de Elasticsearch que conducen a un estado de clúster Amarillo o Rojo. Esta guía explica las causas críticas, incluyendo umbrales de espacio en disco, discrepancias en los atributos de los nodos y la pérdida de shards primarios. Aprenda a usar eficazmente la API de Allocation Explain y a aplicar comandos prácticos para restaurar la estabilidad del clúster y asegurar la disponibilidad de los datos.

49 vistas

Problemas de Asignación de Shards en Elasticsearch: Causas y Soluciones

Los clústeres de Elasticsearch están diseñados para la resiliencia y la alta disponibilidad, y dependen en gran medida de la distribución y asignación adecuadas de los shards entre los nodos. Cuando un shard no logra pasar de un estado UNASSIGNED (SIN ASIGNAR) o INACTIVE (INACTIVO) a un primario o réplica activo, el indicador de salud del clúster a menudo se vuelve amarillo o rojo. Comprender por qué los shards no se están asignando es crucial para mantener un motor de búsqueda saludable, con buen rendimiento y disponible.

Esta guía profundiza en las causas comunes de los fallos en la asignación de shards, desde recursos insuficientes del clúster hasta configuraciones erróneas, y proporciona soluciones prácticas y accionables para resolver estos problemas, asegurando que sus datos estén debidamente indexados y sean consultables.

Entendiendo los Estados y la Asignación de Shards

Antes de solucionar problemas, es esencial saber qué está intentando hacer Elasticsearch. Los shards son la unidad fundamental de distribución en Elasticsearch. Pueden existir en varios estados:

  • STARTED (INICIADO): El shard está activo y atiende solicitudes (Primario o Réplica).
  • RELOCATING (REUBICANDO): El shard se está moviendo de un nodo a otro (durante el reequilibrio o la adición/eliminación de nodos).
  • INITIALIZING (INICIALIZANDO): Se está creando un nuevo shard de réplica a partir del primario.
  • UNASSIGNED (SIN ASIGNAR): El shard existe en los metadatos del estado del clúster pero no está asignado a ningún nodo, a menudo porque el nodo requerido no está disponible o no se cumplen los criterios.

La salud del clúster se determina por la presencia de shards no asignados:

  • Green (Verde): Todos los shards primarios y de réplica están asignados.
  • Yellow (Amarillo): Todos los shards primarios están asignados, pero uno o más shards de réplica no lo están.
  • Red (Rojo): Uno o más shards primarios no están asignados (lo que indica riesgo de pérdida de datos si falla el nodo que aloja el shard primario).

Causas Comunes de Fallos en la Asignación de Shards

La asignación de shards es administrada por la lógica del decisor de asignación del clúster, que verifica numerosos factores antes de colocar un shard. El fallo generalmente se debe a una violación de uno de estos puntos de decisión.

1. Recursos Insuficientes del Clúster

Esta es quizás la causa más frecuente de bloqueos en la asignación, especialmente en entornos dinámicos.

Umbrales de Espacio en Disco

Elasticsearch deja de asignar automáticamente nuevos shards (tanto primarios como de réplica) a un nodo si su uso de disco supera los umbrales predefinidos. Por defecto, la asignación se detiene al 85% de uso y se impide totalmente la asignación al 90%.

Umbrales Predeterminados (Verificar elasticsearch.yml o Configuración del Clúster):

Configuración Valor Predeterminado Descripción
cluster.routing.allocation.disk.watermark.low 85% Umbral en el que el nodo se considera relativamente lleno.
cluster.routing.allocation.disk.watermark.high 90% Umbral en el que se bloquea la asignación al nodo.
cluster.routing.allocation.disk.watermark.flood_stage 95% La asignación se detiene por completo, y las operaciones de indexación/escritura pueden fallar.

Solución: Verifique el uso de disco en todos los nodos y libere espacio o añada más espacio en disco a los nodos que superan el umbral alto (high watermark).

Presión de Memoria y CPU

Aunque es menos común que los problemas de disco, el uso persistente de memoria alta o la carga alta de CPU en los nodos puede impedir que se asignen nuevos shards, ya que los decisores de asignación prefieren nodos con suficiente margen operativo.

2. Desajuste de Roles y Atributos de Nodos

Las implementaciones modernas de Elasticsearch a menudo utilizan nodos maestros, de ingesta o de coordinación dedicados. Los shards no se asignarán a nodos que no cumplan con los criterios requeridos.

Reglas de Asignación Desajustadas

Si ha configurado ajustes específicos del índice que requieren que los shards se coloquen en nodos etiquetados con ciertos atributos (por ejemplo, SSD rápidos), pero ningún nodo disponible coincide con esa etiqueta, los shards permanecerán sin asignar.

Ejemplo: Un índice creado con index.routing.allocation.require.box_type: high_io solo se asignará a nodos configurados explícitamente con esa configuración.

Solución: Verifique las reglas de asignación (allocation.require, allocation.include, allocation.exclude) para el índice afectado y asegúrese de que los nodos posean la configuración correcta de node.attr.

3. Estabilidad del Estado del Clúster y Fallos en la Asignación Primaria (Salud Roja)

Si los shards primarios no están asignados (clúster en ROJO), significa que el nodo que albergaba la última copia primaria ha fallado o ha abandonado el clúster, y ningún shard de réplica disponible puede ser promovido a primario.

Escenarios Comunes:
* Un nodo que aloja la única copia primaria se bloquea inesperadamente.
* El nodo que contiene el shard primario se elimina explícitamente del clúster antes de que las réplicas se copiaran con éxito.

Solución: Si el nodo fallido no se puede recuperar rápidamente, es posible que deba forzar la asignación manualmente anulando el bloqueo primario, pero esto conlleva un alto riesgo de pérdida de datos para esos shards específicos.

4. Límites y Cuotas de Shards

Elasticsearch impone límites para evitar la creación descontrolada de shards que podría desestabilizar el clúster.

Máximo de Shards por Nodo

Si un nodo ha alcanzado su número máximo configurado de shards (cluster.routing.allocation.total_shards_per_node), no se le asignarán más shards, incluso si hay espacio en disco disponible.

Solución: Aumente el límite de total_shards_per_node (use con precaución, ya que demasiados shards por nodo pueden degradar el rendimiento) o añada más nodos al clúster para distribuir la carga.

Diagnóstico de Fallos de Asignación: La API de Explicación de Asignación (Allocation Explain API)

La API de Explicación de Asignación es la herramienta más poderosa para diagnosticar por qué un shard específico no se está asignando. Simula el proceso de toma de decisiones de los decisores de asignación.

Para usarla, necesita el nombre del índice, el número de shard y el nodo en el que debería estar el shard (si se conoce, u omita el nodo para verificar todas las posibilidades).

Ejemplo de Uso (Verificando el Shard 0 del Índice my_data):

GET /_cluster/allocation/explain?pretty
{
  "index": "my_data",
  "shard": 0,
  "primary": true
}

La respuesta detallará cada decisión de asignación tomada para ese shard, indicando explícitamente qué regla se violó (p. ej., "[el disco excede el umbral alto en el nodo X]").

Lectura de la Salida

Preste mucha atención al campo explanation y a la sección deciders. Si un decisor devuelve false, el mensaje correspondiente explica la restricción que se está violando (p. ej., uso de disco, falta de coincidencia en el número de réplicas o exclusión por atributo de nodo).

Pasos y Comandos de Solución de Problemas

Cuando se enfrente a un estado UNASSIGNED, siga esta secuencia de solución de problemas priorizada:

Paso 1: Verificar la Salud del Clúster y los Shards sin Asignar

Primero, vea el panorama general.

GET /_cluster/health?pretty
GET /_cat/shards?h=index,shard,prirep,state,unassigned.reason,node

Observe específicamente la columna unassigned.reason de la salida de la API cat. Esto a menudo proporciona pistas inmediatas (p. ej., CLUSTER_RECOVERED, NODE_LEFT, INDEX_CREATED).

Paso 2: Investigar el Espacio en Disco

Si la razón apunta a presión de disco, verifique el uso real en todos los nodos.

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total

Acción: Si los nodos están cerca del 90% de capacidad, comience inmediatamente a limpiar registros, reducir la retención de índices o añadir capacidad de disco a esos nodos.

Paso 3: Usar Allocation Explain para Casos Complejos

Si la causa no es una presión de recursos obvia, ejecute la API de Explicación de Asignación como se detalló anteriormente para identificar desajustes de configuración.

Paso 4: Forzar Manualmente la Asignación (Usar con Cautela)

Si un shard primario está UNASSIGNED (Salud Roja) porque el nodo original ha desaparecido permanentemente, y usted acepta el riesgo de perder datos escritos desde que existía el shard primario anterior, puede forzar al clúster a promover una réplica (si existe una).

Advertencia: Este comando elimina permanentemente el registro del shard primario sin asignar. Solo use esto si no puede recuperar el nodo que aloja el primario.

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "index_name",
        "shard": 0,
        "node": "node_name_with_replica",
        "accept_data_loss": true
      }
    }
  ]
}

Paso 5: Abordar Réplicas Atascadas (Salud Amarilla)

Si solo las réplicas no están asignadas (Salud Amarilla) debido a nodos o espacio en disco insuficientes, generalmente solucionar la restricción de recursos subyacente (añadir nodos o liberar espacio en disco) hará que las réplicas se asignen automáticamente una vez que los decisores lo permitan.

Si debe proceder sin añadir recursos, puede deshabilitar temporalmente la asignación de réplicas para el índice:

PUT /my_index/_settings
{
  "index.blocks.write": true, 
  "index.number_of_replicas": 0
}

Después de este cambio, la salud del clúster debería volverse Verde (ya que ahora cero réplicas están asignadas con éxito). Recuerde volver a habilitar las réplicas más tarde ("index.number_of_replicas": 1).

Mejores Prácticas para Prevenir Problemas de Asignación

  1. Monitorear Rigurosamente los Umbrales de Disco: Configure alertas basadas en el umbral high (90%) para intervenir antes de que la asignación se bloquee por completo.
  2. Mantener la Diversidad de Nodos: Asegúrese de tener suficientes nodos físicos o virtuales de modo que si uno falla, todavía haya suficientes nodos disponibles que cumplan con los requisitos de atributos para alojar todos los primarios y las réplicas necesarias.
  3. Usar Conciencia de Asignación (Allocation Awareness): Para implementaciones multizona o multirack, configure cluster.routing.allocation.awareness.attributes para evitar que todas las copias de un shard terminen en la misma zona física, mitigando interrupciones a nivel de zona.
  4. Establecer Recuentos de Réplicas Realistas: Evite establecer recuentos de réplicas más altos que el número de nodos físicos que puede mantener, ya que esto garantiza réplicas sin asignar durante el mantenimiento menor.

Al gestionar los recursos de forma proactiva y utilizar la API de Explicación de Asignación, los administradores pueden diagnosticar y resolver rápidamente los factores que impiden que los shards de Elasticsearch logren una asignación óptima.