Lagring: Metodtips för prestanda för SQL Server på virtuella Azure-datorer

gäller för:SQL Server på virtuella Azure-datorer

Den här artikeln innehåller metodtips och riktlinjer för lagring för att optimera prestanda för DIN SQL Server på virtuella Azure-datorer (VM). Lär dig hur du väljer rätt disktyper, konfigurerar lagringspooler och implementerar cachelagringsstrategier för att maximera databasens prestanda.

Det finns vanligtvis en kompromiss mellan att optimera för kostnader och optimera prestanda. Den här serien med metodtips för prestanda fokuserar på att få bästa prestanda för SQL Server på virtuella Azure-datorer. Om din arbetsbelastning är mindre krävande kanske du inte behöver varje rekommenderad optimering. Tänk på dina prestandabehov, kostnader och arbetsbelastningsmönster när du utvärderar dessa rekommendationer.

Mer information finns i de andra artiklarna i den här serien: Checklista, VM-storlek, Security, HADR-konfigurationoch Samla in baslinje.

Checklista

Läs följande checklista för en kort översikt över de metodtips för lagring som beskrivs i resten av artikeln mer detaljerat:

• Övervaka programmet och fastställa kraven på lagringsbandbredd och svarstid för SQL Server-data, loggfiler och tempdb filer innan du väljer disktyp.
• Om tillgänglig, konfigurera tempdb data- och loggfilerna på D: lokala SSD-volymen när du distribuerar en ny virtuell maskin eller efter att du har installerat SQL Server manuellt. SQL IaaS-agenttillägget hanterar mappen och behörigheterna som behövs vid ometablering.
• Optimera lagringsprestanda genom att planera för högsta tillgängliga okapaciterade IOPS och använda cachelagring som en prestandafunktion för dataläsningar, samtidigt som du undviker begränsningar på virtuella datorer och diskar.
• När du använder sql server-datorerna i Ebdsv5 eller Ebsv5-serien använder du Premium SSD v2- för bästa prisprestanda. Du kan distribuera din virtuella SQL Server-dator med Premium SSD v2 med hjälp av Azure-portalen (för närvarande i förhandsversion).
• Om din arbetsbelastning kräver mer än 160 000 IOPS använder du Premium SSD v2 eller Azure Ultra Disks.
• Placera data, loggfiler och tempdb filer på separata enheter.
  • För dataenheten använder du Premium P30- och P40-diskar eller mindre diskar för att säkerställa tillgängligheten för cachestöd. När du använder Ebdsv5 VM-serienanvänder du Premium SSD v2 som ger bättre prisprestanda för arbetsbelastningar som kräver högt IOPS- och I/O-dataflöde.
  • För loggdrivplanen för kapacitet och testprestanda jämfört med kostnad vid utvärdering av antingen Premium SSD v2 eller Premium SSD-P30 – P80-diskar
    • Om lagringsfördröjning undermillisekunder krävs använder du antingen Premium SSD v2 eller Azure ultradiskar för transaktionsloggen.
    • För distributioner av virtuella datorer i M-serien bör du överväga att använda skrivaccelerator istället för att använda Azure Ultra-diskar.
  • Placera tempdb på den temporära disken (den temporära disken är föränderlig och som standard är D:\) för de flesta SQL Server-arbetsbelastningar som inte är del av en felöverlämning klusterinstans (FCI) efter att ha valt den optimala VM-storleken.
    • Om kapaciteten på den lokala enheten inte räcker för tempdbbör du överväga att storleksanpassa den virtuella datorn. Mer information finns i principer för cachelagring av datafiler.
  • För redundansklusterinstanser (FCI) placera tempdb på den delade lagringen.
    • Om FCI-arbetsbelastningen är starkt beroende av diskprestandan för tempdb, placera då tempdb i en avancerad konfiguration på den lokala tillfälliga SSD-enheten (standard D:\), som inte ingår i FCI-lagringen. Den här konfigurationen behöver anpassad övervakning och åtgärd för att säkerställa att den lokala tillfälliga SSD-enheten (standard D:\) är tillgänglig hela tiden eftersom eventuella fel på den här enheten inte utlöser åtgärder från FCI.
• Stripe flera Azure-datadiskar med Lagringsutrymmen för att öka I/O-bandbredden upp till måldatorns IOPS- och dataflödesgränser.
• Ange värdkachning till skrivskyddad för datafildiskar.
• Ange värdcache till inget för diskar med loggfiler.
  • Aktivera inte cachelagring av läsning/skrivning på diskar som innehåller SQL Server-data eller loggfiler.
  • Stoppa alltid SQL Server-tjänsten innan du ändrar cacheinställningarna för disken.
• När du migrerar flera olika arbetsbelastningar till molnet kan Azure Elastic SAN- vara en kostnadseffektiv konsoliderad lagringslösning. När du använder Azure Elastic SAN kräver det dock ofta överetableringskapacitet för att uppnå önskat IOPS/dataflöde för SQL Server-arbetsbelastningar. Även om det vanligtvis inte är lämpligt för enskilda SQL Server-arbetsbelastningar kan du uppnå en kostnadseffektiv lösning när du kombinerar arbetsbelastningar med låga prestanda med SQL Server.
• För utveckling och testning av arbetsbelastningar och långsiktig säkerhetskopieringsarkivering bör du överväga att använda standardlagring. Vi rekommenderar inte att du använder Standard HDD/SSD för produktionsarbetsbelastningar.
• Kreditbaserad disköverbelastning (P1-P20) bör endast övervägas för mindre arbetsbelastningar för utveckling och testning samt system på avdelningsnivå.
• Optimera lagringsprestanda genom att planera för de högsta tillgängliga okachade IOPS och använda datacachelagring som en prestandafunktion för dataläsningar, samtidigt som du undviker att begränsa/flaskhalsar virtuella maskiner och diskar.
• Formatera datadisken så att den använder 64 KB allokeringsenhetsstorlek för alla datafiler som placeras på en annan enhet än den tillfälliga D:\ enheten (som har standardvärdet 4 KB). Virtuella SQL Server-datorer som distribueras via Azure Marketplace har datadiskar som är formaterade med allokeringsenhetsstorlek och interleave för lagringspoolen inställd på 64 KB.
• Konfigurera lagringskontot i samma region som den virtuella SQL Server-datorn.
• Inaktivera Geo-redundant lagring i Azure (geo-replikering) och använd LRS (lokal redundant lagring) på lagringskontot.
• Aktivera SQL Best Practices Assessment för att identifiera möjliga prestandaproblem och utvärdera att den virtuella SQL Server-datorn är konfigurerad för att följa bästa praxis.
• Granska och övervaka disk- och VM-gränser med hjälp av lagrings-I/O-användningsmått.
• Undanta SQL Server-filer från genomsökning av antivirusprogram, inklusive datafiler, loggfiler och säkerhetskopieringsfiler.
• Ändra storlek på lagringspoolen på rätt sätt.

För att jämföra lagringschecklistan med andra bästa praxis, se checklistan för omfattande bästa praxis för prestanda .

Överblick

Om du vill hitta den mest effektiva konfigurationen för SQL Server-arbetsbelastningar på en virtuell Azure-dator börjar du med att mäta lagringsprestandan för ditt affärsprogram. När lagringskraven är kända väljer du en virtuell dator som stöder nödvändig IOPS och dataflöde med rätt förhållande mellan minne och virtuell kärna.

Välj en VM-storlek med tillräcklig lagringsskalbarhet för din arbetsbelastning och en blandning av diskar (vanligtvis i en lagringspool) som uppfyller företagets kapacitets- och prestandakrav.

Vilken typ av disk som är beroende av både den filtyp som finns på disken och dina högsta prestandakrav.

Disktyper för virtuella datorer

Du har ett val i prestandanivån för dina diskar. De typer av hanterade diskar som är tillgängliga som underliggande lagring (som anges genom att öka prestandafunktionerna) är standardhårddiskenheter (HDD), SSD (Standard Solid State Drives), Premium SSD, Premium SSD v2 och Ultra Disks.

