Questa pagina è stata tradotta dall'API Cloud Translation.

Migrazione di un'organizzazione a un altro cluster

Questa pagina descrive come eseguire la migrazione di un'organizzazione ibrida Apigee da un cluster Kubernetes a un altro. Ecco alcuni casi in cui potresti dover eseguire la migrazione di un'organizzazione a un altro cluster:

Il data center che ospita il cluster esistente non ha più capacità o è in fase di dismissione.
Il cluster esegue l'infrastruttura vecchia o una versione precedente di Kubernetes e vuoi eseguire la migrazione a un cluster con infrastruttura più recente.
Vuoi spostare le organizzazioni da cluster multi-organizzazione 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

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

Esiste il rischio di perdita durante lo spostamento dei dati dell'organizzazione in un nuovo cluster Kubernetes. Prima di eseguire la migrazione di un'organizzazione, devi eseguire il backup dei dati per tutte le organizzazioni nel cluster Kubernetes, utilizzando le istruzioni per il backup ibrido.
La dimensione massima dei dati supportata per la migrazione dell'organizzazione è di 5 GB in tutti gli spazi delle chiavi di un'organizzazione, escluse cache e quota.
Non verrà eseguita la migrazione dei dati della cache. Il modello ibrido ricrea i dati della cache.
I dati della quota non verranno migrati. Il modello ibrido reimposta i dati della quota.
Puoi eseguire la migrazione delle organizzazioni solo in un cluster Kubernetes che non contiene alcun deployment ibrido esistente. La migrazione a un cluster con un deployment ibrido esistente non è supportata.
L'organizzazione di cui viene eseguita la migrazione può essere spostata solo in un nuovo cluster con un deployment a regione singola. Una volta eseguito il deployment a livello di singola regione, puoi seguire il processo di espansione descritto in Deployment a più regioni per estenderlo ad altre regioni.
Il cluster Cassandra dovrebbe funzionare in buono stato 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à abilitato, abilita i backup nel cluster Kubernetes contenente l'organizzazione ibrida di cui eseguire la migrazione. Consulta la panoramica del backup di Cassandra per informazioni sui backup ibridi.
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 qualsiasi nome di container valido.
Una volta completato il job di backup, utilizza le istruzioni riportate nelle seguenti sezioni di Monitoraggio dei backup per verificare che il backup sia stato completato correttamente:
- "Controlla lo stato del job di backup"
- "Controlla i log di backup"
Dopo aver verificato l'esito positivo del backup, prendi nota del numero ID alla fine del log di backup. Ad esempio, un log di backup riuscito deve contenere una riga simile alla seguente:
```
INFO: completed upload for 20230207004250
```
Prendi nota del numero a più cifre alla fine della riga. Ti servirà in un secondo momento.
Cambia il contesto 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.
- Ricordati di impostare il valore restore:snapshotTimestamp sul numero a più cifre mostrato nel log di backup nel passaggio 4. Consulta Ripristino in una singola regione.
Una volta completato il ripristino, elimina tutti i dati dell'organizzazione, ad eccezione di quelli dell'organizzazione di cui viene eseguita la migrazione, dal cluster Kubernetes di destinazione. I file di backup ibrido contengono i dati di tutte le organizzazioni, incluse quelle di cui potresti non voler eseguire la migrazione. Una volta ripristinato il deployment ibrido di destinazione, devi rimuovere tutti i dati dell'organizzazione aggiuntivi copiati nel deployment seguendo questa procedura:
1. Verifica che il contesto attuale sia quello corretto per il cluster Kubernetes di destinazione:
```
kubectl config current-context
```
2. Esegui l'esecuzione nel 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 <migrated org name>, consulta Recupero del nome dell'organizzazione di cui è stata eseguita la migrazione.
  
  Copia l'elenco di tutti i nomi mostrati nell'output. Questo elenco sarà necessario nel passaggio 7. f.
4. Esci dal pod apigee-cassandra-default-0.
5. Per creare un pod client di debug Cassandra, utilizza le istruzioni riportate in Creare un contenitore client per il debug. Vai al passaggio successivo dopo aver ricevuto una richiesta cqlsh.
6. Esegui questi comandi nel prompt di cqlsh:
  - ```
  desc keyspaces;
```
  Assicurati che questo comando non restituisca errori.
- Per ogni nome nell'elenco creato nel passaggio 7. c., esegui questo comando:
```
  drop keyspace <name>
```
7. Esci dal pod del client di debug Cassandra.
8. Dopo aver eseguito i comandi cqlsh, esegui questi comandi 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 <migrated org name>, consulta Recupero del 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 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 di eliminazione:
1. Verifica che il contesto attuale sia quello corretto per il cluster Kubernetes di origine:
```
kubectl config current-context
```
  Se necessario, imposta i contesti Kubernetes sul cluster e l'organizzazione deve essere dismessa.
  
  Elenca i contesti attuali per visualizzarne il nome per ciascun cluster:
```
kubectl config get-contexts
```
  Imposta il contesto sul cluster e sulla regione che vuoi ritirare:
```
kubectl config use-context CONTEXT_NAME
```
  Dove CONTEXT_NAME è il nome del contesto per il cluster e la regione.
  
  Ad esempio:
```
    kubectl config get-contexts
    CURRENT   NAME                                                   CLUSTER                                                AUTHINFO                                               NAMESPACE
              gke_example-org-1_us-central1_example-cluster-1        gke_example-org-1_us-central1_example-cluster-1        gke_example-org-1_us-central1_example-cluster-1        apigee
    *         gke_example-org-1_us-central1_example-cluster-2        gke_example-org-1_us-central1_example-cluster-2        gke_example-org-1_us-central1_example-cluster-2        apigee
              gke_example-org-1_us-west1_example-cluster-2           gke_example-org-1_us-west1_example-cluster-2           gke_example-org-1_us-west1_example-cluster-2           apigee

    kubectl config use-context gke_example-org-1_us-west1_example-cluster-2
```
2. Elimina virtualhost. Ripeti questa operazione per ogni gruppo di ambienti:
```
helm -n apigee delete ENV_GROUP_NAME
```
3. Eliminare gli ambienti. Ripeti questa operazione per ogni ambiente:
```
helm -n apigee delete ENV_NAME
```
4. Elimina l'organizzazione Apigee.
```
helm -n apigee delete ORG_NAME
```
5. Esegui l'esecuzione nel pod 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 <migrated org name>, consulta Recupero del nome dell'organizzazione di cui è stata eseguita la migrazione.
  
  Copia l'elenco di tutti i nomi mostrati nell'output. Questo elenco sarà necessario nel passaggio 9. j.
7. Esci dal pod apigee-cassandra-default-0.
8. Per creare un pod client di debug Cassandra, utilizza le istruzioni riportate in Creare un contenitore client per il debug. Vai al passaggio successivo dopo aver ricevuto una richiesta cqlsh.
9. Esegui questi comandi al prompt di cqlsh:
```
desc keyspaces;
```
  Assicurati che questo comando non restituisca errori.
10. Per ogni nome nell'elenco creato al passaggio 10. f., 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 dell'organizzazione di cui viene eseguita la migrazione.
Se il nome dell'organizzazione contiene trattini "-", sostituisci tutti i trattini "-" con trattini bassi "_".