Échec de la sonde Redis

Solutions pour les échecs d'enquête Redis Enterprise, y compris les limites de partition dans Automation Suite sous Linux.

Description

Les échecs de sonde Redis peuvent se produire dans les scénarios suivants.

Fichier d'ID de nœud Redis manquant

La sonde Redis peut échouer si le fichier d'ID de nœud n'existe pas. Cela peut se produire si le pod n'est pas encore amorcé.

Il existe une tâche de récupération qui résout automatiquement ce problème, et les étapes suivantes ne doivent pas être effectuées pendant l'exécution de la tâche.

Lorsqu'un cluster Redis Enterprise perd le contact avec plus de la moitié de ses nœuds (soit en raison de nœuds défaillants, soit en raison d'une division du réseau), le cluster cesse de répondre aux connexions client. Les pods ne parviennent pas non plus à rejoindre le cluster.

Limite de partition Redis Enterprise dépassée

Redis Enterprise peut créer plusieurs partitions qui dépassent le quota de licences. Cela provoque des effets de Remarque lorsque service-rigger ne parvient pas à créer le service Kubernetes requis pour redis-cluster-db, ce qui entraîne des défaillances pour tous les services dépendants de Redis.

Solution

1. Désactivez la synchronisation d'Argo, supprimez la base de données Redis et la ressource de cluster Redis, réactivez la synchronisation d'Argo et démarrez une tâche de récupération, à l'aide des commandes suivantes :

   kubectl -n argocd patch application redis-cluster --type=json -p '[{"op":"replace","path":"/spec/syncPolicy/automated/selfHeal","value":false}]'
   kubectl -n argocd patch application redis-operator --type=json -p '[{"op":"replace","path":"/spec/syncPolicy/automated/selfHeal","value":false}]'
   kubectl delete redb -n redis-system redis-cluster-db --force --grace-period=0 &
   kubectl delete rec -n redis-system redis-cluster --force --grace-period=0 &
   kubectl patch redb -n redis-system redis-cluster-db --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"finalizer.redisenterprisedatabases.app.redislabs.com"}]'
   kubectl patch rec redis-cluster -n redis-system --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"redbfinalizer.redisenterpriseclusters.app.redislabs.com"}]'
   kubectl -n redis-system get pods | grep services-rigger | awk '{print $1}' | xargs kubectl -n redis-system delete pod --force
   kubectl -n redis-system get pods | grep -E "redis-cluster-[0-2]" | awk '{print $1}' | xargs kubectl -n redis-system delete pod --force
   kubectl -n argocd patch application redis-cluster --type=json -p '[{"op":"replace","path":"/spec/syncPolicy/automated/selfHeal","value":true}]'
   kubectl -n argocd patch application redis-operator --type=json -p '[{"op":"replace","path":"/spec/syncPolicy/automated/selfHeal","value":true}]'
   kubectl -n redis-system create job --from=cronjob/redis-cluster-recovery-job cronjob-manual-run
   

2. Si l'erreur persiste, vérifiez s'il existe une distorsion d'horloge entre les nœuds Kubernetes. Si un nœud est même en avance ou en retard de quelques secondes, le pod Redis ne pourra pas s'exécuter dessus. Pour résoudre ce problème, vous devez vous assurer que l'horloge de tous les nœuds est synchronisée.