Projekte zu einer anderen Organisation migrieren

Projektressourcen der Google Cloud Platform (GCP) können nur dann in eine Organisation migriert werden, wenn sie gerade keiner Organisation zugeordnet sind. In dieser Anleitung erfahren Sie, wie Sie zusammen mit dem Google-Support Projekte, die bereits einer Organisation zugeordnet sind, in eine andere Organisation migrieren.

Dabei wird davon ausgegangen, dass die Zielorganisation der Quellorganisation sehr ähnlich ist. Größere Designanstrengungen zum Einbinden von Anwendungen in ein neues System werden in dieser Anleitung nicht behandelt.

Migration planen und ausführen

Schritt 1: Projekte vorbereiten

Das Migrieren eines Projekts von einer Organisation in eine andere ist ein manueller Supportprozess, für den eine Projektkonfiguration erforderlich ist.

Bereiten Sie das Migrieren Ihrer Projektressource anhand der folgenden Liste vor:

  • Wenn Sie für das Google-Konto Ihrer Organisation die primäre Domain geändert haben, geben Sie diese Informationen an, wenn Sie beim Google-Support einen Fall öffnen.
  • Deaktivieren Sie das freigegebene VPC-Netzwerk in dem Projekt, das verschoben werden soll.
  • Konfigurieren Sie alle benutzerdefinierten Rollen von Cloud Identity and Access Management auf Organisationsebene, die Sie auf der Ebene des zu verschiebenden Projekts benötigen. Weitere Informationen finden Sie unter Benutzerdefinierte Cloud IAM-Rollen.
  • Legen Sie alle Organisationsrichtlinien so fest, dass sie Richtlinieninhalte von der übergeordneten Ressource übernehmen. Überprüfen Sie außerdem die Richtlinien vorab, damit Sie wissen, wie sie sich nach der Migration auswirken. Weitere Informationen finden Sie unten im Abschnitt Organisationsrichtlinien.
  • Legen Sie das E-Mail-Routing für die mit der Zielorganisation verknüpfte primäre Domain so fest, dass Sie die Inhaberschaft für die neue Projektressource annehmen können.
  • Weisen Sie die Cloud IAM-Rollen zu, die Sie für die Zielorganisationsressource benötigen. Beispiel: roles/resourcemanager.projectCreator. Alle übernommenen Rollen werden entfernt, nachdem das Projekt zur Zielorganisation migriert wurde.
  • Wenn Sie die domaineingeschränkte Freigabe in der Zielorganisation verwenden, setzen Sie die Domains, die Zugriff auf Ressourcen in der Quellorganisation haben, auf die weiße Liste der Zielorganisation.

Schritt 2: Supportfall öffnen

Wenn Google Professional Services (PSO) in Ihrem Serviceplan enthalten ist, sollten Sie Ihre Projektmigration mit dem PSO-Team planen. Ein Google Technical Account Manager (TAM) kann die relevanten Parteien aufseiten von Google koordinieren.

Zum Starten des Migrationsprozesses öffnen Sie einen Supportfall und geben Folgendes an:

  1. Eine Liste der Projekt-IDs für jede Projektressource, die verschoben werden soll.
  2. Wenn Sie mit PSO an Ihrem Migrationsplan arbeiten, geben Sie über Hangouts ein Datum und eine Uhrzeit für ein Meeting mit dem Google-Support und PSO an. Der TAM wird das Meeting zum Ausarbeiten Ihres Plans arrangieren.

Der Google-Support entfernt die von Ihnen aufgelisteten Projektressourcen aus der aktuellen Organisation und benachrichtigt Sie, wenn dieser Vorgang abgeschlossen ist. Sie können dann die Migration ausführen.

Schritt 3: Migration ausführen

So schließen Sie die Migration ab:

  1. Verschieben Sie die Projekte in die neue Organisation, nachdem Google diese aus der übergeordneten Organisation entfernt hat.
  2. Aktualisieren Sie die Dienstkonfiguration für Ihre Projekte auf Basis der neuen Organisationshierarchie. Einzelheiten finden Sie in den folgenden Abschnitten zum Thema Dienste.

Risiko von Dienstproblemen mindern

GCP-Projektressourcen bilden die Grundlage für die Nutzung aller GCP-Dienste. Projektressourcen sind bei vielen Funktionen auf die Organisationsressource angewiesen. Diese Funktionen können ausfallen, wenn Sie eine Projektressource von einer Organisation in eine andere verschieben. Daher sollten Sie für jeden Dienst, der von den zu verschiebenden Projektressourcen verwendet wird, Strategien zur Risikominderung planen.

Benutzerdefinierte Cloud IAM-Rollen

Benutzerdefinierte Cloud IAM-Rollen können auf Organisationsebene in der GCP-Ressourcenhierarchie erstellt werden. Mit diesen Rollen kann Nutzern, die sich in der Hierarchie unterhalb der Organisationsressource befinden, Zugriff gewährt werden. Wenn ein Projekt aus der Organisation verschoben wird, werden auf Organisationsebene konfigurierte benutzerdefinierte Rollen nicht verschoben, auf Projektebene konfigurierte benutzerdefinierte Rollen jedoch schon.

Benutzerdefinierte Rollen auf Organisationsebene, die nicht verschoben werden, funktionieren nicht mehr. Die Methode getIamPolicy gibt diese benutzerdefinierten Rollen dann nicht mehr als Teil der Cloud IAM-Richtlinie zurück.

Beim Verschieben eines Projekts mit benutzerdefinierten Rollen wirken sich einige der ursprünglichen Organisationsrichtlinien möglicherweise noch auf das Projekt aus. Wenn eine benutzerdefinierte Rolle aus der alten Organisation in der neuen Cloud IAM-Richtlinie vorhanden ist, kann dies die Richtlinie ungültig machen und Fehler verursachen, wenn Sie die Richtlinie aktualisieren. Dieses Problem ist wahrscheinlich nicht unmittelbar nach der Migration ersichtlich, da es erst auftritt, wenn die Cloud IAM-Richtlinie aktualisiert wird.

So listen Sie vorhandene benutzerdefinierte Rollen auf Organisationsebene auf:

gcloud iam roles list --organization ORGANIZATION_ID

So beschreiben Sie eine bestimmte benutzerdefinierte Rolle in einer Organisation:

gcloud iam roles describe --organization ORGANIZATION_ID /
ROLE_NAME

Dabei gilt:

Risikominderung

So verringern Sie das Fehlerrisiko in Zusammenhang mit vorhandenen benutzerdefinierten Cloud IAM-Rollen:

  1. Rufen Sie mit der Methode projects.getIamPolicy die Cloud IAM-Richtlinie für das Projekt ab, das Sie verschieben möchten.
  2. Erstellen Sie für jede benutzerdefinierte Rolle auf Organisationsebene in der Cloud IAM-Richtlinie des Projekts eine entsprechende benutzerdefinierte Rolle auf Projektebene und aktualisieren Sie die Cloud IAM-Richtlinie des Projekts so, dass diese neuen Rollen verwendet werden.
    1. Wenn Sie Ihr Projektkontingent erhöhen müssen, senden Sie eine Anfrage zur Kontingenterhöhung.
  3. Entfernen Sie die Bindungen der benutzerdefinierten Cloud IAM-Rollen auf Organisationsebene aus den zu verschiebenden Projekten.
  4. Migrieren Sie die Projekte wie oben beschrieben.
  5. Aktualisieren Sie die Cloud IAM-Richtlinien der Ressourcen in den verschobenen Projekten so, dass die benutzerdefinierten Rollen aus der Zielorganisation verwendet werden.

Weitere Informationen finden Sie unter Benutzerdefinierte Rollen erstellen und verwalten.

Freigegebene VPCs

Freigegebene VPCs auf der GCP verwenden die Organisationsressource zum Gruppieren. Projektressourcen können nur mit freigegebenen VPCs in derselben Organisation verbunden werden. Ein Projekt, das in eine neue Organisation verschoben wird, verliert die Verbindung zur freigegebenen VPC.

