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

  • Articolo

Questo articolo illustra le modifiche apportate alla disponibilità, ad esempio il numero di richieste non riuscite. Queste modifiche nella disponibilità possono essere spesso 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 Availability contiene un valore percentuale. Viene calcolato prendendo il valore totale delle richieste fatturabili e dividendo il numero di richieste applicabili, incluse quelle che hanno generato errori imprevisti.

Eventuali valori inferiori al 100% indicano che alcune richieste di archiviazione hanno esito negativo. È possibile verificare il motivo per cui si verifica un errore esaminando la dimensione ResponseType per i tipi di errore, ad esempio ServerTimeoutError. È consigliabile che la disponibilità sia temporaneamente inferiore al 100% per motivi come i 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. La metrica disponibilità sarà disponibile solo per i periodi di tempo in cui si verificano anche le transazioni nell'account.

È possibile usare le funzionalità di Monitoraggio di Azure per avvisare 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 gli obiettivi di scalabilità di un servizio di archiviazione. In questo modo il servizio di archiviazione viene limitato per assicurare che nessun client o tenant possa usare il servizio a spese di altri. Vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard per maggiori dettagli sugli obiettivi di scalabilità per gli account di archiviazione e gli 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 di PercentThrottlingError

Un aumento degli errori di limitazione si verifica spesso contemporaneamente a un aumento del numero di richieste di archiviazione o quando si esegue inizialmente il test di carico dell'applicazione. L'aumento si può manifestare anche nel client come messaggio di stato HTTP "503 Server Busy" o "500 Operation Timeout" delle operazioni di archiviazione.

Aumento temporaneo degli errori di limitazione

Se vengono visualizzati 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 ridurre i picchi di traffico. Per altre informazioni su come implementare criteri di retry tramite la libreria client di archiviazione, vedere la proprietà RetryOptions.MaxRetries.

Nota

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

Aumento permanente degli errori di limitazione

Se si riscontra un valore costantemente elevato per gli errori di limitazione in seguito a 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 sta raggiungendo gli obiettivi di scalabilità per un account di archiviazione. Ad esempio, se vengono visualizzati errori di limitazione in una coda (che viene conteggiato 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 una gamma più ampia di valori di chiave di partizione. Una causa comune di questo problema è l'anti-pattern anteporto/accodamento, in cui si seleziona la data come chiave di partizione e quindi tutti i dati in un determinato giorno vengono scritti in una partizione (in fase di caricamento, questo può comportare un collo di bottiglia di scrittura). Prendere in considerazione una progettazione diversa del partizionamento o valutare se l'uso dell'archiviazione BLOB potrebbe essere una soluzione migliore. Controllare anche se la limitazione è in corso a causa di picchi nel traffico e analizzare i modi per uniformare il modello di richieste.

Se si distribuiscono le transazioni in più partizioni, tenere presenti i limiti di scalabilità impostati per l'account di archiviazione. Ad esempio, se sono state usate 10 code, ognuna delle quali elabora il massimo di 2.000 messaggi da 1 KB 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à influisce quando il servizio di archiviazione limita i client. Se sono presenti richieste ed entità di dimensioni maggiori, è possibile che venga limitata prima.

Anche una progettazione insufficiente delle query può causare il raggiungimento dei limiti di scalabillità per le partizioni delle tabelle. Ad esempio, una query con un filtro che seleziona solo l'uno per cento delle entità di una partizione ma esegue la scansione di tutte le entità della partizione dovrà accedere a ogni entità. Ogni entità letta verrà conteggiato per il numero totale di transazioni in tale partizione. Pertanto, è possibile raggiungere facilmente gli obiettivi di scalabilità.

Nota

I test delle prestazioni dovrebbero rivelare eventuali progettazioni inefficaci delle query 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 una grande quantità di messaggi di stato HTTP "500 Operation Timeout" dalle operazioni di archiviazione.

Nota

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

I timeout del server (ServerTimeOutError) sono causati da un errore nel server. I timeout del client (ClientTimeout) si verificano perché un'operazione sul 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 deve essere esaminato. È possibile usare le metriche per verificare se si stanno raggiungendo i limiti di scalabilità per il servizio e identificare eventuali picchi di traffico che potrebbero causare questo problema. Se il problema è intermittente, può 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, è consigliabile generare un problema di supporto. Per i timeout del client, è necessario decidere se il timeout è impostato su un valore appropriato nel client e modificare il valore di timeout impostato nel client o esaminare come è possibile 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. L'errore si verifica se un servizio di archiviazione rileva un errore della rete quando il client esegue una richiesta di archiviazione.

La causa più comune dell'errore è la disconnessione del client prima della scadenza del timeout nel servizio di archiviazione. Esaminare il codice nel client per capire 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.

Vedi 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.