Centro de Conhecimento DevOps
Centro de Conhecimento DevOps

Problemas de Alocação de Shard no Elasticsearch: Causas e Soluções

Resolva falhas comuns de alocação de shard no Elasticsearch que levam à saúde amarela ou vermelha do cluster. Este guia explica causas críticas, incluindo limites de espaço em disco, incompatibilidades de atributos de nó e perda de shard primário. Aprenda a usar efetivamente a API de Explicação de Alocação e aplique comandos práticos para restaurar a estabilidade do cluster e garantir a disponibilidade dos dados.

48 visualizações

Problemas de Alocação de Shards no Elasticsearch: Causas e Soluções

Clusters Elasticsearch são projetados para resiliência e alta disponibilidade, dependendo fortemente da distribuição e alocação adequadas de shards entre os nós. Quando um shard falha em passar de um estado UNASSIGNED ou INACTIVE para um primário ou réplica ativo, o indicador de saúde do cluster geralmente fica amarelo ou vermelho. Compreender por que os shards não estão sendo alocados é crucial para manter um mecanismo de busca saudável, com bom desempenho e disponível.

Este guia aprofunda as causas comuns de falhas na alocação de shards — desde recursos insuficientes do cluster até configurações incorretas — e fornece soluções práticas e acionáveis para resolver esses problemas, garantindo que seus dados sejam indexados e pesquisáveis corretamente.

Entendendo os Estados e a Alocação de Shards

Antes de solucionar problemas, é essencial saber o que o Elasticsearch está tentando fazer. Shards são a unidade fundamental de distribuição no Elasticsearch. Eles podem existir em vários estados:

  • STARTED: O shard está ativo e atendendo requisições (Primário ou Réplica).
  • RELOCATING: O shard está sendo movido de um nó para outro (durante o rebalanceamento ou adição/remoção de nós).
  • INITIALIZING: Um novo shard de réplica está sendo criado a partir do primário.
  • UNASSIGNED: O shard existe nos metadados de estado do cluster, mas não está alocado a nenhum nó, geralmente porque o nó necessário está indisponível ou os critérios não são atendidos.

A saúde do cluster é determinada pela presença de shards não atribuídos:

  • Green: Todos os shards primários e de réplica estão alocados.
  • Yellow: Todos os shards primários estão alocados, mas um ou mais shards de réplica estão não atribuídos.
  • Red: Um ou mais shards primários estão não atribuídos (indicando risco de perda de dados se o nó que hospeda o shard primário falhar).

Causas Comuns de Falhas na Alocação de Shards

A alocação de shards é gerenciada pela lógica de decisão de alocação do cluster, que verifica vários fatores antes de posicionar um shard. A falha geralmente resulta de uma violação de um desses pontos de decisão.

1. Recursos Insuficientes do Cluster

Esta é talvez a causa mais frequente de alocações travadas, especialmente em ambientes dinâmicos.

Limiares de Espaço em Disco

O Elasticsearch automaticamente para de alocar novos shards (tanto primários quanto de réplica) para um nó se seu uso de disco ultrapassar limiares predefinidos. Por padrão, a alocação para em 85% de uso e impede completamente a alocação em 90%.

Limiares Padrão (Verifique elasticsearch.yml ou as Configurações do Cluster):

Configuração Valor Padrão Descrição
cluster.routing.allocation.disk.watermark.low 85% Limiar onde o nó é considerado relativamente cheio.
cluster.routing.allocation.disk.watermark.high 90% Limiar onde a alocação para o nó é bloqueada.
cluster.routing.allocation.disk.watermark.flood_stage 95% A alocação para completamente, e as operações de indexação/escrita podem falhar.

Solução: Verifique o uso de disco em todos os nós e libere espaço ou adicione mais espaço em disco aos nós que estão ultrapassando a marca d'água alta.

Pressão de Memória e CPU

Embora menos comum do que problemas de disco, o uso persistentemente alto de memória ou alta carga de CPU nos nós pode impedir que novos shards sejam atribuídos, já que os decisores de alocação preferem nós com margem operacional suficiente.

2. Incompatibilidade de Funções e Atributos de Nós

Implantações modernas do Elasticsearch frequentemente usam nós mestres, de ingestão ou coordenadores dedicados. Shards não serão alocados para nós que não atendem aos critérios exigidos.

Regras de Alocação Incompatíveis

Se você configurou configurações de índice específicas que exigem que os shards sejam colocados em nós marcados com certos atributos (por exemplo, SSDs rápidos), mas nenhum nó disponível corresponde a essa marca, os shards permanecerão não atribuídos.

Exemplo: Um índice criado com index.routing.allocation.require.box_type: high_io será alocado apenas em nós explicitamente configurados com essa configuração.

Solução: Verifique as regras de alocação (allocation.require, allocation.include, allocation.exclude) para o índice afetado e garanta que os nós possuam as configurações corretas de node.attr.

3. Estabilidade do Estado do Cluster e Falhas na Alocação Primária (Saúde Vermelha)

Se os shards primários estiverem não atribuídos (o cluster está VERMELHO), significa que o nó que mantinha a última cópia primária falhou ou saiu do cluster, e nenhum shard de réplica disponível pode ser promovido a primário.

Cenários Comuns:
* Um nó que detém a única cópia primária trava inesperadamente.
* O nó que contém o shard primário é explicitamente removido do cluster antes que as réplicas fossem copiadas com sucesso.

Solução: Se o nó com falha não puder ser recuperado rapidamente, pode ser necessário forçar manualmente a alocação substituindo o bloqueio primário, mas isso acarreta um alto risco de perda de dados para esses shards específicos.

4. Limites e Cotas de Shards

O Elasticsearch impõe limites para evitar a criação descontrolada de shards que poderia desestabilizar o cluster.

Número Máximo de Shards Por Nó

Se um nó atingiu seu número máximo configurado de shards (cluster.routing.allocation.total_shards_per_node), nenhum shard adicional será atribuído a ele, mesmo que haja espaço em disco disponível.

Solução: Aumente o limite de total_shards_per_node (use com cautela, pois muitos shards por nó podem degradar o desempenho) ou adicione mais nós ao cluster para distribuir a carga.

Diagnóstico de Falhas de Alocação: A API de Explicação de Alocação

A API de Explicação de Alocação é a ferramenta mais poderosa para diagnosticar por que um shard específico não está sendo alocado. Ela simula o processo de tomada de decisão dos decisores de alocação.

Para usá-la, você precisa do nome do índice, do número do shard e do nó no qual o shard deveria estar (se conhecido, ou omita o nó para verificar todas as possibilidades).

Exemplo de Uso (Verificando o Shard 0 do Índice my_data):

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

A resposta detalhará cada decisão de alocação tomada para aquele shard, declarando explicitamente qual regra foi violada (por exemplo, "[disco excedendo a marca d'água alta no nó X]").

Lendo a Saída

Preste muita atenção ao campo explanation e à seção deciders. Se um decisor retornar false, a mensagem correspondente explica a restrição que está sendo violada (por exemplo, uso de disco, incompatibilidade de contagem de réplicas ou exclusão de atributo de nó).

Etapas e Comandos de Resolução de Problemas

Ao se deparar com um estado UNASSIGNED, siga esta sequência de resolução de problemas priorizada:

Etapa 1: Verificar a Saúde do Cluster e Shards Não Atribuídos

Primeiro, veja a visão geral.

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

Procure especificamente a coluna unassigned.reason da saída da API cat. Isso geralmente fornece pistas imediatas (por exemplo, CLUSTER_RECOVERED, NODE_LEFT, INDEX_CREATED).

Etapa 2: Investigar Espaço em Disco

Se o motivo apontar para pressão de disco, verifique o uso real em todos os nós.

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

Ação: Se os nós estiverem perto de 90% da capacidade, comece imediatamente a limpar logs, reduzir a retenção de índices ou adicionar capacidade de disco a esses nós.

Etapa 3: Usar a Explicação de Alocação para Casos Complexos

Se a causa não for uma pressão óbvia de recursos, execute a API de Explicação de Alocação conforme detalhado acima para identificar incompatibilidades de configuração.

Etapa 4: Forçar a Alocação Manualmente (Use com Cautela)

Se um shard primário estiver UNASSIGNED (Saúde Vermelha) porque o nó original se foi permanentemente, e você aceita o risco de perder dados escritos desde a última existência do shard primário, você pode forçar o cluster a promover uma réplica (se existir).

Aviso: Este comando exclui permanentemente o registro do shard primário não atribuído. Use-o apenas se você não puder recuperar o nó que hospeda o primário.

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

Etapa 5: Lidando com Réplicas Travadas (Saúde Amarela)

Se apenas as réplicas estiverem não atribuídas (Saúde Amarela) devido a nós insuficientes ou espaço em disco, simplesmente corrigir a restrição de recurso subjacente (adicionar nós ou liberar espaço em disco) geralmente fará com que as réplicas sejam alocadas automaticamente assim que os decisores permitirem.

Se você precisar prosseguir sem adicionar recursos, pode desativar temporariamente a alocação de réplicas para o índice:

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

Após essa alteração, a saúde do cluster deverá ficar Verde (já que zero réplicas agora estão alocadas com sucesso). Lembre-se de reativar as réplicas mais tarde ("index.number_of_replicas": 1).

Melhores Práticas para Prevenir Problemas de Alocação

  1. Monitorar Rigorosamente as Marcas d'água de Disco: Configure alertas com base na marca d'água high (90%) para intervir antes que a alocação seja totalmente bloqueada.
  2. Manter a Diversidade de Nós: Garanta que você tenha nós físicos ou virtuais suficientes para que, se um falhar, ainda haja nós disponíveis que atendam aos requisitos de atributos para hospedar todos os primários e réplicas necessários.
  3. Usar a Consciência de Alocação (Allocation Awareness): Para implantações multi-zona ou multi-rack, configure cluster.routing.allocation.awareness.attributes para evitar que todas as cópias de um shard parem na mesma zona física, mitigando interrupções em toda a zona.
  4. Definir Contagens Realistas de Réplicas: Evite definir contagens de réplicas maiores do que o número de nós físicos que você pode sustentar, pois isso garante réplicas não atribuídas durante manutenções menores.

Ao gerenciar proativamente os recursos e utilizar a API de Explicação de Alocação, os administradores podem diagnosticar e resolver rapidamente os fatores que impedem que os shards do Elasticsearch alcancem a alocação ideal.