Você configura o cluster, valida os VMs e, de repente, uma queda de energia ou um cabo de rede frouxo derruba toda a operação. Para muitos administradores de infraestrutura, essa é a dor mais comum: acreditar que ter dois servidores resolve o problema de conectividade. A realidade é cruel com quem ignora a camada física. Uma rede redundante no Proxmox não é um luxo; é o único mecanismo que garante que sua infraestrutura continue respondendo quando o cabo principal falha.

Neste post:
A alta disponibilidade depende de múltiplas camadas. Se o storage fica offline, você perde acesso aos dados. Se o hypervisor trava, suas máquinas virtuais param. Mas se a rede cai, você não consegue gerenciar nada disso remotamente. A redundância de link é a espinha dorsal do seu data center virtualizado. Sem ela, você opera no limite do risco aceitável. Este guia técnico explica como estruturar essa camada crítica, comparando os modos de bonding e a importância do LACP para balanceamento real de carga. Vamos além da configuração básica de interface, explorando as nuances que separam um laboratório funcional de uma produção estável. ## Por que a rede falha (e como o Proxmox reage) Antes de tocar no código ou na interface web do Proxmox, é vital entender os vetores de falha. Cabos SFP danificados, portas de switch com firmware desatualizado ou, simplesmente, um erro humano desconectando o link errado são ocorrências diárias em infraestruturas reais. Quando umaNIC (interface de rede) falha, o sistema operacional precisa detectar essa queda e redirecionar o tráfego para a interface espelhada instantaneamente. No Linux, que é o núcleo do Proxmox VE, isso é gerenciado pelo módulo 802.3ad ou drivers de bonding genéricos. Se você não configurar esse processo, a falha física resulta em downtime completo até que um técnico intervina manualmente. A redundância não serve apenas para tolerância a falhas; ela também impacta a performance. Links de 1Gbps são insuficientes para clusters modernos que realizam migrações live (vMotion/Proxmox Live Migration) e replicação de storage simultaneamente. Aqui entra a necessidade de agregar largura de banda, transformando dois ou mais links físicos em um único canal lógico com throughput superior. ## Bonding e LACP: Entendendo os Modos A confusão entre bonding e LACP é frequente. O bonding é o mecanismo do kernel Linux que agrega interfaces. O LACP (Link Aggregation Control Protocol) é um protocolo padrão IEEE (802.3ad/802.1ax) que negocia essa agregação com o switch. Para montar uma rede redundante no Proxmox eficiente, você precisa escolher o modo de bonding correto. Nem todos os modos funcionam com LACP, e nem todos oferecem a mesma garantia de failover. ### Modos Principais de Bonding no Linux 1. **Mode Balance-rr (0):** Round-robin. Alterna pacotes entre as interfaces. Oferece alta taxa de transferência, mas pode causar problemas em switches antigos que não suportam agregação ou causam reordenação de pacotes. 2. **Mode Active-backup (1):** Failover puro. Uma interface ativa, outra em espera. Se a ativa cair, a passiva assume. Não agrega largura de banda, mas é o mais simples e compatível com qualquer switch, mesmo sem suporte a LACP. Ideal para gerenciamento, mas ruim para tráfego pesado. 3. **Mode Balance-tcp (5):** Balanceamento baseado em hash de TCP. Distribui fluxos diferentes por interfaces distintas. Requer configuração específica no switch para evitar perda de pacotes. 4. **Mode 802.3ad (LACP - 4):** O padrão ouro para data centers. Usa o protocolo LACP para negociar a agregação com o switch. Garante que os dois links estejam ativos e compartilhando a carga dinamicamente. Aqui está a tabela comparativa rápida para decidir sua estratégia: | Modo | Redundância (Failover) | Agregação de Banda | Requisitos de Switch | Uso Recomendado | | :--- | :---: | :---: | :--- | :--- | | **Active-backup (1)** | Sim | Não | Nenhum (Plug & Play) | Gerenciamento, VMs leves | | **802.3ad LACP (4)** | Sim | Sim | Suporte a LACP/Trunking | Storage, Live Migration, Alta Carga | | **Balance-rr (0)** | Sim | Sim | Compatível com Agregação | Cenários específicos de alta IOPS | Para clusters Proxmox que rodam máquinas virtuais intensivas, o modo LACP é quase obrigatório. Ele permite que você utilize links de 10Gbps ou 25Gbps agregados, garantindo que a migração de uma VM não congestionue a rede de gerenciamento. ## Configuração Prática no Proxmox VE A configuração pode ser feita via interface web (GUI) ou diretamente no arquivo de configuração do sistema (/etc/network/interfaces). A GUI é segura para a maioria dos casos, mas editar o arquivo direto oferece mais controle e visibilidade sobre o estado final. ### Passo 1: Preparação do Switch Antes de configurar o Proxmox, configure o switch. Você deve criar um Port-Channel (ou EtherChannel) que agrupa as portas físicas conectadas aos dois nós do cluster. * Defina o modo do link como lacp ou dynamic. * Certifique-se de que o VLAN tag seja propagado corretamente se você usar VLANs separadas para storage e tráfego geral. * **Importante:** O tipo de agregação deve ser consistente em todos os switches do caminho (topologia spine-leaf ou core). ### Passo 2: Configurando no Proxmox (GUI) 1. Acesse o nó do Proxmox. 2. Vá em System > Network. 3. Crie uma nova Bridge, por exemplo, vmbr10. 4. Nas configurações da bridge, selecione as interfaces físicas (ex: eth0, eth1). 5. Em Bonding Mode, selecione 802.3ad (LACP). 6. Defina o MTU. Se seu switch e storage suportarem jumbo frames, defina para 9000. Isso reduz a sobrecarga de CPU no processamento de pacotes pequenos. ### Passo 3: Verificando o Status Após aplicar as alterações, verifique se o link está ativo. No terminal do Proxmox, execute: cat /proc/net/bonding/bond0 Você deve ver ambas as interfaces listadas como "up" e "slave". Se uma estiver "down", o LACP não negociou corretamente com o switch. Verifique os logs do switch para erros de LACP negotiation. ## Erros Comuns na Implementação Mesmo com a documentação à mão, erros de configuração podem levar a loops de broadcast ou perda total de conectividade. Fique atento a estes pontos críticos ao montar sua rede redundante no Proxmox. ### 1. Descompasso de Configuração entre Switch e Host O erro mais fatal é configurar LACP no Proxmox mas deixar o switch em modo estático (sem protocolo). O switch verá as negociações LACP vindas do servidor como "ruído" ou ignorará os links, mantendo-os em estado de standby ou bloqueados. Sempre sincronize a configuração: se o host usa 802.3ad, o switch deve usar lacp dynamic ou active. ### 2. Ignorar a Redundância de Switch Ter dois cabos no servidor não ajuda se ambos estão conectados ao mesmo switch físico. Se esse switch perder energia ou travar, sua redundância cai junto. A regra de ouro é: cada interface do bond deve ir para um switch diferente (topologia ToR distinta) ou, pelo menos, para portas em switches com fontes redundantes e caminhos físicos separados. ### 3. MTU Incompatível Se você ativa jumbo frames (MTU 9000) no Proxmox, mas o switch tem MTU padrão (1500) em alguma parte do caminho, os pacotes maiores serão descartados silenciosamente. Isso resulta em lentidão extrema ou falhas intermitentes de conexão. Valide o MTU ponta a ponta: NIC do servidor -> Switch -> Switch de Core -> Storage/Internet. ### 4. VLANs Tagging Incorreto Ao usar LACP com VLANs, certifique-se de que as interfaces físicas estejam configuradas como "trunk" no switch, permitindo a passagem das tags VLAN. Se o switch estiver em modo "access", ele removerá as tags antes que o Proxmox as veja, quebrando a lógica de roteamento interno do cluster. ## Perguntas frequentes

