Hacer que todo sea redundante

Creación de redundancia en la aplicación, para evitar tener puntos únicos de error

Las aplicaciones resistentes esquivan los errores al enrutar. Identifique las rutas críticas de la aplicación. ¿Hay redundancia en cada punto de la ruta de acceso? Si se produce un error en un subsistema, ¿la aplicación realizará una conmutación por error?

Recomendaciones

Considere los requisitos empresariales. La cantidad de redundancia integrada en un sistema puede afectar tanto al costo como a la complejidad. Los requisitos empresariales deben informar a la arquitectura, como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). También debe tener en cuenta los requisitos de rendimiento y la capacidad de su equipo para administrar conjuntos complejos de recursos.

Considere la posibilidad de arquitecturas de varias zonas y de varias regiones. Asegúrese de comprender cómo las zonas y regiones de disponibilidad proporcionan resistencia y diferentes conjuntos de inconvenientes arquitectónicos.

Las zonas de disponibilidad de Azure son conjuntos aislados de centros de datos dentro de una región. Mediante el uso de zonas de disponibilidad, puede ser resistente a errores de un único centro de datos o de una zona de disponibilidad completa. Puede usar zonas de disponibilidad para compensar los costos, la mitigación de riesgos, el rendimiento y la capacidad de recuperación. Por ejemplo, cuando se usan servicios con redundancia de zona en la arquitectura, Azure proporciona replicación automática de datos y conmutación por error entre instancias separadas geográficamente, lo que mitiga muchos tipos diferentes de riesgos.

Si tiene una carga de trabajo crítica y necesita mitigar el riesgo de una interrupción en toda la región, considere la posibilidad de realizar una implementación de varias regiones. Aunque las implementaciones de varias regiones le aíslan contra desastres regionales, tienen un costo. Las implementaciones de varias regiones son más costosas que una implementación de una sola región y son más complicadas de administrar. Necesitará procedimientos operativos para controlar la conmutación por error y la conmutación por recuperación. En función de los requisitos de RPO, es posible que tenga que aceptar un rendimiento ligeramente menor para habilitar la replicación de datos entre regiones. El coste adicional y la complejidad podrían estar justificados para algunos escenarios empresariales.

Sugerencia

Para muchas cargas de trabajo, una arquitectura con redundancia de zona proporciona el mejor conjunto de inconvenientes. Considere una arquitectura de varias regiones si sus requisitos empresariales indican que necesita mitigar el riesgo poco probable de una interrupción en toda la región y si está preparado para aceptar los inconvenientes implicados en este enfoque.

Para más información sobre cómo diseñar la solución para usar regiones y zonas de disponibilidad, vea Recomendaciones para usar zonas de disponibilidad y regiones.

Coloque máquinas virtuales con un equilibrador de carga. No use una sola máquina virtual para las cargas de trabajo críticas. En su lugar, coloque varias máquinas virtuales con un equilibrador de carga. Si alguna deja de estar disponible, el equilibrador de carga distribuye el tráfico a las demás máquinas virtuales en buen estado. Para aprender a implementar esta configuración, consulta [Multiple VMs for scalability and availability][multi-vm-blueprint].

Replique las bases de datos. Azure SQL Database y Azure Cosmos DB replican automáticamente los datos dentro de una región y se pueden configurar para replicar entre zonas de disponibilidad para lograr una mayor resistencia. También puede optar por habilitar la replicación geográfica entre regiones. La replicación geográfica para Azure SQL Database y Azure Cosmos DB crea réplicas legibles secundarias de los datos en una o varias regiones secundarias. Si se produce una interrupción en la región primaria, la base de datos puede conmutar por error a la región secundaria para las escrituras. En función de la configuración de replicación, puede experimentar cierta pérdida de datos de transacciones no replicadas.

Si utiliza una solución de base de datos de IaaS, elija una que admita la replicación y la conmutación por error, como Grupos de disponibilidad AlwaysOn de SQL Server.

Cree particiones para conseguir disponibilidad. La creación de particiones de base de datos se suele usar para mejorar la escalabilidad, pero también puede mejorar la disponibilidad. Aunque una partición deje de funcionar, puede acceder a las demás particiones. Un error en una partición solo provocará la interrupción en un subconjunto de transacciones.

Soluciones de varias regiones

En el siguiente diagrama se muestra una aplicación en varias regiones que utiliza Azure Traffic Manager para controlar la conmutación por error.

Si usa Traffic Manager en una solución de varias regiones, tenga en cuenta las siguientes recomendaciones:

Sincronice la conmutación por error del front-end y del back-end. Use Traffic Manager para conmutar por error el front-end. Si el front-end está inaccesible en una región, Traffic Manager enruta las nuevas solicitudes a la región secundaria. En función de los componentes de back-end y la solución de base de datos, es posible que tenga que coordinar la conmutación por error de los servicios y bases de datos de back-end.

Utilice la conmutación automática por error pero la conmutación por recuperación manual. Use Traffic Manager para la conmutación automática por error, pero no para la conmutación por recuperación automática. La conmutación por recuperación automática supone el riesgo de cambiar a la región principal antes de que se encuentre totalmente en buen estado. En su lugar, compruebe que todos los subsistemas de aplicación tengan un estado correcto antes de la conmutación por recuperación manual. Además, dependiendo de la base de datos, deberá comprobar la coherencia de los datos antes de la conmutación por recuperación.

Para ello, deshabilite el punto de conexión principal de Traffic Manager después de la conmutación por error. Tenga en cuenta que si el intervalo de supervisión de sondeos es corto y el número tolerado de errores es pequeño, la conmutación por error y la conmutación por recuperación se realizarán en un breve tiempo. En algunos casos, la deshabilitación no se completará a tiempo. Para evitar la conmutación por recuperación no confirmada, considere también la posibilidad de implementar un punto de conexión de mantenimiento que pueda comprobar que todos los subsistemas están en buen estado. Consulte Patrón de supervisión del punto de conexión de mantenimiento.

Incluya redundancia para Traffic Manager. Traffic Manager es un posible punto de error. Revise el Acuerdo de Nivel de Servicio de Traffic Manager y determine si el uso de Traffic Manager por sí solo cumple sus requisitos empresariales de alta disponibilidad. Si no es así, considere la posibilidad de agregar otra solución de administración de tráfico como conmutación por recuperación. Si el servicio Azure Traffic Manager no funciona, cambie los registros CNAME de DNS para que apunten a otro servicio de administración del tráfico.