Serveurs Redis pour HCL Cache

Configuration requise liée au serveur Redis pour HCL Commerce

Bien que l'utilisation d'un cache distant dans Redis soit fortement recommandée, elle n'est pas requise dans toutes les configurations.

Elasticsearch : Redis est requis. Les serveurs Redis doivent être partagés par environnement de création et de production. Cette opération est requise, car NiFi doit interagir avec les environnements de création et de production.
Recherche Solr : Redis est recommandé, mais pas obligatoire. Les environnements migrés qui n'implémentent pas Redis doivent continuer à utiliser Kafka pour répliquer les invalidations. Redis remplace Kafka pour les invalidations et peut également agir en tant que cache distant. L'environnement de création et de production peut être configuré avec des serveurs Redis distincts. Cette opération est recommandée pour les environnements de production.

Sélection d'une topologie Redis

Redis peut être installé dans diverses configurations. La sélection dépend de vos performances et de vos exigences de haute disponibilité. Les alternatives possibles sont les suivantes :

Utilisation des graphiques Bitnami pour installer Redis dans le cluster Kubernetes
Redis Enterprise par RedisLabs
Redis en tant que service à partir d'un fournisseur cloud

Configurations autonomes et de cluster

Redis autonome (instance unique) fonctionnera de manière appropriée pour la préproduction et de nombreux environnements de production. Les environnements plus volumineux peuvent bénéficier d'un serveur Redis en cluster, qui permet plusieurs maîtres et répliques.

Un cluster Redis est configuré avec plusieurs maîtres (3+). Les caches et les fragments seront distribués sur les serveurs maîtres. Chaque maître peut être configuré avec zéro réplique ou plus. Les répliques peuvent favoriser l'évolutivité en gérant le trafic de lecture (opérations GET) et peuvent prendre le relais en cas d'indisponibilité du maître.

Configurations requises

Utilisez les configurations suivantes dans le serveur Redis. Pour plus de détails, voir expulsion de clé.

maxmemory: Indique la quantité de mémoire disponible pour stocker les données en cache et doit être définie sur une valeur différente de zéro.
maxmemory-policy: Doit être défini sur volatile-lru

Configurations d'optimisation de clé

Outre la topologie, prenez en compte les configurations de réglage de clé suivantes. La plupart s'appliquent à Redis installé localement, mais peut également être pertinent pour Redis en tant que service.

Pour valider ou comparer les performances du serveur Redis, vous pouvez utiliser l'utilitaire de référence Redis et l'utilitaire hcl-cache-benchmark de HCL Cache.

Utiliser des UC rapides et un stockage rapide: Redis est principalement à unité d'exécution unique, au moins à partir du point de vue d'exécution de la commande. Il bénéficie de processeurs rapides avec un taux de fréquence élevé. Si la persistance est activée, les conteneurs bénéficieront également d'un stockage rapide. Utilisez une classe de stockage premium qui est soutenue par des SSD.

Valider les limites Kubernetes

Vérifiez que les limites définies sur les pods Redis sont définies de manière appropriée :

Stockage: Si la persistance est utilisée, les volumes persistants doivent être dimensionnés en conséquence. Par exemple, les graphiques Bitnami définissent une limite de 8 Go par défaut. Cela peut ne pas être suffisant pour les environnements de production et peut entraîner un plantage.
UC: La régulation de l'UC peut geler le serveur Redis. Kubernetes est très agressif avec la régulation de l'UC. Pour l'éviter, définissez une limite élevée ou supprimez la limite de l'UC pour les pods Redis.
Mémoire: La mémoire requise par le conteneur Redis est une fonction de la configuration maxmemory. maxmemory doit être inférieur à 70 % de la limite du conteneur.

Persistance Redis: Redis inclut des options de persistance (AOF/RDB) qui enregistrent le contenu de la mémoire sur le disque. Cela permet à Redis de récupérer le contenu de la mémoire (cache) en cas de panne. Pour l'utilisation avec HCL Cache, l'activation de la persistance RDB et la désactivation d'AOF doivent être suffisantes.
La persistance est requise lorsque des répliques sont utilisées. Sinon, elle est facultative et Redis ne requiert pas de volume de persistance. Sans persistance, dans le cas peu probable où Redis tombe en panne ou ne répond plus, Kubernetes devrait pouvoir redémarrer le service presque instantanément, mais avec un cache vide.
Si le site Commerce n'est pas réglé pour absorber un cache clear pendant la période de trafic de pointe, la persistance est recommandée. Lorsque la persistance est activée, le démarrage est retardé d'un certain nombre de secondes tandis que Redis recharge le cache mémoire à partir du disque. Il est également possible que si le nœud Kubernetes tombe en panne, une intervention manuelle peut être nécessaire pour libérer le volume de persistance du nœud problématique et pour permettre à Kubernetes de replanifier le pod (en raison du mode ReadWriteOnce-RWO ).
Note: Exclusion de responsabilité : Redis est une marque déposée de Redis Labs Ltd. Tous les droits qu'il contient sont réservés à Redis Labs Ltd. Toute utilisation par HCL est à des fins référentielles uniquement et n'indique pas un parrainage, une approbation ou une affiliation entre Redis Labs Ltd.