Pour une instance cloud-native déployée sur plusieurs zones de disponibilité, si la zone principale compte au moins deux nœuds (et que le nombre total de nœuds est supérieur ou égal à trois), le système de haute disponibilité (HA) privilégie un basculement au sein de la zone principale en cas de défaillance du nœud maître. Cette fonctionnalité évite l'augmentation de la latence d'accès des applications qui résulterait d'un basculement vers une zone secondaire.
Cette fonctionnalité est activée par défaut pour les instances cloud-native utilisant une architecture standard ou en cluster, et ne nécessite aucune configuration manuelle. Cette rubrique prend l'architecture en cluster comme exemple.
Informations générales
Par défaut, un déploiement multi-zones de disponibilité place les nœuds maîtres et les nœuds réplicas de chaque shard d'une instance en cluster dans différentes zones de disponibilité au sein de la même région. Ces zones sont des emplacements physiquement isolés disposant d'alimentations électriques et de réseaux indépendants, ce qui confère à l'instance une grande capacité de reprise après sinistre.
Lorsque le nœud maître d'un shard tombe en panne, l'instance déclenche automatiquement un basculement afin de minimiser l'impact. Les clients sont généralement déployés dans la zone principale. Avant le basculement, le client et le nœud maître se trouvent dans la même zone de disponibilité, ce qui garantit la latence d'accès la plus faible possible. Le schéma ci-dessous illustre une architecture en cluster typique comportant trois shards.
En cas de défaillance du nœud maître d'un shard, le système de haute disponibilité (HA) promeut un nœud réplique situé dans la zone secondaire pour qu'il devienne le nouveau nœud maître. Cela oblige le client à accéder à l'instance via différentes zones de disponibilité, ce qui augmente considérablement la latence d'accès.
La latence d'accès entre différentes zones de disponibilité est bien plus élevée que celle au sein d'une même zone. Pour plus d'informations sur la latence moyenne entre les zones de disponibilité Alibaba Cloud, consultez Performances du réseau cloud.
Étant donné que Tair (Redis OSS-compatible) est une base de données en mémoire offrant hautes performances et faible latence, une latence réseau élevée affecte directement les temps de réponse de votre activité. Par conséquent, nous vous recommandons d'ajouter un nœud réplique supplémentaire à la zone principale de votre instance en cluster. Cette approche permet de concilier hautes performances, stabilité et capacité de reprise après sinistre.
En cas de défaillance du nœud maître, l'instance privilégie un basculement vers un nœud réplique situé dans la même zone de disponibilité. Après le basculement, le nouveau nœud maître reste dans la zone principale, ce qui évite toute augmentation de la latence d'accès.
Si une panne survient au niveau de la zone principale, l'instance effectue un basculement inter-zones, assurant ainsi une grande capacité de reprise après sinistre.
Fonctionnement
Tair (Redis OSS-compatible) vous permet de configurer de 2 à 5 nœuds pour chaque shard d'une instance en cluster.
Avec 2 nœuds, un nœud est déployé par défaut dans la zone principale et l'autre dans la zone secondaire.
Avec 3 nœuds, deux nœuds sont déployés par défaut dans la zone principale et un nœud dans la zone secondaire.
Avec 4 ou 5 nœuds, vous pouvez répartir les nœuds restants entre les zones principale et secondaire.
Cette rubrique prend pour exemple une architecture en cluster à trois shards et trois nœuds (deux nœuds dans la zone principale et un nœud dans la zone secondaire), comme illustré dans la figure suivante.
Si le nœud maître d'un shard tombe en panne, le système de haute disponibilité (HA) promeut préférentiellement le nœud réplique situé dans la zone principale pour qu'il devienne le nouveau nœud maître. Le client continue d'accéder à l'instance au sein de la même zone de disponibilité, ce qui empêche toute augmentation de la latence d'accès, comme illustré dans la figure suivante.
Procédure
-
Si vous ne disposez pas d'instance, créez une instance cloud-native déployée sur plusieurs zones de disponibilité. Pour plus d'informations, consultez Créer une instance.
Afin de garantir que la zone principale comporte au moins deux nœuds, configurez les paramètres suivants : Sur la page de configuration, définissez Read/Write Splitting (vous pouvez sélectionner Disable ou Enable. Cette fonctionnalité n'est pas disponible pour les instances en architecture cluster en mode de connexion directe sans proxy). Sélectionnez Nodes. Par exemple, l'option 3 Nodes fournit un nœud maître et deux nœuds répliques pour chaque shard dans une architecture en cluster. Si la séparation lecture/écriture est activée, les nœuds répliques peuvent également traiter les requêtes en lecture. Définissez le nombre de nœuds pour Node Allocation (Primary Zone). Le nombre de nœuds dans la zone secondaire est calculé comme suit : Nombre total de nœuds - Nœuds dans la zone principale. Nous vous recommandons de configurer au moins deux nœuds dans les zones principale et secondaire, soit un total d'au moins quatre nœuds.
Si vous disposez déjà d'une instance cloud-native déployée sur une seule zone de disponibilité, commencez par migrer l'instance vers un déploiement multi-zones de disponibilité. Ensuite, sur la page Gestion des nœuds, augmentez le nombre de nœuds dans la zone principale pour atteindre au moins deux.
Si vous disposez déjà d'une instance cloud-native déployée sur plusieurs zones de disponibilité, augmentez le nombre de nœuds dans la zone principale pour atteindre au moins deux sur la page Gestion des nœuds. Dans la section Node Distribution (Zone), cliquez sur Modify dans la colonne Actions pour la zone principale.
Si vous disposez d'une instance utilisant le mode de déploiement Classic , créez une nouvelle instance répondant aux exigences précédentes et migrez les données vers cette nouvelle instance en utilisant DTS pour effectuer une synchronisation unidirectionnelle au sein du même compte Alibaba Cloud.