Delen via

Opslag: Best practices voor prestaties voor SQL Server op Azure-VM's

  • Artikel

Van toepassing op: SQL Server op Azure VM

Dit artikel bevat aanbevolen procedures en richtlijnen voor opslag voor het optimaliseren van de prestaties voor uw SQL Server op Azure Virtual Machines (VM).

Er is meestal een afweging tussen optimaliseren voor kosten en optimaliseren voor prestaties. Deze reeks aanbevolen procedures voor prestaties is gericht op het verkrijgen van de beste prestaties voor SQL Server op Azure-VM's. Als uw workload minder veeleisend is, hebt u mogelijk niet elke aanbevolen optimalisatie nodig. Houd rekening met uw prestatiebehoeften, kosten en workloadpatronen wanneer u deze aanbevelingen evalueert.

Zie de andere artikelen in deze reeks voor meer informatie: Controlelijst, VM-grootte, Beveiliging, HADR-configuratie en Basislijn verzamelen.

Checklijst

Bekijk de volgende controlelijst voor een kort overzicht van de aanbevolen procedures voor opslag die in de rest van het artikel in meer detail worden behandeld:

  • Bewaak de toepassing en bepaal de vereisten voor opslagbandbreedte en latentie voor SQL Server-gegevens, logboeken en tempdb bestanden voordat u het schijftype kiest.
  • Configureer indien beschikbaar de tempdbgegevens en logboekbestanden op het D: lokale SSD-volume. De SQL IaaS Agent-extensie verwerkt de map en machtigingen die nodig zijn bij het opnieuw inrichten.
  • Als u de opslagprestaties wilt optimaliseren, plant u de hoogst beschikbare IOPS zonder cache en gebruikt u gegevenscaching als prestatiefunctie voor gegevensleesbewerkingen en voor het voorkomen van limieten voor virtuele machines en schijven.
  • Overweeg het gebruik van Azure Elastic SAN voor SQL Server-workloads voor betere kostenefficiëntie vanwege opslagconsolidatie, gedeelde dynamische prestaties en de mogelijkheid om een hogere opslagdoorvoer te stimuleren zonder een vm te hoeven upgraden.
  • Plaats gegevens, logboeken en tempdb bestanden op afzonderlijke stations.
    • Voor het gegevensstation gebruikt u Premium P30- en P40- of kleinere schijven om de beschikbaarheid van cacheondersteuning te garanderen. Wanneer u de Ebdsv5-VM-serie gebruikt, gebruikt u Premium SSD v2 die betere prijsprestaties biedt voor workloads waarvoor een hoge IOPS- en I/O-doorvoer is vereist.
    • Voor het logboekstationplan voor capaciteit en testprestaties versus kosten tijdens het evalueren van Premium SSD v2 of Premium SSD P30 - P80-schijven
      • Als de opslaglatentie van submilliseconden is vereist, gebruikt u Premium SSD v2 of Azure Ultra Disks voor het transactielogboek.
      • Voor implementaties van virtuele machines uit de M-serie kunt u overwegen om schrijfversneller te gebruiken met behulp van Azure Ultra Disks.
    • Plaats tempdb op de tijdelijke schijf (de tijdelijke schijf is kortstondig en wordt standaard ingesteld D:\op ) voor de meeste SQL Server-workloads die geen deel uitmaken van een failoverclusterexemplaar (FCI) nadat u de optimale VM-grootte hebt gekozen.
      • Als de capaciteit van het lokale station niet voldoende tempdbis, kunt u overwegen om de grootte van de VIRTUELE machine te wijzigen. Zie Cachebeleid voor gegevensbestanden voor meer informatie.
    • Voor FCI-locatie tempdb in de gedeelde opslag.
      • Als de FCI-werkbelasting sterk afhankelijk is van tempdb schijfprestaties, is dit een geavanceerde configuratieplaats tempdb op het lokale tijdelijke SSD-station (standaard D:\) dat geen deel uitmaakt van FCI-opslag. Deze configuratie heeft aangepaste bewaking en actie nodig om ervoor te zorgen dat het lokale tijdelijke SSD-station (standaard D:\) altijd beschikbaar is, omdat eventuele fouten van dit station geen actie van FCI activeren.
  • Streep meerdere Azure-gegevensschijven met behulp van Opslagruimten om de I/O-bandbreedte te verhogen tot de IOPS- en doorvoerlimieten van de doel-VM.
  • Stel hostcaching in op alleen-lezen voor gegevensbestandsschijven.
  • Stel hostcaching in op geen voor logboekbestandsschijven.
    • Schakel lees-/schrijfcache niet in op schijven die SQL Server-gegevens of logboekbestanden bevatten.
    • Stop de SQL Server-service altijd voordat u de cache-instellingen van uw schijf wijzigt.
  • Voor ontwikkelings- en testworkloads en archivering van back-ups op lange termijn kunt u overwegen om standaardopslag te gebruiken. Het wordt niet aanbevolen om Standard HDD/SSD te gebruiken voor productieworkloads.
  • Disk Bursting (P1-P20) op basis van tegoed mag alleen worden overwogen voor kleinere ontwikkel-/testworkloads en afdelingssystemen.
  • Als u de opslagprestaties wilt optimaliseren, plant u de hoogst beschikbare IOPS zonder cache en gebruikt u gegevenscaching als prestatiefunctie voor gegevensleesbewerkingen en vermijdt u het beperken/beperken van virtuele machines en schijven.
  • Maak de gegevensschijf op om de grootte van de toewijzingseenheid van 64 kB te gebruiken voor alle gegevensbestanden die op een ander station zijn geplaatst dan het tijdelijke D:\ station (met een standaardwaarde van 4 kB). SQL Server-VM's die zijn geïmplementeerd via Azure Marketplace worden geleverd met gegevensschijven die zijn geformatteerd met de grootte van de toewijzingseenheid en interleave voor de opslaggroep die is ingesteld op 64 kB.
  • Configureer het opslagaccount in dezelfde regio als de SQL Server-VM.
  • Schakel geografisch redundante Azure-opslag (geo-replicatie) uit en gebruik LRS (lokale redundante opslag) in het opslagaccount.
  • Schakel de SQL Best Practices Assessment in om mogelijke prestatieproblemen te identificeren en te evalueren of uw SQL Server-VM is geconfigureerd om de aanbevolen procedures te volgen.
  • Controleer en bewaak schijf- en VM-limieten met behulp van metrische gegevens over opslag-IO-gebruik.
  • Sluit SQL Server-bestanden uit van het scannen van antivirussoftware, inclusief gegevensbestanden, logboekbestanden en back-upbestanden.

