Dados inconsistentes/inexistentes observados para entidades na IU híbrida ou através das APIs de gestão

Está a ver a documentação do Apigee e do Apigee Hybrid.
Veja a documentação do Apigee Edge.

Sintoma

Os utilizadores observam dados inconsistentes ou nenhuns dados para entidades como produtos de API, apps, programadores, mapas de valores-chave (KVM) e cache intermitentemente na interface do utilizador (IU) híbrida do Apigee e através da API Management.

Mensagens de erro

Não são apresentadas mensagens de erro neste cenário.

Causas possíveis

Causa Descrição
Pods do Cassandra não ligados ao anel Os pods do Cassandra de todos os centros de dados podem não estar ligados ao anel do Cassandra comum.
A reparação da ferramenta nodetool não foi executada O comando nodetool repair pode não ter sido executado periodicamente.
Problemas de conetividade de rede Pode haver problemas de conetividade de rede entre os pods do Cassandra em diferentes centros de dados.

Passos de diagnóstico comuns

  1. Obtenha as informações sobre uma ou mais entidades para as quais está a ver este problema, como produtos de API, apps, etc., através da API Management e verifique se consegue ver resultados diferentes quando é invocada várias vezes.

    Na linha de comandos, use os seguintes exemplos para obter as suas gcloud credenciais de autenticação, definir variáveis de ambiente e executar comandos da API:

    Obtenha produtos de API:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/apiproducts"

    Obter apps:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/apps"

    Envolva programadores:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/developers"

    Obtenha mapas de pares 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"

    Get 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 não vir dados ou vir dados diferentes quando os pedidos da API Management acima forem executados, significa que está a observar o mesmo problema que observou na IU.

Causa: os pods do Cassandra não estão ligados aos pods do Cassandra de todos os centros de dados

Numa implementação híbrida do Apigee multirregional, se todos os pods do Cassandra não estiverem ligados ao mesmo anel do Cassandra, os dados podem não ser replicados por todos os pods do Cassandra. Como resultado, o plano de gestão não recebe o mesmo conjunto de dados para a mesma consulta de forma consistente. Siga os passos seguintes para analisar este cenário:

Diagnóstico

  1. Liste os pods do Cassandra:
    2. # list cassandra pods
kubectl -n apigee get pods -l app=apigee-cassandra
  2. Execute o seguinte comando para verificar o estado de todos os pods do Cassandra em cada centro de dados.

    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 do Apigee Hybrid >= 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"
  3. Verifique o resultado do comando acima e confirme se todos os pods do Cassandra em todos os centros de dados estão ligados ao anel do Cassandra e no estado Up and Normal (UN).

    Exemplo de resultado de um anel Cassandra em bom estado:

    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 resultado de um anel Cassandra não saudável:

    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

    Tenha em atenção que alguns dos pods do Cassandra do resultado acima estão no estado DL (Down and Leaving). Para mais informações, consulte o comando nodetool status.

    • Se detetar pods do Cassandra no estado DL (como se vê no exemplo de saída acima), isso é a causa deste problema.
    • Quando é feito um pedido para obter as informações sobre quaisquer entidades através da interface do utilizador híbrida ou da API Management, se o pedido atingir algum dos pods do Cassandra que estão inativos, não recebe dados.

Resolução

Execute os passos fornecidos na secção seguinte e certifique-se de que os pods do Cassandra no centro de dados problemático estão ligados ao centro de dados original, conforme descrito em Implementação multirregional no GKE e GKE on-prem | Apigee.

Causa: a reparação da nodetool não foi executada

Se o comando nodetool repair não foi executado periodicamente como uma tarefa de manutenção, existe a possibilidade de haver dados inconsistentes nos pods do Cassandra. Siga os passos seguintes para analisar este cenário:

Diagnóstico

  1. Crie um pod de contentor de cliente Cassandra apigee-hybrid-cassandra-client para depuração.
  2. Apresente todos os pods do Cassandra: 
    # list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra
  3. Ligue-se a um dos pods do Cassandra através do 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 resultado:

    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 no resultado acima, liste e consulte todas as entidades em cada centro de dados através do CQLSH.

    Se a entidade inconsistente for um produto de API:

    select * from KMS_KEYSPACE.api_product;

    Se a entidade que é inconsistente for a aplicação (app):

    select * from KMS_KEYSPACE.app;

    Se a entidade inconsistente for developer:

    select * from KMS_KEYSPACE.developer;

    Se a entidade inconsistente for um 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. Tome nota das contagens de registos da saída de cada uma das consultas acima.
  7. Repita os passos acima para cada um dos pods do Cassandra em todos os centros de dados.
  8. Compare as contagens de registos 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 ligue-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 centro de dados:

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

    nodetool repair

    Nas versões do Apigee Hybrid >= 1.4.0:

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

Causa: problemas de conetividade de rede

Se existirem problemas de conetividade de rede entre os centros de dados, os dados do Cassandra podem não ser replicados de forma consistente para todos os pods do Cassandra no anel do Cassandra. Siga os passos seguintes para analisar este cenário:

Diagnóstico

  1. Apresente todos os pods do Cassandra: 
    # list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra
  2. Execute o comando curl seguinte e use o telnet para o primeiro pod do Cassandra no segundo centro de dados (dc-2) a partir do primeiro pod do Cassandra no primeiro centro de dados (dc-1) através da 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 for bem-sucedido, é apresentado 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, é apresentado 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 conetividade do pod do Cassandra num centro de dados para o pod do Cassandra noutro centro de dados indica que tem de haver uma restrição de firewall ou algum tipo de problema de conetividade de rede.

Resolução

  1. Se esta implementação híbrida do Apigee estiver no GKE, verifique se existem regras de firewall definidas que bloqueiam o tráfego de um centro de dados para outro e analise o problema de conectividade de rede consultando a vista geral das regras de firewall da VPC.
  2. Se esta implementação híbrida do Apigee estiver no GKE-on-prem, trabalhe com a equipa de rede relevante e analise o problema de conetividade de rede.

Tem de recolher 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, em seguida, contacte o apoio ao cliente da Google Cloud:

  1. O ID do projeto do Google Cloud
  2. A organização do Apigee Hybrid
  3. O ficheiro overrides.yaml, ocultando quaisquer informações confidenciais
  4. Estado 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 Kubernetes cluster-info dump: 
    # 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