Condividi tramite

Elenco di controllo: procedure consigliate per SQL Server nelle VM di Azure

  • Articolo

Si applica a: SQL Server su VM di Azure

Questo articolo fornisce un elenco di controllo rapido come una serie di procedure consigliate e linee guida per ottimizzare le prestazioni di SQL Server in Macchine Virtuali (VM) di Azure.

Per informazioni dettagliate, consultare gli altri articoli di questa serie: Dimensioni della VM, Archiviazione, Sicurezza, Configurazione HADR, Raccolta dati di previsione.

Abilitare La valutazione SQL per SQL Server nelle VM di Azure e SQL Server verrà calcolato in base alle procedure consigliate note, con i risultati nella pagina di gestione della VM SQL del portale di Azure.

Per i video riguardanti le funzionalità più recenti per ottimizzare le prestazioni della VM di SQL Server e automatizzarne la gestione, consultare i seguenti video sui dati esposti:

Panoramica

Durante l'esecuzione di SQL Server in Macchine Virtuali di Azure, è consigliabile continuare ad usare le stesse opzioni di ottimizzazione delle prestazioni, applicabili a 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 della macchina virtuale e la configurazione dei dischi dati.

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.

Dimensioni della VM

L'elenco di controllo in questa sezione illustra le procedure consigliate per le dimensioni delle VM per SQL Server in Macchine Virtuali di Azure.

  • Identificare le caratteristiche delle prestazioni del carico di lavoro per determinare le dimensioni della macchina virtuale appropriate per l'azienda.
  • Se si esegue la migrazione ad Azure, usare strumenti come Data Migration Assistant e consigli per lo SKU per trovare le dimensioni appropriate per il carico di lavoro di SQL Server esistente e quindi eseguire la migrazione con Azure Data Studio.
  • Usare le immagini di Azure Marketplace per distribuire le macchine virtuali di SQL Server come le impostazioni e le opzioni di archiviazione di SQL Server sono configurate per prestazioni ottimali.
  • Usare le dimensioni delle macchine virtuali con 4 o più vCPU.
  • Usare macchine virtuali con dimensioni ottimizzate per la memoria per ottenere prestazioni ottimali dei carichi di lavoro di SQL Server.
    • La serie Edsv5 e la serie Msv3 e Mdsv3 offrono un rapporto ottimale tra memoria e vCore consigliato per i carichi di lavoro OLTP.
    • Le macchine virtuali serie Mbdsv3 offrono prestazioni ottimali per i carichi di lavoro di SQL Server nelle macchine virtuali di Azure. Prendere in considerazione questa serie per i carichi di lavoro DI SQL Server e OLTP cruciali.
    • La serie Ebdsv5 offre un rapporto elevato tra velocità effettiva di I/O e vCore, insieme a un rapporto da memoria a vCore di 8:1. Questa serie offre il miglior rapporto qualità-prezzo per i carichi di lavoro di SQL Server nelle macchine virtuali di Azure. Prendere in considerazione queste macchine virtuali per la maggior parte dei carichi di lavoro di SQL Server.
    • La famiglia di serie M offre macchine virtuali con l'allocazione di memoria più elevata in Azure.
    • Le macchine virtuali della serie Mbsv3 e Mbdsv3 offrono un'allocazione di memoria elevata e il rapporto massimo tra velocità effettiva di I/O e vCore tra la famiglia di serie M, insieme a un rapporto coerente tra memoria e vCore di almeno 8:1.
  • Avviare gli ambienti di sviluppo con la serie D di livello inferiore, la serie B o Av2 e aumentare l'ambiente nel tempo.

Storage

L'elenco di controllo in questa sezione illustra le procedure consigliate per l'archiviazione per SQL Server in VM di Azure.

  • 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.
    • 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.

Sicurezza

L'elenco di controllo di questa sezione illustra le procedure consigliate per la sicurezza per SQL Server in VM di Azure.

