O Proxmox ganhou uma camada de SDN — rede definida por software — que resolve dores reais de quem opera cluster grande ou multi-tenant. Ela também adiciona uma abstração a mais entre a VM e o pacote, e abstração cobra na hora de depurar. A pergunta certa não é se o SDN é bom, e sim se o seu ambiente tem o problema que ele resolve. Para uma parte grande dos clusters, a resposta honesta é que uma bridge VLAN-aware já basta.

O problema que o SDN resolve

Sem SDN, a rede do cluster vive no arquivo de configuração de rede de cada nó. Isso funciona bem até o momento em que não funciona mais, e o ponto de virada tem dois sintomas.

O primeiro é repetição. Cada rede nova exige a mesma alteração em todos os nós. Com três nós e cinco redes, é administrável. Com nove nós e sessenta redes de clientes, é uma fonte constante de divergência — e a divergência aparece como "a VM funciona no nó 3 e não funciona no nó 7", que é um dos problemas mais chatos de diagnosticar.

O segundo é limite da VLAN. VLAN não atravessa roteador. Se o seu cluster cresceu para outro rack, outra sala ou outro site, com roteamento no meio, a VLAN do cliente para na fronteira da camada 2. E o espaço de VLANs, com pouco mais de quatro mil identificadores, é finito para um provedor com muitos clientes e várias redes por cliente.

Com SDN, a rede passa a ser definida no cluster e distribuída para os nós. E, com overlay, ela deixa de depender de camada 2 contígua.

O vocabulário mínimo

Quatro conceitos organizam tudo:

• Zona é o mecanismo de transporte: como o tráfego trafega entre os nós. É aqui que se escolhe VLAN, VXLAN ou EVPN.
• VNet é a rede virtual que a VM enxerga. Na prática, é o que aparece para ser selecionado na placa de rede da VM.
• Sub-rede é o endereçamento associado a uma VNet, com gateway e faixa.
• IPAM é o controle de quais endereços estão em uso, para o cluster distribuir sem conflito.

Os tipos de zona, e para que servem

1. Simples. Cria uma bridge isolada por nó, com roteamento e NAT feitos pelo próprio host. Útil para rede interna de laboratório ou para dar saída a VMs sem expor endereçamento. Não conecta VMs entre nós diferentes.
2. VLAN. Gerencia centralmente as VLANs que já existem na sua infraestrutura física. É o degrau mais baixo de adoção e o de melhor relação entre benefício e risco: você continua com VLAN, mas para de editar nó por nó.
3. QinQ. Empilha duas etiquetas de VLAN, permitindo que cada cliente tenha o próprio espaço de VLANs dentro de uma VLAN externa. Resolve o esgotamento de identificadores em cenário de provedor, e exige switch que suporte.
4. VXLAN. Encapsula camada 2 dentro de UDP, criando uma rede sobreposta que atravessa roteamento. É o que permite a mesma rede de cliente existir em racks ou sites diferentes, com um espaço de identificadores muito maior.
5. EVPN. VXLAN com um plano de controle em BGP. Além de estender camada 2, roteia entre VNets, distribui as rotas de forma organizada e permite definir nós de saída para o tráfego externo. É o desenho mais completo e o mais exigente.

Quando vale, e quando não

A leitura mais importante dessa tabela é a primeira linha. Se você tem poucos nós e um punhado de VLANs estáveis, o SDN vai adicionar uma camada de abstração para resolver um problema que você não tem. Nesse caso, bridge VLAN-aware com trunk bem configurado é mais simples de operar e mais fácil de depurar — e simplicidade é uma característica de arquitetura, não uma limitação.

O que o SDN cobra

Sendo específico sobre os custos, que são reais:

• Uma camada a mais no diagnóstico. O pacote agora passa por encapsulamento. Um tcpdump na interface física mostra tráfego encapsulado, não o pacote da VM. A equipe precisa saber onde capturar em cada camada.
• Dependência de um substrato correto. Overlay funciona sobre roteamento IP entre os nós. Se o substrato tem perda ou assimetria, o overlay herda o problema e mascara a origem.
• Overhead de encapsulamento. VXLAN acrescenta cerca de 50 bytes por pacote. Se o substrato está em MTU 1500 e a VM também, a fragmentação aparece como lentidão intermitente e inexplicável. Este é o problema número um de quem implanta VXLAN.
• Conhecimento de BGP, no caso do EVPN. Não é opcional: quando o plano de controle tem problema, resolver exige entender rota, vizinhança e política.
• Curva de aprendizado da equipe, que passa a precisar entender dois modelos de rede em vez de um.

MTU: o detalhe que estraga a implantação

Vale isolar este ponto, porque ele responde pela maioria das implantações de VXLAN que "funcionam mas estão lentas".

O encapsulamento consome espaço no pacote. Você tem duas saídas. A recomendada é aumentar o MTU do substrato — a rede física entre os nós — para acomodar o overhead, mantendo as VMs em 1500. Assim nada muda para o convidado. A alternativa é reduzir o MTU dentro das VNets, o que funciona mas exige que cada VM respeite o valor menor, e VM de cliente não respeita nada que você não force.

Em qualquer dos casos, valide com um teste explícito de pacote grande sem fragmentação antes de colocar carga. Um ping comum de 64 bytes atravessa qualquer MTU mal configurado e não prova nada.

Um caminho de adoção sensato

Não vá direto para EVPN. A ordem que reduz risco:

1. Comece pela zona VLAN, mapeando o que você já tem. O ganho imediato é parar de editar configuração em cada nó, sem mudar o transporte.
2. Valide a distribuição da configuração e o comportamento em manutenção: adicione e remova um nó, e confirme que a rede se propaga.
3. Se houver necessidade real de atravessar roteamento, introduza VXLAN em uma rede não crítica, com o MTU do substrato já ajustado.
4. Só vá para EVPN quando precisar de roteamento entre VNets e houver alguém na equipe confortável com BGP.
5. Documente o desenho em cada etapa, incluindo onde capturar tráfego para depurar cada camada.

Para provedor de cloud, o cálculo é diferente

Quem revende cloud tem um requisito que muda a conta: isolamento por cliente, criado sob demanda. Cada cliente novo precisa da própria rede, sem ver o tráfego dos outros, provisionada automaticamente no momento da venda — sem ninguém tocar em configuração de nó.

É exatamente o que o SDN entrega, e é o cenário em que ele deixa de ser opcional. Somado a IPAM, o fluxo de venda passa a criar a rede do cliente, alocar o endereçamento e provisionar a VM sem intervenção. Aqui a complexidade adicional se paga rápido, porque a alternativa é trabalho manual proporcional ao número de clientes — que é o oposto de escalar.

Erros comuns

• Adotar SDN em cluster pequeno para resolver um problema que não existe.
• Ir direto para EVPN sem ninguém que domine BGP.
• Implantar VXLAN sem ajustar o MTU do substrato.
• Validar com ping pequeno e concluir que a rede está boa.
• Esquecer que overlay depende de roteamento saudável entre os nós.
• Não documentar onde capturar tráfego, deixando o diagnóstico no chute.
• Migrar todas as redes de uma vez, sem piloto em rede não crítica.
• Manter configuração manual de rede em paralelo ao SDN, com fontes de verdade concorrentes.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, ajudamos a responder primeiro se o SDN resolve o seu problema — e dizemos quando não resolve, porque bridge VLAN-aware bem feita atende muitos clusters melhor do que uma camada extra. Quando faz sentido, desenhamos a topologia, ajustamos o substrato e o MTU, implantamos por etapas começando pelo menor risco e documentamos o modelo para a sua equipe operar e depurar. Na plataforma E-CLOUD, integramos a criação de rede por cliente ao fluxo de provisionamento.

Quer avaliar se o SDN faz sentido no seu cluster? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.