Confiabilidad en Azure Managed Redis

Azure Managed Redis proporciona Redis Enterprise totalmente integrado y administrado en Azure, que ofrece almacenamiento de datos en memoria de alto rendimiento para aplicaciones. Este servicio se crea 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 la confiabilidad en Azure Managed Redis, incluida la resistencia a errores transitorios, errores de zona de disponibilidad y errores en toda la región. En el artículo 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:

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.

Implemente una instancia de Azure Managed Redis, que también se denomina instancia de caché o caché. Las aplicaciones cliente almacenan e interactúan con los datos de la caché mediante las API de Redis.

Arquitectura física

Hay dos conceptos clave que debe comprender al planear la resistencia para Azure Managed Redis: nodos y 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 administra automáticamente la creación de instancias, la supervisión del estado y la sustitución de instancias incorrectas. El conjunto de máquinas virtuales, tomadas juntas, también se denomina clúster.

  Puede configurar la instancia para lograr una alta disponibilidad. Al hacerlo, Azure Managed Redis garantiza que haya al menos dos nodos y replica automáticamente los datos entre los nodos. En regiones con zonas de disponibilidad, los nodos se colocan 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 usados en cada configuración para evitar la complejidad y garantizar las configuraciones óptimas.

• Particiones: Cada nodo ejecuta varios procesos de servidor de Redis denominados particiones, que administran un subconjunto de los datos de la caché. Cuando la memoria caché está configurada para alta disponibilidad, las particiones se distribuyen y replican automáticamente entre nodos. Especifique una directiva de clúster, que determina cómo se distribuyen las particiones entre 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 reintenten automáticamente cuando se produzcan errores transitorios y que usen los períodos de tiempo de espera y de retroceso 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é en los que la aplicación pueda seguir funcionando con un rendimiento degradado cuando Redis no está disponible temporalmente al revertir al almacén de datos principal.

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.

Las instancias de Azure Managed Redis Cache se pueden hacer con redundancia de zona, lo 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 interrupciones de la zona de disponibilidad o del centro de datos, lo que hace que la memoria caché no esté disponible.

Para que una zona de caché tenga redundancia, debe implementarla en una región admitida y habilitar 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 están 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: Las cachés de Azure Managed Redis con redundancia de zona se pueden implementar en cualquier región que admita zonas de disponibilidad y donde el servicio esté disponible. Para obtener la lista más reciente 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 habilitar la configuración de alta disponibilidad en la memoria caché para que sea con redundancia de zona.

• Niveles: Todos los niveles de Redis administrados de Azure admiten zonas de disponibilidad.

Cost

La redundancia de zona requiere que la memoria caché esté configurada para alta disponibilidad, lo que implementa un mínimo de dos nodos para la memoria caché. La configuración de alta disponibilidad se factura a una tarifa más alta que la 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, habilite la configuración de alta disponibilidad e impleméntela en una región con zonas de disponibilidad. A continuación, incluye automáticamente la redundancia de zona de forma predeterminada. No es necesario realizar más configuraciones.

  Para ver los pasos detallados, consulte Inicio rápido: Creación de una instancia de Redis administrada de Azure.

• Habilite la redundancia de zona en una instancia existente: Para configurar una instancia de Azure Managed Redis existente para que sea con redundancia de zona, asegúrese de que se implementa en una región que admita zonas de disponibilidad y habilite la alta disponibilidad en la memoria caché.

• Deshabilitar la redundancia de zona: No se puede deshabilitar la redundancia de zona en instancias existentes, ya que no se puede deshabilitar la alta disponibilidad una vez habilitada en una instancia de 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 suele estar bajo presión de recursos y necesita prepararse para errores de zona de disponibilidad, tenga en cuenta uno de los enfoques siguientes:

• Sobreaprovisionamiento de la instancia: El aprovisionamiento excesivo implica seleccionar un nivel de rendimiento superior al que podría necesitar. Permite a la instancia tolerar cierta pérdida de capacidad y seguir funcionando sin degradar el rendimiento. Para obtener más información sobre el principio de sobreaprovisionamiento, consulte Administración de la capacidad mediante el sobreaprovisionamiento. Para obtener información sobre cómo escalar la instancia, consulte 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 están operativas:

