NSX Virtuelle Private Clouds (VPCs) bilden eine Abstraktionsschicht, die das Einrichten eigenständiger Virtual Private Cloud-Netzwerke in einem NSX-Projekt vereinfacht und die Nutzung von Netzwerk- und Sicherheitsdiensten in einem Self-Service-Nutzungsmodell ermöglicht.
Diese Funktion wird in Projekten ab NSX 4.1.1 unterstützt.
Eine NSX VPC verhindert, dass Anwendungsbesitzer mit der Komplexität der zugrunde liegenden NSX-Infrastruktur, Netzwerktopologie, Netzwerkobjekten und IP-Adressverwaltung in Kontakt kommen. Sie bietet ihnen ein Self-Service-Nutzungsmodell für das Ausführen von Anwendungen in ihrem eigenen privaten Bereich.
Anwendungsbesitzer oder DevOps-Ingenieure müssen sich nicht mit der zugrunde liegenden NSX-Infrastruktur auskennen, um Anwendungen innerhalb ihres isolierten Bereichs auszuführen. Sie können unabhängig vom Enterprise-Administrator Subnetze (Netzwerke) in der ihnen zugewiesenen NSX VPC hinzufügen und Sicherheitsrichtlinien konfigurieren, die ihre Anwendungsanforderungen erfüllen.
NSX-VPCs sind innerhalb eines Projekts optional. Das folgende Diagramm zeigt zwei Projekte in der Organisation. Projekt 1 enthält NSX-VPCs, während Projekt 2 keine NSX-VPCs enthält.
Das folgende Diagramm zeigt eine logische Beispielansicht einer NSX VPC innerhalb von Projekt 1. Die Beiden Projekte 1 und 2 sind mit demselben Tier-0- oder Tier-0-VRF-Gateway verbunden.
- App-Subnetz (privat)
- Web-Subnetz (öffentlich)
- Testsubnetz (isoliert)
- Sicherheitsadministrator
- Netzwerkoperator
- Sicherheitsbeauftragter
Wenn eine NSX VPC erstellt wird, gibt der Projektadministrator die externen IP-Blöcke und die privaten IP-Blöcke an, die zum Erstellen der Subnetze in der VPC verwendet werden sollen. Die unterstützten Subnetzzugriffsmodi lauten "Privat", "Öffentlich" und "Isoliert". Weitere Informationen zu Subnetzzugriffsmodi finden Sie im Abschnitt Zugriffsmodi für NSX VPC-Subnetze weiter unten in dieser Dokumentation.
Wenn eine NSX VPC erfolgreich erstellt wurde, erstellt das System implizit ein Gateway. Dieses implizite Gateway wird dem Projektadministrator jedoch im schreibgeschützten Modus angezeigt und ist für die NSX VPC-Benutzer nicht sichtbar.
Der Lebenszyklus dieses impliziten Gateways wird vom System verwaltet. Beim Löschen einer NSX VPC wird das implizite Gateway automatisch gelöscht.
Im Datenmodell der NSX-Richtlinie werden NSX VPC-Objekte unter Projekten unter dem folgenden Pfad erstellt:
/orgs/default/projects/<project_id>/vpcs/<vpc-id>
Das realisierte implizite Gateway befindet sich im folgenden Pfad:
/orgs/default/projects/<project_id>/infra/tier-1s/
Beispiel für eine NSX VPC
Angenommen, Ihre Organisation hat ein Projekt mit dem Namen "Vertrieb" in ihrer NSX-Umgebung erstellt. Das Ziel des Projektadministrators ist es, eine isolierte Netzwerk- und Sicherheitsumgebung für die Anwendungsentwickler der Anwendungen "Auftragsverwaltung" und "Analyse" im Geschäftsbereich für den Vertrieb bereitzustellen.
Die Anwendungsentwickler benötigen die Möglichkeit, Netzwerke bereitzustellen und Sicherheitsrichtlinien für diese beiden Anwendungen in einem Self-Service-Nutzungsmodell unabhängig vom Enterprise-Administrator oder Projektadministrator zu konfigurieren.
Um dieses Ziel zu erreichen, kann der Projektadministrator zwei NSX-VPCs innerhalb des Vertriebsprojekts erstellen und diese NSX-VPCs den Anwendungsentwicklern zuweisen.
Beispiel:
| VPC-Name | VPC-Benutzer | IP-Adressblöcke |
|---|---|---|
| Auftragsverwaltung | Jim: VPC-Administrator Bob: Netzwerkbetreiber Carol: Sicherheitsbeauftragte |
Privater IPv4-Block: 172.16.0.0/24 Externer IPv4-Block: 192.168.1.0/24 |
| Analyse | Mike: VPC-Administrator Steve: Netzwerkbetreiber Maria: Sicherheitsbeauftragte |
Privater IPv4-Block: 172.18.0.0/24 Externer IPv4-Block: 192.168.1.0/24 |
Nachdem den NSX VPC-Benutzern Rollen zugewiesen wurden, können diese Benutzer Subnetze innerhalb der NSX VPC hinzufügen und Sicherheitsrichtlinien für diese Arbeitslasten konfigurieren. Die Sicherheitsrichtlinien wirken sich nur auf die Arbeitslasten innerhalb der NSX VPC und nicht außerhalb der NSX VPC aus.
Das folgende Diagramm zeigt beispielsweise drei Subnetze mit dem Namen "Entwicklung", "Test" und "Produktion" innerhalb der NSX VPC für die Auftragsverwaltung sowie drei Subnetze mit dem Namen "App", "Web" und "DB" in der NSX VPC für die Analyse. Arbeitslast-VMs sind an alle Subnetze angehängt. Die NSX-VPCs sind an dasselbe Tier-0- oder Tier-0-VRF-Gateway des Vertriebsprojekts angehängt.
Allgemeiner NSX VPC-Workflow
- Projektadministrator: Fügt die NSX VPC innerhalb eines Projekts hinzu und definiert grundlegende NSX VPC-Einstellungen wie IP-Zuweisung, DHCP-Konfiguration, Edge-Cluster usw.
- Projektadministrator: Weist Benutzern in der NSX VPC Rollen zu.
- Projektadministrator: Definiert Kontingente oder Grenzwerte für die Anzahl Objekte, die Benutzer innerhalb der NSX VPC erstellen können.
- VPC-Administrator oder Netzwerkadministrator: Fügt Subnetze in der NSX VPC hinzu. Verbindet Arbeitslasten basierend auf den Geschäftsanforderungen mit diesen Subnetzen.
- VPC-Administrator oder Sicherheitsadministrator: Fügt Sicherheitsrichtlinien in der NSX VPC hinzu, um die Sicherheitsanforderungen der Arbeitslasten zu erfüllen, die mit den Subnetzen in der VPC verbunden sind.
Zugriffsmodi für NSX VPC-Subnetze
- Privat
-
Auf ein privates Subnetz kann nur innerhalb der NSX VPC zugegriffen werden. Arbeitslasten, die an ein privates Subnetz angehängt sind, können mit Arbeitslasten in anderen privaten oder öffentlichen Subnetzen innerhalb derselben NSX VPC kommunizieren.
Wenn die IP-Zuweisung für das private Subnetz auf "automatisch" festgelegt ist, werden die Subnetz-IP-Blöcke (Subnetz-CIDRs) automatisch aus den privaten IPv4-Blöcken zugewiesen, die der NSX VPC zugeordnet sind. Wenn die IP-Zuweisung für das private Subnetz auf "manuell" festgelegt ist, kann der VPC-Administrator das Subnetz-CIDR manuell zuweisen.
Das CIDR eines VPC-Subnetzes darf sich nicht mit dem CIDR eines anderen VPC-Subnetzes in derselben NSX VPC überschneiden. Die Subnetz-IPs können sich jedoch mit dem Subnetz in einer NSX VPC überschneiden. Diese Konfiguration kann realisiert werden, indem verschiedene private IP-Blöcke mit denselben IP-Bereichen verschiedenen NSX-VPCs zugewiesen werden.
Mehrere NSX-VPCs in einem Projekt können denselben privaten IPv4-Block gemeinsam nutzen. In diesem Fall sind die privaten Subnetze über die verschiedenen VPCs hinweg, die denselben privaten IP-Block nutzen, eindeutig.
Wenn die Option Standard NAT ausgehend für die NSX VPC aktiviert ist, wird eine Standard-SNAT-Regel für die NSX VPC erstellt, um zuzulassen, dass Datenverkehr von den Arbeitslasten in den privaten Subnetzen außerhalb der NSX VPC weitergeleitet wird. Wenn diese Option in ähnlichen Zeilen deaktiviert ist, kann der Datenverkehr aus dem privaten Subnetz nicht außerhalb der NSX VPC weitergeleitet werden.
- Öffentlich
-
Auf ein öffentliches Subnetz kann von außerhalb der NSX VPC zugegriffen werden. Dieses Subnetz wird bis zum Tier-0-Gateway des Projekts automatisch angekündigt und verfügt standardmäßig über eine direkte externe Konnektivität. Mit anderen Worten: Die IPv4-Adressen in den öffentlichen Subnetzen sind sowohl vom Projekt aus als auch außerhalb des Projekts erreichbar.
Wenn die IP-Zuweisung für das öffentliche Subnetz auf "automatisch" festgelegt ist, werden die Subnetz-IP-Blöcke (Subnetz-CIDRs) automatisch aus den externen IPv4-Blöcken zugewiesen, die für das Projekt angegeben sind. Wenn die IP-Zuweisung für das öffentliche Subnetz auf "manuell" festgelegt ist, kann der VPC-Administrator das Subnetz-CIDR manuell zuweisen.
- Isoliert
-
Ein isoliertes Subnetz ist nicht intern mit dem realisierten impliziten Gateway verbunden. Arbeitslasten in einem isolierten Subnetz können zwar miteinander, aber nicht mit Arbeitslasten in privaten oder öffentlichen Subnetzen innerhalb derselben NSX VPC kommunizieren. Darüber hinaus können Pakete aus isolierten Subnetzen die NSX VPC nicht verlassen.
Ein VPC-Administrator muss die CIDR-Adresse eines isolierten Subnetzes manuell angeben.
