Risoluzione dei problemi di ripristino di Cassandra

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Non esiste documentazione equivalente di Apigee Edge per questo argomento.

Nota:questo documento è applicabile solo agli utenti di Apigee Hybrid.

Sintomo

Durante il ripristino di Cassandra in Apigee Hybrid, potresti riscontrare errori nei log di ripristino.

Messaggio di errore

Nei log viene visualizzato uno dei seguenti messaggi:

java.net.ConnectException: Connection timed out (Connection timed out)

/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1

/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

Cause possibili

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Timeout della connessione	Questo è un errore di connettività tra i pod apigee-cassandra-restore e i pod apigee-cassandra-default-*.	Apigee hybrid
Timeout dell'operazione	Questo errore si verifica se il ripristino scade dopo più di 15 minuti.	Apigee hybrid
Esiste già	Questo messaggio di errore non è correlato alla causa del problema ed è il risultato di un'operazione di nuovo tentativo di un job di ripristino.	Apigee hybrid

Causa: Timeout della connessione

Il seguente errore è un errore di connettività tra i pod apigee-cassandra-restore e i pod apigee-cassandra-default-*:

java.net.ConnectException: Connection timed out (Connection timed out)

Diagnosi

1. Se la rete host non è raggiungibile dalla rete del pod, assicurati che hostNetwork sia impostato su false in cassandra in overrides.yaml come mostrato in Ripristino di una regione da un backup.
2. Per testare la connettività, accedi al pod apigee-mart o apigee-runtime, che si trova nella stessa rete del job apigee-cassandra-restore. Puoi anche utilizzare qualsiasi altro pod nella rete di pod.
   1. Ottieni il nome del pod apigee-mart:

      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"

   2. Esegui una sessione bash all'interno del pod del marketplace:

      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Sostituisci MART_POD_NAME con il nome del pod MART. Ad esempio, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.

   3. Esegui test di connettività sulle porte Cassandra:

      curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:9042

      curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:7001

   Se nell'output viene visualizzato un errore Connection timed out, significa che hai problemi di connettività. Tuttavia, se viene visualizzato un messaggio Connected to, significa che la connessione è riuscita e devi premere Ctrl + C per chiuderla e procedere.

Risoluzione

Assicurati che l'impostazione HostNetwork sia impostata su false nel file overrides.yaml utilizzato per il ripristino, e ripeti la procedura di ripristino. Se l'impostazione è già impostata su false, ma vengono visualizzati errori di connettività, assicurati che i pod Cassandra siano attivi con il seguente comando:

kubectl get pods -n apigee -l app=apigee-cassandra

L'output dovrebbe essere simile a quello dell'esempio seguente:

NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          14m
apigee-cassandra-default-1   1/1     Running   0          13m
apigee-cassandra-default-2   1/1     Running   0          11m
exampleuser@example hybrid-files %

Causa: operazione con timeout

Se il ripristino scade dopo più di 15 minuti, si verifica il seguente errore. L'errore indica problemi di I/O, ad esempio la rete e lo spazio di archiviazione non riescono a trasmettere in tempo i contenuti non compressi del backup.

/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client
request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1

Diagnosi

1. Controlla i log di apigee-cassandra-default-0 per annotare il timestamp dell'inizio del ripristino:

   kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1

2. Confronta il timestamp con l'ultimo log della creazione della tabella:

   kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1

   I risultati di questo confronto dovrebbero mostrare che il pod Cassandra era ancora in fase di creazione delle tabelle dopo il superamento del tempo di attesa.

3. Testa la larghezza di banda dello spazio di archiviazione con i seguenti comandi:

   kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'

   kubectl -n apigee exec -it apigee-cassandra-default-1 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'

   kubectl -n apigee exec -it apigee-cassandra-default-2 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'

   Se la velocità di scrittura è inferiore a 100 M/s, potrebbe indicare la mancanza di un StorageClass (unità SSD) appropriato.

4. Testa la larghezza di banda di rete:

   1. Esegui netcat sul pod Cassandra per ascoltare sulla porta:

      kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'

   2. In una sessione di shell separata, ottieni il nome del pod apigee-mart:

      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"

   3. Esegui una sessione bash all'interno del pod apigee-mart. Puoi anche utilizzare qualsiasi altro pod nella rete di pod:

      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Sostituisci MART_POD_NAME con il nome del pod MART. Ad esempio, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.

   4. Esegui un test della larghezza di banda della rete sul pod Cassandra su cui è ancora in esecuzione netcat:

      dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456

   Puoi ripetere la procedura per altri pod Cassandra. Se la velocità risultante è inferiore a 10 M/s, è molto probabile che la causa del problema sia la larghezza di banda della rete.

Risoluzione

Una volta confermata la velocità di I/O lenta con i passaggi precedenti, assicurati che il tuo cluster rispetti i requisiti minimi di rete e archiviazione. Riprova a testare la larghezza di banda.

Causa: esistente

Diagnosi

Viene visualizzato un errore simile al seguente:

/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

Risoluzione

Questo messaggio di errore non è correlato alla causa del problema ed è il risultato di un'operazione di nuovo tentativo di un job di ripristino. Il messaggio di errore effettivo dovrebbe essere visualizzato nei log del primo pod che ha avuto esito negativo.

Recupera i log dell'errore iniziale per diagnosticare il problema.

Se il problema persiste, vai a Devi raccogliere informazioni di diagnostica.

Soluzione alternativa per il problema noto 391861216

Diagnosi

Il pod Cassandra con il numero più alto è in stato CrashLoopBackoff dopo il ripristino. Questo può verificarsi a causa del problema noto 391861216. Nel log del pod Cassandra viene visualizzato un errore simile al seguente:

Cannot change the number of tokens from 512 to 256

Risoluzione

Per risolvere il problema sottostante, svolgi i passaggi che seguono. In questo modo Cassandra potrà avviarsi normalmente conservando i dati.

1. Avvia l'eliminazione del volume PVC per il pod Cassandra bloccato nello stato CrashLoopBackoff. Imposta POD_NAME sul nome del pod nello stato CrashLoopBackoff. Imposta APIGEE_NAMESPACE sullo spazio dei nomi del cluster in cui è installato Apigee.

   kubectl delete pvc cassandra-data-POD_NAME -n APIGEE_NAMESPACE --wait=false

2. Elimina il pod nello stato CrashLoopBackoff.

   kubectl delete pod POD_NAME -n APIGEE_NAMESPACE

3. Modifica manualmente l'host seed per Cassandra impostandolo sul pod con il numero più alto. Ad esempio, se hai tre repliche, SEED_POD_NAME deve essere apigee-cassandra-default-2. Questa operazione è necessaria una sola volta e può essere saltata per i pod successivi.

   kubectl patch apigeeds/default -n APIGEE_NAMESPACE --type='merge' -p '{"spec": {"components": {"cassandra": {"properties": {"externalSeedHost":"SEED_POD_NAME.apigee-cassandra-default.APIGEE_NAMESPACE.svc.cluster.local"}}}}}'

4. Rimuovi il nodo con 512 token dall'anello Cassandra.

   kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status' | awk '/^DN .*\?.* 512 / {print $6; exit}; /^DN .* [KMG]iB.* 512 / {print $7; exit}' | xargs -I {} kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode {}'

5. Attendi che il pod Cassandra si riprenda, riavvialo eventualmente più di una volta e raggiungi un Ready stato di 2/2. Il pod successivo più alto passerà allo stato CrashLoopBackoff.

   kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra -w

6. Aggiorna POD_NAME e ripeti i passaggi precedenti per i pod rimanenti, uno alla volta, man mano che passano allo stato CrashLoopBackoff finché tutti i pod non sono in uno stato Ready di 2/2 e hanno uno stato Running.

7. Verifica che tutti i pod siano riusciti ad accedere all'anello Cassandra.

   kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status'

   Tutti i nodi Cassandra devono avere lo stato UN e 256 token.

8. Ripristina la modifica all'host seed per Cassandra.

   kubectl patch apigeeds/default -n APIGEE_NAMESPACE --type='merge' -p '{"spec": {"components": {"cassandra": {"properties": {"externalSeedHost":""}}}}}'

   Il controller Apigee Datastore riavvierà di nuovo i pod Cassandra ripristinando la modifica dell'host seed.

Deve raccogliere informazioni di diagnostica

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni di diagnostica e poi contatta l'assistenza clienti Google Cloud:

1. Oltre ai dati usuali che ti potrebbe essere chiesto di fornire, raccogli i dati di diagnostica da tutti i pod Cassandra con il seguente comando:

   for p in $(kubectl -n apigee get pods -l app=apigee-cassandra --no-headers -o custom-columns=":metadata.name") ; do \
           for com in info describecluster failuredetector version status ring info gossipinfo compactionstats tpstats netstats cfstats proxyhistograms gcstats ; do kubectl \
           -n apigee exec ${p} -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD '"$com"' 2>&1 '\
           | tee /tmp/k_cassandra_nodetool_${com}_${p}_$(date +%Y.%m.%d_%H.%M.%S).txt | head -n 40 ; echo '...' ; done; done
         

2. Comprimilo e forniscilo nella richiesta di assistenza:

   tar -cvzf /tmp/cassandra_data_$(date +%Y.%m.%d_%H.%M.%S).tar.gz /tmp/k_cassandra_nodetool*

3. Raccogli e fornisci i log del pod di ripristino. Tieni presente che i log hanno una durata breve, pertanto devono essere raccolti subito dopo l'errore.
4. Se hai seguito i passaggi di diagnosi precedenti, raccogli tutti gli output della console, copiali in un file e allegalo alla richiesta di assistenza.