Condividi tramite

Configurare il supporto della rete virtuale (VNet) per un'istanza di Cache Redis di Azure Premium

  • Articolo

La distribuzione della rete virtuale di Azure offre sicurezza e isolamento avanzati insieme a subnet, criteri di controllo di accesso e altre funzionalità per limitare ulteriormente l'accesso. Quando un'istanza di Cache Redis di Azure è configurata con una rete virtuale, non è indirizzabile pubblicamente. È invece possibile accedere all'istanza solo dalle macchine virtuali e dalle applicazioni all'interno della rete virtuale. Questo articolo descrive come configurare il supporto di una rete virtuale per un'istanza di Cache Redis di Azure di livello Premium.

Nota

Il modello di distribuzione classica viene ritirato nell'agosto 2024. Per altre informazioni, vedere Il modello di distribuzione servizi cloud (versione classica) verrà ritirato il 31 agosto 2024.

Importante

Cache di Azure per Redis consiglia di usare il collegamento privato di Azure, che semplifica l'architettura di rete e protegge la connessione tra gli endpoint in Azure. È possibile connettersi a un'istanza della cache di Azure per Redis dalla propria rete virtuale tramite un endpoint privato, a cui viene assegnato un indirizzo IP privato in una subnet entro la rete virtuale. I collegamenti privati di Azure sono disponibili a tutti i livelli, includono assistenza per i Criteri di Azure e la gestione semplificata delle regole del gruppo di sicurezza di rete. Per altre informazioni, vedere la documentazione relativa ai collegamenti privati. Per eseguire la migrazione delle cache inserite nella rete virtuale al collegamento privato, vedere Eseguire la migrazione da cache di inserimento reti virtuali a cache di collegamento privato.

Limitazioni dell'inserimento della rete virtuale

  • La creazione e la gestione delle configurazioni di rete virtuale sono spesso soggette a errori. Anche la risoluzione dei problemi è complessa. Le configurazioni di rete virtuale non corrette possono causare problemi:
    • trasmissione di metriche ostruita dalle istanze della cache
    • errore del nodo di replica per replicare i dati dal nodo primario
    • potenziale perdita di dati
    • errore di operazioni di gestione come il ridimensionamento
    • negli scenari più gravi, perdita di disponibilità
  • Le cache inserite nella rete virtuale sono disponibili solo per Cache Redis di Azure di livello Premium, non per altri livelli.
  • Quando si usa una cache inserita nella rete virtuale, è necessario modificare la rete virtuale per memorizzare nella cache dipendenze, ad esempio CRL/PKI, AKV, Archiviazione di Azure, Monitoraggio di Azure e altro ancora.
  • Non è possibile inserire un'istanza di Cache Redis di Azure esistente in una rete virtuale. È necessario selezionare questa opzione quando si crea la cache.

Configurare il supporto della rete virtuale

Il supporto della rete virtuale è configurato nel riquadro Nuova cache di Azure per Redis durante la creazione della cache.

  1. Per creare una cache di livello Premium, accedere al portale di Azure e selezionare Creare una risorsa. È anche possibile crearli usando modelli di Resource Manager, PowerShell o l'interfaccia della riga di comando di Azure. Per altre informazioni su come creare un'istanza di Cache Redis di Azure, vedere Creare una cache.

    Screenshot che mostra La creazione di una risorsa.

  2. Nella pagina Nuovo selezionare Database. Selezionare quindi Cache di Azure per Redis.

    Screenshot che mostra la selezione di cache di Azure per Redis.

  3. Nella pagina Nuova cache Redis configurare le impostazioni per la nuova cache di livello Premium.

    Impostazione Valore suggerito Descrizione
    Nome DNS Immettere un nome globalmente univoco. Il nome della cache deve essere una stringa compresa tra 1 e 63 caratteri contenente solo numeri, lettere o trattini. Il nome deve iniziare e terminare con un numero o una lettera e non può contenere trattini consecutivi. Il nome host dell'istanza della cache sarà \<DNS name>.redis.cache.windows.net.
    Abbonamento Selezionare la sottoscrizione dall'elenco a discesa. Sottoscrizione in cui creare la nuova istanza della cache di Azure per Redis.
    Gruppo di risorse Selezionare un gruppo di risorse dall'elenco a discesa oppure selezionare Crea nuovo e immettere un nuovo nome del gruppo di risorse. Nome del gruppo di risorse in cui creare la cache e altre risorse. L'inserimento di tutte le risorse di un'app in un unico gruppo di risorse ne semplifica la gestione o l'eliminazione.
    Location selezionare una località dall'elenco a discesa. Selezionare un'area in prossimità di altri servizi che useranno la cache.
    Tipo di cache Selezionare una cache di livello Premium dall'elenco a discesa per configurare le funzionalità di livello Premium. Per altre informazioni, vedere Prezzi di Cache Redis di Azure. Il piano tariffario determina le dimensioni, le prestazioni e le funzionalità disponibili per la cache. Per altre informazioni, vedere la panoramica su Cache Redis di Azure.

  4. Selezionare la scheda Rete o selezionare il pulsante Rete nella parte inferiore della pagina.

  5. Nella scheda Rete selezionare reti virtuali come metodo di connettività. Per usare una nuova rete virtuale, crearla prima seguendo la procedura descritta in Creare una rete virtuale usando il portale di Azure o Creare una rete virtuale (classica) usando il portale di Azure. Tornare quindi al riquadro Nuova cache di Azure per Redis per creare e configurare la cache di livello Premium.

    Importante

    Quando si distribuisce una cache di Azure per Redis in una rete virtuale di Resource Manager, la cache deve trovarsi in una subnet dedicata che non contiene altre risorse ad eccezione delle istanze della cache di Azure per Redis. Se si tenta di distribuire un'istanza di cache di Azure per Redis in una subnet di rete virtuale Resource Manager che contiene altre risorse o a cui è assegnato un gateway NAT, la distribuzione ha esito negativo. L'errore è dovuto al fatto che cache di Azure per Redis usa un servizio di bilanciamento del carico di base non compatibile con un gateway NAT.

    Impostazione Valore suggerito Descrizione
    Rete virtuale Selezionare la rete virtuale dall'elenco a discesa. Selezionare una rete virtuale che si trova nella stessa sottoscrizione e nella stessa posizione della cache.
    Subnet Selezionare la subnet dall'elenco a discesa. L'intervallo di indirizzi della subnet deve trovarsi nella notazione CIDR, ad esempio 192.168.1.0/24. Deve essere incluso nello spazio indirizzi della rete virtuale.
    Indirizzo IP statico (Facoltativo) Immettere un indirizzo IP statico. Se non si specifica un indirizzo IP statico, viene scelto un indirizzo IP in modo automatico.

    Importante

    Azure riserva alcuni indirizzi IP all'interno di ogni subnet e questi indirizzi non possono essere usati. Il primo e l'ultimo indirizzo IP delle subnet sono riservati per motivi di conformità al protocollo, insieme ad altri tre indirizzi usati per i servizi di Azure. Per altre informazioni, vedere Esistono restrizioni sull'uso di indirizzi IP all'interno di tali subnet?

    Oltre agli indirizzi IP usati dall'infrastruttura di rete virtuale di Azure, ogni istanza di Cache di Azure per Redis nella subnet usa due indirizzi IP per partizione e un altro indirizzo IP per il bilanciamento del carico. Si presuppone che una cache non in cluster includa una sola partizione.

  6. Selezionare la scheda Avanti: Avanzate oppure selezionare il pulsante Avanti: Avanzate nella parte inferiore della pagina.

  7. Nella scheda Avanzate per un'istanza della cache di livello Premium configurare le impostazioni per la porta, il clustering e la persistenza dei dati non TLS.

  8. Selezionare la scheda Avanti: Tag oppure selezionare il pulsante Avanti: Tag nella parte inferiore della pagina.

  9. Facoltativamente, nella scheda Tag immettere il nome e il valore per classificare la risorsa.

  10. Selezionare Rivedi e crea. Viene visualizzata la scheda Rivedi e crea in cui Azure convalida la configurazione.

  11. Quando viene visualizzato il messaggio verde di Convalida superata, selezionare Crea.

La creazione della cache richiede un po' di tempo. È possibile monitorare lo stato di avanzamento nella pagina Panoramica della cache di Azure per Redis. Quando l'elemento Stato indica In esecuzione, la cache è pronta per l'uso. Dopo aver creato la cache, è possibile visualizzare la configurazione della rete virtuale facendo clic su Rete virtuale dal menu Risorse.

