Microsoft gör det allt lättare att köra SQL Server 2014 på en virtuell Azure-maskin i ett av Microsofts sjutton Azure-datacenter. Du kan köra en förkonfigurerad virtuell maskin med en förkonfigurerad SQL Server 2014-instans från Azure-galleriet på valfri storlek på den virtuella Azure-maskinen. Ett av valen från galleriet är "SQL Server 2014 Enterprise Optimized for Transactional Workloads" som körs på Windows Server 2012 R2. En trevlig sak med att använda en förkonfigurerad galleribild är att du inte behöver betala för några SQL Server 2014-licenser. Du betalar helt enkelt timkostnaden för den version av SQL Server och virtuell maskinstorlek som du väljer.
SQL Server 2014-konfigurationsalternativ
Microsoft förklarar att "Denna Enterprise Edition-avbildning är optimerad för OLTP-arbetsbelastningar och är avsedd för VM-storlekar inklusive A4, A7, A8 och A9. När den väl har distribuerats kommer den virtuella datorn med Windows Storage Spaces förkonfigurerade." Microsoft gör också en del konfigurationsarbete på instansnivå på SQL Server 2014, även om de inte går tillräckligt långt med vad jag skulle anse vara vanliga bästa praxis.
De skapar åtta tempdb-datafiler som alla är 25 600 MB stora, med en autotillväxt på 1 024 MB, vilket är ett bra standardval. De aktiverar också TF1117 och TF1118 som startspårningsflaggor, vilket också är bra val för SQL Server. Slutligen möjliggör Microsoft även omedelbar filinitiering och låsa sidor i minnet i operativsystemet, vilket jag också håller med om.
Jag skulle föredra att Microsoft också gjorde några ändringar i dessa konfigurationsalternativ på instansnivå:
- standard för säkerhetskopieringskomprimering
- kostnadströskel för parallellism
- max grad av parallellitet
- max serverminne (MB)
- optimera för ad hoc-arbetsbelastningar
Säkerhetskopieringskomprimering bör vara aktiverad som standard i de flesta fall. Kostnadströskeln för parallellitet bör ofta höjas till ett högre värde än standardvärdet 5, beroende på din arbetsbelastning. Max grad av parallellitet bör vanligtvis ändras till ett icke-standardvärde baserat på antalet kärnor i en NUMA-nod. Den här inställningen beror också på din arbetsbelastning. Max serverminne bör ställas in på ett icke-standardvärde baserat på mängden RAM i den virtuella maskinen och vad du kör (förutom SQL Server-databasmotorn) på den virtuella datorn. Slutligen tror jag att optimering för ad hoc-arbetsbelastningar bör vara aktiverat, i stort sett i alla fall.
Till Microsofts försvar skulle det vara svårt att göra ett tillfredsställande konfigurationsval för vissa av dessa objekt utan att veta (i förväg) detaljerna om din virtuella dators storlek och förväntade databasserverarbetsbelastning. Det lämnar uppgiften upp till dig, precis som med en lokal SQL Server-instans.
Azure Virtual Machine Sizing
Även om du kan välja allt från en A0 Basic till en A9 Standard-maskin, rekommenderar Microsoft att du väljer antingen en A4 Standard, A7 Standard, A8 Standard eller A9 Standard storlek virtuell maskin för produktionsanvändning. Prisinformation för virtuella SQL Server-maskiner listas här.
Om man tittar på de jämförande specifikationerna för dessa rekommendationer i Tabell 1 är det svårt att förstå varför du skulle vilja välja en A4 Standard-maskin, eftersom den kostar samma summa per timme som de större A7 eller A8 Standard-maskinerna. När man tittar på onlinedokumentationen är det initialt inte särskilt tydligt vad den faktiska skillnaden är mellan en A7 och en A8 Standard-maskin. Om man gräver lite djupare anses A8 Standard-maskinen vara en Compute Intensive-instans, som är tänkt att använda en snabbare 2,6 GHz Intel Xeon E5-2670-processor, tillsammans med två nätverksadaptrar (en 10Gbps och en 32Gbps RDMA-kapabel).
Den virtuella maskinen A7 Standard använder en något långsammare 2,2 GHz Intel Xeon E5-2660-processor, medan nätverksanslutningen verkar vara standard 1 Gbps Ethernet. Även om detta låter som en betydande skillnad i processor- och nätverksprestanda, är det inte riktigt huvudproblemet med A-seriens virtuella maskiner för SQL Server-användning.
| VM-storlek | SQL Standard Rate | SQL Enterprise Rate | Antal kärnor | RAM-mängd |
|---|---|---|---|---|
| A4 Standard | 0,80 USD/timme | 3,00 USD/timme | 8 | 14 GB |
| A7 Standard | 0,80 USD/timme | 3,00 USD/timme | 8 | 56 GB |
| A8 Standard | 0,80 USD/timme | 3,00 USD/timme | 8 | 56 GB |
| A9 Standard | 1,60 USD/timme | 6,00 USD/timme | 16 | 112 GB |
Tabell 1:A-Series SQL Server Virtual Machine Information
Huvudproblemet med alla virtuella datorer i A-serien är den ganska eländiga I/O-undersystemets prestanda, även om Microsoft har förkonfigurerat diskundersystemet med Windows Storage Spaces för att få bästa möjliga prestanda med tanke på de inneboende prestandabegränsningarna hos A- serie virtuella maskiner och värdar. Figur 1 visar CrystalDiskMark-resultaten för E:-enheten från en A4 Standard-maskin från East US Azure datacenter, som är avsedd för transaktionsloggfiler.
Figur 1:A4 Standard CrystalDiskMark-resultat
Ett mycket bättre alternativ för SQL Server är de virtuella maskinerna i D-serien. Dessa virtuella maskiner kostar lika mycket per timme som de jämförbara stora virtuella maskinerna i A-serien, och de har lokal SSD-lagring som endast bör användas för tempdb- och/eller för buffertpooltillägg (BPE), eftersom de inte är beständiga. Några relevanta specifikationer för virtuella datorer i D-serien visas i Tabell 2.
| VM-storlek | SQL Standard Rate | SQL Enterprise Rate | Antal kärnor | RAM-mängd |
|---|---|---|---|---|
| D4 Standard | 0,80 USD/timme | 3,00 USD/timme | 8 | 28 GB |
| D13 Standard | 0,80 USD/timme | 3,00 USD/timme | 8 | 56 GB |
| D14 Standard | 1,60 USD/timme | 6,00 USD/timme | 16 | 112 GB |
Tabell 2:D-Series SQL Server Virtual Machine Information
D4 Standard-maskinen kostar lika mycket som en A4 Standard-maskin, men den har dubbelt så mycket RAM och lite lokal SSD-lagring. D13 Standard-maskinen kostar detsamma som en A7 eller A8 Standard-maskin, men med fördelen av lokal SDD-lagring. D14 Standard-maskinen kostar detsamma som en A9 Standard-maskin, men har också fördelen av lokal SSD-lagring. Med tanke på denna information är det inte meningsfullt att använda en virtuell maskin i A-serien för SQL Server.
Tyvärr har de permanenta enheterna för dina SQL Server-data och loggfiler också ganska undermålig I/O-prestanda i CrystalDiskMark, som visas i figur 2 och 3.
 Figur 2:D14 Standard CrystalDiskMark-resultat |  Figur 3:D14 Standard CrystalDiskMark-resultat |
