Azure Cache for Redis y confiabilidad
Azure Cache for Redis proporciona un almacén de datos en memoria basado en el software de Redis (servidor de diccionario remoto). Un agente de mensajería y una memoria caché de datos segura que proporciona a las aplicaciones un acceso de alto rendimiento y baja latencia a los datos.
Estos son algunos conceptos clave y procedimientos recomendados que dan apoyo a la confiabilidad:
En las secciones siguientes se incluyen consideraciones de diseño, una lista de comprobación de configuración y opciones de configuración recomendadas específicas de Azure Cache for Redis.
Consideraciones de diseño
Los Acuerdos de Nivel de Servicio de Azure Cache for Redis solo incluyen las cachés de los niveles Estándar y Premium. El nivel Básico no está cubierto.
Redis es una caché en memoria para pares clave-valor que tiene una alta disponibilidad de manera predeterminada, excepto en el nivel Básico. Hay tres niveles para Azure Cache for Redis:
Básico: no se recomienda para las cargas de trabajo de producción. El nivel Básico es idóneo para:
- Nodo único
- Varios tamaños
- Desarrollo
- Prueba
- Cargas de trabajo no críticas
Estándar: caché replicada en una configuración de dos nodos, principal y secundario, administrada por Microsoft y con un Acuerdo de Nivel de Servicio de alta disponibilidad.
Prémium: incluye todas las características de nivel estándar e incluye las siguientes características:
- Hardware y rendimiento más rápidos, en comparación con los niveles Básico o Estándar.
- Caché de mayor tamaño, hasta
120GB
. - Persistencia de los datos, que incluye un archivo de base de datos de Redis (RDB) y un archivo de solo anexar (AOF).
- Compatibilidad con redes virtuales.
- Clustering
- Replicación geográfica: una caché secundaria se encuentra en otra región y replica los datos de la réplica principal para la recuperación ante desastres. Para conmutar por error a la base de datos secundaria, las memorias caché deben desvincularse manualmente y, a continuación, la secundaria estará disponible para escrituras. La aplicación que escribe en Redis debe actualizarse con la cadena de conexión de la caché secundaria.
- Zonas de disponibilidad: implemente la memoria caché y las réplicas entre las zonas de disponibilidad.
Nota
De manera predeterminada, cada implementación tendrá una sola réplica por partición. La persistencia, la agrupación en clústeres y la replicación geográfica están deshabilitadas en este momento con implementaciones que tienen más de una réplica. Los nodos se distribuirán uniformemente entre todas las zonas. Debe tener un recuento de réplicas que sea
>=
que el número de zonas. - Importación y exportación.
Microsoft garantiza como mínimo que al menos un 99.9%
los clientes tendrán conectividad entre los puntos de conexión de la caché y la puerta de enlace de Internet de Microsoft.
Lista de comprobación
¿Ha configurado Azure Cache for Redis teniendo en cuenta la resistencia?
- Programar actualizaciones.
- Supervise la caché y establezca alertas.
- Implemente la caché dentro de una red virtual.
- Evalúe una estrategia de creación de particiones en Redis Cache.
- Configure Persistencia de los datos para guardar una copia de la memoria caché en Azure Storage o usar la replicación geográfica, según los requisitos empresariales.
- Implemente directivas de reintento en el contexto de Azure Redis Cache.
- Use una implementación estática o singleton del multiplexor de conexión a Redis y siga la guía de procedimientos recomendados.
- Consulte Administración de Azure Cache for Redis.
Recomendaciones para la configuración
Consulte la siguiente tabla de recomendaciones para optimizar la configuración de Azure Cache for Redis relacionada con la confiabilidad del servicio:
Recomendación | Descripción |
---|---|
Programar actualizaciones. | Programe los días y las horas en que las actualizaciones del servidor de Redis se aplicarán a la caché, lo que no incluye las actualizaciones de Azure ni las del sistema operativo de la máquina virtual. |
Supervise la caché y establezca alertas. | Establezca alertas para excepciones, uso elevado de CPU, uso elevado de memoria, carga del servidor y claves expulsadas para obtener información sobre cuándo escalar la memoria caché. Si es necesario escalar la memoria caché, es importante saber cuál el mejor momento para hacerlo, ya que aumentará uso de la CPU durante el evento de escalado para migrar los datos. |
Implemente la caché dentro de una red virtual. | Proporciona al cliente más control sobre el tráfico que se puede conectar a la caché. Asegúrese de que la subred tenga suficiente espacio de direcciones disponible para implementar los nodos de la memoria caché y las particiones (clúster). |
Evalúe una estrategia de creación de particiones en Redis Cache. | Crear particiones en un almacén de datos Redis implica dividir los datos entre las instancias del servidor de Redis. Cada instancia constituye una sola partición. Azure Redis Cache abstrae los servicios de Redis detrás de una fachada y no los expone directamente. La manera más sencilla de implementar la creación de particiones es crear varias instancias de Azure Redis Cache y repartir los datos entre ellas. Puede asociar cada uno de los elementos de datos con un identificador (una clave de partición) que especifica en qué caché se almacenan. La lógica de la aplicación cliente puede usar luego este identificador para enrutar las solicitudes a la partición apropiada. Este esquema es sencillo, pero si cambia el esquema de creación de particiones (por ejemplo, si se crean instancias de Azure Redis Cache adicionales), es posible que las aplicaciones cliente se deban volver a configurar. |
Configure Persistencia de los datos para guardar una copia de la memoria caché en Azure Storage o usar la replicación geográfica, según los requisitos empresariales. | Persistencia de datos: si el maestro y la réplica se reinician, los datos se cargarán automáticamente desde la cuenta de almacenamiento. Replicación geográfica: la caché secundaria debe desvincularse de la principal. La secundaria se convertirá ahora en la principal y puede recibir escrituras. |
Implemente directivas de reintento en el contexto de Azure Redis Cache. | La mayoría de SDK de cliente y de servicios de Azure incluye un mecanismo de reintento. Estos mecanismos difieren porque cada servicio tiene características y requisitos diferentes. Cada mecanismo de reintento se ajusta a un servicio específico. |
Consulte Administración de Azure Cache for Redis. | Sepa cómo se puede producir la pérdida de datos con los reinicios de la caché y cómo probar la resistencia de la aplicación. |
Artefactos de origen
Para identificar las instancias de Redis que no están en el nivel Premium, use la siguiente consulta:
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'