Rete virtuale

Domande frequenti sulla rete virtuale per cache di Azure per Redis

L'elenco seguente contiene risposte a domande frequenti sulla rete di Cache Redis di Azure.

Quali sono alcuni problemi comuni di configurazione errata per Cache di Azure per Redis e le reti virtuali?

Quando Cache di Azure per Redis è ospitata in una rete virtuale, vengono usate le porte indicate nelle tabelle seguenti.

Importante

Se le porte nelle tabelle seguenti sono bloccate, la cache potrebbe non funzionare correttamente. Il blocco di una o più di queste porte è il problema di configurazione più comune nell'uso di Cache di Azure per Redis in una rete virtuale.

Requisiti delle porte in uscita

Vi sono nove requisiti delle porte in uscita. Le richieste in uscita in questi intervalli sono: a) in uscita ad altri servizi necessari per il funzionamento della cache o b) interne alla subnet Redis per la comunicazione internodo. Per la replica geografica, esistono altri requisiti in uscita per la comunicazione tra subnet della cache primaria e di replica.

Porte Direction Protocollo di trasporto Scopo IP locale IP remoto
80, 443 In uscita TCP Dipendenze Redis in Archiviazione di Azure/PKI (Internet) (Subnet Redis) * 4
443 In uscita TCP Dipendenza di Redis da Azure Key Vault e da Monitoraggio di Azure (Subnet Redis) AzureKeyVault, AzureMonitor 1
53 In uscita TCP/UDP Dipendenze di Redis da DNS (internet/rete virtuale) (Subnet Redis) 168.63.129.16 e 169.254.169.254 2 e qualsiasi server DNS personalizzato per la subnet 3
8443 In uscita TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)
10221-10231 In uscita TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)
20226 In uscita TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)
13000-13999 In uscita TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)
15000-15999 In uscita TCP Comunicazioni interne per Redis e replica geografica (Subnet Redis) (subnet Redis) (subnet peer di replica geografica)
6379-6380 In uscita TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)

1 È possibile usare i tag del servizio AzureKeyVault e AzureMonitor con i gruppi di sicurezza di rete di Resource Manager.

2 Questi indirizzi IP di proprietà di Microsoft vengono usati per gestire la macchina virtuale host che serve DNS di Azure.

3 Queste informazioni non sono necessarie per le subnet senza server DNS personalizzato o cache Redis più recenti che ignorano il DNS personalizzato.

4 Per altre informazioni, vedere Requisiti aggiuntivi di connettività della rete virtuale.

Requisiti per le porte peer per la replica geografica

Se si usa la replica geografica tra le cache nelle reti virtuali di Azure: a) sbloccare le porte 15000-15999 per l'intera subnet nelle direzioni in ingresso e in uscita e b) in entrambe le cache. Con questa configurazione, tutti i componenti di replica nella subnet possono comunicare direttamente tra loro anche se è presente un futuro failover geografico.

Requisiti delle porte in ingresso

Vi sono otto requisiti delle porte in ingresso. Le richieste in ingresso in questi intervalli sono in ingresso da altri servizi ospitati nella stessa rete virtuale. In alternativa, sono interni alle comunicazioni della subnet Redis.

Porte Direction Protocollo di trasporto Scopo IP locale IP remoto
6379, 6380 In entrata TCP Comunicazione tra client e Redis, bilanciamento del carico di Azure (Subnet Redis) (subnet Redis), (subnet client), AzureLoadBalancer 1
8443 In entrata TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)
8500 In entrata TCP/UDP Bilanciamento del carico di Azure (Subnet Redis) AzureLoadBalancer
10221-10231 In entrata TCP Comunicazione client con cluster Redis, comunicazioni interne per Redis (Subnet Redis) (subnet Redis), (subnet client), AzureLoadBalancer
13000-13999 In entrata TCP Comunicazione tra client e cluster Redis, bilanciamento del carico di Azure (Subnet Redis) (subnet Redis), (subnet client), AzureLoadBalancer
15000-15999 In entrata TCP Comunicazione client con cluster Redis, bilanciamento del carico di Azure e replica geografica (Subnet Redis) (subnet Redis), (subnet client), AzureLoadBalancer, (subnet peer di replica geografica)
16001 In entrata TCP/UDP Bilanciamento del carico di Azure (Subnet Redis) AzureLoadBalancer
20226 In entrata TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)

