Guide pratique pour administrer le Cache Azure pour Redis

  • Article

Cet article explique comment effectuer des tâches d’administration, telles que le redémarrage, le Canal de mise à jour et Planifier les mises à jour, pour vos instances Azure Cache pour Redis.

Redémarrer

À gauche, le panneau Redémarrer vous permet de redémarrer un ou plusieurs nœuds de votre cache. Cette fonctionnalité de redémarrage vous permet de tester votre application pour garantir la résilience en cas de panne d’un nœud de cache.

Important

Le redémarrage n’est pas encore disponible pour le niveau Enterprise. Il l’est pour tous les autres niveaux.

Screenshot that highlights the Reboot menu option

Sélectionnez les nœuds à relancer, puis sélectionnez Redémarrer.

Screenshot that shows which nodes you can reboot

Si vous avez un cache premium avec activation du clustering, vous pouvez sélectionner les partitions du cache à redémarrer.

screenshot of shard options

Pour redémarrer un ou plusieurs nœuds de votre cache, sélectionnez les nœuds concernés, puis sélectionnez Redémarrer. Si vous disposez d’un cache Premium avec clustering, sélectionnez les partitions à redémarrer, puis sélectionnez Redémarrer. Après quelques minutes, les nœuds sélectionnés sont redémarrés et sont de nouveau en ligne.

L’impact sur les applications clientes varie selon les nœuds que vous redémarrez.

  • Principal : lorsque le nœud principal est redémarré, Azure Cache pour Redis bascule sur le nœud de réplica et le promeut au niveau principal. Pendant ce basculement, il peut y avoir un court intervalle pendant lequel les connexions au cache peuvent échouer.
  • Réplica : lorsque le nœud de réplica est redémarré, il n’y a généralement aucun effet sur les clients du cache.
  • Principal et réplica : Lorsque les deux nœuds de cache sont redémarrés, Azure Cache pour Redis tente de redémarrer correctement les deux nœuds, en attendant que l’un se termine avant de redémarrer l’autre. En règle générale, il n’y a pas de perte de données. Toutefois, la perte de données peut toujours se produire en cas d’événements ou de défaillances de maintenance inattendus. Le redémarrage de votre cache plusieurs fois de suite augmente les risques de perte de données.
  • Nœuds d’un cache Premium avec activation du clustering : lorsque vous redémarrez le ou les nœuds d’un cache Premium et que le clustering est activé, le comportement des nœuds sélectionnés est le même que lorsque vous redémarrez un ou plusieurs nœuds correspondants d’un cache non cluster.

Forum aux questions sur le redémarrage

Quel nœud dois-je redémarrer pour tester mon application ?

Pour tester la résilience de votre application en cas de défaillance du nœud principal de votre cache, redémarrez le nœud Principal. Pour tester la résilience de votre application en cas de défaillance du nœud réplica, redémarrez le nœud réplica.

Est-il possible de redémarrer le cache pour effacer les connexions client ?

Oui, toutes les connexions clientes sont effacées si vous redémarrez le cache. Le redémarrage est pertinent lorsque chaque connexion cliente est utilisée en raison d’une erreur logique ou d’un bogue dans l’application cliente. Chaque niveau tarifaire a différentes limites de connexion client pour les différentes tailles. Une fois ces limites sont atteintes, aucune autre connexion client supplémentaire n’est acceptée. Redémarrer le cache permet d’effacer toutes les connexions client.

Important

Si vous réinitialisez votre cache pour effacer les connexions client, StackExchange.Redis se reconnecte automatiquement une fois le nœud Redis en ligne. Si le problème sous-jacent n’est pas résolu, les connexions client peuvent continuer à être utilisées.

Vais-je perdre les données dans mon cache si je redémarre ?

Si vous redémarrez à la fois les nœuds Principal et Réplica, toutes les données du cache (ou dans cette partition lorsque vous utilisez un cache Premium avec le clustering activé) risquent d’être sécurisé. Toutefois, les données peuvent être perdues dans certains cas. Le redémarrage des deux nœuds doit être pris avec précaution.

Si vous ne redémarrez qu’un seul nœud, les données ne sont généralement pas perdues, mais il y a un risque qu’elles le soient quand même. Par exemple, si le nœud principal est redémarré et qu’une opération d’écriture dans le cache est en cours, les données écrites dans le cache sont perdues. Vous êtes également susceptible de perdre des données lorsque vous redémarrez un nœud et que l’autre nœud se met hors service en même temps en raison d’une défaillance. Pour plus d’informations sur les causes possibles d’une perte de données, voir Qu’est-il arrivé à mes données dans Redis ?

Est-il possible de redémarrer mon cache à l’aide de PowerShell, de l’interface de ligne de commande ou d’autres outils de gestion ?

Oui. Pour connaître les instructions PowerShell, voir Redémarrer un Cache Azure pour Redis.

Puis-je redémarrer mon cache Enterprise ?

Non. Le redémarrage n’est pas disponible pour le niveau Enterprise. Il est disponible pour les niveaux De base, Standard et Premium. Les paramètres que vous voyez dans le menu Ressource sous Administration dépendent du niveau de votre cache. Vous ne voyez pas Redémarrer quand vous utilisez un cache à partir du niveau Enterprise.

Vider les données (préversion)

Lorsque vous utilisez les niveaux De base, Standard ou Premium d’Azure Cache pour Redis, vous voyez Vider les données dans le menu des ressources. L’opération Vider les données vous permet de supprimer ou de vider toutes les données de votre cache. Cette opération de vidage peut être utilisée avant les opérations de mise à l’échelle afin de réduire potentiellement le temps nécessaire à l’exécution de l’opération de mise à l’échelle sur votre cache. Vous pouvez également configurer pour exécuter l’opération de vidage régulièrement sur vos caches de développement/test pour maintenir l’utilisation de la mémoire dans case activée.

L’opération de vidage, lorsqu’elle est exécutée sur un cache en cluster, efface les données de toutes les partitions en même temps.

Important

Avant, l’opération de vidage était disponible seulement pour les caches de niveau Entreprise géorépliqués. Elle est maintenant disponible pour les niveaux De base, Standard et Premium.

Screenshot showing flush data selected in the resource menu of a cache instance.

Canal de mise à jour et planification des mises à jour

Sur la gauche, Planifier les mises à jour vous permet de choisir un canal de mise à jour et une fenêtre de maintenance pour votre instance de cache.

Toute instance de cache utilisant le canal de mise à jour Stable reçoit les mises à jour quelques semaines plus tard que les instances de cache utilisant le canal de mise à jour Préversion. Nous vous recommandons de choisir le canal de mise à jour Préversion pour vos charges de travail qui ne sont pas en production et qui sont moins critiques. Choisissez le canal de mise à jour Stable pour vos charges de travail les plus critiques qui sont en production. Tous les caches sont définis par défaut sur le canal de mise à jour Stable.

Important

Le changement de canal de mise à jour sur votre instance de cache entraîne un événement de mise à jour corrective dans votre cache pour appliquer les mises à jour appropriées. Pensez à changer le canal de mise à jour pendant votre fenêtre de maintenance.

Une fenêtre de maintenance vous permet de contrôler les jours et les heures de la semaine où les machines virtuelles hébergeant votre cache peuvent être mises à jour. Azure Cache pour Redis s’efforce de commencer et de finir la mise à jour du logiciel serveur Redis dans la fenêtre de temps que vous avez définie.

Important

Le canal de mise à jour et la fenêtre de maintenance s’appliquent aux mises à jour du serveur Redis, ainsi qu’aux mises à jour du système d’exploitation des machines virtuelles qui hébergent le cache. Le canal de mise à jour et la fenêtre de maintenance ne s’appliquent pas aux mises à jour du système d’exploitation hôte pour les hôtes qui hébergent des machines virtuelles de cache ou d’autres composants Azure Networking. Dans les rares cas où les caches sont hébergés sur de plus vieux modèles, la fenêtre de maintenance ne s’applique pas non plus aux mises à jour du système d’exploitation invité. Vous pouvez savoir si votre cache est sur un plus vieux modèle si le nom DNS du cache est résolu avec un suffixe cloudapp.net, chinacloudapp.cn, usgovcloudapi.net ou cloudapi.de.

Actuellement, aucune option n’est disponible pour configurer un canal de mise à jour ou des mises à jour planifiées pour un cache de niveau Entreprise.

Screenshot showing schedule updates

Pour spécifier une fenêtre de maintenance, cochez les jours qui vous intéressent et indiquez l’heure de début de la fenêtre de maintenance pour chaque jour. Ensuite, sélectionnez OK. L’heure de la fenêtre de maintenance est au format UTC et ne peut être configurée que par heure.

La fenêtre de maintenance minimale et par défaut pour les mises à jour est de cinq heures. Cette valeur n’est pas configurable à partir du portail Azure, mais vous pouvez la configurer dans PowerShell à l’aide du paramètre MaintenanceWindow de l’applet de commande New-AzRedisCacheScheduleEntry. Pour plus d’informations, voir Puis-je gérer les mises à jour planifiées à l’aide de PowerShell, de l’interface de ligne de commande ou de tout autre outil de gestion ?

Forum aux questions de la planification des mises à jour

Quand les mises à jour sont-elles effectuées si je n’utilise pas la fonctionnalité de planification des mises à jour ?

Si vous ne spécifiez pas une fenêtre de maintenance, les mises à jour peuvent être effectuées à tout moment.

Quels types de mises à jour sont exécutés au cours de la fenêtre de maintenance planifiée ?

Seules les mises à jour du serveur Redis sont exécutées au cours de la fenêtre de maintenance planifiée. La fenêtre de maintenance ne s’applique pas aux mises à jour d’Azure ou du système d’exploitation de la machine virtuelle.

Puis-je gérer les mises à jour planifiées à l’aide de PowerShell, de l’interface de ligne de commande ou de tout autre outil de gestion ?

Oui. Vous pouvez gérer vos mises à jour planifiées à l’aide des cmdlets de commande PowerShell suivantes :

Une mise à jour qui est couverte et gérée par la fonctionnalité Mises à jour planifiées peut-elle se produire en dehors de la fenêtre Mises à jour planifiées ?

Oui. En général, les mises à jour ne sont pas appliquées en dehors de la fenêtre Mises à jour planifiées configurée. De rares mises à jour de sécurité critiques peuvent être appliquées en dehors de la planification de mises à jour correctives, dans le cadre de notre stratégie de sécurité.

Étapes suivantes

En savoir plus sur les fonctionnalités d’Azure Cache pour Redis.