Elenco di controllo: Procedure consigliate per SQL Server nelle macchine virtuali di Azure

SI APPLICA A: SQL Server sulla macchina virtuale di Azure

Questo articolo fornisce un rapido elenco di controllo come una serie di procedure consigliate e linee guida per ottimizzare le prestazioni dei SQL Server nelle macchine virtuali di Azure.This article provides a quick checklist as a series of best practices and guidelines to optimize performance of your SQL Server on Azure Virtual Machines (VMs).

Per informazioni dettagliate, vedere gli altri articoli di questa serie:Elenco di controllo,Dimensioni della macchina virtuale, Archiviazione, Sicurezza, configurazione HADR, Raccolta della previsione.

Abilitare SQL valutazione per SQL Server nelle macchine virtuali di Azure e il SQL Server verrà valutato in base alle procedure consigliate e ai risultati noti visualizzati nella pagina di gestione delle macchine virtuali di SQL del portale di Azure.

Panoramica

Durante l'SQL Server in macchine virtuali di Azure, continuare a usare le stesse opzioni di ottimizzazione delle prestazioni del database applicabili SQL Server in ambienti server locali. Tuttavia, le prestazioni di un database relazionale in un cloud pubblico dipendono da molti fattori, ad esempio le dimensioni di una macchina virtuale e la configurazione dei dischi dati.

In genere esiste un compromesso tra l'ottimizzazione dei costi e l'ottimizzazione delle prestazioni. Questa serie di procedure consigliate per le prestazioni è incentrata su come ottenere le prestazioni migliori per SQL Server nelle macchine virtuali di Azure. Se il carico di lavoro è meno impegnativo, potrebbe non essere necessaria ogni ottimizzazione consigliata. Valutare le esigenze di prestazioni, i costi e i modelli di carico di lavoro durante la valutazione di questi suggerimenti.

Dimensioni macchina virtuale

Di seguito è riportato un rapido elenco di controllo delle procedure consigliate per le dimensioni della macchina virtuale per l'esecuzione SQL Server in Azure VM:

  • Usare le dimensioni delle macchine virtuali con 4 o più VCPU, ad esempio E4ds_v5 o versioni successive.
  • Usare le dimensioni ottimizzate per la memoria delle macchine virtuali per ottenere le migliori prestazioni dei SQL Server di lavoro.
  • La serie Edsv5,la serie M-e la serie Mv2 offrono il rapporto ottimale tra memoria e vCore necessario per i carichi di lavoro OLTP.
  • La serie Edsv5 offre il miglior prezzo per i carichi di lavoro SQL Server nelle macchine virtuali di Azure. Considerare questa serie prima per la maggior parte dei SQL Server di lavoro.
  • Le macchine virtuali della serie M offrono il rapporto memoria-vCore più elevato in Azure. Considerare queste macchine virtuali per carichi di lavoro mission critical e data warehouse.
  • Sfruttare le immagini di Azure Marketplace per distribuire le SQL Server virtuali quando le SQL Server e le opzioni di archiviazione sono configurate per prestazioni ottimali.
  • Raccogliere le caratteristiche delle prestazioni del carico di lavoro di destinazione e usarle per determinare le dimensioni appropriate della macchina virtuale per l'azienda.
  • Usare lo strumento di raccomandazioneSKU Migration Assistant dati per trovare le dimensioni della macchina virtuale giuste per il carico di lavoro SQL Server lavoro.

Per altre informazioni, vedere le procedure consigliate complete per le dimensioni delle macchine virtuali.

Archiviazione

Di seguito è riportato un rapido elenco di controllo delle procedure consigliate per la configurazione dello spazio di archiviazione per l'SQL Server in Azure VM:

  • Monitorare l'applicazione e determinare i requisiti di larghezza di banda e latenza di archiviazione per SQL Server file di dati, log e tempdb prima di scegliere il tipo di disco.
  • Per ottimizzare le prestazioni di archiviazione, pianificare il massimo numero di operazioni di I/O non memorizzate nella cache disponibili e usare la memorizzazione dei dati nella cache come funzionalità per le prestazioni per la lettura dei dati, evitando il limite o la limitazione di macchine virtuali e dischi.
  • Inserire file di dati, log e tempdb in unità separate.
    • Per l'unità dati, usare solo dischi P30 e P40 premium per garantire la disponibilità del supporto della cache
    • Per il piano di unità di log per la capacità e le prestazioni di test rispetto ai costi durante la valutazione dei dischi premium P30 - P80.
      • Se è necessaria una latenza di archiviazione di sottomillisecondi, usare i dischi ultra di Azure per il log delle transazioni.
      • Per le distribuzioni di macchine virtuali di serie M, considerare Write Accelerator sull'uso dei dischi ultra di Azure.
    • Inserire tempdb nell'unità SSD effimera locale (impostazione predefinita) per la maggior parte dei carichi di lavoro SQL Server dopo aver scelto le dimensioni ottimali della macchina virtuale.
      • Se la capacità dell'unità locale non è sufficiente per tempdb, è consigliabile ridimensionare la macchina virtuale. Per altre informazioni, vedere Criteri di memorizzazione nella cache dei file di dati.
  • Stripe multiple Azure data disks using Spazi di archiviazione to increase I/O bandwidth up to the target virtual machine's IOPS and throughput limits.
  • 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 SQL Server file.
    • Arrestare sempre il SQL Server prima di modificare le impostazioni della cache del disco.
  • Per i carichi di lavoro di sviluppo e test, è consigliabile usare lo spazio di archiviazione standard. Non è consigliabile usare hdd/SDD standard per carichi di lavoro di produzione.
  • Lo bursting del disco basato sul credito (P1-P20) deve essere considerato solo per i carichi di lavoro di sviluppo/test più piccoli e per i sistemi di reparto.
  • Eseguire il provisioning dell'account di archiviazione nella stessa area geografica della SQL Server vm.
  • Disabilitare l'archiviazione con ridondanza geografica di Azure (replica geografica) e usare LRS (archiviazione ridondante locale) nell'account di archiviazione.
  • Formattare il disco dati in modo da usare le dimensioni dell'unità di allocazione di 64 KB per tutti i file di dati inseriti in un'unità diversa dall'unità temporanea ,che ha un valore predefinito D:\ di 4 KB. SQL Server le macchine virtuali distribuite tramite Azure Marketplace sono formattate con dischi di dati formattati con le dimensioni dell'unità di allocazione e l'interfoliazione per il pool di archiviazione impostato su 64 KB.

Per altre informazioni, vedere le procedure consigliate Archiviazione completa.

SQL Server caratteristiche

Di seguito è riportato un rapido elenco di controllo delle procedure consigliate per SQL Server di configurazione quando si eseguono le istanze di SQL Server in una macchina virtuale di Azure in produzione:

Funzionalità di Azure

Di seguito è riportato un rapido elenco di controllo delle procedure consigliate per istruzioni specifiche di Azure quando si esegue il SQL Server in Una macchina virtuale di Azure:

Configurazione HADR

Le funzionalità hadr (High Availability and Disaster Recovery), come il gruppo di disponibilità Always On e l'istanza del cluster di failover, si basano sulla tecnologia del cluster di failover Windows Server. Esaminare le procedure consigliate per modificare le impostazioni HADR per supportare meglio l'ambiente cloud.

