Migrazione di un'organizzazione in un altro cluster

Questa pagina descrive come eseguire la migrazione di un'organizzazione ibrida Apigee da un cluster Kubernetes a un altro. Di seguito sono riportati alcuni casi in cui potrebbe essere necessario eseguire la migrazione di un'organizzazione in un altro cluster:

Il data center che ospita il cluster esistente non ha più capacità o è in fase di smontaggio.
Il cluster esegue la vecchia infrastruttura o una vecchia versione di Kubernetes e vuoi eseguire la migrazione a un cluster con un'infrastruttura più recente.
Vuoi spostare le organizzazioni da cluster a più organizzazioni in cluster separati.

Tieni presente che la migrazione di un'organizzazione a un altro cluster ibrido comporta rischi e limitazioni. Leggi i dettagli nella sezione Limitazioni prima di eseguire una migrazione.

Limitazioni

Durante la migrazione di un'organizzazione ibrida a un altro cluster Kubernetes si applicano le limitazioni seguenti:

Il trasferimento dei dati dell'organizzazione in un nuovo cluster Kubernetes comporta il rischio di una perdita di dati. Devi eseguire il backup dei dati di tutte le organizzazioni nel cluster Kubernetes utilizzando le istruzioni per il backup ibrido prima di eseguire la migrazione di un'organizzazione.
La dimensione massima supportata dei dati per la migrazione dell'organizzazione è 5 GB in tutti gli spazi delle chiavi di un'organizzazione, escluse cache e quota.
La migrazione dei dati della cache non verrà eseguita. Ibrido per ricostruzione dei dati della cache.
La migrazione dei dati delle quote non verrà eseguita. Il modello ibrido reimposta i dati di quota.
Puoi eseguire la migrazione delle organizzazioni solo a un cluster Kubernetes che non contiene un deployment ibrido esistente. La migrazione a un cluster con un deployment ibrido esistente non è supportata.
L'organizzazione in fase di migrazione può essere spostata solo in un nuovo cluster con deployment a regione singola. Dopo aver avviato il deployment per singola regione, puoi seguire la procedura di espansione delle regioni, descritta in Deployment per più regioni, per espandere il servizio ad altre regioni.
Il cluster Cassandra dovrebbe funzionare in buone condizioni in tutte le regioni.

Migrazione di un'organizzazione

Segui le istruzioni riportate di seguito per eseguire la migrazione di un'organizzazione ibrida da un cluster Kubernetes a un altro:

Se non è già abilitata, abilita i backup sul cluster Kubernetes contenente l'organizzazione ibrida di cui eseguire la migrazione. Per informazioni sui backup ibridi, consulta la panoramica dei backup di Cassandra.
Avvia un job di backup ibrido utilizzando il seguente comando:
```
kubectl create job -n apigee --from=cronjob/apigee-cassandra-backup <backup job name>
```
<backup job name> può essere un nome di container valido.
Una volta completato il job di backup, segui le istruzioni nelle sezioni seguenti di Monitoraggio dei backup per verificare che il backup sia stato completato correttamente:
- "Verifica lo stato del job di backup"
- "Controlla i log di backup"
Dopo aver verificato che il backup è riuscito, prendi nota del numero ID alla fine del log di backup. Ad esempio, un log di backup riuscito deve contenere una riga come la seguente:
```
INFO: completed upload for 20230207004250
```
Prendi nota del numero a più cifre alla fine della riga. Questo numero ti servirà in un secondo momento.
Cambia il contesto di Kubernetes nel cluster Kubernetes di destinazione:
```
kubectl config use-context <destination cluster name> # <destination cluster name>
```
dove <destination cluster name> è il nome del cluster Kubernetes di destinazione.
Ripristina i dati di backup nel cluster Kubernetes di destinazione utilizzando le istruzioni riportate in Ripristino in una singola regione.
- Utilizza il file override.yaml per l'organizzazione di cui viene eseguita la migrazione al deployment ibrido di destinazione.
- Ricorda di impostare il valore restore:snapshotTimestamp sul numero di più cifre indicato dal log di backup nel passaggio 4. Consulta la pagina Ripristino in un'unica regione.
Al termine del ripristino, elimina dal cluster Kubernetes di destinazione qualsiasi dato diverso dall'organizzazione di cui viene eseguita la migrazione. I file di backup ibrido contengono i dati di tutte le organizzazioni, inclusi quelli di cui non vuoi eseguire la migrazione. Dopo aver ripristinato il deployment ibrido di destinazione, devi rimuovere eventuali dati dell'organizzazione aggiuntivi che sono stati copiati nel deployment, seguendo questi passaggi:
1. Verifica che il contesto attuale sia il contesto corretto per il cluster Kubernetes di destinazione:
```
kubectl config current-context
```
2. Esecuzione del pod apigee-cassandra-default-0:
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
```
3. Esegui questo comando:
```
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2 -printf "%f\n"
```
  Per istruzioni su come trovare il nome <migrated org name>, vedi Ottenere il nome dell'organizzazione di cui è stata eseguita la migrazione.
  
  Copia l'elenco di tutti i nomi visualizzati nell'output. Questo elenco sarà necessario nel passaggio 7. f.
4. Esci dal pod apigee-cassandra-default-0.
5. Crea un pod client di debug Cassandra seguendo le istruzioni riportate in Creare un container client per il debug. Vai al passaggio successivo dopo aver ricevuto un messaggio cqlsh.
6. Esegui questi comandi nel prompt di cqlsh:
  - ```
  desc keyspaces;
