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

  1. 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.
  2. 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

  1. 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

  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 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.

  3. 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.

  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 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.

Solución alternativa para el problema conocido 391861216

Diagnóstico

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

Cannot change the number of tokens from 512 to 256

Solución

Sigue estos pasos para borrar el problema subyacente. Esto permitirá que Cassandra se inicie de forma normal y, al mismo tiempo, se preserven los datos.

  1. Inicia la eliminación del PVC del pod de Cassandra atascado en el estado CrashLoopBackoff. Establece POD_NAME en el nombre del pod en el estado CrashLoopBackoff. Configura APIGEE_NAMESPACE con el espacio de nombres del clúster en el que se instaló Apigee. 

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

  2. Borra el pod en el estado CrashLoopBackoff. 

    kubectl delete pod POD_NAME -n APIGEE_NAMESPACE

  3. Cambia manualmente el host de origen 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. Esto solo se debe hacer una vez y se puede omitir para 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. Quita 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, reinicie posiblemente más de una vez y alcance un estado Ready de 2/2. Luego, 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 para los pods restantes, uno a la vez, a medida que entran en el estado CrashLoopBackoff hasta que todos los pods estén en un estado Ready de 2/2 y tengan un 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 origen 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 nuevamente a medida que revierta el cambio de host inicial.

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:

  1. 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

  2. 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*
  3. 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.
  4. 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.