¿Qué son la conmutación por error y la conmutación por recuperación?

En este artículo se proporciona información general sobre cómo funcionan la conmutación por error y la conmutación por recuperación en un entorno de nube. Sin embargo, para comprender la conmutación por error, primero debe comprender la redundancia y la replicación. Para obtener información sobre esos conceptos antes de continuar con este artículo, consulte Redundancia, replicación y copia de seguridad.

Una razón habitual para mantener copias redundantes tanto de las aplicaciones como de las réplicas de datos es poder llevar a cabo una conmutación por error. Con la conmutación por error, puede redirigir el tráfico y las solicitudes de las instancias en estado incorrecto a instancias en estado correcto. A continuación, una vez que las instancias originales vuelvan a estar en buen estado de salud, puede realizar un retorno para volver a la configuración original.

Roles de instancia activos y pasivos

En el contexto de la conmutación por error, una instancia puede ser un único componente, como una base de datos o una colección de varios componentes que componen una implementación de servicio en una región. En una solución completa, puede conmutar por error diferentes partes de esa solución de maneras diferentes y en situaciones diferentes.

Un componente, o una colección de componentes configurados para la conmutación por error y la conmutación por recuperación, requiere varias instancias. Cada una de esas instancias asume un rol determinado:

• Las instancias principales o activas funcionan activamente, como atender las solicitudes entrantes de los clientes. Normalmente, hay solo una instancia principal a la vez.
• Las instancias secundarias o pasivas están inactivas, pero están listas para cambiarse para convertirse en la principal si es necesario. Puede haber varias instancias secundarias.

Hay varias maneras de configurar instancias pasivas. Cada manera implica inconvenientes entre el tiempo de recuperación y otros factores, como el costo y la complejidad operativa:

• Sistemas de respaldo en caliente, diseñados para estar listos para aceptar el tráfico de producción en cualquier momento.
• Esperas activas, diseñadas para estar casi preparadas para aceptar el tráfico de producción, pero esto puede requerir algunos cambios de configuración o operaciones de escalado para completarse antes de que puedan aceptar el tráfico.
• Las esperas ligeras piloto, que se implementan parcialmente en una configuración mínima, y requieren que se complete una preparación significativa antes de que puedan aceptar el tráfico de producción.
• Soportes fríos, que podrían no implementarse en absoluto, y confían en que los componentes se desplieguen antes de que puedan aceptar el tráfico de producción.

Sugerencia

Algunas soluciones se crean para usar un enfoque activo-activo, lo que significa que varias instancias atienden las solicitudes. Un sistema activo-activo no requiere conmutación por error, ya que todas las instancias atienden activamente las solicitudes en todo momento.

Ámbitos de conmutación por error

Las diferentes situaciones requieren estrategias de conmutación por error diferentes. Para ilustrar estas estrategias posibles, considere una solución de ejemplo que consta de una aplicación que accede a los datos de una base de datos. Configura la solución para la conmutación por error creando copias redundantes de tu servidor de aplicaciones y múltiples réplicas de la base de datos. A continuación, configure:

• Redundancia de zona colocando copias y réplicas en diferentes zonas de disponibilidad dentro de una región de Azure.
• Redundancia geográfica mediante un equilibrador de carga global para el cambio automático entre regiones.

Este es un diagrama simplificado que ilustra la arquitectura general en operaciones normales:

Diferentes situaciones pueden desencadenar eventos de conmutación por error diferentes en esta solución. Cada uno de ellos corresponde a un ámbito de conmutación por error, que representa la granularidad de los componentes que conmutan por error:

• Es posible que se produzca una conmutación por error de réplica de base de datos cuando la réplica de base de datos activa deje de estar disponible. La réplica pasiva se promueve para convertirse en la réplica activa. Normalmente, las aplicaciones pueden volver a enrutar rápidamente sus solicitudes a la nueva réplica activa:

  

• Una conmutación por error de zona de disponibilidad puede producirse si una zona de disponibilidad en su totalidad experimenta una interrupción. Este tipo de interrupción requiere que todo el tráfico se enrute al servidor web de la zona restante y también garantiza que la réplica de base de datos de la zona sobreviviente se convierta en la réplica activa si aún no lo es.

  

• Es posible que se produzca una conmutación por error de región si se produce una pérdida grave de toda la región primaria de Azure.

  

Aunque cada uno de estos ámbitos proporciona un tipo de conmutación por error, es posible que tengan distintos requisitos y procesos de conmutación por error. Además, Microsoft puede ser responsable de algunos ámbitos de conmutación por error, como cuando se usan servicios con redundancia de zona, mientras que es posible que sea responsable de la conmutación por error en ámbitos más amplios, como la conmutación por error entre regiones de Azure.

Planeación de la conmutación por error y continuidad empresarial

Una parte del plan de continuidad empresarial es diseñar sus estrategias de failover, que incluyen los diferentes ámbitos en los que puede realizar la conmutación.