Als u de controlelijst voor opslag wilt vergelijken met de andere aanbevolen procedures, raadpleegt u de uitgebreide controlelijst voor best practices voor prestaties.

Overzicht

Als u de meest effectieve configuratie voor SQL Server-workloads op een Azure-VM wilt vinden, begint u met het meten van de opslagprestaties van uw bedrijfstoepassing. Zodra de opslagvereisten bekend zijn, selecteert u een virtuele machine die ondersteuning biedt voor de benodigde IOPS en doorvoer met de juiste verhouding tussen geheugen en vCore.

Kies een VM-grootte met voldoende schaalbaarheid voor opslag voor uw workload en een combinatie van schijven (meestal in een opslaggroep) die voldoen aan de capaciteits- en prestatievereisten van uw bedrijf.

Het type schijf is afhankelijk van zowel het bestandstype dat op de schijf wordt gehost als de piekvereisten voor prestaties.

Tip

Het inrichten van een SQL Server-VM via Azure Portal helpt u bij het configuratieproces voor opslag en implementeert de meeste aanbevolen procedures voor opslag, zoals het maken van afzonderlijke opslaggroepen voor uw gegevens en logboekbestanden, gericht op tempdb het D:\ station en het inschakelen van het optimale cachebeleid. Zie de configuratie van SQL VM-opslag voor meer informatie over het inrichten en configureren van opslag.

Typen VM-schijven

U hebt een keuze in het prestatieniveau voor uw schijven. De typen beheerde schijven die beschikbaar zijn als onderliggende opslag (vermeld door verbeterde prestatiemogelijkheden) zijn Standard-harde schijven (HDD), Standard SOLID-state drives (SSD), Premium SSD's, Premium SSD v2 en Ultra Disks.

Voor Standard-HDD's, Standard SSD's en Premium SSD's neemt de prestaties van de schijf toe met de grootte van de schijf, gegroepeerd op Premium-schijflabels zoals de P1 met 4 GiB ruimte en 120 IOPS naar de P80 met 32 TiB aan opslag en 20.000 IOPS. Premium Storage ondersteunt een opslagcache waarmee de lees- en schrijfprestaties voor sommige workloads worden verbeterd. Zie Het overzicht van beheerde schijven voor meer informatie.

De prestaties van Premium SSD v2 en Ultra Disks kunnen onafhankelijk van de grootte van de schijf worden gewijzigd, voor meer informatie, zie ultraschijfprestaties en Premium SSD v2-prestaties.

Er zijn ook drie hoofdschijfrollen die u kunt overwegen voor uw SQL Server op Azure VM: een besturingssysteemschijf, een tijdelijke schijf en uw gegevensschijven. Kies zorgvuldig wat is opgeslagen op het besturingssysteemstation (C:\) en het tijdelijke station (D:\).

Besturingssysteemschijf

Een besturingssysteemschijf is een VHD die kan worden opgestart en gekoppeld als een actieve versie van een besturingssysteem en is gelabeld als het C:\ station. Wanneer u een Azure-VM maakt, koppelt het platform ten minste één schijf aan de VIRTUELE machine voor de besturingssysteemschijf. Het C:\ station is de standaardlocatie voor installatie van toepassingen en bestandsconfiguratie.

Gebruik voor productie-SQL Server-omgevingen de besturingssysteemschijf niet voor gegevensbestanden, logboekbestanden en foutenlogboeken.

Tijdelijke schijf

Veel Virtuele Azure-machines bevatten een ander schijftype genaamd de tijdelijke schijf (gelabeld als het D:\ station). Afhankelijk van de VM-serie en de grootte van de capaciteit van deze schijf varieert. De tijdelijke schijf is kortstondig, wat betekent dat de schijfopslag opnieuw wordt gemaakt (zoals in, de toewijzing ervan ongedaan wordt gemaakt en opnieuw wordt toegewezen), wanneer de virtuele machine opnieuw wordt opgestart of naar een andere host wordt verplaatst (bijvoorbeeld voor serviceherstel).

Het tijdelijke opslagstation blijft niet behouden in de externe opslag en mag daarom geen gebruikersdatabasebestanden, transactielogboekbestanden of andere bestanden bevatten die behouden moeten blijven.

Plaats tempdb op het lokale tijdelijke SSD-station D:\ voor SQL Server-workloads, tenzij het verbruik van lokale cache een probleem is. Als u een virtuele machine gebruikt die geen tijdelijke schijf heeft, is het raadzaam om een eigen geïsoleerde schijf of opslaggroep te plaatsen tempdb met caching ingesteld op alleen-lezen. Zie tempdb-beleid voor gegevenscaching voor meer informatie.

Gegevensschijven

Gegevensschijven zijn externe opslagschijven die vaak in opslaggroepen worden gemaakt om de capaciteit en prestaties te overschrijden die elke enkele schijf aan de VIRTUELE machine kan bieden.

Koppel het minimale aantal schijven dat voldoet aan de IOPS-, doorvoer- en capaciteitsvereisten van uw workload. Overschrijd niet het maximum aantal gegevensschijven van de kleinste VM waarnaar u het formaat wilt wijzigen.

Plaats gegevens- en logboekbestanden op gegevensschijven die zijn ingericht voor de beste prestatievereisten.

Maak de gegevensschijf op om de grootte van de toewijzingseenheid van 64 kB te gebruiken voor alle gegevensbestanden die op een ander station zijn geplaatst dan het tijdelijke D:\ station (met een standaardwaarde van 4 kB). SQL Server-VM's die zijn geïmplementeerd via Azure Marketplace worden geleverd met gegevensschijven die zijn geformatteerd met de grootte van de toewijzingseenheid en interleave voor de opslaggroep die is ingesteld op 64 kB.

Notitie

Het is ook mogelijk om uw SQL Server-databasebestanden rechtstreeks in Azure Blob Storage of in SMB-opslag, zoals Azure Premium-bestandsshare, te hosten, maar we raden u aan beheerde Azure-schijven te gebruiken voor de beste prestaties, betrouwbaarheid en beschikbaarheid van functies.

Premium SSD v2

U moet Premium SSD v2-schijven gebruiken bij het uitvoeren van SQL Server-workloads in ondersteunde regio's, als de huidige beperkingen geschikt zijn voor uw omgeving. Afhankelijk van uw configuratie kan Premium SSD v2 goedkoper zijn dan Premium SSD-SSD's, terwijl ook prestatieverbeteringen worden geboden. Met Premium SSD v2 kunt u uw doorvoer of IOPS afzonderlijk aanpassen, onafhankelijk van de grootte van uw schijf. Als u prestatieopties afzonderlijk kunt aanpassen, kunt u deze grotere kostenbesparingen realiseren en kunt u scriptwijzigingen uitvoeren om te voldoen aan de prestatievereisten tijdens verwachte of bekende perioden van behoefte. We raden u aan Premium SSD v2 te gebruiken bij het gebruik van de Ebdsv5 VM-serie , omdat het een rendabelere oplossing is voor deze hoge I/O-doorvoermachines. Premium SSD v2 biedt momenteel geen ondersteuning voor hostcaching, dus het kiezen van een VM-grootte met een hoge niet-cachedoorvoer, zoals de VM's uit de Ebdsv5-serie, wordt aanbevolen.

Premium SSD v2-schijven worden momenteel niet ondersteund door installatiekopieën van de SQL Server-galerie, maar ze kunnen worden gebruikt met SQL Server op Azure-VM's wanneer ze handmatig zijn geconfigureerd.

Azure Elastic SAN

