Entendendo a Eleição do Nó Mestre no Elasticsearch e os Requisitos de Quórum

O quórum do nó mestre no Elasticsearch decide se seu cluster pode eleger um líder com segurança, publicar mudanças no estado do cluster e evitar que dois lados desconectados do mesmo cluster tomem decisões diferentes.

O mestre eleito não torna as buscas mais rápidas por si só. Ele coordena o cluster. Quando as eleições são instáveis, os sintomas podem parecer dispersos: a criação de índices trava, a alocação de shards para, o Kibana relata estados de saúde variáveis e os logs repetem mensagens sobre um mestre não encontrado.

O Papel Crítico do Nó Mestre

Enquanto os nós de dados lidam com o trabalho pesado de indexação, busca e armazenamento de dados, o nó mestre é responsável por gerenciar a estrutura e os metadados de todo o cluster. Ele normalmente não participa de operações de consulta ou indexação, a menos que também seja configurado como um nó de dados.

Responsabilidades do Nó Mestre

1. Gerenciamento do Estado do Cluster: O mestre mantém e publica o estado do cluster—um blueprint da configuração atual do cluster, incluindo quais índices existem, os mapeamentos e configurações desses índices e a localização de cada shard.
2. Gerenciamento de Nós: Lidar com a entrada e saída de nós, atualizando o estado do cluster de acordo.
3. Gerenciamento de Índices: Criar, deletar ou atualizar índices.
4. Alocação de Shards: Decidir onde os shards primários e réplicas devem residir (alocação inicial e rebalanceamento após falha de nó).

Se o mestre eleito falhar, o cluster pausa o trabalho exclusivo do mestre até que outro mestre seja eleito. As buscas existentes podem continuar para shards disponíveis, mas a criação de índices, atualizações de mapeamento e decisões de alocação dependem de uma coordenação estável do mestre.

Entendendo a Eleição e Votação do Mestre

Em um sistema distribuído, um processo de eleição é necessário sempre que o nó mestre atual falha ou se torna inalcançável. Desde o Elasticsearch 7.0, o mecanismo de eleição foi significativamente simplificado e fortalecido, principalmente através da eliminação da complexa configuração discovery.zen.minimum_master_nodes e da introdução de Configurações de Votação autogerenciadas.

O Processo de Eleição (Elasticsearch 7.x+)

A eleição do mestre agora é tratada automaticamente pelos nós elegíveis a mestre, que são definidos na configuração usando node.roles: [master, data], ou apenas node.roles: [master] para mestres dedicados.

1. Descoberta de Candidatos: Nós elegíveis a mestre se comunicam para determinar o conjunto de membros votantes ativos.
2. Verificação de Quórum: Os nós verificam se podem alcançar um quórum—uma maioria dos nós votantes conhecidos—para garantir consenso.
3. Seleção do Líder: Se um quórum for estabelecido, o subsistema de coordenação do Elasticsearch seleciona um mestre de acordo com suas regras internas de eleição.
4. Votação e Compromisso: A proposta é votada e, se aceita pela maioria, o novo mestre assume o controle e publica o novo estado do cluster.

Inicialização Inicial do Cluster

Ao iniciar um cluster novo pela primeira vez, o Elasticsearch precisa saber quais nós devem participar da configuração de votação inicial. Isso é tratado usando a configuração cluster.initial_master_nodes. Esta configuração deve ser usada apenas uma vez durante a inicialização inicial do cluster.

# Trecho do elasticsearch.yml para configuração inicial
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

# Liste os nomes de todos os nós elegíveis a mestre usados para o bootstrap inicial
cluster.initial_master_nodes: [node-1, node-2, node-3]

Dica: Depois que o cluster for formado, remova cluster.initial_master_nodes de todos os nós. Mantê-lo pode ser perigoso durante reinicializações posteriores, pois esta configuração é destinada apenas ao primeiro bootstrap de um cluster novo.

Requisitos de Quórum e Prevenção de Split-Brain

A razão fundamental para os requisitos de quórum é garantir que apenas um líder possa ser eleito a qualquer momento, prevenindo assim o problema de split-brain.

O que é Split-Brain?

Split-brain ocorre quando uma partição de rede divide o cluster em segmentos isolados, e mais de um segmento acredita ter o mestre autoritativo. Se isso acontecer, lados diferentes podem aceitar mudanças conflitantes no estado do cluster, que é exatamente o que o quórum foi projetado para prevenir.

A Regra do Quórum (Consenso da Maioria)

Para prevenir split-brain, o Elasticsearch aplica uma regra de consenso da maioria, exigindo um número mínimo de nós votantes para concordar com qualquer mudança no estado do cluster. Este mínimo é o quórum, calculado como:

