Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Independencia de la zona de disponibilidad
Para lograr el primer resultado, dejar de enviar trabajo a la zona de disponibilidad afectada, la evacuación requiere la implementación de la Independencia de la zona de disponibilidad
En una carga de trabajo de tipo solicitud/respuesta, la implementación de AZI requiere deshabilitar el equilibrio de carga entre zonas para los Equilibradores de carga de aplicación (ALB), los Equilibradores de carga clásicos (CLB) y los Equilibradores de carga de red (NLB) (el equilibrio de carga entre zonas está deshabilitado de forma predeterminada para los NLB). La deshabilitación del equilibrio de carga entre zonas tiene algunas desventajas. Al deshabilitar el equilibrio de carga entre zonas, el tráfico se divide equitativamente entre cada zona de disponibilidad, independientemente del número de instancias que haya en cada una. Si tiene recursos o grupos de escalado automático desequilibrados, esto puede suponer una carga adicional para los recursos de una zona de disponibilidad que tenga menos recursos que otras. Esto se ilustra en la siguiente figura, donde dos instancias de la zona de disponibilidad 1 reciben cada una el 25 % de la carga y las cinco instancias de la zona de disponibilidad 2 reciben cada una el 10 % de la carga.
El efecto de deshabilitar el equilibrio de carga entre zonas con instancias desequilibradas
Otros servicios zonales que utilice también deberán implementarse utilizando patrones AZI para facilitar la evacuación efectiva de las zonas de disponibilidad. Por ejemplo, los puntos de conexión de VPC de la interfaz proporcionan nombres de DNS específicos para cada zona de disponibilidad en la que está disponible el punto de conexión de la interfaz.
Uno de los desafíos de la implementación de AZI es el de las bases de datos, especialmente porque la mayoría de las bases de datos relacionales solo admiten un único escritor principal en cualquier momento. Al comunicarse con la instancia principal, es posible que deba cruzar un límite de zona de disponibilidad. Muchos servicios de bases de datos de AWS admiten una configuración Multi-AZ definida por el usuario y tienen una característica de conmutación por error Multi-AZ integrada como, por ejemplo, Amazon RDS o Amazon Aurora. En muchos escenarios de error, el servicio puede detectar el impacto y conmutar por error automáticamente la base de datos a una zona de disponibilidad diferente cuando se produce un problema. Sin embargo, durante un error gris, es posible que el servicio no detecte el impacto que está afectando a la carga de trabajo o que el impacto no esté relacionado en absoluto con la base de datos. En estos casos, una vez que detecte el impacto en una zona de disponibilidad, puede invocar manualmente una conmutación por error para mover la base de datos principal. Esto permite reaccionar de forma eficaz a un deterioro de una sola zona de disponibilidad.
Si utiliza réplicas de lectura con esas bases de datos, puede que también desee implementar AZI para ellas, ya que no puede realizar la conmutación por error de una réplica de lectura a una zona de disponibilidad diferente, como ocurre con la base de datos principal. Si tiene una réplica de lectura única en la zona de disponibilidad 1 y las instancias de tres zonas de disponibilidad están configuradas para utilizarla, un deterioro que afecte a la zona de disponibilidad 1 también afectará a las operaciones en las otras dos zonas de disponibilidad. Este es el impacto que desea evitar.
En el caso de las instancias de RDS, recibirá un punto de conexión de DNS para acceder a la réplica en una zona de disponibilidad específica. Para lograr la AZI, necesitará una réplica de lectura por zona de disponibilidad y una forma de que su aplicación sepa qué punto de conexión de réplica debe utilizar en la zona de disponibilidad en la que se encuentra. Un enfoque que puede adoptar es usar el ID de la zona de disponibilidad como parte del identificador de la base de datos, por ejemplo, use1-az1-read-replica.cbkdgoeute4n.us-east-1.rds.amazonaws.com. También puede hacerlo utilizando la detección de servicios (por ejemplo, con AWS Cloud Map
Descubrimiento de los nombres de DNS de los puntos de conexión de RDS para cada zona de disponibilidad
La configuración predeterminada de Amazon Aurora consiste en proporcionar un único punto de conexión de lectura que equilibre la carga de las solicitudes entre las réplicas de lectura disponibles. Para implementar AZI con Aurora, puede usar un punto de conexión personalizado para cada réplica de lectura que utilice el tipo ANY (para que pueda promover una réplica de lectura si es necesario). Asigne un nombre al punto de conexión personalizado en función del ID de la zona de disponibilidad donde se implementa la réplica. A continuación, puede usar el nombre de DNS proporcionado por el punto de conexión personalizado para conectarse a una réplica de lectura específica en una zona de disponibilidad específica, como se muestra en la siguiente figura.
Uso de un punto de conexión personalizado para una réplica de lectura de Aurora
Cuando el sistema está diseñado de esta manera, la evacuación de la zona de disponibilidad es una tarea mucho más sencilla. Por ejemplo, en la siguiente figura, cuando se produce un deterioro que afecta a la zona de disponibilidad 3, las operaciones de lectura y escritura en las zonas de disponibilidad 1 y 2 no se ven afectadas.
Uso de AZI para evitar impactos con réplicas de lectura de Amazon Aurora
Como alternativa, si la zona de disponibilidad 2 se viera afectada, las operaciones de lectura seguirían siendo satisfactorias en las zonas de disponibilidad 1 y 3. Posteriormente, si Amazon Aurora no ha realizado una conmutación por error automática en la base de datos principal, puede invocar manualmente una conmutación por error a una zona de disponibilidad diferente para restablecer la capacidad de procesar escrituras. Este enfoque evita tener que realizar cambios de configuración en las conexiones de la base de datos cuando necesite evacuar una zona de disponibilidad. Minimizar los cambios necesarios y mantener el proceso lo más simple posible hará que sea más fiable.
