Condividi tramite

Risoluzione dei problemi di connettività

  • Articolo

In questo articolo viene fornito supporto per la risoluzione dei problemi per la connessione dell'applicazione client a cache di Azure per Redis. I problemi di connettività sono suddivisi in due tipi: problemi di connettività intermittenti e problemi di connettività continua.

Problemi di connettività intermittente

L'applicazione client potrebbe avere problemi di connettività intermittenti causati da eventi come l'applicazione di patch o picchi nel numero di connessioni.

Manutenzione del server

In alcuni casi, la cache viene sottoposta a una manutenzione pianificata o non pianificata del server e l'applicazione può essere influenzata negativamente durante la manutenzione. È possibile convalidare controllando la Errors (Type: Failover) metrica nel portale. Per ridurre al minimo gli effetti dei failover, vedere Resilienza delle connessioni.

Numero di client connessi

Controllare se l'aggregazione max per Connected Clients la metrica è vicina o superiore al numero massimo di connessioni consentite per una determinata dimensione della cache. Per altre informazioni sul dimensionamento per ogni connessione client, vedere cache di Azure per Redis prestazioni.

Applicazioni ospitate in Kubernetes

  • Se l'applicazione client è ospitata in Kubernetes, verificare che il pod che esegue l'applicazione client o i nodi del cluster non siano sotto pressione per quanto riguarda memoria/CPU/rete. Un pod che esegue l'applicazione client può essere interessato da altri pod in esecuzione nello stesso nodo e limitare le connessioni Redis o le operazioni di I/O.
  • Se si usa Istio o qualsiasi altra mesh di servizio, verificare che il proxy mesh del servizio riserva la porta 13000-13019 o 15000-15019. Queste porte vengono usate dai client per comunicare con un cache di Azure per Redis in cluster e possono causare problemi di connettività su tali porte.

Applicazione client basata su Linux

L'utilizzo delle impostazioni TCP ottimistiche in Linux potrebbe causare problemi di connettività delle applicazioni client. Vedere Blocchi di connessione che durano 15 minuti.

Connettività continua

Se l'applicazione non riesce a connettersi a cache di Azure per Redis, è possibile che alcune configurazioni nella cache non siano corrette. Le sezioni seguenti offrono suggerimenti su come assicurarsi che la cache sia configurata correttamente.

Testare la connettività con redis-cli

Testare la connettività usando redis-cli. Per altre informazioni sull'interfaccia della riga di comando, usare lo strumento da riga di comando Redis con cache di Azure per Redis.

Verificare la connettività con PSPING

Se l’interfaccia della riga di comando di Redis non è in grado di connettersi, è possibile testare la connettività usando PSPING in PowerShell.

psping -q <cache DNS endpoint>:<Port Number>

È possibile verificare che il numero di pacchetti inviati sia uguale ai pacchetti ricevuti. La conferma garantisce l'assenza di problemi di connettività.

Configurazione della rete virtuale

Procedura per controllare la configurazione della rete virtuale:

  1. Controllare se una rete virtuale viene assegnata alla cache dalla sezione "Rete virtuale" nel menu Impostazioni del menu Risorsa del portale di Azure.
  2. Assicurarsi che il computer host client si trova nella stessa rete virtuale del cache di Azure per Redis.
  3. Quando l'applicazione client si trova in una rete virtuale diversa dalla cache di Azure per Redis, entrambe le reti virtuali devono avere il peering reti virtuali abilitate nella stessa area di Azure.
  4. Verificare che le regole in ingresso e in uscita soddisfino i requisiti.
  5. Per altre informazioni, vedere Configurare una rete virtuale - Istanza di cache di Azure per Redis di livello Premium.

Configurazione endpoint privato

Procedura per controllare la configurazione dell'endpoint privato:

  1. Public Network Access flag è disabilitato per impostazione predefinita durante la creazione di un endpoint privato. Assicurarsi di impostare correttamente Public Network Access . Quando si dispone della cache in portale di Azure, cercare in Endpoint privato nel menu Risorsa a sinistra per questa impostazione.
  2. Se si sta provando a connettersi all'endpoint privato della cache dall'esterno della rete virtuale della cache, Public Network Access deve essere abilitato.
  3. Se si elimina l'endpoint privato, assicurarsi che l'accesso alla rete pubblica sia abilitato.
  4. Verificare se l'endpoint privato è configurato correttamente. Per altre informazioni, vedere Creare un endpoint privato con una nuova istanza di cache di Azure per Redis.
  5. Verificare se l'applicazione si connette alla <cachename>.redis.cache.windows.net porta 6380. È consigliabile evitare l'uso di <cachename>.privatelink.redis.cache.windows.net nella configurazione o nella stringa di connessione.
  6. Per verificare che il comando venga risolto nell'indirizzo IP privato per la cache, eseguire un comando simile nslookup <hostname> all'interno della rete virtuale collegata all'endpoint privato.

Regole del firewall

Se è stato configurato un firewall per il cache di Azure per Redis, assicurarsi che l'indirizzo IP client venga aggiunto alle regole del firewall. È possibile selezionare Firewall nel menu Risorsa in Impostazioni nel portale di Azure.

Firewall di terze parti o proxy esterno

Quando si usa un firewall o un proxy di terze parti nella rete, verificare che l'endpoint per cache di Azure per Redis, *.redis.cache.windows.net, sia consentito insieme alle porte 6379 e 6380. Potrebbe essere necessario consentire più porte quando si usa una cache in cluster o una replica geografica.

Modifica allo spazio indirizzi IP pubblico

Se si configura una risorsa di rete o di sicurezza per l'uso dell'indirizzo IP pubblico della cache, verificare se l'indirizzo IP pubblico della cache è stato modificato. Per altre informazioni, vedere Affidarsi al nome host e non all’IP pubblico per la cache.

Replica geografica usando l'inserimento di reti virtuali con cache Premium

Sebbene sia possibile usare l'inserimento della rete virtuale (VNet) con le cache Premium, è consigliabile collegamento privato di Azure.

Per altre informazioni, vedi:

La replica geografica delle cache nella rete virtuale (VNet)s è supportata con avvertenze:

  • La replica geografica tra cache nella stessa rete virtuale è supportata.
  • È supportata anche la replica geografica tra cache in reti virtuali diverse.
    • Se le reti virtuali si trovano nella stessa area, è possibile connetterle usando il peering reti virtuali o una connessione da rete virtuale a rete virtuale Gateway VPN.
    • Se le reti virtuali si trovano in aree diverse, la replica geografica tramite peering reti virtuali non è supportata. Una macchina virtuale client nella rete virtuale 1 (area 1) non è in grado di accedere alla cache nella rete virtuale 2 (area 2) usando il nome DNS a causa di un vincolo con servizi di bilanciamento del carico interno basic. Per altre informazioni sui vincoli di peering reti virtuali, vedere Rete virtuale - Peering - Requisiti e vincoli. È consigliabile usare una connessione da rete virtuale a rete virtuale Gateway VPN.

Per configurare in modo efficace la rete virtuale ed evitare problemi di replica geografica, è necessario configurare correttamente le porte in ingresso e in uscita. Per altre informazioni su come evitare i problemi di configurazione errata della rete virtuale più comuni, vedere Requisiti delle porte peer di replica geografica.

Contenuto correlato

Questi articoli forniscono altre informazioni sulla connettività e la resilienza: