Archiviazione: procedure consigliate per le prestazioni per SQL Server nelle macchine virtuali Azure

Applies to:SQL Server su macchina virtuale di Azure

Questo articolo fornisce le procedure consigliate per l'archiviazione e le linee guida per ottimizzare le prestazioni per SQL Server in macchine virtuali di Azure. Informazioni su come selezionare i tipi di disco appropriati, configurare i pool di archiviazione e implementare strategie di memorizzazione nella cache per ottimizzare le prestazioni del database.

Vi è in genere un compromesso tra l'ottimizzazione per i costi e l'ottimizzazione per le prestazioni. Questa serie di procedure consigliate per le prestazioni è finalizzata a ottenere le migliori prestazioni per SQL Server nelle macchine virtuali di Azure. Se il carico di lavoro è contenuto, potrebbero non essere necessarie tutte le ottimizzazioni elencate di seguito. Prendere in considerazione le esigenze in termini di prestazioni, i costi e i modelli di carico di lavoro durante la valutazione di queste indicazioni.

Per altre informazioni, vedere gli altri articoli di questa serie: Elenco di controllo, Dimensioni della macchina virtuale, Sicurezza, Configurazione HADR e Raccolta dati di base.

Elenco di controllo

Esaminare l'elenco di controllo seguente per una breve panoramica delle procedure consigliate, illustrate nel resto dell'articolo in modo più dettagliato:

• Monitorare l'applicazione e determinare i requisiti di larghezza di banda e latenza dello storage per i dati, i log e i tempdb file di SQL Server prima di scegliere il tipo di disco.
• Se disponibile, configurare i file di dati e di log tempdb sul volume locale SSD D: quando si distribuisce una nuova macchina virtuale o dopo aver installato manualmente SQL Server. L'estensione SQL IaaS Agent gestisce la cartella e le autorizzazioni necessarie al momento del re-provisioning.
• Per ottimizzare le prestazioni di archiviazione, pianificare il numero massimo di IOPS non memorizzati nella cache disponibili e utilizzare la cache dei dati come funzione di ottimizzazione delle prestazioni per le operazioni di lettura dei dati, evitando di porre limiti alle macchine virtuali e ai dischi.
  • Imposta la memorizzazione nella cache host su sola lettura per i dischi dei file dati.
  • Impostare la memorizzazione nella cache host su nessun per i dischi dei file di log.
    • Non abilitare la memorizzazione nella cache di lettura/scrittura sui dischi che contengono i file di dati o di log di SQL Server.
    • Arrestare sempre il servizio SQL Server prima di modificare le impostazioni della cache del disco.
• Quando si utilizzano le macchine virtuali della serie Ebdsv5 o Ebsv5 di SQL Server, usare Premium SSD v2 per ottenere il miglior rapporto qualità-prezzo in termini di prestazioni. È possibile distribuire la macchina virtuale SQL Server con SSD Premium v2 usando il portale di Azure (attualmente in anteprima).
• Se il carico di lavoro richiede più di 160.000 operazioni di I/O al secondo, usare Premium SSD v2 o Azure Dischi Ultra.
• Posizionamento di dati, log e file tempdb in unità distinte.
  • Per l'unità dati, usare dischi Premium di tipo P30 e P40 o di dimensioni inferiori per garantire la disponibilità del supporto della cache. Quando si utilizza la serie Ebdsv5 di macchine virtuali, si consiglia di utilizzare Premium SSD v2, che offre un miglior rapporto qualità-prezzo per i carichi di lavoro che richiedono un alto numero di IOPS e un'elevata velocità di throughput di I/O.
  • Per il piano di unità di registro, valuta la capacità e il rapporto tra test delle prestazioni e costi, considerando dischi SSD Premium v2 o SSD Premium P30 - P80
    • Se è necessaria la latenza di archiviazione submillisecondo, usare Premium SSD v2 o Dischi Ultra di Azure per il log delle transazioni.
    • Per le distribuzioni di macchine virtuali serie M, considerare di utilizzare write accelerator anziché Azure Ultra Disks.
  • Posizionare tempdb nel disco temporary (il disco temporaneo è temporaneo e il valore predefinito è D:\) per la maggior parte dei carichi di lavoro SQL Server che non fanno parte di un'istanza del cluster di failover dopo aver scelto le dimensioni ottimali della macchina virtuale.
    • Se la capacità dell'unità locale non è sufficiente per tempdb, valutare la possibilità di ridimensionare la VM. Per maggiori informazioni, consultare i criteri di memorizzazione nella cache dei file di dati.
  • Per le istanze del cluster di failover (FCI) posizionare tempdb nell'archiviazione condivisa.
    • Se il carico di lavoro dell'FCI dipende in larga misura dalle prestazioni del disco tempdb, allora, come configurazione avanzata, posiziona tempdb sull'unità SSD temporanea locale (predefinita D:\), che non fa parte dell'archiviazione dell'FCI. Questa configurazione richiede un monitoraggio e un'azione personalizzati per garantire che l'unità SSD locale temporanea (predefinita D:\) sia sempre disponibile, poiché eventuali guasti di questa unità non attiverebbero azioni dall'FCI.
• Eseguire lo striping di più dischi dati Azure usando Storage Spaces per aumentare la larghezza di banda I/O fino ai limiti di IOPS e throughput della macchina virtuale di destinazione.
• Quando si esegue la migrazione di diversi carichi di lavoro nel cloud, Azure Elastic SAN può essere una soluzione di archiviazione consolidata conveniente. Tuttavia, quando si usa Azure Elastic SAN, il raggiungimento delle IOPS o della velocità effettiva desiderata per i carichi di lavoro SQL Server spesso richiede un sovradimensionamento della capacità. Anche se in genere non è appropriato per singoli carichi di lavoro SQL Server, è possibile ottenere una soluzione conveniente quando si combinano carichi di lavoro a prestazioni ridotte con SQL Server.
• Per i carichi di lavoro di sviluppo e test e l'archiviazione dei backup a lungo termine è consigliabile usare l'archiviazione standard. Non è consigliabile usare HDD/SSD Standard per i carichi di lavoro di produzione.
• Il bursting del disco basato sui crediti (P1-P20) andrebbe considerato solo per piccoli carichi di lavoro di sviluppo/test e sistemi di reparto.
• Formattare il disco dati per usare le dimensioni delle unità di allocazione da 64 KB per tutti i file di dati inseriti in un'unità diversa dall'unità temporanea D:\ (con un valore predefinito di 4 KB). Le macchine virtuali SQL Server distribuite tramite Azure Marketplace vengono fornite con dischi dati formattati con una dimensione dell'unità di allocazione e un'interleave per il pool di archiviazione impostati su 64 KB.
• Configurare l'account di archiviazione nella stessa area della macchina virtuale SQL Server.
• Disabilitare l'archiviazione con ridondanza geografica di Azure (replica geografica) e usare LRS (archiviazione con ridondanza locale) nell'account di archiviazione.
• Abilitare la valutazione delle procedure consigliate SQL per identificare i possibili problemi di prestazioni e valutare che la macchina virtuale SQL Server sia configurata per seguire le procedure consigliate.
• Esamina e monitora i limiti di disco e delle VM utilizzando le metriche di utilizzo di I/O per l'archiviazione.
• Escludi i file di SQL Server dall'analisi del software antivirus, inclusi file di dati, file di log e file di backup.
• Ridimensionare il pool di archiviazione in modo appropriato.

Per confrontare la lista di controllo con le altre migliori pratiche, consultare l'Elenco di controllo delle migliori pratiche per le prestazioni.

Panoramica

Per trovare la configurazione più efficace per i carichi di lavoro SQL Server in una macchina virtuale Azure, iniziare assurando le prestazioni di archiviazione dell'applicazione aziendale. Dopo aver appreso i requisiti di archiviazione, selezionare una macchina virtuale che supporti gli IOPS e il throughput necessari con il rapporto memoria-vCore appropriato.

Scegliere una dimensione di macchina virtuale con scalabilità di archiviazione sufficiente per il carico di lavoro e una combinazione di dischi (in genere in un pool di archiviazione) che soddisfi i requisiti di capacità e prestazioni dell'azienda.

Il tipo di disco dipende sia dal tipo di file che ospita il disco che dai requisiti di prestazioni massimi.

Tipi di dischi per la VM

È possibile scegliere il livello di prestazioni per i dischi. I tipi di dischi gestiti disponibili come risorsa di archiviazione sottostante, elencate da funzionalità di prestazioni crescenti, sono unità disco rigido Standard (HDD), unità SSD Standard(SSD), SSD Premium, SSD Premium v2 e Dischi Ultra.

Per unità HDD Standard, SSD Standard e SSD Premium, le prestazioni del disco aumentano con le dimensioni del disco. I dischi sono raggruppati per etichette disco Premium, ad esempio P1 con 4 GiB di spazio e 120 operazioni di I/O al secondo per P80 con 32 TiB di archiviazione e 20.000 operazioni di I/O al secondo. Archiviazione Premium supporta una cache di archiviazione che consente di migliorare le prestazioni di lettura e scrittura per alcuni carichi di lavoro. Per altre informazioni, vedere Panoramica del servizio Managed Disks.

È possibile modificare le prestazioni dei dischi SSD Premium v2 e Ultra indipendentemente dalle dimensioni del disco. Per informazioni dettagliate, vedere Prestazioni del disco Ultra e Prestazioni ssd Premium v2. Se il carico di lavoro richiede più di 160.000 operazioni di I/O al secondo, prendere in considerazione l'uso di dischi SSD Premium v2 o Ultra.

Per SQL Server nella macchina virtuale di Azure, prendere in considerazione i tre ruoli principali del disco , ovvero un disco del sistema operativo, un disco temporaneo e i dischi dati. Scegliere con attenzione ciò che si archivia nell'unità (C:\) del sistema operativo e nell'unità (D:\) temporanea.

Disco del sistema operativo

Un disco del sistema operativo è un disco rigido virtuale che è possibile avviare e montare come versione in esecuzione di un sistema operativo. Viene etichettata come unità C:\. Quando si crea una macchina virtuale Azure, la piattaforma collega almeno un disco alla macchina virtuale per il disco del sistema operativo. L'unità C:\ è il percorso predefinito per le installazioni delle applicazioni e la configurazione dei file.

Per gli ambienti SQL Server di produzione, non usare il disco del sistema operativo per i file di dati, i file di log o i log degli errori.

Disco temporaneo

Molte macchine virtuali di Azure contengono un altro tipo di disco denominato disco temporaneo, etichettato come D:\ unità. A seconda della serie e delle dimensioni della macchina virtuale, la capacità del disco varia. Il disco temporaneo è temporaneo, ovvero l'archiviazione su disco viene ricreata (deallocata e allocata di nuovo) quando la macchina virtuale viene riavviata o si sposta in un host diverso. Questo processo può verificarsi durante la riparazione del servizio.

L'unità di archiviazione temporanea non viene mantenuta nell'archiviazione remota. Pertanto, non archiviare i file di database utente, i file di log delle transazioni o qualsiasi elemento che deve essere mantenuto in questa unità. Ad esempio, è possibile usarla per le estensioni del pool di buffer, il file di pagina e tempdb.

Posizionare tempdb nell'unità SSD temporanea locale D:\ per i carichi di lavoro SQL Server, a meno che l'utilizzo della cache locale non sia un problema. Se si utilizza una macchina virtuale che non dispone di un disco temporaneo, posizionare tempdb su un disco isolato o un pool di archiviazione con la cache impostata su sola lettura. Per altre informazioni, vedere Criteri di memorizzazione nella cache dei dati tempdb.

Dischi dati

I dischi dati sono dischi di archiviazione remota creati spesso nei pool di archiviazione per superare la capacità e le prestazioni offerte da qualsiasi singolo disco alla macchina virtuale.

Collegare il numero minimo di dischi che soddisfano i requisiti di IOPS (operazioni di I/O al secondo), larghezza di banda e capacità del carico di lavoro. Non superare il numero massimo di dischi dati della macchina virtuale più piccola in cui si prevede di ridimensionare.

Inserire i file di dati e di log nei dischi dati di cui si esegue il provisioning in base ai requisiti di prestazioni ottimali.

Formattare il disco dati per usare le dimensioni delle unità di allocazione da 64 KB per tutti i file di dati inseriti in un'unità diversa dall'unità temporanea D:\ (con un valore predefinito di 4 KB). Le macchine virtuali SQL Server distribuite tramite Azure Marketplace vengono fornite con dischi dati formattati con una dimensione dell'unità di allocazione e un'interleave per il pool di archiviazione impostati su 64 KB.

SSD Premium v2

Usare dischi SSD Premium v2 quando si eseguono carichi di lavoro di SQL Server in aree supportate, se le limitazioni correnti sono adatte per l'ambiente in uso. A seconda della configurazione, l'unità SSD Premium v2 può essere più economica rispetto alle unità SSD Premium, fornendo anche miglioramenti delle prestazioni. Usando SSD Premium v2, è possibile regolare singolarmente la velocità effettiva o le operazioni di I/O al secondo in modo indipendente dalle dimensioni del disco. La possibilità di regolare singolarmente le opzioni di prestazioni consente un risparmio più elevato sui costi e consente di creare script per soddisfare i requisiti di prestazioni durante i periodi di necessità previsti o noti.

