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 Konnektivitätsverwaltungsmodells. VPC-Spokes können alle Subnetzrouten von anderen Spoke-VPCs in einem Network Connectivity Center-Hub exportieren und importieren. Dies gewährleistet eine vollständige Konnektivität zwischen allen Arbeitslasten, die sich in diesen VPC-Netzwerken befinden. Der Inter-VPC-Netzwerk traffic 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.
Hinweise zum dynamischen Routenaustausch mit VPC-Spokes
Routing-VPC-Netzwerke, die auch VPC-Spokes sind: Das 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 weitergeleitete Private Service Connect-Verbindungen nicht ü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.
Vergleich mit VPC-Netzwerk-Peering
VPC-Spokes unterstützen die Anforderungen von mittleren bis großen Unternehmen durch Folgendes:
- Sie können steuern, welche IPv4- und IPv6-Subnetzrouten zum Hub exportiert werden.
- Importieren von IPv4- und IPv6-Subnetzrouten vom Hub
- Importieren von dynamischen IPv4- und IPv6-Routen (Vorschau) , die von Hybrid-Spokes zum Hub exportiert wurden
- Sie können statische Routen konfigurieren mit internen Passthrough-Network-Load-Balancern als nächsten Hop in anderen VPC-Spokes.
Die folgenden Regeln gelten für ein VPC-Spoke-Netzwerk, das über VPC-Netzwerk-Peering mit einem anderen VPC Netzwerk verbunden ist mit Ausnahme von Ersteller-VPC Spokes :
- Das andere VPC-Netzwerk kann nicht als VPC-Spoke mit dem NCC-Hub verbunden sein.
- Das VPC-Spoke-Netzwerk kann die Peering-Subnetz routen, die es aus dem anderen Netzwerk importiert hat, nicht zum Hub exportieren.
| Funktion | VPC-Netzwerk-Peering | VPC-Spokes |
|---|---|---|
| Anzahl der VPC-Netzwerke | ||
| Anzahl der Subnetzbereiche (Subnetzrouten) |
Kontingent für Subnetz-routen pro Routingtabelle |
|
| Anzahl der dynamischen Routen |
Kontingent für dynamische Routen pro Region und Peering-Gruppe |
Kontingent für eindeutige dynamische Routenpräfixe pro Hub-Routingtabelle und Region |
| Anzahl der statischen Routen |
Der Austausch statischer Routen wird nicht unterstützt. Sie können jedoch statische Routen mit internen Passthrough-Network-Load-Balancern als nächsten Hop in einem anderen VPC-Spoke konfigurieren. |
|
| Exportfilter |
Bestimmte Filter werden nicht unterstützt. Weitere Informationen finden Sie unter Optionen für den Routenaustausch in der Dokumentation zu VPC-Netzwerk-Peering. |
Unterstützt sowohl Bereiche für den Export als auch Bereiche, die vom Export ausgeschlossen werden. Weitere Informationen finden Sie unter Exportfilter und Exportfilterregeln für VPC-Spokes. |
| Inter-VPC NAT |
|
|
| Weitergabe von Private Service Connect-Endpunkten |
|
|
| Konnektivität von Ersteller-VPC-Spokes in anderen VPC-Netzwerken |
|
|
| 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 verschiedenen Projekten
VPC-Spokes können sich entweder im NCC-Hub-Projekt oder in einem anderen Projekt befinden. Wenn sich ein VPC-Spoke und ein NCC-Hub in verschiedenen Projekten befinden, können sich die Projekte entweder in derselben oder in verschiedenen Organisationen befinden.
- Ein Hub-Administrator erstellt und verwaltet den NCC-Hub und akzeptiert VPC-Spoke-Angebote.
- Ein Spoke-Administrator erstellt ein Angebot für ein VPC-Netzwerk, um dem Hub als VPC-Spoke beizutreten.
Weitere Informationen zu Hub- und Spoke-Administratoren finden Sie unter:
Wenn ein Spoke-Administrator einen VPC Spoke im selben Projekt wie der Hub erstellt, fügt das NCC den VPC-Spoke sofort hinzu.
Wenn ein Spoke-Administrator einen VPC-Spoke in einem anderen Projekt als dem NCC-Hub-Projekt erstellt, erstellt das NCC ein Spoke-Angebot , das ein Hub-Administrator genehmigen muss, bevor der VPC-Spoke aktiv wird. Weitere Informationen finden Sie unter:
- VPC-Spoke in einem anderen Projekt vorschlagen
- Status eines VPC-Spoke prüfen
- Vorgeschlagene VPC-Spokes prüfen
Spoke-Interaktion mit VPC Service Controls
Das NCC unterstützt VPC Service Controls für projekt- und organisationsübergreifende Spokes. Wenn für einen Spoke in einem anderen Projekt als dem Hub ein neuer VPC Service Controls-Perimeter hinzugefügt wird, können Sie keine neuen Spokes hinzufügen, die gegen den 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 dem 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 dem NCC können Sie die Konnektivitätskonfiguration für alle VPC-Spokes festlegen. Sie können eine der folgenden beiden voreingestellten Topologien auswählen:
Ausführliche Informationen zu Konnektivitätstopologien finden Sie unter Voreingestellte Konnektivitätstopologien.
Ausführliche Informationen zum Konfigurieren der Mesh- oder Stern-Topologie 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 Ersteller-VPC-Spokes.
Einschränkungen von VPC-Spokes
- Sie können kein VPC-Netzwerk-Peering zwischen zwei VPC-Spokes verwenden, die auch über einen NCC-Hub verbunden sind. Beachten Sie jedoch Folgendes:
- Ein Ersteller-VPC-Spoke erfordert eine Peering-Verbindung zu einem VPC-Spoke auf demselben Hub. Die Konnektivität über das NCC wird nicht zwischen dem Ersteller-VPC-Spoke und dem zugehörigen VPC-Spoke hergestellt.
- Sie können einen mit dem NCC verbundenen VPC-Spoke haben, der über VPC-Netzwerk-Peering mit einer separaten VPC verbunden ist, die nicht Teil des 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 das NCC Spokes in der Edge-Gruppe nicht miteinander verbindet.
- Der Austausch statischer Routen über VPC-Spokes wird nicht unterstützt.
- Interne Passthrough-Network-Load-Balancer auf IPv6-Basis sind zwischen VPC-Spokes nicht erreichbar.
- 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. Nachdem das Netzwerk aktualisiert wurde, kann diese Aktion nicht rückgängig gemacht werden.
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 Wartezeit 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. Bei diesem Kontingent wird die Nutzung nach Ziel (Präfix) nur gezählt, ohne Rücksicht auf die Priorität oder den nächsten Hop einer dynamischen Route. Wenn die Nutzung dieses Kontingents das Limit überschreitet, verwirft das NCC Routen nach Ziel. Wenn ein Ziel verworfen 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 werden Details zur Abrechnung von Spoke-Stunden und ausgehendem Traffic beschrieben.
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 das NCC finden Sie unter Service Level Agreement (SLA) für Network Connectivity Center.
Preise
Informationen zu Preisen finden Sie unter Network Connectivity Center – 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.