Migrer des niveaux De base, Standard, Premium et Entreprise vers Azure Managed Redis

Cet article explique pourquoi et comment migrer du Cache Azure pour Redis (y compris les niveaux De base, Standard, Premium et Entreprise) vers Azure Managed Redis.

Vous apprendrez à propos de :

• Avantages du choix d’Azure Managed Redis sur les niveaux précédents.
• Principales différences de fonctionnalités entre les services.
• Stratégies de migration de vos données de cache.
• Méthodes pour garantir un processus de migration fluide.
• Conseils pour choisir le SKU et le niveau de performance Azure Managed Redis adaptés à vos besoins.
• Considérations et recommandations relatives à la mise à jour de vos applications clientes.

Que vous utilisiez des niveaux De base, Standard, Premium ouEnterprise ou OSS, ce guide vous aide à planifier et à exécuter votre migration vers Azure Managed Redis.

Le document se divise en deux sections. L’une concerne les instances d’entreprise. L’autre concerne les niveaux De base, Standard et Premium du Cache Azure pour Redis.

• Avantages du passage d’Entreprise à Azure Managed Redis
• Avantages du passage des caches De base, Standard ou Premium vers Azure Managed Redis

Avantages du passage d’Entreprise à Azure Managed Redis

Azure Managed Redis repose sur le logiciel Redis Enterprise avancé. Azure Managed Redis est une offre Azure première partie, ce qui signifie qu’il n’existe aucun composant de la Place de marché Azure impliqué et que les utilisateurs n’ont pas à effectuer de transactions avec la Place de marché séparément. Vous approvisionnez, gérez et payez azure Managed Redis comme n’importe quel autre service ou produit Azure natif.

Azure Managed Redis n’a pas besoin du nœud de quorum qui conduit à des ressources inutilisées et limite les régions ou clouds où Azure Cache pour Redis Enterprise peut être proposé. Azure Managed Redis est désormais disponible dans la plupart des régions Azure avec des plans pour être pris en charge dans d’autres clouds souverains. Pour plus d’informations sur le nœud de quorum, consultez les niveaux Enterprise et Enterprise Flash. En supprimant le nœud de quorum inutilisé, vous bénéficiez d’une rentabilité accrue, car tous les nœuds peuvent être utilisés en tant que nœuds de données.

Azure Managed Redis est redondant interzone par défaut.

Vous pouvez utiliser Azure Managed Redis sans haute disponibilité pour vos environnements de développement et de test. L’utilisation d’environnements hors production sans haute disponibilité réduit de moitié le coût de votre instance.

La structure de référence SKU pour Azure Managed Redis est basée sur vos besoins en mémoire et en performances. Au lieu de gérer les facteurs d’échelle ou la capacité comme avec Azure Cache pour Redis Enterprise, vous pouvez choisir parmi trois niveaux de performances dans Azure Managed Redis. Pour plus d’informations, consultez Choisir le niveau approprié.

Enfin, Azure Managed Redis offre l’authentification Microsoft Entra ID lorsque vous créez un cache pour améliorer la posture de sécurité de votre charge de travail.

Comparaison des fonctionnalités

Caractéristique	Azure Cache pour Redis Entreprise	Redis managé Azure
Version de Redis	7.2	7.4
Stratégie de clustering	OSS, Entreprise	OSS, Enterprise, non-clusterisé
Geo-replication	Active	Active
Accord de Niveau de Service (SLA)	Jusqu’à 99 999%	Jusqu’à 99 999%
Redondance de zone	Yes	*Oui avec haute disponibilité
Mode non haute disponibilité	No	Oui (pour dev/test)
Persistance des données	Oui (en préversion)	Yes
Croissance	Yes	Yes
Prise en charge des versions TLS	1.2,1.3	1.2,1.3
Authentification par Microsoft Entra ID	No	Yes
Prise en charge de la région Azure	Limité	Exigeante
Prise en charge du cloud souverain Azure	No	Oui (bientôt disponible)
Suffixe DNS du nom d’hôte	<name>.<region>.redisenterprise.cache.azure.net	<name>.<region>.redis.azure.net

* Lorsque la haute disponibilité est activée, Azure Managed Redis est redondant interzone dans les régions avec plusieurs zones de disponibilité.

Considérations à prendre en compte lorsque vous passez d’Entreprise à Azure Managed Redis

Azure Managed Redis utilise la même pile logicielle qu’Azure Cache pour Redis Enterprise. Vos applications existantes utilisant le niveau Entreprise n’ont donc pas besoin de nombreuses modifications. L’exception significative est la nécessité de modifier les informations d’identification de connexion.

