En una instancia cloud-native multizona, si la zona principal cuenta con dos o más nodos (y el total es de tres o más), el sistema de alta disponibilidad (HA) prioriza el failover dentro de la zona principal cuando falla el nodo maestro. Esta función evita el aumento en la latencia de acceso a la aplicación que se produciría al realizar un failover hacia una zona secundaria.
Esta función está habilitada de forma predeterminada para las instancias cloud-native que utilizan arquitectura estándar o de clúster, y no requiere configuración manual. Este tema toma como ejemplo la arquitectura de clúster.
Contexto
De forma predeterminada, un despliegue multizona distribuye los nodos maestros y réplica de cada shard de una instancia de clúster en distintas zonas de disponibilidad dentro de la misma región. Estas zonas son ubicaciones físicamente aisladas con suministro eléctrico y redes independientes, lo que otorga a la instancia una alta capacidad de recuperación ante desastres.
Cuando falla el nodo maestro de un shard, la instancia desencadena automáticamente un failover para minimizar el impacto. Por lo general, los clientes se despliegan en la zona principal. Antes del failover, el cliente y el nodo maestro residen en la misma zona de disponibilidad, lo que garantiza la menor latencia de acceso posible. El siguiente diagrama muestra una arquitectura típica de clúster con tres shards.
Si falla el nodo maestro de un shard, el sistema de alta disponibilidad (HA) promueve un nodo réplica de la zona secundaria para convertirlo en el nuevo nodo maestro. Esto obliga al cliente a acceder a la instancia a través de distintas zonas de disponibilidad, lo que incrementa significativamente la latencia de acceso.
La latencia de acceso entre diferentes zonas de disponibilidad es mucho mayor que dentro de una sola zona. Para obtener detalles sobre la latencia promedio entre las zonas de disponibilidad de Alibaba Cloud, consulte Cloud Network Performance.
Dado que Tair (Redis OSS-compatible) es una base de datos en memoria de alto rendimiento y baja latencia, una latencia de red elevada afecta directamente los tiempos de respuesta de su negocio. Por lo tanto, se recomienda agregar un nodo réplica adicional a la zona principal de su instancia de clúster. Este enfoque equilibra el alto rendimiento y la estabilidad con una sólida recuperación ante desastres.
Cuando falla el nodo maestro, la instancia realiza preferentemente un failover hacia un nodo réplica dentro de la misma zona de disponibilidad. Tras el failover, el nuevo nodo maestro permanece en la zona principal, lo que evita el aumento de la latencia de acceso.
Si ocurre un fallo de zona en la zona principal, la instancia ejecuta un failover entre zonas, lo que proporciona una alta capacidad de recuperación ante desastres.
Funcionamiento
Tair (Redis OSS-compatible) permite configurar de 2 a 5 nodos para cada shard de una instancia de clúster.
Con 2 nodos, de forma predeterminada se despliega un nodo en la zona principal y el otro en la zona secundaria.
Con 3 nodos, de forma predeterminada se despliegan dos nodos en la zona principal y uno en la zona secundaria.
Con 4 o 5 nodos, puede distribuir los nodos restantes entre las zonas principal y secundaria.
Este tema utiliza como ejemplo una arquitectura de clúster de tres shards y tres nodos (dos nodos en la zona principal y uno en la zona secundaria), como se muestra en la siguiente figura.
Si falla el nodo maestro de un shard, el sistema de alta disponibilidad (HA) promueve preferentemente el nodo réplica de la zona principal para convertirlo en el nuevo nodo maestro. El cliente continúa accediendo a la instancia dentro de la misma zona de disponibilidad, lo que evita el aumento de la latencia de acceso, como se ilustra en la siguiente figura.
Procedimiento
-
Si no cuenta con una instancia, cree una instancia cloud-native multizona. Para obtener más información, consulte Create an instance.
Para asegurarse de que la zona principal tenga como mínimo dos nodos, configure los siguientes ajustes: En la página de configuración, configure Read/Write Splitting (puede seleccionar Disable o Enable. Esta función no está disponible para instancias con arquitectura de clúster en modo de conexión directa sin proxy). Seleccione Nodes. Por ejemplo, 3 Nodes proporciona un nodo maestro y dos nodos réplica para cada shard en una arquitectura de clúster. Si la división de lectura/escritura está habilitada, los nodos réplica también pueden atender solicitudes de lectura. Establezca el número de nodos en Node Allocation (Primary Zone). El número de nodos en la zona secundaria se calcula como: Nodos - Nodos en la zona principal. Se recomienda configurar como mínimo dos nodos tanto en la zona principal como en la secundaria, para un total de al menos cuatro nodos.
Si ya tiene una instancia cloud-native de zona única, primero migrate the instance to a multi-availability zone deployment. Luego, en la página Node Management, aumente el número de nodos en la zona principal a como mínimo dos.
Si ya tiene una instancia cloud-native multizona, aumente el número de nodos en la zona principal a como mínimo dos en la página Node Management. En la sección Node Distribution (Zone), haga clic en Modify en la columna Actions correspondiente a la zona principal.
Si tiene una instancia que utiliza el modo de despliegue Classic, cree una nueva instancia que cumpla con los requisitos anteriores y migre los datos a la nueva instancia mediante DTS to perform one-way synchronization in the same Alibaba Cloud account.