Partager via

Configurer la prise en charge du réseau virtuel pour une instance Azure Cache Premium pour Redis

  • Article

Le déploiement du Réseau virtuel Azure fournit une sécurité et une isolation améliorées, ainsi que des sous-réseaux, des stratégies de contrôle d’accès et d’autres fonctionnalités qui permettent de restreindre davantage l’accès. Lorsqu’une instance Azure Cache pour Redis est configurée avec un réseau virtuel, elle n’est pas adressable publiquement. L’instance n’est alors accessible qu’à partir des machines virtuelles et des applications présentes au sein du réseau virtuel. Cet article décrit comment configurer la prise en charge d’un réseau virtuel pour une instance Azure Cache pour Redis de niveau Premium.

Notes

Le modèle de déploiement classique sera mis hors service en août 2024. Pour plus d’informations, consultez Le modèle de déploiement de Cloud Services (Classic) sera mis hors service le 31 août 2024.

Important

Azure Cache pour Redis recommande d’utiliser Azure Private Link, qui simplifie l’architecture réseau et sécurise la connexion entre les points de terminaison dans Azure. Vous pouvez vous connecter à une instance Azure Cache depuis votre réseau virtuel via un point de terminaison privé, auquel est attribuée une adresse IP privée dans un sous-réseau au sein du réseau virtuel. Azure Private Link est proposé sur tous nos niveaux et comprend la prise en charge d’Azure Policy et la gestion simplifiée des règles NSG. Pour en savoir plus, consultez Documentation de Private Link. Pour migrer vos caches injectés dans un réseau virtuel vers Private Link, consultez Migrer des caches d’injection VNet vers des caches Private Link.

Limitations de l’injection de réseau virtuel

  • La création et la maintenance de configurations de réseau virtuel sont souvent sujettes à des erreurs. La résolution des problèmes est également difficile. Des configurations de réseau virtuel incorrectes peuvent entraîner des problèmes :

    • transmission des métriques obstruées à partir de vos instances de cache

    • échec du nœud réplica pour répliquer des données à partir du nœud principal

    • perte de données potentielle

    • échec des opérations de gestion telles que la mise à l’échelle

    • Échecs intermittents ou complets de SSL/TLS

    • échecs d’application des mises à jour, notamment les améliorations de fiabilité et de sécurité importantes

    • dans les scénarios les plus graves, perte de disponibilité

  • Les caches injectés de réseau virtuel sont disponibles uniquement pour le cache Azure de niveau Premium pour Redis, et non pour les autres niveaux.
  • Quand vous utilisez un cache injecté sur un VNet, vous devez changer votre VNet pour mettre en cache les dépendances telles que les listes de révocation de certificats/l’infrastructure à clé publique, Azure Key Vault, Stockage Azure, Azure Monitor, etc.
  • Vous ne pouvez pas injecter une instance Azure Cache pour Redis existante dans un réseau virtuel. Vous devez sélectionner cette option lorsque vous créer le cache.

Configurer la prise en charge du réseau virtuel

La configuration de la prise en charge du réseau virtuel s’effectue dans le volet Nouveau cache Azure pour Redis lors de la création du cache.

  1. Pour créer un cache de niveau Premium, connectez-vous au portail Azure et sélectionnez Créer une ressource. Vous pouvez également les créer à l’aide de modèles Resource Manager, de PowerShell ou de l’interface Azure CLI. Pour plus d’informations sur la création d’une instance Azure Cache pour Redis, consultez Créer un cache.

    Capture d’écran montrant l’option Créer une ressource

  2. Dans la page Nouveau, sélectionnez Bases de données. Ensuite, sélectionnez Azure Cache pour Redis.

    Capture d’écran montrant la sélection d’Azure Cache pour Redis

  3. Dans la page Nouveau cache Redis, configurez les paramètres du nouveau cache de niveau Premium.

    Paramètre Valeur suggérée Description
    Nom DNS Entrez un nom globalement unique. Le nom du cache doit être une chaîne de 1 à 63 caractères ne contenant que des chiffres, des lettres ou des traits d’union. Le nom doit commencer et se terminer par un chiffre ou une lettre, et ne doit pas contenir de traits d’union consécutifs. Le nom d'hôte de votre instance de cache sera \<DNS name>.redis.cache.windows.net.
    Abonnement Sélectionnez votre abonnement dans la liste déroulante. Abonnement sous lequel créer cette nouvelle instance d’Azure Cache pour Redis.
    Groupe de ressources Sélectionnez un groupe de ressources dans la liste déroulante ou sélectionnez Créer nouveau, puis entrez un nouveau nom de groupe de ressources. Nom du groupe de ressources dans lequel créer votre cache et d’autres ressources. En plaçant toutes les ressources de votre application dans un seul groupe de ressources, vous pouvez facilement les gérer ou les supprimer ensemble.
    Lieu Sélectionnez un emplacement dans la liste déroulante. Choisissez une Région proche d’autres services qui utiliseront votre cache.
    Type de cache Sélectionnez un cache de niveau Premium dans la liste déroulante pour configurer les fonctionnalités de niveau Premium. Pour plus d’informations, consultez Tarification du Cache Azure pour Redis. Le niveau tarifaire détermine la taille, les performances et les fonctionnalités disponibles pour le cache. Pour plus d’informations, consultez Présentation d’Azure Cache pour Redis.

  4. Sélectionnez l’onglet Réseau ou sélectionnez le bouton Réseau au bas de la page.

  5. Sous l’onglet Réseau, sélectionnez Réseaux virtuels comme méthode de connexion. Pour utiliser un nouveau réseau virtuel, vous devez tout d’abord le créer en suivant les étapes indiquées dans Créer un réseau virtuel à l’aide du portail Azure ou Créer un réseau virtuel (classique) à l’aide du portail Azure. Revenez ensuite au volet Nouveau cache Azure pour Redis pour créer et configurer votre cache de niveau Premium.

    Important

    Lorsque vous déployez Azure Cache pour Redis dans un réseau virtuel Resource Manager, le cache doit se trouver dans un sous-réseau dédié ne contenant pas de ressources autres que des instances Azure Cache pour Redis. Si vous tentez de déployer une instance Azure Cache pour Redis dans un sous-réseau de réseau virtuel Resource Manager contenant d’autres ressources, ou ayant une passerelle NAT attribuée, le déploiement échoue. L’échec est dû au fait qu’Azure Cache pour Redis utilise un équilibreur de charge de base qui n’est pas compatible avec une passerelle NAT.

    Paramètre Valeur suggérée Description
    Réseau virtuel Sélectionnez votre réseau virtuel dans la liste déroulante. Sélectionnez un réseau virtuel figurant dans les mêmes abonnement et emplacement que votre cache.
    Sous-réseau Sélectionnez votre sous-réseau dans la liste déroulante. La plage d’adresses du sous-réseau doit utiliser la notation CIDR (par exemple, 192.168.1.0/24). Elle doit être contenue dans l’espace d’adressage du réseau virtuel.
    Adresse IP statique (Facultatif) Entrez une adresse IP statique. Si vous ne spécifiez pas d’adresse IP statique, une adresse IP est choisie automatiquement.

    Important

    Azure réserve dans chaque sous-réseau des adresses IP qui ne peuvent pas être utilisées. Les première et dernière adresse IP des sous-réseaux sont réservées à la conformité du protocole, et 3 adresses supplémentaires sont utilisées pour les services Azure. Pour plus d’informations, consultez Existe-t-il des restrictions sur l’utilisation des adresses IP au sein de ces sous-réseaux ?.

    Outre les adresses IP utilisées par l’infrastructure de réseau virtuel Azure, chaque instance Azure Cache pour Redis dans le sous-réseau utilise deux adresses IP par partition et une adresse IP supplémentaire pour l’équilibreur de charge. Un cache non-cluster est considéré comme ayant une seule partition.

  6. Sélectionnez l’onglet Suivant : Avancé ou sélectionnez le bouton Suivant : Avancé en bas de la page.

  7. Sous l’onglet Avancé d’une instance de cache de niveau Premium, configurez les paramètres pour le port non-TLS, le clustering et la persistance des données.

  8. Sélectionnez l’onglet Suivant : Avancé ou sélectionnez le bouton Suivant : Étiquettes au bas de la page.

  9. Si vous le voulez, sous l’onglet Étiquettes, entrez le nom et la valeur si vous souhaitez catégoriser la ressource.

  10. Sélectionnez Revoir + créer. Vous êtes redirigé vers l’onglet Vérifier + créer où Azure valide votre configuration.

  11. Une fois que le message vert Validation réussie s’affiche, sélectionnez Créer.

La création du cache prend un certain temps. Vous pouvez surveiller la progression dans la page Vue d’ensemble du Azure Cache pour Redis. Lorsque État indique En cours d’exécution, le cache est prêt pour utilisation. Une fois le cache créé, vous pouvez afficher la configuration pour le réseau virtuel en sélectionnant Réseau virtuel dans le menu Ressource.

Réseau virtuel

Questions fréquentes (FAQ) sur le réseau virtuel Azure Cache pour Redis

La liste suivante contient des réponses aux questions fréquemment posées sur la mise en réseau Azure Cache pour Redis.

Quels sont les problèmes de configuration les plus courants avec Azure Cache pour Redis et des réseaux virtuels ?

Quand Azure Cache pour Redis est hébergé dans un réseau virtuel, les ports répertoriés dans les tableaux suivants sont utilisés.

Important

Si les ports répertoriés dans les tableaux suivants sont bloqués, le cache risque de ne pas fonctionner correctement. Le blocage d’un ou plusieurs de ces ports constitue le problème de configuration le plus courant lorsque vous utilisez Azure Cache pour Redis dans un réseau virtuel.

Configuration requise de port sortant

Il existe neuf configurations requises de port sortant. Les demandes sortantes dans ces plages sont soit : a) sortantes vers d’autres services nécessaires au cache pour fonctionner, soit b) internes au sous-réseau Redis pour la communication entre les nœuds. Pour la géoréplication, il existe d’autres règles de trafic sortant pour la communication entre les sous-réseaux du cache principal et de réplica.

Ports Sens Protocole de transfert Objectif Adresse IP locale Adresse IP distante
80, 443 Règle de trafic sortant TCP Dépendances Redis sur Azure Storage/l’infrastructure à clé publique (Internet) (sous-réseau Redis) * 4
443 Règle de trafic sortant TCP Dépendance Redis à Azure Key Vault et à Azure Monitor (sous-réseau Redis) AzureKeyVault, AzureMonitor1
12 000 Règle de trafic sortant TCP Dépendance Redis sur Azure Monitor (sous-réseau Redis) AzureMonitor 1
53 Règle de trafic sortant TCP/UDP Dépendances Redis sur DNS (Internet/réseau virtuel) (sous-réseau Redis) 168.63.129.16 et 169.254.169.254 2 et n’importe quel serveur DNS personnalisé pour le sous-réseau 3
123 Sortant(e) UDP Dépendance du système d’exploitation à l’égard de NTP (sous-réseau Redis) *
1688 Règle de trafic sortant TCP Dépendance du système d’exploitation pour l’activation (sous-réseau Redis) *
8443 Règle de trafic sortant TCP Communications internes pour Redis (sous-réseau Redis) (sous-réseau Redis)
10221-10231 Règle de trafic sortant TCP Communications internes pour Redis (sous-réseau Redis) (sous-réseau Redis)
20226 Règle de trafic sortant TCP Communications internes pour Redis (sous-réseau Redis) (sous-réseau Redis)
13000-13999 Règle de trafic sortant TCP Communications internes pour Redis (sous-réseau Redis) (sous-réseau Redis)
15000-15999 Règle de trafic sortant TCP Communications internes pour Redis et géoréplication (sous-réseau Redis) (Sous-réseau Redis) (Sous-réseau d’homologues géo-réplica)
6379-6380 Règle de trafic sortant TCP Communications internes pour Redis (sous-réseau Redis) (sous-réseau Redis)

1 Vous pouvez utiliser les étiquettes de service AzureKeyVault et AzureMonitor avec des groupes de sécurité réseau Resource Manager.

2 Ces adresses IP appartenant à Microsoft sont utilisées pour adresser la machine virtuelle hôte qui sert Azure DNS.

3 Ces informations ne sont pas nécessaires pour les sous-réseaux sans serveur DNS personnalisé ou pour des caches Redis plus récents qui ignorent le service DNS personnalisé.

4 Pour plus d’informations, consultez Conditions supplémentaires de connexion aux réseaux virtuels.

Exigences relatives aux ports homologues de géoréplication

Si vous utilisez la géoréplication entre caches dans des réseaux virtuels Azure : débloquez les ports a) 15000 à 15999 pour l’ensemble du sous-réseau dans les directions entrante et sortante, et b) vers les deux caches. Cette configuration permet à tous les composants de réplica du sous-réseau de communiquer directement entre eux, même en cas de basculement géographique.

Configuration requise des ports entrants

Il existe huit configurations requises de port entrant. Les requêtes entrantes dans ces plages proviennent d’autres services hébergés dans le même réseau virtuel. Ou, elles sont internes aux communications de sous-réseau Redis.

Ports Sens Protocole de transfert Objectif Adresse IP locale Adresse IP distante
6379, 6380 Trafic entrant TCP Communication client avec Redis, équilibrage de charge Azure (sous-réseau Redis) (sous-réseau Redis), (sous-réseau client), AzureLoadBalancer 1
8443 Trafic entrant TCP Communications internes pour Redis (sous-réseau Redis) (sous-réseau Redis)
8500 Trafic entrant TCP/UDP Équilibrage de charge Azure (sous-réseau Redis) AzureLoadBalancer
10221-10231 Trafic entrant TCP Communication client avec les clusters Redis, communications internes pour Redis (sous-réseau Redis) (sous-réseau Redis), (sous-réseau client), AzureLoadBalancer
13000-13999 Trafic entrant TCP Communication client avec les clusters Redis, équilibrage de charge Azure (sous-réseau Redis) (sous-réseau Redis), (sous-réseau client), AzureLoadBalancer
15000-15999 Trafic entrant TCP Communication client avec les clusters Redis, équilibrage de charge Azure et géoréplication (sous-réseau Redis) (sous-réseau Redis), (sous-réseau client), AzureLoadBalancer, (sous-réseau homologue avec géoréplication)
16001 Trafic entrant TCP/UDP Équilibrage de charge Azure (sous-réseau Redis) AzureLoadBalancer
20226 Trafic entrant TCP Communications internes pour Redis (sous-réseau Redis) (sous-réseau Redis)

1 Vous pouvez utiliser la balise de service AzureLoadBalancer pour Resource Manager ou AZURE_LOADBALANCER pour le modèle de déploiement classique dans le but de créer les règles de groupe de sécurité réseau.

Conditions supplémentaires de connexion aux réseaux virtuels

Il existe des conditions de connexion réseau pour Azure Cache pour Redis qui peuvent ne pas être initialement satisfaites dans un réseau virtuel. Azure Cache pour Redis nécessite tous les éléments suivants pour fonctionner correctement lorsqu’il est utilisé dans un réseau virtuel :

  • Connectivité réseau sortante à des points de terminaison Azure Key Vault dans le monde entier. Les points de terminaison Azure Key Vault sont résolus sous le domaine DNS *.vault.azure.net.
  • Connectivité réseau sortante à des points de terminaison Azure Storage dans le monde entier. Cela inclut les points de terminaison situés dans la même région que l’instance Azure Cache pour Redis, ainsi que les points de terminaison de stockage situés dans d’autres régions Azure. Les points de terminaison stockage Azure se résolvent sous les domaines DNS suivants : *.table.core.windows.net, *.blob.core.windows.net, *.queue.core.windows.netet *.file.core.windows.net.
  • Connectivité réseau sortante vers ocsp.digicert.com, crl4.digicert.com, ocsp.msocsp.com, mscrl.microsoft.com, crl3.digicert.com, cacerts.digicert.com, oneocsp.microsoft.com, et crl.microsoft.com, cacerts.geotrust.com, www.microsoft.com, cdp.geotrust.com, status.geotrust.com. Cette connectivité est nécessaire pour prendre en charge la fonctionnalité TSL/SSL.
  • Connectivité réseau sortante vers les points de terminaison Azure Monitor suivants, qui se résolvent dans les domaines DNS suivants : shoebox3.prod.microsoftmetrics.com, shoebox3-red.prod.microsoftmetrics.com, shoebox3-black.prod.microsoftmetrics.com, azredis.prod.microsoftmetrics.com, azredis-red.prod.microsoftmetrics.com, azredis-black.prod.microsoftmetrics.com, global.prod.microsoftmetrics.com, gcs.prod.monitoring.core.windows.net et *.prod.warm.ingest.monitor.core.windows.net.
  • Connectivité réseau sortante vers les points de terminaison suivants pour les diagnostics internes, qui se résolvent dans les domaines DNS suivants : azurewatsonanalysis-prod.core.windows.net, *.data.microsoft.com, shavamanifestazurecdnprod1.azureedge.net et shavamanifestcdnprod1.azureedge.net.
  • Connectivité réseau sortante vers les points de terminaison suivants du service de mise à jour du système d’exploitation, qui se résolvent dans les domaines DNS suivants : *.update.microsoft.com, *.ctldl.windowsupdate.com et ctldl.windowsupdate.com, *.delivery.mp.microsoft.com et download.windowsupdate.com.
  • Connectivité réseau sortante vers les points de terminaison suivants pour l’antivirus, qui se résolvent dans les domaines DNS suivants : go.microsoft.com, wdcp.microsoft.com, wdcpalt.microsoft.com et definitionupdates.microsoft.com.
  • La configuration DNS pour le réseau virtuel doit être capable de résoudre tous les points de terminaison et les domaines mentionnés dans les points précédents. La configuration DNS requise peut être satisfaite en garantissant qu'une infrastructure DNS valide est configurée et gérée pour le réseau virtuel.

Comment puis-je vérifier que mon cache fonctionne dans un réseau virtuel ?

Important

Quand vous vous connectez à une instance Azure Cache pour Redis hébergée dans un réseau virtuel, vos clients de cache doivent figurer dans le même réseau virtuel ou dans un réseau virtuel pour lequel le peering de réseaux virtuels est activé dans la même région Azure. Le peering global de réseaux virtuels n’est pas pris en charge actuellement. Cette condition s’applique aux applications de test et aux outils de requête de diagnostic. Quel que soit l’endroit où l’application cliente est hébergée, les groupes de sécurité réseau ou d’autres couches réseau doivent être configurés de façon à ce que le trafic réseau du client soit autorisé à atteindre l’instance Azure Cache pour Redis.

Une fois les exigences de port configurées selon la description de la section précédente, un redémarrage est nécessaire dans la plupart des cas pour garantir que les modifications sont correctement appliquées. Sinon, vous pouvez rencontrer des problèmes de connectivité. Vous pouvez vérifier que votre cache fonctionne en procédant comme suit :

  • Redémarrez tous les nœuds de cache. Le cache ne pourra pas redémarrer correctement si toutes les dépendances de cache nécessaires ne sont pas accessibles, telles qu’elles sont décrites dans Configuration requise des ports entrants et Configuration requise des ports sortants.
  • Une fois que les nœuds de cache ont redémarré, comme indiqué par l’état du cache dans le portail Azure, vous pouvez effectuer les tests suivants :

    • Vous pouvez effectuer un test ping du point de terminaison du cache en utilisant le port 6380 à partir d’une machine figurant dans le même réseau virtuel que le cache, à l’aide de tcping. Par exemple :

      tcping.exe contosocache.redis.cache.windows.net 6380

      Si l’outil tcping signale que le port est ouvert, le cache est disponible pour la connexion à partir de clients dans le réseau virtuel.

    • Un autre test consiste à créer un client de cache de test qui se connecte au cache, puis ajoute et récupère des éléments de celui-ci. Le client de cache de test peut être une application console utilisant StackExchange.Redis. Installez l’exemple d’application cliente sur une machine virtuelle figurant dans le même réseau virtuel que le cache. Ensuite, exécutez-la pour vérifier la connectivité au cache.

Quand j’essaie de me connecter à mon instance Azure Cache pour Redis dans un réseau virtuel, pourquoi est-ce que je reçois un message d’erreur indiquant que le certificat distant n’est pas valide ?

Quand vous tentez de vous connecter à une instance Azure Cache pour Redis dans un réseau virtuel, vous voyez une erreur de validation de certificat comme celle-ci :

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

La cause tient peut-être au fait que vous vous connectez à l’hôte par le biais de l’adresse IP. Nous vous recommandons d’utiliser le nom d’hôte. En d’autres termes, utilisez la chaîne suivante :

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Évitez d’utiliser l’adresse IP similaire à la chaîne de connexion suivante :

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Si vous ne parvenez pas à résoudre le nom DNS, certaines bibliothèques clientes incluent des options de configuration comme sslHost, qui est fournie par le client StackExchange.Redis. Cette option vous permet de remplacer le nom d’hôte utilisé pour la validation du certificat. Par exemple :

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

De plus, si le sous-réseau où Azure Cache pour Redis est hébergé bloque les connexions sortantes TCP sur le port 80 pour la fonctionnalité SSL/TLS, les clients peuvent rencontrer des erreurs intermittentes de validation de certificat TLS.

Puis-je utiliser des réseaux virtuels avec un cache De base ou Standard ?

Les réseaux virtuels ne peuvent être utilisés qu’avec des caches de niveau Premium.

Pourquoi la création d’une instance Azure Cache pour Redis échoue-t-elle dans certains sous-réseaux mais pas d’autres ?

Si vous déployez une instance Azure Cache pour Redis dans un réseau virtuel, le cache doit se trouver dans un sous-réseau dédié qui ne contient aucun autre type de ressource. Si vous tentez de déployer une instance Azure Cache pour Redis dans un sous-réseau de réseau virtuel Resource Manager contenant d’autres ressources, telles que des instances Azure Application Gateway ou des règles NAT de trafic sortant, le déploiement échoue en général. Supprimez les autres types de ressources existantes avant de créer une nouvelle instance Azure Cache pour Redis.

Vous devez également disposer de suffisamment d’adresses IP disponibles dans le sous-réseau.

Quelles sont les exigences d’espace d’adressage du sous-réseau ?

Azure réserve dans chaque sous-réseau des adresses IP qui ne peuvent pas être utilisées. Les première et dernière adresse IP des sous-réseaux sont réservées à la conformité du protocole, et 3 adresses supplémentaires sont utilisées pour les services Azure. Pour plus d’informations, consultez Existe-t-il des restrictions sur l’utilisation des adresses IP au sein de ces sous-réseaux ?

Outre les adresses IP utilisées par l’infrastructure de réseau virtuel Azure, chaque instance Azure Cache pour Redis figurant dans le sous-réseau utilise deux adresses IP par partition de cluster, ainsi que des adresses IP pour les réplicas supplémentaires, le cas échéant. Une adresse IP supplémentaire est utilisée pour l’équilibreur de charge. Un cache non cluster est considéré comme ayant une seule partition.

Puis-je me connecter à mon cache à partir d’un réseau virtuel appairé ?

Si les réseaux virtuels se trouvent dans la même région, vous pouvez les connecter via un peering de réseaux virtuels ou une connexion de passerelle VPN de réseau virtuel à réseau virtuel.

Si les réseaux virtuels Azure appairés se trouvent dans des régions différentes : une machine virtuelle cliente dans la région 1 ne peut pas accéder au cache de la région 2 via son adresse IP à charge équilibrée, en raison d’une contrainte avec des équilibreurs de charge de base. Autrement dit, sauf s’il s’agit d’un cache doté d’un équilibreur de charge standard, qui n’est actuellement qu’un cache créé avec des zones de disponibilité.

Pour plus d’informations sur les contraintes liées au peering de réseaux virtuels, consultez Réseau virtuel - Peering - Exigences et contraintes. Une solution consiste à utiliser une connexion de passerelle VPN de réseau virtuel à réseau virtuel au lieu d’un peering de réseaux virtuels.

Toutes les fonctionnalités de cache fonctionnent-elles quand un cache est hébergé dans un réseau virtuel ?

Quand votre cache fait partie d’un réseau virtuel, seuls les clients de ce réseau virtuel peuvent accéder au cache. Par conséquent, les fonctionnalités de gestion de cache suivantes ne fonctionnent pas pour l’instant :

  • Console Redis : comme la console Redis s’exécute dans votre navigateur local, en général sur une machine de développement qui n’est pas connecté au réseau virtuel, elle ne peut pas se connecter à votre cache.

L’injection de réseau virtuel est-elle prise en charge sur un cache dans lequel Azure Lighthouse est activé ?

Non, si Azure Lighthouse est activé pour votre abonnement, vous ne pouvez pas utiliser l’injection de réseau virtuel sur une instance Azure Cache pour Redis. Utilisez des liens privés à la place.

Utiliser ExpressRoute avec le Cache Azure pour Redis

Les clients peuvent connecter un circuit Azure ExpressRoute à leur infrastructure de réseau virtuel. De cette façon, ils étendent leur réseau local à Azure.

Par défaut, un circuit ExpressRoute nouvellement créé ne fait pas de tunneling forcé (publication d’une route par défaut, 0.0.0.0/0) dans un réseau virtuel. Par conséquent, la connectivité Internet sortante est autorisée directement à partir du réseau virtuel. Les applications clientes peuvent se connecter à d’autres points de terminaison Azure, ce qui inclut une instance Azure Cache pour Redis.

Une configuration client courante consiste à utiliser un tunneling forcé (publication d’une route par défaut), ce qui force le trafic Internet sortant à circuler localement à la place. Ce flux de trafic interrompt la connectivité avec Azure Cache pour Redis si le trafic sortant est ensuite bloqué localement, de sorte que l’instance Azure Cache pour Redis ne puisse pas communiquer avec ses dépendances.

La solution consiste à définir une ou plusieurs routes définies par l’utilisateur (UDR) sur le sous-réseau qui contient l’instance Azure Cache pour Redis. Un itinéraire défini par l'utilisateur définit des itinéraires spécifiques au sous-réseau qui seront respectés au lieu de l'itinéraire par défaut.

Si possible, utilisez la configuration suivante :

  • La configuration ExpressRoute publie 0.0.0.0/0 et, par défaut, utilise le tunneling forcé sur tout le trafic sortant local.
  • La route définie par l’utilisateur appliquée au sous-réseau qui contient l’instance Azure Cache pour Redis définit 0.0.0.0/0 avec une route de travail pour le trafic TCP/IP vers le réseau Internet public. Par exemple, elle définit le type de tronçon suivant sur Internet.

L’effet combiné de ces étapes est que la route définie par l’utilisateur au niveau du sous-réseau a la priorité sur le tunneling forcé ExpressRoute, garantissant ainsi un accès Internet sortant à partir de l’instance Azure Cache pour Redis.

La connexion à une instance Azure Cache pour Redis à partir d’une application locale à l’aide d’ExpressRoute n’est pas un scénario d’utilisation standard pour des raisons de performances. Pour des performances optimales, les clients Azure Cache pour Redis doivent se trouver dans la même région que l’instance Azure Cache pour Redis.

Important

Les itinéraires définis dans un UDR doivent être suffisamment spécifiques pour avoir la priorité sur les itinéraires annoncés par la configuration ExpressRoute. L’exemple suivant utilise la plage d’adresses 0.0.0.0/0 étendue, qui peut de ce fait être remplacée accidentellement par des publications de routes utilisant des plages d’adresses plus spécifiques.

Avertissement

Azure Cache pour Redis n’est pas pris en charge avec les configurations ExpressRoute qui publient de manière incorrecte et de façon croisée les routes entre le chemin d’accès de peering Microsoft et le chemin d’accès de peering privé. Les configurations ExpressRoute pour lesquelles le peering Microsoft est configuré reçoivent les publications de routes de Microsoft pour un vaste ensemble de plages d’adresses IP Microsoft Azure. Si ces plages d’adresses sont incorrectement publiées de façon croisée sur le chemin d’accès de peering privé, il en résulte que tous les paquets réseau sortants du sous-réseau de l’instance du Cache Azure pour Redis sont incorrectement acheminés de force vers l’infrastructure réseau locale d’un client. Ce flux réseau interrompt le Cache Azure pour Redis. La solution à ce problème consiste à arrêter la publication croisée des routes entre le chemin d’accès de peering Microsoft et le chemin d’accès de peering privé.

Des informations contextuelles sur les routes définies par l’utilisateur sont disponibles dans Routage du trafic de réseau virtuel.

Pour plus d’informations sur ExpressRoute, voir Aperçu technique d’ExpressRoute.

Contenu connexe

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