Posso usar Bonding sem LACP no meu cluster?

Sim. O modo Active-backup (1) não requer suporte a LACP no switch. Você pode conectar cada cabo em portas independentes e o Proxmox alternará entre elas se uma falhar. É uma solução válida para ambientes pequenos ou de baixo custo, mas você perderá a agregação de banda. O throughput máximo será limitado à velocidade de um único link (ex: 1Gbps), mesmo tendo dois cabos conectados.

Qual a diferença entre LACP e Link Aggregation genérica?

Link Aggregation é o conceito geral de juntar links. LACP (802.3ad) é o protocolo que automatiza essa junção. Sem LACP, você pode configurar agregação estática no switch, mas isso não detecta falhas na extremidade oposta (no servidor) dinamicamente. O LACP envia pacotes de controle periódicos para verificar se os dois lados estão saudosos. Para alta disponibilidade real, o LACP é superior à configuração estática manual.

O Proxmox suporta mais de 4 interfaces no mesmo Bond?

Tecnicamente sim, mas há limitações práticas. O protocolo LACP padrão (802.3ad) define um máximo de 16 links, mas a implementação do kernel Linux e a maioria dos switches comerciais recomendam ou limitam a 8, 4 ou até 2 links ativos simultaneamente para simplificar o hashing. Usar mais de 4 interfaces em um único bond no Proxmox pode gerar complexidade desnecessária e overhead de CPU sem ganhos lineares de performance. Para escalabilidade horizontal, prefira adicionar mais bridges ou usar SDN (Software Defined Networking).

Como diagnosticar se meu Bond está funcionando corretamente?

Além do comando cat /proc/net/bonding/bond0, você pode forçar um failover manual para testar a resposta. No terminal, execute: ip link set eth0 down (substituindo pela interface principal). Se o tráfego continuar fluindo e o bond relatar que eth1 é agora a porta ativa, sua redundância está operacional. Monitore também os logs do kernel com dmesg | grep -i bond para ver mensagens de link up/down.

Bonding afeta a performance das VMs?

O overhead do bonding no kernel Linux é mínimo na maioria dos cenários modernos. No entanto, o algoritmo de hashing (que decide qual link usar para qual pacote) pode causar desbalanceamento se o tráfego vier de poucas fontes (ex: um único cliente grande). O modo Balance-tcp (5) ou LACP com hash baseado em endereço MAC/IP/TCP port tende a distribuir melhor a carga do que modos baseados apenas em MAC. ## Conclusão Montar uma rede redundante no Proxmox não é apenas sobre conectar dois cabos. É sobre entender como o protocolo LACP negocia estados, como o switch processa os frames e como o kernel Linux gerencia o failover. A diferença entre um ambiente resiliente e um frágil está nos detalhes da configuração: MTU alinhado, switch configurado corretamente e topologia física diversificada. Investir tempo nessa camada de infraestrutura paga dividendos em estabilidade. Quando a falha acontecer — e ela acontecerá — seu cluster continuará rodando, suas VMs migrarão sem dor e seus clientes nem notarão o susto. A alta disponibilidade é construída bit a bit, cabo a cabo. Para garantir que sua infraestrutura de cloud e virtualização opere no mais alto nível de eficiência, conte com especialistas que entendem a fundo essas nuances de rede e hardware. A equipe da Toda Solução está preparada para auditar e otimizar sua arquitetura de servidores, garantindo que seu negócio nunca pare por uma questão de conectividade.