Compartir vía

Conmutación por error y aplicación de revisiones para Azure Cache for Redis

  • Se aplica a: ✅ Azure Cache for Redis

Importante

Azure Cache for Redis anunció su cronograma de retiro para todos los SKU. Se recomienda mover las instancias existentes de Azure Cache for Redis a Azure Managed Redis tan pronto como pueda.

Para obtener más información sobre la retirada:

Para crear aplicaciones cliente resistentes y exitosas, es fundamental comprender la conmutación por error en el servicio Azure Cache for Redis. Una conmutación por error puede formar parte de las operaciones de administración planeadas o puede deberse a errores de red o hardware no planeados. Un uso habitual de la conmutación por error de la caché tiene lugar cuando el servicio de administración aplica parches a los archivos binarios de Azure Cache for Redis.

En este artículo encontrará esta información:

  • ¿Qué es una conmutación por error?
  • Cómo se produce una conmutación por error durante la aplicación de revisiones.
  • Creación de una aplicación cliente resistente.

¿Qué es una conmutación por error?

Comencemos con información general de la conmutación por error para Azure Cache for Redis.

Un resumen rápido de la arquitectura de caché

Una memoria caché se construye de varias máquinas virtuales con direcciones IP privadas y independientes. Cada máquina virtual, también conocida como nodo, está conectada a un equilibrador de carga compartido con una única dirección IP virtual. Cada nodo ejecuta el proceso de servidor de Redis y es accesible mediante el nombre de host y los puertos de Redis. Cada nodo se considera un nodo principal o de réplica. Cuando una aplicación cliente se conecta a una caché, su tráfico pasa por este equilibrador de carga y se enruta automáticamente al nodo principal.

En una caché básica, el único nodo siempre es un primario. En una caché Estándar o Premium, hay dos nodos: uno se elige como principal y el otro es la réplica. Dado que las cachés Estándar y Premium tienen varios nodos, es posible que un nodo no esté disponible mientras el otro sigue procesando las solicitudes. Las memorias caché en clúster se componen de muchas particiones, cada una con nodos principales y de réplica distintos. Una partición puede estar inactiva mientras que las demás siguen estando disponibles.

Nota:

Una caché básica no tiene varios nodos y no ofrece un contrato de nivel de servicio (SLA) para su disponibilidad. Las memorias caché básicas solo se recomiendan con fines de desarrollo y pruebas. Use una caché Estándar o Premium para una implementación de varios nodos para aumentar la disponibilidad.

Explicación de una conmutación por error

Una conmutación por error se produce cuando un nodo de réplica se promueve a sí mismo para convertirse en un nodo principal y el nodo principal anterior cierra las conexiones existentes. Cuando el nodo principal vuelve a estar disponible, observa el cambio en los roles y disminuye su nivel para convertirse en una réplica. A continuación, se conecta a la nueva principal y sincroniza los datos. Una conmutación por error puede ser planeada o no planeada.

Una conmutación por error planeada tiene lugar durante dos momentos diferentes:

  • Actualizaciones del sistema, como la aplicación de parches (Redis) o las actualizaciones del sistema operativo.
  • Operaciones de administración, como el escalado y el reinicio.

Dado que los nodos reciben un aviso previo de la actualización, pueden intercambiar roles de forma cooperativa y actualizar rápidamente el equilibrador de carga del cambio. Normalmente, una conmutación por error planeada finaliza en menos de 1 segundo.

Una conmutación por error no planeada puede producirse debido a errores de hardware, errores de red u otras interrupciones inesperadas en el nodo principal. El nodo de réplica se promueve a principal, pero el proceso tarda más tiempo. Un nodo de réplica primero debe detectar que su nodo principal no está disponible para poder iniciar el proceso de conmutación por error. El nodo de réplica también debe comprobar que este error no planeado no es transitorio o local, para evitar una conmutación por error innecesaria. Este retraso en la detección significa que una conmutación por error no planeada normalmente finaliza en un plazo de 10 a 15 segundos.

¿Cómo ocurre el parcheo?

El servicio Azure Cache for Redis actualiza periódicamente la memoria caché con las últimas características y correcciones de la plataforma. Para aplicar revisiones a una caché, el servicio sigue estos pasos:

  1. Primero, el servicio parchea el nodo de réplica.
  2. La réplica revisada se promueve de forma cooperativa a la principal. Esta promoción se considera una conmutación por error planeada.
  3. El nodo principal anterior se reinicia para tomar los nuevos cambios y vuelve a crearse como un nodo de réplica.
  4. El nodo de réplica se conecta al nodo principal y sincroniza los datos.
  5. Una vez completada la sincronización de datos, el proceso de aplicación de revisiones se repite para los nodos restantes.

Como la aplicación de la revisión es una conmutación por error planeada, el nodo réplica se promueve rápidamente para convertirse en principal. A continuación, el nodo comienza a atender las solicitudes y las nuevas conexiones. Las memorias caché básicas no tienen un nodo de réplica y no están disponibles hasta que se complete la actualización. Cada fragmento de una caché agrupada se actualiza por separado y no cierra las conexiones a otro fragmento.

Importante

Los nodos se revisan de uno en uno para evitar la pérdida de datos. Las memorias caché básicas tendrán pérdida de datos. En las cachés en clúster, la aplicación de la revisión se realiza en una partición a la vez.

Cuando hay varias cachés en el mismo grupo de recursos o en la misma región, la aplicación de la revisión también se realiza en una partición a la vez. Las memorias caché que se encuentran en diferentes grupos de recursos o regiones diferentes se pueden parchear simultáneamente.

Dado que la sincronización de datos completa se produce antes de que se repita el proceso, es poco probable que se produzca una pérdida de datos cuando se usa una caché Estándar o Premium. Puede protegerse aún más contra la pérdida de datos exportando datos y habilitando la persistencia.

