Los pods de Cassandra que no se inician en la región secundaria

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

Síntoma

Los Pods de Cassandra no pueden iniciarse en una de las regiones de una configuración multirregional de Apigee Hybrid. Cuando se aplica el archivo overrides.yaml, los Pods de Cassandra no se inician de forma correcta.

Mensajes de error

  1. Observarás el siguiente mensaje de error en los registros del Pod de Cassandra:
    Exception (java.lang.RuntimeException) encountered during startup:
    A node with address 10.52.18.40 already exists, cancelling join.
    use cassandra.replace_addrees if you want to replace this node.
    
  2. Es posible que observes la siguiente advertencia en el estado del Pod de Cassandra:

Causas posibles

Por lo general, este problema se observa en la siguiente situación:

  1. El clúster del entorno de ejecución de Apigee se borra en una de las regiones.
  2. Se intenta reinstalar el clúster de entorno de ejecución de Apigee en la región con la configuración del host inicial de Cassandra en el archivo overrides.yaml, tal como se describe en Implementación multirregional en GKE y GKE On-Prem.
  3. Borrar el clúster de entorno de ejecución de Apigee no quita las referencias en el clúster de Cassandra. Por lo tanto, se conservarán las referencias inactivas de los Pods de Cassandra en el clúster borrado. Debido a esto, cuando intentas reinstalar el clúster de entorno de ejecución de Apigee en la región secundaria, los pods de Cassandra reclaman que ya existen ciertas direcciones IP. Esto se debe a que las direcciones IP pueden haber sido asignadas desde la misma subred que se usó antes.
Causa Descripción
Referencias inactivas a pods de región secundaria borrados en el clúster de Cassandra Si borras el clúster del entorno de ejecución de Apigee en la región secundaria, no se quitan las referencias a las direcciones IP de los pods de Cassandra en la región secundaria.

Referencias inactivas a pods de región secundaria borrados en el clúster de Cassandra

Diagnóstico

  1. El mensaje de error en los registros del Pod de Cassandra A node with address 10.52.18.40 already exists indica que existe una referencia inactiva a uno de los Pods de Cassandra de la región secundaria con la dirección IP 10.52.18.40. Para validar esto, ejecuta el comando nodetool status en la región principal.

    Resultado de muestra:

    En el ejemplo anterior, se muestra que la dirección IP 10.52.18.40 asociada con Pods de Cassandra de la región secundaria aún aparece en el resultado.

  2. Si el resultado contiene las referencias inactivas a los Pods de Cassandra en la región secundaria, indica que se borró la región secundaria, pero las direcciones IP de los Pods de Cassandra en la región secundaria no se quitan.

Solución

