REL11-BP03 Automatización de la reparación en todas las capas
Cuando se detecte un error, utilice las funciones automatizadas para tomar medidas correctivas. Las degradaciones pueden repararse automáticamente a través de mecanismos de servicio interno o requerir que los recursos se reinicien o eliminen a través de medidas de corrección.
Para las aplicaciones autoadministradas y la reparación entre regiones, los diseños de recuperación y los procesos de reparación automatizados se pueden extraer de las prácticas recomendadas existentes
La capacidad de reiniciar o eliminar un recurso es una herramienta importante para corregir los errores. Una práctica recomendada es convertir los servicios en servicios sin estado siempre que sea posible. Esto evita la pérdida de datos o disponibilidad tras el reinicio del recurso. En la nube, puede (y generalmente debería) sustituir todo el recurso (por ejemplo, la instancia de computación o la función sin servidor) como parte del reinicio. El reinicio en sí es una forma sencilla y fiable de recuperarse de un error. En las cargas de trabajo ocurren muchos tipos de errores diferentes. Los errores pueden ocurrir en el hardware, el software, las comunicaciones y el funcionamiento.
El reinicio o el reintento también se aplican a las solicitudes de red. Se aplica el mismo enfoque de recuperación tanto a un tiempo de espera de la red como a un error en la dependencia, en el que la dependencia devuelve un error. Ambos eventos tienen un efecto similar en el sistema, por lo que, en lugar de intentar convertir cada uno en un caso especial, se aplicaría una estrategia similar de reintento con retroceso exponencial y fluctuación. La capacidad de reiniciar es un mecanismo de recuperación que aparece en la computación orientada a la recuperación y en las arquitecturas de clústeres de alta disponibilidad.
Resultado deseado: se llevan a cabo medidas automatizadas para corregir la detección de un error.
Patrones comunes de uso no recomendados:
-
Aprovisionar recursos sin escalado automático.
-
Implementar las aplicaciones en instancias o contenedores individualmente.
-
Implementar aplicaciones que no se pueden implementar en varias ubicaciones sin usar la recuperación automática.
-
Reparar manualmente las aplicaciones que el escalado automático y la recuperación automática no pueden reparar.
-
No hay automatización de las bases de datos de conmutación por error.
-
Carencia de métodos automatizados para redirigir el tráfico a nuevos puntos de conexión.
-
No hay replicación del almacenamiento.
Beneficios de establecer esta práctica recomendada: la reparación automática puede reducir el tiempo medio de recuperación y mejorar la disponibilidad.
Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto
Guía para la implementación
Los diseños de Amazon EKS u otros servicios de Kubernetes deben incluir conjuntos de réplicas o con estado mínimo y máximo y el tamaño mínimo del clúster y los grupos de nodos. Estos mecanismos proporcionan una cantidad mínima de recursos de procesamiento disponibles de forma continua y, al mismo tiempo, corrigen automáticamente cualquier error mediante el plano de control de Kubernetes.
Los patrones de diseño a los que se accede a través de un equilibrador de carga mediante clústeres de computación deben utilizar los grupos de escalado automático. Elastic Load Balancing (ELB) distribuye automáticamente el tráfico de aplicaciones entrante entre varios destinos y dispositivos virtuales en una o más zonas de disponibilidad (AZ).
Los diseños basados en computación en clúster que no utilizan el equilibrio de carga deben tener un diseño de tamaño que dé cabida a la pérdida de al menos un nodo. Esto permitirá que el servicio siga funcionando con una capacidad potencialmente reducida mientras recupera un nuevo nodo. Algunos servicios son Mongo, el Acelerador de DynamoDB, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK y Amazon OpenSearch Service. Muchos de estos servicios se pueden diseñar con características adicionales de autorreparación. Algunas tecnologías de clústeres deben generar una alerta tras la pérdida de un nodo, lo que desencadena un flujo de trabajo automático o manual para recrear un nuevo nodo. Este flujo de trabajo se puede automatizar con AWS Systems Manager para corregir los problemas rápidamente.
Se puede usar Amazon EventBridge para supervisar y filtrar los eventos, como las alarmas de CloudWatch o cambios en el estado en otros servicios de AWS. En función de la información del evento, se puede invocar a AWS Lambda, Automatización de Systems Manager u otros destinos para ejecutar una lógica de corrección personalizada en la carga de trabajo. Amazon EC2 Auto Scaling se puede configurar para comprobar el estado de la instancia de EC2. Si el estado de la instancia es cualquier otro estado distinto de En ejecución o si el estado del sistema es Dañado, Amazon EC2 Auto Scaling considera que la instancia tiene un estado incorrecto y lanza una instancia de reemplazo. Para sustituciones a gran escala (como la pérdida de toda una zona de disponibilidad), se prefiere la estabilidad estática para la alta disponibilidad.
Pasos para la implementación
-
Use grupos de escalado automático para implementar niveles en una carga de trabajo. El escalado automático puede llevar a cabo una reparación automática de aplicaciones sin estado y agregar o eliminar capacidad.
-
En el caso de las instancias de computación indicadas anteriormente, utilice el equilibrio de carga y elija el tipo de equilibrador de carga adecuado.
-
Considere la reparación para Amazon RDS. Con las instancias en espera, defina la configuración de la conmutación por error automática
en la instancia en espera. Para la réplica de lectura de Amazon RDS, se requiere un flujo de trabajo automatizado para convertir una réplica de lectura en principal. -
Implemente la recuperación automática en instancias de EC2 que tengan aplicaciones implementadas que no se puedan implementar en varias ubicaciones y puedan tolerar el reinicio tras un error. La recuperación automática se puede usar para reemplazar hardware defectuoso y reiniciar la instancia cuando la aplicación no se puede implementar en varias ubicaciones. Los metadatos de la instancia y las direcciones IP asociadas se conservan, así como los volúmenes de EBS y los puntos de montaje en Amazon Elastic File System o File Systems para Lustre y Windows. Con AWS OpsWorks, puede configurar la reparación automática de las instancias de EC2 en el nivel de capa.
-
Implemente la recuperación automática mediante AWS Step Functions y AWS Lambda cuando no pueda usar el escalado automático ni la recuperación automática o cuando la recuperación automática produzca un error. Cuando no pueda usar el escalado automático ni la recuperación automática, o esta produzca un error, puede automatizar la reparación con AWS Step Functions y AWS Lambda.
-
Se puede usar Amazon EventBridge para supervisar y filtrar los eventos, como las alarmas de CloudWatch o cambios en el estado en otros servicios de AWS. En función de la información del evento, se puede invocar AWS Lambda (u otros destinos) para ejecutar una lógica de corrección personalizada en su carga de trabajo.
Recursos
Prácticas recomendadas relacionadas:
Documentos relacionados:
Videos relacionados:
Ejemplos relacionados:
Herramientas relacionadas:
