Dieses Dokument enthält eine Referenzarchitektur, mit der Sie eine VPC-Netzwerktopologie für ein Cross-Cloud-Netzwerk in Google Cloudbereitstellen können. Dieses Netzwerkdesign ermöglicht die Bereitstellung von Softwarediensten in Google Cloud und externen Netzwerken, z. B. in lokalen Rechenzentren oder bei anderen Cloud-Dienstanbietern.
Dieses Dokument richtet sich an Netzwerkadministratoren, Cloud-Architekten und Unternehmensarchitekten, die die Netzwerkkonnektivität aufbauen. Dazu gehören auch Cloud-Architekten, die planen, wie Arbeitslasten bereitgestellt werden. In diesem Dokument wird davon ausgegangen, dass Sie über grundlegende Kenntnisse in den Bereichen Routing und Internetverbindung verfügen.
Dieses Design unterstützt mehrere externe Verbindungen, mehrere VPC-Netzwerke (Virtual Private Cloud) für den Dienstzugriff, die Dienste und Dienstzugriffspunkte enthalten, sowie mehrere VPC-Netzwerke für Arbeitslasten.
In diesem Dokument bezieht sich der Begriff Dienstzugriffspunkte auf Zugriffspunkte für Dienste, die über den privaten Dienstzugriff und Private Service Connect verfügbar gemacht werden. Google Cloud Das Network Connectivity Center ist ein Hub-and-Spoke-Modell für die Steuerungsebene zur Verwaltung der Netzwerkverbindung inGoogle Cloud. Die Hub-Ressource bietet eine zentrale Verwaltung der Verbindungen für VPC-Spokes des Network Connectivity Center.
Der Network Connectivity Center-Hub ist eine globale Steuerungsebene, die Routen zwischen den verschiedenen Spoke-Typen, die mit ihm verbunden sind, lernt und verteilt. VPC-Spokes fügen in der Regel Subnetzrouten in die zentrale Hub-Routingtabelle ein. Bei Hybrid-Spokes werden in der Regel dynamische Routen in die zentrale Hub-Routingtabelle eingefügt. Anhand der Informationen der Steuerungsebene des Network Connectivity Center-Hubs Google Cloudwird automatisch eine Verbindung der Datenebene zwischen Network Connectivity Center-Spokes hergestellt.
Network Connectivity Center ist der empfohlene Ansatz, um VPCs für skalierbares Wachstum auf Google Cloudmiteinander zu verbinden. Wenn Sie NVAs (Network Virtual Appliances) in den Trafficpfad einfügen müssen, können Sie die Router-Appliance-Funktion für dynamische Routen oder statische oder richtlinienbasierte Routen zusammen mit VPC-Netzwerk-Peering verwenden, um VPCs zu verbinden. Weitere Informationen finden Sie unter Cloud-übergreifende Netzwerkverbindungen zwischen VPCs mit VPC-Netzwerk-Peering.
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 (lokales Netzwerk oder Netzwerk eines anderen CSP) | Hier werden die Clients von Arbeitslasten gehostet, die in den Arbeitslast-VPCs und in den VPCs für den Dienstzugriff ausgeführt werden. Dienste können auch in externen Netzwerken gehostet werden. | Tauscht Daten mit den VPC-Netzwerken von Google Cloudüber das Transitnetzwerk aus. Stellt eine Verbindung zum Transitnetzwerk über Cloud Interconnect oder HA VPN her. Beendet ein Ende der folgenden Flows:
|
| Transit-VPC-Netzwerk (im Network Connectivity Center auch als Routing-VPC-Netzwerk bezeichnet) | Fungiert als Hub für das externe Netzwerk, das VPC-Netzwerk für den Dienstzugriff und die VPC-Netzwerke für Arbeitslasten. | Verbindet das externe Netzwerk, das VPC-Netzwerk für den Dienstzugriff, das Private Service Connect-Nutzer-Netzwerk und die VPC-Netzwerke für Arbeitslasten über eine Kombination aus Cloud Interconnect, HA VPN und Network Connectivity Center. |
| VPC-Netzwerk für den Dienstzugriff | 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 für verwaltete Dienste, die in anderen Netzwerken gehostet werden. | Tauscht Daten mit den externen, Workload- und Private Service Connect-Nutzernetzwerken über das Transitnetzwerk aus. Verbindung zur Transit-VPC über HA VPN. Das transitive Routing von HA VPN ermöglicht es, dass externer Traffic über das VPC-Netzwerk für den Dienstzugriff auf VPCs für verwaltete Dienste zugreifen kann. Beendet ein Ende der folgenden Flows:
|
| VPC-Netzwerk für verwaltete Dienste | Hostet verwaltete Dienste, die von Clients in anderen Netzwerken benötigt werden. | Tauscht Daten mit dem externen 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 Private Service Connect-VPC des Nutzers herstellen. Beendet ein Ende von Flows 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. | Tauscht Daten mit den externen und Dienstzugriffs-VPC-Netzwerken über das Transit-VPC-Netzwerk aus. Verbindet sich über Network Connectivity Center-VPC-Spokes mit dem Transitnetzwerk und anderen VPC-Netzwerken für Arbeitslasten. |
| Arbeitslast-VPC-Netzwerke | Hostet Arbeitslasten, die von Clients in anderen Netzwerken benötigt werden. Diese Architektur ermöglicht mehrere VPC-Netzwerke für Arbeitslasten. | Tauscht Daten mit den externen und Dienstzugriffs-VPC-Netzwerken über das Transit-VPC-Netzwerk aus. Verbindet sich über Network Connectivity Center-VPC-Spokes mit dem Transitnetzwerk, den Private Service Connect-Nutzernetzwerken und anderen VPC-Netzwerken für Arbeitslasten. Beendet ein Ende der folgenden Flows:
|
| Network Connectivity Center | Der Network Connectivity Center-Hub enthält eine globale Routing-Datenbank, die als Netzwerksteuerungsebene für Routen für VPC-Subnetze und Hybridverbindungen in allen Google Cloud Regionen dient. | Verbindet mehrere VPC- und Hybridnetzwerke in einer Any-to-Any-Topologie, indem ein Datenpfad erstellt wird, der die Routingtabelle der Steuerungsebene verwendet. |
Das folgende Diagramm zeigt eine detaillierte Ansicht der Architektur, in der die vier Verbindungen zwischen den Komponenten hervorgehoben sind:
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 über BGP zwischen den Cloud-Routern im Transit-VPC-Netzwerk und zwischen den externen Routern im externen Netzwerk ausgetauscht.
- Router in den externen Netzwerken kündigen die Routen für die externen Subnetze bei den Transit-VPC-Cloud-Routern an. Im Allgemeinen werden Routen von externen Routern an einem bestimmten Standort, die vom selben externen Standort stammen, gegenüber Routen für andere externe Standorte bevorzugt. 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 Cloudin den externen Netzwerken an. Diese Routen müssen mit benutzerdefinierten Route Advertisements von Cloud Router angekündigt werden.
- Mit dem Network Connectivity Center können Sie Daten zwischen verschiedenen lokalen Netzwerken über das Google-Backbonenetzwerk übertragen. Wenn Sie die Interconnect-VLAN-Anhänge als hybride Network Connectivity Center-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 Transit-VPC-Netzwerken 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 über BGP zwischen den regionalen Cloud-Routern in den Transit-VPC-Netzwerken und in den VPC-Netzwerken für den Dienstzugriff ausgetauscht.
- Transit-VPC HA VPN: Cloud Router kündigen Routen für externe Netzwerkpräfixe, Workload-VPCs und andere Dienstzugriffs-VPCs beim Cloud Router der Dienstzugriffs-VPC an. Diese Routen müssen mit benutzerdefinierten Route Advertisements von Cloud Router angekündigt werden.
- Die VPC für den Zugriff auf Dienste kündigt ihre Subnetze und die Subnetze aller angehängten VPC-Netzwerke für verwaltete Dienste im Transit-VPC-Netzwerk an. VPC-Routen für verwaltete Dienste und VPC-Subnetzrouten für den Dienstzugriff müssen mit benutzerdefinierten Route Advertisements von Cloud Router angekündigt werden.
Verbindung 3: Zwischen dem Transit-VPC-Netzwerk, den VPC-Netzwerken für Arbeitslasten und den VPC-Netzwerken für den Zugriff auf Private Service Connect-Dienste
Die Verbindung zwischen dem Transit-VPC-Netzwerk, den VPC-Netzwerken für Arbeitslasten und den VPC-Netzwerken für Private Service Connect-Nutzer erfolgt, wenn Subnetze und Präfixrouten über das Network Connectivity Center ausgetauscht werden. Diese Verbindung ermöglicht die Kommunikation zwischen den Arbeitslast-VPC-Netzwerken, den VPC-Netzwerken für den Dienstzugriff, die als Network Connectivity Center-VPC-Spokes verbunden sind, und anderen Netzwerken, die als Network Connectivity Center-Hybrid-Spokes 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 Network Connectivity Center, um dynamische Routen in die Workload-VPC-Netzwerke zu exportieren.
- Wenn Sie das Arbeitslast-VPC-Netzwerk als Spoke des Network Connectivity Center-Hubs konfigurieren, werden die Subnetze des Arbeitslast-VPC-Netzwerks automatisch in das Transit-VPC-Netzwerk exportiert. Optional können Sie das Transit-VPC-Netzwerk als VPC-Spoke einrichten. Es werden keine statischen Routen aus dem VPC-Netzwerk für Arbeitslasten in das Transit-VPC-Netzwerk exportiert. Es werden keine statischen Routen aus dem Transit-VPC-Netzwerk in das Workload-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 verwaltete Dienste von Google und Drittanbietern ermöglicht.
- Das Private Service Connect-VPC-Netzwerk des Nutzers ist als Network Connectivity Center-VPC-Spoke 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 Routingtabelle des Network Connectivity Center-Hubs angekündigt.
- Private Service Connect-VPC-Netzwerke für den Dienstzugriff von Nutzern werden mit VPC-Netzwerken für Arbeitslasten und mit Transit-VPC-Netzwerken verbunden. Diese Verbindungen ermöglichen eine transitive Verbindung zu Private Service Connect-Endpunkten. Im Network Connectivity Center-Hub muss die Weitergabe von Private Service Connect-Verbindungen 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 ermöglicht werden.
In der folgenden Tabelle werden die Abläufe im Diagramm beschrieben:
| Quelle | Ziel | Beschreibung |
|---|---|---|
| Externes Netzwerk | VPC-Netzwerk für den Dienstzugriff |
|
| VPC-Netzwerk für den Dienstzugriff | Externes Netzwerk |
|
| Externes Netzwerk | VPC-Netzwerk für Arbeitslasten oder VPC-Netzwerk für Private Service Connect-Nutzer |
|
| VPC-Netzwerk für Arbeitslasten oder VPC-Netzwerk für Private Service Connect-Nutzer | Externes Netzwerk |
|
| VPC-Netzwerk der Arbeitslast | VPC-Netzwerk für den Dienstzugriff |
|
| VPC-Netzwerk für den Dienstzugriff | VPC-Netzwerk der Arbeitslast |
|
| VPC-Netzwerk der Arbeitslast | VPC-Netzwerk der Arbeitslast | Traffic, der eine Arbeitslast-VPC verlässt, folgt der spezifischeren Route zur anderen Arbeitslast-VPC über Network Connectivity Center. Beim 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 VPC.
- 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-Speaker- und Responder-Funktionen (Border Gateway Protocol) bietet. Cloud Router funktioniert mit Cloud Interconnect, Cloud VPN und Router-Appliances, um dynamische Routen in VPC-Netzwerken basierend auf BGP-empfangenen und benutzerdefinierten erlernten Routen zu erstellen.
- Cloud Next Generation Firewall: Ein vollständig verteilter Firewalldienst mit erweiterten Schutzfunktionen, Mikrosegmentierung und vereinfachter Verwaltung, um Ihre Google Cloud Arbeitslasten vor internen und externen Angriffen zu schützen.
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 einzelnen Region bereitstellen. Wenn Sie den gesamten Traffic in einer einzelnen Region halten möchten, können Sie eine 99,9 %-Topologie verwenden.
- Verwenden Sie Cloud Next Generation Firewall (Cloud NGFW), um Traffic zu schützen, der in die VPC-Netzwerke für Dienstzugriff und Arbeitslasten ein- und ausgeht. Wenn Sie den Traffic untersuchen möchten, der über das Transitnetzwerk zwischen Hybridnetzwerken oder zwischen externen Netzwerken und von Google verwalteten Diensten übertragen wird, müssen Sie externe Firewalls oder NVA-Firewalls verwenden.
- Wenn Sie eine L7-Traffic-Prüfung benötigen, aktivieren Sie den Dienst zur Angriffsprävention und ‑erkennung (optional mit TLS-Prüfungsunterstützung), um schädliche Aktivitäten zu blockieren und Ihre Arbeitslasten vor Bedrohungen zu schützen. Dabei werden Sicherheitslücken, Anti-Spyware und Antivirus unterstützt. Der Dienst erstellt von Google verwaltete zonale Firewall-Endpunkte, die Technologie zum Abfangen von Paketen verwenden, um die Arbeitslasten transparent zu prüfen, ohne dass eine Umgestaltung der Routen erforderlich ist. Für Cloud Next Generation Firewall Enterprise fallen Gebühren für zonale Firewall-Endpunkte und Datenverarbeitung an.
- Wenn Sie Traffic basierend auf Google Threat Intelligence-Daten zulassen oder blockieren möchten, verwenden Sie Google Threat Intelligence. Es fallen Standardgebühren für die Datenverarbeitung der Cloud Firewall der nächsten Generation an.
- Aktivieren Sie das Logging von Firewallregeln und verwenden Sie Firewall Insights, um Ihre Firewallregeln zu prüfen, ihre Auswirkungen zu analysieren und sie zu optimieren. Das Logging von Firewallregeln kann Kosten verursachen. Daher können Sie sie selektiv verwenden.
- Aktivieren Sie Konnektivitätstests, um sicherzustellen, dass der Traffic wie erwartet weitergeleitet wird.
- Aktivieren Sie Logging und Monitoring entsprechend Ihrem Traffic und Ihren Complianceanforderungen. Um Einblicke in Ihre Traffic-Muster zu erhalten, verwenden Sie VPC-Flusslogs zusammen mit Flow Analyzer.
- Verwenden Sie Cloud IDS oder den Cloud NGFW Enterprise-Dienst zur Einbruchsprävention im Warnmodus, um zusätzliche Informationen zu Ihrem Traffic zu erhalten.
Zuverlässigkeit
In der folgenden Liste werden die Aspekte der Zuverlässigkeit 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.
- Um die Zuverlässigkeit zu verbessern und das Risiko regionaler Fehler zu minimieren, können Sie Arbeitslasten und andere Cloud-Ressourcen auf mehrere Regionen verteilen.
- Erstellen Sie eine ausreichende Anzahl von VPN-Tunneln, um den erwarteten Traffic zu bewältigen. Für einzelne VPN-Tunnel gelten Bandbreitenlimits.
Leistungsoptimierung
In der folgenden Liste werden die Leistungsaspekte für diese Referenzarchitektur beschrieben:
- Sie können die Netzwerkleistung möglicherweise verbessern, indem Sie die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) Ihrer Netzwerke und Verbindungen erhöhen. Weitere Informationen finden Sie unter Maximale Übertragungseinheit.
- Die Kommunikation zwischen der Transit-VPC und den Arbeitslastressourcen erfolgt über eine Network Connectivity Center-Verbindung. Diese Verbindung bietet einen Durchsatz mit voller Leitungsrate für alle VMs im Netzwerk ohne zusätzliche Kosten. Sie haben mehrere Möglichkeiten, Ihr externes Netzwerk mit dem Transitnetzwerk zu verbinden. Weitere Informationen dazu, wie Sie Kosten- und Leistungsaspekte abwägen können, finden Sie unter Netzwerkverbindungsprodukt auswählen.
Bereitstellung
In diesem Abschnitt wird beschrieben, wie Sie die VPC-übergreifende Konnektivität des Cross-Cloud Network mithilfe der in diesem Dokument beschriebenen Network Connectivity Center-Architektur bereitstellen.
Die Architektur in diesem Dokument erstellt drei Arten von Verbindungen zu einer zentralen Transit-VPC sowie eine Verbindung zwischen Arbeitslast-VPC-Netzwerken und Arbeitslast-VPC-Netzwerken. Nachdem das Network Connectivity Center vollständig konfiguriert ist, wird die Kommunikation zwischen allen Netzwerken hergestellt.
Bei dieser Bereitstellung wird davon ausgegangen, dass Sie Verbindungen zwischen dem externen Netzwerk und dem Transitnetzwerk in zwei Regionen erstellen. Arbeitslast-Subnetze können sich jedoch in anderen Regionen befinden. Wenn Arbeitslasten nur in einer Region platziert 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 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 Ihrem Transit-VPC-Netzwerk und den Arbeitslast-VPC-Netzwerken herstellen
- Cloud NGFW-Richtlinien konfigurieren
- Konnektivität zu Arbeitslasten testen
Netzwerksegmentierung mit Network Connectivity Center erstellen
Bevor Sie zum ersten Mal einen Network Connectivity Center-Hub erstellen, müssen Sie entscheiden, ob Sie eine Full Mesh-Topologie oder eine Star-Topologie verwenden möchten. Die Entscheidung für ein vollständiges Mesh aus miteinander verbundenen VPCs oder eine Stern-Topologie von VPCs ist irreversibel. Beachten Sie die folgenden allgemeinen Richtlinien, wenn Sie diese irreversible Entscheidung treffen:
- Wenn die Geschäftsarchitektur Ihrer Organisation Traffic zwischen allen Ihren VPC-Netzwerken zulässt, verwenden Sie das Network Connectivity Center-Mesh.
- Wenn der Traffic zwischen bestimmten verschiedenen VPC-Spokes nicht zulässig ist, 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 Verbindungen und 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 Region Picker und Best Practices für die Auswahl der Region in Compute Engine.
VPC-Netzwerke und Subnetze erstellen
Führen Sie die folgenden Aufgaben 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, stellen Sie Ihre Projekte als freigegebene VPC-Hostprojekte bereit.
Planen Sie die Zuweisung von IP-Adressen für Ihre Netzwerke. Sie können Ihre Bereiche vorab zuweisen und reservieren, indem Sie interne Bereiche erstellen. Dadurch werden die spätere Konfiguration und der Betrieb vereinfacht.
Erstellen Sie eine Transitnetzwerk-VPC mit aktiviertem globalen Routing.
VPC-Netzwerke für den Dienstzugriff erstellen. 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 ein Failover zueinander durchführen können. Außerdem wird davon ausgegangen, dass Clients an einem externen Standort bevorzugt auf Dienste in der Region zugreifen, in der sich der externe Standort befindet.
- Richten Sie die Verbindung zwischen externen Netzwerken und Ihrem Transitnetzwerk ein. Informationen dazu, wie Sie vorgehen sollten, finden Sie unter Externe und Hybridkonnektivität. Eine Anleitung 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:
- Kündigen Sie alle Subnetze für diesen externen Standort mit demselben BGP-MED auf beiden Schnittstellen an, z. B. 100. Wenn beide Schnittstellen denselben MED-Wert ankündigen, kann Google Cloud ECMP verwenden, um den Traffic auf beide Verbindungen zu verteilen.
- Kündigen Sie alle Subnetze vom anderen externen Standort mit einem MED mit niedrigerer Priorität als dem der ersten Region an, z. B. 200. Geben Sie über beide Schnittstellen dieselbe MED an.
- Konfigurieren Sie den externen Cloud Router in der 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 externen Cloud Router-Schnittstellen anzukündigen. Fassen Sie sie nach Möglichkeit zusammen. Verwenden Sie auf beiden Schnittstellen denselben MED, z. B. 100.
- Konfigurieren Sie den Router am angegebenen externen Standort so:
Wenn Sie mit Network Connectivity Center-Hubs und Hybrid-Spokes arbeiten, verwenden Sie die Standardparameter.
- Erstellen Sie einen Network Connectivity Center-Hub. Wenn Ihre Organisation Traffic zwischen allen VPC-Netzwerken zulässt, verwenden Sie die Standardkonfiguration für das vollständige Mesh.
- Wenn Sie Partner Interconnect, Dedicated Interconnect, HA VPN oder eine Router-Appliance verwenden, um lokale Präfixe zu erreichen, konfigurieren Sie diese Komponenten als unterschiedliche Network Connectivity Center-Hybrid-Spokes.
- Wenn Sie die Subnetze der Network Connectivity Center-Hub-Routingtabelle für Remote-BGP-Nachbarn ankündigen möchten, legen Sie einen Filter fest, der alle IPv4-Adressbereiche enthält.
- Wenn die Hybridverbindung 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. Dadurch 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 transitives Routing zwischen externen Netzwerken und der VPC für den Dienstzugriff sowie zwischen Arbeitslast-VPCs und der VPC für den Dienstzugriff zu ermöglichen, verwendet die VPC für den Dienstzugriff HA VPN für die Konnektivität.
- Schätzen Sie, wie viel Traffic zwischen den Transit- und Dienstzugriffs-VPCs in jeder Region übertragen werden muss. Passen Sie die erwartete Anzahl von Tunneln entsprechend an.
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 dedizierten HA VPN Cloud Router im Transit-VPC-Netzwerk. Lassen Sie den Router, der mit dem externen Netzwerk verbunden ist, für externe Netzwerkverbindungen.
- Cloud Router-Konfiguration für Transit-VPC:
- Wenn Sie Subnetze des externen Netzwerks und der Arbeitslast-VPC für die Dienstzugriffs-VPC freigeben möchten, verwenden Sie benutzerdefinierte Route Advertisements für den Cloud Router in der Transit-VPC.
- Cloud Router-Konfiguration für den Dienstzugriff:
- Um Subnetze des VPC-Netzwerks für den Dienstzugriff für die Transit-VPC freizugeben, verwenden Sie benutzerdefinierte Route Advertisements im Cloud Router des VPC-Netzwerk für den Dienstzugriff.
- Wenn Sie Zugriff auf private Dienste verwenden, um ein VPC-Netzwerk für verwaltete Dienste mit der VPC für den Dienstzugriff zu verbinden, verwenden Sie benutzerdefinierte Routen, um auch diese Subnetze anzukündigen.
- Konfigurieren Sie auf der Transit-VPC-Seite des HA VPN-Tunnels das Tunnelpaar als Network Connectivity Center-Hybrid-Spoke:
- Um die interregionale Datenübertragung zu unterstützen, konfigurieren Sie den Hybrid-Spoke mit aktivierter Site-to-Site-Datenübertragung.
- Wenn Sie die Subnetze der Network Connectivity Center-Hub-Routentabelle für Remote-BGP-Nachbarn ankündigen möchten, legen Sie einen Filter fest, der alle IPv4-Adressbereiche enthält. Durch diese Aktion werden alle IPv4-Subnetzrouten an den Nachbarn angekündigt.
- Wenn die Kapazität des externen Routers begrenzt ist, können Sie dynamische Routen installieren, indem Sie den Cloud Router so konfigurieren, dass er eine Sammelroute mit einem benutzerdefinierten Route Advertisement 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 Dienstzugriff verbinden, nachdem die VPC-Netzwerk-Peering-Verbindung hergestellt wurde, müssen Sie auch die Seite der VPC für den Dienstzugriff der VPC-Netzwerk-Peering-Verbindung aktualisieren, um benutzerdefinierte Routen zu exportieren.
Verbindung zwischen Transit-VPC-Netzwerk und Arbeitslast-VPC-Netzwerken herstellen
Um Inter-VPC-Konnektivität im großen Maßstab herzustellen, verwenden Sie Network Connectivity Center mit VPC-Spokes. Das Network Connectivity Center unterstützt zwei verschiedene Arten von Datenebenenmodellen: das Full-Mesh-Datenebenenmodell oder das Star-Topologie-Datenebenenmodell.
- Wenn alle Ihre Netzwerke miteinander kommunizieren dürfen, stellen Sie eine vollständige Mesh-Konnektivität her.
- Wenn für Ihre Unternehmensarchitektur eine Punkt-zu-Mehrpunkt-Topologie erforderlich ist, stellen Sie eine Sterntopologieverbindung her.
Vollständige Mesh-Konnektivität herstellen
Zu den Network Connectivity Center-VPC-Spokes gehören die Transit-VPCs, die Private Service Connect-Nutzer-VPCs und alle Arbeitslast-VPCs.
- Obwohl das Network Connectivity Center ein vollständig vermaschtes Netzwerk von VPC-Spokes erstellt, müssen die Netzwerkbetreiber Traffic zwischen den Quell- und Zielnetzwerken mithilfe von Firewallregeln oder Firewallrichtlinien zulassen.
- Konfigurieren Sie alle VPCs für Arbeitslasten, Transit und Private Service Connect-Nutzer als Network Connectivity Center-VPC-Spokes. Es darf keine Subnetzüberschneidungen bei VPC-Spokes geben.
- Wenn Sie den VPC-Spoke konfigurieren, kündigen Sie nicht überlappende IP-Adress-Subnetzbereiche in der Routentabelle des Network Connectivity Center-Hubs an:
- Export-Subnetzbereiche einschließen.
- Export-Subnetzbereiche ausschließen.
- Wenn Sie den VPC-Spoke konfigurieren, kündigen Sie nicht überlappende IP-Adress-Subnetzbereiche in der Routentabelle des Network Connectivity Center-Hubs 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 eine Anfrage zum Beitritt zum Network Connectivity Center-Hub in den anderen Projekten stellen.
- Verwenden Sie IAM-Berechtigungen (Identity and Access Management) im Hub-Projekt des Network Connectivity Center, um diesem Nutzer die Rolle
roles/networkconnectivity.groupUserzu gewähren.
- Verwenden Sie IAM-Berechtigungen (Identity and Access Management) im Hub-Projekt des Network Connectivity Center, um diesem Nutzer die Rolle
- Damit private Dienstverbindungen vorübergehend und global von anderen Network Connectivity Center-Spokes aus zugänglich sind, aktivieren Sie die Weitergabe von Private Service Connect-Verbindungen im Network Connectivity Center-Hub.
Wenn die vollständige Mesh-VPC-Kommunikation zwischen den VPCs der Arbeitslast nicht zulässig ist, sollten Sie eine Network Connectivity Center-Stern-Topologie verwenden.
Sterntopologie-Verbindung herstellen
Für zentralisierte Geschäftsarchitekturen, die eine Punkt-zu-Mehrpunkt-Topologie erfordern, kann eine Stern-Topologie des Network Connectivity Center verwendet werden.
Führen Sie die folgenden Aufgaben aus, um eine Stern-Topologie 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 Weitergabe von Private Service Connect-Verbindungen im Network Connectivity Center-Hub.
- Wenn Sie den Network Connectivity Center-Hub für eine Stern-Topologie konfigurieren, können Sie VPCs in einer von zwei vordefinierten Gruppen gruppieren: Center-Gruppen oder Edge-Gruppen.
Wenn Sie VPCs in der Center-Gruppe gruppieren möchten, konfigurieren Sie die Transit-VPC und die Private Service Connect-Nutzer-VPCs als Network Connectivity Center-VPC-Spoke als Teil der Center-Gruppe.
Das Network Connectivity Center erstellt ein vollständig vermaschtes Netzwerk zwischen VPC-Spokes, die sich in der Center-Gruppe befinden.
Wenn Sie Arbeitslast-VPCs in der Edge-Gruppe gruppieren möchten, konfigurieren Sie jedes dieser Netzwerke als Network Connectivity Center-VPC-Spoke in 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.
Cloud NGFW-Richtlinien konfigurieren
Beachten Sie zusätzlich zu den Informationen unter Sicherheit und Compliance die Best Practices für Firewallregeln.
Weitere Hinweise:
- Wir empfehlen, Netzwerk-Firewallrichtlinien anstelle von VPC-Firewallregeln zu verwenden, wenn Ihre Arbeitslasten auf Compute Engine-VMs ausgeführt werden. Netzwerk-Firewallrichtlinien bieten Vorteile wie detaillierte Sicherheits- und Zugriffssteuerung mithilfe von Tags, vereinfachte Regelverwaltung, einfache Bedienung, umfangreichere Funktionen und flexible Datenspeicherung. Wenn Sie bereits VPC-Firewallregeln haben, können Sie das Migrationstool für VPC-Firewallregeln verwenden, um die Migration zu einer globalen Netzwerk-Firewallrichtlinie zu erleichtern.
- Google Kubernetes Engine erstellt und verwaltet automatisch bestimmte VPC-Firewallregeln, um wichtigen Traffic zuzulassen. Wir empfehlen daher, diese Regeln nicht zu ändern oder zu löschen. Netzwerk-Firewallrichtlinien können jedoch weiterhin zusammen mit VPC-Firewallregeln verwendet werden. Optional kann auch die Reihenfolge der Richtlinienerzwingung geändert werden.
- Wir empfehlen, Tags anstelle von Netzwerk-Tags mit Firewallregeln zu verwenden, da sie IAM-Steuerelemente, eine bessere Skalierung und Unterstützung für Netzwerk-Firewallrichtlinien bieten. Tags werden jedoch nicht von hierarchischen Firewallrichtlinien oder über Network Connectivity Center-Peering-Netzwerke unterstützt. In diesen Fällen müssen Sie Regeln basierend auf CIDR-Bereichen erstellen.
- Wenn Sie die L7-Prüfung in Cloud NGFW aktivieren möchten, konfigurieren Sie den Dienst zur Einbruchsprävention, einschließlich Sicherheitsprofilen, Firewall-Endpunkt und VPC-Verknüpfung.
- Erstellen Sie eine globale Netzwerk-Firewallrichtlinie und alle erforderlichen Firewallregeln. Berücksichtigen Sie die vorhandenen implizierten Regeln, um ausgehenden Traffic zuzulassen und eingehenden Traffic abzulehnen, die in jedem VPC-Netzwerk vorhanden sind.
- Verknüpfen Sie die Richtlinie mit den VPC-Netzwerken.
- Wenn Sie bereits VPC-Firewallregeln in Ihren Netzwerken verwenden, sollten Sie möglicherweise die Reihenfolge der Richtlinien- und Regelauswertung ändern, damit Ihre neuen Regeln vor den VPC-Firewallregeln ausgewertet werden.
- Aktivieren Sie optional das Logging von Firewallregeln.
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