La migrazione di un'istanza di SQL Server locale a una macchina virtuale (VM) di Azure è un metodo comune per la migrazione ad Azure. I professionisti IT hanno familiarità con l'ambito delle dimensioni delle macchine virtuali per quanto riguarda vCPU, memoria e capacità di archiviazione. Microsoft offre più tipi e dimensioni di VM per le esigenze di un'organizzazione. Vedrai i tipi a cui si fa riferimento come Family nel portale di Azure durante il dimensionamento di una macchina virtuale.
Tipi e dimensioni di VM
Microsoft ha contribuito a semplificare le cose creando più tipi di macchine virtuali. I tipi sono orientati alla definizione delle macchine in base allo scopo. I vari tipi sono:
- Uso generico:rapporto CPU-memoria bilanciato, database di piccole e medie dimensioni
- Ottimizzazione per il calcolo:rapporto CPU-memoria elevato, server Web e server applicativi a traffico medio
- Ottimizzazione per la memoria:elevato rapporto memoria/CPU, server di database relazionali, cache di dimensioni medio-grandi e analisi in memoria
- Ottimizzazione dello storage:throughput del disco e I/O elevati
- GPU:rendering grafico e editing video pesanti
- Elaborazione ad alte prestazioni:le macchine virtuali con CPU più veloci e potenti
All'interno di ogni tipo/famiglia ci sono numerose dimensioni tra cui scegliere. Le dimensioni offrono opzioni per il numero di vCPU, RAM e dischi dati. Il numero di dischi dati determinerà gli IOPS massimi (IOPS sta per operazioni di input/output al secondo) e la dimensione complessiva determinerà la quantità di memoria temporanea disponibile. Alcune dimensioni supportano anche l'archiviazione premium, che dovrebbe essere un requisito per un SQL Server di produzione.
Opzioni immagine VM
Quando si seleziona un'immagine per SQL Server, sono disponibili diverse opzioni. Puoi scegliere di selezionare solo il sistema operativo, come Linux o Windows, oppure puoi scegliere di selezionare un'immagine con il sistema operativo e SQL Server già installati. Attualmente preferisco scegliere l'immagine con solo il sistema operativo in modo da poter installare SQL Server e configurarlo come mi piace. Quando scegli l'immagine della raccolta con SQL Server preinstallato, vengono installati tutti i componenti inclusi nell'ISO per quella versione e non sempre è necessario che Integration Services o Analysis Services siano installati.
Considerazioni sul dimensionamento della VM
La selezione di una macchina virtuale di Azure può sembrare semplice, con la scelta di una dimensione in base al numero di vCPU, memoria e spazio di archiviazione sufficiente per contenere i database, tuttavia vedo che i clienti hanno problemi di prestazioni relativi all'archiviazione. La tendenza comune è quella di scegliere una macchina virtuale basata esclusivamente su vCPU, memoria e capacità di archiviazione senza eseguire il benchmark degli attuali requisiti di I/O e velocità effettiva. Quando crei una macchina virtuale di Azure nel portale di Azure, puoi filtrare le opzioni in base a quanto segue:
- Dimensioni
- Generazione
- Famiglia
- RAM/memoria
- Supporto per l'archiviazione premium
- Numero di vCPU
- Disco del sistema operativo effimero
Dopo aver selezionato le opzioni di filtro, se presenti, vedrai un elenco di server disponibili. Nell'elenco vengono visualizzate le dimensioni della VM, l'offerta, la famiglia, la vCPU, la RAM, il numero di dischi dati supportati, gli IOPS massimi, l'archiviazione temporanea (D:), se è supportato il disco premium e il costo stimato. Ho filtrato quanto segue su un disco premium supportato e dimensioni che iniziano con la lettera E per ottimizzare la memoria.
Ciò che non viene visualizzato, tuttavia, è la quantità di throughput consentita per VM. Il throughput misura la velocità di trasferimento dei dati da e verso il supporto di archiviazione in megabyte al secondo.
Il rendimento può essere calcolato utilizzando la seguente formula
MB/s =IOPS * KB per IO / 1.024
Usando questa formula, KB per IO sarebbe la dimensione del tuo blocco. Se stai formattando i dati e le unità di registro a 64k, la formula per le VM E2s_v3, E4-2s_v3 ed E8-2s_v3 con 3.200, 6.400 e 12.800 IOPS sarebbe:
MB/s =3.200 * 64/1.024 o 200 MB/s
MB/s =6.400 * 64/1.024 o 400 MB/s
MB/s =12.800 * 64/1.024 o 800 MB/s
I calcoli del throughput basati sugli IOPS di ciascuna macchina virtuale con una dimensione del blocco di 64k non sono male. Questi numeri non prendono in considerazione eventuali penalità di scrittura per RAID. Ho testato ciascuna di queste macchine virtuali utilizzando CrystalDiskMark. I numeri che ho ottenuto per il throughput non erano affatto vicini a quelli stimati dai calcoli.
Test comparativo
Ho eseguito il provisioning di tre macchine virtuali della stessa famiglia, ma di dimensioni diverse, e ciascuna con 2 vCPU. Le specifiche delle macchine virtuali erano:
- E2s_v3 – 2 vCPU – 16 GB RAM – 3.200 IOPS – Supporta fino a 4 dischi dati
- E4-2s_v3 – 2 vCPU – 32 GB RAM – 6.400 IOPS – Supporta fino a 8 dischi dati
- E8-2s_v3 – 2 vCPU – 64 GB RAM – 12.800 IOPS – Supporta fino a 16 dischi dati
- Disco dati P60 – SSD Premium – 16.000 IOPS
Su ciascuna macchina virtuale, ho eseguito il provisioning di un disco premium P60 con una capacità di 8 TB. Questo disco annunciava 16.000 IOPS che con una dimensione del blocco di 64.000 potrebbero supportare una velocità effettiva di 1.000 MBps, tuttavia la documentazione di Azure afferma che il disco fornisce una velocità effettiva di 500 MBps.
CrystalDiskMark è uno strumento di benchmark per unità disco open source per Windows ed è basato sullo strumento Diskspd di Microsoft. Lo strumento misura le prestazioni sequenziali e casuali di letture e scritture.
Nella parte superiore dello strumento ci sono alcuni menu a discesa. Il numero 5 è il numero di iterazioni del test che verranno eseguite. Il prossimo è 1GiB, questa è la dimensione del file di test. Per un vero test di produzione, questo dovrebbe essere abbastanza grande da evitare di colpire la cache. La versione 7.0 supporta un file fino a 64 GiB. L'ultima è l'unità su cui vuoi eseguire il test.
Una volta effettuata la selezione, puoi fare clic su Tutti per iniziare la serie di test. Il test eseguirà ciclicamente varie operazioni di lettura/scrittura sequenziali e casuali. Prestare attenzione se si prevede di confrontare i server di produzione reali. Questo test mette a dura prova il tuo disco e potrebbe avere un impatto drastico su un carico di lavoro di produzione. Sarebbe preferibile dopo ore o durante una finestra di manutenzione.
Ho scelto di eseguire 5 iterazioni del test con un file da 32 GiB sul disco P60 che era l'unità E:.
La VM E2s_v3 ha raggiunto il massimo sotto i 50 MBps, che è molto inferiore ai 200 MB che abbiamo calcolato.
La VM E4-2s_v3 ha raggiunto il limite massimo di 100 MBps anziché 400 MBps.
La VM E8-2s_v3 ha raggiunto il massimo sotto i 200 MBps anziché gli 800 MBps stimati.
Perché ridurre il throughput?
Sulla base dei miei calcoli precedenti, 3.200 IOPS con una dimensione del blocco di 64k dovrebbero produrre un throughput di 200 MB, ma non ho visto numeri simili fino a quando non ho avuto un disco da 16.000 IOPS su una macchina virtuale che supporta fino a 12.800 IOPS. Il ragionamento è che ogni dimensione della macchina virtuale ha un limite per la velocità effettiva. Se guardi la documentazione per la famiglia di macchine virtuali ottimizzate per la memoria, scoprirai che il throughput massimo del disco non memorizzato nella cache di E2 è 3.200 IOPS/48 MBps, il throughput massimo del disco non memorizzato nella cache di E4 è 6.400 IOPS/96 MBps e il disco non memorizzato nella cache massima di E8s il throughput è di 12.800 IOPS/192 MBps. Questi numeri coincidono con i risultati che ho ottenuto utilizzando CrystalDiskMark.
Anche se puoi allocare dischi molto grandi che hanno molti IOPS e che supportano numeri di throughput elevati, la dimensione della VM potrebbe benissimo limitare il tuo throughput.
Il benchmarking delle tue attuali esigenze di velocità effettiva dovrebbe essere una priorità assoluta prima di migrare qualsiasi carico di lavoro di SQL Server ad Azure.
Conclusione
Comprendo che IOPS è un'unità di misura fornita dai produttori di dischi e dai fornitori di storage, e va bene. Tuttavia, quando si tratta di testare lo storage, tendiamo a concentrarci maggiormente sui numeri di throughput. È solo un problema di matematica, ma a meno che tu non sia nel business del benchmarking dello storage e dei calcoli da IOPS a throughput in base alla dimensione del blocco, può creare confusione.
Ciò che mi preoccupa è il fatto che la restrizione sulla velocità effettiva non è chiara quando si seleziona una dimensione della macchina virtuale. L'unità di misura per lo storage IO è IOPS. A 3.200 IOPS con una dimensione del blocco di 64k, potevo essere di circa 200 MBps, tuttavia la mia VM era limitata a 48 MBps. Molti professionisti IT hanno scoperto di avere problemi di prestazioni del disco e hanno ridimensionato il loro spazio di archiviazione su un disco più grande e veloce (più IOPS) aspettandosi prestazioni migliori, solo per scoprire che non ha risolto il loro problema. Il problema è che la dimensione della VM ne limitava la velocità effettiva. Il ridimensionamento a una VM di dimensioni maggiori risolverebbe il problema, ma ciò comporta un costo. Nel mio esempio, l'E4 costava il doppio dell'E2, tuttavia raddoppiava la memoria e il throughput, pur mantenendo la stessa vCPU. L'E8 costava il doppio dell'E4 e raddoppiava il throughput e la memoria, pur mantenendo la stessa vCPU. Mantenere lo stesso numero di vCPU significa che non avrei un aumento del costo della licenza di base di SQL Server.
In definitiva, è necessario confrontare i requisiti di velocità effettiva attuali e assicurarsi di dimensionare la macchina virtuale di Azure o qualsiasi macchina virtuale in modo appropriato per le proprie esigenze. Non concentrarti solo su un benchmark del tuo storage locale, analizza ciò di cui il tuo carico di lavoro ha bisogno e dimensiona di conseguenza.
