Controlelijst: Best practices voor SQL Server azure-VM's

  • Artikel
  • 9 minuten om te lezen

VAN TOEPASSING OP: SQL Server op virtuele Azure-machine

Dit artikel bevat een snelle controlelijst als een reeks best practices en richtlijnen voor het optimaliseren van de prestaties van uw SQL Server op Azure Virtual Machines (VM's).

Zie de andere artikelen in deze reeks voor uitgebreide informatie: Checklist, VM-grootte, Storage, Beveiliging, HADR-configuratie, Basislijn verzamelen.

Schakel SQL Assessment in voor SQL Server op Azure-VM's. Uw SQL Server wordt geëvalueerd op basis van bekende best practices en resultaten die worden weergegeven op de SQL-VM-beheerpagina van de Azure Portal.

Overzicht

Terwijl u SQL Server in Azure Virtual Machines, kunt u dezelfde afstemmingsopties voor databaseprestaties blijven gebruiken die van toepassing zijn op SQL Server in on-premises serveromgevingen. De prestaties van een relationele database in een openbare cloud zijn echter afhankelijk van veel factoren, zoals de grootte van een virtuele machine en de configuratie van de gegevensschijven.

Er is doorgaans een balans tussen optimaliseren voor kosten en optimaliseren voor prestaties. Deze reeks best practices voor prestaties is gericht op het verkrijgen van de beste prestaties voor SQL Server in Azure Virtual Machines. Als uw workload minder veeleisende is, hebt u mogelijk niet elke aanbevolen optimalisatie nodig. Houd rekening met uw prestatiebehoeften, kosten en workloadpatronen bij het evalueren van deze aanbevelingen.

VM-grootte

Hier volgt een snelle controlelijst met best practices voor VM-grootte voor het uitvoeren van uw SQL Server azure-VM:

  • Gebruik VM-grootten met 4 of meer vCPU's, zoals de Standard_M8-4 ms,de E4ds_v4of de DS12_v2 of hoger.
  • Voor de beste prestaties van SQL Server-workloads gebruikt u VM-grootten die voor geheugen zijn geoptimaliseerd.
  • De DSv2-serie 11-15, Edsv4, de M-en de Mv2-serie bieden de optimale geheugen-naar-vCore-verhouding die vereist is voor OLTP-workloads. Beide VM's uit de M-serie bieden de hoogste geheugen-naar-vCore-verhouding die vereist is voor essentiële workloads en zijn ook ideaal voor datawarehouse-workloads.
  • Overweeg een hogere geheugen-naar-vCore-verhouding voor essentiële workloads en datawarehouse-workloads.
  • Gebruik de Azure Virtual Machine Marketplace-afbeeldingen als de SQL Server instellingen en opslagopties zijn geconfigureerd voor optimale SQL Server prestaties.
  • Verzamel de prestatiekenmerken van de doelworkload en gebruik deze om de juiste VM-grootte voor uw bedrijf te bepalen.
  • Gebruik het hulpprogramma voor Migration Assistant SKU-aanbeveling om de juiste VM-grootte voor uw bestaande SQL Server vinden.

Zie de uitgebreide best practices voor VM-grootte voor meer informatie.

Storage

Hier volgt een snelle controlelijst met best practices voor opslagconfiguratie voor het uitvoeren van uw SQL Server azure-VM:

  • Controleer de toepassing en bepaal de vereisten voor opslagbandbreedte en -latentie SQL Server gegevens-, logboek- en tempdb-bestanden voordat u het schijftype kiest.
  • Als u de opslagprestaties wilt optimaliseren, moet u de hoogste niet-gecachede IOPS plannen en gegevenscacheding gebruiken als prestatiefunctie voor het lezen van gegevens, terwijl u tegelijkertijd limieten/beperkingen voor virtuele machines en schijven vermijdt.
  • Plaats gegevens-, logboek- en tempdb-bestanden op afzonderlijke stations.
    • Gebruik voor het gegevensstation alleen Premium P30- en P40-schijven om de beschikbaarheid van cacheondersteuning te garanderen
    • Voor het logboekstationplan voor capaciteit en testprestaties versus kosten tijdens het evalueren van de Premium P30 - P80-schijven.
      • Als opslaglatentie van minder dan een seconde is vereist, gebruikt u Azure Ultra Disks voor het transactielogboek.
      • Voor implementaties van virtuele machines uit de M-serie Write Accelerator over het gebruik van Azure Ultra Disks.
    • Plaats tempdb op het lokale tijdelijke SSD-station (standaard ) voor de meeste SQL Server workloads na het D:\ kiezen van de optimale VM-grootte.
  • Stripe meerdere Azure-gegevensschijven met behulp Opslagruimten I/O-bandbreedte te verhogen tot de IOPS- en doorvoerlimieten van de doel-virtuele machine.
  • Stel host caching in op alleen-lezen voor gegevensbestandsschijven.
  • Stel host caching in op geen voor logboekbestandsschijven.
    • Lees-/schrijf caching niet inschakelen op schijven die SQL Server bevatten.
    • Stop altijd de SQL Server voordat u de cache-instellingen van uw schijf verandert.
  • Overweeg het gebruik van standaardopslag voor ontwikkelings- en testworkloads. Het wordt afgeraden om een Standard - HDD/SDD te gebruiken voor productieworkloads.
  • Op tegoed gebaseerde schijf bursting (P1-P20) moet alleen worden overwogen voor kleinere werkbelastingen voor ontwikkelen/testen en afdelingssystemen.
  • Het opslagaccount inrichten in dezelfde regio als de SQL Server VM.
  • Schakel geografisch redundante Azure-opslag (geo-replicatie) uit en gebruik LRS (lokaal redundante opslag) in het opslagaccount.
  • Maak uw gegevensschijf zo op dat deze een grootte van 64 kB gebruikt voor alle gegevensbestanden die op een ander station zijn geplaatst dan het tijdelijke station (met een standaardgrootte D:\ van 4 kB). SQL Server VM's die zijn geïmplementeerd via Azure Marketplace worden er gegevensschijven met de grootte van de toewijzingseenheid en interleave voor de opslaggroep op 64 kB ingesteld.

Zie de uitgebreide Storage best practices voor meer informatie.

SQL Server functies

Hier volgt een snelle controlelijst met best practices voor SQL Server configuratie-instellingen bij het uitvoeren van uw SQL Server-exemplaren in een virtuele Azure-machine in productie:

Azure-functies

Hier volgt een snelle controlelijst met best practices voor specifieke Azure-richtlijnen bij het uitvoeren van SQL Server azure-VM:

HADR-configuratie

Functies voor hoge beschikbaarheid en herstel na noodherstel (HADR), zoals de Always On-beschikbaarheidsgroep en het exemplaar van het failovercluster, zijn afhankelijk van de onderliggende Windows Server-failoverclustertechnologie. Bekijk de best practices voor het wijzigen van uw HADR-instellingen om de cloudomgeving beter te ondersteunen.

Houd voor Windows cluster rekening met de volgende best practices:

  • Implementeer waar mogelijk uw SQL Server-VM's naar meerdere subnetten om de afhankelijkheid van een Azure Load Balancer of een gedistribueerde netwerknaam (DNN) te voorkomen om verkeer naar uw HADR-oplossing te routeer.
  • Wijzig het cluster in minder agressieve parameters om onverwachte storingen door tijdelijke netwerkfouten of onderhoud van het Azure-platform te voorkomen. Zie Heartbeat- en drempelwaardeninstellingen voor meer informatie. Gebruik Windows Server 2012 aanbevolen waarden voor meer informatie:
    • SameSubnetDelay: 1 seconde
    • SameSubnetThreshold: 40 heartbeats
    • CrossSubnetDelay: 1 seconde
    • CrossSubnetThreshold: 40 heartbeats
  • Plaats uw VM's in een beschikbaarheidsset of in verschillende beschikbaarheidszones. Zie VM availability settings (VM-beschikbaarheidsinstellingen) voor meer informatie.
  • Gebruik één NIC per clusterknooppunt en één subnet.
  • Configureer het stemmen van het clusterquorum om 3 of meer oneven aantal stemmen te gebruiken. Wijs geen stemmen toe aan DR-regio's.
  • Houd resourcelimieten zorgvuldig in de gaten om onverwacht opnieuw opstarten of failovers vanwege resourcebeperkingen te voorkomen.
    • Zorg ervoor dat uw besturingssysteem, stuurprogramma's SQL Server nieuwste builds zijn.
    • Prestaties optimaliseren voor SQL Server virtuele Azure-VM's. Bekijk de andere secties in dit artikel voor meer informatie.
    • Verminder of verspreid de werkbelasting om resourcelimieten te voorkomen.
    • Ga naar een VM of schijf met een hogere limiet om beperkingen te voorkomen.

Houd rekening SQL Server de volgende best practices voor uw SQL Server beschikbaarheidsgroep of failovercluster- exemplaar:

  • Als u regelmatig onverwachte fouten ondervindt, volgt u de best practices voor prestaties die in de rest van dit artikel worden beschreven.
  • Als het optimaliseren SQL Server van uw VM-prestaties uw onverwachte failovers niet verhelpt, kunt u overwegen om de bewaking voor de beschikbaarheidsgroep of het failovercluster-exemplaar te verversen. Dit kan echter niet de onderliggende bron van het probleem aanpakken en kan symptomen maskeren door de kans op fouten te verminderen. Mogelijk moet u nog steeds de onderliggende hoofdoorzaak onderzoeken en aanpakken. Gebruik Windows Server 2012 aanbevolen waarden voor meer informatie:
    • Time-out voor lease: gebruik deze vergelijking om de maximale time-outwaarde voor de lease te berekenen:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Begin met 40 seconden. Als u de eerder aanbevolen waarden en gebruikt, mag u niet langer dan 80 seconden duren SameSubnetThreshold SameSubnetDelay voor de time-outwaarde van de lease.
    • Maximum aantal fouten in een opgegeven periode: u kunt deze waarde instellen op 6.
    • Time-out statuscontrole: u kunt deze waarde in eerste instantie instellen op 60000, indien nodig aanpassen.
  • Wanneer u de naam van het virtuele netwerk (VNN) en Azure Load Balancer gebruikt om verbinding te maken met uw HADR-oplossing, geeft u op in het connection string, zelfs als uw cluster slechts één MultiSubnetFailover = true subnet omvat.
    • Als de client geen ondersteuning biedt, moet u mogelijk en instellen om clientreferenties voor kortere MultiSubnetFailover = True RegisterAllProvidersIP = 0 duur in te HostRecordTTL = 300 cachen. Dit kan echter tot extra query's op de DNS-server leiden.
  • Als u verbinding wilt maken met uw HADR-oplossing met behulp van de gedistribueerde netwerknaam (DNN), moet u rekening houden met het volgende:
    • U moet een client-stuurprogramma gebruiken dat ondersteuning biedt MultiSubnetFailover = True voor , en deze parameter moet zich in de connection string.
    • Gebruik een unieke DNN-poort in de connection string verbinding te maken met de DNN-listener voor een beschikbaarheidsgroep.
  • Gebruik een databasespiegelingsgroep connection string voor een basisbeschikbaarheidsgroep om de noodzaak van een load balancer of DNN over te slaan.
  • Valideer de sectorgrootte van uw VHD's voordat u uw oplossing voor hoge beschikbaarheid implementeert om te voorkomen dat uw I/O's verkeerd zijn uitgelijnd. Zie KB3009974 voor meer informatie.

Zie de uitgebreide best practices voor HADR voor meer informatie.

Volgende stappen

Zie de andere artikelen in deze reeks voor meer informatie:

Zie Beveiligingsoverwegingen voor beveiligingsoverwegingen voor SQL Server in Azure Virtual Machines.

Overweeg om SQL evaluatie in te SQL Server op Azure-VM's.

Bekijk andere SQL Server virtual machine op SQL Server overzicht van Azure Virtual Machines. Als u vragen hebt over virtuele machines met SQL Server, raadpleegt u Veelgestelde vragen.