Risolvere i problemi di disponibilità negli account di archiviazione di Azure

  • Articolo

Questo articolo consente di analizzare le modifiche nella disponibilità, ad esempio il numero di richieste non riuscite. Queste modifiche nella disponibilità possono spesso essere identificate monitorando le metriche di archiviazione in Monitoraggio di Azure. Per informazioni generali sull'uso di metriche e log in Monitoraggio di Azure, vedere gli articoli seguenti:

Monitoraggio della disponibilità

È consigliabile monitorare la disponibilità dei servizi di archiviazione nell'account di archiviazione monitorando il valore della metrica Disponibilità . La metrica Disponibilità contiene un valore percentuale. Viene calcolato prendendo il valore totale delle richieste fatturabili e dividendo il valore per il numero di richieste applicabili, incluse quelle che hanno generato errori imprevisti.

Qualsiasi valore inferiore al 100% indica che alcune richieste di archiviazione hanno esito negativo. È possibile capire perché hanno esito negativo esaminando la dimensione ResponseType per i tipi di errore, ad esempio ServerTimeoutError. Si prevede che la disponibilità scende temporaneamente al di sotto del 100% per motivi quali timeout temporanei del server mentre il servizio sposta le partizioni in richieste di bilanciamento del carico migliori; la logica di ripetizione dei tentativi nell'applicazione client deve gestire tali condizioni intermittenti.

È possibile usare le funzionalità di Monitoraggio di Azure per avvisare l'utente se la disponibilità per un servizio scende al di sotto di una soglia specificata.

Le metriche mostrano un aumento degli errori di limitazione

Gli errori di limitazione si verificano quando si superano le destinazioni di scalabilità di un servizio di archiviazione. Il servizio di archiviazione limita per garantire che nessun singolo client o tenant possa usare il servizio a spese di altri. Per altre informazioni, vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard per informazioni dettagliate sugli obiettivi di scalabilità per gli account di archiviazione e sugli obiettivi di prestazioni per le partizioni all'interno degli account di archiviazione.

Se il valore ClientThrottlingError o ServerBusyError della dimensione ResponseType mostra un aumento della percentuale di richieste che hanno esito negativo con un errore di limitazione, è necessario esaminare uno dei due scenari seguenti:

  • Aumento temporaneo di PercentThrottlingError
  • Aumento permanente dell'errore PercentThrottlingError

Un aumento degli errori di limitazione si verifica spesso contemporaneamente a un aumento del numero di richieste di archiviazione o quando si sta inizialmente testando il carico dell'applicazione. Questo può anche manifestarsi nel client come messaggi di stato HTTP "503 Server Occupato" o "Timeout operazione 500" dalle operazioni di archiviazione.

Aumento temporaneo degli errori di limitazione

Se si riscontrano picchi di errori di limitazione che coincidono con periodi di attività elevata per l'applicazione, si implementa una strategia di back-off esponenziale (non lineare) per i tentativi nel client. I tentativi di back-off riducono il carico immediato sulla partizione e consentono all'applicazione di eliminare i picchi di traffico. Per altre informazioni su come implementare i criteri di ripetizione dei tentativi tramite la libreria client di archiviazione, vedere la proprietà RetryOptions.MaxRetries .

Nota

È anche possibile che si verifichino picchi di errori di limitazione che non coincidono con periodi di attività elevata per l'applicazione. La causa più probabile è lo spostamento delle partizioni da parte del servizio di archiviazione per migliorare il bilanciamento del carico.

Aumento permanente degli errori di limitazione

Se viene visualizzato un valore costantemente elevato per gli errori di limitazione a seguito di un aumento permanente dei volumi delle transazioni o quando si eseguono i test di carico iniziali nell'applicazione, è necessario valutare il modo in cui l'applicazione usa le partizioni di archiviazione e se si sta avvicinando agli obiettivi di scalabilità per un account di archiviazione. Ad esempio, se vengono visualizzati errori di limitazione in una coda (che viene conteggiata come una singola partizione), è consigliabile usare code aggiuntive per distribuire le transazioni tra più partizioni. Se vengono visualizzati errori di limitazione in una tabella, è consigliabile usare uno schema di partizionamento diverso per distribuire le transazioni tra più partizioni usando un intervallo più ampio di valori della chiave di partizione. Una causa comune di questo problema è l'anti-pattern anteponi/accodamento, in cui si seleziona la data come chiave di partizione e quindi tutti i dati di un determinato giorno vengono scritti in una partizione (sotto carico, questo può causare un collo di bottiglia di scrittura). Prendere in considerazione una progettazione di partizionamento diversa o valutare se l'uso dell'archiviazione BLOB potrebbe essere una soluzione migliore. Controllare anche se la limitazione si verifica a causa di picchi nel traffico e analizzare i modi per rendere più uniforme il modello di richieste.

Se si distribuiscono le transazioni tra più partizioni, è comunque necessario tenere presente i limiti di scalabilità impostati per l'account di archiviazione. Ad esempio, se sono state usate 10 code, ognuna delle quali elabora al massimo 2.000 messaggi 1KB al secondo, si raggiungerà il limite complessivo di 20.000 messaggi al secondo per l'account di archiviazione. Se è necessario elaborare più di 20.000 entità al secondo, è consigliabile usare più account di archiviazione. È anche necessario tenere presente che le dimensioni delle richieste e delle entità influiscono quando il servizio di archiviazione limita i client. Se si dispone di richieste ed entità più grandi, è possibile che si venga limitati prima.

La progettazione di query inefficiente può anche causare il raggiungere i limiti di scalabilità per le partizioni di tabella. Ad esempio, una query con un filtro che seleziona solo l'1% delle entità in una partizione ma che analizza tutte le entità in una partizione dovrà accedere a ogni entità. Ogni entità letta verrà conteggiata per il numero totale di transazioni in tale partizione. Pertanto, è possibile raggiungere facilmente gli obiettivi di scalabilità.

Nota

Il test delle prestazioni dovrebbe rivelare qualsiasi progettazione di query inefficiente nell'applicazione.

Le metriche mostrano un aumento degli errori di timeout

Gli errori di timeout si verificano quando la dimensione ResponseType è uguale a ServerTimeoutError o ClientTimeout.

Le metriche mostrano un aumento degli errori di timeout per uno dei servizi di archiviazione. Allo stesso tempo, il client riceve un volume elevato di messaggi di stato HTTP "Timeout operazione 500" dalle operazioni di archiviazione.

Nota

È possibile che vengano visualizzati temporaneamente errori di timeout quando il servizio di archiviazione bilancia il carico delle richieste spostando una partizione in un nuovo server.

I timeout del server (ServerTimeOutError) sono causati da un errore nel server. I timeout client (ClientTimeout) si verificano perché un'operazione nel server ha superato il timeout specificato dal client. Ad esempio, un client che usa la libreria client di archiviazione può impostare un timeout per un'operazione.

I timeout del server indicano un problema con il servizio di archiviazione che richiede ulteriori indagini. È possibile usare le metriche per verificare se si raggiungono i limiti di scalabilità per il servizio e per identificare eventuali picchi di traffico che potrebbero causare questo problema. Se il problema è intermittente, potrebbe essere dovuto all'attività di bilanciamento del carico nel servizio. Se il problema è persistente e non è causato dal raggiungimento dei limiti di scalabilità del servizio da parte dell'applicazione, è necessario generare un problema di supporto. Per i timeout client, è necessario decidere se il timeout è impostato su un valore appropriato nel client e modificare il valore di timeout impostato nel client oppure esaminare come migliorare le prestazioni delle operazioni nel servizio di archiviazione, ad esempio ottimizzando le query di tabella o riducendo le dimensioni dei messaggi.

Le metriche mostrano un aumento degli errori di rete

Gli errori di rete si verificano quando la dimensione ResponseType è uguale a NetworkError. Questi si verificano quando un servizio di archiviazione rileva un errore di rete quando il client effettua una richiesta di archiviazione.

La causa più comune di questo errore è la disconnessione di un client prima della scadenza di un timeout nel servizio di archiviazione. Esaminare il codice nel client per comprendere perché e quando il client si disconnette dal servizio di archiviazione. È anche possibile usare strumenti di analisi di rete di terze parti per analizzare i problemi di connettività di rete dal client.

Vedere anche

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.