Basculement et patching pour Azure Managed Redis

Pour concevoir des applications clientes robustes et efficaces, il demeure indispensable de comprendre précisément les mécanismes de basculement au sein du service Azure Managed 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 Managed 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 Managed 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 (ou « nœud ») exécute plusieurs processus de serveur Redis (appelés « partitions ») en parallèle. Plusieurs partitions permettent une utilisation plus efficace des processeurs virtuels sur chaque machine virtuelle ainsi que des performances plus élevées. Toutes les partitions Redis primaires ne se trouvent pas sur la même machine virtuelle ou sur le même nœud. En effet, les partitions primaires et les partitions de réplica sont réparties entre les deux nœuds. Étant donné que les partitions primaires utilisent plus de ressources de processeur que les partitions de réplica, cette approche permet d’exécuter plus de partitions primaires en parallèle. Chaque nœud dispose d’un processus de proxy hautes performances pour gérer les partitions, traiter les connexions et déclencher la réparation spontanée. Une partition peut être en panne pendant que les autres restent disponibles.

Pour plus d’informations sur Azure architecture Redis managée, vous trouverez here.

Explication d’un basculement

Un basculement se produit lorsqu’une ou plusieurs partitions de réplicas sont promues pour devenir des partitions primaires et que les anciennes partitions primaires ferment les connexions existantes. Un basculement peut être planifié ou non planifié.

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

• 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 d’un ou de plusieurs nœuds du cluster. La ou les partitions de réplica sur le ou les nœuds restants sont promues en serveur principal pour maintenir la disponibilité, mais le processus prend plus de temps. La partition de réplica doit tout d’abord détecter que sa partition principale n’est pas disponible avant de pouvoir démarrer le processus de basculement. La partition de 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 Redis géré Azure met régulièrement à jour votre cache avec les dernières fonctionnalités et correctifs de plateforme. Pour corriger un cache, le service effectue les étapes suivantes :

1. Le service crée de nouvelles machines virtuelles à jour pour remplacer toutes les machines virtuelles faisant l'objet d'un correctif.
2. Il promeut ensuite l’une des nouvelles machines virtuelles « responsable du cluster ».
3. Un par un, tous les nœuds faisant l'objet d'un correctif sont supprimés du cluster. Toutes les partitions de ces machines virtuelles seront rétrogradées et migrées vers l’une des nouvelles machines virtuelles.
4. Enfin, toutes les machines virtuelles qui ont été remplacées sont supprimées.

Chaque partition d’un cache en cluster est corrigée séparément et ne ferme pas les connexions à une autre partition.

É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 pour votre cache. Vous pouvez vous protéger davantage contre la perte de données en exportant des données et en activant la persistance.

Charge de cache supplémentaire

Chaque fois qu’un basculement se produit, les caches 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.

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

Les applications clientes peuvent recevoir certaines erreurs de leur instance Azure Redis managée. 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, la recréation de la connexion sans redémarrer l’application peut être effectuée à l’aide d’un modèle ForceReconnect.

Quelles sont les mises à jour incluses sous maintenance ?

La maintenance inclut les mises à jour suivantes :

• 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 incluent les correctifs des composants logiciels dans l’environnement d’hébergement, la mise à niveau des composants réseau ou la désactivation de matériel.

L’historique de maintenance apparaît-il dans le portail Azure ?

Pour en savoir plus sur l’historique de maintenance dans le portail Azure, consultez le journal Azure Activity pour votre instance de cache. L’événement « healthevent » est émis lorsque la maintenance commence.

Pour recevoir automatiquement des notifications, configurez une alerte sur le journal d’activité.

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. Votre application cliente perd probablement sa connexion à d’autres ressources réseau externes, mais également au service Redis managé Azure.

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 :

• Modèles de fiabilité - Modèles de conception cloud
• Conseils de nouvelle tentative pour les services Azure - Les meilleures pratiques pour les applications cloud
• Implémenter des nouvelles tentatives avec interruption exponentielle

Contenu connexe

• Résilience des connexions