Usare SSD Premium v2 quando si usa la serie di macchine virtuali Ebdsv5 o Ebsv5 perché è una soluzione più conveniente per questi computer con velocità effettiva di I/O elevata. Se il carico di lavoro richiede più di 160.000 operazioni di I/O al secondo, prendere in considerazione l'uso di dischi SSD Premium v2 o Ultra.

È possibile distribuire le macchine virtuali SQL Server con SSD Premium v2 usando il portale di Azure (attualmente in anteprima).

Se si distribuisce la macchina virtuale SQL Server usando il portale di Azure e si vuole usare SSD Premium v2, attualmente si è limitati alle macchine virtuali Ebdsv5 o Ebsv5. Tuttavia, se si crea manualmente la macchina virtuale con archiviazione SSD Premium v2 e quindi si installano manualmente SQL Server nella macchina virtuale, è possibile usare qualsiasi serie di macchine virtuali che supporti l'unità SSD Premium v2. Assicurati di registrare la macchina virtuale SQL Server con l'estensione SQL IaaS Agent in modo da poter sfruttare tutti i vantaggi forniti dall'estensione.

Azure Elastic SAN

San elastico di Azure è un'offerta di archiviazione collegata alla rete che offre una soluzione flessibile e scalabile con il potenziale per ridurre i costi tramite il consolidamento dell'archiviazione. Azure Elastic SAN offre una soluzione di archiviazione a blocchi conveniente, efficiente e affidabile che si connette a un'ampia gamma di servizi di calcolo Azure tramite protocollo iSCSI. Elastic SAN consente una transizione senza interruzioni da un ambiente di archiviazione SAN esistente al cloud senza dover effettuare il refactoring dell'architettura dell'applicazione.

Questa soluzione può ottenere una scalabilità fino a milioni di IOPS, velocità effettiva di decine di GB/s e latenze di pochi millisecondi, con resilienza integrata per ridurre al minimo i tempi di inattività. Usare Azure Elastic SAN se è necessario consolidare l'archiviazione, usare più servizi di calcolo o avere carichi di lavoro che richiedono livelli di velocità effettiva elevati quando si guida l'archiviazione sulla larghezza di banda di rete. Tuttavia, poiché il raggiungimento delle operazioni di I/O al secondo e la velocità effettiva desiderate per i carichi di lavoro di SQL Server spesso richiedono capacità di overprovisioning, in genere non è appropriato per singoli carichi di lavoro di SQL Server. Per ottenere la soluzione più conveniente con SAN elastico, è consigliabile usarla come risorsa di archiviazione per più carichi di lavoro di SQL Server o una combinazione di SQL Server e altri carichi di lavoro a prestazioni ridotte.

Prendere in considerazione l'inserimento di carichi di lavoro SQL Server sulla SAN elastica per migliorare l'efficienza dei costi, il consolidamento dell'archiviazione, la condivisione dinamica delle prestazioni e aumentare la velocità effettiva di archiviazione.

SSD Premium

Usare unità SSD Premium per i file di dati e di log per i carichi di lavoro di produzione SQL Server. Le operazioni di I/O al secondo e la larghezza di banda SSD Premium variano in base alle dimensioni e al tipo di disco.

Per i carichi di lavoro di produzione, usare i dischi P30 e P40 per i file di dati di SQL Server per garantire il supporto della memorizzazione nella cache e usare P30 fino a P80 per i file di log delle transazioni di SQL Server. Per il costo totale di proprietà ottimale, iniziare con P30s (5.000 IOPS/200 MBps) per i file di dati e di log e scegliere solo capacità superiori quando è necessario controllare il numero di dischi delle macchine virtuali. Per i sistemi di sviluppo/test o di piccole dimensioni è possibile scegliere di usare dimensioni inferiori a P30 perché questi dischi supportano la memorizzazione nella cache, ma non offrono prezzi riservati.

Per i carichi di lavoro OLTP, allineare le IOPS (operazioni di input/output al secondo) desiderate per disco (o pool di archiviazione) con i requisiti di prestazioni utilizzando carichi di lavoro nei momenti di picco e i contatori delle prestazioni Disk Reads/sec + Disk Writes/sec. Per i carichi di lavoro del data warehouse e dei report, adattare il throughput di destinazione utilizzando i carichi di lavoro durante i periodi di picco e Disk Read Bytes/sec + Disk Write Bytes/sec.

Usare Spazi di archiviazione per ottenere prestazioni ottimali, configurare due pool, uno per i file di log e l'altro per i file di dati. Se non si usa lo striping del disco, usare due UNITÀ SSD Premium mappate a unità separate, in cui un'unità contiene il file di log e l'altra contiene i dati.

Le operazioni di I/O al secondo con provisioning e la velocità effettiva per disco determinano la funzionalità complessiva del pool di archiviazione. Le capacità combinate di IOPS e throughput dei dischi rappresentano la capacità massima nei limiti di throughput della macchina virtuale.

Usare il minor numero di dischi possibili, soddisfando i requisiti minimi per operazioni di I/O al secondo, velocità effettiva e capacità. Tuttavia, il bilanciamento del prezzo e delle prestazioni tende ad essere migliore con un numero elevato di dischi di piccole dimensioni anziché un numero ridotto di dischi di grandi dimensioni.

Ridimensionare i dischi Premium

Le dimensioni dell'unità SSD Premium determinano il livello di prestazioni iniziale del disco. Il livello di prestazioni può essere modificato in fase di distribuzione o successivamente, senza modificare le dimensioni del disco. Se la domanda aumenta, aumentare il livello di prestazioni per soddisfare le esigenze aziendali.

Modificando il livello di prestazioni, è possibile prepararsi e soddisfare una domanda più elevata senza basarsi sul bursting del disco.

Usare le prestazioni più elevate per il tempo necessario. La fatturazione è progettata per soddisfare il livello di prestazioni di archiviazione. Aggiornare il livello in modo che corrisponda ai requisiti di prestazioni senza aumentare la capacità. Tornare al livello originale quando le prestazioni aggiuntive non sono più necessarie.

Questa espansione temporanea e conveniente delle prestazioni è un caso d'uso efficace per eventi mirati, ad esempio shopping, test delle prestazioni, eventi di training e altre brevi finestre in cui sono necessarie prestazioni maggiori solo per un breve periodo di tempo.

Per altre informazioni, vedere Livelli di prestazioni dei dischi gestiti.

Disco Ultra di Azure

Se sono necessari tempi di risposta di sottomillisecondi con una latenza ridotta, è consigliabile usare il disco Ultra di Azure per l'unità di log di SQL Server o anche l'unità dati per le applicazioni estremamente sensibili alla latenza di I/O.

È possibile configurare il disco Ultra in modo che la capacità e le operazioni di I/O al secondo siano ridimensionate in modo indipendente. Usando il disco Ultra, è possibile effettuare il provisioning di un disco con la capacità, le operazioni di I/O al secondo e i requisiti di velocità effettiva in base alle esigenze dell'applicazione.

Il disco Ultra non è supportato in tutte le serie di macchine virtuali e presenta altre limitazioni, ad esempio la disponibilità dell'area, la ridondanza e il supporto per Azure Backup. Per altre informazioni, vedere Using Azure Ultra Disks per un elenco completo delle limitazioni.

HDD standard e SSD

Le unità SSD e le unità SSD Standard hanno latenze e larghezza di banda variabili. Usarli solo per carichi di lavoro di sviluppo/test. Usare SSD Premium v2 o SSD Premium per carichi di lavoro produttivi. Se si usa SSD Standard (scenari di sviluppo/test), aggiungere il numero massimo di dischi dati supportati dalle dimensioni della macchina virtuale e usare lo striping del disco usando Spazi di archiviazione per ottenere prestazioni ottimali.

Cache

Le macchine virtuali che supportano la memorizzazione nella cache dello storage Premium possono usare BlobCache di Azure o la memorizzazione nella cache dell'host per aumentare le capacità di IOPS e la larghezza di banda delle macchine virtuali. Le macchine virtuali abilitate sia per l'archiviazione Premium che per la memorizzazione nella cache dell'archiviazione Premium usano questi due limiti di larghezza di banda di archiviazione diversi insieme per migliorare le prestazioni di archiviazione.

La velocità effettiva di IOPS e MBps senza memorizzazione nella cache incide sui limiti di velocità effettiva dei dischi non memorizzati nella cache di una macchina virtuale. I limiti massimi memorizzati nella cache forniscono un altro buffer per le letture che consentono di risolvere picchi imprevisti e di crescita.