1 È possibile usare il tag del servizio AzureLoadBalancer per Resource Manager o AZURE_LOADBALANCER per il modello di distribuzione classica per la creazione delle regole del gruppo di sicurezza di rete.

Ulteriori requisiti di connettività della rete virtuale

Esistono requisiti di connettività di rete per Cache Redis di Azure che potrebbero non essere inizialmente soddisfatti in una rete virtuale. Per il corretto funzionamento se usato all'interno di una rete virtuale, Cache Redis di Azure richiede tutti gli elementi seguenti:

  • Connettività di rete in uscita per endpoint di Azure Key Vault in tutto il mondo. Gli endpoint di Azure Key Vault si risolvono nel dominio DNS vault.azure.net.
  • Connettività di rete in uscita per endpoint di archiviazione di Azure in tutto il mondo. Sono inclusi gli endpoint che si trovano nella stessa area dell'istanza di Cache Redis di Azure e degli endpoint di archiviazione che si trovano in altre aree di Azure. Gli endpoint di Archiviazione di Azure si risolvono nei domini DNS seguenti: table.core.windows.net, blob.core.windows.net, queue.core.windows.net e file.core.windows.net.
  • Connettività di rete in uscita a ocsp.digicert.com, crl4.digicert.com, ocsp.msocsp.com, mscrl.microsoft.com, crl3.digicert.com, cacerts.digicert.com, oneocsp.microsoft.com e crl.microsoft.com. Questa connettività è necessaria per supportare la funzionalità TLS/SSL.
  • La configurazione DNS per la rete virtuale deve essere in grado di risolvere tutti gli endpoint e i domini indicati nei punti precedenti. Questi requisiti DNS possono essere soddisfatti garantendo che un'infrastruttura DNS valida venga configurata e mantenuta per la rete virtuale.
  • Connettività di rete in uscita agli endpoint di Monitoraggio di Azure seguenti, che vengono risolti nei domini DNS seguenti: shoebox2-black.shoebox2.metrics.nsatc.net, north-prod2.prod2.metrics.nsatc.net, azglobal-black.azglobal.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.com, azredis-red.prod.microsoftmetrics.com e azredis-black.prod.microsoftmetrics.com.

Come è possibile verificare che la cache funzioni in una rete virtuale?

Importante

Quando il client si connette a un'istanza di cache di Azure per Redis ospitata in una rete virtuale, i client della cache devono essere nella stessa rete virtuale o in una rete virtuale con peering di rete virtuale abilitato all'interno della stessa area di Azure. Il peering di rete virtuale globale non è attualmente supportato. Questo requisito si applica a tutte le applicazioni di test o agli strumenti di ping di diagnostica. Indipendentemente dalla posizione che ospita l'applicazione client, i gruppi di sicurezza di rete o altri livelli devono essere configurati in modo che il traffico di rete del client sia autorizzato a raggiungere l'istanza di cache di Azure per Redis.

Dopo aver configurato i requisiti delle porte come descritto nella sezione precedente, nella maggior parte dei casi è necessario un riavvio per garantire che le modifiche riflettano correttamente. In caso contrario, potrebbero verificarsi alcuni problemi di connettività. È possibile verificare che la cache funzioni seguendo questa procedura:

  • Riavviare tutti i nodi della cache. La cache non sarà in grado di riavviare correttamente se non è possibile raggiungere tutte le dipendenze della cache necessarie---come documentato in requisiti delle porte in ingresso e requisiti delle porte in uscita.
  • Dopo il riavvio dei nodi della cache (come riportato dallo stato della cache nel portale di Azure), è possibile eseguire i test seguenti:

    • Eseguire il ping dell'endpoint della cache usando la porta 6380 da un computer all'interno della stessa rete virtuale della cache, usando tcping. Ad esempio:

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

      Se lo strumento tcping indica che la porta è aperta, la cache è disponibile per la connessione dai client nella rete virtuale.

    • Un altro modo per testare: creare un client della cache di test che si connette alla cache, quindi aggiunge e recupera alcuni elementi dalla cache. Il client della cache di test potrebbe essere un'applicazione console che usa StackExchange.Redis. Installare l'applicazione client di esempio in una macchina virtuale che si trova nella stessa rete virtuale della cache. Eseguirlo quindi per verificare la connettività alla cache.