Azure Elastic SAN biedt een zeer schaalbare, rendabele, zeer krachtige en betrouwbare blokopslagoplossing die verbinding maakt met verschillende Azure-rekenservices via iSCSI-protocol. Elastisch SAN maakt een naadloze overgang mogelijk van een bestaande SAN-opslagomgeving naar de cloud zonder dat u de architectuur van de klanttoepassing hoeft te herstructureren. Deze oplossing kan enorme schaal bereiken: tot miljoenen IOPS, dubbele cijfers GB/s aan doorvoer en lage latenties van één milliseconden met ingebouwde tolerantie om downtime te minimaliseren. Dit maakt het een uitstekende keuze voor klanten die opslag willen consolideren, klanten die met meerdere rekenservices werken of die workloads hebben die hoge doorvoerniveaus vereisen die worden bereikt door opslag via netwerkbandbreedte te stimuleren. 

Notitie

  • VM-grootte met Elastisch SAN moet voldoen aan vereisten voor productie (VM naar VM) netwerkdoorvoer, samen met opslagdoorvoer.

Overweeg om SQL Server-workloads op elastic SAN te plaatsen voor betere kostenefficiëntie, omdat:

  • Opslagconsolidatie en dynamisch delen van prestaties: normaal gesproken voor SQL Server op Azure VM-workloads wordt schijfopslag ingericht op basis van de capaciteit van de klant en piekprestaties voor die VM. Deze overprovisioned prestaties zijn beschikbaar wanneer dat nodig is, maar de ongebruikte prestaties kunnen niet worden gedeeld met workloads op andere VM's. Elastisch SAN, vergelijkbaar met on-premises SAN, maakt het mogelijk om opslagbehoeften van meerdere SQL- en niet-SQL-workloads te consolideren om betere kostenefficiëntie te bereiken, met de mogelijkheid om de ingerichte prestaties dynamisch te delen tussen de volumes die zijn ingericht voor deze verschillende workloads op basis van IO-vereisten. Als u bijvoorbeeld in VS - oost 10 workloads hebt waarvoor 2 TiB-capaciteit en 10.000 IOPS nodig zijn, maar gezamenlijk hebben ze op elk moment niet meer dan 60.000 IOPS nodig. U kunt een elastisch SAN configureren met 12 basiseenheden (1 basiseenheid = $ 0,08 per GiB/maand) die u 12 TiB-capaciteit en de benodigde 60.000 IOPS en 8 eenheden met alleen capaciteit (1 capaciteitseenheid = $ 0,06 per GiB/maand) geeft waarmee u de resterende 8 TiB-capaciteit tegen een lagere prijs krijgt. Deze optimale opslagconfiguratie biedt een betere kostenefficiëntie en biedt tegelijkertijd de benodigde prestaties (10.000 IOPS) voor elk van deze workloads. Voor meer informatie over elastische SAN-basis- en alleen-capaciteitsinrichtingseenheden, gaat u naar Planning voor een elastisch Azure SAN en voor prijzen, gaat u naar Azure Elastic SAN - Prijzen.
  • Om een hogere opslagdoorvoer te stimuleren: SQL Server op Azure VM-implementaties vereisen af en toe overprovisioning van een VM vanwege schijfdoorvoerlimieten voor die VM. U kunt dit voorkomen met elastic SAN, omdat u hogere opslagdoorvoer via rekennetwerkbandbreedte met het iSCSI-protocol wilt stimuleren. Een Standard_E32bds_v5 (SCSI)-VM is bijvoorbeeld beperkt tot 88.000 IOPS en 2500 MBps voor schijf-/opslagdoorvoer, maar kan maximaal 16.000 MBps-netwerkdoorvoer bereiken. Als de vereiste voor opslagdoorvoer voor uw workload groter is dan 2500 MBps, hoeft u de VM geen hogere SKU bij te werken, omdat deze nu maximaal 16.000 MBps kan ondersteunen met behulp van Elastic SAN.

Premium SSD

Gebruik Premium SSD's voor gegevens- en logboekbestanden voor sql Server-productieworkloads. Premium SSD IOPS en bandbreedte variëren op basis van de schijfgrootte en het type.

Gebruik voor productieworkloads de P30- en/of P40-schijven voor SQL Server-gegevensbestanden om ondersteuning voor caching te garanderen en gebruik de P30 tot P80 voor TRANSACTIElogboekbestanden van SQL Server. Voor de beste totale eigendomskosten begint u met P30s (5000 IOPS/200 MBPS) voor gegevens en logboekbestanden en kiest u alleen hogere capaciteiten wanneer u het aantal VM-schijven wilt beheren. Voor ontwikkel-/test- of kleine systemen kunt u ervoor kiezen om grootten te gebruiken die kleiner zijn dan P30, omdat deze ondersteuning bieden voor caching, maar ze bieden geen gereserveerde prijzen.