Nom d’hôte et suffixe différents

Même si le logiciel principal pour Azure Cache pour Redis Enterprise et Azure Managed Redis est similaire, le suffixe DNS de votre nom d’hôte de cluster Redis est différent. Lorsque vous passez à Azure Managed Redis, votre application doit modifier le nom d’hôte du cluster Redis. Si vous utilisez des clés d’accès pour vous connecter à votre cache, vous devez également mettre à jour la clé d’accès qu’elle utilise pour se connecter au cache.

Important

Envisagez de mettre à jour le code qui se connecte au cache. Au lieu d’utiliser des clés d’accès, utilisez l’ID Microsoft Entra. Nous vous recommandons d’utiliser l’ID Microsoft Entra au lieu des clés d’accès.

Choix de la taille et du SKU Azure Managed Redis approprié

Azure Managed Redis offre de nombreuses tailles de mémoire et trois niveaux de performances. Vous pouvez lire plus d’informations sur les tailles de mémoire et les niveaux de performances ici en choisissant le niveau approprié.

Identifier la taille de mémoire de l’instance Azure Cache pour Redis Enterprise existante

Les instances azure Cache pour Redis Enterprise peuvent être mises à l’échelle pour fournir davantage de mémoire et plus de ressources de calcul. Il est donc important de noter le facteur de scale-out de votre cache. Le scale-out est également lié à la capacité, qui est essentiellement le nombre de machines virtuelles en cours d’exécution pour votre cluster.

Pour choisir la taille de mémoire Redis managée Azure appropriée :

1. Accédez au portail Azure, puis sélectionnez Vue d’ensemble dans le menu de ressources.
2. Vérifiez le champ État dans la vue d’ensemble de votre instance d’entreprise. Le champ État affiche la taille de mémoire de votre instance Redis Enterprise.

Examinons un scénario possible.

Dans le volet État de la vue d’ensemble, vous voyez En cours d’exécution - Entreprise 8 Go (2 x 4 Go). Cette notation signifie que le cache utilise actuellement une référence SKU E5 Entreprise avec une échelle de 2, ce qui génère un cache de 8 Go. Par conséquent, vous devez commencer par au moins 10 Go de cache sur Azure Managed Redis.

Dans ce cas, utilisez l’un des niveaux qui offrent 12 Go de mémoire.

Référence (SKU)	Niveau
M10	Memory Optimized
B10	Balanced
X10	Compute Optimized

Identifier le niveau de performances

Vous devez également prendre en compte si votre charge de travail est gourmande en mémoire ou en ressources de calcul intensives. Si votre instance d’entreprise actuelle est plus susceptible de manquer de mémoire avant le processeur, votre charge de travail est gourmande en mémoire. Envisagez de choisir le niveau de performances mémoire optimisée .

Si votre débit de charge de travail est intensif ou a trop de latence, votre charge de travail est gourmande en calcul. Envisagez de choisir le niveau de performances optimisé pour le calcul .

Si vous n’êtes pas sûr, vous pouvez commencer par le niveau de performances équilibré , car il offre un mélange sain de mémoire et de performances.

Si vous utilisez actuellement le niveau Flash Redis Enterprise, vous devez choisir le niveau Optimisé Flash.

Créer une instance Azure Managed Redis

Après avoir choisi le niveau de mémoire et de performances de votre nouvelle instance Azure Managed Redis, vous pouvez créer la nouvelle instance Azure Managed Redis. Pour plus d’informations sur la création d’un cache, consultez Démarrage rapide : Créer une instance Redis managée Azure.

Ensuite, vous devez choisir une stratégie pour déplacer vos données. Enfin, vous devez mettre à jour votre application pour utiliser le nouveau cache.

Mettre à jour l’application pour se connecter à l’instance Redis managée Azure

Une fois que vous avez créé une instance Redis managée Azure, vous devez modifier le point de terminaison/le nom d’hôte Redis et la clé d’accès de votre application pour pointer vers votre nouvelle instance Azure Managed Redis. Nous vous recommandons de publier ce changement de point de terminaison pendant les heures creuses, car cela entraîne un accroc dans la connectivité.

Note

Si vous vous connectez à votre instance Redis Enterprise existante via un point de terminaison privé, assurez-vous que votre nouveau cache Redis géré Azure est également appairé au réseau virtuel de votre application. Le nouveau cache doit avoir une configuration similaire à l’instance Redis Enterprise existante.

Vérifiez que votre application s’exécute comme prévu, puis supprimez votre instance Redis Enterprise précédente.

Déplacement de vos données de votre cache Entreprise vers un nouveau cache Redis managé Azure

Lors de la migration vers une instance Redis managée Azure, vous devez prendre en compte le meilleur moyen de déplacer vos données de l’instance Redis Enterprise existante vers votre nouvelle instance Azure Managed Redis. Si votre application peut tolérer la perte de données ou a d’autres mécanismes pour réalimenter le cache sans effets négatifs, vous ignorez cette étape et passez aux étapes suivantes.

Si votre application doit s’assurer que les données sont également migrées vers la nouvelle instance Azure Managed Redis, choisissez l’une des options suivantes :

Exportation et importation de données à l’aide d’un fichier RDB

• Avantages : conserve l’instantané des données.
• Inconvénients : risque de perte de données si les écritures se produisent après l’instantané.

Voici la procédure d’exportation/importation de base :

1. Exportez la base de données RDB à partir du cache Redis Enterprise existant vers votre compte stockage Azure.
2. Importez des données à partir du compte stockage Azure dans un nouveau cache Redis managé Azure.
3. En savoir plus sur l’exportation/l’importation de données ici , importez et exportez des données dans Azure Managed Redis.

Stratégie de double écriture

• Avantages : Temps d’arrêt zéro, transition sécurisée.
• Inconvénients : nécessite une configuration temporaire du double cache.

Voici la procédure de base de l'écriture en double :

1. Modifiez votre application pour écrire dans les deux caches, à savoir le cache Azure pour Redis Enterprise déjà existant et le nouveau cache Redis géré Azure.
2. Poursuivez la lecture et l’écriture à partir du cache Redis Enterprise.
3. Après une synchronisation de données suffisante, basculez vers Azure Managed Redis et supprimez l’instance Redis Enterprise

Migration par programmation à l’aide de RIOT-X

RIOT-X permet de migrer votre contenu d’Entreprise vers Azure Managed Redis. Pour plus d’informations, consultez Migration de données avec RIOT-X pour Azure Managed Redis.

• Avantages : Contrôle total, personnalisable.
• Inconvénients : nécessite un effort de développement.

Avantages du passage des caches De base, Standard ou Premium vers Azure Managed Redis

Si vous utilisez l’un des SKU OSS, De base, Standard ou Premium, passer à Azure Managed Redis vous offre plus de fonctionnalités à tous les niveaux de cache.

Voici un tableau qui compare les fonctionnalités d’Azure Cache pour Redis aux fonctionnalités d’Azure Managed Redis

Description de la fonctionnalité	Basic OSS	Standard OSS	Premium OSS	Balanced AMR	Memory Optimized AMR	Compute Optimized AMR
Availability	N/A	99.9%	99.9%	Jusqu’à 99 999%	Jusqu’à 99 999%	Jusqu’à 99 999%
Chiffrement des données en transit	Yes	Yes	Yes	Yes	Yes	Yes
Isolation du réseau	Yes	Yes	Yes	Yes	Yes	Yes
Scale-up/scale-out	Yes	Yes	Yes	Yes	Yes	Yes
Scale-down/scale-in	Yes	Yes	Yes	No	No	No
Clustering OSS	No	No	Yes	Yes	Yes	Yes
Persistance des données	No	No	Yes	Yes	Yes	Yes
Redondance de zone	No	Oui (aperçu)	Yes	*Oui avec haute disponibilité	*Oui avec haute disponibilité	*Oui avec haute disponibilité
Geo-replication	No	No	Oui (passif)	Oui (actif)	Oui (actif)	Oui (actif)
Journaux d’audit de connexion	No	No	Yes	Yes(Event-based)	Yes(Event-based)	Yes(Event-based)
Modules Redis	No	No	No	Yes	Yes	Yes
Import/Export	No	No	Yes	Yes	Yes	Yes
Reboot	Yes	Yes	Yes	No	No	No
Mises à jour planifiées	Yes	Yes	Yes	No	No	No
Authentification par Microsoft Entra ID	Yes	Yes	Yes	Yes	Yes	Yes
RBAC Microsoft Entra ID	Yes	Yes	Yes	No	No	No
Notification d’espace de clés	Yes	Yes	Yes	No	No	No
Non haute disponibilité	N/A	No	No	Yes	Yes	Yes

OSS fait référence au cache Azure pour Redis
AMR fait référence à Azure Managed Redis

* Lorsque la haute disponibilité est activée, Azure Managed Redis est redondant interzone dans les régions avec plusieurs zones de disponibilité.

Voici quelques autres différences à prendre en compte lors de l’implémentation d’Azure Managed Redis. Tenez compte des modifications suivantes apportées à l’application cliente :

Description de la fonctionnalité	Cache Azure pour Redis	Redis managé Azure
Suffixe DNS (uniquement pour le cloud PROD)	.redis.cache.windows.net	<region>.redis.azure.net
Port TLS	6380	10000
Port sans TLS	6379	Non prise en charge
Ports TLS des nœuds individuels	13XXX	85xx
Ports non-TLS des nœuds individuels	15XXX	Non prise en charge
Prise en charge du clustering	Mode de clustering OSS	Modes de cluster OSS et Entreprise
Commandes non prises en charge	Commandes non prises en charge	Commandes multi-clés
Disponibilité régionale	Toutes les régions Azure	* Consultez la liste des régions après cette section.
Version de Redis	6	7.4
Versions TLS prises en charge	1.2 et 1.3	1.2 et 1.3

Migrer votre cache De base, Standard ou Premium vers Azure Managed Redis

En fonction du tableau, voici quelques correspondances entre les SKU d'Azure Cache pour Redis et les options de caches dans Azure Managed Redis.

Note

Utiliser l’option sans haute disponibilité de Redis managé Azure pour la migration des références SKU de base

Cache Azure pour Redis	Redis managé Azure	Mémoire supplémentaire (%)
De base/Standard – C0	Équilibré – B0	50
De base/Standard – C1	Équilibré – B1	0
De base/Standard – C2	Équilibré – B3	17
De base/Standard – C3	Équilibré – B5	0
De base/Standard – C4	À mémoire optimisée – M10	-8
De base/Standard – C4	À mémoire optimisée – M20**	46
De base/Standard – C5	À mémoire optimisée – M20*	-8
De base/Standard – C5	À mémoire optimisée – M50**	57
De base/Standard – C6	À mémoire optimisée – M50	12
Premium – P1	Équilibré – B5	0
Premium – P2	Équilibré – B10	-8
Premium – P2	Équilibré – B20**	46
Premium – P3	Équilibré – B20*	-8
Premium – P3	Équilibré – B50**	57
Premium – P4	Équilibré – B50	12
Premium – P5	Équilibré – B100	0

• * Cette option est destinée à l’efficacité des coûts. Vérifiez que le pic de mémoire totale utilisée au cours du mois dernier est inférieur à la mémoire Azure Managed Redis suggérée pour choisir cette option.
• ** Cette option est destinée à une consommation abondante de la mémoire.

Azure Cache pour Redis Premium en cluster

• Pour un cluster partitionné, choisissez un niveau À mémoire optimisée qui a une mémoire totale équivalente.
• Pour les clusters avec plusieurs réplicas en lecture, choisissez un niveau Optimisé pour le calcul avec une mémoire totale équivalente comme réplica principal.

Options de migration

Les applications clientes doivent être en mesure d’utiliser une instance Redis managé Azure qui a différents modes de clustering et points de terminaison. Azure Cache pour Redis et Azure Managed Redis sont compatibles. Par conséquent, aucune modification du code d’application autre que les configurations de connexion n’est requise pour la plupart des scénarios.

Pour plus d’informations, consultez :

• Mettre à l’échelle une instance Azure Managed Redis

Options de migration d’Azure Cache pour Redis vers Redis managé Azure

Option	Advantages	Disadvantages
Créer un cache	Plus simple à implémenter.	Vous devez remplir de nouveau le cache, ce qui peut ne pas fonctionner avec de nombreuses applications.
Exporter et importer des données via un fichier RDB	Compatible avec tout cache Redis en général.	Certaines données peuvent être perdues si elles sont écrites dans le cache existant après la génération du fichier RDB.
Double-écriture de données dans deux caches	Aucune perte de données, ni aucun temps d’arrêt. Opérations ininterrompues du cache existant. Test plus facile du nouveau cache.	Nécessite deux caches pendant une période prolongée.
Migrer des données par programme	Contrôle total sur la façon dont les données sont déplacées.	Requiert du code personnalisé.

Créer une instance Redis managée Azure

Cette approche n’est techniquement pas une migration. Si la perte de données n’est pas un problème, le moyen le plus simple de passer au niveau Redis managé Azure consiste à créer une instance de cache et à connecter votre application à celle-ci. Par exemple, si vous utilisez Redis comme cache de recherche d’enregistrements de base de données, vous pouvez facilement reconstruire le cache à partir de zéro. Les étapes générales pour implémenter cette option sont les suivantes :

1. Créez une instance Redis managé Azure.
2. Mettez à jour votre application pour utiliser la nouvelle instance.
3. Supprimez l’ancienne instance Azure Cache pour Redis.

