VPC-Netzwerkentwurf
Einstellung des Vertriebs: Ab dem 31. Oktober 2025 stehen Neukunden keine neuen Bereitstellungen von „ VMware Solutions “-Angeboten mehr zur Verfügung. Bestehende Kunden können ihre aktiven „ VMware® “-Workloads weiterhin auf IBM Cloud® nutzen und erweitern. Weitere Informationen finden Sie unter Ende der Vermarktung für VMware auf IBM Cloud.
Die folgenden Informationen geben einen Überblick über die IBM Cloud® Virtual Private Cloud Bereitstellung für eine VMware® Bereitstellung. Es ist wichtig, die Trennung und Integration von VMware-Infrastrukturnetzwerken mit VPC zu verstehen und zu wissen, wie die Konnektivität mit anderem Workload-Verkehr integriert und konfiguriert werden muss.
VPC-Teilnetze
In IBM Cloud VPC können Sie die logische Segmentierung oder Isolierung auf mehrere Arten vornehmen. Diese Architektur verwendet eine traditionelle VLAN-Segmentierung analog zu den VMware Cloud Foundation™-Anforderungen, aber IBM Cloud VPC verwendet Subnetze anstelle von VLANs. Jeder Systemverkehrstyp hat sein eigenes VPC-Subnetz, und der Verkehr zwischen VMkernel-Adapter-Netzwerkschnittstellen kann sowohl mit IBM Cloud VPC Sicherheitsgruppen (SGs) als auch mit Subnetz-Zugriffskontrolllisten (ACLs) kontrolliert werden. Das folgende Diagramm zeigt einen Überblick über das konsolidierte VPC-Design.
Bei dieser Architektur wird für jede VMware Cloud Foundation-Instanz eine neue VPC erstellt. Diese Maßnahme dient der Einfachheit und der Vermeidung von Problemen mit der Skalierbarkeit und den architektonischen Anforderungen und Prinzipien von VMware Cloud Foundation. Um eine Verbindung zu anderen Workloads und anderen VPCs herzustellen, können Sie IBM Cloud Interkonnektivitätslösungen wie Transit Gateway verwenden.
In der folgenden Tabelle sind die Subnetze aufgeführt, die in VPC erstellt werden. Der Entwurf des Subnetzes basiert auf der Anforderung der VMware Cloud Foundation, die Systemverkehrsarten logisch zu trennen und für jeden Benutzer ein eigenes VPC-Subnetz zu verwenden. Bare Metal Server PCI-Schnittstellen werden in einem eigenen Subnetz gehostet. Verwaltungsschnittstellen und Appliances wie VMware vCenter®, VMware NSX®-Manager, SDDC-Manager und NSX Edge™-Verwaltungsschnittstellen werden in ihrem eigenen Verwaltungssubnetz bereitgestellt.
| Name des Teilnetzes | Typ des Systemdatenverkehrs | Anleitung zur Teilnetzdimensionierung |
|---|---|---|
vpc-host-subnet |
Host-Management-Datenverkehr | Anzahl der Hosts x 2 (jede PCI-NIC benötigt eine IP-Adresse) |
vpc-mgmt-subnet |
Datenverkehr der Management-Appliance | Anzahl der VMware Cloud Foundation Management Appliances |
vpc-vmot-subnet |
vMotion-Datenverkehr | Anzahl Hosts |
vpc-vsan-subnet |
vSAN-Datenverkehr | Anzahl Hosts |
vpc-tep-subnet |
TEP-Verkehr für Hosts | Anzahl der Hosts x 2 (jeder Host benötigt 2 x TEPs) |
NSX-Edge-TEP-Datenverkehr und NSX Tier-0 logische Gateway-Schnittstellen werden in VMware Cloud Foundation-Bereitstellungen in eigenen Subnetzen bereitgestellt. Die folgenden VPC-Subnetze sind für den Edge-Cluster erforderlich.
| Name des Teilnetzes | Typ des Systemdatenverkehrs | Anleitung zur Teilnetzdimensionierung |
|---|---|---|
vpc-edge-tep-subnet |
TEP-Verkehr für Randknoten | Anzahl der Randknoten x 2 (jeder Randknoten erfordert 2 x TEPs) |
vpc-t0-public-uplink-subnet |
Öffentliches Teilnetz für T0-Uplink | /29 oder größer |
vpc-t0-private-uplink-subnet |
Privates Teilnetz für T0-Uplink | /29 oder größer |
Um Teilnetze in VPC erstellen zu können, müssen Sie ein VPC-Präfix erstellen. VPC-Präfixe werden pro Zone definiert. Um das Routing zu vereinfachen, müssen Sie die empfohlenen Subnetze aus einem einzigen Präfix zuweisen. Das bedeutet, dass Sie
für fünf Subnetze ein /21-Präfix benötigen, um Adressen für etwa 120 Hosts pro Zone bereitstellen zu können. Wenn Sie ein Präfix mit /22 verwenden möchten, können Sie ungefähr 60 Hosts pro Zone hinzufügen. Wenn Sie
ein ausreichend großes Präfix wählen, haben Sie genügend Spielraum für Skalierbarkeit und zukünftige Anforderungen, wie z. B. dedizierte VMKs für NFS, Replikation und NSX Tier-0 Uplinks.
VPC-Zugriffskontrolllisten und Sicherheitsgruppen
Bare Metal Server for VPC bietet eine umfassende Unterstützung der Funktionen für den VPC-Netzbetrieb. Netzwerksicherheitsfunktionen wie Sicherheitsgruppen und Zugriffskontrolllisten können mit Bare-Metal-Server-PCI- und VLAN-Schnittstellen verwendet werden. In diesem Design teilen sich sowohl die VMware Infrastruktur-Subnetze, die für die Übertragung von VMware Systemverkehrstypen verwendet werden, als auch die VPC-Subnetze für Workloads VMs die Routing-Domäne. Dieses Design ermöglicht die Verwendung dieser beiden integrierten Netzwerk-VPC-Sicherheitstools.
Zugriffssteuerungsliste mit VMware-Workloads
Eine Zugriffssteuerungsliste (ACL) kann verwaltet werden, indem eingehender und abgehender Datenverkehr für ein Teilnetz zugelassen oder verweigert wird. Eine ACL ist statusunabhängig, d. h. Regeln für ein- und ausgehende Daten müssen separat und explizit angegeben werden. Jede ACL besteht aus Regeln, die auf einer Quell-IP, einem Quellport, einer Ziel-IP, einem Zielport und einem Protokoll basieren. Jede VPC verfügt über eine Standard-ACL, die den gesamten ein- und ausgehenden Datenverkehr zulässt. Sie können die ACL-Standardregeln bearbeiten oder eine angepasste ACL erstellen.
Da ACLs auf ein Subnetz angewendet werden, können Sie sie als virtuelle Server verwenden, um den Verkehr zu und von den VPC-Subnetzen zu kontrollieren. Sie können auch isolierte Teilnetze erstellen, z. B. für vSAN™, vMotion und TEP-Datenverkehr.
Die Standardbereitstellung verwendet eine Standard-ACL (allow any) für die gesamte VPC, aber Sie können diese nach der ersten Bereitstellung anpassen.
Weitere Informationen zu ACLs finden Sie unter Sicherheit in VPC. Weitere Informationen zu ACLs mit IBM Cloud-Bare-Metal-Servern finden Sie unter Einführung in den Netzbetrieb von IBM Cloud-Bare-Metal-Servern.
Sicherheitsgruppen mit VMware-Workloads
Eine Sicherheitsgruppe fungiert als virtuelle Firewall, die den Datenverkehr für eine oder mehrere virtuelle Servernetzschnittstellen und IBM Cloud-Bare-Metal-Server-PCI- oder VLAN-Schnittstellen steuert. Eine Sicherheitsgruppe ist eine Sammlung von Regeln, die angeben, ob Datenverkehr für eine zugeordnete Schnittstelle zugelassen oder verweigert werden soll. Sie können eine Schnittstelle einer oder mehreren Sicherheitsgruppen zuordnen und die Regeln der Sicherheitsgruppe bearbeiten. Sie können Sicherheitsgruppen auch als Quelle oder Ziel in den Regeln verwenden, um dynamischere Regeln zu erstellen, ohne IP-Adressen anzugeben.
In diesem Entwurf werden Ihre Sicherheitsgruppen verwendet, um eine logische Gruppierung von Management-, vSAN, vMotion und TEP-Verkehrstypen zu erstellen und Regeln anzuwenden, um die erforderlichen Verkehrsflüsse zuzulassen. Die folgenden Sicherheitsgruppen werden erstellt:
| Name der Sicherheitsgruppe | Verwendung |
|---|---|
sg-mgmt |
Verwaltungsgeräte und Hosts |
sg-vmot |
VMkernel-Adapter für vMotion |
sg-vsan |
VMkernel-Adapter für vSAN |
sg-tep |
VMkernel-Adapter für TEP |
sg-uplink-pub |
VMkernel-Adapter für Tier-0 öffentliche Uplinks |
sg-uplink-priv |
VMkernel-Adapter für Tier-0 private Uplinks |
sg-bastion |
VMkernel-Adapter für Bastion-Hosts (Automatisierung VSI) |
Das Grundprinzip der Standardregeln ist es, ein praktisches Minimum zu ermöglichen. Zum Beispiel erlaubt sg-vmot den Verkehr zwischen den Mitgliedern der Sicherheitsgruppe und den von der Sicherheitsgruppe sg-mgmt eingehenden icmp. Das gleiche Prinzip gilt für alle Sicherheitsgruppen, die für VMkernel-Adapter verwendet werden. sg-mgmt erlaubt die Verbindung von privaten RFC 1918-Netzwerken. Diese Regeln können nach der erstmaligen
Bereitstellung angepasst werden; die folgenden Informationen bieten vereinfachte Anleitungen und Grundsätze.
Wenn Sicherheitsgruppen mit VLAN-Schnittstellen in VMware virtuellen Maschinen (VMs) verwendet werden, ist es zur Vermeidung von Fehlkonfigurationen und Missverständnissen wichtig zu verstehen, wie der Datenverkehr zu und von den standardmäßigen und verteilten vSwitches, fließt und wann der Datenverkehr innerhalb der Hosts innerhalb dieser vSwitches durchläuft.
In einer VMware Umgebung wird der Datenverkehr zwischen VLAN-Netzwerkschnittstellen mit derselben VLAN-ID auf demselben Bare-Metal-Server in der Regel von vSwitches innerhalb des ESXi-Hosts weitergeleitet. Wenn sich die virtuellen Maschinen oder VMkernel-Schnittstellen auf demselben Host befinden und dieselbe Portgruppe und VLAN-ID verwenden, erreicht der Datenverkehr nicht das VPC-Netzwerk.
Auf einem VMware vSphere®-Cluster, der aus mehreren Bare-Metal-Server-Hosts besteht, konfigurieren Sie zum Beispiel einen verteilten vSwitch. In diesem Fall können Sie eine Portgruppe mit der VLAN-ID 1611 erstellen und sie zu
dem spezifischen vSwitch hinzufügen. Der Datenverkehr zwischen vNICs von zwei VMs, die der Portgruppe 1611 zugeordnet sind, wird vom vSwitch gesteuert.
In diesem Beispiel hat dies die folgenden Konsequenzen in VMware Cloud Foundation-Bereitstellungen:
- Sicherheitsgruppenregeln, die den Verkehr zwischen den Netzwerkschnittstellen in der Portgruppen-VLAN-ID
1611kontrollieren, werden nicht angewendet, wenn der Verkehr den vSwitch nicht verlässt.
Wenn Sie mit Sicherheitsgruppen arbeiten, die auf NSX Tier 0-Gateway-Uplinks und NSX-Overlay-Datenverkehr angewendet werden, müssen Sie außerdem Regeln definieren, die beispielsweise auf IP-Adressen basieren:
- Wenn Sie auf eine VM auf einem NSX-Overlay mit der IP-Adresse
192.168.45.10von einer VMware VM (oder einem VSI) im VPC-Subnetz aus zugreifen und den Datenverkehr zu dieser IP-Adresse zulassen möchten, muss Ihre Regel für die Quellsicherheitsgruppe mit dem ausgehenden Datenverkehr übereinstimmen, und die Sicherheitsgruppe, die den Uplinks des Gateways der Stufe 0 zugewiesen ist, muss mit dem eingehenden Datenverkehr übereinstimmen. In diesem Fall muss eine IP-Adresse oder ein CIDR verwendet werden, um dem Overlay-Verkehr zu entsprechen. - Wenn eine VM auf einem NSX-Overlay mit einer IP-Adresse von
192.168.45.10mit einem vCenter oder SDDC-Manager kommunizieren muss, muss die Sicherheitsgruppenregel für Tier-0-Gateway-Uplinks mit dem ausgehenden Datenverkehr übereinstimmen, und die Sicherheitsgruppe, die der VLAN-Schnittstelle des vCenter oder SDDC-Managers zugewiesen ist, muss mit dieser bei der eingehenden Kommunikation übereinstimmen. In diesem Fall muss eine IP-Adresse oder ein CIDR verwendet werden, um dem Overlay-Verkehr zu entsprechen.
Weitere Informationen zu Sicherheitsgruppen finden Sie unter Sicherheit in Ihrer VPC. Weitere Informationen zu Sicherheitsgruppen mit IBM Cloud-Bare-Metal-Servern finden Sie unter Einführung in den Netzbetrieb von IBM Cloud-Bare-Metal-Servern.
Öffentliche Konnektivität mit VMware-VMs im VPC-Teilnetz
Bare Metal Server for VPC bietet vollständige Unterstützung für öffentliche VPC-Netzfunktionen. Externe Konnektivität kann entweder über eine Public Gateway erreicht werden, die mit einem VPC-Subnetz verbunden ist, oder über eine freie IP-Adresse, die mit einer PCI- oder VLAN-Schnittstelle eines Bare-Metal-Servers verbunden ist. Das öffentliche Gateway verwendet Source Network Address Translation (SNAT) und eine Floating IP verwendet Destination Network Address Translation (DNAT). Diese Funktionen sind mit denen der virtuellen VPC-Server identisch.
VLAN-Schnittstellen, die einem VPC-Teilnetz mit einem öffentlichen Gateway zugeordnet sind, können Verbindungen zum Internet einleiten, aber sie können keine Verbindungen vom Internet empfangen. Das öffentliche Gateway stellt Konnektivität für ein ganzes Teilnetz bereit und öffentlicher Datenverkehr, der von den VMs in diesem Teilnetz stammt, betrachtet die IP-Adresse des öffentlichen Gateways als Quelle. Wenn das Teilnetz keinem öffentlichen Gateway zugeordnet ist, ist der Datenverkehr vollständig privat. Als Beispiele in diesem Design dienen vSAN-, vMotion- oder TEP-Teilnetze.
Eine VLAN-Schnittstelle mit einer variablen IP-Adresse kann Verbindungen zum oder vom Internet einleiten oder empfangen. Variable IP-Adressen stellen Konnektivität für eine einzelne Instanz bereit. Diese Aktion setzt die Public Gateway dieser spezifischen VLAN-Schnittstelle im VPC-Subnetz außer Kraft, wenn diese für ein Subnetz mit angehängtem Public Gateway bereitgestellt wurde.
In VMware Cloud Foundation-Bereitstellungen müssen Sie ein Management-Subnetz zu einem Public Gateway hinzufügen, das es beispielsweise dem SDDC-Manager ermöglicht, Updates direkt von VMware Public Software Repositories zu erhalten.
Weitere Informationen zu Overlay und öffentlicher NSX-Konnektivität finden Sie unter VMware NSX logische Router auf VPC-Bereitstellungen und VMware NSX logisches Routing auf VPC.