Docker Swarm em três continentes: alta disponibilidade concebida para 100 % de uptime

Um servidor num centro de dados é um ponto único de falha, por melhores que sejam o hardware e a rede. Se a localização falhar, seja por uma avaria na energia ou na rede, seja simplesmente por um erro durante uma manutenção, a aplicação fica indisponível. O Docker Swarm em vários centros de dados resolve exatamente este problema: os containers correm em três localizações independentes, idealmente em três continentes, e, se uma delas falhar por completo, as outras duas assumem o trabalho sem que os utilizadores deem por nada.

Este artigo mostra, passo a passo, como montar um cluster Docker Swarm concebido para 100 % de uptime: um servidor na América do Norte, outro na Europa e outro na Ásia, uma rede WireGuard encriptada entre os nós, um quórum de managers que sobrevive à falha de um continente inteiro, um ponto de entrada por região e um failover de DNS que encaminha automaticamente os utilizadores para a localização saudável mais próxima. Além disso, explicamos com honestidade o que ainda pode falhar mesmo com esta arquitetura e como pode cobrir também esses riscos.

É possível chegar aos 100 % de uptime com o Docker Swarm?

Um Docker Swarm distribuído por três continentes está concebido para 100 % de uptime: nenhum servidor, nenhum centro de dados e nenhum continente consegue, por si só, parar a aplicação. Ainda assim, ninguém pode garantir uma disponibilidade absoluta, nem mesmo os grandes fornecedores de cloud, cujos compromissos mais elevados se situam entre 99,99 e 99,999 %. A razão não está nos centros de dados, mas naquilo que todas as localizações têm em comum. É precisamente isso que este artigo também aborda, para que chegue tão perto dos 100 % quanto é tecnicamente possível.

O que a disponibilidade significa em números

O cálculo baseia-se em 8 760 horas por ano e 730 horas por mês. Cada nove adicional reduz o tempo de inatividade permitido a um décimo, e é precisamente aí que começa o trabalho que um único servidor já não consegue fazer.

Porque é que três continentes fazem tanta diferença

Três localizações independentes entre si, cada uma com 99,9 % de disponibilidade, só ficam indisponíveis em simultâneo, em termos de cálculo, se as três tiverem uma avaria ao mesmo tempo: 0,1 % vezes 0,1 % vezes 0,1 % dá 0,0000001 %. Quanto mais afastadas estiverem as localizações, mais independentes são na realidade: redes elétricas próprias, ligações de rede próprias, condições meteorológicas próprias, janelas de manutenção próprias. Por isso, a distribuição pela América do Norte, pela Europa e pela Ásia é a forma mais robusta de tolerância a falhas que se pode construir com servidores.

O que ainda pode falhar, mesmo com três continentes

Os riscos que restam são as dependências comuns a todas as localizações, e para cada uma delas existe uma contramedida:

• Uma atualização defeituosa é distribuída pelo cluster a todas as localizações com a mesma fiabilidade que uma atualização correta. Contramedida: health checks e rollback automático, e ainda atualizações região a região.
• O DNS é o único ponto por onde passam todos os utilizadores. Contramedida: um fornecedor de DNS com rede distribuída por todo o mundo e failover, TTL curto.
• A base de dados tem de ter os mesmos dados em todas as localizações. Contramedida: replicação com comutação automática, ver a secção sobre dados.
• Certificados e domínios expirados afetam todas as localizações ao mesmo tempo. Contramedida: renovação automática e monitorização das datas de expiração.
• A própria comutação demora até que os health checks e o DNS reajam, normalmente um a dois minutos, durante os quais alguns pedidos podem falhar. Contramedida: intervalos de verificação curtos, TTL curto e clientes que repetem os pedidos falhados.

Visão geral da arquitetura

Um Docker Swarm distribuído por vários continentes é composto por seis componentes. Cada um deles elimina um ponto de falha específico:

Quantos managers e onde?

Os nós manager de um Swarm gerem o estado do cluster com o algoritmo de consenso Raft. Cada alteração precisa da aprovação de uma maioria dos managers, o chamado quórum. Se a maioria deixar de estar disponível, os containers existentes continuam a correr, mas o cluster deixa de conseguir reagendar, compensar falhas ou distribuir atualizações.

A Docker recomenda um número ímpar de managers e a distribuição por pelo menos três zonas: com três managers, na proporção 1-1-1; com cinco, na proporção 2-2-1. Daqui resulta a regra mais importante deste artigo: duas localizações não chegam. Com duas localizações, uma delas tem forçosamente mais managers e, se for precisamente essa a falhar, perde-se a maioria. Só com três localizações é que o quórum sobrevive à falha de qualquer centro de dados e, portanto, com três continentes, à falha de um continente inteiro.

Três continentes ou um só continente: prós e contras

Cada alteração ao cluster, cada deployment e cada reagendamento de um container espera pela confirmação da maioria dos managers. Entre a Europa, a América do Norte e a Ásia, cada uma destas confirmações demora o tempo de trânsito dos pacotes, cerca de 80 a 250 milissegundos. Para os utilizadores, isto é irrelevante, porque os seus pedidos são respondidos localmente; mas os deployments e os reagendamentos demoram visivelmente mais do que num cluster com distâncias curtas.

Para aplicações com utilizadores em vários continentes e com o objetivo da máxima disponibilidade possível, a variante com três continentes é a certa, e é essa que montamos no guia. Há uma regra importante que atravessa todos os passos: cada pedido é respondido na sua região e nunca viaja de um continente para outro.

Que localizações da KernelHost são adequadas

A KernelHost opera servidores no centro de dados maincubes, em Frankfurt am Main, e oferece servidores virtuais noutras localizações na Europa, na América do Norte e na Ásia-Pacífico, entre as quais três localizações nos EUA e ainda Canadá, Londres, Estrasburgo, Varsóvia, Helsínquia, Singapura, Japão, Sydney e Mumbai. A lista completa, com mapa, está na página Localizações de servidores. Para o exemplo deste artigo, usamos Frankfurt am Main para a Europa, a costa leste dos EUA para a América do Norte e Singapura para a Ásia.

Guia: montar um Docker Swarm em três continentes

O exemplo usa três servidores: swarm-eu em Frankfurt am Main, swarm-us na costa leste dos EUA e swarm-asia em Singapura. Os endereços públicos vêm da rede de documentação 203.0.113.0/24 e a rede WireGuard usa 10.10.0.0/24. Substitua ambos pelos seus valores. Os três nós são, ao mesmo tempo, managers e workers; para ter mais capacidade, acrescente mais tarde, em cada região, nós que sejam apenas workers.

Passo 1: disponibilizar servidores em três continentes

Encomende três servidores com Debian 12 ou 13 em três regiões e aplique a proteção básica: SSH apenas com chave, atualizações de segurança automáticas, utilizadores próprios. A lista de verificação para novos servidores root cobre tudo isto. Atribua nomes de host descritivos, para ver de imediato em docker node ls que nó está onde.

hostnamectl set-hostname swarm-eu

Passo 2: instalar o Docker em todos os nós

Instale o Docker Engine a partir do repositório oficial do Docker nos três servidores, como descrito no artigo Instalar o Docker em Debian e Ubuntu. Depois, verifique a versão em cada nó; os três devem ter a mesma versão principal:

docker version --format '{{.Server.Version}}'

Passo 3: montar uma rede WireGuard entre os continentes

Os nós comunicam entre si através da internet pública. Para que todo o tráfego do cluster seja encriptado e as portas do Swarm nunca fiquem acessíveis publicamente, uma rede WireGuard liga os três servidores. Em cada nó, gere primeiro um par de chaves:

apt-get install -y wireguard
umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key

A seguir, cada nó recebe um ficheiro /etc/wireguard/wg0.conf. Em swarm-eu tem este aspeto; os outros dois nós são configurados de forma simétrica:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = CHAVE_PRIVADA_DE_SWARM_EU
MTU = 1420

[Peer]
PublicKey = CHAVE_PUBLICA_DE_SWARM_US
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

[Peer]
PublicKey = CHAVE_PUBLICA_DE_SWARM_ASIA
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.10.0.3/32
PersistentKeepalive = 25

systemctl enable --now wg-quick@wg0
ping -c 3 10.10.0.2

Se todos os nós responderem através dos seus endereços 10.10.0.x, a rede está pronta. O PersistentKeepalive mantém a ligação aberta mesmo atrás de firewalls stateful. As latências que o ping mostra agora entre os continentes são exatamente os tempos de espera que cada alteração ao cluster custa.

Passo 4: firewall que só deixa entrar os nós do Swarm

Entre os nós, o Docker Swarm precisa da porta 2377/TCP para a gestão do cluster, da 7946/TCP e UDP para a comunicação entre os nós e da 4789/UDP para a rede overlay. Autorize estas portas exclusivamente na interface WireGuard; publicamente, só o próprio WireGuard fica aberto, e apenas para os outros nós. Com o ufw, isto fica assim em swarm-eu:

ufw allow from 203.0.113.12 to any port 51820 proto udp
ufw allow from 203.0.113.13 to any port 51820 proto udp
ufw allow in on wg0 to any port 2377 proto tcp
ufw allow in on wg0 to any port 7946
ufw allow in on wg0 to any port 4789 proto udp

Importante: as portas que o Docker publica para containers contornam o ufw, porque o Docker define as suas próprias regras iptables. Por isso, publique apenas as portas do ponto de entrada (80 e 443) e nunca portas de bases de dados ou de administração.

Passo 5: inicializar o Swarm e adicionar os managers

Em swarm-eu, inicialize o Swarm e garanta que a gestão e o tráfego de dados passam pelo WireGuard:

docker swarm init --advertise-addr 10.10.0.1 --data-path-addr 10.10.0.1
docker swarm join-token manager

O segundo comando mostra o comando de adesão para outros managers. Execute-o em swarm-us e em swarm-asia, cada um com o seu próprio endereço WireGuard; aqui, para swarm-us:

docker swarm join --token SWMTKN-1-... --advertise-addr 10.10.0.2 --data-path-addr 10.10.0.2 10.10.0.1:2377
docker node ls

O docker node ls mostra então três nós, um deles com o estado Leader e os outros dois com Reachable. O token de adesão é um segredo: quem o conhecer pode infiltrar um manager próprio no seu cluster. Depois da montagem, renove-o com docker swarm join-token --rotate manager.

Passo 6: ativar o Autolock

Os managers guardam o estado do cluster, juntamente com as chaves que encriptam os registos Raft, em /var/lib/docker/swarm/. Com o Autolock, estas próprias chaves passam a ser encriptadas, e um manager reiniciado só volta a juntar-se ao cluster depois de ser introduzida uma chave de desbloqueio:

docker swarm update --autolock=true
docker swarm unlock

O primeiro comando mostra a chave de desbloqueio, que deve guardar num gestor de palavras-passe. O segundo é necessário depois de cada reinício de um manager. Sem a chave, nem a partir de um backup é possível restaurar o Swarm; por isso, guarde-a separada dos servidores.

Passo 7: etiquetar os nós por região

Os labels indicam ao scheduler onde se encontra cada nó. É neles que assentam as regras de colocação dos passos seguintes:

docker node update --label-add region=eu swarm-eu
docker node update --label-add region=us swarm-us
docker node update --label-add region=asia swarm-asia

Passo 8: criar uma rede overlay com a MTU adequada

Os containers em localizações diferentes comunicam entre si através de uma rede overlay. Como esta passa pelo túnel WireGuard, a sua MTU tem de ser menor: o WireGuard trabalha com 1420 bytes, a rede overlay (VXLAN) precisa de 50 bytes desses para os seus próprios cabeçalhos, e sobram 1370 bytes:

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1370 appnet

Uma MTU demasiado grande manifesta-se de forma traiçoeira: os pedidos pequenos funcionam, as respostas grandes ficam penduradas. Quem dispensar o WireGuard pode, em alternativa, encriptar a rede overlay com --opt encrypted; nesse caso, é preciso autorizar também, entre os nós, o protocolo IP 50 (ESP), e a Docker alerta expressamente para perdas de desempenho percetíveis. Recomendamos o WireGuard, porque cobre todo o tráfego, incluindo a gestão.

Passo 9: operar a aplicação em cada região

Um serviço Swarm normal distribui os pedidos, através do seu endereço de serviço, por todas as réplicas do cluster, ou seja, também pelos outros continentes. Com três continentes, um em cada dois ou três pedidos atravessaria meio mundo. Por isso, cada região recebe um serviço próprio, que se mantém na sua região graças a uma regra de colocação. As definições de atualização garantem que as novas versões são implementadas container a container e revertidas automaticamente em caso de erro:

for r in eu us asia; do
  docker service create --name web-$r --replicas 2 --network appnet \
    --constraint node.labels.region==$r \
    --update-parallelism 1 --update-delay 30s \
    --update-failure-action rollback \
    registry.example.com/web:1.0
done

Para que o Swarm detete se um container está realmente a trabalhar e não apenas a correr, a imagem deve incluir um health check, por exemplo esta linha no Dockerfile da sua aplicação:

HEALTHCHECK --interval=10s --timeout=3s --retries=3 CMD wget -qO- http://127.0.0.1:8080/health || exit 1

Um container cujo health check falhe três vezes seguidas é substituído e, durante uma atualização, um health check que falhe interrompe a implementação.

Passo 10: um ponto de entrada por região

O ponto de entrada fica a cargo de um reverse proxy como o Caddy, o Traefik ou o nginx. Também ele corre como serviço próprio em cada região e só encaminha os pedidos para a aplicação da sua região. Em modo host, publica as portas 80 e 443 diretamente no servidor da sua região. Basta uma configuração comum, porque o Caddy lê o destino a partir de uma variável de ambiente:

example.com {
    reverse_proxy {$UPSTREAM}:80
}

docker config create caddyfile ./Caddyfile
for r in eu us asia; do
  docker service create --name edge-$r --network appnet \
    --constraint node.labels.region==$r \
    --env UPSTREAM=web-$r \
    --config source=caddyfile,target=/etc/caddy/Caddyfile \
    --publish mode=host,target=80,published=80 \
    --publish mode=host,target=443,published=443 \
    caddy:2
done

Todas as regiões precisam de um certificado TLS para o mesmo domínio. Por isso, obtenha os certificados através do desafio DNS, que funciona independentemente da região para onde o registo DNS aponta nesse momento; o Caddy precisa, para tal, do módulo do seu fornecedor de DNS. As bases sobre o proxy estão no artigo Configurar o nginx como reverse proxy.

Passo 11: configurar Geo-DNS com failover

O último componente leva os utilizadores à região certa. Um serviço de DNS com encaminhamento geográfico e health checks envia os utilizadores da Europa para Frankfurt am Main, os da América para a costa leste dos EUA e os da Ásia para Singapura. Se uma região falhar, o health check deteta-o em 30 a 60 segundos e envia os respetivos utilizadores para a região saudável mais próxima. Defina o tempo de vida (TTL) dos registos para 60 segundos, para que os resolvers adotem rapidamente uma alteração. Vários registos A sem health check são apenas uma solução de recurso: os navegadores tentam muitas vezes o endereço seguinte, mas nem todos os clientes o fazem, e uma região em falha continua a constar da resposta.

Faça as contas com honestidade: entre a falha e a comutação decorre o intervalo de verificação mais o TTL, ou seja, no exemplo, um a dois minutos, durante os quais uma parte dos utilizadores da região afetada ainda chega à localização em falha. As aplicações e as apps que repetem os pedidos falhados após uma breve pausa atravessam este período quase sem que se note.

Passo 12: testar a falha de uma região

Um failover que nunca foi ensaiado raramente funciona numa emergência real. Simule a falha de uma região retirando o respetivo nó de serviço e observe como reagem o cluster e o DNS:

docker node update --availability drain swarm-asia
docker node ls
docker service ls
docker node update --availability active swarm-asia

Como os serviços da região estão presos ao seu nó por uma regra de colocação, não mudam de sítio, ficam em pausa; é o failover de DNS que assume os utilizadores da região. Por isso, neste teste, verifique sobretudo se o health check retira a região das respostas e se a região vizinha aguenta a carga adicional. Para um teste mais duro, desligue o nó completamente da rede, por exemplo parando o WireGuard. Repita o teste depois de alterações maiores e, pelo menos, uma vez por trimestre.

Dados: a parte mais difícil da alta disponibilidade

O Docker Swarm replica containers, não dados. Um volume está sempre no nó onde o container corre. Por isso, os serviços sem estado, como frontends web e API, podem funcionar sem problemas em qualquer região; para tudo o que envolva dados, precisa de uma replicação própria.

Replicar bases de dados entre continentes

As bases de dados trazem a sua própria replicação, e essa é sempre preferível a um armazenamento partilhado entre centros de dados. Entre continentes, a solução comprovada é uma instância primária numa região com réplicas assíncronas nas outras duas: no PostgreSQL, por exemplo, através de streaming replication com uma ferramenta como o Patroni para a comutação automática; no MariaDB e no MySQL, através da replicação integrada. Cada região responde então localmente às consultas de leitura, e as escritas vão para a instância primária. Sejamos honestos: assíncrono também significa que, se a região primária falhar, podem perder-se os últimos segundos de escritas. Quem quiser escrever em todo o mundo sem perder nada recorre a bases de dados construídas para várias regiões, como o CockroachDB ou o YugabyteDB. Fixe os nós da base de dados à respetiva região através de uma regra de colocação, para que o Swarm nunca os mova sem os seus dados:

docker service create --name db-asia --constraint node.labels.region==asia ...

Ficheiros e uploads

Os ficheiros carregados não devem ficar num volume local, mas sim num armazenamento de objetos compatível com S3, com replicação para uma segunda região, ou num sistema de armazenamento próprio e replicado. Sistemas de ficheiros de rede como o NFS, estendidos entre continentes, são lentos e constituem eles próprios um ponto único de falha.

Sessões e caches

Se a aplicação guardar as sessões na memória de um container, os utilizadores têm de voltar a iniciar sessão depois da comutação. Guarde as sessões numa base de dados replicada ou numa cache replicada como o Redis, ou use tokens assinados que cada região possa verificar por si própria.

Os backups continuam a ser obrigatórios

A replicação protege contra a falha de uma localização, mas não contra erros: um registo apagado por engano fica apagado em todas as regiões segundos depois. Por isso, qualquer arquitetura de alta disponibilidade precisa de backups regulares e testados, guardados num local independente, como descrito no artigo Estratégia de backup para servidores.

Operação: atualizações, manutenção e monitorização

Atualizações região a região

Não implemente novas versões em todas as regiões ao mesmo tempo, mas sim uma após outra, e observe brevemente cada região antes de passar à seguinte. Assim, um erro que nenhum health check deteta atinge, no máximo, uma região, e as outras duas continuam a servir os utilizadores dessa região:

for r in asia us eu; do
  docker service update --image registry.example.com/web:1.1 web-$r || break
  sleep 300
done

Se uma atualização falhar, o Swarm reverte-a automaticamente graças às definições do passo 9, e o || break termina o ciclo assim que o comando devolve um erro. Uma atualização cujo problema só se nota mais tarde é revertida manualmente com docker service rollback web-asia.

Manutenção de uma região

Se um servidor tiver de ser reiniciado ou atualizado, retire-o de serviço com docker node update --availability drain e deixe que, antes disso, o failover de DNS encaminhe os seus utilizadores para as regiões vizinhas. Depois da manutenção, volte a ativá-lo com --availability active. Antes de passar ao manager seguinte, espere até que o docker node ls volte a mostrar os três como acessíveis, para que nunca faltem dois managers ao mesmo tempo.

Monitorização a partir do exterior

Monitorize cada região separadamente e a partir de fora do cluster: a acessibilidade dos pontos de entrada, os health checks dos serviços, o estado dos managers, o atraso de replicação da base de dados e as datas de expiração dos certificados e dos domínios. Um alarme tem de chegar mesmo quando uma região inteira fica em silêncio. O artigo Configurar a monitorização de servidores mostra como montar isto para servidores individuais.

Distribuir segredos em segurança

As palavras-passe e as chaves não devem ficar em variáveis de ambiente nem em ficheiros Compose, mas sim em Docker Secrets. Estes são guardados encriptados no registo Raft e só são entregues aos serviços a que os atribuir expressamente:

printf '%s' 'SUA_PALAVRA_PASSE_DA_BASE_DE_DADOS' | docker secret create db_password -
docker service update --secret-add db_password web-eu

Porquê a KernelHost para um Swarm em vários continentes

Um cluster em vários continentes coloca ao fornecedor exigências diferentes das de um único servidor. Na prática, são estes os pontos decisivos:

Encontra uma visão geral de todos os planos cloud, com preços, e uma comparação de custos com os grandes fornecedores de cloud na página Alugar servidor cloud.

Erros frequentes e como evitá-los

• Managers em apenas duas localizações. Se a localização com a maioria falhar, o cluster fica parado. Solução: três localizações, distribuição 1-1-1 ou 2-2-1.
• Número par de managers. Quatro managers não toleram mais falhas do que três, mas aumentam o esforço de coordenação. Solução: 3, 5 ou 7.
• Pedidos que viajam entre continentes. Um endereço de serviço comum a todas as regiões envia os utilizadores a meio mundo de distância. Solução: um serviço e um ponto de entrada por região.
• Portas do Swarm acessíveis publicamente. A porta 2377 e a rede overlay nunca devem estar expostas à internet. Solução: apenas através do WireGuard; publicamente, só as portas 80 e 443 e o WireGuard para os outros nós.
• MTU esquecida. As respostas grandes ficam penduradas, as pequenas funcionam. Solução: MTU do overlay de 1370 com o WireGuard a 1420.
• Confiar no ufw para as portas dos containers. O Docker contorna o ufw nas portas publicadas. Solução: publicar apenas o ponto de entrada.
• Base de dados num volume sem replicação. Se a região falhar, os dados ficam inacessíveis. Solução: replicação da base de dados e colocação fixa na região.
• Atualização em todas as regiões ao mesmo tempo. Um erro atinge então todos os utilizadores do mundo. Solução: implementar região a região.
• TTL de DNS elevado. Com um TTL de um dia, o failover só produz efeito no dia seguinte. Solução: 60 segundos.
• Replicação em vez de backup. Um erro é replicado tal como os dados corretos. Solução: backups testados adicionais, num local independente.

Em resumo

• Um Docker Swarm distribuído por três continentes está concebido para 100 % de uptime: uma localização ou um continente inteiro pode falhar sem que a aplicação pare.
• Ninguém pode garantir uma disponibilidade absoluta; os riscos que restam são o DNS, as atualizações defeituosas, a base de dados e os certificados, e para cada um deles existe uma contramedida.
• Três managers em três localizações são o mínimo; duas localizações não chegam para um quórum tolerante a falhas.
• Cada pedido fica na sua região: um serviço e um ponto de entrada por região, e ainda Geo-DNS com health checks e TTL curto.
• O WireGuard encripta o tráfego do cluster, as portas do Swarm ficam invisíveis e a MTU do overlay desce para 1370.
• O Swarm replica containers, não dados: as bases de dados precisam de replicação própria e os backups continuam a ser obrigatórios.
• A KernelHost oferece localizações na Europa, na América do Norte e na Ásia-Pacífico, tráfego ilimitado, proteção DDoS em todas as localizações e faturação PrePaid sem período mínimo.