Skip to content

Latest commit

 

History

History
108 lines (71 loc) · 7.13 KB

cache-troubleshoot-connectivity.md

File metadata and controls

108 lines (71 loc) · 7.13 KB
title titleSuffix description author ms.author ms.service ms.topic ms.date ms.custom
Troubleshoot connectivity in Azure Cache for Redis
Azure Cache for Redis
Learn how to resolve connectivity problems when creating clients with Azure Cache for Redis.
flang-msft
franlanglois
cache
conceptual
03/22/2022
template-concept

Connectivity troubleshooting

In this article, we provide troubleshooting help for connecting your client application to Azure Cache for Redis. Connectivity issues are divided into two types: intermittent connectivity issues and continuous connectivity issues.

Intermittent connectivity issues

Your client application might have intermittent connectivity issues caused by events such as patching, or spikes in the number of connections.

Server maintenance

Sometimes, your cache undergoes a planned or an unplanned server maintenance. Your application can be negatively affected during the maintenance. You can validate by checking the Errors (Type: Failover) metric on your portal. To minimize the effects of failovers, see Connection resilience.

Number of connected clients

Check if the Max aggregate for Connected Clients metric is close or higher than the maximum number of allowed connections for a particular cache size. For more information on sizing per client connections, see Azure Cache for Redis performance.

Kubernetes hosted applications

  • If your client application is hosted on Kubernetes, check that the pod running the client application or the cluster nodes aren't under memory/CPU/Network pressure. A pod running the client application can be affected by other pods running on the same node and throttle Redis connections or IO operations.
  • If you're using Istio or any other service mesh, check that your service mesh proxy reserves port 13000-13019 or 15000-15019. These ports are used by clients to communicate with a clustered Azure Cache For Redis nodes and could cause connectivity issues on those ports.

Linux-based client application

Using optimistic TCP settings in Linux might cause client applications to experience connectivity issues. See Connection stalls lasting for 15 minutes.

Continuous connectivity

If your application can't connect to your Azure Cache for Redis, it's possible some configuration on the cache isn't set up correctly. The following sections offer suggestions on how to make sure your cache is configured correctly.

Test connectivity using redis-cli

Test connectivity using redis-cli. For more information on CLI, Use the Redis command-line tool with Azure Cache for Redis.

Test connectivity using PSPING

If redis-cli is unable to connect, you can test connectivity using PSPING in PowerShell.

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

You can confirm the number of sent packets is equal to the received packets. Confirming ensures no drop in connectivity.

Virtual network configuration

Steps to check your virtual network configuration:

  1. Check if a virtual network is assigned to your cache from the "Virtual Network" section under the Settings on the Resource menu of the Azure portal.
  2. Ensure that the client host machine is in the same virtual network as the Azure Cache For Redis.
  3. When the client application is in a different VNet from your Azure Cache For Redis, both VNets must have VNet peering enabled within the same Azure region.
  4. Validate that the Inbound and Outbound rules meet the requirement.
  5. For more information, see Configure a virtual network - Premium-tier Azure Cache for Redis instance.

Private endpoint configuration

Steps to check your private endpoint configuration:

  1. Public Network Access flag is disabled by default on creating a private endpoint. Ensure that you have set the Public Network Access correctly. When you have your cache in Azure portal, look under Private Endpoint in the Resource menu on the left for this setting.
  2. If you're trying to connect to your cache private endpoint from outside your virtual network of your cache, Public Network Access needs to be enabled.
  3. If you've deleted your private endpoint, ensure that the public network access is enabled.
  4. Verify if your private endpoint is configured correctly. For more information, see Create a private endpoint with a new Azure Cache for Redis instance.
  5. Verify if your application is connecting to <cachename>.redis.cache.windows.net on port 6380. We recommend avoiding the use of <cachename>.privatelink.redis.cache.windows.net in the configuration or the connection string.
  6. Run a command like nslookup <hostname> from within the VNet that is linked to the private endpoint to verify that the command resolves to the private IP address for the cache.

Firewall rules

If you have a firewall configured for your Azure Cache For Redis, ensure that your client IP address is added to the firewall rules. You can check Firewall on the Resource menu under Settings on the Azure portal.

Third-party firewall or external proxy

When you use a third-party firewall or proxy in your network, check that the endpoint for Azure Cache for Redis, *.redis.cache.windows.net, is allowed along with the ports 6379 and 6380. You might need to allow more ports when using a clustered cache or geo-replication.

Public IP address change

If you've configured any networking or security resource to use your cache's public IP address, check to see if your cache's public IP address changed. For more information, see Rely on hostname not public IP address for your cache.

Next steps

These articles provide more information on connectivity and resilience: