Projekte zwischen Organisationsressourcen migrieren

Beim Migrieren eines Google Cloud Projekts handelt es sich um einen Metadatenvorgang, bei dem der Speicherort des Projekts in der Ressourcenhierarchie geändert wird. Auf dieser Seite finden Sie eine Übersicht darüber, wie Migrationen funktionieren, was gleich bleibt und was sich ändert, wenn ein Projekt in eine neue Organisation verschoben wird.

Projekte in der Ressourcenhierarchie

Die Projektressource ist die grundlegende Organisationseinheit in einer Google Cloud Organisationsressource. Projekte werden unter Organisationsressourcen erstellt und können in Ordnern oder der Organisationsressource selbst platziert werden, die die Ressourcenhierarchiebilden.

Möglicherweise müssen Sie Projekte aufgrund von Übernahmen, gesetzlichen Anforderungen oder der Trennung von Geschäftseinheiten zwischen Organisationsressourcen migrieren. Sie können die Resource Manager API verwenden, um diese Projekte zu migrieren. Mit der API können Sie auch eine Migration rückgängig machen und das Projekt bei Bedarf an seinen ursprünglichen Speicherort in der Hierarchie verschieben.

Migrationsszenarien

Der Speicherort Ihres Projekts bestimmt, welchen der beiden Pfade Sie verwenden:

  • Projekte von einer Organisation zu einer anderen Organisationsressource migrieren
  • Ein eigenständiges Projekt (ohne Organisation erstellt) in die Hierarchie einer Organisationsressource migrieren

Aktuellen Status des Projekts ermitteln

Bevor Sie beginnen, müssen Sie feststellen, ob Ihr Projekt mit einer Organisationsressource verknüpft ist. Dadurch wird bestimmt, ob Sie den Pfad Organisation zu Organisation oder Keine Organisation verwenden.

Wenn Sie nicht die Berechtigung resourcemanager.organizations.get für die übergeordnete Organisationsressource des Projekts haben, werden Ihre Projekte in der Konsole wahrscheinlich nicht wie erwartet unter der tatsächlichen Organisation angezeigt. Google Cloud Dies kann den Anschein erwecken, dass das Projekt mit keiner Organisationsressource verknüpft ist.

Führen Sie den folgenden Befehl aus, um zu ermitteln, ob das Projekt mit einer Organisationsressource verknüpft ist:

gcloud 

gcloud projects describe PROJECT_ID

Ersetzen Sie PROJECT_ID durch die ID des Projekts, das Sie migrieren möchten.

Wenn die Ausgabe ein Feld parent enthält, ist Ihr Projekt bereits Teil einer Organisationshierarchie.

Wenn das Feld parent fehlt oder leer ist, handelt es sich um ein eigenständiges Projekt ohne Organisationsressource.

Folgen Sie je nach Status Ihres Projekts der entsprechenden Anleitung:

Funktionsweise der Migration

Bei einer Projektmigration werden keine Daten übertragen. Ihre Dienste, Datenbanken und VM-Instanzen (virtuelle Maschinen) bleiben aktiv und es kommt zu keinen Ausfallzeiten. Stattdessen wird bei der Migration die übergeordnete Ressource des Projekts aktualisiert. Da Google Cloud ein hierarchisches Vererbungsmodell verwendet, ändert sich die Sicherheitskonfiguration des Projekts, sobald es an eine neue übergeordnete Ressource angehängt wird.

Funktion Status Auswirkungen
Projekt-ID und ‑nummer Bleibt gleich API-Schlüssel, Dienstnamen und fest codierte IDs bleiben unverändert.
Daten und Ressourcen Bleibt gleich VMs, Storage-Buckets und Datenbanken bleiben online.
Direkte IAM-Rollen Bleibt gleich Rollen, die direkt für das Projekt gewährt wurden, werden mit dem Projekt verschoben.
Geerbte IAM-Rollen Änderungen Rollen, die auf der Ebene der Quellorganisation oder des Quellordners gewährt wurden, gehen verloren.
Organisationsrichtlinien Änderungen Quellbeschränkungen werden durch Zielbeschränkungen ersetzt.
Kontingente Änderungen Geerbte Kontingente auf Organisationsebene gehen verloren. Kontingente auf Projektebene bleiben erhalten.
Rechnungskonto Bleibt gleich Das Projekt bleibt mit dem ursprünglichen Rechnungskonto verknüpft.

Auswirkungen auf Kontingente

Wenn Sie Kontingente auf einer bestimmten Ressourcenebene definiert haben, gelten nach der Migration die folgenden Aspekte:

  • Alle auf Projektebene definierten Kontingente bleiben unverändert.
  • Alle auf Organisationsebene definierten Kontingente werden nicht übertragen. Die Organisation verliert alle geerbten Kontingente.

Auf den folgenden Seiten können Sie ermitteln, welche Kontingente für eine Organisationsressource gelten:

Beispiel

$ gcloud alpha services quota list --service=compute.googleapis.com --consumer=projects/workloadyee --filter="metric: compute.googleapis.com/cpus"

...
  - defaultLimit: '600'
    dimensions:
      region: us-central1
    effectiveLimit: '650'
...

Wichtige Überlegungen

Bevor Sie eine Migration starten, sollten Sie diese Bereiche mit hohem Risiko prüfen, um Dienstunterbrechungen zu vermeiden:

  • Kontingentlimits: Wenn die Zielorganisation niedrigere Kontingentlimits als die Quellorganisation hat, kann das Kontingent Ihres Projekts nach der Migration überschritten werden.

  • Freigegebene VPC: Sie können kein Projekt migrieren, das an eine freigegebene VPC angehängt ist. Sie müssen das Projekt von der freigegebenen Quell-VPC trennen, bevor Sie es verschieben.

  • Benutzerdefinierte Rollen: Wenn Ihr Projekt auf benutzerdefinierten IAM-Rollen basiert, die auf Organisationsebene definiert sind, sind diese Rollen im Ziel nicht vorhanden. Erstellen Sie sie in der Zielorganisation neu, bevor Sie das Projekt verschieben.

Roadmap für die Migration

Verwenden Sie die folgende Roadmap, um den Prozess der Projektmigration zu durchlaufen:

  1. Vorbereiten: Erstellen Sie einen Migrationsplan, um den Zeitplan zu koordinieren.
  2. Ausführen: Weisen Sie IAM-Rollen zu, konfigurieren Sie Organisationsrichtlinien und führen Sie die Migration aus.
  3. Prüfen: Führen Sie Aufgaben nach der Migration aus, z. B. geerbte Richtlinien prüfen und die Abrechnung aktualisieren.

Nächste Schritte