Solução de problemas de conectividade

  • Artigo

Neste artigo, fornecemos ajuda de solução de problemas ao conectar seu aplicativo cliente ao Cache do Azure para Redis. Os problemas de conectividade são divididos em dois tipos: problemas de conectividade intermitentes e problemas de conectividade contínuos.

Problemas de conectividade intermitentes

Seu aplicativo cliente pode ter problemas de conectividade intermitentes causados por eventos como aplicação de patch ou picos no número de conexões.

Manutenção do servidor

Às vezes, o cache passa por uma manutenção de servidor planejada ou não planejada. Seu aplicativo pode ser afetado negativamente durante a manutenção. Você pode validar verificando a métrica Errors (Type: Failover) em seu portal. Para minimizar os efeitos dos failovers, confira Resiliência de conexão.

Número de clientes conectados

Verifique se a agregação máxima para a métrica Connected Clients é próxima ou maior que o número máximo de conexões permitidas para um tamanho de cache específico. Para obter mais informações sobre o dimensionamento por conexões de cliente, confira Desempenho do Cache do Azure para Redis.

Aplicativos hospedados no Kubernetes

  • Se o aplicativo cliente estiver hospedado no Kubernetes, verifique se o Pod que está executando o aplicativo cliente ou os nós de cluster não está sob pressão de memória/CPU/rede. Um pod que executa o aplicativo cliente pode ser afetado por outros pods em execução no mesmo nó e limitar as conexões do Redis ou as operações de E/S.
  • Se você estiver usando o Istio ou qualquer outra malha de serviço, verifique se o proxy de malha de serviço reserva a porta 13000-13019 ou 15000-15019. Essas portas são usadas pelos clientes para se comunicar com os nós de um Cache do Azure para Redis clusterizado e podem causar problemas de conectividade nessas portas.

Aplicativo cliente baseado em Linux

O uso de configurações de TCP otimistas no Linux pode fazer com que os aplicativos cliente tenham problemas de conectividade. Confira Paralisações de conexão que duram 15 minutos.

Conectividade contínua

Se o aplicativo não consegue se conectar ao seu Cache do Azure para Redis, é possível que algumas configurações no cache não estejam corretas. As seções a seguir oferecem sugestões sobre como verificar se o cache está configurado corretamente.

Testar a conectividade usando redis-cli

Teste a conectividade usando redis-cli. Para obter mais informações sobre a CLI, confira Como usar a ferramenta de linha de comando Redis com Cache do Azure para Redis.

Testar a conectividade usando PSPING

Se redis-cli não puder se conectar, você poderá testar a conectividade usando o PSPING no PowerShell.

psping -q <cache DNS endpoint>:<Port Number>

Você pode confirmar se o número de pacotes enviados é igual ao de pacotes recebidos. A confirmação garante que não haja queda na conectividade.

Configuração da rede virtual

Etapas para verificar sua configuração de rede virtual:

  1. Verifique se uma rede virtual está atribuída ao seu cache da seção "Rede virtual" sob as Configurações no menu de recursos do portal do Azure.
  2. Verifique se o computador host do cliente está na mesma rede virtual que o Cache do Azure para Redis.
  3. Quando o aplicativo cliente está em uma VNet diferente do Cache do Azure para Redis, as duas VNets precisam ter o emparelhamento VNet habilitado na mesma região do Azure.
  4. Confirme que as regras de Entrada e Saída atendem aos requisitos.
  5. Para obter mais informações, confira Configurar uma rede virtual - Instância do Cache do Azure para Redis de Camada Premium.

Configuração de ponto de extremidade privado

Etapas para verificar sua configuração de ponto de extremidade privado:

  1. O sinalizador Public Network Access é desabilitado por padrão na criação de um ponto de extremidade privado. Verifique se você definiu Public Network Access corretamente. Quando seu cache estiver no portal do Azure, procure em Ponto de Extremidade Privado no menu de recursos à esquerda dessa configuração.
  2. Se você estiver tentando se conectar ao ponto de extremidade privado do cache de fora da rede virtual do seu cache, o Public Network Access precisará ser habilitado.
  3. Se você tiver excluído seu ponto de extremidade privado, verifique se o acesso à rede pública está habilitado.
  4. Verifique se o seu ponto de extremidade privado está configurado corretamente. Para obter mais informações, confira Criar um ponto de extremidade privado com uma nova instância do Cache do Azure para Redis.
  5. Verifique se o aplicativo está conectando o <cachename>.redis.cache.windows.net na porta 6380. É recomendável evitar o uso de <cachename>.privatelink.redis.cache.windows.net na configuração ou na cadeia de conexão.
  6. Execute um comando como nslookup <hostname> na VNet que está vinculada ao ponto de extremidade privado para verificar se o comando é resolvido para o endereço IP privado do cache.

Regras de firewall

Se você tiver um firewall configurado para o Cache do Azure para Redis, verifique se o endereço IP do cliente foi adicionado às regras de firewall. Você pode marcar Firewall no menu de recursos, em Configurações no portal do Azure.

Proxy externo ou firewall de terceiros

Ao usar um firewall ou proxy de terceiros em sua rede, verifique se o ponto de extremidade do Cache do Azure para Redis, *.redis.cache.windows.net, é permitido junto com as portas 6379 e 6380. Talvez seja necessário permitir mais portas ao usar um cache clusterizado ou replicação geográfica.

Alterar o endereço IP público

Se você tiver configurado qualquer recurso de rede ou segurança para usar o endereço IP público do cache, verifique se o endereço IP público do cache foi alterado. Para obter mais informações, consulte Confiar no nome do host e não no endereço IP público do cache.

Replicação geográfica usando injeção de VNet com caches Premium

Embora seja possível usar a injeção de VNet com seus caches Premium, recomendamos o Link Privado do Azure.

Para saber mais, veja:

Há suporte para a replicação geográfica de caches em VNets com ressalvas:

  • Há suporte para a replicação geográfica entre caches na mesma VNet.
  • Também há suporte para a replicação geográfica entre caches em diferentes VNets.
    • Se os VNets estiverem na mesma região, é possível conectá-los usando o emparelhamento VNet ou uma Conexão de VNet para VNet do Gateway de VPN.
    • Se as VNets estiverem em regiões diferentes, a replicação geográfica usando o emparelhamento da VNet não será suportado. Uma VM cliente na VNet 1 (região 1) não pode acessar o cache na VNet 2 (região 2) usando o nome DNS dela por causa de uma restrição com balanceadores de carga internos básicos. Para obter mais informações sobre restrições de emparelhamento VNet, consulte Rede Virtual – emparelhamento – requisitos e restrições. Recomendamos usar uma conexão VNet a VNet do Gateway de VPN.

Para configurar a VNet com eficiência e evitar problemas de replicação geográfica, você deve configurar as portas de entrada e de saída corretamente. Para obter mais informações sobre como evitar os problemas mais comuns de configuração incorreta da VNet, confira Requisitos de porta dos pares de replicação geográfica.

Conteúdo relacionado

Estes artigos fornecem mais informações sobre conectividade e resiliência: