Configurer la persistance des données pour une instance Azure Cache pour Redis

La persistance Redis vous permet de conserver les données stockées dans l’instance de cache. En cas de défaillance matérielle, l’instance de cache est réhydratée avec les données du fichier de persistance lorsqu’elle est remise en ligne. La possibilité de conserver des données est un moyen important d’améliorer la durabilité d’une instance de cache, car toutes les données du cache sont stockées en mémoire. Une perte de données est possible si une défaillance se produit là où les nœuds de cache sont en panne. La persistance doit être un élément clé de votre stratégie de haute disponibilité et récupération d’urgence avec Azure Cache pour Redis.

Étendue de la disponibilité

Types de persistance des données dans Redis

Vous disposez de deux options pour la persistance avec Azure Cache pour Redis : le format de base de données Redis (RDB) et le format Append-only File (AOF) :

• Persistance RDB : quand vous utilisez la persistance RDB, Azure Cache pour Redis conserve un instantané de votre cache au format binaire. L’instantané est enregistré dans un compte de stockage Azure. La fréquence de sauvegarde configurable détermine la fréquence de conservation de l’instantané. Si un événement catastrophique se produit et provoque la désactivation du cache principal et du réplica, le cache est automatiquement reconstruit à l’aide de l’instantané le plus récent. Découvrez-en plus sur les avantages et les inconvénients de la persistance RDB.
• Persistance AOF : lorsque vous utilisez la persistance AOF, Azure Cache pour Redis enregistre chaque opération d’écriture dans un journal. Le journal est enregistré au moins une fois par seconde dans un compte de stockage Azure. Si un événement catastrophique se produit et provoque la désactivation du cache principal et du réplica, le cache est automatiquement reconstruit à l’aide des opérations d’écriture stockées. Découvrez-en plus sur les avantages et les inconvénients de la persistance AOF.

Les fonctionnalités de persistance Azure Cache pour Redis sont destinées à être utilisées pour automatiquement restaurer des données dans le même cache après une perte de données. Les fichiers de données persistants RDB/AOF ne peuvent pas être importés dans un nouveau cache ou dans le cache existant. Pour déplacer des données entre les caches, utilisez la fonctionnalité Importation et exportation. Pour plus d’informations, consultez Importer et exporter des données dans Azure Cache pour Redis.

Pour générer une sauvegarde des données qui peuvent être ajoutées à un nouveau cache, vous pouvez écrire des scripts automatisés à l’aide de PowerShell ou de l’interface CLI pour exporter régulièrement des données.

Conditions préalables et limitations

Les fonctionnalités de persistance sont destinées à être utilisées pour restaurer des données dans le même cache après une perte de données.

• Les fichiers de données persistants RDB/AOF ne peuvent pas être importés dans un nouveau cache ou dans le cache existant. Utilisez la fonctionnalité Import/Export à la place.
• La persistance n’est pas prise en charge avec les caches utilisant la géoréplication passive ou la géoréplication active.
• Dans le niveau Premium, la persistance AOF n’est pas prise en charge avec plusieurs réplicas.
• Dans le niveau Premium, les données doivent être conservées dans un compte de stockage dans la même région que l’instance de cache.
• Au niveau Premium, les comptes de stockage dans différents abonnements peuvent être utilisés pour conserver les données si l’identité managée est utilisée pour se connecter au compte de stockage.

Différences de persistance entre les niveaux Premium et Enterprise

Dans le niveau Premium, les données sont conservées directement dans un compte Stockage Azure que vous possédez et gérez. Stockage Azure chiffre automatiquement les données lorsqu’elles sont persistantes, mais vous pouvez également utiliser vos propres clés pour le chiffrement. Pour plus d’informations, consultez Clés gérées par le client pour le chiffrement Stockage Azure.

Dans les niveaux Enterprise et Enterprise Flash, les données sont conservées sur un disque managé attaché directement à l’instance de cache. L’emplacement n’est pas configurable ni accessible à l’utilisateur. L’utilisation d’un disque managé augmente les performances de persistance. Le disque est chiffré à l’aide de clés managées Microsoft (MMK) par défaut, mais vous pouvez également utiliser des clés gérées par le client (CMK). Pour plus d’informations, consultez Gestion du chiffrement des données.

