Come configurare il supporto di una rete virtuale per un'istanza Premium di Cache Redis di Azure

Cache Redis di Azure include diverse soluzioni cache che offrono flessibilità di scelta riguardo alle dimensioni e alle funzionalità della cache, tra cui le funzionalità del livello Premium come clustering, persistenza e supporto per reti virtuali. Una rete virtuale è una rete privata nel cloud. Quando un'istanza di Cache Redis di Azure viene configurata con una rete virtuale, non è indirizzabile pubblicamente ed è accessibile solo da macchine virtuali e applicazioni all'interno della rete virtuale. Questo articolo descrive come configurare il supporto di una rete virtuale per un'istanza Premium di Cache Redis di Azure.

Nota

Cache Redis di Azure supporta le reti virtuali classiche e di Resource Manager.

Per informazioni su altre funzionalità di cache premium, vedere Introduzione al piano Premium di Cache Redis di Azure.

Perché usare una rete virtuale?

La distribuzione di Rete virtuale di Azure offre sicurezza e isolamento migliorati per Cache Redis di Azure, nonché subnet, criteri di controllo di accesso e altre funzionalità per limitare ulteriormente l'accesso.

Supporto della rete virtuale

Il supporto della rete virtuale viene configurato nel pannello Nuova cache Redis durante la creazione della cache.

Per creare una cache Premium, accedere al portale di Azure e fare clic su Nuovo > Database > Cache Redis.

Create cache

Nota

Oltre a creare cache nel portale di Azure, è possibile crearle usando modelli di Resource Manager, PowerShell o l'interfaccia della riga di comando di Azure. Per altre informazioni sulla creazione di un'istanza di Cache Redis di Azure, vedere Creare una cache.

Per configurare le funzionalità Premium, selezionare prima di tutto uno dei piani tariffari Premium nell'elenco a discesa Piano tariffario. Per altre informazioni sui diversi piani tariffari, fare clic su Visualizza i dettagli completi sui prezzi e selezionare un piano tariffario nel pannello Scegliere un piano tariffario.

Scegliere il piano tariffario

Dopo aver selezionato un piano tariffario Premium, è possibile configurare l'integrazione rete virtuale di Cache Redis selezionando una rete virtuale nella stessa sottoscrizione e nella stessa posizione della cache. Per usare una nuova rete virtuale, è necessario prima crearla seguendo i passaggi in Creare una rete virtuale usando il portale di Azure o in Creare una rete virtuale (classica) usando il portale di Azure, quindi tornare al pannello Nuova cache Redis per creare e configurare la cache Premium.

Per configurare la rete virtuale per la nuova cache, fare clic su Rete virtuale nel pannello Nuova cache Redis e selezionare la rete virtuale desiderata dall'elenco a discesa.

Rete virtuale

Nell'elenco a discesa Subnet selezionare la subnet desiderata e specificare l'indirizzo IP statico. Se si usa una rete virtuale classica, il campo Indirizzo IP statico è facoltativo e, se non è specificato, ne verrà scelto uno dalla subnet selezionata.

Importante

Quando si distribuisce Cache Redis di Azure in una rete virtuale di Resource Manager, la cache deve trovarsi in una subnet dedicata che non contiene altre risorse, ad eccezione delle istanze di Cache Redis di Azure. Se si tenta di distribuire un'istanza di Cache Redis di Azure in una rete virtuale di Resource Manager all'interno di una subnet contenente altre risorse, la distribuzione non riesce.

Rete virtuale

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 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 cluster includa una sola partizione.

Dopo aver creato la cache, è possibile visualizzare la configurazione della rete virtuale facendo clic su Rete virtuale dal menu Risorse.

Rete virtuale

Per connettersi all'istanza di Cache Redis di Azure quando si usa una rete virtuale, specificare il nome host della cache nella stringa di connessione, come mostrato nell'esempio seguente:

private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
    return ConnectionMultiplexer.Connect("contoso5premium.redis.cache.windows.net,abortConnect=false,ssl=true,password=password");
});

public static ConnectionMultiplexer Connection
{
    get
    {
        return lazyConnection.Value;
    }
}

Domande frequenti sulla rete virtuale di Cache Redis di Azure

Nell'elenco seguente sono fornite le risposte alle domande poste comunemente sulla rete virtuale di Cache Redis di Azure.

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

Quando Cache Redis di Azure è 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 Redis di Azure in una rete virtuale.

Requisiti delle porte in uscita

Vi sono sette requisiti delle porte in uscita.

  • Se lo si desidera, tutte le connessioni a Internet in uscita possono essere eseguite tramite un dispositivo di controllo locale del cliente.
  • Tre delle porte instradano il traffico a endpoint di Azure che servono Archiviazione di Azure e Azure DNS.
  • Gli intervalli di porte rimanenti sono destinati alle comunicazioni interne subnet di Redis. Per le comunicazioni subnet interne di Redis non è richiesta alcuna regola NSG subnet.
Porte Direzione Protocollo di trasporto Scopo IP locale IP remoto
80, 443 In uscita TCP Dipendenze Redis in Archiviazione di Azure/PKI (Internet) (Subnet Redis) *
53 In uscita TCP/UDP Dipendenze Redis nel DNS (Internet/rete virtuale) (Subnet Redis) *
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 (Subnet Redis) (Subnet Redis)

Requisiti delle porte in ingresso

Vi sono otto requisiti delle porte in ingresso. Le richieste in ingresso in questi intervalli provengono da altri servizi ospitati nella stessa VNET o sono interne alle comunicazioni subnet di Redis.

Porte Direzione Protocollo di trasporto Scopo IP locale IP remoto
6379, 6380 In ingresso TCP Comunicazione tra client e Redis, bilanciamento del carico di Azure (Subnet Redis) Rete virtuale, Bilanciamento carico di Azure
8443 In ingresso TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)
8500 In ingresso TCP/UDP Bilanciamento del carico di Azure (Subnet Redis) Azure Load Balancer
10221-10231 In ingresso TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis), bilanciamento del carico di Azure
13000-13999 In ingresso TCP Comunicazione tra client e cluster Redis, bilanciamento del carico di Azure (Subnet Redis) Rete virtuale, Bilanciamento carico di Azure
15000-15999 In ingresso TCP Comunicazione tra client e cluster Redis, bilanciamento del carico di Azure (Subnet Redis) Rete virtuale, Bilanciamento carico di Azure
16001 In ingresso TCP/UDP Bilanciamento del carico di Azure (Subnet Redis) Azure Load Balancer
20226 In ingresso TCP Comunicazioni interne per Redis (Subnet Redis) (Subnet Redis)

Ulteriori requisiti di connettività della rete VNET

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 archiviazione di Azure in tutto il mondo. Sono inclusi gli endpoint che si trovano nella stessa area dell'istanza di Cache Redis di Azure, nonché gli endpoint di archiviazione che si trovano in altre aree di Azure. Gli endpoint di Archiviazione di Azure vengono risolti nei seguenti domini DNS: table.core.windows.net, blob.core.windows.net, queue.core.windows.net e file.core.windows.net.
  • Connettività di rete in uscita verso ocsp.msocsp.com, mscrl.microsoft.com e crl.microsoft.com. Tale connettività è necessaria per il supporto della funzionalità 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.

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

Importante

Quando ci si connette a un'istanza di Cache Redis di Azure ospitata in una rete virtuale, i client della cache devono trovarsi nella stessa rete virtuale, incluse eventuali applicazioni di test o strumenti di diagnostica ping.

Dopo aver configurato i requisiti delle porte come descritto nella sezione precedente, è possibile verificare che la cache funzioni eseguendo la procedura seguente.

  • Riavviare tutti i nodi della cache. Se non è possibile raggiungere tutte le dipendenze della cache richieste (come descritto in Requisiti delle porte in ingresso e Requisiti delle porte in uscita), la cache non sarà in grado di riavviarsi.
  • 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 (tramite la porta 6380) da un computer che si trova all'interno della stessa rete virtuale della cache tramite 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 eseguire il test è quello di creare un client della cache di test (che potrebbe essere una semplice applicazione della console tramite StackExchange.Redis) che si connette alla cache, aggiunge e recupera alcuni elementi dalla cache. Installare l'applicazione client di esempio in una macchina virtuale che si trova nella stessa rete virtuale della cache ed eseguirla per verificare la connettività alla cache.

È possibile usare reti virtuali con una cache Standard o Basic?

Le reti virtuali possono essere usate solo con cache Premium.

Perché la creazione di una cache Redis ha esito negativo in alcune subnet e non in altre?

Quando si distribuisce un'istanza di Cache Redis di Azure in una rete virtuale di Resource Manager, la cache deve trovarsi in una subnet dedicata che non contiene altri tipi di risorse. Se si tenta di distribuire un'istanza di Cache Redis di Azure in una rete virtuale di Resource Manager all'interno di una subnet contenente altre risorse, la distribuzione non riesce. Prima di poter creare una nuova cache Redis, è necessario eliminare le risorse esistenti all'interno della subnet.

È possibile distribuire più tipi di risorse in una rete virtuale classica, purché siano disponibili indirizzi IP sufficienti.

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 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 cluster includa una sola partizione.

Tutte le funzionalità della cache funzionano quando si ospita una cache 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, che si trova esternamente alla rete virtuale, non può connettersi alla cache.

Usare ExpressRoute con Cache Redis di Azure

I clienti possono connettere un circuito Azure ExpressRoute all'infrastruttura di rete virtuale per estendere la rete locale ad Azure.

Per impostazione predefinita, un circuito ExpressRoute appena creato non esegue il tunneling forzato (annuncio della route predefinita, 0.0.0.0/0) in una rete virtuale. Di conseguenza, la connettività Internet in uscita è consentita direttamente dalla rete virtuale e le applicazioni client sono in grado di connettersi agli altri endpoint di Azure tra cui la Cache Redis di Azure.

Tuttavia, 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 Redis di Azure se il traffico in uscita viene quindi bloccato in locale in modo da impedire all'istanza di Cache Redis di Azure 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 la Cache Redis di Azure. Una route UDR definisce le route specifiche della subnet che verranno accettate invece della route predefinita.

Se possibile, è consigliabile utilizzare la seguente configurazione:

  • 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 routine definita dall'utente applicata alla subnet contenente Cache Redis di Azure definisce 0.0.0.0/0 con una route di lavoro per il traffico TCP/IP verso la rete Internet pubblica, ad esempio impostando 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, garantendo l'accesso a Internet in uscita da Cache Redis di Azure.

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

Importante

Le route definite in un UDR devono essere sufficientemente specifiche per avere la precedenza su qualsiasi route annunciata dalla configurazione di ExpressRoute. Nell'esempio di seguito viene utilizzato l'intervallo di indirizzi ampio 0.0.0.0/0 e pertanto può essere accidentalmente sottoposto a override dagli annunci di route mediante più intervalli di indirizzi 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 riceveranno 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 generali sulle route definite dall'utente sono disponibili in questa panoramica.

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

Passaggi successivi

Informazioni su come usare altre funzionalità di cache premium.