Instalación de Bitnami Redis

Consideraciones relativas a la instalación:

Topología

Redis se puede instalar con diferentes topologías, incluyendo standalone, master/subordinate, sentinel o cluster. La mayoría de los proveedores de nube también ofrecen versiones gestionadas de Redis que ocultan algunas de las complejidades de alta disponibilidad y replicación. A continuación se indican las configuraciones recomendadas utilizando los gráficos Bitnami:

1. standalone: Un único maestro sin réplicas puede funcionar bien en muchos casos. Dado que HCL Cache es una infraestructura de varios niveles, el contenido al que se accede con más frecuencia se sirve desde memorias caché locales, reduciendo la carga en Redis y, por lo tanto, reduciendo sus requisitos de capacidad. (La cantidad de almacenamiento en memoria caché y proporción de aciertos afectará a la carga en cada sitio). HCL Cache también está diseñado con características de alta disponibilidad e implementa interruptores de circuito que bloquean el acceso a Redis hasta que el servidor se recupere. Durante ese tiempo, las memorias caché locales permanecerán disponibles. Kubernetes detectará condiciones de cuelgue o bloqueo y volverá a generar rápidamente el contenedor maestro basándose en las sondas definidas en el despliegue de Redis.
   Note: Si se han definido réplicas/subordinados (sin Sentinel), las réplicas son para acceso de solo preparado y no se promocionan a maestro. El sistema todavía tiene que esperar a que se vuelva a generar el maestro. Consulte topologías para obtener más detalles.
2. cluster: La agrupación en clúster se puede utilizar para escalar Redis. Aunque cada HCL Cache solo puede existir en un solo nodo (cada memoria caché está vinculada a una sola ranura), HCL Commerce define varias memorias caché (50 o posteriores) que se pueden distribuir entre los nodos de clúster de Redis. Con la migración de ranuras, es posible seleccionar qué cachés acabarán en cada servidor. Un clúster de Redis requiere un mínimo de tres servidores maestros. Si se utilizan réplicas, es necesario desplegar seis contenedores. Consulte la guía de aprendizaje del clúster de Redis para obtener más detalles.

Persistencia

Redis ofrece opciones de persistencia AOF (anexar solo archivo) y RDB (base de datos Redis) que guardan el contenido de la memoria en el disco. Esto permite a Redis recuperar el contenido de memoria (memoria caché) en caso de que se interrumpa. Para obtener más información acerca de AOF y RDB, consulte Redis Persistence.

Con Redis autónomo, el uso de la persistencia es opcional pero con el clúster de Redis se recomienda. El uso de la persistencia puede añadir una pequeña sobrecarga a las operaciones de tiempo de ejecución. También puede haber un retardo durante el inicio de Redis ya que carga la memoria caché persistente en la memoria. Este retardo varía en función del tamaño del archivo. Para su uso con HCL Cache, el uso de RDB solamente (no AOF) puede ser suficiente.

Al configurar volúmenes permanentes de Kubernetes para Redis, seleccione una storageClass con almacenamiento SSD rápido. De forma predeterminada, Redis solo 8 solicita GB de almacenamiento para un volumen persistente. Puede que no sea suficiente, especialmente si la persistencia AOF está habilitada. Solicite un tamaño mayor (por ejemplo, 30 GB) y supervise el uso para comprender mejor cuánto almacenamiento es necesario.

Gráficos bitnami de Redis

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

Redis autónomo

Utilice este gráfico de Redis para instalar Redis independiente, sin persistencia. Revise redis-standalone-values.yaml para obtener más detalles.

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

Note: Si Prometheus no está configurado, inhabilite la sección de métricas antes de instalar. Para obtener más información acerca de Promethus y la integración de Grafana, consulte Supervisión de HCL Commerce: Integración de Prometheus y Grafana

Clúster de Redis

Estos pasos instalan un clúster de Redis con tres maestros. Revise redis-cluster-values.yaml para obtener más detalles.

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

Note: Si Prometheus no está configurado, inhabilite la sección de métricas antes de instalar. Para obtener más información acerca de Promethus y la integración de Grafana, consulte Supervisión de HCL Commerce: Integración de Prometheus y Grafana

Configuraciones y ajustes comunes

Las siguientes configuraciones son comunes para los gráficos autónomos y de clúster:

Configuraciones de Redis

La sección siguiente consiste en personalizar las configuraciones predeterminadas de Redis (consulte redis.conf).

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

maxmemory

Determina el tamaño de la memoria disponible para almacenar objetos Redis. La cantidad de memoria caché variará de sitio a sitio. 10 GB es una buena configuración de inicio. El límite de memoria del pod debe ser superior.

maxmemory-policy

Es necesario utilizar volatile-lru para HCL Cache. Esto permite a Redis expulsar entradas de memoria caché pero no IDs de dependencia. Las opciones appendonly y save son para la persistencia, que está inhabilitada en el ejemplo.

Esta sección también se puede utilizar para habilitar valores de depuración, como por ejemplo para SLOWLOG:

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

Solo clúster de Redis:

cluster-require-full-coverage: No:

Cuando no todas las ranuras están cubiertas (por ejemplo, debido al maestro inactivo), se emite el error CLUSTERDOWN . Configurar de cluster-require-full-coverage a no habilita el subconjunto de nodos que permanecen disponibles para continuar atendiendo solicitudes.

Si tiene previsto habilitar réplicas, consulte Uso de réplicas de Redis para obtener configuraciones adicionales.

Persistencia

La persistencia de Kubernetes (PVC) debe estar habilitada si se utiliza la persistencia de Redis (AOF/RDB) o con la agrupación en clúster de Redis. Si se utiliza la persistencia de Redis, la PVC debe ser lo suficientemente grande para dar cabida a las papeleras de memoria de Redis. Con el clúster de Redis, el clúster mantiene un archivo nodes.conf que debe persistir, ya que de lo contrario los nodos que se reinician no pueden volver a unirse al clúster. Este archivo requiere un almacenamiento mínimo.

Recursos

Redis tiene una sola hebra (en su mayoría), por lo que se beneficia más de tener procesadores más rápidos, en lugar de tener varios procesadores. Dos CPUs pueden funcionar bien en muchos casos. Es importante supervisar la limitación de recursos de Kubernetes CPU y asegurarse de que no se está produciendo, ya que la regulación puede detener la hebra principal de Redis. La memoria asignada debe ser mayor que la memoria asignada para la memoria caché de Redis (consulte más arriba).

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

Métricas

Si Prometheus está configurado, puede habilitar métricas y serviceMonitors (requiere Kube-prometer-stack). Las métricas de Redis se pueden consumir con el panel de Redis Grafana. El panel HCL Cache - Remote también muestra las métricas de Redis.

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

Configuraciones adicionales del sistema operativo (sysctl)