Per il cluster Windows, considerare le procedure consigliate seguenti:

  • Distribuire le macchine virtuali SQL Server in più subnet quando possibile per evitare la dipendenza da un Azure Load Balancer o da un nome di rete distribuito (DNN) per instradare il traffico alla soluzione HADR.
  • Modificare il cluster in parametri meno aggressivi per evitare interruzioni impreviste da errori di rete temporanei o manutenzione della piattaforma Azure. Per altre informazioni, vedere Impostazioni di heartbeat e soglia. Per Windows Server 2012 e versioni successive, usare i valori consigliati seguenti:
    • SameSubnetDelay: 1 secondo
    • SameSubnetThreshold: 40 heartbeat
    • CrossSubnetDelay: 1 secondo
    • CrossSubnetThreshold: 40 heartbeat
  • Inserire le macchine virtuali in un set di disponibilità o in aree di disponibilità diverse. Per altre informazioni, vedere Impostazioni di disponibilità della macchina virtuale.
  • Usare una singola scheda NIC per ogni nodo del cluster e una singola subnet.
  • Configurare il voto del quorum del cluster per l'uso di 3 o più voti dispari. Non assegnare voti alle aree geografiche dr.
  • Monitorare attentamente i limiti delle risorse per evitare riavvii imprevisti o failover a causa di vincoli di risorse.
    • Verificare che il sistema operativo, i driver e SQL Server siano aggiornati alle build più recenti.
    • Ottimizzare le prestazioni SQL Server le macchine virtuali di Azure. Per altre informazioni, vedere le altre sezioni di questo articolo.
    • Ridurre o distribuire il carico di lavoro per evitare limiti di risorse.
    • Passare a una macchina virtuale o a un disco con limiti superiori per evitare vincoli.

Per il gruppo SQL Server di disponibilità o l'istanza del cluster di failover, prendere in considerazione le procedure consigliate seguenti:

  • Se si verificano frequenti errori imprevisti, seguire le procedure consigliate per le prestazioni descritte nel resto di questo articolo.
  • Se l'ottimizzazione SQL Server prestazioni della macchina virtuale non risolve i failover imprevisti, è consigliabile rilassare il monitoraggio per il gruppo di disponibilità o l'istanza del cluster di failover. Tuttavia, questa operazione potrebbe non risolvere l'origine sottostante del problema e mascherare i sintomi riducendo la probabilità di errore. Potrebbe essere ancora necessario esaminare e risolvere la causa radice sottostante. Per Windows Server 2012 versione successiva, usare i valori consigliati seguenti:
    • Timeout lease:usare questa equazione per calcolare il valore di timeout massimo del lease:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Iniziare con 40 secondi. Se si usano i valori relaxed e i valori consigliati in precedenza, non superare SameSubnetThresholdSameSubnetDelay gli 80 secondi per il valore di timeout del lease.
    • Numero massimo di errori in un periodo specificato:è possibile impostare questo valore su 6.
    • Timeout controllo integrità:è possibile impostare inizialmente questo valore su 60000, regolando in base alle esigenze.
  • Quando si usa il nome della rete virtuale (VNN) e Azure Load Balancer per connettersi alla soluzione HADR, specificare nella stringa di connessione, anche se il cluster si estende su una MultiSubnetFailover = true sola subnet.
    • Se il client non supporta, potrebbe essere necessario impostare e memorizzare nella cache le MultiSubnetFailover = True credenziali del client per RegisterAllProvidersIP = 0HostRecordTTL = 300 durate più brevi. Tuttavia, questa operazione potrebbe causare altre query al server DNS.
  • Per connettersi alla soluzione HADR usando il nome di rete distribuita (DNN), tenere presente quanto segue:
    • È necessario usare un driver client che MultiSubnetFailover = True supporti , e questo parametro deve essere nella stringa di connessione.
    • Usare una porta DNN univoca nella stringa di connessione quando ci si connette al listener DNN per un gruppo di disponibilità.
  • Usare una stringa di connessione di mirroring del database per un gruppo di disponibilità di base per evitare la necessità di un servizio di bilanciamento del carico o DNN.
  • Convalidare le dimensioni del settore dei dischi rigidi virtuali prima di distribuire la soluzione a disponibilità elevata per evitare di avere I/O disallineati. Per altre informazioni, vedere KB3009974.

Per altre informazioni, vedere le procedure consigliate complete di HADR.

Passaggi successivi

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

Per le procedure consigliate per la sicurezza, vedere Considerazioni sulla sicurezza SQL Server sulle macchine virtuali di Azure.

È consigliabile abilitare SQL valutazione SQL Server per le macchine virtuali di Azure.

Per altre SQL Server sulla macchina virtuale, vedere SQL Server panoramica sulle macchine virtuali di Azure. Per domande sulle SQL Server virtuali, vedere domande frequenti.