För Standard HDD, Standard SSD och Premium SSD ökar diskens prestanda med storleken på disken, grupperad efter premiumdisketiketter till exempel P1 med 4 GiB utrymme och 120 IOPS till P80 med 32 TiB lagringsutrymme och 20 000 IOPS. Premium Storage har stöd för en lagringscache som hjälper till att förbättra läs- och skrivprestanda för vissa arbetsbelastningar. Mer information finns i översikten över hanterade diskar.

Prestanda för Premium SSD v2 och Ultra Disks kan ändras oberoende av diskens storlek. Mer information finns i Ultra-diskprestanda och Premium SSD v2-prestanda. Om din arbetsbelastning kräver mer än 160 000 IOPS kan du överväga att använda Premium SSD v2 eller Ultra Disks.

Det finns också tre huvudsakliga diskroller att tänka på för din SQL Server på en virtuell Azure-dator – en OS-disk, en tillfällig disk och dina datadiskar. Välj noggrant vad som lagras på operativsystemenheten (C:\) och den tillfälliga enheten (D:\).

Operativsystemdisk

En operativsystemdisk är en virtuell hårddisk som kan startas och monteras som en körande version av ett operativsystem och märkt som enhet C:\. När du skapar en virtuell Azure-dator ansluter plattformen minst en disk till den virtuella datorn för operativsystemdisken. C:\-enheten är standardplatsen för programinstallationer och filkonfiguration.

För SQL Server-produktionsmiljöer ska du inte använda operativsystemdisken för datafiler, loggfiler, felloggar.

Tillfällig disk

Många virtuella Azure-datorer innehåller en annan disktyp som kallas tillfällig disk (märkt som den D:\ enheten). Beroende på VM-serien och storleken på den här disken varierar kapaciteten. Den temporära disken är flyktig, vilket innebär att disklagringen återskapas (det vill säga frigörs och allokeras igen) när den virtuella datorn startas om eller flyttas till en annan värd (till exempel vid tjänståterställning).

Den tillfälliga lagringsenheten sparas inte på fjärrlagring och bör därför inte lagra användardatabasfiler, transaktionsloggfiler eller något som måste bevaras. Du kan till exempel använda den för buffertpoolstillägg, sidfilen och tempdb.

Placera tempdb på den lokala tillfälliga SSD-D:\ enheten för SQL Server-arbetsbelastningar om inte förbrukning av lokal cache är ett problem. Om du använder en virtuell dator som inte har någon tillfällig disk rekommenderar vi att du placerar tempdb på en egen isolerad disk eller lagringspool med cachelagring inställd på skrivskyddad. Mer information finns i tempdb-datacachelagringsprinciper.

Datadiskar

Datadiskar är fjärrlagringsdiskar som ofta skapas i lagringspooler för att överskrida den kapacitet och prestanda som en enskild disk kan erbjuda den virtuella datorn.

Koppla det minsta antalet diskar som uppfyller IOPS-, dataflödes- och kapacitetskraven för din arbetsbelastning. Överskrid inte det maximala antalet datadiskar för den minsta virtuella datorn som du planerar att ändra storlek till.

Placera data och loggfiler på datadiskar som etablerats efter bästa prestandakrav.

Formatera datadisken så att den använder 64 KB allokeringsenhetsstorlek för alla datafiler som placeras på en annan enhet än den tillfälliga D:\ enheten (som har standardvärdet 4 KB). Virtuella SQL Server-datorer som distribueras via Azure Marketplace har datadiskar som är formaterade med allokeringsenhetsstorlek och interleave för lagringspoolen inställd på 64 KB.

Premium SSD v2

Du bör använda Premium SSD v2 diskar när du kör SQL Server-arbetsbelastningar i regioner som stöds, om de aktuella begränsningarna är lämpliga för din miljö. Beroende på din konfiguration kan Premium SSD v2 vara billigare än Premium SSD, samtidigt som prestandaförbättringar uppnås. Med Premium SSD v2 kan du individuellt justera ditt dataflöde eller IOPS oberoende av diskens storlek. Om du kan justera prestandaalternativen individuellt kan du göra detta större kostnadsbesparingar och göra så att du kan utföra skriptändringar för att uppfylla prestandakraven under förväntade eller kända perioder av behov.

Vi rekommenderar att du använder Premium SSD v2 när du använder Ebdsv5- eller Ebsv5-serien för virtuella datorer eftersom det är en mer kostnadseffektiv lösning för dessa datorer med högt I/O-dataflöde. Om din arbetsbelastning kräver mer än 160 000 IOPS kan du överväga att använda Premium SSD v2 eller Ultra Disks.

Du kan distribuera dina virtuella SQL Server-datorer med Premium SSD v2 med hjälp av Azure-portalen (för närvarande i förhandsversion).

Om du distribuerar din virtuella SQL Server-dator med hjälp av Azure-portalen och vill använda Premium SSD v2 är du för närvarande begränsad till de virtuella datorerna i Ebdsv5- eller Ebsv5-serien. Men om du skapar den virtuella datorn manuellt med Premium SSD v2-lagring och sedan installerar SQL Server manuellt på den virtuella datorn kan du använda alla VM-serier som stöder Premium SSD v2. Se till att registrera din virtuella SQL Server-dator med SQL IaaS Agent-tillägget så att du kan dra nytta av alla fördelar som tillägget ger.

Elastiskt SAN-nätverk i Azure

Azure Elastic SAN- är ett nätverksanslutet lagringserbjudande som ger kunderna en flexibel och skalbar lösning som kan minska kostnaderna genom lagringskonsolidering. Azure Elastic SAN levererar en kostnadseffektiv, högpresterande och tillförlitlig blocklagringslösning som ansluter till en mängd olika Azure-beräkningstjänster via iSCSI-protokollet. Elastic SAN möjliggör en sömlös övergång från en befintlig SAN-lagringsegendom till molnet utan att behöva omstrukturera kundens programarkitektur.

Den här lösningen kan skala upp till miljontals IOPS, tvåsiffriga GB/s dataflöde och låga ensiffriga svarstider för millisekunder, med inbyggd återhämtning för att minimera stilleståndstiden. Använd Azure Elastic SAN om du behöver konsolidera lagring, arbeta med flera beräkningstjänster eller ha arbetsbelastningar som kräver höga dataflödesnivåer när du kör lagring över nätverksbandbredd. Men eftersom det ofta krävs överprovisionering av kapacitet för att uppnå önskat IOPS/dataflöde för SQL Server-arbetsbelastningar är det vanligtvis inte lämpligt för enskilda SQL Server-arbetsbelastningar. För att uppnå den mest kostnadseffektiva lösningen med Elastic SAN kan du överväga att använda den som lagring för flera SQL Server-arbetsbelastningar eller en kombination av SQL Server och andra arbetsbelastningar med låg prestanda.

Överväg att placera SQL Server-arbetsbelastningar på Elastic SAN för bättre kostnadseffektivitet, lagringskonsolidering, dynamisk prestandadelning och för att öka dataflödet för lagring.

Premium SSD

Använd Premium SSD för data och loggfiler för SQL Server-produktionsarbetsbelastningar. Premium SSD IOPS och bandbredd varierar beroende på diskstorlek och typ.

För produktionsarbetsbelastningar använder du P30- och/eller P40-diskarna för SQL Server-datafiler för att säkerställa cachelagringsstöd och använda P30 upp till P80 för SQL Server-transaktionsloggfiler. För den bästa totala ägandekostnaden börjar du med P30s (5 000 IOPS/200 Mbit/s) för data och loggfiler och väljer bara högre kapaciteter när du behöver kontrollera antalet virtuella datorer. För dev/test eller små system kan du välja att använda storlekar som är mindre än P30 eftersom dessa stöder cachelagring, men de erbjuder inte reserverade priser.

För OLTP-arbetsbelastningar matchar du mål-IOPS per disk (eller lagringspool) med dina prestandakrav med hjälp av arbetsbelastningar vid hög belastning och Disk Reads/sec + Disk Writes/sec prestandaräknare. För datalager- och rapporteringsarbetsbelastningar anpassar du måldataflödet efter arbetsbelastningar under hög belastning samt Disk Read Bytes/sec + Disk Write Bytes/sec.

