VPC-Spokes – Übersicht

Diese Seite bietet eine Übersicht über die Unterstützung von Virtual Private Cloud (VPC) im 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-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 Network Connectivity Center-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 durch die Bereitstellung von IPv4- und IPv6-Subnetzroutenverbindungen sowie dynamischen IPv4-Routenverbindungen über Hybrid-Spokes.

Ein VPC-Netzwerk kann gleichzeitig ein VPC-Spoke in Network Connectivity Center 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 Network Connectivity Center-VPC-Spokes und VPC-Netzwerk-Peering verwenden:

  • Peering-Subnetzrouten in einem VPC-Spoke werden nicht in den Hub exportiert.

  • Network Connectivity Center bietet keine Verbindung zu Ressourcen in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering mit einem VPC-Spoke verbunden ist. Die folgende Ausnahme gilt:

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

Peerings pro VPC-Netzwerk

Aktive VPC-Spokes pro Hub

Subnetzbereiche (Subnetzrouten)

Subnetzbereiche pro Peering-Gruppe

Subnetzrouten pro Routentabelle

Statische und dynamische Routen

Statische Routen pro Peering-Gruppe

Dynamische Routen pro Region und Peering-Gruppe

Eindeutige dynamische Routenpräfixe pro Hub-Routingtabelle 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.

Nur private interne IPv4-Adressen, mit Ausnahme privat verwendeter öffentlicher IPv4-Adressen. Weitere Informationen finden Sie unter Gültige IPv4-Bereiche.

Interne und externe IPv6-Adressen.
IP-Adressfamilien Unterstützte Konfigurationen:
  • Nur IPv4-Subnetzbereiche austauschen
  • Sowohl IPv4- als auch IPv6-Subnetzbereiche austauschen
 Unterstützte Konfigurationen:
  • Nur IPv4-Subnetzbereiche austauschen
  • Sowohl IPv4- als auch IPv6-Subnetzbereiche austauschen
  • Nur IPv6-Subnetzbereiche austauschen
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 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.

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.

Spoke-Interaktion mit VPC Service Controls

Network Connectivity Center 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 Network Connectivity Center können Sie die Konnektivität aller Spoke-VPC-Netzwerke auf einen Teil der Subnetzwerke in der Spoke-VPC beschränken. So können Sie die Konnektivität einschränken:

  • Sie können den Spoke so konfigurieren, dass entweder alle oder keine seiner Subnetzbereiche beworben werden.
  • Sie können exportierte Subnetz-Adressbereiche ändern (Vorschau).
  • Sie können Adressbereiche angeben, um zu verhindern, dass sie beworben werden, und eine Liste von CIDR-Bereichen erstellen, die über das VPC-Netzwerk beworben werden können. Alternativ können Sie auch nur eine Liste zulässiger CIDR-Bereiche angeben und so alle anderen Bereiche blockieren.

Mit Exportfiltern können Sie VPC-Spokes so konfigurieren, dass nur IPv4-Subnetzbereiche, nur IPv6-Subnetzbereiche oder sowohl IPv4- als auch IPv6-Subnetzbereiche ausgetauscht werden. Angenommen, ein Spoke-VPC-Netzwerk hat eine Mischung aus Subnetz-Stack-Typen. Wenn Sie den Spoke so konfigurieren, dass nur IPv6-Subnetzbereiche exportiert werden, werden IPv6-Bereiche aus Dual-Stack- und reinen IPv6-Subnetzen ausgetauscht, IPv4-Subnetzbereiche aus reinen IPv4- und Dual-Stack-Subnetzen jedoch nicht.

Exportbereiche ausschließen

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 IP-Adressbereiche, 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.

Exportbereiche einschließen

Sie können festlegen, welche IP-Adressbereiche von einem VPC-Spoke beworben werden dürfen. Verwenden Sie dazu das Flag --include-export-ranges oder das Feld includeExportRanges in der API. Sie können Folgendes angeben:

  • Wenn Sie alle IPv4-Subnetzbereiche bewerben möchten, können Sie ALL_PRIVATE_IPV4_RANGES angeben.
  • Wenn Sie nur bestimmte Subnetzbereiche anbieten möchten, können Sie eine Liste von CIDR-Bereichen angeben.
  • Wenn Sie alle IPv6-Subnetzbereiche bewerben möchten, können Sie ALL_IPV6_RANGES angeben.

