REL11-BP04 Confiar en el plano de datos y no en el plano de control durante la recuperación - AWS Well-Architected Framework
Guía para la implementaciónRecursos

REL11-BP04 Confiar en el plano de datos y no en el plano de control durante la recuperación

Los planos de control proporcionan las API administrativas que se utilizan para crear, leer y describir, actualizar, eliminar y enumerar los recursos (CRUDL), mientras que los planos de datos gestionan el tráfico de servicio diario. Al implementar respuestas de recuperación o mitigación a eventos que puedan afectar a la resiliencia, concéntrese en utilizar un número mínimo de operaciones del plano de control para recuperar, reescalar, restaurar, reparar o conmutar por error el servicio. La acción del plano de datos debe reemplazar cualquier actividad durante estos eventos de degradación.

Por ejemplo, las siguientes son todas acciones del plano de control: lanzar una nueva instancia de computación, crear almacenamiento en bloques y describir los servicios de colas. Al lanzar instancias de computación, el plano de control debe realizar varias tareas, como encontrar un host físico con capacidad, asignar interfaces de red, preparar los volúmenes de almacenamiento en bloques locales, generar credenciales y añadir reglas de seguridad. Los planos de control suelen tener una orquestación complicada.

Resultado deseado: cuando un recurso entra en un estado deteriorado, el sistema es capaz de recuperarse automática o manualmente al cambiar el tráfico de recursos deteriorados a recursos en buen estado.

Patrones comunes de uso no recomendados:

  • Dependencia de cambiar los registros de DNS para redirigir el tráfico.

  • Dependencia de las operaciones de escalado del plano de control para reemplazar los componentes dañados debido a que no se han aprovisionado suficientes recursos.

  • Confiar en amplias acciones del plano de control, multiservicio y multiAPI para corregir cualquier categoría de deterioro.

Beneficios de establecer esta práctica recomendada: el aumento de la tasa de éxito de la corrección automatizada puede reducir el tiempo medio de recuperación y mejorar la disponibilidad de la carga de trabajo.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: Medio. En ciertos tipos de degradaciones del servicio, los planos de control se ven afectados. La dependencia del uso extensivo del plano de control para la corrección puede aumentar el tiempo de recuperación (RTO) y el tiempo medio de recuperación (MTTR).

Guía para la implementación

Para limitar las acciones del plano de datos, evalúe cada servicio para determinar qué acciones son necesarias para restablecer el servicio.

Utilice Amazon Route 53 Application Recovery Controller para cambiar el tráfico de DNS. Estas características supervisan continuamente la capacidad de la aplicación de recuperarse de los errores y le permiten controlar la recuperación de la aplicación en las distintas Regiones de AWS, zonas de disponibilidad y localmente.

Las políticas de enrutamiento de Route 53 utilizan el plano de control, por lo que no debe confiar en él para la recuperación. Los planos de datos de Route 53 responden a consultas de DNS y llevan a cabo y evalúan comprobaciones de estado. Se distribuyen a nivel mundial y están diseñados para un acuerdo de nivel de servicio (SLA) del 100 % de disponibilidad..

Las API de administración de Route 53 y las consolas en las que se crean, actualizan y eliminan recursos de Route 53 se ejecutan en planos de control diseñados para dar prioridad a la sólida coherencia y durabilidad que necesita al administrar DNS. Para conseguirlo, los planos de control se encuentran en una única región: Este de EE. UU. (Norte de Virginia). Aunque ambos sistemas se han diseñado para ser muy fiables, los planos de control no están incluidos en el SLA. Podría haber eventos poco frecuentes en los que el diseño resiliente del plano de datos permita mantener la disponibilidad mientras que los planos de control no lo permitan. Con los mecanismos de recuperación de desastres y conmutación por error, utilice las funciones del plano de datos para proporcionar la mejor fiabilidad posible.

Para Amazon EC2, utilice diseños de estabilidad estática para limitar las acciones del plano de control. Las acciones del plano de control incluyen la ampliación de los recursos de forma individual o mediante grupos de Auto Scaling (ASG). Para obtener los niveles más altos de resiliencia, aprovisione suficiente capacidad en el clúster utilizado para la conmutación por error. Si este umbral de capacidad debe limitarse, establezca reguladores en todo el sistema de principio a fin para limitar de forma segura el tráfico total que llega al conjunto limitado de recursos.

Para servicios como Amazon DynamoDB, Amazon API Gateway, los equilibradores de carga y los servicios de AWS Lambda sin servidor, el uso de esos servicios utiliza el plano de datos. Sin embargo, la creación de nuevas funciones, equilibradores de carga, puertas de enlace de API o tablas de DynamoDB es una acción del plano de control y debe completarse antes de la degradación como preparación para un evento y ensayo de las acciones de conmutación por error. En el caso de Amazon RDS, las acciones del plano de datos permiten el acceso a los datos.

Para obtener más información sobre los planos de datos, los planos de control y cómo AWS crea servicios para cumplir los objetivos de alta disponibilidad, consulte Estabilidad estática con zonas de disponibilidad.

Comprenda qué operaciones están en el plano de datos y cuáles están en el plano de control.

Pasos para la implementación

Para cada carga de trabajo que deba restaurarse después de un evento de degradación, evalúe el runbook de conmutación por error, el diseño de alta disponibilidad, el diseño de reparación automática o el plan de restauración de recursos de alta disponibilidad. Identifique cada acción que pueda considerarse una acción del plano de control.

Considere cambiar la acción de control por una acción del plano de datos:

  • Auto Scaling (plano de control) en comparación con los recursos de Amazon EC2 preescalados (plano de datos).

  • Migre a Lambda y sus métodos de escalado (plano de datos) o a Amazon EC2 y ASG (plano de control).

  • Evalúe cualquier diseño con Kubernetes y la naturaleza de las acciones del plano de control. Añadir pods es una acción del plano de datos en Kubernetes. Las acciones deben limitarse a añadir pods y no a añadir nodos. Con nodos sobreaprovisionados es el método preferido para limitar las acciones del plano de control.

Considere enfoques alternativos que permitan que las acciones del plano de datos afecten a la misma corrección.

Considere algunos servicios en una región secundaria, si el servicio es crucial para la misión, para permitir más acciones del plano de control y el plano de datos en una región no afectada.

  • Amazon EC2 Auto Scaling o Amazon EKS en una región principal en comparación con Amazon EC2 Auto Scaling o Amazon EKS en una región secundaria y enrutamiento del tráfico a la región secundaria (acción del plano de control).

  • Hacer réplicas de lectura en la región principal secundaria o intentar la misma acción en la región principal (acción del plano de control).

Recursos

Prácticas recomendadas relacionadas:

Documentos relacionados:

Vídeos relacionados:

Ejemplos relacionados:

Herramientas relacionadas: