Este artigo é a primeira parte de uma série de três artigos que abordam os seguintes temas: rede, armazenamento e compute.
O que muda quanto à rede: o Virtual Private Cloud (VPC)
Após o anúncio da disponibilidade geral do VMware Cloud Foundation 9.0, a 17 de junho de 2025, e das novidades introduzidas pelo VCF 9.1, em maio de 2026, surge um elemento que marca uma viragem para as equipas de redes e de aplicações: o Virtual Private Cloud (VPC).
Até agora, ligar uma nova aplicação à rede no VCF exigia conhecer profundamente o NSX (Tier-0, Tier-1, Edge VM) e mobilizar a equipa de rede a cada implementação. O VPC veio alterar esta mecânica ao proporcionar um consumo de rede em self-service, à semelhança de uma cloud pública. Além disso, é diretamente acessível às equipas de aplicações a partir do vCenter e já não apenas a partir da consola NSX.
O VPC constitui uma ferramenta adicional na caixa de ferramentas de rede do VCF e não uma substituição. Isto significa que as VLAN clássicas, os Tier-0/Tier-1 NSX em modo «tradicional», bem como os mecanismos de firewall habituais (DFW, Gateway Firewall), permanecem totalmente disponíveis e podem coexistir com os VPC conforme as necessidades.
Esta primeira parte da nossa série sobre as novidades do VCF 9 (que tínhamos introduzido com um TLDR, aqui) foca-se na rede. Os próximos artigos vão tratar do armazenamento e, depois, do compute.
O que é um VPC?
Um Virtual Private Cloud (VPC) é um ambiente de rede isolado e multi-inquilino, alojado numa cloud privada VCF mais vasta.
Permite que uma equipa de aplicações defina e administre a sua própria rede logicamente isolada: endereçamento IP, encaminhamento, regras de segurança. Tudo isto sem depender de uma intervenção de rede a cada alteração. Este conceito não deixará perdidos os arquitetos que já utilizem a cloud pública. De facto, retoma a lógica de um VPC existente em todos os grandes fornecedores cloud, transposta para uma cloud privada VCF.
Para saber mais, consulte este artigo do blogue da VMware sobre o assunto.
Um VPC é estruturado por dois blocos.
- As sub-redes: redes virtuais de camada 3 (L3) do modelo OSI, públicas ou privadas. Uma sub-rede privada utiliza um bloco IP que nunca é anunciado fora do VPC. Já uma sub-rede pública recebe os seus endereços diretamente no pool IP externo. Na OVHcloud, trata-se geralmente de blocos de endereços IP.
- Os gateways: cada VPC possui um gateway próprio que encaminha os pacotes entre as suas sub-redes. No âmbito de um mesmo projeto, uma Transit Gateway pode ligar entre si todos os VPC.
Um VPC pode permanecer ligado a um único domínio de gestão, ou estender-se por vários através do span, se estes partilharem a mesma instância NSX. Na versão 9.1, um projeto pode incluir várias Transit Gateways, independentemente do número de VPC que agrupar. Cada VPC ligado a uma Transit Gateway pode também ter a aplicação de uma política de conectividade (Community, Promiscuous, Isolated) que controle a sua comunicação com os outros VPC, sem recorrer à implementação de uma firewall. Quanto aos limites de dimensionamento (número de VPC, de sub-redes), são definidos pelos valores máximos de configuração NSX documentados pela VMware.
A repartição de funções permanece clara. É ela que torna o modelo verdadeiramente self-service, sem sacrificar o controlo centralizado. Durante a implementação de um domínio de gestão, o administrador de rede define os blocos de endereços IP que alimentarão os futuros VPC. Os administradores vCenter criam, de seguida, os VPC e as suas sub-redes com total autonomia. Nunca escolhem os intervalos IP das redes públicas ou de trânsito: estes são retirados dos blocos predefinidos. Apenas os IP das sub-redes puramente privadas, que nunca são anunciados para o exterior, são geridos livremente pela equipa de aplicações.
Na prática, uma equipa de aplicações que necessite de um novo ambiente isolado pode criar o seu próprio VPC em alguns cliques, sem abrir um ticket junto da equipa de rede e sem aguardar por uma janela de manutenção.
Assim, tudo é gerido a partir do separador «Rede» do vCenter (criação de VPC, de sub-rede, configuração da conectividade) ou através da API/PowerCLI. Por isso, é possível integrar a sua criação diretamente em pipelines de Infrastructure-as-Code, da mesma forma que a implementação de uma máquina virtual. Não é necessária nenhuma intervenção nos switches ou nos routers físicos: o NSX instala e gere automaticamente os componentes virtuais subjacentes.
Para quem está familiarizado com o vSphere Client, eis como se representam as sub-redes no âmbito de um VPC, no VCF 9.x.
Esta lógica não é totalmente nova: o VCF 5.2.1 já tinha introduzido um primeiro vislumbre no vCenter. O VCF 9.0 generalizou o modelo. O VCF 9.1 vem enriquecê-lo com novas capacidades de conectividade, o que será objeto do capítulo seguinte.
Funcionalidades e componentes do VPC
Conectividade centralizada vs. conectividade distribuída
Um VPC pode ligar as suas cargas de trabalho à rede física de duas formas. Na conectividade centralizada, a Transit Gateway encaminha o tráfego para um gateway Tier-0 instanciado em máquinas virtuais Edge NSX: todo o tráfego de entrada e de saída transita por estas últimas. Na conectividade distribuída, introduzida com o VCF 9.0, a Transit Gateway baseia-se diretamente numa VLAN partilhada por todos os hosts ESX, sem qualquer máquina virtual Edge ou gateway Tier-0. O VCF 9.1 vem colmatar a principal limitação histórica deste segundo modo: a ausência de serviços de rede avançados. A escolha entre estes dois modos depende mais do nível de serviço de rede necessário do que apenas do desempenho da rede.
VPC e Distributed Transit Gateway (DTGW)
O modelo distribuído ganhava em termos de simplicidade e desempenho, mas permanecia limitado aos serviços de rede básicos (NAT estático, DHCP distribuído). Com o VCF 9.1, um novo componente de software vem colmatar esta lacuna: a Virtual Network Appliance (VNA). Trata-se de uma appliance ligeira, implementada a partir do vCenter, que se liga a um ambiente VPC distribuído para lhe fornecer serviços centralizados a pedido: NAT avançado, DHCP e, sobretudo, a distribuição de carga através do Avi Load Balancer. Resultado: uma Transit Gateway distribuída pode agora apoiar-se no Avi para expor um distribuidor de carga, sem reintroduzir uma máquina virtual Edge clássica e sem renunciar aos ganhos de desempenho do modelo distribuído.
Nota: após a leitura deste artigo, pode acompanhar o nosso roteiro para o VMware Avi Load Balancer. Não hesite em dar a sua opinião em comentário e/ou a votar na sua priorização.O Avi Load Balancer é o motor de distribuição de carga L4-L7 integrado no VCF: até à versão VCF 9.1, estava reservado a implementações em conectividade centralizada, pois o modelo distribuído não oferecia qualquer meio de integração. A Virtual Network Appliance (VNA) vem colmatar esta lacuna: um administrador de rede implementa-a uma vez ao nível do projeto ou do VPC e, de seguida, associa-a ao controlador Avi. As equipas de aplicações podem, então, criar os seus próprios Virtual Services Avi, para expor uma API, um site ou um ingress Kubernetes. E isto sem nunca tocar na configuração de rede subjacente. Esta combinação torna o modelo distribuído viável para a quase totalidade dos casos de uso de aplicações, quando anteriormente só cobria os cenários mais simples.
Ligação VLAN distribuída para o vSphere Supervisor
A VNA abre também a conectividade distribuída a novos casos de uso: o vSphere Supervisor e o VCF Automation podem agora ligar-se ao datacenter através de uma simples VLAN, em vez de uma arquitetura de conectividade centralizada, mais pesada. Para equipas que implementem Kubernetes (vSphere Supervisor) ou que orquestrem ambientes de aplicações (VCF Automation), isto reduz significativamente os pré-requisitos de rede a implementar a montante. Agora, já não é necessário preparar uma topologia Edge/Tier-0 dedicada para obter uma conectividade funcional.
Conclusão
O Virtual Private Cloud revolucionou a forma como as equipas de rede e de aplicações colaboram no VCF 9. Isto significa menos idas e vindas, consumo de rede em self-service e, graças à VNA, serviços avançados (Avi Load Balancer, conectividade VLAN simplificada para Supervisor) acessíveis, sem sacrificar a simplicidade do modelo distribuído.
Para os arquitetos, a mensagem é simples: menos tickets trocados com a equipa de rede e uma infraestrutura que permanece sob controlo graças aos limites definidos a montante. Esta evolução insere-se numa tendência mais vasta do VCF 9: aproximar a experiência da cloud privada da experiência da cloud pública, sem abdicar do controlo da infraestrutura.
A próxima parte desta série debruçar-se-á sobre as novidades quanto ao armazenamento.
Descubra a oferta VMware Cloud Foundation na OVHcloud para construir a sua cloud privada com base nesta tecnologia.