Cuáles son los procedimientos recomendados para los niveles Enterprise y Enterprise Flash
Estos son los procedimientos recomendados al usar los niveles Enterprise y Enterprise Flash de Azure Cache for Redis.
Redundancia de zona
Se recomienda encarecidamente implementar nuevas cachés en una configuración con redundancia de zona. La redundancia de zona garantiza que los nodos de Redis Enterprise se reparten entre tres zonas de disponibilidad, lo que aumenta la redundancia para las interrupciones de nivel de centro de datos. El uso de redundancia de zona aumenta la disponibilidad. Para obtener más información, consulte Acuerdos de nivel de servicio (SLA) para servicios en línea.
La redundancia de zona es importante en el nivel Enterprise porque la instancia de caché siempre usa al menos tres nodos. Dos nodos son nodos de datos, que contienen los datos y un nodo de cuórum. Aumentar la capacidad escala el número de nodos de datos en incrementos de número par.
También hay otro nodo denominado nodo de cuórum. Este nodo supervisa los nodos de datos y selecciona automáticamente el nuevo nodo principal si se produjo una conmutación por error. La redundancia de zona garantiza que los nodos se distribuyan uniformemente entre tres zonas de disponibilidad, lo que minimiza el potencial de pérdida de cuórum. No se cobra a los clientes por el nodo de cuórum y no hay ningún otro cargo por usar la redundancia de zona más allá de los cargos de ancho de banda dentro de la zona.
Ampliación
En los niveles Enterprise y Enterprise Flash de Azure Cache for Redis, se recomienda priorizar el escalado vertical en vez del escalado horizontal. Priorice el escalado vertical porque los niveles Enterprise se basan en Redis Enterprise, que es capaz de usar más núcleos de CPU en máquinas virtuales más grandes.
Por el contrario, la recomendación contraria es cierta para los niveles Básico, Estándar y Premium, que se basan en Redis de código abierto. En esos niveles, se recomienda priorizar el escalado horizontal en vez del escalado vertical en la mayoría de los casos.
Particionamiento y uso de CPU
En los niveles Básico, Estándar y Premium de Azure Cache for Redis, determinar el número de CPU virtuales (vCPU) en uso es sencillo. Cada nodo de Redis se ejecuta en una máquina virtual (VM) dedicada. El proceso de servidor de Redis es de un solo subproceso, utilizando una CPU virtual en cada nodo principal y cada nodo de réplica. Las otras CPU virtuales de la máquina virtual se siguen usando para otras actividades, como la coordinación del flujo de trabajo para diferentes tareas, la supervisión del estado y la carga de TLS, entre otras.
Al usar la agrupación en clústeres, el efecto es distribuir datos entre más nodos con una partición por nodo. Al aumentar el número de particiones, aumenta linealmente el número de CPU virtuales que se usan, en función del número de particiones del clúster.
Por otro lado, Redis Enterprise puede usar varias CPU virtuales para la propia instancia de Redis. En otras palabras, todos los niveles de Azure Cache for Redis pueden usar varias CPU virtuales para tareas en segundo plano y de supervisión, pero solo los niveles Enterprise y Enterprise Flash pueden usar varias CPU virtuales por máquina virtual para las particiones de Redis. En la tabla se muestra el número de CPU virtuales efectivas que se usan para cada SKU y la configuración de capacidad (es decir, escalabilidad horizontal).
Las tablas muestran el número de CPU virtuales usadas para las particiones principales, no las particiones de réplica. Las particiones no se asignan una a una al número de CPU virtuales. Las tablas solo muestran las CPU virtuales, no las particiones. Algunas configuraciones usan más particiones que las CPU virtuales disponibles para aumentar el rendimiento en algunos escenarios de uso.
E1
| Capacity | CPU virtuales efectivas |
|---|---|
| 2 | 1 (ampliable) |
E5
| Capacity | CPU virtuales efectivas |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capacity | CPU virtuales efectivas |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capacity | CPU virtuales efectivas |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capacity | CPU virtuales efectivas |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capacity | CPU virtuales efectivas |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capacity | CPU virtuales efectivas |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capacity | CPU virtuales efectivas |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capacity | CPU virtuales efectivas |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capacity | CPU virtuales efectivas |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capacity | CPU virtuales efectivas |
|---|---|
| 3 | 30 |
| 9 | 90 |
Agrupación en clústeres en nivel Enterprise
Los niveles Enterprise y Enterprise Flash se agrupan de forma inherente, a diferencia de los niveles Básico, Estándar y Premium. La implementación depende de la directiva de agrupación en clústeres seleccionada. Los niveles Enterprise ofrecen 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 OSS implementa la misma API de clúster de Redis como Redis de código abierto. La API de clúster de Redis permite al cliente de Redis conectarse directamente a cada nodo de Redis, lo que minimiza la latencia y optimiza el rendimiento de red. Como resultado, se obtiene una escalabilidad casi lineal al escalar horizontalmente el clúster con más nodos. La directiva de agrupación en clústeres OSS generalmente proporciona el mejor rendimiento y latencia, pero requiere que la biblioteca cliente admita la agrupación en clústeres de Redis. 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 las bibliotecas cliente de Redis no necesitan admitir la agrupación en clústeres de Redis para aprovechar varios nodos. 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.
Comandos de varias claves
Dado que los niveles Enterprise usan una configuración en clúster, es posible que vea excepciones CROSSSLOT en comandos que funcionan en 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.
Procedimientos recomendados de Enterprise Flash
El nivel Enterprise Flash utiliza tanto almacenamiento Flash NVMe como RAM. Dado que el almacenamiento Flash posee un costo menor, el uso del nivel Enterprise Flash le permite intercambiar algo de rendimiento por una eficiencia de los precios.
En las instancias de Enterprise Flash, el 20 % del espacio en caché está en 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 Enterprise Flash
Las cargas de trabajo que probablemente se ejecuten bien en el nivel Enterprise 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 Enterprise Flash
Algunas cargas de trabajo tienen características de acceso menos optimizadas para el diseño del nivel 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.
Control de escenarios de regiones inactivas con replicación geográfica activa
La replicación geográfica activa es una característica eficaz para aumentar drásticamente la disponibilidad al usar los niveles Enterprise de Azure Cache for Redis. Sin embargo, debe realizar los pasos necesarios para preparar las memorias caché si hay una interrupción regional.
Por ejemplo, considere estos consejos:
- Identifique de antemano a qué otra memoria caché del grupo de replicación geográfica se va a cambiar si una región deja de funcionar.
- Asegúrese de que los firewalls estén establecidos para que las aplicaciones y los clientes puedan acceder a la memoria caché de reserva identificada.
- Cada caché del grupo de replicación geográfica tiene su propia clave de acceso. Determine cómo cambia la aplicación a claves de acceso distintas al dirigirse a una caché de reserva.
- Si una caché del grupo de replicación geográfica deja de funcionar, comienza a producirse una acumulación de metadatos en todas las memorias caché del grupo de replicación geográfica. Los metadatos no se pueden descartar hasta que las escrituras se puedan volver a sincronizar con todas las caché. Puede evitar la acumulación de metadatos mediante la desvinculación forzada de la caché que está inactiva. Considere la posibilidad de supervisar la memoria disponible en la caché y desvincular si hay presión en la memoria, especialmente para cargas de trabajo con mucha escritura.
También es posible usar un patrón de disyuntor. Use el patrón para redirigir automáticamente el tráfico fuera de una caché que experimenta una interrupción de la región y hacia una caché de reserva en el mismo grupo de replicación geográfica. Use servicios de Azure como Azure Traffic Manager o Azure Load Balancer para habilitar el redireccionamiento.
Comparación entre la persistencia de datos y la copia de seguridad de datos
La característica de persistencia de datos en los niveles Enterprise y Enterprise Flash está diseñada para proporcionar automáticamente un punto de recuperación rápido para los datos cuando una caché deja de funcionar. La recuperación rápida se hace posible almacenando el archivo RDB o AOF en un disco administrado montado en la instancia de caché. Los archivos de persistencia del disco no son accesibles para los usuarios.
Muchos clientes quieren usar la persistencia para realizar copias de seguridad periódicas de los datos en su caché. No se recomienda usar la persistencia de datos de esta manera. En su lugar, use la característica import/export. Puede exportar copias de datos de caché en formato RDB directamente a la cuenta de almacenamiento elegida y desencadenar la exportación de datos con la frecuencia que necesite. La exportación se puede desencadenar desde el portal o mediante la CLI, PowerShell o las herramientas del SDK.
Limitaciones de SKU de E1
La SKU de E1 está pensada para escenarios de desarrollo y pruebas, principalmente. E1 se ejecuta en máquinas virtualesampliables más pequeñas. Las máquinas virtuales ampliables ofrecen un rendimiento variable en función de la cantidad de CPU consumida. A diferencia de otras ofertas de SKU empresarial, no se puede escalar horizontalmente la SKU E1, aunque todavía es posible escalar verticalmente a una SKU mayor. La SKU E1 tampoco admite la Replicación geográfica activa.