Freigegebene VPC – Übersicht

Eine freigegebene VPC ermöglicht einer Organisation, Ressourcen von mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können. Wenn Sie eine freigegebene VPC verwenden, bestimmen Sie ein Projekt zum Hostprojekt und fügen ihm ein oder mehrere Dienstprojekte hinzu. Die VPC-Netzwerke im Hostprojekt werden als freigegebene VPC-Netzwerke bezeichnet. Zulässige Ressourcen aus Dienstprojekten können Subnetze im freigegebenen VPC-Netzwerk verwenden.

Über eine freigegebene VPC können Organisationsadministratoren administrative Aufgaben wie das Erstellen und Verwalten von Instanzen an Dienstprojektadministratoren delegieren, ohne die zentrale Steuerung von Netzwerkressourcen wie Subnetzen, Routen und Firewalls aus der Hand zu geben. Mit diesem Modell haben Organisationen folgende Möglichkeiten:

  • Als Best Practice zur Sicherheit die geringste Berechtigung für die Netzwerkverwaltung, -prüfung und -zugriffssteuerung implementieren. Administratoren der freigegebenen VPC können Aufgaben in der Netzwerkverwaltung an Netzwerk- und Sicherheitsadministratoren im freigegebenen VPC-Netzwerk delegieren, ohne Dienstprojektadministratoren die Möglichkeit zu geben, Änderungen mit Auswirkungen auf das Netzwerk durchzuführen. Dienstprojektadministratoren können nur Instanzen erstellen und verwalten, die das freigegebene VPC-Netzwerk verwenden. Weitere Informationen finden Sie unter Administratoren und IAM.
  • Einheitliche Richtlinien zur Zugriffssteuerung auf Netzwerkebene für mehrere Dienstprojekte in der Organisation anwenden und erzwingen und gleichzeitig administrative Aufgaben delegieren. Beispielsweise können Dienstadministratoren in ihrem Projekt Compute-Instanzadministratoren sein und somit Instanzen erstellen und löschen, die genehmigte Subnetze im freigegebenen VPC-Hostprojekt verwenden.
  • Budgets oder interne Kostenstellen über Dienstprojekte voneinander trennen. Weitere Informationen finden Sie unter Abrechnung.

Konzepte

Organisationen, Ordner und Projekte

Eine freigegebene VPC verbindet Projekte innerhalb einer Organisation. Beteiligte Host- und Dienstprojekte müssen derselben Organisation angehören. Verknüpfte Projekte können sich im selben Ordner oder in verschiedenen Ordnern befinden. Wenn sie sich in verschiedenen Ordnern befinden, muss der Administrator für beide Ordner die Berechtigungen eines Administrators der freigegebenen VPC haben. Weitere Informationen zu Organisationen, Ordnern und Projekten finden Sie in der Google Cloud-Ressourcenhierarchie.

Ein Projekt, das einer freigegebenen VPC angehört, kann entweder ein Hostprojekt oder ein Dienstprojekt sein.

  • Ein Hostprojekt enthält mindestens ein Netzwerk für freigegebene VPC. Ein Administrator der freigegebenen VPC muss zuerst ein Projekt als Hostprojekt aktivieren. Danach kann er ein oder mehrere Dienstprojekte anhängen.

  • Ein Dienstprojekt ist ein Projekt, das durch einen Administrator für freigegebene VPC an ein Hostprojekt angehängt wurde. Dieser Anhang ermöglicht die Teilnahme an der freigegebenen VPC. Üblicherweise werden separate Dienstprojekte von verschiedenen Abteilungen oder Teams einer Organisation abgewickelt und verwaltet.

  • Ein Projekt kann nicht gleichzeitig ein Hostprojekt und ein Dienstprojekt sein. Ein Dienstprojekt kann daher kein Hostprojekt für weitere Dienstprojekte sein.

  • Sie können mehrere Hostprojekte erstellen und verwenden. Jedes Dienstprojekt kann jedoch nur an ein einzelnes Hostprojekt angehängt werden. Im Beispiel mit mehreren Hostprojekten wird dies dargestellt.

Aus Gründen der Verständlichkeit wird ein Projekt, das kein Teil einer freigegebenen VPC ist, als eigenständiges Projekt bezeichnet. So wird deutlich gemacht, dass es sich weder um ein Hostprojekt noch um ein Dienstprojekt handelt.

Netzwerke

Ein freigegebenes VPC-Netzwerk ist ein VPC-Netzwerk, das in einem Hostprojekt definiert und als zentral freigegebenes Netzwerk für zulässige Ressourcen in Dienstprojekten zur Verfügung gestellt wird. Freigegebene VPC-Netzwerke können im automatischen oder benutzerdefinierten Modus ausgeführt werden, Legacy-Netzwerke werden aber nicht unterstützt.

Wenn ein Hostprojekt für eine freigegebene VPC aktiviert wurde, werden alle im Projekt vorhandenen VPC-Netzwerke in freigegebene VPC-Netzwerke umgewandelt. Neue Netzwerke werden dann ebenfalls automatisch als Netzwerke für freigegebene VPC erstellt. Somit kann es für ein einziges Hostprojekt mehr als ein Netzwerk für freigegebene VPC geben.

Host- und Dienstprojekte sind auf Projektebene miteinander verbunden. Dienstprojektadministratoren können auf Subnetze von freigegebenen VPC-Netzwerken im Hostprojekt zugreifen, wie unter Administratoren und IAM beschrieben.

Einschränkungen für Organisationsrichtlinien

Über Organisationsrichtlinien und IAM-Berechtigungen werden verschiedene Ebenen der Zugriffskontrolle bereitgestellt. Mit Organisationsrichtlinien können Sie Kontrollen auf Organisations-, Ordner- oder Projektebene festlegen.

Als Administrator für Organisationsrichtlinien können Sie diese Einschränkungen für die freigegebene VPC in einer Organisationsrichtlinie festlegen:

  • Sie können die Anzahl der Hostprojekte einschränken, an die ein Nicht-Hostprojekt oder Nicht-Hostprojekte in einem Ordner oder einer Organisation angehängt werden können. Die Beschränkung gilt, wenn der Administrator eines freigegebenen VPC ein Dienst- an ein Hostprojekt anhängt. Sie wirkt sich nicht auf vorhandene Anhänge aus. Die bleiben erhalten, auch wenn eine Richtlinie neue Anhänge ablehnt. Weitere Informationen finden Sie unter der Einschränkung constraints/compute.restrictSharedVpcHostProject.

  • Sie können einschränken, auf welche Subnetze von freigegebenen VPC Dienstprojekte auf Projekt-, Ordner- oder Organisationsebene zugreifen können. Die Einschränkung gilt, wenn Sie neue Ressourcen in den angegebenen Subnetzen erstellen. Sie wirkt sich nicht auf vorhandene Ressourcen aus. Diese funktionieren weiterhin normal in ihren Subnetzen, auch wenn durch eine Richtlinie das Einbinden neuer Ressourcen verhindert wird. Weitere Informationen finden Sie in der Einschränkung constraints/compute.restrictSharedVpcSubnetworks.

Administratoren und IAM

beta

Freigegebene VPC nutzen Rollen von Identity and Access Management (IAM) für die delegierte Administration. Die folgenden Rollen können IAM-Mitgliedern wie Nutzern, Google-Gruppen, Google-Domains oder Google Cloud-Dienstkonten zugewiesen werden. Wenn Sie Kontakt zu einem Administrator aufnehmen müssen, können Sie ihn in der IAM-Richtlinie Ihrer Organisation oder Ihres Projekts nachschlagen. Wenn Ihnen die erforderlichen Berechtigungen dafür fehlen, dann wenden Sie sich an einen Netzwerk- oder Projektadministrator in Ihrer Organisation.

Erforderliche administrative Rollen

Administrator (IAM-Rolle) Zweck
Organisationsadministrator (resourcemanager.organizationAdmin)
  • IAM-Mitglied in der Organisation
Organisationsadministratoren haben die Rolle resourcemanager.organizationAdmin für die Organisation. Sie benennen Administratoren der freigegebenen VPC. Dazu weisen sie ihnen entsprechende Rollen für das Erstellen und Löschen von Projekten und die Rolle Administrator für freigegebene VPC für die Organisation zu. Organisationsadministratoren können Richtlinien auf Organisationsebene definieren, für bestimmte Ordner- und Projektaktionen sind jedoch zusätzliche Ordner- und Projektrollen erforderlich.
Administrator für freigegebene VPC
(compute.xpnAdmin und
resourcemanager.projectIamAdmin)
  • IAM-Mitglied in der Organisation oder
  • IAM-Mitglied in einem Ordner (Beta)
Administratoren für die freigegebene VPC haben die Rollen Administrator für freigegebene Compute-VPC (compute.xpnAdmin) und Projekt-IAM-Administrator (resourcemanager.projectIamAdmin) für die Organisation oder einen oder mehrere Ordner. Sie führen verschiedene Aufgaben aus, die zum Einrichten einer freigegebenen VPC nötig sind. Beispielsweise wählen sie Hostprojekte aus, hängen Dienstprojekte an Hostprojekte an und delegieren den Zugriff auf einige oder alle Subnetze in freigegebenen VPC-Netzwerken an Dienstprojektadministratoren. Ein Administrator für freigegebene VPC eines bestimmten Hostprojekts ist normalerweise auch Inhaber des Projekts.
Ein Nutzer, dem die Rolle eines Administrators für freigegebene VPC für die Organisation zugewiesen wurde, hat diese Rolle für alle Ordner in der Organisation. Ein Nutzer, dem die Rolle für einen Ordner zugewiesen wurde, hat diese Rolle für den angegebenen Ordner und alle darunter verschachtelten Ordner. Ein Administrator für freigegebene VPC kann Projekte in zwei verschiedenen Ordnern nur dann verknüpfen, wenn er diese Rolle für beide Ordner hat.
Dienstprojektadministrator
(compute.networkUser)
  • IAM-Mitglied in der Organisation,
  • IAM-Mitglied in einem Hostprojekt oder
  • IAM-Mitglied in einigen Subnetzen des Hostprojekts
Ein Administrator für eine freigegebene VPC definiert einen Dienstprojektadministrator. Dazu weist er einem IAM-Mitglied die Rolle Netzwerknutzer (compute.networkUser) für das gesamte Hostprojekt oder ausgewählte Subnetze seiner freigegebenen VPC-Netzwerke zu. Dienstprojektadministratoren sind auch zuständig für die Eigentümerschaft und die Kontrolle über Ressourcen in den Dienstprojekten, sodass sie die Rolle Instanzadministrator (compute.instanceAdmin) für die entsprechenden Dienstprojekte brauchen. Außerdem können sie in den Dienstprojekten zusätzliche IAM-Rollen haben, z. B. als Projektinhaber.

Dienstprojektadministratoren

Beim Definieren der einzelnen Dienstprojektadministratoren kann ein Administrator für freigegebene VPC ihnen die Berechtigung zur Nutzung des gesamten Hostprojekts oder nur einiger Subnetze erteilen:

  • Berechtigungen auf Projektebene: Ein Dienstprojektadministrator kann die Berechtigung zur Nutzung aller Subnetze im Hostprojekt haben, wenn der Administrator der freigegebenen VPC dem Dienstprojektadministrator die Rolle compute.networkUser für das gesamte Hostprojekt zuweist. Das hat zur Folge, dass der Dienstprojektadministrator berechtigt ist, alle Subnetze in allen VPC-Netzwerken des Hostprojekts zu verwenden, auch Subnetze und VPC-Netzwerke, die dem Hostprojekt zukünftig hinzugefügt werden.

  • Berechtigungen auf Subnetzebene: Alternativ können einem Dienstprojektadministrator stärker eingeschränkte Berechtigungen zur Nutzung einiger Subnetze gewährt werden, wenn der Administrator der freigegebenen VPC dem Dienstprojektadministrator die Rolle compute.networkUser für diese ausgewählten Subnetze zuweist. Dienstprojektadministratoren, die nur Berechtigungen auf Subnetzebene haben, können auch nur diese Subnetze verwenden. Wenn neue freigegebene VPC-Netzwerke oder neue Subnetze zum Hostprojekt hinzugefügt werden, sollte ein Administrator für freigegebene VPC die Berechtigungsbindungen für die Rolle compute.networkUser prüfen, damit die Berechtigungen auf Subnetzebene für alle Dienstprojektadministratoren mit der beabsichtigten Konfiguration übereinstimmen.

Netzwerk- und Sicherheitsadministratoren

Administratoren für freigegebene VPC haben die vollständige Kontrolle über die Ressourcen im Hostprojekt. Das schließt auch die Administration des freigegebenen VPC-Netzwerks mit ein. Optional können sie bestimmte Verwaltungsaufgaben für das Netzwerk an andere IAM-Mitglieder delegieren:

Administrator Zweck
Netzwerkadministrator
  • IAM-Mitglied im Hostprojekt oder
  • IAM-Mitglied in der Organisation
Ein Administrator für eine freigegebene VPC kann einen Netzwerkadministrator definieren. Dazu weist er einem IAM-Mitglied die Rolle Netzwerkadministrator (compute.networkAdmin) für das Hostprojekt zu. Netzwerkadministratoren haben die volle Kontrolle über alle Netzwerkressourcen mit Ausnahme von Firewallregeln und SSL-Zertifikaten.
Sicherheitsadministrator
  • IAM-Mitglied im Hostprojekt oder
  • IAM-Mitglied in der Organisation
Ein Administrator für eine freigegebene VPC kann einen Sicherheitsadministrator definieren. Dazu weist er einem IAM-Mitglied die Rolle Sicherheitsadministrator (compute.securityAdmin) für das Hostprojekt zu. Sicherheitsadministratoren verwalten Firewallregeln und SSL-Zertifikate.

Spezifikationen

Kontingente und Limits

Hostprojekte freigegebener VPC unterliegen den standardmäßigen VPC-Kontingenten pro Projekt. Freigegebene VPC-Netzwerke unterliegen den Limits pro Netzwerk und den Limits pro Instanz für VPC-Netzwerke. Außerdem unterliegt die Beziehung zwischen Host- und Dienstprojekten den Einschränkungen für freigegebene VPC.

Abrechnung

Die Abrechnung für eine Ressource in einem Netzwerk freigegebener VPC wird dem Dienstprojekt zugeordnet, in dem sich die Ressource befindet. Dies ist auch dann der Fall, wenn die Ressource das Netzwerk freigegebener VPC im Hostprojekt verwendet.

  • Die Preise und Regeln, nach denen Rechnungsbeträge für Ressourcen in Dienstprojekten berechnet werden, in denen ein freigegebenes VPC-Netzwerk verwendet wird, unterscheiden sich nicht von den Preisen und Regeln, nach denen die Ressourcen im Hostprojekt selbst berechnet werden.
  • Die Abrechnung von ausgehendem Traffic, der von einer Ressource generiert wird, wird dem Projekt zugeordnet, in dem die Ressource definiert ist:
    • Ausgehender Traffic von einer Instanz wird dem Projekt zugeordnet, in dem sich die Instanz befindet. Wenn eine Instanz beispielsweise in einem Dienstprojekt erstellt wird, jedoch ein freigegebenes VPC-Netzwerk verwendet, erfolgt die Abrechnung des in der Instanz generierten ausgehenden Traffics über das entsprechende Dienstprojekt. So können Sie Ressourcen mithilfe einer freigegebenen VPC in Kostenstellen für die Organisation organisieren.
    • Kosten, die in Verbindung mit einem Load-Balancer entstehen, werden auf das Projekt mit den Load-Balancer-Komponenten angerechnet. Weitere Informationen zum Load-Balancing und freigegebenen VPCs finden Sie im Bereich zum Load-Balancing.
    • Ausgehender Traffic zu VPNs wird dem Projekt mit der VPN-Gatewayressource zugeordnet. Wenn beispielsweise ein VPN-Gateway im freigegebenen VPC-Netzwerk erstellt wird, ist es im Hostprojekt enthalten. Der ausgehende Traffic durch das VPN-Gateway wird völlig unabhängig von dem Dienstprojekt, das diesen verursacht, dem Hostprojekt zugeordnet.

Ressourcen

Zulässige Ressourcen

Die folgenden Dienstprojektressourcen können Teil einer freigegebenen VPC sein, wenn bestimmte praktische Einschränkungen beachtet werden:

Weitere geeignete Ressourcen finden Sie in der Dokumentation des entsprechenden Produkts.

Praktische Einschränkungen für zulässige Ressourcen

Die folgenden Einschränkungen gelten für Ressourcen, die als Teil eines Szenarios mit freigegebener VPC zulässig sind:

  • Die Verwendung eines freigegebenen VPC-Netzwerks ist nicht obligatorisch. Beispielsweise können Instanzadministratoren in einem Dienstprojekt Instanzen erstellen, die ein VPC-Netzwerk in dem Projekt verwenden. In Dienstprojekten definierte Netzwerke werden nicht freigegeben.

  • Einige Ressourcen müssen neu erstellt werden, damit ein freigegebenes VPC-Netzwerk verwendet wird. Wenn ein Administrator einer freigegebenen VPC ein vorhandenes Projekt an ein Hostprojekt anhängt, wird dieses Projekt in ein Dienstprojekt umgewandelt, die vorhandenen Ressourcen verwenden jedoch nicht automatisch freigegebene Netzwerkressourcen. Damit eine zulässige Ressource ein freigegebenes VPC-Netzwerk verwenden kann, muss ein Dienstprojektadministrator die Ressource erstellen und so konfigurieren, dass sie das Subnetz eines freigegebenen VPC-Netzwerks verwendet. Eine vorhandene Instanz in einem Dienstprojekt kann nicht neu konfiguriert werden, um ein freigegebenes VPC-Netzwerk zu verwenden. Es kann jedoch eine neue Instanz erstellt werden, die verfügbare Subnetze in einem freigegebenen VPC-Netzwerk verwendet. Diese Einschränkung gilt für private Zonen.

Unzulässige Ressourcen

Mit Deployment Manager können nur Ressourcen innerhalb eines einzelnen Projekts verwaltet werden. Das Tool lässt sich also nur mit einer speziellen Konfiguration in einem Szenario mit freigegebener VPC verwenden. Weitere Informationen finden Sie unter Freigegebene VPC mit Deployment Manager erstellen.

IP-Adressen

Wenn sich Instanzen in Dienstprojekten befinden, die an ein Hostprojekt angehängt wurden, das dasselbe freigegebene VPC-Netzwerk verwendet, können die Instanzen über sitzungsspezifische oder reservierte statische interne IP-Adressen miteinander kommunizieren, wenn die geltenden Firewallregeln das zulassen.

Sitzungsspezifische interne IP-Adressen können Instanzen in einem Dienstprojekt automatisch zugewiesen werden. Wenn beispielsweise Dienstprojektadministratoren Instanzen erstellen, wählen sie eine Zone, das freigegebene VPC-Netzwerk und ein verfügbares Subnetz aus. Die IP-Adresse stammt aus dem Bereich der verfügbaren IP-Adressen im ausgewählten freigegebenen Subnetz.

Alternativ kann ein Dienstprojektadministrator eine statische interne IP-Adresse reservieren. Das IP-Adressobjekt muss im selben Dienstprojekt erstellt werden wie die Instanz, von der es verwendet wird. Das gilt auch dann, wenn der Wert der IP-Adresse aus dem Bereich der verfügbaren IP-Adressen in einem bestimmten freigegebenen Subnetz des freigegebenen VPC-Netzwerks stammt. Weitere Informationen finden Sie auf der Seite Freigegebene VPC bereitstellen unter Statische interne IP-Adresse reservieren.

Im Hostprojekt definierte externe IP-Adressen können nur von Ressourcen in diesem Projekt verwendet werden. Sie können in Dienstprojekten nicht verwendet werden. Dienstprojekte können eine eigene Reihe von externen IP-Adressen beibehalten. Eine Instanz in einem Dienstprojekt etwa muss eine externe IP-Adresse verwenden, die in diesem Dienstprojekt definiert ist. Das ist auch dann der Fall, wenn die Instanz eine interne IP-Adresse aus einem freigegebenen VPC-Netzwerk im Hostprojekt verwendet.

Internes DNS

VMs im selben Dienstprojekt können einander über die internen DNS-Namen erreichen, die von Google Cloud automatisch erstellt werden. Die DNS-Namen verwenden die Projekt-ID des Dienstprojekts, in dem die VMs erstellt werden, obwohl die Namen auf interne IP-Adressen im Hostprojekt verweisen. Eine vollständige Erläuterung finden Sie in der Dokumentation zum internen DNS unter Interne DNS-Namen und freigegebene VPC.

Private Cloud DNS-Zonen

Sie können private Cloud DNS-Zonen in einem freigegebenen VPC-Netzwerk verwenden. Sie müssen Ihre private Zone im Hostprojekt erstellen und den Zugriff auf die Zone für das freigegebene VPC-Netzwerk gewähren.

Load-Balancing

Eine freigegebene VPC kann mit Load-Balancing verwendet werden. Alle Load-Balancing-Komponenten müssen im selben Projekt entweder komplett in einem Hostprojekt oder komplett in einem Dienstprojekt erstellt werden. Das Erstellen einiger Load-Balancing-Komponenten in einem Hostprojekt und anderer in einem angehängten Dienstprojekt wird nicht unterstützt. Wenn Sie allerdings die interne Weiterleitungsregel für einen internen TCP-UDP-Load-Balancer in einem Dienstprojekt erstellen, verweisen Sie auf ein freigegebenes Subnetz in dem Hostprojekt, an das das Dienstprojekt angehängt wurde. Weitere Informationen finden Sie auf der Seite Freigegebene VPC bereitstellen unter Erstellen eines internen TCP/UDP-Load-Balancers.

In der folgenden Tabelle werden Komponenten für HTTP(S)-, SSL-Proxy- und TCP-Proxy-Load-Balancing zusammengefasst. In den meisten Fällen werden die Back-End-Instanzen in einem Dienstprojekt erstellt. Dann werden alle Komponenten des Load-Balancers in diesem Projekt erstellt. Die Back-End-Instanzen können auch im Hostprojekt erstellt werden, aber in diesem Fall müssen sich alle Komponenten des Load-Balancers im Hostprojekt befinden.

Load-Balancer IP-Adresse Weiterleitungsregel Andere Front-End-Komponenten Back-End-Komponenten
HTTP(S)-Load-Balancing Eine externe IP-Adresse muss im selben Projekt wie die Instanzen mit Load-Balancing definiert werden, also dem Dienstprojekt. Die externe Weiterleitungsregel muss im selben Projekt wie die Back-End-Instanzen (dem Dienstprojekt) definiert werden. Ein HTTP-Zielproxy oder HTTPS-Zielproxy mit verknüpfter URL-Zuordnung muss im selben Projekt wie die Back-End-Instanzen definiert werden. Ein globaler Back-End-Dienst muss im selben Projekt wie die Back-End-Instanzen definiert werden. Diese Instanzen müssen sich in Instanzgruppen befinden, die als Back-Ends an den Back-End-Dienst angehängt wurden. Mit den Back-End-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Back-End-Dienst definiert werden.
SSL-Proxy-Load-Balancing Der SSL-Zielproxy muss im selben Projekt wie die Back-End-Instanzen definiert werden.
TCP-Proxy-Load-Balancing Der TCP-Zielproxy muss im selben Projekt wie die Back-End-Instanzen definiert werden.

In der folgenden Tabelle werden Komponenten für das Netzwerk-Load-Balancing zusammengefasst:

IP-Adresse Weiterleitungsregel Back-End-Komponenten
Eine regionale externe IP-Adresse muss im selben Projekt wie die Instanzen mit Load-Balancing definiert werden. Eine regionale externe Weiterleitungsregel muss im selben Projekt wie die Instanzen im Zielpool definiert werden, also dem Dienstprojekt. Der Zielpool muss im selben Projekt und in derselben Region wie die Instanzen im Zielpool definiert werden. Mit dem Zielpool verknüpfte Systemdiagnosen müssen auch im selben Projekt definiert werden.

