Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Avant de migrer, passez en revue les principales différences entre Le Cache Azure pour Redis et Azure Managed Redis afin de pouvoir planifier efficacement.
Important
Une compétence de l’agent de migration Redis est disponible pour répondre aux questions liées à la migration et préparer un plan de migration adapté à votre environnement. Pour plus d’informations, consultez la compétence de l’agent de migration Redis.
Pourquoi Azure Managed Redis est plus performant
Azure Managed Redis repose sur la pile logicielle Redis Enterprise, qui offre des améliorations de performances importantes par rapport à Redis open source utilisé dans les niveaux de Base, Standard et Premium. Redis Enterprise utilise une architecture multithread qui peut gérer plus d’opérations par seconde, fournir des latences inférieures et utiliser plus efficacement le matériel sous-jacent. Cela signifie que pour la même quantité de mémoire et de calcul, Azure Managed Redis peut servir un débit beaucoup plus élevé par rapport au cache de niveau De base, Standard ou Premium équivalent.
En outre, Azure Managed Redis prend en charge les structures de données avancées via des modules Redis (tels que RediSearch, RedisJSON et RedisBloom) qui ne sont pas disponibles dans les niveaux De base, Standard ou Premium. Pour en savoir plus sur l’architecture, consultez l’architecture Redis managée Azure.
Différences entre fonctionnalités clés et autres fonctionnalités
Voici les différences importantes à connaître lors du passage de Basic, Standard ou Premium à Azure Managed Redis :
Structure de référence SKU. Azure Managed Redis organise les références SKU différemment d’Azure Cache pour Redis. Au lieu des références SKU basées sur des niveaux (De base, Standard, Premium) où les fonctionnalités varient selon le niveau, les références SKU Redis managées Azure sont basées sur deux dimensions : la taille de la mémoire et le niveau de performances (équilibré, optimisé en mémoire ou optimisé pour le calcul). Toutes les fonctionnalités de haute disponibilité et de récupération d’urgence (HADR), notamment la redondance de zone, la persistance des données, la géoréplication et l’importation/exportation, sont disponibles sur toutes les tailles et niveaux de performances. Vous n’avez plus besoin de choisir une référence SKU de niveau supérieur pour accéder à ces fonctionnalités.
Haute disponibilité et non haute disponibilité. Azure Managed Redis vous offre la possibilité de déployer avec ou sans haute disponibilité. L’option non haute disponibilité est conçue pour les charges de travail de non-production et de développement/test dans lesquelles vous souhaitez réduire les coûts. Les instances non haute disponibilité n’ont pas d'accord de niveau de service et comportent un risque de perte de données pendant la maintenance. En revanche, les niveaux De base, Standard et Premium n’offrent pas cette flexibilité : Basic n’a pas de haute disponibilité, tandis que Standard et Premium l’incluent toujours.
Regroupement. Azure Managed Redis est clusteré par défaut et propose deux stratégies de clustering : le clustering OSS et le clustering Entreprise. Nous vous recommandons de choisir le clustering OSS pour des performances optimales. Si vous utilisez actuellement un cache de base ou standard non cluster, votre configuration de bibliothèque cliente Redis peut nécessiter des modifications pour fonctionner avec une instance en cluster (par exemple, la gestion
MOVEDdes redirections à l’aide d’une bibliothèque cliente prenant en charge le cluster). Si votre application nécessite absolument une instance non cluster, Azure Managed Redis offre un mode non cluster pour les caches pouvant atteindre 25 Go.Isolation du réseau. Azure Managed Redis ne prend pas en charge l’injection de réseau virtuel et la configuration des règles de pare-feu basées sur IP. Si votre instance Azure Cache pour Redis existante utilise l’injection de réseau virtuel pour l’isolation réseau, vous devez passer à l’utilisation d’Azure Private Link avec votre nouvelle instance Azure Managed Redis.
Mise à l'échelle. Azure Managed Redis prend en charge la modification de la taille de mémoire et du niveau de performances.
ID Microsoft Entra. Les deux services prennent en charge l’authentification Microsoft Entra ID. Toutefois, Azure Managed Redis ne prend actuellement pas en charge le contrôle d’accès basé sur les rôles (RBAC) de Microsoft Entra ID.
Mises à jour planifiées. Azure Cache pour Redis prend en charge la configuration d’une fenêtre de mise à jour planifiée pour les mises à jour du moteur Redis. Azure Managed Redis prend en charge les mises à jour planifiées actuellement en préversion.
La prise en charge des ports TLS et non TLS. Dans les niveaux De base, Standard et Premium du Cache Azure, la même instance de cache peut prendre en charge simultanément les connexions TLS (port 6380) et texte brut (port 6379), ce qui permet à différentes applications de se connecter à l’aide de l’un ou l’autre mode. Dans Azure Managed Redis, le cache prend en charge un seul mode à la fois ( TLS ou non-TLS). Une fois le mode choisi lors de la création du cache, toutes les applications qui se connectent à ce cache doivent utiliser le même mode.
Redondance de zone. Azure Managed Redis est redondant interzone par défaut lorsque la haute disponibilité est activée et que la région prend en charge plusieurs zones de disponibilité. Par comparaison, la redondance de zone n’est disponible que dans le niveau Premium (et en préversion pour Standard).
Bases de données. Les niveaux De base, Standard et Premium prennent en charge plusieurs bases de données Redis (jusqu’à 16 par défaut, configurables jusqu’à 64 sur Premium). Azure Managed Redis ne prend en charge qu’une base de données unique (base de données 0). Si votre application utilise plusieurs bases de données, vous devez refactoriser votre modèle de données pour utiliser une base de données unique ou utiliser des préfixes de clé pour séparer logiquement les données avant la migration.
Géoréplication. Azure Managed Redis prend en charge la géoréplication active, ce qui permet d’effectuer des opérations de lecture et d’écriture dans des caches liés dans différentes régions. Le niveau Premium prend uniquement en charge la géoréplication passive, où le cache secondaire est en lecture seule. Contrairement à Azure Cache pour Redis, Azure Managed Redis ne propose pas de commande explicite de basculement. Au lieu de cela, votre application doit basculer vers une autre instance Azure Managed Redis géorépliquée lorsqu’elle détecte l’une des régions est en panne.
Persistance des données. Azure Managed Redis prend en charge la persistance des données sur toutes les références SKU. Dans Le Cache Azure pour Redis, la persistance est disponible uniquement dans le niveau Premium.
Modules Redis. Azure Managed Redis prend en charge les modules Redis tels que RediSearch, RedisJSON, RedisBloom et RedisTimeSeries. Ces modules ne sont pas disponibles dans les niveaux De base, Standard ou Premium.
Importer/Exporter. Azure Managed Redis prend en charge l’importation et l’exportation RDB sur toutes les références SKU. Dans Le Cache Azure pour Redis, cette fonctionnalité est disponible uniquement dans le niveau Premium.
Notifications d’espace de clés. Les notifications Keyspace sont prises en charge dans Le Cache Azure pour Redis, mais elles ne sont pas actuellement disponibles dans Azure Managed Redis.
Redémarrage. Azure Cache pour Redis prend en charge le redémarrage manuel des nœuds de cache. Cette opération n’est pas disponible dans Azure Managed Redis, qui gère automatiquement les opérations de nœud. Si vous utilisez Reboot pour vider les données de votre cache, Azure Managed Redis offre Vidage en tant qu’opération de gestion. Les API Redis managées Azure pour simuler des événements de maintenance pour tester la résilience de vos applications sont sur la feuille de route.
Principales différences pour les applications clientes
Passez en revue ces différences lors de la planification des mises à jour de votre application :
| Description de la fonctionnalité | Cache Azure pour Redis | Azure Managed Redis |
|---|---|---|
| Suffixe DNS (pour le cloud public Azure) | .redis.cache.windows.net |
<region>.redis.azure.net |
| Port TLS | 6380 | 10 000 |
| Port sans TLS | 6379 | 10 000 |
| Ports TLS des nœuds individuels | 13XXX | 85xx |
| Ports non-TLS des nœuds individuels | 15XXX | 85xx |
| Prise en charge du clustering | Clustering OSS uniquement | Clustering d’OSS et d’Entreprise |
| Non-clusterisé/autonome | Oui (De base, Standard, Premium jusqu’à 120 Go) | Oui (mode non cluster, jusqu’à 25 Go uniquement) |
| Version de Redis | 6 | 7.4 |
| Versions TLS prises en charge | 1.2 et 1.3 | 1.2 et 1.3 |
Choisir la taille et la référence SKU Azure Managed Redis appropriées
Le choix de la bonne référence SKU Redis managée Azure implique deux étapes : sélectionner la taille de mémoire appropriée, puis sélectionner le niveau de performances approprié.
Étape A : choisir la taille de mémoire appropriée
- Identifiez la taille de mémoire de votre cache actuel. Accédez au portail Azure, ouvrez votre cache De base, Standard ou Premium, puis notez la taille de la mémoire à partir de la page Vue d’ensemble (par exemple, C3 = 13 Go, P2 = 13 Go).
Note
Pour les caches en cluster Premium : pour les clusters partitionnés, choisissez une taille qui a une mémoire totale équivalente sur toutes les partitions.
Recherchez une référence SKU de taille similaire dans Azure Managed Redis. Recherchez une référence SKU Redis managée Azure qui offre la même quantité de mémoire utilisable ou supérieure. Lors de la comparaison des tailles, notez qu’Azure Managed Redis réserve environ 20% de mémoire pour les opérations système et la surcharge. Comptez cette réservation lors de la sélection d’une taille ( par exemple, les références SKU B10/M10/X10 offrent 12 Go de mémoire totale, mais environ 9,6 Go de mémoire utilisable pour vos données après la réservation.
Optimisez en fonction de l’utilisation réelle de la mémoire. Au lieu de correspondre à la taille nominale du cache, passez en revue la métrique Mémoire utilisée sur votre cache existant dans Azure Monitor. Vérifiez l’utilisation maximale de la mémoire au cours du mois dernier pour identifier une référence SKU mieux adaptée. Si votre utilisation réelle de la mémoire est bien inférieure à la taille du cache, vous pouvez sélectionner une référence SKU Redis managée Azure plus petite et plus économique.
Étape B : Choisir le niveau de performance approprié
Azure Managed Redis offre trois niveaux de performances : équilibré, optimisé en mémoire et optimisé pour le calcul. Sélectionnez en fonction des caractéristiques de votre charge de travail :
- Équilibré - Un bon point de départ si vous n’êtes pas sûr. Offre une combinaison saine de mémoire et de calcul.
- Mémoire optimisée : choisissez cette option si votre charge de travail est gourmande en mémoire et plus susceptible d’épuiser la mémoire avant le processeur.
- Optimisé pour le calcul : choisissez-le si votre charge de travail est sensible au débit ou à la latence.
Pour plus d’informations, consultez Choisir le niveau approprié.
Considérations supplémentaires
- Désactivez la haute disponibilité pour les migrations de niveau de base. Si vous migrez à partir d’un cache de base (qui n’a pas de réplication ou de contrat SLA), désactivez la haute disponibilité sur votre nouvelle instance Azure Managed Redis. Cela réduit de moitié le coût et fournit une configuration comparable pour les charges de travail de développement/test.