Dieses Dokument enthält eine Referenzarchitektur, mit der Sie eine Netzwerktopologie für ein cloudübergreifendes Netzwerk zwischen VPCs in Google Cloudbereitstellen können. Dieses Netzwerkdesign ermöglicht die Bereitstellung von Softwarediensten in Google Cloud und über externe Netzwerke hinweg, z. B. in lokalen Rechenzentren oder bei anderen Cloud-Dienstanbietern (Cloud Service Providers, CSPs).
Dieses Dokument richtet sich an Netzwerkadministratoren, Cloud-Architekten und Unternehmensarchitekten, die die Netzwerkkonnektivität aufbauen. Dazu gehören auch Cloud-Architekten, die die Bereitstellung von Arbeitslasten planen. In diesem Dokument werden Grundkenntnisse zu Routing und Internetverbindung vorausgesetzt.
Dieses Design unterstützt mehrere externe Verbindungen, mehrere VPC-Netzwerke (Virtual Private Cloud) mit Dienstzugriff, die Dienste und Dienstzugangspunkte enthalten, sowie mehrere VPC-Netzwerke für Arbeitslasten.
In diesem Dokument bezieht sich der Begriff Dienstzugriffspunkte auf Zugriffspunkte auf Dienste, die mithilfe von Google Cloud privatem Dienstzugriff und Private Service Connect verfügbar gemacht werden. Network Connectivity Center ist ein Hub-and-Spoke-Steuerungsebenenmodell für die Verwaltung der Netzwerkverbindung inGoogle Cloud. Die Hub-Ressource bietet eine zentrale Konnektivitätsverwaltung für VPC-Spokes des Network Connectivity Centers.
Der Network Connectivity Center-Hub ist eine globale Steuerebene, die Routen zwischen den verschiedenen Spoke-Typen lernt und verteilt, die mit ihm verbunden sind. VPC-Spokes fügen in der Regel Subnetzrouten in die zentrale Hub-Routingtabelle ein. Hybrid-Spokes fügen in der Regel dynamische Routen in die zentrale Hub-Routingtabelle ein. Anhand der Informationen der Kontrollebene des Network Connectivity Center-Hubs Google Cloudwird automatisch eine Datenebenenverbindung zwischen den Network Connectivity Center-Spokes hergestellt.
Network Connectivity Center ist der empfohlene Ansatz, um VPCs für skalierbares Wachstum auf Google Cloudzu verbinden. Wenn Netzwerk-VM-Appliances in den Traffic-Pfad eingefügt werden müssen, verwenden Sie statische oder richtlinienbasierte Routen zusammen mit VPC-Netzwerk-Peering, um VPCs zu verbinden. Weitere Informationen finden Sie unter VPC-Netzwerk-Peering – Inter-VPC-Verbindungen zwischen Cloud-Netzwerken.
Architektur
Das folgende Diagramm zeigt einen allgemeinen Überblick über die Architektur der Netzwerke und die verschiedenen Paketflüsse, die diese Architektur unterstützt.
Die Architektur umfasst die folgenden allgemeinen Elemente:
Komponente | Zweck | Interaktionen |
---|---|---|
Externe Netzwerke (lokale oder andere CSP-Netzwerke) | Hier werden die Clients der Arbeitslasten gehostet, die in den Arbeitslast-VPCs und in den VPCs für den Dienstzugriff ausgeführt werden. Externe Netzwerke können auch Dienste hosten. | Er tauscht Daten über das Transitnetzwerk mit den VPC-Netzwerken von Google Cloudaus. Stellt über Cloud Interconnect oder HA VPN eine Verbindung zum Transitnetzwerk her. Beendet ein Ende der folgenden Verbindungen:
|
Transit-VPC-Netzwerk (auch als Routing-VPC-Netzwerk im Network Connectivity Center bezeichnet) | Die VPC dient als Hub für das externe Netzwerk, das VPC-Netzwerk für den Dienstzugriff und die VPC-Netzwerke für die Arbeitslast. | Verbindet das externe Netzwerk, das VPC-Netzwerk für den Dienstzugriff, das Private Service Connect-Nutzernetzwerk und die VPC-Netzwerke der Arbeitslast über eine Kombination aus Cloud Interconnect, HA VPN und Network Connectivity Center. |
VPC-Netzwerk für den Zugriff auf Dienste | Bietet Zugriff auf Dienste, die von Arbeitslasten benötigt werden, die in den VPC-Netzwerken der Arbeitslast oder in externen Netzwerken ausgeführt werden. Bietet auch Zugriffspunkte auf verwaltete Dienste, die in anderen Netzwerken gehostet werden. | Er tauscht Daten über das Transitnetzwerk mit den externen, Arbeitslast- und Private Service Connect-Nutzernetzwerken aus. Verbindet sich über HA VPN mit der Transit-VPC. Durch das transitive Routing von HA VPN kann externer Traffic über das VPC-Netzwerk für den Dienstzugriff VPCs für verwaltete Dienste erreichen. Beendet ein Ende der folgenden Verbindungen:
|
VPC-Netzwerk für verwaltete Dienste | Hostet verwaltete Dienste, die von Clients in anderen Netzwerken benötigt werden. | Er tauscht Daten mit den externen Netzwerken, dem Dienstzugriff, dem Private Service Connect-Nutzer und den Arbeitslastnetzwerken aus. Stellt über den Zugriff auf private Dienste, der VPC-Netzwerk-Peering verwendet, eine Verbindung zum VPC-Netzwerk für den Dienstzugriff her. Die VPC für verwaltete Dienste kann auch über Private Service Connect oder den Zugriff auf private Dienste eine Verbindung zur VPC des Private Service Connect-Nutzers herstellen. Beendet ein Ende von Verbindungen aus allen anderen Netzwerken. |
Private Service Connect-Nutzer-VPC | Hostet Private Service Connect-Endpunkte, auf die über andere Netzwerke zugegriffen werden kann. Diese VPC kann auch eine Arbeitslast-VPC sein. | Er tauscht Daten über das Transit-VPC-Netzwerk mit den externen VPC-Netzwerken und den VPC-Netzwerken für den Dienstzugriff aus. Verbindet sich über Network Connectivity Center VPC-Spokes mit dem Transitnetzwerk und anderen VPC-Netzwerken für Arbeitslasten. |
VPC-Netzwerke für Arbeitslasten | Hostet Arbeitslasten, die von Clients in anderen Netzwerken benötigt werden. Diese Architektur ermöglicht mehrere VPC-Netzwerke für Arbeitslasten. | Er tauscht Daten über das Transit-VPC-Netzwerk mit den externen VPC-Netzwerken und den VPC-Netzwerken für den Dienstzugriff aus. Stellt über VPC-Spokes in Network Connectivity Center eine Verbindung zum Transitnetzwerk, zu Private Service Connect-Nutzernetzwerken und zu anderen VPC-Netzwerken für Arbeitslasten her. Beendet ein Ende der folgenden Verbindungen:
|
Network Connectivity Center | Der Network Connectivity Center-Hub enthält eine globale Routing-Datenbank, die als Netzwerk-Kontrollebene für VPC-Subnetz- und Hybridverbindungsrouten in allen Google Cloud Regionen dient. | Verbindet mehrere VPC- und Hybridnetzwerke in einer beliebigen Topologie, indem ein Datenpfad mit der Routingtabelle der Kontrollebene erstellt wird. |
Das folgende Diagramm zeigt eine detaillierte Ansicht der Architektur mit den vier Verbindungen zwischen den Komponenten:
Beschreibungen von Verbindungen
In diesem Abschnitt werden die vier Verbindungen beschrieben, die im vorherigen Diagramm dargestellt sind. In der Network Connectivity Center-Dokumentation wird das Transit-VPC-Netzwerk als Routing-VPC bezeichnet. Diese Netzwerke haben zwar unterschiedliche Namen, dienen aber demselben Zweck.
Verbindung 1: Zwischen externen Netzwerken und den Transit-VPC-Netzwerken
Diese Verbindung zwischen den externen Netzwerken und den Transit-VPC-Netzwerken erfolgt über Cloud Interconnect oder HA VPN. Die Routen werden mit BGP zwischen den Cloud Routern im Transit-VPC-Netzwerk und zwischen den externen Routern im externen Netzwerk ausgetauscht.
- Die Router in den externen Netzwerken geben die Routen für die externen Subnetze an die Transit-VPC-Cloud Router weiter. Externe Router an einem bestimmten Standort geben Routen von diesem Standort aus in der Regel als bevorzugter an als Routen für andere externe Standorte. Die Präferenz der Routen kann mithilfe von BGP-Messwerten und ‑Attributen ausgedrückt werden.
- Cloud Router im Transit-VPC-Netzwerk kündigen Routen für Präfixe in den VPCs von Google Cloudan die externen Netzwerke an. Diese Routen müssen mit benutzerdefinierten Cloud Router-Routen angekündigt werden.
- Mit dem Network Connectivity Center können Sie Daten über das Google-Backbonenetzwerk zwischen verschiedenen lokalen Netzwerken übertragen. Wenn Sie die Interconnect-VLAN-Anhänge als Network Connectivity Center-Hybrid-Spokes konfigurieren, müssen Sie die Site-to-Site-Datenübertragung aktivieren.
- Cloud Interconnect-VLAN-Anhänge, die dieselben externen Netzwerkpräfixe verwenden, werden als einzelner Network Connectivity Center-Spoke konfiguriert.
Verbindung 2: Zwischen VPC-Netzwerken für den Durchlauf und VPC-Netzwerken für den Dienstzugriff
Diese Verbindung zwischen Transit-VPC-Netzwerken und VPC-Netzwerken für den Dienstzugriff erfolgt über HA VPN mit separaten Tunneln für jede Region. Routen werden mit BGP zwischen den regionalen Cloud-Routern in den Transit-VPC-Netzwerken und in den VPC-Netzwerken für den Dienstzugriff ausgetauscht.
- HA VPN-Cloud Router für Transit-VPCs geben Routen für externe Netzwerkpräfixe, Arbeitslast-VPCs und andere VPCs mit Dienstzugriff an den Cloud Router der VPC mit Dienstzugriff weiter. Diese Routen müssen mit benutzerdefinierten Cloud Router-Routen angekündigt werden.
- Das VPC für den Dienstzugriff kündigt seine Subnetze und die Subnetze aller angehängten VPC-Netzwerke für verwaltete Dienste an das Transit-VPC-Netzwerk an. VPC-Routen für verwaltete Dienste und die VPC-Subnetzrouten für den Dienstzugriff müssen mit benutzerdefinierten Cloud Router-Routen-Anzeigen angekündigt werden.
Verbindung 3: Zwischen dem Transit-VPC-Netzwerk, den Arbeitslast-VPC-Netzwerken und den VPC-Netzwerken für den Zugriff auf Private Service Connect-Dienste
Die Verbindung zwischen dem Transit-VPC-Netzwerk, den Arbeitslast-VPC-Netzwerken und den VPC-Netzwerken von Private Service Connect-Nutzern wird hergestellt, wenn Subnetze und Präfixrouten über Network Connectivity Center ausgetauscht werden. Diese Verbindung ermöglicht die Kommunikation zwischen den VPC-Netzwerken der Arbeitslast, VPC-Netzwerken für den Dienstzugriff, die als VPC-Spokes von Network Connectivity Center verbunden sind, und anderen Netzwerken, die als hybride Spokes von Network Connectivity Center verbunden sind. Zu diesen anderen Netzwerken gehören die externen Netzwerke und die VPC-Netzwerke für den Dienstzugriff, die jeweils Verbindung 1 und Verbindung 2 verwenden.
- Die Cloud Interconnect- oder HA VPN-Anhänge im Transit-VPC-Netzwerk verwenden das Network Connectivity Center, um dynamische Routen in die VPC-Netzwerke der Arbeitslast zu exportieren.
- Wenn Sie das Arbeitslast-VPC-Netzwerk als Spoke des Network Connectivity Center-Hubs konfigurieren, exportiert das Arbeitslast-VPC-Netzwerk seine Subnetze automatisch in das Transit-VPC-Netzwerk. Optional können Sie das Transit-VPC-Netzwerk als VPC-Spoke einrichten. Es werden keine statischen Routen aus dem VPC-Netzwerk der Arbeitslast in das Transit-VPC-Netzwerk exportiert. Es werden keine statischen Routen aus dem Transit-VPC-Netzwerk in das Arbeitslast-VPC-Netzwerk exportiert.
Verbindung 4: Private Service Connect-Nutzer-VPC mit Network Connectivity Center-Weiterleitung
- Private Service Connect-Endpunkte sind in einer gemeinsamen VPC organisiert, die Nutzern Zugriff auf eigene und von Drittanbietern verwaltete Dienste ermöglicht.
- Das VPC-Netzwerk des Private Service Connect-Nutzers ist als VPC-Spoke des Network Connectivity Center konfiguriert. Dieser Spoke ermöglicht die Private Service Connect-Weitergabe am Network Connectivity Center-Hub. Bei der Private Service Connect-Weitergabe wird das Hostpräfix des Private Service Connect-Endpunkts als Route in der Hub-Routingtabelle des Network Connectivity Centers angekündigt.
- Nutzer-VPC-Netzwerke mit Zugriff auf Private Service Connect-Dienste sind mit Arbeitslast-VPC-Netzwerken und Transit-VPC-Netzwerken verbunden. Diese Verbindungen ermöglichen eine transitive Konnektivität zu Private Service Connect-Endpunkten. Für den Network Connectivity Center-Hub muss die Private Service Connect-Verbindungsweitergabe aktiviert sein.
- Das Network Connectivity Center erstellt automatisch einen Datenpfad von allen Spokes zum Private Service Connect-Endpunkt.
Trafficabläufe
Das folgende Diagramm zeigt die Abläufe, die durch diese Referenzarchitektur aktiviert werden.
In der folgenden Tabelle werden die Abläufe im Diagramm beschrieben:
Quelle | Ziel | Beschreibung |
---|---|---|
Externes Netzwerk | VPC-Netzwerk für den Zugriff auf Dienste |
|
VPC-Netzwerk für den Zugriff auf Dienste | Externes Netzwerk |
|
Externes Netzwerk | Arbeitslast-VPC-Netzwerk oder Private Service Connect-Nutzer-VPC-Netzwerk |
|
Arbeitslast-VPC-Netzwerk oder Private Service Connect-Nutzer-VPC-Netzwerk | Externes Netzwerk |
|
VPC-Netzwerk der Arbeitslast | VPC-Netzwerk für den Zugriff auf Dienste |
|
VPC-Netzwerk für den Zugriff auf Dienste | VPC-Netzwerk der Arbeitslast |
|
VPC-Netzwerk der Arbeitslast | VPC-Netzwerk der Arbeitslast | Traffic, der eine Arbeitslast-VPC verlässt, folgt der spezifischeren Route über das Network Connectivity Center zur anderen Arbeitslast-VPC. Bei Rücktraffic wird dieser Pfad umgekehrt. |
Verwendete Produkte
- Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPCs.
- Network Connectivity Center: Ein Orchestrierungs-Framework, das Netzwerkverbindungen zwischen Spoke-Ressourcen vereinfacht, die mit einer zentralen Verwaltungsressource verbunden sind, die als Hub bezeichnet wird.
- Cloud Interconnect: Ein Dienst, mit dem Ihr externes Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk erweitert wird.
- Cloud VPN: Ein Dienst, mit dem Sie Ihr Peer-Netzwerk über einen IPsec-VPN-Tunnel sicher auf das Google-Netzwerk ausdehnen können.
- Cloud Router: Ein verteiltes und vollständig verwaltetes Angebot, das BGP-Funktionen (Border Gateway Protocol) für Sprecher und Antworter bietet. Cloud Router arbeitet mit Cloud Interconnect, Cloud VPN und Router-Appliances zusammen, um dynamische Routen in VPC-Netzwerken anhand von BGP-empfangenen und benutzerdefinierten ermittelten Routen zu erstellen.
Designaspekte
In diesem Abschnitt werden Designfaktoren, Best Practices und Designempfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit und Leistung entspricht.
Sicherheit und Compliance
In der folgenden Liste werden die Sicherheits- und Compliance-Aspekte für diese Referenzarchitektur beschrieben:
- Aus Compliance-Gründen möchten Sie Arbeitslasten möglicherweise nur in einer einzigen Region bereitstellen. Wenn Sie den gesamten Traffic in einer einzelnen Region halten möchten, können Sie eine Topologie mit 99,9% verwenden.
- Verwenden Sie die Cloud Next Generation Firewall (Cloud NGFW), um den Traffic zu sichern, der in die VPC-Netzwerke für den Dienstzugriff und die Arbeitslast ein- und austritt. Um Traffic zu prüfen, der zwischen Hybridnetzwerken durch das Transitnetzwerk fließt, müssen Sie externe Firewalls oder NVA-Firewalls verwenden.
- Aktivieren Sie Konnektivitätstests, um sicherzustellen, dass sich der Traffic wie erwartet verhält.
- Aktivieren Sie Logging und Monitoring entsprechend Ihren Anforderungen an Traffic und Compliance. Wenn Sie Einblicke in Ihre Traffic-Muster gewinnen möchten, verwenden Sie VPC-Flusslogs zusammen mit dem Flussanalysator.
- Verwenden Sie Cloud IDS, um zusätzliche Informationen zu Ihrem Traffic zu erhalten.
Zuverlässigkeit
In der folgenden Liste werden die Zuverlässigkeitsaspekte für diese Referenzarchitektur beschrieben:
- Um eine Verfügbarkeit von 99,99% für Cloud Interconnect zu erreichen, müssen Sie eine Verbindung zu zwei verschiedenen Google Cloud Regionen aus verschiedenen Metropolregionen über zwei verschiedene Zonen herstellen.
- Sie können Arbeitslasten und andere Cloud-Ressourcen auf Regionen verteilen, um die Zuverlässigkeit zu verbessern und das Risiko regionaler Ausfälle zu minimieren.
- Erstellen Sie eine ausreichende Anzahl von VPN-Tunneln, um den erwarteten Traffic zu verarbeiten. Für einzelne VPN-Tunnel gelten Bandbreitenlimits.
Leistungsoptimierung
In der folgenden Liste werden die Leistungsaspekte für diese Referenzarchitektur beschrieben:
- Möglicherweise lässt sich die Netzwerkleistung verbessern, indem Sie die maximale Übertragungseinheit (MTU) Ihrer Netzwerke und Verbindungen erhöhen. Weitere Informationen finden Sie unter Maximale Übertragungseinheit.
- Die Kommunikation zwischen dem Transit-VPC und den Arbeitslastressourcen erfolgt über eine Network Connectivity Center-Verbindung. Diese Verbindung bietet ohne zusätzliche Kosten einen Durchsatz in voller Leitungsrate für alle VMs im Netzwerk. Sie haben mehrere Möglichkeiten, Ihr externes Netzwerk mit dem Transitnetzwerk zu verbinden. Weitere Informationen dazu, wie Sie Kosten und Leistung in Einklang bringen, finden Sie unter Netzwerkverbindungsprodukt auswählen.
Bereitstellung
In diesem Abschnitt wird beschrieben, wie Sie die Cloud-übergreifende Netzwerkverbindung zwischen VPCs mithilfe der in diesem Dokument beschriebenen Network Connectivity Center-Architektur bereitstellen.
Mit der Architektur in diesem Dokument werden drei Arten von Verbindungen zu einem zentralen Transit-VPC sowie eine Verbindung zwischen VPC-Netzwerken für Arbeitslasten und VPC-Netzwerken für Arbeitslasten erstellt. Nachdem das Network Connectivity Center vollständig konfiguriert ist, stellt es die Kommunikation zwischen allen Netzwerken her.
Bei dieser Bereitstellung wird davon ausgegangen, dass Sie Verbindungen zwischen den externen und Transitnetzwerken in zwei Regionen erstellen. Arbeitslast-Subnetze können sich jedoch auch in anderen Regionen befinden. Wenn Arbeitslasten nur in einer Region bereitgestellt werden, müssen Subnetze nur in dieser Region erstellt werden.
Führen Sie die folgenden Aufgaben aus, um diese Referenzarchitektur bereitzustellen:
- Netzwerksegmentierung mit Network Connectivity Center erstellen
- Regionen für die Bereitstellung von Konnektivität und Arbeitslasten identifizieren
- VPC-Netzwerke und Subnetze erstellen
- Verbindungen zwischen externen Netzwerken und Ihrem Transit-VPC-Netzwerk erstellen
- Verbindungen zwischen Ihrem Transit-VPC-Netzwerk und VPC-Netzwerken für den Dienstzugriff erstellen
- Verbindung zwischen dem Transit-VPC-Netzwerk und den Arbeitslast-VPC-Netzwerken herstellen
- Konnektivität zu Arbeitslasten testen
Netzwerksegmentierung mit dem Network Connectivity Center erstellen
Bevor Sie zum ersten Mal einen Network Connectivity Center-Hub erstellen, müssen Sie entscheiden, ob Sie eine Full-Mesh- oder eine Star-Topologie verwenden möchten. Die Entscheidung für eine vollständige Mesh-Topologie aus miteinander verbundenen VPCs oder eine Sterntopologie aus VPCs ist nicht umkehrbar. Beachten Sie bei dieser irreversiblen Entscheidung die folgenden allgemeinen Richtlinien:
- Wenn die Geschäftsarchitektur Ihrer Organisation Traffic zwischen Ihren VPC-Netzwerken zulässt, verwenden Sie das Network Connectivity Center-Mesh.
- Wenn Trafficflüsse zwischen bestimmten VPC-Spokes nicht zulässig sind, diese VPC-Spokes aber mit einer Kerngruppe von VPC-Spokes verbunden werden können, verwenden Sie eine Network Connectivity Center-Sterntopologie.
Regionen für Konnektivität und Arbeitslasten identifizieren
Im Allgemeinen sollten Sie die Konnektivität und die Google Cloud Arbeitslasten in der Nähe Ihrer lokalen Netzwerke oder anderer Cloud-Clients platzieren. Weitere Informationen zum Platzieren von Arbeitslasten finden Sie unter Google Cloud Regionauswahl und Best Practices für die Auswahl der Compute Engine-Regionen.
VPC-Netzwerke und Subnetze erstellen
Führen Sie die folgenden Schritte aus, um Ihre VPC-Netzwerke und Subnetze zu erstellen:
Erstellen oder identifizieren Sie die Projekte, in denen Sie Ihre VPC-Netzwerke erstellen möchten. Weitere Informationen finden Sie unter Netzwerksegmentierung und Projektstruktur. Wenn Sie freigegebene VPC-Netzwerke verwenden möchten, bereiten Sie Ihre Projekte als freigegebene VPC-Hostprojekte vor.
Planen Sie die IP‑Adresszuweisungen für Ihre Netzwerke. Sie können Ihre Bereiche vorab zuweisen und reservieren, indem Sie interne Bereiche erstellen. So lassen sich die spätere Konfiguration und der Betrieb vereinfachen.
Erstellen Sie ein VPC-Netzwerk für ein Transitnetzwerk mit aktiviertem globalem Routing.
Erstellen Sie VPC-Netzwerke für den Dienstzugriff. Wenn Sie Workloads in mehreren Regionen haben möchten, aktivieren Sie das globale Routing.
VPC-Netzwerke für Arbeitslasten erstellen Wenn Sie Arbeitslasten in mehreren Regionen haben, aktivieren Sie das globale Routing.
Verbindungen zwischen externen Netzwerken und Ihrem Transit-VPC-Netzwerk erstellen
In diesem Abschnitt wird davon ausgegangen, dass eine Verbindung in zwei Regionen besteht und dass die externen Standorte miteinander verbunden sind und auf die jeweils andere Region umschalten können. Außerdem wird davon ausgegangen, dass Clients an einem externen Standort bevorzugt Dienste in der Region erreichen möchten, in der sich der externe Standort befindet.
- Richten Sie die Verbindung zwischen externen Netzwerken und Ihrem Transitnetzwerk ein. Weitere Informationen finden Sie unter Externe und Hybridkonnektivität. Informationen zur Auswahl eines Verbindungsprodukts finden Sie unter Netzwerkverbindungsprodukt auswählen.
Konfigurieren Sie BGP in jeder verbundenen Region so:
- Konfigurieren Sie den Router am angegebenen externen Standort so:
- Geben Sie alle Subnetze für diesen externen Standort mit derselben BGP-MED auf beiden Schnittstellen an, z. B. 100. Wenn beide Schnittstellen dieselbe MED angeben, kann Google Cloud ECMP verwendet werden, um den Traffic über beide Verbindungen zu verteilen.
- Geben Sie alle Subnetze vom anderen externen Standort an, indem Sie eine MED mit niedrigerer Priorität als die der ersten Region verwenden, z. B. 200. Ankündigen Sie dieselbe MED von beiden Schnittstellen.
- Konfigurieren Sie den extern ausgerichteten Cloud Router im Transit-VPC der verbundenen Region so:
- Weisen Sie Ihrem Cloud Router eine private ASN zu.
- Verwenden Sie benutzerdefinierte Route Advertisements, um alle Subnetzbereiche aus allen Regionen über beide Cloud Router-Schnittstellen anzukündigen, die nach außen gerichtet sind. Fassen Sie sie nach Möglichkeit zusammen. Verwenden Sie dieselbe MED auf beiden Schnittstellen, z. B. 100.
- Konfigurieren Sie den Router am angegebenen externen Standort so:
Wenn Sie mit dem Network Connectivity Center-Hub und Hybrid-Spokes arbeiten, verwenden Sie die Standardparameter.
- Erstellen Sie einen Network Connectivity Center-Hub. Wenn Ihre Organisation den Traffic zwischen allen Ihren VPC-Netzwerken zulässt, verwenden Sie die Standardkonfiguration für Full-Mesh.
- Wenn Sie Partner Interconnect, Dedicated Interconnect, HA-VPN oder eine Router-Appliance verwenden, um On-Premises-Präfixe zu erreichen, konfigurieren Sie diese Komponenten als verschiedene Hybrid-Spokes des Network Connectivity Centers.
- Wenn Sie die Subnetze der Hub-Routingtabelle des Network Connectivity Center für Remote-BGP-Nachbarn ankündigen möchten, legen Sie einen Filter fest, der alle IPv4-Adressbereiche umfasst.
- Wenn die hybride Konnektivität an einem Cloud-Router in einer Region endet, die die Datenübertragung unterstützt, konfigurieren Sie den Hybrid-Spoke mit aktivierter Site-to-Site-Datenübertragung. So wird die Site-to-Site-Datenübertragung über das Backbone-Netzwerk von Google unterstützt.
Verbindungen zwischen Ihrem Transit-VPC-Netzwerk und VPC-Netzwerken für den Dienstzugriff erstellen
Um ein transitives Routing zwischen externen Netzwerken und der VPC für den Dienstzugriff sowie zwischen Arbeitslast-VPCs und der VPC für den Dienstzugriff bereitzustellen, verwendet die VPC für den Dienstzugriff HA VPN für die Konnektivität.
- Schätzen Sie ab, wie viel Traffic zwischen den Transit- und Servicezugriffs-VPCs in jeder Region übertragen werden muss. Skalieren Sie die erwartete Anzahl der Tunnel entsprechend.
Konfigurieren Sie HA VPN zwischen dem Transit-VPC-Netzwerk und dem VPC-Netzwerk für den Dienstzugriff in Region A. Folgen Sie dazu der Anleitung unter HA VPN-Gateways zum Verbinden von VPC-Netzwerken erstellen. Erstellen Sie einen speziellen HA VPN-Cloud Router im Transit-VPC-Netzwerk. Lassen Sie den Router, der zum externen Netzwerk ausgerichtet ist, für externe Netzwerkverbindungen.
- Cloud Router-Konfiguration für Transit-VPC:
- Verwenden Sie benutzerdefinierte Route Advertisements auf dem Cloud Router im Transit-VPC, um VPC-Subnetze für externes Netzwerk und Arbeitslast für das VPC mit Dienstzugriff anzukündigen.
- VPC-Cloud Router-Konfiguration für den Dienstzugriff:
- Verwenden Sie benutzerdefinierte Route Advertisements auf dem Cloud Router des VPC-Netzwerks für den Dienstzugriff, um VPC-Netzwerksubnetze für den Dienstzugriff im Transit-VPC anzukündigen.
- Wenn Sie den Zugriff auf private Dienste verwenden, um ein VPC-Netzwerk für verwaltete Dienste mit dem VPC für den Dienstzugriff zu verbinden, müssen Sie auch diese Subnetze mit benutzerdefinierten Routen ankündigen.
- Konfigurieren Sie das Tunnelpaar auf der Transit-VPC-Seite des HA VPN-Tunnels als Network Connectivity Center-Hybrid-Spoke:
- Wenn Sie die interregionale Datenübertragung unterstützen möchten, konfigurieren Sie den Hybrid-Spoke mit aktivierter Site-to-Site-Datenübertragung.
- Wenn Sie die Subnetze der Hub-Routentabelle des Network Connectivity Center an entfernte BGP-Nachbarn ansagen möchten, legen Sie einen Filter fest, der alle IPv4-Adressbereiche umfasst. Bei dieser Aktion werden alle IPv4-Subnetzrouten an den Nachbarn angekündigt.
- Wenn Sie dynamische Routen installieren möchten, wenn die Kapazität auf dem externen Router begrenzt ist, konfigurieren Sie den Cloud Router so, dass er eine Zusammenfassungsroute mit einem benutzerdefinierten Routen-Advertising ankündigt. Verwenden Sie diesen Ansatz, anstatt die vollständige Routentabelle des Network Connectivity Center-Hubs anzukündigen.
- Cloud Router-Konfiguration für Transit-VPC:
Wenn Sie eine VPC für verwaltete Dienste über den Zugriff auf private Dienste mit der VPC für den Dienstezugriff verbinden, nachdem die VPC-Netzwerk-Peering-Verbindung hergestellt wurde, müssen Sie auch die VPC-Seite für den Dienstezugriff der VPC-Netzwerk-Peering-Verbindung aktualisieren, um benutzerdefinierte Routen zu exportieren.
Verbindung zwischen Ihrem Transit-VPC-Netzwerk und Arbeitslast-VPC-Netzwerken herstellen
Verwenden Sie Network Connectivity Center mit VPC-Spokes, um eine Inter-VPC-Konnektivität im großen Maßstab herzustellen. Network Connectivity Center unterstützt zwei verschiedene Arten von Datenebenenmodellen: das Full-Mesh-Datenebenenmodell oder das Datenebenenmodell mit Sterntopologie.
- Wenn alle Ihre Netzwerke miteinander kommunizieren dürfen, erstellen Sie eine Full-Mesh-Konnektivität.
- Wenn Ihre Geschäftsarchitektur eine Punkt-zu-Mehrpunkt-Topologie erfordert, erstellen Sie eine Sterntopologie-Verbindung.
Full-Mesh-Konnektivität herstellen
Die VPC-Spokes des Network Connectivity Center umfassen die Transit-VPCs, die Nutzer-VPCs von Private Service Connect und alle Arbeitslast-VPCs.
- Network Connectivity Center erstellt zwar ein vollständig vermaschtes Netzwerk aus VPC-Spokes, aber die Netzwerkbetreiber müssen mithilfe von Firewallregeln oder Firewallrichtlinien Trafficflüsse zwischen den Quellnetzwerken und den Zielnetzwerken zulassen.
- Konfigurieren Sie alle Arbeitslast-, Transit- und Private Service Connect-Nutzer-VPCs als Network Connectivity Center-VPC-Spokes. Es dürfen keine Subnetzüberschneidungen zwischen VPC-Spokes geben.
- Wenn Sie den VPC-Spoke konfigurieren, geben Sie nicht überlappende IP-Adresssubnetzbereiche in der Network Connectivity Center-Hub-Routentabelle an:
- Export-Subnetzbereiche einschließen.
- Export-Subnetzbereiche ausschließen.
- Wenn Sie den VPC-Spoke konfigurieren, geben Sie nicht überlappende IP-Adresssubnetzbereiche in der Network Connectivity Center-Hub-Routentabelle an:
- Wenn sich VPC-Spokes in verschiedenen Projekten befinden und von anderen Administratoren als den Network Connectivity Center-Hub-Administratoren verwaltet werden, müssen die VPC-Spoke-Administratoren einen Antrag auf Beitritt zum Network Connectivity Center-Hub in den anderen Projekten stellen.
- Verwenden Sie IAM-Berechtigungen (Identity and Access Management) im Network Connectivity Center-Hubprojekt, um diesem Nutzer die Rolle
roles/networkconnectivity.groupUser
zu gewähren.
- Verwenden Sie IAM-Berechtigungen (Identity and Access Management) im Network Connectivity Center-Hubprojekt, um diesem Nutzer die Rolle
- Damit Private Service Connect-Verbindungen vorübergehend und global von anderen Network Connectivity Center-Spokes aus zugänglich sind, aktivieren Sie die Weiterleitung von Private Service Connect-Verbindungen am Network Connectivity Center-Hub.
Wenn eine vollständige Mesh-VPC-Kommunikation zwischen Arbeitslast-VPCs nicht zulässig ist, sollten Sie eine Network Connectivity Center-Sterntopologie verwenden.
Sterntopologie herstellen
Für zentralisierte Geschäftsarchitekturen, die eine Punkt-zu-Mehrpunkt-Topologie erfordern, kann eine Sterntopologie des Network Connectivity Centers verwendet werden.
Führen Sie die folgenden Aufgaben aus, um eine Sterntopologie für das Network Connectivity Center zu verwenden:
- Erstellen Sie im Network Connectivity Center einen Network Connectivity Center-Hub und geben Sie eine Sterntopologie an.
- Damit private Dienstverbindungen vorübergehend und global von anderen Network Connectivity Center-Spokes aus zugänglich sind, aktivieren Sie die Weiterleitung von Private Service Connect-Verbindungen am Network Connectivity Center-Hub.
- Wenn Sie den Network Connectivity Center-Hub für eine Sterntopologie konfigurieren, können Sie VPCs in einer von zwei vordefinierten Gruppen gruppieren: Center-Gruppen oder Edge-Gruppen.
Wenn Sie VPCs in der zentralen Gruppe gruppieren möchten, konfigurieren Sie die Transit-VPC und die VPCs von Private Service Connect-Nutzern als VPC-Spoke des Network Connectivity Center als Teil der zentralen Gruppe.
Das Network Connectivity Center erstellt ein vollständig meshiges Netzwerk zwischen VPC-Spokes, die in der zentralen Gruppe platziert sind.
Wenn Sie VPCs für Arbeitslasten in der Edge-Gruppe gruppieren möchten, konfigurieren Sie jedes dieser Netzwerke als Network Connectivity Center-Spokes innerhalb dieser Gruppe.
Das Network Connectivity Center erstellt einen Punkt-zu-Punkt-Datenpfad von jedem Network Connectivity Center-VPC-Spoke zu allen VPCs in der Center-Gruppe.
Verbindung zu Arbeitslasten testen
Wenn Sie Arbeitslasten haben, die bereits in Ihren VPC-Netzwerken bereitgestellt sind, testen Sie jetzt den Zugriff darauf. Wenn Sie die Netzwerke verbunden haben, bevor Sie Arbeitslasten bereitgestellt haben, können Sie die Arbeitslasten jetzt bereitstellen und testen.
Nächste Schritte
- Weitere Informationen zu den in dieser Designanleitung verwendeten Google Cloud Produkten:
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.
Beitragende
Autoren:
- Eric Yu | Networking Specialist Customer Engineer
- Deepak Michael | Networking Specialist Customer Engineer
- Victor Moreno | Product Manager, Cloud Networking
- Osvaldo Costa | Networking Specialist Customer Engineer
Weitere Beitragende:
- Mark Schlagenhauf | Technical Writer, Netzwerk
- Ammett Williams | Developer Relations Engineer
- Ghaleb Al-habian | Network Specialist
- Tony Sarathchandra | Senior Product Manager