Freigegebene VPC – Übersicht

Eine freigegebene VPC ermöglicht es einer Organisation, Ressourcen von mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen aus diesem Netzwerk 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. Bei diesem Modell haben Organisationen die folgenden 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 im Abschnitt Administratoren und IAM.
  • Konsistente Richtlinien zur Zugriffssteuerung auf Netzwerkebene für mehrere Dienstprojekte in der Organisation anwenden und erzwingen und gleichzeitig administrative Aufgaben delegieren. Beispielsweise können Dienstadministratoren Compute-Instanzadministratoren in ihrem Projekt 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 im Abschnitt Abrechnung.

Konzepte

Organisationen und Projekte

Eine freigegebene VPC verbindet Projekte innerhalb einer Organisation. Beteiligte Host- und Dienstprojekte müssen derselben Organisation angehören. Weitere Informationen zu Organisationen und Projekten finden Sie in der Ressourcenhierarchie der GCP.

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 für freigegebene VPC muss zuerst ein Projekt als Hostprojekt aktivieren. Danach kann ein Administrator für freigegebene VPC 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 in 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 Klarheit 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 Netzwerk für freigegebene VPC 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. Netzwerke für freigegebene VPC 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 vorhandenen VPC-Netzwerke in Netzwerke freigegebener VPC umgewandelt. Auch neue Netzwerke werden darin 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 über Anhänge auf Projektebene miteinander verbunden. Dienstprojektadministratoren können auf Subnetze von freigegebenen VPC-Netzwerken im Hostprojekt zugreifen, wie im nächsten Abschnitt Administratoren und IAM beschrieben.

Administratoren und IAM

Freigegebene VPCs nutzen IAM-Rollen (IAM = Identitäts- und Zugriffsverwaltung) für die delegierte Administration. Die folgenden Rollen können IAM-Mitgliedern wie Nutzern, Google-Gruppen, Google-Domains oder GCP-Dienstkonten zugewiesen werden:

Erforderliche administrative Rollen

Administrator Zweck
Organisationsadministrator
  • IAM-Mitglied in der Organisation
Organisationsadministratoren haben die Rolle resourcemanager.organizationAdmin für die Organisation. Sie benennen Administratoren für freigegebene 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. Diese Administratoren 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
  • IAM-Mitglied in der Organisation
Administratoren für freigegebene VPC haben die Rolle Administrator für freigegebene VPC (compute.xpnAdmin) für die Organisation. 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 Netzwerken für freigegebene VPC an Dienstprojektadministratoren. Administratoren für eine freigegebene VPC für ein bestimmtes Hostprojekt sind normalerweise auch Inhaber des Projekts.
Dienstprojektadministrator
  • IAM-Mitglied in einem Dienstprojekt oder
  • IAM-Mitglied in der Organisation
Ein Administrator für freigegebene VPC definiert einen Dienstprojektadministrator. Dazu weist er einem IAM-Mitglied die Rolle Netzwerknutzer (compute.networkUser) für das ganze Hostprojekt oder ausgewählte Subnetze seiner Netzwerke mit gemeinsamer VPC zu. Dienstprojektadministratoren behalten auch die Inhaberschaft und die Kontrolle über Ressourcen, die in den Dienstprojekten definiert sind, sodass sie mindestens die Rolle Instanzadministrator (compute.instanceAdmin) für die entsprechenden Dienstprojekte haben müssen. 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 eine freigegebene VPC die Berechtigung zur Nutzung des gesamten Hostprojekts oder nur einiger Subnetze erteilen:

  • Berechtigungen auf Projektebene: In der Definition eines Dienstprojektadministrators kann festgelegt werden, dass der Administrator die Berechtigung zur Nutzung aller Subnetze im Hostprojekt hat, wenn der Administrator für freigegebene VPC dem Dienstprojektadministrator die Rolle compute.networkUser für das gesamte Hostprojekt zuweist. Dies 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 für freigegebene 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. Nach dem Hinzufügen von neuen freigegebenen VPC-Netzwerken oder neuen Subnetzen zum Hostprojekt sollte ein Administrator für eine freigegebene VPC die Berechtigungsbindungen für die Rolle compute.networkUser überprüfen, um sicherzustellen, dass die Berechtigungen auf Subnetzebene für alle Dienstprojektadministratoren mit der beabsichtigten Konfiguration übereinstimmen.

Netzwerk- und Sicherheitsadministratoren

Administratoren für eine freigegebene VPC haben die vollständige Kontrolle über die Ressourcen im Hostprojekt, u. a. auch die Administration des freigegebenen VPC-Netzwerks. 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
Der Administrator für freigegebene VPC definiert einen Netzwerkadministrator. 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 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

Projekte freigegebener VPC unterliegen den standardmäßigen VPC-Kontingenten pro Projekt. Netzwerke freigegebener VPC unterliegen den zulässigen Höchstzahlen pro Netzwerk und den Höchstzahlen pro Instanz für VPC-Netzwerke. Darüber hinaus unterliegt die Beziehung zwischen Host- und Dienstprojekten den folgenden Einschränkungen für freigegebene VPC:

Posten Limit Hinweise
Anzahl der Dienstprojekte, die an ein Hostprojekt angehängt werden können 100 Wenden Sie sich an Ihr GCP-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
Anzahl der freigegebenen VPC-Hostprojekte 100 Dieses Limit kann nicht erhöht werden.
Anzahl der Hostprojekte, an die ein Dienstprojekt angehängt werden kann 1 Dieses Limit kann nicht erhöht werden.

Abrechnung

Die Abrechnung für Ressourcen, die in einem Netzwerk freigegebener VPC enthalten sind, wird dem Dienstprojekt zugeordnet, in dem sich die Ressource befindet, auch 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, in dem die Ressource definiert ist, zugeordnet:
    • 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. Auf diese Weise können Sie Ressourcen mithilfe einer freigegebenen VPC in Kostenstellen für die Organisation organisieren.
    • Kosten, die in Verbindung mit einem Lastenausgleichsmodul entstehen, werden auf das Projekt mit den Lastenausgleichskomponenten angerechnet. Weitere Informationen zu Lastenausgleichsmodulen und freigegebenen VPCs finden Sie im Abschnitt zum Lastenausgleich.
    • Ausgehender Traffic zu VPNs wird dem Projekt mit der VPN-Gateway-Ressource 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:

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 Instanzen in dem Dienstprojekt erstellen, das ein VPC-Netzwerk in dem Projekt verwendet. 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, von den vorhandenen Ressourcen werden jedoch nicht automatisch freigegebene Netzwerkressourcen verwendet. Ein Dienstprojektadministrator muss eine zulässige Ressource erstellen und die Verwendung eines Subnetzes von einem freigegebenen VPC-Netzwerk dafür konfigurieren, um ein freigegebenes VPC-Netzwerk verwenden zu können. So kann eine vorhandene Instanz in einem Dienstprojekt nicht neu konfiguriert werden, um ein freigegebenes VPC-Netzwerk zu verwenden. Es kann jedoch eine neue Instanz erstellt werden, um verfügbare Subnetze in einem freigegebenen VPC-Netzwerk zu verwenden.

Unzulässige Ressourcen

In einem Dienstprojekt können die flexiblen App Engine-Ressourcen nicht Teil einer freigegebenen VPC sein.

IP-Adressen

Wenn sich Instanzen in Dienstprojekten befinden, die an ein Hostprojekt angehängt wurden, das dasselbe Netzwerk für freigegebene VPC verwendet, können die Instanzen über sitzungsspezifische oder reservierte statische interne IP-Adressen miteinander kommunizieren, wenn die geltenden Firewallregeln dies 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 Netzwerk für freigegebene VPC 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, auch 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 unter Statische interne IP-Adresse reservieren auf der Seite Freigegebene VPC bereitstellen.

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 erstellt wurde. Dies ist auch dann der Fall, wenn die Instanz eine interne IP-Adresse aus einem freigegebenen VPC-Netzwerk im Hostprojekt verwendet.

Internes DNS

