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: Checklist, VM-grootte, Security, HADR-configuratieen Basislijn verzamelen.

Controlelijst

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 de vereisten voor opslagbandbreedte en latentie voor SQL Server-gegevens, logboekbestanden 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 voor de hoogste beschikbare niet-gecachede IOPS en gebruikt u gegevenscaching als prestatiefunctie voor datalezen, terwijl u voorkomt dat virtuele machines en schijven worden beperkt.
  • Wanneer u de Ebdsv5- of Ebsv5--serie SQL Server-VM's gebruikt, gebruikt u Premium SSD v2 voor de beste prijsprestaties. U kunt uw SQL Server-VM implementeren met Premium SSD v2 met behulp van Azure Portal (momenteel in preview).
  • Als uw workload meer dan 160.000 IOPS vereist, gebruikt u Premium SSD v2 of Azure Ultra Disks.
  • Plaats gegevens-, logboek- en tempdb-bestanden op afzonderlijke schijven.
    • Gebruik voor het gegevensstation premium P30- en P40- of kleinere schijven om de beschikbaarheid van cacheondersteuning te garanderen. Wanneer u de Ebdsv5-VM-seriegebruikt, gebruikt u Premium SSD v2 die betere prijsprestaties biedt voor workloads waarvoor een hoge IOPS- en I/O-doorvoer is vereist.
    • Voor het logstationplan voor capaciteit en testprestaties versus kosten tijdens het evalueren van Premium SSD v2 of Premium SSD P30 - P80-schijven
      • Als de latentie van de opslag 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 schrijfversneller te gebruiken in plaats van Azure Ultra Disks.
    • Plaats tempdb- op de tijdelijke schijf (de tijdelijke schijf is kortstondig en wordt standaard ingesteld op D:\) 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 is voor tempdb, kun je overwegen om de grootte van de virtuele machine te wijzigen. Zie cachebeleid voor gegevensbestandenvoor meer informatie.
    • Voor failoverclusterexemplaren (FCI) plaatst u tempdb op de gedeelde opslag.
      • Als de FCI-werkbelasting sterk afhankelijk is van tempdb schijfprestaties, plaatst u als een geavanceerde configuratie tempdb op het lokale tijdelijke SSD-station (standaard D:\) dat geen deel uitmaakt van FCI-opslag. Voor deze configuratie is aangepaste bewaking en actie vereist 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 hostcache in op alleen-lezen voor gegevensbestandsschijven.
  • Stel hostcache 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.
  • Wanneer u verschillende workloads naar de cloud migreert, kan elastische SAN- van Azure een rendabele geconsolideerde opslagoplossing zijn. Wanneer u Azure Elastic SAN gebruikt, vereist het bereiken van de gewenste IOPS/doorvoer voor SQL Server-workloads vaak het overprovisioneren van capaciteit. Hoewel dit doorgaans niet geschikt is voor individuele SQL Server-workloads, kunt u een rendabele oplossing bereiken bij het combineren van workloads met lage prestaties met SQL Server.
  • 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.
  • Tegoed-gebaseerd Disk Bursting (P1-P20) mag alleen worden overwogen voor kleinere ontwikkel-/testworkloads en afdelingssystemen.
  • Als u de opslagprestaties wilt optimaliseren, plan dan voor de hoogste beschikbare IOPS zonder caching en gebruik gegevenscaching als prestatiefunctie voor gegevensleesbewerkingen, terwijl u het afremmen/beperken van virtuele machines en schijven vermijdt.
  • Maak de gegevensschijf op om een toewijzingseenheidsgrootte van 64 kB te gebruiken voor alle gegevensbestanden die op een ander station worden opgeslagen 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 opslagpool 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 io-gebruik.
  • SQL Server-bestanden uitsluiten 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 naar het D:\ station en het inschakelen van het optimale cachebeleid. Zie sql VM-opslagconfiguratievoor meer informatie over het inrichten en configureren van opslag.

VM-schijftypen

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 Overzicht van beheerde schijvenvoor meer informatie.

De prestaties van Premium SSD v2 en Ultra Disks kunnen onafhankelijk van de grootte van de schijf worden gewijzigd. Zie Ultra disk performance en Premium SSD v2 performance. Als uw workload meer dan 160.000 IOPS vereist, kunt u overwegen Premium SSD v2 of Ultra Disks te gebruiken.

Er zijn ook drie belangrijke schijfrollen om rekening mee te houden 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 gemount als een actieve versie van een besturingssysteem en gelabeld is als de C:\-schijf. 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 Azure-VM's bevatten een ander type schijf, namelijk de tijdelijke schijf (met de aanduiding de D:\-schijf). 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).

De tijdelijke opslagdrive wordt niet doorgezet naar externe opslag en mag daarom geen gebruikersdatabasebestanden, transactielogboekbestanden of iets anders opslaan dat behouden moet blijven. U kunt deze bijvoorbeeld gebruiken voor buffergroepextensies, het paginabestand en tempdb.

