Como configurar failover automático de rede no systemd-networkd

Por que usar o systemd-networkd para failover de rede

Manter servidores sempre acessíveis exige resiliência física e lógica na infraestrutura. Em distribuições Linux modernas, o systemd-networkd — o serviço nativo do sistema operacional responsável por gerenciar endereços IP, placas de rede e conexões — oferece ferramentas poderosas para garantir que sua máquina mude para uma rota secundária automaticamente se a principal cair. Na prática, isso significa que se o seu link principal de internet ou conexão com o switch falhar, o tráfego é desviado para uma rota alternativa sem derrubar os serviços ou exigir intervenção manual.

Diferente de abordagens tradicionais que dependem de scripts em Python ou Bash rodando em segundo plano para pingar endereços externos, o systemd-networkd faz isso de forma integrada e no nível do kernel. Isso reduz o consumo de recursos e elimina falhas de execução comuns em ferramentas externas. Além disso, essa abordagem se integra perfeitamente a outras rotinas de infraestrutura, como o gerenciamento de regras de firewall ou a auditoria de portas abertas detalhada em guias sobre como usar o comando ss no Linux para auditar conexões de rede. O resultado é um ambiente mais limpo, previsível e fácil de manter a longo prazo.

Compreendendo o monitoramento de link nativo

O monitoramento de link nativo no systemd-networkd baseia-se na verificação da saúde das rotas e na resposta do gateway. O kernel do Linux mantém tabelas de roteamento que definem para onde cada pacote de dados deve ir. Quando configuramos rotas estáticas com diferentes métricas, dizemos ao sistema qual caminho priorizar. Se o roteador principal deixa de responder aos pacotes ARP ou falha no encaminhamento, o sistema operacional percebe a perda de contato e invalida aquela rota.

Na prática, o systemd-networkd permite atribuir custos (métricas) e prioridades para cada interface de rede. Um link com métrica menor é sempre o preferido. Quando esse link perde a conectividade com o gateway, a rota perde validade e o kernel ativa automaticamente a rota seguinte, que possui métrica maior. Essa troca ocorre em frações de segundo, garantindo que aplicações críticas continuem operando sem quedas perceptíveis para os usuários finais ou clientes conectados ao servidor.

Estruturando a configuração das interfaces de rede

Para colocar a alta disponibilidade em prática, precisamos criar arquivos de configuração específicos dentro do diretório /etc/systemd/network/. Cada interface física ganha um arquivo .network dedicado que define seu comportamento. Abaixo, mostramos um exemplo de configuração para uma placa de rede principal (por exemplo, eth0) operando com endereço IP estático e métrica baixa.

[Match]
Name=eth0

[Network]
Address=192.168.1.50/24
Gateway=192.168.1.1
Metric=10
DNS=8.8.8.8

Neste bloco, o parâmetro Metric=10 define que esta interface tem alta prioridade. O sistema vai preferir esta rota para todo o tráfego de saída. Caso você precise ajustar nomes de domínios locais ou mapear endereços estáticos adicionais para testes internos, vale a pena consultar o procedimento descrito em como configurar o arquivo hosts no Windows e no Linux para complementar a resolução de nomes na sua rede local.

Criando a rota estática alternativa para o failover

O segredo do failover sem scripts externos está na criação de uma rota secundária com métrica superior. Vamos configurar uma segunda interface (por exemplo, eth1) ou um gateway secundário na mesma rede para assumir o controle caso o link primário deixe de responder. Criamos um arquivo .network para a interface de backup com uma métrica mais alta, indicando que ela só deve ser usada quando a primeira falhar.

[Match]
Name=eth1

[Network]
Address=192.168.2.50/24
Gateway=192.168.2.1
Metric=100

Com o parâmetro Metric=100, o systemd-networkd entende que a interface eth1 é a segunda opção. Enquanto eth0 estiver respondendo ao gateway 192.168.1.1, todo o tráfego flui por ela. No momento em que o kernel detecta a perda de sinal ou falha no roteador principal, a tabela de roteamento atualiza os pesos e redireciona os pacotes para o gateway 192.168.2.1 de forma totalmente transparente.

Validando e testando o failover na prática

Após aplicar as configurações salvando os arquivos e reiniciando o serviço com o comando sudo systemctl restart systemd-networkd, é fundamental validar se o failover está funcionando como esperado. Para simular uma falha real, você pode desconectar fisicamente o cabo da interface primária ou desativá-la temporariamente pelo terminal usando ferramentas de gerenciamento de link.

1. Desative a interface primária executando o comando para derrubar a placa de rede.
   

   sudo ip link set eth0 down

2. Verifique se a rota ativa mudou automaticamente para o gateway secundário listado na tabela de roteamento do sistema.
   

   ip route show

3. Reative a interface primária para testar o retorno automático do tráfego assim que o link for restabelecido.
   

   sudo ip link set eth0 up

Durante os testes de bancada, monitore também a temperatura dos componentes e do hardware para garantir que o estresse de processamento e tráfego intenso não cause instabilidades térmicas na placa-mãe ou nos adaptadores de rede, seguindo as recomendações de como monitorar a temperatura do NVMe no Linux via terminal para manter a saúde geral do servidor.

Considerações finais sobre redundância de rede

Implementar o failover automático utilizando recursos nativos do systemd-networkd eleva a confiabilidade de servidores Linux sem adicionar complexidade desnecessária ao sistema. Ao eliminar a dependência de daemons de terceiros ou scripts complexos de verificação, você ganha em velocidade de resposta e facilidade de manutenção. A gestão correta das métricas de rota garante que sua infraestrutura permaneça online mesmo diante de falhas físicas inesperadas na rede.

Compreender o comportamento do kernel e das tabelas de roteamento permite que engenheiros e administradores de sistemas construam ambientes robustos, previsíveis e altamente disponíveis. Adotar essas práticas nativas consolida uma arquitetura limpa, alinhada com os padrões modernos de engenharia de confiabilidade de sites.