VPC-Spokes – Übersicht

Diese Seite bietet eine Übersicht über die Unterstützung von VPC-Spokes (Virtual Private Cloud) in Network Connectivity Center.

VPC-Spokes

Network Connectivity Center bietet Inter-VPC-Netzwerkkonnektivität im großen Maßstab mit Unterstützung für VPC-Spokes. VPC-Netzwerk-Spokes reduzieren die operative Komplexität der Verwaltung der einzelnen paarweisen Peering-Verbindungen, die im VPC-Netzwerk-Peering verwendet werden. Dazu wird ein einfacheres zentralisiertes Konnektivitätsverwaltungsmodell ermöglicht. VPC-Spokes exportieren und importieren alle IPv4-Subnetzrouten aus anderen Spoke-VPCs. Dies gewährleistet eine vollständige IPv4-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 Network Connectivity Center-Hub befinden.

VPC-Spokes können gleichzeitig 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 mittlere bis große Arbeitslasten von Unternehmensarbeitslasten für die weitergeleitete Konnektivität zwischen IPv4-Subnetzbereichen in vielen verschiedenen VPC-Netzwerken.

Ein VPC-Netzwerk kann sowohl ein VPC-Spoke in Network Connectivity Center sein als auch über VPC-Netzwerk-Peering mit anderen VPC-Netzwerken verbunden sein. Peering-Subnetzrouten, die das Spoke-VPC-Netzwerk mithilfe von VPC-Netzwerk-Peering importiert, werden jedoch nicht für andere VPC-Spokes freigegeben, die mit dem Network Connectivity Center-Hub verbunden sind. Daher sind verwaltete Dienste, die vom Zugriff auf private Dienste unterstützt werden, nicht vorübergehend über andere Spokes eines Network Connectivity Center-Hubs erreichbar.

Funktion VPC-Netzwerk-Peering VPC-Spokes
VPC-Netzwerke

Bis zu 25 (erfordert niedrigere VPC-Kontingente)

Bis zu 250 aktive VPC-Spokes pro Hub

VM-Instanzen

Instanzen pro Peering-Gruppe

Network Connectivity Center unterstützt bis zur maximalen Anzahl von VPC-Netzwerken (keine separaten Peering-Gruppenkontingente erforderlich).

Subnetzbereiche (Subnetzrouten)

Subnetzwerkbereiche pro Peering-Gruppe

Subnetzrouten pro Routentabelle

Statische und dynamische Routen

Statische Routen pro Peering-Gruppe

Dynamische Routen pro Region und Peering-Gruppe

Statischer und dynamischer Routenaustausch wird nicht unterstützt.

Exportfilter

Bestimmte Filter werden nicht unterstützt. Siehe Optionen für den Routenaustausch in der Dokumentation zu VPC-Netzwerk-Peering.

Bis zu 16 CIDR-Bereiche werden pro VPC-Spoke unterstützt.

IP-Adressierung

Interne IP-Adressen, einschließlich privater IP-Adressen und privat verwendeter öffentlicher IPv4-Adressen. Siehe Gültige IPv4-Bereiche.

Nur private interne IPv4-Adressen, mit Ausnahme privat verwendeter öffentlicher IPv4-Adressen. Siehe Gültige IPv4-Bereiche.

IP-Adressfamilien

IPv4- und IPv6/IPv4-Dual-Stack-Adressen

Nur IPv4-Adressen

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 Network Connectivity Center können Sie VPC-Netzwerke, die als 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.

Network Connectivity Center 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.

VPC-Konnektivität mit Exportfiltern

Mit dem Network Connectivity Center können Sie die Konnektivität aller Spoke-VPC-Netzwerke auf einen Teil der Subnetzwerke in der Spoke-VPC beschränken. Wenn Sie verhindern möchten, dass ein IP-Adressbereich beworben wird, verwenden Sie das Flag exclude-export-ranges in der Google Cloud CLI oder das Feld excludeExportRanges in der API. Alle Subnetzwerke, die dem angegebenen Bereich entsprechen, werden vom Export in den Hub ausgeschlossen. Diese Filterung ist nützlich, wenn Sie Subnetze haben, die im VPC-Netzwerk privat sein müssen oder sich mit anderen Subnetzen in der Hub-Routingtabelle überschneiden können.

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.

Einschränkungen von VPC-Spokes

  • Hubs von Network Connectivity Center unterstützen keine VPC-Spokes mit VPN-, Cloud Interconnect- und Router-Appliance-Spokes auf demselben Hub.
  • VPC-Netzwerke können auf exklusive Weise über den Network Connectivity Center-Hub oder über VPC-Netzwerk-Peering miteinander verbunden werden. Sie können kein VPC-Netzwerk-Peering zwischen zwei VPC-Spokes verwenden, die mit demselben Network Connectivity Center-Hub verbunden sind. Sie können jedoch einen mit Network Connectivity Center verbundenen VPC-Spoke haben, der über VPC-Netzwerk-Peering mit einer separaten VPC verbunden ist, die nicht Teil von Network Connectivity Center ist.
  • VPCs, die über Network Connectivity Center und VPC-Peering-VPCs in einer beliebigen Kombination verbunden sind, sind nicht transitiv.
  • Statische und dynamische IPv4-Routen mit Austausch über VPC-Spokes werden nicht unterstützt.
  • Routen, die auf interne virtuelle Pass-Through IP-Adressen des Netzwerk-Load-Balancers in anderen VPC-Spokes verweisen, werden nicht unterstützt.
  • Sich überschneidende Subnetze müssen durch Exportfilter maskiert werden.
  • Es können höchstens 16 exclude export range-Filter pro Spoke angegeben werden.
  • Die Aktualisierung von export range filters nach der Erstellung des VPC-Spoke wird nicht unterstützt.
  • 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 funktionieren jedoch weiterhin.

Anforderungen an die Wartezeit nach dem Löschen eines VPC-Spoke

In diesem Abschnitt wird die erforderliche Wartezeit zwischen dem Löschen eines VPC-Spoke und dem Erstellen eines neuen Spoke für dieselbe VPC dargestellt. Wenn eine ausreichende Wartezeit nicht möglich ist, wird die neue Konfiguration möglicherweise nicht wirksam.

  • Nachdem Sie einen Spoke gelöscht haben, müssen Sie mindestens zehn Minuten warten, bevor Sie einen neuen Spoke für dasselbe VPC-Netzwerk erstellen, das mit demselben Hub verbunden ist.
  • Bei einem neuen Spoke für dasselbe VPC-Netzwerk, das mit einem anderen Hub verbunden ist, müssen Sie mindestens 24 Stunden warten.
  • Es ist möglich, dass die Spoke-Erstellung für dasselbe VPC-Netzwerk nicht ordnungsgemäß auf die Filter angewendet wird. Als Problemumgehung können Sie den Spoke löschen, dann länger warten und den Spoke neu erstellen.

Kontingente und Limits

Es gelten die folgenden Kontingente und Limits:

  • Anzahl der VPC-Spokes pro Projekt: (vorgeschlagen) 1.000
  • Anzahl aktiver VPC-Spokes pro Hub: 250
  • Gesamtzahl der VPC-Spokes pro Hub: 1.000
  • Anzahl von Subnetzrouten pro Routingtabelle: 1.000
  • Anzahl der Exportfilter pro VPC-Spoke: 16

Abrechnung

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 Network Connectivity Center finden Sie unter Service Level Agreement (SLA) für Network Connectivity Center.

Preise

Informationen zu den Preisen finden Sie unter Preise für Network Connectivity Center.

Nächste Schritte