Använd Lagringsutrymmen för att uppnå optimala prestanda, konfigurera två pooler, en för loggfilerna och den andra för datafilerna. Om du inte använder disklistning använder du två Premium SSD-diskar mappade till separata enheter, där den ena enheten innehåller loggfilen och den andra innehåller data.

Den konfigurerade IOPS och genomströmning per disk som används som en del av din lagringspool. Diskarnas kombinerade IOPS- och dataflödesfunktioner är den maximala kapaciteten upp till dataflödesgränserna för den virtuella datorn.

Det bästa sättet är att använda så många diskar som möjligt samtidigt som du uppfyller de minsta kraven för IOPS (och dataflöde) och kapacitet. Pris- och prestandabalansen tenderar dock att vara bättre med ett stort antal små diskar snarare än ett litet antal stora diskar.

Justera premiumdiskar

Storleken på din Premium SSD avgör diskens initiala prestandanivå. Ange prestandanivån vid distributionen eller ändra den efteråt, utan att ändra diskens storlek. Om efterfrågan ökar kan du öka prestandanivån för att uppfylla dina affärsbehov.

Om du ändrar prestandanivån kan administratörer förbereda sig för och möta högre efterfrågan utan att förlita sig på disksprängning.

Använd högre prestanda så länge som det behövs där faktureringen är utformad för att uppfylla lagringsprestandanivån. Uppgradera nivån så att den matchar prestandakraven utan att öka kapaciteten. Gå tillbaka till den ursprungliga nivån när den extra prestandan inte längre krävs.

Den här kostnadseffektiva och tillfälliga prestandaökningen är ett starkt användningsfall för riktade händelser som shopping, prestandatestning, träningshändelser och andra korta fönster där bättre prestanda endast behövs på kort sikt.

Mer information finns i Prestandanivåer för hanterade diskar.

Azure Ultra Disk

Om det finns behov av svarstider för undermillisekunder med lägre latens kan du överväga att använda Azure ultradisk för SQL Server-loggdriven eller till och med datadriven för program som är extremt känsliga för I/O-latens.

Ultradisk kan konfigureras där kapacitet och IOPS kan skalas separat. Med ultradiskar kan administratörer tilldela en disk med krav på kapacitet, IOPS och dataflöde baserat på programbehov.

Ultradisk stöds inte i alla VM-serier och har andra begränsningar som regiontillgänglighet, redundans och stöd för Azure Backup. Mer information finns i Använda Azure-ultradiskar för en fullständig lista över begränsningar.

Standard HDD och SSD

Standard HDD:er och SSD har varierande svarstider och bandbredd och rekommenderas endast för dev/test-arbetsbelastningar. Produktionsbelastningar bör använda Premium-SSD:er v2 eller Premium-SSD:er. Om du använder Standard SSD (utvecklings-/testscenarier) rekommenderar vi att du lägger till det maximala antalet datadiskar som stöds av din VM-storlek och använder disklistning med Lagringsutrymmen för bästa prestanda.

Cachelagring

Virtuella datorer som stöder cachelagring i Premium Storage kan dra nytta av ytterligare en funktion som kallas Azure BlobCache eller värdcachelagring för att utöka IOPS- och dataflödesfunktionerna för en virtuell dator. Virtuella datorer som är aktiverade för både Premium Storage- och Premium Storage-cachelagring har dessa två olika gränser för lagringsbandbredd som kan användas tillsammans för att förbättra lagringsprestandan.

IOPS och MBps genomströmning utan cache räknas mot en virtuell dators ogränsade diskgenomflödesgränser. De maximala cachelagrade gränserna ger en annan buffert för läsningar som hjälper till att hantera tillväxt och oväntade toppar.

Aktivera premiumcachelagring när alternativet stöds för att avsevärt förbättra prestanda för läsningar mot dataenheten utan extra kostnad.

Läsningar och skrivningar till Azure BlobCache (cachelagrad IOPS och genomströmning) räknas inte mot den virtuella datorns icke-cachelagrade IOPS- och genomströmningsgränser.

Icke-cachelagrat dataflöde

Maximalt IOPS och dataflöde för oansluten disk är den maximala gränsen för fjärrlagring som den virtuella datorn kan hantera. Den här gränsen definieras på den virtuella datorn och är inte en gräns för den underliggande disklagringen. Den här gränsen gäller endast för I/O mot dataenheter som fjärransluts till den virtuella datorn, inte den lokala I/O-enheten mot den temporära enheten (D:\ enhet) eller OS-enheten.

Mängden oanvänd IOPS och dataflöde som är tillgängligt för en virtuell dator kan verifieras i dokumentationen för den virtuella datorn.

Dokumentationen för M-serien visar till exempel att det maximala okästad dataflödet för den virtuella Standard_M8ms-datorn är 5000 IOPS och 125 MB/s okästad diskgenomströmning.

På samma sätt kan du se att Standard_M32ts stöder 20 000 icke-cachelagrade disk-IOPS och 500 MB/s icke-cachelagrat diskläsningshastighet. Den här gränsen styrs på VM-nivå oavsett den underliggande premiumdisklagringen.

Mer information finns i ej åtkomliga och cachelagrade gränser.

Cachelagrat och temporärt lagringsdataflöde

Gränsen för maximalt cachelagrat och temporärt lagringsdataflöde är en separat gräns från gränsen för oåtkomt dataflöde på den virtuella datorn. Azure BlobCache består av en kombination av värddatorns RAM-minne och lokalt ansluten SSD. Den temporära enheten (D:\ enhet) på den virtuella datorn finns också på den här lokala SSD:n.

Gränsen för maximalt cachelagringsflöde och temporärt lagringsflöde styr I/O mot den lokala temporära enheten (D:\ enhet) och Azure BlobCache endast om värdcache är aktiverad.

När cachelagring är aktiverat på Premium Storage kan virtuella datorer skalas utöver begränsningarna för den fjärranslutna virtuella datorns IOPS- och dataflödesgränser.

Endast vissa virtuella datorer stöder både Premium Storage och cachelagring av Premium Storage (vilket måste verifieras i dokumentationen för den virtuella datorn). Dokumentationen M-serien anger till exempel att både premiumlagring och premiumcachelagring stöds:

Gränserna för cacheminnet varierar beroende på storleken på den virtuella datorn. Till exempel stöder den Standard_M8ms virtuella datorn 10000 cachelagrad disk-IOPS och 1 000 Mbit/s cachelagrat diskdataflöde med en total cachestorlek på 793 GiB. På samma sätt stöder den Standard_M32ts virtuella datorn 40000 cachelagrad disk-IOPS och 400 Mbit/s cachelagrat diskdataflöde med en total cachestorlek på 3 174 GiB.

Du kan aktivera cachelagring av värd manuellt på en befintlig virtuell dator. Stoppa alla programarbetsbelastningar och SQL Server-tjänsterna innan några ändringar görs i den virtuella datorns cachelagringsprincip. Om du ändrar inställningarna för vm-cachen kopplas måldisken från och kopplas tillbaka när inställningarna har tillämpats.

Principer för cachelagring av datafiler

Din cachelagringsprincip för lagring varierar beroende på vilken typ av SQL Server-datafiler som finns på enheten.

Följande tabell innehåller en sammanfattning av de rekommenderade cachelagringsprinciperna baserat på typen av SQL Server-data:

Mer information finns i Diskcachelagring.

Diskstrypning

Analysera dataflödet och bandbredden som krävs för dina SQL-datafiler för att fastställa antalet datadiskar, inklusive loggfilen och tempdb. Dataflödes- och bandbreddsgränserna varierar beroende på vm-storlek. Mer information finns i VM-storlekar.

Lägg till fler datadiskar och använd disklistning för mer dataflöde. Ett program som till exempel behöver 12 000 IOPS- och 180 MB/s-dataflöde kan använda tre randiga P30-diskar för att leverera 15 000 IOPS och 600 MB/s dataflöde.

