Resolver problemas de conectividade

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
  • Manutenção do servidor
  • Número de clientes conectados
  • Aplicativos hospedados no Kubernetes
  • Aplicativo cliente baseado em Linux
• Problemas de conectividade contínuos
  • Testar a conectividade usando redis-cli
  • Testar a conectividade usando PSPING
  • Configuração de rede virtual
  • Configuração de ponto final privado
  • Regras da firewall
  • Alteração de endereço IP público
• Replicação geográfica usando injeção de VNet com caches Premium

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 Connected Clients métrica é próxima ou maior do que o número máximo de conexões permitidas para 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. Essas portas são usadas por clientes para se comunicar com um Cache do Azure clusterizado para nós Redis 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 Interrupções 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 rede virtual (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. Certifique-se de definir o Public Network Access corretamente. 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 você excluir seu ponto de extremidade privado, verifique se o acesso à rede pública está habilitado.
4. Verifique se o 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. Para verificar se o comando é resolvido para o endereço IP privado do cache, execute um comando como nslookup <hostname> de dentro da rede virtual (VNet) vinculada ao ponto de extremidade privado.

Regras da 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 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 você configurar 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, 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 rede virtual (VNet) com seus caches Premium, recomendamos o Azure Private Link.

Para obter mais informações, consulte:

• Migrar das caches de injeção da VNet para as caches do Private Link
• O que é o Cache Redis do Azure com o Azure Private Link?

A replicação geográfica de caches em redes virtuais (VNet) é 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 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 pode 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 (VNet) 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:

• Práticas recomendadas para resiliência de conexão
• Elevada disponibilidade para a Cache do Azure para Redis