Solucionar problemas de restauración de Cassandra

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

Nota: Este documento solo se aplica a los usuarios de Apigee Hybrid.

Síntoma

Durante la restauración de Cassandra en Apigee hybrid, es posible que se produzcan errores en los registros de restauración.

Mensaje de error

En los registros aparece 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

Posibles motivos

Causa	Descripción	Instrucciones de solución de problemas aplicables a
Se ha agotado el tiempo de espera de la conexión	Este error se debe a un problema de conectividad entre los pods de apigee-cassandra-restore y los de apigee-cassandra-default-*.	Apigee Hybrid
Tiempo de espera de la operación agotado	Este error se produce si se agota el tiempo de espera de la restauración después de más de 15 minutos.	Apigee Hybrid
Ya existe	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 restauración.	Apigee Hybrid

Causa: se ha agotado el tiempo de espera de la conexión

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

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

Diagnóstico

1. Si no se puede acceder a tu red de host desde la red de pods, asegúrate de que hostNetwork esté configurado como false en cassandra de overrides.yaml, tal como se muestra en Restaurar una región a partir de una copia de seguridad.
2. Para probar la conectividad, inicia sesión en el pod apigee-mart o apigee-runtime, que está en la misma red que el trabajo apigee-cassandra-restore. También puedes usar cualquier otro pod de la red.
   1. Obtén el nombre del apigee-mart pod:

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

   2. Ejecuta una sesión de bash en el pod mart:

      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Sustituye 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 aparece un error Connection timed out en el resultado, significa que tienes problemas de conectividad. Sin embargo, si ves un mensaje de Connected to, significa que la conexión se ha establecido correctamente y debes pulsar Ctrl + C para cerrarla y continuar.

Resolución

Asegúrate de que el ajuste HostNetwork esté configurado como false en el archivo overrides.yaml usado para la restauración y repite el proceso de restauración. Si el ajuste ya está configurado como false, pero ves errores de conectividad, comprueba que los pods de Cassandra estén activos con el siguiente comando:

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

La salida debería tener un aspecto similar al siguiente ejemplo:

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 ha agotado el tiempo de espera de la operación

Se produce el siguiente error si se agota el tiempo de espera de la restauración después de más de 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

1. Consulta los registros de apigee-cassandra-default-0 para anotar la marca de tiempo del inicio de la restauración:

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

2. 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 deberían mostrar que el pod de Cassandra aún estaba creando tablas después de que se superara el tiempo de espera.

3. Prueba el ancho de banda del 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, puede que no se haya usado una StorageClass (SSD) adecuada.

4. 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 otra sesión de shell, 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 en el pod apigee-mart. También puedes usar cualquier otro pod de la red de pods:

      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Sustituye 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 sigue ejecutando 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 con otros pods de Cassandra. Si la velocidad resultante es inferior a 10 M/s, lo más probable es que el problema se deba al ancho de banda de la red.

Resolución

Una vez que hayas confirmado que la velocidad de E/S es lenta siguiendo los pasos anteriores, asegúrate de que tu clúster cumpla los requisitos mínimos de red y almacenamiento. Después, vuelve a probar el ancho de banda.

Causa: ya existe

Diagnóstico

Aparece un error similar al siguiente:

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

Resolució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 restauración. El mensaje de error real debería aparecer en los registros del primer pod que ha fallado.

Obtén los registros del error inicial para diagnosticar el problema.

Si el problema persiste, ve a Recoger información de diagnóstico.

Solución alternativa para el problema conocido 391861216

Diagnóstico

El pod de Cassandra con el número más alto tiene el estado CrashLoopBackoff después de la restauración. Esto puede ocurrir debido al problema conocido 391861216. Aparece un error en el registro del pod de Cassandra similar al siguiente:

Cannot change the number of tokens from 512 to 256

Resolución

Sigue estos pasos para solucionar el problema subyacente. De esta forma, Cassandra podrá iniciarse normalmente y conservar los datos.

1. Inicia la eliminación del PVC del pod de Cassandra que está en estado CrashLoopBackoff. Define POD_NAME como el nombre del pod en el estado CrashLoopBackoff. Asigna APIGEE_NAMESPACE al espacio de nombres del clúster en el que está instalado Apigee.

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

2. Elimina el pod en estado CrashLoopBackoff.

   kubectl delete pod POD_NAME -n APIGEE_NAMESPACE

3. Cambia manualmente el host de la semilla de Cassandra al pod con el número más alto. Por ejemplo, si tienes tres réplicas, SEED_POD_NAME debe ser apigee-cassandra-default-2. Solo es necesario hacerlo una vez y se puede omitir en los pods posteriores.

   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. Elimina el nodo con 512 tokens del anillo de 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. Espera a que el pod de Cassandra se recupere, reinícialo (quizá más de una vez) y alcanza el estado Ready de 2/2. El siguiente pod más alto pasará al estado CrashLoopBackoff.

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

6. Actualiza POD_NAME y repite los pasos anteriores con los pods restantes, uno a uno, a medida que pasen al estado CrashLoopBackoff hasta que todos los pods estén en el estado Ready de 2/2 y tengan el estado Running.

7. Verifica que todos los pods se hayan unido correctamente al anillo de 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'

   Todos los nodos de Cassandra deben tener el estado UN y 256 tokens.

8. Revierte el cambio en el host de inicialización de Cassandra.

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

   El controlador de Apigee Datastore reiniciará los pods de Cassandra de nuevo, ya que revierte el cambio de host de seed.

Debe recoger información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recoge la siguiente información de diagnóstico y ponte en contacto con el equipo de Asistencia de Google Cloud:

1. Además de los datos habituales que se le pueden pedir, recoja 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
         

2. Comprímelo y facilítalo en el caso de asistencia:

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

3. Recoge y proporciona registros del pod de restauración. Ten en cuenta que los registros tienen una duración breve, por lo que deben recogerse justo después del fallo.
4. Si has seguido los pasos de diagnóstico anteriores, recoge todos los datos de salida de la consola, cópialos en un archivo y adjúntalo al parte de asistencia.