Projekte zwischen Organisationsressourcen migrieren

Sie können ein Cloud de Confiance by S3NS -Projekt an einen neuen Speicherort in Ihrer Ressourcenhierarchie verschieben, indem Sie die Metadaten aktualisieren. Bevor Sie ein Projekt zu einer neuen Organisation migrieren, sollten Sie sich ansehen, wie sich die Migration auf Projektressourcen und -konfigurationen auswirkt.

Projekte in der Ressourcenhierarchie

Die Projektressource ist die unterste Organisationseinheit in einer Organisationsressource von Cloud de Confiance by S3NS. Projekte werden unter Organisationsressourcen erstellt und können in Ordnern oder der Organisationsressource selbst platziert werden. Dadurch entsteht die Ressourcenhierarchie.

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 ein Rollback einer Migration durchführen und das Projekt bei Bedarf an seine ursprüngliche Position in der Hierarchie zurücksetzen.

Migrationsszenarien

Der Standort Ihres Projekts bestimmt, welchen der beiden Pfade Sie wählen:

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

Wenn Sie ein Projekt zurück zu Keine Organisation verschieben müssen, nachdem es mit einer Organisationsressource verknüpft wurde, wenden Sie sich an Cloud Customer Care. Ein Selfservice-Rollback von einer Organisation zurück zu keiner Organisation wird nicht unterstützt.

Zusätzlich zur API können Sie auch die Cloud de Confiance Console verwenden, um Projekte zu verschieben. Wählen Sie dazu das Projekt aus und weisen Sie ihm ein neues übergeordnetes Ziel zu.

Aktuellen Status des Projekts ermitteln

Bevor Sie beginnen, müssen Sie feststellen, ob Ihr Projekt mit einer Organisationsressource verknüpft ist. Davon hängt ab, ob Sie den Pfad Von Organisation zu Organisation oder den Pfad Keine Organisation verwenden.

Wenn Sie nicht die Berechtigung resourcemanager.organizations.get für die übergeordnete Organisationsressource des Projekts haben, werden Ihre Projekte wahrscheinlich nicht wie erwartet unter der tatsächlichen Organisation in derCloud de Confiance Console angezeigt. Dadurch kann es so aussehen, als wäre das Projekt mit keiner Organisationsressource verknüpft.

Führen Sie den folgenden Befehl aus, um festzustellen, 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 Ressourcentyp organization 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

Eine Projektmigration ist keine Datenübertragung. 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 Cloud de Confiance by S3NS 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 Projektnummer Bleibt gleich API-Schlüssel, Dienstnamen und hartcodierte 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 ihm verschoben.
Übernommene 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 Übernommene 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 das Kontingent

Wenn Sie Kontingente auf einer bestimmten Ressourcenebene definiert haben, gilt nach der Migration Folgendes:

  • Alle auf Projektebene definierten Kontingente bleiben unverändert.
  • Kontingente, die auf Ebene der Organisationsressource definiert sind, werden nicht übertragen. Die Organisation verliert alle übernommenen Kontingente oder Kontingentüberschreibungen.

Auf den folgenden Seiten können Sie feststellen, 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

Prüfen Sie vor Beginn einer Migration die folgenden Bereiche mit hohem Risiko, um Dienstunterbrechungen zu vermeiden:

  • Kontingentlimits: Wenn die Zielorganisation niedrigere Kontingentlimits als die Quelle hat, kann Ihr Projekt bei der Ankunft das Kontingent überschreiten.

  • Asset Inventory: Es kann einige Tage dauern, bis die vollständige Liste der Ressourcen in Cloud Asset Inventory nach der Migration vollständig aktualisiert ist.

  • 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, wenn Sie sie mit Ihrem Google-Vertriebsmitarbeiter ausgehandelt haben. Rabatte für zugesicherte Nutzung (CUDs) und Google Cloud Marketplace-Käufe müssen möglicherweise ebenfalls 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 sind, sind diese Rollen im Ziel nicht vorhanden. Erstellen Sie sie vor dem Verschieben in der Zielorganisation neu.

Die Migrations-Roadmap

Verwenden Sie die folgende Roadmap, um sich im Projektmigrationsprozess zurechtzufinden:

  1. Vorbereiten: Erstellen Sie einen Migrationsplan, um den Zeitplan zu koordinieren.
  2. Ausführen: IAM-Rollen zuweisen, Organisationsrichtlinien konfigurieren und Migration ausführen.
  3. Prüfen: Führen Sie Aufgaben nach der Migration aus, z. B. die Prüfung übernommener Richtlinien und die Aktualisierung der Abrechnung.

Nächste Schritte