Voor OLTP-workloads komt u overeen met de doel-IOPS per schijf (of opslaggroep) met uw prestatievereisten met behulp van workloads op piektijden en de Disk Reads/sec + Disk Writes/sec prestatiemeteritems. Voor datawarehouse- en rapportageworkloads komt u overeen met de doeldoorvoer met behulp van workloads op piekmomenten en de Disk Read Bytes/sec + Disk Write Bytes/sec.

Gebruik Opslagruimten om optimale prestaties te bereiken, twee pools te configureren, één voor de logboekbestanden en de andere voor de gegevensbestanden. Als u geen schijfstriping gebruikt, gebruikt u twee Premium SSD-schijven die zijn toegewezen aan afzonderlijke stations, waarbij één station het logboekbestand bevat en de andere de gegevens bevat.

De ingerichte IOPS en doorvoer per schijf die wordt gebruikt als onderdeel van uw opslaggroep. De gecombineerde IOPS- en doorvoermogelijkheden van de schijven zijn de maximale capaciteit tot aan de doorvoerlimieten van de VIRTUELE machine.

De aanbevolen procedure is om het minste aantal schijven te gebruiken dat mogelijk is, terwijl aan de minimale vereisten voor IOPS (en doorvoer) en capaciteit wordt voldaan. Het saldo van de prijs en prestaties is echter meestal beter met een groot aantal kleine schijven in plaats van een klein aantal grote schijven.

Premium-schijven schalen

De grootte van uw Premium SSD bepaalt de initiële prestatielaag van uw schijf. Wijs de prestatielaag bij de implementatie aan of wijzig deze later, zonder de grootte van de schijf te wijzigen. Als de vraag toeneemt, kunt u het prestatieniveau verhogen om te voldoen aan de behoeften van uw bedrijf.

Door de prestatielaag te wijzigen, kunnen beheerders zich voorbereiden op en voldoen aan een hogere vraag zonder te vertrouwen op schijf-bursting.

Gebruik de hogere prestaties zolang dat nodig is wanneer facturering is ontworpen om te voldoen aan de opslagprestatielaag. Werk de laag bij zodat deze overeenkomt met de prestatievereisten zonder de capaciteit te vergroten. Ga terug naar de oorspronkelijke laag wanneer de extra prestaties niet meer nodig zijn.

Deze kosteneffectieve en tijdelijke uitbreiding van de prestaties is een sterk gebruiksscenario voor gerichte evenementen, zoals winkelen, prestatietests, trainingsgebeurtenissen en andere korte vensters, waarbij betere prestaties alleen op korte termijn nodig zijn.

Zie Prestatielagen voor beheerde schijven voor meer informatie.

Azure Ultra Disk

Als er een reactietijd van submilliseconden met verminderde latentie nodig is, kunt u overwegen om Azure Ultra Disk te gebruiken voor het SQL Server-logboekstation of zelfs het gegevensstation voor toepassingen die zeer gevoelig zijn voor I/O-latentie.

Ultra disk kan worden geconfigureerd waar capaciteit en IOPS onafhankelijk van elkaar kunnen worden geschaald. Met ultraschijfbeheerders kunnen een schijf inrichten met de capaciteit, IOPS en doorvoervereisten op basis van toepassingsbehoeften.

Ultra disk wordt niet ondersteund op alle VM-serie en heeft andere beperkingen, zoals beschikbaarheid van regio's, redundantie en ondersteuning voor Azure Backup. Zie Azure Ultra Disks gebruiken voor een volledige lijst met beperkingen voor meer informatie.

Standard-HDD's en HDD's

Standard-HDD's en HDD's hebben verschillende latenties en bandbreedte en worden alleen aanbevolen voor ontwikkel-/testworkloads. Productieworkloads moeten Premium SSD v2 of Premium SSD's gebruiken. Als u Standard SSD (ontwikkel-/testscenario's) gebruikt, is het raadzaam om het maximum aantal gegevensschijven toe te voegen dat wordt ondersteund door uw VM-grootte en schijfstriping te gebruiken met Opslagruimten voor de beste prestaties.

Caching

VM's die premium-opslagcaching ondersteunen, kunnen profiteren van een extra functie, de Azure BlobCache of hostcache, om de IOPS- en doorvoermogelijkheden van een VIRTUELE machine uit te breiden. Vm's die zijn ingeschakeld voor zowel Premium Storage als Premium Storage Caching, hebben deze twee verschillende opslagbandbreedtelimieten die samen kunnen worden gebruikt om de opslagprestaties te verbeteren.

De doorvoer van IOPS en MBps zonder caching telt mee aan de limieten voor niet-in cache geplaatste schijfdoorvoer van een virtuele machine. De maximale limieten in de cache bieden een andere buffer voor leesbewerkingen waarmee groei en onverwachte pieken kunnen worden aangepakt.