Carga de caché adicional

Cada vez que se produce una conmutación por error, las memorias caché Estándar y Premium deben replicar datos de un nodo a otro. Esta replicación provoca un aumento de la carga tanto en la memoria del servidor como en la CPU. Si la instancia de caché ya está muy cargada, es posible que las aplicaciones cliente experimenten una mayor latencia. En casos extremos, las aplicaciones cliente pueden recibir excepciones de tiempo de espera. Para ayudar a mitigar el efecto de más carga, configure la configuración de maxmemory-reserved la memoria caché.

¿Cómo afecta una conmutación por error a mi aplicación cliente?

Las aplicaciones cliente podrían recibir algunos errores de Azure Cache para Redis. El número de errores detectados por una aplicación cliente depende del número de operaciones pendientes de esa conexión en el momento de la conmutación por error. Cualquier conexión enrutada a través del nodo que cerró sus conexiones experimenta errores.

Muchas bibliotecas cliente pueden producir diferentes tipos de errores cuando se interrumpen las conexiones, entre las que se incluyen:

  • Excepciones de tiempo de espera
  • Excepciones de conexión
  • Excepciones de socket

El número y el tipo de excepciones depende de dónde se encuentra la solicitud en la ruta de acceso del código cuando la memoria caché cierra sus conexiones. Por ejemplo, una operación que envía una solicitud pero que no ha recibido una respuesta cuando se produce la conmutación por error puede obtener una excepción de tiempo de espera. Las nuevas solicitudes del objeto de conexión cerrado reciben excepciones de conexión hasta que la reconexión se produce correctamente.

La mayoría de las bibliotecas cliente intentan volver a conectarse a la memoria caché si están configuradas para hacerlo. Sin embargo, los errores imprevistos pueden colocar ocasionalmente los objetos de biblioteca en un estado irrecuperable. Si los errores persisten durante más tiempo que un período de tiempo preconfigurado, se debe volver a crear el objeto de conexión. En Microsoft.NET y otros lenguajes orientados a objetos, se puede volver a crear la conexión sin reiniciar la aplicación mediante un patrón ForceReconnect.

¿Puedo recibir una notificación por adelantado del mantenimiento?

Azure Cache for Redis publica notificaciones de mantenimiento en tiempo de ejecución en un canal de publicación/suscripción (pub/sub) denominado AzureRedisEvents. Muchas bibliotecas cliente populares de Redis admiten la suscripción a canales pub/sub. La recepción de notificaciones del AzureRedisEvents canal suele ser una adición sencilla a la aplicación cliente. Para más información sobre los eventos de mantenimiento, consulte AzureRedisEvents.

Nota:

El AzureRedisEvents canal no es un mecanismo que puede notificarle días o horas de antelación. El canal puede notificar a los clientes cualquier próximo evento de mantenimiento del servidor que pueda afectar a la disponibilidad del servidor. AzureRedisEvents solo está disponible para los niveles Básico, Estándar y Premium.

¿Cuáles son las actualizaciones incluidas en mantenimiento?

El mantenimiento incluye estas actualizaciones:

  • Actualizaciones del servidor de Redis: cualquier actualización o revisión de los archivos binarios del servidor de Redis.
  • Actualizaciones de la máquina virtual: las actualizaciones de la máquina virtual que hospedan el servicio Redis. Las actualizaciones de las VM incluyen la aplicación de parches a componentes de software en el entorno de hospedaje, la actualización de componentes de red o su desmantelamiento.

¿Aparece el mantenimiento en el estado de salud del servicio en el portal de Azure antes de un parche?

No, el mantenimiento no aparece en ningún lugar en el estado del servicio en el portal ni en ningún otro lugar.

¿Cuánto tiempo puedo obtener la notificación antes del mantenimiento planeado?

Al usar el AzureRedisEvents canal, se le notificará 15 minutos antes del mantenimiento.

Cambios en la configuración de red del cliente

Algunos cambios en la configuración de red del lado cliente pueden desencadenar errores de conexión no disponible. Estos cambios pueden incluir:

  • Intercambio de la dirección IP virtual de una aplicación cliente entre ranuras de ensayo y producción.
  • Escalado del tamaño o número de instancias de la aplicación.

Estos cambios pueden provocar un problema de conectividad que suele durar menos de un minuto. Es probable que la aplicación cliente pierda su conexión a otros recursos de red externos, pero también al servicio Azure Cache for Redis.

Creación de resistencia

Es imposible evitar por completo las conmutaciones por error. En su lugar, escriba las aplicaciones cliente para que sean resistentes a las interrupciones de conexión y las solicitudes fallidas. La mayoría de las bibliotecas cliente se vuelven a conectar automáticamente al punto de conexión de caché, pero pocas de ellas intentan volver a intentar las solicitudes fallidas. En función del escenario de la aplicación, es posible que la lógica de reintento con retroceso tenga sentido.

¿Cómo puedo hacer que mi aplicación sea resistente?

Consulte estos patrones de diseño para crear clientes resistentes, sobre todo los patrones de reintento e interruptores:

Para probar la resiliencia de una aplicación cliente, use un reinicio como desencadenador manual para las interrupciones de conexión.

Además, se recomienda usar actualizaciones programadas para elegir un canal de actualización y una ventana de mantenimiento para que la memoria caché aplique revisiones en tiempo de ejecución de Redis durante ventanas semanales específicas. Estas ventanas suelen ser períodos en los que el tráfico de la aplicación cliente es bajo, para evitar posibles incidentes. Para obtener más información, consulte Actualizar canal y Programar actualizaciones.

Para más información, consulte Resistencia de la conexión.

Contenido relacionado

  • Last updated on