Résoudre des problèmes

Cette page décrit différents scénarios d'erreur et fournit des conseils pour les résoudre.

Scénarios de réplication

Cette section explique les problèmes de réplication qui peuvent survenir avec votre cluster.

Comment surveillez-vous les délais avant réplication ?

Memorystore for Redis Cluster inclut la métrique /cluster/replication/maximum_offset_diff. Cette métrique surveille la différence maximale de décalage de réplication (en octets) pour un nœud d'un cluster principal.

En maintenant une faible différence de décalage de réplication, les réplicas peuvent effectuer des opérations de synchronisation incrémentielle plus fréquemment et à un coût inférieur à celui des opérations de synchronisation complète.

Nous vous recommandons de définir un seuil pour la métrique maximum_offset_diff. Si le seuil est dépassé, Memorystore pour Redis Cluster peut vous en informer par le biais d'une alerte.

En fonction du type de nœud de votre cluster, nous vous recommandons de définir le seuil comme suit :

  • Si le type de nœud est redis-shared-core-nano, redis-standard-small, redis-highmem-medium, redis-highcpu-medium ou redis-standard-large, définissez le seuil sur une valeur inférieure à 64 Mo.

  • Si le type de nœud est redis-highmem-xlarge ou redis-highmem-2xlarge, définissez le seuil sur une valeur inférieure à 1 Go.

Scénarios d'erreur de connectivité

Cette section explique les problèmes de connectivité que votre cluster peut rencontrer.

Erreur de connexion provoquée par des règles de pare-feu

Si vous n'autorisez pas les ports appropriés sur votre pare-feu, votre cluster peut rencontrer des erreurs de connexion, car le pare-feu peut bloquer les ports utilisés par Memorystore pour Redis Cluster.

Pour tous les points de terminaison Private Service Connect de votre cluster, vous devez autoriser le port TCP 6379, ainsi que les ports TCP 11000 à 13047. Pour en savoir plus sur ces points de terminaison, consultez Adresses réseau réservées.

Erreur de connexion causée par des règles d'administration

Il est possible qu'une règle d'administration bloque vos connexions Private Service Connect à votre cluster.

Si votre règle d'administration utilise la règle .restrictPrivateServiceConnectProducer, autorisez le dossier 961333125034, qui est un dossier spécifiquement destiné à Memorystore for Redis Cluster. Exemple :

name: organizations/Consumer-org-1/policies/compute.restrictPrivateServiceConnectProducer
spec:
    rules:
      - values:
          allowedValues:
          - under:folders/961333125034

Si votre règle d'administration utilise la règle .disablePrivateServiceConnectCreationForConsumers, autorisez SERVICE_PRODUCERS. Exemple :

name: organizations/Consumer-org-1/policies/compute.disablePrivateServiceConnectCreationForConsumers
spec:
    rules:
      - values:
          allowedValues:
          - SERVICE_PRODUCERS

Erreur de connexion provoquée par des connexions non réactives

Nous vous recommandons vivement de configurer votre application cliente pour qu'elle détecte les connexions non réactives à Memorystore pour Redis Cluster. Lorsqu'une connexion qui ne répond pas est détectée, le client doit la réinitialiser. Pour créer une application résiliente, nous vous recommandons les configurations client suivantes :

  • Configurez les paramètres de message keep-alive TCP : définissez les paramètres TCP keepalive time, TCP keepalive interval et TCP keepalive probes afin que les clients détectent et abandonnent de manière proactive les connexions qui ne répondent pas, même lorsqu'elles sont inactives. Par exemple, si vous définissez le paramètre TCP keepalive time sur 30 secondes, TCP keepalive interval sur 10 secondes et TCP keepalive probes sur 3, les clients réinitialisent les connexions inactives non réactives en une minute.
  • Configurer les délais d'expiration des utilisateurs TCP : définissez ce délai d'expiration dans vos clients pour réinitialiser les connexions qui ont des requêtes en attente et qui ne répondent plus. Par exemple, si vous définissez le délai avant expiration sur 15 secondes, les clients réinitialisent les connexions non réactives qui ont des requêtes en attente au bout de 15 secondes.

Scénarios d'utilisation du processeur

Cette section explique les problèmes d'utilisation du processeur que votre cluster peut rencontrer.

Le tampon de sortie de votre cluster manque d'espace

Si le tampon de sortie de votre cluster manque d'espace, procédez comme suit :

  • Définissez une valeur plus petite pour le paramètre maxmemory.
  • Utilisez la règle maxmemory allkeys-lru.

Si la mémoire de votre cluster est saturée et qu'une nouvelle écriture arrive, Memorystore for Redis Cluster supprime les clés afin de libérer de l'espace pour l'écriture, en fonction de la règle maxmemory de votre cluster. La règle allkeys-lru supprime les clés les moins récemment utilisées (LRU, least recently used) de la collection de clés.

Nous vous recommandons de surveiller la maxmemory et la mémoire utilisée de votre cluster. Cela vous permet de savoir si votre cluster atteint la capacité de cluster provisionnée. De plus, en réduisant la valeur du paramètre maxmemory, vous obtenez plus d'espace pour les frais généraux.

Pourquoi des métriques externes peuvent-elles manquer pour votre cluster ?

Si votre cluster connaît une utilisation élevée du processeur ou si ses ressources sont épuisées (par exemple, en raison d'un nombre trop important de connexions), il peut se comporter de manière anormale et des métriques externes peuvent manquer.

Isoler la source de la latence de votre cluster

Pour déterminer si la latence que vous rencontrez provient de votre cluster, de votre application cliente ou de votre environnement réseau, utilisez l'outil redis-cli pour exécuter un test de latence continu.

Pour isoler la source de la latence de votre cluster, procédez comme suit :

  1. Connectez-vous à une VM Compute Engine située dans la même région et le même réseau VPC que votre cluster.

  2. Si l'outil redis-cli n'est pas encore installé, installez-le sur votre VM.

    • Pour les VM basées sur Debian ou Ubuntu, exécutez la commande suivante :

      sudo apt-get install redis-tools

    • Pour les VM basées sur RHEL ou CentOS, exécutez la commande suivante :

      sudo yum install redis

  3. Pour mesurer la latence du cluster en millisecondes, exécutez la commande suivante :

    redis-cli --latency -h DISCOVERY_ENDPOINT_ADDRESS -p PORT

    Si votre cluster utilise le chiffrement en transit, ajoutez le flag --tls et spécifiez vos autorités de certification (CA) pour vous connecter.

    Effectuez les remplacements suivants :

    • DISCOVERY_ENDPOINT_ADDRESS : adresse IP du point de terminaison de découverte de votre cluster.
    • PORT : numéro de port réservé au point de terminaison de découverte de votre cluster. Ce numéro de port est généralement 6379.

  4. Laissez la commande s'exécuter pendant quelques minutes. L'outil envoie des requêtes ping au serveur en continu et calcule les valeurs de latence minimale, maximale et moyenne.

  5. Pour arrêter la commande et afficher les résultats, appuyez sur Ctrl+C.

Si la commande génère une latence moyenne constamment faible (généralement une milliseconde ou moins), cela signifie que le cluster est sain et répond rapidement.

Si la commande affiche une latence constamment faible, mais que votre application cliente rencontre toujours des retards, les problèmes suivants peuvent être à l'origine de la latence :

  • Réseau : le trafic acheminé entre votre client et le cluster dans différentes régions ou zones peut entraîner des latences réseau importantes.
  • Client : une utilisation intensive du processeur ou de la mémoire sur le client, des pools de connexions épuisés ou des goulots d'étranglement de la logique d'application peuvent augmenter le délai aller-retour total que le client rencontre.

Scénarios de persistance

Cette section explique les problèmes de persistance qui peuvent survenir avec votre cluster.

Votre trafic d'écriture dépasse la capacité de Memorystore pour Redis Cluster à compacter et à récupérer de l'espace grâce à la réécriture AOF.

Dans ce cas, le fichier AOF (Append-Only File) croît plus rapidement que le processus de réécriture ne peut le gérer. Cela entraîne l'épuisement de l'espace disque, des échecs d'écriture et le blocage des opérations nécessitant la création d'un réplica et une synchronisation complète.

Memorystore for Redis Cluster a mis en place des mesures de protection pour réguler le débit d'écriture. Cela garantit que la réécriture AOF peut suivre le rythme des charges de travail à écriture élevée soutenue.