Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
Azure Cache pour Redis a annoncé sa chronologie de mise hors service pour toutes les références SKU. Nous vous recommandons de déplacer vos instances Azure Cache pour Redis existantes vers Azure Managed Redis dès que vous le pouvez.
Pour plus d’informations sur la mise hors service :
Cet article explique comment résoudre les problèmes courants liés à la connexion de votre application cliente à Azure Cache pour Redis. Les problèmes de connectivité peuvent être causés par des conditions intermittentes ou par une configuration incorrecte du cache. Cet article est divisé en problèmes intermittents et problèmes de configuration du cache.
Problèmes de connectivité intermittente
- Applications hébergées par Kubernetes
- Application cliente basée sur Linux
- Nombre de clients connectés
- Maintenance du serveur
Problèmes de connectivité de configuration du cache
- Règles de pare-feu
- Configuration du point de terminaison privé
- Modification de l’adresse IP publique
- Configuration du réseau virtuel
Tester la connectivité
Vous pouvez tester la connectivité à l’aide de l’outil en ligne de commande Redis-cli. Pour plus d’informations sur l’interface CLI Redis, consultez l’outil en ligne de commande Redis avec Azure Cache pour Redis.
Si redis-cli n’est pas en mesure de se connecter, vous pouvez tester la connectivité à l’aide PSPING d’Azure PowerShell.
psping -q <cachename>:<port>
Si le nombre de paquets envoyés est égal au nombre de paquets reçus, il n’existe aucune baisse de connectivité.
Problèmes de connectivité intermittente
Votre application cliente peut avoir des problèmes de connectivité intermittents provoqués par des pics dans le nombre de connexions ou par des événements tels que la mise à jour corrective.
Applications hébergées par Kubernetes
Si votre application cliente est hébergée sur Kubernetes, vérifiez si les nœuds de cluster ou le pod exécutant l’application cliente sont sous mémoire, processeur ou pression réseau. Un pod exécutant l’application cliente peut être affecté par d’autres pods s’exécutant sur le même nœud et peut limiter les connexions Redis ou les opérations d’E/S.
Si vous utilisez Istio ou tout autre maillage de service, assurez-vous que votre proxy de maillage de service réserve des ports 13000-13019 ou 15000-15019. Les clients utilisent ces ports pour communiquer avec des nœuds dans un cache Redis Azure cluster et peuvent provoquer des problèmes de connectivité 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. Pour plus d’informations, consultez les paramètres TCP pour les applications clientes hébergées sur Linux et les blocages de connexion pendant 15 minutes.
Nombre de clients connectés
Vérifiez si l’agrégat Max pour la métrique Clients connectés est proche ou supérieur au nombre maximal de connexions autorisées pour votre taille de cache. Pour plus d’informations sur le dimensionnement par connexion cliente, consultez les performances du Cache Azure pour Redis.
Maintenance du serveur
Votre cache peut subir une maintenance planifiée ou non planifiée du serveur qui affecte négativement votre application pendant la fenêtre de maintenance. Vous pouvez vérifier ce problème en consultant la métrique Erreurs (Type : Basculement) sur votre cache dans le portail Azure. Pour minimiser les effets des basculements, consultez Résilience des connexions.
Problèmes de configuration de la connectivité
Si votre application ne peut pas se connecter à votre cache Redis Azure du tout, une configuration de cache peut ne pas être configurée correctement. Les sections suivantes présentent des suggestions sur la façon de vérifier que votre cache est correctement configuré.
Règles de pare-feu
Si vous avez configuré un pare-feu pour votre cache Redis Azure, vérifiez que votre adresse IP cliente est ajoutée aux règles de pare-feu. Pour vérifier les règles de pare-feu, sélectionnez Pare-feu sous Paramètres dans le menu de navigation de gauche de votre page de cache.
Pare-feu ou proxy externe tiers
Si vous utilisez un pare-feu ou un proxy tiers dans votre réseau, assurez-vous qu’il autorise le point de terminaison *.redis.cache.windows.net Azure Cache pour Redis et les ports 6379 et 6380. Vous devrez peut-être autoriser davantage de ports lorsque vous utilisez un cache en cluster ou une géoréplication.
Configuration de point de terminaison privé
Dans le portail Azure, vérifiez la configuration de votre point de terminaison privé en sélectionnant Point de terminaison privé sous Paramètres dans le menu de navigation de gauche de votre cache.
Dans la page Point de terminaison privé , vérifiez que l’activation de l’accès au réseau public est correctement définie.
- L’accès au réseau public est désactivé par défaut lorsque vous créez un point de terminaison privé.
- Pour vous connecter à votre point de terminaison privé de cache à partir de l’extérieur de votre réseau virtuel de cache, vous devez activer l’accès au réseau public.
- Si vous supprimez votre point de terminaison privé, veillez à activer l’accès au réseau public.
Sélectionnez le lien sous Point de terminaison privé et vérifiez que votre point de terminaison privé est configuré correctement. Pour plus d’informations, consultez Créer un point de terminaison privé avec une nouvelle instance Azure Cache pour Redis.
Assurez-vous que votre application se connecte à
<cachename>.redis.cache.windows.netsur le port6380. Évitez d’utiliser<cachename>.privatelink.redis.cache.windows.netdans la configuration ou la chaîne de connexion.Pour vérifier qu’une 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é.
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 le nom d’hôte et non l’adresse IP publique.
Configuration du réseau virtuel
Vérifiez la configuration de votre réseau virtuel comme suit :
- Vérifiez qu’un réseau virtuel est affecté à votre cache. Dans le portail Azure, sélectionnez Réseau virtuel sous Paramètres dans le menu de navigation de gauche de votre cache.
- Vérifiez que la machine hôte cliente se trouve dans le même réseau virtuel que le cache.
- Si l’application cliente se trouve dans un réseau virtuel différent du cache, activez le peering pour les deux réseaux virtuels dans la même région Azure.
- Vérifiez que les règles entrantes et sortantes répondent aux exigences du port.
Pour plus d’informations, consultez Configurer la prise en charge du réseau virtuel pour une instance Azure Cache Premium pour Redis.
Géoréplication à l'aide de l'injection de réseau virtuel avec des caches Premium
La géoréplication entre les caches du même réseau virtuel est prise en charge. La géoréplication entre les caches de différents réseaux virtuels est prise en charge avec les avertissements suivants :
Si les réseaux virtuels se trouvent dans la même région, vous pouvez les connecter en utilisant l’appairage 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 dans
VNet 1(région 1) ne peut pas accéder à un cache dansVNet 2(région 2) à l’aide de son nom, en raison d’une contrainte avec des équilibreurs de charge internes de base. Utilisez à la place une connexion de passerelle VPN de réseau virtuel à réseau virtuel. Pour plus d’informations sur les contraintes de peering de réseaux virtuels, consultez exigences et contraintes de peering de 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 façon d’éviter les problèmes courants de mauvaise configuration des réseaux virtuels, consultez les exigences pour les ports homologues de géoréplication.
Bien qu’il soit possible d’utiliser l’injection de réseau virtuel avec des caches Premium, il est préférable d’utiliser Azure Private Link. Pour plus d'informations, consultez les pages suivantes :
-
Migrer des
VNetcaches d’injection vers des caches Private Link - Qu’est-ce qu’Azure Cache pour Redis avec Azure Private Link ?