Auf dieser Seite wird beschrieben, wie Sie eine Apigee Hybrid-Organisation von einem Kubernetes-Cluster zu einem anderen migrieren. In folgenden Fällen müssen Sie eine Organisation möglicherweise zu einem anderen Cluster migrieren:
Das Rechenzentrum, in dem der vorhandene Cluster gehostet wird, hat keine Kapazität mehr oder wird außer Betrieb genommen.
Der Cluster führt eine alte Infrastruktur oder eine alte Version von Kubernetes aus und Sie möchten zu einem Cluster mit neuerer Infrastruktur migrieren.
Sie möchten Organisationen aus Multi-Organisations-Clustern in separate Cluster verschieben.
Beachten Sie, dass bei der Migration einer Organisation in einen anderen Hybridcluster Risiken und Einschränkungen bestehen.
Lesen Sie die Details im Abschnitt Einschränkungen, bevor Sie eine Migration ausführen.
Beschränkungen
Die folgenden Einschränkungen gelten bei der Migration einer Hybridorganisation zu einem anderen Kubernetes-Cluster:
Wenn Sie Organisationsdaten in einen neuen Kubernetes-Cluster verschieben, besteht das Risiko eines Datenverlusts.
Sie sollten die Daten für alle Organisationen im Kubernetes-Cluster sichern. Verwenden Sie dazu die Anleitung zur Hybridsicherung, bevor Sie eine Organisation migrieren.
Die maximale Datengröße, die für die Organisationsmigration unterstützt wird, beträgt 5 GB für alle Schlüsselbereiche einer Organisation, ohne Cache und Kontingent.
Cache-Daten werden nicht migriert. Hybrid erstellt Cache-Daten neu.
Kontingentdaten werden nicht migriert. Hybrid setzt Kontingentdaten zurück.
Sie können Organisationen nur zu einem Kubernetes-Cluster migrieren, der keine vorhandene Hybridbereitstellung enthält.
Die Migration zu einem Cluster mit einer vorhandenen Hybridbereitstellung wird nicht unterstützt.
Die zu migrierende Organisation kann nur in einen neuen Cluster mit einer einzigen Regionsbereitstellung verschoben werden.
Nachdem die Bereitstellung für eine einzelne Region abgeschlossen ist, können Sie den Vorgang der Regionserweiterung ausführen, wie unter Multiregionale Bereitstellung beschrieben, um auf andere Regionen zu erweitern.
Der Cassandra-Cluster sollte in allen Regionen fehlerfrei funktionieren.
Organisation migrieren
Folgen Sie der Anleitung unten, um eine Hybridorganisation von einem Kubernetes-Cluster in einen anderen zu migrieren:
Wenn nicht bereits aktiviert, aktivieren Sie Sicherungen im Kubernetes-Cluster mit der zu migrierenden Hybridorganisation. Weitere Informationen zu Hybridsicherungen finden Sie unter Cassandra-Sicherungsübersicht.
Starten Sie den Hybrid-Sicherungsjob mit dem folgenden Befehl:
<backup job name> kann ein beliebiger gültiger Containername sein.
Nachdem der Sicherungsjob abgeschlossen ist, prüfen Sie anhand der Anleitung in den folgenden Abschnitten unter Sicherungen überwachen, ob die Sicherung erfolgreich abgeschlossen wurde:
„Status des Sicherungsjobs prüfen“
„Sicherungslogs prüfen“
Nachdem Sie überprüft haben, ob die Sicherung erfolgreich war, notieren Sie sich die ID-Nummer am Ende des Sicherungslogs.
Ein erfolgreiches Sicherungslog sollte beispielsweise eine Zeile wie die folgende enthalten:
INFO: completed upload for 20230207004250
Notieren Sie sich die mehrstellige Nummer am Zeilenende. Sie benötigen diese Nummer später.
Wechseln Sie den Kubernetes-Kontext zum Kubernetes-Zielcluster:
Verwenden Sie die Datei overrides.yaml für die Organisation, die zur Bereitstellung in der Ziel-Hybrid migriert wird.
Denken Sie daran, den Wert restore:snapshotTimestamp auf die mehrstellige Zahl zu setzen, die im Sicherungslog in Schritt 4 angezeigt wird. Siehe
In einer einzelnen Region wiederherstellen.
Löschen Sie nach Abschluss der Wiederherstellung alle Organisationsdaten mit Ausnahme der Daten für die Organisation, die migriert wird, aus dem Kubernetes-Zielcluster. Hybrid-Sicherungsdateien enthalten die Daten für alle Organisationen, einschließlich derjenigen, die Sie möglicherweise nicht migrieren möchten. Nachdem die Ziel-Hybridbereitstellung wiederhergestellt wurde, müssen Sie alle zusätzlichen Organisationsdaten entfernen, die in die Bereitstellung kopiert wurden. Gehen Sie dazu so vor:
Prüfen Sie, ob der aktuelle Kontext der richtige Kontext für den Kubernetes-Zielcluster ist:
kubectl config current-context
Führen Sie den Pod apigee-cassandra-default-0 aus:
Kopieren Sie die Liste aller Namen, die in der Ausgabe angezeigt werden. Diese Liste benötigen Sie in Schritt 7. f.
Beenden Sie den apigee-cassandra-default-0-Pod.
Erstellen Sie einen Cassandra-Debugging-Client-Pod mithilfe der Anleitung unter
Client-Container zur Fehlerbehebung erstellen. Fahren Sie mit dem nächsten Schritt fort, nachdem Sie eine cqlsh-Eingabeaufforderung erhalten haben.
Führen Sie die folgenden Befehle in der Eingabeaufforderung cqlsh aus:
desc keyspaces;
Achten Sie darauf, dass dieser Befehl keine Fehler zurückgibt.
Führen Sie für jeden Namen in der in Schritt 7 erstellten Liste den folgenden Befehl aus:
drop keyspace <name>
Beenden Sie den Cassandra-Debugging-Client-Pod.
Führen Sie nach der Ausführung der cqlsh-Befehle die folgenden Befehle auf allen Cassandra-Pods im Kubernetes-Zielcluster aus:
Wechseln Sie den Kubernetes-Kontext zum Kubernetes-Quellcluster:
kubectl config use-context <source cluster name>
Dabei ist <source cluster name> der Name des Kubernetes-Quellclusters.
Löschen Sie die migrierte Organisation aus dem Kubernetes-Quellcluster. Achten Sie darauf, für die Organisation die Datei overrides.yaml im Löschbefehl zu verwenden:
Prüfen Sie, ob der aktuelle Kontext der richtige Kontext für den Kubernetes-Quellcluster ist:
kubectl config current-context
apigeectl delete --settings virtualhost -f
apigeectl delete --all-envs -f <overrides.yaml>
apigeectl delete -f <overrides.yaml> --org
Führen Sie den Pod "apigee-cassandra-default-0" aus:
Kopieren Sie die Liste aller Namen, die in der Ausgabe angezeigt werden. Sie benötigen diese Liste in Schritt 9. j.
Beenden Sie den apigee-cassandra-default-0-Pod.
Erstellen Sie einen Cassandra-Debugging-Client-Pod mithilfe der Anleitung unter
Client-Container zur Fehlerbehebung erstellen. Fahren Sie mit dem nächsten Schritt fort, nachdem Sie eine cqlsh-Eingabeaufforderung erhalten haben.
Führen Sie die folgenden Befehle an der cqlsh-Eingabeaufforderung aus:
desc keyspaces;
Achten Sie darauf, dass dieser Befehl keine Fehler zurückgibt.
Führen Sie für jeden Namen in der Liste, die in Schritt 10. f erstellt wurde,
diesen Befehl aus:
drop keyspace <name>;
Beenden Sie den Cassandra-Debugging-Client-Pod.
Führen Sie nach der Ausführung der cqlsh-Befehle folgende Befehle auf allen Cassandra-Pods im Kubernetes-Quellcluster aus:
kubectl exec -it -n apigee <cassandra pod name> -- /bin/bash
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2
Einige der im vorherigen Abschnitt beschriebenen Schritte erfordern den Namen der migrierten Organisation. So rufen Sie den Namen der migrierten Organisation ab:
Rufen Sie den Namen der Organisation aus der Datei overrides.yaml der Organisation ab. Prüfen Sie die Datei overrides.yaml für die zu migrierende Organisation.
Wenn der Organisationsname Bindestriche „-“ enthält, ersetzen Sie alle Bindestriche „-“ durch Unterstriche „_“.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-28 (UTC)."],[[["\u003cp\u003eThis documentation outlines the process of migrating an Apigee hybrid organization from one Kubernetes cluster to another, covering reasons for migration such as data center decommissioning or infrastructure updates.\u003c/p\u003e\n"],["\u003cp\u003eMigrating an organization to a new Kubernetes cluster involves risks, including potential data loss, and limitations, such as a maximum data size of 5GB and no migration of cache or quota data.\u003c/p\u003e\n"],["\u003cp\u003eThe migration procedure involves backing up the org data in the source cluster, restoring it in the destination cluster, and then deleting the org data from the source cluster, including deleting the appropriate keyspaces.\u003c/p\u003e\n"],["\u003cp\u003eThe destination cluster must have no existing hybrid deployments, only supports single-region deployments initially, and the Cassandra cluster should be in good health.\u003c/p\u003e\n"],["\u003cp\u003eThe current version of this documentation is end-of-life, so it is highly recommended to upgrade to a newer version.\u003c/p\u003e\n"]]],[],null,["# Migrating an org to another cluster\n\n| You are currently viewing version 1.8 of the Apigee hybrid documentation. **This version is end of life.** You should upgrade to a newer version. For more information, see [Supported versions](/apigee/docs/hybrid/supported-platforms#supported-versions).\n\nThis page describes how to migrate an Apigee hybrid org from one\nKubernetes cluster to another. Some cases in which you might need to migrate\nan org to another cluster are the following:\n\n- The data center hosting the existing cluster has no more capacity, or is being decommissioned.\n- The cluster is running old infrastructure or an old version of Kubernetes, and you want to migrate to a cluster with newer infrastructure.\n- You want to move orgs from multi-org clusters into separate clusters.\n\nNote that there are risks and limitations when migrating an org to another hybrid cluster.\nRead the details in the [Limitations](#limitations)\nsection before performing a migration.\n\nLimitations\n-----------\n\nThe following limitations apply when migrating a hybrid org to another Kubernetes cluster:\n\n- There is a risk of data loss when moving org data to a new Kubernetes cluster. You should back up the data for all orgs in the Kubernetes cluster, using the [hybrid backup\n instructions](/apigee/docs/hybrid/v1.8/cassandra-backup-overview), before migrating an org.\n- The maximum data size supported for org migration is 5GB across all keyspaces of an org, excluding cache and quota.\n- Cache data will not be migrated. Hybrid rebuilds cache data.\n- Quota data will not be migrated. Hybrid resets quota data.\n- You can only migrate orgs to a Kubernetes cluster that contains no existing hybrid deployment. Migrating to a cluster with an existing hybrid deployment is not supported.\n- The org being migrated can only be moved to a new cluster with a single region deployment. After the single region deployment is up and running, you can follow the region expansion process, described in [Multi-region\n deployment](/apigee/docs/hybrid/v1.8/multi-region), to expand to other regions.\n- The Cassandra cluster should be operating in good health across all regions.\n\nMigrating an org\n----------------\n\nFollow the instructions below to migrate a hybrid org from one Kubernetes cluster to another:\n\n1. If not already enabled, enable backups on the Kubernetes cluster containing the hybrid org to be migrated. See [Cassandra backup overview](/apigee/docs/hybrid/v1.8/cassandra-backup-overview) for information on hybrid backups.\n2. Start a hybrid backup job using the following command: \n\n ```\n kubectl create job -n apigee --from=cronjob/apigee-cassandra-backup \u003cbackup job name\u003e\n ```\n\n The `\u003cbackup job name\u003e` can be any valid container name.\n3. Once the backup job is completed, use the instructions in the following sections of [Monitoring\n backups](/apigee/docs/hybrid/v1.8/monitor-cassandra-backups) to verify that the backup has successfully completed:\n - \"Check the status of the backup job\"\n - \"Check the backup logs\"\n4. After verifying that the backup was successful, make a note of the ID number at the end of the backup log. For example, a successful backup log should contain a line like the following: \n\n ```\n INFO: completed upload for 20230207004250\n ```\n Make a note of the multi-digit number at the end of the line. You will need this number later.\n5. Switch the Kubernetes context to the destination Kubernetes cluster: \n\n ```\n kubectl config use-context \u003cdestination cluster name\u003e # \u003cdestination cluster name\u003e\n ```\n\n where `\u003cdestination cluster name\u003e` is the name of the destination Kubernetes\n cluster.\n6. Restore the backup data into the destination Kubernetes cluster using the instructions in [Restoring in a single region](https://cloud.google.com/apigee/docs/hybrid/v1.8/restore-cassandra-single-region).\n - Use the overrides.yaml file for the org that is being migrated to the destination hybrid deployment.\n - Remember to set the `restore:snapshotTimestamp` value to the multi-digit number shown by the backup log in step 4. See [Restoring in a single region](https://cloud.google.com/apigee/docs/hybrid/v1.8/restore-cassandra-single-region).\n7. Once the restoration is complete, delete any org data, other than the data for the org being migrated, from the destination Kubernetes cluster. Hybrid backup files contain the data for all orgs, including ones you may not want to migrate. After the destination hybrid deployment is restored, you need to remove any extra org data that was copied to the deployment, using the following steps:\n 1. Verify that the current context is the correct context for the destination Kubernetes cluster: \n\n ```\n kubectl config current-context\n ```\n 2. Exec into the `apigee-cassandra-default-0` pod: \n\n ```\n kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash\n ```\n 3. Execute the following command: \n\n ```\n find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*\u003cmigrated org name\u003e*' -type d -maxdepth 2 -printf \"%f\\n\"\n ```\n\n See [Get the name of the migrated org](#get-the-name-of-the-migrated-org)\n for instructions on finding `\u003cmigrated org name\u003e`.\n\n Copy the list of all names that are shown in the\n output. You will need this list in step 7. f.\n 4. Exit the `apigee-cassandra-default-0` pod.\n 5. Create a Cassandra debug client pod using the instructions in [Create a client container for debugging](/apigee/docs/api-platform/troubleshoot/playbooks/cassandra/ts-cassandra#create-a-client-container-for-debugging). Move on to the next step after getting a `cqlsh` prompt.\n 6. Execute the following commands in the `cqlsh` prompt:\n -\n\n ```\n desc keyspaces;\n ```\n\n Make sure this command returns no errors.\n - For each name in the list created in step 7. c., run the following command: \n\n ```\n drop keyspace \u003cname\u003e\n ```\n 7. Exit the Cassandra debug client pod.\n 8. After executing the `cqlsh` commands, run the following commands on all Cassandra pods in the destination Kubernetes cluster:\n -\n\n ```\n kubectl exec -it -n apigee -- /bin/bash\n ```\n -\n\n ```\n find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*\u003cmigrated org name\u003e*' -type d -maxdepth 2\n ```\n\n See [Get the name of the migrated org](#get-the-name-of-the-migrated-org)\n for instructions on finding `\u003cmigrated org name\u003e`.\n -\n\n ```\n find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '**' -type d -maxdepth 2 -exec rm -rf {} +\n ```\n 9. Exit the Cassandra pod.\n8. Switch the Kubernetes context to the source Kubernetes cluster: \n\n ```\n kubectl config use-context \u003csource cluster name\u003e\n ```\n\n where `\u003csource cluster name\u003e` is the name of the source Kubernetes cluster.\n9. Delete the migrated org from the source Kubernetes cluster. Be sure to use the `overrides.yaml` file for the org in the delete command:\n 1. Verify the current context is the correct context for the source Kubernetes cluster: \n\n ```\n kubectl config current-context\n ```\n 2.\n\n ```\n apigeectl delete --settings virtualhost -f \n ```\n 3.\n\n ```\n apigeectl delete --all-envs -f \u003coverrides.yaml\u003e\n ```\n 4.\n\n ```\n apigeectl delete -f \u003coverrides.yaml\u003e --org\n ```\n 5. Exec into the apigee-cassandra-default-0 pod: \n\n ```\n kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash\n ```\n 6. Execute the following command: \n\n ```\n find /opt/apigee/data/apigee-cassandra/ -iname '*\u003cmigrated org name\u003e_hybrid' -type d -maxdepth 2 -printf \"%f\\n\"\n ```\n\n See [Get the name of the migrated org](#get-the-name-of-the-migrated-org)\n for instructions on finding `\u003cmigrated org name\u003e`.\n\n Copy the list of all the names that are shown in the output. You will need this list\n in step 9. j.\n 7. Exit the `apigee-cassandra-default-0` pod.\n 8. Create a Cassandra debug client pod using the instructions in [Create a client container for debugging](/apigee/docs/api-platform/troubleshoot/playbooks/cassandra/ts-cassandra#create-a-client-container-for-debugging). Move on to the next step after getting a `cqlsh` prompt.\n 9. Execute the following commands at the `cqlsh` prompt: \n\n ```\n desc keyspaces;\n ```\n\n Make sure this command returns no errors.\n 10. For each name in the list created in step 10. f., run the following command: \n\n ```\n drop keyspace \u003cname\u003e;\n ```\n 11. Exit the Cassandra debug client pod.\n After executing the `cqlsh` commands, run the following commands on all Cassandra pods in the source Kubernetes cluster:\n -\n\n ```\n kubectl exec -it -n apigee \u003ccassandra pod name\u003e -- /bin/bash\n ```\n -\n\n ```\n find /opt/apigee/data/apigee-cassandra/ -iname '*\u003cmigrated org name\u003e_hybrid' -type d -maxdepth 2\n ```\n\n See [Get the name of the migrated org](#get-the-name-of-the-migrated-org)\n for instructions on finding `\u003cmigrated org name\u003e`.\n -\n\n ```\n find /opt/apigee/data/apigee-cassandra/ -iname '*\u003cmigrated org name\u003e_hybrid' -type d -maxdepth 2 -exec rm -rf {} +\n ```\n 12. Exit the Cassandra pod.\n\n### Get the name of the migrated org\n\nSeveral of the steps in the procedure described in the previous section require the name of\nthe migrated org. To get the migrated org name, do the following:\n\n1. Get the org name from the org's overrides.yaml file. Make sure to check the overrides.yaml file for the org being migrated.\n2. If the org name contains any dashes \"-\", replace all dashes \"-\" with underscores \"_\"."]]
