Partager via

Basculement et mise à jour corrective pour Azure Cache pour Redis

  • S’applique à: ✅ Azure Cache for Redis

Important

Azure Cache pour Redis a annoncé sa chronologie de mise hors service pour toutes les références SKU. Nous vous recommandons de déplacer vos instances Azure Cache pour Redis existantes vers Azure Managed Redis dès que vous le pouvez.

Pour plus d’informations sur la mise hors service :

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 ces informations :

  • 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 une vue d’ensemble du basculement pour Azure Cache pour Redis.

Résumé rapide de l’architecture du cache

Un cache est construit de plusieurs machines virtuelles avec des adresses IP distinctes et privées. Chaque machine virtuelle, également appelée nœud, est connectée à un équilibreur de charge partagé avec une adresse IP virtuelle unique. Chaque nœud exécute le processus du serveur Redis et est accessible à l’aide du nom d’hôte et des 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 acheminé vers le nœud principal.

Dans un cache de base, le nœud unique est toujours un nœud principal. Dans un cache Standard ou Premium, il existe deux nœuds : l’un est choisi comme 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 demandes. Les caches en cluster sont constitués de nombreux fragments, chacun avec des nœuds principaux et répliques distincts. Un fragment peut être en panne alors que les autres restent disponibles.

Note

Un cache de base n’a pas plusieurs nœuds et n’offre pas de contrat de niveau de service (SLA) pour sa 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 à 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 principal et synchronise les données. Un basculement peut être planifié ou non.

Un basculement planifié a lieu pendant deux périodes différentes :

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

Étant donné que les nœuds reçoivent une notification préalable de la mise à jour, ils peuvent échanger des rôles de manière coopérative et mettre rapidement à jour l’équilibreur de charge de la modification. 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 réseau ou d’autres interruptions inattendues affectant le nœud principal. Le nœud réplique devient principal, mais le processus prend plus de temps. Un nœud de réplica doit 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 de réplique doit également vérifier que cette défaillance non planifiée n’est pas locale ou temporaire, 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 se produit la mise à jour corrective ?

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

  1. Le service met d’abord à jour le nœud réplique.
  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 prendre les nouvelles modifications et revient en tant que 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 demandes de maintenance et les nouvelles connexions. Les caches de base n’ont pas de nœud de réplica et ne sont pas disponibles tant que la mise à jour n’est pas terminée. Chaque partition d’un cache en cluster est corrigée séparément et ne ferme pas les connexions à une autre partition.

Important

Les nœuds sont corrigés un par un pour empêcher la perte de données. Les caches de base ont une perte de données. Les caches en cluster sont mis à jour un fragment à la fois.

Plusieurs caches dans le même groupe de ressources et la même région sont également corrigés un par un. Les caches qui se trouvent dans différents groupes de ressources ou différentes régions 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, la perte de données est peu probable lorsque vous utilisez un cache Standard ou Premium. Vous pouvez vous protéger davantage contre la perte de données en exportant des données et en activant la persistance.

Chargement supplémentaire du cache

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

Comment un basculement affecte-t-il mon application cliente ?

Les applications clientes peuvent recevoir certaines erreurs de leur Cache Azure pour Redis. Le nombre d’erreurs observées par une application cliente dépend du nombre d’opérations en attente sur cette connexion au moment du basculement. Toute connexion routée via le nœud qui a fermé ses connexions voit des erreurs.

De nombreuses bibliothèques clientes peuvent lever différents types d’erreurs lorsque les connexions se coupent, notamment :

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

Le nombre et le type d’exceptions dépendent de l’emplacement où la requête se trouve dans le chemin du code lorsque 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 reconnexion se produise correctement.

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

Puis-je être informé à l’avance de la maintenance ?

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

Note

Le AzureRedisEvents canal n’est pas un mécanisme qui peut vous avertir des jours ou des heures à l’avance. Le canal peut informer les clients de tous les événements de maintenance de serveur à venir susceptibles d’affecter la disponibilité du serveur. AzureRedisEvents est disponible uniquement pour les niveaux De base, 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 des machines virtuelles incluent la mise à jour corrective des composants logiciels dans l’environnement d’hébergement, la mise à niveau des composants réseau, ou la désaffectation des composants.

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 AzureRedisEvents canal, vous êtes averti 15 minutes avant la maintenance.

Modifications apportées à la configuration du réseau 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 :

  • Échange de l’adresse IP virtuelle d’une application cliente entre les environnements de staging et de production.
  • Mise à l’échelle de la taille ou du nombre d’instances de votre application.

Ces modifications peuvent entraîner un problème de connectivité qui dure généralement moins d’une minute. Votre application cliente perd probablement sa connexion à d’autres ressources réseau externes, mais également au 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 clientes se reconnectent automatiquement au point de terminaison du cache, mais peu d’entre elles tentent de réessayer les demandes ayant échoué. Selon le scénario d’application, il peut être judicieux d’utiliser une logique de réessai avec temporisation.

Comment 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 sauts de connexion.

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

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

Contenu connexe

  • Last updated on