Nieuw voor VMware Cloud Foundation: netwerken en Virtual Private Cloud (VCF 9.1)

Dit artikel is het eerste deel van een serie van drie artikelen die de volgende onderwerpen behandelen: netwerken, opslag en compute.

Wat er verandert qua netwerk: de Virtual Private Cloud (VPC)

Na de aankondiging van de algemene beschikbaarheid van VMware Cloud Foundation 9.0 op 17 juni 2025 en de veranderingen die in mei 2026 doorgevoerd zijn met VCF 9.1, verandert één bouwsteen heel veel voor netwerk- en applicatieteams: de Virtual Private Cloud (VPC).

Tot nu toe vereiste het verbinden van een nieuwe applicatie met het netwerk onder VCF diepgaande kennis van NSX (Tier-0, Tier-1, Edge VM) en het netwerkteam moest bij elke implementatie ingeschakeld worden. VPC verandert dit mechanisme. Het biedt namelijk self-service netwerkconsumptie, net als bij een publieke cloud. Bovendien is dit rechtstreeks toegankelijk voor applicatieteams vanuit vCenter en niet alleen maar vanuit de NSX-console.

VPC is een extra tool in de netwerktoolbox van VCF en geen vervanging. Dit betekent dat klassieke VLAN's, NSX Tier-0/Tier-1 in "traditionele" modus, evenals de gebruikelijke firewallmechanismen (DFW, Gateway Firewall) volledig beschikbaar blijven en, indien gewenst, naast VPC's kunnen bestaan.

Dit eerste deel van onze serie over alle nieuwe zaken in VCF 9 (die we begonnen met deze TLDR) richt zich op het netwerk. De volgende artikelen zullen opslag en vervolgens compute behandelen.

Wat is een VPC?

Een Virtual Private Cloud (VPC) is een afgeschermde, multi-tenant netwerkomgeving, gehost binnen een grotere VCF private cloud.

Hiermee kan een applicatieteam zijn eigen logisch afgeschermde netwerk definiëren en beheren: IP-adressen, routering, beveiligingsregels. Dit kan allemaal gebeuren zonder bij elke wijziging iets aan het netwerk te hoeven veranderen. Dit concept zal architecten die al met een Public Cloud werken niet vreemd zijn. Het heeft namelijk dezelfde logica als bij een bestaande VPC bij alle grote cloudproviders, vertaald naar een VCF private cloud.

Lees dit blogartikel bij VMware over dit onderwerp voor meer informatie.

Twee bouwstenen bepalen de structuur van een VPC.

• Subnetten: virtuele netwerken van laag 3 (L3) van het OSI-model, publiek of privé. Een privé subnet gebruikt een IP-blok dat nooit buiten de VPC zichtbaar is. Een publiek subnet ontvangt zijn adressen daarentegen direct uit de externe IP-pool. Bij OVHcloud gaat het meestal om IP-adresblokken.
• Gateways: elke VPC heeft zijn eigen gateway die de pakketten tussen zijn subnetten routeert. Binnen hetzelfde project kan een Transit Gateway alle VPC's met elkaar verbinden.

