Network Connectivity Center

Das Network Connectivity Center ist ein Hub-and-Spoke-Modell für die Verwaltung der Netzwerkverbindung in Google Cloud. Die Hub-Ressource reduziert die operative Komplexität durch ein einfaches, zentrales Modell für das Verbindungsmanagement. Der Hub ist mit dem Google-Netzwerk gekoppelt, um bei Bedarf zuverlässig eine Verbindung herzustellen.

Definitionen vonHub und Spoke finden Sie unter Hubs und Spokes weiter unten in diesem Dokument.

Mit dem Network Connectivity Center können Sie Ihre lokalen Netzwerke über das Google-Netzwerk als Netzwerk für die Datenübertragung verbinden. Lokale Netzwerke können lokale Rechenzentren und Zweig- oder Außenstellen haben.

Lokale Netzwerke stellen über Spokes, mit denen unterstützte Google Cloud-Spoke-Ressourcen verbunden sind, eine Verbindung zum Network Connectivity Center-Hub her. Ein Spoke kann beispielsweise HA VPN-Tunnel für ein Cloud VPN-Gateway in der Nähe des lokalen Netzwerks enthalten.

Das folgende Diagramm zeigt verschiedene Arten von Spoke-Ressourcen, die mit einem Network Connectivity Center-Hub verbunden sind. Der Hub ist einem VPC-Netzwerk zugeordnet.

Grafik: Konzept des Network Connectivity Centers
Konzept des Network Connectivity Centers (zum Vergrößern klicken)

Datenübertragung über das Google-Netzwerk

Das Network Connectivity Center unterstützt das Verbinden von Unternehmensstandorten außerhalb von Google Cloud über das Google-Netzwerk als Wide Area Network (WAN). Diese Art von Traffic wird als Datenübertragungstraffic bezeichnet.

Externe Standorte können zum Beispiel Netzwerke für Niederlassungen, private Rechenzentren und Arbeitslasten anderer Cloud-Anbieter umfassen. Diese Standorte stellen eine Verbindung zu einem Network Connectivity Center her. Dazu nutzen Sie vorhandene Ressourcen der Cloud-Hybridkonnektivität wie Cloud VPN, Dedicated Interconnect, Partner Interconnect oder ausgewählte Appliance-Partner.

Mit dem Network Connectivity Center profitieren Sie sofort von der globalen Reichweite und Zuverlässigkeit des Google-Netzwerks. Mit dieser Funktionalität kann Ihr Unternehmen von den Google-Verfahren für Zuverlässigkeit und Traffic-Engineering profitieren.

Grafik: Datenübertragung über das Google-Netzwerk
Datenübertragung über das Google-Netzwerk (zum Vergrößern klicken)

So gehts

In den folgenden Abschnitten werden die Funktionsweise und die Komponenten des Network Connectivity Centers beschrieben.

Hubs und Spokes

Das Network Connectivity Center besteht aus Hub- und Spoke-Ressourcen. Sie können einer Hub- oder Spoke-Ressource ein oder mehrere Labels hinzufügen, um sie zu identifizieren.

Hub

Ein Hub ist eine globale Google Cloud-Ressource, die mehrere angehängte Spokes unterstützt. Es bietet eine einfache Möglichkeit, Spokes miteinander zu verbinden, um eine Datenübertragung zwischen ihnen zu ermöglichen. Ein Hub kann den Datentransfer zwischen verschiedenen lokalen Standorten und einem VPC-Netzwerk (Virtual Private Cloud) über die zugehörigen Spokes ermöglichen.

Die Hub-Ressource reduziert die operative Komplexität durch ein einfaches, zentrales Modell für das Verbindungsmanagement. Ein Hub, kombiniert mit dem Netzwerk von Google, bietet bei Bedarf zuverlässige Konnektivität.

Spoke

Ein Spoke ist eine Google Cloud-Netzwerkressource, die mit einem Hub verbunden ist. Sie ist Teil eines Hubs und lässt sich erst erstellen, wenn der Hub neu erstellt wurde. Ein Spoke leitet den Traffic an Remote-Netzwerkadresseblöcke und ermöglicht die Verbindung mehrerer Remote-Netzwerke.

Spokes können nur einen Ressourcentyp haben, der jedem Spoke zugeordnet ist. Informationen zu Ressourcentypen finden Sie im nächsten Abschnitt.

Spoke-Ressourcentypen

Das Network Connectivity Center unterstützt das Anhängen folgender Google Cloud-Ressourcen an Spokes. Sie können zwar nur einen Ressourcentyp in einem Spoke haben, aber Sie können mehrere Instanzen desselben Ressourcentyps an denselben Spoke anhängen.

  • HA VPN-Tunnel
  • VLAN-Anhänge
  • Router-Appliance-Instanzen, die Sie oder ausgewählte Partner in Google Cloud bereitstellen

Sie konfigurieren eine Router-Appliance-Instanz als BGP-Peer eines Cloud Routers. Sie können eine Router-Appliance-Instanz erstellen, indem Sie eine Compute Engine-VM konfigurieren, BGP-Peering für Cloud Router aktivieren und ein Image Ihrer Wahl ausführen, z. B. eine virtuelle Appliance eines Drittanbieter-Netzwerks.

Hochverfügbarkeit für Spoke-Ressourcen (erforderlich)

Jeder Ressourcentyp hat unterschiedliche Anforderungen für Hochverfügbarkeit. Konfigurieren Sie die zu verwendenden Ressourcentypen, indem Sie die Informationen in den folgenden Abschnitten lesen.

Hochverfügbarkeit für Cloud Interconnect

Damit das Network Connectivity Center mit Cloud Interconnect-Ressourcen ordnungsgemäß funktioniert, müssen Sie mehrere Interconnect-Verbindungen in einer separaten Edge-Verfügbarkeitsdomain konfigurieren.

Ausführliche Informationen zum Konfigurieren von Cloud Interconnect-Ressourcen für Hochverfügbarkeit finden Sie in der folgenden Dokumentation:

Hochverfügbarkeit für Cloud VPN

Damit die Netzwerkverbindung mit Cloud VPN-Ressourcen ordnungsgemäß funktioniert, müssen Sie mehrere HA VPN-Gateway-Schnittstellen und Tunnel konfigurieren, um ein SLA von 99,99% zu erhalten. Weitere Informationen finden Sie in der Übersicht zu Cloud VPN.

Hochverfügbarkeit für Router-Appliance

Damit das Network Connectivity Center ordnungsgemäß mit Router-Instanzen funktioniert, die an einen Spoke angehängt sind, müssen Sie Folgendes tun:

Wenn Sie alle Router-Appliance-Instanzen in einem einzigen Spoke zusammenfassen, verwenden Sie das ECMP-Tool (Equal Cost Multipath) für denselben Advertising-Satz von zwei Router-Appliance-Instanzen. Wenn Sie verschiedene Präfixe für verschiedene Spokes anbieten möchten, fügen Sie jede Router-Appliance-Instanz einem anderen Spoke hinzu.

Sie können keine regionsübergreifende Konfiguration in einem einzelnen Spoke erstellen.

ECMP ist das Ergebnis desselben Advertising-Präfix bzw. derselben Präfixe mit denselben MEDs und AS-Pfaden, soweit anwendbar, von zwei oder mehr Router-Instanzen. Die Hinweise zur Routenauswahl in VPC-Netzwerken gelten für Router-Appliance-Instanzen ebenso wie für andere Google Cloud-Ressourcen.

Ausführliche Informationen zum Konfigurieren von Router-Appliance-Instanzen für Hochverfügbarkeit finden Sie unter Anforderungen für eine Verfügbarkeit von 99,9%.

Routenaustausch

Das Network Connectivity Center bietet vollständige Mesh-Konnektivität zwischen den einzelnen Spokes, die mit ihm verbunden sind, indem es alle Routen, die ein Spoke erlernt, an alle anderen Spokes weitergibt, die mit demselben Hub verbunden sind.

Grafik: Topologie des Network Connectivity Centers
Topologie des Network Connectivity Centers (zum Vergrößern klicken)

In der obigen Topologie sind die Spokes A, B und C mit demselben Hub verbunden und verwenden Cloud Router, um Präfixe im Hub anzubieten.

Zur Aktivierung des regionenübergreifenden Site-to-Site-Traffics über Hubs und Spokes müssen Sie im VPC-Netzwerk, das den Hubs und Spokes zugeordnet ist, das globale Routing aktivieren. Befinden sich alle Spokes in derselben Region, ist das globale Routing nicht erforderlich, da Site-to-Site-Traffic ohne globales Routing funktioniert.

Die folgende Tabelle zeigt, wie das Hub Präfix-Advertisements an andere Spokes weiterleitet.

Routen von Spoke A Routen von Spoke B Routen von Spoke C
Routen wurden an Spoke A exportiert 10.3.0.0/16 ist über Spoke B erreichbar. 10.4.0.0/16 ist über Spoke C erreichbar.
Routen wurden an Spoke B exportiert 10.2.0.0/16 ist über Spoke A erreichbar. 10.4.0.0/16 ist über Spoke C erreichbar.
Routen wurden an Spoke C exportiert 10.2.0.0/16 ist über Spoke A erreichbar. 10.3.0.0/16 ist über Spoke B erreichbar.

Routenkonflikte

Beachten Sie bei der Bestimmung der Reihenfolge der Routen, dass die von einem Network Connectivity Center-Hub installierten Routen als dynamische Routen behandelt werden. Weitere Informationen zum Beheben von Routenkonflikten finden Sie in der VPC-Dokumentation unter Anwendbarkeit und Reihenfolge der Route.

Zur Ermittlung der besten Pfade für eingehende Advertisements verwendet Google Cloud MED, um die Priorität zu bestimmen. Weitere Informationen finden Sie unter Überlegungen zum Routing.

Kompatibilität mit vorhandenen Netzwerkkonfigurationen

Das Network Connectivity Center betrifft nur die Kommunikation zwischen Spokes. Die Kommunikation zwischen Cloud VPN oder Cloud Interconnect und VPC-Netzwerken wird davon nicht beeinflusst.

  • Alle VMs im selben VPC-Netzwerk lernen weiterhin alle Routen, die ein Cloud VPN-Tunnel oder eine Interconnect-Verbindung anbietet.
  • Alle Subnetzrouten im selben VPC-Netzwerk werden weiterhin allen Cloud VPN-Tunneln und Interconnect-Verbindungen in diesem VPC-Netzwerk angeboten.
  • Die vorherige Routenverteilung erfolgt weiterhin über Netzwerke, die VPC-Netzwerk-Peering verwenden. Ausnahmen finden Sie unter Überlegungen zum Routing.

Außerdem wirkt sich das Network Connectivity Center nicht auf das Advertising in Netzwerken aus, das VPC-Netzwerk-Peering verwendet. Alle von einem Cloud VPN-Tunnel oder VLAN-Anhang angebotenen Routen können weiterhin an ein Peering-Netzwerk exportiert werden. Alle Subnetzrouten des Peering-Netzwerks werden dem lokalen Netzwerk über einen Cloud VPN-Tunnel oder über einen VLAN-Anhang angeboten.

Hinweise

In diesem Abschnitt werden allgemeine Überlegungen vor dem Einrichten des Network Connectivity Centers beschrieben. Außerdem werden Informationen zu den mit einem Hub verbundenen Ressourcen und zum Routing über Hubs und Spokes bereitgestellt.

Kontingente und Limits für das Network Connectivity Center finden Sie unter Kontingente und Limits.

Hubs, Spokes und VPC-Netzwerke

Wenn Sie einem Hub den ersten Spoke hinzufügen, wird dieser Hub mit dem Projekt und Netzwerk für den Spoke verknüpft. Bei einem VPC-Netzwerk darf es nur eine Instanz eines Hubs geben. Das mit dem Hub verknüpfte VPC-Netzwerk kann kein Legacy-VPC-Netzwerk sein.

Ressourcen wie Cloud VPN-Tunnel und an einen Spoke angehängte VLAN-Anhänge müssen zum selben VPC-Netzwerk gehören wie der Hub.

Freigegebene VPC-Netzwerke unterstützen Hubs und Spokes auf unterschiedliche Weise.

Die folgenden Überlegungen gelten auch für Hubs und Spokes:

  • Nur HA VPN-Tunnel werden als Anhänge für Spokes unterstützt. Klassische VPN-Tunnel werden nicht unterstützt.
  • Beim Erstellen von HA VPN-Tunneln, die an ein Network Connectivity Center-Spoke angehängt werden, ist das Erstellen von Google Cloud-zu-Google Cloud-HA-VPN-Gateways in verschiedenen Regionen innerhalb desselben Google Cloud-Projekts nicht möglich. Dies ist eine Beschränkung von HA VPN, keine Einschränkung des Network Connectivity Centers.
  • Der Datenübertragungs-Traffic zwischen Standorten erfolgt nach bestem Gewissen und es gibt keine Bandbreitengarantien.
  • Das Network Connectivity Center ist nur an unterstützten Standorten verfügbar (mit einigen Ausnahmen).

Unterstützung für VPC-Netzwerk-Peering

Sie können das mit dem Hub verknüpfte Netzwerk mit VPC-Netzwerk-Peering über ein oder mehrere andere VPC-Netzwerke verbinden. Damit das Netzwerk, das mit dem Hub-Netzwerk verbunden ist, Traffic an die lokalen, mit dem Hub verbundenen Netzwerke senden und von ihnen empfangen kann, müssen Sie außerdem Folgendes tun:

  1. Verwenden Sie benutzerdefinierte Route Advertisements, um Peer-VPC-Subnetze für lokale Netzwerke freizugeben, die mit dem Hub verbunden sind.
  2. Den Import und Export benutzerdefinierter Routen aktivieren. Dadurch werden Routen aus lokalen, mit dem Hub verbundenen Netzwerken für die Subnetze in VPC-Netzwerken sichtbar, die mit dem VPC-Netzwerk verbunden sind, dem der Hub zugeordnet ist.

Unterstützung für freigegebene VPC-Netzwerke

Wenn Sie freigegebene VPC-Netzwerke verwenden, müssen Sie den Hub im Hostprojekt erstellen.

Informationen zur Rolle networkconnectivity.googleapis.com/spokeAdmin, die Sie Administratoren von Dienstprojekten zuweisen können, finden Sie unter Zugriffssteuerung.

Überlegungen zu APIs

Überlegungen zum Routing

  • Routingpräfixe müssen exklusiv in einem Hub oder außerhalb eines Hubs angeboten werden. Wird beispielsweise dasselbe Präfix von zwei Cloud VPN-Tunneln angekündigt, eins in einem Hub und eins außerhalb eines Hubs, kann die Datenübertragung unter Umständen nicht ausgeführt werden, wenn der Tunnel außerhalb des Hubs ausgewählt wird.
  • Der AS-Pfad wird für die beste Pfadauswahl innerhalb einer einzelnen Cloud Router-Aufgabe verwendet. Andernfalls wird nur MED verwendet, um Routen zu priorisieren. Weitere Informationen finden Sie im Abschnitt "AS-Pfad" in der Cloud Router-Übersicht.

Spokes ASNs zuordnen

Zur Vereinfachung Ihrer Konfiguration empfehlen wir die folgende Vorgehensweise, um ASNs zu Spokes zuzuweisen.

  • Verwenden Sie für alle Spoke-Ressourcen, die mit einem einzelnen Hub verbunden sind, eine einzelne autonome Systemnummer von Google (ASN) (router.bgp.asn) auf dem Cloud Router. Beispiel: Die HA VPN-Tunnel, die mit einem Spoke verbunden sind, würden auf dem Cloud Router diejenige Google ASN verwenden, die sie für das Peering nutzen. Folgen Sie den Empfehlungen für die Nummerierung von ASNs in der Dokumentation zum Erstellen eines Cloud Routers.
  • Weisen Sie jedem Spoke, der mit demselben Hub (router.bgpPeers.asn) verbunden ist, eine eindeutige Peer-ASN zu. Achten Sie darauf, dass in allen Spokes alle Peer-ASNs identisch sind. Denn wenn zwei Peers dasselbe Präfix mit unterschiedlichen ASNs oder AS-Pfaden bewerben, werden nur die ASN und der AS-Pfad eines einzelnen Peers für dieses Präfix neu beworben.
  • Wir empfehlen die Konfiguration der AS-Pfadschleifenerkennung auf Ihren Peer-Routern. Dieses Feature ist standardmäßig fast immer aktiviert. In einigen Fällen kann es nicht deaktiviert werden. Beispielsweise wenn der Peer-Router ein Cloud Router ist oder wenn Routingfunktionen von anderen Cloud-Anbietern verwendet werden.

    Wenn die AS-Pfadschleifenerkennung aktiviert ist und zwei Spokes mit der gleichen Peer-ASN konfiguriert sind, verwirft die AS-Pfadschleifenerkennung auf einem Peer-Router für einen Spoke alle Präfix-Advertisements vom anderen Spoke.

Im folgenden Beispiel bewerben Peer-Router in den folgenden Spokes die folgenden Präfixe und unterschiedliche ASNs:

  • Spoke A: Peer-Router 1, ASN 65001 bewirbt die Präfixe 10.1.0.0/16 und 10.2.0.0/16
  • Spoke A: Peer-Router 2, ASN 65002, bewirbt die Präfixe 10.1.0.0/16 und 10.3.0.0/16
  • Spoke B: Peer-Router 3, ASN 65003 bewirbt die Präfixe 10.1.0.0/16 und 10.4.0.0/16

Cloud Router bewirbt dann die folgenden Präfixe für einen Peer für Spoke C:

  • 10.1.0.0/16, aber der AS-Pfad kann mit einer der folgenden ASNs beginnen: 65001 oder 65002 oder 65003
  • 10.2.0.0/16 mit einem AS-Pfad, der mit 65001 beginnt
  • 10.3.0.0/16 mit einem AS-Pfad, der mit 65002 beginnt
  • 10.4.0.0/16 mit einem AS-Pfad, der mit 65003 beginnt

Indem Sie dafür sorgen, dass jedes Präfix nur von einem einzigen Spoke angeboten wird und dass alle Peers innerhalb einer Spoke dieselbe ASN haben, wird diese Mehrdeutigkeit vermieden.

Routen-Advertising

  • Wenn es ein doppeltes Route Advertisement von mehreren Spokes für Subnetze mit derselben Priorität gibt, verwendet Cloud Router ECMP, um Traffic auf alle folgenden Hops zu verteilen. In diesem Fall empfangen Interconnect-Verbindungen mehr Traffic als Cloud VPN-Verbindungen, die mehr Traffic empfangen als VMs, die als Router-Appliance-Instanzen fungieren.
  • Bekanntes Problem: Wenn es doppelte Route Advertisements aus Ressourcen in den beteiligten Spokes gibt, z. B. HA VPN-Tunnel, und von ähnlichen Ressourcen außerhalb der Spokes, verwendet der Traffic in den entsprechenden Spokes möglicherweise ECMP für alle folgenden Hops. Das ist auch dann der Fall, wenn es sich bei den nächsten Hops nicht um beteiligte Hubs oder Spokes handelt. Dieses Verhalten wird in einer zukünftigen Version des Network Connectivity Centers behoben.
  • Ein Beispiel für die Konfiguration von Routen-Advertisements, wenn eine Ihrer redundanten Interconnect-Verbindungen zu einem nicht unterstützten Standort führt, inden Sie unter Optimales Route Advertisement für das Network Connectivity Center.

BGP-Sitzungen

  • BGP-Sitzungen für HA VPN-Tunnel bieten identische IP-Adressbereiche an.
  • Ein BGP-Attribut wird so unterstützt:
    • Die Übertragung des AS-Pfads und des MED zu Hybridanhängen wird unterstützt.
    • BGP-Communities werden nicht unterstützt.

Nächste Schritte