Arquitectura de Azure Managed Redis (versión preliminar)
Azure Managed Redis (versión preliminar) se ejecuta en la pila de Redis Enterprise, que ofrece ventajas significativas sobre la edición comunitaria 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.
Importante
Azure Managed Redis se encuentra actualmente en VERSIÓN PRELIMINAR. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
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 versión de Redis tiene varias limitaciones significativas, incluidas las de un solo subproceso por diseño. 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 cuenta con 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
Clustering
Dado que Redis Enterprise puede usar varias particiones por nodo, cada instancia de Azure Managed Redis está configurada internamente para usar la agrupación en clústeres, en todos los niveles y SKU. 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 dos 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 dos opciones para la directiva de agrupación en clústeres: OSS y Enterprise. 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 directiva de agrupación en clústeres de OSS implementa la misma API de clústeres Redis que la edición comunitaria de 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 tampoco se puede usar con el módulo RediSearch.
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 para los usuarios. Esto significa que las bibliotecas de 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, lo que aumenta la compatibilidad con versiones anteriores y simplifica la conexión. 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. Mientras que la directiva de clúster Enterprise hace que una instancia de Azure Managed Redis aparezca como no agrupada a los usuarios, todavía tiene algunas limitaciones con los comandos de varias claves.
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:
El número de particiones y vCPU utilizadas en cada SKU puede cambiar con el tiempo a medida que el equipo de Azure Managed Redis optimiza el rendimiento.
| Niveles | Optimizado para flash | Memoria optimizada | Equilibrada | Optimizada 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/1 | 4/2 |
| 6 | - | - | 2/1 | 4/2 |
| 12 | - | 2/1 | 4/2 | 8/6 |
| 24 | - | 4/2 | 8/6 | 16/12 |
| 60 | - | 8/6 | 16/12 | 32/24 |
| 120 | - | 16/12 | 32/24 | 64/48 |
| 180 | - | 24/24 | 48/48 | 96/96 |
| 240 | 8/6 | 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 | - | - | - |
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 la reducción de escala en Azure Managed redis. Para más información, consulte Requisitos previos/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.