Questa pagina descrive come eseguire la migrazione di un'organizzazione Apigee hybrid da un cluster Kubernetes all'altro. Alcuni casi in cui potrebbe essere necessario eseguire la migrazione da un'organizzazione a un altro cluster:
- Il data center che ospita il cluster esistente non ha più capacità o verrà dismesso.
- Il cluster utilizza una vecchia infrastruttura o una versione obsoleta di Kubernetes a un cluster con un'infrastruttura più recente.
- Vuoi spostare le organizzazioni da cluster multi-organizzazione in cluster distinti.
Tieni presente che la migrazione di un'organizzazione a un altro cluster ibrido presenta rischi e limitazioni. Leggi i dettagli nella pagina Limitazioni prima di eseguire una migrazione.
Limitazioni
Quando esegui la migrazione di un'organizzazione ibrida a un altro cluster Kubernetes si applicano le seguenti limitazioni:
- Esiste un rischio di perdita di dati quando si spostano i dati dell'organizzazione in un nuovo cluster Kubernetes. Prima di eseguire la migrazione di un'organizzazione, devi eseguire il backup dei dati di 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 chiavi di un'organizzazione, escludendo cache e quota.
- La migrazione dei dati della cache non verrà eseguita. La modalità ibrida ricrea i dati della cache.
- La migrazione dei dati delle quote non verrà eseguita. La modalità ibrida reimposta i dati delle quote.
- Puoi eseguire la migrazione delle organizzazioni solo in un cluster Kubernetes che non contiene un deployment ibrido. La migrazione a un cluster con un deployment ibrido esistente non è supportata.
- L'organizzazione di cui viene eseguita la migrazione può essere spostata in un nuovo cluster solo con un deployment in una singola regione. Una volta avviato il deployment in una singola regione, puoi seguire di espansione, descritto in Più regioni deployment, per estenderla ad altre regioni.
- Il cluster Cassandra dovrebbe funzionare correttamente 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 sono già abilitati, attiva i backup sul cluster Kubernetes contenente l'organizzazione ibrida di cui eseguire la migrazione. Consulta: 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 contenitore valido. - Una volta completato il job di backup, segui le istruzioni riportate nelle sezioni seguenti di
Monitoraggio
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 dovrebbe contenere una riga simile alla seguente:
Annota il numero a più cifre alla fine della riga. Ti servirà in un secondo momento.INFO: completed upload for 20230207004250
- Passa dal contesto di Kubernetes al 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 seguendo le istruzioni riportate in
Ripristino in una singola regione.
- Utilizza il file overrides.yaml per l'organizzazione di cui viene eseguita la migrazione al deployment ibrido di destinazione.
- Ricorda di impostare il valore
restore:snapshotTimestamp
su più cifre numero indicato dal log di backup al passaggio 4. Consulta: Ripristino in una singola regione.
- Al termine del ripristino, elimina dal cluster Kubernetes di destinazione tutti i dati dell'organizzazione, ad eccezione di quelli dell'organizzazione di cui è in corso la migrazione. I file di backup ibridi contengono i dati di tutti
organizzazioni, incluse quelle di cui non vuoi eseguire la migrazione. Dopo l'ibrido di destinazione
ripristinare il deployment, devi rimuovere tutti i dati dell'organizzazione aggiuntivi che sono stati copiati
seguendo questi passaggi:
- Verifica che il contesto attuale sia corretto per il cluster Kubernetes di destinazione:
kubectl config current-context
- Esegui nel pod
apigee-cassandra-default-0
:kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Esegui questo comando:
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2 -printf "%f\n"
Consulta Ottenere il nome dell'organizzazione di cui è stata eseguita la migrazione per istruzioni su come trovare
<migrated org name>
.Copia l'elenco di tutti i nomi che vengono mostrati come output. Ti servirà questo elenco nel passaggio 7. f.
- Esci dal pod
apigee-cassandra-default-0
. - Crea un pod client di debug Cassandra seguendo le istruzioni riportate in
Creare un contenitore client per il debug. Vai al passaggio successivo dopo aver ricevuto un messaggio di prompt
cqlsh
. - Esegui i seguenti comandi nel prompt
cqlsh
:-
desc keyspaces;
Assicurati che questo comando non restituisca errori.
- Per ogni nome nell'elenco creato nel passaggio 7. c., esegui il seguente comando:
drop keyspace <name>
-
- Esci dal pod del client di debug Cassandra.
- Dopo aver eseguito i comandi
cqlsh
, esegui i seguenti 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
Consulta Ottenere il nome dell'organizzazione di cui è stata eseguita la migrazione per istruzioni su come trovare
<migrated org name>
.find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*
*' -type d -maxdepth 2 -exec rm -rf {} +
- Esci dal pod Cassandra.
- Verifica che il contesto attuale sia corretto per il cluster Kubernetes di destinazione:
- Passa il contesto Kubernetes al 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:- Verifica che il contesto corrente sia quello corretto per il cluster Kubernetes di origine:
kubectl config current-context
Se necessario, imposta i contesti Kubernetes per il cluster e l'organizzazione che devono essere dismessi.
Elenca i tuoi contesti attuali per vedere il nome del contesto per ogni cluster:
kubectl config get-contexts
Imposta il contesto del cluster e della 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 apigeekubectl config use-context gke_example-org-1_us-west1_example-cluster-2
- Elimina l'host virtuale.
Helm
Ripeti questa operazione per ogni gruppo di ambienti:
helm -n apigee delete ENV_GROUP_NAME
apigeectl
$APIGEECTL_HOME/apigeectl delete --settings virtualhost -f OVERRIDES_FILE.yaml
- Elimina gli ambienti.
Helm
Ripeti l'operazione per ogni ambiente:
helm -n apigee delete ENV_NAME
apigeectl
$APIGEECTL_HOME/apigeectl delete --all-envs -f OVERRIDES_FILE.yaml
- Elimina l'organizzazione Apigee.
Helm
helm -n apigee delete ORG_NAME
apigeectl
$APIGEECTL_HOME/apigeectl delete -f OVERRIDES_FILE.yaml --org
- Exec nel pod apigee-cassandra-default-0:
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Esegui questo comando:
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -printf "%f\n"
Consulta Recuperare il nome dell'organizzazione di cui è stata eseguita la migrazione. per istruzioni su come trovare
<migrated org name>
.Copia l'elenco di tutti i nomi visualizzati nell'output. Ti servirà questo elenco nel passaggio 9. j.
- Esci dal pod
apigee-cassandra-default-0
. - Crea un pod client di debug Cassandra seguendo le istruzioni riportate in
Crea un contenitore client per il debug. Vai al passaggio successivo
dopo aver ricevuto un prompt di
cqlsh
. - Esegui i seguenti comandi al prompt
cqlsh
:desc keyspaces;
Assicurati che questo comando non restituisca errori.
- Per ciascun nome dell'elenco creato nel passaggio 10. f.,
Esegui il seguente comando:
drop keyspace <name>;
- Esci dal pod del client di debug Cassandra. Dopo aver eseguito i comandi
-
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
Consulta Ottenere il nome dell'organizzazione di cui è stata eseguita la migrazione per istruzioni su come trovare
<migrated org name>
. -
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -exec rm -rf {} +
- Esci dal pod Cassandra.
cqlsh
, esegui i seguenti comandi su tutti i pod Cassandra nel cluster Kubernetes di origine: - Verifica che il contesto corrente sia quello corretto per il cluster Kubernetes di origine:
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:
- Ottieni il nome dell'organizzazione dal file override.yaml dell'organizzazione. Assicurati di controllare 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 "_".