Archiviazione Premium di Azure: progettare per prestazioni elevate

Si applica a: ✔️ Macchine virtuali Linux ✔️ Macchine virtuali Windows ✔️ Set di scalabilità flessibili ✔️ Set di scalabilità uniformi

Questo articolo fornisce linee guida per la creazione di applicazioni ad alte prestazioni usando l'archiviazione Premium di Azure. È possibile usare le istruzioni fornite in questo documento in combinazione con le procedure consigliate per le prestazioni applicabili alle tecnologie usate dall'applicazione. Per illustrare le linee guida, viene usato SQL Server in esecuzione nell'archiviazione Premium come esempio in questo documento.

Anche se vengono affrontati gli scenari di prestazioni per il livello di archiviazione in questo articolo, è necessario ottimizzare il livello dell'applicazione. Ad esempio, se si ospita una farm di SharePoint nell'archiviazione Premium, è possibile usare gli esempi di SQL Server di questo articolo per ottimizzare il server di database. È anche possibile ottimizzare il server Web e il server applicazioni di SharePoint Farm per ottenere il massimo livello di prestazioni.

Questo articolo consente di rispondere alle domande comuni seguenti sull'ottimizzazione delle prestazioni dell'applicazione nell'archiviazione Premium:

• Come è possibile misurare le prestazioni dell'applicazione?
• Perché non vengono visualizzate prestazioni elevate previste?
• Quali fattori influenzano le prestazioni dell'applicazione nell'archiviazione Premium?
• In che modo questi fattori influiscono sulle prestazioni dell'applicazione nell'archiviazione Premium?
• Come è possibile ottimizzare le operazioni di input/output al secondo (IOPS), larghezza di banda e latenza?

Queste linee guida vengono fornite specificamente per l'archiviazione Premium perché i carichi di lavoro in esecuzione nell'archiviazione Premium sono estremamente sensibili alle prestazioni. Vengono forniti esempi in base alle esigenze. È anche possibile applicare alcune di queste linee guida alle applicazioni in esecuzione nelle macchine virtuali IaaS (Infrastructure as a Service) con dischi di archiviazione standard.

Prima di iniziare, se non si ha familiarità con l'archiviazione Premium, leggere Selezionare un tipo di disco di Azure per le macchine virtuali IaaS e obiettivi di scalabilità per gli account di archiviazione BLOB di pagine Premium.

Indicatori di prestazioni dell'applicazione

Si valuta se un'applicazione ha prestazioni ottimali o meno usando indicatori di prestazioni come:

• Velocità con cui un'applicazione sta elaborando una richiesta utente.
• Quantità di dati che un'applicazione elabora per ogni richiesta.
• Numero di richieste elaborate da un'applicazione in un periodo di tempo specifico.
• Per quanto tempo un utente deve attendere di ricevere una risposta dopo l'invio della richiesta.

I termini tecnici per questi indicatori di prestazioni sono operazioni di I/O al secondo, velocità effettiva o larghezza di banda e latenza.

In questa sezione vengono illustrati gli indicatori di prestazioni comuni nel contesto dell'archiviazione Premium. Nella sezione Elenco di controllo delle applicazioni prestazioni per i dischi si apprenderà come misurare questi indicatori di prestazioni per l'applicazione. Più avanti in Ottimizzare le prestazioni dell'applicazione vengono illustrati i fattori che influiscono su questi indicatori di prestazioni e consigli per ottimizzarli.

Operazioni di I/O al secondo

Le operazioni di I/O al secondo sono il numero di richieste inviate dall'applicazione ai dischi di archiviazione in un secondo. Un'operazione di input/output può essere di lettura o scrittura, sequenziale o casuale. Le applicazioni OLTP (Online Transaction Processing) come un sito Web online devono elaborare immediatamente molte richieste utente simultanee. Le richieste utente sono transazioni di database a elevato utilizzo di aggiornamento e inserimento, che l'applicazione deve elaborare rapidamente. Per questo motivo, le applicazioni OLTP richiedono operazioni di I/O al secondo molto elevate.

Le applicazioni OLTP gestiscono milioni di richieste di I/O piccole e casuali. Se si dispone di un'applicazione di questo tipo, è necessario progettare l'infrastruttura dell'applicazione per ottimizzare le operazioni di I/O al secondo. Per altre informazioni su tutti i fattori da considerare per ottenere operazioni di I/O al secondo elevate, vedere Ottimizzare le prestazioni dell'applicazione.

Quando si collega un disco di archiviazione Premium alla macchina virtuale su larga scala, Azure effettua il provisioning di un numero garantito di operazioni di I/O al secondo in base alla specifica del disco. Ad esempio, un disco P50 fornisce 7.500 operazioni di I/O al secondo. Ogni dimensione di macchina virtuale su larga scala ha anche un limite di operazioni di I/O al secondo specifico che può sostenere. Ad esempio, una macchina virtuale GS5 Standard ha un limite di 80.000 operazioni di I/O al secondo.

Capacità di produzione

La velocità effettiva o la larghezza di banda sono la quantità di dati inviati dall'applicazione ai dischi di archiviazione in un intervallo specificato. Se l'applicazione esegue operazioni di input/output con grandi dimensioni di unità di I/O, richiede una velocità effettiva elevata. Le applicazioni data warehouse tendono a eseguire operazioni a elevato utilizzo di analisi che accedono a grandi porzioni di dati alla volta ed eseguono in genere operazioni bulk. In altre parole, tali applicazioni richiedono una velocità effettiva più elevata. Se si dispone di un'applicazione di questo tipo, è necessario progettare l'infrastruttura per ottimizzare la velocità effettiva. Nella sezione successiva vengono illustrati i fattori che è necessario ottimizzare per ottenere questa ottimizzazione.

Quando si collega un disco di archiviazione Premium a una macchina virtuale su larga scala, Azure effettua il provisioning della velocità effettiva in base a tale specifica del disco. Ad esempio, un disco P50 fornisce un throughput del disco di 250 MB/sec. Ogni dimensione di macchina virtuale su larga scala ha anche un limite di velocità effettiva specifico che può sostenere. Ad esempio, la macchina virtuale GS5 Standard ha una velocità effettiva massima di 2.000 MB/sec.

Esiste una relazione tra velocità effettiva e operazioni di I/O al secondo, come illustrato nella formula seguente.

È importante determinare la velocità effettiva ottimale e i valori di IOPS richiesti dall'applicazione. Quando si tenta di ottimizzarne uno, anche l'altro è interessato. Per altre informazioni sull'ottimizzazione delle operazioni di I/O al secondo e della velocità effettiva, vedere Ottimizzare le prestazioni dell'applicazione.

Latenza

La latenza è il tempo necessario per un'applicazione per ricevere una singola richiesta, inviarla ai dischi di archiviazione e inviare la risposta al client. La latenza è una misura essenziale delle prestazioni di un'applicazione, oltre a IOPS e velocità effettiva. La latenza di un disco di archiviazione Premium è il tempo necessario per recuperare le informazioni per una richiesta e comunicarla di nuovo all'applicazione. L'archiviazione Premium offre latenze costantemente basse. I dischi Premium sono progettati per fornire latenze di millisecondi a cifra singola per la maggior parte delle operazioni di I/O. Se si abilita la memorizzazione nella cache dell'host ReadOnly nei dischi di archiviazione Premium, è possibile ottenere una latenza di lettura molto inferiore. Per altre informazioni sulla memorizzazione nella cache del disco, vedere Memorizzazione nella cache del disco.

Quando si ottimizza l'applicazione per ottenere operazioni di I/O al secondo e velocità effettiva più elevate, influisce sulla latenza dell'applicazione. Dopo aver ottimizzato le prestazioni dell'applicazione, valutare la latenza dell'applicazione per evitare un comportamento imprevisto di latenza elevata.

Alcune operazioni del piano di controllo sui dischi gestiti potrebbero spostare il disco da un percorso di archiviazione a un altro. Lo spostamento del disco tra posizioni di archiviazione viene orchestrato tramite una copia in background dei dati, che può richiedere diverse ore per il completamento. In genere, il tempo è inferiore a 24 ore a seconda della quantità di dati nei dischi. Durante questo periodo, l'applicazione può riscontrare una latenza di lettura superiore al solito perché alcune letture possono essere reindirizzate alla posizione originale e richiedere più tempo per il completamento.

Durante una copia in background, non c'è alcun effetto sulla latenza di scrittura per la maggior parte dei tipi di disco. Per i dischi SSD Premium v2 e Ultra, se il disco ha dimensioni di settore 4K, si verifica una latenza di lettura superiore. Se il disco ha dimensioni del settore 512e, si verifica una latenza di lettura e scrittura superiore.

Le operazioni del piano di controllo seguenti potrebbero spostare il disco tra posizioni di archiviazione e causare una maggiore latenza:

• Aggiornare il tipo di archiviazione.
• Scollegare e collegare un disco da una macchina virtuale a un'altra.
• Creare un disco gestito da un VHD.
• Creare un disco gestito da una istantanea.
• Convertire i dischi non gestiti in dischi gestiti.

Elenco di controllo delle applicazioni per le prestazioni per i dischi

Il primo passaggio per la progettazione di applicazioni ad alte prestazioni in esecuzione nell'archiviazione Premium è comprendere i requisiti di prestazioni dell'applicazione. Dopo aver raccolto i requisiti di prestazioni, è possibile ottimizzare l'applicazione per ottenere prestazioni ottimali.

Nella sezione precedente sono stati illustrati gli indicatori di prestazioni comuni: operazioni di I/O al secondo, velocità effettiva e latenza. È necessario identificare quali di questi indicatori di prestazioni sono fondamentali per l'applicazione per offrire l'esperienza utente desiderata. Ad esempio, un elevato IOPS è particolarmente importante per le applicazioni OLTP che elaborano milioni di transazioni al secondo. La velocità effettiva elevata è fondamentale per le applicazioni del data warehouse che elaborano grandi quantità di dati in un secondo. La latenza estremamente bassa è fondamentale per applicazioni in tempo reale come siti Web di streaming video live.

Misurare quindi i requisiti di prestazioni massimi dell'applicazione per tutta la durata. Usare l'elenco di controllo di esempio seguente come inizio. Registrare i requisiti di prestazioni massime nei periodi di carico di lavoro normali, di picco e fuori orario. Identificando i requisiti per tutti i livelli di carico di lavoro, è possibile determinare il requisito di prestazioni complessivo dell'applicazione.

Ad esempio, il carico di lavoro normale di un sito Web di e-commerce è costituito dalle transazioni che gestisce durante la maggior parte dei giorni in un anno. Il carico di lavoro massimo del sito Web è rappresentato dalle transazioni che serve durante le stagioni festivi o eventi di vendita speciali. Il carico di lavoro di picco viene in genere riscontrato per un periodo limitato, ma può richiedere all'applicazione di ridimensionare due o più volte il normale funzionamento. Scopri i requisiti del 50° percentile, del 90° percentile e del 99° percentile. Queste informazioni consentono di filtrare gli outlier nei requisiti di prestazioni ed è possibile concentrarsi sull'ottimizzazione dei valori corretti.

Elenco di controllo dei requisiti di prestazioni dell'applicazione

Se si dispone di un'applicazione esistente e si vuole passare all'archiviazione Premium, compilare prima di tutto l'elenco di controllo precedente per l'applicazione esistente. Compilare quindi un prototipo dell'applicazione nell'archiviazione Premium e progettare l'applicazione in base alle linee guida descritte in Ottimizzare le prestazioni dell'applicazione. L'articolo successivo descrive gli strumenti che è possibile usare per raccogliere le misurazioni delle prestazioni.

Contatori per misurare i requisiti di prestazioni dell'applicazione

Il modo migliore per misurare i requisiti di prestazioni dell'applicazione consiste nell'usare PerfMongli strumenti di monitoraggio forniti dal sistema operativo del server. È possibile usare PerfMon per Windows e iostat per Linux. Questi strumenti acquisiscono i contatori corrispondenti a ogni misura illustrata nella sezione precedente. È necessario acquisire i valori di questi contatori quando l'applicazione esegue i carichi di lavoro normali, di picco e di minore ora.

I PerfMon contatori sono disponibili per processore, memoria e ogni disco logico e disco fisico del server. Quando si usano dischi di archiviazione Premium con una macchina virtuale, i contatori dei dischi fisici sono per ogni disco di archiviazione Premium e i contatori dei dischi logici sono per ogni volume creato nei dischi di archiviazione Premium. È necessario acquisire i valori per i dischi che ospitano il carico di lavoro dell'applicazione. Se è presente un mapping uno-a-uno tra dischi logici e fisici, è possibile fare riferimento ai contatori dei dischi fisici. In caso contrario, fare riferimento ai contatori dei dischi logici.

In Linux il iostat comando genera un report sull'utilizzo della CPU e del disco. Il report sull'utilizzo del disco fornisce statistiche per ogni dispositivo fisico o partizione. Se si dispone di un server di database con i relativi dati e log in dischi separati, raccogliere questi dati per entrambi i dischi. La tabella seguente descrive i contatori per dischi, processori e memoria.

Altre informazioni su iostat e PerfMon.

Ottimizzare le prestazioni dell'applicazione

I fattori principali che influenzano le prestazioni di un'applicazione in esecuzione nell'archiviazione Premium sono la natura delle richieste di I/O, le dimensioni della macchina virtuale, le dimensioni del disco, il numero di dischi, la memorizzazione nella cache del disco, il multithreading e la profondità della coda. È possibile controllare alcuni di questi fattori con manopole fornite dal sistema.

La maggior parte delle applicazioni potrebbe non offrire un'opzione per modificare direttamente le dimensioni di I/O e la profondità della coda. Ad esempio, se si usa SQL Server, non è possibile scegliere le dimensioni di I/O e la profondità della coda. SQL Server sceglie i valori ottimali per le dimensioni di I/O e la profondità della coda per ottenere il massimo livello di prestazioni. È importante comprendere gli effetti di entrambi i tipi di fattori sulle prestazioni dell'applicazione in modo da poter effettuare il provisioning di risorse appropriate per soddisfare le esigenze di prestazioni.

In questa sezione fare riferimento all'elenco di controllo dei requisiti dell'applicazione creato per identificare quanto è necessario ottimizzare le prestazioni dell'applicazione. In base all'elenco di controllo, è possibile determinare quali fattori di questa sezione è necessario ottimizzare.

Per verificare gli effetti di ogni fattore sulle prestazioni dell'applicazione, eseguire gli strumenti di benchmarking nella configurazione dell'applicazione. Per la procedura per eseguire strumenti di benchmarking comuni nelle macchine virtuali Windows e Linux, vedere gli articoli sul benchmarking alla fine di questo documento.

Ottimizzare le operazioni di I/O al secondo, la velocità effettiva e la latenza a colpo d'occhio

La tabella seguente riepiloga i fattori di prestazioni e i passaggi necessari per ottimizzare operazioni di I/O al secondo, velocità effettiva e latenza. Le sezioni che seguono questo riepilogo descrivono ogni fattore in modo più approfondito.

Per altre informazioni sulle dimensioni delle macchine virtuali e sulle operazioni di I/O al secondo, velocità effettiva e latenza disponibili per ogni tipo di macchina virtuale, vedere Dimensioni per le macchine virtuali in Azure.

Natura delle richieste di I/O

Una richiesta di I/O è un'unità di operazione di input/output eseguita dall'applicazione. L'identificazione della natura delle richieste di I/O, casuali o sequenziali, di lettura o scrittura, di piccole o grandi dimensioni, consente di determinare i requisiti di prestazioni dell'applicazione. È importante comprendere la natura delle richieste di I/O per prendere le decisioni giuste quando si progetta l'infrastruttura dell'applicazione. Le operazioni di I/O devono essere distribuite in modo uniforme per ottenere le migliori prestazioni possibili.

Le dimensioni di I/O sono uno dei fattori più importanti. Le dimensioni di I/O sono le dimensioni della richiesta di operazione di input/output generata dall'applicazione. Le dimensioni di I/O influiscono in modo significativo sulle prestazioni, soprattutto sulle operazioni di I/O al secondo e sulla larghezza di banda che l'applicazione può ottenere. La formula seguente illustra la relazione tra operazioni di I/O al secondo, dimensioni di I/O e larghezza di banda/velocità effettiva.

Alcune applicazioni consentono di modificare le dimensioni di I/O, mentre alcune applicazioni non lo sono. Ad esempio, SQL Server determina le dimensioni di I/O ottimali e non fornisce agli utenti alcuna manopola per modificarla. D'altra parte, Oracle fornisce un parametro denominato DB_BLOCK_SIZE, che è possibile usare per configurare le dimensioni della richiesta di I/O del database.

Se si usa un'applicazione, che non consente di modificare le dimensioni di I/O, usare le linee guida in questo articolo per ottimizzare l'indicatore KPI delle prestazioni più rilevante per l'applicazione. Per esempio:

• Un'applicazione OLTP genera milioni di richieste di I/O piccole e casuali. Per gestire questi tipi di richieste di I/O, è necessario progettare l'infrastruttura dell'applicazione per ottenere operazioni di I/O al secondo più elevate.
• Un'applicazione di data warehousing genera richieste di I/O di grandi dimensioni e sequenziali. Per gestire questi tipi di richieste di I/O, è necessario progettare l'infrastruttura dell'applicazione per ottenere una maggiore larghezza di banda o velocità effettiva.

Se si usa un'applicazione che consente di modificare le dimensioni di I/O, usare questa regola generale per le dimensioni di I/O oltre ad altre linee guida sulle prestazioni:

• Dimensioni di I/O inferiori per ottenere un numero maggiore di operazioni di I/O al secondo. Ad esempio, 8 KB per un'applicazione OLTP.
• Dimensioni di I/O maggiori per ottenere una maggiore larghezza di banda/velocità effettiva. Ad esempio, 1.024 KB per un'applicazione data warehouse.

Di seguito è riportato un esempio di come calcolare le operazioni di I/O al secondo e la velocità effettiva/larghezza di banda per l'applicazione.

Si consideri un'applicazione che usa un disco P30. Il numero massimo di operazioni di I/O al secondo e velocità effettiva/larghezza di banda che un disco P30 può raggiungere è rispettivamente di 5.000 operazioni di I/O al secondo e 200 MB/sec. Se l'applicazione richiede il numero massimo di operazioni di I/O dal disco P30 e si usano dimensioni di I/O inferiori, ad esempio 8 KB, la larghezza di banda risultante che è possibile ottenere è 40 MB/sec. Se l'applicazione richiede la velocità effettiva/larghezza di banda massima da un disco P30 e si usano dimensioni di I/O maggiori, ad esempio 1.024 KB, le operazioni di I/O al secondo risultanti sono minori, ad esempio 200 operazioni di I/O al secondo.

Regolare la dimensione dell'I/O affinché soddisfi i requisiti di IOPS e larghezza di banda dell'applicazione. La tabella seguente riepiloga le diverse dimensioni di I/O, gli IOPS corrispondenti e il throughput per un disco P30.

Per ottenere operazioni di I/O al secondo e larghezza di banda superiori al valore massimo di un singolo disco di archiviazione Premium, usare più dischi Premium con striping. Ad esempio, eseguire lo striping di due dischi P30 per ottenere un numero combinato di operazioni di I/O al secondo pari a 10.000 operazioni di I/O al secondo o una velocità effettiva combinata di 400 MB/sec. Come illustrato nella sezione successiva, è necessario usare una dimensione di macchina virtuale che supporti le operazioni di I/O al secondo e la velocità effettiva combinate del disco.

Per verificare gli effetti delle dimensioni di I/O sulle prestazioni dell'applicazione, è possibile eseguire strumenti di benchmarking nella macchina virtuale e nei dischi. Creare più esecuzioni di test e usare dimensioni di I/O diverse per ogni esecuzione per visualizzare l'effetto. Per altre informazioni, vedere gli articoli di benchmarking alla fine di questo documento.

Dimensioni delle macchine virtuali su larga scala

Quando si inizia a progettare un'applicazione, una delle prime operazioni da eseguire consiste nel scegliere una macchina virtuale per ospitare l'applicazione. L'archiviazione Premium include dimensioni di macchine virtuali su larga scala che possono eseguire applicazioni che richiedono una potenza di calcolo superiore e prestazioni di I/O del disco locale elevate. Queste macchine virtuali offrono processori più veloci, un rapporto memoria-core superiore e un'unità SSD (Solid State Drive) per il disco locale. Esempi di macchine virtuali su larga scala che supportano l'archiviazione Premium sono le macchine virtuali serie DS e GS.

Le macchine virtuali su larga scala sono disponibili in dimensioni diverse con un numero diverso di core CPU, memoria, sistema operativo e dimensioni temporanee del disco. Ogni dimensione della macchina virtuale ha anche un numero massimo di dischi dati che è possibile collegare alla macchina virtuale. La dimensione della macchina virtuale scelta influisce sulla quantità di elaborazione, memoria e capacità di archiviazione disponibili per l'applicazione. Influisce anche sul costo di calcolo e archiviazione. Ad esempio, le specifiche seguenti riguardano le dimensioni massime della macchina virtuale in una serie DS e una serie GS.

Per visualizzare un elenco completo di tutte le dimensioni di macchine virtuali di Azure disponibili, vedere Dimensioni per le macchine virtuali in Azure. Scegliere una taglia della macchina virtuale che possa ridimensionarsi e soddisfare i requisiti di prestazioni della tua applicazione. Tenere conto anche delle considerazioni importanti seguenti quando si scelgono le dimensioni delle macchine virtuali.

Limiti di scalabilità

I limiti massimi di operazioni di I/O al secondo per macchina virtuale e per disco sono diversi e indipendenti l'uno dall'altro. Assicurarsi che l'applicazione stia rispettando gli IOPS nei limiti operativi della VM e dei dischi Premium collegati. In caso contrario, le prestazioni dell'applicazione subiscono un rallentamento.

Si supponga, ad esempio, che un requisito dell'applicazione sia un massimo di 4.000 operazioni di I/O al secondo. Per ottenere questo livello, effettuare il provisioning di un disco P30 in una macchina virtuale DS1. Il disco P30 può recapitare fino a 5.000 operazioni di I/O al secondo. Tuttavia, la macchina virtuale DS1 è limitata a 3.200 operazioni di I/O al secondo. Pertanto, le prestazioni dell'applicazione sono vincolate dal limite di macchine virtuali a 3.200 operazioni di I/O al secondo e le prestazioni sono ridotte. Per evitare questa situazione, scegliere una macchina virtuale e una dimensione del disco che soddisfano entrambi i requisiti dell'applicazione.

Costo dell'operazione

In molti casi, è possibile che il costo complessivo dell'operazione usando l'archiviazione Premium sia inferiore rispetto all'uso dell'archiviazione standard.

Si consideri, ad esempio, un'applicazione che richiede 16.000 operazioni di I/O al secondo. Per ottenere queste prestazioni, è necessaria una macchina virtuale IaaS di Azure Standard_D14, che può offrire un numero massimo di operazioni di I/O al secondo pari a 16.000 usando 32 dischi di archiviazione standard da 1 TB. Ogni disco di archiviazione standard da 1 TB può raggiungere un massimo di 500 operazioni di I/O al secondo.

• Il costo stimato di questa macchina virtuale al mese è di $ 1.570.
• Il costo mensile di 32 dischi di archiviazione standard è di $ 1.638.
• Il costo mensile stimato è di $ 3.208.

Se è stata ospitata la stessa applicazione nell'archiviazione Premium, sono necessarie dimensioni di macchina virtuale inferiori e meno dischi di archiviazione Premium, riducendo il costo complessivo. Una macchina virtuale Standard_DS13 può soddisfare il requisito di 16.000 operazioni di I/O al secondo usando quattro dischi P30. La macchina virtuale DS13 ha un numero massimo di operazioni di I/O al secondo pari a 25.600 e ogni disco P30 ha un numero massimo di operazioni di I/O al secondo pari di 5.000. In generale, questa configurazione può ottenere 5.000 x 4 = 20.000 operazioni di I/O al secondo.

• Il costo stimato di questa macchina virtuale al mese è di $1.003.
• Il costo mensile di quattro dischi di archiviazione Premium P30 è di $ 544,34.
• Il costo mensile stimato è di $1.544.

La tabella seguente riepiloga la suddivisione dei costi di questo scenario per l'archiviazione Standard e Premium.

Distribuzioni Linux

Con l'archiviazione Premium si ottiene lo stesso livello di prestazioni per le macchine virtuali che eseguono Windows e Linux. Sono supportati molti tipi di distribuzioni Linux. Per altre informazioni, vedere Distribuzioni linux approvate in Azure.

Distribuzioni diverse sono più adatte per diversi tipi di carichi di lavoro. Vengono visualizzati diversi livelli di prestazioni a seconda della distribuzione in cui è in esecuzione il carico di lavoro. Testare le distribuzioni linux con l'applicazione e scegliere quella più adatta.

Quando si esegue Linux con archiviazione Premium, controllare gli aggiornamenti più recenti sui driver necessari per garantire prestazioni elevate.

Dimensioni del disco di archiviazione Premium

L'archiviazione Premium offre diverse dimensioni, in modo da poter scegliere quella più adatta alle proprie esigenze. Ogni dimensione del disco ha un limite di scalabilità diverso per operazioni di I/O al secondo, larghezza di banda e archiviazione. Scegliere le dimensioni corrette del disco di archiviazione Premium in base ai requisiti dell'applicazione e alle dimensioni delle macchine virtuali su larga scala. La tabella seguente illustra le dimensioni dei dischi e le relative funzionalità. Le dimensioni P4, P6, P15, P60, P70 e P80 sono attualmente supportate solo per i dischi gestiti.

*Si applica solo ai dischi con bursting on demand abilitato.
** Si applica solo ai dischi con Performance Plus abilitata.

Il numero di dischi scelti dipende dalle dimensioni del disco scelte. È possibile usare un singolo disco P50 o più dischi P10 per soddisfare le esigenze dell'applicazione. Prendere in considerazione le considerazioni elencate qui quando si fa la scelta.

Limiti di scalabilità (operazioni di I/O al secondo e velocità effettiva)

I limiti di operazioni di I/O al secondo e velocità effettiva di ogni dimensione del disco Premium sono diversi e indipendenti dai limiti di scalabilità delle macchine virtuali. Assicurarsi che le operazioni di I/O al secondo e la velocità effettiva totali dei dischi siano entro i limiti di scalabilità delle dimensioni della macchina virtuale scelta.

Ad esempio, se un requisito dell'applicazione è un throughput massimo di 250 MB/sec e si utilizza una macchina virtuale DS4 con un singolo disco P30, la macchina virtuale DS4 può fornire fino a 256 MB/sec di throughput. Tuttavia, un singolo disco P30 ha un limite di velocità effettiva di 200 MB/sec. Pertanto, l'applicazione è vincolata a 200 MB/sec a causa del limite di disco. Per superare questo limite, effettuare il provisioning di più dischi dati nella macchina virtuale o ridimensionare i dischi in P40 o P50.

Numero di dischi

Determinare il numero di dischi necessari valutando i requisiti dell'applicazione. Ogni dimensione della macchina virtuale ha anche un limite per il numero di dischi che è possibile collegare alla macchina virtuale. In genere, questa quantità è due volte il numero di core. Assicurarsi che le dimensioni della macchina virtuale scelte possano supportare il numero di dischi necessari.

Tenere presente che i dischi di archiviazione Premium hanno funzionalità di prestazioni superiori rispetto ai dischi di archiviazione standard. Se si esegue la migrazione dell'applicazione da una macchina virtuale IaaS di Azure usando l'archiviazione Standard all'archiviazione Premium, è probabile che siano necessari meno dischi Premium per ottenere prestazioni uguali o superiori per l'applicazione.

Memorizzazione nella cache del disco

Le macchine virtuali su larga scala che usano l'archiviazione Premium hanno una tecnologia di memorizzazione nella cache a più livelli denominata BlobCache. BlobCache usa una combinazione della RAM host e dell'unità SSD locale per la memorizzazione nella cache. Questa cache è disponibile per dischi gestiti HDD Standard, SSD Standard e Ssd Premium. Per impostazione predefinita, questa impostazione della cache è impostata su ReadWrite per i dischi del sistema operativo e ReadOnly per i dischi dati. Con la memorizzazione nella cache dei dischi abilitata, le macchine virtuali su larga scala possono ottenere livelli estremamente elevati di prestazioni che superano le prestazioni del disco sottostanti.

Per ulteriori informazioni sul funzionamento di BlobCache, consultare il post del blog "All'interno dell'Archiviazione Premium di Azure".

È importante abilitare la memorizzazione nella cache nel set corretto di dischi. Il fatto che sia necessario abilitare la memorizzazione nella cache del disco in un disco o meno dipende dal modello di carico di lavoro gestito dal disco. La tabella seguente mostra le impostazioni della cache predefinite per il sistema operativo e i dischi dati.

È consigliabile usare le impostazioni della cache del disco seguenti per i dischi dati:

Sola lettura

Configurare la memorizzazione nella cache ReadOnly sui dischi dati permette di ottenere una bassa latenza di lettura, unitamente a IOPS e throughput di lettura molto elevate per l'applicazione per due motivi:

1. Le letture eseguite dalla cache, che si trova nella memoria della macchina virtuale e nell'unità SSD locale, sono più veloci rispetto alle letture dal disco dati, che si trova in Archiviazione BLOB di Azure.
2. L'archiviazione non conta le letture servite dalla cache per le operazioni di I/O al secondo e la velocità di trasmissione del disco. Per questo motivo, la tua applicazione può raggiungere IOPS e velocità effettiva totali più elevate.

LeggiScrivi

Per impostazione predefinita, i dischi del sistema operativo hanno la memorizzazione nella cache ReadWrite abilitata. È stato aggiunto di recente anche il supporto per la memorizzazione nella cache ReadWrite nei dischi dati. Se si usa la memorizzazione nella cache ReadWrite , è necessario disporre di un modo appropriato per scrivere i dati dalla cache ai dischi permanenti. Ad esempio, SQL Server gestisce la scrittura di dati memorizzati nella cache nei dischi di archiviazione persistente autonomamente. L'uso della cache ReadWrite con un'applicazione che non gestisce la persistenza dei dati necessari può causare la perdita di dati, se la macchina virtuale si arresta in modo anomalo.

Nessuno

Attualmente none è supportato solo nei dischi dati. Non è supportato nei dischi del sistema operativo. Se si imposta Nessuno su un disco del sistema operativo, esegue l'override di questa impostazione internamente e la imposta su ReadOnly.

Ad esempio, è possibile applicare queste linee guida a SQL Server in esecuzione in macchine virtuali abilitate per l'archiviazione Premium seguendo questa procedura:

1. Configurare la cache ReadOnly su HDD Standard, SSD Standard o Dischi gestiti SSD Premium che ospitano file di dati.
   1. La velocità di lettura dalla cache riduce il tempo di query di SQL Server perché le pagine di dati vengono recuperate più velocemente dalla cache rispetto ai dischi dati direttamente dai dischi dati.
   2. La gestione delle letture dalla cache indica una maggiore velocità effettiva disponibile dai dischi dati. SQL Server può usare questa velocità effettiva aggiuntiva per recuperare più pagine di dati e altre operazioni, ad esempio backup/ripristino, caricamenti batch e ricompilazione dell'indice.
2. Configurare la cache None nei dischi di archiviazione Premium che ospitano i file di log.
   1. I file di log hanno principalmente operazioni di scrittura, quindi non traggono vantaggio dalla cache ReadOnly .

Ottimizzare le prestazioni nelle macchine virtuali Linux

Per tutti i dischi SSD Premium o Ultra, è possibile disabilitare le barriere per i file system sul disco per migliorare le prestazioni quando è noto che non sono presenti cache che potrebbero perdere dati. Se la memorizzazione nella cache dei dischi di Azure è impostata su ReadOnly o Nessuno, è possibile disabilitare le barriere. Tuttavia, se la memorizzazione nella cache è impostata su ReadWrite, le barriere devono rimanere abilitate per garantire la durabilità della scrittura. Le barriere sono in genere abilitate per impostazione predefinita, ma è possibile disabilitare le barriere usando uno dei metodi seguenti a seconda del tipo di file system:

• reiserFS: usare l'opzione barrier=none mount per disabilitare le barriere. Per abilitare in modo esplicito le barriere, usare barrier=flush.
• ext3/ext4: usare l'opzione di montaggio barrier=0 per disabilitare le barriere. Per abilitare in modo esplicito le barriere, usare barrier=1.
• XFS: usare l'opzione di montaggio nobarrier per disabilitare le barriere. Per abilitare in modo esplicito le barriere, usare la barriera. A partire dalla versione 4.10 del kernel Linux principale, la progettazione del file system XFS garantisce sempre la durabilità. La disabilitazione delle barriere non ha alcun effetto e l'opzione nobarrier è deprecata. Tuttavia, alcune distribuzioni di Linux potrebbero aver eseguito il backporting delle modifiche apportate a una versione di distribuzione con una versione precedente del kernel. Rivolgersi al fornitore di distribuzione per verificare lo stato della distribuzione e della versione in esecuzione.

Ripartizione dei dati su disco

Quando una macchina virtuale a scalabilità elevata è collegata a diversi dischi persistenti di archiviazione Premium, i dischi possono essere raggruppati per aggregare le operazioni di I/O, la larghezza di banda e la capacità di archiviazione.

In Windows è possibile usare Spazi di archiviazione per eseguire lo striping dei dischi insieme. È necessario configurare una colonna per ogni disco in un pool. In caso contrario, le prestazioni complessive del volume con striping possono essere inferiori al previsto a causa di una distribuzione non uniforme del traffico tra i dischi.

Usando l'interfaccia utente di Server Manager, è possibile impostare il numero totale di colonne su 8 per un volume con striping. Quando si collegano più di otto dischi, usare PowerShell per creare il volume. Usando PowerShell, è possibile impostare il numero di colonne uguale al numero di dischi. Ad esempio, se sono presenti 16 dischi in un singolo set di striping, specificare 16 le colonne nel NumberOfColumns parametro del cmdlet di New-VirtualDisk PowerShell.

In Linux, usare l'utilità MDADM per lo striping dei dischi. Per informazioni su come eseguire lo striping dei dischi in Linux, vedere Configurare RAID software in Linux.

Dimensioni dei blocchi di dati

Una configurazione importante nello striping del disco è la dimensione della stripe. Le dimensioni dello striping o del blocco sono il blocco più piccolo di dati che un'applicazione può gestire in un volume con striping. Le dimensioni di striping configurate dipendono dal tipo di applicazione e dal relativo modello di richiesta. Se si sceglie la dimensione di striping errata, potrebbe verificarsi un errore di I/O, con un calo delle prestazioni dell'applicazione.

Ad esempio, se una richiesta di I/O generata dall'applicazione è maggiore delle dimensioni di striping del disco, il sistema di archiviazione lo scrive oltre i limiti dell'unità di striping su più dischi. Quando è il momento di accedere a tali dati, è necessario cercare in più unità di striping per completare la richiesta. L'effetto cumulativo di questo comportamento può causare una riduzione sostanziale delle prestazioni. D'altra parte, se la dimensione della richiesta di I/O è inferiore alla dimensione dello striping e se ha natura casuale, le richieste di I/O potrebbero accumularsi sullo stesso disco, causando un collo di bottiglia e infine degradare le prestazioni di I/O.

A seconda del tipo di carico di lavoro in cui è in esecuzione l'applicazione, scegliere una dimensione di striping appropriata. Per le richieste di I/O casuali di piccole dimensioni, usare una dimensione dello stripe inferiore. Per le richieste di I/O sequenziali di grandi dimensioni, usare una dimensione di striping maggiore. Scopri le raccomandazioni relative alle dimensioni del stripe per l'applicazione in esecuzione nell'archiviazione premium. Per SQL Server configurare dimensioni di striping pari a 64 KB per carichi di lavoro OLTP e 256 KB per carichi di lavoro di tipo data warehouse. Per altre informazioni, vedere Procedure consigliate per le prestazioni per SQL Server in macchine virtuali di Azure.

Multithreading

Azure ha progettato la piattaforma di archiviazione Premium per essere parallela in modo massiccio. Per questo motivo, un'applicazione multithreading ottiene prestazioni superiori rispetto a un'applicazione a thread singolo. Un'applicazione multithreading suddivide le attività in più thread e aumenta l'efficienza dell'esecuzione usando la macchina virtuale e le risorse disco al massimo.

Ad esempio, se l'applicazione è in esecuzione in una singola macchina virtuale core usando due thread, la CPU può passare tra i due thread per ottenere un'efficienza. Mentre un thread è in attesa del completamento di un I/O su disco, la CPU può passare all'altro thread. In questo modo, due thread possono ottenere più di quanto farebbe uno singolo. Se la macchina virtuale ha più di un core, diminuisce ulteriormente il tempo di esecuzione perché ogni core può eseguire attività in parallelo.

Potrebbe non essere possibile modificare il modo in cui un'applicazione fuori uso implementa il threading singolo o il multithreading. Ad esempio, SQL Server è in grado di gestire più CPU e multicore. Tuttavia, SQL Server decide in quali condizioni usa uno o più thread per elaborare una query. Può eseguire query e compilare indici usando il multithreading. Per una query che prevede l'unione di tabelle di grandi dimensioni e l'ordinamento dei dati prima di tornare all'utente, SQL Server usa probabilmente più thread. Un utente non può controllare se SQL Server esegue una query usando un singolo thread o più thread.

Esistono impostazioni di configurazione che è possibile modificare per influenzare l'elaborazione multithreading o parallela di un'applicazione. Ad esempio, per SQL Server è la max degree of parallelism configurazione. Questa impostazione denominata MAXDOP consente di configurare il numero massimo di processori che SQL Server può usare durante l'elaborazione parallela. È possibile configurare MAXDOP per singole query o operazioni sugli indici. Questa funzionalità è utile quando si vogliono bilanciare le risorse del sistema per un'applicazione critica per le prestazioni.

Si supponga, ad esempio, che l'applicazione che usa SQL Server esegua una query di grandi dimensioni e un'operazione sull'indice contemporaneamente. Si supponga di voler che l'operazione sull'indice sia più efficiente rispetto alla query più grande. In questo caso, è possibile impostare il valore MAXDOP dell'operazione sull'indice su un valore superiore al valore MAXDOP per la query. In questo modo, SQL Server dispone di più processori che può usare per l'operazione di indice rispetto al numero di processori che può dedicare alla query di grandi dimensioni. Tenere presente che non si controlla il numero di thread usati da SQL Server per ogni operazione. È possibile controllare il numero massimo di processori dedicati per il multithreading.

Altre informazioni sui gradi di parallelismo in SQL Server. Informazioni su come tali impostazioni influiscono sul multithreading nell'applicazione e sulle relative configurazioni per ottimizzare le prestazioni.

Profondità della coda

La profondità della coda o la lunghezza della coda o la dimensione della coda corrisponde al numero di richieste di I/O in sospeso nel sistema. Il valore della profondità della coda determina il numero di operazioni di I/O che la tua applicazione può mettere in coda, che verranno elaborate dai dischi di archiviazione. Influisce su tutti e tre gli indicatori di prestazioni dell'applicazione descritti in questo articolo: operazioni di I/O al secondo, velocità effettiva e latenza.

La profondità della coda e il multithreading sono strettamente correlati. Il valore di profondità della coda indica il livello di multithreading che può essere raggiunto dall'applicazione. Se la profondità della coda è elevata, l'applicazione può eseguire più operazioni contemporaneamente; in altre parole, può aumentare il multithreading. Se la profondità della coda è ridotta, anche se l'applicazione è multithreading, non avrà richieste sufficienti allineate per l'esecuzione simultanea.

In genere, le applicazioni off-the-shelf non consentono di modificare la profondità della coda, perché se è impostata in modo non corretto, fa più male che bene. Le applicazioni impostano il valore corretto della profondità della coda per ottenere prestazioni ottimali. È importante comprendere questo concetto in modo da poter risolvere i problemi di prestazioni con l'applicazione. È anche possibile osservare gli effetti della profondità della coda eseguendo strumenti di benchmarking nel sistema.

Alcune applicazioni forniscono impostazioni per influenzare la profondità della coda. Ad esempio, l'impostazione MAXDOP in SQL Server illustrata nella sezione precedente. MAXDOP è un modo per influenzare la profondità della coda e il multithreading, anche se non modifica direttamente il valore di profondità della coda di SQL Server.

Profondità elevata della coda

Una profondità elevata della coda aumenta le operazioni sul disco. Il disco conosce in anticipo la richiesta successiva nella coda. Il disco può quindi pianificare le operazioni in anticipo ed elaborarle in una sequenza ottimale. Poiché l'applicazione invia più richieste al disco, il disco può elaborare più operazioni di I/O parallele. In definitiva, l'applicazione può ottenere operazioni di I/O al secondo più elevate. Poiché l'applicazione sta elaborando più richieste, aumenta anche la velocità effettiva totale dell'applicazione.

In genere, un'applicazione può raggiungere la velocità effettiva massima con 8-16+ operazioni di I/O in sospeso per ogni disco collegato. Se la profondità della coda è uno, l'applicazione non invia un numero sufficiente di operazioni di I/O al sistema e elabora una quantità inferiore in un determinato periodo. In altre parole, minore velocità effettiva.

Ad esempio, in SQL Server, impostare il valore MAXDOP per una query su 4 informa SQL Server che può usare fino a quattro core per eseguire la query. SQL Server determina il migliore valore di profondità della coda e il numero di core per l'esecuzione della query.

Profondità ottimale della coda

Un valore di profondità della coda molto elevato presenta anche i suoi svantaggi. Se il valore di profondità della coda è troppo elevato, l'applicazione tenta di ottimizzare elevati IOPS. A meno che l'applicazione non disponga di dischi persistenti con IOPS provisionati sufficienti, un valore di profondità della coda molto elevato può influire negativamente sulla latenza dell'applicazione. La formula seguente illustra la relazione tra operazioni di I/O al secondo, latenza e profondità della coda.

Non è consigliabile configurare la profondità della coda su un valore elevato, ma su un valore ottimale, che può offrire operazioni di I/O al secondo sufficienti per l'applicazione senza influire sulle latenze. Ad esempio, se la latenza dell'applicazione deve essere di 1 millisecondo, la profondità della coda necessaria per ottenere 5.000 operazioni di I/O al secondo è QD = 5.000 x 0,001 = 5.

Profondità della coda per il volume con suddivisione

Per un volume con striping, mantenere una profondità della coda sufficientemente elevata affinché ogni disco raggiunga singolarmente la profondità massima della coda. Si consideri, ad esempio, un'applicazione che esegue il push di una profondità della coda di 2 e che sono presenti quattro dischi nello striping. Le due richieste di I/O vengono indirizzate a due dischi mentre gli altri due dischi rimangono inattivi. Configurare quindi la profondità della coda in modo che tutti i dischi possano essere occupati. La seguente formula illustra come determinare la profondità di coda dei volumi con striping.

Regolazione

L'archiviazione Premium effettua il provisioning di un numero specificato di operazioni di I/O al secondo e velocità effettiva a seconda delle dimensioni della macchina virtuale e dei dischi scelti. Ogni volta che l'applicazione tenta di gestire operazioni di I/O al secondo o velocità effettiva superiori a questi limiti, la macchina virtuale o il disco può gestire, l'archiviazione Premium la limita. Il risultato è una riduzione delle prestazioni nell'applicazione, che può comportare una latenza più elevata, una velocità effettiva inferiore o un numero inferiore di operazioni di I/O al secondo.

Se l'archiviazione premium non limita, l'applicazione potrebbe fallire completamente superando ciò che le sue risorse sono in grado di ottenere. Per evitare problemi di prestazioni a causa della limitazione, effettuare sempre il provisioning di risorse sufficienti per l'applicazione. Prendere in considerazione quanto illustrato nelle sezioni precedenti relative alle dimensioni delle macchine virtuali e alle dimensioni del disco. Il benchmarking è il modo migliore per individuare le risorse necessarie per ospitare l'applicazione.

Passaggi successivi

Per eseguire il benchmark del disco, vedere gli articoli seguenti:

• Per Linux: Eseguire il benchmark dell'applicazione in Archiviazione su disco di Azure
• Per Windows: Eseguire il benchmark di un disco

Altre informazioni sui tipi di disco disponibili:

• Per Linux: selezionare un tipo di disco
• Per Windows: selezionare un tipo di disco

Per gli utenti di SQL Server, vedere gli articoli sulle procedure consigliate per le prestazioni per SQL Server:

• Procedure consigliate per le prestazioni per SQL Server nelle macchine virtuali di Azure
• Archiviazione Premium di Azure offre prestazioni ottimali per SQL Server nella macchina virtuale di Azure