Schakel Premium-caching in wanneer de optie wordt ondersteund om de prestaties voor leesbewerkingen op het gegevensstation aanzienlijk te verbeteren zonder extra kosten.

Lees- en schrijfbewerkingen naar Azure BlobCache (in cache opgeslagen IOPS en doorvoer) tellen niet mee voor de niet-in de cache opgeslagen IOPS en doorvoerlimieten van de virtuele machine.

Notitie

Schijfcache wordt niet ondersteund voor schijven 4 TiB en groter (P50 en groter). Als er meerdere schijven aan uw VM zijn gekoppeld, biedt elke schijf die kleiner is dan 4 TiB ondersteuning voor caching. Zie Schijfcache voor meer informatie.

Niet-cachedoorvoer

De maximaal niet-opgeslagen schijf-IOPS en doorvoer is de maximale limiet voor externe opslag die door de VIRTUELE machine kan worden verwerkt. Deze limiet wordt gedefinieerd op de virtuele machine en is geen limiet voor de onderliggende schijfopslag. Deze limiet geldt alleen voor I/O voor gegevensstations die extern zijn gekoppeld aan de virtuele machine, niet de lokale I/O tegen het tijdelijke station (D:\ station) of het besturingssysteemstation.

De hoeveelheid niet-in cache opgeslagen IOPS en doorvoer die beschikbaar is voor een virtuele machine, kan worden gecontroleerd in de documentatie voor uw VIRTUELE machine.

In de documentatie van de M-serie ziet u bijvoorbeeld dat de maximale niet-cachedoorvoer voor de Standard_M8ms VM 5000 IOPS en 125 MBps van niet-in de cache opgeslagen schijfdoorvoer is.

Screenshot showing M-series uncached disk throughput documentation.

Op dezelfde manier kunt u zien dat de Standard_M32ts 20.000 IOPS voor niet-in cache opgeslagen schijf-IOPS en 500-MBps niet-in de cache opgeslagen schijfdoorvoer ondersteunt. Deze limiet wordt beheerd op VM-niveau, ongeacht de onderliggende Premium-schijfopslag.

Zie niet-cache- en cachelimieten voor meer informatie.

Doorvoer van opslag in cache en tijdelijke opslag

De maximale doorvoerlimiet voor opslag in cache en tijdelijke opslag is een afzonderlijke limiet van de limiet voor niet-in de cache geplaatste doorvoer op de virtuele machine. De Azure BlobCache bestaat uit een combinatie van het willekeurige toegangsgeheugen van de VM-host en lokaal gekoppelde SSD. Het tijdelijke station (D:\ station) binnen de VIRTUELE machine wordt ook gehost op deze lokale SSD.

De maximale doorvoerlimiet voor opslag in cache en tijdelijke opslag bepaalt de I/O voor het lokale tijdelijke station (D:\ station) en de Azure BlobCache alleen als hostcaching is ingeschakeld.

Wanneer caching is ingeschakeld voor Premium Storage, kunnen VM's worden geschaald buiten de beperkingen van de IOPS en doorvoerlimieten voor niet-opgeslagen VM's.

Alleen bepaalde VM's ondersteunen zowel Premium Storage als Premium Storage Caching (die moeten worden geverifieerd in de documentatie van de virtuele machine). De documentatie van de M-serie geeft bijvoorbeeld aan dat zowel Premium Storage als Premium Storage Caching wordt ondersteund:

Screenshot showing M-Series Premium Storage support.

De limieten van de cache variëren op basis van de VM-grootte. De Standard_M8ms VM ondersteunt bijvoorbeeld schijf-IOPS met 10000 cache en schijfdoorvoer van 1000 MBps met een totale cachegrootte van 793 GiB. Op dezelfde manier ondersteunt de Standard_M32ts VM 40000 schijf-IOPS en 400 MBps-schijfdoorvoer in cache met een totale cachegrootte van 3174 GiB.

Screenshot showing M-series cached disk throughput documentation.

U kunt hostcaching handmatig inschakelen op een bestaande VIRTUELE machine. Stop alle toepassingsworkloads en de SQL Server-services voordat er wijzigingen worden aangebracht in het cachebeleid van uw VM. Als u een van de cache-instellingen van de VIRTUELE machine wijzigt, wordt de doelschijf losgekoppeld en opnieuw gekoppeld nadat de instellingen zijn toegepast.

Cachebeleid voor gegevensbestanden

Het cachebeleid voor opslag is afhankelijk van het type SQL Server-gegevensbestanden dat op het station wordt gehost.

De volgende tabel bevat een overzicht van het aanbevolen cachebeleid op basis van het type SQL Server-gegevens:

SQL Server-schijf Aanbeveling
Gegevensschijf Schakel Read-only caching in voor de schijven die als host fungeren voor SQL Server-gegevensbestanden.
Leesbewerkingen uit de cache zijn sneller dan de niet-in de cache opgeslagen leesbewerkingen van de gegevensschijf.
Niet-cache-IOPS en doorvoer plus IOPS in cache en doorvoer leveren de totale mogelijke prestaties op die beschikbaar zijn op de VM binnen de vm-limieten, maar de werkelijke prestaties variëren op basis van de mogelijkheid van de workload om de cache te gebruiken (cachetrefferverhouding).
Transactielogboekschijf Stel het cachebeleid None in op schijven die als host fungeren voor het transactielogboek. Er is geen prestatievoordeel voor het inschakelen van caching voor de transactielogboekschijf, en in feite Read-only kan het in de cache inschakelen op Read/Write het logboekstation de prestaties van de schrijfbewerkingen tegen het station verminderen en de hoeveelheid cache verminderen die beschikbaar is voor leesbewerkingen op het gegevensstation.
Besturingssysteemschijf gebruiken Het standaardbeleid voor caching is Read/write voor het besturingssysteemstation.
Het wordt niet aanbevolen om het cacheniveau van het besturingssysteemstation te wijzigen.
tempdb Als tempdb u het tijdelijke station D:\ niet kunt plaatsen vanwege capaciteitsredenen, wijzigt u het formaat van de VIRTUELE machine om een groter kortstondig station te krijgen of plaatst tempdb u deze op een afzonderlijk gegevensstation met Read-only caching geconfigureerd.
De VM-cache en het tijdelijke station maken beide gebruik van de lokale SSD. Houd er dus rekening mee dat bij het aanpassen van de grootte tempdb als I/O wordt geteld tegen de limieten van de in de cache opgeslagen IOPS en doorvoer-VM's wanneer deze worden gehost op het tijdelijke station.

Belangrijk

Het wijzigen van de cache-instelling van een Azure-schijf koppelt de doelschijf los en weer vast. Wanneer u de cache-instelling wijzigt voor een schijf waarop SQL Server-gegevens, logboekbestanden of toepassingsbestanden worden gehost, moet u de SQL Server-service samen met andere gerelateerde services stoppen om beschadiging van gegevens te voorkomen.

Zie Schijfcache voor meer informatie.

Schijfstriping

Analyseer de doorvoer en bandbreedte die nodig is voor uw SQL-gegevensbestanden om het aantal gegevensschijven te bepalen, inclusief het logboekbestand en tempdb. Doorvoer- en bandbreedtelimieten variëren per VM-grootte. Zie VM-grootte voor meer informatie

Voeg meer gegevensschijven toe en gebruik schijfstriping voor meer doorvoer. Een toepassing die bijvoorbeeld 12.000 IOPS en doorvoer van 180 MB/s nodig heeft, kan drie gestreepte P30-schijven gebruiken om 15.000 IOPS- en 600 MB/s-doorvoer te leveren.

Zie schijfstriping om schijfstriping te configureren.

Schijflimieten

Er gelden doorvoerlimieten op schijf- en VM-niveau. De maximale IOPS-limieten per VM en per schijf verschillen en zijn onafhankelijk van elkaar.

Toepassingen die resources buiten deze limieten verbruiken, worden beperkt (ook wel beperkt genoemd). Selecteer een VIRTUELE machine en schijfgrootte in een schijfstrook die voldoet aan de toepassingsvereisten en ondervindt geen beperkingen voor het beperken van beperkingen. Gebruik caching of stem de toepassing zo af dat er minder doorvoer nodig is om het beperken aan te pakken.

Een toepassing die bijvoorbeeld 12.000 IOPS en 180 MB/s nodig heeft, kan:

  • Gebruik de Standard_M32ms, met een maximale schijfdoorvoer zonder cache van 20.000 IOPS en 500 MBps.
  • Stripe drie P30-schijven om 15.000 IOPS en 600 MB/s doorvoer te leveren.
  • Gebruik een Standard_M16ms-VM en gebruik hostcaching om gebruik te maken van lokale cache over het verbruik van doorvoer.

VM's die zijn geconfigureerd om omhoog te schalen in tijden van hoog gebruik, moeten opslag inrichten met voldoende IOPS en doorvoer ter ondersteuning van de maximale VM-grootte, terwijl het totale aantal schijven kleiner dan of gelijk blijft aan het maximumaantal dat wordt ondersteund door de kleinste VM-SKU die moet worden gebruikt.

Zie Schijf-IO-limieten voor meer informatie over schijflimieten en het gebruik van caching om limieten te voorkomen.

Notitie

Sommige schijflimieten kunnen nog steeds leiden tot bevredigende prestaties voor gebruikers; werkbelastingen afstemmen en onderhouden in plaats van het formaat te wijzigen naar een grotere VIRTUELE machine om de kosten en prestaties voor het bedrijf te beheren.

Schrijfversnelling

Write Acceleration is een schijffunctie die alleen beschikbaar is voor de VM's uit de M-serie . Schrijfversnelling is bedoeld om de I/O-latentie van schrijfbewerkingen op Azure Premium Storage te verbeteren wanneer u I/O-latentie van één cijfer nodig hebt vanwege essentiële OLTP-workloads of datawarehouse-omgevingen met een hoog volume.

Gebruik Schrijfversnelling om de schrijflatentie te verbeteren voor het station dat als host fungeert voor de logboekbestanden. Gebruik geen schrijfversnelling voor SQL Server-gegevensbestanden.

Write Accelerator-schijven delen dezelfde IOPS-limiet als de VIRTUELE machine. Gekoppelde schijven kunnen de IOPS-limiet voor write accelerator voor een virtuele machine niet overschrijden.

De volgende tabel bevat een overzicht van het aantal gegevensschijven en IOPS dat per VM wordt ondersteund:

VM-SKU # Write Accelerator-schijven Write Accelerator disk IOPS per VM
M416ms_v2, M416s_v2 16 20000
M128ms, M128s 16 20000
M208ms_v2, M208s_v2 8 10000
M64ms, M64ls, M64s 8 10000
M32ms, M32ls, M32ts, M32s 4 5000
M16ms, M16s 2 2500
M8ms, M8s 1 1250

Er zijn verschillende beperkingen voor het gebruik van Schrijfversnelling. Zie Beperkingen bij het gebruik van Write Accelerator voor meer informatie.

Vergelijken met Azure Ultra Disk

Het grootste verschil tussen Schrijfversnelling en Azure ultraschijven is dat Write Acceleration een VM-functie is die alleen beschikbaar is voor de M-serie en Azure Ultra Disks is een opslagoptie. Schrijfversnelling is een voor schrijven geoptimaliseerde cache met eigen beperkingen op basis van de VM-grootte. Azure Ultra-schijven zijn een optie voor schijfopslag met lage latentie voor Virtuele Azure-machines.

Gebruik indien mogelijk Write Acceleration via ultraschijven voor de transactielogboekschijf. Gebruik Azure Ultra-schijven voor VM's die schrijfversnelling niet ondersteunen, maar lage latentie voor het transactielogboek vereisen.

Opslagprestaties bewaken

Als u de opslagbehoeften wilt beoordelen en wilt bepalen hoe goed de opslag presteert, moet u weten wat u moet meten en wat deze indicatoren betekenen.

IOPS (Input/Output per seconde) is het aantal aanvragen dat de toepassing maakt voor opslag per seconde. IOPS meten met prestatiemeteritems Disk Reads/sec en Disk Writes/sec. OLTP-toepassingen (Online transaction processing) moeten hogere IOPS aandrijven om optimale prestaties te bereiken. Toepassingen zoals betalingsverwerkingssystemen, online winkelen en retail point-of-sale systemen zijn allemaal voorbeelden van OLTP-toepassingen.

Doorvoer is het volume aan gegevens dat naar de onderliggende opslag wordt verzonden, vaak gemeten met megabytes per seconde. Meet de doorvoer met de prestatiemeteritems Disk Read Bytes/sec en Disk Write Bytes/sec. Datawarehousing is geoptimaliseerd om de doorvoer via IOPS te maximaliseren. Toepassingen zoals gegevensarchieven voor analyse, rapportage, ETL-werkstromen en andere business intelligence-doelen zijn allemaal voorbeelden van datawarehousingtoepassingen.

I/O-eenheidsgrootten beïnvloeden IOPS en doorvoermogelijkheden omdat kleinere I/O-grootten hogere IOPS opleveren en grotere I/O-grootten hogere doorvoer opleveren. SQL Server kiest automatisch de optimale I/O-grootte. Zie IOPS, doorvoer en latentie optimaliseren voor uw toepassingen voor meer informatie.

Er zijn specifieke metrische Gegevens van Azure Monitor die waardevol zijn voor het detecteren van limieten op vm- en schijfniveau, evenals het verbruik en de status van de AzureBlob-cache. Zie metrische gegevens over opslaggebruik om belangrijke tellers te identificeren die u wilt toevoegen aan uw bewakingsoplossing en het Dashboard van Azure Portal.

Notitie

Azure Monitor biedt momenteel geen metrische gegevens op schijfniveau voor het tijdelijke station (D:\). Het verbruikte percentage verbruikte IOPS in de cache en het verbruikte percentage verbruikte bandbreedte in de VM-cache weerspiegelen IOPS en doorvoer van zowel het tijdelijke station (D:\) als de hostcache samen.

Volgende stappen

Zie de andere artikelen in deze reeks aanbevolen procedures voor meer informatie: