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 einem zentralen Modell für die Konnektivitätsverwaltung. VPC-Spokes exportieren und importieren alle IPv4-Subnetzrouten aus anderen Spoke-VPCs in einem Network Connectivity Center-Hub. 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, standardmäßig nicht vorübergehend über andere Spokes eines Network Connectivity Center-Hubs erreichbar. In diesem Fall können Sie den verwalteten Dienst mit einem Ersteller-VPC-Spoke (Vorabversion) erreichbar machen.

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 Routingtabelle

Statische und dynamische Routen

Statische Routen pro Peering-Gruppe

Dynamische Routen pro Region und Peering-Gruppe

500 dynamische Routen pro Hub.

Der Austausch von Static Routes 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.

Interne IPv4-Adressen, einschließlich privater IP-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 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.

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. Sie können die Konnektivität einschränken, indem Sie IP-Adressbereiche angeben, die nicht angesagt werden sollen, und eine Liste mit CIDR-Bereichen erstellen, die aus dem VPC-Netzwerk angesagt werden können. Sie können die Konnektivität auch einschränken, indem Sie eine Liste zulässiger CIDR-Bereiche angeben. Dadurch werden alle Bereiche außer den zulässigen Bereichen blockiert.

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 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.

Exportbereiche einschließen

Mit dem Flag include-export-ranges oder dem Feld includeExportRanges in der API können Sie eine Liste mit CIDR-Bereichen erstellen, die von einem VPC-Spoke beworben werden dürfen. Wenn Sie diese Option zusammen mit dem IP-Adressbereich des Exportfilters verwenden, der auszuschließen ist, wird eine genauere Verbindung hergestellt. Durch diese Filterung wird festgelegt, ob ein bestimmter Subnetzbereich aus dem VPC-Netzwerk beworben werden kann.

Hinweise

Beachten Sie Folgendes, wenn Sie die Filter „Auszuschließende Exportbereiche“ und „Einzuschließende Exportbereiche“ verwenden:

  • Die Include-Bereiche dürfen sich nicht überschneiden. Angenommen, es gibt drei IP-Adressbereiche:

    Range 1: 10.100.64.0/18

    Range 2: 10.100.250.0/21

    Range 3: 10.100.100.0/22

    Range 1 und range 2 sind gültige Einschlussbereiche, da sie sich nicht überschneiden. range 3 liegt jedoch unter range 1, was zu Überschneidungen führen kann. Daher ist range 3 ungültig.

  • Da im Network Connectivity Center bereits Ausschlussexportfilter in der Netzwerkkonfigurationsrichtlinie verfügbar sind, wirken sich sowohl die Exportfilter für Einschlüsse als auch die für Ausschlüsse auf die gültigen CIDR-Bereiche der Netzwerkkonfiguration aus. Wenn sowohl Exportfilter für einzuschließende als auch für auszuschließende Daten verwendet werden, müssen die IP-Adressbereiche, die eingeschlossen werden sollen, eine Übermenge der IP-Adressbereiche sein, die ausgeschlossen werden sollen.

  • Standardmäßig haben alle VPC-Konnektivitätsrichtlinien einen CIDR-Bereich von 0.0.0.0/0. Wenn Sie also beim Erstellen des VPC-Spokes keinen Include-Filter angeben, setzt Network Connectivity Center den Standard-Include-Bereich auf alle gültigen privaten IPv4-Adressen, wie in Gültige IPv4-Bereiche definiert.

  • Sie können einen Einschlussbereich verfeinern, indem Sie mehrere Ausschlussbereiche hinzufügen. 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, wird die Konnektivität durch die Kombination von Einschluss- und Ausschlussfiltern optimiert. Dazu gehören 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. Überschneidungen mit Include- und Exclude-Bereichen 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: Angenommen, es gibt die folgenden IP-Adressbereiche.

    Zu berücksichtigender Bereich: 10.0.0.0/8

    Exclude range 4: 10.1.1.0/24

    Subnet range 4: 10.1.0.0/16

    In diesem Fall enthält der Include-Bereich subnet range 4. Es ist jedoch ein Obermenge von exclude range 4. Daher ist subnet range 4 ungültig.

  • Überschneidung mit dem Include-Bereich: Angenommen, es gibt die folgenden IP-Adressbereiche:

    Zu berücksichtigender Bereich: 10.1.1.0/24

    Subnet range 5: 10.1.0.0/16

    Subnet range 5 überschneidet sich mit dem Include-Bereich und ist daher ungültig.

Wenn Sie beim Erstellen eines Subnetzes einen ungültigen Subnetzbereich eingeben, erhalten Sie einen Invalid IPCiderRange-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 vordefinierten Topologien auswählen:

  • Mesh-Netzwerktopologie
  • Sterntopologie

Wenn Sie einen Hub mit dem Befehl gcloud network-connectivity hubs create erstellen, wählen Sie die vordefinierte Mesh- oder Sterntopologie aus. Wenn die Topologie nicht angegeben ist, wird standardmäßig „Mesh“ verwendet. Die beim Erstellen des Hubs festgelegte Topologie kann nicht mehr geändert werden.

Wenn Sie die Topologieeinstellungen eines Spokes ändern möchten, können Sie den Spoke löschen und einen neuen Spoke mit einem neuen Hub erstellen, der eine andere Topologie verwendet.

Mesh-Netzwerktopologie

Die Mesh-Topologie bietet eine Netzwerkkonnektivität im großen Maßstab zwischen VPC-Spokes. Mit dieser Topologie können alle Spokes miteinander verbunden werden und miteinander kommunizieren. Subnetze innerhalb dieser VPC-Speichen sind vollständig erreichbar, sofern Sie exclude export filters nicht angeben. Wenn zwei oder mehr Arbeitslast-VPC-Netzwerke so konfiguriert sind, dass sie einem Network Connectivity Center-Hub als Spokes beitreten, erstellt Network Connectivity Center standardmäßig eine vollständige Mesh-Konnektivität zwischen den einzelnen Spokes.

Alle Speichen innerhalb der Mesh-Topologie gehören zu einer einzigen Standard-Gruppe. Die Mesh-Topologie wird für VPC- und Hybrid-Spoke-Typen unterstützt.

Das folgende Diagramm zeigt die Mesh-Topologie-Verbindung im Network Connectivity Center.

Mesh-Topologie-Verbindung des Network Connectivity Center
Netzwerkkonnektivität der Mesh-Topologie des Network Connectivity Centers (zum Vergrößern anklicken)

Sterntopologie

Die Sterntopologie wird nur mit VPC-Spokes unterstützt. Wenn Sie eine Sterntopologie für die Konnektivität verwenden, erreichen die Edge-Spokes und ihre zugehörigen Subnetze nur die angegebenen Center-Spokes, während die Center-Spokes alle anderen Spokes erreichen können. So wird die Segmentierung und Verbindungstrennung in Edge-VPC-Netzwerken sichergestellt.

Da VPC-Spokes an einen Hub in einem anderen Projekt angehängt werden können, können sie aus verschiedenen Verwaltungsdomains stammen. Diese Spokes, die sich in einem anderen Projekt als dem Hub befinden, müssen möglicherweise nicht mit jedem anderen Spoke im Network Connectivity Center-Hub kommunizieren.

Sie können die Sterntopologie für den folgenden Anwendungsfall auswählen:

  • Arbeitslasten, die in verschiedenen VPC-Netzwerken ausgeführt werden und keine Verbindung untereinander, sondern nur Zugriff auf die VPC-Netzwerke über das zentrale VPC-Netzwerk mit freigegebenen Diensten benötigen.

  • Sicherheitskontrolle der Kommunikation über mehrere VPC-Netzwerke, bei der der Traffic eine Reihe von zentralen Netzwerk-Virtuellen-Appliances (NVAs) durchlaufen muss.

Das folgende Diagramm zeigt eine Sterntopologie in Network Connectivity Center. center-vpc-a und center-vpc-b sind mit der Mittelgruppe und edge-vpc-c und edge-vpc-d mit der Randgruppe verknüpft. In diesem Fall können edge-vpc-c und edge-vpc-d über die Sterntopologie mit center-vpc-a und center-vpc-b verbunden werden und ihre Subnetze an die zentrale Gruppe weitergeben, aber nicht miteinander verbunden sein (keine direkte Erreichbarkeit zwischen edge-vpc-c und edge-vpc-d). center-vpc-a und center-vpc-b sind dagegen miteinander und mit edge-vpc-c und edge-vpc-d verbunden, sodass die VPCs der zentralen Gruppe von den VPCs der Edge-Gruppe vollständig erreichbar sind.

Netzwerkkonnektivität mit Sterntopologie des Network Connectivity Center
Sterntopologie-Verbindung des Network Connectivity Centers (zum Vergrößern anklicken)

Spoke-Gruppen

Eine Spoke-Gruppe ist eine Teilmenge von Spokes, die mit einem Hub verbunden sind. Wenn Sie das Network Connectivity Center mit einer Sterntopologie konfigurieren möchten, müssen Sie alle VPC-Spokes in zwei verschiedene Gruppen unterteilen, die auch als Routingdomains bezeichnet werden:

  1. Eine zentrale Gruppe von Spokes, die mit allen anderen Spokes kommunizieren, die mit dem Hub verbunden sind
  2. Eine Randgruppe von Speichen, die nur mit Speichen kommunizieren, die zur Mittelgruppe gehören

Ein VPC-Spoke kann jeweils nur zu einer Gruppe gehören. Gruppen werden automatisch erstellt, wenn Sie einen Hub erstellen.

Ein Hub-Administrator kann eine Spoke-Gruppe mit dem Befehl gcloud network-connectivity hubs groups update aktualisieren. Der Hub-Administrator kann eine Liste mit Projekt-IDs oder Projektnummern hinzufügen, um die automatische Annahme für Spokes zu aktivieren. Wenn die automatische Annahme aktiviert ist, wird der Spoke aus dem Projekt mit automatischer Annahme automatisch mit dem Hub verbunden, ohne dass ein einzelner Spoke-Vorschlag überprüft werden muss.

Mit dem Befehl gcloud network-connectivity hubs groups list --hub können Sie die Gruppen center und edge als verschachtelte Ressourcen für einen bestimmten Hub auflisten. Bei Hubs, die mit einer Mesh-Topologie erstellt wurden, wird in der Ausgabe die Standardgruppe zurückgegeben. Für Hubs, die mit einer Sterntopologie erstellt wurden, werden in der Ausgabe die Gruppen center und edge zurückgegeben.

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 VPC-Spokes von Produzenten (Vorabversion).

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. Zwischen dem Ersteller-VPC-Spoke und dem zugehörigen VPC-Spoke wird keine Verbindung über das Network Connectivity Center 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 von statischen IPv4-Routen über VPC-Spokes wird 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 Ausschlussexportfilter maskiert 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.
  • Bei einer Sterntopologie werden keine Hybrid-Spokes oder dynamischer Routenaustausch unterstützt.

Anforderungen an die 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 demselben Hub als Spoke hinzugefügt wird.

Kontingente und Limits

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