Risoluzione dei problemi di ripristino di Cassandra

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

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 errore è un errore di connettività tra i pod apigee-cassandra-restore e i pod apigee-cassandra-default-*. Apigee hybrid
Timeout 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 riprova 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 mart: 
      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 i test di connettività rispetto alle 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à. Se invece visualizzi il 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 visualizzi errori di connettività, assicurati che i pod Cassandra siano attivi ed esegui il comando seguente: 

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: timeout dell'operazione

Si verifica il seguente errore se il ripristino scade dopo più di 15 minuti. L'errore indica problemi di I/O, ad esempio l'archiviazione e la rete non sono in grado di 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 di 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 timeout.

  3. Testa la larghezza di banda 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 una StorageClass (SSD) appropriata.

  4. Testa la larghezza di banda di rete:

    1. Esegui netcat sul pod Cassandra per rimanere in ascolto sulla porta: 

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

    2. In una sessione 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 di rete sul pod Cassandra che sta ancora eseguendo 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 gli altri pod Cassandra. Se la velocità risultante è inferiore a 10 M/s, è molto probabile che la larghezza di banda della rete sia la causa del problema.

Risoluzione

Una volta confermata la bassa velocità di I/O con i passaggi precedenti, assicurati che il cluster rispetti i requisiti minimi di rete e archiviazione. Dopodiché, esegui di nuovo il test della larghezza di banda.

Causa: già 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 riprova di un job di ripristino. Il messaggio di errore effettivo dovrebbe essere visualizzato nei log del primo pod non riuscito.

Ottieni i log dall'errore iniziale per diagnosticare il problema.

Se il problema persiste, vai a Informazioni di diagnostica da raccogliere.

Soluzione alternativa per il problema noto 391861216

Diagnosi

Il pod Cassandra con il numero più alto è nello stato CrashLoopBackoff dopo il ripristino. Ciò 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, procedi nel seguente modo. In questo modo, Cassandra si avvierà normalmente conservando i dati.

  1. Avvia l'eliminazione della 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 nel 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 ignorata 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 il ripristino del pod Cassandra, riavvia possibilmente più di una volta e raggiungi uno stato Ready di 2/2. Il pod con il punteggio 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 si trovano nello stato Ready di 2/2 e hanno lo stato Running.

  7. Verifica che tutti i pod siano stati aggiunti correttamente 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 quando ripristina la modifica dell'host seed.

Deve raccogliere informazioni diagnostiche

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

  1. Oltre ai dati che ti vengono solitamente richiesti, 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 fornisci il file 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 dal pod di ripristino. Tieni presente che i log hanno una durata limitata, pertanto devono essere raccolti subito dopo l'errore.
  4. Se hai seguito i passaggi di diagnostica descritti sopra, raccogli tutti gli output della console, copiali in un file e allegalo alla richiesta di assistenza.