Partager via

Basculement et mise à jour corrective pour Azure Cache pour Redis

  • Article

Pour générer des applications clientes résilientes et réussies, il est essentiel de comprendre ce qu’est un basculement dans le service Azure Cache pour Redis. Un basculement peut faire partie des opérations de gestion planifiées, ou il peut être dû à des défaillances matérielles ou réseau non planifiées. Une utilisation courante du basculement du cache est fournie lorsque le service de gestion corrige les fichiers binaires Azure Cache pour Redis.

Dans cet article, vous trouverez les informations suivantes :

  • Qu’est-ce qu’un basculement ?
  • Comment le basculement se produit lors d’une mise à jour corrective.
  • Comment créer une application cliente résiliente.

Qu’est-ce qu’un basculement ?

Commençons par un aperçu du basculement pour Azure Cache pour Redis.

Un rapide résumé de l’architecture du cache

Un cache se compose de plusieurs machines virtuelles avec des adresses IP privées et distinctes. Chaque machine virtuelle, également appelée nœud, est connectée à un équilibreur de charge partagé avec une seule adresse IP virtuelle. Chaque nœud exécute le processus serveur Redis et est accessible en utilisant le nom d’hôte et les ports Redis. Chaque nœud est considéré comme un nœud principal ou réplica. Lorsqu’une application cliente se connecte à un cache, son trafic passe par cet équilibreur de charge et est automatiquement routé au nœud principal.

Dans un cache De base, le nœud unique est toujours un nœud principal. Un cache Standard ou Premium comprend deux nœuds : l’un est choisi comme nœud principal et l’autre est le réplica. Étant donné que les caches Standard et Premium ont plusieurs nœuds, un nœud peut être indisponible pendant que l’autre continue à traiter les requêtes. Les caches en cluster sont constitués de plusieurs partitions, chacune ayant un nœud principal et un nœud réplica distincts. Une partition peut être en panne pendant que les autres restent disponibles.

Notes

Un cache de base n’a pas plusieurs nœuds et n’offre pas de contrat de niveau de service (SLA) en matière de disponibilité. Les caches de base sont recommandés uniquement à des fins de développement et de test. Utilisez un cache Standard ou Premium pour un déploiement sur plusieurs nœuds afin d’augmenter la disponibilité.

Explication d’un basculement

Un basculement se produit lorsqu’un nœud réplica se promeut en nœud principal et que l’ancien nœud principal ferme des connexions existantes. Une fois le nœud principal rétabli, il remarque le changement de rôle et se rétrograde pour devenir un réplica. Il se connecte ensuite au nouveau nœud principal et synchronise les données. Un basculement peut être planifié ou non.

Un basculement planifié a lieu à deux moments différents :

  • Mises à jour système, telles que les mises à niveau du système d’exploitation ou les mises à jour correctives Redis.
  • Opérations de gestion, telles que la mise à l’échelle et le redémarrage.

Étant donné que les nœuds sont avertis à l’avance de la mise à jour, ils peuvent échanger des rôles de manière coopérative et indiquer rapidement la modification à l’équilibreur de charge. Un basculement planifié se termine généralement en moins de 1 seconde.

Un basculement non planifié peut se produire en raison d’une défaillance matérielle, d’une défaillance de réseau ou d’autres pannes inattendues du nœud principal. Le nœud réplica se promeut en nœud principal, mais le processus prend plus de temps. Un nœud réplica doit tout d’abord détecter que son nœud principal n’est pas disponible avant de pouvoir démarrer le processus de basculement. Le nœud réplica doit également vérifier que cette défaillance non planifiée n’est ni temporaire ni locale, afin d’éviter un basculement inutile. Ce retard de détection signifie qu’un basculement non planifié se termine généralement dans un délai de 10 à 15 secondes.

Comment la mise à jour corrective a-t-elle lieu ?

Le service Azure Cache pour Redis met régulièrement à jour votre cache avec les fonctionnalités et les correctifs les plus récents de la plateforme. Pour corriger un cache, le service effectue les étapes suivantes :

  1. Le service corrige d’abord le nœud de réplica.
  2. En coopération, le nœud réplica corrigé s’auto-promeut nœud réplica principal. Cette promotion est considérée comme un basculement planifié.
  3. L’ancien nœud principal redémarre pour accepter les nouveaux changements, puis revient comme nœud réplica.
  4. Le nœud réplica se connecte au nœud principal et synchronise les données.
  5. Une fois la synchronisation des données terminée, le processus de mise à jour corrective se répète pour les nœuds restants.

La mise à jour corrective étant un basculement planifié, le nœud réplica se promeut rapidement en nœud principal. Ensuite, le nœud commence à traiter les requêtes et les nouvelles connexions. Les caches de base n’ont pas de nœud réplica et sont indisponibles tant que la mise à jour n’est pas terminée. Chaque fragment d'un cache en cluster est corrigé séparément et ne ferme pas les connexions à un autre fragment.

Important

Les nœuds sont corrigés un à un pour éviter toute perte de données. Les caches de base subissent une perte de données. Les caches en cluster sont corrigés une partition à la fois.

Si plusieurs caches se trouvent dans le même groupe de ressources et la même région, ils sont également corrigés un à un. Les caches qui se trouvent dans des groupes de ressources différents ou des régions différentes peuvent être corrigés simultanément.

Étant donné que la synchronisation complète des données se produit avant la répétition du processus, il est peu probable que des données soient perdues lorsque vous utilisez un cache Standard ou Premium. Vous pouvez vous prémunir davantage contre la perte de données en exportant les données et en activant la persistance.

Charge de cache supplémentaire

Chaque fois qu’un basculement se produit, les caches Standard et Premium doivent répliquer les données d’un nœud à l’autre. Cette réplication entraîne une augmentation de la charge au niveau de la mémoire et du processeur du serveur. Si l’instance de cache est déjà très chargée, les applications clientes peuvent subir une latence accrue. Dans des cas extrêmes, les applications clientes peuvent recevoir des exceptions de délai d’expiration. Pour aider à atténuer l’effet d’une charge plus grande, configurez le paramètre maxmemory-reserved du cache.

Quel est l’impact d’un basculement sur mon application cliente ?

Des applications clientes pourraient recevoir des erreurs de leur Azure Cache pour Redis. Le nombre d’erreurs détectées par une application cliente dépend du nombre d’opérations en attente sur cette connexion au moment du basculement. Toute connexion acheminée via le nœud ayant fermé ses connexions rencontre des erreurs.

De nombreuses bibliothèques clientes peuvent lever différents types d’erreurs en cas d’interruption des connexions, à savoir :

  • Exceptions de délai d’attente
  • Exceptions de connexion
  • Exceptions de socket

Le nombre et le type d’exceptions dépendent de l’emplacement de la demande dans le chemin du code quand le cache ferme ses connexions. Par exemple, une opération qui envoie une requête mais qui ne reçoit pas de réponse quand le basculement se produit peut obtenir une exception de délai d’expiration. Les nouvelles requêtes sur l’objet de connexion fermé reçoivent des exceptions de connexion jusqu’à ce que la connexion soit rétablie.

La plupart des bibliothèques clientes tentent de se reconnecter au cache si elles sont configurées pour ce faire. Toutefois, des bogues imprévus peuvent parfois placer les objets de bibliothèque dans un état irrécupérable. Si les erreurs persistent plus longtemps qu’une durée préconfigurée, l’objet de connexion doit être recréé. Dans Microsoft.NET et d’autres langages orientés objet, il est possible de recréer la connexion sans redémarrer l’application à l’aide d’un modèle ForceReconnect.

Puis-je être notifié à l’avance d’une maintenance ?

Azure Cache pour Redis publie des notifications de maintenance de runtime via un canal de publication/d’abonnement (Pub/Sub) nommé AzureRedisEvents. De nombreuses bibliothèques clientes Redis populaires prennent en charge l’abonnement à des canaux Pub/Sub. La réception de notifications à partir du canal AzureRedisEvents est généralement un ajout simple à votre application cliente. Pour plus d’informations sur les événements de maintenance, consultez AzureRedisEvents.

Remarque

Le canal AzureRedisEvents n’est pas un mécanisme capable de vous avertir plusieurs jours ou heures à l’avance. Le canal peut informer les clients des événements de maintenance de serveur à venir, susceptibles d’affecter la disponibilité du serveur. AzureRedisEvents n'est disponible que pour les niveaux Basic, Standard et Premium.

Quelles sont les mises à jour incluses sous maintenance ?

La maintenance inclut ces mises à jour :

  • Mises à jour du serveur Redis : toutes les mises à jour ou correctifs des fichiers binaires du serveur Redis.
  • Mises à jour de machine virtuelle : toutes les mises à jour de la machine virtuelle hébergeant le service Redis. Les mises à jour de machine virtuelle comprennent des correctifs pour les composants de logiciels dans l’environnement d’hébergement à la mise à niveau des composants réseau ou à la désactivation de matériel.

La maintenance apparaît-elle dans l’intégrité du service dans le portail Azure avant un correctif ?

Non, la maintenance n’apparaît nulle part sous l’intégrité du service dans le portail ou n’importe quel autre endroit.

Combien de temps puis-je recevoir la notification avant la maintenance planifiée ?

Lorsque vous utilisez le canal AzureRedisEvents, vous êtes averti 15 minutes avant la maintenance.

Modifications de la configuration réseau du client

Certaines modifications de la configuration réseau côté client peuvent déclencher des erreurs de type Aucune connexion disponible. Ces modifications peuvent inclure :

  • Le remplacement de l’adresse IP virtuelle d’une application cliente entre les emplacements intermédiaires et de production.
  • Mise à l’échelle de la taille ou du nombre d’instances de votre application.

De telles modifications peuvent entraîner un problème de connectivité qui dure en général moins d’une minute. Il est probable que votre application client perde sa connexion avec d'autres ressources réseau externes, mais aussi avec le service Azure Cache pour Redis.

Intégrer la résilience

Vous ne pouvez pas éviter complètement les basculements. Au lieu de cela, écrivez vos applications clientes pour qu’elles soient résilientes aux interruptions de connexion et aux demandes ayant échoué. La plupart des bibliothèques de clients se reconnectent automatiquement au point de terminaison de cache, mais seules quelques-unes retentent les demandes ayant échoué. Selon le scénario de l’application, il peut être utile d’utiliser la logique de nouvelle tentative avec retrait.

Comment faire rendre mon application résiliente ?

Reportez-vous aux modèles de conception ci-dessous pour créer des clients résilients, en particulier aux modèles de disjoncteur et de nouvelle tentative :

Pour tester la résilience d’une application cliente, utilisez un redémarrage comme déclencheur manuel pour les interruptions de connexion.

De plus, nous vous recommandons d'utiliser les mises à jour planifiées pour choisir un canal de mise à jour et une fenêtre de maintenance pour votre cache afin d'appliquer les correctifs d'exécution Redis pendant des fenêtres hebdomadaires spécifiques. Ces fenêtres correspondent généralement à des périodes où le trafic de l’application cliente est faible pour éviter les incidents potentiels. Pour plus d’informations, consultez canal de mise à jour et planifier les mises à jour.

Pour plus d’informations, consultez Résilience des connexions.

Contenu connexe