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 fallo en un subsistema, la aplicación se reubicará a otra alternativa?

En una implementación perfecta, agregar redundancia uniforme podría aumentar exponencialmente la disponibilidad del sistema. Por ejemplo, imagina que tienes N componentes equivalentes, equilibrados de manera equitativa que:

• Puede fallar de forma independiente y ser eliminado simultáneamente del grupo
• Tienen un estado idéntico o ningún estado
• no tienen ningún trabajo en curso que se pierda permanentemente durante el mal funcionamiento
• son idénticos en las funcionalidades
• no tienen dependencias entre sí
• maneja la reducción de capacidad sin fallos adicionales

Si cada componente individual tiene una disponibilidad de A, la disponibilidad general del sistema se puede calcular mediante la fórmula 1 - (1 - A)^N.

Recomendaciones

Tenga en cuenta los requisitos empresariales. La cantidad de redundancia integrada en un sistema puede afectar tanto al costo como a la complejidad. Su arquitectura debe estar basada en sus requisitos empresariales, 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 de disponibilidad y las regiones proporcionan resistencia y diferentes conjuntos de ventajas arquitectónicas.

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 redundante por zonas ofrece el mejor conjunto de balances. 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 obtener más información sobre cómo diseñar la solución para usar regiones y zonas de disponibilidad, consulte Recomendaciones para usar regiones y zonas de disponibilidad.

Coloque máquinas virtuales detrás de 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.

Replicar 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 usa una solución de base de datos iaaS, elija una que admita la replicación y la conmutación por error, como los 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. Si una partición deja de funcionar, las demás particiones siguen siendo accesibles. Un fallo en una partición solo interrumpirá un subconjunto del total de las transacciones.

Pruebe y valide los componentes redundantes. La confiabilidad se beneficia de muchas maneras de la simplicidad, y agregar redundancia puede aumentar la complejidad. Para asegurarse de que agregar redundancia realmente conduce a una mayor disponibilidad, debe validar lo siguiente:

• ¿Puede su sistema detectar de manera confiable componentes redundantes saludables y no saludables, y eliminarlos de manera segura y rápida del conjunto de componentes?
• ¿Puede su sistema escalar y reducir de forma confiable los componentes redundantes?
• ¿Pueden las operaciones rutinarias, ad hoc y las tareas de emergencia gestionar la redundancia?

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 o Azure Front Door en una solución de varias regiones como mecanismo de enrutamiento de conmutación por error, tenga en cuenta las siguientes recomendaciones:

Sincronice la conmutación por error del front-end y del back-end. Use el mecanismo de enrutamiento para conmutar por error el front-end. Si el front-end está inaccesible en una región, enrute mediante conmutación por error 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. Utilice la automatización para la conmutación por error, pero no para la conmutación por recuperación. 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. También debería comprobar la coherencia de los datos antes de la conmutación por error.

Para ello, deshabilite el punto de conexión principal 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 el Patrón de supervisión del punto de conexión de mantenimiento.

Incluya redundancia para la solución de enrutamiento. Considere la posibilidad de diseñar una solución de redundancia de enrutamiento global para aplicaciones web críticas.