Dela via

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

  • Artikel

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

Den här artikeln innehåller en snabb checklista som en serie metodtips och riktlinjer för att optimera prestanda för din SQL Server på virtuella Azure-datorer (VM).

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

Aktivera SQL-utvärdering för SQL Server på virtuella Azure-datorer och din SQL Server utvärderas mot kända metodtips med resultat på SQL VM-hanteringssida i Azure-portalen.

Videor om de senaste funktionerna för att optimera prestanda för virtuella SQL Server-datorer och automatisera hanteringen finns i följande dataexponerade videor:

Överblick

När du kör SQL Server på Azure Virtual Machines fortsätter du att använda samma alternativ för justering av databasprestanda som gäller för SQL Server i lokala servermiljöer. Prestandan för en relationsdatabas i ett offentligt moln beror dock på många faktorer, till exempel storleken på en virtuell dator och konfigurationen av datadiskarna.

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.

Installera SQL Server manuellt på en virtuell Azure-dator

Om du planerar att installera SQL Server manuellt på en virtuell Azure-dator bör du tänka på följande:

  • Kontrollera att du har en produktnyckel redo för installationen.
  • Undvik konfigurationer som inte stöds, till exempel:
    • Fler än 64 virtuella kärnor per NUMA-nod.
    • Lagring med 8 KB sektorstorlek.
    • Skalningsuppsättningar för virtuella Azure-datorer.
  • Om de inte redan finns skapar du mapparna för din SQL Server-installation och dina datafiler innan du startar installationsmediet.
  • Kopiera installationsmediet till en lokal enhet i stället för att installera direkt från den monterade ISO:en.
  • Efter installationen registrerar du den virtuella SQL Server-datorn med SQL Server IaaS-agenttillägget för att automatisera hanteringsuppgifter.

VM-storlek

Checklistan i det här avsnittet beskriver bästa praxis för VM-storlek för SQL Server på virtuella Azure-datorer.

  • Identifiera prestandaegenskaper för arbetsbelastningar för att fastställa lämplig VM-storlek för ditt företag.
  • Om du migrerar till Azure använder du verktyg som Data Migration Assistant och SKU-rekommendation för att hitta rätt VM-storlek för din befintliga SQL Server-arbetsbelastning och sedan migrera med Azure Data Studio-.
  • Använd Azure Marketplace-avbildningar för att distribuera dina virtuella SQL Server-datorer eftersom SQL Server-inställningarna och lagringsalternativen har konfigurerats för optimala prestanda.
  • Använd VM-storlekar med 4 eller fler vCPUs.
  • Använd minnesoptimerade storlekar för virtuella datorer för bästa prestanda för SQL Server-arbetsbelastningar.
    • Edsv5-serienoch Msv3- och Mdsv3-serien erbjuder ett optimalt minne till vCore-förhållande som föreslås för OLTP-arbetsbelastningar.
    • De virtuella datorerna i Mbdsv3-serien erbjuder den bästa prestandan för SQL Server-arbetsbelastningar på Azure-virtuella datorer. Tänk på den här serien först för verksamhetskritiska OLTP- och datalager-SQL Server-arbetsbelastningar.
    • Ebdsv5-serien ger ett högt I/O-dataflöde till vCore-förhållande, tillsammans med ett förhållande mellan minne och virtuell kärna på 8:1. Den här serien erbjuder bästa prisprestanda för SQL Server-arbetsbelastningar på virtuella Azure-datorer. Tänk på de här virtuella datorerna först för de flesta SQL Server-arbetsbelastningar.
    • Familjen M-serien erbjuder virtuella datorer med den högsta minnesallokeringen i Azure.
    • Mbsv3- och Mbdsv3-serien virtuella datorer ger en hög minnesallokering och det högsta förhållandet mellan I/O-dataflöde och virtuella kärnor i M-serien, tillsammans med ett konsekvent förhållande mellan minne och virtuell kärna på minst 8:1.
  • Starta utvecklingsmiljöer med D-serien på lägre nivå, B-serien eller Av2-serien och utöka din miljö över tid.
  • Kontrollera stöd för virtuella datorer för att undvika konfigurationer som inte stöds.

Lagring

Checklistan i det här avsnittet beskriver bästa praxis för lagring för SQL Server på virtuella Azure-datorer.

  • Ö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 det är tillgängligt konfigurerar du tempdbdata och loggfiler på den lokala SSD-volymen D:. 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 okachade IOPS och använda datacaching som en prestandafunktion för dataläsningar samtidigt som du undviker begränsningar från virtuella maskiner 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 planen för loggdriften av kapacitet och testprestanda i förhållande till kostnad vid utvärdera 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 skrivaccelerator istället för att använda Azure Ultra-disks.
    • Placera tempdb på den tillfälliga disken (den tillfälliga disken är tillfällig och standard är D:\) för de flesta SQL Server-arbetsbelastningar som inte ingår i en redundansklusterinstans (FCI) när du har valt den optimala VM-storleken.
    • För redundansklusterinstanser (FCI), placera tempdb på den delade lagringen.
      • Om FCI-arbetsbelastningen är starkt beroende av tempdb diskprestanda, placera då tempdb enligt 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.
  • Ställ in värdcache till skrivskyddad för datafildiskar.
  • Ange värdcachelagring till ingen för loggfildiskar.
    • 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 disksprängning (P1-P20) bör endast övervägas för mindre dev/test-arbetsbelastningar och avdelningssystem.
  • Optimera lagringsprestanda genom att planera för högsta okända IOPS och använda datacachelagring som en prestandafunktion för dataläsningar samtidigt som du undviker begränsningar av 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.

Säkerhet

Checklistan i det här avsnittet beskriver bästa praxis för säkerhet för SQL Server på virtuella Azure-datorer.

