Questo post è il primo di una serie di tre articoli dedicati a rete, storage e compute.
Cosa cambia a livello della rete: il Virtual Private Cloud (VPC)
Dopo l’annuncio della disponibilità generale di VMware Cloud Foundation 9.0 il 17 giugno 2025 e delle evoluzioni di VCF 9.1 nel maggio 2026, arriva un nuovo elemento rivoluzionario per i team di rete e applicativi: il Virtual Private Cloud (VPC).
In passato, per collegare una nuova applicazione alla rete sotto VCF era necessario conoscere a fondo NSX (Tier-0, Tier-1, Edge VM) e coinvolgere il team di rete a ogni deploy. Il VPC cambia questa meccanica: infatti, il servizio offre un consumo di rete in modalità self-service, come un cloud pubblico. Inoltre, è direttamente accessibile ai team applicativi da vCenter e non più solo dalla console NSX.
Il VPC è un elemento aggiuntivo all’interno degli strumenti VCF, non un sostituto. Ciò significa che le VLAN tradizionali, i Tier-0/Tier-1 NSX in modalità “tradizionale”, i meccanismi di firewall standard (DFW, Gateway Firewall) sono ancora disponibili e possono coesistere con i VPC, a seconda delle esigenze.
Questa prima parte della nostra serie sulle novità di VCF 9 (che abbiamo iniziato con un TLDR) si concentra sulla rete. I prossimi articoli parleranno di storage e compute.
Cos'è un VPC?
Un Virtual Private Cloud (VPC) è un ambiente di rete multi-tenant isolato, ospitato all’interno di un cloud privato VCF più ampio.
Questo servizio consente ai team applicativi di definire e gestire la propria rete logicamente isolata: indirizzamento IP, routing, regole di sicurezza. Tutto ciò senza dover dipendere da un intervento sulla rete a ogni cambiamento. Questo concept non allontanerà gli architetti abituati al public cloud: infatti, riprende la logica dei VPC, disponibile presso tutti i grandi cloud provider, e la adatta a un cloud privato VCF.
Per saperne di più, consulta l’articolo del blog VMware dedicato a questo argomento.
Un VPC è basato su due componenti.
- Le sottoreti: reti virtuali di livello 3 (L3) del modello OSI, pubbliche o private. Una sottorete privata utilizza un blocco IP che non viene mai annunciato al di fuori del VPC. Una sottorete pubblica riceve gli indirizzi direttamente dal pool IP esterno. In OVHcloud, si tratta generalmente di blocchi di indirizzi IP.
- I gateway: ogni VPC ha il proprio gateway che inoltra i pacchetti tra le sue sottoreti. All'interno di uno stesso progetto, un Transit Gateway può collegare tutti i VPC.
Un VPC può rimanere associato a un solo dominio di gestione o estendersi su più domini tramite span, se i domini condividono la stessa istanza NSX. Nella versione 9.1, un progetto può avere più Transit Gateway, indipendentemente dal numero di VPC che raggruppa. Inoltre, ogni VPC collegato a un Transit Gateway può essere soggetto a una politica di connettività (Community, Promiscuous, Isolated) che controlla gli scambi con gli altri VPC senza necessità di installare un firewall. I limiti di dimensionamento (numero di VPC, di sottoreti) sono definiti dai valori massimi di configurazione NSX documentati da VMware.
La suddivisione dei ruoli è chiara: per questo il modello rimane self-service senza sacrificare il controllo centralizzato. Al momento del deploy di un dominio di gestione, l’amministratore di rete definisce i blocchi di indirizzi IP che alimenteranno i futuri VPC. In seguito, gli amministratori vCenter creano i VPC e le loro sottoreti in totale autonomia. Non scelgono mai gli intervalli IP delle reti pubbliche o di transito: questi vengono ricavati da blocchi predefiniti. Solo gli IP delle sottoreti completamente private, che non vengono mai pubblicati all'esterno, sono gestiti liberamente dal team applicativo.
In pratica, un team applicativo che ha bisogno di un nuovo ambiente isolato può creare il proprio VPC in pochi clic, senza dover aprire un ticket per il team di rete o aspettare una finestra di manutenzione.
Tutto è gestito dalla scheda di rete di vCenter (creazione di VPC, sottoreti, configurazione della connettività) o tramite API/PowerCLI. In questo modo, la creazione può essere integrata direttamente all’interno di pipeline di Infrastructure as Code, proprio come il deploy di una macchina virtuale. Non è necessario effettuare alcun intervento sugli switch o router fisici: NSX installa e gestisce automaticamente i componenti virtuali sottostanti.
Per chi conosce il vSphere Client, ecco come sono rappresentate le sottoreti all'interno di un VPC in VCF 9.x.
Questa logica non è del tutto nuova: VCF 5.2.1 ne aveva già dato un’anteprima in vCenter. VCF 9.0 generalizza il modello. VCF 9.1 lo arricchisce con nuove capacità di connettività, che saranno oggetto del capitolo successivo.
Funzionalità e componenti del VPC
Connettività centralizzata vs. distribuita
Un VPC può collegare i carichi di lavoro alla rete fisica in due modi. Nel caso di una connettività centralizzata, il Transit Gateway instrada il traffico verso un gateway Tier-0 istanziato su macchine virtuali Edge NSX: tutto il traffico in entrata e in uscita passa attraverso queste ultime. In una connettività distribuita, introdotta da VCF 9.0, il Transit Gateway si basa direttamente su una VLAN condivisa da tutti gli host ESX, senza macchine virtuali Edge o gateway Tier-0. VCF 9.1 risolve il principale limite storico di questa seconda modalità: l’assenza di servizi di rete avanzati. La scelta tra queste due modalità dipende dal livello di servizio di rete richiesto, più che dalla performance della rete.
VPC et Distributed Transit Gateway (DTGW)
Il modello distribuito era più semplice e performante, ma era limitato ai servizi di rete di base (NAT statico, DHCP distribuito). Con VCF 9.1, un nuovo componente software sopperisce a questa mancanza: la Virtual Network Appliance (VNA). Si tratta di un’appliance leggera, implementata da vCenter, che si collega a un ambiente VPC distribuito per fornire servizi centralizzati on demand: NAT avanzato, DHCP e soprattutto la ripartizione del carico tramite Avi Load Balancer. Risultato: un Transit Gateway distribuito può utilizzare Avi per esporre un load balancer senza dover ricorrere a una macchina virtuale Edge tradizionale o rinunciare alle maggiori prestazioni di un modello distribuito.
NB: dopo aver letto questo articolo, puoi seguire la nostra roadmap per il VMware Avi Load Balancer. Non esitare a lasciare un commento e/o a votare per darle priorità.Avi Load Balancer è il motore di ripartizione del carico L4-L7 integrato in VCF: fino alla versione VCF 9.1, era riservato ai deploy con connettività centralizzata, poiché il modello distribuito non offriva alcun mezzo di integrazione. La Virtual Network Appliance (VNA) risolve questo problema: un amministratore di rete la implementa una volta a livello di progetto o del VPC e la associa al controller Avi. I team applicativi possono quindi creare i propri Virtual Service Avi per esporre una API, un sito web o un Kubernetes Ingress, il tutto senza mai intervenire sulla configurazione di rete sottostante. Questa combinazione rende il modello distribuito praticabile nella quasi totalità dei casi d’uso applicativi, mentre in precedenza si adattava solo agli scenari più semplici.
Connessione VLAN distribuita per vSphere Supervisor
La VNA apre la connettività distribuita a nuovi casi d’uso: vSphere Supervisor e VCF Automation possono connettersi al datacenter tramite una semplice VLAN, anziché attraverso una più complessa architettura di connettività centralizzata. In questo modo, per i team che implementano Kubernetes (vSphere Supervisor) o che orchestrano ambienti applicativi (VCF Automation), i requisiti di rete da impostare in precedenza sono notevolmente ridotti. Infatti, non è più necessario configurare una topologia Edge/Tier-0 dedicata per ottenere una connettività funzionale.
Conclusione
Il Virtual Private Cloud trasforma il modo in cui i team di rete e applicativi collaborano in VCF 9. Ciò significa meno avanti e indietro, un consumo di rete in modalità self-service e, grazie alla VNA, servizi avanzati (Avi Load Balancer, connettività VLAN semplificata per Supervisor) accessibili senza sacrificare la semplicità del modello distribuito.
Per gli architetti, il vantaggio è chiaro: minor scambio di ticket con il team di rete e un’infrastruttura sotto controllo grazie alle quote definite in anticipo. Questa evoluzione si inserisce in un trend generale di VCF 9: rendere l’esperienza del cloud privato simile a quella del cloud pubblico, senza rinunciare al controllo dell’infrastruttura.
Il prossimo articolo di questa serie si concentrerà sulle novità nel settore dello storage.
Scopri l ’offerta VMware Cloud Foundation su OVHcloud e costruisci il tuo cloud privato su questa base.