Migrer une organisation vers un autre cluster

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 :
```
kubectl create job -n apigee --from=cronjob/apigee-cassandra-backup <backup job name>
```
<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 :
```
kubectl config use-context <destination cluster name> # <destination cluster name>
```
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 :
1. Vérifiez que le contexte actuel est le contexte approprié pour le cluster Kubernetes de destination :
```
kubectl config current-context
```
2. Procédez à l'exécution sur le pod apigee-cassandra-default-0 :
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
```
3. Exécutez la commande suivante :
```
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2 -printf "%f\n"
```
  Pour savoir comment trouver <migrated org name>, consultez la section Obtenir le nom de l'organisation migrée.
  
  Copiez la liste de tous les noms affichés dans la sortie. Vous aurez besoin de cette liste à l'étape 7. f.
4. Fermez le pod apigee-cassandra-default-0.
5. 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.
6. Exécutez les commandes suivantes dans l'invite cqlsh :
  - ```
  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>
```
7. Quittez le pod client de débogage Cassandra.
8. Après avoir exécuté les commandes cqlsh, exécutez les commandes suivantes sur tous les pods Cassandra du cluster Kubernetes de destination :
  - ```
  kubectl exec -it -n apigee  -- /bin/bash
```
- ```
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2
```
    Pour savoir comment trouver <migrated org name>, consultez la section Obtenir le nom de l'organisation migrée.
  - ```
  find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '**' -type d -maxdepth 2 -exec rm -rf {} +
```
9. Quittez le pod Cassandra.
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 :
1. Vérifiez que le contexte actuel est le contexte approprié pour le cluster Kubernetes source.
```
kubectl config current-context
```
2. ```
apigeectl delete --settings virtualhost -f 
```
3. ```
apigeectl delete --all-envs -f <overrides.yaml>
```
4. ```
apigeectl delete -f <overrides.yaml> --org
```
5. Exécutez sur le pod apigee-cassandra-default-0 :
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
```
6. Exécutez la commande suivante :
```
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -printf "%f\n"
```
  Pour savoir comment trouver <migrated org name>, consultez la section Obtenir le nom de l'organisation migrée.
  
  Copiez la liste de tous les noms affichés dans la sortie. Vous aurez besoin de cette liste à l'étape 9. j.
7. Fermez le pod apigee-cassandra-default-0.
8. 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.
9. Exécutez les commandes suivantes lorsque l'invite cqlsh s'affiche :
```
desc keyspaces;
```
  Vérifiez que cette commande ne renvoie aucune erreur.
10. Pour chaque nom de la liste créée à l'étape 10. f., exécutez la commande suivante :
```
drop keyspace <name>;
```
11. Quittez le pod client de débogage Cassandra.
12. Quittez le pod Cassandra.

Obtenir le nom de l'organisation migrée

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 "_".