Microsoft gør det stadig nemmere at køre SQL Server 2014 på en virtuel Azure-maskine i et af Microsofts sytten Azure-datacentre. Du kan køre en forudkonfigureret virtuel maskine med en forudkonfigureret SQL Server 2014-instans fra Azure-galleriet på dit valg af enhver størrelse Azure-virtuel maskine. Et af valgene fra galleriet er "SQL Server 2014 Enterprise Optimized for Transactional Workloads", der kører på Windows Server 2012 R2. En god ting ved at bruge et prækonfigureret galleribillede er, at du ikke skal betale for nogen SQL Server 2014-licenser. Du betaler blot timeprisen for den udgave af SQL Server og den virtuelle maskinstørrelse, du vælger.
SQL Server 2014-konfigurationsindstillinger
Microsoft forklarer, at "Dette Enterprise Edition-billede er optimeret til OLTP-arbejdsbelastninger og er beregnet til VM-størrelser inklusive A4, A7, A8 og A9. Når den først er installeret, leveres VM'en med Windows Storage Spaces forudkonfigureret." Microsoft udfører også noget konfigurationsarbejde på instansniveau på SQL Server 2014, selvom de ikke går langt nok med, hvad jeg ville betragte som standard bedste praksis.
De opretter otte tempdb-datafiler, der alle er 25.600 MB i størrelse, med en autogrow-stigning på 1024 MB, hvilket er et godt standardvalg. De aktiverer også TF1117 og TF1118 som opstartssporingsflag, som også er gode valg til SQL Server. Endelig muliggør Microsoft også øjeblikkelig filinitialisering og låse sider i hukommelsen i styresystemet, hvilket jeg også er enig i.
Jeg ville foretrække, at Microsoft også lavede nogle ændringer til disse konfigurationsmuligheder på instansniveau:
- standard for backup-komprimering
- omkostningstærskel for parallelitet
- maksimal grad af parallelitet
- maks. serverhukommelse (MB)
- optimer til ad hoc-arbejdsbelastninger
Backup-komprimering bør være aktiveret som standard i de fleste tilfælde. Omkostningsgrænsen for parallelitet bør ofte hæves til en højere værdi end standardværdien på 5, afhængigt af din arbejdsbyrde. Max grad af parallelitet bør normalt ændres til en ikke-standardværdi baseret på antallet af kerner i en NUMA-knude. Denne indstilling afhænger også af din arbejdsbyrde. Max serverhukommelse bør indstilles til en ikke-standardværdi baseret på mængden af RAM i den virtuelle maskine, og hvad du kører (udover SQL Server-databasemotoren) på VM'en. Endelig tror jeg, at optimering til ad hoc-arbejdsbelastninger bør være aktiveret, stort set i alle tilfælde.
Til Microsofts forsvar ville det være vanskeligt at træffe et tilfredsstillende konfigurationsvalg for nogle af disse elementer uden at kende (på forhånd) detaljerne om din VM-størrelse og forventede databaseserverarbejdsbelastning. Det lader opgaven være op til dig, ligesom med en lokal SQL Server-instans.
Azure Virtual Machine Sizing
Selvom du kan vælge alt fra en A0 Basic til en A9 Standard-maskine, anbefaler Microsoft, at du vælger enten en A4 Standard-, A7 Standard-, A8 Standard- eller A9 Standard-størrelse virtuel maskine til produktionsbrug. Prisoplysninger for virtuelle SQL Server-maskiner er angivet her.
Ser man på de sammenlignende specifikationer for disse anbefalinger i tabel 1, er det svært at forstå, hvorfor du ønsker at vælge en A4 Standard maskine, da den koster det samme beløb i timen som de større A7 eller A8 Standard maskiner. Ser man på online dokumentationen, er det i første omgang ikke særlig klart, hvad den reelle forskel er mellem en A7 og en A8 Standard maskine. Graver man lidt dybere, betragtes A8 Standard-maskinen som en Compute Intensive-instans, som formodes at bruge en hurtigere 2,6GHz Intel Xeon E5-2670-processor sammen med to netværksadaptere (en 10Gbps og en 32Gbps RDMA-kompatibel).
Den virtuelle A7 Standard-maskine bruger en noget langsommere 2,2GHz Intel Xeon E5-2660-processor, mens netværksforbindelsen ser ud til at være standard 1Gbps Ethernet. Selvom dette lyder som en væsentlig forskel i processor- og netværksydelse, er det egentlig ikke hovedproblemet med A-seriens virtuelle maskiner til SQL Server-brug.
| VM-størrelse | SQL Standard Rate | SQL Enterprise Rate | Kerneantal | RAM-mængde |
|---|---|---|---|---|
| A4 Standard | $0,80/time | 3,00 USD/time | 8 | 14 GB |
| A7 Standard | $0,80/time | 3,00 USD/time | 8 | 56 GB |
| A8 Standard | $0,80/time | 3,00 USD/time | 8 | 56 GB |
| A9 Standard | 1,60 USD/time | 6,00 USD/time | 16 | 112 GB |
Tabel 1:A-Series SQL Server Virtual Machine Information
Hovedproblemet med alle A-seriens virtuelle maskiner er den ret elendige I/O-undersystemydelse, selvom Microsoft har forudkonfigureret diskundersystemet med Windows Storage Spaces for at få den bedst mulige ydeevne givet de iboende ydeevnebegrænsninger af A- serie virtuelle maskiner og værter. Figur 1 viser CrystalDiskMark-resultaterne for E:-drevet fra en A4 Standard-maskine fra det østlige amerikanske Azure-datacenter, som er beregnet til transaktionslogfiler.
Figur 1:A4 Standard CrystalDiskMark-resultater
Et meget bedre alternativ til SQL Server er de virtuelle maskiner i D-serien. Disse virtuelle maskiner koster det samme i timen som de sammenlignelige størrelser virtuelle maskiner i A-serien, og de har lokal SSD-lagring, der kun bør bruges til tempdb og/eller til buffer pool extensions (BPE) filer, da de ikke er persistente. Nogle relevante specifikationer for virtuelle maskiner i D-serien er vist i tabel 2.
| VM-størrelse | SQL Standard Rate | SQL Enterprise Rate | Kerneantal | RAM-mængde |
|---|---|---|---|---|
| D4 Standard | $0,80/time | 3,00 USD/time | 8 | 28 GB |
| D13 Standard | $0,80/time | 3,00 USD/time | 8 | 56 GB |
| D14 Standard | 1,60 USD/time | 6,00 USD/time | 16 | 112 GB |
Tabel 2:D-Series SQL Server Virtual Machine Information
D4 Standard-maskinen koster det samme som en A4 Standard-maskine, men den har dobbelt så meget RAM og noget lokalt SSD-lager. D13 Standard-maskinen koster det samme som en A7 eller A8 Standard-maskine, men med fordel af lokal SDD-lagring. D14 Standard-maskinen koster det samme som en A9 Standard-maskine, men har også fordelen af lokal SSD-lagring. I betragtning af disse oplysninger giver det ikke meget mening at bruge en virtuel maskine i A-serien til SQL Server.
Desværre har de permanente drev til dine SQL Server-data og logfiler også ret substandard I/O-ydeevne i CrystalDiskMark, som vist i figur 2 og 3.
 Figur 2:D14 Standard CrystalDiskMark-resultater |  Figur 3:D14 Standard CrystalDiskMark-resultater |
