Organisationsübersicht

Die Organisationsressource stellt eine Verwaltungseinheit oder eine Geschäftsfunktion dar, die denselben Ressourcenpool und dieselben gemeinsamen Richtlinien verwendet. Google Distributed Cloud (GDC) air-gapped bietet physische Isolation zwischen Organisationen, die Hardware-Level-Multi-Tenancy-Funktionen verwenden. Jede Organisation hat auch eigene Steuerungsebenenkomponenten für ihre Dienste, die nicht für andere Organisationen freigegeben werden. Alle Ressourcen wie Projekte, Cluster und Dienste gehören einer Organisation und nicht ihren Erstellern. Ressourcen werden daher nicht gelöscht, wenn der Nutzer, der sie erstellt hat, die Organisation verlässt. Stattdessen folgen alle Ressourcentypen dem Lebenszyklus der Organisation. Weitere Informationen finden Sie unter GDC-Ressourcenhierarchie.

Externe Netzwerkverbindung

Damit eine Organisation nützlich ist, muss sie mit externen Netzwerken verbunden sein. So können Plattformadministratoren und Anwendungsbetreiber die Organisation und ihre Ressourcen verwalten und Endnutzer die darin bereitgestellten Dienste nutzen. In GDC wird die gesamte externe Konnektivität über Interconnects bereitgestellt.

Wenn eine Organisation erstellt wird, wird sie nicht automatisch mit einem Netzwerk verbunden. Als Betreiber müssen Sie zusätzliche Konfigurationsschritte ausführen, um eine Organisation an eine vorhandene Interconnect-Verbindung anzuhängen oder eine neue, dedizierte Verbindung bereitzustellen. Dazu gehören in der Regel:

  • Die Organisation wird einem AttachmentGroup hinzugefügt.
  • Interconnect-Ressourcen für neue physische oder logische Verbindungen erstellen
  • RoutePolicy-Ressourcen definieren, um die Netzwerkrouten der Organisation im externen Netzwerk zu bewerben.

Organisationen bieten erweiterte Netzwerkfunktionen, einschließlich der Möglichkeit für Organisationen mit dedizierten Interconnects, sich überschneidende externe IP-Adressen zu verwenden, was die IP-Verwaltung vereinfacht.

Ausführliche Informationen zu Konzepten und Konfigurationsverfahren finden Sie in der Interconnect-Übersicht.

Interconnect-Verbindungsmodelle

GDC-Verbindungen unterstützen zwei primäre Konfigurationen, die auf unterschiedliche Anforderungen an Sicherheit und IP-Management abgestimmt sind.

Gemeinsame externe Netzwerkverbindung

Mit diesem Modell können mehrere Organisationen über ein gemeinsames externes Netzwerk eine Verbindung zu einer GDC-Zone herstellen. In dieser Konfiguration verwaltet der Infrastructure Operator (IO) in der Regel die physische Verbindung und das BGP-Peering. Eine wichtige Voraussetzung ist, dass die externen IP-Adressen, die von den einzelnen Organisationen verwendet werden, im freigegebenen Netzwerk eindeutig sein müssen. Dieses Modell ist für Umgebungen mit einer gemeinsamen Vertrauensdomäne einfacher zu verwalten.

Dedizierte externe Netzwerkverbindung

Dieses Modell ist für Organisationen gedacht, die ein höheres Maß an Isolation benötigen und sich mit einem separaten externen Netzwerk verbinden. Mit einer dedizierten Verbindung kann der PA das BGP-Peering verwalten und so mehr Kontrolle ausüben.

Ein wesentlicher Vorteil dieses Modells ist die Möglichkeit für Organisationen, sich überschneidende externe IP-Adressen zu verwenden. Diese Funktion vereinfacht die Verwaltung von IP-Adressen, da IP-Bereiche nicht mehr für alle Mandanten im GDC-Universum in Konflikt stehen müssen.

Ausführliche Informationen zu Konzepten und Konfigurationsverfahren finden Sie in der Interconnect-Übersicht.

Organisationsarchitekturen

GDC bietet zwei Architekturen für Organisationen:

  • GDC-Architektur für Organisationen mit Air Gap V1 (V1-Organisation)
  • GDC-Architektur mit Air Gap für Organisation v2 (Organisation v2)

Auf den ersten Blick werden Organisationen mit beiden Architekturen auf ähnliche Weise bereitgestellt, verwendet und betrieben. Die zugrunde liegenden Cluster-, Netzwerk- und Speicherarchitekturen sind jedoch für jeden Organisationstyp unterschiedlich.

GDC mit Air Gap – Organisationsarchitektur V1

Eine Organisation der Version 1 besteht aus zwei Clustern:

  • Administratorcluster der Organisation: Führt die Komponenten der Steuerungsebene von verwalteten Diensten und Marketplace-Diensten für die Organisation aus. Außerdem werden dort einige wichtige Infrastrukturdienste gehostet.
  • Systemcluster: Führt VM-Arbeitslasten und einige Data-Plane-Arbeitslasten für verwaltete Dienste für die Organisation aus. Die Anzahl der Worker-Knoten hängt von der Auslastung des Clusters ab.

Der PA und der AO sind manchmal erforderlich, um auf diese Clustertypen zuzugreifen, um Arbeitslasten bereitzustellen und das System zu verwalten.

In einer Organisation der Version 1 werden verschiedene Knoten der Steuerungsebene und Worker-Knoten für die verschiedenen Clustertypen ausgeführt.

Der Speicher für virtuelle Cluster wird von einem anbieterspezifischen CSI-Treiber im Cluster verwaltet.

GDC mit Air Gap – Organisationsarchitektur V2

Eine Organisation der Version 2 besteht aus einem Cluster, dem Infrastrukturcluster der Organisation, in dem die Komponenten der Steuerungsebene und der Datenebene der Organisation ausgeführt werden. In diesem Cluster wird auch der Management-API-Server gehostet, auf dem alle Nicht-Container-Arbeitslasten und ‑Dienste bereitgestellt werden. Der Management-API-Server bietet eine Ebene, auf der PAs und AOs Arbeitslasten bereitstellen können, ohne direkt mit dem Infrastrukturcluster der Organisation zu interagieren.

In einer Organisation der Version 2 werden verschiedene Knoten der Steuerungsebene und der Datenebene im Infrastrukturcluster der Organisation ausgeführt.

Der Speicher für virtuelle Cluster wird von einem Proxy-CSI-Treiber verwaltet, der es dem CSI-Treiber des Infrastrukturclusters der Organisation ermöglicht, Vorgänge zu verarbeiten.

Netzwerkkomponenten wie IP-Adressenverwaltung, Ingress- und Egress-Umleitung sowie VRF-Struktur bieten Verbesserungen gegenüber der Organisationsarchitektur von Version 1 in Bezug auf Sicherheit und Benutzerfreundlichkeit des Systems.

Was ist neu bei Organisationen der Version 2?

Die Organisationsarchitektur der Version 2 führt im Vergleich zur Organisationsarchitektur der Version 1 Änderungen in mehreren Komponenten ein.

API- und Clusterarchitektur

Die V2-Organisationsarchitektur bietet nur einen Cluster für die Organisation anstelle der zwei Cluster, die in der vorherigen Architektur bereitgestellt wurden. Durch die Reduzierung der Cluster können Hardware-Ressourcen flexibler genutzt werden.

Außerdem gibt es eine Netzwerkaufteilung der Steuerungsebene und der Datenebene, die für Organisationen der Version 1 nicht verfügbar war. Der Management-API-Server oder die Steuerungsebene kann jetzt in einem Kundennetzwerk bereitgestellt werden, das sich von dem Kundennetzwerk unterscheidet, in dem die Datenebene bereitgestellt wird. Diese Trennung bietet eine optionale zusätzliche Ebene der Isolation zwischen der Bereitstellung von Cloud-Ressourcen und dem Ressourcenverbrauch. Ihre Administratoren und Entwickler sollten Verbindungen zu beiden externen Netzwerken haben.

Speicher

In der neuen Organisationsarchitektur v2 werden NetApp-Speicheranmeldedaten aus dem Nutzercluster entfernt, indem der KubeVirt-CSI-Treiber anstelle des NetApp Trident-CSI-Treibers bereitgestellt wird, der in der vorherigen Architektur verwendet wurde. Durch dieses Update des CSI-Treibers werden die direkten Berechtigungen für das Speicher-Array weiter reduziert.

Netzwerk

Die folgenden Verbesserungen am Netzwerk sind für Organisationen der Version 2 verfügbar:

Knoten-zu-Knoten-Verschlüsselung

Die Organisationsarchitektur der Version 2 bietet Verschlüsselung zwischen den Bare-Metal-Knoten der Organisation, sodass der gesamte Kundennetzwerkverkehr verschlüsselt wird, wenn er den physischen Knoten verlässt. So wird verhindert, dass Netzwerkschalter Einblick in unverschlüsselten Traffic haben.

Dedizierter Cluster für die Verarbeitung von Netzwerk-Traffic

Der Perimeter-Cluster ist ein skalierbarer virtueller Cluster, der den gesamten Ingress- und Egress-Traffic (Nord/Süd) für die Organisation verarbeitet. Dieser Cluster ermöglicht es auch, Ihr GDC-Universum in Zukunft auf skalierbarere Optionen für virtuelle Intrusion Detection and Prevention Systems (IDPS) umzustellen.

Vereinfachtes VM-Netzwerk

In der Organisationsarchitektur der Version 2 werden zwei Schnittstellen pro VM aus der vorherigen Architektur zu einer einzigen Schnittstelle zusammengeführt. VMs werden in ein standardmäßiges VPC-Netzwerkmodell (Virtual Private Cloud) verschoben. Das bedeutet, dass VMs auf Ebene 3 (L3) mit dem Netzwerk verbunden sind.

Kunden können auch eigene Subnetze definieren, was für V1-Organisationen nicht unterstützt wird.

Effiziente Nutzung und Verwaltung von IP-Adressen

Die Organisationsarchitektur der Version 2 erlaubt sich überschneidende externe IP-Adressen für Organisationen. Durch sich überschneidende externe IP-Adressen können Organisationen direkt eine Verbindung zu Kundennetzwerken herstellen. Dadurch ist kein einzelner großer externer IP-Adressbereich mehr erforderlich, der auf alle Organisationen im GDC-Universum abgestimmt ist.

IP-Adressen werden auch pro Organisation bereitgestellt, anstatt an ein einzelnes zonenbezogenes übergeordnetes Subnetz gebunden zu sein. Mit dieser Funktion können Administratoren ihre eigenen IP-Adressen angeben, anstatt dass Sie als Betreiber eine angeben müssen. Diese Funktion bietet mehr Flexibilität und Isolation für Organisationen, die eine starke Netzwerkisolation wünschen, da kein übergeordnetes Supernetzwerk gemeinsam genutzt wird.

Für Organisationen der Version 1 waren Egress-NAT-IP-Adressen einmal pro Projekt, pro Nutzercluster und pro Organisation erforderlich. Für v2-Organisationen wurde diese Anforderung deutlich verbessert: Sie gilt nur einmal pro Projekt und Organisation. Diese Änderung führt zu einer effizienteren Nutzung der vom Kunden bereitgestellten IP-Adressen.

Funktionale Unterschiede zwischen Organisationen der Version 1 und Version 2

Eine Organisation der Version 2 bietet dieselben Funktionen wie eine Organisation der Version 1. Die einzigen Funktionen, die in einer V2-Organisation nicht verfügbar sind, sind die folgenden:

  • Vertex AI
  • CLI für Datenbankdienste

Welche Architektur verwenden Organisationen mit mehreren Zonen?

Wenn Sie in einem GDC-Universum mit mehreren Zonen eine vorhandene Organisation auf eine neue Zone erweitern, muss die Organisation in der neuen Zone dieselbe Architektur wie die vorhandene Zone verwenden. Daher wird die Verwendung unterschiedlicher Organisationsstrukturen pro Zone nicht unterstützt.

v2-Organisation bereitstellen

Beim Bereitstellen einer Organisation werden standardmäßig V2-Organisationen für Kunden erstellt, die keinen Akkreditierungsverfahren unterliegen.

Organisationen der Version 2 stellen jedoch eine erhebliche architektonische Änderung dar. Für Kundenbereitstellungen, die der Akkreditierung unterliegen, bleibt die Organisationsarchitektur der Version 1 die Standardeinstellung, bis die Organisationsarchitektur der Version 2 akkreditiert ist.

Die Standardeinstellung für die Organisationsarchitektur wird durch ein Feature-Flag gesteuert, das beim Bereitstellen einer Zone konfiguriert wird.

Organisationsarchitektur erzwingen

In seltenen Fällen möchten Sie möglicherweise das Standardverhalten bei der Bereitstellung überschreiben und eine bestimmte Organisationsstruktur erzwingen. Dazu fügen Sie das Feld spec.compatibilityOptions.architectureOverridePolicy während der Bereitstellung der Ressource Organization hinzu. Weitere Informationen finden Sie auf der Seite Kundenorganisation erstellen.

Es wird davon abgeraten, die Standardarchitektur Ihrer Organisation zu überschreiben, es sei denn, Sie haben einen triftigen Grund, ein bestimmtes Verhalten zu erzwingen.

Sie können beispielsweise eine V1-Organisation erzwingen, wenn Sie ein erhebliches Problem mit einer V2-Organisation haben, das eine Aufgabe blockiert. Ebenso können Sie eine V2-Organisation erzwingen, wenn Sie eine Akkreditierung benötigen und eine einzelne V2-Organisation erforderlich ist, um den Akkreditierungsprozess zu starten. Diese Überschreibungsflags müssen entfernt werden, wenn sie nicht mehr unbedingt erforderlich sind, um die Bereitstellung von Organisationen mit der falschen Architektur in Zukunft zu vermeiden.

Was passiert mit vorhandenen V1-Organisationen?

Bestehende Organisationen, die vor GDC Air-Gapped 1.14.2 erstellt wurden, behalten dieselbe Architektur bei, auch wenn die GDC-Zone auf Version 1.14.2 oder höher aktualisiert wird. Es ist zwar kein In-Place-Upgrade zum Konvertieren von V1-Organisationen in V2-Organisationen verfügbar, aber vorhandene Funktionen in V1-Organisationen werden weiterhin unterstützt, bis die V1-Organisationsarchitektur eingestellt wird.

Neue Funktionen werden in Zukunft möglicherweise nur Organisationen mit Version 2 hinzugefügt. Wir empfehlen Ihnen daher, Ihre Arbeitslasten so schnell wie möglich von Ihren v1-Organisationen in die neue v2-Organisationsarchitektur zu migrieren. Ein einzelnes GDC-Universum ohne Internetverbindung kann beide Organisationsarchitekturen gleichzeitig enthalten, was den Übergang erleichtert.