Konfigurera stöd för virtuella nätverk (VNet) för en Premium Azure Cache for Redis-instans

  • Artikel

Azure Virtual Network-distribution ger förbättrad säkerhet och isolering tillsammans med: undernät, principer för åtkomstkontroll och andra funktioner för att begränsa åtkomsten ytterligare. När en Azure Cache for Redis-instans konfigureras med ett virtuellt nätverk kan den inte adresseras offentligt. I stället kan instansen endast nås från virtuella datorer och program i det virtuella nätverket. Den här artikeln beskriver hur du konfigurerar stöd för virtuella nätverk för en Azure Cache for Redis-instans på Premium-nivå.

Kommentar

Den klassiska distributionsmodellen dras tillbaka i augusti 2024. Mer information finns i Distributionsmodellen för Cloud Services (klassisk) upphör den 31 augusti 2024.

Viktigt!

Azure Cache for Redis rekommenderar att du använder Azure Private Link, vilket förenklar nätverksarkitekturen och skyddar anslutningen mellan slutpunkter i Azure. Med Private Link kan du ansluta till en Azure Cache for Redis-instans från ditt virtuella nätverk via en privat slutpunkt, som tilldelas en privat IP-adress i ett undernät till det virtuella nätverket. Privata Azure-länkar erbjuds på alla nivåer, de har stöd för Azure Policy och förenklad hantering av NSG-regler. Läs mer i Private Link-dokumentationen. Om du vill migrera dina VNet-inmatade cacheminnen till Private Link läser du Migrera från VNet-inmatade cacheminnen till Private Link.

Begränsningar för VNet-inmatning

  • Det är ofta felbenäget att skapa och underhålla konfigurationer för virtuella nätverk. Felsökning är också en utmaning. Felaktiga konfigurationer av virtuella nätverk kan leda till problem:
    • hindrad överföring av mått från dina cacheinstanser
    • fel på repliknoden för att replikera data från den primära noden
    • potentiell dataförlust
    • fel vid hanteringsåtgärder som skalning
    • i de allvarligaste scenarierna, förlust av tillgänglighet
  • VNet-inmatade cacheminnen är endast tillgängliga för Azure Cache for Redis på Premium-nivå, inte för andra nivåer.
  • När du använder ett VNet-inmatat cacheminne måste du ändra ditt virtuella nätverk till cacheberoenden som CRLs/PKI, AKV, Azure Storage, Azure Monitor med mera.
  • Du kan inte mata in en befintlig Azure Cache for Redis-instans i ett virtuellt nätverk. Du måste välja det här alternativet när du skapar cacheminnet.

Konfigurera stöd för virtuellt nätverk

Stöd för virtuella nätverk konfigureras i fönstret New Azure Cache for Redis när cachen skapas.

  1. Om du vill skapa en Premium-nivåcache loggar du in på Azure-portalen och väljer Skapa en resurs. Du kan också skapa dem med hjälp av Resource Manager-mallar, PowerShell eller Azure CLI. Mer information om hur du skapar en Azure Cache for Redis-instans finns i Skapa en cache.

    Screenshot that shows Create a resource.

  2. På sidan Nytt väljer du Databaser. Välj sedan Azure Cache for Redis.

    Screenshot that shows selecting Azure Cache for Redis.

  3. På sidan Ny Redis Cache konfigurerar du inställningarna för din nya Cache på Premium-nivå.

    Inställning Föreslaget värde beskrivning
    DNS-namn Ange ett globalt unikt namn. Cachenamnet måste vara en sträng mellan 1 och 63 tecken som endast innehåller siffror, bokstäver eller bindestreck. Namnet måste börja och sluta med ett tal eller en bokstav, och det får inte innehålla bindestreck i följd. Värdnamnet för cacheinstansen blir \<DNS name>.redis.cache.windows.net.
    Abonnemang Välj din prenumeration i listrutan. Prenumerationen som den nya Azure Cache for Redis-instansen ska skapas under.
    Resursgrupp Välj en resursgrupp i listrutan eller välj Skapa ny och ange ett nytt resursgruppsnamn. Namnet på resursgruppen där cacheminnet och andra resurser ska skapas. Genom att placera alla dina appresurser i en resursgrupp kan du enkelt hantera eller ta bort dem tillsammans.
    Plats Välj en plats i listrutan. Välj en region nära andra tjänster som ska använda din cache.
    Cachetyp Välj en Premium-nivåcache i listrutan för att konfigurera premiumfunktioner. Mer information finns i Priser för Azure Cache for Redis. Prisnivån avgör storlek, prestanda och funktioner som är tillgängliga för cacheminnet. Mer information finns i Översikt över Azure Cache for Redis.

  4. Välj fliken Nätverk eller välj knappen Nätverk längst ned på sidan.

  5. På fliken Nätverk väljer du Virtuella nätverk som anslutningsmetod. Om du vill använda ett nytt virtuellt nätverk skapar du det först genom att följa stegen i Skapa ett virtuellt nätverk med azure-portalen eller Skapa ett virtuellt nätverk (klassiskt) med hjälp av Azure-portalen. Gå sedan tillbaka till fönstret Ny Azure Cache for Redis för att skapa och konfigurera din Premium-nivåcache.

    Viktigt!

    När du distribuerar Azure Cache for Redis till ett virtuellt Resource Manager-nätverk måste cachen finnas i ett dedikerat undernät som inte innehåller några andra resurser förutom Azure Cache for Redis-instanser. Om du försöker distribuera en Azure Cache for Redis-instans till ett virtuellt Resource Manager-undernät som innehåller andra resurser eller har en NAT Gateway tilldelad misslyckas distributionen. Felet beror på att Azure Cache for Redis använder en grundläggande lastbalanserare som inte är kompatibel med en NAT Gateway.

    Inställning Föreslaget värde beskrivning
    Virtuellt nätverk Välj ditt virtuella nätverk i listrutan. Välj ett virtuellt nätverk som finns i samma prenumeration och plats som din cache.
    Undernät Välj ditt undernät i listrutan. Undernätets adressintervall ska vara i CIDR-notation (till exempel 192.168.1.0/24). Den måste finnas i adressutrymmet för det virtuella nätverket.
    Statisk IP-adress (Valfritt) Ange en statisk IP-adress. Om du inte anger en statisk IP-adress väljs en IP-adress automatiskt.

    Viktigt!

    Azure reserverar vissa IP-adresser inom varje undernät och dessa adresser kan inte användas. De första och sista IP-adresserna i undernäten är reserverade för protokollöverensstämmelse, tillsammans med ytterligare tre adresser som används för Azure-tjänster. Mer information finns i Finns det några begränsningar för att använda IP-adresser i sådana undernät?

    Förutom de IP-adresser som används av den virtuella nätverksinfrastrukturen i Azure använder varje Azure Cache for Redis-instans i undernätet två IP-adresser per shard och en ytterligare IP-adress för lastbalanseraren. En icke-grupperad cache anses ha en shard.

  6. Välj fliken Nästa: Avancerat eller välj knappen Nästa: Avancerat längst ned på sidan.

  7. På fliken Avancerat för en cacheinstans på Premium-nivå konfigurerar du inställningarna för icke-TLS-port, klustring och datapersistence.

  8. Välj fliken Nästa: Taggar eller välj knappen Nästa: Taggar längst ned på sidan.

  9. Du kan också ange namnet och värdet på fliken Taggar om du vill kategorisera resursen.

  10. Välj Granska + skapa. Du kommer till fliken Granska + skapa där Azure verifierar din konfiguration.

  11. När det gröna verifieringsmeddelandet har skickats väljer du Skapa.

Det tar en stund innan cacheminnet skapas. Du kan övervaka förloppet på översiktssidan för Azure Cache for Redis. När Status visas som Körs är cachen redo att användas. När cacheminnet har skapats kan du visa konfigurationen för det virtuella nätverket genom att välja Virtuellt nätverk på resursmenyn .

Virtual network

Vanliga frågor och svar om virtuella nätverk i Azure Cache for Redis

Följande lista innehåller svar på vanliga frågor om Azure Cache for Redis-nätverk.

Vilka är några vanliga felkonfigurationsproblem med Azure Cache for Redis och virtuella nätverk?

När Azure Cache for Redis finns i ett virtuellt nätverk används portarna i följande tabeller.

Viktigt!

Om portarna i följande tabeller blockeras kanske cacheminnet inte fungerar korrekt. Att blockera en eller flera av dessa portar är det vanligaste felkonfigurationsproblemet när du använder Azure Cache for Redis i ett virtuellt nätverk.

Krav för utgående portar

Det finns nio portkrav för utgående trafik. Utgående begäranden i dessa intervall är antingen: a) utgående till andra tjänster som krävs för att cacheminnet ska fungera eller b) internt i Redis-undernätet för internode-kommunikation. För geo-replikering finns det andra utgående krav för kommunikation mellan undernät i den primära cachen och replikcachen.

Portar Riktning Transportprotokoll Syfte Lokal IP-adress Fjärr-IP
80, 443 Utgående TCP Redis-beroenden på Azure Storage/PKI (Internet) (Redis-undernät) * 4
443 Utgående TCP Redis-beroende av Azure Key Vault och Azure Monitor (Redis-undernät) AzureKeyVault, AzureMonitor 1
53 Utgående TCP/UDP Redis-beroenden i DNS (internet/virtuellt nätverk) (Redis-undernät) 168.63.129.16 och 169.254.169.254 2 och alla anpassade DNS-servrar för undernätet 3
8443 Utgående TCP Intern kommunikation för Redis (Redis-undernät) (Redis-undernät)
10221-10231 Utgående TCP Intern kommunikation för Redis (Redis-undernät) (Redis-undernät)
20226 Utgående TCP Intern kommunikation för Redis (Redis-undernät) (Redis-undernät)
13000-13999 Utgående TCP Intern kommunikation för Redis (Redis-undernät) (Redis-undernät)
15000-15999 Utgående TCP Intern kommunikation för Redis och geo-replikering (Redis-undernät) (Redis-undernät) (Peer-undernät för geo-replikering)
6379-6380 Utgående TCP Intern kommunikation för Redis (Redis-undernät) (Redis-undernät)

1 Du kan använda tjänsttaggar för AzureKeyVault och AzureMonitor med Resource Manager-nätverkssäkerhetsgrupper (NSG:er).

2 Dessa IP-adresser som ägs av Microsoft används för att hantera den virtuella värddator som hanterar Azure DNS.

3 Den här informationen behövs inte för undernät utan anpassad DNS-server eller nyare Redis-cacheminnen som ignorerar anpassad DNS.

4 Mer information finns i Ytterligare anslutningskrav för virtuella nätverk.

Krav på peerportar vid geo-replikering

Om du använder geo-replikering mellan cacheminnen i virtuella Azure-nätverk: a) avblockera portarna 15000–15999 för hela undernätet i både inkommande och utgående riktning och b) till båda cacheminnena. Med den här konfigurationen kan alla replikkomponenter i undernätet kommunicera direkt med varandra även om det finns en framtida geo-redundans.

Krav för inkommande portar

Det finns åtta krav för inkommande portintervall. Inkommande begäranden i dessa intervall är antingen inkommande från andra tjänster som finns i samma virtuella nätverk. Eller så är de interna för Redis-undernätskommunikationen.

Portar Riktning Transportprotokoll Syfte Lokal IP-adress Fjärr-IP
6379, 6380 Inkommande TCP Klientkommunikation till Redis, Azure-belastningsutjämning (Redis-undernät) (Redis-undernät), (klientundernät), AzureLoadBalancer 1
8443 Inkommande TCP Intern kommunikation för Redis (Redis-undernät) (Redis-undernät)
8 500 Inkommande TCP/UDP Belastningsutjämning i Azure (Redis-undernät) AzureLoadBalancer
10221-10231 Inkommande TCP Klientkommunikation till Redis-kluster, intern kommunikation för Redis (Redis-undernät) (Redis-undernät), (klientundernät), AzureLoadBalancer
13000-13999 Inkommande TCP Klientkommunikation till Redis-kluster, Azure-belastningsutjämning (Redis-undernät) (Redis-undernät), (klientundernät), AzureLoadBalancer
15000-15999 Inkommande TCP Klientkommunikation till Redis-kluster, Azure-belastningsutjämning och geo-replikering (Redis-undernät) (Redis-undernät), (klientundernät), AzureLoadBalancer, (geo-replik peer-undernät)
16001 Inkommande TCP/UDP Belastningsutjämning i Azure (Redis-undernät) AzureLoadBalancer
20226 Inkommande TCP Intern kommunikation för Redis (Redis-undernät) (Redis-undernät)

