Compreendendo a Eleição do Nó Mestre do Elasticsearch e os Requisitos de Quorum

Elasticsearch é um sistema distribuído, que depende da coordenação entre os nós para manter uma visão consistente do estado do cluster. No cerne dessa coordenação está o Nó Mestre. O nó mestre é a única fonte de verdade para os metadados do cluster, e garantir sua estabilidade e eleição adequada é de suma importância para a saúde, escalabilidade e resiliência do cluster.

Este artigo detalha as responsabilidades críticas do nó mestre, explica o processo de eleição moderno usado em versões recentes do Elasticsearch (7.x+), e esclarece o conceito essencial de quorum — o mecanismo necessário para prevenir o cenário devastador conhecido como problema de split-brain.

O Papel Crítico do Nó Mestre

Enquanto os nós de dados lidam com o trabalho pesado de indexação, pesquisa e armazenamento de dados, o nó mestre é responsável por gerenciar a estrutura e os metadados de todo o cluster. Ele não participa tipicamente de operações de consulta ou indexação, a menos que também esteja 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 projeto da configuração atual do cluster, incluindo quais índices existem, os mapeamentos e configurações para esses índices e a localização de cada shard.
2. Gerenciamento de Nós: Lida com a entrada e saída de nós, atualizando o estado do cluster de acordo.
3. Gerenciamento de Índices: Criação, exclusão ou atualização de índices.
4. Alocação de Shards: Decidir onde os shards primários e de réplica devem residir (alocação inicial e rebalanceamento após falha do nó).

Se o nó mestre falhar, o cluster não pode realizar tarefas administrativas ou realocar shards até que um novo mestre seja eleito com sucesso.

Compreendendo 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 inacessí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 para 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 para mestre se comunicam para determinar o conjunto de membros votantes ativos.
2. Verificação de Quorum: Os nós verificam se conseguem atingir um quorum — a maioria dos nós votantes conhecidos — para garantir o consenso.
3. Seleção do Líder: Se um quorum for estabelecido, o candidato de maior classificação (com base em um mecanismo de desempate como o ID do estado do cluster) é proposto como o novo mestre.
4. Votação e Confirmação: A proposta é votada e, se aceita pela maioria, o novo mestre assume o controle e publica o novo estado do cluster.

Inicialização do Cluster

Ao iniciar um cluster totalmente 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 de elasticsearch.yml para configuração inicial
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

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

Dica: Uma vez que o cluster esteja em execução e estável, você deve remover ou comentar a configuração cluster.initial_master_nodes dos arquivos de configuração de todos os nós para evitar problemas potenciais se os nós forem reiniciados posteriormente em um estado misto.

Requisitos de Quorum e Prevenção de Split-Brain

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

O que é Split-Brain?

O split-brain ocorre quando uma partição de rede divide o cluster em dois ou mais segmentos isolados, e cada segmento acredita ser o mestre autoritário. Se isso acontecer, os nós em diferentes segmentos podem aceitar independentemente solicitações de indexação e alocar shards, levando à inconsistência e corrupção de dados quando a rede eventualmente se restabelece.

A Regra do Quorum (Consenso da Maioria)

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

$$\text{Quorum} = \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 alcançar o quorum e continuar operando. O lado menor, incapaz de eleger um mestre, irá parar e esperar que a conectividade da rede seja restaurada, evitando assim a gravação de dados no segmento particionado.

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

Aviso de Boa Prática: Sempre implante um número ímpar de nós elegíveis para 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 precedente (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 ele só pode tolerar uma falha, o mesmo que um cluster de 3 nós, mas usa um servidor extra.

Configurando Nós Mestre Dedicados

Para ambientes de produção, especialmente clusters grandes (20+ nós de dados), é altamente recomendável usar nós mestre dedicados. Isso separa as tarefas intensivas em recursos de busca/indexação das cruciais funções administrativas do mestre.

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

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

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

# Desabilita o tráfego HTTP/Transport para mestres puros (opcional, mas boa prática de segurança)
# http.enabled: false 
# transport.bind_host: [private_ip_of_master]

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

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

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

# Nota: Se nenhuma role for especificada, o Elasticsearch assume como padrão [master, data, ingest] (padrão pré-8.0)

Configurações de Descoberta de Cluster

Todos os nós devem ser configurados para encontrar o mesmo conjunto de nós elegíveis para mestre usando a configuração discovery.seed_hosts. Essa 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 para mestre (es-master-01, es-master-02, es-master-03, etc.).

Solução de Problemas de Eleição

Se o cluster falhar em eleger um mestre, ele tipicamente entra em um estado 'vermelho' ou 'amarelo' e registra erros persistentes. As 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 ou alta latência. Garanta que as portas 9200 (HTTP) e 9300 (Transport) estejam abertas entre os nós.
Incompatibilidade de Configuração	cluster.name está incorreto ou discovery.seed_hosts não aponta para os nós elegíveis para mestre corretos. Verifique se todos os nós usam configurações idênticas.
Perda de Quorum	Muitos nós elegíveis para mestre falharam simultaneamente (por exemplo, duas falhas em uma configuração de mestre de 3 nós). Pode ser necessária intervenção manual (por exemplo, usando a API api/cluster/decommission/voting_config_exclusions) para remover à força os nós falhos da lista de votação.
E/S de Disco	A E/S de disco do nó mestre está saturada, 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.voting_config_excluding_deferred

Essa saída confirma quais nós são atualmente contados para o quorum, garantindo que sua configuração corresponda aos seus objetivos de tolerância a falhas.

Resumo

O processo de eleição do nó mestre é a espinha dorsal da resiliência de um cluster Elasticsearch. Ao compreender as responsabilidades do mestre e implementar corretamente a regra do quorum (usando um número ímpar de nós elegíveis para mestre e garantindo o cluster.initial_master_nodes correto durante o bootstrap), os administradores podem prevenir de forma confiável cenários de split-brain e manter um sistema distribuído altamente disponível. Sempre use nós mestre dedicados em produção para isolar tarefas administrativas e garantir a publicação confiável do estado do cluster.