Comment administrer Azure Managed Redis (aperçu)
Cet article décrit comment effectuer des tâches d’administration telles que le redémarrage et la Mise à jour du canal et la planification des mises à jour pour vos instances Azure Managed Redis (préversion).
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.
Sélectionnez les nœuds à relancer, puis sélectionnez Redémarrer.
Si vous avez un cache premium avec activation du clustering, vous pouvez sélectionner les partitions du cache à redémarrer.
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.
- Primaire - Lorsque le nœud principal est redémarré, Azure Managed Redis bascule vers le nœud de réplica et le promeut en tant que nœud 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.
- À la fois primaire et réplique - Lorsque les deux nœuds de cache sont redémarrés, Azure Managed Redis tente de redémarrer correctement les deux nœuds, en attendant que l’un 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 ?
- Est-il possible de redémarrer le cache pour effacer les connexions client ?
- Vais-je perdre les données dans mon cache si je redémarre ?
- 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 ?
- Puis-je redémarrer mon cache Enterprise ?
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 utile lorsque toutes les connexions client sont utilisées, par exemple 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 toutes les données dans cette partition lorsque vous utilisez un cache Premium avec le clustering activé devraient être sécurisés. 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.
Vous devez également savoir que le redémarrage des deux nœuds n’entraîne pas d’évacuation des données. Si vous souhaitez effacer les données, utilisez la procédure d’évacuation à partir de la console du portail.
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. Le redémarrage n'est disponible que pour les niveaux Basic, 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
Lorsque vous utilisez les niveaux Basic, Standard ou Premium d’Azure Managed 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.
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 Managed Redis fait de son mieux pour démarrer et terminer la mise à jour du logiciel serveur Redis dans la fenêtre de temps spécifiée que vous définissez.
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.
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 ?
- Quels types de mises à jour sont exécutés au cours de la fenêtre de maintenance planifiée ?
- 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 ?
- 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 » ?
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 :
- Get-AzRedisCachePatchSchedule
- New-AzRedisCachePatchSchedule
- New-AzRedisCacheScheduleEntry
- Remove-AzRedisCachePatchSchedule
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é.