Rede é onde o cluster Proxmox mais apanha — e o pior tipo de erro de rede é o que não aparece na instalação. O cluster sobe, as VMs pingam, tudo parece certo. O problema surge três meses depois, na primeira migração ao vivo de uma VM grande, quando o Corosync perde pacote, o nó é expulso do quórum e VMs saudáveis reiniciam sozinhas. Desenho de rede não é detalhe de instalação: é o que decide se o cluster aguenta produção.

O modelo mental certo: é uma bridge Linux, não um switch mágico

O Proxmox não inventou uma camada de rede própria. Ele usa o que o kernel Linux já oferece: bridges, bonds e interfaces VLAN. Aquele vmbr0 que aparece na interface é uma bridge Linux comum — um switch de camada 2 em software, que conecta as interfaces virtuais das VMs a uma interface física do host.

Isso é uma boa notícia por dois motivos. Primeiro, o comportamento é previsível e documentado há décadas. Segundo, tudo o que você sabe de rede Linux vale aqui: ip a, bridge link, ethtool, tcpdump. Se você tratar a rede do Proxmox como uma caixa-preta proprietária, vai depurar no chute. Se tratar como Linux, vai depurar com ferramenta.

A configuração vive em /etc/network/interfaces, no formato do ifupdown2. A interface web escreve nesse arquivo — ela é uma conveniência, não uma camada separada. Vale saber ler o arquivo: em incidente, é mais rápido que navegar por telas.

O erro fundador: tudo numa interface só

A instalação padrão cria uma bridge sobre uma única placa de rede, e é assim que a maioria dos clusters entra em produção. Funciona em laboratório. Em produção, significa que cinco tipos de tráfego muito diferentes disputam o mesmo fio:

• Corosync, a comunicação de cluster, que é minúscula em volume e brutalmente sensível a latência.
• Migração ao vivo, que satura o link inteiro por minutos quando move uma VM de 32 GB.
• Storage — Ceph, NFS ou iSCSI —, que é constante e sofre com qualquer atraso.
• Tráfego das VMs, imprevisível por definição, porque é o seu cliente usando o serviço.
• Gestão e backup, que enche o link em janelas concentradas.

O conflito mais destrutivo é entre migração e Corosync. Uma migração satura o link, o Corosync começa a perder pacote, o nó é considerado morto pelos outros e o mecanismo de HA age exatamente como foi projetado: reinicia as VMs em outro nó. Você acabou de derrubar um serviço que estava perfeitamente saudável, por causa de uma operação de rotina.

Separação de tráfegos: o desenho de referência

Não existe número mágico de placas, mas existe uma ordem de prioridade clara sobre o que separar primeiro:

Com poucas interfaces, priorize nesta ordem: primeiro tire o Corosync do caminho de todo mundo, depois o storage, depois a migração. Se você tem apenas duas placas, o desenho mínimo defensável é um bond para Corosync e gestão, e outro bond para VMs, storage e migração — com limite de banda configurado na migração para ela não engolir o storage.

Bonding: escolha o modo pelo que o switch permite

Agregar interfaces resolve duas coisas ao mesmo tempo: tolerância a falha e, dependendo do modo, mais banda. Os modos que importam na prática:

1. LACP (802.3ad) é a escolha padrão quando você controla o switch e ele suporta agregação. Distribui por fluxo, tolera queda de link e é o mais previsível de operar. Exige configuração do lado do switch — um port-channel correspondente.
2. active-backup é o modo à prova de ambiente hostil. Não soma banda: um link trabalha, o outro espera. Em compensação, funciona com qualquer switch, sem configuração especial, e sobrevive a switches empilhados de forma esquisita. Para a rede do Corosync, costuma ser a escolha mais sensata — ali você quer estabilidade, não vazão.
3. balance-alb dispensa suporte do switch e distribui carga manipulando ARP. É tentador justamente por não exigir nada do switch, mas o comportamento com VLAN e com bridge é cheio de arestas. Evite em cluster de produção.

Um detalhe que morde muita gente no LACP: a distribuição é por fluxo, não por pacote. Uma única migração ao vivo é um fluxo TCP e vai usar um link do bond. Bond de 2×10 Gbps não entrega 20 Gbps para uma migração — entrega 10. Se a sua meta é migração mais rápida, o caminho é interface mais rápida, não mais interfaces no bond.

VLANs: prefira a VLAN-aware bridge

Há dois jeitos de fazer VLAN no Proxmox. O antigo é criar uma bridge por VLAN no host — vmbr0.100, vmbr0.200 e assim por diante. Funciona, mas cada VLAN nova exige mexer na configuração de rede de todos os nós.

O jeito recomendado é marcar a bridge como VLAN-aware. Aí você configura o trunk uma vez, e passa a definir a VLAN na própria placa de rede virtual da VM, por número. Criar uma VLAN nova para um cliente novo passa a ser um campo preenchido na VM, não uma alteração de infraestrutura em cada host.

Duas armadilhas recorrentes. A primeira: o trunk precisa liberar as VLANs no switch — a bridge estar VLAN-aware não convence o switch a entregar tráfego que ele não foi configurado para entregar. A segunda: com bridge VLAN-aware, o host precisa da sua própria interface VLAN para falar na rede de gestão. Esquecer isso é o clássico "reconfigurei a rede e perdi o acesso ao nó".

MTU: só aumente se aumentar em todo o caminho

Jumbo frames — MTU 9000 — dão ganho real em rede de storage, principalmente Ceph. Menos overhead por pacote, menos interrupção por byte transferido.

O risco é que MTU é uma propriedade do caminho inteiro, não de uma ponta. Se o host manda 9000, o switch aceita 9000 e o outro host está em 1500, o resultado não é um erro claro: é fragmentação, retransmissão e uma lentidão intermitente muito difícil de rastrear. Pior ainda quando o switch está em 9000 mas um dos nós voltou a 1500 depois de uma troca de placa.

Regra prática: só suba o MTU na rede de storage, faça em todos os nós e no switch, e valide com um ping de tamanho fixo e sem fragmentação antes de considerar o assunto resolvido. E documente a decisão, porque o próximo nó adicionado ao cluster precisa nascer com o mesmo MTU.

Corosync quer latência, não banda

Vale repetir porque quase todo desenho ruim erra nisso: o Corosync troca muito pouco dado. O que ele não tolera é atraso e perda. Um link de 1 Gbps ocioso serve melhor ao Corosync do que um link de 25 Gbps compartilhado com migração e backup.

Configure também um segundo anel de Corosync em outra rede física, quando houver interface disponível. É o mecanismo que impede que a queda de um switch derrube o quórum do cluster inteiro. É configuração de poucos minutos e evita uma classe completa de incidentes.

Ceph: duas redes, não uma

Quem roda Ceph hiperconvergente precisa entender que ele tem dois tipos de tráfego bem diferentes. A rede pública atende os clientes — os hosts lendo e escrevendo nos discos. A rede de cluster carrega replicação e recuperação entre OSDs.

A diferença aparece no pior momento possível: quando um disco ou um nó falha, o Ceph inicia a recuperação e a rede de cluster satura. Se ela é a mesma rede pública, a performance de todas as VMs cai justamente durante o incidente — quando você menos pode se dar ao luxo disso. Separar as duas redes é o que mantém o ambiente utilizável enquanto o Ceph se reconstrói sozinho.

Nomes de interface previsíveis

Placas de rede em Linux moderno recebem nomes derivados do hardware, como enp3s0f1. Isso é melhor que o antigo eth0 sorteado a cada boot, mas ainda muda quando você troca uma placa de slot ou substitui hardware — e uma interface renomeada é uma interface fora do bond, ou seja, um nó fora da rede após o reboot.

Duas defesas simples: documente qual porta física corresponde a qual nome em cada nó, com etiqueta no equipamento; e, depois de qualquer manutenção de hardware, confira a configuração de rede antes de devolver o nó ao cluster.

O firewall que tranca você do lado de fora

O Proxmox tem firewall integrado em três níveis: datacenter, nó e VM. É um recurso bom e vale usar. Também é o caminho mais rápido para perder acesso ao seu próprio cluster.

Antes de ligar o firewall no nível de datacenter, garanta que as regras liberam o que o cluster precisa para viver: o Corosync entre os nós, a porta da interface de gestão, o SSH e o tráfego de storage. E tenha um caminho de recuperação fora da rede — acesso físico, IPMI ou console remoto. Ligar firewall em cluster acessado apenas por SSH, sem plano B, é aposta ruim.

Erros comuns

• Corosync no mesmo link da migração ao vivo, gerando reinício de VM saudável.
• Bond LACP sem port-channel correspondente no switch.
• Esperar 20 Gbps de um bond 2×10 numa migração que é um único fluxo TCP.
• MTU 9000 em alguns nós e 1500 em outros, com lentidão intermitente.
• Bridge VLAN-aware sem liberar as VLANs no trunk do switch.
• Nenhum segundo anel de Corosync, deixando o quórum na mão de um switch.
• Ceph com rede pública e de cluster juntas, degradando tudo durante a recuperação.
• Firewall de datacenter ligado sem acesso alternativo ao nó.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, projetamos a rede do cluster antes de instalar qualquer coisa: levantamos o hardware disponível, definimos a separação de tráfegos possível com as interfaces que existem, escolhemos os modos de bond de acordo com o seu switch e documentamos o desenho para que o próximo nó nasça igual aos outros. Também revisamos clusters já em produção — boa parte dos incidentes de HA que investigamos termina em uma causa de rede que estava lá desde o primeiro dia.

Quer uma revisão do desenho de rede do seu cluster? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.