Sie können die Konnektivität präziser festlegen, indem Sie neben dem Ausschlussfilter auch einen Einschlussfilter verwenden. Durch diese Filterung wird bestimmt, ob ein bestimmter Subnetzbereich aus dem VPC-Netzwerk angekündigt werden kann.

Hinweise

Beachten Sie Folgendes, wenn Sie die Filter zum Ein- und Ausschließen von Exportbereichen verwenden:

  • Die Einbeziehungsbereiche dürfen sich nicht überschneiden. Angenommen, es gibt drei IPv4-Adressbereiche:

    Bereich 1: 10.100.64.0/18

    Bereich 2: 10.100.250.0/21

    Bereich 3: 10.100.100.0/22

    Bereich 1 und Bereich 2 sind gültige Include-Bereiche, da sie sich nicht überschneiden. Bereich 3 ist jedoch in Bereich 1 enthalten, daher ist Bereich 3 ungültig.

    Angenommen, Sie verwenden IPv6 und haben die folgenden drei IPv6-Adressbereiche:

    Bereich 1: 2001:db8::/32

    Bereich 2: 2001:db9::/32

    Bereich 3: 2001:db8:1000::/48

    Bereich 1 und Bereich 2 sind gültige Include-Bereiche, da sie sich nicht überschneiden. Bereich 3 ist jedoch in Bereich 1 enthalten, daher ist Bereich 3 ungültig.

  • Da im Network Connectivity Center bereits Ausschlussfilter für den Export in der Richtlinie für die Netzwerkkonfiguration verfügbar sind, wirken sich sowohl die Einschluss- als auch die Ausschlussfilter für den Export auf die gültigen CIDR-Bereiche für die Netzwerkkonfiguration aus. Wenn sowohl Ein- als auch Ausschlussfilter für den Export verwendet werden, müssen die eingeschlossenen IP-Adressbereiche eine Obermenge der ausgeschlossenen IP-Adressbereiche sein.

  • Wenn Sie beim Erstellen des VPC-Spoke den „Einschließen“-Filter nicht angeben, legt Network Connectivity Center den Standardbereich für das Einschließen auf alle gültigen privaten IPv4-Adressen fest, wie in Gültige IPv4-Bereiche definiert.

  • Sie können mehrere Ausschlussbereiche hinzufügen, um einen Einschlussbereich einzugrenzen. Wenn Sie beispielsweise 10.1.0.0/16 als Einschlussbereich und 10.1.100.0/24 und 10.1.200.0/24 als Ausschlussbereiche angeben, erhalten Sie eine verfeinerte Konnektivität mit der Kombination aus Ein- und Ausschlussfiltern. Dieser Bereich umfasst alles von 10.1.0.0/24 bis 10.1.99.0/24, 10.1.101.0/24 bis 10.1.199.0/24 und 10.1.201.0/24 bis 10.1.255.0/24.

  • Vorhandene Subnetzbereiche funktionieren weiterhin wie erwartet. Überlappungen mit Ein- und Ausschlussbereichen beim Erstellen neuer Subnetzbereiche führen zu einem Fehler.

Beispiele für ungültige neue Subnetzbereiche

Die folgenden Beispiele zeigen ungültige Subnetzbereiche:

  • Überschneidung mit dem Ausschlussbereich

    In diesem Fall enthält der folgende Einschlussbereich den Subnetzbereich 4, der eine Obermenge des Ausschlussbereichs 4 ist. Das bedeutet, dass der Subnetzbereich 4 ungültig ist.

    Bereich einschließen: 10.0.0.0/8

    Ausgeschlossener Bereich 4: 10.1.1.0/24

    Subnetzbereich 4: 10.1.0.0/16

  • Überschneidung mit dem Bereich zum Einbeziehen

    Subnetzbereich 5 überschneidet sich mit dem Einschlussbereich und ist daher ungültig.

    Bereich einschließen: 10.1.1.0/24

    Subnetzbereich 5: 10.1.0.0/16

    Wenn Sie beim Erstellen eines Subnetzes einen ungültigen Subnetzbereich eingeben, erhalten Sie einen Invalid IPCidrRange-Fehler, der in etwa so aussieht:

    Invalid IPCidrRange: CIDR_RANGE conflicts with existing subnetwork SUBNET_RANGE in region REGION

Voreingestellte Topologien

Mit dem Network Connectivity Center können Sie die gewünschte 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 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. Beachten Sie jedoch Folgendes:
    • Für einen Ersteller-VPC-Spoke ist eine Peering-Verbindung zu einem VPC-Spoke im selben Hub erforderlich. Die Verbindung über das Network Connectivity Center wird nicht zwischen dem Ersteller-VPC-Spoke und dem zugehörigen VPC-Spoke hergestellt.
    • Sie können 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-Netzwerk-Peering in einer beliebigen Kombination verbunden sind, sind nicht transitiv.
  • Der Austausch statischer Routen über VPC-Spokes wird nicht unterstützt.
  • Routen, die auf interne virtuelle IP-Adressen des Passthrough-Network Load Balancers in anderen VPC-Spokes verweisen, werden 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 beim Austausch dynamischer Routen

  • Nur IPv4: Das Network Connectivity Center unterstützt nur den Austausch dynamischer 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: Network Connectivity Center unterstützt zwei oder mehr Routing-VPC-Netzwerke auf demselben Hub nur, wenn alle Routing-VPC-Netzwerke nicht auch VPC-Spokes sind. Wenn ein Network Connectivity Center-Hub ein einzelnes VPC-Routingnetzwerk hat, kann dieses VPC-Routingnetzwerk 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öchten, 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.

  • Regeln für die Interaktion dynamischer Routen: In einem Routing-VPC-Netzwerk müssen Sie für jedes eindeutige Ziel einer dynamischen Route mit einem nächsten Hop in einem Hybrid-Spoke dafür sorgen, dass alle anderen dynamischen Routen, unabhängig von der Priorität, deren Ziele genau mit dem eindeutigen Ziel der dynamischen Route übereinstimmen oder in dieses passen, auch Cloud VPN-Tunnel oder VLAN-Anhänge als nächsten Hop in einem Hybrid-Spoke haben. Außerdem müssen Sie dafür sorgen, dass für diese Hybrid-Spokes dieselbe Einstellung für die Site-to-Site-Datenübertragung verwendet wird (entweder aktiviert oder deaktiviert).

    • Wenn sich nur einige Next Hops für dynamische Routen mit einem gemeinsamen Ziel in Hybrid-Spokes befinden, kann Network Connectivity Center dynamische Routen, die dieses Ziel verwenden, nicht zuverlässig mit VPC-Spokes im Hub austauschen. Daher erhalten VPC-Spokes diese dynamischen Routen möglicherweise nicht.

    • Das Network Connectivity Center führt kein ECMP zwischen allen Next Hops von dynamischen Hybrid-Spoke-Routen durch, wenn für einige Hybrid-Spokes die Site-to-Site-Datenübertragung aktiviert ist, für andere jedoch nicht. Wenn dynamische Routen mit einem gemeinsamen Ziel in Hybrid-Spokes ohne übereinstimmende Einstellungen für die Website-zu-Website-Datenübertragung vorhanden sind, sind die nächsten Hops für die Website-zu-Website-Datenübertragung oder für die Verbindung zwischen VPC-Spokes und lokalen Netzwerken möglicherweise nicht wie erwartet.

  • Regeln für die Interaktion von dynamischen und statischen Routen: In einem Routing-VPC-Netzwerk müssen Sie für jedes eindeutige Ziel einer dynamischen Route, das einen nächsten Hop in einem Hybrid-Spoke hat, dafür sorgen, dass keine lokalen statischen Routen vorhanden sind, deren Ziele genau mit dem Ziel der dynamischen Route übereinstimmen oder in dieses passen, unabhängig von der Priorität.

    • Wenn eine lokale statische Route im Routing-VPC-Netzwerk dasselbe Ziel wie eine dynamische Route des Hybrid-Spoke hat, verlieren VPC-Spokes möglicherweise die Verbindung zum Ziel der dynamischen Route.

    • Wenn eine lokale statische Route in einem VPC-Routingnetzwerk ein Ziel hat, das in das Ziel einer dynamischen Route des Hybrid-Spoke passt, verlieren VPC-Spokes die Verbindung zum Ziel der statischen Route.

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 Abklingzeit 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 im Network Connectivity Center nach Ziel gelöscht. Wenn ein Ziel entfernt wird, werden alle dynamischen Routen mit diesem Ziel nicht mehr an den Hub gesendet, unabhängig von Priorität oder nächstem Hop.

Ausführliche Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

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