Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Non esiste una equivalente
Documentazione di Apigee Edge 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 elementi:
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 |
---|---|---|
Sessione di connessione scaduta |
Questo è un errore di connettività tra
apigee-cassandra-restore pod e
apigee-cassandra-default-* pod.
|
Apigee hybrid |
Timeout dell'operazione | Questo errore si verifica se il ripristino scade dopo più di 15 minuti. | Apigee hybrid |
Già esistente | 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: connessione scaduta
Il seguente errore è un errore di connettività tra
apigee-cassandra-restore
pod e
apigee-cassandra-default-*
pod:
java.net.ConnectException: Connection timed out (Connection timed out)
Diagnosi
-
Se la rete host non è raggiungibile dalla rete del pod, assicurati che
hostNetwork
sia impostato sufalse
incassandra
inoverrides.yaml
come mostrato in Ripristino di una regione da un backup. -
Per testare la connettività, accedi al pod
apigee-mart
oapigee-runtime
, che si trova nella stessa rete del jobapigee-cassandra-restore
. Puoi anche utilizzare qualsiasi altro pod nella rete di pod.-
Ottieni il nome del pod
apigee-mart
:kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
-
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
. -
Esegui test di connettività rispetto
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 ricevi un errore
Connection timed out
nell'output, significa che hai problemi di connettività. Tuttavia, se visualizzi un messaggioConnected to
, significa che la connessione è riuscita e devi premere Ctrl + C per chiuderla e procedere. -
Ottieni il nome del pod
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 Cassandra
i pod sono attivi e in esecuzione con 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
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
-
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
-
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 è ancora in fase di creazione delle tabelle dopo che il timeout era superato.
-
Verifica 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, ciò potrebbe indicare una mancanza di un adeguato StorageClass (SSD) utilizzato.
-
Testa la larghezza di banda di rete:
-
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'
-
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"
-
Esegui una sessione bash all'interno del pod
apigee-mart
. Tu 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
. -
Esegui un test della larghezza di banda della rete sul pod Cassandra
netcat
è ancora in esecuzione: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 il risultato è inferiore a 10 M/s, la larghezza di banda della rete è molto probabilmente causa del problema.
-
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. Al termine, verifica nuovamente la larghezza di banda.
Causa: esiste già
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 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.
Ottieni i log dell'errore iniziale per diagnosticare il problema.
Se il problema persiste, vai a Devi raccogliere informazioni di diagnostica.
Raccogliere dati diagnostici
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:
-
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
-
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*
- Raccogli e fornisci i log del pod di ripristino. Tieni presente che i log sono di breve durata, quindi devono essere raccolti subito dopo l'errore.
- Se hai seguito la procedura di diagnostica precedente, raccogli tutti i componenti della console copiarli in un file e allegarlo alla richiesta di assistenza.