Condividi tramite

Risoluzione degli errori di connessione in uscita intermittenti nel Servizio app di Azure

  • Articolo

Questo articolo illustra come risolvere gli errori di connessione intermittenti e i problemi di prestazioni correlati in app Azure Servizio. Fornisce altre informazioni sulle metodologie di risoluzione dei problemi e sull'esaurimento delle porte SNAT (Network Address Translation) di origine. Per altre informazioni in qualsiasi punto di questo articolo, contattare gli esperti di Azure nei forum MSDN Azure e Stack Overflow. In alternativa, inviare un evento imprevisto supporto tecnico di Azure. Accedere al sito del supporto di Azure e selezionare Richiesta di supporto.

Sintomi

Le applicazioni e le funzioni ospitate in app Azure servizio possono presentare uno o più dei sintomi seguenti:

  • Tempi di risposta lenti su tutte o alcune delle istanze di un piano di servizio.
  • Errori intermittenti del gateway 5xx o non valido
  • Messaggi di errore di timeout
  • Non è stato possibile connettersi a endpoint esterni (ad esempio SQLDB, Service Fabric, altri servizi app e così via)

Causa

La causa principale per i problemi di connessione intermittente sta raggiungendo un limite durante la creazione di nuove connessioni in uscita. I limiti che è possibile raggiungere includono:

  • Connessione TCP: è previsto un limite per il numero di connessioni in uscita che è possibile effettuare. Il limite per le connessioni in uscita è associato alle dimensioni del ruolo di lavoro usato.
  • Porte SNAT: le connessioni in uscita in Azure descrivono le restrizioni delle porte SNAT e il modo in cui influiscono sulle connessioni in uscita. Azure usa Source Network Address Translation (SNAT) e servizi di bilanciamento del carico (non esposti ai clienti) di origine per comunicare con indirizzi IP pubblici. A ogni istanza del servizio app Azure viene inizialmente assegnato un numero preallocato di 128 porte SNAT. Il limite per le porte SNAT ha conseguenze sull'apertura delle connessioni allo stesso indirizzo e alla stessa combinazione di porte. Se l'app crea connessioni a una combinazione di combinazioni di indirizzi e porte, non userai le porte SNAT. Le porte SNAT vengono usate se vengono eseguite più chiamate allo stesso indirizzo e alla stessa combinazione di porte. Una volta rilasciata una porta, la porta sarà disponibile per il riutilizzo in base alle esigenze. Il servizio di bilanciamento del carico di rete di Azure recupera la porta SNAT dalle connessioni chiuse solo dopo 4 minuti.

Quando le applicazioni o le funzioni aprono rapidamente una nuova connessione, possono esaurire rapidamente la quota preallocata delle 128 porte. Vengono quindi bloccati fino a quando non diventa disponibile una nuova porta SNAT, tramite l'allocazione dinamica di più porte SNAT o il riutilizzo di una porta SNAT recuperata. Se l'app esaurisce le porte SNAT, si verificano problemi di connettività in uscita intermittenti.

Evitare il problema

Esistono alcune soluzioni che consentono di evitare limitazioni delle porte SNAT. che includono:

  • pool di connessioni: raggruppando le connessioni, si evita di aprire nuove connessioni di rete per le chiamate allo stesso indirizzo e alla stessa porta.
  • endpoint di servizio: non si dispone di una restrizione della porta SNAT per i servizi protetti con gli endpoint di servizio.
  • endpoint privati: non è disponibile una restrizione della porta SNAT per i servizi protetti con endpoint privati.
  • Gateway NAT: con un gateway NAT, sono disponibili 64.000 porte SNAT in uscita utilizzabili dalle risorse che inviano traffico attraverso di esso.

Per evitare il problema della porta SNAT, si impedisce la creazione ripetitiva di nuove connessioni allo stesso host e alla stessa porta. Connessione pool di Connessione sono uno dei modi più ovvi per risolvere il problema.

Se la destinazione è un servizio di Azure che supporta gli endpoint di servizio, è possibile evitare problemi di esaurimento delle porte SNAT usando endpoint di servizio e integrazione rete virtuale a livello di area o endpoint privati. Quando si usa l'integrazione rete virtuale a livello di area e si inserisce endpoint servizio nella subnet di integrazione, il traffico in uscita dell'app verso tali servizi non avrà restrizioni sulle porte SNAT in uscita. Analogamente, se si usa l'integrazione della rete virtuale a livello di area e gli endpoint privati, non si verificano problemi di porta SNAT in uscita a tale destinazione.

Se la destinazione è un endpoint esterno ad Azure, l'uso di un gateway NAT offre 64.000 porte SNAT in uscita. Offre anche un indirizzo in uscita dedicato che non si condivide con nessuno.

Se possibile, migliorare il codice per usare i pool di connessioni ed evitare l'intera situazione. Non è sempre possibile modificare il codice in modo sufficientemente veloce per attenuare questa situazione. Per i casi in cui non è possibile modificare il codice in tempo, sfruttare le altre soluzioni. La soluzione migliore al problema consiste nel combinare tutte le soluzioni nel modo migliore possibile. Provare a usare endpoint di servizio e endpoint privati per i servizi di Azure e il gateway NAT per il resto.

Le strategie generali per ridurre l'esaurimento delle porte SNAT sono descritte nella sezione Risoluzione dei problemi della documentazione sulle connessioni in uscita di Azure . Di queste strategie, le seguenti sono applicabili alle app e alle funzioni ospitate nel servizio app Azure.

Modificare l'applicazione per usare pool di connessioni

Ecco una raccolta di collegamenti per l'implementazione del pool di Connessione ion in base a uno stack di soluzioni diverso.

Nodo

Per impostazione predefinita, le connessioni per NodeJS non vengono mantenute attive. Di seguito sono riportati i database e i pacchetti più comuni per il pool di connessioni che contengono esempi su come implementarli.

HTTP Keep-alive

Java

Di seguito sono riportate le librerie più diffuse usate per il pool di connessioni JDBC che contengono esempi su come implementarle: JDBC Connessione ion Pooling.

Pool di connessioni HTTP

PHP

Anche se PHP non supporta il pool di connessioni, è possibile provare a usare connessioni di database persistenti al server back-end.

Python

Di seguito sono riportati i database e i moduli più diffusi per il pool di connessioni che contengono esempi su come implementarli.

Pool di connessioni HTTP

  • Il pool di connessioni KEEP-ALIVE e HTTP è abilitato per impostazione predefinita nel modulo Richieste .
  • Urllib3

Modificare l'applicazione per riutilizzare le connessioni

Modificare l'applicazione per usare una logica di ripetizione meno aggressiva

Usare keep-alive per reimpostare il timeout di inattività per le connessioni uscita

Altre indicazioni specifiche per servizio app:

  • Un test di carico deve simulare i dati reali in una velocità di alimentazione costante. I test di app e funzioni sotto stress reale possono identificare e risolvere i problemi di esaurimento delle porte SNAT in anticipo.
  • Assicurarsi che i servizi back-end possano restituire rapidamente risposte. Per la risoluzione dei problemi di prestazioni con database SQL di Azure, vedere Risolvere i problemi di prestazioni database SQL di Azure con Intelligent Insights.
  • Aumentare il numero di istanze del piano di servizio app. Per altre informazioni sul ridimensionamento, vedere Ridimensionare un'app nel Servizio app di Azure. A ogni istanza del ruolo di lavoro in un piano di servizio app viene allocata una serie di porte SNAT. Se si distribuisce l'utilizzo in più istanze, è possibile ottenere l'utilizzo della porta SNAT per ogni istanza al di sotto del limite consigliato di 100 connessioni in uscita, per endpoint remoto univoco.
  • Prendere in considerazione il passaggio a ambiente del servizio app (A edizione Standard), in cui viene assegnato un singolo indirizzo IP in uscita e i limiti per le connessioni e le porte SNAT sono superiori. In un oggetto A edizione Standard il numero di porte SNAT per istanza si basa sulla tabella di preallocazione del servizio di bilanciamento del carico di Azure. Ad esempio, un A edizione Standard con 1-50 istanze di lavoro ha 1024 porte preallocate per istanza, mentre un A edizione Standard con 51-100 istanze di lavoro ha 512 porte preallocate per ogni istanza.

Evitare i limiti TCP in uscita è più semplice da risolvere, in quanto i limiti vengono impostati in base alle dimensioni del ruolo di lavoro. È possibile visualizzare i limiti in Limiti numerici per macchine virtuali sandbox - Connessione TCP