Realiza los siguientes pasos para quitar las referencias inactivas de los Pods de Cassandra del clúster borrado:

  1. Accede al contenedor y conéctate a la interfaz de línea de comandos de Cassandra mediante los pasos que se indican en Crea el contenedor del cliente.
  2. Después de acceder al contenedor y conectarte a la interfaz de cqlsh de Cassandra, ejecuta la siguiente consulta de SQL para enumerar las definiciones actuales de keyspace:
    select * from system_schema.keyspaces;
    

    Resultado de muestra que muestra los espacios de claves actuales:

    En el siguiente resultado, Primary-DC1 hace referencia a la región principal y Secondary-DC2 a la región secundaria.

    bash-4.4# cqlsh 10.50.112.194 -u admin_user -p ADMIN.PASSWORD --ssl
    Connected to apigeecluster at 10.50.112.194:9042.
    [cqlsh 5.0.1 | Cassandra 3.11.6 | CQL spec 3.4.4 | Native protocol v4]
    Use HELP for help.
    
    admin_user@cqlsh> Select * from system_schema.keyspaces;
    
    keyspace_name                        | durable_writes | replication
    -------------------------------------+----------------+--------------------------------------------------------------------------------------------------
    system_auth                          |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    kvm_tsg1_apigee_hybrid_prod_hybrid   |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    kms_tsg1_apigee_hybrid_prod_hybrid   |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    system_schema                        |           True |                                           {'class': 'org.apache.cassandra.locator.LocalStrategy'}
    system_distributed                   |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    system                               |           True |                                           {'class': 'org.apache.cassandra.locator.LocalStrategy'}
    perses                               |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    cache_tsg1_apigee_hybrid_prod_hybrid |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    rtc_tsg1_apigee_hybrid_prod_hybrid   |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    quota_tsg1_apigee_hybrid_prod_hybrid |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    system_traces                        |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    (11 rows)

    Como puedes ver, keyspaces hace referencia a Primary-DC1 y a Secondary-DC2, aunque el clúster del entorno de ejecución de Apigee se borró en la región secundaria.

    Las referencias inactivas a Secondary-DC2 deben borrarse de cada una de las definiciones keyspace.

  3. Antes de borrar las referencias inactivas en las definiciones keyspace, usa el siguiente comando para borrar toda la instalación híbrida de Apigee, excepto ASM (Istio) y cert-manager de Secondary-DC2. Para obtener más información, consulta Desinstala el entorno de ejecución híbrido.
    apigeectl delete -f YOUR_OVERRIDES_FILE.yaml --all
    
  4. Quita las referencias inactivas a Secondary-DC2 de cada una de las keyspaces mediante la modificación de la definición de keyspace.
    ALTER KEYSPACE system_auth WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE kvm_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE kms_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE system_distributed WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE perses WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE cache_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE rtc_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE quota_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE system_traces WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    
  5. Ejecuta el siguiente comando para verificar que las referencias inactivas a la región Secondary-DC2 se hayan quitado de todos los keyspaces:
    select * from system_schema.keyspaces;
    
  6. Accede a un Pod de Cassandra del Primary-DC1 y quita las referencias a los UUID de todos los Pods de Cassandra de Secondary-DC2. Los UUID se pueden obtener con el comando nodetool status como se describió antes en Diagnóstico.
    kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash
    nodetool -u admin_user -pw ADMIN.PASSWORD removenode UUID_OF_CASSANDRA_POD_IN_SECONDARY_DC2
    
  7. Ejecuta el comando nodetool status para verificar que no haya pods de Cassandra de Secondary-DC2 presentes.
  8. Instala el clúster de entorno de ejecución de Apigee en la región secundaria (Secondary-DC2) mediante los pasos que se detallan en Implementación multirregional en GKE y GKE On-Prem.

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:

  1. El ID del proyecto de Google Cloud
  2. El nombre de la organización de Apigee Hybrid
  3. Los archivos overrides.yaml de las regiones principal y secundaria, que enmascaran información sensible
  4. Estado del pod de Kubernetes en todos los espacios de nombres de las regiones principal y secundaria:
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
    
  5. Un volcado de cluster-info de Kubernetes desde las regiones principal y secundaria:
    # generate kubernetes cluster-info dump
    kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
    
    # zip kubernetes cluster-info dump
    zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
    
  6. El resultado de los siguientes comandos nodetool de la región principal.
    export u=`kubectl -n apigee get secrets apigee-datastore-default-creds -o jsonpath='{.data.jmx\.user}' | base64 -d`
    export pw=`kubectl -n apigee get secrets apigee-datastore-default-creds -o jsonpath='{.data.jmx\.password}' | base64 -d`
    
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw info 2>&1 | tee /tmp/k_nodetool_info_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw describecluster 2>&1 | tee /tmp/k_nodetool_describecluster_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw failuredetector 2>&1 | tee /tmp/k_nodetool_failuredetector_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw status 2>&1 | tee /tmp/k_nodetool_status_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw gossipinfo 2>&1 | tee /tmp/k_nodetool_gossipinfo_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw netstats 2>&1 | tee /tmp/k_nodetool_netstats_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw proxyhistograms 2>&1 | tee /tmp/k_nodetool_proxyhistograms_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw tpstats 2>&1 | tee /tmp/k_nodetool_tpstats_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw gcstats 2>&1 | tee /tmp/k_nodetool_gcstats_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw version 2>&1 | tee /tmp/k_nodetool_version_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw ring 2>&1 | tee /tmp/k_nodetool_ring_$(date +%Y.%m.%d_%H.%M.%S).txt
          

Referencias