Por lo general, los planes de continuidad empresarial deben incluir procedimientos de conmutación por error automatizados dentro o entre zonas de disponibilidad. Este tipo de conmutación por error forma parte de la estrategia de alta disponibilidad. Por ejemplo, si se produce un error en la réplica activa de una base de datos, un proceso automatizado puede promover una réplica pasiva para convertirse en la réplica activa. A continuación, los servidores web se comunican con la nueva réplica activa. De forma similar, si se produce un error en una zona de disponibilidad, muchas soluciones se compilan para recuperarse automáticamente mediante el uso de las zonas restantes.

Se emplean diferentes procedimientos de conmutación por error para escenarios de desastres, como en el poco probable caso de una interrupción total de la región. En el caso de una interrupción de región, puede redirigir las solicitudes web entrantes para utilizar una segunda región, así como desencadenar una conmutación por error de la base de datos a una réplica en la región secundaria.

Tenga en cuenta que, al incluir procedimientos de conmutación por error en el planeamiento de continuidad empresarial, es necesario realizar pruebas y diseño más detallados. Para obtener más información, consulte ¿Qué son la continuidad empresarial, la alta disponibilidad y la recuperación ante desastres?.

Conmutaciones por error planeadas y no planeadas

Las conmutaciones por error no planeadas son aquellas que se realizan durante una interrupción de un componente, de modo que pueda restaurar el servicio mediante otra instancia. Las conmutaciones por error no planeadas a veces producen tiempo de inactividad o pérdida de datos, en función de cómo se diseñe una solución. Las conmutaciones por error no planeadas requieren algo para detectar el error y tomar una decisión sobre cuándo desencadenar la conmutación por error.

En cambio, las conmutaciones por error planeadas son las que se desencadenan de forma proactiva. En previsión de que ocurra algo, como cuando una máquina virtual va a ser parcheada y reiniciada. Las conmutaciones por error planeadas pueden tener una tolerancia menor para el tiempo de inactividad y la pérdida de datos, ya que forman parte de los procedimientos de mantenimiento normales.

Cómo funciona la conmutación por error

Por lo general, el proceso de conmutación por error involucra los siguientes pasos, que se pueden realizar manualmente o mediante un sistema automatizado. Los detalles específicos de cada uno de estos pasos dependen del sistema concreto.

1. Detectar un error (solo conmutaciones por error no planeadas). Una conmutación por error automatizada requiere que algo detecte cuándo una instancia no está disponible, que normalmente se basa en algún tipo de comprobación de estado. Los diferentes servicios definen su estado de maneras diferentes. Por ejemplo, algunos servicios envían eventos heartbeat de forma proactiva entre instancias. Otros requieren un componente independiente para sondear cada instancia a intervalos regulares. A menudo se tarda algún tiempo en que los monitores de estado detecten un error en una instancia y a menudo es importante proporcionar un período de gracia en caso de que la instancia simplemente estaba ocupada y no pudo responder.

2. Elija la conmutación por fallo. En algún momento, se tomará la decisión de realizar una conmutación por error. Una herramienta automatizada podría tomar la decisión o manualmente. La tolerancia al riesgo de su organización puede afectar a la rapidez con la que se toma esta decisión. Si tiene una tolerancia baja al riesgo, puede optar por cambiar a modo de reserva rápidamente ante cualquier indicio de problema. Si tiene una mayor tolerancia al riesgo, puede optar por esperar para ver si el problema se puede resolver antes de realizar un traspaso.

3. Seleccione una nueva instancia principal. Una de las instancias restantes debe convertirse en la nueva primaria.

   En algunas situaciones, es posible que tenga predefinida qué instancia debería convertirse en la nueva principal o que solo disponga de una instancia para cambiar.

   En otras situaciones, hay un proceso automatizado por el que el sistema selecciona una nueva instancia principal. Hay varios algoritmos de consenso que se usan en la computación distribuida, incluido para las elecciones de líderes. Estos algoritmos se implementan dentro de los servicios pertinentes, como las bases de datos. En algunos sistemas, es importante que cada instancia sea informada de la nueva réplica principal, por lo que los resultados de la selección se anuncian automáticamente a cada réplica.

4. Solicitudes de redirección. Configure el entorno para que las solicitudes se dirijan a las instancias correctas o a la nueva instancia principal.

   Para lograr esto, es posible que tenga que actualizar otros sistemas para que sepan dónde enviar solicitudes. Esto puede implicar la actualización de un sistema de equilibrio de carga para excluir la instancia incorrecta. En otras situaciones, el sistema de nombres de dominio (DNS) se usa normalmente como una manera de enviar solicitudes a una instancia activa de un sistema. Como parte del proceso de conmutación por error, normalmente debe actualizar los registros DNS para que las solicitudes se enruten a la nueva instancia principal. DNS tiene el concepto de tiempo de vida (TTL), que indica a los clientes con qué frecuencia deben comprobar los registros DNS actualizados. Si el TTL se establece en un valor largo, los clientes pueden tardar tiempo en recibir información sobre la conmutación por error y puede que sigan enviando solicitudes a la principal anterior.

Dado que los procesos de conmutación por error pueden incluir retrasos, es importante planear los procedimientos de conmutación por error para cumplir los requisitos de tiempo de inactividad (objetivo de punto de recuperación o RTO) y pérdida de datos (objetivo de punto de recuperación o RPO). Para más información, consulte ¿Qué son la continuidad empresarial, la alta disponibilidad y la recuperación ante desastres?.

Failback

Recuperación es el proceso de reestablecer y redirigir el tráfico de nuevo a la instancia principal original.

En algunas situaciones, no es necesario realizar la recuperación en absoluto porque cada instancia es igualmente capaz de actuar como primaria. Sin embargo, hay algunas situaciones en las que es importante revertir, por ejemplo, cuando necesita ejecutar las aplicaciones desde una región de Azure determinada y ha conmutado temporalmente a otra región durante una interrupción regional.

A veces, la conmutación por recuperación se controla de la misma manera que una conmutación por error. Sin embargo, el retorno también puede ser más complejo que la conmutación por error, por varias razones:

• Problemas de sincronización de datos. Durante, e incluso después, una conmutación por error normal, es posible que la instancia principal anterior haya realizado algún trabajo o haya escrito algunos datos en un almacén de datos. Parte del proceso de retorno consiste en garantizar la coherencia y la integridad de los datos en toda su solución, incluida la administración de conflictos o duplicaciones entre las instancias principales y secundarias.

  Es habitual que los problemas de sincronización de datos requieran intervención manual. Si no necesita los datos en conflicto, puede optar por restablecer la base de datos u otro estado.

• Pasos de corrección. Si se intentaron pasos de remediación en la principal antes de que se produjera la conmutación por error, podrían haber dejado la instancia principal en un estado desconocido.

  Si existe un riesgo de que la instancia principal esté en un estado incoherente, es posible que tenga que destruir y volver a implementar la instancia principal para que esté en un estado correcto conocido antes de realizar la conmutación por recuperación.

• Tiempo de inactividad adicional. El tiempo de inactividad durante el proceso de conmutación por recuperación puede ser mayor que durante una conmutación por error debido a reconfiguraciones necesarias o operaciones para restaurar la coherencia de los datos.

  Puede mitigar este problema ejecutando procesos de retorno durante una ventana de mantenimiento o informando a los usuarios sobre el cambio con anticipación. Además, es posible que pueda realizar algunas de las operaciones preparatorias mientras el sistema está en línea y minimizar el tiempo de inactividad necesario.

• Tolerancia al riesgo. Si se produjo la conmutación por error debido a una interrupción, la tolerancia de la organización al tiempo de inactividad u otros riesgos durante la conmutación por recuperación puede ser menor.

  Las partes interesadas de la empresa deben mantenerse informados de la situación durante todo el proceso, y deben hacerse plenamente conscientes de la necesidad de la conmutación por recuperación y las consecuencias de los procedimientos de conmutación por recuperación. Es posible que pueda negociar un momento adecuado para realizar los cambios.

Conmutación por error y conmutación por recuperación en los servicios de Azure

Aunque es importante comprender cómo funciona la conmutación por error en general, tenga en cuenta que cada servicio de Azure puede abordar la conmutación por error y la conmutación por recuperación de forma diferente. Para obtener información sobre cómo funcionan los servicios específicos de Azure desde una perspectiva de confiabilidad, consulte la guía de confiabilidad de cada servicio.

Muchos servicios de Azure controlan determinados tipos de conmutación por error automáticamente. Por ejemplo, cuando se usan servicios de Azure configurados para que sean con redundancia de zona, Microsoft realiza automáticamente la conmutación por error entre zonas de disponibilidad. Para más información, consulte ¿Qué son las zonas de disponibilidad? y las guías de confiabilidad del servicio de Azure.

Si usa máquinas virtuales, Azure Site Recovery replica máquinas virtuales y sus discos entre zonas de disponibilidad o en otra región de Azure, y puede realizar la conmutación por error por usted.

Al diseñar su propia solución que combina varios servicios de Azure juntos, es posible que los requisitos de conmutación por error se vuelvan más complejos. Supongamos que va a diseñar una solución con un nivel de aplicación y una base de datos, y quiere crear una arquitectura activa/pasiva de varias regiones. Durante una interrupción en la región primaria, es importante que tanto la aplicación como la base de datos realicen una conmutación por error hacia la región secundaria. En función de los servicios exactos que use, es posible que deba planear su propia estrategia de conmutación por error para cambiar entre los despliegues de cada región. Azure proporciona enrutamiento de tráfico global y equilibrio de carga a través de Azure Front Door y Azure Traffic Manager, y puede seleccionar la tecnología que cumple los requisitos de conmutación por error. Cada servicio admite la supervisión del estado de cada instancia regional de la aplicación y puede configurarlo para volver a enrutar automáticamente el tráfico a la instancia correcta.

Pasos siguientes

• Obtenga información sobre la responsabilidad compartida de confiabilidad.
• Obtenga información sobre las recomendaciones para el diseño de varias regiones de alta disponibilidad en Azure Well-Architected Framework.