1 Du kan använda tjänsttaggen AzureLoadBalancer för Resource Manager eller AZURE_LOADBALANCER för den klassiska distributionsmodellen för redigering av NSG-reglerna.

Ytterligare anslutningskrav för virtuella nätverk

Det finns nätverksanslutningskrav för Azure Cache for Redis som kanske inte uppfylls från början i ett virtuellt nätverk. Azure Cache for Redis kräver att alla följande objekt fungerar korrekt när de används i ett virtuellt nätverk:

  • Utgående nätverksanslutning till Azure Key Vault-slutpunkter över hela världen. Azure Key Vault-slutpunkter löses under DNS-domänen vault.azure.net.
  • Utgående nätverksanslutning till Azure Storage-slutpunkter över hela världen. Slutpunkter som finns i samma region som Azure Cache for Redis-instansen och lagringsslutpunkter som finns i andra Azure-regioner ingår. Azure Storage-slutpunkter löses under följande DNS-domäner: table.core.windows.net, blob.core.windows.net, queue.core.windows.netoch file.core.windows.net.
  • Utgående nätverksanslutning till ocsp.digicert.com, crl4.digicert.com, ocsp.msocsp.com, mscrl.microsoft.com, crl3.digicert.com, cacerts.digicert.com, oneocsp.microsoft.comoch crl.microsoft.com. Den här anslutningen krävs för att stödja TLS/SSL-funktioner.
  • DNS-konfigurationen för det virtuella nätverket måste kunna matcha alla slutpunkter och domäner som nämns i de tidigare punkterna. Dessa DNS-krav kan uppfyllas genom att säkerställa att en giltig DNS-infrastruktur konfigureras och underhålls för det virtuella nätverket.
  • Utgående nätverksanslutning till följande Azure Monitor-slutpunkter, som löses under följande DNS-domäner: shoebox2-black.shoebox2.metrics.nsatc.net, , azglobal-black.azglobal.metrics.nsatc.netnorth-prod2.prod2.metrics.nsatc.net, shoebox2-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.com, shoebox3-black.prod.microsoftmetrics.comazredis-red.prod.microsoftmetrics.com och azredis-black.prod.microsoftmetrics.com.

Hur kan jag kontrollera att cacheminnet fungerar i ett virtuellt nätverk?

Viktigt!

När du ansluter till en Azure Cache for Redis-instans som finns i ett virtuellt nätverk måste dina cacheklienter finnas i samma virtuella nätverk eller i ett virtuellt nätverk med peering för virtuella nätverk aktiverat i samma Azure-region. Global peering för virtuella nätverk stöds inte för närvarande. Det här kravet gäller alla testprogram eller diagnostiska pingverktyg. Oavsett var klientprogrammet finns måste NSG:er eller andra nätverkslager konfigureras så att klientens nätverkstrafik kan nå Azure Cache for Redis-instansen.

När portkraven har konfigurerats enligt beskrivningen i föregående avsnitt kan du kontrollera att cacheminnet fungerar genom att följa dessa steg:

  • Starta om alla cachenoder. Cachen kan inte startas om om alla nödvändiga cacheberoenden inte kan nås--- som dokumenteras i krav på inkommande portar och utgående portar.
  • När cachenoderna har startats om, enligt cachestatusen i Azure-portalen, kan du göra följande tester:

    • Pinga cacheslutpunkten med hjälp av port 6380 från en dator som finns i samma virtuella nätverk som cachen med hjälp av tcping. Till exempel:

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

      tcping Om verktyget rapporterar att porten är öppen är cachen tillgänglig för anslutning från klienter i det virtuella nätverket.

    • Ett annat sätt att testa: skapa en testcacheklient som ansluter till cacheminnet och sedan lägger till och hämtar vissa objekt från cacheminnet. Testcacheklienten kan vara ett konsolprogram med StackExchange.Redis. Installera exempelklientprogrammet på en virtuell dator som finns i samma virtuella nätverk som cachen. Kör den sedan för att verifiera anslutningen till cacheminnet.

Varför visas ett felmeddelande om att fjärrcertifikatet är ogiltigt när jag försöker ansluta till min Azure Cache for Redis-instans i ett virtuellt nätverk?

När du försöker ansluta till en Azure Cache for Redis-instans i ett virtuellt nätverk visas ett certifikatverifieringsfel som det här:

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

Orsaken kan vara att du ansluter till värden med IP-adressen. Vi rekommenderar att du använder värdnamnet. Använd med andra ord följande sträng:

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

Undvik att använda IP-adressen som liknar följande anslutningssträng:

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

Om du inte kan matcha DNS-namnet innehåller vissa klientbibliotek konfigurationsalternativ som sslHost, som tillhandahålls av StackExchange.Redis-klienten. Med det här alternativet kan du åsidosätta värdnamnet som används för certifikatverifiering. Till exempel:

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

Kan jag använda virtuella nätverk med en standard- eller grundläggande cacheminne?

Virtuella nätverk kan bara användas med Premium-nivåcacheminnen.

Varför misslyckas skapandet av en Azure Cache for Redis-instans i vissa undernät, men inte i andra?

Om du distribuerar en Azure Cache for Redis-instans till ett virtuellt nätverk måste cachen finnas i ett dedikerat undernät som inte innehåller någon annan resurstyp. Om ett försök görs att distribuera en Azure Cache for Redis-instans till ett undernät för ett virtuellt Resource Manager-nätverk som innehåller andra resurser---till exempel Azure Application Gateway-instanser och Utgående NAT--- misslyckas distributionen vanligtvis. Ta bort befintliga resurser av andra typer innan du skapar en ny Azure Cache for Redis-instans.

Du måste också ha tillräckligt med IP-adresser i undernätet.

Vilka är kraven för undernätets adressutrymme?

Azure reserverar vissa IP-adresser inom varje undernät och dessa adresser kan inte användas. De första och sista IP-adresserna i undernäten är reserverade för protokollöverensstämmelse, tillsammans med ytterligare tre adresser som används för Azure-tjänster. Mer information finns i Finns det några begränsningar för att använda IP-adresser i sådana undernät?

Förutom de IP-adresser som används av den virtuella Azure-nätverksinfrastrukturen använder varje Azure Cache for Redis-instans i undernätet två IP-adresser per klustershard, plus IP-adresser för ytterligare repliker, om några. Ytterligare en IP-adress används för lastbalanseraren. En icke-klustrad cache anses ha en shard.

Kan jag ansluta till min cache från ett peer-kopplat virtuellt nätverk?

Om de virtuella nätverken finns i samma region kan du ansluta dem med peering för virtuella nätverk eller en VPN Gateway VNET-till-VNET-anslutning.

Om de peerkopplade virtuella Azure-nätverken finns i olika regioner: en virtuell klientdator i region 1 kan inte komma åt cachen i region 2 via sin belastningsutjämnings-IP-adress på grund av en begränsning med grundläggande lastbalanserare. Om det inte är en cache med en standardlastbalanserare, som för närvarande bara är en cache som har skapats med tillgänglighetszoner.

Mer information om begränsningar för peering för virtuella nätverk finns i Virtual Network – Peering – Krav och begränsningar. En lösning är att använda en VPN Gateway VNET-till-VNET-anslutning i stället för peering för virtuella nätverk.

Fungerar alla cachefunktioner när en cache finns i ett virtuellt nätverk?

När cachen är en del av ett virtuellt nätverk kan endast klienter i det virtuella nätverket komma åt cachen. Därför fungerar inte följande funktioner för cachehantering just nu:

  • Redis-konsolen: Eftersom Redis-konsolen körs i din lokala webbläsare---användare på en utvecklardator som inte är ansluten till det virtuella nätverket---det går inte att ansluta till cachen.

Stöds VNet-inmatning i en cache där Azure Lighthouse är aktiverat?

Nej, om din prenumeration har Azure Lighthouse aktiverat kan du inte använda VNet-inmatning på en Azure Cache for Redis-instans. Använd i stället privata länkar.

Använda ExpressRoute med Azure Cache for Redis

Kunder kan ansluta en Azure ExpressRoute-krets till sin virtuella nätverksinfrastruktur. På så sätt utökar de sitt lokala nätverk till Azure.

Som standard använder inte en nyskapad ExpressRoute-krets tvingad tunneltrafik (annonsering av en standardväg, 0.0.0.0/0) i ett virtuellt nätverk. Därför tillåts utgående Internetanslutning direkt från det virtuella nätverket. Klientprogram kan ansluta till andra Azure-slutpunkter, inklusive en Azure Cache for Redis-instans.

En vanlig kundkonfiguration är att använda tvingad tunneltrafik (annonsera en standardväg), vilket tvingar utgående Internettrafik att i stället flöda lokalt. Det här trafikflödet bryter anslutningen med Azure Cache for Redis om den utgående trafiken sedan blockeras lokalt, så att Azure Cache for Redis-instansen inte kan kommunicera med dess beroenden.

Lösningen är att definiera en eller flera användardefinierade vägar (UDR) i undernätet som innehåller Azure Cache for Redis-instansen. En UDR definierar undernätsspecifika vägar som ska respekteras i stället för standardvägen.

Använd om möjligt följande konfiguration:

  • ExpressRoute-konfigurationen annonserar 0.0.0.0/0 och tvingar som standard tunnlar all utgående trafik lokalt.
  • Den UDR som tillämpas på undernätet som innehåller Azure Cache for Redis-instansen definierar 0.0.0.0/0 med en fungerande väg för TCP/IP-trafik till det offentliga Internet. Den ställer till exempel in nästa hopptyp på Internet.

Den kombinerade effekten av dessa steg är att UDR på undernätsnivå har företräde framför expressroute-tvingad tunneltrafik och som säkerställer utgående Internetåtkomst från Azure Cache for Redis-instansen.

Anslut ing till en Azure Cache for Redis-instans från ett lokalt program med hjälp av ExpressRoute är inte ett typiskt användningsscenario på grund av prestandaskäl. För bästa prestanda bör Azure Cache for Redis-klienter vara i samma region som Azure Cache for Redis-instansen.

Viktigt!

De vägar som definieras i en UDR måste vara tillräckligt specifika för att ha företräde framför alla vägar som annonseras av ExpressRoute-konfigurationen. I följande exempel används det breda adressintervallet 0.0.0.0/0 och kan därför oavsiktligt åsidosättas av vägannonser som använder mer specifika adressintervall.

Varning

Azure Cache for Redis stöds inte med ExpressRoute-konfigurationer som felaktigt korsannonserar vägar från den offentliga peeringsökvägen till den privata peeringsökvägen. ExpressRoute-konfigurationer som har konfigurerad offentlig peering tar emot vägannonser från Microsoft för en stor uppsättning Ip-adressintervall för Microsoft Azure. Om dessa adressintervall är felaktigt korsannonserade på den privata peeringsökvägen är resultatet att alla utgående nätverkspaket från Azure Cache for Redis-instansens undernät är felaktigt framtvingade till en kunds lokala nätverksinfrastruktur. Det här nätverksflödet bryter Azure Cache for Redis. Lösningen på det här problemet är att stoppa korsannonseringsvägar från den offentliga peering-sökvägen till den privata peering-sökvägen.

Bakgrundsinformation om UDR är tillgänglig i trafikroutning för virtuella nätverk.

Mer information om ExpressRoute finns i Teknisk översikt över ExpressRoute.

Relaterat innehåll

Läs mer om Azure Cache for Redis-funktioner.