Delen via

VNet-ondersteuning (virtueel netwerk) configureren voor een Premium Azure Cache voor Redis-exemplaar

  • Artikel

Azure Virtual Network-implementatie biedt verbeterde beveiliging en isolatie, samen met: subnetten, toegangsbeheerbeleid en andere functies om de toegang verder te beperken. Wanneer een Azure Cache voor Redis-exemplaar is geconfigureerd met een virtueel netwerk, is het niet openbaar adresseerbaar. In plaats daarvan kan het exemplaar alleen worden geopend vanuit virtuele machines en toepassingen binnen het virtuele netwerk. In dit artikel wordt beschreven hoe u ondersteuning voor virtuele netwerken configureert voor een Premium-laag Azure Cache voor Redis exemplaar.

Notitie

Het klassieke implementatiemodel wordt in augustus 2024 buiten gebruik gesteld. Zie Cloud Services (klassiek) implementatiemodel op 31 augustus 2024 buiten gebruik gesteld voor meer informatie.

Belangrijk

Azure Cache voor Redis raadt u aan om Azure Private Link te gebruiken, wat de netwerkarchitectuur vereenvoudigt en de verbinding tussen eindpunten in Azure beveiligt. U kunt vanuit uw virtuele netwerk verbinding maken met een Azure Cache-exemplaar via een privé-eindpunt, waaraan een privé-IP-adres in een subnet binnen het virtuele netwerk is toegewezen. Azure Private Links worden aangeboden in alle lagen en bevatten Azure Policy-ondersteuning en vereenvoudigd beheer van NSG-regels. Zie de Private Link-documentatie voor meer informatie. Zie Caches met VNet-injectie migreren naar Private Link-caches om uw caches met VNet-injectie te migreren naar Private Link.

Beperkingen van VNet-injectie

  • Het maken en onderhouden van configuraties voor virtuele netwerken is vaak foutgevoelig. Het oplossen van problemen is ook lastig. Onjuiste configuraties voor virtuele netwerken kunnen leiden tot problemen:
    • geblokkeerde overdracht van metrische gegevens van uw cache-exemplaren
    • fout van replicaknooppunt om gegevens te repliceren van primair knooppunt
    • mogelijk gegevensverlies
    • mislukte beheerbewerkingen, zoals schalen
    • in de meest ernstige scenario's, verlies van beschikbaarheid
  • In VNet geïnjecteerde caches zijn alleen beschikbaar voor Premium-laag Azure Cache voor Redis, niet voor andere lagen.
  • Wanneer u een in VNet geïnjecteerde cache gebruikt, moet u uw VNet wijzigen in de cache van afhankelijkheden zoals CRL's/PKI, AKV, Azure Storage, Azure Monitor en meer.
  • U kunt een bestaand Azure Cache voor Redis exemplaar niet injecteren in een virtueel netwerk. U moet deze optie selecteren wanneer u de cache maakt .

Ondersteuning voor virtueel netwerk instellen

Ondersteuning voor virtuele netwerken wordt geconfigureerd in het deelvenster Nieuw Azure Cache voor Redis tijdens het maken van de cache.

  1. Als u een Premium-laag-cache wilt maken, meldt u zich aan bij Azure Portal en selecteert u Een resource maken. U kunt ze ook maken met behulp van Resource Manager-sjablonen, PowerShell of de Azure CLI. Zie Een cache maken voor meer informatie over het maken van een Azure Cache voor Redis exemplaar.

    Schermopname van Een resource maken.

  2. Selecteer Databases op de pagina Nieuw. Selecteer vervolgens Azure Cache voor Redis.

    Schermopname van het selecteren van Azure Cache voor Redis.

  3. Configureer op de pagina Nieuwe Redis Cache de instellingen voor de nieuwe Premium-laag-cache.

    Instelling Voorgestelde waarde Beschrijving
    DNS-naam Voer een wereldwijd unieke naam in. De cachenaam moet een tekenreeks tussen 1 en 63 tekens zijn die alleen cijfers, letters of afbreekstreepjes bevatten. De naam moet beginnen en eindigen met een getal of letter en mag geen opeenvolgende afbreekstreepjes bevatten. De hostnaam van uw cache-exemplaar is\<DNS name>.redis.cache.windows.net.
    Abonnement Selecteer uw abonnement in de vervolgkeuzelijst. Het abonnement waarmee dit nieuwe Azure Cache voor Redis-exemplaar wordt gemaakt.
    Resourcegroep Selecteer een resourcegroep in de vervolgkeuzelijst of selecteer Nieuwe maken en voer een nieuwe resourcegroepnaam in. De naam voor de resourcegroep waarin u uw cache en andere resources maakt. Door al uw app-resources in één resourcegroep te plaatsen, kunt u ze eenvoudig beheren of verwijderen.
    Location Selecteer een locatie in de vervolgkeuzelijst. Selecteer een regio in de buurt van andere services die gaan gebruikmaken van de cache.
    Cachetype Selecteer een Cache in de Premium-laag in de vervolgkeuzelijst om functies voor Premium-lagen te configureren. Zie Prijzen van Azure Cache voor Redis voor meer informatie. De prijscategorie bepaalt de grootte, prestaties en functies die beschikbaar zijn voor de cache. Zie Azure Cache voor Redis overzicht voor meer informatie.

  4. Selecteer het tabblad Netwerken of selecteer de knop Netwerken onderaan de pagina.

  5. Selecteer Op het tabblad Netwerken de optie Virtuele netwerken als uw connectiviteitsmethode. Als u een nieuw virtueel netwerk wilt gebruiken, maakt u het eerst door de stappen te volgen in Een virtueel netwerk maken met behulp van Azure Portal of een virtueel netwerk (klassiek) maken met behulp van Azure Portal. Ga vervolgens terug naar het deelvenster Nieuw Azure Cache voor Redis om uw Premium-laag-cache te maken en te configureren.

    Belangrijk

    Wanneer u Azure Cache voor Redis implementeert in een virtueel Resource Manager-netwerk, moet de cache zich in een toegewezen subnet bevinden dat geen andere resources bevat, met uitzondering van Azure Cache voor Redis exemplaren. Als u probeert een Azure Cache voor Redis-exemplaar te implementeren in een virtueel Resource Manager-netwerksubnet dat andere resources bevat of als er een NAT Gateway aan is toegewezen, mislukt de implementatie. De fout komt doordat Azure Cache voor Redis gebruikmaakt van een eenvoudige load balancer die niet compatibel is met een NAT-gateway.

    Instelling Voorgestelde waarde Beschrijving
    Virtueel netwerk Selecteer uw virtuele netwerk in de vervolgkeuzelijst. Selecteer een virtueel netwerk dat zich in hetzelfde abonnement en dezelfde locatie bevindt als uw cache.
    Subnet Selecteer uw subnet in de vervolgkeuzelijst. Het adresbereik van het subnet moet de CIDR-notatie hebben (bijvoorbeeld 192.168.1.0/24). Deze moet zijn opgenomen in de adresruimte van het virtuele netwerk.
    Statisch IP-adres (Optioneel) Voer een statisch IP-adres in. Als u geen statisch IP-adres opgeeft, wordt automatisch een IP-adres gekozen.

    Belangrijk

    Azure reserveert een aantal IP-adressen binnen elk subnet en deze adressen kunnen niet worden gebruikt. Het eerste en het laatste IP-adres van de subnetten worden gereserveerd voor protocolconformiteit en dan zijn er nog drie adressen voor Azure-services. Raadpleeg Zijn er beperkingen voor het gebruik van IP-adressen in deze subnetten? voor meer informatie.

    Naast de IP-adressen die worden gebruikt door de infrastructuur van het virtuele Azure-netwerk, wordt voor elk Azure Cache voor Redis-exemplaar in het subnet gebruikgemaakt van twee IP-adressen per shard en één extra IP-adres voor de load balancer. Een niet-geclusterde cache wordt geacht over één shard te beschikken.

  6. Selecteer het tabblad Volgende: Geavanceerd of selecteer de knop Volgende: Geavanceerd onder aan de pagina.

  7. Configureer op het tabblad Geavanceerd voor een cache-exemplaar in de Premium-laag de instellingen voor niet-TLS-poort, clustering en gegevenspersistentie.

  8. Selecteer het tabblad Volgende: Tags of selecteer de knop Volgende: Tags onderaan de pagina.

  9. Voer desgewenst op het tabblad Tags de naam en waarde in als u de resource wilt categoriseren.

  10. Selecteer Controleren + maken. U gaat naar het tabblad Controleren en maken , waar Azure uw configuratie valideert.

  11. Nadat het groene bericht Validatie is geslaagd , selecteert u Maken.

Het duurt even voor de cache is gemaakt. U kunt de voortgang bekijken op de overzichtspagina van Azure Cache voor Redis. Als u bij Status Wordt uitgevoerd ziet staan, kunt u de cache gebruiken. Nadat de cache is gemaakt, kunt u de configuratie voor het virtuele netwerk weergeven door Virtueel netwerk te selecteren in het menu Resource.

Virtueel netwerk

Veelgestelde vragen over virtuele netwerken voor Azure Cache voor Redis

De volgende lijst bevat antwoorden op veelgestelde vragen over Azure Cache voor Redis netwerken.

Wat zijn enkele veelvoorkomende problemen met onjuiste configuratie met Azure Cache voor Redis en virtuele netwerken?

Wanneer Azure Cache voor Redis wordt gehost in een virtueel netwerk, worden de poorten in de volgende tabellen gebruikt.

Belangrijk

Als de poorten in de volgende tabellen worden geblokkeerd, werkt de cache mogelijk niet correct. Het blokkeren van een of meer van deze poorten is het meest voorkomende probleem met onjuiste configuratie wanneer u Azure Cache voor Redis in een virtueel netwerk gebruikt.

Vereisten voor de uitgaande poort

Er zijn negen vereisten voor uitgaande poorten. Uitgaande aanvragen in deze bereiken zijn: a) uitgaand naar andere services die nodig zijn om de cache te laten functioneren, of b) intern voor het Redis-subnet voor communicatie tussen knooppunten. Voor geo-replicatie bestaan er andere uitgaande vereisten voor communicatie tussen subnetten van de primaire en replicacache.

Poorten Richting Transportprotocol Doel Lokaal IP-adres Extern IP-adres
80, 443 Uitgaand TCP Redis-afhankelijkheden op Azure Storage/PKI (internet) (Redis-subnet) * 4
443 Uitgaand TCP Redis-afhankelijkheid van Azure Key Vault en Azure Monitor (Redis-subnet) AzureKeyVault, AzureMonitor 1
53 Uitgaand TCP/UDP Redis-afhankelijkheden op DNS (internet/virtueel netwerk) (Redis-subnet) 168.63.129.16 en 169.254.169.254 2 en eventuele aangepaste DNS-server voor het subnet 3
8443 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
10221-10231 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
20226 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
13000-13999 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
15000-15999 Uitgaand TCP Interne communicatie voor Redis en geo-replicatie (Redis-subnet) (Redis-subnet) (Geo-replica-peersubnet)
6379-6380 Uitgaand TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)

1 U kunt de servicetags AzureKeyVault en AzureMonitor gebruiken met netwerkbeveiligingsgroepen (NSG's) van Resource Manager.

2 Deze IP-adressen die eigendom zijn van Microsoft, worden gebruikt om de host-VM te adresseren die azure DNS dient.

3 Deze informatie is niet nodig voor subnetten zonder aangepaste DNS-server of nieuwere Redis-caches die aangepaste DNS negeren.

4 Zie Aanvullende vereisten voor virtuele netwerkconnectiviteit voor meer informatie.

Vereisten voor geo-replicatie peer-poort

Als u geo-replicatie tussen caches in virtuele Azure-netwerken gebruikt: a) deblokkeren poorten 15000-15999 voor het hele subnet in zowel binnenkomende als uitgaande richtingen, en b) naar beide caches. Met deze configuratie kunnen alle replicaonderdelen in het subnet rechtstreeks met elkaar communiceren, zelfs als er een toekomstige geo-failover is.

Vereisten voor inkomende poort

Er zijn acht binnenkomende poortbereikvereisten. Binnenkomende aanvragen in deze bereiken zijn binnenkomend van andere services die worden gehost in hetzelfde virtuele netwerk. Of ze zijn intern voor de communicatie van het Redis-subnet.

Poorten Richting Transportprotocol Doel Lokaal IP-adres Extern IP-adres
6379, 6380 Inkomend TCP Clientcommunicatie met Redis, Azure-taakverdeling (Redis-subnet) (Redis-subnet), (clientsubnet), AzureLoadBalancer 1
8443 Inkomend TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)
8500 Inkomend TCP/UDP Azure-taakverdeling (Redis-subnet) AzureLoadBalancer
10221-10231 Inkomend TCP Clientcommunicatie met Redis-clusters, interne communicatie voor Redis (Redis-subnet) (Redis-subnet), (clientsubnet), AzureLoadBalancer
13000-13999 Inkomend TCP Clientcommunicatie met Redis-clusters, Azure-taakverdeling (Redis-subnet) (Redis-subnet), (clientsubnet), AzureLoadBalancer
15000-15999 Inkomend TCP Clientcommunicatie met Redis-clusters, Azure-taakverdeling en geo-replicatie (Redis-subnet) (Redis-subnet), (clientsubnet), AzureLoadBalancer, (geo-replica peersubnet)
16001 Inkomend TCP/UDP Azure-taakverdeling (Redis-subnet) AzureLoadBalancer
20226 Inkomend TCP Interne communicatie voor Redis (Redis-subnet) (Redis-subnet)

1 U kunt de servicetag AzureLoadBalancer gebruiken voor Resource Manager of AZURE_LOADBALANCER voor het klassieke implementatiemodel voor het ontwerpen van de NSG-regels.

Aanvullende vereisten voor virtuele netwerkconnectiviteit

Er zijn vereisten voor netwerkconnectiviteit voor Azure Cache voor Redis die mogelijk niet in eerste instantie worden voldaan in een virtueel netwerk. Azure Cache voor Redis vereist dat alle volgende items correct werken wanneer ze in een virtueel netwerk worden gebruikt:

  • Uitgaande netwerkconnectiviteit met Azure Key Vault-eindpunten wereldwijd. Azure Key Vault-eindpunten worden omgezet onder het DNS-domein vault.azure.net.
  • Uitgaande netwerkconnectiviteit met Azure Storage-eindpunten wereldwijd. Eindpunten die zich in dezelfde regio bevinden als de Azure Cache voor Redis-instantie en opslageindpunten die zich in andere Azure-regio's bevinden, worden opgenomen. Azure Storage-eindpunten worden omgezet onder de volgende DNS-domeinen: table.core.windows.net, blob.core.windows.net, queue.core.windows.neten file.core.windows.net.
  • Uitgaande netwerkconnectiviteit met ocsp.digicert.com, , crl4.digicert.com, ocsp.msocsp.com, mscrl.microsoft.com, crl3.digicert.com, , cacerts.digicert.com, , , en oneocsp.microsoft.com.crl.microsoft.com Deze verbinding is nodig om TLS/SSL-functionaliteit te ondersteunen.
  • De DNS-configuratie voor het virtuele netwerk moet alle eindpunten en domeinen die in de eerdere punten zijn genoemd, kunnen oplossen. Aan deze DNS-vereisten kan worden voldaan door ervoor te zorgen dat een geldige DNS-infrastructuur is geconfigureerd en onderhouden voor het virtuele netwerk.
  • Uitgaande netwerkconnectiviteit met de volgende Azure Monitor-eindpunten, die worden omgezet onder de volgende DNS-domeinen: shoebox2-black.shoebox2.metrics.nsatc.net, , north-prod2.prod2.metrics.nsatc.net, azglobal-black.azglobal.metrics.nsatc.netshoebox2-red.shoebox2.metrics.nsatc.net, east-prod2.prod2.metrics.nsatc.net, , azglobal-red.azglobal.metrics.nsatc.net, shoebox3.prod.microsoftmetrics.com, , shoebox3-red.prod.microsoftmetrics.comen . azredis-red.prod.microsoftmetrics.com azredis-black.prod.microsoftmetrics.comshoebox3-black.prod.microsoftmetrics.com

Hoe kan ik controleren of mijn cache in een virtueel netwerk werkt?

Belangrijk

Wanneer u verbinding maakt met een Azure Cache voor Redis exemplaar dat wordt gehost in een virtueel netwerk, moeten uw cacheclients zich in hetzelfde virtuele netwerk bevinden of in een virtueel netwerk met peering van virtuele netwerken ingeschakeld binnen dezelfde Azure-regio. Wereldwijde peering van virtuele netwerken wordt momenteel niet ondersteund. Deze vereiste is van toepassing op alle testtoepassingen of hulpprogramma's voor diagnostisch pingen. Ongeacht waar de clienttoepassing wordt gehost, moeten NSG's of andere netwerklagen zodanig worden geconfigureerd dat het netwerkverkeer van de client de Azure Cache voor Redis kan bereiken.

Nadat de poortvereisten zijn geconfigureerd zoals beschreven in de vorige sectie, is opnieuw opstarten in de meeste gevallen nodig om ervoor te zorgen dat de wijzigingen correct worden weergegeven. Anders kunnen er verbindingsproblemen optreden. U kunt controleren of uw cache werkt door de volgende stappen uit te voeren:

  • Start alle cacheknooppunten opnieuw op . De cache kan niet opnieuw worden opgestart als alle vereiste cacheafhankelijkheden niet kunnen worden bereikt---as gedocumenteerd in de vereisten voor binnenkomende poorten en vereisten voor uitgaande poorten.
  • Nadat de cacheknooppunten opnieuw zijn opgestart, zoals gerapporteerd door de cachestatus in Azure Portal, kunt u de volgende tests uitvoeren:

    • Ping het cache-eindpunt met behulp van poort 6380 vanaf een computer die zich binnen hetzelfde virtuele netwerk bevindt als de cache, met behulp van tcping. Voorbeeld:

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

      Als het tcping hulpprogramma meldt dat de poort is geopend, is de cache beschikbaar voor verbinding vanaf clients in het virtuele netwerk.

    • Een andere manier om te testen: maak een testcacheclient die verbinding maakt met de cache en voegt vervolgens enkele items uit de cache toe en haalt deze op. De testcacheclient kan een consoletoepassing zijn met behulp van StackExchange.Redis. Installeer de voorbeeldclienttoepassing op een virtuele machine die zich in hetzelfde virtuele netwerk bevindt als de cache. Voer deze vervolgens uit om de verbinding met de cache te controleren.

Wanneer ik verbinding probeer te maken met mijn Azure Cache voor Redis exemplaar in een virtueel netwerk, waarom krijg ik een foutmelding waarin wordt aangegeven dat het externe certificaat ongeldig is?

Wanneer u verbinding probeert te maken met een Azure Cache voor Redis exemplaar in een virtueel netwerk, ziet u een certificaatvalidatiefout zoals deze:

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

De oorzaak kan zijn dat u verbinding maakt met de host door het IP-adres. U wordt aangeraden de hostnaam te gebruiken. Gebruik met andere woorden de volgende tekenreeks:

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

Vermijd het gebruik van het IP-adres dat lijkt op de volgende verbindingsreeks:

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

Als u de DNS-naam niet kunt oplossen, bevatten sommige clientbibliotheken configuratieopties zoals sslHost, die worden geleverd door de StackExchange.Redis-client. Met deze optie kunt u de hostnaam overschrijven die wordt gebruikt voor certificaatvalidatie. Voorbeeld:

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

Kan ik virtuele netwerken gebruiken met een standaard- of basiscache?

Virtuele netwerken kunnen alleen worden gebruikt met Premium-laag-caches.

Waarom mislukt het maken van een Azure Cache voor Redis exemplaar in sommige subnetten, maar niet in andere?

Als u een Azure Cache voor Redis exemplaar implementeert in een virtueel netwerk, moet de cache zich in een toegewezen subnet bevinden dat geen ander resourcetype bevat. Als er een poging wordt gedaan om een Azure Cache voor Redis-exemplaar te implementeren in een subnet van een virtueel Resource Manager-netwerk dat andere resources bevat--- zoals Azure-toepassing Gateway-exemplaren en uitgaande NAT---de implementatie mislukt meestal. Verwijder de bestaande resources van andere typen voordat u een nieuw exemplaar van Azure Cache voor Redis maakt.

U moet ook voldoende IP-adressen beschikbaar hebben in het subnet.

Wat zijn de adresruimtevereisten voor het subnet?

Azure reserveert een aantal IP-adressen binnen elk subnet en deze adressen kunnen niet worden gebruikt. Het eerste en het laatste IP-adres van de subnetten worden gereserveerd voor protocolconformiteit en dan zijn er nog drie adressen voor Azure-services. Raadpleeg Zijn er beperkingen voor het gebruik van IP-adressen in deze subnetten? voor meer informatie.

Naast de IP-adressen die worden gebruikt door de infrastructuur van het virtuele Azure-netwerk, gebruikt elk Azure Cache voor Redis exemplaar in het subnet twee IP-adressen per cluster-shard, plus IP-adressen voor extra replica's, indien van toepassing. Er wordt nog een IP-adres gebruikt voor de load balancer. Een niet-geclusterde cache wordt beschouwd als één shard.

Kan ik verbinding maken met mijn cache vanuit een virtueel peernetwerk?

Als de virtuele netwerken zich in dezelfde regio bevinden, kunt u deze verbinden met behulp van peering van virtuele netwerken of een VNET-naar-VNET-verbinding voor VPN Gateway.

Als de gekoppelde virtuele Azure-netwerken zich in verschillende regio's bevinden: een client-VM in regio 1 heeft geen toegang tot de cache in regio 2 via het IP-adres met gelijke taakverdeling vanwege een beperking met eenvoudige load balancers. Dat wil gezegd, tenzij het een cache is met een standaard load balancer, wat momenteel alleen een cache is die is gemaakt met beschikbaarheidszones.

Zie Virtual Network - Peering - Vereisten en beperkingen voor meer informatie over peeringbeperkingen voor virtuele netwerken. Een oplossing is het gebruik van een VPN Gateway-VNET-naar-VNET-verbinding in plaats van peering van virtuele netwerken.

Werken alle cachefuncties wanneer een cache wordt gehost in een virtueel netwerk?

Wanneer uw cache deel uitmaakt van een virtueel netwerk, hebben alleen clients in het virtuele netwerk toegang tot de cache. Als gevolg hiervan werken de volgende cachebeheerfuncties op dit moment niet:

  • Redis Console: Omdat Redis-console wordt uitgevoerd in uw lokale browser---usually op een ontwikkelcomputer die niet is verbonden met het virtuele netwerk---it kan vervolgens geen verbinding maken met uw cache.

Wordt VNet-injectie ondersteund in een cache waarvoor Azure Lighthouse is ingeschakeld?

Nee, als voor uw abonnement Azure Lighthouse is ingeschakeld, kunt u VNet-injectie niet gebruiken op een Azure Cache voor Redis exemplaar. Gebruik in plaats daarvan privékoppelingen.

ExpressRoute gebruiken met Azure Cache voor Redis

