Fördelar med att använda Azure NetApp Files för SQL Server-distribution
Azure NetApp Files minskar den totala ägandekostnaden för SQL Server (TCO) jämfört med blocklagringslösningar. Med blocklagring har virtuella datorer infört gränser för I/O och bandbredd för diskåtgärder. Endast nätverksbandbreddsgränser tillämpas mot Azure NetApp Files och endast på utgående trafik. Med andra ord tillämpas inga I/O-gränser på VM-nivå på Azure NetApp Files. Utan dessa I/O-gränser kan SQL Server som körs på mindre virtuella datorer som är anslutna till Azure NetApp Files fungera samt SQL Server som körs på mycket större virtuella datorer. Genom att minska storleken på instanser minskar beräkningskostnaden till 25 % av den tidigare prislappen. Du kan minska beräkningskostnaderna med Azure NetApp Files.
Beräkningskostnaderna är dock små jämfört med SQL Server-licenskostnader. Microsoft SQL Server-licensiering är kopplat till antalet fysiska kärnor. Därför medför en minskande instansstorlek en ännu större kostnadsbesparingar för programvarulicensiering. Du kan minska kostnaderna för programvarulicenser med Azure NetApp Files.
Den här artikeln visar en detaljerad kostnadsanalys och prestandafördelar med att använda Azure NetApp Files för SQL Server-distribution. Mindre instanser har inte bara tillräckligt med PROCESSOR för att databasen bara ska fungera med blockering på större instanser, i många fall är de mindre instanserna ännu mer högpresterande än deras större diskbaserade motsvarigheter på grund av Azure NetApp Files.
Detaljerad kostnadsanalys
De två uppsättningarna grafik i det här avsnittet visar TCO-exemplet. Antalet och typen av hanterade diskar, tjänstnivån Azure NetApp Files och kapaciteten för varje scenario har valts för att uppnå bästa pris-kapacitet-prestanda. Varje bild består av grupperade datorer (D16 med Azure NetApp Files, jämfört med D64 med hanterad disk efter exempel), och priserna delas upp för varje datortyp.
Den första uppsättningen grafik visar den totala kostnaden för lösningen med en databasstorlek på 1 TiB och jämför D16s_v4 med D64, D8 till D32 och D4 till D16. De planerade IOP:erna för varje konfiguration indikeras av en grön eller gul linje och motsvarar Y-axeln på höger sida.
Den andra uppsättningen grafik visar den totala kostnaden med hjälp av en 50-TiB-databas. Jämförelserna är i övrigt desamma – D16 jämfört med Azure NetApp Files jämfört med D64 med block by example.
Prestanda och mycket av det
För att kunna leverera den betydande kostnadsminsknings försäkran krävs massor av prestanda – de största instanserna i den allmänna Azure-inventeringen stöder 80 000 disk-IOPS per exempel. En enda Azure NetApp Files-volym kan uppnå 80 000 databas-IOPS, och instanser som D16 kan använda samma. D16, som normalt klarar 25 600 disk-IOPS, är 25 % av D64-storleken. Den D64s_v4 klarar av 80 000 disk-IOPS och utgör därför en utmärkt jämförelsepunkt på den övre nivån.
D16s_v4 kan köra en Azure NetApp Files-volym till 80 000 databas-IOPS. Som framgår av benchmarkingverktyget för SQL Storage Benchmark (SSB) uppnådde D16-instansen en arbetsbelastning som var 125 % större än den som kunde uppnås för disken från D64-instansen. Mer information om verktyget finns i avsnittet SSB-testverktyg .
Med en 1-TiB-arbetsuppsättningsstorlek och en 80 % läsning, 20 % uppdatering av SQL Server-arbetsbelastningen mättes prestandafunktionerna för de flesta instanser i D-instansklassen. de flesta, inte alla, eftersom själva D2- och D64-instanserna exkluderades från testning. Det förstnämnda utelämnades eftersom det inte stöder accelererat nätverk, och det senare eftersom det är jämförelsepunkten. Se följande diagram för att förstå gränserna för D4s_v4, D8s_v4, D16s_v4 respektive D32s_v4. Hanterade disklagringstester visas inte i diagrammet. Jämförelsevärden hämtas direkt från tabellen azure virtual machine limits för klassinstanstypen D.
Med Azure NetApp Files kan var och en av instanserna i D-klassen uppfylla eller överskrida diskprestandafunktionerna för instanser två gånger större. Du kan minska kostnaderna för programvarulicenser avsevärt med Azure NetApp Files.
- D4 vid 75 % cpu-användning matchade diskfunktionerna i D16.
- D16 är hastighetsbegränsat till 25 600 disk-IOPS.
- D8 vid 75 % cpu-användning matchade diskfunktionerna i D32.
- D32 är hastighetsbegränsat till 51 200 disk-IOPS.
- D16 vid 55 % cpu-användning matchade diskfunktionerna i D64.
- D64 är hastighetsbegränsat till 80 000 disk-IOPS.
- D32 vid 15 % processoranvändning matchade även diskfunktionerna i D64.
- D64 som anges ovan är hastighetsbegränsat till 80 000 disk-IOPS.
Test av S3B-CPU-gränser – Prestanda jämfört med bearbetningskraft
I följande diagram sammanfattas testet av S3B-cpu-gränser:
Skalbarhet är bara en del av berättelsen. Den andra delen är svarstid. Det är en sak för mindre virtuella datorer att ha möjlighet att köra mycket högre I/O-priser, det är en annan sak att göra det med låga ensiffriga svarstider som visas nedan.
- D4 körde 26 000 IOPS mot Azure NetApp Files med svarstid på 2,3 ms.
- D8 körde 51 000 IOPS mot Azure NetApp Files med 2,0 ms svarstid.
- D16 körde 88 000 IOPS mot Azure NetApp Files med 2,8 ms svarstid.
- D32 körde 80 000 IOPS mot Azure NetApp Files med 2,4 ms svarstid.
Svarstidsresultat för S3B per instanstyp
Följande diagram visar svarstiden för SQL Server med en instans över Azure NetApp Files:
SSB-testverktyg
TPC-E-benchmarking-verktyget betonar avsiktligt beräkning snarare än lagring. Testresultaten som visas i det här avsnittet baseras på ett stresstestverktyg med namnet SQL Storage Benchmark (SSB). SQL Server Storage Benchmark kan köra sql-körning i massiv skala mot en SQL Server-databas för att simulera en OLTP-arbetsbelastning, ungefär som benchmarkingverktyget för SLOB2 Oracle.
SSB-verktyget genererar en SELECT- och UPDATE-driven arbetsbelastning som utfärdar dessa instruktioner direkt till SQL Server-databasen som körs på den virtuella Azure-datorn. För det här projektet ökade SSB-arbetsbelastningarna från 1 till 100 SQL Server-användare, med 10 eller 12 mellanliggande punkter på 15 minuter per antal användare. Alla prestandamått från dessa körningar var ur perfmonsynpunkt, för repeterbarhet kördeS SSB tre gånger per scenario.
Själva testerna konfigurerades som 80 % SELECT och 20 % UPDATE-instruktion, vilket innebär att 90 % slumpmässig läsning. Själva databasen, som SSB skapade, var 1 000 GB stor. Den består av 15 användartabeller och 9 000 000 rader per användartabell och 8 192 byte per rad.
SSB-riktmärket är ett verktyg med öppen källkod. Den är fritt tillgänglig på SQL Storage Benchmark GitHub-sidan.
Sammanfattningsvis
Med Azure NetApp Files kan du öka SQL-serverprestandan samtidigt som du minskar den totala ägandekostnaden avsevärt.