Dieses Dokument enthält eine Referenzarchitektur, mit der Sie eine Cross-Cloud Network-Netzwerktopologie zwischen VPCs 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 Google Cloud Zugriff auf private Dienste und Private Service Connect verfügbar gemacht werden. NCC ist ein Hub-and-Spoke-Modell für die Steuerungsebene, mit dem Netzwerkverbindungen inGoogle Cloudverwaltet werden. Die Hub-Ressource bietet eine zentrale Konnektivitätsverwaltung für VPC-Spokes von NCC.
Der NCC-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. Hybride Spokes fügen in der Regel dynamische Routen in die zentrale Hub-Routingtabelle ein. Anhand der Informationen der Steuerungsebene des NCC-Hubs Google Cloudwird automatisch eine Verbindung der Datenebene zwischen NCC-Spokes hergestellt.
NCC ist der empfohlene Ansatz, um VPCs für skalierbares Wachstum auf Google Cloudzu verbinden. Wenn Sie virtuelle Netzwerk-Appliances (NVAs) 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 Cross-Cloud Network inter-VPC-Konnektivität 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 NCC 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 NCC. |
| VPC-Netzwerk für den Dienstzugriff | Bietet Zugriff auf Dienste, die von Arbeitslasten benötigt werden, die in den VPC-Netzwerken der Arbeitslasten 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, Arbeitslast- und Private Service Connect-Nutzernetzwerken über das Transitnetzwerk aus. Verbindung zur Transit-VPC über HA VPN. Das transitive Routing, das von HA VPN bereitgestellt wird, 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, die auf Dienste zugreifen. Stellt über den Zugriff auf private Dienste eine Verbindung zum VPC-Netzwerk für den Dienstzugriff her. Dabei wird VPC-Netzwerk-Peering verwendet. 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 einen Endpunkt von Flows aus allen anderen Netzwerken. |
| Private Service Connect-Nutzer-VPC | Hostet Private Service Connect-Endpunkte, auf die von anderen Netzwerken aus zugegriffen werden kann. Diese VPC kann auch eine Arbeitslast-VPC sein. | Tauscht Daten mit den externen und den VPC-Netzwerken für den Dienstzugriff über das Transit-VPC-Netzwerk aus. Verbindet sich über NCC-VPC-Spokes mit dem Transitnetzwerk und anderen VPC-Netzwerken für Arbeitslasten. |
| VPC-Netzwerke der Arbeitslast | 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 den VPC-Netzwerken für den Dienstzugriff über das Transit-VPC-Netzwerk aus. Verbindet sich über NCC-VPC-Spokes mit dem Transitnetzwerk, den Private Service Connect-Nutzernetzwerken und anderen VPC-Netzwerken für Arbeitslasten. Beendet ein Ende der folgenden Flows:
|
| NCC | Der NCC-Hub enthält eine globale Routingdatenbank, 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 NCC-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 geben die Routen für die externen Subnetze an die Transit-VPC-Cloud-Router weiter. Im Allgemeinen kündigen externe Router an einem bestimmten Standort Routen vom selben externen Standort 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 Cloudfür die externen Netzwerke an. Diese Routen müssen mit benutzerdefinierten Route Advertisements von Cloud Router angekündigt werden.
- Mit NCC können Sie Daten zwischen verschiedenen lokalen Netzwerken über das Google-Backbone-Netzwerk übertragen. Wenn Sie die Interconnect-VLAN-Anhänge als NCC-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 NCC-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 Dienstzugriffs-VPC-Cloud Router 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 Zugriff auf Dienste müssen mit benutzerdefinierten Cloud Router-Route-Advertisements angekündigt werden.
Verbindung 3: Zwischen dem Transit-VPC-Netzwerk, den VPC-Netzwerken für Arbeitslasten und den VPC-Netzwerken für den Dienstzugriff von Private Service Connect
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 NCC ausgetauscht werden. Diese Verbindung ermöglicht die Kommunikation zwischen den Arbeitslast-VPC-Netzwerken, den VPC-Netzwerken für den Dienstzugriff, die als NCC-VPC-Spokes verbunden sind, und anderen Netzwerken, die als NCC-Hybrid-Spokes verbunden sind. Zu diesen anderen Netzwerken gehören die externen Netzwerke und die VPC-Netzwerke für den Dienstzugriff, die Verbindung 1 bzw. Verbindung 2 verwenden.
- Die Cloud Interconnect- oder HA VPN-Anhänge im Transit-VPC-Netzwerk verwenden NCC, um dynamische Routen in die VPC-Netzwerke der Arbeitslast zu exportieren.
- Wenn Sie das Arbeitslast-VPC-Netzwerk als Spoke des NCC-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 VPC-Netzwerk für Arbeitslasten exportiert.
Verbindung 4: Private Service Connect-Nutzer-VPC mit NCC-Weitergabe
- 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-Nutzer-VPC-Netzwerk ist als NCC-VPC-Spoke konfiguriert. Dieser Spoke ermöglicht die Private Service Connect-Weitergabe im NCC-Hub. Bei der Private Service Connect-Weitergabe wird das Hostpräfix des Private Service Connect-Endpunkts als Route in der NCC-Hub-Routingtabelle 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. Für den NCC-Hub muss die Private Service Connect-Verbindungsweitergabe aktiviert sein.
- NCC 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 Private Service Connect-Nutzer-VPC-Netzwerk |
|
| VPC-Netzwerk für Arbeitslasten oder Private Service Connect-Nutzer-VPC-Netzwerk | 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 NCC. 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 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 den Traffic zu schützen, der in die VPC-Netzwerke für den Dienstzugriff und die Arbeitslasten ein- und ausgeht. Wenn Sie den Traffic zwischen Hybridnetzwerken über das Transitnetzwerk oder zwischen externen Netzwerken und von Google verwalteten Diensten untersuchen möchten, müssen Sie externe Firewalls oder NVA-Firewalls verwenden.
- Wenn Sie eine L7-Traffic-Prüfung benötigen, aktivieren Sie den Einbruchserkennungs- und ‑präventionsdienst (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 Umstrukturierung 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 Next Generation Firewall 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 Firewallregel-Logging kann Kosten verursachen. Daher können Sie es 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-Einbruchspräventionsdienst im Benachrichtigungsmodus, 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 NCC-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 in Einklang bringen, finden Sie unter Netzwerkverbindungsprodukt auswählen.
Bereitstellung
In diesem Abschnitt wird beschrieben, wie Sie die VPC-übergreifende Konnektivität des Cross-Cloud-Netzwerks mithilfe der in diesem Dokument beschriebenen NCC-Architektur bereitstellen.
In der Architektur in diesem Dokument werden drei Arten von Verbindungen zu einer zentralen Transit-VPC sowie eine Verbindung zwischen Arbeitslast-VPC-Netzwerken und Arbeitslast-VPC-Netzwerken erstellt. Nachdem das NCC 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 NCC 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 NCC erstellen
Bevor Sie zum ersten Mal einen NCC-Hub erstellen, müssen Sie entscheiden, ob Sie eine Full-Mesh-Topologie oder eine Sterntopologie 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 NCC-Mesh.
- Wenn der Traffic zwischen bestimmten verschiedenen VPC-Spokes nicht zulässig ist, diese VPC-Spokes aber eine Verbindung zu einer Kerngruppe von VPC-Spokes herstellen können, verwenden Sie eine NCC-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 gemeinsam genutzte VPC-Netzwerke verwenden möchten, stellen Sie Ihre Projekte als Hostprojekte für freigegebene VPC bereit.
Planen Sie die IP-Adressenzuweisungen für Ihre Netzwerke. Sie können Ihre Bereiche vorab zuweisen und reservieren, indem Sie interne Bereiche erstellen. Das erleichtert die spätere Konfiguration und Bedienung.
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 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 einer MED mit niedrigerer Priorität als die 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:
- Legen Sie für Ihren Cloud Router eine private ASN fest.
- 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:
Mit NCC-Hub und Hybrid-Spokes arbeiten: Verwenden Sie die Standardparameter.
- Erstellen Sie einen NCC-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 NCC-Hybrid-Spokes.
- Wenn Sie die Subnetze der NCC-Hub-Routentabelle 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 Workload-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 der Tunnel 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 VPC für 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 NCC-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 NCC-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 Routingtabelle des NCC-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 skalierbare Konnektivität zwischen VPCs einzurichten, verwenden Sie NCC mit VPC-Spokes. NCC unterstützt zwei verschiedene Arten von Datenebenenmodellen: das Full-Mesh-Datenebenenmodell und das Stern-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 Verbindung mit Sterntopologie her.
Vollständige Mesh-Konnektivität herstellen
Die NCC-VPC-Spokes umfassen die Transit-VPCs, die Private Service Connect-Nutzer-VPCs und alle Arbeitslast-VPCs.
- Obwohl NCC 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 Arbeitslast-, Transit- und Private Service Connect-Consumer-VPCs als NCC-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 NCC-Hub-Routingtabelle 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 NCC-Hub-Routingtabelle an:
- Wenn sich VPC-Spokes in verschiedenen Projekten befinden und von anderen Administratoren als den NCC-Hub-Administratoren verwaltet werden, müssen die VPC-Spoke-Administratoren eine Anfrage zum Beitritt zum NCC-Hub in den anderen Projekten stellen.
- Verwenden Sie IAM-Berechtigungen (Identity and Access Management) im NCC-Hub-Projekt, um dem Nutzer die Rolle
roles/networkconnectivity.groupUserzuzuweisen.
- Verwenden Sie IAM-Berechtigungen (Identity and Access Management) im NCC-Hub-Projekt, um dem Nutzer die Rolle
- Damit private Dienstverbindungen vorübergehend und global von anderen NCC-Spokes aus zugänglich sind, aktivieren Sie die Weitergabe von Private Service Connect-Verbindungen im NCC-Hub.
Wenn die vollständige Mesh-VPC-Kommunikation zwischen Arbeitslast-VPCs nicht zulässig ist, sollten Sie eine NCC-Stern-Topologie verwenden.
Sterntopologie-Verbindung herstellen
Zentrale Geschäftsarchitekturen, die eine Punkt-zu-Mehrpunkt-Topologie erfordern, können eine NCC-Stern-Topologie verwenden.
So verwenden Sie eine NCC-Stern-Topologie:
- Erstellen Sie in NCC einen NCC-Hub und geben Sie eine Sterntopologie an.
- Damit private Dienstverbindungen vorübergehend und global von anderen NCC-Spokes aus zugänglich sind, aktivieren Sie die Weitergabe von Private Service Connect-Verbindungen im NCC-Hub.
- Wenn Sie den NCC-Hub für eine Sterntopologie konfigurieren, können Sie VPCs in einer von zwei vorgegebenen 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 NCC-VPC-Spoke als Teil der Center-Gruppe.
NCC 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 NCC-VPC-Spoke in dieser Gruppe.
NCC erstellt einen Punkt-zu-Punkt-Datenpfad von jedem NCC-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 Feature-Sets und flexible Datenstandorte. 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 lässt sich auch die Reihenfolge der Richtlinienerzwingung ändern.
- 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 unterstützt oder über Peering-Netzwerke des Network Connectivity Center. In diesen Fällen müssen Sie also Regeln auf Grundlage von 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.
- Richtlinie mit den VPC-Netzwerken verknüpfen
- 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
Autor*innen:
- 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