SQL Server-funktioner tillhandahåller metoder för att skydda data på databasnivå som kan kombineras med säkerhetsfunktioner på infrastrukturnivå. Tillsammans ger dessa funktioner djupgående skydd på infrastrukturnivå för molnbaserade lösningar och hybridlösningar. Med Azure-säkerhetsåtgärder är det dessutom möjligt att kryptera känsliga data, skydda virtuella datorer mot virus och skadlig kod, skydda nätverkstrafik, identifiera och identifiera hot, uppfylla efterlevnadskrav och tillhandahåller en enda metod för administration och rapportering för eventuella säkerhetsbehov i hybridmolnet.

  • Använd Microsoft Defender för molnet för att utvärdera och vidta åtgärder för att förbättra säkerhetsstatusen för din datamiljö. Funktioner som Azure Advanced Threat Protection (ATP) kan användas i dina hybridarbetsbelastningar för att förbättra säkerhetsutvärderingen och ge möjlighet att reagera på risker. Om du registrerar din virtuella SQL Server-dator med SQL IaaS Agent-tillägget visas Microsoft Defender for Cloud-utvärderingar i den virtuella SQL-datorresursen i Azure-portalen.
  • Använd Microsoft Defender för SQL för att identifiera och minimera potentiella databassårbarheter, samt identifiera avvikande aktiviteter som kan tyda på ett hot mot sql Server-instansen och databasskiktet.
  • Sårbarhetsbedömning är en del av Microsoft Defender för SQL som kan identifiera och hjälpa till att åtgärda potentiella risker för DIN SQL Server-miljö. Den ger insyn i ditt säkerhetstillstånd och innehåller åtgärdsbara steg för att lösa säkerhetsproblem.
  • Använd konfidentiella virtuella Azure-datorer för att förstärka skyddet av dina data som används och vilande data mot värdoperatörsåtkomst. Med konfidentiella virtuella Azure-datorer kan du tryggt lagra känsliga data i molnet och uppfylla strikta efterlevnadskrav.
  • Om du använder SQL Server 2022 bör du överväga att använda Microsoft Entra-autentisering för att ansluta till din instans av SQL Server.
  • Azure Advisor analyserar din resurskonfigurations- och användningstelemetri och rekommenderar sedan lösningar som kan hjälpa dig att förbättra kostnadseffektivitet, prestanda, hög tillgänglighet och säkerhet för dina Azure-resurser. Använd Azure Advisor på den virtuella datorn, resursgruppen eller prenumerationsnivån för att identifiera och tillämpa metodtips för att optimera dina Azure-distributioner.
  • Använd Azure Disk Encryption när din efterlevnad och säkerhet kräver att du krypterar data från slutpunkt till slutpunkt med hjälp av dina krypteringsnycklar, inklusive kryptering av den tillfälliga disken (lokalt ansluten).
  • Managed Disks krypteras i vila som standard med hjälp av Azure Storage Service Encryption, där krypteringsnycklarna är Microsoft-hanterade nycklar som lagras i Azure.
  • En jämförelse av krypteringsalternativen för hanterade diskar finns i jämförelsediagrammet för hanterad diskkryptering
  • Hanteringsportar bör stängas på dina virtuella datorer – Öppna fjärrhanteringsportar gör den virtuella datorn utsatt för en hög risknivå vid internetbaserade attacker. Dessa attacker försöker råstyra autentiseringsuppgifter för att få administratörsåtkomst till datorn.
  • Aktivera JIT-åtkomst (Just-in-time) för virtuella Azure-datorer
  • Använd Azure Bastion via Remote Desktop Protocol (RDP).
  • Lås portar och tillåt endast nödvändig programtrafik med hjälp av Azure Firewall som är en hanterad brandvägg som en tjänst (FaaS) som beviljar/nekar serveråtkomst baserat på den ursprungliga IP-adressen.
  • Använd nätverkssäkerhetsgrupper (NSG:er) för att filtrera nätverkstrafik till och från Azure-resurser på virtuella Azure-nätverk
  • Använd programsäkerhetsgrupper för att gruppera servrar tillsammans med liknande portfiltreringskrav, med liknande funktioner, till exempel webbservrar och databasservrar.
  • För webb- och programservrar använder du DDoS-skydd (Azure Distributed Denial of Service). DDoS-attacker är utformade för att överbelasta och tömma nätverksresurser, vilket gör appar långsamma eller svarar inte. Det är vanligt att DDoS-attacker riktas mot användargränssnitt. Azure DDoS-skydd sanerar oönskad nätverkstrafik innan det påverkar tjänstens tillgänglighet
  • Använd VM-tillägg för att hantera skadlig kod, önskat tillstånd, hotidentifiering, förebyggande åtgärder och åtgärder för att hantera hot på operativsystem-, dator- och nätverksnivå:
  • Använd Azure Policy för att skapa affärsregler som kan tillämpas på din miljö. Azure-principer utvärderar Azure-resurser genom att jämföra egenskaperna för dessa resurser med regler som definierats i JSON-format.
  • Med Azure Blueprints kan molnarkitekter och centrala informationsteknikgrupper definiera en upprepningsbar uppsättning Azure-resurser som implementerar och följer organisationens standarder, mönster och krav. Azure Blueprints skiljer sig från Azure-policyer.
  • Använd Windows Server 2019 eller Windows Server 2022 för att vara FIPS- kompatibel med SQL Server på virtuella Azure-datorer.

SQL Server-funktioner

Följande är en snabb checklista med metodtips för KONFIGURATIONsinställningar för SQL Server när du kör dina SQL Server-instanser på en virtuell Azure-dator i produktion:

Azure-funktioner

Följande är en snabb checklista med metodtips för Azure-specifik vägledning när du kör din SQL Server på en virtuell Azure-dator:

HADR-konfiguration

Checklistan i det här avsnittet beskriver bästa praxis för HADR för SQL Server på virtuella Azure-datorer.

Funktioner för hög tillgänglighet och haveriberedskap (HADR), till exempel Always On-tillgänglighetsgrupp och redundansklusterinstans förlitar sig på den underliggande tekniken Windows Server Failover Cluster. Granska metodtipsen för att ändra DINA HADR-inställningar för att bättre stödja molnmiljön.

