Mejores prácticas para los cambios zonales en ARC

Asegúrese de haber planificado y escalado previamente, o de escalar automáticamente, la capacidad suficiente para adaptarse a la carga adicional que se impone en las zonas de disponibilidad al iniciar un cambio de zona. Con una arquitectura orientada a la recuperación, una recomendación habitual es escalar previamente la capacidad de cómputo con el fin de incluir suficiente margen para atender los picos de tráfico cuando una de las (normalmente) tres réplicas esté fuera desconectada.

Al iniciar un cambio de zona para un único recurso de equilibrador de carga, por ejemplo, la capacidad de una zona de disponibilidad se eliminará temporalmente desde detrás del equilibrador de carga. En función de los cambios de zona que inicie y de la configuración de los equilibradores de carga, debe asegurarse de haber planificado detenidamente la gestión del aumento de carga en las zonas de disponibilidad restantes.

Cuando Amazon Application Recovery Controller (ARC) aleja el tráfico de una deficiencia, por ejemplo, mediante el cambio zonal o el cambio automático zonal, el mecanismo que se ARC utiliza para mover el tráfico de las aplicaciones es una actualización. DNS Una DNS actualización hace que todas las conexiones nuevas se dirijan lejos de la ubicación dañada.

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

Si usa un Application Load Balancer, puede usar la keepalive opción para configurar la duración de las conexiones. Para obtener más información, consulte la duración HTTP del mantenimiento del cliente en la Guía del usuario de Application Load Balancer.

De forma predeterminada, los balanceadores de carga de aplicaciones establecen el valor de duración de keepalive del HTTP cliente en 3600 segundos o 1 hora. Le sugerimos que reduzca el valor para ajustarlo al objetivo de tiempo de recuperación de su aplicación, por ejemplo, 300 segundos. Al elegir el tiempo de permanencia activo de un HTTP cliente, 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 alejar más rápidamente a todos los clientes de una zona de disponibilidad o región con problemas.

Inicie cambios de zona para probar periódicamente a desviar el tráfico de las zonas de disponibilidad para la aplicación. Planifique y ejecute el inicio de cambios de zona, preferiblemente tanto en entornos de prueba como de producción, como parte de las pruebas de conmutación por error periódicas para recuperar las aplicaciones en caso de un desastre. Las pruebas periódicas son fundamentales para garantizar que está preparado y tiene la confianza necesaria para mitigar los problemas cuando se produce un incidente operativo.

Los cambios de zona funcionan marcando un recurso, es decir, una réplica de una aplicación, como incorrecto en una zona de disponibilidad. Esto significa que es fundamental garantizar que los objetivos de los equilibradores de carga de las aplicaciones estén en buen estado y capten tráfico de forma activa en las zonas de disponibilidad de una región. Le recomendamos que tenga paneles para realizar un seguimiento de esto, que incluyan, por ejemplo, las métricas de Elastic Load Balancing para los objetivos en mal estado y bytesProcessed por zona de disponibilidad.

Considere la posibilidad de monitorear el estado de sus recursos desde una segunda región adyacente. Las ventajas de este enfoque son que puede representar mejor la experiencia de los usuarios finales y, además, reduce el riesgo de que tanto la aplicación como la supervisión se vean afectadas por el mismo desastre al mismo tiempo (“destino compartido”).

Para iniciar un cambio zonal cuando necesite recuperar una aplicación rápidamente y con pocas dependencias, le recomendamos que utilice las acciones de cambio zonal AWS Command Line Interface o API con ellas, con credenciales almacenadas previamente, si es posible. También puede iniciar cambios zonales en el AWS Management Console, para facilitar su uso. Sin embargo, cuando la recuperación rápida y fiable es fundamental, las operaciones del plano de datos son una mejor opción. Para obtener más información, consulte la Guía de APIreferencia de cambios zonales.

Un cambio de zona desvía el tráfico de una zona de disponibilidad de forma temporal para mitigar una alteración. Debe restaurar el servicio del recurso de la aplicación en cuanto haya tomado medidas para corregir un problema. Esto garantiza que toda la aplicación se restaure a su estado original, totalmente redundante y resiliente.