Klanten kunnen een Azure ExpressRoute-circuit verbinden met hun virtuele netwerkinfrastructuur. Op deze manier breiden ze hun on-premises netwerk uit naar Azure.

Een nieuw expressRoute-circuit maakt standaard geen gebruik van geforceerde tunneling (aankondiging van een standaardroute, 0.0.0.0/0) in een virtueel netwerk. Hierdoor is uitgaande internetverbinding rechtstreeks vanuit het virtuele netwerk toegestaan. Clienttoepassingen kunnen verbinding maken met andere Azure-eindpunten, waaronder een Azure Cache voor Redis-exemplaar.

Een algemene klantconfiguratie is het gebruik van geforceerde tunneling (adverteren van een standaardroute), waardoor uitgaand internetverkeer wordt gedwongen om on-premises te stromen. Deze verkeersstroom breekt de connectiviteit met Azure Cache voor Redis als het uitgaande verkeer vervolgens on-premises wordt geblokkeerd, zodat het Azure Cache voor Redis exemplaar niet kan communiceren met de afhankelijkheden.

De oplossing is het definiëren van een of meer door de gebruiker gedefinieerde routes (UDR's) in het subnet dat het Azure Cache voor Redis-exemplaar bevat. Een UDR definieert subnetspecifieke routes die worden uitgevoerd in plaats van de standaardroute.

Gebruik indien mogelijk de volgende configuratie:

  • De ExpressRoute-configuratie adverteert 0.0.0.0/0 en forceert standaard al het uitgaande verkeer on-premises.
  • De UDR die is toegepast op het subnet dat het Azure Cache voor Redis-exemplaar bevat, definieert 0.0.0.0/0 met een werkroute voor TCP/IP-verkeer naar het openbare internet. Het volgende hoptype wordt bijvoorbeeld ingesteld op internet.

Het gecombineerde effect van deze stappen is dat de UDR op subnetniveau voorrang heeft op de geforceerde ExpressRoute-tunneling en dat zorgt voor uitgaande internettoegang vanaf het Azure Cache voor Redis exemplaar.

Het maken van verbinding met een Azure Cache voor Redis exemplaar vanuit een on-premises toepassing met behulp van ExpressRoute is vanwege prestatieredenen geen typisch gebruiksscenario. Voor de beste prestaties moeten Azure Cache voor Redis clients zich in dezelfde regio bevinden als het Azure Cache voor Redis-exemplaar.

Belangrijk

De routes die in een UDR zijn gedefinieerd, moeten specifiek genoeg zijn om voorrang te krijgen op alle routes die worden aangekondigd door de ExpressRoute-configuratie. In het volgende voorbeeld wordt gebruikgemaakt van het brede adresbereik 0.0.0.0/0 en kan mogelijk per ongeluk worden overschreven door routeadvertenties die meer specifieke adresbereiken gebruiken.

Waarschuwing

Azure Cache voor Redis wordt niet ondersteund met ExpressRoute-configuraties die onjuist routes van het openbare peeringpad naar het privépeeringspad adverteren. ExpressRoute-configuraties waarvoor openbare peering is geconfigureerd, ontvangen routeadvertenties van Microsoft voor een grote set IP-adresbereiken van Microsoft Azure. Als deze adresbereiken onjuist worden geadverteerd op het privé-peeringpad, is het resultaat dat alle uitgaande netwerkpakketten van het subnet van het Azure Cache voor Redis exemplaar onjuist geforceerd worden geforceerd naar de on-premises netwerkinfrastructuur van een klant. Deze netwerkstroom breekt Azure Cache voor Redis. De oplossing voor dit probleem is het stoppen van cross-advertising routes van het openbare peeringpad naar het privépeeringspad.

Achtergrondinformatie over UDR's is beschikbaar in routering van virtueel netwerkverkeer.

Zie het technische overzicht van ExpressRoute voor meer informatie over ExpressRoute.

Gerelateerde inhoud

Meer informatie over Azure Cache voor Redis functies.