Installation de Bitnami Redis

Remarques sur l'installation :

Topologie

Redis peut être installé avec différentes topologies, y compris autonome, maître/subordonné, sentinelle ou cluster. La plupart des fournisseurs cloud offrent également des versions gérées de Redis qui masquent certaines des complexités de haute disponibilité et de réplication. Voici des configurations recommandées à l'aide des graphiques Bitnami :

1. standalone : Un seul maître sans réplique peut fonctionner correctement dans de nombreux scénarios. Etant donné que HCL Cache est une structure à plusieurs niveaux, le contenu le plus fréquemment consulté est servi à partir de caches locaux, réduisant ainsi la charge sur Redis et ses exigences de capacité. (La quantité de mise en cache et les taux d'accès affecteront la charge sur chaque site). HCL Cache est également conçu avec des fonctions à haute disponibilité et implémente des circuit breakers qui bloquent l'accès Redis jusqu'au rétablissement du serveur. Pendant ce temps, les caches locaux restent disponibles. Kubernetes détectera les conditions de blocage ou d'incident et réappliquera rapidement le conteneur maître en fonction des sondes définies dans le déploiement Redis.
   Note: Si des répliques/subordonnés ont été définis (sans Sentinel), les répliques sont destinées à un accès en lecture seule et ne sont pas promues en tant que maître. Le système doit encore attendre que le maître soit à nouveau généré. Pour plus de détails, voir topologies.
2. cluster : La mise en cluster peut être utilisée pour mettre Redis à l'échelle. Bien que chaque HCL Cache ne puisse exister que sur un seul nœud (chaque cache est lié à un emplacement unique), HCL Commerce définit plusieurs caches (50 ou plus) qui peuvent être distribués sur les nœuds de cluster Redis. Avec la migration des emplacements, il est possible de sélectionner les caches qui atterrissent sur chaque serveur. Un cluster Redis requiert au moins trois serveurs maîtres. Si des répliques sont utilisées, six conteneurs doivent être déployés. Pour plus de détails, voir le tutoriel Redis Cluster.

Persistance

Redis offre des options de persistance AOF (Append Only File) et RDB (Redis Database) 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 plus d'informations sur AOF et RDB, voir Persistance Redis.

Avec Redis autonome, l'utilisation de la persistance est facultative, mais avec le cluster Redis, elle est recommandée. L'utilisation de la persistance peut ajouter une petite surcharge aux opérations d'exécution. Il peut également y avoir un délai pendant le démarrage de Redis, car il charge le cache conservé dans la mémoire. Ce délai varie en fonction de la taille du fichier. Pour une utilisation avec HCL Cache, l'utilisation de RDB uniquement (et non AOF) peut être suffisante.

Lors de la configuration des volumes persistants Kubernetes pour Redis, sélectionnez une valeur storageClass avec stockage SSD rapide. Par défaut, Redis ne demande que 8 Go de stockage pour un volume persistant. Cela peut ne pas suffire, surtout si la persistance AOF est activée. Demandez une taille plus grande (par exemple, 30 Go) et surveillez l'utilisation pour mieux comprendre la quantité de stockage requise.

Graphiques Redis Bitnami

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Redis autonome

Utilisez ce graphique Redis pour installer Redis autonome, sans persistance. Consultez redis-standalone-values.yaml pour plus de détails.

helm install hcl-commerce-redis bitnami/redis -n redis -f redis-standalone-values.yaml

Note: Si Prometheus n'est pas configuré, désactivez la section des métriques avant l'installation. Pour plus d'informations sur l'intégration de Prometheus et de Grafana, voir HCL Commerce Monitoring - Prometheus and Grafana Integration.

Cluster Redis

Ces étapes installent un cluster Redis avec trois maîtres. Consultez redis-cluster-values.yaml pour plus de détails.

helm install hcl-commerce-redis bitnami/redis-cluster -n redis -f redis-cluster-values.yaml

Note: Si Prometheus n'est pas configuré, désactivez la section des métriques avant l'installation. Pour plus d'informations sur l'intégration de Prometheus et de Grafana, voir HCL Commerce Monitoring - Prometheus and Grafana Integration.

Configurations et paramètres courants

Les configurations suivantes sont communes pour les graphiques autonomes et de cluster :

Configuration de Redis

La section suivante permet de personnaliser les configurations par défaut de Redis (voir redis.conf).

  configuration: |-
    appendonly no
    save ""
    maxmemory 10000mb
    maxmemory-policy volatile-lru

maxmemory

Détermine la taille de la mémoire disponible pour stocker les objets Redis. La quantité de cache varie d'un site à l'autre. 10 Go est une bonne configuration de départ. La limite de mémoire du pod doit être supérieure.

maxmemory-policy

L'utilisation de volatile-lru est requise pour le HCL Cache. Cela permet à Redis d'évincer les entrées de cache, mais pas les ID de dépendance. Les options appendonly et save sont destinées à la persistance, qui est désactivée dans l'exemple.

Cette section peut également être utilisée pour activer les paramètres de débogage, comme pour SLOWLOG :

slowlog-log-slower-than 10000
slowlog-max-len 512    
latency-monitor-threshold 100

Cluster Redis uniquement :

cluster-require-full-coverage : non :

Lorsque tous les emplacements ne sont pas couverts (par exemple en raison d'une panne principale), l'erreur CLUSTERDOWN est émise. La configuration de cluster-require-full-coverage pour no active le sous-ensemble de nœuds qui restent disponibles pour continuer à traiter les demandes.

Si vous prévoyez d'activer des répliques, voir Utilisation de répliques Redis pour des configurations supplémentaires.

Persistance

La persistance Kubernetes (PVC) doit être activée si la persistance Redis (AOF/RDB) est utilisée ou avec la mise en cluster Redis. Si la persistance Redis est utilisée, la PVC doit être suffisante pour accueillir les vidages de mémoire Redis. Avec le cluster Redis, le cluster conserve un fichier nodes.conf qui doit persister, car dans le cas contraire, les nœuds qui redémarrent ne peuvent pas rejoindre le cluster. Ce fichier requiert un stockage minimal.

Ressources

Redis est à unité d'exécution unique (pour la plupart), il est donc plus avantageux d'avoir des processeurs plus rapides, plutôt que plusieurs processeurs. Deux UC peuvent fonctionner correctement dans de nombreux scénarios. Il est important de surveiller pour Kubernetes la régulation des ressources de l'UC et de s'assurer qu'elle ne se produit pas, car la régulation peut bloquer l'unité d'exécution principale de Redis. La mémoire affectée doit être supérieure à la mémoire allouée pour la mémoire cache de Redis (voir ci-dessus).

 resources:
    limits:
      cpu: 2000m
      memory: 12Gi
    requests:
      cpu: 2000m
      memory: 12Gi

Valeurs

Si Prometheus est configuré, vous pouvez activer les métriques et serviceMonitors (requiert Kube-prometheus-stack). Les métriques Redis peuvent être utilisées avec le tableau de bord Redis Grafana. Le tableau de bord HCL Cache - Distant affiche également les métriques Redis.

metrics:
  enabled: true
  serviceMonitor:
    enabled: true
    namespace: redis

Configurations de système d'exploitation supplémentaires (sysctl)