Den lokale SSD-ydeevne er relateret til størrelsen på den virtuelle Azure-maskine, hvor større størrelser får bedre lokal SSD-ydeevne. CrystalDiskMark-ydeevneresultaterne for en D14 Standard-maskine i det østlige amerikanske Azure-datacenter er vist i figur 4.
Figur 4:D14 Standard CrystalDiskMark-resultater for lokal SSD-lagring
F:-drevet (til SQL Server-datafiler) har lidt bedre resultater end E:-drevet, men begge drev har et meget lavt ydelsesniveau for SQL Server.
Konklusion
Det ser ret klart ud, at maskinerne i D-serien er bedre til SQL Server-brug end maskinerne i A-serien. Det giver også mening at være meget opmærksom på størrelsen og prissætningen af den virtuelle maskine, du beslutter dig for at levere til SQL Server, da du kan få mere RAM til samme timepris. De to bedste valg ud fra et præstationsperspektiv er de virtuelle D13- eller D14 Standard-maskiner.
De prækonfigurerede SQL Server 2014-instanser fra Azure-galleriet kan spare dig for mange penge i SQL Server-licensomkostninger, og de har allerede meget af det nødvendige konfigurationsarbejde fuldført i basisbilledet. Du bør stadig gå ind og foretage et par endelige konfigurationsændringer baseret på dine præferencer og arbejdsbyrde. Endelig bør du tage dig tid til at køre nogle præstationsbenchmarks på din virtuelle maskine, så du forstår niveauet af ydeevne, den kan levere.