Configurer la persistance des données à l’aide du portail Azure

Configurer la persistance des données à l’aide de PowerShell et d’Azure CLI

New-AzRedisEnterpriseCache -Name "MyCache" -ResourceGroupName "MyGroup" -Location "West US" -Sku "Enterprise_E10" -RdbPersistenceEnabled -RdbPersistenceFrequency "1h"

Update-AzRedisEnterpriseCacheDatabase -Name "MyCache" -ResourceGroupName "MyGroup" -RdbPersistenceEnabled -RdbPersistenceFrequency "12h"

az redis create --location westus2 --name MyRedisCache --resource-group MyResourceGroup --sku Premium --vm-size p1 --redis-configuration @"config_rdb.json"

az redis update --name MyRedisCache --resource-group MyResourceGroup --set "redisConfiguration.rdb-storage-connection-string"="BlobEndpoint=https//..." "redisConfiguration.rdb-backup-enabled"="true" "redisConfiguration.rdb-backup-frequency"="15" "redisConfiguration.rdb-backup-max-snapshot-count"="1"

az redisenterprise create --cluster-name "cache1" --resource-group "rg1" --location "East US" --sku "Enterprise_E10" --persistence rdb-enabled=true rdb-frequency="1h" 

az redisenterprise database update --cluster-name "cache1" --resource-group "rg1" --persistence rdb-enabled=true rdb-frequency="12h" 

Gestion du chiffrement des données

Étant donné que la persistance Redis crée des données au repos, le chiffrement de ces données est une préoccupation importante pour de nombreux utilisateurs. Les options de chiffrement varient en fonction du niveau d’Azure Cache pour Redis utilisé.

Avec le niveau Premium, les données sont diffusées directement à partir de l’instance de cache vers Stockage Azure lorsque la persistance est lancée. Vous pouvez utiliser différentes méthodes de chiffrement avec Stockage Azure, notamment les clés gérées par Microsoft, les clés gérées par le client et les clés fournies par le client. Pour plus d’informations sur les méthodes de chiffrement, consultez Chiffrement du Stockage Azure pour les données au repos.

Avec les niveaux Enterprise et Enterprise Flash, les données sont stockées sur un disque managé monté sur l’instance de cache. Par défaut, le disque contenant les données de persistance et le disque du système d’exploitation sont chiffrés à l’aide de clés gérées par Microsoft. Une clé gérée par le client (CMK) peut également être utilisée pour contrôler le chiffrement des données. Pour obtenir des instructions, consultez Chiffrement sur les caches de niveau Enterprise.

Forum aux questions sur la persistance

La liste suivante présente différentes réponses aux questions les plus fréquemment posées sur la persistance du Cache Redis Azure.

• Puis-je activer la persistance sur un cache créé précédemment ?
• Puis-je activer la persistance AOF et RDB en même temps ?
• Comment la persistance fonctionne-t-elle avec la géoréplication ?
• Quel modèle de persistance dois-je choisir ?
• Que se passe-t-il si j’ai mis à l’échelle vers une taille différente et si une sauvegarde antérieure à l’opération de mise à l’échelle, est restaurée ?
• Puis-je utiliser le même compte de stockage pour une persistance dans deux caches différents ?
• Suis-je facturé pour le stockage utilisé dans la persistance des données
• Quelle est la fréquence d’écriture de la persistance RDB et AOF dans mes objets blob et dois-je activer la suppression réversible ?
• Le fait d’avoir des exceptions de pare-feu sur le compte de stockage affecte la persistance
• Comment savoir si la suppression réversible est activée sur mon compte de stockage ?

Persistance RDB

• Puis-je modifier la fréquence de sauvegarde RDB après avoir créé le cache ?
• Pourquoi y a-t-il un délai supérieur à 60 minutes entre les sauvegardes si la fréquence de sauvegarde RDB est de 60 minutes ?
• Qu’advient-il des anciennes sauvegardes RDB quand une nouvelle sauvegarde est effectuée ?

Persistance AOF

• Quand dois-je utiliser un deuxième compte de stockage ?
• La persistance AOF affecte-t-elle le débit, la latence ou les performances de mon cache ?
• Comment puis-je supprimer le deuxième compte de stockage ?
• Qu’est-ce qu’une réécriture et comment affecte-t-elle mon cache ?
• À quoi dois-je attendre lors de la mise à l’échelle d’un cache avec la persistance AOF activée ?
• Comment sont organisées mes données AOF dans le stockage ?
• Puis-je activer la persistance AOF si j’ai plusieurs réplicas ?

Puis-je activer la persistance sur un cache créé précédemment ?

Oui, vous pouvez configurer la persistance lors de la création du cache ou sur les caches Premium, Enterprise ou Enterprise Flash existants.

Puis-je activer la persistance AOF et RDB en même temps ?

Non, vous pouvez activer RDB ou AOF, mais pas les deux en même temps.

Comment la persistance fonctionne-t-elle avec la géoréplication ?

Si vous activez la persistance des données, vous ne pouvez pas activer la géoréplication pour votre cache.

Quel modèle de persistance dois-je choisir ?

La persistance AOF enregistre chaque écriture dans un journal, ce qui a un impact significatif sur le débit. par rapport à la persistance AOF avec RDB, qui enregistre les sauvegardes selon l’intervalle de sauvegarde configuré avec un impact minimal sur les performances. Choisissez la persistance AOF si votre objectif principal est de minimiser la perte de données et si vous pouvez gérer un débit inférieur pour votre cache. Choisissez la persistance RDB si vous souhaitez maintenir un débit optimal de votre cache mais avez quand même besoin d’un mécanisme de récupération de données.

• Découvrez-en plus sur les avantages et les inconvénients de la persistance RDB.
• Découvrez-en plus sur les avantages et les inconvénients de la persistance AOF.

Pour plus d’informations sur les performances lors de l’utilisation de persistance AOF, consultez La persistance affecte-t-elle le débit, la latence ou les performances de mon cache ?

La persistance AOF affecte-t-elle le débit, la latence ou les performances de mon cache ?

La persistance AOF affecte le débit. AOF s’exécute à la fois sur le processus principal et réplica. Par conséquent, vous voyez une charge du processeur et du serveur plus élevée pour un cache avec persistance AOF qu’un cache identique sans persistance AOF. AOF offre la meilleure cohérence avec les données en mémoire, car chaque écriture et chaque suppression sont conservées avec seulement quelques secondes de retard. Le compromis est que l’AOF est plus gourmand en calcul.

Tant que la charge du processeur et celle du serveur sont toutes deux inférieures à 90 %, il y a une pénalité sur le débit, mais le cache fonctionne normalement. Au-delà de 90 % de charge du processeur et du serveur, la pénalité de débit peut être beaucoup plus élevée et la latence de toutes les commandes traitées par le cache augmente. En effet, la latence augmente car la persistance AOF s’exécute à la fois sur le processus principal et le réplica, augmentant la charge sur le nœud utilisé et plaçant la persistance sur le chemin critique des données.

Que se passe-t-il si j’ai mis à l’échelle vers une taille différente et si une sauvegarde antérieure à l’opération de mise à l’échelle, est restaurée ?

Pour la persistance RDB et AOF :

• Si vous avez effectué une mise à l’échelle vers une plus grande taille, il n’y a aucun effet.
• Si vous avez mis à l’échelle vers une taille plus petite et que vous avez un paramètre personnalisé de bases de données supérieur à la limite des bases de données pour votre nouvelle taille, les données de ces bases de données ne sont pas restaurées. Pour en savoir plus, voir Les paramètres personnalisés de mes bases de données sont-ils affectés au cours de la mise à l’échelle ?
• Si vous avez mis à l’échelle vers une plus petite taille et que l’espace est insuffisant pour contenir toutes les données issues de la dernière sauvegarde, les clés sont supprimées lors du processus de restauration. En général, les clés sont éliminées avec la stratégie d’éviction allkeys-lru.

Puis-je utiliser le même compte de stockage pour la persistance dans deux caches différents ?

Non, vous devez utiliser différents comptes de stockage pour différents caches. Chaque cache doit avoir son propre compte de stockage à configurer pour la persistance.

Suis-je facturé pour le stockage utilisé dans la persistance des données ?