Överväg följande metodtips för ditt Windows-kluster:

  • Distribuera dina virtuella SQL Server-datorer till flera undernät när det är möjligt för att undvika beroendet av en Azure Load Balancer eller ett distribuerat nätverksnamn (DNN) för att dirigera trafik till din HADR-lösning.
  • Ändra klustret till mindre aggressiva parametrar för att undvika oväntade avbrott från tillfälliga nätverksfel eller Azure-plattformsunderhåll. Mer information finns i pulsslag och tröskelvärdesinställningar. Använd följande rekommenderade värden för Windows Server 2012 och senare:
    • SameSubnetDelay: 1 sekund
    • SameSubnetThreshold: 40 hjärtslag
    • CrossSubnetDelay: 1 sekund
    • CrossSubnetThreshold: 40 pulsslag
  • Placera dina virtuella datorer i en tillgänglighetsuppsättning eller i olika tillgänglighetszoner. Mer information finns i VM-tillgänglighetsinställningar.
  • Använd ett enda nätverkskort per klusternod.
  • Konfigurera kluster kvorumröstning för att använda 3 eller fler udda röster. Tilldela inte röster till DR-regioner.
  • Övervaka noggrant resursbegränsningar för att undvika oväntade omstarter eller växlingar på grund av resursbegränsningar.
    • Se till att operativsystemet, drivrutinerna och SQL Server är de senaste versionerna.
    • Optimera prestanda för SQL Server på virtuella Azure-datorer. Läs de andra avsnitten i den här artikeln om du vill veta mer.
    • Minska eller sprida ut arbetsbelastningen för att undvika resursgränser.
    • Byt till en virtuell dator eller disk som har högre gränser för att undvika begränsningar.

För sql Server-tillgänglighetsgruppen eller redundansklusterinstansen bör du överväga följande metodtips:

  • Om du ofta får oväntade fel följer du de bästa praxis för prestanda som beskrivs i resten av den här artikeln.
  • Om optimeringen av prestanda för virtuella SQL Server-datorer inte löser dina oväntade failoverhändelser bör du överväga att lätta på övervakningen för tillgänglighetsgruppen eller failoverklusterinstansen. Detta kan dock inte åtgärda den underliggande källan till problemet och kan maskera symtom genom att minska sannolikheten för fel. Du kan fortfarande behöva undersöka och åtgärda grundorsaken. Använd följande rekommenderade värden för Windows Server 2012 eller senare:
    • Tidsgräns för lån: Använd den här ekvationen för att beräkna det maximala tidsgränsvärdet för lån:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Börja med 40 sekunder. Om du använder de tidigare rekommenderade avslappnade SameSubnetThreshold- och SameSubnetDelay-värdena, bör du inte överskrida 80 sekunder för leasingens tidsgräns.
    • Maximalt antal fel under en angiven period: Ange värdet till 6.
  • När du använder det virtuella nätverksnamnet (VNN) och en Azure Load Balancer för att ansluta till DIN HADR-lösning anger du MultiSubnetFailover = true i anslutningssträngen, även om klustret bara sträcker sig över ett undernät.
    • Om klienten inte stöder MultiSubnetFailover = True kan du behöva ange RegisterAllProvidersIP = 0 och HostRecordTTL = 300 cachelagrar klientautentiseringsuppgifter under kortare tidsperioder. Detta kan dock orsaka ytterligare frågor till DNS-servern.
  • Om du vill ansluta till DIN HADR-lösning med hjälp av det distribuerade nätverksnamnet (DNN) bör du tänka på följande:
    • Du måste använda en klientdrivrutin som stöder MultiSubnetFailover = Trueoch den här parametern måste finnas i anslutningssträngen.
    • Använd en unik DNN-port i anslutningssträngen när du ansluter till DNN-lyssnaren för en tillgänglighetsgrupp.
  • Använd en databasspeglingsanslutningssträng för en grundläggande tillgänglighetsgrupp för att kringgå behovet av en lastbalanserare eller DNN.
  • Verifiera sektorstorleken för dina virtuella hårddiskar innan du distribuerar din lösning för hög tillgänglighet för att undvika feljusterade I/Os. Mer information finns i KB3009974.
  • Om SQL Server-databasmotorn, AlwaysOn-tillgänglighetsgruppens lyssnare eller redundansklusterinstansens hälsoavsökning har konfigurerats för att använda en port mellan 49 152 och 65 536 (standard dynamiskt portintervall för TCP/IP-), lägger du till ett undantag för varje port. Detta förhindrar att andra system tilldelas samma port dynamiskt. I följande exempel skapas ett undantag för port 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Prestandafelsökning

Följande är en lista över resurser som hjälper dig att felsöka prestandaproblem med SQL Server ytterligare.

Relaterat innehåll

Överväg att aktivera SQL-utvärdering för SQL Server på virtuella Azure-datorer.

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.