Projekte zwischen Organisationsressourcen migrieren

Die Migration eines Cloud de Confiance by S3NS -Projekts ist ein Metadatenvorgang, bei dem der Speicherort des Projekts in der Ressourcenhierarchie geändert wird. Auf dieser Seite finden Sie einen Überblick 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 unterste Organisationseinheit in einer Cloud de Confiance by S3NSOrganisationsressource. Projekte werden unter Organisationsressourcen erstellt und können in Ordnern oder der Organisationsressource selbst platziert werden, die die Ressourcenhierarchie bilden.

Es kann vorkommen, dass Sie Projekte zwischen Ressourcen von Organisationen 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. 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 Standort Ihres Projekts bestimmt, welchen der beiden Wege Sie einschlagen:

  • Projekte von einer Organisation zu einer anderen Organisationsressource migrieren
  • Migrieren Sie ein eigenständiges Projekt (das ohne Organisation erstellt wurde) in die Hierarchie einer Organisationsressource.

Aktuellen Status des Projekts ermitteln

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

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

Führen Sie den folgenden Befehl aus, um festzustellen, 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 das Feld parent enthält, ist Ihr Projekt bereits Teil einer Organisationshierarchie.

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

Folgen Sie je nach Status Ihres Projekts dem entsprechenden Leitfaden:

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 die übergeordnete Ressource des Projekts aktualisiert. Da Cloud de Confiance by S3NS einem hierarchischen Vererbungsmodell folgt, ändert sich die Sicherheitslage des Projekts, sobald es an ein neues übergeordnetes Element angehängt wird.

Funktion Status Auswirkungen
Projekt-ID und ‑Nummer 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 dem Projekt verschoben.
Übernommene IAM-Rollen Änderungen Rollen, die auf Ebene der Quellorganisation oder des Quellordners zugewiesen 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 das Kontingent

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

  • Alle auf Projektebene definierten Kontingente bleiben unverändert.
  • Kontingente, die auf Organisationsebene definiert sind, werden nicht übertragen. Die Organisation verliert alle übernommenen Kontingente.

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

Sehen Sie sich vor dem Start einer Migration diese Bereiche mit hohem Risiko an, um Dienstunterbrechungen zu vermeiden:

  • Kontingentlimits: Wenn die Zielorganisation niedrigere Kontingentlimits als die Quelle hat, überschreitet Ihr Projekt möglicherweise sein Kontingent nach der Migration.

  • Freigegebene VPC: Sie können kein Projekt migrieren, das an eine freigegebene VPC angehängt ist. Sie müssen das Projekt von der freigegebene VPC der Quelle 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 die Daten übertragen.

Roadmap für die Migration

Anhand der folgenden Roadmap können Sie den Migrationsprozess für Projekte 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 durch.
  3. Prüfen: Führen Sie Aufgaben nach der Migration aus, z. B. die Überprüfung übernommener Richtlinien und die Aktualisierung der Abrechnung.

Nächste Schritte