Nome limite Descrizione Piccola (A1) Media (A2) Grande (A3) Livello isolato (A edizione Standard)
Connessioni Numero di connessioni tra l'intera macchina virtuale 1920 3968 8064 16.000

Per evitare limiti TCP in uscita, è possibile aumentare le dimensioni dei ruoli di lavoro o aumentare il numero di istanze orizzontalmente.

Risoluzione dei problemi

Conoscere i due tipi di limiti di connessione in uscita e le operazioni eseguite dall'app dovrebbe semplificare la risoluzione dei problemi. Se sai che l'app effettua molte chiamate allo stesso account di archiviazione, potresti sospettare un limite SNAT. Se l'app crea un numero elevato di chiamate agli endpoint su Internet, si sospetta di raggiungere il limite di macchine virtuali.

Se non si conosce il comportamento dell'applicazione abbastanza per determinare rapidamente la causa, sono disponibili alcuni strumenti e tecniche in servizio app per facilitare tale determinazione.

Trovare informazioni sull'allocazione delle porte SNAT

È possibile usare servizio app Diagnostica per trovare informazioni sull'allocazione delle porte SNAT e osservare la metrica di allocazione delle porte SNAT di un sito servizio app. Per trovare le informazioni sull'allocazione delle porte SNAT, seguire questa procedura:

  1. Per accedere alla diagnostica servizio app, passare all'app Web servizio app o ambiente del servizio app nel portale di Azure. Nel riquadro di spostamento a sinistra selezionare Diagnosticare e risolvere i problemi.
  2. Selezionare La categoria disponibilità e prestazioni
  3. Selezionare il riquadro SNAT Port Exhaustion (Esaurimento porte SNAT) nell'elenco dei riquadri disponibili nella categoria . La pratica è quella di mantenerla al di sotto del 128. Se necessario, è comunque possibile aprire un ticket di supporto e il tecnico del supporto otterrà la metrica dal back-end.

Poiché l'utilizzo delle porte SNAT non è disponibile come metrica, non è possibile ridimensionare automaticamente in base all'utilizzo delle porte SNAT o configurare la scalabilità automatica in base alla metrica di allocazione delle porte SNAT.

Porte TCP Connessione e SNAT

Le connessioni TCP e le porte SNAT non sono direttamente correlate. Un rilevatore di utilizzo delle connessioni TCP è incluso nella pagina diagnostica e risoluzione dei problemi di gestione di qualsiasi app servizio app. Cercare la frase "Connessioni TCP" per trovarla.

  • Le porte SNAT vengono usate solo per i flussi di rete esterni, mentre le Connessione TCP totali includono connessioni loopback locali.
  • Una porta SNAT può essere condivisa da flussi diversi, se i flussi sono diversi in entrambi i protocolli, indirizzo IP o porta. La metrica tcp Connessione ions conta ogni connessione TCP.
  • Il limite di connessioni TCP si verifica a livello di istanza del ruolo di lavoro. Il bilanciamento del carico in uscita della rete di Azure non usa la metrica tcp Connessione ions per la limitazione delle porte SNAT.
  • I limiti delle connessioni TCP sono descritti in Limiti numerici di cross-VM sandbox - Connessione TCP
  • Le sessioni TCP esistenti hanno esito negativo quando vengono aggiunte nuove sessioni TCP in uscita da app Azure porta di origine del servizio. È possibile usare un singolo indirizzo IP o riconfigurare i membri del pool back-end per evitare conflitti.
Nome limite Descrizione Piccola (A1) Media (A2) Grande (A3) Livello isolato (A edizione Standard)
Connessioni Numero di connessioni tra l'intera macchina virtuale 1920 3968 8064 16.000

Processi Web e connessioni di database

Se le porte SNAT sono esaurite e i processi Web non sono in grado di connettersi a database SQL, non esiste alcuna metrica per mostrare il numero di connessioni aperte da ogni singolo processo dell'applicazione Web. Per trovare il processo Web problematico, spostare diversi processi Web in un altro servizio app piano per verificare se la situazione migliora o se un problema rimane in uno dei piani. Ripetere il processo fino a trovare il processo Web problematico.

Informazioni aggiuntive