Information om hur du konfigurerar diskstripping finns i diskstripping.

Diskbegränsning

Det finns dataflödesgränser på både disk- och VM-nivå. De maximala IOPS-gränserna per virtuell dator och disk skiljer sig åt och är oberoende av varandra.

Applikationer som förbrukar resurser bortom dessa gränser kommer att strypas (kallas även begränsade). Välj en virtuell dator och diskstorlek i en diskremsa som uppfyller programkraven och inte stöter på begränsningsgränser. Använd cachelagring eller justera programmet så att mindre dataflöde krävs för att åtgärda begränsningen.

Ett program som till exempel behöver 12 000 IOPS och 180 MB/s kan:

• Använd Standard_M32ms, som har ett maximalt oanvänt diskdataflöde på 20 000 IOPS och 500 Mbit/s.
• Använd stripe-konfiguration med tre P30-diskar för att leverera 15 000 IOPS och 600 MB/s genomströmning.
• Använd en Standard_M16ms virtuell dator och använd värdcachelagring för att utnyttja den lokala cachen istället för att förbruka dataflöde.

Virtuella datorer som har konfigurerats för att skalas upp under tider med hög användning bör etablera lagring med tillräckligt med IOPS och dataflöde för att stödja den maximala VM-storleken samtidigt som det totala antalet diskar hålls mindre än eller lika med det maximala antal som stöds av den minsta virtuella datorns SKU som ska användas.

För mer information om begränsningstak för disk och användning av cache för att undvika dessa tak, se disk-I/O-begränsning.

Skriv Acceleration

Skrivacceleration är en diskfunktion som endast är tillgänglig för de virtuella datorerna i M-serien. Syftet med skrivacceleration är att förbättra I/O-svarstiden för skrivningar mot Azure Premium Storage när du behöver ensiffrig I/O-svarstid på grund av viktiga OLTP-arbetsbelastningar eller informationslagermiljöer med hög volym.

Använd Skrivacceleration för att förbättra skrivfördröjningen till den enhet som är värd för loggfilerna. Använd inte skrivacceleration för SQL Server-datafiler.

Skrivacceleratordiskar delar samma IOPS-gräns som den virtuella datorn. Anslutna diskar får inte överskrida IOPS-gränsen för skrivningsacceleratorer för en virtuell dator.

I följande tabell beskrivs antalet datadiskar och IOPS som stöds per virtuell dator:

Det finns flera begränsningar för att använda skrivacceleration. Mer information finns i Begränsningar när du använder Write Accelerator.

Jämför med Azure Ultra Disk

Den största skillnaden mellan skrivacceleration och Azure ultradiskar är att skrivacceleration är en vm-funktion som endast är tillgänglig för M-serien och Azure Ultra Disks är ett lagringsalternativ. Skrivacceleration är en skrivoptimerad cache med sina egna begränsningar baserat på vm-storleken. Azure Ultra Disks är ett disklagringsalternativ med låg fördröjning för virtuella Azure-datorer.

Använd om möjligt skrivacceleration över ultradiskar för transaktionsloggdisken. För virtuella datorer som inte stöder skrivacceleration men som kräver låg svarstid till transaktionsloggen använder du Azure Ultra Disks.

Ändra storlek på lagringspooler på rätt sätt

När du vill ändra storlek på en lagringspool i Azure gör du det genom att ändra antalet diskar i poolen i stället för att ändra storleken på diskarna som redan finns i poolen. Om du ändrar storleken på de virtuella eller fysiska diskarna i en lagringspool ökar inte volymens tillgängliga utrymme när den finns i lagringspoolen, så det ökade diskutrymmet används inte och slösas bort.

För SQL Server på virtuella Azure-datorer som distribueras från Azure Marketplace med premium-SSD (v1) läggs diskar automatiskt till i lagringspoolen och du kan använda fönstret Lagring för resursen för virtuella SQL-datorer i Azure-portalen för att ändra storlek på diskarna i lagringspoolen.

För SQL Server på Azure VM Marketplace-avbildningar som använder Premium SSD v2-diskar, ultradiskar eller virtuella datorer med självinstallerade SQL Server-instanser ändrar du manuellt antalet diskar i lagringspoolen för att ändra volymstorleken.

Följ till exempel de här stegen för att expandera en lagringspool:

1. Lägg till en ny disk:
   1. Ansluta en hanterad disk i Azure-portalen
   2. Ansluta en hanterad disk med PowerShell
   3. Koppla en ohanterad disk med PowerShell
2. Anslut till den virtuella datorn.
3. Lägg till diskarna i lagringspoolen från serverhanterarens> fil- och lagringstjänstvolymer >> lagringspooler. Använd Uppgifter för att välja alternativet Lägg till fysisk disk .
4. När disken har lagts till högerklickar du på den virtuella måldisken och väljer Utöka virtuell disk.
5. Öppna Diskhantering, högerklicka på målvolymen och välj Utöka volym.

Övervaka lagringsprestanda

För att utvärdera lagringsbehoven och avgöra hur bra lagringen presterar måste du förstå vad som ska mätas och vad dessa indikatorer innebär.

IOPS (indata/utdata per sekund) är antalet begäranden som programmet gör till lagring per sekund. Mät IOPS med hjälp av prestandaövervakarens räknare Disk Reads/sec och Disk Writes/sec. OLTP (onlinetransaktionsbearbetning) program måste köra högre IOPS för att uppnå optimala prestanda. Program som betalningsbearbetningssystem, online-shopping och system för försäljningsställen är alla exempel på OLTP-program.

Genomströmning är den datavolym som skickas till den underliggande lagringen, ofta mätt i megabyte per sekund. Mät dataflödet med prestandaövervakarens räknare Disk Read Bytes/sec och Disk Write Bytes/sec. Datavarehus är optimerade för att maximera dataflödet snarare än IOPS. Program som datalager för analys, rapportering, ETL-arbetsströmmar och andra business intelligence-mål är alla exempel på program för datalagerhantering.

I/O-enhetsstorlekar påverkar IOPS- och dataflödesfunktioner eftersom mindre I/O-storlekar ger högre IOPS och större I/O-storlekar ger högre dataflöde. SQL Server väljer den optimala I/O-storleken automatiskt. Mer information om finns i Optimera IOPS, dataflöde och svarstid för dina program.

Det finns specifika Azure Monitor-mått som är ovärderliga för identifiering av tak på vm- och disknivå samt förbrukning och hälsotillstånd för AzureBlob-cachen. Information om hur du identifierar viktiga räknare som ska läggas till i övervakningslösningen och instrumentpanelen i Azure-portalen finns i Mått för lagringsanvändning.

Övervaka transaktionsloggens tillväxt

Eftersom en fullständig transaktionslogg kan leda till prestandaproblem och avbrott är det viktigt att övervaka det tillgängliga utrymmet i transaktionsloggen samt det diskutrymme som används på den enhet som innehåller transaktionsloggen. Åtgärda problem med transaktionsloggen innan de påverkar din arbetsbelastning.

Granska Felsöka en fullständig transaktionslogg om loggen har blivit full.

Om du behöver utöka disken kan du göra det i fönstret Storage för resursen virtuella SQL-datorer om du distribuerade en SQL Server-avbildning från Azure Marketplace eller i fönstret Diskar för din virtuella Azure-dator och självinstallerade SQL Server.

Nästa steg

Mer information finns i de andra artiklarna i den här serien med metodtips:

• Snabbchecklista

• VM-storlek

• Säkerhet

• HADR-inställningar

• Samla baslinjedata

• Metodtips för säkerhet finns i Säkerhetsöverväganden för SQL Server på Azure Virtual Machines.

• Detaljerad testning av SQL Server-prestanda på virtuella Azure-datorer med TPC-E och TPC_C benchmarks finns i bloggen Optimera OLTP-prestanda.

• Läs andra artiklar om SQL Server Virtual Machine på SQL Server på Azure Virtual Machines Overview. Om du har frågor om virtuella SQL Server-datorer kan du läsa Vanliga frågor och svar.