```
  Assicurati che questo comando non restituisca errori.
- Per ogni nome nell'elenco creato al passaggio 7. c., esegui il comando seguente:
```
  drop keyspace <name>
```
7. Esci dal pod del client di debug Cassandra.
8. Dopo aver eseguito i comandi cqlsh, esegui i comandi seguenti su tutti i pod Cassandra nel cluster Kubernetes di destinazione:
  - ```
  kubectl exec -it -n apigee  -- /bin/bash
```
- ```
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2
```
    Per istruzioni su come trovare il nome <migrated org name>, vedi Ottenere il nome dell'organizzazione di cui è stata eseguita la migrazione.
  - ```
  find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '**' -type d -maxdepth 2 -exec rm -rf {} +
```
9. Esci dal pod Cassandra.
Cambia il contesto di Kubernetes nel cluster Kubernetes di origine:
```
kubectl config use-context <source cluster name>
```
dove <source cluster name> è il nome del cluster Kubernetes di origine.
Elimina l'organizzazione di cui è stata eseguita la migrazione dal cluster Kubernetes di origine. Assicurati di utilizzare il file overrides.yaml per l'organizzazione nel comando delete:
1. Verifica che il contesto attuale sia il contesto corretto per il cluster Kubernetes di origine:
```
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. Esegui il pod nel Apigee Apigee-cassandra-default-0:
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
```
6. Esegui questo comando:
```
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -printf "%f\n"
```
  Per istruzioni su come trovare il nome <migrated org name>, vedi Ottenere il nome dell'organizzazione di cui è stata eseguita la migrazione.
  
  Copia l'elenco di tutti i nomi visualizzati nell'output. Avrai bisogno di questo elenco nel passaggio 9. j.
7. Esci dal pod apigee-cassandra-default-0.
8. Crea un pod client di debug Cassandra seguendo le istruzioni riportate in Creare un container client per il debug. Vai al passaggio successivo dopo aver ricevuto un messaggio cqlsh.
9. Esegui questi comandi alla richiesta cqlsh:
```
desc keyspaces;
```
  Assicurati che questo comando non restituisca errori.
10. Per ogni nome nell'elenco creato al passaggio 10., esegui questo comando:
```
drop keyspace <name>;
```
11. Esci dal pod del client di debug Cassandra.
12. Esci dal pod Cassandra.

Recupera il nome dell'organizzazione di cui è stata eseguita la migrazione

Diversi passaggi della procedura descritta nella sezione precedente richiedono il nome dell'organizzazione di cui è stata eseguita la migrazione. Per ottenere il nome dell'organizzazione di cui è stata eseguita la migrazione:

Recupera il nome dell'organizzazione dal file override.yaml dell'organizzazione. Assicurati di controllare il file override.yaml per l'organizzazione di cui viene eseguita la migrazione.
Se il nome dell'organizzazione contiene trattini "-", sostituisci tutti i trattini "-" con trattini bassi "_".