Plaats tempdb op de lokale tijdelijke SSD D:\ station 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 tempdb op een eigen geïsoleerde schijf of opslaggroep te plaatsen met caching ingesteld op alleen-lezen. Zie tempdb-beleid voor het opslaan van gegevens in cachevoor meer informatie.

Gegevensschijven

Gegevensschijven zijn externe opslagschijven die vaak worden gemaakt in opslaggroepen om de capaciteit en prestaties te overschrijden die een 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 een toewijzingseenheidsgrootte van 64 kB te gebruiken voor alle gegevensbestanden die op een ander station worden opgeslagen 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 een toewijzingseenheidsgrootte en interleave voor de opslagpool ingesteld op 64 KB.

Notitie

Het is ook mogelijk om uw SQL Server-databasebestanden rechtstreeks op Azure Blob Storage- of op SMB-opslag te hosten, zoals Azure Premium-bestandsshare, 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- of Ebsv5-serie virtuele machines omdat het een rendabelere oplossing is voor deze hoge I/O-doorvoermachines. Als uw workload meer dan 160.000 IOPS vereist, kunt u overwegen Premium SSD v2 of Ultra Disks te gebruiken.

U kunt uw SQL Server-VM's implementeren met Premium SSD v2 met behulp van Azure Portal (momenteel in preview).

Als u uw SQL Server-VM implementeert met behulp van Azure Portal en Premium SSD v2 wilt gebruiken, bent u momenteel beperkt tot de virtuele machines uit de Ebdsv5- of Ebsv5-serie. Als u uw VIRTUELE machine echter handmatig maakt met Premium SSD v2-opslag en vervolgens SQL Server handmatig installeert op de virtuele machine, kunt u elke VM-serie gebruiken die Premium SSD v2 ondersteunt. Zorg ervoor dat u registreert uw SQL Server-VM met de SQL IaaS Agent-extensie, zodat u kunt profiteren van alle voordelen die de extensie biedt.

Elastische SAN van Azure

Azure Elastische SAN is een netwerkopslagaanbod dat klanten een flexibele en schaalbare oplossing biedt met het potentieel om kosten te verlagen via opslagconsolidatie. Azure Elastic SAN biedt een rendabele, 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 worden geschaald tot miljoenen IOPS, dubbelcijferige GB/s aan doorvoer en lage latenties van één milliseconden, met ingebouwde tolerantie om downtime te minimaliseren. Gebruik Azure Elastic SAN als u opslag wilt consolideren, met meerdere rekenservices wilt werken of werkbelastingen wilt hebben die hoge doorvoerniveaus vereisen bij het stimuleren van opslag via netwerkbandbreedte. Omdat het bereiken van de gewenste IOPS/doorvoer voor SQL Server-workloads vaak overprovisioningcapaciteit vereist, is het doorgaans niet geschikt is voor enkele SQL Server-workloads. Als u de meest rendabele oplossing met Elastic SAN wilt bereiken, kunt u deze gebruiken als opslag voor meerdere SQL Server-workloads of een combinatie van SQL Server en andere workloads met lage prestaties.

Overweeg OM SQL Server-workloads op elastisch SAN te plaatsen voor betere kostenefficiëntie, opslagconsolidatie, dynamisch delen van prestaties en om een hogere opslagdoorvoer te stimuleren.

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 stem de doel-IOPS per schijf (of opslaggroep) af op uw prestatievereisten met behulp van workloads tijdens piekmomenten en de Disk Reads/sec + Disk Writes/sec prestatiecounters. Voor datawarehouse- en rapportageworkloads zorgt u voor de gewenste doorvoer door het gebruik van workloads op piektijden 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.

Het schalen van premium-schijven

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 aan te passen, kunnen beheerders zich voorbereiden op en voldoen aan een hogere vraag zonder te vertrouwen op schijfuitbarsting.

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 schijvenvoor 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 beheerders een schijf inrichten met de capaciteit, IOPS en doorvoer die nodig zijn op basis van de behoeften van de toepassing.

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.

Standaard HDD's en SSD'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.

Cache beheren

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 voor de limieten van de niet-gecachete 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 VIRTUELE machine zijn gekoppeld, biedt elke schijf die kleiner is dan 4 TiB ondersteuning voor caching. Zie Disk cachingvoor meer informatie.

Niet-gecachede doorvoer

De maximale niet-gecachede 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 M-serie documentatie 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.

Schermopname van documentatie over niet-in cache opgeslagen schijfdoorvoer uit de M-serie.

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

Zie voor meer informatie niet-gecachte en gecachete limieten.

Doorvoer van 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. De tijdelijke schijf (D:\ station) binnen de virtuele machine wordt ook gehost op deze lokale SSD.

De maximale doorvoersnelheidlimiet voor opslag in cache en tijdelijke opslag bepaalt de I/O voor de lokale tijdelijke schijf (D:\ schijf) en de Azure BlobCache-alleen als hostcache is ingeschakeld.

