Cette page a été traduite par l'API Cloud Translation.
Switch to English

Haute disponibilité

Cette page décrit la haute disponibilité pour les instances Memorystore pour Redis au niveau standard. Le niveau standard permet la haute disponibilité à travers les fonctionnalités de réplication et de basculement automatique. Cloud Memorystore pour Redis n'utilise pas Sentinel Redis pour la haute disponibilité.

Qu'est-ce que la haute disponibilité ?

Memorystore pour Redis fournit la haute disponibilité en répliquant un nœud Redis principal vers un nœud dupliqué. Le nœud dupliqué est une copie du nœud principal qui reflète les modifications apportées à ce dernier.

Chaque instance Memorystore pour Redis de niveau Standard est provisionnée avec un nœud principal et un nœud d'instance dupliquée. Les requêtes d'application sont redirigées vers le nœud principal. Les modifications apportées aux données du nœud principal sont copiées dans l'instance dupliquée à l'aide du protocole de réplication asynchrone Redis.

Avantages de la haute disponibilité

Si le nœud principal échoue, le service Memorystore pour Redis déclenche un basculement. Le service définit alors l'instance dupliquée comme nouvelle instance principale et, une fois la récupération terminée, l'ancienne instance principale devient l'instance dupliquée. En substance, les nœuds changent de rôle.

Pour tolérer les défaillances de zone, le nœud principal et le nœud dupliqué sont situés dans différentes zones d'une même région. Pour spécifier les zones de nœud principal et d'instance dupliquée, vous devez créer l'instance Redis à l'aide de l'outil gcloud.

Une instance de niveau standard conserve les données d'instance en cas de défaillance d'un seul nœud, car les données sont sauvegardées dans le nœud qui n'échoue pas. Si le nœud principal et le nœud dupliqué échouent simultanément en raison d'une défaillance multizone, les données ne peuvent pas être récupérées.

Lorsqu'un basculement est déclenché

Un basculement se produit lorsque le nœud Redis principal échoue. Lors du basculement, toutes les requêtes adressées au nouveau principal sont automatiquement redirigées vers le nœud dupliqué, et l'instance Memorystore pour Redis continue de répondre à votre application.

Impact du basculement sur vos applications

Lorsque le nœud principal bascule sur le nœud dupliqué, les connexions existantes à Memorystore pour Redis sont supprimées. Toutefois, lors de la reconnexion, votre application est automatiquement redirigée vers le nouveau nœud principal à l'aide de la même chaîne de connexion ou de la même adresse IP. Vous n'avez pas besoin de mettre à jour l'application après un basculement.

Pendant que le service Memorystore pour Redis fait basculer le nœud dupliqué en tant que nœud principal, l'instance Memorystore pour Redis est temporairement indisponible. Comme chaque nœud est situé dans une seule zone, les défaillances de zone peuvent prolonger le temps de récupération. Pendant ce temps, il n'y a qu'une seule copie des données.

Nouvelle tentative de connexion à l'instance après le basculement

Un basculement entraîne toujours une perte de connexion. Cette opération est nécessaire, car l'instance principale et l'instance dupliquée changent de rôle et d'adresses IP en interne. Cependant, vous devez toujours accéder à votre instance Redis à l'aide de son adresse IP statique.

En raison de cette perte de connexion, l'application doit effectuer une nouvelle tentative pour rétablir la connexion. La logique de nouvelle tentative doit utiliser l'intervalle exponentiel entre les tentatives pour garantir que vous ne surchargez pas votre instance avec un trop grand nombre de tentatives de requête. Outre la logique de nouvelle tentative, vous devez tester l'impact d'un basculement sur votre application en la testant avec un basculement manuel.

La plupart des clients Redis intègrent des fonctionnalités de nouvelle tentative que vous devez exploiter en cas de perte de connexion due au basculement.

Un basculement se produit dans les scénarios suivants :

Si vous mettez en œuvre une logique de répétition dans votre application pour gérer les pertes de connexion en raison de basculements, votre instance ne devrait pas subir d'impact significatif sur les performances. Généralement, les problèmes ne surviennent que si la logique de nouvelle tentative n'est pas mise en place.

Comment afficher l'état pour la haute disponibilité

Vous pouvez afficher les métriques de haute disponibilité de votre instance Redis à l'aide de la suite des opérations Google Cloud. Pour en savoir plus sur les métriques fournies par la suite des opérations Google Cloud pour Memorystore pour Redis, consultez la page Surveiller des instances Redis. Pour en savoir plus sur l'utilisation de la suite des opérations Google Cloud avec Google Cloud, consultez la documentation de Stackdriver Monitoring.

Pour afficher l'état de la réplication native fournie par Redis, vous pouvez émettre la commande INFO de Redis vers l'instance Cloud Memorystore pour Redis.

Étape suivante