Interne IP-Adressen können nicht nur für die Kommunikation eingesetzt werden. Instanzen in Dienstprojekten können sich gegenseitig über voll qualifizierte interne DNS-Namen wie die folgenden erreichen. Beachten Sie, dass die Projekt-ID für jeden DNS-Namen die ID des Dienstprojekts ist, auch wenn sie auf eine IP-Adresse im Hostprojekt verweist.

  • Instanzen, die das interne zonale DNS verwenden: [INSTANCE_NAME].[ZONE].c.[SERVICE_PROJECT_ID].internal
  • Instanzen, die das interne globale DNS verwenden: [INSTANCE_NAME].c.[SERVICE_PROJECT_ID].internal

Dabei gilt:

  • [INSTANCE_NAME] ist der Name der Instanz.
  • [ZONE] ist die Zone, in der sich Ihre Instanz befindet.
  • [SERVICE_PROJECT_ID] ist das Dienstprojekt, zu dem die Instanz gehört.

Weitere Informationen zu vollqualifizierten Domainnamen (FQDN) finden Sie unter Internes DNS.

Lastenausgleich

Eine freigegebene VPC kann mit Lastenausgleich verwendet werden. Alle Lastenausgleichskomponenten müssen im selben Projekt entweder komplett in einem Hostprojekt oder komplett in einem Dienstprojekt erstellt werden. Das Erstellen einiger Lastenausgleichskomponenten in einem Hostprojekt und anderer in einem angehängten Dienstprojekt wird nicht unterstützt. Die Weiterleitungsregel für ein internes Lastenausgleichsmodul, das in einem Dienstprojekt erstellt wurde, kann jedoch auf ein freigegebenes Subnetz in dem Hostprojekt verweisen, an das das Dienstprojekt angehängt wurde.

Die folgende Tabelle enthält eine Übersicht der Komponenten für die drei globalen Lastenausgleichstypen. In den meisten Anwendungsfällen sind die Instanzen, für die ein Lastenausgleich erfolgt, in einem Dienstprojekt enthalten. Deshalb würden auch alle Lastenausgleichskomponenten in diesem Projekt erstellt werden. Die externe IP-Adresse des Lastenausgleichsmoduls stammt auch aus dem Dienstprojekt, obwohl für die beteiligten Instanzen interne IP-Adressen in einem Subnetz eines Netzwerks für freigegebene VPC vorhanden wären.

Lastenausgleichsmodul IP-Adresse Weiterleitungsregel Andere Front-End-Komponenten Back-End-Komponenten
HTTP(S)-Lastenausgleich In dem Projekt, in dem sich die Instanzen mit Lastenausgleich befinden, muss eine globale externe IP-Adresse definiert sein. In dem Projekt, in dem sich die Instanzen mit Lastenausgleich befinden, muss eine globale Weiterleitungsregel definiert sein. In dem Projekt, in dem sich die Instanzen mit Lastenausgleich befinden, muss ein HTTP-Zielproxy oder HTTPS-Zielproxy mit verknüpfter URL-Zuordnung definiert sein. In dem Projekt, in dem sich die Instanzen mit Lastenausgleich befinden, muss ein globaler Back-End-Dienst definiert sein. Instanzen mit Lastenausgleich 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 sein.
SSL-Proxy-Lastenausgleich Der SSL-Zielproxy muss im selben Projekt wie die Instanzen definiert sein, für die der Lastenausgleich durchgeführt wird.
TCP-Proxy-Lastenausgleich Der TCP-Zielproxy muss im selben Projekt wie die Instanzen definiert sein, für die der Lastenausgleich durchgeführt wird.

In der folgenden Tabelle werden die Komponenten für die zwei regionalen Lastenausgleichs-Modultypen dargestellt. Darin wird gezeigt, wie eine Weiterleitungsregel für ein internes Lastenausgleichsmodul auf ein freigegebenes Subnetz in einem freigegebenen VPC-Netzwerk verweisen kann, um regionalen internen Lastenausgleich im freigegebenen VPC-Netzwerk bereitzustellen.

