Dados inconsistentes/sem dados observados para entidades na IU híbrida ou por meio das APIs Management

Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.

Sintoma

Os usuários observam dados inconsistentes ou não têm dados para entidades como produtos de API, aplicativos, desenvolvedores, mapas de valores-chave (KVM) e cache de forma intermitente na interface de usuário híbrida (IU) da Apigee e por meio da API de gerenciamento.

Mensagens de erro

Nenhuma mensagem de erro é conhecida no cenário.

Causas possíveis

Causa Descrição
Pods do Cassandra não conectados ao anel Os pods do Cassandra de todos os data centers talvez não estejam conectados ao anel comum do Cassandra.
O reparo do nodetool não foi executado O comando nodetool repair pode não ter sido executado periodicamente.
Problemas de conectividade de rede Pode haver problemas de conectividade de rede entre os pods do Cassandra em diferentes data centers.

Etapas comuns do diagnóstico

  1. Busque as informações sobre uma ou mais entidades para as quais você está enfrentando esse problema, como produtos de API, apps e assim por diante, usando a API Management e verifique se você pode ou não ver resultados diferentes quando invocado várias vezes.

    Na linha de comando, use os exemplos a seguir para receber suas credenciais de autenticação gcloud, definir variáveis de ambiente e executar comandos da API:

    Veja os produtos da API:

    TOKEN=$(gcloud auth print-access-token)
    ORG=ORGANIZATION_NAME
    
    curl -i -H "Authorization: Bearer $TOKEN" \
    "https://apigee.googleapis.com/v1/organizations/$ORG/apiproducts"

    Acessar os apps:

    TOKEN=$(gcloud auth print-access-token)
    ORG=ORGANIZATION_NAME
    
    curl -i -H "Authorization: Bearer $TOKEN" \
    "https://apigee.googleapis.com/v1/organizations/$ORG/apps"

    Faça o download dos desenvolvedores:

    TOKEN=$(gcloud auth print-access-token)
    ORG=ORGANIZATION_NAME
    
    curl -i -H "Authorization: Bearer $TOKEN" \
    "https://apigee.googleapis.com/v1/organizations/$ORG/developers"

    Acessar mapas de chave-valor (KVMs):

    TOKEN=$(gcloud auth print-access-token)
    ORG=ORGANIZATION_NAME
    
    curl -i -H "Authorization: Bearer $TOKEN" \
    "https://apigee.googleapis.com/v1/organizations/$ORG/keyvaluemaps"

    Usar caches:

    TOKEN=$(gcloud auth print-access-token)
    ORG=ORGANIZATION_NAME
    ENV=ENVIRONMENT_NAME
    
    curl -i -H "Authorization: Bearer $TOKEN" \
    "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/caches"
  2. Se você não vir dados ou dados diferentes quando as solicitações da API Management acima forem executadas, significa que você está observando o mesmo problema observado na IU.

Causa: pods do Cassandra não conectados aos pods do Cassandra de todos os data centers

Em uma implantação da Apigee híbrida multirregional, se todos os pods do Cassandra não estiverem conectados ao mesmo anel Cassandra, os dados podem não ser replicados por todos os pods do Cassandra. Como resultado, o plano de gerenciamento não receberá o mesmo conjunto de dados para a mesma consulta de forma consistente. Execute as etapas a seguir para analisar esse cenário:

Diagnóstico

  1. Liste os pods do Cassandra:
  2. # list cassandra pods
    kubectl -n apigee get pods -l app=apigee-cassandra
  3. Execute o comando a seguir para verificar o status de todos os pods do Cassandra em cada data center.

    Na versão híbrida do Apigee < 1.4.0:

    # check cassandra cluster status
    kubectl -n apigee get pods \
    -l app=apigee-cassandra \
    --field-selector=status.phase=Running \
    -o custom-columns=name:metadata.name --no-headers \
    | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool status"

    Nas versões híbridas do Apigee >= 1.4.0:

    # check cassandra cluster status
    kubectl -n apigee get pods \
    -l app=apigee-cassandra \
    --field-selector=status.phase=Running \
    -o custom-columns=name:metadata.name --no-headers \
    | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw JMXUSER_PASSWORD status"
  4. Verifique o resultado do comando acima e confirme se todos os pods do Cassandra em todos os data centers estão conectados ao anel Cassandra e no status Up and Normal (UN).

    Exemplo de saída de um anel Cassandra íntegro:

    kubectl -n apigee get pods \
    -l app=apigee-cassandra \
    --field-selector=status.phase=Running \
    -o custom-columns=name:metadata.name --no-headers \
    | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw iloveapis123 status"
    
    apigee-cassandra-default-0
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
    UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
    UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
    Datacenter: dc-2
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
    UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
    UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1
    
    apigee-cassandra-default-1
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
    UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
    UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
    Datacenter: dc-2
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
    UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
    UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1
    
    apigee-cassandra-default-2
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
    UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
    UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
    Datacenter: dc-2
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
    UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
    UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

    Exemplo de saída de um anel de Cassandra não íntegro:

    kubectl -n apigee get pods \
    -l app=apigee-cassandra \
    --field-selector=status.phase=Running \
    -o custom-columns=name:metadata.name --no-headers \
    | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw iloveapis123 status"
    
    apigee-cassandra-default-0
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
    DL  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
    DL  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
    Datacenter: dc-2
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
    UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
    DL  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1
    
    apigee-cassandra-default-1
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
    UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
    UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
    Datacenter: dc-2
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
    UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
    UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1
    
    apigee-cassandra-default-2
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
    UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
    UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
    Datacenter: dc-2
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
    UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
    UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

    Observe que alguns dos pods do Cassandra da saída acima estão no status DL (baixo e saída). Para mais informações, consulte status do nodetool.

    • Se você observar qualquer pod do Cassandra no status DL (como visto no exemplo de saída acima), essa seria a causa desse problema.
    • Quando uma solicitação é feita para buscar informações sobre qualquer entidade por meio da IU híbrida ou da API de gerenciamento, se a solicitação atingir qualquer um dos pods do Cassandra que estão inativos, você não terá dados.