Abilitare la memorizzazione nella cache Premium ogni volta che l'opzione è supportata per migliorare significativamente le prestazioni per le letture sull'unità dati senza costi aggiuntivi.

Le letture e le scritture nei Azure BlobCache (operazioni di I/O al secondo e velocità effettiva memorizzate nella cache) non vengono conteggiate rispetto ai limiti di IOPS e velocità effettiva non memorizzati nella cache della macchina virtuale.

Velocità effettiva massima senza memorizzazione nella cache

Il numero massimo di operazioni di I/O al secondo e velocità effettiva del disco non memorizzato nella cache è il limite massimo di archiviazione remoto che la macchina virtuale può gestire. Questo limite viene definito alla macchina virtuale e non è un limite dell'archiviazione su disco sottostante. Questo limite si applica solo all'I/O rispetto alle unità dati collegate in remoto alla macchina virtuale, non all'I/O locale rispetto all'unità temporanea (unità D:\) o all'unità del sistema operativo.

È possibile verificare la quantità di operazioni di I/O al secondo non memorizzate nella cache e la velocità effettiva disponibili per una macchina virtuale nella documentazione per la macchina virtuale.

Ad esempio, la documentazione della serie M mostra che la velocità effettiva massima non memorizzata nella cache per la macchina virtuale Standard_M8ms è di 5.000 operazioni di I/O al secondo e 125 MBps di velocità effettiva del disco non memorizzato nella cache.

Analogamente, è possibile notare che lo Standard_M32ts supporta 20.000 IOPS di disco non in cache e un throughput di disco non in cache di 500 MBps. Questo limite è regolato a livello di macchina virtuale indipendentemente dall'archiviazione su disco Premium sottostante.

Per altre informazioni, vedere Limiti di memorizzazione e non memorizzazione nella cache.

Velocità effettiva di archiviazione temporanea e nella cache

Il limite massimo di throughput dello storage temporaneo e della memorizzazione nella cache è un limite separato dal limite di throughput non memorizzato nella cache sulla macchina virtuale. BlobCache di Azure usa una combinazione della memoria ad accesso casuale dell'host della macchina virtuale e dell'unità SSD collegata localmente. L'unità temporanea (D:\ unità) nella macchina virtuale utilizza anche questa SSD locale.

Il limite massimo di throughput della memorizzazione nella cache e archiviazione temporanea controlla l'I/O sul disco temporaneo locale (D:\ drive) e sul Azure BlobCache solo se la memorizzazione nella cache dell'host è abilitata.

Quando si abilita il caching nell'archiviazione Premium, le macchine virtuali possono essere ridimensionate oltre i limiti di IOPS e di velocità effettiva delle macchine virtuali senza cache.

È necessario verificare nella documentazione della macchina virtuale che una macchina virtuale supporti sia l'archiviazione Premium che la memorizzazione nella cache dell'archiviazione Premium. Ad esempio, la documentazione della serie M indica che supporta sia l'archiviazione Premium sia la memorizzazione nella cache della stessa.

I limiti della cache variano in base alle dimensioni della macchina virtuale. Ad esempio, la macchina virtuale Standard_M8ms supporta 10.000 operazioni di I/O al secondo del disco memorizzate nella cache e 100 MBps con una dimensione totale della cache di 793 GiB. Analogamente, la macchina virtuale Standard_M32ts supporta 40.000 operazioni di I/O al secondo del disco memorizzate nella cache e 400 MBps con una dimensione totale della cache di 3.174 GiB.

È possibile abilitare manualmente la memorizzazione nella cache dell'host in una macchina virtuale esistente. Arrestare tutti i carichi di lavoro dell'applicazione e i servizi di SQL Server prima di apportare modifiche ai criteri di memorizzazione nella cache della macchina virtuale. La modifica di una delle impostazioni della cache della macchina virtuale scollega il disco di destinazione e quindi la ricollega dopo l'applicazione delle impostazioni.

Criteri di memorizzazione nella cache dei file di dati

La politica di memorizzazione nella cache dell'archiviazione varia a seconda del tipo di file di dati di SQL Server ospitati dall'unità.

Nella tabella seguente viene fornito un riepilogo dei criteri di memorizzazione nella cache consigliati in base al tipo di dati SQL Server:

Per altre informazioni, vedere Memorizzazione nella cache del disco.

Ripartizione dei dati su disco

Analizzare la velocità effettiva e la larghezza di banda necessari per i file di dati SQL per determinare il numero di dischi dati, inclusi il file di log e tempdb. I limiti di produttività e bandwidth variano in base alle dimensioni della VM. Per altre informazioni, vedere Dimensioni delle macchine virtuali.

