La scelta delle dimensioni corrette delle macchine virtuali è importante per ottenere performance ottimali di un database relazionale in un cloud pubblico. Microsoft consiglia di continuare a utilizzare le stesse opzioni di ottimizzazione delle performance del database applicabili a SQL Server in ambienti server on-premise. Utilizzare "ottimizzato per la memoria" Dimensioni delle macchine virtuali per le migliori performance dei carichi di lavoro di SQL Server. Raccogliere i dati sulle performance dell'implementazione esistente per identificare l'utilizzo della RAM e della CPU, scegliendo le istanze giuste. La maggior parte delle implementazioni sceglie tra le serie D, e o M.

Note:

Per aumentare la ridondanza e l'alta disponibilità, le VM di SQL Server devono essere uguali "set di disponibilità" o diverso "zone di disponibilità". Quando si creano macchine virtuali Azure, è necessario scegliere tra la configurazione dei set di disponibilità e le zone di disponibilità; una macchina virtuale Azure non può partecipare a entrambe.

Per l'alta disponibilità, la configurazione di SQL Server AOAG o Always on failover Cluster Instance (FCI) è l'opzione migliore. Per AOAG, questo comporta istanze multiple di SQL Server su macchine virtuali Azure in una rete virtuale. Se è richiesta una disponibilità elevata a livello di database, considerare la configurazione dei gruppi di disponibilità di SQL Server.

Microsoft SQL Server può essere implementato con una condivisione file SMB come opzione di storage. A partire da SQL Server 2012, database di sistema (master, modello, msdb o tempdb), Inoltre, i database degli utenti possono essere installati con il file server SMB (Server message Block) come opzione di storage. Questo vale sia per SQL Server standalone che per SQL Server FCI.

Azure NetApp Files offre storage di file dalle performance elevate per soddisfare qualsiasi carico di lavoro impegnativo e riduce il TCO di SQL Server rispetto alle soluzioni di storage a blocchi. Con lo storage a blocchi, le macchine virtuali hanno imposto limiti di i/o e larghezza di banda per le operazioni su disco; i limiti di larghezza di banda della rete vengono applicati solo a fronte di Azure NetApp Files. In altre parole, non vengono applicati limiti di i/o a livello di macchina virtuale a Azure NetApp Files. Senza questi limiti di i/o, SQL Server in esecuzione su macchine virtuali più piccole collegate a Azure NetApp Files può funzionare e SQL Server in esecuzione su macchine virtuali molto più grandi. Azure NetApp Files riduce i costi di implementazione di SQL Server riducendo i costi di licenza software e di calcolo. Per un'analisi dettagliata dei costi e i vantaggi delle performance derivanti dall'utilizzo di Azure NetApp Files per la distribuzione di SQL Server, vedere "Vantaggi dell'utilizzo di Azure NetApp Files per la distribuzione di SQL Server".

Crea condivisioni continuamente disponibili con il portale Azure o Azure CLI. Nel portale, selezionare l'opzione della proprietà Enable Continuous Availability (attiva disponibilità continua). Per Azure CLI, specificare la condivisione come condivisione a disponibilità continua utilizzando az netappfiles volume create with the smb-continuously-avl opzione impostata su $True. Per ulteriori informazioni sulla creazione di un nuovo volume abilitato per la disponibilità continua, vedere "Creazione di una condivisione a disponibilità continua".

Note:

Azure NetApp Files supporta tre livelli di servizio: Standard (16 Mbps per terabyte), Premium (64 MB per terabyte) e Ultra (128 MB per terabyte). Il provisioning delle giuste dimensioni del volume è importante per ottenere performance ottimali del carico di lavoro del database. Con Azure NetApp Files, le performance dei volumi e il limite di throughput si basano su una combinazione dei seguenti fattori:

Per ulteriori informazioni, vedere "Livelli di servizio per Azure NetApp Files".

Come per qualsiasi implementazione, il test della macchina virtuale e dello storage è fondamentale. Per la convalida dello storage, strumenti come HammerDB, Apploader, "Tool di benchmark dello storage (SB) di SQL Server", O qualsiasi script personalizzato o FIO con il mix di lettura/scrittura appropriato. Tenere presente tuttavia che la maggior parte dei carichi di lavoro di SQL Server, anche i carichi di lavoro OLTP occupati, sono più vicini al 80%-90% in lettura e al 10%-20% in scrittura.

Per mostrare le performance, è stato eseguito un rapido test su un volume utilizzando livelli di servizio premium. In questo test, le dimensioni del volume sono state aumentate da 100 GB a 2 TB in tempo reale senza alcuna interruzione dell'accesso alle applicazioni e senza alcuna migrazione dei dati.

Ecco un altro esempio di test delle performance in tempo reale con HammerDB eseguito per l'implementazione trattata in questo documento. Per questo test, abbiamo utilizzato una piccola istanza con otto vCPU, un SSD Premium da 500 GB e un volume Azure NetApp Files SMB da 500 GB. HammerDB è stato configurato con 80 warehouse e otto utenti.

Il grafico seguente mostra che Azure NetApp Files è stato in grado di offrire un numero di transazioni al minuto 2,6 volte superiore con una latenza 4 volte inferiore quando si utilizza un volume di dimensioni paragonabili (500 GB).

Un test aggiuntivo è stato eseguito ridimensionando in un'istanza più grande con 32x vCPU e un volume Azure NetApp Files da 16 TB. Si è verificato un aumento significativo delle transazioni al minuto con una latenza costante di 1 ms. HammerDB è stato configurato con 80 warehouse e 64 utenti per questo test.

Azure NetApp Files consente di ridimensionare il volume in modo trasparente e senza interruzioni e di modificare i livelli di servizio senza downtime e senza alcun effetto sulle applicazioni. Si tratta di una funzionalità unica che consente una gestione dinamica dei costi che evita la necessità di eseguire il dimensionamento del database con metriche di picco. Puoi invece utilizzare carichi di lavoro a stato stazionario, evitando i costi iniziali. La risagomatura del volume e la modifica dinamica del livello di servizio consentono di regolare la larghezza di banda e il livello di servizio dei volumi Azure NetApp Files on-demand quasi istantaneamente senza interrompere l'i/o, mantenendo al contempo l'accesso ai dati.

Le offerte PaaS di Azure, come LogicApp o le funzioni, possono essere utilizzate per ridimensionare facilmente il volume in base a un webhook specifico o a un trigger di regola di avviso per soddisfare le esigenze dei carichi di lavoro gestendo dinamicamente i costi.

Ad esempio, si consideri un database che richiede 250 MBps per il funzionamento a stato stazionario; tuttavia, richiede anche un throughput di picco di 400 Mbps. In questo caso, l'implementazione deve essere eseguita con un volume da 4 TB all'interno del livello di servizio Premium per soddisfare i requisiti di performance stazionario. Per gestire il carico di lavoro di picco, aumentare le dimensioni del volume utilizzando le funzioni di Azure fino a 7 TB per quel periodo specifico, quindi ridurre il volume per rendere l'implementazione conveniente. Questa configurazione evita l'overprovisioning dello storage.