Partager via

Résolution des problèmes de connectivité

  • Article

Dans cet article, nous fournissons une aide à la résolution des problèmes de connexion de votre application cliente à Azure Cache pour Redis. Les problèmes de connectivité sont divisés en deux types : les problèmes de connectivité intermittente et les problèmes de connectivité continue.

Problèmes de connectivité intermittente

Votre application cliente peut présenter des problèmes de connectivité intermittente dus à des événements tels que la mise à jour corrective ou des pics au niveau du nombre de connexions.

Maintenance des serveurs

Parfois, votre cache subit une maintenance planifiée ou non planifiée des serveurs. Votre application peut être impactée négativement au cours de la maintenance. Vous pouvez le confirmer en examinant la métrique Errors (Type: Failover) dans votre portail. Pour minimiser les effets des basculements, consultez Résilience des connexions.

Nombre de clients connectés

Vérifiez si l’agrégat Max pour la métrique Connected Clients est proche du nombre maximal de connexions autorisées pour une taille de cache particulière, ou supérieur à celui-ci. Pour plus d’informations sur le dimensionnement des connexions par client, consultez Performances d’Azure Cache pour Redis.

Applications hébergées par Kubernetes

  • Si votre application cliente est hébergée sur Kubernetes, vérifiez que le pod exécutant l’application cliente ou les nœuds du cluster ne sont pas soumis à une sollicitation de la mémoire/du processeur/du réseau. Un pod exécutant l’application cliente peut être affecté par d’autres pods en cours d’exécution sur le même nœud, et limiter les connexions Redis ou les opérations d’E/S.
  • Si vous utilisez Istio ou tout autre maillage de services, vérifiez que votre proxy de maillage de services réserve le port 13000-13019 ou 15000-15019. Ces ports sont utilisés par les clients pour communiquer avec des nœuds Azure Cache pour Redis en cluster et des problèmes de connectivité peuvent survenir sur ces ports.

Application cliente basée sur Linux

L’utilisation de paramètres TCP optimistes dans Linux peut entraîner des problèmes de connectivité pour les applications clientes. Consultez Interruptions de connexion d’une durée de 15 minutes.

Connectivité continue

Si votre application ne peut pas se connecter à Azure Cache pour Redis, il est possible qu’une certaine configuration sur le cache ne soit pas définie correctement. Les sections suivantes présentent des suggestions sur la façon de vérifier que votre cache est correctement configuré.

Tester la connectivité avec redis-cli

Testez la connectivité avec redis-cli. Pour plus d’informations sur l’interface CLI, utilisez l’outil de ligne de commande Redis avec Azure Cache pour Redis.

Tester la connectivité avec PSPING

Si redis-cli ne parvient pas à se connecter, vous pouvez tester la connectivité à l’aide de PSPING dans PowerShell.

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

Vous pouvez vérifier que le nombre de paquets envoyés est égal aux paquets reçus. La vérification permet d’éviter toute baisse de connectivité.

Configuration du réseau virtuel

Procédure de vérification de la configuration de votre réseau virtuel :

  1. Vérifiez si un réseau virtuel est attribué à votre cache à partir de la section « Réseau virtuel » sous Paramètres dans le menu Ressources du portail Azure.
  2. Assurez-vous que l’ordinateur hôte du client se trouve dans le même réseau virtuel qu’Azure Cache pour Redis.
  3. 3. Si l’application cliente ne se trouve pas sur le même réseau virtuel (VNet) qu’Azure Cache pour Redis, le peering de réseaux virtuels doit être activé sur les deux réseaux virtuels dans la même région Azure.
  4. Vérifiez que les règles de trafic entrant et sortant remplissent les conditions requises.
  5. Pour plus d’informations, consultez Configurer un réseau virtuel – Instance Azure Cache pour Redis de niveau Premium.

Configuration de point de terminaison privé

Procédure de vérification de la configuration de votre point de terminaison privé :

  1. L’indicateur Public Network Access est désactivé par défaut lors de la création d’un point de terminaison privé. Vérifiez que vous avez correctement défini l’indicateur Public Network Access. Une fois votre cache dans le portail Azure, regardez sous Point de terminaison privé dans le menu Ressources à gauche à la recherche de ce paramètre.
  2. Si vous essayez de vous connecter au point de terminaison privé de votre cache en dehors du réseau virtuel du cache, Public Network Access doit être activé.
  3. 3. Si vous supprimez votre point de terminaison privé, assurez-vous que l’accès au réseau public est activé.
  4. Vérifiez si votre point de terminaison privé est correctement configuré. Pour plus d’informations, consultez Créer un point de terminaison privé avec une nouvelle instance Azure Cache pour Redis.
  5. Vérifiez si votre application se connecte à <cachename>.redis.cache.windows.net sur le port 6380. Nous vous recommandons d’éviter d’utiliser <cachename>.privatelink.redis.cache.windows.net dans la configuration ou la chaîne de connexion.
  6. Pour vérifier que la commande est résolue en adresse IP privée pour le cache, exécutez une commande comme nslookup <hostname> à partir du réseau virtuel lié au point de terminaison privé.

Règles de pare-feu

Si un pare-feu est configuré pour Azure Cache pour Redis, assurez-vous que l’adresse IP de votre client est ajoutée aux règles de pare-feu. Vous pouvez examiner Pare-feu dans le menu Ressources sous Paramètres dans le portail Azure.

Pare-feu ou proxy externe tiers

Quand vous utilisez un pare-feu ou un proxy tiers dans votre réseau, vérifiez que le point de terminaison pour Azure Cache pour Redis, *.redis.cache.windows.net, est autorisé avec les ports 6379 et 6380. Vous devrez peut-être autoriser davantage de ports lors de l’utilisation d’un cache en cluster ou de la géoréplication.

Modification de l’adresse IP publique

Si vous configurez une ressource réseau ou de sécurité pour utiliser l’adresse IP publique de votre cache, vérifiez si l’adresse IP publique de votre cache a changé. Pour plus d’informations, consultez S’appuyer sur l’adresse IP non publique du nom d’hôte pour votre cache.

Géoréplication à l'aide de l'injection de réseau virtuel avec des caches Premium

Bien qu’il soit possible d’utiliser l’injection de réseau virtuel avec vos caches Premium, nous recommandons Azure Private Link.

Pour plus d’informations, consultez l’article suivant :

La géoréplication des caches dans les réseaux virtuels est prise en charge avec des mises en garde :

  • La géoréplication entre caches figurant dans un même réseau virtuel est prise en charge.
  • La géoréplication entre caches figurant dans des réseaux virtuels différents est également prise en charge.
    • Si les réseaux virtuels se trouvent dans la même région, vous pouvez les connecter via un peering de réseaux virtuels ou une connexion de passerelle VPN de réseau virtuel à réseau virtuel.
    • Si les réseaux virtuels se trouvent dans différentes régions, la géoréplication à l’aide du peering de réseaux virtuels n’est pas prise en charge. Une machine virtuelle cliente du réseau virtuel 1 (région 1) ne peut pas accéder au cache du réseau virtuel 2 (région 2) à l'aide de son nom DNS en raison d'une contrainte avec les équilibreurs de charge internes de base. Pour plus d'informations sur les contraintes liées au peering de réseaux virtuels, consultez Réseau virtuel - Peering - Exigences et contraintes. Nous vous recommandons d’utiliser une connexion de passerelle VPN de réseau virtuel à réseau virtuel.

Pour configurer efficacement votre réseau virtuel et éviter les problèmes de géoréplication, vous devez configurer correctement les ports entrants et sortants. Pour plus d’informations sur la manière d’éviter les problèmes de configuration incorrecte de réseau virtuel les plus courants, consultez Exigences relatives aux ports homologues de géoréplication.

Contenu associé

Ces articles fournissent des informations supplémentaires sur la connectivité et la résilience :