Servidores Redis para HCL Cache

Requisitos del servidor Redis para HCL Commerce

Aunque el uso de una memoria caché remota en Redis es muy recomendable, no es necesario en todas las configuraciones.

Elasticsearch: Redis es necesario. Los servidores de Redis deben compartirse por autoría y en directo. Esto es necesario ya que NiFi debe interactuar con los entornos de autoría y de producción.
Búsqueda Solr: Se recomienda Redis pero no es obligatorio. Los entornos migrados que no implementan Redis deben seguir utilizando Kafka para replicar invalidaciones. Redis sustituye Kafka para invalidaciones y también puede actuar como memoria caché remota. La creación y producción se pueden configurar con servidores Redis separados. Esto es recomendable para entornos de producción.

Selección de una topología de Redis

Redis se puede instalar en una variedad de configuraciones. La selección depende del rendimiento y de los requisitos de alta disponibilidad. Las alternativas incluyen:

Utilización de los gráficos Bitnami para instalar Redis dentro del clúster de Kubernetes
Redis Enterprise por RedisLabs
Redis como servicio de un proveedor de nube

Configuraciones autónomas y de clúster

Redis autónomo (instancia única) funcionará adecuadamente para entornos de preproducción y muchos entornos de producción. Los entornos más grandes pueden beneficiarse de Redis en clúster, lo que permite varios maestros y réplicas.

Se ha configurado un clúster de Redis con varios maestros (3+). Las memorias caché y los fragmentos se distribuirán entre los servidores maestros. Cada maestro se puede configurar con cero o más réplicas. Las réplicas pueden ayudar a la escalabilidad manejando el tráfico de lectura (operaciones GET) y pueden tomar el control en caso de que el maestro deje de estar disponible.

Configuraciones requeridas

Utilice las configuraciones siguientes en el servidor Redis. Consulte el apartado desalojo de claves para obtener más detalles.

maxmemory: Indica la cantidad de memoria disponible para contener datos almacenados en memoria caché y debe establecerse en un valor distinto de cero.
maxmemory-policy: Debe establecerse en volatile-lru

Configuraciones de ajuste de teclas

Además de la topología, tenga en cuenta las siguientes configuraciones de ajuste de claves. La mayoría se aplica a Redis instalado localmente, pero también puede ser relevante para Redis como servicio.

Para validar o comparar el rendimiento del servidor Redis, puede utilizar el programa de utilidad benchmark de Redis y el programa de utilidad de HCL Cache, hcl-cache-benchmark .

Utilizar CPU rápidas y almacenamiento rápido: Redis es principalmente de una sola hebra, al menos desde el punto de vista de ejecución del mandato. Se beneficia de procesadores rápidos con una frecuencia alta. Si la persistencia está habilitada, los contenedores también se beneficiarán del almacenamiento rápido. Utilice una clase de almacenamiento premium respaldada por SSDs.

Validar los límites de Kubernetes

Asegúrese de que los límites establecidos en los pods de Redis estén establecidos de forma appropiate:

Almacenamiento: Si se utiliza la persistencia, es necesario ajustar el tamaño de los volúmenes permanentes de forma precisa. Por ejemplo, los gráficos Bitnami establecen un límite de GB de 8 forma predeterminada. Esto puede no ser suficiente para los entornos de producción y puede provocar un bloqueo.
CPU: La regulación de CPU puede bloquear el servidor Redis. Kubernetes es muy agresivo con la regulación de CPU. Para evitarlo, establezca un límite alto o elimine el límite de CPU para los pods de Redis.
Memoria: La memoria que necesita el contenedor Redis es una función de la configuración de maxmemory. maxmemory debe ser inferior al 70% del límite de contenedor.

Persistencia de Redis: Redis incluye opciones de persistencia (AOF/ RDB) 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 el uso con HCL Cache, la habilitación de la persistencia RDB y la inhabilitación de AOF debe ser suficiente.
La persistencia es necesaria cuando se utilizan réplicas. De lo contrario, es opcional y Redis no requiere un volumen de persistencia. Sin persistencia, en el caso improbable de que Redis se bloquee o no responda, Kubernetes debería poder reiniciar el servicio casi instantáneamente, pero con una memoria caché vacía.
Si el sitio de Commerce no se ajusta para absorber una memoria caché clear durante el periodo de tráfico máximo, se recomienda la persistencia. Cuando la persistencia está habilitada, el inicio se retrasará un número de segundos mientras Redis vuelva a cargar la memoria caché del disco. También es posible que si Kubernetes nodo se bloquea, es posible que sea necesaria una intervención manual para liberar el volumen de persistencia de la nodo problemático y para permitir que Kubernetes replanifique el pod (debido al modo ReadWriteOnce-RWO ).
Note: Exención de responsabilidad: Redis es una marca registrada de Redis Labs Ltd. Los derechos que en él se incluyen están reservados a Redis Labs Ltd. Cualquier uso por parte de HCL es únicamente para fines referenciales y no indica patrocinio, respaldo ni afiliación entre Redis Labs Ltd.