In der folgenden Tabelle werden Komponenten für internes TCP/UDP-Load-Balancing zusammengefasst. Weitere Informationen finden Sie auf der Seite Freigegebene VPC bereitstellen unter Internen TCP/UDP-Load-Balancer erstellen.

IP-Adresse Weiterleitungsregel Back-End-Komponenten
Ein internes IP-Adressobjekt muss im selben Projekt wie die VMs mit Load-Balancing definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss das interne IP-Adressobjekt von Google Cloud im selben Dienstprojekt definiert werden, in dem sich die Back-End-VMs befinden. Außerdem muss es auf ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verweisen. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.

Wenn Sie ein internes IP-Adressobjekt in einem Dienstprojekt erstellen, das auf ein Subnetz in einem VPC-Netzwerk im Dienstprojekt selbst verweist, wird Ihr interner TCP/UDP-Load-Balancer in diesem Netzwerk als lokal betrachtet, nicht in jedem freigegebenen VPC-Netzwerk.
Eine interne Weiterleitungsregel muss im selben Projekt wie die VMs mit Load-Balancing definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne Weiterleitungsregel im selben Dienstprojekt definiert werden, in dem sich die Back-End-VMs befinden. Außerdem muss sie auf dasselbe Subnetz (im freigegebenen VPC-Netzwerk) verweisen, auf das die verknüpfte interne IP-Adresse verweist.

Wenn Sie eine interne Weiterleitungsregel in einem Dienstprojekt erstellen, das auf ein Subnetz in einem VPC-Netzwerk im Dienstprojekt selbst verweist, wird Ihr interner TCP/UDP-Load-Balancer in diesem Netzwerk als lokal betrachtet, nicht in jedem freigegebenen VPC-Netzwerk.
Im Szenario eines freigegebenen VPC-Netzwerks befinden sich die Back-End-VMs in einem Dienstprojekt. Dort müssen auch der regionale interne Back-End-Dienst und die Systemdiagnose definiert werden.

Beispiele und Anwendungsfälle

Grundlegende Konzepte

Im folgenden Beispiel wird ein einfaches Szenario mit freigegebener VPC veranschaulicht:

Grundlegende Konzepte (zum Vergrößern klicken)
Grundlegende Konzepte (zum Vergrößern klicken)
  • Ein Administrator für freigegebene VPC der Organisation hat ein Hostprojekt erstellt und zwei Dienstprojekte daran angehängt:

    • In Service Project A können Dienstprojektadministratoren für den Zugriff auf alle oder einige der Subnetze im freigegebenen VPC-Netzwerk konfiguriert werden. Ein Dienstprojektadministrator mit Berechtigungen, die mindestens auf Subnetzebene für 10.0.1.0/24 Subnet gelten, hat Instance A in einer Zone der Region us-west1 erstellt. Diese Instanz erhält die interne IP-Adresse 10.0.1.3 dem CIDR-Block 10.0.1.0/24.

    • In Service Project B können Dienstprojektadministratoren für den Zugriff auf alle oder einige der Subnetze im freigegebenen VPC-Netzwerk konfiguriert werden. Ein Dienstprojektadministrator mit Berechtigungen, die zumindest auf Subnetzebene für 10.15.2.0/24 Subnet gelten, hat Instance B in einer Zone der Region us-east1 erstellt. Diese Instanz erhält die interne IP-Adresse 10.15.2.4 aus dem CIDR-Block 10.15.2.0/24.

  • Das eigenständige Projekt gehört nicht zum freigegebenen VPC-Netzwerk. Es ist weder ein Hostprojekt noch ein Dienstprojekt. Eigenständige Instanzen werden von IAM-Mitgliedern erstellt, die mindestens die Rolle compute.InstanceAdmin für das Projekt haben.

Mehrere Hostprojekte

Im folgenden Beispiel wird gezeigt, wie mit einer freigegebenen VPC separate Test- und Produktionsumgebungen erstellt werden können. In diesem Fall wurde in einer Organisation beschlossen, zwei separate Hostprojekte zu verwenden: eine Testumgebung und eine Produktionsumgebung.

Mehrere Hostprojekte (zum Vergrößern klicken)
Mehrere Hostprojekte (zum Vergrößern klicken)
  • Ein Administrator für freigegebene VPC der Organisation hat zwei Hostprojekte erstellt und ihnen auf folgende Weise jeweils zwei Dienstprojekte angehängt:

    • Die Dienstprojekte Apps Testing und Mobile Testing sind an das Hostprojekt Test Environment angehängt. In beiden Projekten können Dienstprojektadministratoren für den Zugriff auf alle oder einige der Subnetze im Testing Network konfiguriert werden.

    • Die Dienstprojekte Apps Production und Mobile Production sind an das Hostprojekt Production Environment angehängt. In beiden Projekten können Dienstprojektadministratoren für den Zugriff auf alle oder einige der Subnetze im Production Network konfiguriert werden.

  • Beide Hostprojekte haben ein freigegebenes VPC-Netzwerk mit Subnetzen, für die die Verwendung derselben CIDR-Bereiche konfiguriert wurde. Im Testing Network und Production Network sind die zwei Subnetze:

    • 10.0.1.0/24 Subnet in der Region us-west1

    • 10.15.2.0/24 Subnet in der Region us-east1

  • Berücksichtigen Sie Instance AT im Dienstprojekt Apps Testing und Instance AP im Dienstprojekt Apps Production:

    • Dienstprojektadministratoren können Instanzen dieser Art erstellen, wenn sie mindestens Berechtigungen auf Subnetzebene für das 10.0.1.0/24 Subnet haben.

    • Von beiden Instanzen wird die IP-Adresse 10.0.1.3 verwendet wird. Das ist möglich, da sich jede Instanz in einem Dienstprojekt befindet, das an ein eindeutiges Hostprojekt mit einem eigenen freigegebenen VPC-Netzwerk angehängt ist. Die Netzwerke der Test- und Produktionsumgebung wurden gezielt auf die gleiche Weise konfiguriert.

    • Instanzen, die das 10.0.1.0/24 Subnet verwenden, müssen sich in einer Zone befinden, die in der gleichen Region wie das Subnetz besteht, auch wenn das Subnetz und die Instanzen in verschiedenen Projekten definiert sind. Da sich das 10.0.1.0/24 Subnet in der Region us-west1 befindet, müssen Dienstprojektadministratoren, die Instanzen mithilfe dieses Subnetzes erstellen, eine Zone in derselben Region auswählen, z. B. us-west1-a.

Hybrid-Cloud-Szenario

Im folgenden Beispiel wird gezeigt, wie die freigegebene VPC in einer hybriden Umgebung verwendet werden kann.

Hybrid-Cloud (zum Vergrößern klicken)
Hybrid-Cloud (zum Vergrößern klicken)

In diesem Beispiel wurde in einer Organisation ein Hostprojekt mit einem freigegebenen VPC-Netzwerk erstellt. Das freigegebene VPC-Netzwerk ist über Cloud VPN mit einem lokalen Netzwerk verbunden. Einige Dienste und Anwendungen werden in Google Cloud gehostet, andere werden lokal bereitgestellt:

  • Ein Administrator für freigegebene VPC hat das Hostprojekt aktiviert und drei Dienstprojekte damit verbunden: Service Project A, Service Project B und Service Project C.

    • Die Dienstprojekte können jeweils von separaten Teams verwaltet werden. Die IAM-Berechtigungen wurden so konfiguriert, dass ein Dienstprojektadministrator für ein Projekt keine Berechtigungen für die anderen Dienstprojekte hat.

    • Der Administrator für freigegebene VPC hat den entsprechenden Dienstprojektadministratoren Berechtigungen auf Subnetzebene oder Projektebene erteilt, damit sie Instanzen erstellen können, die das freigegebene VPC-Netzwerk verwenden:

      • Ein Dienstprojektadministrator für Service Project A mit Berechtigungen auf Subnetzebene für das 10.0.1.0/24 Subnet kann Instance A darin erstellen. Der Dienstprojektadministrator muss eine Zone in der Region us-west1 für die Instanz auswählen, da das die Region ist, in der sich das 10.0.1.0/24 Subnet befindet. Instance A erhält die IP-Adresse 10.0.1.3 aus dem Bereich der freien IP-Adressen im 10.0.1.0/24 Subnet.

      • Ein Dienstprojektadministrator für Service Project B mit Berechtigungen auf Subnetzebene für das 10.15.2.0/24 Subnet kann Instance B darin erstellen. Der Dienstprojektadministrator muss eine Zone in der Region us-east1 für die Instanz auswählen, da das die Region ist, in der sich das 10.15.2.0/24 Subnet befindet. Instance B erhält die IP-Adresse 10.15.2.4 aus dem Bereich der freien IP-Adressen im 10.15.2.0/24 Subnet.

      • Ein Dienstprojektadministrator für Service Project C mit Berechtigungen auf Projektebene für das gesamte Hostprojekt kann Instanzen in jedem der Subnetze in jedem VPC-Netzwerk im Hostprojekt erstellen. Beispielsweise kann der Dienstprojektadministrator Instance C im 10.7.1.0/24 Subnet erstellen und eine Zone in der Region us-east1 auswählen, die der Region des Subnetzes entspricht. Instance C erhält die IP-Adresse 10.7.1.50 aus dem Bereich der freien IP-Adressen im 10.7.1.0/24 Subnet.

    • Alle Dienstprojekte werden separat abgerechnet.

    • Die Dienstprojektadministratoren in den einzelnen Projekten sind dafür zuständig, Ressourcen zu erstellen und zu verwalten.

  • Ein Administrator für freigegebene VPC hat Netzwerkverwaltungsaufgaben an andere IAM-Mitglieder delegiert, die Netzwerk- und Sicherheitsadministratoren für das freigegebene VPC-Netzwerk sind.

    • Ein Netzwerkadministrator hat ein Cloud VPN-Gateway erstellt und einen VPN-Tunnel über das Internet zu einem lokalen Gateway konfiguriert. Das Cloud VPN kann Routen von seinem lokalen Gegenstück empfangen und mit ihm austauschen, da ein entsprechender Cloud Router in derselben us-east1-Region konfiguriert wurde.

    • Wenn das dynamische Routing der VPC im globalen Modus erfolgt, wendet der Cloud Router die erkannten Routen auf das lokale Netzwerk in allen Subnetzen im VPC-Netzwerk an und gibt die Routen für alle VPC-Subnetze für sein lokales Gegenstück frei.

    • Sicherheitsadministratoren erstellen und verwalten Firewallregeln im freigegebenen VPC-Netzwerk, um Traffic zwischen Instanzen in Google Cloud und dem lokalen Netzwerk zu steuern.

    • Abhängig von den geltenden Firewallregeln kann für Instanzen in den Dienstprojekten die Kommunikation mit internen Diensten konfiguriert werden, z. B. mit lokalen Datenbank- oder Verzeichnisservern.

Zweischichtiger Webdienst

Im folgenden Beispiel wird gezeigt, wie eine freigegebene VPC eingesetzt werden kann, um Verwaltungsaufgaben zu delegieren und das Prinzip der geringsten Berechtigung aufrechtzuerhalten. In diesem Fall verfügt eine Organisation über einen Webdienst, der auf zwei Schichten aufgeteilt wurde, und verschiedene Teams zum Verwalten der Schichten. Schicht 1 ist die nach außen ausgerichtete Komponente, hinter der sich ein HTTP-Load-Balancer befindet. Schicht 2 stellt einen internen Dienst dar, auf dem Schicht 1 aufsetzt. Sie wird durch einen internen TCU-UDP-Load-Balancer ausgeglichen.

Zweischichtiger Webdienst (zum Vergrößern klicken)
Zweischichtiger Webdienst (zum Vergrößern klicken)

Mit der freigegebenen VPC können Sie jede Schicht des Webdiensts anderen Projekten zuordnen, damit diese von unterschiedlichen Teams verwaltet werden können, wobei ein freigegebenes VPC-Netzwerk gemeinsam genutzt wird:

  • Ressourcen wie Instanzen und Load-Balancer-Komponenten für die einzelnen Schichten werden in einzelnen Dienstprojekten angesiedelt, die von verschiedenen Teams verwaltet werden.

  • Jedes Dienstprojekt in einer Schicht wurde von einem Administrator für freigegebene VPC an das Hostprojekt angehängt. Der Administrator für freigegebene VPC hat auch das Hostprojekt aktiviert.

    • Jede Schicht des Webdiensts kann von separaten Teams verwaltet werden, da diese Dienstprojektadministratoren im entsprechenden Dienstprojekt sind.

    • Alle Dienstprojekte werden separat abgerechnet.

    • Die Dienstprojektadministratoren in den einzelnen Projekten sind dafür zuständig, Ressourcen zu erstellen und zu verwalten.

  • Die Netzwerkzugriffssteuerung sieht folgendermaßen aus:

    • IAM-Mitglieder, die nur in Schicht 1 arbeiten, sind Dienstprojektadministratoren für das Tier 1 Service Project und erhalten nur Berechtigungen auf Subnetzebene für das 10.0.1.0/24 Subnet. In diesem Beispiel hat einer dieser Dienstprojektadministratoren drei Tier 1 Instances in diesem Subnetz erstellt.

    • IAM-Mitglieder, die nur in Schicht 2 arbeiten, sind Dienstprojektadministratoren für das Tier 2 Service Project und erhalten nur Berechtigungen auf Subnetzebene für das 10.0.2.0/24 Subnet. In diesem Beispiel hat ein Dienstprojektadministrator drei Tier 2 Instances in diesem Subnetz sowie einen internen Load-Balancer erstellt, dessen Weiterleitungsregel eine IP-Adresse aus dem verfügbaren Bereich dieses Subnetzes verwendet.

    • IAM-Mitglieder, die den gesamten Webdienst betreuen, sind Dienstprojektadministratoren in beiden Dienstprojekten und haben Berechtigungen auf Projektebene für das Hostprojekt. Sie können deshalb jedes beliebige Subnetz im Hostprojekt verwenden.

    • Optional kann ein Administrator für freigegebene VPC Netzwerkverwaltungsaufgaben an Netzwerk- und Sicherheitsadministratoren delegieren.

Weitere Informationen