Cette page explique comment migrer une organisation Apigee hybrid d'un cluster Kubernetes à un autre. Il arrive que vous deviez migrer une organisation vers un autre cluster, par exemple dans les cas suivants :
Le centre de données qui héberge le cluster existant n'a plus de capacité ou est en cours de mise hors service.
Le cluster exécute une ancienne infrastructure ou une ancienne version de Kubernetes et vous souhaitez migrer vers un cluster doté d'une infrastructure plus récente.
Vous souhaitez déplacer des organisations depuis des clusters multi-organisations vers des clusters distincts.
Notez que la migration d'une organisation vers un autre cluster hybride présente des risques et des limites.
Lisez les détails de la section Limites avant d'effectuer une migration.
Limites
Les limites suivantes s'appliquent lors de la migration d'une organisation hybride vers un autre cluster Kubernetes :
Il existe un risque de perte de données lors du déplacement de données d'organisation vers un nouveau cluster Kubernetes.
Avant de migrer une organisation, vous devez sauvegarder les données de toutes les organisations dans le cluster Kubernetes en suivant les instructions de sauvegarde hybride.
La taille maximale des données pour la migration d'une organisation est de 5 Go dans les espaces de clés d'une organisation, hors cache et quota.
Les données du cache ne seront pas migrées. La sauvegarde hybride recompile les données de cache.
Les données de quota ne seront pas migrées. La sauvegarde hybride réinitialise les données de quota.
Vous ne pouvez migrer des organisations que vers un cluster Kubernetes qui ne contient aucun déploiement hybride existant.
La migration vers un cluster avec un déploiement hybride existant n'est pas possible.
L'organisation en cours de migration ne peut être déplacée que vers un nouveau cluster avec un déploiement dans une seule région.
Une fois que le déploiement dans une seule région est opérationnel, vous pouvez suivre le processus d'expansion régionale, décrit dans la section Déploiement multirégional, pour étendre les régions.
Le cluster Cassandra devrait fonctionner correctement dans toutes les régions.
Migrer une organisation
Suivez les instructions ci-dessous pour migrer une organisation hybride d'un cluster Kubernetes vers un autre :
Si ce n'est pas déjà fait, activez la sauvegarde sur le cluster Kubernetes contenant l'organisation hybride à migrer. Pour en savoir plus sur les sauvegardes hybrides, consultez la page Présentation de la sauvegarde Cassandra.
Déclenchez un job de sauvegarde hybride en exécutant la commande suivante :
<backup job name> peut être n'importe quel nom de conteneur valide.
Une fois la tâche de sauvegarde terminée, suivez les instructions des sections suivantes de la page Surveiller les sauvegardes pour vérifier que la sauvegarde a bien été effectuée :
"Vérifier l'état de la tâche de sauvegarde"
"Vérifier les journaux de sauvegarde"
Après avoir vérifié la réussite de la sauvegarde, notez le numéro d'ID à la fin du journal de sauvegarde.
Par exemple, un journal de sauvegarde réussie doit contenir une ligne semblable à celle-ci :
INFO: completed upload for 20230207004250
Notez le numéro à plusieurs chiffres à la fin de la ligne. Vous en aurez besoin ultérieurement.
Basculez le contexte Kubernetes vers le cluster Kubernetes de destination :
où <destination cluster name> est le nom du cluster Kubernetes de destination.
Restaurez les données de sauvegarde dans le cluster Kubernetes de destination en suivant les instructions de la section Restaurer dans une seule région.
Utilisez le fichier overrides.yaml pour l'organisation en cours de migration vers le déploiement hybride de destination.
N'oubliez pas de définir la valeur restore:snapshotTimestamp sur le nombre à plusieurs chiffres affiché par le journal de sauvegarde à l'étape 4. Consultez la section Restaurer dans une seule région.
Une fois la restauration terminée, supprimez toutes les données de l'organisation, autres que celles de l'organisation en cours de migration, du cluster Kubernetes de destination. Les fichiers de sauvegarde hybride contiennent les données de toutes les organisations, y compris celles que vous ne souhaitez peut-être pas migrer. Une fois le déploiement hybride de destination restauré, vous devez supprimer toutes les données d'organisation supplémentaires copiées dans le déploiement, en procédant comme suit :
Vérifiez que le contexte actuel est le contexte approprié pour le cluster Kubernetes de destination :
kubectl config current-context
Procédez à l'exécution sur le pod apigee-cassandra-default-0 :
Copiez la liste de tous les noms affichés dans la sortie. Vous aurez besoin de cette liste à l'étape 7. f.
Fermez le pod apigee-cassandra-default-0.
Créez un pod client de débogage Cassandra en suivant les instructions de la section Créer un conteneur client pour le débogage. Passez à l'étape suivante après avoir reçu une requêtecqlsh.
Execute the following commands in the cqlsh prompt:
desc keyspaces;
Vérifiez que cette commande ne renvoie aucune erreur.
Pour chaque nom de la liste créée à l'étape 7. c., exécutez la commande suivante :
drop keyspace <name>
Quittez le pod client de débogage Cassandra.
Après avoir exécuté les commandes cqlsh, exécutez les commandes suivantes sur tous les pods Cassandra du cluster Kubernetes de destination :
Basculez le contexte Kubernetes vers le cluster Kubernetes source :
kubectl config use-context <source cluster name>
où <source cluster name> est le nom du cluster Kubernetes source.
Supprimez l'organisation migrée du cluster Kubernetes source. Veillez à utiliser le fichier overrides.yaml pour l'organisation dans la commande de suppression :
Vérifiez que le contexte actuel est le contexte approprié pour le cluster Kubernetes source.
Copiez la liste de tous les noms affichés dans la sortie. Vous aurez besoin de cette liste à l'étape 9. j.
Fermez le pod apigee-cassandra-default-0.
Créez un pod client de débogage Cassandra en suivant les instructions de la section Créer un conteneur client pour le débogage. Passez à l'étape suivante après avoir reçu une requêtecqlsh.
Exécutez les commandes suivantes lorsque l'invite cqlsh s'affiche :
desc keyspaces;
Vérifiez que cette commande ne renvoie aucune erreur.
Pour chaque nom de la liste créée à l'étape 10. f.,
exécutez la commande suivante :
drop keyspace <name>;
Quittez le pod client de débogage Cassandra.
Après avoir exécuté les commandes cqlsh, exécutez les commandes suivantes sur tous les pods Cassandra du cluster Kubernetes source :
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
Plusieurs étapes de la procédure décrite dans la section précédente nécessitent le nom de l'organisation migrée. Pour obtenir le nom de l'organisation migrée, procédez comme suit :
Obtenez le nom de l'organisation à partir du fichier overrides.yaml de l'organisation. Veillez à vérifier le fichier overrides.yaml pour l'organisation en cours de migration.
Si le nom de l'organisation contient des tirets "-", remplacez tous les tirets "-" par des traits de soulignement "_".
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/28 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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 \"_\"."]]
