In diesem Dokument werden drei Architekturoptionen zum Einrichten einer Hub-and-Spoke-Netzwerktopologie in Google Cloudvorgestellt. Bei der ersten Option wird Network Connectivity Center verwendet, bei der zweiten VPC-Netzwerk-Peering und bei der dritten Cloud VPN.
Ein Unternehmen kann Arbeitslasten zur Abrechnung, Umgebungsisolation und für andere Aspekte in einzelne VPC-Netzwerke aufteilen. Das Unternehmen muss jedoch eventuell auch bestimmte Ressourcen für diese Netzwerke freigeben, z. B. gemeinsam genutzte Diensts oder lokale Verbindungen. In solchen Fällen kann es hilfreich sein, die gemeinsam genutzte Ressource in einem Hub-Netzwerk (im Folgenden als Routingnetzwerk bezeichnet) zu platzieren und die anderen VPC-Netzwerke als Spoke-Netzwerke (im Folgenden als Arbeitslastnetzwerke bezeichnet) anzuhängen. Das folgende Diagramm zeigt ein Hub-and-Spoke-Netzwerk mit zwei Arbeitslast-VPCs. Es können jedoch weitere Arbeitslast-VPCs hinzugefügt werden.
In diesem Beispiel werden separate VPC-Netzwerke für Arbeitslasten für die Arbeitslasten einzelner Geschäftseinheiten innerhalb eines großen Unternehmens verwendet. Jedes VPC-Netzwerk für die Arbeitslast ist mit einem zentralen VPC-Routingnetzwerk verbunden, das freigegebene Dienste enthält und als einziger Einstiegspunkt in die Cloud vom lokalen Netzwerk des Unternehmens dienen kann.
Zusammenfassung der Optionen
Berücksichtigen Sie bei der Auswahl einer der in diesem Dokument beschriebenen Architekturen die relativen Vorteile von Network Connectivity Center, VPC-Netzwerk-Peering und Cloud VPN:
- Network Connectivity Center bietet die volle Bandbreite zwischen VPCs von Arbeitslasten und Transitivität zwischen VPCs von Arbeitslasten.
- Das VPC-Netzwerk-Peering bietet die volle Bandbreite zwischen Arbeitslast-VPCs und der Routing-VPC. Es bietet keine Transitivität zwischen VPCs für Arbeitslasten. VPC-Netzwerk-Peering unterstützt das Routing zu NVAs in anderen VPCs.
- Cloud VPN ermöglicht transitives Routing, aber die Gesamtbandbreite (eingehender und ausgehender Traffic) zwischen Netzwerken ist auf die Bandbreiten der Tunnel beschränkt. Um die Bandbreite zu erhöhen, können weitere Tunnel hinzugefügt werden.
Architektur mit Network Connectivity Center
Das folgende Diagramm zeigt ein Hub-and-Spoke-Netzwerk, das Network Connectivity Center verwendet.
Network Connectivity Center hat eine Hub-Ressource, die die Steuerungsebene verwaltet, aber es ist kein Hub-Netzwerk für die Datenebene.
- Das Network Connectivity Center kann die Netzwerke über eine Stern- (Hub-and-Spoke) oder Mesh-Topologie verbinden. Bei einer Sterntopologie wird die Kommunikation zwischen VPC-Spokes (VPC für Arbeitslasten) verhindert, bei der Mesh-Topologie hingegen nicht.
- Das VPC-Netzwerk für die Weiterleitung (Hub) hat eine Verbindung zu lokalen Standorten über Cloud VPN- oder Cloud Interconnect-Verbindungen.
- Dynamische Routen können über VPC-Netzwerke weitergegeben werden.
- Private Service Connect-Routen sind zwischen VPCs der Arbeitslast transitiv.
- Routen für den Zugriff auf private Dienste sind zwischen Arbeitslast-VPCs über Ersteller-Spokes für viele von Google bereitgestellte Dienste transitiv. Bei Diensten, bei denen Routen nicht transitiv sind, können Sie das VPC-Netzwerk des Kunden mit dem VPC-Routingnetzwerk verbinden, indem Sie Cloud VPN anstelle von Network Connectivity Center verwenden.
- Alle VMs in den Peering-Netzwerken können mit der vollen Bandbreite der VMs kommunizieren.
- Jedes Arbeitslast-VPC und das Routing-VPC-Netzwerk haben ein Cloud NAT-Gateway für die ausgehende Kommunikation mit dem Internet.
- DNS-Peering und ‑Weiterleitung sind so eingerichtet, dass Arbeitslasten in Arbeitslast-VPCs von lokalen Standorten aus erreicht werden können.
Architektur mit VPC-Netzwerk-Peering
Das folgende Diagramm zeigt ein Hub-and-Spoke-Netzwerk mit VPC-Netzwerk-Peering. Das VPC-Netzwerk-Peering ermöglicht die Kommunikation mithilfe interner IP-Adressen zwischen Ressourcen in separaten VPC-Netzwerken. Der Traffic verbleibt im internen Netzwerk von Google und durchläuft nicht das öffentliche Internet.
- Jedes VPC-Netzwerk für die Arbeitslast (Spoke) in dieser Architektur hat eine Peering-Beziehung zu einem zentralen VPC-Netzwerk für das Routing (Hub).
- Das Routing-VPC-Netzwerk hat eine Verbindung zu lokalen Standorten über Cloud VPN- oder Cloud Interconnect-Verbindungen.
- Alle VMs in den Peering-Netzwerken können mit der vollen Bandbreite der VMs kommunizieren.
- VPC-Netzwerk-Peering-Verbindungen sind nicht transitiv. In dieser Architektur können die lokalen und Arbeitslast-VPC-Netzwerke Traffic mit dem Routingnetzwerk austauschen, aber nicht miteinander. Wenn Sie freigegebene Dienste bereitstellen möchten, platzieren Sie sie entweder im Routingnetzwerk oder verbinden Sie sie über Cloud VPN mit dem Routingnetzwerk.
- Jedes Arbeitslast-VPC und das Routing-VPC-Netzwerk haben ein Cloud NAT-Gateway für die ausgehende Kommunikation mit dem Internet.
- DNS-Peering und ‑Weiterleitung sind so eingerichtet, dass Arbeitslasten in Arbeitslast-VPCs von lokalen Standorten aus erreicht werden können.
Architektur mit Cloud VPN
Die Skalierbarkeit einer Hub-and-Spoke-Topologie, die VPC-Netzwerk-Peering verwendet, unterliegt den Limits für VPC-Netzwerk-Peering. Wie bereits erwähnt, erlauben VPC-Netzwerk-Peering-Verbindungen keinen transitiven Traffic über die beiden VPC-Netzwerke hinaus, die sich in einer Peering-Beziehung befinden. Das folgende Diagramm zeigt eine alternative Hub-and-Spoke-Netzwerkarchitektur, die Cloud VPN verwendet, um die Einschränkungen des VPC-Netzwerk-Peerings zu umgehen.
- IPsec-VPN-Tunnel verbinden jedes VPC-Netzwerk der Arbeitslast (Spoke) mit einem VPC-Netzwerk für die Routing-Funktion (Hub).
- In jedem Arbeitslastnetzwerk gibt es eine private DNS-Zone im Routingnetzwerk sowie eine DNS-Peering-Zone und eine private Zone.
- Verbindungen sind transitiv. Die lokalen und Spoke-VPC-Netzwerke können sich über das Routingnetzwerk erreichen, was jedoch eingeschränkt sein kann.
- Die Bandbreite zwischen Netzwerken ist durch die Gesamt-Bandbreiten der Tunnel begrenzt.
- Jedes VPC für die Arbeitslast (Spoke) und das VPC-Netzwerk für das Routing haben ein Cloud NAT-Gateway für die ausgehende Kommunikation mit dem Internet.
- Das VPC-Netzwerk-Peering bietet keine transitiven Routenankündigungen.
- DNS-Peering und ‑Weiterleitung sind so eingerichtet, dass Arbeitslasten in Arbeitslast-VPCs von lokalen Standorten aus erreicht werden können.
Designalternativen
Sehen Sie sich die folgenden Architekturalternativen für Interconnect-Verbindungen von Ressourcen an, die in separaten VPC-Netzwerken in Google Cloudbereitgestellt werden:
Verbindungen zwischen Spokes mithilfe eines Gateways im Routing-VPC-Netzwerk herstellen
Für die Kommunikation zwischen den Spokes können Sie eine Network Virtual Appliance (NVA) oder eine Next Generation Firewall (NGFW) im Routing-VPC-Netzwerk bereitstellen, die als Gateway für den Traffic von Spoke zu Spoke dient.
Mehrere freigegebene VPC-Netzwerke
Erstellen Sie ein freigegebenes VPC-Netzwerk für jede Gruppe von Ressourcen, die Sie auf Netzwerkebene isolieren möchten. Wenn Sie beispielsweise die Ressourcen trennen möchten, die für Produktions- und Entwicklungsumgebungen verwendet werden, erstellen Sie ein freigegebenes VPC-Netzwerk für die Produktion und ein weiteres freigegebenes VPC-Netzwerk für die Entwicklung. Anschließend verbinden Sie die beiden VPC-Netzwerke miteinander, um die Kommunikation zwischen VPCs zu ermöglichen. Ressourcen in einzelnen Projekten für jede Anwendung oder Abteilung können Dienste aus dem entsprechenden freigegebenen VPC-Netzwerk nutzen.
Für die Verbindung zwischen den VPC-Netzwerken und Ihrem lokalen Netzwerk können Sie entweder separate VPN-Tunnel für jedes VPC-Netzwerk oder separate VLAN-Anhänge in derselben Dedicated Interconnect-Verbindung verwenden.
Nächste Schritte
- Hub-and-Spoke-Netzwerk mit Terraform bereitstellen
- Im Leitfaden zum Cloud-übergreifenden Netzwerkdesign erfahren Sie, wie Sie Ihre Hub-and-Spoke-Topologie mit lokalen und anderen Clouds verbinden.
- Weitere Designoptionen für das Verbinden mehrerer VPC-Netzwerke.
- Best Practices zum Erstellen einer sicheren und robusten Cloud-Topologie, die im Hinblick auf Kosten und Leistung optimiert ist.