Prácticas recomendadas para control de enrutamiento en ARC

En un escenario de recuperación ante desastres (DR), reduzca al mínimo las dependencias del sistema mediante un enfoque sencillo para acceder a las tareas de recuperación AWS y realizarlas. Cree credenciales de IAM de larga duración específicas para las tareas de DR y guárdelas de forma segura en una caja fuerte física en las instalaciones o en un almacén virtual para acceder a ellas cuando sea necesario. Con IAM, puede gestionar de forma centralizada las credenciales de seguridad, como las claves de acceso y los permisos de acceso a AWS los recursos. En el caso de tareas no relacionadas con DR, le recomendamos que siga utilizando el acceso federado mediante los servicios de AWS , como, por ejemplo, AWS Single Sign-On.

Para realizar tareas de conmutación por error en ARC con la API del plano de datos del clúster de recuperación, puede asociar una política de IAM de ARC a su usuario. Para obtener más información, consulte Ejemplos de políticas basadas en identidades del Controlador de recuperación de aplicaciones (ARC) de Amazon.

En el caso de los registros de DNS que pueda necesitar cambiar como parte del mecanismo de conmutación por error, especialmente los registros cuyo estado se haya comprobado, se recomienda utilizar valores de TTL más bajos. Configurar un TTL de 60 o 120 segundos es una opción común para esta situación.

La configuración TTL (tiempo de vida) de DNS indica a los solucionadores de DNS cuánto tiempo deben almacenar en caché un registro antes de solicitar uno nuevo. Cuando selecciona un TTL, inicia un compromiso entre latencia y fiabilidad y la capacidad de respuesta a los cambios. Con TTL más cortos en un registro, los solucionadores de DNS detectan las actualizaciones del registro más rápido, ya que deben realizar consultas con más frecuencia.

Para obtener más información, consulte Elija valores de TTL para los registros de DNS en Prácticas recomendadas para registros de DNS de Amazon Route 53.

Cuando utilizas controles de enrutamiento para cambiar de uno Región de AWS a otro, el mecanismo que Amazon Application Recovery Controller (ARC) utiliza para mover el tráfico de tus aplicaciones es una actualización de DNS. Esta actualización hace que todas las conexiones nuevas se desvíen de la ubicación afectada.

Sin embargo, los clientes con conexiones abiertas preexistentes pueden seguir realizando solicitudes a la ubicación afectada hasta que se vuelvan a conectar. Para garantizar una recuperación rápida, le recomendamos que limite el tiempo que los clientes permanecen conectados a los puntos de conexión.

Si utiliza un equilibrador de carga de aplicación, puede utilizar la opción keepalive para configurar la duración de las conexiones. Para obtener más información, consulte Duración del valor keepalive del cliente HTTP en la Guía del usuario del equilibrador de carga de aplicación.

De forma predeterminada, los equilibradores de carga de aplicación establecen el valor de duración keepalive del cliente HTTP en 3600 segundos o 1 hora. Le recomendamos que reduzca el valor para que se ajuste al objetivo de tiempo de recuperación de la aplicación, por ejemplo, 300 segundos. Al elegir un tiempo de duración del valor keepalive del cliente HTTP, tenga en cuenta que este valor es una compensación entre volver a conectarse con más frecuencia en general, lo que puede afectar a la latencia, y desviar más rápidamente a todos los clientes de una zona de disponibilidad o región con fallos.

Le recomendamos que guarde una copia local de los puntos de conexión del clúster regional de ARC, en marcadores o guardada en el código de automatización que utilice para volver a intentar los puntos de conexión. Durante un caso de error, es posible que no pueda acceder a algunas operaciones de la API, incluidas las operaciones de la API de ARC que no están alojadas en el clúster del plano de datos extremadamente fiable. Puede enumerar los puntos finales de sus clústeres ARC mediante la DescribeClusteroperación de API.

Los controles de enrutamiento proporcionan cinco puntos de conexión regionales para garantizar una alta disponibilidad, incluso al hacer frente errores. Para lograr su total resiliencia, es importante contar con una lógica de reintento que pueda utilizar los cinco puntos de conexión según sea necesario. Para obtener información sobre el uso de ejemplos de código con el AWS SDK, incluidos ejemplos para probar puntos de enlace de clústeres, consulte. Ejemplos de código para Application Recovery Controller mediante AWS SDKs

Con la API del plano de datos ARC, consulte los controles y estados de enrutamiento con la ListRoutingControlsoperación y actualice los estados del control de enrutamiento para redirigir el tráfico y realizar la conmutación por error con la UpdateRoutingControlStateoperación. Puede usar el código AWS CLI (como en estos ejemplos) o el código que escriba con uno de los AWS SDKs. ARC ofrece una fiabilidad extrema con la API en el plano de datos para conmutar el tráfico por error. Recomendamos usar la API en lugar de cambiar los estados de control de enrutamiento en la Consola de administración de AWS.

Conéctese a uno de los puntos de conexión del clúster regionales para que ARC utilice la API del plano de datos. Si el punto de conexión no está disponible, puede intentar conectarse a otro punto de conexión del clúster.

Si una regla de seguridad bloquea una actualización del estado del control de enrutamiento, puede omitirla para realizar la actualización y conmutar por error el tráfico. Para obtener más información, consulte Anulación de las reglas de seguridad para redirigir el tráfico.

Pruebe la conmutación por error con regularidad con el control de enrutamiento de ARC, para realizar la conmutación por error de su pila de aplicaciones principal a una pila de aplicaciones secundaria. Es importante asegurarse de que las estructuras de ARC que ha agregado estén alineadas con los recursos correctos de su pila y de que todo funcione como esperaba. Debe probar esto después de configurar ARC para el entorno y continuar realizando pruebas periódicamente para que el entorno de conmutación por error esté preparado antes de que se produzca una situación de error en la que necesite que el sistema secundario esté listo y funcionando rápidamente para evitar el tiempo de inactividad de los usuarios.