Projekte zwischen Organisationsressourcen migrieren

Bei der Migration 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 über die Funktionsweise von Migrationen, 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.

Es kann vorkommen, dass Sie Projekte zwischen Organisationsressourcen migrieren müssen, z. B. aufgrund von Übernahmen, gesetzlichen Vorschriften oder der Trennung von Geschäftsbereichen. Sie können die Resource Manager API verwenden, um diese Projekte zu migrieren. Der Migrationsvorgang gibt einen String zurück, der den Vorgangsnamen darstellt. 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 von zwei Pfaden Sie einschlagen:

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

Wenn Sie ein Projekt wieder zu Keine Organisation verschieben müssen, nachdem es mit einer Organisationsressource verknüpft wurde, müssen Sie sich an Cloud Customer Care wenden. Ein Self-Service-Rollback von einer Organisation zu „Keine Organisation“ wird nicht unterstützt.

Neben der API können Sie Projekte auch über die Google Cloud Console verschieben, indem Sie das Projekt auswählen und ihm ein neues übergeordnetes Ziel zuweisen.

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 Google Cloud Console wahrscheinlich nicht wie erwartet unter der tatsächlichen Organisation angezeigt. 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 get-ancestors PROJECT_ID

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

Wenn die Ausgabe einen organization-Ressourcentyp in der Hierarchie enthält, ist Ihr Projekt bereits Teil einer Organisationshierarchie.

Wenn der Typ organization fehlt oder leer ist, ist das Projekt 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 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 der Sicherheitsstatus des Projekts, sobald es an ein neues übergeordnetes Element angehängt wird.

Funktion Status Auswirkungen
Projekt-ID und ‑nummer Bleiben gleich API-Schlüssel, Dienstnamen und fest codierte IDs bleiben unverändert.
Daten und Ressourcen Bleiben gleich VMs, Storage-Buckets und Datenbanken bleiben online.
Direkte IAM-Rollen Bleiben 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 oder Kontingentüberschreibungen.

Auf den folgenden Seiten können Sie ermitteln, welche Kontingente auf eine Organisationsressource angewendet werden:

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 mit der Migration beginnen, sollten Sie diese Bereiche mit hohem Risiko prüfen, um Dienstunterbrechungen zu vermeiden:

  • Kontingentlimits: Wenn die Zielorganisation niedrigere Kontingentlimits als die Quellorganisation hat, kann Ihr Projekt nach der Migration sein Kontingent überschreiten.

  • Asset Inventory: Es kann einige Tage dauern, bis alle Aktualisierungen der vollständigen Liste der Ressourcen in Cloud Asset Inventory nach der Migration vollständig übernommen wurden.

  • Kosten und Rabatte: Wenn die ursprüngliche Organisation SKU-basierte Rabatte oder Rabatte im Rahmen des Enterprise Discount Program (EDP) hatte, gelten diese Rabatte in der neuen Organisation erst, nachdem Sie sie mit Ihrem Google-Vertriebsmitarbeiter ausgehandelt haben. Rabatte für zugesicherte Nutzung (Committed Use Discounts, CUDs) und Google Cloud Marketplace-Käufe müssen möglicherweise neu erworben werden.

  • Supportstufen: Wenn in der Zielorganisation kein aktiver Supportvertrag oder eine niedrigere Supportstufe vorhanden ist, verlieren Sie möglicherweise Ihre aktuelle Supportstufe.

  • Benutzerdefinierte Rollen: Wenn Ihr Projekt auf benutzerdefinierten IAM-Rollen basiert, die auf Organisationsebene definiert wurden, 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 sich durch den Prozess der Projektmigration zu bewegen:

  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. Überprüfen: Führen Sie Aufgaben nach der Migration aus, z. B. geerbte Richtlinien prüfen und Abrechnung aktualisieren.

Nächste Schritte