VPC-Spokes
Network Connectivity Center bietet Inter-VPC-Netzwerkkonnektivität im großen Maßstab mit Unterstützung für VPC-Spokes. VPC-Spokes reduzieren die operative Komplexität der Verwaltung der einzelnen paarweisen VPC-Netzwerk-Peering-Verbindungen durch die Verwendung von VPC-Spokes und eines zentralisierten Verbindungsmodells. VPC-Spokes können alle Subnetzrouten aus anderen Spoke-VPCs in einem Network Connectivity Center-Hub exportieren und importieren. Dies gewährleistet eine vollständige Verbindung zwischen allen Arbeitslasten, die sich in diesen VPC-Netzwerken befinden. Der Inter-VPC-Netzwerktraffic verbleibt im Google Cloud -Netzwerk und wird nicht über das Internet geleitet, wodurch Datenschutz und Sicherheit gewährleistet sind.
VPC-Spokes können sich im selben Projekt und in derselben Organisation oder in einem anderen Projekt und einer anderen Organisation als der NCC-Hub befinden. Ein VPC-Spoke kann jeweils nur mit einem Hub verbunden sein.
Informationen zum Erstellen eines VPC-Spoke finden Sie unter VPC-Spoke erstellen.
Vergleich mit VPC-Netzwerk-Peering
VPC-Spokes unterstützen die Anforderungen mittlerer bis großer Unternehmen, indem sie IPv4- und IPv6-Subnetzroutenverbindungen und dynamische IPv4-Routenverbindungen über Hybrid-Spokes bereitstellen.
Ein VPC-Netzwerk kann gleichzeitig ein NCC-VPC-Spoke sein und über VPC-Netzwerk-Peering mit einem anderen VPC-Netzwerk verbunden sein, sofern das per Peering verbundene VPC-Netzwerk selbst kein VPC-Spoke ist.
Beachten Sie Folgendes, wenn Sie NCC-VPC-Spokes und VPC-Netzwerk-Peering verwenden:
Peering-Subnetzrouten in einem VPC-Spoke werden nicht in den Hub exportiert.
Das NCC bietet keine Verbindung zu Ressourcen in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering mit einem VPC-Spoke verbunden ist. Die folgende Ausnahme gilt:
- Ein VPC-Netzwerk des Diensterstellers mit Peering für den Zugriff auf private Dienste kann als Ersteller-VPC-Spoke hinzugefügt werden.
| Funktion | VPC-Netzwerk-Peering | VPC-Spokes |
|---|---|---|
| VPC-Netzwerke | ||
| Subnetzbereiche (Subnetzrouten) | ||
| Statische und dynamische Routen |
Eindeutige dynamische Routenpräfixe pro Hub-Routentabelle und Region. Der Austausch statischer Routen wird nicht unterstützt. |
|
| Exportfilter |
Bestimmte Filter werden nicht unterstützt. Weitere Informationen finden Sie in der Dokumentation zum VPC-Netzwerk-Peering unter Optionen für den Routenaustausch. |
Bis zu 16 CIDR-Bereiche werden pro VPC-Spoke unterstützt. |
| Inter-VPC NAT |
Nicht unterstützt |
Unterstützt |
| Private Service Connect-Verbindungsweitergabe |
Nicht unterstützt |
Unterstützt |
| Verbindung von anderen VPC-Netzwerken zum Ersteller-VPC-Spoke |
Nicht unterstützt |
Unterstützt |
| IP-Adressierung |
Interne IPv4-Adressen, einschließlich privater IPv4-Adressen und privat verwendeter öffentlicher IPv4-Adressen. Siehe Gültige IPv4-Bereiche. Interne und externe IPv6-Adressen. |
Interne IPv4-Adressen, einschließlich privater IPv4-Adressen und privat verwendeter öffentlicher IPv4-Adressen. Siehe Gültige IPv4-Bereiche. Interne und externe IPv6-Adressen. |
| IP-Adressfamilien |
Unterstützte Konfigurationen:
|
Unterstützte Konfigurationen:
|
| Leistung und Durchsatz (im Vergleich zu anderen VPC-Konnektivitätsmechanismen) |
Niedrigste Latenz, höchster Durchsatz (VM-VM-Entsprechung). |
Niedrigste Latenz, höchster Durchsatz (VM-VM-Entsprechung). |
VPC-Spokes in einem anderen Projekt als einem Hub
Mit dem NCC können Sie VPC-Netzwerke, die als VPC-Spokes dargestellt werden, an einen einzelnen Hub in einem anderen Projekt anhängen, einschließlich eines Projekts in einer anderen Organisation. So können Sie Ihre VPC-Netzwerke über mehrere Projekte und Organisationen hinweg in großem Maßstab miteinander verbinden.
Folgende Arten von Nutzern sind zulässig:
- Ein Hub-Administrator, der Inhaber eines Hubs in einem Projekt ist
- Ein VPC-Netzwerk-Spoke-Administrator oder Netzwerkadministrator, der sein VPC-Netzwerk in einem anderen Projekt als Spoke zum Hub hinzufügen möchte
Der Hub-Administrator steuert mithilfe von IAM-Berechtigungen (Identity and Access Management) den VPC-Spoke in einem anderen Projekt, das mit seinem Hub verknüpft ist. Der VPC-Netzwerk-Spoke-Administrator erstellt einen Spoke in einem anderen Projekt als dem Hub. Diese Spokes sind nach der Erstellung inaktiv. Der Hub-Administrator muss sie prüfen und den Spoke entweder akzeptieren oder ablehnen. Wenn der Hub-Administrator den Spoke akzeptiert, wird er aktiviert.
NCC akzeptiert immer automatisch Spokes, die im selben Projekt wie der Hub erstellt wurden.
Ausführliche Informationen zum Verwalten von Hubs, die VPC-Spokes in einem anderen Projekt als dem Hub haben, finden Sie unter Hub-Verwaltung – Übersicht. Ausführliche Informationen zu Spoke-Administratoren finden Sie unter Spoke-Verwaltung – Übersicht.
Spoke-Interaktion mit VPC Service Controls
NCC unterstützt VPC Service Controls für Spokes für mehrere Projekte und Organisationen. Wenn für einen Spoke in einem anderen Projekt aus dem Hub ein neuer VPC Service Controls-Perimeter hinzugefügt wird, können Sie keine neuen Spokes verwenden, die gegen diesen Perimeter verstoßen. Vorhandene Spokes, die Sie vor dem Hinzufügen des VPC Service Controls-Perimeters hinzugefügt haben, funktionieren jedoch weiterhin.
VPC-Konnektivität mit Exportfiltern
Mit NCC können Sie mithilfe von Spoke-Filtern einschränken, wie andere Spokes eine Verbindung zu einem VPC-Spoke herstellen können. Ausführliche Informationen zu Spoke-Filtern finden Sie unter Spoke-Filter – Übersicht. VPC-Spokes unterstützen nur Exportfilter.
Voreingestellte Topologien
Mit NCC können Sie die Konnektivitätskonfiguration für alle VPC-Spokes angeben. Sie können eine der folgenden beiden voreingestellten Topologien auswählen:
Ausführliche Informationen zu Verbindungstopologien finden Sie unter Voreingestellte Verbindungstopologien.
Ausführliche Informationen zum Konfigurieren der Mesh- oder Sterntopologie für Ihre VPC-Spokes finden Sie unter Hub konfigurieren.
Beschränkungen
In diesem Abschnitt werden die Einschränkungen von VPC-Spokes im Allgemeinen und ihre Verknüpfung mit einem Hub in einem anderen Projekt beschrieben. Diese Einschränkungen gelten auch für Producer-VPC-Spokes.
Einschränkungen von VPC-Spokes
- VPC-Netzwerke können auf exklusive Weise über den NCC-Hub oder über VPC-Netzwerk-Peering miteinander verbunden werden.
- Sie können kein VPC-Netzwerk-Peering zwischen zwei VPC-Spokes verwenden, die auch über einen NCC-Hub verbunden sind. Beachten Sie jedoch Folgendes:
- Für einen Ersteller-VPC-Spoke ist eine Peering-Verbindung zu einem VPC-Spoke im selben Hub erforderlich. Es wird keine Verbindung über das NCC zwischen dem Ersteller-VPC-Spoke und dem zugehörigen VPC-Spoke mit Peering hergestellt.
- Sie können einen mit NCC verbundenen VPC-Spoke haben, der über VPC-Netzwerk-Peering mit einer separaten VPC verbunden ist, die nicht Teil von NCC ist.
- Sie können VPC-Netzwerk-Peering zwischen zwei VPC-Spokes in der Edge-Spoke-Gruppe eines Hubs verwenden, der für die Verwendung der Stern-Topologie konfiguriert ist. Das liegt daran, dass NCC Spokes in der Edge-Gruppe nicht miteinander verbindet.
- VPCs, die über NCC und VPC-Netzwerk-Peering in einer beliebigen Kombination verbunden sind, sind nicht transitiv.
- Der Austausch statischer Routen über VPC-Spokes wird nicht unterstützt.
- IPv6-basierte interne Passthrough-Network Load Balancer sind zwischen VPC-Spokes nicht erreichbar.
- Der dynamische IPv6-Routenaustausch wird nicht unterstützt.
- VPC-Netzwerke im automatischen Modus werden nicht als VPC-Spokes unterstützt. Sie können vom automatischen Modus zu einem benutzerdefinierten VPC-Netzwerk wechseln, in dem Sie Subnetzpräfixe für jede Region in Ihrem VPC-Netzwerk manuell definieren können. Sobald die Aktualisierung erfolgt ist, kann sie nicht mehr rückgängig gemacht werden.
Einschränkungen des dynamischen Routenaustauschs
Nur IPv4: NCC unterstützt nur den Austausch von dynamischen IPv4-Routen. Der Austausch dynamischer IPv6-Routen wird nicht unterstützt.
Kompatibilität von Hybrid-Spokes mit der Stern-Topologie: Für einen Hub, der für die Verwendung der Stern-Topologie konfiguriert ist, gelten die folgenden Einschränkungen für seine Hybrid-Spokes:
- Hybrid-Spokes mit aktivierter Site-to-Site-Datenübertragung werden nur in der Center-Spoke-Gruppe unterstützt.
- Hybrid-Spokes ohne aktivierte Site-to-Site-Datenübertragung können sich entweder in der Center-Spoke-Gruppe oder in der Edge-Spoke-Gruppe befinden.
Routing-VPC-Netzwerke, die auch VPC-Spokes sind: NCC unterstützt zwei oder mehr Routing-VPC-Netzwerke auf demselben Hub nur, wenn nicht alle Routing-VPC-Netzwerke auch VPC-Spokes sind. Wenn ein NCC-Hub ein einzelnes Routing-VPC-Netzwerk hat, kann dieses Routing-VPC-Netzwerk optional auch ein VPC-Spoke sein:
Wenn Sie weitergeleitete Private Service Connect-Verbindungen über die Hybrid-Spokes des Hubs für lokale Netzwerke verfügbar machen müssen, muss das einzelne Routing-VPC-Netzwerk des Hubs auch als VPC-Spoke verbunden sein.
Wenn Sie keine weitergeleiteten Private Service Connect-Verbindungen über die Hybrid-Spokes des Hubs für lokale Netzwerke verfügbar machen müssen, empfehlen wir, kein Routing-VPC-Netzwerk als VPC-Spoke zu konfigurieren, damit der Hub zwei oder mehr Routing-VPC-Netzwerke unterstützen kann.
Wartezeit nach dem Löschen eines VPC-Spoke
Bei einem neuen Spoke für dasselbe VPC-Netzwerk, das mit einem anderen Hub verbunden ist, müssen Sie mindestens 10 Minuten warten. Wenn eine ausreichende Wartezeit nicht möglich ist, wird die neue Konfiguration möglicherweise nicht wirksam. Diese Abkühlphase ist nicht erforderlich, wenn das VPC-Netzwerk als Spoke zum selben Hub hinzugefügt wird.
Kontingente und Limits
Wenn Sie den dynamischen Routenaustausch verwenden, sollten Sie die Nutzung der Anzahl der dynamischen Routen pro Hub sorgfältig im Blick behalten. Dieses Kontingent berücksichtigt die Nutzung nur nach Ziel (Präfix), ohne Berücksichtigung der Priorität oder des nächsten Hops einer dynamischen Route. Wenn die Nutzung dieses Kontingents das Limit überschreitet, werden Routen vom NCC nach Ziel entfernt. Wenn ein Ziel entfernt wird, werden alle dynamischen Routen mit diesem Ziel, unabhängig von Priorität oder nächstem Hop, nicht mehr an den Hub gesendet.
Ausführliche Informationen zu Kontingenten finden Sie unter Kontingente und Limits.
Abrechnung
In den folgenden Abschnitten finden Sie Details zur Abrechnung von Spoke-Stunden und ausgehendem Traffic.
Spoke-Stunden
Spoke-Stunden werden dem Projekt in Rechnung gestellt, in dem sich die Spoke-Ressource befindet, und folgen den Standardpreisen für Spoke-Stunden. Spoke-Stunden werden nur in Rechnung gestellt, wenn sich der Spoke im Status ACTIVE befindet.
Ausgehender Traffic
Ausgehender Traffic wird dem Projekt der Spoke-Ressource in Rechnung gestellt, von der der Traffic stammt. Die Preise sind unabhängig davon, ob der Traffic Projektgrenzen überschreitet, gleich.
Service Level Agreement
Informationen zum Service Level Agreement (SLA) für NCC finden Sie unter Service Level Agreement (SLA) für Network Connectivity Center.
Preise
Informationen zu den Preisen finden Sie unter NCC-Preise.
Nächste Schritte
- Informationen zum Erstellen von Hubs und Spokes finden Sie unter Mit Hubs und Spokes arbeiten.
- Eine Liste der Partner, deren Lösungen in das NCC eingebunden sind, finden Sie unter NCC-Partner.
- Lösungen für häufige Probleme finden Sie unter Fehlerbehebung.
- Ausführliche Informationen zur API und zu
gcloud-Befehlen finden Sie unter APIs und Referenz.