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.

Observação: este documento é destinado apenas a usuários da Apigee.

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:

# list cassandra pods
kubectl -n apigee get pods -l app=apigee-cassandra

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

3. 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 da Apigee:

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

• Implantação de várias regiões da Apigee híbrida no GKE e no GKE On-Prem
• Documentação do Kubernetes
• Comando de status do nodetool para Cassandra