Per ottenere una maggiore velocità di trasferimento, è possibile aggiungere più dischi dati e usare lo striping dei dischi. Ad esempio, un'applicazione che richiede 12.000 operazioni di I/O al secondo e una velocità effettiva di 180 MB/s può usare tre dischi P30 con striping per fornire 15.000 operazioni di I/O al secondo e una velocità effettiva di 600 MB/s.

Per configurare lo striping del disco, vedere striping del disco.

Limite massimo del disco

Sia il disco che la macchina virtuale hanno limiti di velocità effettiva. I limiti massimi di operazioni di I/O al secondo per macchina virtuale e per disco differiscono e funzionano in modo indipendente.

Il sistema limita (o rallenta) le applicazioni che consumano risorse oltre questi limiti. Selezionare una VM e una dimensione del disco in uno stripe che soddisfi i requisiti dell'applicazione ed eviti limitazioni del cappaggio. Per risolvere il limite, usare la memorizzazione nella cache o ottimizzare l'applicazione in modo che richieda una velocità effettiva inferiore.

Ad esempio, un'applicazione che richiede 12.000 operazioni di I/O al secondo e 180 MB/s può:

• Usare la Standard_M32ms, con una velocità effettiva massima del disco non memorizzata nella cache di 20.000 IOPS e 500 MBps.
• Esegui lo striping di tre dischi P30 per ottenere 15.000 IOPS e una velocità di trasferimento di 600 MB/s.
• Utilizzare una macchina virtuale Standard_M16ms e sfruttare la memorizzazione nella cache dell'host per privilegiare la cache locale rispetto al consumo di larghezza di banda.

Configurare le macchine virtuali per aumentare le prestazioni durante i periodi di utilizzo elevato. Effettuare il provisioning dello storage con IOPS e velocità effettiva sufficienti per supportare la dimensione massima della macchina virtuale, assicurandosi che il numero complessivo di dischi sia minore o uguale al numero massimo supportato dallo SKU di macchina virtuale più piccolo da usare.

Per altre informazioni sulle limitazioni relative al limite del disco e sull'uso della memorizzazione nella cache per evitare il limite, vedere Limite di I/O del disco.

Accelerazione della scrittura

L'accelerazione della scrittura è una funzionalità del disco disponibile solo per le macchine virtuali serie M . Lo scopo dell'accelerazione della scrittura è migliorare la latenza di I/O delle scritture in Archiviazione Premium di Azure quando è necessaria una latenza di I/O a cifra singola a causa di carichi di lavoro OLTP cruciali o ambienti di data warehouse con volumi elevati.

Usare l'acceleratore di scrittura per migliorare la latenza di scrittura nell'unità che ospita i file di log. Non usare Write Acceleration per i file di dati di SQL Server.

I dischi dell'acceleratore di scrittura condividono lo stesso limite di operazioni di I/O al secondo della macchina virtuale. I dischi collegati non possono superare il limite di operazioni di I/O al secondo dell'acceleratore di scrittura per una macchina virtuale.

La tabella seguente illustra il numero di dischi dati e operazioni di I/O al secondo supportate per ogni macchina virtuale:

Esistono diverse restrizioni per l'uso dell'acceleratore di scrittura. Per altre informazioni, vedere Restrizioni quando si usa l'acceleratore di scrittura.

Rispetto a Ultra Disk di Azure

La differenza principale tra accelerazione scrittura e Azure dischi Ultra è che l'accelerazione di scrittura è una funzionalità di macchina virtuale disponibile solo per la serie M e Azure dischi Ultra è un'opzione di archiviazione. L'acceleratore di scrittura è una cache ottimizzata per la scrittura con limitazioni proprie in base alle dimensioni della macchina virtuale. Azure i dischi Ultra sono un'opzione di archiviazione su disco a bassa latenza per le macchine virtuali Azure.

Se possibile, usare l'accelerazione di scrittura su dischi Ultra per il disco del log delle transazioni. Per le macchine virtuali che non supportano l'accelerazione di scrittura, ma richiedono bassa latenza per il log delle transazioni, usare Azure dischi Ultra.

Ridimensionare i pool di archiviazione in modo appropriato

In Azure ridimensionare un pool di archiviazione modificando il numero di dischi nel pool. Non modificare le dimensioni dei dischi già presenti nel pool. La modifica delle dimensioni dei dischi virtuali o fisici in un pool di archiviazione non aumenta lo spazio disponibile del volume quando si trova all'interno del pool di archiviazione. Lo spazio su disco aggiuntivo è inutilizzato e sprecato.

Per SQL Server in macchine virtuali di Azure con dischi SSD Premium (v1) distribuiti da Azure Marketplace, la distribuzione aggiunge automaticamente i dischi al pool di archiviazione. Usare il riquadro Archiviazione della risorsa macchine virtuali SQL nel portale di Azure per ridimensionare i dischi nel pool di archiviazione.

Per le immagini di SQL Server in Azure VM Marketplace che usano dischi SSD Premium v2 o Dischi Ultra o per le macchine virtuali con istanze di SQL Server installate automaticamente, modificare manualmente il numero di dischi nel pool di archiviazione per modificare le dimensioni del volume.

Per espandere un pool di archiviazione, seguire questa procedura:

1. Aggiungere un nuovo disco:
   1. Collega un disco gestito nel portale Azure
   2. Collegare un disco gestito con PowerShell
   3. Collegare un disco non gestito con PowerShell
2. Connettersi alla macchina virtuale.
3. Aggiungere i dischi al pool di archiviazione da Server Manager> File e Servizi di archiviazione > Volumi > Pool di archiviazione. Usare Attività per selezionare l'opzione Aggiungi disco fisico .
4. Dopo aver aggiunto il disco, fare clic con il pulsante destro del mouse sul disco virtuale di destinazione e selezionare Estendi disco virtuale.
5. Aprire Gestione disco, fare clic con il pulsante destro del mouse sul volume di destinazione e scegliere Estendi volume.

Monitorare le prestazioni dell'archiviazione

Per valutare le esigenze di archiviazione e determinare le prestazioni dell'archiviazione, è necessario comprendere cosa misurare e cosa significano tali indicatori.

Le dimensioni delle unità di I/O influenzano le capacità di IOPS (operazioni di input/output al secondo) e la velocità effettiva. Le dimensioni di I/O inferiori generano IOPS superiori e dimensioni di I/O maggiori generano una velocità di trasferimento più elevata. SQL Server sceglie automaticamente le dimensioni di I/O ottimali. Per altre informazioni, vedere Ottimizzare operazioni di I/O al secondo, velocità effettiva e latenza per le applicazioni.

Le metriche specifiche di Monitoraggio di Azure sono preziose per l'individuazione del limite a livello di macchina virtuale e disco, nonché per l'utilizzo e l'integrità della cache AzureBlob. Per identificare i contatori chiave da aggiungere alla soluzione di monitoraggio e al dashboard del portale di Azure, consultare le metriche di utilizzo di archiviazione.

Monitorare lo sviluppo del log delle transazioni

Poiché un log delle transazioni completo può causare problemi di prestazioni e interruzioni, monitorare lo spazio disponibile nel log delle transazioni e lo spazio su disco utilizzato dell'unità che contiene il log delle transazioni. Risolvere i problemi del log delle transazioni prima che influiscano sul carico di lavoro.

Si veda Risolvere i problemi relativi a un log delle transazioni completo se il log diventa pieno.

Se è necessario estendere il disco, è possibile farlo nel riquadro di archiviazione della risorsa macchine virtuali SQL se è stata creata un'immagine SQL Server da Azure Marketplace, oppure nel riquadro Dischi per la macchina virtuale Azure e SQL Server installato autonomamente.

Contenuti correlati

Per indicazioni dettagliate su ogni area di ottimizzazione:

• Elenco di controllo rapido : esaminare l'elenco di controllo completo per le procedure consigliate
• Dimensioni macchina virtuale : scegliere la serie e la configurazione della macchina virtuale appropriate
• Sicurezza - Implementare le procedure consigliate per la sicurezza
• Impostazioni HADR - Configurare la disponibilità elevata e il ripristino di emergenza
• Raccogliere linee di riferimento - Stabilire linee di riferimento delle prestazioni
• Aggiornamento di SQL Server - Mantenere SQL Server aggiornato

Per un test dettagliato delle prestazioni di SQL Server nelle macchine virtuali Azure con benchmark TPC-E e TPC_C, vedere il blog Optimize OLTP performance.

Consulta altri articoli sulle macchine virtuali di SQL Server alla pagina Panoramica di SQL Server su Azure Virtual Machines. Per domande sulle macchine virtuali SQL Server, vedere le Domande frequenti.