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

En los registros, ves uno de los siguientes mensajes:

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 es un error de conectividad entre Pods `apigee-cassandra-restore` y Pods `apigee-cassandra-default-*`.	Apigee Hybrid
Se agotó el tiempo de espera de la operación	Este error se produce si el tiempo de espera de la restauración supera los 15 minutos.	Apigee Hybrid
Already exists	Este mensaje de error no se relaciona con la causa del problema y es el resultado de una operación de reintento de un trabajo de restauración.	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 los Pods apigee-cassandra-default-*:

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

Diagnóstico

Si no se puede acceder a tu 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 Cómo restablecer 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 de Pods.
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 los 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 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 el parámetro de configuración ya está configurado como 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

Se produce el siguiente error si el tiempo de espera de la restauración supera los 15 minutos. El error indica problemas de E/S, como que 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

Revisa los registros de apigee-cassandra-default-0 para anotar la marca de tiempo del comienzo de la restauración:
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1
```
Compara la marca de tiempo con el registro más reciente de la creación de la tabla:
```
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, es posible que no se esté usando una StorageClass (SSD) adecuada.

Prueba el ancho de banda de la 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 independiente, 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 de Pods:
```
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 todavía 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 después.

Causa: Ya existe

Diagnóstico

Verás 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 se relaciona con la causa del problema y es el resultado de una operación de reintento de un trabajo de restauración. El mensaje de error real debería mostrarse 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 Atención al cliente de Google Cloud:

Además de los datos habituales que se te puede solicitar que proporciones, 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

Comprimirla y proporcionarla 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 se deben recopilar inmediatamente 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 adjúntalo al caso de asistencia.