Resolução

Siga as etapas fornecidas na seção a seguir e verifique se os pods do Cassandra no data center problemático estão conectados ao data center original, conforme descrito em Implantação multirregional no GKE e no GKE On-Prem | Apigee.

Causa: o reparo do nodetool não foi executado

Se o comando nodetool repair não foi executado periodicamente como uma tarefa de manutenção, há a possibilidade de dados inconsistentes nos pods do Cassandra. Execute as etapas a seguir para analisar esse cenário:

Diagnóstico

  1. Crie um pod de contêiner do cliente do Cassandra apigee-hybrid-cassandra-client para depuração.
  2. Liste todos os pods do Cassandra:
    # list cassandra pods
    kubectl -n=apigee get pods -l app=apigee-cassandra
  3. Conecte-se a um dos pods do Cassandra usando CQLSH:
    cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
  4. Lista keyspaces:
    SELECT * from system_schema.keyspaces;

    Exemplo de resposta:

    ddl_user@cqlsh> SELECT keyspace_name from system_schema.keyspaces;
    
     keyspace_name
    -----------------------------
                     system_auth
     cache_PROJECT_ID_hybrid
                   system_schema
       kms_PROJECT_ID_hybrid
       kvm_PROJECT_ID_hybrid
       rtc_PROJECT_ID_hybrid
              system_distributed
                          system
                          perses
                   system_traces
     quota_PROJECT_ID_hybrid
    
    (11 rows)
  5. Identifique o keyspaces do resultado acima, liste e consulte todas as entidades em cada data center usando o CQLSH.

    Se a entidade inconsistente for o produto da API:

    select * from KMS_KEYSPACE.api_product;

    Se a entidade inconsistente for o aplicativo (app):

    select * from KMS_KEYSPACE.app;

    Se a entidade inconsistente for developer:

    select * from KMS_KEYSPACE.developer;

    Se a entidade inconsistente for o mapa de chave-valor:

    select * from KVM_KEYSPACE.kvm_map_entry;

    Se a entidade inconsistente for cache:

    select * from CACHE_KEYSPACE.cache_map_entry;
  6. Anote as contagens de registros da saída de cada uma das consultas acima.
  7. Repita as etapas acima para cada um dos pods do Cassandra em todos os data centers.
  8. Compare as contagens de registros obtidas de todos os pods do Cassandra.
  9. Identifique os pods do Cassandra que têm dados inconsistentes.

Resolução

  1. Liste os pods do Cassandra e conecte-se a um pod específico do Cassandra que tinha dados inconsistentes:
    # list cassandra pods
    kubectl -n=apigee get pods -l app=apigee-cassandra
    
    # connect to one cassandra pod
    kubectl -n=apigee exec -it apigee-cassandra-default-0 bash
  2. Execute o comando nodetool repair em cada pod do Cassandra em cada data center:

    Na versão híbrida do Apigee < 1.4.0:

    nodetool repair

    Nas versões híbridas do Apigee >= 1.4.0:

    nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair
  3. Siga a seção de diagnóstico novamente e verifique se os dados foram replicados para todos os pods do Cassandra de maneira consistente.
  4. Repita as etapas acima para todos os pods do Cassandra que tinham dados inconsistentes.

Causa: problemas de conectividade de rede

Se houver problemas de conectividade de rede entre os data centers, os dados do Cassandra não serão replicados de maneira consistente para todos os pods do Cassandra no anel do Cassandra. Execute as etapas a seguir para analisar esse cenário:

Diagnóstico

  1. Liste todos os pods do Cassandra:
    # list cassandra pods
    kubectl -n=apigee get pods -l app=apigee-cassandra
  2. Execute o comando curl a seguir e telnet para o primeiro pod do Cassandra no segundo data center (dc-2) do primeiro pod do Cassandra no primeiro data center (dc-1), usando a porta. 7001:
      kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001
  3. Se o telnet tiver sido bem-sucedido, será exibido um resultado semelhante ao seguinte:
    * 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. Caso contrário, será exibido um erro semelhante ao seguinte:
    * 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

    A falha de conectividade do pod do Cassandra em um data center para o pod do Cassandra em outro data center indica que deve haver uma restrição de firewall ou algum tipo de problema de conectividade de rede.

Resolução

  1. Se essa implantação da Apigee híbrida estiver no GKE, verifique se alguma regra de firewall está definida para bloquear o tráfego de um data center para outro e analise o problema de conectividade de rede consultando VPC Visão geral das regras de firewall.
  2. Se essa implantação da Apigee híbrida estiver no GKE On-Prem, trabalhe com a equipe de rede relevante e analise o problema de conectividade de rede.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e entre em contato com o Suporte do Google Cloud:

  1. O ID do projeto do Google Cloud
  2. A organização da Apigee híbrida
  3. O arquivo overrides.yaml, mascarando informações confidenciais
  4. Status do pod do Kubernetes em todos os namespaces:
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Um cluster-info dump do Kubernetes:
    # 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/*

Referências