Eleição no Docker Swarm quando um manager morre | Swarm | Docker
- Eleição no Docker Swarm quando um manager morre | Swarm | Docker
No Docker Swarm, os nós podem ter dois papéis principais:
| Papel | Função |
|---|---|
manager | Controla o cluster, mantém o estado do Swarm, agenda tasks e participa do consenso |
worker | Executa os containers/tasks enviados pelos managers |
O Swarm usa o algoritmo Raft Consensus para manter o estado global do cluster consistente entre os managers. Os managers são responsáveis por decisões como criação de serviços, atualização de serviços, eleição de líder e manutenção do estado do cluster.
O que é o líder no Swarm
Dentro dos managers, sempre existe um manager com papel de:
Leader
Esse manager é o principal responsável pelas decisões de gerenciamento e orquestração.
Exemplo:
docker node ls
Saída simulada:
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
abc123 manager-1 Ready Active Leader
def456 manager-2 Ready Active Reachable
ghi789 manager-3 Ready Active Reachable
Nesse cenário:
| Nó | Papel |
|---|---|
manager-1 | Manager líder |
manager-2 | Manager disponível para eleição |
manager-3 | Manager disponível para eleição |
O que acontece se o manager líder morrer
Se o manager que está como Leader cair, o Swarm detecta que ele ficou indisponível.
Exemplo:
docker node ls
Saída simulada:
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
abc123 manager-1 Ready Active Unreachable
def456 manager-2 Ready Active Leader
ghi789 manager-3 Ready Active Reachable
O que aconteceu:
- O antigo líder ficou
Unreachable. - Os managers restantes iniciaram uma nova eleição.
- Um novo
Leaderfoi escolhido. - O cluster continua funcionando, desde que ainda exista quorum.
O ponto mais importante: quorum
O Swarm não elege líder simplesmente porque “sobrou um manager vivo”. Ele precisa de quorum, ou seja, maioria dos managers disponíveis.
A regra prática é:
quorum = metade dos managers + 1
Tabela:
| Quantidade de managers | Quorum necessário | Quantos managers podem morrer |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 7 | 4 | 3 |
Por isso, em produção, o comum é usar número ímpar de managers: 3, 5 ou 7. O material do Docker Cookbook reforça que, para um Swarm tolerante a falhas, é recomendado usar três ou cinco managers: com três managers, você tolera a perda de um; com cinco, tolera a perda de dois antes de perder o consenso Raft.
Por que 2 managers é ruim
Com 2 managers:
quorum = 2
Se um manager morrer, sobra apenas um.
Resultado:
não há quorum
não há eleição válida
o cluster perde capacidade de gerenciamento
Por isso, 2 managers é uma configuração ruim para alta disponibilidade.
Exemplo:
| Situação | Resultado |
|---|---|
| 2 managers vivos | OK |
| 1 manager morre | Sem quorum |
| Sobra 1 manager | Não consegue eleger líder sozinho |
| Serviços existentes | Podem continuar rodando |
| Criar/alterar serviços | Pode falhar |
O livro Continuous Delivery with Docker and Jenkins explica esse ponto: com dois managers, a maioria necessária é dois; se qualquer manager cair, não é possível atingir quorum nem eleger líder. Com três managers, a maioria continua sendo dois, então perder um manager não derruba o cluster.
O que continua funcionando se perder o leader
Se você ainda tem quorum, o Swarm continua funcionando normalmente após a eleição.
Continua funcionando:
| Item | Continua? |
|---|---|
| Containers já em execução | Sim |
| Serviços já publicados | Sim |
| Rede overlay | Sim, se os nós necessários estiverem acessíveis |
| Load balancing interno | Sim |
| Reagendamento de tasks | Sim, se houver manager/quorum |
docker service update | Sim, se houver novo líder |
docker stack deploy | Sim, se houver novo líder |
O que acontece se perder quorum
Se o cluster perder quorum, o Swarm fica sem capacidade de tomar decisões administrativas.
Exemplo com 3 managers:
manager-1 morreu
manager-2 morreu
manager-3 está vivo
Resultado:
3 managers exigem quorum de 2
só existe 1 vivo
não há quorum
não há líder confiável
Impacto:
| Operação | Resultado |
|---|---|
| Containers já rodando | Tendem a continuar rodando |
| Tráfego para containers existentes | Pode continuar |
| Criar novo serviço | Não |
| Atualizar serviço | Não |
| Remover serviço | Não |
| Reagendar tasks com segurança | Não |
| Promover/demover nós | Não |
docker stack deploy | Não confiável/falha |
Em outras palavras: a aplicação pode continuar respondendo, mas o plano de controle do Swarm fica comprometido.
Diferença entre aplicação rodando e Swarm gerenciando
Esse ponto é importante.
Quando o manager morre, não significa automaticamente que os containers param.
Existem dois planos:
| Plano | O que é |
|---|---|
| Plano de dados | Containers, conexões, tráfego, rede, aplicação rodando |
| Plano de controle | Decisões do Swarm, scheduler, service update, stack deploy, eleição |
Se você perde o manager líder mas ainda tem quorum:
plano de controle continua após nova eleição
plano de dados continua rodando
Se você perde quorum:
plano de dados pode continuar
plano de controle fica travado
Exemplo recomendado em produção
Configuração simples e correta:
3 managers
N workers
Exemplo:
manager-1
manager-2
manager-3
worker-1
worker-2
worker-3
Com essa configuração:
| Falha | Resultado |
|---|---|
| 1 manager morre | Cluster continua |
| 2 managers morrem | Perde quorum |
| 1 worker morre | Tasks podem ser reagendadas |
| Leader morre | Novo leader é eleito |
Comandos úteis
Ver os nós:
docker node ls
Ver quem é o líder:
docker node ls
Procure a coluna:
MANAGER STATUS
Valores comuns:
| Status | Significado |
|---|---|
Leader | Manager líder atual |
Reachable | Manager saudável e participante do quorum |
Unreachable | Manager inacessível |
| vazio | Normalmente worker |
Promover worker para manager:
docker node promote nome-do-node
Rebaixar manager para worker:
docker node demote nome-do-node
Gerar token para adicionar novo manager:
docker swarm join-token manager
Gerar token para adicionar worker:
docker swarm join-token worker
Recomendação prática
Para seu cenário com API, SignalR e Swarm:
| Cenário | Recomendação |
|---|---|
| Laboratório/teste simples | 1 manager pode bastar |
| Produção pequena | 3 managers |
| Produção mais crítica | 5 managers |
| Evitar | 2 managers |
| Evitar também | Muitos managers sem necessidade |
Mais managers não significa sempre melhor. Cada decisão do Swarm precisa passar pelo Raft entre os managers. Muitos managers aumentam a tolerância a falhas, mas também aumentam o custo de consenso e podem impactar performance em operações de gerenciamento.
Resumo prático
Se o leader morrer e ainda houver quorum:
outro manager vira leader
o Swarm continua funcionando
Se o leader morrer e não houver quorum:
não há eleição válida
o Swarm perde controle administrativo
Se containers já estavam rodando:
eles podem continuar vivos
Se precisar criar/alterar/remover serviços:
precisa de quorum