Wanneer caching is ingeschakeld voor Premium Storage, kunnen VM's worden geschaald voorbij de IOPS en doorvoerbeperkingen van niet-opgeslagen VM's op externe opslag.

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:

schermopname met ondersteuning voor M-Series Premium Storage.

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 schijfdoorvoer van 4000 MBps met een totale cachegrootte van 3.174 GiB.

Screenshot van documentatie over de doorvoer van gecachede schijven uit de M-serie.

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 varieert afhankelijk van het type SQL Server-gegevensbestanden dat op de schijf 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-gecachete IOPS en doorvoer, samen met gecachete IOPS en doorvoer, resulteren in de totale mogelijke prestaties die beschikbaar zijn binnen de VM-limieten, maar de werkelijke prestaties variëren afhankelijk van de capaciteit van de workload om de cache te gebruiken (cachetrefferverhouding).
transactielogboekschijf Stel het cachebeleid in op None voor schijven die het transactielogboek hosten. Er is geen prestatievoordeel bij het inschakelen van caching voor de transactielogboekschijf. In feite kan caching van Read-only of Read/Write op de logboekschijf de prestatie van schrijfbewerkingen op de schijf verslechteren en de beschikbare hoeveelheid cache voor leesbewerkingen op de gegevensschijf verminderen.
besturingssysteemschijf 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 niet kan worden geplaatst op de tijdelijke schijf D:\ vanwege capaciteitsredenen, wijzigt u de grootte van de virtuele machine om een grotere tijdelijke schijf te krijgen of plaatst u tempdb op een afzonderlijke datadrager waarbij Read-only caching is geconfigureerd.
De VM-cache en het tijdelijke station maken beide gebruik van de lokale SSD. Houd hier rekening mee bij het bepalen van de grootte, omdat tempdb I/O meetelt voor de IOPS en doorvoerlimieten wanneer deze op het tijdelijke station worden gehost.

Belangrijk

Als u de cache-instelling van een Azure-schijf wijzigt, wordt de doelschijf losgekoppeld en opnieuw gekoppeld. 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 Disk Cachingvoor 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. Voor meer informatie, zie VM-grootten.

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 middelen buiten deze limieten verbruiken, worden beperkt (ook wel gecapt genoemd). Selecteer een VM en schijfgrootte in een schijfstrook die voldoet aan de toepassingsvereisten en geen beperkingen tegenkomt. Gebruik caching of pas de toepassing aan zodat er minder doorvoer nodig is om capaciteitslimieten aan te pakken.

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

  • Gebruik de Standard_M32ms, met een maximale niet-gecachede schijfdoorvoer 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 de lokale cache te benutten in plaats van 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 Disk IO-limietenvoor 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 M-serie VM's. 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 de drive die de logbestanden host. 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 # Schrijfversnellerschijven Schrijfversneller schijf IOPS per virtuele machine
M416ms_v2, M416s_v2 16 20000
M128ms, M128s 16 20000
M208ms_v2, M208s_v2 8 10.000
M64ms, M64ls, M64s 8 10.000
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 Acceleratorvoor meer informatie.

Vergelijken met Azure Ultra Disk

Het grootste verschil tussen Write Acceleration en Azure Ultra Disks is dat Write Acceleration een VM-functie is die alleen beschikbaar is voor de M-serie en Azure Ultra Disks een opslagoptie is. 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) het aantal aanvragen is dat de toepassing per seconde naar de opslag verzendt. Meet IOPS met behulp van prestatiemeteritems Disk Reads/sec en Disk Writes/sec. OLTP (Online transaction processing) toepassingen moeten hogere IOPS behalen 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 in megabytes per seconde. Meet de doorvoer met de Prestatie Monitor-tellers Disk Read Bytes/sec en Disk Write Bytes/sec. Datawarehousing is geoptimaliseerd voor het maximaliseren van doorvoer ten opzichte van IOPS. 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 toepassingenvoor 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 opslaggebruikom belangrijke tellers te identificeren die u aan uw bewakingsoplossing en het Dashboard van Azure Portal wilt toevoegen.

Notitie

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

Groei van transactielogboeken bewaken

Omdat een volledig transactielogboek kan leiden tot prestatieproblemen en storingen, is het belangrijk om de beschikbare ruimte in uw transactielogboek te bewaken, evenals de gebruikte schijfruimte van het station dat uw transactielogboek bevat. Los problemen met transactielogboeken op voordat ze van invloed zijn op uw workload.

Bekijk Hoe u problemen oplost bij een volledig transactielogboek wanneer uw logboek vol raakt.

Als u de schijf wilt uitbreiden, kunt u dit doen in het deelvenster Storage van de resource van de virtuele SQL-machines als u een SQL Server-installatiekopie hebt geïmplementeerd vanuit Azure Marketplace of in het deelvenster Schijven voor uw virtuele Azure-machine en zelf geïnstalleerde SQL Server.

Volgende stappen

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