Le funzionalità e le capacità di SQL Server offrono metodi di protezione dei dati a livello di database che possono essere combinati con le funzionalità di sicurezza a livello di infrastruttura. Insieme, queste funzionalità forniscono una difesa approfondita a livello di infrastruttura per soluzioni basate sul cloud e ibride. Inoltre, con le misure di sicurezza di Azure, è possibile crittografare i dati sensibili, proteggere le macchine virtuali da virus e malware, proteggere il traffico di rete, identificare e rilevare le minacce, soddisfare i requisiti di conformità e fornisce un unico metodo per l'amministrazione e la creazione di report per qualsiasi esigenza di sicurezza nel cloud ibrido.

  • Usare Microsoft Defender per il cloud per valutare e intervenire per migliorare il comportamento di sicurezza dell'ambiente dati. Le funzionalità come Azure Advanced Threat Protection (ATP) possono essere utilizzate nei carichi di lavoro ibridi per migliorare la valutazione della sicurezza e offrire la possibilità di reagire ai rischi. La registrazione della macchina virtuale di SQL Server con l'estensione SQL IaaS Agent presenta le valutazioni di Microsoft Defender per il cloud all'interno della risorsa macchina virtuale SQL del portale di Azure.
  • Usa Microsoft Defender per SQL per individuare e mitigare potenziali vulnerabilità del database e rilevare attività anomale che potrebbero essere un indicatore di minacce per l'istanza di SQL Server e il livello di database.
  • La valutazione della vulnerabilità fa parte di Microsoft Defender per SQL che consente di individuare e correggere potenziali rischi per l'ambiente SQL Server. Consente di visualizzare lo stato di sicurezza e prevede passaggi utili per risolvere i problemi di sicurezza.
  • Usare le VM riservate di Azure per rafforzare la protezione dei dati in uso e i dati inattivi rispetto all'accesso dell'operatore host. Le VM riservate di Azure consentono di archiviare in modo sicuro i dati sensibili nel cloud e soddisfare requisiti di conformità rigorosi.
  • Se si usa SQL Server 2022, è consigliabile usare l'autenticazione Microsoft Entra per connettersi all'istanza di SQL Server.
  • Azure Advisor analizza i dati di telemetria dell'uso e della configurazione delle risorse e consiglia soluzioni che consentono di migliorare l'efficienza dei costi, le prestazioni, la disponibilità elevata e la sicurezza delle risorse di Azure. Utilizzare Azure Advisor a livello di macchina virtuale, gruppo di risorse o sottoscrizione per identificare e applicare le procedure consigliate per ottimizzare le distribuzioni di Azure.
  • Usare la Crittografia dischi di Azure se il requisito di conformità e sicurezza prevede la crittografia dei dati end-to-end tramite le chiavi di crittografia, tra cui la crittografia del disco temporaneo (temporaneo collegato in locale).
  • In alternativa, per impostazione predefinita, le istanze di Managed Disks vengono crittografate quando inattive mediante crittografia del servizio di archiviazione di Azure, in cui le chiavi di crittografia sono chiavi gestite da Microsoft archiviate in Azure.
  • Per un confronto delle opzioni di crittografia dei dischi gestiti, vedere il grafico di confronto della crittografia dei dischi gestiti.
  • Le porte di gestione devono essere chiuse nelle macchine virtuali: le porte di gestione remota aperte espongono la VM a un alto livello di rischio da attacchi basati su Internet. per sottrarre le credenziali e ottenere l'accesso di amministratore alla macchina virtuale.
  • Abilitare l'accesso JIT (Just-In-Time) per le macchine virtuali di Azure
  • Usare Azure Bastion su Remote Desktop Protocol (RDP).
  • Bloccare le porte e consentire solo il traffico dell'applicazione necessario usando Firewall di Azure, che è un firewall gestito come servizio (FaaS) che concede/nega l'accesso al server in base all'indirizzo IP di origine.
  • Usare i gruppi di sicurezza di rete (NSGs), che consentono di filtrare il traffico di rete da e verso le risorse di Azure nelle reti virtuali di Azure.
  • Utilizzare i gruppi di sicurezza delle applicazioni per raggruppare i server con requisiti di filtro delle porte simili, con funzioni simili, come ad esempio server Web e server di database.
  • Per i server Web e applicazioni, utilizzare la protezione DDoS (Distributed Denial of Service) di Azure. Gli attacchi DDoS sovraccaricano ed esauriscono le risorse di rete, rendendo le app lente o poco reattive. È comune che gli attacchi DDoS vengano destinati alle interfacce utente. La protezione DDoS di Azure sanifica il traffico di rete indesiderato, prima che influisca sulla disponibilità del servizio
  • Usare le estensioni della VM per gestire l'antimalware, lo stato desiderato, il rilevamento delle minacce, la prevenzione e la correzione, affrontando le minacce a livello di sistema operativo, computer e rete:
  • Usare Criteri di Azure per creare regole di business che possono essere applicate all'ambiente. Criteri di Azure valuta le risorse in Azure confrontando le proprietà di tali risorse con le regole aziendali in formato JSON.
  • Azure Blueprints consente agli architetti del cloud e ai gruppi centrali del settore IT di definire un set ripetibile di risorse di Azure per implementare e rispettare gli standard, i modelli e i requisiti di un'organizzazione. I criteri di Azure Blueprints sono diversi dai Criteri di Azure.
  • Usare Windows Server 2019 o Windows Server 2022 per essere conforme a FIPS con SQL Server nelle VM di Azure.

Caratteristiche di SQL Server

Di seguito è riportato un rapido elenco di controllo delle procedure consigliate per le impostazioni di configurazione di SQL Server durante l'esecuzione delle istanze di SQL Server in una macchina virtuale di Azure nell'ambiente di produzione:

Caratteristiche di Microsoft Azure

Di seguito è riportato un rapido elenco di controllo delle procedure consigliate per indicazioni specifiche di Azure durante l'esecuzione di SQL Server in una VM di Azure:

Configurazione HADR

L'elenco di controllo in questa sezione concerne le procedure consigliate HADR per SQL Server nelle VM di Azure.

Funzionalità di disponibilità elevata e ripristino di emergenza (HADR), ad esempio il gruppo di disponibilità Always On e l'istanza del cluster di failover si basano sulla tecnologia del Cluster di Failover del Server di Windows. Esaminare le procedure consigliate per modificare le impostazioni HADR per supportare al meglio l'ambiente cloud.

Per il cluster Windows, prendere in considerazione le seguenti procedure consigliate:

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

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

  • Se si verificano con frequenza errori imprevisti, seguire le procedure consigliate per le prestazioni descritte nel resto di questo articolo.
  • Se l'ottimizzazione delle prestazioni delle macchine virtuali di SQL Server non risolve i failover imprevisti, è consigliabile ridurre 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 potrebbe mascherare i sintomi riducendo la probabilità di errore. Potrebbe essere comunque necessario analizzare e risolvere la causa radice sottostante. Per Windows Server 2012 e versioni successive, usare i valori consigliati seguenti:
    • Timeout del lease: usare questa equazione per calcolare il valore massimo di timeout del lease:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Iniziare con 40 secondi. Se si usano i valori SameSubnetThreshold e SameSubnetDelay più flessibili consigliati in precedenza, non superare 80 secondi per il valore di timeout del lease.
    • Numero massimo di errori in un periodo specificato: impostare questo valore su 6.
  • Quando si usano il nome di rete virtuale (VNN) e Azure Load Balancer per connettersi alla soluzione HADR, specificare MultiSubnetFailover = true nella stringa di connessione, anche se il cluster si estende solo su una subnet.
    • Se il client non supporta MultiSubnetFailover = True, potrebbe essere necessario impostare RegisterAllProvidersIP = 0 e HostRecordTTL = 300 per memorizzare nella cache le credenziali del client per durate più brevi. Tuttavia, questa operazione può causare query aggiuntive al server DNS.
  • Per connettersi alla soluzione HADR usando il nome di rete distribuita (DNN), tenere presente quanto segue:
    • È necessario usare un driver del client che supporta MultiSubnetFailover = True, e questo parametro deve trovarsi nella stringa di connessione.
    • Usare una porta DNN univoca nella stringa di connessione durante la connessione 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 ignorare 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 operazioni di I/O non allineate. Per ulteriori informazioni, consultare KB3009974.
  • Se il motore del database di SQL Server, il listener del gruppo di disponibilità Always On o il probe di integrità dell'istanza del cluster di failover sono configurati per usare una porta compresa tra 49.152 e 65.536 (intervallo di porte dinamiche predefinito per TCP/IP), aggiungere un'esclusione per ogni porta. In questo modo, gli altri sistemi non possono essere assegnati dinamicamente alla stessa porta. L'esempio seguente crea un'esclusione per la porta 59.999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Risoluzione dei problemi di prestazioni

Di seguito è riportato un elenco di risorse che consentono di risolvere ulteriormente i problemi di prestazioni di SQL Server.

Contenuto correlato

Valutare l'abilitazione della valutazione SQL per SQL Server in VM di Azure.

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.