Résoudre des problèmes

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

Scénarios de réplication

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

Comment surveiller les délais de réplication ?

Memorystore for Redis Cluster dispose de 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 dans un cluster principal.

En maintenant une faible différence de décalage de réplication, les instances répliquées peuvent effectuer des opérations de synchronisation incrémentielle plus fréquemment et à moindre coût que les 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 for Redis Cluster peut vous envoyer 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 décrit les problèmes de connectivité que votre cluster peut rencontrer.

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

Les règles de pare-feu peuvent entraîner des erreurs de connexion en bloquant les ports utilisés par Memorystore for Redis Cluster. Pour les deux points de terminaison Private Service Connect de votre cluster, autorisez 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 causée par des connexions qui ne répondent pas

Nous vous recommandons vivement de configurer votre application cliente pour détecter les connexions qui ne répondent pas à Memorystore for 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 :

  • Configurer 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 qui ne répondent pas en une minute.
  • Configurer les délais d'attente utilisateur TCP : définissez ce délai d'attente 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 d'attente sur 15 secondes, les clients réinitialisent les connexions qui ne répondent pas et qui ont des requêtes en attente après 15 secondes.

Scénarios d'utilisation du processeur

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

L'espace du tampon de sortie de votre cluster est insuffisant

Si l'espace du tampon de sortie de votre cluster est insuffisant, procédez comme suit :

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

Lorsque la mémoire de votre cluster est saturée et qu'une nouvelle écriture arrive, Memorystore for Redis Cluster supprime les clés conformément à la règle maxmemory de votre cluster afin de libérer de l'espace pour l'écriture. 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 mémoire maxmemory et la mémoire utilisée de votre cluster. Cela vous permet de savoir si votre cluster atteint la capacité provisionnée. De plus, en réduisant la valeur du paramètre maxmemory, vous obtenez plus d'espace pour la surcharge.

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 trop grand nombre 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 ou de votre application cliente et de votre environnement réseau, vous pouvez utiliser 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. Facultatif : Installez l'outil redis-cli sur votre VM en exécutant la commande suivante :

    sudo apt-get install redis-tools

  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, vous devez ajouter l'indicateur --tls et spécifier 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. En règle générale, ce numéro de port est 6379.

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

  5. Facultatif : Pour arrêter l'exécution de la commande, appuyez sur Ctrl+C.

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

Si votre application cliente rencontre toujours des retards alors que la commande affiche des performances serveur typiques, 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 retards réseau importants.
  • Client : une utilisation élevée du processeur ou de la mémoire sur le client, des pools de connexions épuisés ou des goulots d'étranglement dans la logique de l'application peuvent augmenter le délai aller-retour total que le client rencontre.

Scénarios de persistance

Cette section décrit les problèmes de persistance qui peuvent survenir avec votre cluster.

Votre trafic d'écriture dépasse la capacité de Memorystore for Redis Cluster à compacter et à récupérer de l'espace via la réécriture AOF

Dans ce cas, le fichier AOF (Append-Only File) augmente plus rapidement que le processus de réécriture ne peut le gérer. Cela entraîne une saturation du disque, des échecs d'écriture et bloque les opérations qui nécessitent la création d'une instance répliquée et une synchronisation complète.

Memorystore for Redis Cluster a mis en place des garde-fous pour réguler le débit d'écriture. Cela garantit que la réécriture AOF peut suivre les charges de travail à écriture élevée soutenues.