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?
En una implementación perfecta, agregar redundancia uniforme podría aumentar exponencialmente la disponibilidad del sistema. Por ejemplo, imagine que tiene N componentes equivalentes, igual de equilibrados que:
- puede no funcionar de forma independiente y simultáneamente eliminado 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í
- controla la reducción de la capacidad sin un funcionamiento incorrecto adicional
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
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.
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.
Pruebe y valide los componentes redundantes. Las ventajas de confiabilidad de muchas maneras de simplificar y agregar redundancia pueden aumentar la complejidad. Para asegurarse de que agregar redundancia realmente conduce a una mayor disponibilidad, debe validar lo siguiente:
- ¿El sistema puede detectar componentes con redundancia correctos y incorrectos de forma segura y rápida?
- ¿El sistema se puede escalar horizontalmente de forma confiable y en los componentes redundantes?
- ¿Las operaciones rutinarias, ad hoc y de carga de trabajo de emergencia pueden controlar 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, la conmutación por error 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 de back-end y las bases de datos.
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 debe comprobar la coherencia de los datos antes de conmutar por recuperación.
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 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 de misión crítica.