Error de replicación de datos de Cassandra

Estás viendo la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.

Síntoma

Cuando se replican datos durante una expansión multirregional, el estado CassandraDataReplication puede mostrar un estado de error y la replicación de datos puede fallar.

Mensaje de error

Cuando uses kubectl para ver el estado de recompilación:

  kubectl -n apigee get apigeeds \
  -o jsonpath="{.items[].status.cassandraDataReplication}{'\n'}"

Verás que uno o más pods de Cassandra muestran un estado de error y un mensaje en el que se indica que la recompilación falló. Por ejemplo:

{
  "rebuildDetails": {
    "apigee-cassandra-default-0": {
      "message": "failed to rebuild from us-west1: java.lang.IllegalStateException : Unable to find sufficient sources for streaming range (-8567285182390470134,-8567154549835592965] in keyspace system_distributed",
      "state": "error",
      "updated": 1641581899
    },
    …
  }
}

Causas posibles

Causa Descripción Instrucciones de solución de problemas aplicables para
Región de origen incorrecta Se especificó un valor incorrecto para source.region dentro del archivo YAML de la replicación de datos de Cassandra. Apigee Hybrid
Problemas con la conectividad de red Es posible que haya problemas de conectividad de red entre Pods de Cassandra en centros de datos diferentes. Apigee Hybrid

Pasos comunes de diagnóstico

  1. Recupera el estado de la replicación de datos:
    kubectl -n apigee get apigeeds \
    -o jsonpath="{.items[].status.cassandraDataReplication}{'\n'}"
  2. Si ves un error con un mensaje similar al especificado en Mensaje de error, significa que estás observando este problema.

Causa: región de origen incorrecta

Si especificas una región de origen (datacenter) en tu archivo YAML de replicación de datos que es diferente de la datacenter de origen real, la replicación de datos fallará. Sigue los pasos en Diagnóstico para analizar esta situación y realiza los pasos en Resolución a fin de corregirla.

Diagnóstico

  1. Enumera todos los pods de Cassandra en la región de origen:
    kubectl -n apigee get pods -l app=apigee-cassandra
    
  2. Obtén el valor datacenter real de cualquiera de los pods de Cassandra que se muestran en el paso 1:
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- \
    nodetool -u JMX_user -pw JMX_password status
    
  3. Obtén el valor que se usaste para source.region en el archivo de recursos personalizados (YAML) de replicación de datos de Cassandra que creaste en Implementación multirregión. Si usas el nombre de archivo de ejemplo que se encuentra en la documentación de implementación multirregional, este se debe llamar datareplication.yaml.
    cat datareplication.yaml
    

    Resultados de ejemplo:

    apiVersion: apigee.cloud.google.com/v1alpha1
    kind: CassandraDataReplication
    metadata:
      name: region-expansion
      namespace: apigee
    spec:
      organizationRef: apigee-hybrid-example-org
      force: false
      source:
        region: "us-west1"
  4. Comprueba el valor del resultado de nodetool status y verifica si el valor datacenter coincide o no con el de source.region:

    kubectl -n apigee exec -it apigee-cassandra-default-0 -- \
    nodetool -u jmxuser -pw iloveapis123 status
    

    Resultados de ejemplo:

    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.104.13.2  491.84 KiB  256          100.0%            7254711c-fe0a-4b34-b50f-861109f97936  ra-1
    UN  10.104.11.3  527.36 KiB  256          100.0%            5ec389f0-fd67-4de6-9f21-172d5899ff78  ra-1
    UN  10.104.12.7  838.46 KiB  256          100.0%            7a88be82-1f81-4117-86e3-2cda434c0878  ra-1
  5. Ten en cuenta que el source.region (us-west1) del archivo datareplication.yaml no coincide con el valor datacenter (dc-1) real del resultado de estado nodetool. Sigue los pasos que se indican en Resolución para corregir la configuración.

Solución

Para corregir la replicación de datos, deberás borrar el trabajo de replicación de datos y crearlo con el nombre datacenter correcto. Sigue los siguientes pasos:

  1. Borra el proceso de replicación de datos actual. Si se usa el nombre de archivo de ejemplo que se encuentra en la documentación de la implementación de varias regiones, este se debe llamar datareplication.yaml.
    kubectl delete -f datareplication.yaml
    
  2. Actualiza el nombre de la región en el archivo YAML al valor datacenter correcto, p. ej., dc-1:
    apiVersion: apigee.cloud.google.com/v1alpha1
    kind: CassandraDataReplication
    metadata:
      name: region-expansion
      namespace: apigee
    spec:
      organizationRef: apigee-hybrid-example-org
      force: false
      source:
        region: "dc-1"
  3. Aplica la replicación de datos actualizada:
    kubectl apply -f datareplication.yaml
    
  4. Comprueba el estado de la recompilación con el siguiente comando y verifica que ya no veas el estado de error informado anteriormente:
      kubectl -n apigee get apigeeds \
      -o jsonpath="{.items[].status.cassandraDataReplication}{'\n'}"
    
  5. Si el problema persiste, ve a Causa: problemas de conectividad de red.

Causa: Problemas de conectividad de red

El error de replicación de datos también puede ser el resultado de los problemas de conectividad entre los nodos de Cassandra.

Diagnóstico

Sigue estos pasos para analizar esta situación:

  1. Obtén una lista de todos los Pods de Cassandra:
    # list cassandra pods
    kubectl -n=apigee get pods -l app=apigee-cassandra
  2. Ejecuta el siguiente comando curl y Telnet en el primer Pod de Cassandra en el segundo centro de datos (dc-2) del primer Pod de Cassandra en el primer centro de datos (dc-1) mediante el puerto 7001:
    kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001
  3. Si Telnet ejecuta de forma correcta, se muestra un resultado similar al siguiente:
    * Rebuilt URL to: telnet://10.0.4.10:7001/
    *   Trying 10.0.4.10...
    * TCP_NODELAY set
    * Connected to 10.0.4.10 (10.0.4.10) port 7001 (#0)
  4. De lo contrario, se muestra un error similar al siguiente:
    * Rebuilt URL to: telnet://10.0.4.10:7001/
    *   Trying 10.0.4.10...
    * TCP_NODELAY set
    * connect to 10.0.4.10 port 7001 failed: Connection refused
    * Failed to connect to 10.0.4.10 port 7001: Connection refused
    * Closing connection 0
    curl: (7) Failed to connect to 10.0.4.10 port 7001: Connection refused

    La falla de conectividad del Pod de Cassandra en un centro de datos al Pod de Cassandra en otro centro de datos indica que debe haber una restricción de firewall o una especie de problema de conectividad de red.

Solución

  1. Si esta implementación híbrida de Apigee está en GKE, verifica si se establecieron reglas de firewall que bloquean el tráfico de un centro de datos a otro y analiza el problema de conectividad de red. Para ello consulta Descripción general de las reglas de firewall de VPC.
  2. Si esta implementación híbrida de Apigee está en GKE On-Prem, trabaja con el equipo de red relevante y analiza el problema de conectividad de red.

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.

  1. El ID del proyecto de Google Cloud.
  2. La organización híbrida de Apigee
  3. Los archivos overrides.yaml de las regiones nuevas y de origen, que enmascaran cualquier información sensible.
  4. El archivo YAML CassandraDataReplication.
  5. Resultado de nodetool status de Cassandra:
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- \
    nodetool -u JMX_user -pw JMX_password status
    
  6. Resultado de nodetool describecluster de Cassandra:
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- \
    nodetool -u JMX_user -pw JMX_password describecluster