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

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.

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.

   

2. Nella pagina Nuovo selezionare Database. Selezionare quindi 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.

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 di configurazione errata comuni con Cache Redis di Azure e le reti virtuali?
• Come è possibile verificare che la cache funzioni in una rete virtuale?
• Quando si tenta di connettersi all'istanza di Cache Redis di Azure in una rete virtuale, perché viene visualizzato un errore che indica che il certificato remoto non è valido?
• È possibile usare reti virtuali con una cache standard o di base?
• Perché la creazione di un'istanza di cache di Azure per Redis ha esito negativo in alcune subnet ma non in altre?
• Quali sono i requisiti di spazio per gli indirizzi di subnet?
• È possibile connettersi alla cache da una rete virtuale con peering?
• L'inserimento della rete virtuale è supportato in una cache in cui è abilitato Azure Lighthouse?
• Tutte le funzionalità della cache funzionano quando una cache è ospitata in una rete virtuale?
• L'inserimento della rete virtuale è supportato in una cache in cui è abilitato Azure Lighthouse?

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.

• Requisiti delle porte in uscita
• Requisiti delle porte in ingresso

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.

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

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

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

⁴ 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.

¹ È 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?

Dopo aver configurato i requisiti delle porte come descritto nella sezione precedente, è 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.

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.

• Livelli di servizio Premium di Cache di Azure per Redis