$$\text{Quórum} = \lfloor (\text{Número de Nós Votantes} / 2) \rfloor + 1$$

Ao exigir uma maioria estrita, se a rede for particionada, apenas o lado maior (que detém a maioria) pode atingir o quórum e continuar operando. O lado menor, incapaz de eleger um mestre, irá parar e aguardar a restauração da conectividade de rede, evitando assim gravações de dados no segmento particionado.

Número de Nós Mestres Votantes (N)	Quórum Necessário (N/2 + 1)
3	2
5	3
7	4

Aviso de Melhores Práticas: Sempre implante um número ímpar de nós elegíveis a mestre (por exemplo, três ou cinco). Implantar um número par (por exemplo, quatro) oferece a mesma tolerância a falhas que o número ímpar anterior (três), mas requer mais recursos. Por exemplo, um cluster de votação de 4 nós requer 3 votos (N/2+1), o que significa que pode tolerar apenas uma falha, assim como um cluster de 3 nós, mas usa um servidor extra.

Configurando Nós Mestres Dedicados

Para ambientes de produção, três nós dedicados elegíveis a mestre são a linha de base comum. Isso separa a carga de busca e indexação do trabalho de coordenação. Clusters de desenvolvimento pequenos podem executar funções mistas, mas um cluster que importa não deve permitir que uma agregação pesada ou pico de ingestão prive o mestre eleito de recursos.

Exemplo de Configuração de Nó (Mestre Dedicado)

Para configurar um nó para ser elegível a mestre, mas não armazenar dados ou executar pipelines de ingestão, use as seguintes funções em elasticsearch.yml:

# Nó 1: Mestre Dedicado
node.name: es-master-01
node.roles: [master]

# Vincule o transporte a uma rede privada e restrinja o acesso com firewalls/grupos de segurança.
# network.host: 10.0.0.1

Exemplo de Configuração de Nó (Nó de Dados Dedicado)

Por outro lado, um nó de dados dedicado deve ser impedido de participar do processo de eleição de mestre:

# Nó 4: Nó de Dados Dedicado
node.name: es-data-04
node.roles: [data]

# Se nenhuma função for especificada, o Elasticsearch atribui o conjunto de funções padrão para essa versão.

Configurações de Descoberta do Cluster

Todos os nós devem ser configurados para encontrar o mesmo conjunto de nós elegíveis a mestre usando a configuração discovery.seed_hosts. Esta configuração lista os endereços de rede onde o Elasticsearch pode tentar contatar outros nós para se juntar ao cluster.

# Configuração comum para todos os nós no cluster
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]

Esta lista deve conter os endereços dos nós elegíveis a mestre (es-master-01, es-master-02, es-master-03, etc.).

Solucionando Problemas de Eleição

Se o cluster falhar ao eleger um mestre, ele normalmente entra em um estado 'vermelho' ou 'amarelo' e registra erros persistentes. Causas comuns incluem:

Problema	Descrição e Solução
Problemas de Rede	Os nós não conseguem se comunicar devido a regras de firewall, problemas de roteamento, problemas de DNS ou alta latência. A porta de transporte, comumente 9300, deve estar acessível entre os nós. HTTP, comumente 9200, é para acesso de cliente/API e não é o canal de eleição.
Incompatibilidade de Configuração	cluster.name está incorreto ou discovery.seed_hosts não aponta para os nós elegíveis a mestre corretos. Verifique se todos os nós usam configurações idênticas.
Perda de Quórum	Muitos nós votantes falharam ao mesmo tempo, como duas falhas em uma configuração de três mestres. Se os nós ausentes desapareceram permanentemente, use a API de exclusões de configuração de votação com cuidado e somente após confirmar o modo de falha.
I/O de Disco	O I/O de disco do nó mestre está saturado, impedindo-o de publicar o estado do cluster rapidamente, levando a timeouts e eleições repetidas.

Verificando a Configuração de Votação

Você pode inspecionar a configuração de votação atual usando a API do Cluster:

GET /_cluster/state?filter_path=metadata.cluster_coordination

Esta saída confirma quais nós estão atualmente contados para o quórum, garantindo que sua configuração corresponda às suas metas de tolerância a falhas.

O padrão de produção mais seguro é simples: três nós dedicados elegíveis a mestre em domínios de falha separados, rede de transporte estável, seed hosts corretos e cluster.initial_master_nodes usado apenas uma vez. Quando as eleições falharem, resista ao impulso de reiniciar todos os nós de uma vez. Leia os logs, confirme quais nós elegíveis a mestre podem se ver e faça uma mudança controlada de cada vez.