Soluciona problemas de restablecimiento de Cassandra

Estás viendo la documentación de Apigee y Apigee Hybrid.
No hay documentación de Apigee Edge equivalente para este tema.

Síntoma

Durante el restablecimiento de Cassandra en Apigee Hybrid, puedes encontrar errores en los registros de restablecimiento.

Mensaje de error

Verás una de las siguientes opciones en los registros:

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

Causas posibles

Causa	Descripción	Instrucciones de solución de problemas aplicables para
Se ha superado el tiempo de espera de conexión.	Este error es un error de conectividad entre los pods `apigee-cassandra-restore` y `apigee-cassandra-default-*`.	Apigee Hybrid
Se agotó el tiempo de espera de la operación	Este error ocurre si el restablecimiento agota el tiempo de espera después de más de 15 minutos.	Apigee Hybrid
Already exists	Este mensaje de error no está relacionado con la causa del problema y es el resultado de una operación de reintento de un trabajo de restablecimiento.	Apigee Hybrid

Causa: Se agotó el tiempo de espera de la conexión

El siguiente error es un error de conectividad entre los pods apigee-cassandra-restore y apigee-cassandra-default-*:

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

Diagnóstico

Si no se puede acceder a la red host desde la red del pod, asegúrate de que hostNetwork esté configurado como false, en cassandra, en overrides.yaml, como se muestra en . Restablece una región a partir de una copia de seguridad.
Para probar la conectividad, accede al pod apigee-mart o apigee-runtime, que se encuentra en la misma red que el trabajo apigee-cassandra-restore. También puedes usar cualquier otro Pod en la red del Pod.
1. Obtén el nombre del pod apigee-mart:
```
kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
```
2. Ejecuta una sesión de bash dentro del pod de MART:
```
kubectl exec -it MART_POD_NAME -n apigee -- bash
```
  Reemplaza MART_POD_NAME por el nombre del Pod de MART. Por ejemplo, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl
3. Ejecuta pruebas de conectividad en puertos de 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
```
Si recibes un error Connection timed out en el resultado, significa que tienes problemas de conectividad. Sin embargo, si ves un mensaje Connected to, significa que la conexión se realizó correctamente y que debes presionar Ctrl + C para cerrarla y continuar.

Solución

Asegúrate de que la configuración HostNetwork esté configurada como false en el archivo overrides.yaml que se usa para el restablecimiento y repite el proceso de restablecimiento. Si la configuración ya está establecida en false, pero ves errores de conectividad, asegúrate de que los pods de Cassandra estén en funcionamiento con el siguiente comando:

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

El resultado debería ser similar al siguiente:

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: Se agotó el tiempo de espera de la operación

El siguiente error se produce si el restablecimiento agota el tiempo de espera después de más de 15 minutos. El error indica que los problemas de E/S, como el almacenamiento y la red, no pueden transmitir el contenido sin comprimir de la copia de seguridad a tiempo.

/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

Diagnóstico

Verifica los registros apigee-cassandra-default-0 para anotar la marca de tiempo del comienzo del restablecimiento:
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1
```
Compara la marca de tiempo con el último registro de la creación de tablas:
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1
```
Los resultados de esta comparación deben mostrar que el pod de Cassandra aun estaba en el proceso de creación de tablas después de que se superó el tiempo de espera.

Prueba el ancho de banda de almacenamiento con los siguientes comandos:

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'

Si la velocidad de escritura es inferior a 100 M/s, esto puede indicar la falta de una StorageClass (SSD) adecuada.

Prueba el ancho de banda de red:
1. Ejecuta netcat en el Pod de Cassandra para escuchar en el puerto:
```
kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'
```
2. En una sesión de shell separada, obtén el nombre del pod apigee-mart:
```
kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
```
3. Ejecuta una sesión de Bash dentro del Pod apigee-mart. También puedes usar cualquier otro Pod en la red del Pod:
```
kubectl exec -it MART_POD_NAME -n apigee -- bash
```
  Reemplaza MART_POD_NAME por el nombre del Pod de MART. Por ejemplo, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl
4. Ejecuta una prueba de ancho de banda de red en el Pod de Cassandra que aún ejecuta netcat:
```
dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456
```
Puedes repetir el proceso para otros Pods de Cassandra. Si la velocidad resultante es inferior a 10 M/s, es probable que el ancho de banda de la red sea la causa del problema.

Solución

Una vez que se confirme una velocidad de E/S lenta con los pasos anteriores, asegúrate de que tu clúster cumpla con la red y el almacenamiento mínimos requisitos. Vuelve a probar el ancho de banda más adelante.

Causa: ya existe

Diagnóstico

Podría aparecer un error similar al siguiente:

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

Solución

Este mensaje de error no está relacionado con la causa del problema y es el resultado de una operación de reintento de un trabajo de restablecimiento. El mensaje de error real debe aparecer en los registros del primer pod que falló.

Obtén los registros de la falla inicial para diagnosticar el problema.

Si el problema persiste, consulta Recopila información de diagnóstico.

Se debe recopilar información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Asistencia de Apigee:

Además de los datos habituales que puede que debas proporcionar, recopila los datos de diagnóstico de todos los pods de Cassandra con el siguiente 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

Comprimirlo y proporcionarlo en el caso de ayuda:

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

Recopila y proporciona registros del pod de restablecimiento. Ten en cuenta que los registros son de corta duración, por lo que deben recopilarse justo después de la falla.
Si seguiste los pasos de diagnóstico anteriores, recopila todos los resultados de la consola, cópialos en un archivo y adjunta el archivo al caso de ayuda.