REL11-BP04 Confianza 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, cé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 las 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 hacer 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 agregar 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:
-
Depender de cambiar los registros de DNS para redirigir el tráfico.
-
Depender 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 de varios servicios y varias API 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 (para determinados tipos de degradaciones del servicio, los planos de control se ven afectados). Si se depende del uso extensivo del plano de control para la corrección, se 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.
Use el Controlador de recuperación de aplicaciones de Amazon 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 en las instalaciones.
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. Están distribuidos por todo el mundo y están diseñados para cumplir con un acuerdo de nivel de servicio (SLA) con una disponibilidad del 100 %
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.
Diseñe su infraestructura informática para que sea estable desde el punto de vista estático a fin de evitar el uso del plano de control durante un incidente. Por ejemplo, si utiliza instancias de Amazon EC2, evite aprovisionar nuevas instancias manualmente o dar instrucciones a los grupos de escalado automático para que agreguen instancias en respuesta. 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 limitaciones en todo el sistema de principio a fin para limitar de forma segura el tráfico total que llega al conjunto limitado de recursos.
En el caso de los servicios como Amazon DynamoDB, Amazon API Gateway, los equilibradores de carga y sin servidor de AWS Lambda, 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 planos de datos, 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 manual de procedimientos 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:
-
Escalado automático (plano de control) a los recursos de Amazon EC2 preescalados (plano de datos)
-
Escalado de instancias de Amazon EC2 (plano de control) a escalado de AWS Lambda (plano de datos)
-
Evalúe cualquier diseño con Kubernetes y la índole de las acciones del plano de control. Agregar pods es una acción del plano de datos en Kubernetes. Las acciones deben limitarse a agregar pods y no a agregar nodos. Usar nodos sobreaprovisionados
es el método preferido para limitar las acciones del plano de control
Tenga en cuenta los enfoques alternativos que permiten que las acciones del plano de datos afecten a la misma corrección.
-
Cambio de registro de Route 53 (plano de control) o Controlador de recuperación de aplicaciones de Amazon (plano de datos)
-
Comprobaciones de estado de Route 53 para obtener actualizaciones más automatizadas
Considere algunos servicios en una región secundaria, en caso de que el servicio sea crítico, 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 una 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:
-
Socio de APN: socios que pueden ayudar con la automatización de su tolerancia a errores
-
AWS Marketplace: productos que pueden usarse para tolerancia a errores
-
Ejecuciones de AWS Lambda (divididas entre el plano de control y el plano de datos)
Videos relacionados:
Ejemplos relacionados:
Herramientas relacionadas: