Arquitectura de Redis administrada de Azure

Azure Managed Redis se ejecuta en la pila de Redis Enterprise, que ofrece ventajas significativas sobre la edición Community de Redis. La siguiente información proporciona más detalles sobre cómo la arquitectura de Azure Managed Redis, incluida la información que puede resultar útil para los usuarios avanzados.

Comparación con Azure Cache for Redis

Los niveles Básico, Estándar y Premium de Azure Cache for Redis se crearon en la edición comunitaria de Redis. Esta edición de la comunidad de Redis tiene varias limitaciones significativas, incluida la de un solo subproceso. Esto reduce significativamente el rendimiento y hace que el escalado sea menos eficaz, ya que el servicio no utiliza completamente más vCPUs. Una instancia típica de Azure Cache for Redis usa una arquitectura como esta:

Tenga en cuenta que se usan dos máquinas virtuales: una principal y una réplica. Estas máquinas virtuales también se denominan "nodos". El nodo principal contiene el proceso principal de Redis y acepta todas las escrituras. La replicación se realiza de forma asíncrona en el nodo réplica para proporcionar una copia de seguridad durante el mantenimiento, el escalado o un error inesperado. Cada nodo solo es capaz de ejecutar un único proceso de servidor de Redis debido al diseño de un solo subproceso de Redis.

Mejoras en la arquitectura de Azure Managed Redis

Azure Managed Redis usa una arquitectura más avanzada que tiene un aspecto similar al siguiente:

Hay varias diferencias:

• Cada máquina virtual (o "nodo") ejecuta varios procesos de servidor de Redis (denominados "particiones") en paralelo. Varias particiones permiten un uso más eficaz de las vCPU en cada máquina virtual y un mayor rendimiento.
• No todas las particiones principales de Redis están en la misma máquina virtual o nodo. En su lugar, las particiones principales y de réplica se distribuyen entre ambos nodos. Dado que las particiones principales utilizan más recursos de CPU que las particiones de réplica, este enfoque permite ejecutar más particiones principales en paralelo.
• Cada nodo tiene un proceso de proxy de alto rendimiento para administrar las particiones, controlar la administración de conexiones y desencadenar la recuperación automática.

Esta arquitectura permite un mayor rendimiento y también características avanzadas, como la replicación geográfica activa

Agrupación en clústeres

Cada instancia de Azure Managed Redis está configurada internamente para usar la agrupación en clústeres, en todos los niveles y SKU. Azure Managed Redis se basa en Redis Enterprise, que puede usar varias particiones por nodo. Esto incluye instancias más pequeñas que solo están configuradas para usar una sola partición. La agrupación en clústeres es una manera de dividir los datos en la instancia de Redis entre varios procesos de Redis, también denominado "particionamiento". Azure Managed Redis ofrece tres directivas de clúster que determinan qué protocolo está disponible para los clientes de Redis para conectarse a la instancia de caché.

Directivas de clústeres

Azure Managed Redis ofrece tres directivas de agrupación en clústeres: sistema operativo, empresa y no agrupado (versión preliminar). Se recomienda la directiva de clúster OSS para la mayoría de las aplicaciones, ya que admite un mayor rendimiento máximo, pero ambas versiones tienen sus ventajas y desventajas.

La política de agrupación en clústeres de OSS implementa la misma API de clúster de Redis que los niveles de servicio de Azure Cache for Redis. La API de clúster de Redis permite al cliente de Redis conectarse directamente a las particiones de cada nodo de Redis, minimizando la latencia y optimizando el rendimiento de la red, lo que permite que el rendimiento se amplíe de forma casi lineal a medida que aumenta el número de particiones y vCPU. La directiva de clúster OSS suele ofrecer el mejor rendimiento y latencia. Sin embargo, la directiva de clústeres de OSS requiere que su biblioteca cliente sea compatible con la API de clústeres de Redis. Actualmente, casi todos los clientes de Redis soportan la API de clúster de Redis, pero la compatibilidad puede ser un problema para versiones antiguas de clientes o bibliotecas especializadas.

La directiva de agrupación en clústeres de OSS no se puede usar con el módulo RediSearch.

El protocolo de agrupación en clústeres del sistema operativo requiere que el cliente realice las conexiones de particiones correctas. La conexión inicial es a través del puerto 10000. La conexión a nodos individuales se realiza mediante puertos en el rango de 85XX. Los puertos 85xx pueden cambiar con el tiempo y no deben codificarse de forma dura en la aplicación. Los clientes de Redis que admiten la agrupación en clústeres usan el comando CLUSTER NODES para determinar los puertos exactos que se usan para las particiones principales y de réplicas y realizar las conexiones de particiones por usted.

La directiva de agrupación en clústeres Enterprise es una configuración más sencilla que utiliza un único punto de conexión para todas las conexiones de cliente. El uso de la directiva de agrupación en clústeres Enterprise enruta todas las solicitudes a un único nodo de Redis que, a continuación, se usa como proxy, enrutando internamente las solicitudes al nodo correcto del clúster. La ventaja de este enfoque es que hace que Azure Managed Redis parezca no agrupado a los usuarios. Esto significa que las bibliotecas cliente de Redis no necesitan admitir la agrupación en clústeres de Redis para obtener algunas de las ventajas de rendimiento de Redis Enterprise. El uso de un único punto de conexión aumenta la compatibilidad con versiones anteriores y hace que la conexión sea más sencilla. El inconveniente es que el proxy de nodo único puede ser un cuello de botella, ya sea en el uso de proceso o en el rendimiento de red.

La directiva de agrupación en clústeres Enterprise es la única que se puede usar con el módulo RediSearch. Aunque la directiva de clúster enterprise hace que una instancia de Redis administrada de Azure parezca que no está agrupada para los usuarios, sigue teniendo algunas limitaciones con comandos de varias claves.

La directiva de agrupación en clústeres no agrupada (versión preliminar) almacena datos en cada nodo sin particionamiento. Solo se aplica a las memorias caché con un tamaño de 25 GB y más pequeños. Entre los escenarios para usar la directiva de agrupación en clústeres no agrupados (versión preliminar) se incluyen:

• Al migrar desde un entorno de Redis que no está particionado. Por ejemplo, las topologías no particionadas de SKU Básica, Estándar y Premium de Azure Cache for Redis.
• Al ejecutar comandos entre ranuras ampliamente y dividir los datos en particiones, se producirán errores. Por ejemplo, los comandos MULTI.
• Al usar Redis como agente de mensajes y no necesita particionamiento.

Las consideraciones para usar la directiva no agrupada (versión preliminar) son:

• Esto solo se aplica a los niveles de Redis administrados de Azure que son menores o iguales a 25 GB.
• No es tan eficaz como otras directivas de agrupación en clústeres, ya que las CPU solo pueden multiproceso con software de Redis Enterprise cuando la memoria caché está particionada.
• Si desea escalar verticalmente la caché de Azure Managed Redis, primero debe cambiar la directiva de clúster.
• Si va a pasar de una topología básica, estándar o premium no agrupada, considere la posibilidad de usar clústeres de sistema operativo para mejorar el rendimiento. Las configuraciones no agrupadas solo deben usarse si la aplicación no puede admitir topologías de sistema operativo o enterprise.

Reducción o adición de nodos

El software principal de Redis Enterprise es capaz de escalar verticalmente (mediante máquinas virtuales más grandes) o escalar horizontalmente (agregando más nodos o máquinas virtuales). En última instancia, cualquier acción de escalado consigue lo mismo: agregar más memoria, más vCPU y más particiones. Debido a esta redundancia, Azure Managed Redis no ofrece la capacidad de controlar el número específico de nodos usados en cada configuración. Este detalle de implementación se abstrae para que el usuario evite confusiones, complejidades y configuraciones poco óptimas. En su lugar, cada SKU está diseñada con una configuración de nodo para maximizar las vCPU y la memoria. Algunas SKU de Azure Managed Redis usan solo dos nodos, mientras que algunas usan más.

Comandos de varias claves

Dado que las instancias de Azure Managed Redis están diseñadas con una configuración en clúster, es posible que aparezcan excepciones CROSSSLOT en los comandos que operan con varias claves. El comportamiento varía en función de la directiva de agrupación en clústeres utilizada. Si usa la directiva de agrupación en clústeres de OSS, los comandos de varias claves requieren que todas las claves se asignen a la misma ranura hash.

También puede ver errores CROSSSLOT con la directiva de agrupación en clústeres Enterprise. Solo se permiten los siguientes comandos de varias claves entre ranuras con clústeres Enterprise: DEL, MSET, MGET, EXISTS, UNLINK y TOUCH.

En bases de datos Activa-activa, los comandos de escritura de varias claves (DEL, MSET y UNLINK) solo se podrán ejecutar en las claves que estén en la misma ranura. Sin embargo, se permiten los siguientes comandos de varias claves entre ranuras de bases de datos Activa-activa: MGET, EXISTS y TOUCH. Para obtener más información, consulte Agrupación en clústeres de base de datos.

Configuración de particionamiento

Cada SKU de Azure Managed Redis está configurada para ejecutar un número específico de procesos de servidor de Redis, particiones en paralelo. La relación entre el rendimiento, el número de particiones y el número de vCPU disponibles en cada instancia es complicado. La adición de particiones suele aumentar el rendimiento, ya que las operaciones de Redis se pueden ejecutar en paralelo. Sin embargo, si las particiones no pueden ejecutar comandos porque no hay vCPUs disponibles, el rendimiento puede disminuir. En la siguiente tabla se muestra la configuración de particionamiento para cada SKU de Azure Managed Redis. Estas particiones se asignan para optimizar el uso de cada vCPU al tiempo que se reservan ciclos de vCPU para el proxy de Redis Enterprise, el agente de administración y las tareas del sistema operativo, que también afectan al rendimiento.

Nota:

Azure Managed Redis optimiza el rendimiento con el tiempo cambiando el número de particiones y vCPU que se usan en cada SKU.

Importante

Todos los niveles en memoria que usan más de 120 GB de almacenamiento se encuentran en versión preliminar pública, incluido el M150 optimizado para memoria y versiones posteriores; el B150 equilibrado y versiones posteriores; y el X150 optimizado para cómputo y versiones posteriores. Todos estos niveles y superiores se encuentran en versión preliminar pública.

Todos los niveles optimizados para Flash están en versión preliminar pública.

Niveles	Optimizado para Flash (versión preliminar)	Memoria optimizada	Equilibrada	Optimizado para proceso
Tamaño (GB)	vCPU/particiones principales	vCPU/particiones principales	vCPU/particiones principales	vCPU/particiones principales
0,5	-	-	2/1	-
1	-	-	2/1	-
3	-	-	2/2	4/2
6	-	-	2/2	4/2
12	-	2/2	4/2	8 de junio
veinticuatro	-	4/2	8 de junio	16/12
60	-	8 de junio	16/12	32/24
120	-	16/12	32/24	64/48
180 *	-	24/24	48/48	96/96
240 *	8 de junio	32/24	64/48	128/96
360 *	-	48/48	96/96	192/192
480 *	16/12	64/48	128/96	256/192
720 *	24/24	96/96	192/192	384/384
960 *	32/24	128/192	256/192	-
1440 *	48/48	192/192	-	-
1920 *	64/48	256/192	-	-
4500 *	144/96	-	-	-

* Estos niveles están en versión preliminar pública.

Ejecución sin modo de alta disponibilidad habilitado

Es posible ejecutar sin el modo de alta disponibilidad (HA) habilitado. Esto significa que la instancia de Redis no tiene la replicación habilitada y no tiene acceso al Acuerdo de nivel de servicio de disponibilidad. No recomendamos ejecutar en modo sin alta disponibilidad (HA) fuera de los escenarios de desarrollo/prueba. No se puede deshabilitar la alta disponibilidad en una instancia que ya se creó. Sin embargo, puede habilitar la alta disponibilidad en una instancia que no la tenga. Dado que una instancia que se ejecuta sin alta disponibilidad utiliza menos máquinas virtuales/nodos, las vCPUs no se pueden utilizar de forma tan eficiente, por lo que el rendimiento puede ser inferior.

Memoria reservada

En cada instancia de Azure Managed Redis, aproximadamente el 20 % de la memoria disponible se reserva como búfer para operaciones que no son de caché, como la replicación durante la conmutación por error y el búfer de replicación geográfica activa. Este búfer ayuda a mejorar el rendimiento de la caché y evita que la memoria se agote.

Reducción vertical

Actualmente no se admite el escalado vertical en Redis administrado de Azure. Para más información, consulte Limitaciones del escalado de Azure Managed Redis.

Nivel optimizado para Flash

El nivel optimizado para Flash utiliza tanto almacenamiento Flash NVMe como RAM. Dado que el almacenamiento Flash es un costo menor, el uso del nivel optimizado para Flash le permite reducir el rendimiento de la eficiencia de los precios.

En las instancias optimizadas para Flash, el 20 % del espacio de caché está en la RAM, mientras que el otro 80 % usa almacenamiento Flash. Todas las claves se almacenan en RAM, mientras que los valores se pueden almacenar en almacenamiento Flash o RAM. El software de Redis determina de forma inteligente la ubicación de los valores. Los valores de Frecuente a los que se accede con frecuencia se almacenan en RAM, mientras que los valores de No interesado que se usan con menos frecuencia se mantienen en Flash. Antes de leer o escribir los datos, debe moverse a la RAM, convirtiéndose en datos deFrecuente.

Dado que Redis optimiza el mejor rendimiento, la instancia rellena primero la RAM disponible antes de agregar elementos al almacenamiento Flash. El llenado de RAM primero tiene algunas implicaciones para el rendimiento:

• Se puede producir un mejor rendimiento y una menor latencia al probar con un uso de memoria bajo. Las pruebas con una instancia de caché completa pueden producir un rendimiento menor porque solo se usa RAM en la fase de prueba de uso de memoria baja.
• A medida que escribe más datos en la memoria caché, la proporción de datos en RAM en comparación con el almacenamiento Flash disminuye, lo que suele provocar que también disminuya la latencia y el rendimiento del rendimiento.

Cargas de trabajo adecuadas para el nivel optimizado para Flash

Las cargas de trabajo que probablemente se ejecuten bien en el nivel optimizado para Flash suelen tener las siguientes características:

• Gran carga de lectura, con una alta proporción de comandos de lectura en comparación con comandos de escritura.
• El acceso se centra en un subconjunto de claves que se usan con mucha más frecuencia que el resto del conjunto de datos.
• Valores relativamente grandes en comparación con los nombres de clave. (Dado que los nombres de clave siempre se almacenan en RAM, los valores grandes pueden convertirse en un cuello de botella para el crecimiento de la memoria.)

Cargas de trabajo que no son adecuadas para el nivel optimizado para Flash

Algunas cargas de trabajo tienen características de acceso menos optimizadas para el diseño del nivel optimizado para Flash:

• Cargas de trabajo con gran carga de escritura.
• Patrones de acceso a datos aleatorios o uniformes en la mayoría del conjunto de datos.
• Nombres de clave largos con tamaños de valor relativamente pequeños.

Contenido relacionado

• Escalar una instancia de Azure Managed Redis