Exporter les données vers un fichier RDB et l’importer dans Redis managé Azure

Cette option est applicable seulement aux caches de niveau Premium. Redis open source définit un mécanisme standard pour la capture d’un instantané du jeu de données en mémoire d’un cache et son enregistrement dans un fichier. Un autre cache Redis peut lire le fichier RDB exporté. Le niveau Premium d’Azure Cache pour Redis prend en charge l’exportation de données depuis une instance de cache via des fichiers RDB. Vous pouvez utiliser un fichier RDB pour transférer des données d’une instance Azure Cache pour Redis existante vers une instance Redis managé Azure.

Les étapes générales pour implémenter cette option sont les suivantes :

1. Créez une instance Redis managé Azure de la même taille (ou plus grande) que celle de l’instance Azure Cache pour Redis existante.
2. Exporter le fichier RDB à partir d’une instance Azure Cache pour Redis existante à l’aide de ces instructions d’exportation ou de l’applet de commande PowerShell Export
3. Importez le fichier RDB dans une nouvelle instance Redis managé Azure en utilisant ces instructions d’importation ou la cmdlet PowerShell Import.
4. Mettez à jour votre application pour utiliser la nouvelle chaîne de connexion de l’instance Redis managé Azure.

Écrire simultanément dans deux caches Redis au cours de la période de migration

Au lieu de déplacer les données directement entre les caches, vous pouvez utiliser votre application pour écrire des données dans un cache existant et un nouveau cache que vous configurez. L’application continue de lire les données dans le cache existant. Lorsque le nouveau cache disposera des données nécessaires, vous basculerez l’application vers ce cache et mettrez l’ancien hors service. Supposons, par exemple, que vous utilisez Redis comme magasin de sessions et que les sessions d’application sont valides pendant sept jours. Après avoir écrit dans les deux caches pendant une semaine, vous avez la certitude que le nouveau cache contient toutes les informations de session non expirées. Vous pouvez, en toute sécurité, l’utiliser à partir de ce point, sans vous soucier des pertes de données.

Les étapes générales pour implémenter cette option sont les suivantes :

1. Créez une instance Redis managé Azure de la même taille (ou plus grande) que celle de l’instance Azure Cache pour Redis existante.
2. Modifiez le code de l’application pour écrire à la fois dans la nouvelle instance et celle d’origine.
3. Continuez la lecture des données à partir de l’instance d’origine jusqu’à ce que la nouvelle instance soit suffisamment remplie avec des données.
4. Mettez à jour le code de l’application pour qu’elle lise et écrive à partir de la nouvelle instance uniquement.
5. Supprimez l'instance d'origine.

Migrer par programme

Créez un processus de migration personnalisé en lisant par programmation les données d’une instance Azure Cache pour Redis existante et en les écrivant dans une instance Redis managé Azure. Vous pouvez essayer deux outils open source :

• Redis-copy
  • Cet outil open source peut être utilisé pour copier des données d’une instance Azure Cache pour Redis vers une autre. Cet outil est utile pour déplacer des données entre des instances de cache dans différentes régions Azure Cache. Une version compilée est également disponible. Le code source peut aussi être un guide utile pour écrire votre propre outil de migration.
• RIOT
  • RIOT est un autre outil de migration répandu testé par la communauté Redis. C’est un utilitaire en ligne de commande conçu pour vous aider à placer et à extraire des données dans Redis.

Note

Cet outil n’est pas officiellement pris en charge par Microsoft.

Les étapes générales pour implémenter cette option sont les suivantes :

1. Créez une machine virtuelle dans la région où se trouve le cache existant. Si votre jeu de données est volumineux, choisissez une machine virtuelle relativement puissante pour réduire le temps de copie.
2. Créez une instance Redis managé Azure.
3. Videz les données du nouveau cache pour vous assurer qu’il est vide. Cette étape est requise, car l’outil de copie lui-même ne remplace aucune clé existante dans le cache cible. Important : veillez à ne PAS vider le cache source.
4. Utilisez une application telle que l’outil open source mentionné précédemment pour automatiser la copie des données du cache source vers le cache cible. N’oubliez pas que le processus de copie peut prendre un certain temps en fonction de la taille de votre jeu de données.

Disponibilité régionale pour Azure Managed Redis

Azure Managed Redis s’étend continuellement dans de nouvelles régions. Pour vérifier la disponibilité dans votre région, consultez Disponibilité des produits par région.

Contenu connexe

• Présentation de Redis managé Azure
• Architecture Redis managée Azure