Den lokala SSD-prestandan är relaterad till storleken på den virtuella Azure-maskinen, med större storlekar som ger bättre lokal SSD-prestanda. CrystalDiskMark-prestandaresultaten för en D14 Standard-maskin i East US Azure-datacentret visas i figur 4.
Figur 4:D14 Standard CrystalDiskMark-resultat för lokal SSD-lagring
F:-enheten (för SQL Server-datafiler) har något bättre resultat än E:-enheten, men båda enheterna har en mycket låg prestandanivå för SQL Server.
Slutsats
Det verkar ganska tydligt att D-seriens maskiner är bättre för SQL Server-användning än A-seriens maskiner. Det är också vettigt att vara uppmärksam på storleken och prissättningen av den virtuella maskin du bestämmer dig för att tillhandahålla för SQL Server, eftersom du kan få mer RAM till samma timkostnad. De två bästa valen ur ett prestandaperspektiv är de virtuella datorerna D13 eller D14 Standard.
De förkonfigurerade SQL Server 2014-instanserna från Azure-galleriet kan spara mycket pengar i SQL Server-licenskostnader, och de har mycket av det nödvändiga konfigurationsarbetet redan slutfört i basavbildningen. Du bör fortfarande gå in och göra några sista konfigurationsändringar baserat på dina preferenser och arbetsbelastning. Slutligen bör du ta dig tid att köra några prestandabenchmarks på din virtuella maskin så att du förstår nivån på prestanda som den kan leverera.