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 Connessione ivity 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 Connessione.

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 i nodi di cache Redis di Azure in cluster e possono causare problemi di connettività.

Applicazione client basata su Linux

L'utilizzo delle impostazioni TCP ottimistiche in Linux potrebbe causare problemi di connettività delle applicazioni client. Vedere Connessione stalle 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 è assegnata alla cache dalla sezione "Rete virtuale" sotto il Impostazioni nel menu Risorsa del portale di Azure.
  2. Assicurarsi che il computer host client si trova nella stessa rete virtuale di Cache Redis di Azure.
  3. Quando l'applicazione client si trova in una rete virtuale diversa da Cache Redis di Azure, entrambe le reti virtuali devono avere il peering reti virtuali abilitate all'interno della 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 aver impostato 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 è stato eliminato 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. Eseguire un comando come nslookup <hostname> dall'interno della rete virtuale collegata all'endpoint privato per verificare che il comando venga risolto nell'indirizzo IP privato per la cache.

Regole del firewall

Se è stato configurato un firewall per 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 nella 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 sono state configurate risorse di rete o di sicurezza per l'utilizzo 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 di reti virtuali con le cache Premium, è consigliabile collegamento privato di Azure.

Per altre informazioni, vedi:

La replica geografica delle cache nelle reti virtuali è 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 la rete virtuale in modo efficace 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: