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

  • Articolo

Si applica a:SQL Server nella 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 Azure Macchine virtuali (VM).

In genere esiste un compromesso tra l'ottimizzazione dei costi e l'ottimizzazione delle prestazioni. Questa serie di procedure consigliate per le prestazioni è incentrata sul miglioramento delle prestazioni per SQL Server nelle macchine virtuali di Azure. Se il carico di lavoro è meno impegnativo, è possibile che non siano necessarie tutte le ottimizzazioni consigliate. Prendere in considerazione le esigenze di prestazione, i costi e i modelli di carico di lavoro durante la valutazione di questi elementi consigliati.

Per altre informazioni, vedere gli altri articoli di questa serie: Elenco di controllo, dimensioni delle macchine virtuali, sicurezza, configurazione HADR e Raccolta baseline.

Elenco di controllo

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

  • Monitorare l'applicazione e determinare i requisiti di larghezza di banda e latenza di archiviazione per dati, log e tempdb file di SQL Server prima di scegliere il tipo di disco.
  • Se disponibile, configurare i tempdbfile di dati e di log nel volume SSD locale D: . L'estensione SQL IaaS Agent gestisce la cartella e le autorizzazioni necessarie al nuovo 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 di macchine virtuali e dischi.
  • Quando si usano macchine virtuali SQL Server serie Ebdsv5 o Ebsv5 , usare SSD Premium v2 per ottenere prestazioni ottimali. È possibile distribuire la macchina virtuale di SQL Server con SSD Premium v2 usando il portale di Azure (attualmente in anteprima).
  • Prendere in considerazione l'uso della san elastica di Azure per i carichi di lavoro di SQL Server per migliorare l'efficienza dei costi a causa del consolidamento dell'archiviazione, delle prestazioni dinamiche condivise e della capacità di aumentare la velocità effettiva di archiviazione senza dover aggiornare una macchina virtuale.
  • Inserire dati, log e tempdb file in unità separate.
    • Per l'unità dati, usare dischi P30 e P40 Premium 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
    • Posizionare tempdb sul disco temporaneo (il disco temporaneo è temporaneo 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 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 macchina virtuale. Per altre informazioni, vedere 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 tempdb prestazioni del disco, come posizione tempdb di configurazione avanzata 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 disponibile sempre, perché eventuali errori di questa unità non attiveranno l'azione dall'istanza del cluster di failover.
  • Eseguire lo striping di più dischi dati di Azure usando spazi di Archiviazione per aumentare la larghezza di banda di I/O delle operazioni di I/O fino ai limiti di IOPS e velocità effettiva della macchina virtuale di destinazione.
  • Impostare la memorizzazione nella cache dell'host in sola lettura per i dischi dei file di dati.
  • Impostare la memorizzazione nella cache dell'host su nessuno per i dischi dei file di log.
    • 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.
  • 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 sul credito (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 e usare la memorizzazione nella cache dei dati come funzionalità di prestazioni per le letture dei dati evitando al contempo il limite/limitazione delle richieste 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 macchina virtuale di SQL Server.
  • Disabilitare l'archiviazione con ridondanza geografica di Azure (replica geografica) e usare l'archiviazione con ridondanza 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 per seguire le procedure consigliate.
  • Esaminare e monitorare i limiti dei dischi e delle macchine virtuali usando le metriche di utilizzo di I/O 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 di archiviazione con le altre procedure consigliate, vedere l'elenco di controllo completo per le 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.

Suggerimento

Il provisioning di una macchina virtuale di SQL Server tramite il portale di Azure consente di seguire il processo di configurazione dell'archiviazione e di implementare la maggior parte delle procedure consigliate di archiviazione, ad esempio la creazione di pool di archiviazione separati per i file di dati e di log, la destinazione tempdb all'unità e l'abilitazione D:\ dei criteri di memorizzazione nella cache ottimali. Per altre informazioni sul provisioning e sulla configurazione dell'archiviazione, vedere Configurazione dell'archiviazione delle macchine virtuali SQL.

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à SSD 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 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 di 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 premium ssd 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à (C:\) del sistema operativo e nell'unità (D:\)temporanea temporanea .

Disco del sistema operativo

Un 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 C:\ unità. 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 tipo di disco denominato disco temporaneo (etichettato come D:\ unità). A seconda della serie di macchine virtuali e delle dimensioni, la capacità del disco varia. Il disco temporaneo è temporaneo, il che significa che l'archiviazione su disco viene ricreata (come in, 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 usarlo 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 inserirla 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.

Nota

È anche possibile ospitare i file di database di SQL Server direttamente nell'archiviazione BLOB di Azure o nell'archiviazione SMB, ad esempio la condivisione file Premium di Azure, ma è consigliabile usare i dischi gestiti di Azure per ottenere prestazioni, affidabilità e disponibilità delle funzionalità migliori.

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 usa la serie di macchine virtuali Ebdsv5 o Ebsv5 perché è una soluzione più conveniente per questi computer con velocità effettiva di I/O elevata.

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

Se si distribuisce la macchina virtuale 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 macchina virtuale con archiviazione SSD Premium v2 e quindi si installa manualmente SQL Server nella macchina virtuale, è possibile usare qualsiasi serie di macchine virtuali che supporti l'unità SSD Premium v2. Assicurarsi di registrare la macchina virtuale di SQL Server con l'estensione SQL IaaS Agent in modo da poter sfruttare tutti i vantaggi offerti dall'estensione.

SAN di Elastic in Azure

San elastico di Azure offre una soluzione di archiviazione a blocchi altamente scalabile, conveniente, ad alte prestazioni e affidabile che si connette a un'ampia gamma di servizi di calcolo di Azure tramite protocollo iSCSI. La san elastica 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à elevata, fino a milioni di operazioni di I/O al secondo, GB/s a doppia cifra della velocità effettiva e latenze di millisecondi a singola cifra con resilienza predefinita per ridurre al minimo i tempi di inattività. Ciò rende ideale per i clienti che vogliono consolidare l'archiviazione, i clienti che usano più servizi di calcolo o quelli che hanno carichi di lavoro che richiedono livelli di velocità effettiva elevati ottenuti guidando l'archiviazione sulla larghezza di banda di rete. 

Nota

  • Il dimensionamento delle macchine virtuali con san elastico deve soddisfare i requisiti di velocità effettiva di rete di produzione (vm a macchina virtuale) insieme alla velocità effettiva di archiviazione.

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

  • Archiviazione consolidamento e condivisione dinamica delle prestazioni: in genere per SQL Server nei carichi di lavoro delle macchine virtuali di Azure, viene effettuato il provisioning dell'archiviazione su disco per ogni macchina virtuale in base alla capacità del cliente 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. La san elastica, 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, negli Stati Uniti orientali, se sono presenti 10 carichi di lavoro che richiedono 2 tiB capacità e 10.000 operazioni di I/O al secondo, ma collettivamente non richiedono più di 60.000 operazioni di I/O al secondo in qualsiasi momento. È possibile configurare una SAN elastica con 12 unità di base (1 unità base = $ 0,08 per GiB/mese) che fornirà 12 TiB 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 offriranno la capacità di 8 TiB rimanenti a un prezzo più economico. 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 SAN elastico e di sola capacità, vedere Pianificazione di una SAN elastica di Azure e per i prezzi, vedere San elastico di Azure - Prezzi.
  • Per aumentare la velocità effettiva di archiviazione: SQL Server nelle distribuzioni di macchine virtuali di Azure richiede occasionalmente l'overprovisioning di una macchina virtuale a causa dei limiti di velocità effettiva del disco per tale macchina virtuale. È possibile evitare questo problema con la san elastica, 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_E32bds_v5 (SCSI) è limitata a 88.000 operazioni di I/O al secondo e 2.500 MBps per la velocità effettiva del disco/archiviazione, ma può raggiungere un massimo di 16.000 MBps velocità effettiva di rete. Se il requisito di velocità effettiva dell'archiviazione per il carico di lavoro è maggiore di 2.500 MBps, non sarà necessario aggiornare la macchina virtuale a uno SKU superiore perché ora può supportare fino a 16.000 MBps tramite SAN elastico.

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 macchine virtuali. 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 Disk Reads/sec + Disk Writes/sec contatori delle prestazioni. 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 Archiviazione Spazi 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 mappati a unità separate, in cui un'unità contiene il file di log e l'altra contiene i dati.

Operazioni di I/O al secondo con provisioning e velocità effettiva per disco usate come parte del pool di archiviazione. Le funzionalità di I/O al secondo e velocità effettiva combinate 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. Designare il livello di prestazioni in fase di distribuzione o modificarlo in seguito, 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 per i dischi gestiti.

Disco Ultra di Azure

Se sono necessari tempi di risposta submillisecond 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à SSD e le unità SSD Standard hanno latenze e larghezza di banda variabili e sono consigliate solo per carichi di lavoro di sviluppo/test. I carichi di lavoro di produzione devono usare UNITÀ SSD Premium v2 o Premium. Se si usano unità SSD Standard (scenari di sviluppo/test), è consigliabile aggiungere il numero massimo di dischi dati supportati dalle dimensioni della macchina virtuale e usare lo striping del disco con spazi 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à 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 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 ai limiti di IOPS e velocità effettiva non memorizzati nella cache della macchina virtuale.

Nota

La memorizzazione nella cache del disco non è supportata per i dischi 4 TiB e superiori (P50 e versioni superiori). Se alla VM sono collegati più dischi, ogni disco con dimensioni inferiori a 4 TiB supporta la memorizzazione nella cache. Per altre informazioni, vedere Memorizzazione nella cache del disco.

Velocità effettiva non memorizzata 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 (D:\ unità) 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.

Screenshot showing M-series uncached disk throughput documentation.

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 non memorizzati nella cache e non memorizzati nella cache.

Velocità effettiva di archiviazione temporanea e memorizzata nella cache

Il limite massimo di velocità effettiva dell'archiviazione temporanea e memorizzato nella cache è un limite separato dal limite di velocità effettiva non memorizzato 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 (D:\ unità) all'interno della macchina virtuale è ospitata anche in questa unità SSD locale.

Il limite massimo di velocità effettiva dell'archiviazione temporanea e memorizzato nella cache regola l'I/O rispetto all'unità temporanea locale (D:\ unità) e l'oggetto 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 dei limiti di IOPS e velocità effettiva delle macchine virtuali di 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:

Screenshot showing M-Series Premium Storage support.

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 1000 MBps con una dimensione totale della cache di 793 GiB. Analogamente, la macchina virtuale Standard_M32ts supporta 40000 operazioni di I/O al secondo del disco memorizzate nella cache e 400 MBps con dimensioni totali della cache pari a 3174 GiB.

Screenshot showing M-series cached disk throughput documentation.

È 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:

Disco di SQL Server Elemento consigliato
Disco dati Abilitare Read-only la memorizzazione nella cache per i dischi che ospitano i file di dati di SQL Server.
Le letture dalla cache saranno più veloci rispetto alle letture non memorizzate nella cache dal disco dati.
Le operazioni di I/O al secondo e la velocità effettiva non memorizzate nella cache consentono di ottenere le prestazioni totali disponibili dalla macchina virtuale entro i limiti delle macchine virtuali, ma le prestazioni effettive variano in base alla capacità del carico di lavoro di usare la cache (percentuale riscontri cache).
Disco del log delle transazioni Impostare i criteri di memorizzazione nella cache su None per i dischi che ospitano il log delle transazioni. Non esiste alcun vantaggio per le prestazioni per abilitare la memorizzazione nella cache per il disco del log delle transazioni e, di fatto, la presenza Read-only di o Read/Write memorizzazione nella cache abilitata nell'unità di log può compromettere le prestazioni delle scritture nell'unità e ridurre la quantità di cache disponibile per le letture nell'unità dati.
Disco del sistema operativo operativo I criteri di memorizzazione nella cache predefiniti sono Read/write per l'unità del sistema operativo.
Non è consigliabile modificare il livello di memorizzazione nella cache dell'unità del sistema operativo.
tempdb Se tempdb non è possibile posizionare l'unità D:\ temporanea a causa di motivi di capacità, ridimensionare la macchina virtuale per ottenere un'unità temporanea più grande o posizionare tempdb su un'unità dati separata con Read-only la memorizzazione nella cache configurata.
La cache della macchina virtuale e l'unità temporanea usano entrambe l'unità SSD locale, quindi tenere presente che quando si esegue il dimensionamento perché tempdb le operazioni di I/O verranno conteggiate rispetto ai limiti di IOPS e velocità effettiva memorizzati nella cache quando sono ospitati nell'unità temporanea.

Importante

La modifica dell'impostazione della cache di un disco di Azure scollega e ricollega il disco di destinazione. Quando si modifica l'impostazione della cache per un disco che ospita i file di dati, log o applicazioni di SQL Server, assicurarsi di arrestare il servizio SQL Server insieme a qualsiasi altro servizio correlato per evitare il danneggiamento dei dati.

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 velocità effettiva e larghezza di banda variano in base alle dimensioni della macchina virtuale. Per altre informazioni, vedere Dimensioni delle macchine virtuali

Aggiungere altri dischi dati e usare lo striping del disco per una maggiore velocità effettiva. 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 velocità effettiva di 600 MB/s.

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

Limite del disco

Esistono limiti di velocità effettiva sia a livello di disco che di macchina virtuale. I limiti massimi di operazioni di I/O al secondo per macchina virtuale e per disco differiscono e sono indipendenti l'uno dall'altro.

Le applicazioni che utilizzano risorse oltre questi limiti verranno limitate (note anche come limitate). 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 limitazione. 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 di macchine virtuali 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 su disco.

Nota

Alcuni limiti di disco possono comunque comportare prestazioni soddisfacenti per gli utenti; ottimizzare e gestire i carichi di lavoro invece di ridimensionare una macchina virtuale di dimensioni maggiori per bilanciare i costi e le prestazioni per la gestione dei costi e delle prestazioni per l'azienda.

Accelerazione scrittura

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

SKU di VM # Write Accelerator disks (Dischi dell'acceleratore di scrittura) Operazioni di I/O al secondo del disco dell'acceleratore di scrittura per macchina virtuale
M416ms_v2, M416s_v2 16 20000
M128ms, M128s 16 20000
M208ms_v2, M208s_v2 8 10000
M64ms, M64ls, M64s 8 10000
M32ms, M32ls, M32ts, M32s 4 5000
M16ms, M16s 2 2500
M8ms, M8s 1 1250

Esistono diverse restrizioni per l'uso dell'accelerazione 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'accelerazione di scrittura e i dischi Ultra di Azure è che l'accelerazione della scrittura è una funzionalità di macchina virtuale disponibile solo per le serie M e i dischi Ultra di Azure è un'opzione di archiviazione. L'accelerazione della 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'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 una bassa latenza per il log delle transazioni, usare i dischi Ultra di Azure.

Monitorare le prestazioni di 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 Monitor prestazioni contatori Disk Reads/sec e Disk Writes/sec. Le applicazioni OLTP (Online Transaction Processing) 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 punto 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. Misurare la velocità effettiva con i contatori Disk Read Bytes/sec Monitor prestazioni e Disk Write Bytes/sec. Il data warehousing è ottimizzato per ottimizzare 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 data warehousing.

Le dimensioni delle unità di I/O influisce sulle funzionalità di I/O al secondo e 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 operazioni di I/O al secondo, velocità effettiva e latenza per le applicazioni.

Esistono metriche specifiche di Monitoraggio di Azure che sono preziose per individuare il limite 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 Archiviazione metriche di utilizzo.

Nota

Monitoraggio di Azure attualmente non offre metriche a livello di disco per l'unità (D:\)temporanea temporanea temporanea . Percentuale utilizzo operazioni di I/O al secondo memorizzate nella cache della macchina virtuale e percentuale utilizzo larghezza di banda memorizzata nella cache delle macchine virtuali rifletterà le operazioni di I/O al secondo e la velocità effettiva sia dall'unità (D:\) temporanea temporanea che dalla memorizzazione nella cache dell'host insieme.

Passaggi successivi

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