Bitnami Redis installation

Installation considerations:

Topology

Redis can be installed with different topologies, including standalone, master/subordinate, sentinel or cluster. Most cloud providers also offer managed versions of Redis that hide some of the high-availability and replication complexities. The following are recommended configurations using the Bitnami charts:

1. standalone: A single master with no replicas can work well in many scenarios. Because HCL Cache is a multi-tiered framework, the most frequently-accessed content is served from local caches, reducing the load on Redis and therefore decreasing its capacity requirements. (The amount of caching and hit ratios will affect the load on each site). HCL Cache is also designed with high availability features, and implements circuit breakers that block Redis access until the server recovers. During that time, the local caches remain available. Kubernetes will detect hang or crash conditions and rapidly re-spawn the master container based on the probes defined in the Redis deployment.
   Note: If replicas/ subordinates were defined (without Sentinel), the replicas are for ready-only access and are not promoted to master. The system still needs to wait for the master to be re-spawned. See topologies for more details.
2. cluster: Clustering can be used to scale Redis. Although each HCL Cache can only exist on a single node (each cache is tied to a single slot), HCL Commerce defines multiple caches (50 or greater) that can be distributed across the Redis cluster nodes. With slot migration, it is possible to select what caches land on each server. A Redis cluster requires a minimum of three master servers. If replicas are used, six containers need to be deployed. See the Redis Cluster tutorial for more details.

Persistence

Redis offers persistence AOF (Append Only File) and RDB (Redis Database) options that save the memory contents to disk. This allows Redis to recover the memory contents (cache) in case of a crash. For more information on AOF and RDB, see Redis Persistence.

With standalone Redis, the use of persistence is optional but with Redis cluster it is recommended. The use of persistence can add a small overhead to runtime operations. There can also be a delay during Redis startup as it loads the persisted cache into memory. This delay varies depending on the size of the file. For use with HCL Cache, use of RDB only (not AOF) can be sufficient.

When configuring Kubernetes persistent volumes for Redis, select a storageClass with fast SSD storage. By default, Redis requests only 8 GB of storage for a persistant volume. That may not be enough, especially if AOF persistence is enabled. Request a larger size (For example, 30 GB) and monitor usage to get a better understanding for how much storage is required.

Redis Bitnami Charts

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

Redis Standalone

Use this Redis chart to install Redis standalone, with no persistence. Review redis-standalone-values.yaml for details.

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

Note: If Prometheus is not set up, disable the metrics section prior to install. For more infromation on Promethus and Grafana integration, see HCL Commerce Monitoring - Prometheus and Grafana Integration

Redis Cluster

These steps install a Redis Cluster with three masters. Review redis-cluster-values.yaml For details.

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

Note: If Prometheus is not set up, disable the metrics section prior to install. For more infromation on Promethus and Grafana integration, see HCL Commerce Monitoring - Prometheus and Grafana Integration

Common configurations and settings

The following configurations are common for the standalone and cluster charts:

Redis configurations

The following section is to customize Redis default configurations (see redis.conf).

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

maxmemory

Determines the size of the memory available to store Redis objects. The amount of cache will vary from site to site. 10 GB is a good starting configuration. The pod memory limit must be higher.

maxmemory-policy

Using volatile-lru is required for the HCL Cache. This allows Redis to evict cache entries but not dependency IDs. The options appendonly and save are for persistence, which is disabled in the sample.

This section can also be used to enable debug settings, such as for SLOWLOG:

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

Redis Cluster only:

cluster-require-full-coverage: no:

When not all of the slots are covered (e.g. due to master down), the CLUSTERDOWN error is issued. Configuring cluster-require-full-coverage to no enables the subset of nodes that remain available to continue to serve requests.

If you plan to enable replicas, see Use of Redis Replicas for additional configurations.

Persistence

Kubernetes persistence (PVC) must be enabled if Redis persistence (AOF/RDB) is used, or with Redis clustering. If Redis persistence is used, the PVC must be large enough to accommodate the Redis memory dumps. With Redis Cluster, the cluster maintains a nodes.conf file that must persist, as otherwise nodes that restart are unable to re-join the cluster. This file requires minimal storage.

Resources

Redis is single-threaded (for the most part), so it benefits more from having faster processors, as opposed to having multiple processors. Two CPUs can work well in many scenarios. It's important to monitor for Kubernetes CPU resource throttling and ensure that is not happening, as throttling can hang the Redis main thread. The memory assigned should be larger than the memory allocated for the Redis cache memory (see above).

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

Metrics

If Prometheus is set up, you can enable metrics and serviceMonitors (requires Kube-prometheus-stack). Redis metrics can be consumed with the Redis Grafana dashboard. The HCL Cache - Remote dashboard also displays Redis metrics.

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

Additional operating system configurations (sysctl)