Resolver problemas de conectividade

  • Artigo

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

Problemas de conectividade intermitentes

A aplicação do cliente pode ter problemas de conectividade intermitentes causados por eventos como a aplicação de patches ou picos no número de ligações.

Manutenção de servidores

Por vezes, a cache é submetida a uma manutenção planeada ou não planeada do servidor. A aplicação pode ser afetada negativamente durante a manutenção. Você pode validar verificando a Errors (Type: Failover) métrica no seu portal. Para minimizar os efeitos dos failovers, consulte Resiliência da conexão.

Número de clientes ligados

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

Aplicações anfitriãs do Kubernetes

  • Se a aplicação cliente estiver alojada no Kubernetes, verifique se o pod em execução na aplicação cliente ou nos nós de cluster não está sob pressão de memória/CPU/Rede. Um pod em execução na aplicação cliente pode ser afetado por outros pods em execução no mesmo nó e limitar as ligações 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. Estas portas são utilizadas pelos clientes para comunicar com os nós da Cache do Azure para Redis em cluster e podem causar problemas de conectividade nessas portas.

Aplicação cliente baseada no Linux

A utilização de definições TCP otimistas no Linux pode fazer com que as aplicações cliente tenham problemas de conectividade. Consulte Paradas de conexão com duração de 15 minutos.

Conectividade contínua

Se a aplicação não se conseguir ligar à Cache do Azure para Redis, é possível que alguma configuração na cache não esteja correta. As secções seguintes oferecem sugestões sobre como garantir que a cache está configurada corretamente.

Testar a conectividade usando redis-cli

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

Testar a conectividade com PSPING

Se redis-cli não conseguir estabelecer a ligação, poderá testar a conectividade com PSPING no PowerShell.

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

Pode confirmar se o número de pacotes enviados é igual ao de pacotes recebidos. A confirmação garante que não existe nenhuma quebra na conectividade.

Configuração da rede virtual

Passos para verificar a configuração da rede virtual:

  1. Verifique se uma rede virtual está atribuída ao seu cache na seção "Rede Virtual" nas Configurações no menu Recurso do portal do Azure.
  2. Verifique se a máquina 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 seu Cache do Azure para Redis, ambas as VNets devem ter o emparelhamento de VNet habilitado dentro da mesma região do Azure.
  4. Valide se as regras de entrada e saída atendem ao requisito.
  5. Para obter mais informações, consulte Configurar uma rede virtual - Cache do Azure de camada Premium para instância Redis.

Configuração dos pontos finais privados

Passos para verificar a configuração dos pontos finais privados:

  1. Public Network Access flag é desabilitado por padrão ao criar um ponto de extremidade privado. Garanta que definiu corretamente Public Network Access. Quando você tiver seu cache no portal do Azure, procure em Ponto de Extremidade Privado no menu Recurso à esquerda para essa configuração.
  2. Se você estiver tentando se conectar ao ponto de extremidade privado do cache de fora da rede virtual do cache, Public Network Access será necessário ativá-lo.
  3. Se tiver eliminado o seu ponto de extremidade privado, certifique-se de que o acesso à rede pública está ativado.
  4. Verifique se o seu ponto de extremidade privado está configurado corretamente. Para obter mais informações, veja Criar um ponto final privado com uma nova instância da Cache do Azure para Redis.
  5. Verifique se seu aplicativo está se conectando à <cachename>.redis.cache.windows.net porta 6380. É recomendável evitar utilizar <cachename>.privatelink.redis.cache.windows.net na configuração ou na cadeia de ligação.
  6. Execute um comando como nslookup <hostname> na VNet vinculada ao ponto de extremidade privado para verificar se o comando é resolvido para o endereço IP privado do cache.

Regras da firewall

Se tiver uma firewall configurada para a Cache do Azure para Redis, verifique se o endereço IP cliente foi adicionado às regras da firewall. Você pode verificar Firewall no menu Recurso em Configurações no portal do Azure.

Firewall de terceiros ou proxy externo

Ao utilizar uma firewall ou proxy de terceiros na rede, verifique se o ponto final da Cache do Azure para Redis, *.redis.cache.windows.net, é permitido juntamente com as portas 6379 e 6380. Pode ter de permitir mais portas ao utilizar uma cache em cluster ou a georreplicação.

Alteração do endereço IP público

Se tiver configurado qualquer recurso de rede ou de segurança para utilizar o endereço IP público da cache, verifique se o endereço IP público da cache foi alterado. Para obter mais informações, veja Confiar no nome do anfitrião e não no endereço IP público para a 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 Azure Private Link.

Para obter mais informações, consulte:

A replicação geográfica de caches em redes virtuais é suportada com advertências:

  • Há suporte para replicação geográfica entre caches na mesma VNet.
  • A replicação geográfica entre caches em diferentes redes virtuais também é suportada.
    • Se as redes virtuais estiverem na mesma região, você poderá conectá-las usando o emparelhamento de VNet ou uma conexão VNet-to-VNet do Gateway VPN.
    • Se as redes virtuais estiverem em regiões diferentes, não há suporte para replicação geográfica usando emparelhamento de VNet. Uma VM cliente na VNet 1 (região 1) não consegue acessar o cache na VNet 2 (região 2) usando seu nome DNS devido a uma restrição com balanceadores de carga internos básicos. Para obter mais informações sobre restrições de emparelhamento de rede virtual, consulte Rede virtual - Emparelhamento - Requisitos e restrições. Recomendamos o uso de uma conexão VNet-to-VNet do Gateway VPN.

Para configurar sua rede virtual de forma eficaz e evitar problemas de replicação geográfica, você deve configurar as portas de entrada e saída corretamente. Para obter mais informações sobre como evitar os problemas mais comuns de configuração incorreta de VNet, consulte Requisitos de porta de mesmo nível de replicação geográfica.

Conteúdo relacionado

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