Mehrere Google-Cloud-Projekte, ein hybrides VPN? Entscheiden Sie zuerst
Gemeinsames VPC, Peering und ein Konnektivitäts-Hub beantworten unterschiedliche Eigentumsfragen. Legen Sie die Netzgrenze fest, bevor Sie ein VPN pro Projekt bereitstellen.
Wenn mehrere Google-Cloud-Projekte hybriden Zugriff brauchen, ist der Instinkt ein VPN pro Projekt, und das ist fast immer die falsche Form. Projekt-Eigentum und Paket-Routing sind verwandte, aber unterschiedliche Fragen, und die nützliche Architektur behält die administrativen Grenzen, die Sie brauchen, und gibt den vorgesehenen Präfixen zugleich einen bewussten Weg ins Büro oder Rechenzentrum. Diese Prüfungen entscheiden, welches Netzmodell Sie wirklich wollen, in der Reihenfolge, die Nacharbeit vermeidet. Jede kann die Diskussion früh beenden, und das ist der Punkt.
Eine Projektgrenze erfordert nicht automatisch einen eigenen Tunnel.
Prüfen Sie, ob das gemeinsame Objekt das Netzwerk ist
Beginnen Sie mit einer Frage nach dem Eigentum, nicht nach der Konnektivität: Kann zentrale Netzwerk-Eigentümerschaft diese Workloads tragen? Wenn ja und die Organisation eine geeignete Konfiguration hat, besitzt ein Hostprojekt das VPC, die Subnetze und die Konnektivität, während Serviceprojekte ihre Anwendungsressourcen besitzen. Eine Cloud-VPN-Verbindung in diesem gemeinsamen Netzwerk kann dann die vorgesehenen Workload-Präfixe bedienen, vorbehaltlich Routing- und Sicherheitsrichtlinien .
Seien Sie genau, was die Zuordnung tut. Das Anhängen eines Serviceprojekts führt dessen bestehendes unabhängiges VPC nicht mit dem Hostnetzwerk zusammen und verschiebt nicht jede Ressource automatisch. Workload-Zuordnung, Berechtigungen, Adressraum und DNS sind Teil der Architektur, nicht Folgen der Einstellung. Lesen Sie die Zuordnung zuerst als Berechtigungsänderung und erst danach als Routingänderung, weil Teams den Unterschied meist beim Umstieg entdecken.
Wenn zentrales Eigentum für die beteiligten Teams nicht akzeptabel ist, halten Sie hier an und behandeln Sie den Rest als Peering- oder Hub-Design. Shared VPC einer Gruppe aufzuzwingen, die unabhängige Netzwerk-Lebenszyklen braucht, erzeugt ein politisches Problem mit einem technischen Namen.
Prüfen Sie, ob unabhängige VPCs unabhängig bleiben können
Peering bewahrt getrennte VPCs, und genau deshalb zieht es Teams an, die eigene Adresspläne und eigene Änderungskontrolle wollen. Der Haken ist, dass Peering nicht transitiv ist: Peering A-zu-B und B-zu-C erzeugt nicht von selbst Routing von A nach C über B. Wenn drei Projekte ein hybrides Ziel erreichen müssen, brauchen Sie einen bewussten Austauschplan statt einer Kette von Peerings.
Das Teilen hybrider Erreichbarkeit hängt auch am dokumentierten Austausch benutzerdefinierter Routen und an den vorgesehenen Cloud-Router-Ankündigungen. Ein Peering-Status „aktiv“ beweist, dass das Peering existiert, nicht dass die Präfixe, die beiden Seiten wichtig sind, jemals exportiert wurden. Prüfen Sie die exportierten Bereiche auf beiden Seiten des Peers, in der Konfiguration, die den Export durchführt, und vergleichen Sie sie mit den Adressen, die Ihre Workloads tatsächlich nutzen. Eine Abweichung dort ist der häufigste Grund, warum ein Peering gesund aussieht, während ein Präfix unerreichbar bleibt.
Schreiben Sie den Adressplan vor allem anderen. Überlappungsfreie Bereiche, die Routen zu jedem vorgesehenen Ziel und die Rückankündigungen sind die drei Artefakte, von denen dieses Modell lebt oder stirbt.
Prüfen Sie, ob ein Hub-Modell zur Topologie passt
Für ein größeres oder anders segmentiertes Design beschreibt Googles Überblick über das Network Connectivity Center die Hub-and-Spoke-Modelle. Lesen Sie ihn für das, was die aktuelle Version unterstützt, nicht für das, was das Diagramm andeutet: welche VPC- und Hybrid-Kombinationen, welche Routenfamilien und welche Richtlinien jeder Spoke-Typ zulässt.
Prüfen Sie die Adressfamilie ausdrücklich. Planungsbeispiele in den meisten Leitfäden, auch in diesem, betreffen IPv4, und ein Feature, das für einen Spoke-Typ existiert, gilt nicht automatisch unverändert für einen anderen. Wenn Ihre Umgebung Dual-Stack ist, gehört diese Frage zur Modellwahl, nicht in eine spätere Migration.
Die folgende Tabelle ist die Zusammenfassung der drei Modelle und der Frage, die jedes entscheidet.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Prüfen Sie, was Routing nicht gewährt
Routenaustausch ist keine pauschale Vertrauensfreigabe. DNS-Auflösung, Firewall-Berechtigung und Anwendungsautorisierung bleiben eigene Zuständigkeiten, und jede davon wird in den meisten Organisationen von einem anderen Eigentümer konfiguriert. Ein Design, das annimmt, Erreichbarkeit bedeute Autorisierung, besteht seinen Konnektivitätstest und fällt in der Sicherheitsprüfung durch.
Bestätigen Sie auch die DNS-Geschichte für jedes Modell, denn Zone und Weiterleitung unterscheiden sich zwischen einem gemeinsamen Netzwerk und gepeerten Netzwerken. Private Namen, die in einem Projekt aufgelöst werden, folgen keiner Route in ein anderes.
Halten Sie die Entscheidung und ihren Eigentümer fest
Zentralisieren Sie dort, wo die Organisation einen gemeinsamen Netzwerk-Eigentümer will; behalten Sie getrennte VPCs, wo Lebenszyklus oder Richtlinie es verlangen. Wählen Sie dann eine unterstützte Konnektivitätsbeziehung und notieren Sie, welche Sie gewählt haben, wer das gemeinsame Netzwerk besitzt und was jedes Projekt ankündigen darf.
Projekte zu zählen und für jedes ein VPN zu kaufen ersetzt diese Eigentumsentscheidung nicht. Es ist dieselbe Entscheidung, später getroffen, von dem, der die Rechnung und die Routingtabelle erbt.