Een VPC kan verbonden blijven met één beheerd domein, of zich uitstrekken over meerdere door middel van span, als deze dezelfde NSX-instance delen. In versie 9.1 kan een project meerdere Transit Gateways bevatten, ongeacht het aantal VPC's die ertoe behoren. Elke VPC die verbonden is met een Transit Gateway kan ook een connectiviteitsbeleid (Community, Promiscuous, Isolated) toegewezen krijgen dat het verkeer met andere VPC's regelt, zonder dat er een firewall hoeft te worden gemaakt. De schaalbeperkingen (aantal VPC's, subnetten) blijven gedefinieerd door de maximale NSX-configuratiewaarden zoals gedocumenteerd door VMware.

De rolverdeling blijft duidelijk. Dit is wat het model echt self-service maakt zonder de centrale controle op te offeren. Bij het implementeren van een beheerd domein definieert de netwerkbeheerder de IP-adresblokken die voor de toekomstige VPC's zullen gelden. vCenter-beheerders creëren vervolgens volledig autonoom de VPC's en hun subnetten. Ze kiezen nooit de IP-reeksen van de publieke of transit-netwerken: deze worden uit de vooraf gedefinieerde blokken gehaald. Alleen de IP-adressen van zuiver privé subnetten, die nooit buiten zichtbaar zijn, worden vrijelijk beheerd door het applicatieteam.

In de praktijk kan een applicatieteam dat een nieuwe afgeschermde omgeving nodig heeft, met een paar klikken zijn eigen VPC aanmaken, zonder een ticket te openen bij het netwerkteam of te wachten op een onderhoudsvenster.

Zo wordt alles aangestuurd vanuit het netwerktabblad van vCenter (aanmaken van een VPC, subnet, connectiviteit configureren) of via de API/PowerCLI. Het is dus mogelijk om de creatie ervan direct te integreren in Infrastructure as Code-pipelines, net zoals bij een implementatie van een virtuele machine. Er is geen interventie op fysieke switches of routers nodig: NSX installeert en beheert automatisch de onderliggende virtuele componenten.

Voor wie bekend is met vSphere Client, staat hieronder hoe subnetten binnen een VPC worden weergegeven onder VCF 9.x.

Deze logica is niet volledig nieuw: VCF 5.2.1 had al een eerste voorproefje geïntroduceerd in vCenter. VCF 9.0 omarmt het model. VCF 9.1 breidt dit uit met nieuwe connectiviteitsmogelijkheden, wat het onderwerp zal zijn van het volgende hoofdstuk.

Features en componenten van een VPC

Centrale versus gedistribueerde connectiviteit

Een VPC kan zijn workloads op twee manieren verbinden met het fysieke netwerk. Bij centrale connectiviteit routeert de Transit Gateway het verkeer naar een Tier-0-gateway die geïnstantieerd is op NSX Edge-virtuele machines: al het inkomende en uitgaande verkeer verloopt via deze machines. Bij gedistribueerde connectiviteit, geïntroduceerd bij VCF 9.0, berust de Transit Gateway direct op een VLAN dat door alle ESX-hosts wordt gedeeld, zonder wat voor Edge-virtuele machine of Tier-0-gateway dan ook. VCF 9.1 lost de belangrijkste bestaande beperking van deze tweede modus op: het gemis aan geavanceerde netwerkdiensten. De keuze tussen deze twee modi hangt meer af van het vereiste niveau van netwerkdiensten dan van zuiver de netwerkprestaties.

VPC en Distributed Transit Gateway (DTGW)

Het gedistribueerde model won aan eenvoud en prestaties, maar bleef beperkt tot basale netwerkdiensten (statische NAT, gedistribueerde DHCP). Bij VCF 9.1 verhelpt een nieuwe softwarebouwsteen dit tekort: de Virtual Network Appliance (VNA). Dit is een lichtgewicht appliance, geïmplementeerd vanuit vCenter, die wordt gekoppeld aan een gedistribueerde VPC-omgeving om daar on demand gecentraliseerde diensten aan toe te voegen: Geavanceerde NAT, DHCP en vooral load balancing via Avi Load Balancer. Resultaat: een gedistribueerde Transit Gateway kan nu Avi gebruiken om een load balancer aan te bieden, zonder opnieuw een klassieke Edge-virtuele machine te introduceren of de betere prestaties van het gedistribueerde model op te offeren.

De Avi Load Balancer is de L4-L7 load balancing-engine die in VCF is geïntegreerd: tot versie VCF 9.1 bleef deze beperkt tot implementaties met centrale connectiviteit, omdat het niet in het gedistribueerde model geïntegreerd kon worden. De Virtual Network Appliance (VNA) verhelpt deze lacune: een netwerkbeheerder implementeert het eenmalig op project- of VPC-niveau en koppelt het vervolgens aan de Avi-controller. Applicatieteams kunnen vervolgens hun eigen Avi Virtual Services maken om een API, een website of een Kubernetes-ingress aan te bieden. Dit allemaal zonder ooit de onderliggende netwerkconfiguratie aan te passen. Deze combinatie maakt het gedistribueerde model levensvatbaar voor vrijwel alle use cases van applicaties, waar het voorheen alleen de eenvoudigste scenario's dekte.

Gedistribueerde VLAN-verbinding voor vSphere Supervisor

VNA maakt ook gedistribueerde connectiviteit voor nieuwe use cases mogelijk: vSphere Supervisor en VCF Automation kunnen nu via een eenvoudig VLAN verbinding maken met het datacenter, in plaats van via een zwaardere, centrale connectiviteitsarchitectuur. Voor teams die Kubernetes implementeren (vSphere Supervisor) of applicatieomgevingen orkestreren (VCF Automation), vermindert dit aanzienlijk wat er vooraf in het netwerk ingesteld moeten worden. Het is namelijk niet langer nodig om een speciale Edge/Tier-0-topologie voor te bereiden om functionele connectiviteit te verkrijgen.

Conclusie

Virtual Private Cloud verandert de manier waarop netwerk- en applicatieteams samenwerken binnen VCF 9. Dit betekent minder communicatie over en weer, self-service netwerkverbruik en nu, dankzij VNA, geavanceerde diensten (Avi Load Balancer, vereenvoudigde VLAN-connectiviteit voor Supervisor) die toegankelijk zijn zonder de eenvoud van het gedistribueerde model op te offeren.

Voor architecten is de boodschap simpel: minder tickets uitgewisseld met het netwerkteam en een infrastructuur die onder controle blijft dankzij vooraf gedefinieerde quota. Deze evolutie past in een bredere trend van VCF 9: de werkwijze van de privé cloud dichter bij die van de public cloud brengen, zonder de controle over de infrastructuur op te offeren.

Het volgende deel van deze serie zal ingaan op wat er nieuw is bij opslag.

Ontdek VMware Cloud Foundation bij OVHcloud om uw Private Cloud op dezelfde basis te bouwen.