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

  • Artikel

Gäller för:SQL Server på en virtuell Azure-dator

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).

Omfattande information finns i de andra artiklarna i den här serien: VM-storlek, Lagring, Säkerhet, 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å hanteringssidan för SQL VM 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:

Översikt

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.

Storlek på virtuell dator

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

  • Den nya Ebdsv5-serien ger det högsta I/O-dataflödet till virtuella kärnor i Azure tillsammans med ett förhållande mellan minne och virtuell kärna på 8. Den här serien erbjuder bästa prisprestanda för SQL Server-arbetsbelastningar på virtuella Azure-datorer. Tänk på den här serien först för de flesta SQL Server-arbetsbelastningar.
  • Använd VM-storlekar med 4 eller fler vCPU:er som E4ds_v5 eller högre.
  • Använd minnesoptimerade storlekar på virtuella datorer för att få bästa möjliga prestanda för SQL Server-arbetsbelastningar.
  • Edsv5-serien, M-serien och Mv2-serien erbjuder det optimala förhållandet mellan minne och virtuell kärna som krävs för OLTP-arbetsbelastningar.
  • De virtuella datorerna i M-serien erbjuder det högsta förhållandet mellan minne och virtuell kärna i Azure. Överväg dessa virtuella datorer för verksamhetskritiska arbetsbelastningar och arbetsbelastningar för informationslager.
  • 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.
  • Samla in målarbetsbelastningens prestandaegenskaper och använd dem för att fastställa lämplig VM-storlek för ditt företag.
  • Använd rekommendationsverktygen datamigreringsassistenten och SKU för att hitta rätt VM-storlek för din befintliga SQL Server-arbetsbelastning.
  • Använd Azure Data Studio för att migrera till Azure.

Lagring

Checklistan i det här avsnittet beskriver metodtipsen 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, logg och tempdb filer innan du väljer disktyp.
  • Om det är tillgängligt konfigurerar tempdbdu data och loggfiler på den lokala SSD-volymen D: . SQL IaaS-agenttillägget hanterar mappen och behörigheterna som behövs vid ometablering.
  • För att optimera lagringsprestanda planerar du för högsta tillgängliga IOPS och använder datacachelagring som prestandafunktion för dataläsningar samtidigt som du undviker begränsningar för virtuella datorer och diskar.
  • Överväg att använda Azure Elastic SAN för SQL Server-arbetsbelastningar för bättre kostnadseffektivitet på grund av lagringskonsolidering, delade dynamiska prestanda och möjligheten att köra högre dataflöde för lagring utan att behöva uppgradera en virtuell dator.
  • Placera data, logg 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-serien anvä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 loggenhetsplanen för kapacitet och testprestanda jämfört med kostnad vid utvärdering av antingen Premium SSD v2 eller Premium SSD P30 – P80-diskar
    • Placera tempdb på den tillfälliga disken (den tillfälliga disken är tillfällig och standardvärdet D:\är ) för de flesta SQL Server-arbetsbelastningar som inte ingår i en redundansklusterinstans (FCI) när du har valt den optimala VM-storleken.
      • Om kapaciteten på den lokala enheten inte räcker för tempdbkan du överväga att storleksanpassa den virtuella datorn. Mer information finns i Principer för cachelagring av datafiler.
    • För FCI-plats tempdb på den delade lagringen.
      • Om FCI-arbetsbelastningen är starkt beroende av tempdb diskprestanda kan du som en avancerad konfigurationsplats tempdb 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 en åtgärd från FCI.
  • Stripe flera Azure-datadiskar med hjälp av Lagringsutrymmen för att öka I/O-bandbredden upp till måldatorns IOPS- och dataflödesgränser.
  • Ange värdcachelagring 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.
  • 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 beaktas för mindre dev/test-arbetsbelastningar och avdelningssystem.
  • Optimera lagringsprestanda genom att planera för högsta tillgängliga IOPS och använda datacachelagring som prestandafunktion för dataläsningar samtidigt som du undviker att begränsa/begränsa virtuella datorer 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 har konfigurerats för att följa metodtipsen.
  • Granska och övervaka disk- och VM-gränser med hjälp av mått för lagrings-I/O-användning.
  • 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 metodtipsen för säkerhet för SQL Server på virtuella Azure-datorer.

SQL Server-funktioner ger en säkerhetsmetod på datanivå och är hur du uppnår skydd på djupet 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 utnyttjas i dina hybridarbetsbelastningar för att förbättra säkerhetsutvärderingen och ge möjlighet att reagera på risker. När du registrerar din virtuella SQL Server-dator med SQL IaaS-agenttillägget visas Microsoft Defender för molnet utvärderingar i den virtuella SQL-datorresursen i Azure-portalen.
  • Använd Microsoft Defender för SQL för att identifiera och minimera potentiella sårbarheter i databasen, 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 resurskonfiguration 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 temporär).
  • Hanterade diskar krypteras som standard i vila med 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 RDP (Remote Desktop Protocol).
  • 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 i 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.
  • Azure Blueprint gör det möjligt för molnarkitekter och centrala IT-grupper att definiera en upprepningsbar uppsättning med Azure-resurser som implementerar och tillämpar en organisations standarder, mönster och krav. Azure Blueprints skiljer sig från Azure-principer.

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 HADR-metodtipsen för SQL Server på virtuella Azure-datorer.

Funktioner för hög tillgänglighet och haveriberedskap (HADR), till exempel AlwaysOn-tillgänglighetsgruppen och redundansklusterinstansen förlitar sig på underliggande Windows Server-redundansklusterteknik. 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 inställningar för pulsslag och tröskelvärden. Använd följande rekommenderade värden för Windows Server 2012 och senare:
    • SameSubnetDelay: 1 sekund
    • SameSubnetThreshold: 40 pulsslag
    • CrossSubnetDelay: 1 sekund
    • CrossSubnetThreshold: 40 pulsslag
  • Placera dina virtuella datorer i en tillgänglighetsuppsättning eller i olika tillgänglighetszoner. Mer information finns i Tillgänglighetsinställningar för virtuella datorer.
  • Använd ett enda nätverkskort per klusternod.
  • Konfigurera klusterkvorumröstning för att använda 3 eller fler udda antal röster. Tilldela inte röster till DR-regioner.
  • Övervaka resursbegränsningar noggrant för att undvika oväntade omstarter eller redundansvä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.
    • Flytta till en virtuell dator eller disk som hans 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 får ofta oväntade fel följer du de metodtips 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 redundansväxlingar kan du överväga att lätta på övervakningen för tillgänglighetsgruppen eller redundansklusterinstansen. 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 den underliggande rotorsaken. 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 avslappnade SameSubnetThreshold värden och SameSubnetDelay värden som rekommenderades tidigare ska du inte överskrida 80 sekunder för tidsgränsvärdet för lån.
    • Maximalt antal fel under en angiven period: Ange det här 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äng, ä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 klientens autentiseringsuppgifter 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 = True, och den här parametern måste finnas i anslutningssträng.
    • Använd en unik DNN-port i anslutningssträng när du ansluter till DNN-lyssnaren för en tillgänglighetsgrupp.
  • Använd en databasspegling anslutningssträ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 hälsoavsökningen för redundansklusterinstanser är konfigurerade att använda en port mellan 49 152 och 65 536 (standardintervallet för dynamisk port 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 ytterligare felsöka prestandaproblem med SQL Server.

Relaterat innehåll

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

Granska andra SQL Server Virtual Machine-artiklar på SQL Server på Översikt över virtuella Azure-datorer. Om du har frågor om virtuella SQL Server-datorer kan du läsa Vanliga frågor.