• Pour les caches Premium, vous êtes facturé pour le stockage utilisé selon le modèle de tarification du compte de stockage utilisé.
• Pour les caches Enterprise et Enterprise Flash, vous n’êtes pas facturé pour le stockage sur disque managé. Il est inclus dans le prix.

Quelle est la fréquence d’écriture de la persistance RDB et AOF dans mes objets blob et dois-je activer la suppression réversible ?

Nous vous recommandons d’éviter d’activer la suppression réversible sur les comptes de stockage lorsqu’ils sont utilisés avec la persistance des données Azure Cache pour Redis avec le niveau Premium. La persistance RDB et AOF peut écrire dans vos objets blobs à une fréquence de quelques heures, de quelques minutes ou d’une seconde. En outre, l’activation de la suppression réversible sur un compte de stockage signifie qu’Azure Cache pour Redis ne peut pas réduire les coûts de stockage en supprimant les données de sauvegarde anciennes.

La suppression réversible peut rapidement s’avérer coûteuse avec les tailles de données typiques d’un cache qui effectue également les opérations d’écriture chaque seconde. Pour plus d’informations sur les coûts liés à la suppression réversible, consultez Tarification et facturation.

Puis-je modifier la fréquence de sauvegarde RDB après avoir créé le cache ?

Oui, vous pouvez modifier la fréquence de sauvegarde pour la persistance RDB à l’aide du portail Azure, de l’interface CLI ou de PowerShell.

Pourquoi, si la fréquence de sauvegarde RDB est de 60 minutes, y a-t-il un délai supérieur à 60 minutes entre les sauvegardes ?

L’intervalle de fréquence de sauvegarde avec la persistance RDB ne démarre qu’une fois le processus de sauvegarde précédent terminé. Si la fréquence de sauvegarde est de 60 minutes et que l’exécution d’un processus de sauvegarde prend 15 minutes, la sauvegarde suivante ne démarre que 75 minutes après l’heure de début de la sauvegarde précédente.

Qu’advient-il des anciennes sauvegardes RDB quand une nouvelle sauvegarde est effectuée ?

Toutes les sauvegardes avec la persistance RDB à l’exception de la plus récente sont supprimées automatiquement. Cette suppression peut ne pas avoir lieu immédiatement, mais les anciennes sauvegardes ne sont pas conservées indéfiniment. Si vous utilisez le niveau Premium pour la persistance et que la suppression réversible est activée pour votre compte de stockage, le paramètre de suppression réversible s’applique et les sauvegardes existantes continuent d’y résider à l’état de suppression réversible.

Quand dois-je utiliser un deuxième compte de stockage ?

Utilisez un deuxième compte de stockage pour la persistance AOF lorsque vous pensez que vous avez plus d’opérations ensemblistes que prévu définies sur le cache. La configuration du deuxième compte de stockage permet de vous assurer que votre cache n’atteindra pas les limites de bande passante de stockage. Cette option est uniquement disponible pour les caches de niveau Premium.

Comment puis-je supprimer le deuxième compte de stockage ?

Vous pouvez supprimer le compte de stockage secondaire pour la persistance AOF en définissant le deuxième compte de stockage de manière à ce qu’il soit identique au premier compte de stockage. Pour les caches existants, accédez à Persistance des données dans le menu Ressource de votre cache. Pour désactiver la persistance AOF, sélectionnez Désactivé.

Qu’est-ce qu’une réécriture et comment affecte-t-elle mon cache ?

Lorsque le fichier AOF devient suffisamment volumineux, une réécriture est automatiquement mise en file d’attente dans le cache. La réécriture redimensionne le fichier AOF avec l’ensemble minimal d’opérations nécessaires pour créer le jeu de données en cours. Durant les réécritures, vous pouvez vous attendre à atteindre plus rapidement les limites de performances, en particulier lors du traitement de grands jeux de données. Les réécritures s’effectueront moins souvent au fur et à mesure que le fichier AOF deviendra volumineux, mais elles prennent un temps considérable le cas échéant.

À quoi dois-je attendre lors de la mise à l’échelle d’un cache avec la persistance AOF activée ?

Si le fichier AOF est volumineux au moment de la mise à l’échelle, attendez-vous à ce que l’opération de mise à l’échelle soit plus longue que prévu, étant donné qu’elle recharge le fichier une fois la mise à l’échelle terminée.

Pour en savoir plus sur la mise à l’échelle, consultez Que se passe-t-il si j’ai mis à l’échelle vers une taille différente et si une sauvegarde antérieure à l’opération de mise à l’échelle est restaurée ?

Comment sont organisées mes données AOF dans le stockage ?

Lorsque vous utilisez le niveau Premium, les données stockées dans des fichiers AOF sont divisées en plusieurs objets blob de pages par partition. Par défaut, la moitié des objets blob sont enregistrés dans le compte de stockage principal et la moitié sont enregistrés dans le compte de stockage secondaire. Le fractionnement des données entre plusieurs objets blob de pages et deux comptes de stockage différents augmente les performances.

Si le taux maximal d’écritures dans le cache n’est pas très élevé, cette performance supplémentaire peut ne pas être nécessaire. Dans ce cas, la configuration du compte de stockage secondaire peut être supprimée. Tous les fichiers AOF sont stockés dans le seul compte de stockage principal. Le tableau suivant montre le nombre total d’objets blob de pages utilisés pour chaque niveau tarifaire :

Lorsque le clustering est activé, chaque partition dans le cache a son propre ensemble d’objets blob de pages, comme indiqué dans le tableau précédent. Par exemple, un cache P2 avec trois partitions distribue son fichier AOF entre 48 objets blob de pages : seize objets blob par partition, avec trois partitions.

Après une réécriture, deux jeux de fichiers AOF se trouvent dans le stockage. Les réécritures se produisent en arrière-plan et s’ajoutent au premier jeu de fichiers. Les opérations de définition, envoyées au cache lors de la réécriture, sont ajoutées au second jeu. Une sauvegarde est stockée temporairement pendant la réécriture en cas de défaillance. La sauvegarde est rapidement supprimée après la fin d’une réécriture. Si la suppression réversible est activée pour votre compte de stockage, le paramètre de suppression réversible s’applique et les sauvegardes existantes continuent d’y résider à l’état de suppression réversible.

Le fait d’avoir des exceptions de pare-feu sur le compte de stockage affecte-t-il la persistance ?

Oui. L’utilisation de paramètres de pare-feu sur le compte de stockage peut empêcher le fonctionnement de la fonctionnalité de persistance. Vous pouvez voir s’il existe des erreurs dans les données persistantes en affichant la métrique Erreurs. Cette métrique indique si le cache ne peut pas rendre des données persistantes en raison de restrictions de pare-feu sur le compte de stockage ou d’autres problèmes.

Pour utiliser la persistance de données avec un compte de stockage avec un pare-feu configuré, utilisez l’authentification basée sur une identité managée pour vous connecter au stockage. L’utilisation de l’identité managée ajoute l’instance de cache à la liste des services approuvés, ce qui facilite l’exécution des exceptions de pare-feu. Si vous n’utilisez pas d’identité managée et que vous autorisez plutôt un compte de stockage à l’aide d’une clé, les exceptions de pare-feu sur le compte de stockage ont tendance à interrompre le processus de persistance. Cela s’applique uniquement à la persistance dans le niveau Premium.

Puis-je activer la persistance AOF si j’ai plusieurs réplicas ?

Avec le niveau Premium, vous ne pouvez pas utiliser la persistance AOF (Append-only File) avec plusieurs réplicas. Dans les niveaux Enterprise et Enterprise Flash, l’architecture de réplica est plus compliquée, mais la persistance AOF est prise en charge lorsque les caches Enterprise sont utilisés dans un déploiement redondant interzone.

Comment savoir si la suppression réversible est activée sur mon compte de stockage ?

Sélectionnez le compte de stockage utilisé par votre cache pour la persistance. Dans le menu Ressource, sélectionnez Protection des données. Dans le volet de travail, vérifiez l’état de Activer la suppression réversible pour les blob. Pour plus d’informations concernant la suppression réversible dans les comptes de stockage Azure, consultez l’article Activer la suppression réversible pour les objets blob.

Étapes suivantes

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

• Niveaux de service Premium Azure Cache pour Redis
• Ajouter des réplicas à Azure Cache pour Redis