REL11-BP02 Conmutación por error a recursos en buen estado
Si un recurso fallara, los recursos en buen estado deberían seguir atendiendo las solicitudes. Para problemas de ubicación (como zonas de disponibilidad o Región de AWS), asegúrese de que disponga de sistemas para conmutar por error a recursos en buen estado en ubicaciones sin problemas.
Al diseñar un servicio, distribuya la carga entre los recursos, las zonas de disponibilidad o las regiones. De esta manera, el error de un recurso individual o el deterioro puede mitigarse al desplazar el tráfico a los recursos restantes en buen estado. Tenga en cuenta cómo se descubren los servicios y cómo se enruta a ellos en caso de que se produzca un error.
Tenga en cuenta la recuperación de errores al diseñar sus servicios. En AWS, diseñamos servicios para minimizar el tiempo de recuperación de los errores y el impacto en los datos. Nuestros servicios utilizan principalmente almacenes de datos que confirman las solicitudes solo después de que se almacenen de forma duradera en varias réplicas en una región. Se han diseñado para utilizar el aislamiento basado en celdas y el aislamiento de errores que proporcionan las zonas de disponibilidad. Utilizamos ampliamente la automatización en nuestros procedimientos operativos. También optimizamos nuestra funcionalidad de reemplazo y reinicio para recuperarnos rápidamente de las interrupciones.
Los patrones y diseños que permiten la conmutación por error varían para cada servicio de plataforma de AWS. Muchos servicios administrados nativos de AWS son zonas de disponibilidad múltiples de forma nativa (como Lambda o API Gateway). Otros servicios de AWS (como EC2 y EKS) requieren diseños específicos de las prácticas recomendadas para admitir la conmutación por error de los recursos o el almacenamiento de datos en las AZ.
La supervisión debe configurarse para que compruebe que el recurso de conmutación por error esté en buen estado, hacer un seguimiento del progreso de los recursos de conmutación por error y supervisar la recuperación de los procesos empresariales.
Resultado deseado: los sistemas son capaces de utilizar nuevos recursos de forma automática o manual para recuperarse de la degradación.
Patrones comunes de uso no recomendados:
-
La planificación de errores no forma parte de la fase de planificación y diseño.
-
No se establecen el RTO ni el RPO.
-
Supervisión insuficiente para detectar recursos defectuosos.
-
Aislamiento adecuado de los dominios de error.
-
No se considera la conmutación por error multirregional.
-
La detección de errores es demasiado sensible o agresiva a la hora de decidir efectuar una conmutación por error.
-
No probar ni validar el diseño de la conmutación por error.
-
Llevar a cabo la automatización de la recuperación automática, pero no notificar que se necesitaba una reparación.
-
Ausencia de un periodo de amortiguación para evitar que la conmutación por error se lleve a cabo demasiado pronto.
Beneficios de establecer esta práctica recomendada: con una degradación uniforme y una recuperación rápida, puede crear sistemas más resilientes que mantengan la fiabilidad cuando se producen errores.
Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto
Guía para la implementación
Los servicios de AWS, como Elastic Load Balancing y Amazon EC2 Auto Scaling, ayudan a distribuir la carga entre los recursos y las zonas de disponibilidad. Por lo tanto, el error de un recurso individual (como una instancia de EC2) o el deterioro de una zona de disponibilidad puede mitigarse si se desplaza el tráfico a los recursos restantes en buen estado.
Para las cargas de trabajo multirregionales, los diseños son más complicados. Por ejemplo, las réplicas de lectura entre regiones le permiten implementar sus datos en varias Regiones de AWS. Sin embargo, la conmutación por error sigue siendo necesaria para convertir la réplica de lectura en principal y, a continuación, dirigir el tráfico al nuevo punto de conexión. Amazon Route 53, el Controlador de recuperación de aplicaciones de (ARC)
Los servicios de AWS, como Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge o Amazon DynamoDB, se implementan automáticamente en varias zonas de disponibilidad mediante AWS. En caso de error, estos servicios de AWS dirigen automáticamente el tráfico a ubicaciones en buen estado. Los datos se almacenan de forma redundante en varias zonas de disponibilidad y siguen estando disponibles.
Para Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS o Amazon ECS, Multi-AZ es una opción de configuración. AWS puede dirigir el tráfico a la instancia en buen estado si se inicia la conmutación por error. Esta acción de conmutación por error puede llevarla a cabo AWS o según lo requiera el cliente
Para las instancias de Amazon EC2, Amazon Redshift, las tareas de Amazon ECS o los pods de Amazon EKS, elige en qué zonas de disponibilidad deben implementarse. En algunos diseños, Elastic Load Balancing proporciona la solución para detectar instancias en zonas que no están en buen estado y dirigir el tráfico a las que sí están en buen estado. Elastic Load Balancing también puede dirigir el tráfico a componentes de su centro de datos en las instalaciones.
En cuanto a la conmutación por error del tráfico multirregional, el reenrutamiento puede utilizar Amazon Route 53, el Controlador de recuperación de aplicaciones de Amazon, AWS Global Accelerator, DNS privado de Route 53 para VPC o CloudFront para proporcionar una forma de definir dominios de Internet y asignar políticas de enrutamiento, incluidas comprobaciones de estado, para enrutar el tráfico a regiones en buen estado. AWS Global Accelerator proporciona direcciones IP estáticas que actúan como punto de entrada fijo a su aplicación; a continuación, se enrutan a los puntos de conexión de las Regiones de AWS que elija, mediante la red global de AWS en lugar de Internet para mejorar el rendimiento y la fiabilidad.
Pasos para la implementación
-
Cree diseños de conmutación por error para todas las aplicaciones y servicios pertinentes. Aísle cada componente de la arquitectura y cree diseños de conmutación por error que satisfagan el RTO y el RPO de cada componente.
-
Configure entornos inferiores (como los de desarrollo o prueba) con todos los servicios que sean necesarios para tener un plan de conmutación por error. Implemente las soluciones mediante la infraestructura como código (IaC) para garantizar la repetibilidad.
-
Configure un sitio de recuperación, como una segunda región, para implementar y probar los diseños de conmutación por error. Si fuera necesario, los recursos para las pruebas se pueden configurar temporalmente para limitar los costos adicionales.
-
Determine qué planes de conmutación por error se automatizan mediante AWS, cuáles pueden automatizarse mediante un proceso de DevOps y cuáles pueden ser manuales. Documente y mida el RTO y el RPO de cada servicio.
-
Cree un manual de estrategias de conmutación por error e incluya todos los pasos de la conmutación por error de cada recurso, aplicación y servicio.
-
Cree un manual de estrategias de conmutación por recuperación e incluya todos los pasos de la conmutación por recuperación (con plazos) de cada recurso, aplicación y servicio.
-
Cree un plan para iniciar y ensayar el manual de estrategias. Utilice simulaciones y pruebas de caos para poner a prueba los pasos del manual de estrategias y la automatización.
-
Para problemas de ubicación (como zonas de disponibilidad o Región de AWS), asegúrese de que disponga de sistemas para conmutar por error a recursos en buen estado en ubicaciones sin problemas. Compruebe la cuota, los niveles de escalado automático y los recursos en ejecución antes de llevar a cabo la prueba de conmutación por error.
Recursos
Prácticas recomendadas de Well-Architected relacionadas:
Documentos relacionados:
Ejemplos relacionados:
