Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Managed Redis es un servicio de Azure totalmente administrado basado en Redis Enterprise. Proporciona almacenamiento de datos en memoria de alto rendimiento para aplicaciones y está diseñado para cargas de trabajo empresariales que requieren una latencia ultra baja, un alto rendimiento y estructuras de datos avanzadas.
Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.
En este artículo se describe cómo hacer que Azure Managed Redis sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones en regiones. También se describen las estrategias de copia de seguridad y el acuerdo de nivel de servicio (SLA).
Recomendaciones de implementación de producción
Para garantizar una alta confiabilidad para las instancias de Azure Managed Redis de producción, se recomienda:
Use la alta disponibilidad, que implementa varios nodos para la memoria caché.
Use la redundancia de zona mediante la implementación de una caché de alta disponibilidad en una región que tenga zonas de disponibilidad.
Considere la posibilidad de implementar la replicación geográfica activa para cargas de trabajo críticas que requieren conmutación por error entre regiones.
Introducción a la arquitectura de confiabilidad
En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.
Arquitectura lógica
Azure Managed Redis se basa en Redis Enterprise y proporciona confiabilidad a través de configuraciones de alta disponibilidad y funcionalidades de replicación.
Puede implementar una instancia de Azure Managed Redis, que también se conoce como una instancia de caché o una caché. Las aplicaciones cliente almacenan e interactúan con los datos de la caché mediante las API de Redis.
Arquitectura física
Al planear la resistencia en Azure Managed Redis, debe comprender los conceptos clave de los nodos y las particiones.
Nodos: Cada instancia de caché consta de nodos, que son máquinas virtuales (VM). Cada máquina virtual actúa como una unidad de proceso independiente en el clúster. No ve ni administra las máquinas virtuales directamente. La plataforma crea automáticamente instancias, supervisa el estado de las instancias y reemplaza las instancias que se vuelven no saludables. Este conjunto de máquinas virtuales forma un clúster.
Puede configurar la instancia para lograr una alta disponibilidad. Cuando se usa alta disponibilidad, Azure Managed Redis garantiza que la instancia tenga al menos dos nodos y replique automáticamente los datos entre ellos. En las regiones que tienen zonas de disponibilidad, el servicio coloca los nodos en diferentes zonas de disponibilidad. Para obtener más información, consulte Resilience to availability zone failures (Resistencia a errores de zona de disponibilidad).
El servicio abstrae el número específico de nodos de cada configuración para evitar la complejidad y garantizar configuraciones óptimas.
Particiones: Cada nodo ejecuta varios procesos de servidor de Redis conocidos como particiones. Cada partición administra un subconjunto de los datos de la memoria caché. Al establecer la memoria caché para alta disponibilidad, las particiones se distribuyen y replican automáticamente entre los nodos. Se especifica una directiva de clúster, que determina cómo se distribuyen los fragmentos entre los nodos.
Para más información, consulte Arquitectura de Azure Managed Redis y Conmutación y aplicación de revisiones para Azure Managed Redis.
Resistencia a errores transitorios
Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.
Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.
Siga estas recomendaciones para administrar errores transitorios al usar Azure Managed Redis:
Use configuraciones del SDK que vuelvan a intentarlo automáticamente cuando se produzcan errores transitorios y apliquen los períodos de retroceso y tiempo de espera adecuados. Considere la posibilidad de usar el patrón Retry y el patrón Circuit Breaker en las aplicaciones.
Diseñe patrones de reserva de caché, donde la aplicación puede seguir funcionando con un rendimiento degradado al revertir al almacén de datos principal cuando Redis deja de estar disponible temporalmente.
Resistencia a errores de zona de disponibilidad
Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.
Puede hacer que las instancias de caché de Redis administradas de Azure tengan redundancia de zona, que distribuye automáticamente los nodos de caché entre varias zonas de disponibilidad dentro de una región. La redundancia de zona reduce el riesgo de que un centro de datos o una interrupción de la zona de disponibilidad haga que la memoria caché no esté disponible.
Para que una zona de caché sea redundante, debe implementarla en una región admitida y establecerla para usar la configuración de alta disponibilidad. En regiones sin zonas de disponibilidad, la configuración de alta disponibilidad todavía crea al menos dos nodos, pero no se colocan en zonas independientes.
En el diagrama siguiente se muestra una caché con redundancia de zona con dos nodos, cada una en una zona independiente.
Requisitos
Compatibilidad con regiones: Puede implementar cachés de Azure Managed Redis con redundancia de zona en cualquier región que admita zonas de disponibilidad y donde el servicio esté disponible. Para obtener la lista de regiones que admiten zonas de disponibilidad, consulte Regiones de Azure con zonas de disponibilidad. Para obtener la lista de regiones que admiten Azure Managed Redis, consulte Disponibilidad del producto por región.
Configuración de alta disponibilidad: Debe usar la configuración de alta disponibilidad en la memoria caché para que sea redundante de zona.
Niveles: Todos los niveles de Redis administrados de Azure admiten zonas de disponibilidad.
Cost
La redundancia de zona requiere configurar la memoria caché para lograr una alta disponibilidad, lo que implementa un mínimo de dos nodos para la memoria caché. La configuración de alta disponibilidad cuesta más que una configuración sin alta disponibilidad. Para más información, consulte Precios de Azure Managed Redis.
Configurar soporte de zonas de disponibilidad
Cree una nueva instancia con redundancia de zona. Al crear una nueva instancia de Azure Managed Redis, use la configuración de alta disponibilidad e impleméntela en una región que admita zonas de disponibilidad. La instancia incluye la redundancia de zona de forma predeterminada, sin que se requiera ninguna configuración adicional.
Para más información, consulte Creación de una instancia de Azure Managed Redis.
Haga que una zona de instancia existente sea redundante. Para que una instancia de Azure Managed Redis existente tenga redundancia de zona, impleméntela en una región que admita zonas de disponibilidad y configure alta disponibilidad en la memoria caché.
Desactivar la redundancia de zona. No se puede desactivar la redundancia de zona en instancias existentes porque no se puede revertir la alta disponibilidad después de aplicarla a una memoria caché.
Planeamiento y administración de capacidad
Durante un evento de zona inactiva, es posible que la instancia tenga menos recursos disponibles para atender la carga de trabajo. Si la instancia a menudo experimenta presión de recursos y necesita prepararse para una falla de zona de disponibilidad, considere uno de los siguientes enfoques:
Sobreaprovisionar la instancia. Seleccione un nivel de rendimiento superior al necesario para que la instancia pueda tolerar cierta pérdida de capacidad y seguir funcionando sin degradar el rendimiento. Para más información, consulte Administración de la capacidad mediante sobreaprovisionamiento y Escalado de una instancia de Azure Managed Redis.
Use la replicación geográfica activa. Puede implementar varias instancias en diferentes regiones y configurar la replicación geográfica activa para distribuir la carga entre esas instancias independientes.
Comportamiento cuando todas las zonas están en buen estado
En esta sección se describe qué esperar cuando una caché administrada de Redis es con redundancia de zona y todas las zonas de disponibilidad funcionan normalmente:
Enrutamiento de tráfico entre zonas: Azure Managed Redis distribuye particiones entre nodos en función de la directiva de clúster. La directiva de clúster también determina cómo se enruta el tráfico a cada nodo. La redundancia de zona no cambia el modo en que el servicio enruta el tráfico.
Replicación de datos entre zonas: Azure Managed Redis replica automáticamente particiones entre nodos mediante la replicación asincrónica. Normalmente, se mide el retraso de replicación entre particiones en segundos, pero la duración exacta depende de la carga de trabajo de la memoria caché. Los escenarios con alta carga de escritura y de red suelen experimentar una mayor latencia de replicación.
Comportamiento durante un fallo de zona
En esta sección se describe qué esperar cuando una caché administrada de Redis es redundante de zona y una o varias zonas de disponibilidad no están disponibles:
- Detección y respuesta: Azure Managed Redis es responsable de detectar un error en una zona de disponibilidad. No es necesario hacer nada para iniciar una conmutación por error de la zona.
- Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.
Solicitudes activas: El servicio podría descartar las solicitudes en proceso y las aplicaciones deben intentar de nuevo. Las aplicaciones deben implementar lógica de reintento para controlar estas interrupciones temporales.
Pérdida de datos esperada: Es posible que los datos que no se hayan replicado en particiones de otra zona se pierdan durante un error de zona. Normalmente, se mide la cantidad de pérdida de datos en segundos, pero depende del retraso de replicación.
Tiempo de inactividad esperado: Una pequeña cantidad de tiempo de inactividad, normalmente de 10 a 15 segundos, puede producirse mientras los fragmentos realizan la conmutación por error a los nodos en zonas saludables. Para obtener más información sobre el proceso de conmutación por error no planeado, consulte Explicación de una conmutación por error. Al diseñar aplicaciones, siga los procedimientos para el control de errores transitorios.
Reenrutamiento del tráfico: Azure Managed Redis redirige automáticamente el tráfico a los nodos de zonas correctas.
Recuperación de zona
Cuando se recupera la zona de disponibilidad afectada, Azure Managed Redis restaura automáticamente las operaciones a esa zona. La plataforma Azure administra completamente este proceso y no requiere ninguna intervención del cliente.
Prueba de fallos de zona
Azure Managed Redis administra completamente el enrutamiento del tráfico, la conmutación por error y la conmutación por restablecimiento para las fallas de zona, de modo que no es necesario validar los procesos de fallas en la zona de disponibilidad ni aportar más información.
Resistencia a errores en toda la región
Azure Managed Redis proporciona compatibilidad nativa con varias regiones a través de la replicación geográfica activa, que permite vincular varias instancias de Azure Managed Redis entre distintas regiones de Azure en un único grupo de replicación. Después, puede configurar su propio enfoque de conmutación por error entre las instancias.
Replicación geográfica activa
Cuando se usa la replicación geográfica activa, las aplicaciones pueden leer y escribir en cualquier instancia de caché del grupo, con cambios sincronizados automáticamente en todas las regiones. El servicio admite patrones de replicación activo-activo en los que cada región puede controlar las operaciones de lectura y escritura simultáneamente. Cuando se producen conflictos debido a escrituras simultáneas en regiones diferentes, el servicio los resuelve automáticamente mediante algoritmos de resolución de conflictos predeterminados sin necesidad de intervención manual. Este enfoque proporciona resistencia a errores de región al tiempo que mantiene el acceso de baja latencia para las aplicaciones distribuidas globalmente.
En el diagrama siguiente se muestran dos instancias de caché en regiones diferentes dentro del mismo grupo de replicación geográfica activa, junto con las aplicaciones cliente que se conectan a cada instancia de caché.
Tú eres responsable de configurar las aplicaciones cliente para redirigir las solicitudes a una instancia operativa si falla alguna instancia regional. En el diagrama siguiente se muestra cómo una aplicación puede redirigir sus solicitudes a una instancia de caché correcta cuando se produce un error en la instancia que suelen usar.
Requisitos
Compatibilidad con regiones: Puede configurar la replicación geográfica activa de Azure Managed Redis entre cualquier región de Azure en la que el servicio esté disponible.
Configuración de instancia: La replicación geográfica activa requiere instancias de Azure Managed Redis que usen el mismo nivel y tamaño en cada región participante. Todas las instancias de caché de un grupo de replicación deben usar una configuración idéntica, incluidas las opciones de persistencia, los módulos y las directivas de agrupación en clústeres.
Otros requisitos: Las instancias de caché deben cumplir otros requisitos, incluidos los módulos que use. Estos requisitos afectan a cómo puede escalar las instancias de caché. Para más información, consulte Requisitos previos de replicación geográfica activa.
Consideraciones
Responsabilidad de conmutación por error: Al usar la replicación geográfica activa, es responsable de la conmutación por error entre instancias de caché. Prepare su aplicación para gestionar la conmutación por error. La conmutación por error requiere preparación y puede implicar realizar varios pasos. Para obtener más información, consulte Cómo forzar la desvinculación durante una interrupción regional.
Coherencia final: Diseñe aplicaciones para controlar escenarios de coherencia finales, ya que los cambios pueden tardar tiempo en propagarse en todas las regiones, en función de las condiciones de red y la distancia geográfica. Durante las interrupciones de la región, es posible que experimente más incoherencias de datos hasta que finalice la conectividad y finalice la sincronización.
Cost
Al configurar la replicación geográfica activa, paga por cada instancia de Azure Managed Redis en cada región del grupo de replicación. También puede incurrir en cargos de transferencia de datos para el tráfico de replicación entre regiones diferentes. Para más información, consulte Precios de Azure Managed Redis y Detalles de precios de ancho de banda.
Configuración de la compatibilidad con varias regiones
Cree una nueva instancia de caché con replicación geográfica. Configure la replicación geográfica activa al aprovisionar la memoria caché especificando un grupo de replicación y vinculando varias instancias. Para obtener más información, consulte Creación o unión de un grupo de replicación geográfica activa.
Agregue una instancia de caché existente a un grupo de replicación geográfica. Puede agregar una instancia de caché existente a un grupo de replicación geográfica activo.
Al agregar una instancia existente a un grupo de replicación geográfica activa, la plataforma debe borrar los datos de la instancia y experimentar una pequeña cantidad de tiempo de inactividad. Si es posible, planee configurar la replicación geográfica activa al crear instancias de caché.
Para obtener más información, consulte Incorporación de una instancia existente a un grupo de replicación geográfica activo.
Desactivar la replicación geográfica en una instancia de caché. Quite una instancia de un grupo de replicación geográfica mediante la eliminación de la instancia de caché. Las instancias restantes ajustan automáticamente su configuración.
Planeamiento y administración de capacidad
Durante un evento de región inactiva, las otras instancias pueden experimentar una mayor carga. Si una instancia se ejecuta a menudo cerca de sus límites de recursos y debe prepararse para aumentar los requisitos de capacidad durante un error de región, considere la posibilidad de sobreaprovisionar la instancia. Para más información, consulte Escalado de una instancia de Azure Managed Redis.
Comportamiento cuando todas las regiones están en buen estado
En esta sección se describe qué esperar al configurar instancias para usar la replicación geográfica activa y todas las regiones funcionan normalmente.
Enrutamiento del tráfico entre regiones: Es responsable de configurar las aplicaciones para conectarse a una instancia de caché específica. Las aplicaciones pueden conectarse a cualquier instancia de caché del grupo de replicación y realizar operaciones de lectura y escritura. La aplicación controla el enrutamiento de tráfico, lo que permite dirigir a los clientes a la región más cercana para una latencia mínima. Azure Managed Redis no enruta automáticamente el tráfico entre regiones.
Replicación de datos entre regiones: El servicio usa la replicación asincrónica entre regiones para mantener la coherencia final. Confirma inmediatamente las operaciones de escritura en la región local y, a continuación, las propaga a otras regiones en segundo plano. Los tipos de datos replicados sin conflictos (CRDT) garantizan que el servicio combina automáticamente escrituras simultáneas en diferentes regiones.
Comportamiento durante una falla de región
En esta sección se describe qué esperar al configurar instancias para usar la replicación geográfica activa y se produce una interrupción en una región.
Detección y respuesta: Eres responsable de detectar el fallo de una instancia de caché y decidir cuándo realizar una conmutación por error. Puede supervisar el estado de salud de un clúster con replicación geográfica, lo que puede ayudarle a decidir cuándo comenzar el proceso de failover. Para más información, consulte Métrica de replicación geográfica.
La conmutación por error requiere que realice varios pasos. Para obtener más información, consulte Cómo forzar la desvinculación durante una interrupción regional.
Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.
También puede supervisar la salud de cada instancia.
Para supervisar el estado de la relación de replicación geográfica, utilice la métrica estado saludable de replicación geográfica. La métrica siempre tiene un valor de
1(correcto) o0(incorrecto). Configure alertas de Azure Monitor en esta métrica para identificar cuándo las instancias podrían no estar sincronizadas.Solicitudes activas: El servicio finaliza las solicitudes a la región que ha fallado, y la lógica de conmutación de la aplicación debe controlarlas. Las aplicaciones deben implementar directivas de reintento que puedan redirigir el tráfico a cachés correctas.
Pérdida de datos esperada: La replicación asincrónica entre regiones puede resultar en la pérdida de escrituras recientes en la región fallida si esas escrituras no se han replicado en otras regiones. La cantidad de pérdida de datos potencial depende del retraso de replicación en el momento del error. Para obtener más información, consulte Redis distribuido geográficamente activo yconsideraciones sobre la coherencia y la pérdida de datos en un error regional de base de datos replicada (CRDB) sin conflictos.
Tiempo de inactividad esperado: Las aplicaciones experimentan tiempo de inactividad solo durante el tiempo necesario para detectar el error y redirigir el tráfico a regiones correctas. Este tiempo de inactividad suele oscilar entre segundos y unos minutos y depende de cómo configure la comprobación de estado y la configuración de conmutación por error de la aplicación.
Reenrutamiento del tráfico: Es responsable de implementar lógica en las aplicaciones para detectar errores de región y enrutar el tráfico a regiones correctas. Puede implementar esta lógica a través de comprobaciones de estado, patrones de disyuntor o soluciones de equilibrio de carga externas.
Recuperación de regiones
Cuando se recupera una región con errores, Azure Managed Redis reintegra automáticamente las instancias de esa región en el grupo de replicación geográfica activa sin su intervención. El servicio sincroniza automáticamente datos de instancias saludables. Durante este proceso, las instancias recuperadas sincronizan gradualmente los cambios que se produjeron durante la interrupción. Una vez finalizada la sincronización, las instancias recuperadas se vuelven totalmente activas y pueden controlar las operaciones de lectura y escritura.
Usted es responsable de volver a configurar su aplicación para enrutar el tráfico de regreso a la instancia de la región recuperada.
Prueba de fallos de región
Prueben periódicamente los procedimientos de conmutación por error de su aplicación. La aplicación debe poder conmutar por error entre instancias y cumplir los requisitos empresariales para el tiempo de inactividad durante la transición. Pruebe también los procesos de respuesta generales, incluida cualquier reconfiguración de firewalls y otras infraestructuras, y el proceso de recuperación.
Resistencia al mantenimiento del servicio
Azure Managed Redis controla las actualizaciones de servicio normales y otras tareas de mantenimiento.
Durante el mantenimiento, Azure Managed Redis crea automáticamente nuevos nodos y realiza una conmutación. Las aplicaciones cliente pueden experimentar interrupciones de conexión y otros errores transitorios. Las aplicaciones deben implementar lógica de reintento para controlar estas interrupciones temporales.
Para obtener más información sobre los procesos de mantenimiento de Azure Managed Redis, consulte Conmutación por error y aplicación de revisiones para Azure Managed Redis.
Copias de seguridad y restauración
Azure Managed Redis proporciona funcionalidades de persistencia y copia de seguridad de datos para protegerse frente a escenarios de pérdida de datos que podrían no abordar otras características de confiabilidad. Las copias de seguridad protegen frente a escenarios como daños en los datos, eliminación accidental o errores de configuración.
Persistencia de datos: De forma predeterminada, Azure Managed Redis almacena todos los datos de caché en memoria. Opcionalmente, el servicio puede escribir instantáneas de los datos en el disco mediante la persistencia de datos. Si un error de hardware afecta al nodo, Azure Managed Redis restaura automáticamente los datos. Puede elegir entre diferentes tipos de persistencia de datos, que proporcionan diferentes ventajas entre la frecuencia de instantánea y los efectos de rendimiento en la memoria caché.
No puede restaurar archivos de datos en otra instancia y no puede acceder a los archivos. La persistencia de datos no le protege de daños en los datos ni de la eliminación accidental.
Importación y exportación: Azure Managed Redis admite la copia de seguridad de los datos cuando se usa la funcionalidad de importación y exportación, que guarda los archivos de copia de seguridad en Azure Blob Storage. Puede configurar el almacenamiento con redundancia geográfica (GRS) en la cuenta de Azure Storage en regiones admitidas, o bien puede copiar o mover los blobs de copia de seguridad a otras ubicaciones para mayor protección.
Puede restaurar archivos exportados a la misma instancia de caché o a una instancia de caché diferente.
El servicio no incluye un programador de importación o exportación integrado, pero puede desarrollar sus propios procesos de automatización que usen la CLI de Azure o Azure PowerShell para iniciar operaciones de exportación.
Acuerdo de nivel de servicio
El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.
El Acuerdo de Nivel de Servicio para Azure Managed Redis cubre la conectividad con los puntos de conexión de caché. No cubre la protección contra la pérdida de datos.
Para ser apto para los SLA de disponibilidad para Azure Managed Redis, debe cumplir los siguientes requisitos:
Debe usar una configuración de alta disponibilidad.
No debe iniciar ninguna característica de producto ni acciones de administración documentadas para producir una falta de disponibilidad temporal.
Se aplican acuerdos de nivel de servicio (SLA) de mayor disponibilidad cuando la instancia tiene redundancia de zona. En algunos niveles, puede optar a un Acuerdo de Nivel de Servicio de mayor disponibilidad al implementar instancias con redundancia de zona en al menos tres regiones mediante la replicación geográfica activa.