Freigegebene VPCs werden mithilfe eines Hostprojekts implementiert, in dem die freigegebenen VPCs bereitgestellt werden. Dienstprojekte dürfen die freigegebenen VPCs verwenden.

Virtuelle Maschinen (VMs) von Compute Engine können nicht direkt von einer VPC in eine andere verschoben werden und müssen migriert oder neu erstellt werden. VMs werden normalerweise in den Dienstprojekten der freigegebenen VPC bereitgestellt und nicht direkt im Hostprojekt der freigegebenen VPC.

So listen Sie alle Hostprojekte von freigegebenen VPCs in einer Organisationsressource auf:

gcloud beta compute shared-vpc organizations list-host-projects
ORGANIZATION_ID

Dabei ist ORGANIZATION_ID Ihre Organisations-ID.

Risikominderung

  1. Rufen Sie in der GCP Console die Seite Freigegebene VPC auf.
    Zur Seite "Freigegebene VPC"
  2. Erstellen Sie eine Liste der Hostprojekte, der freigegebenen VPC-Netzwerke und von allen verbundenen Dienstprojekten, die auf der Seite Freigegebene VPC angezeigt werden.
    1. Wenn Sie alle Projekte in einer Organisation migrieren, listen Sie alle Hostprojekte von freigegebenen VPCs mit dem oben gezeigten Befehl list-host-projects auf.
  3. Stellen Sie äquivalente Hostprojekte und freigegebene VPCs in der neuen Organisation bereit. Eine ausführliche Anleitung finden Sie unter Freigegebene VPC einrichten.
  4. Entfernen Sie die zu verschiebenden Projekte aus den freigegebenen VPCs in der Quellorganisation:
    1. Erstellen Sie Snapshots der VM-Laufwerke, die mit der freigegebenen VPC verbunden sind.
    2. Fahren Sie die VMs herunter, die Verbindungen zur freigegebenen VPC haben.
    3. Löschen Sie die VMs.
    4. Entfernen Sie alle internen Load-Balancer, die mit der freigegebenen VPC verbunden sind.
  5. Stellen Sie die VMs aus den Snapshots wieder her und stellen Sie eine Verbindung zu einer lokalen VPC im Dienstprojekt her.
  6. Führen Sie die Migration aus.
  7. Verbinden Sie Ihre verschobenen Projekte mit den neuen freigegebenen VPCs.

VPC-Peering

Projekte, die Google-VPC-Peering verwenden, können zwischen Organisationen verschoben werden, da VPC-Peering nicht von der Organisationsmitgliedschaft abhängig ist und weiterhin funktioniert. Dies bedeutet, dass beim Verschieben eines Projekts in eine Organisation mit aktiviertem VPC-Peering das Peering für dieses Projekt aktiviert wird.

Risikominderung

Wenn Sie ein Projekt in eine Organisation mit aktiviertem VPC-Peering verschieben, müssen Sie vor der Migration prüfen, was sich am anderen Ende dieses Peerings befindet und ob Sie VPC-Peering für das Projekt aktivieren möchten.

Cloud Interconnect

Projekte, die ein Dedicated Interconnect enthalten, können nur dann in eine neue Organisation verschoben werden, wenn für Cloud Interconnect keine VLAN-Anhänge definiert wurden.

Risikominderung

Entfernen Sie vor der Migration alle VLAN-Anhänge aus den Projekten, die verschoben werden sollen.

Umbenannte Domains

Wenn für die Quellorganisation jemals der Domainname geändert wurde, müssen von Google unter Umständen zusätzliche Schritte ausgeführt werden, um Projekte aus dieser Organisation zu migrieren.

Risikominderung

Wenn Sie zum Migrieren Ihrer Projekte einen Supportfall öffnen, geben Sie die Details des Domainänderungsvorgangs an, darunter den ursprünglichen und den neuen Domainnamen. Google hat Tools für dieses Szenario, benötigt jedoch möglicherweise mehr Zeit, um die Migration vorzunehmen.