Quando si tenta di connettersi all'istanza di Cache di Azure per Redis in una rete virtuale, perché viene visualizzato un errore che indica che il certificato remoto non è valido?

Quando si tenta di connettersi a un'istanza di Cache Redis di Azure in una rete virtuale, viene visualizzato un errore di convalida del certificato, ad esempio questo:

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

La causa potrebbe essere che ci si sta connettendo all'host tramite l'indirizzo IP. È consigliabile usare il nome host. In altri termini, usare la stringa seguente:

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

Evitare di usare l'indirizzo IP simile alla stringa di connessione seguente:

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

Se non si è in grado di risolvere il nome DNS, alcune librerie client includono delle opzioni di configurazione come sslHost che viene fornita dal client StackExchange.Redis. Questa opzione consente di eseguire l'override del nome host usato per la convalida del certificato. Ad esempio:

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

È possibile usare reti virtuali con una cache standard o di base?

Le reti virtuali possono essere usate solo con cache di livello Premium.

Perché la creazione di un'istanza di cache di Azure per Redis ha esito negativo in alcune subnet ma non in altre?

Se si distribuisce un'istanza di Cache di Azure per Redis in una rete virtuale, la cache deve trovarsi in una subnet dedicata che non contiene altri tipi di risorsa. Se si tenta di distribuire un'istanza di Cache di Azure per Redis in una subnet di rete virtuale di Resource Manager che contiene altre risorse--- ad esempio istanze del gateway applicazione di Azure e NAT in uscita--- la distribuzione in genere non riesce. Eliminare le risorse esistenti di altri tipi prima di creare una nuova istanza della cache di Azure per Redis.

È anche necessario disporre di indirizzi IP sufficienti nella subnet.

Quali sono i requisiti di spazio per gli indirizzi di subnet?

Azure riserva alcuni indirizzi IP all'interno di ogni subnet e questi indirizzi non possono essere usati. Il primo e l'ultimo indirizzo IP delle subnet sono riservati per motivi di conformità al protocollo, insieme ad altri tre indirizzi usati per i servizi di Azure. Per altre informazioni, vedere Esistono restrizioni sull'uso di indirizzi IP all'interno di tali subnet?

Oltre agli indirizzi IP usati dall'infrastruttura di rete virtuale di Azure, ogni istanza di Cache di Azure per Redis nella subnet usa due indirizzi IP per partizione del cluster, più indirizzi IP per repliche aggiuntive, se presenti. Per il servizio di bilanciamento del carico viene usato un altro indirizzo IP. Si presuppone che una cache non cluster includa una sola partizione.

È possibile connettersi alla cache da una rete virtuale con peering?

Se le reti virtuali si trovano nella stessa area, è possibile connetterle usando il peering di rete virtuale o una connessione da rete virtuale a rete virtuale del gateway VPN.

Se le reti virtuali di Azure con peering si trovano in aree diverse: una macchina virtuale client nell'area 1 non può accedere alla cache nell'area 2 tramite l'indirizzo IP con carico bilanciato a causa di un vincolo con servizi di bilanciamento del carico di base. Ovvero, a meno che non si tratti di una cache con un servizio di bilanciamento del carico standard, che è attualmente solo una cache creata con zone di disponibilità.

Per altre informazioni sui vincoli di peering di rete virtuale, vedere Rete virtuale - Peering - Requisiti e vincoli. Una soluzione consiste nell'usare una connessione da rete virtuale a rete virtuale del gateway VPN invece del peering di rete virtuale.

Tutte le funzionalità della cache funzionano quando una cache è ospitata in una rete virtuale?

Quando la cache fa parte di una rete virtuale, solo i client nella rete virtuale possono accedere alla cache. Di conseguenza, le seguenti funzionalità di gestione della cache non funzionano in questo momento:

  • Console Redis: poiché la console Redis viene eseguita nel browser locale---di solito in un computer sviluppatore che non è connesso alla rete virtuale---non può quindi connettersi alla cache.

L'inserimento della rete virtuale è supportato in una cache in cui è abilitato Azure Lighthouse?

No, se la sottoscrizione ha Azure Lighthouse abilitato, non è possibile usare l'inserimento della rete virtuale in un'istanza di Cache di Azure per Redis. Usare invece collegamenti privati.

Usare ExpressRoute con Cache Redis di Azure

I clienti possono connettere un circuito Azure ExpressRoute all'infrastruttura di rete virtuale. In questo modo, estendono la rete locale ad Azure.

Per impostazione predefinita, un circuito ExpressRoute appena creato non usa il tunneling forzato (annuncio di una route predefinita, 0.0.0.0/0) in una rete virtuale. Di conseguenza, la connettività Internet in uscita è consentita direttamente dalla rete virtuale. Le applicazioni client possono connettersi ad altri endpoint di Azure, che includono un'istanza di Cache Redis di Azure.

Una configurazione comune dei clienti è quella di usare il tunneling forzato (segnalare una route predefinita) verso la quale viene forzato il traffico Internet in uscita invece di far passare il flusso localmente. Questo flusso di traffico interrompe la connettività con Cache di Azure per Redis se il traffico in uscita viene quindi bloccato in locale in modo da impedire all'istanza di Cache di Azure per Redis di comunicare con le proprie dipendenze.

La soluzione consiste nel definire una o più route definite dall'utente (UDR, User Defined Route) nella subnet contenente l’istanza Cache di Azure per Redis. Una route UDR definisce le route specifiche della subnet che verranno accettate invece della route predefinita.

Se possibile, usare la configurazione seguente:

  • La configurazione di ExpressRoute annuncia 0.0.0.0/0 e per impostazione predefinita esegue il tunneling forzato di tutto il traffico in uscita in un ambiente locale.
  • La route definita dall'utente applicata alla subnet che contiene l'istanza di Cache di Azure per Redis definisce 0.0.0.0/0 con una route di lavoro per il traffico TCP/IP verso Internet pubblico. Ad esempio, imposta il tipo di hop successivo su Internet.

L'effetto combinato di questi passaggi è che il livello di subnet UDR avrà la precedenza sul tunneling forzato di ExpressRoute, e ciò garantisce l'accesso a Internet in uscita dall’istanza di Cache di Azure per Redis.

La connessione a un'istanza di Cache di Azure per Redis da un'applicazione locale tramite ExpressRoute non è uno scenario di utilizzo tipico a causa di motivi di prestazioni. Per ottenere prestazioni ottimali, i client di Cache di Azure per Redis devono trovarsi nella stessa area dell'istanza di Cache di Azure per Redis.

Importante

Le route definite in una route UDR devono essere sufficientemente specifiche da avere la precedenza su qualsiasi route annunciata dalla configurazione di ExpressRoute. Nell'esempio seguente viene usato l'intervallo di indirizzi ampio 0.0.0.0/0 e pertanto può essere accidentalmente sostituito dagli annunci di route che usano intervalli di indirizzi più specifici.

Avviso

Cache Redis di Azure non è supportato con le configurazioni di ExpressRoute che annunciano erroneamente route dal percorso di peering pubblico al percorso di peering privato. Le configurazioni di ExpressRoute per cui è configurato il peering pubblico ricevono gli annunci delle route da Microsoft per un elevato numero di intervalli di indirizzi IP di Microsoft Azure. Se questi intervalli di indirizzi vengono annunciati in modo non corretto nel percorso di peering privato, il risultato finale è che tutti i pacchetti di rete in uscita dalla subnet dell'istanza di Cache Redis di Azure verranno erroneamente sottoposti a tunneling forzato verso l'infrastruttura di rete locale del cliente. Questo flusso di rete interromperà Cache Redis di Azure. La soluzione a questo problema consiste nell'interrompere l'annuncio di più route dal percorso di peering pubblico al percorso di peering privato.

Le informazioni di base sulle route definite dall'utente sono disponibili in Routing del traffico di rete virtuale.

Per altre informazioni su ExpressRoute, vedere Panoramica tecnica relativa a ExpressRoute.

Contenuto correlato

Altre informazioni sulle funzionalità di Cache di Azure per Redis.