Utilisation de répliques Redis

Bien que d'autres topologies prennent en charge l'utilisation de répliques, ce document est écrit en tenant compte des clusters.

Scénario de basculement

Lorsque le cluster Redis détecte qu'un nœud maître est arrêté, il lance le basculement vers l'une des répliques du maître. Les répliques utilisent le processus de réplication pour mettre en miroir les mises à jour à partir du nœud maître au fur et à mesure qu'elles se produisent.

Dans Kubernetes, lorsque le pod précédemment défaillant se rétablit et rejoint à nouveau le cluster, il bascule vers un rôle de réplique du maître qui sert actuellement les emplacements (qui était autrefois sa réplique).

Si les répliques ne sont pas utilisées, Kubernetes détectera toujours (à l'aide d'analyses) et redémarrera les pods qui ne répondent pas. Les emplacements desservis par le maître affecté seront temporairement indisponibles. Selon la durée de la panne, HCL Cacheles circuit breakers s'activeront. La nouvelle disponibilité du nœud Redis peut prendre quelques minutes. Cette durée est prolongée lorsque la persistance est utilisée, car Redis doit recharger le cache au démarrage et le service n'est pas disponible tant que le chargement du cache n'est pas terminé.

Scénarios d'évolutivité

Outre leur rôle de basculement, les répliques peuvent augmenter l'évolutivité en gérant des opérations GET/de lecture. Cela libère des ressources sur le nœud maître et permet une utilisation plus efficace des ressources. Le client Redis HCL Cache peut être configuré pour diriger les opérations de lecture vers des répliques à l'aide de la configuration readMode.

Lorsque des répliques sont utilisées pour des opérations de lecture, la considération suivante doit être prise en compte :

• Le processus de réplication introduit un délai. Si une opération de lecture se produit immédiatement après une écriture, la lecture peut renvoyer des données périmées ou aucune donnée. Cela peut introduire des problèmes fonctionnels pour certains caches et scénarios de personnalisations. Le HCL Cache inclut un certain nombre de configurations qui déterminent si les lectures sont dirigées vers des maîtres ou des répliques et des temps d'attente pour que les réplications se terminent.
• Si des répliques sont utilisées pour les lectures, les serveurs maître et de réplique doivent être disponibles pour des performances optimales : Une réplique indisponible peut entraîner des délais d'attente des commandes WAIT pendant les opérations PUT (syncReplicas, voir ci-dessous) et des opérations de lecture échouées (GET) exécutées sur les répliques. Lorsque le maître récupéré est redémarré, il reconfigure lui-même une réplique et lance un nouveau processus de synchronisation. Si une synchronisation complète est requise, le serveur de réplique peut être indisponible pendant un certain temps pendant la réplication de la base de données. La récupération du système peut prendre plus de temps lorsque les opérations de lecture sont déchargées sur des répliques.

Configurations

Les répliques et le HCL Cache peuvent nécessiter des modifications de configuration dans Redis, le client Redis ou le HCL Cache :

Configuration de Redis

• cluster-replica-validity-factor : xxxxxxx
• repl-diskless-sync
• client-output-buffer-limit

Configuration de client Redis

Le HCL Cache peut être configuré pour émettre des opérations de lecture (GET) pour répliquer des serveurs avec le paramètre readMode.

Configurations d'HCL Cache

Le HCL Cache inclut un certain nombre de configurations avancées au niveau du cache pour contrôler le comportement des opérations PUT lorsque des répliques sont utilisées. Ces paramètres sont plus pertinents lorsque readMode : SLAVE est utilisé.

cacheConfigs:
  cacheName:
    remoteConfig:
       forceReadFromMaster: [TRUE|false]
       syncReplicas: [NULL| <number_of_replicas> OR all : timeout_ms]
       limitSyncReplicasToNumberAvailable: [TRUE|false]

forceReadFromMaster

Lorsque readMode est défini sur SLAVE ou MASTER_SLAVE, la configuration forceReadFromMaster garantit que les écritures (PUT) de ce cache sont envoyées au serveur maître.

syncReplicas

La configuration est désactivée par défaut. Si cette option est activée, le HCL Cache appelle la commande WAIT après une opération PUT. La commande WAIT introduit un délai jusqu'à ce que le nombre configuré de répliques ait traité la modification ou que le délai d'attente soit atteint. Au lieu de spécification d'un nombre fixe de répliques, il est possible d'utiliser all, ce qui se traduit par le nombre de répliques actuellement connues par le client Redis. Exemple : Avec la configuration suivante, le HCL Cache attendra que la modification soit répliquée sur toutes les répliques disponibles et attendra jusqu'à 250 millisecondes :

  syncReplicas: all:250

limitSyncReplicasToNumberAvailable

Lorsque syncReplicas est activé avec un certain nombre de répliques, la configuration limitSyncReplicasToNumberAvailable peut être utilisée pour limiter le nombre configuré au nombre de répliques actuellement connues par le client Redis.