Prácticas recomendadas para los cambios de zona 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.

Cuando inicia un cambio de zona para un recurso compatible y el tráfico se aleja de una zona de disponibilidad, se elimina la capacidad que la aplicación utilizaba para atender las solicitudes. Debe asegurarse de haber planificado un traslado del tráfico fuera de una zona de disponibilidad y de poder seguir atendiendo las solicitudes en las zonas restantes AZs.

Cuando el Controlador de recuperación de aplicaciones de Amazon (ARC) desvía el tráfico de una zona afectada, por ejemplo, mediante un cambio de zona o un cambio automático de zona, el mecanismo que utiliza ARC para mover el tráfico de la aplicación es una actualización del DNS. Una actualización del DNS hace que todas las nuevas 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.

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 recursos 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 ELB para los destinos incorrectos y los bytes procesados por zona de disponibilidad.

Plantéese la posibilidad de supervisar el estado de los 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.

Para iniciar un cambio zonal cuando necesite recuperar una aplicación rápidamente y con pocas dependencias, le recomendamos que utilice la API AWS Command Line Interface o la API con acciones de cambio zonal y, de ser posible, con credenciales almacenadas previamente. También puedes iniciar cambios zonales en el Consola de administración de AWS, 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 referencia de la API de cambio de zona.

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.