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

Si applica a: SQL Server su VM di Azure

Questo articolo fornisce procedure consigliate e linee guida per l'archiviazione per ottimizzare le prestazioni di SQL Server in Macchine Virtuali (VM) di Azure.

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, è incentrata sull'ottenimento delle migliori prestazioni per SQL Server in 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, log e i file tempdb di SQL Server prima di scegliere il tipo di disco.
• Se disponibile, configurare i file di dati e i file di log nel volume SSD locale D: di tempdb. L'estensione SQL IaaS Agent gestisce la cartella e le autorizzazioni necessarie al momento del re-provisioning.
• Per ottimizzare le prestazioni di archiviazione, pianificare le operazioni di I/O al secondo non memorizzate più elevate disponibili e usare la memorizzazione nella cache dei dati come funzionalità di prestazioni per le letture dei dati evitando il limite massimo di macchine virtuali e dischi.
• Quando si utilizzano macchine virtuali SQL Server serie Ebdsv5 o Ebsv5, usare SSD Premium v2 per ottenere prestazioni ottimali. È possibile implementare le macchine virtuali di SQL Server con SSD Premium v2 utilizzando il portale di Azure (attualmente in anteprima).
• 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 usa la serie di macchine virtuali Ebdsv5, usare SSD Premium v2 che offre prestazioni migliori per i carichi di lavoro che richiedono un numero elevato di operazioni di I/O al secondo e velocità effettiva di I/O.
  • Per il piano di unità di log per la capacità e il test delle prestazioni rispetto ai costi, durante la valutazione di dischi SSD Premium v2 o SSD Premium P30 - P80
    • Se è necessaria una latenza di archiviazione inferiore ad un millisecondo, usare dischi SSD Premium v2 o Azure ultra per il log delle transazioni.
    • Per le distribuzioni di macchine virtuali serie M, è consigliabile usare l'acceleratore di scrittura rispetto all'uso di dischi Ultra di Azure.
  • Posizionare tempdb sul disco temporaneo (il disco temporaneo è effimero e il valore predefinito è D:\) per la maggior parte dei carichi di lavoro di SQL Server che non fanno parte di un'istanza del cluster di failover (FCI) 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 nella risorsa di archiviazione condivisa.
    • Se il carico di lavoro dell'istanza del cluster di failover dipende in larga misura dalle prestazioni del disco tempdb, come posizione di configurazione avanzata tempdb nell'unità SSD temporanea locale (predefinita D:\), che non fa parte dell'archiviazione dell'istanza del cluster di failover. Questa configurazione richiede il monitoraggio e l'azione personalizzati per assicurarsi che l'unità SSD temporanea locale (predefinita D:\) sia sempre disponibile, in quanto eventuali errori di questa unità non attiverebbero l'azione dall'istanza del cluster di failover.
• Usare Spazi di archiviazione per eseguire lo striping di più dischi dati di Azure e aumentare la larghezza di banda di I/O fino alle operazioni di I/O al secondo della macchina virtuale di destinazione e ai limiti di velocità effettiva.
• Impostare la memorizzazione nella cache host in sola lettura per i dischi dei file di dati.
• Impostare la memorizzazione nella cache host su nessuno per i dischi dei file di resoconto.
  • Non abilitare la memorizzazione nella cache di lettura/scrittura nei dischi che contengono file di log o dati di SQL Server.
  • Arrestare sempre il servizio SQL Server prima di modificare le impostazioni della cache del disco.
• Quando si esegue la migrazione di diversi carichi di lavoro al cloud, SAN di Elastic in Azure può essere una soluzione di archiviazione consolidata conveniente. Tuttavia, quando si usa la SAN di Elastic in Azure, il raggiungimento delle operazioni di I/O al secondo/velocità effettiva desiderate per i carichi di lavoro di SQL Server spesso richiede una capacità di overprovisioning. Sebbene non sia in genere appropriato per singoli carichi di lavoro di SQL Server, è possibile ottenere una soluzione conveniente combinando 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) deve essere considerato solo per carichi di lavoro di sviluppo/test più piccoli e sistemi di reparto.
• Per ottimizzare le prestazioni di archiviazione, pianificare le operazioni di I/O al secondo non memorizzate più elevate disponibili e usare la memorizzazione nella cache dei dati come funzionalità di prestazioni per le letture dei dati evitando il ‭limite massimo di macchine virtuali e dischi‭.
• 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 di SQL Server distribuite tramite Azure Marketplace sono dotate di dischi dati formattati con dimensioni dell'unità di allocazione e interleave per il pool di archiviazione impostato su 64 KB.
• Configurare l'account di archiviazione nella stessa area della VM SQL Server.
• Disabilitare l'archiviazione con ridondanza geografica (replica geografica) e usare LRS (archiviazione ridonante locale) nell'account di archiviazione.
• Abilitare la valutazione delle procedure consigliate di SQL per identificare i possibili problemi di prestazioni e valutare che la macchina virtuale di SQL Server sia configurata secondo le procedure consigliate.
• Esaminare e monitorare i limiti dei dischi e delle macchine virtuali usando le metriche di utilizzo di I/O di Archiviazione.
• Escludere i file di SQL Server dall'analisi software antivirus, inclusi file di dati, file di log e file di backup.

Per confrontare l'elenco di controllo con le altre procedure consigliate, vedere Elenco di controllo delle procedure consigliate per le prestazioni.

Panoramica

Per trovare la configurazione più efficace per i carichi di lavoro di SQL Server in una macchina virtuale di Azure, iniziare misurando le prestazioni di archiviazione dell'applicazione aziendale. Una volta noti i requisiti di archiviazione, selezionare una macchina virtuale che supporti le operazioni di I/O al secondo e la velocità effettiva necessarie con il rapporto appropriato tra memoria e vCore.

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 soddisfano i requisiti di capacità e prestazioni dell'azienda.

Il tipo di disco dipende sia dal tipo di file ospitato sul 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à a stato solido 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, raggruppate per etichette disco Premium, ad esempio P1 con 4 GiB di spazio e 120 operazioni di I/O al secondo fino a 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.

Le prestazioni dei dischi SSD Premium v2 e Ultra possono essere modificate indipendentemente dalle dimensioni del disco. Per informazioni dettagliate, vedere Prestazioni del disco Ultra e prestazioni SSD Premium v2.

Esistono anche tre ruoli principali del disco da considerare per SQL Server nella macchina virtuale di Azure: un disco del sistema operativo, un disco temporaneo e i dischi dati. Scegliere con attenzione ciò che viene archiviato nell'unità del sistema operativo (C:\) e nell'unità effimera temporanea (D:\).

Disco del sistema operativo

Il disco del sistema operativo è un disco rigido virtuale che può essere avviato e montato come versione in esecuzione di un sistema operativo ed è etichettato come unità C:\. Quando si crea una macchina virtuale di Azure, la piattaforma associa almeno un disco alla macchina virtuale per il disco del sistema operativo. L'unità C:\ è il percorso predefinito per le installazioni dell'applicazione e la configurazione dei file.

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

Disco temporaneo

Molte macchine virtuali di Azure contengono un altro disco, chiamato disco temporaneo, contrassegnato come unità D:\. A seconda della serie di macchine virtuali e delle dimensioni, la capacità del disco varia. Il disco temporaneo è effimero, il che significa che l'archiviazione su disco viene ricreata (viene deallocata e allocata di nuovo), quando la macchina virtuale viene riavviata o spostata in un host diverso (ad esempio per la correzione del servizio).

L'unità di archiviazione temporanea non viene salvata in modo permanente nell'archiviazione remota, pertanto non deve archiviare file di database utente, file di log delle transazioni o elementi che devono essere conservati. Ad esempio, è possibile usarla per le estensioni del pool di buffer, il file di pagina e tempdb.

Posizionare tempdb nell'unità SSD D:\ temporanea locale per i carichi di lavoro di SQL Server, a meno che l'utilizzo della cache locale non sia un problema. Se si usa una macchina virtuale che non dispone di un disco temporaneo, è consigliabile inserire tempdb nel proprio disco isolato o nel pool di archiviazione con memorizzazione nella 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 che vengono spesso creati nei pool di archiviazione per superare la capacità e le prestazioni che qualsiasi singolo disco potrebbe offrire alla macchina virtuale.

Collegare il numero minimo di dischi che soddisfano i requisiti di operazioni di I/O al secondo, velocità effettiva 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 è stato effettuato il provisioning per soddisfare i requisiti di prestazioni migliori.

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 di SQL Server distribuite tramite Azure Marketplace sono dotate di dischi dati formattati con dimensioni dell'unità di allocazione e interleave per il pool di archiviazione impostato su 64 KB.

SSD Premium v2

È consigliabile 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. Con 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.

È consigliabile usare SSD Premium v2 quando si usano le macchine virtuali della serie Ebdsv5 o Ebsv5 perché rappresentano una soluzione più conveniente per questi computer con velocità effettiva di I/O elevata.

è possibile implementare le macchine virtuali di SQL Server con SSD Premium v2 utilizzando il portale di Azure (attualmente in anteprima).

Se si distribuisce la VM di SQL Server usando il portale di Azure e si vuole usare SSD Premium v2, attualmente si è limitati alle macchine virtuali serie Ebdsv5 o Ebsv5. Tuttavia, se si crea manualmente la VM con archiviazione SSD Premium v2 e quindi si installa manualmente SQL Server nella VM, è possibile utilizzare qualsiasi serie di VM che supporti SSD Premium v2. Assicurarsi di registrare la VM di SQL Server con l'estensione SQL IaaS Agent in modo da poter sfruttare tutti i vantaggi da essa offerti.

SAN di Elastic in Azure

SAN di Elastic in Azure è un'offerta di archiviazione NAS che offre ai clienti una soluzione flessibile e scalabile con la possibilità di ridurre i costi tramite il consolidamento delle risorse di archiviazione. SAN di Elastic in Azure offre una soluzione di archiviazione a blocchi conveniente, performante e affidabile che si connette a un'ampia gamma di servizi di calcolo di Azure tramite protocollo iSCSI. SAN di Elastic consente una transizione senza interruzioni da un ambiente di archiviazione SAN esistente al cloud senza dover effettuare il refactoring dell'architettura delle applicazioni dei clienti.

Questa soluzione può ottenere una scalabilità fino a milioni di operazioni di I/O al secondo, GB/s a doppia cifra della velocità effettiva e latenze di pochi millisecondi a singola cifra con resilienza predefinita per ridurre al minimo i tempi di inattività. Usare SAN di Elastic in Azure se è necessario consolidare l'archiviazione, lavorare con più servizi di calcolo o avere carichi di lavoro che richiedono livelli di velocità effettiva elevati quando si utilizza l'archiviazione sulla larghezza di banda di rete. Tuttavia, poiché il raggiungimento delle operazioni di I/O al secondo/della velocità effettiva desiderate per i carichi di lavoro di SQL Server spesso richiede capacità di overprovisioning, in genere non è appropriato per singoli carichi di lavoro di SQL Server. Per ottenere la soluzione più conveniente, potrebbe essere necessario combinare altri carichi di lavoro a basse prestazioni con SQL Server.

Quando si valutano le dimensioni e le prestazioni delle VM per la SAN di Elastic in Azure, è importante comprendere che la comunicazione di archiviazione avviene in rete. Ad esempio, le dimensioni della VM E4d_v5 non supportano l’Archiviazione Premium di Azure ma funzionano bene con la SAN di Elastic in Azure perché supporta fino a 12.500 Mbps velocità effettiva di rete. Quando si usa la SAN di Elastic in Azure con questa dimensione di VM, è necessario assicurarsi che i requisiti di velocità effettiva di rete e di archiviazione per il carico di lavoro siano compresi nel limite di velocità effettiva di rete di 12.500 Mbps.

Determinare i requisiti di rete e di archiviazione prima di implementare la VM di SQL Server con una SAN di Elastic in Azure e, successivamente, monitorare attentamente l'utilizzo della rete e dell'archiviazione per verificare che la VM scelta possa supportare il carico di lavoro. Per altre informazioni, si veda Prestazioni delle VM con volumi SAN di Elastic e metriche SAN di Elastic.

Prendere in considerazione l'inserimento di carichi di lavoro di SQL Server in SAN di Elastic per migliorare l'efficienza dei costi perché:

• Consolidamento dell'archiviazione e condivisione dinamica delle prestazioni: in genere per SQL Server nei carichi di lavoro delle VM di Azure, viene effettuato il provisioning dell'archiviazione su disco per ogni macchina virtuale in base alla capacità e ai requisiti di prestazioni di picco per tale macchina virtuale. Queste prestazioni con provisioning eccessivo sono disponibili quando necessario, ma le prestazioni inutilizzate non possono essere condivise con carichi di lavoro in altre macchine virtuali. SAN di Elastic, analogamente alla SAN locale, consente di consolidare le esigenze di archiviazione di più carichi di lavoro SQL e non SQL per ottenere una migliore efficienza dei costi, con la possibilità di condividere dinamicamente le prestazioni di cui è stato effettuato il provisioning tra i volumi di cui è stato effettuato il provisioning in questi diversi carichi di lavoro in base alle esigenze di I/O. Ad esempio, nella regione degli Stati Uniti orientali, supponiamo di avere 10 carichi di lavoro che richiedono una capacità di 2-TiB e 10.000 operazioni di I/O al secondo ciascuno, ma che collettivamente non hanno bisogno di più di 60.000 operazioni di I/O al secondo in un determinato momento. È possibile configurare una SAN di Elastic con 12 unità di base (1 unità base = $ 0,08 per GiB/mese) che fornirà 12 TiB di capacità e le 60.000 unità di I/O al secondo necessarie e 8 unità di sola capacità (1 unità di sola capacità = $ 0,06 per GiB/mese) che offrono la capacità di 8 TiB rimanenti a un prezzo più basso. Questa configurazione di archiviazione ottimale offre una migliore efficienza dei costi offrendo al contempo le prestazioni necessarie (10.000 operazioni di I/O al secondo) per ognuno di questi carichi di lavoro. Per altre informazioni sulle unità di provisioning di base di SAN di Elastic e unità di sola capacità, si veda Pianificazione di una SAN di Elastic in Azure e per i prezzi, vedere SAN di Elastic in Azure - Prezzi.
• Per aumentare la velocità effettiva di archiviazione: SQL Server nelle distribuzioni di macchine virtuali di Azure richiede occasionalmente il provisioning eccessivo di una macchina virtuale a causa dei limiti di velocità effettiva del disco per tale macchina virtuale. È possibile evitare questo problema con la SAN di Elastic, poiché si aumenta la velocità effettiva di archiviazione tramite la larghezza di banda di rete di calcolo con il protocollo iSCSI. Ad esempio, una macchina virtuale Standard_E32ds_v5 VM è limitata a 51.200 operazioni di I/O al secondo e 865 MBps per la velocità effettiva del disco/archiviazione, ma può raggiungere un massimo di 2.000 MBps di velocità effettiva di rete. Se il requisito di velocità effettiva dell'archiviazione per il carico di lavoro è maggiore di 865 MBps, non sarà necessario aggiornare la macchina virtuale a uno SKU di dimensioni maggiori perché ora può supportare fino a 2.000 MBps tramite SAN di Elastic.

SSD Premium

Usare unità SSD Premium per i file di dati e di log per i carichi di lavoro di SQL Server di produzione. 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/o 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 (5000 IOPS/200 Mbps) per i file di dati e di log e scegliere solo capacità più elevate quando è necessario controllare il numero di dischi delle VM. Per i sistemi di sviluppo/test o di piccole dimensioni è possibile scegliere di usare dimensioni inferiori a P30 perché supportano la memorizzazione nella cache, ma non offrono prezzi riservati.

Per i carichi di lavoro OLTP, associare le operazioni di I/O al secondo di destinazione per disco (o pool di archiviazione) con i requisiti di prestazioni usando i 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, trovare la corrispondenza con la velocità effettiva di destinazione usando i carichi di lavoro nei momenti 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 dischi SSD Premium di cui uno contenente il file di log e l'altro contenente i file di dati.

Le Operazioni di I/O al secondo con provisioning e velocità effettiva per disco usate come parte del pool di archiviazione. Le funzionalità combinate delle operazioni di I/O al secondo e velocità effettiva dei dischi sono la capacità massima fino ai limiti di velocità effettiva della macchina virtuale.

La procedura consigliata consiste nell'usare il minor numero di dischi possibili, soddisfando i requisiti minimi per operazioni di I/O al secondo (e 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, è possibile aumentare il livello di prestazioni per soddisfare le esigenze aziendali.

La modifica del livello di prestazioni consente agli amministratori di prepararsi e soddisfare una domanda più elevata senza basarsi sul bursting del disco.

Usare le prestazioni più elevate a condizione che la fatturazione sia 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 a breve termine.

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

Disco Ultra di Azure

Se sono necessari tempi di risposta inferiori al millisecondo 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.

Il disco Ultra può essere configurato in cui la capacità e le operazioni di I/O al secondo possono essere ridimensionate in modo indipendente. Con gli amministratori di dischi 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 Backup di Azure. Per altre informazioni, vedere Uso di dischi Ultra di Azure per un elenco completo delle limitazioni.

Unità SSD e HDD Standard

Le unità HDD e SSD Standard sono caratterizzate da latenze e larghezze di banda variabili e sono consigliate solo per i carichi di lavoro di sviluppo e test. Per i carichi di lavoro di produzione si consiglia di usare le unità SSD Premium v2 o SSD Premium. Se non si usano unità SSD Standard (scenari di sviluppo e test), è consigliabile aggiungere il numero massimo di dischi dati supportato dalle dimensioni della macchina virtuale e usare lo striping del disco con spazi di archiviazione per ottenere prestazioni ottimali.

Memorizzazione nella cache

Le macchine virtuali che supportano la memorizzazione nella cache di archiviazione Premium possono sfruttare una funzionalità aggiuntiva denominata BlobCache di Azure o memorizzazione nella cache dell'host per estendere le funzionalità delle operazioni di I/O al secondo e velocità effettiva di una macchina virtuale. Le macchine virtuali abilitate sia per l'archiviazione Premium che per la memorizzazione nella cache di archiviazione Premium hanno questi due diversi limiti di larghezza di banda di archiviazione che possono essere usati insieme per migliorare le prestazioni di archiviazione.

Velocità effettiva delle operazioni di I/O al secondo e MBps senza memorizzazione nella cache rispetto ai limiti di velocità effettiva del disco 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 operazioni di lettura e scrittura in BlobCache di Azure (operazioni di I/O al secondo e velocità effettiva memorizzate nella cache) non vengono conteggiate rispetto agli IOPS non memorizzati nella cache e ai limiti di velocità effettiva 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.

La quantità di operazioni di I/O al secondo non memorizzate nella cache e la velocità effettiva disponibili per una macchina virtuale possono essere verificate nella documentazione relativa alla 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 5000 operazioni di I/O al secondo e 125 MBps di velocità effettiva del disco non memorizzato nella cache.

Analogamente, è possibile notare che l'Standard_M32ts supporta 20.000 operazioni di I/O al secondo del disco non memorizzate nella cache e 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 massima di archiviazione temporanea e memorizzazione nella cache

Il limite massimo di velocità effettiva dell'archiviazione temporanea e memorizzazione nella cache è un limite separato dal limite di velocità effettiva non memorizzata nella cache nella macchina virtuale. BlobCache di Azure è costituito da una combinazione della memoria ad accesso casuale dell'host della macchina virtuale e dell'unità SSD collegata localmente. L'unità temporanea (unità D:\) all'interno della macchina virtuale è ospitata anche in questa unità SSD locale.

Il limite massimo di velocità effettiva della cash e dell'archiviazione temporanea regola l'I/O rispetto all'unità temporanea locale (unità D:\) e BlobCache di Azure solo se la memorizzazione nella cache dell'host è abilitata.

Quando la memorizzazione nella cache è abilitata nell'archiviazione Premium, le macchine virtuali possono essere ridimensionate oltre le limitazioni degli IOPS e dei limiti di velocità effettiva delle macchine virtuali senza cash dell'archiviazione remota.

Solo determinate macchine virtuali supportano sia l'archiviazione Premium che la memorizzazione nella cache dell'archiviazione Premium( che deve essere verificata nella documentazione della macchina virtuale). Ad esempio, la documentazione della serie M indica che sia l'archiviazione Premium che la memorizzazione nella cache dell'archiviazione Premium sono supportate:

I limiti della cache variano in base alle dimensioni della macchina virtuale. Ad esempio, la macchina virtuale Standard_M8ms supporta 10000 operazioni di I/O al secondo del disco memorizzate nella cache e una velocità effettiva del disco memorizzato nella cache di 1000 MBps con una dimensione totale della cache di 793 GiB. Allo stesso modo, la VM Standard_M32ts supporta 40.000 operazioni di I/O al secondo del disco memorizzate nella cache e una velocità effettiva del disco memorizzato nella cache di 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 che vengano apportate modifiche ai criteri di memorizzazione nella cache della macchina virtuale. Se si modifica una delle impostazioni della cache della macchina virtuale, il disco di destinazione viene scollegato e ricollegato dopo l'applicazione delle impostazioni.

Criteri di memorizzazione nella cache dei file di dati

I criteri di memorizzazione nella cache dell'archiviazione variano a seconda del tipo di file di dati di SQL Server ospitati nell'unità.

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

Per altre informazioni, vedere Memorizzazione nella cache del disco.

Striping del 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 una maggiore velocità effettiva, è possibile aggiungere altri dischi dati e usare lo striping del disco. 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

Esistono limiti di velocità effettiva sia a livello di disco che di macchina virtuale. I limiti massimi per le operazioni di I/O al secondo per ogni VM e ogni disco sono diversi e indipendenti gli uni dagli altri.

Le applicazioni che utilizzano risorse oltre questi limiti verranno limitate (note anche come ristrette). Selezionare una macchina virtuale e le dimensioni del disco in uno striping del disco che soddisfi i requisiti dell'applicazione e non affrontino limitazioni di restrizioni. Per risolvere il limite, usare la memorizzazione nella cache o ottimizzare l'applicazione in modo che sia necessaria una minore velocità effettiva.

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 operazioni di I/O al secondo e 500 MBps.
• Eseguire lo striping di tre dischi P30 per offrire 15.000 operazioni di I/O al secondo e velocità effettiva di 600 MB/s.
• Usare una macchina virtuale Standard_M16ms e usare la memorizzazione nella cache dell'host per usare la cache locale rispetto all'utilizzo della velocità effettiva.

Le macchine virtuali configurate per aumentare le prestazioni durante i periodi di utilizzo elevato devono effettuare il provisioning dell'archiviazione con operazioni di I/O al secondo e velocità effettiva sufficienti per supportare le dimensioni massime della macchina virtuale, mantenendo al contempo il numero complessivo di dischi minore o uguale al numero massimo supportato dallo SKU della macchina virtuale più piccolo destinato ad essere utilizzato.

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

Acceleratore di scrittura

L'acceleratore di 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 Azure Archiviazione Premium quando è necessaria una latenza di I/O a cifra singola a causa di carichi di lavoro OLTP cruciali per volumi elevati o ambienti di data warehouse.

Usare l'acceleratore di scrittura per migliorare la latenza di scrittura nell'unità che ospita i file di log. Non usare l'acceleratore di scrittura 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.

Confronto con il disco Ultra di Azure

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

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

Monitorare le prestazioni dell'archiviazione

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

Le operazioni di I/O al secondo (input/output al secondo) sono il numero di richieste che l'applicazione effettua nell'archiviazione al secondo. Misurare le operazioni di I/O al secondo usando contatori del Monitor prestazioni Disk Reads/sec e Disk Writes/sec. Le applicazioni OLTP (elaborazione di transazioni online) devono aumentare le operazioni di I/O al secondo per ottenere prestazioni ottimali. Le applicazioni come sistemi di elaborazione dei pagamenti, acquisti online e sistemi per punti vendita al dettaglio sono tutti esempi di applicazioni OLTP.

La velocità effettiva è il volume di dati inviati alla risorsa di archiviazione sottostante, spesso misurata da megabyte al secondo. Usare i contatori di monitoraggio delle prestazioni Disk Read Bytes/sec e Disk Write Bytes/sec per misurare la velocità effettiva. L'archiviazione dati è ottimizzata per massimizzare la velocità effettiva rispetto alle operazioni di I/O al secondo. Le applicazioni come gli archivi dati per analisi, creazione di report, flussi di lavoro ETL e altre destinazioni di business intelligence sono tutti esempi di applicazioni di archiviazione dati.

Le dimensioni delle unità di I/O influisce sulle funzionalità delle operazioni di I/O al secondo e sulla velocità effettiva, poiché le dimensioni di I/O minori producono dimensioni di I/O superiori producono una velocità effettiva maggiore. SQL Server sceglie automaticamente le dimensioni di I/O ottimali. Per altre informazioni, vedere Ottimizzare le operazioni di I/O al secondo, la velocità effettiva e la latenza per le applicazioni.

Esistono metriche specifiche di Monitoraggio di Azure che sono preziose per individuare il limite massimo a livello di macchina virtuale e disco, nonché l'utilizzo e l'integrità della cache AzureBlob. Per identificare i contatori chiave da aggiungere alla soluzione di monitoraggio e al dashboard di portale di Azure, vedere Metriche di utilizzo dell'archiviazione.

Monitorare lo sviluppo del log delle transazioni

Poiché un log delle transazioni completo può causare problemi di prestazioni e interruzioni, è importante monitorare lo spazio disponibile nel log delle transazioni, nonché lo spazio su disco usato 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 Archiviazione della risorsa macchine virtuali SQL se è stata implementata un'immagine di SQL Server da Azure Marketplace o nel riquadro Dischi per la macchina virtuale di Azure e SQL Server installato automaticamente.

Passaggi successivi

Per altre informazioni, vedere gli altri articoli di questa serie di procedure consigliate:

• Elenco di controllo rapido

• Dimensioni macchina virtuale

• Sicurezza

• Impostazioni HADR

• Raccogliere la baseline

• Per le procedure consigliate relative alla sicurezza, vedere Considerazioni relative alla sicurezza per SQL Server in Macchine virtuali di Azure.

• Per i test dettagliati delle prestazioni SQL Server nelle macchine virtuali di Azure con i benchmark TPC-E e TPC_C, fare riferimento al blog sull'ottimizzazione delle prestazioni OLTP.

• Esaminare altri articoli relativi alle Macchine Virtuali di SQL Server in Panoramica di SQL Server in Macchine virtuali di Azure. In caso di domande sulle macchine virtuali SQL Server, consultare le domande frequenti.