Solução de Problemas em Cenários Comuns de Split-Brain em Clusters Elasticsearch

Split brain é a falha do Elasticsearch sobre a qual as pessoas falam porque parece dramática, mas a pergunta útil é mais prática: mais de uma parte do cluster pode tomar decisões de nível de mestre ao mesmo tempo? As versões modernas do Elasticsearch são projetadas para evitar isso por meio da coordenação de cluster baseada em maioria. Clusters mais antigos, especialmente versões anteriores à 7.0 com uma configuração ruim de discovery.zen.minimum_master_nodes, eram mais fáceis de configurar incorretamente.

Portanto, este artigo separa duas situações que frequentemente são confundidas. Um verdadeiro split brain significa que partições independentes podem eleger ou manter um mestre cada uma. Uma falha na eleição do mestre significa que o cluster não consegue eleger um mestre porque não tem maioria. O primeiro risco é um estado de cluster conflitante e inconsistência de dados. O segundo é doloroso, mas geralmente é o modo de falha mais seguro.

Como o split brain se parece

Em um cluster saudável, um mestre eleito gerencia o estado do cluster: criação de índices, decisões de alocação de shards, mapeamentos, associação de nós e metadados semelhantes. Os nós de dados podem lidar com leituras e gravações, mas o cluster ainda depende de uma visão única do mestre sobre o mundo.

Um cenário de split brain ocorre quando partições de rede ou configurações de descoberta ruins permitem que dois grupos de nós se comportem como se cada grupo fosse o cluster real. Um lado pode aceitar gravações em um índice enquanto o outro lado aceita gravações diferentes. Quando a conectividade é restaurada, o Elasticsearch não pode simplesmente mesclar dois históricos conflitantes como um arquivo de texto.

No Elasticsearch moderno, se uma partição não tiver a maioria dos nós elegíveis a mestre, ela não deve eleger um mestre. Isso significa que alguns nós podem ficar indisponíveis em vez de formar um cluster concorrente. Esse é o comportamento que você deseja.

A versão é importante

Para Elasticsearch 6.x e versões anteriores, a configuração principal era:

discovery.zen.minimum_master_nodes: 2

A regra era a maioria dos nós elegíveis a mestre: (N / 2) + 1, arredondado para baixo na divisão inteira antes de adicionar um. Com três nós elegíveis a mestre, defina como 2. Com cinco, defina como 3. Definir como 1 em um cluster de três nós tornava o split brain possível.

Para Elasticsearch 7.x e posteriores, discovery.zen.minimum_master_nodes não existe mais. A coordenação do cluster mudou e o Elasticsearch gerencia a configuração de votação. Novos clusters ainda precisam de bootstrapping correto com cluster.initial_master_nodes, mas essa configuração é apenas para a primeira formação do cluster. Após a formação do cluster, remova-a da configuração.

Não "corrija" um cluster moderno adicionando configurações antigas de discovery.zen. Elas não são mais o plano de controle.

Causas comuns

O gatilho mais comum é uma partição de rede entre nós elegíveis a mestre. Em termos de nuvem, isso pode ser uma alteração no grupo de segurança, uma tabela de roteamento ruim, um ACL de rede, um problema no nível da zona ou uma regra de firewall que bloqueia a porta de transporte 9300. Em ambientes bare metal, pode ser um switch, VLAN, DNS, MTU ou problema de perda de pacotes.

Outra causa é executar poucos nós elegíveis a mestre. Dois nós elegíveis a mestre são complicados porque não há uma maioria clara após a falha de um. Um cluster de produção normalmente usa três nós dedicados elegíveis a mestre, ou três nós de função mista em uma implantação pequena.

Uma terceira causa são diretórios de dados obsoletos ou reutilizados. Se você clonar VMs ou reutilizar discos de clusters antigos, os nós podem carregar metadados de cluster que você não pretendia. Isso pode levar a falhas de associação confusas e, nos piores casos, à formação acidental de um cluster separado.

Finalmente, a recuperação manual sob pressão pode piorar o problema. Reiniciar nós aleatórios, limpar caminhos de dados ou forçar alocação insegura antes de saber qual partição é autoritativa pode transformar um incidente recuperável em perda de dados.

Primeiras verificações durante um incidente

Comece perguntando a cada nó acessível o que ele pensa:

curl -s "http://NODE:9200/_cat/master?v"
curl -s "http://NODE:9200/_cat/nodes?v&h=ip,name,roles,master,node.role"
curl -s "http://NODE:9200/_cluster/health?pretty"

Execute esses comandos em mais de um nó, se possível. Se nós diferentes relatarem mestres diferentes ou associação de nós diferente, você pode estar olhando para um cluster particionado ou nós isolados.

Verifique os logs nos nós elegíveis a mestre em busca de mensagens sobre eleições, associações, desconexões e falhas de publicação. Termos de pesquisa úteis incluem master not discovered, elected-as-master, node-left, node-join, publication, connect_transport_exception e handshake.

Em seguida, teste a conectividade de transporte, não apenas HTTP:

nc -vz node-1.example.internal 9300
nc -vz node-2.example.internal 9300
nc -vz node-3.example.internal 9300

Execute esses testes de nó para nó. Um balanceador de carga ou bastião acessando a porta HTTP 9200 diz muito pouco sobre se os nós do Elasticsearch podem formar um cluster pela porta 9300.

Verifique a configuração de descoberta e bootstrap

No Elasticsearch 7.x e posteriores, inspecione estas configurações:

cluster.name: my-cluster
discovery.seed_hosts:
  - node-1:9300
  - node-2:9300
  - node-3:9300

Apenas para um cluster novo:

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

Os nomes de bootstrap devem corresponder a node.name. Após a formação do cluster, remova cluster.initial_master_nodes de todos os nós.

No Elasticsearch 6.x e versões anteriores, verifique:

discovery.zen.minimum_master_nodes: 2

para um cluster de três nós elegíveis a mestre. Confirme também que todos os nós elegíveis a mestre têm hosts de descoberta e nomes de cluster consistentes.

Princípios de recuperação

Se você suspeitar de um verdadeiro split brain, pare de fazer alterações através da API do cluster até saber qual lado é autoritativo. A recuperação mais segura geralmente segue esta ordem:

1. Preserve evidências: colete logs, listas de nós, visualizações de mestre e saúde do índice de cada partição.
2. Restaure a conectividade de rede ou isole intencionalmente o lado ruim.
3. Escolha a partição autoritativa com base na maioria, dados válidos mais recentes e impacto nos negócios.
4. Pare o Elasticsearch nos nós que não devem continuar como uma partição independente.
5. Traga os nós de volta um de cada vez e verifique se eles se juntam ao cluster autoritativo.
6. Restaure dados perdidos de snapshots se algum histórico de shard primário for perdido ou inconsistente.

Não exclua diretórios de translog como uma correção rotineira de split brain. Esse é um conselho perigoso. Os translogs fazem parte da recuperação do Elasticsearch. Remover arquivos manualmente no caminho de dados pode causar perda de dados e só deve ser feito com orientação específica da versão do suporte Elastic ou depois que você aceitou a perda e tem um plano de reconstrução.

Se duas partições aceitaram gravações independentemente, pode não haver uma mesclagem automática perfeita. Você pode precisar restaurar de snapshot, reindexar de sistemas de origem, reproduzir logs de aplicativos ou escolher os dados de um lado como autoritativos.

Um exemplo realista

Imagine um cluster de três nós em três sub-redes privadas. Uma alteração no firewall bloqueia acidentalmente o tráfego de transporte entre o nó 1 e os nós 2 e 3. Os nós 2 e 3 ainda se veem, então eles mantêm ou elegem um mestre. O nó 1 não consegue ver uma maioria. Em um cluster moderno e configurado corretamente, o nó 1 não deve formar um mestre concorrente sozinho. Os clientes que usam o nó 1 podem falhar, mas o cluster evita mestres conflitantes.

Agora imagine um cluster antigo 6.x com três nós elegíveis a mestre e discovery.zen.minimum_master_nodes: 1. O nó 1 pode se eleger, enquanto os nós 2 e 3 elegem outro mestre. Esse é o risco clássico de split brain. A correção não é apenas reconectar a rede. Você também precisa corrigir a configuração de quorum e decidir como lidar com quaisquer gravações aceitas no lado errado.

Prevenção

Use três nós elegíveis a mestre para clusters pequenos e médios. Para clusters maiores, torne-os nós mestres dedicados para que a carga de pesquisa e indexação não interfira na coordenação do cluster.

Mantenha os nós elegíveis a mestre em redes confiáveis com baixa perda de pacotes. Espalhar nós entre zonas pode ajudar na disponibilidade, mas apenas se a rede entre as zonas for confiável e o design do quorum ainda fizer sentido.

Monitore as mudanças de mestre. Uma eleição de mestre durante a manutenção planejada é normal. Eleições frequentes durante o tráfego normal são um sinal de alerta.

Monitore a conectividade de transporte e não apenas o tempo de atividade HTTP. Um nó pode responder na porta 9200 e ainda falhar em participar corretamente do cluster se o tráfego de transporte estiver bloqueado.

Faça snapshots regularmente e teste as restaurações. As réplicas não protegem contra uma exclusão incorreta, dados corrompidos ou gravações conflitantes durante um incidente grave.

Tenha cuidado com as configurações de bootstrap. Em clusters modernos, cluster.initial_master_nodes não é uma configuração de descoberta do dia a dia. Use-o para criar um novo cluster e depois remova-o.

A melhor recuperação de split brain é aquela que você nunca precisa: elegibilidade de mestre baseada em maioria, configurações de descoberta corretas específicas da versão, regras de rede previsíveis e um plano de snapshot testado.

Como distinguir split brain de uma eleição normal

Uma eleição de mestre não é automaticamente split brain. Durante uma reinicialização contínua, oscilação de rede ou falha de nó mestre, o Elasticsearch pode eleger um novo mestre. Se o cluster mantiver um mestre autoritativo e o mestre antigo renunciar, esse é um comportamento normal de sistema distribuído.

Sinais de alerta são visualizações diferentes de nós diferentes. Se o nó A se reportar como mestre enquanto o nó B reporta o nó C como mestre, pare e investigue. Se dois grupos de nós aceitarem alterações de estado do cluster enquanto desconectados, você tem uma situação muito mais séria do que uma breve eleição.

Observe também o comportamento do cliente. Clientes fixados em um nó isolado podem ver falhas mesmo enquanto o lado majoritário está saudável. Isso não significa que o cluster majoritário está quebrado. Pode significar que sua estratégia de conexão de cliente ou balanceador de carga ainda está enviando tráfego para um nó que não pode participar.

Balanceadores de carga e roteamento de clientes

A descoberta de transporte do Elasticsearch não é o mesmo que o roteamento HTTP do cliente. Não coloque a descoberta de mestre atrás de um balanceador de carga HTTP genérico e espere que ele resolva a associação ao cluster. Os nós precisam de conectividade de transporte entre si.

Para clientes, use vários endpoints HTTP ou um balanceador de carga que remova nós não saudáveis rapidamente. Um nó que perdeu seu mestre ainda pode ter um processo ouvindo por um curto período, mas não é um bom alvo para gravações. As verificações de saúde devem ser mais significativas do que "a porta 9200 está aberta".

Uma verificação de saúde HTTP prática pode consultar a saúde do cluster localmente e rejeitar nós que não têm um mestre descoberto. A abordagem exata depende do seu cliente e infraestrutura, mas o princípio é simples: não continue enviando gravações para nós isolados.

Limpeza pós-incidente

Após o cluster estar estável, compare a saúde do índice, contagens de documentos e contagens de fonte de verdade no nível do aplicativo. Se houve alguma chance de gravações caírem em partições diferentes, a saúde do Elasticsearch sozinha não pode provar que os dados estão semanticamente corretos.

Revise a linha do tempo. Qual nó perdeu conectividade primeiro? Qual nó era o mestre antes do evento? Os clientes continuaram escrevendo? Os snapshots estavam atualizados? Os alertas dispararam antes dos usuários perceberem? Esses detalhes determinam se você precisa apenas de uma correção de rede ou de um plano de reconciliação de dados.

Para clusters mais antigos, agende o trabalho de versão e configuração de descoberta. Se você ainda estiver executando uma versão que depende de discovery.zen.minimum_master_nodes, certifique-se de que está correto hoje e planeje um caminho de atualização. A prevenção de split brain não é uma etapa única de runbook; faz parte do gerenciamento do ciclo de vida do cluster.

Mudanças de configuração a evitar durante o pânico

Não altere cluster.name para fazer os nós se juntarem. Isso cria um problema diferente de identidade do cluster.

Não limpe caminhos de dados a menos que esteja descartando intencionalmente as cópias locais de shard do nó e tenha confirmado que o cluster tem cópias válidas em outro lugar ou snapshots disponíveis.

Não adicione cluster.initial_master_nodes de volta a um cluster moderno existente como uma correção geral de reinicialização. Essa configuração é para bootstrap inicial, não para descoberta rotineira.

Não reduza as proteções de quorum em clusters antigos para restaurar a disponibilidade. Tornar uma partição minoritária gravável pode parecer progresso, mas é exatamente como mestres conflitantes se tornam possíveis.

Projetando para domínios de falha complicados

Três nós elegíveis a mestre funcionam melhor quando nenhum evento de infraestrutura único pode remover dois deles. Em uma região de nuvem de três zonas, um nó elegível a mestre por zona é um padrão comum. Em um ambiente de duas zonas, o posicionamento é mais difícil porque uma zona pode conter dois votos. Se essa zona maior falhar, o voto único restante não pode eleger um mestre com segurança. Isso não é o Elasticsearch sendo frágil; é a matemática da maioria.

Não resolva isso adicionando um número par de nós de votação sem pensar nos modos de falha. Quatro nós elegíveis a mestre ainda exigem uma maioria, e uma partição dois-dois não pode escolher um lado com segurança. Nós dedicados apenas para votação podem ajudar em alguns designs, mas o princípio permanece o mesmo: o cluster precisa de uma maioria confiável para tomar decisões de estado do cluster.

Anote isso nas notas de arquitetura. Durante uma interrupção, as pessoas frequentemente perguntam por que o nó ou zona sobrevivente não pode simplesmente continuar servindo gravações. A resposta deve ser clara antes do incidente: aceitar gravações sem uma maioria arrisca um histórico conflitante.