Organisationsrichtlinien

Durch das Verschieben eines Projekts in eine neue Organisation werden möglicherweise die auf dieses Projekt angewendeten Richtlinien durch Übernahme geändert. Die Richtlinien in der Quellorganisation können von den Richtlinien in der Zielorganisation abweichen und die gültige Organisationsrichtlinie kann sich nach der Migration anders auf Ihr Projekt auswirken.

Risikominderung

Legen Sie die Organisationsrichtlinie für jedes zu verschiebende Projekt so fest, dass der Richtlinieninhalt von der übergeordneten Ressource übernommen wird. Prüfen Sie die Richtlinien vorab, sodass Sie einen neuen Satz von Organisationsrichtlinien planen und erstellen können, der die von Ihnen gewünschte gültige Richtlinie in der neuen Organisation beinhaltet.

Weitere Einzelheiten zur Übernahme von Organisationsrichtlinien finden Sie unter Informationen zu Evaluierungen der Hierarchie.

Cloud Billing

Cloud Billing-Konten können organisationsübergreifend verwendet werden. Das Verschieben eines Projekts von einer Organisation in eine andere wirkt sich nicht auf die Abrechnung aus und das alte Rechnungskonto wird weiterhin belastet. Allerdings setzt das Verschieben von Organisationen oft einen Wechsel zu einem neuen Rechnungskonto voraus.

Rechnungskonto für ein Projekt ändern

Zum Ändern des Rechnungskontos für ein vorhandenes Projekt müssen Sie die Rolle roles/owner für das Projekt und die Rolle roles/billing.admin für das Zielrechnungskonto haben. So ändern Sie das Rechnungskonto:

  1. Rufen Sie in der GCP Console die Seite Abrechnung auf.
    Zur Seite "Abrechnung"
  2. Klicken Sie auf den Namen des Rechnungskontos, das Sie ändern möchten.
  3. Suchen Sie unter Mit diesem Rechnungskonto verknüpfte Projekte nach dem Namen des zu verschiebenden Projekts und klicken Sie dann rechts auf die Menüschaltfläche.
  4. Klicken Sie auf Abrechnung ändern und wählen Sie das neue Rechnungskonto aus.
  5. Klicken Sie auf Konto festlegen.

Bereits angefallene Gebühren, die noch nicht im Transaktionsverlauf aufgeführt sind, werden dem vorherigen Rechnungskonto belastet. Dazu können Gebühren gehören, die bis zu zwei Tage vor dem Verschieben des Projekts angefallen sind.

Rechnungskonto zwischen Organisationen verschieben

Ein Rechnungskonto kann von einer Organisation in eine andere verschoben werden, obwohl dies nicht oft notwendig ist. Die meisten vorhandenen Organisationen haben bereits ein Rechnungskonto, das stattdessen verwendet werden sollte. Wenn Sie ein vorhandenes Rechnungskonto migrieren müssen, gehen Sie so vor:

  1. Lassen Sie sich die notwendigen Berechtigungen für die Migration erteilen:
    1. role/resourcemanager.organizationAdmin in der Quellorganisation.
    2. roles/billing.admin für die Quellorganisation oder die jeweiligen Rechnungskonten, die verschoben werden sollen.
    3. role/resourcemanager.organizationAdmin für die Zielorganisation.
    4. Entweder roles/billing.admin oder roles/billing.creator in der Zielorganisation.
  2. Rufen Sie in der GCP Console die Seite Abrechnung auf.
    Zur Seite "Abrechnung"
  3. Klicken Sie auf den Namen des Rechnungskontos, das Sie verschieben möchten.
  4. Klicken Sie oben auf der Seite Übersicht auf Organisation ändern.
  5. Wählen Sie die Zielorganisation aus und klicken Sie auf OK.

Das Rechnungskonto ist jetzt mit der angegebenen Organisation verknüpft.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Dokumentation zu Resource Manager