• Enrutamiento de tráfico entre zonas: Los fragmentos se distribuyen entre nodos en función de la política 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 cómo se enruta el tráfico.

• Replicación de datos entre zonas: Las particiones se replican entre nodos automáticamente y usan la replicación asincrónica. Normalmente, el retraso de replicación entre particiones se mide en segundos, pero esto puede variar en función de la carga de trabajo de la caché, con escenarios de escritura intensiva y de red que suelen ver un retraso de replicación mayor.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando una caché administrada de Redis es con redundancia 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: Es posible que las solicitudes en vuelo sean descartadas y deben ser reintentadas. 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, la cantidad de pérdida de datos se mide 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 hagan el failover a los nodos en zonas saludables. Para obtener 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 las prácticas 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

Dado que Azure Managed Redis administra completamente el enrutamiento del tráfico, la conmutación por error y la recuperación de error para las fallas de zona, no es necesario validar los procesos de fallo de zonas de disponibilidad ni proporcionar ninguna entrada adicional.

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, lo que permite vincular varias instancias de Azure Managed Redis entre diferentes regiones de Azure en un único grupo de replicación. Después, puede configurar su propio método 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 diferentes regiones, 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, con aplicaciones cliente que se conectan a cada instancia de caché:

Es responsable de configurar las aplicaciones cliente para que, si se produce un error en alguna instancia regional, pueden redirigir sus solicitudes a una instancia correcta. En el diagrama siguiente se muestra cómo una aplicación puede redirigir sus solicitudes a una instancia de caché correcta cuando normalmente se produce un error en la instancia que usan:

Requisitos

• Compatibilidad con regiones La replicación geográfica activa de Azure Managed Redis se puede configurar 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 del mismo nivel y tamaño en todas las regiones participantes. Todas las instancias de caché de un grupo de replicación deben configurarse con valores idénticos, 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 usa, y afecta a cómo se pueden 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é. Debe preparar y configurar su aplicación para gestionar la conmutación por error. La conmutación por error implica la preparación y puede requerir que complete varios pasos. Para obtener más información, consulte Desvincular en caso de interrupción en la región.

• Coherencia final: Las aplicaciones deben diseñarse para controlar los escenarios de coherencia final, 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, puede experimentar más incoherencias de datos hasta que se restaure la conectividad y se complete la sincronización.

Cost

Al habilitar la replicación geográfica activa, se le factura cada instancia de Azure Managed Redis en cada región del grupo de replicación. Además, puede incurrir en cargos de transferencia de datos para el tráfico de replicación entre regiones. Para más información sobre los precios, 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 durante el aprovisionamiento de 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.

• Habilitar una instancia de caché existente para la replicación geográfica: puede agregar una instancia de caché existente a un grupo de replicación geográfica activo.

  Sin embargo, cuando se agrega una instancia existente a un grupo de replicación geográfica activa, los datos de la instancia deben vaciarse y hay una pequeña cantidad de tiempo de inactividad. Si es posible, planee habilitar 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.

• Deshabilitar 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 se vuelven a configurar automáticamente.

Planeamiento y administración de capacidad

Durante un evento de caída de la región, las otras instancias podrían estar bajo mayor presión. Si una instancia suele estar bajo presión de recursos y necesita prepararse para aumentar los requisitos de capacidad durante un error de región, considere la posibilidad de sobreaprovisionar la instancia. Para obtener información sobre cómo escalar una instancia, 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 cuando las instancias están configuradas para usar la replicación geográfica activa y todas las regiones están operativas.

• Enrutamiento de 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 proporciona enrutamiento automático del 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. Las operaciones de escritura se confirman inmediatamente en la región local y, a continuación, se propagan a otras regiones en segundo plano. Los tipos de datos replicados sin conflictos (CRDT) garantizan que las escrituras simultáneas en diferentes regiones se combinen automáticamente.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando las instancias están configuradas para usar la replicación geográfica activa y hay una interrupción en una región:

• Detección y respuesta: es responsable de detectar el fallo de una instancia de caché y decidir cuándo conmutar. Puede monitorear el estado de un clúster con replicación geográfica, lo que puede ayudarle a decidir cuándo iniciar la conmutación por error. Para más información, consulte Métrica de replicación geográfica.

  La conmutación por error requiere realizar varios pasos. Para obtener más información, consulte Desvincular forzosamente si hay una interrupción de región.

• 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, puede usar la métrica Salud de la replicación geográfica. La métrica siempre tiene un valor de 1 (correcto) o 0 (incorrecto). Puede configurar alertas de Azure Monitor en esta métrica para comprender cuándo las instancias podrían no estar sincronizadas.

• Solicitudes activas: las solicitudes a la región con errores se finalizan y se deben controlar mediante la lógica de conmutación por error de la aplicación. Las aplicaciones deben implementar directivas de reintento que puedan redirigir el tráfico a cachés correctas.

• Pérdida de datos esperada: debido a la replicación asincrónica entre regiones, es posible que algunas escrituras recientes en la región con errores se pierdan si aún 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 Active-Active Redis distribuido geográficamente y Consideraciones sobre la coherencia y la pérdida de datos en un error regional de CRDB.

• Tiempo de inactividad esperado: las aplicaciones experimentan tiempo de inactividad solo durante la duración necesaria para detectar el error y redirigir el tráfico a regiones correctas. Esto suele oscilar entre segundos y unos minutos, en función de cómo haya configurado la comprobación de estado y la configuración de conmutación por error de la aplicación.

• Enrutamiento de tráfico: es responsable de implementar la lógica en las aplicaciones para detectar errores de región y enrutar el tráfico a regiones correctas. Esto se puede lograr mediante comprobaciones de estado, patrones de interruptor de circuito o soluciones externas de equilibrio de carga.

Recuperación de regiones

Cuando una región que ha fallado se recupera, Azure Managed Redis reintegra automáticamente las instancias de esa región en el grupo de replicación geográfica activa sin necesidad de la intervención. El servicio sincroniza automáticamente los datos de las instancias saludables. Durante este proceso, la instancia recuperada se ocupa gradualmente de los cambios que se produjeron durante la interrupción. Una vez completada 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

Debes probar periódicamente los procedimientos de conmutación por error de la aplicación. Es importante que tu aplicación pueda realizar conmutación por error entre instancias y que cumpla con los requisitos de la empresa para el tiempo de inactividad durante este proceso. También es importante que pruebe los procesos generales de respuesta, incluida cualquier reconfiguración de firewalls y otra infraestructura, y el proceso de recuperación.

Resistencia al mantenimiento del servicio

Azure Managed Redis realiza actualizaciones de servicio periódicas y otras tareas de mantenimiento.

Cuando el mantenimiento está en curso, Azure Managed Redis realiza automáticamente la creación de nuevos nodos y realiza la conmutación por error automáticamente. Es posible que las aplicaciones cliente vean 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 pueden no abordar otras características de confiabilidad. Las copias de seguridad pueden proporcionar protección 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. Puede escribir instantáneas de sus datos en el disco opcionalmente mediante la persistencia de datos. Si se produce un error de hardware que afecta al nodo, Azure Managed Redis restaura automáticamente los datos. Hay diferentes tipos de persistencia de datos entre los que puede elegir, que ofrecen diferentes compromisos entre la frecuencia de las instantáneas y los efectos sobre el rendimiento de su memoria caché.

  Sin embargo, los archivos de datos no se pueden restaurar en otra instancia y no se puede acceder a los archivos. La persistencia de datos no le protege frente a daños en los datos ni a la eliminación accidental.

• Importación y exportación: Azure Managed Redis admite la copia de seguridad de los datos mediante 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 en la cuenta de Azure Storage, o bien puede copiar o mover los blobs de copia de seguridad a otras ubicaciones para mayor protección.

  Los archivos exportados se pueden restaurar en la misma instancia de caché o en una instancia de caché diferente.

  No hay ningún 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é. El Acuerdo de Nivel de Servicio no cubre la protección frente a la pérdida de datos.

Para ser elegible para las SLA de disponibilidad de Azure Managed Redis:

• Debe habilitar la 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 de mayor disponibilidad cuando la instancia tiene redundancia de zona. En algunos niveles, puede ser apto para un Acuerdo de Nivel de Servicio de mayor disponibilidad cuando haya implementado instancias con redundancia de zona en al menos tres regiones mediante la replicación geográfica activa.