Dieser Artikel ist der erste Teil einer dreiteiligen Serie, die folgende Themen behandelt: Netzwerk, Speicher und Compute.
Was sich beim Netzwerk ändert: die Virtual Private Cloud (VPC)
Nach der Ankündigung der allgemeinen Verfügbarkeit von VCF 9.0 am 17. Juni 2025 und den durch VCF 9.1 im Mai 2026 eingeführten Entwicklungen verändert ein Baustein die Situation für Netzwerk- und Anwendungsteams grundlegend: die Virtual Private Cloud (VPC).
Bisher waren bei der Anbindung einer neuen Anwendung an das Netzwerk unter VCF fundierte NSX-Kenntnisse (Tier-0, Tier-1, Edge VM) und das Eingreifen des Netzwerkteams bei jeder Bereitstellung erforderlich. Die VPC verändert diese Vorgehensweise. Sie ermöglicht nämlich einen Netzwerkkonsum im Self-Service, ähnlich wie bei einer Public Cloud. Darüber hinaus ist sie für Anwendungsteams direkt über vCenter zugänglich und nicht mehr nur über die NSX-Konsole.
Die VPC stellt ein zusätzliches Werkzeug in der Netzwerk-Toolbox von VCF dar und keinen Ersatz. Das bedeutet, dass klassische VLANs, NSX Tier-0/Tier-1 im „traditionellen“ Modus sowie die üblichen Firewall-Mechanismen (DFW, Gateway Firewall) weiterhin voll verfügbar sind und je nach Bedarf zusammen mit VPCs bestehen können.
Dieser erste Teil unserer Serie über die Neuerungen von VCF 9 (die wir mit einem TLDR hier begonnen hatten) konzentriert sich auf das Netzwerk. Die nächsten Artikel befassen sich mit Storage und dann Compute.
Was ist eine VPC?
Eine Virtual Private Cloud (VPC) ist eine isolierte, mandantenfähige Netzwerkumgebung, die innerhalb einer größeren VCF Private Cloud gehostet wird.
Sie ermöglicht es einem Anwendungsteam, sein eigenes logisch isoliertes Netzwerk zu definieren und zu verwalten: IP-Adressierung, Routing, Sicherheitsregeln. Und zwar ohne bei jeder Änderung von einem Netzwerkeingriff abhängig zu sein. Dieses Konzept bringt Architekten, die bereits mit der Public Cloud arbeiten, nicht durcheinander. Es übernimmt nämlich die Logik einer VPC, wie sie bei allen großen Cloud-Anbietern existiert, die auf eine VCF Private Cloud übertragen wurde.
Mehr erfahren Sie in diesem VMware-Blogartikel zu diesem Thema.
Zwei Bausteine strukturieren eine VPC.
- Subnetze: virtuelle Netzwerke der Schicht 3 (L3) des OSI-Modells, öffentlich oder privat. Ein privates Subnetz verwendet einen IP-Block, der niemals außerhalb der VPC angekündigt wird. Ein öffentliches Subnetz hingegen erhält seine Adressen direkt aus dem externen IP-Pool. Bei OVHcloud handelt es sich in der Regel um IP-Adressblöcke.
- Gateways: Jede VPC besitzt ihr eigenes Gateway, das die Pakete zwischen ihren Subnetzen routet. Innerhalb desselben Projekts können alle VPCs über ein Transit Gateway miteinander verbunden werden.
Eine VPC kann an eine einzige Verwaltungs-Domain gebunden bleiben oder sich über den Span auf mehrere erstrecken, sofern diese dieselbe NSX-Instanz gemeinsam haben. In der Version 9.1 kann ein Projekt unabhängig von der Anzahl der darin enthaltenen VPCs mehrere Transit Gateways umfassen. Jede VPC, die mit einem Transit Gateway verbunden ist, kann auch eine Konnektivitätsrichtlinie (Community, Promiscuous, Isolated) erhalten, die den Datenaustausch mit anderen VPCs steuert, ohne dass ein Firewall eingerichtet werden muss. Die Skalierungsgrenzen (Anzahl der VPCs, Subnetze) sind weiterhin durch die von VMware dokumentierten maximalen NSX-Konfigurationswerte definiert.
Die Rollenverteilung bleibt klar. Sie macht das Modell zu einem echten Self-Service-Modell ohne Abstriche bei der zentralen Kontrolle. Bei der Bereitstellung einer Verwaltungs-Domain definiert der Netzwerkadministrator die IP-Adressblöcke, die dann die zukünftigen VPCs speisen. Die vCenter-Administratoren erstellen anschließend die VPCs und deren Subnetze völlig autonom. Sie wählen niemals die IP-Bereiche der öffentlichen oder Transit-Netzwerke aus: Diese werden aus den vordefinierten Blöcken entnommen. Nur die IPs der rein privaten Subnetze, die niemals nach außen angekündigt werden, werden vom Anwendungsteam frei verwaltet.
In der Praxis kann ein Anwendungsteam, das eine neue isolierte Umgebung benötigt, mit wenigen Klicks seine eigene VPC erstellen, ohne ein Ticket beim Netzwerkteam zu eröffnen oder auf ein Wartungsfenster zu warten.
Somit wird alles über den Netzwerk-Tab von vCenter gesteuert (Erstellung von VPCs, Subnetzen, Konfiguration der Konnektivität) oder über die API/PowerCLI. So ist es möglich, die Erstellung direkt in Infrastructure-as-Code-Pipelines zu integrieren, genau wie bei der Bereitstellung einer virtuellen Maschine. Es ist kein Eingriff an physischen Switches oder Routern erforderlich: NSX installiert und verwaltet die zugrunde liegenden virtuellen Komponenten automatisch.
Diejenigen unter Ihnen, die mit dem vSphere Client vertraut sind, können hier sehen, wie Subnetze innerhalb eines VPC unter VCF 9.x dargestellt werden.
Diese Logik ist nicht völlig neu: VCF 5.2.1 hatte bereits in vCenter einen ersten Einblick vermittelt. VCF 9.0 verallgemeinert das Modell. VCF 9.1 erweitert es um neue Konnektivitätsfunktionen, die Gegenstand des nächsten Kapitels sein werden.
Funktionen und Komponenten der VPC
Zentralisierte versus verteilte Konnektivität
Eine VPC kann ihre Workloads auf zwei Arten mit dem physischen Netzwerk verbinden. Bei zentralisierter Konnektivität leitet das Transit Gateway den Datenverkehr an ein Tier-0 Gateway weiter, das auf virtuelle NSX Edge-Maschinen instanziiert ist: Der gesamte ein- und ausgehende Datenverkehr läuft über diese Maschinen. Bei verteilter Konnektivität, die mit VCF 9.0 eingeführt wurde, basiert das Transit Gateway direkt auf einem VLAN, das von allen ESX-Hosts gemeinsam genutzt wird, ohne Edge-VM oder Tier-0 Gateway. VCF 9.1 beseitigt die wichtigste historische Einschränkung dieses zweiten Modus: das Fehlen fortschrittlicher Netzwerkdienste. Die Wahl zwischen diesen beiden Modi hängt eher vom erforderlichen Netzwerk-Service-Level ab als nur von der Netzwerk-Performance.
VPC und Distributed Transit Gateway (DTGW)
Das verteilte Modell ist einfacher und leistungsstärker geworden, blieb jedoch auf grundlegende Netzwerkdienste (statisches NAT, verteiltes DHCP) beschränkt. Mit VCF 9.1 schließt ein neuer Software-Baustein diese Lücke: die Virtual Network Appliance (VNA). Es handelt sich um eine leichtgewichtige Appliance, die von vCenter aus bereitgestellt und an eine verteilte VPC-Umgebung angebunden wird, um dort bei Bedarf zentralisierte Dienste zu bieten: Erweitertes NAT, DHCP und vor allem Lastverteilung über Avi Loadbalancer. Das Ergebnis: Eine verteilte Transit Gateway kann sich nun auf Avi stützen, um einen Loadbalancer bereitzustellen, ohne eine klassische Edge-VM wieder einzuführen oder auf die Performance-Vorteile des verteilten Modells zu verzichten.
Hinweis: Nach der Lektüre dieses Blogbeitrags können Sie unserer Roadmap für den VMware Avi Loadbalancer folgen. Sie können gerne Ihre Meinung in den Kommentaren hinterlassen und/oder über ihre Priorisierung abstimmen.Der Avi Loadbalancer ist die in VCF integrierte L4-L7-Lastverteilung: Bis zur Version VCF 9.1 blieb er auf Bereitstellungen mit zentralisierter Konnektivität beschränkt, da das verteilte Modell keine Integrationsmöglichkeit bot. Die Virtual Network Appliance (VNA) schließt diese Lücke: Ein Netzwerkadministrator stellt sie einmal auf Projekt- oder VPC-Ebene bereit und verknüpft sie dann mit dem Avi-Controller. Die Anwendungsteams können dann ihre eigenen Avi Virtual Services einrichten, um eine API, eine Website oder einen Kubernetes-Ingress bereitzustellen. Und das, ohne jemals an der zugrunde liegenden Netzwerkkonfiguration zu rühren. Diese Kombination macht das verteilte Modell für nahezu alle Use Case-Szenarien tragfähig, während es zuvor nur die einfachsten Szenarien abdeckte.
Verteilte VLAN-Verbindung für vSphere Supervisor
Die VNA eröffnet die verteilte Konnektivität auch für neue Use Case-Szenarien: vSphere Supervisor und VCF Automation können nun über ein einfaches VLAN an das Rechenzentrum angebunden werden, anstatt über eine schwerfälligere, zentralisierte Konnektivitätsarchitektur. Für Teams, die Kubernetes (vSphere Supervisor) bereitstellen oder Anwendungsumgebungen (VCF Automation) organisieren, reduziert dies die im Vorfeld einzurichtenden Netzwerkanforderungen erheblich. Es nämlich nicht mehr erforderlich, eine dedizierte Edge/Tier-0-Topologie vorzubereiten, um eine funktionale Konnektivität zu erhalten.
Fazit
Die Virtual Private Cloud verändert die Art und Weise, wie Netzwerk- und Anwendungsteams unter VCF 9 zusammenarbeiten. Dies bedeutet weniger Hin- und Her, einen Self-Service-Netzwerkkonsum und nun, dank der VNA, erweiterte Dienste (Avi Loadbalancer, vereinfachte VLAN-Konnektivität für Supervisor), die ohne Abstriche bei der Einfachheit des verteilten Modells zugänglich sind.
Für Architekten ist die Botschaft einfach: weniger Tickets, die mit dem Netzwerkteam ausgetauscht werden müssen, und eine Infrastruktur, die dank der im Vorfeld definierten Quoten unter Kontrolle bleibt. Diese Entwicklung ist Teil eines breiteren Trends von VCF 9: das Private Cloud Erlebnis an dasjenige der Public Cloud anzunähern, ohne auf die Kontrolle der Infrastruktur zu verzichten.
Der nächste Teil dieser Serie wird sich mit den Neuerungen im Bereich Speicher befassen.
Entdecken Sie das Angebot VMware Cloud Foundation, um Ihre Private Cloud auf genau dieser Basis aufzubauen.