Modifier

FAQ sur le cache Azure pour Redis

Découvrez les réponses aux questions les plus fréquentes, les modèles et les meilleures pratiques concernant le Cache Azure pour Redis.

Changement concernant la gestion des licences Redis

Quels sont les changements apportés à la gestion des licences Redis ?

Le projet open source Redis est passé à un modèle à double licence avec prise en charge de la licence RSALv2 (Redis Source Available License version 2) ou de la licence SSPLv1 (Server-Side Public License version 1). Pour plus d’informations, consultez le communiqué de presse Redis. Consultez également le billet de blog Microsoft sur le changement de licence Redis.

Azure Cache pour Redis est-il désormais également couvert par les licences RSALv2 et SSPLv1 ?

Non, Azure Cache pour Redis est proposé aux clients dans le cadre des conditions d’utilisation du service de Microsoft. Les licences RSALv2 et SSPLv1 ne s’appliquent pas à votre utilisation d’Azure Cache pour Redis.

Mon instance d’Azure Cache pour Redis va-t-elle continuer à faire l’objet de correctifs et de résolutions de bogues ?

Oui, Azure Cache pour Redis, Azure Cache pour Redis Enterprise et Enterprise Flash continueront de faire l’objet de correctifs et de résolutions de bogues même après l’annonce relative à la gestion des licences.

Que dois-je faire en tant que client Azure Cache pour Redis en réponse à cette annonce relative à la gestion des licences ?

Aucune action n’est nécessaire de la part de nos clients Azure à la suite de l’annonce relative à la gestion des licences.

Services dépréciés

Quels sont les services Azure Cache pour Redis qui sont dépréciés ?

Caches avec une dépendance sur les services cloud (classique)

Que dois-je faire avec les instances d’Azure Cache pour Redis qui dépendent des services cloud (classiques) ?

Vous devez migrer tous les caches avec une dépendance sur les services cloud (classique). En août 2021, nous avons annoncé que les services cloud (classiques) seront mis hors service le 31 août 2024. Toutes les instances de Azure Cache pour Redis qui dépendent des services cloud (classiques) doivent être supprimées à la même date.

Vous devez migrer tous les caches avec une dépendance sur les services cloud (classique) avant le 31 août 2024.

Combien de caches sont affectés ?

Nous avons fait un effort pour migrer autant de caches que possible. En raison de cela, peu de caches et de clients sont affectés.

Comment savoir si un cache est affecté ?

Vérifiez les recommandations d’Azure Advisor. Si votre cache est affecté, vous voyez une recommandation dans votre abonnement.

Capture d’écran de recommandation d’Advisor pour migrer le cache à partir de services cloud.

Comment faire pour migrer des caches Services cloud (classiques) vers Azure Virtual Machine Scale Sets ?

Nous avons migré la plupart des caches basés sur Services cloud (classique) vers des caches basés sur les groupes de machines virtuelles identiques Azure. La migration vers Azure Virtual Machine Scale Sets a pour effet de supprimer la dépendance. Il existe trois façons de lancer ce processus pour les caches dans un réseau virtuel :

  • Migrez vers un nouveau cache à l’aide de liaisons privées (Private Link).

    Créez un cache qui utilise Private Link pour l’isolation réseau plutôt que l’injection de réseau virtuel et migrez vos données vers ce cache. Cette option vous offre la meilleure expérience d’isolation réseau sécurisée, tout en garantissant également que tous les nouveaux caches sont créés à l’aide de l’infrastructure mise à jour.

  • Migrez vers un nouveau cache dans un nouveau sous-réseau de réseau virtuel Azure Resource Manager.

    La création d’un cache dans un réseau virtuel classique crée un cache Services cloud (classique) et non un cache de groupes de machines virtuelles identiques Azure. La migration vers un nouveau cache dans un nouveau sous-réseau de réseau virtuel Azure Resource Manager corrige la dépendance sous-jacente aux services cloud tout en conservant une expérience de réseau virtuel similaire.

    Nous avons migré la plupart des caches basés sur Services cloud (classique) vers des caches basés sur les groupes de machines virtuelles identiques Azure. Pour migrer, supprimez le cache existant et créez un cache dans un nouveau sous-réseau de réseau virtuel Azure Resource Manager. Nous vous recommandons vivement de ne pas utiliser d’anciens sous-réseaux lors de la migration des caches. Pour obtenir les options recommandées pour migrer les données dans le cache, consultez Migrer vers Azure Cache pour Redis.

  • Migration automatique avec perte de données (recommandé).

    Nous pouvons migrer des caches utilisant Services cloud (classique) vers des caches utilisant des groupes de machines virtuelles identiques automatiquement, avec une configuration du cache (dont les clés d’accès et le nom d’hôte) conservée. Cependant, cette méthode nécessite environ 30 minutes de temps d'arrêt et une perte totale des données sur le cache. Vous pouvez utiliser la fonctionnalité importer/exporter pour enregistrer une copie de vos données avant la migration.

    Pour utiliser cette option, contactez azurecachemigration@microsoft.com ou créez une demande de support pour demander une migration.

Mon cache n’utilise pas l’injection de réseau virtuel, mais j’ai reçu l’avis que j’ai besoin de migrer. Que dois-je faire ?

Vérifiez si votre cache utilise la géoréplication. Dans ce cas, vous devez migrer les données de votre paire géorépliquée actuelle vers une nouvelle paire géorépliquée.

Par exemple :

  1. Créez une paire géorépliquée de caches Premium qui correspondent à la même configuration que votre paire actuelle de caches.
  2. Dissociez votre paire d’origine de caches géorépliqués et exportez un fichier RDB à partir du cache principal.
  3. Importez le fichier RDB dans le cache principal dans votre nouvelle paire géorépliquée.

La nouvelle paire de caches géorépliqués n’aura pas la même dépendance sur les services cloud.

Que dois-je faire si je ne parviens pas à créer une instance de cache et que le message d’erreur « le sous-réseau est affecté par la mise hors service de Services cloud » s’affiche ?

Nous commençons à bloquer la création de nouveaux caches à l’aide du modèle de déploiement Services cloud (classique). De nouveaux caches peuvent toujours être créés à l’aide de cet ancien modèle de déploiement s’ils sont créés dans un sous-réseau de réseau virtuel qui contenait autrefois un cache Services cloud ou si un cache est déployé dans un réseau virtuel classique. Si ce message s’affiche, créez un sous-réseau dans le réseau virtuel dans lequel déployer votre cache. La création d’un sous-réseau dans votre réseau virtuel garantit qu’un cache est créé sans dépendance Services cloud.

Pour vérifier si vous avez un ou plusieurs caches basés sur Services cloud dans votre sous-réseau, vous pouvez vérifier Azure Advisor dans le portail ou utiliser l’API REST resource-navigation-links. Utilisez l’API resource-navigation-links avec votre ID d’abonnement, le nom du groupe de ressources, le nom du réseau virtuel et le nom du sous-réseau, pour récupérer les caches de ce sous-réseau qui utilisent Services cloud.

Si vous créez un cache à l’aide de l’API REST, assurez-vous également que vous ne transmettez pas la configuration redis {"CacheVmType": "CloudService"} avec la demande de création. Ce paramètre est un paramètre non documenté. Il est donc peu probable que vous procédiez ainsi.

Si vous devez créer des caches à l’aide du modèle de déploiement Services cloud (classique), contactez azurecachemigration@microsoft.com ou créez une demande de support pour demander une exemption.

Que se passe-t-il si les caches ne sont pas mis à niveau/migrés le 31 août 2024 ?

Ces caches seront arrêtés et vous perdrez toutes les données de vos caches.

Qu’est-ce que la chronologie de la prise en charge ?

La mise hors service se produit en trois phases afin que vous disposiez du délai maximal de migration :

  1. Phase active (maintenant au 30 avril 2023)

    Les caches ont une prise en charge complète, sans aucune modification de l’état d’aujourd’hui. Cette période est donnée pour permettre aux clients de passer hors service cloud (classique) avec une interruption minimale.

  2. Phase de maintenance (1er mai 2023 au 31 décembre 2023)

    Les caches recevront des correctifs critiques de sécurité, de stabilité et de bogues, mais aucune nouvelle fonctionnalité.

  3. Phase inactive (1er janvier 2024 au 31 août 2024)

    Les caches reçoivent seulement des correctifs de sécurité critiques. Tous les clients ayant des problèmes de support sont invités à migrer vers un cache basé sur VMSS avant de recevoir le support. Les clients doivent quitter leurs caches le 31 août 2024.

Image montrant la chronologie de retrait de Service cloud (classiques).

Cette chronologie s’applique-t-elle aux caches s’exécutant sur Redis 4.0 ?

Nombre Cette chronologie s’applique uniquement aux caches s’exécutant sur Redis 6.0. Redis 4.0 fait partie d’un retrait distinct qui se termine avant la mise hors service des services cloud (classique). Tous les caches restants utilisant Redis 4.0 sur Services cloud (classique) seront automatiquement migrés pour utiliser des groupes de machines virtuelles identiques et Redis 6.0 après le 31 octobre 2023. Cette méthode de migration nécessite un temps d’arrêt et une perte complète de données sur le cache. Migrez donc avant cette date si vous souhaitez éviter des temps d’arrêt ou une perte de données. Contactez azurecachemigration@microsoft.com ou créez une demande de support pour demander une mise à niveau automatique avant le 31 octobre 2023.

Où puis-je obtenir plus d’informations si j’ai plus de questions sur cette retraite ?

Publiez toutes vos questions sur la page Q&A relative à la mise hors services de l’offre Services cloud (classique). En outre, vous pouvez envoyer un e-mail à azurecachemigration@microsoft.com pour plus d’informations.

Questions générales

Que se passe-t-il si ma question sur Azure Cache pour Redis n’a pas de réponse ici ?

Si votre question n’est pas répertoriée ici, faites-le-nous savoir pour que nous puissions vous aider à trouver une réponse.