Lastenausgleichsmodul IP-Adresse Weiterleitungsregel Back-End-Komponenten
Regionaler Netzwerklastenausgleich In dem Projekt, in dem sich die Instanzen mit Lastenausgleich befinden, muss eine regionale externe IP-Adresse definiert sein. In dem Projekt, in dem sich die Instanzen mit Lastenausgleich befinden, muss eine regionale Weiterleitungsregel definiert sein. Der Zielpool muss im selben Projekt und in derselben Region wie die Instanzen definiert sein, für die der Lastenausgleich durchgeführt wird. Mit dem Zielpool verknüpfte Systemdiagnosen müssen auch im selben Projekt definiert sein.
Regionaler interner Lastenausgleich Die interne IP-Adresse kann entweder aus dem Hostprojekt oder aus dem Dienstprojekt stammen:
  • Wenn das Lastenausgleichsmodul für das freigegebene VPC-Netzwerk verfügbar sein soll, stammt die IP-Adresse aus dem Bereich im freigegebenen Subnetz.
  • Wenn das Lastenausgleichsmodul lokal für ein Dienstprojekt bereitgestellt werden soll, stammt die interne IP-Adresse aus einem Subnetz in diesem Dienstprojekt.
In dem Projekt, in dem sich die Instanzen mit Lastenausgleich befinden, muss eine regionale Weiterleitungsregel definiert sein. Es hängt jedoch von dem Subnetz ab, auf das die Regel verweist, ob das Lastenausgleichsmodul in einem Szenario mit freigegebener VPC verwendet werden kann:
  • Wenn das Lastenausgleichsmodul für das freigegebene VPC-Netzwerk verfügbar sein soll, verweist die Weiterleitungsregel auf ein freigegebenes Subnetz. Eine genaue Anleitung dazu finden Sie unter Internes Lastenausgleichsmodul erstellen auf der Seite Freigegebene VPC bereitstellen.
  • Wenn das Lastenausgleichsmodul lokal für ein Dienstprojekt bereitgestellt werden soll, verweist die Weiterleitungsregel auf ein Subnetz in einem Netzwerk in diesem Dienstprojekt.
In dem Projekt, in dem sich die Instanzen mit Lastenausgleich befinden, muss ein regionaler Back-End-Dienst definiert sein. Instanzen mit Lastenausgleich 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 sein.

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 die freigegebene VPC der Organisation hat ein Hostprojekt erstellt und zwei Dienstprojekte daran angehängt:

    • Für Dienstprojektadministratoren in Service Project A kann der Zugriff auf alle oder einige der Subnetze im freigegebenen VPC-Netzwerk konfiguriert werden. Ein Dienstprojektadministrator mit Berechtigungen, die zumindest 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 eine interne IP-Adresse 10.0.1.3 aus dem CIDR-Block 10.0.1.0/24.

    • Für Dienstprojektadministratoren in Service Project B kann der 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 eine 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 die freigegebene VPC der Organisation hat zwei Hostprojekte erstellt und ihnen auf folgende Weise 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 mit 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 mit 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 folgende:

    • 10.0.1.0/24 Subnet in der Region us-west1

    • 10.15.2.0/24 Subnet in der Region us-east1

  • Bezüglich Instance AT im Dienstprojekt Apps Testing und Instance AP im Dienstprojekt Apps Production gilt Folgendes:

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

    • Beachten Sie, dass von beiden Instanzen 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 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.

Hybrides Cloudszenario

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

Hybride Cloud (zum Vergrößern klicken)
Hybride 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 GCP gehostet, andere werden lokal bereitgestellt:

  • Ein Administrator der freigegebenen 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 die 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 dies die Region ist, in der sich das 10.0.1.0/24 Subnet befindet. Instance A erhält eine 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 dies die Region ist, in der sich das 10.15.2.0/24 Subnet befindet. Instance B erhält eine 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 eine 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 die 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 durch 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 ermittelten Routen auf das lokale Netzwerk in allen Subnetzen im VPC-Netzwerk an und gibt die Routen für alle VPC-Subnetze für die lokalen Gegenstellen frei.

    • Sicherheitsadministratoren erstellen und verwalten Firewallregeln im freigegebenen VPC-Netzwerk, um Traffic zwischen Instanzen in der GCP 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 globales HTTP-Lastenausgleichsmodul befindet. Schicht 2 stellt einen internen Dienst dar, auf dem Schicht 1 aufsetzt. Sie wird durch ein internes Lastenausgleichsmodul 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 Lastenausgleichskomponenten 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 anderer Dienstprojektadministrator drei Tier 2 Instances in diesem Subnetz sowie ein internes Lastenausgleichsmodul 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

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...