SQL Server Azure Virtual Machines DBMS-distribution för SAP NetWeaver
Det här dokumentet beskriver flera olika områden att tänka på när du distribuerar SQL Server för SAP-arbetsbelastning i Azure IaaS. Som en förutsättning för det här dokumentet läser du dokumentet Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning och andra guider i SAP-arbetsbelastningen i Azure-dokumentationen.
Viktigt!
Omfånget för det här dokumentet är Windows-versionen på SQL Server. SAP stöder inte Linux-versionen av SQL Server med någon av SAP-programvaran. I dokumentet diskuteras inte Microsoft Azure SQL Database, som är ett erbjudande om plattform som en tjänst för Microsoft Azure-plattformen. Diskussionen i det här dokumentet handlar om att köra SQL Server-produkten som den är känd för lokala distributioner i Azure Virtual Machines, vilket utnyttjar funktionen Infrastruktur som en tjänst i Azure. Databasfunktionerna och funktionerna mellan dessa två erbjudanden skiljer sig åt och bör inte blandas ihop med varandra. Mer information finns i Azure SQL Database.
I allmänhet bör du överväga att använda de senaste SQL Server-versionerna för att köra SAP-arbetsbelastningen i Azure IaaS. De senaste SQL Server-versionerna ger bättre integrering i några av Azures tjänster och funktioner. Eller har ändringar som optimerar åtgärder i en Azure IaaS-infrastruktur.
Allmän dokumentation om SQL Server som körs i Azure Virtual Machines (VM) finns i följande artiklar:
- SQL Server på virtuella Azure-datorer (Windows)
- Automatisera hanteringen med Windows SQL Server IaaS-agenttillägget
- Konfigurera Azure Key Vault-integrering för SQL Server på virtuella Azure-datorer (Resource Manager)
- Checklista: Metodtips för SQL Server på virtuella Azure-datorer
- Lagring: Metodtips för prestanda för SQL Server på virtuella Azure-datorer
- Metodtips för HADR-konfiguration (SQL Server på virtuella Azure-datorer)
Inte allt innehåll och alla instruktioner som görs i den allmänna DOKUMENTATIONen om SQL Server i virtuella Azure-datorer gäller för SAP-arbetsbelastningen. Men dokumentationen ger ett gott intryck av principerna. Ett exempel på funktioner som inte stöds för SAP-arbetsbelastningar är användningen av FCI-klustring.
Det finns viss SQL Server i IaaS-specifik information som du bör känna till innan du fortsätter:
- Stöd för SQL-version: Även med SAP Note #1928533 som anger att den lägsta SQL Server-versionen som stöds är SQL Server 2008 R2, dikteras även fönstret med SQL Server-versioner som stöds i Azure med SQL Server-livscykeln. Det utökade underhållet av SQL Server 2012 upphörde i mitten av 2022. Därför bör den aktuella lägsta versionen för nyligen distribuerade system vara SQL Server 2014. Ju nyare, desto bättre. De senaste SQL Server-versionerna ger bättre integrering i några av Azures tjänster och funktioner. Eller har ändringar som optimerar åtgärder i en Azure IaaS-infrastruktur.
- Använda avbildningar från Azure Marketplace: Det snabbaste sättet att distribuera en ny virtuell Microsoft Azure-dator är att använda en avbildning från Azure Marketplace. Det finns avbildningar på Azure Marketplace som innehåller de senaste SQL Server-versionerna. Avbildningarna där SQL Server redan är installerat kan inte användas omedelbart för SAP NetWeaver-program. Orsaken är att SQL Server-standardsortering installeras i dessa avbildningar och inte den sortering som krävs för SAP NetWeaver-system. Om du vill använda sådana avbildningar kontrollerar du stegen som beskrivs i kapitlet Använda en SQL Server-avbildning från Microsoft Azure Marketplace.
- Stöd för SQL Server-flera instanser i en enda virtuell Azure-dator: Den här distributionsmetoden stöds. Tänk dock på resursbegränsningar, särskilt kring nätverks- och lagringsbandbredd för den vm-typ som du använder. Detaljerad information finns i artikeln Storlekar för virtuella datorer i Azure. Dessa kvotbegränsningar kan hindra dig från att implementera samma arkitektur för flera instanser som du kan implementera lokalt. När det gäller konfigurationen och interferensen av att dela de resurser som är tillgängliga på en enskild virtuell dator måste samma överväganden som lokalt beaktas.
- Flera SAP-databaser i en enda SQL Server-instans på en enda virtuell dator: Konfigurationer som dessa stöds. Överväganden för flera SAP-databaser som delar delade resurser för en enskild SQL Server-instans är desamma som för lokala distributioner. Tänk på andra begränsningar, till exempel antalet diskar som kan kopplas till en viss typ av virtuell dator. Eller nätverks- och lagringskvotgränser för specifika typer av virtuella datorer som detaljerade storlekar för virtuella datorer i Azure.
Nya virtuella datorer i M-serien och SQL Server
Azure släppte några nya familjer med SKU:er i M-serien under familjen Mv3. Vissa typer av virtuella datorer i den här familjen ska inte användas för SQL Server, inklusive SQL Server 2022 utan att inaktivera SMT (Hyperthreading) i Windows Server-gästoperativsystemet. Orsaken är antalet NUMA-noder som presenteras i Windows Server-gästoperativsystemet, som med större än 64 vCPU:er är för stort för att SQL Server ska rymmas. Genom att inaktivera SMT i Windows Server-gästoperativsystemet minskar antalet virtuella processorer. Så att antalet virtuella processorer är mindre än 64 i varje NUMA-nod. Hur du inaktiverar SMT beskrivs här. De specifika typerna av virtuella datorer är:
- M176(d)s_3_v3 – inaktivera SMT eller använd M176bds_4_v3 eller M176bds_4_v3 som alternativ
- M176(d)s_4_v3 – inaktivera SMT eller använd M176bds_4_v3 som alternativ
- M624(d)s_12_v3 – inaktivera SMT eller använd M416ms_v2 som alternativ
- M832(d)s_12_v3 – inaktivera SMT eller använd M416ms_v2 som alternativ
- M832i(d)s_16_v3 – inaktivera SMT eller använd M416ms_v2 som alternativ
Kommentar
Med några av de nya typerna av virtuella M(b)v3-datorer kan användningen av läscachelagrad Premium SSD v1-lagring resultera i lägre IOPS-priser och dataflöde för läsning och skrivning än du skulle få om du inte använder läscachen.
Rekommendationer om VM/VHD-struktur för SAP-relaterade SQL Server-distributioner
I enlighet med den allmänna beskrivningen operativsystem, körbara SQL Server-filer ska SAP-körbara filer finnas eller installeras separata Azure-diskar. Vanligtvis används de flesta SQL Server-systemdatabaser inte på hög nivå med SAP NetWeaver-arbetsbelastning. Systemdatabaserna för SQL Server bör dock vara tillsammans med de andra SQL Server-katalogerna på en separat Azure-disk. SQL Server tempdb ska antingen finnas på den icke-tillgängliga D:\-enheten eller på en separat disk.
- Med alla SAP-certifierade VM-typer (se SAP Note #1928533) kan tempdb-data och loggfiler placeras på den icke-baserade D:\-enheten.
- Med SQL Server-versioner, där SQL Server endast installerar tempdb med en datafil, rekommenderar vi att du använder flera tempdb-datafiler. Tänk på att D:\-enhetsvolymer skiljer sig åt i storlek och funktioner baserat på VM-typ. Exakta storlekar på D:\ -enheten för de olika virtuella datorerna finns i artikeln Storlekar för virtuella Windows-datorer i Azure.
Med de här konfigurationerna kan tempdb förbruka mer utrymme och viktigare I/O-åtgärder per sekund (IOPS) och lagringsbandbredd än vad systemenheten kan tillhandahålla. Den icke-existerande D:\-enheten ger också bättre I/O-svarstid och dataflöde. För att fastställa rätt tempdb-storlek kan du kontrollera tempdb-storlekarna på befintliga system.
Kommentar
Om du placerar tempdb-datafiler och loggfiler i en mapp på den D:\-enhet som du skapade, måste du se till att mappen finns efter en omstart av den virtuella datorn. Eftersom D:\-enheten kan initieras på nytt efter en omstart av en virtuell dator kan alla fil- och katalogstrukturer rensas. En möjlighet att återskapa eventuella katalogstrukturer på D:\-enheten innan SQL Server-tjänsten startas dokumenteras i den här artikeln.
En VM-konfiguration som kör SQL Server med en SAP-databas och där tempdb-data och tempdb-loggfil placeras på D:\ -enheten och Azure Premium Storage v1 eller v2 skulle se ut så här:
Diagrammet visar ett enkelt skiftläge. Som det framgår av artikeln Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning, Azure-lagringstyp, antal och storlek på diskar beror på olika faktorer. Men i allmänhet rekommenderar vi:
- För mindre och medelstora distributioner använder du en stor volym som innehåller SQL Server-datafilerna. Orsaken till den här konfigurationen är att det är enklare att hantera olika I/O-arbetsbelastningar om SQL Server-datafilerna inte har samma lediga utrymme. I stora distributioner, särskilt distributioner där kunden flyttade med en heterogen databasmigrering till SQL Server i Azure, använde vi separata diskar och distribuerade sedan datafilerna över dessa diskar. En sådan arkitektur lyckas bara när varje disk har samma antal datafiler, alla datafiler har samma storlek och har ungefär samma lediga utrymme.
- Använd D:\drive för tempdb så länge prestandan är tillräckligt bra. Om den övergripande arbetsbelastningen är begränsad i prestanda för tempdb som finns på D:\-enheten måste du flytta tempdb till Azure Premium Storage v1 eller v2 eller Ultra-disk enligt rekommendationerna i den här artikeln.
SQL Server proportionell fyllningsmekanism distribuerar läsningar och skrivningar till alla datafiler jämnt förutsatt att alla SQL Server-datafiler har samma storlek och har samma kostnadsfria takt. SAP på SQL Server ger bästa möjliga prestanda när läsningar och skrivningar fördelas jämnt över alla tillgängliga datafiler. Om en databas har för få datafiler eller om de befintliga datafilerna är mycket obalanserade är den bästa metoden att korrigera en R3load-export och -import. En R3load-export och -import innebär stilleståndstid och bör endast göras om det finns ett uppenbart prestandaproblem som måste lösas. Om datafilerna bara är måttligt olika storlekar ökar du alla datafiler till samma storlek och SQL Server ombalanserar data över tid. SQL Server växer automatiskt datafilerna jämnt om spårningsflagga 1117 har angetts eller om SQL Server 2016 eller senare används utan spårningsflagga.
Special för virtuella datorer i M-serien
För virtuella Azure M-series-datorer kan svarstiden som skrivs in i transaktionsloggen minskas jämfört med Azure Premium Storage-prestanda v1 när du använder Azure Write Accelerator. Om den angivna svarstiden för Premium Storage v1 begränsar skalbarheten för SAP-arbetsbelastningen kan disken som lagrar SQL Server-transaktionsloggfilen aktiveras för skrivacceleratorn. Information kan läsas i dokumentet Skrivaccelerator. Azure Write Accelerator fungerar inte med Azure Premium Storage v2 och Ultra Disk. I båda fallen är svarstiden bättre än vad Azure Premium Storage v1 levererar. Skrivacceleratorn stöder inte Premium SSD v2.
Kommentar
Med några av de nya typerna av virtuella M(b)v3-datorer kan användningen av läscachelagrad Premium SSD v1-lagring resultera i lägre IOPS-priser och dataflöde för läsning och skrivning än du skulle få om du inte använder läscachen.
Formatera diskarna
För SQL Server ska NTFS-blockstorleken för diskar som innehåller SQL Server-data och loggfiler vara 64 KB. Du behöver inte formatera D:\-enheten. Den här enheten är förformaterad.
Om du vill undvika att återställningen eller skapandet av databaser initierar datafilerna genom att nollställa innehållet i filerna kontrollerar du att användarkontexten som SQL Server-tjänsten körs i har underhållsaktiviteterna Användarrätt utför volym. Mer information finns i Databasinitiering av omedelbar fil.
SQL Server 2014 och senare SQL Server-versioner – Lagra databasfiler direkt på Azure Blob Storage
SQL Server 2014 och senare versioner öppnar möjligheten att lagra databasfiler direkt i Azure Blob Store utan "wrapper" för en virtuell hårddisk runt dem. Den här funktionen var avsedd att åtgärda brister i Azure-blocklagring för flera år sedan. I dag rekommenderas det inte att använda den här distributionsmetoden och i stället välja antingen Azure Premium Storage v1, Premium Storage v2 eller Ultra Disk. Beroende på kraven.
Överväganden för säkerhetskopiering/återställning för SQL Server
När du distribuerar SQL Server till Azure måste du granska säkerhetskopieringsarkitekturen. Även om systemet inte är ett produktionssystem måste SQL Server SAP-databasen säkerhetskopieras regelbundet. Eftersom Azure Storage behåller tre avbildningar är en säkerhetskopia nu mindre viktig för att kompensera för en lagringskrasch. Prioritetsorsaken till att upprätthålla en korrekt säkerhetskopierings- och återställningsplan är viktig för återställningsfunktioner vid tidpunkt för att kompensera för logiska/manuella fel. Målet är att antingen använda säkerhetskopior för att återställa databasen till en viss tidpunkt. Eller för att använda säkerhetskopiorna i Azure för att skapa ett annat system med att kopiera den befintliga databassäkerhetskopian.
Det finns flera sätt att säkerhetskopiera och återställa SQL Server-databaser i Azure. För att få den bästa översikten och informationen läser du dokumentet Säkerhetskopiering och återställning för SQL Server på virtuella Azure-datorer. Artikeln beskriver flera olika möjligheter.
Använda en SQL Server-avbildning från Microsoft Azure Marketplace
Microsoft erbjuder virtuella datorer på Azure Marketplace, som redan innehåller versioner av SQL Server. För SAP-kunder som behöver licenser för SQL Server och Windows kan det vara en möjlighet att använda dessa avbildningar för att täcka behovet av licenser genom att skapa virtuella datorer med SQL Server redan installerat. För att kunna använda sådana avbildningar för SAP måste följande överväganden göras:
- Sql Server-versioner som inte är utvärderingsversioner får högre kostnader än en virtuell Dator med endast Windows som distribueras från Azure Marketplace. Om du vill jämföra priser kan du läsa Priser för virtuella Windows-datorer och priser för VIRTUELLA DATORER för SQL Server Enterprise.
- Du kan bara använda SQL Server-versioner som stöds av SAP för deras programvara.
- Sortering av SQL Server-instansen, som är installerad på de virtuella datorer som erbjuds på Azure Marketplace, är inte sorteringen SAP NetWeaver kräver att SQL Server-instansen körs. Du kan dock ändra sorteringen med anvisningarna i följande avsnitt.
Ändra SQL Server-sortering för en virtuell Microsoft Windows-/SQL Server-dator
Eftersom SQL Server-avbildningarna på Azure Marketplace inte har konfigurerats för att använda sorteringen, som krävs för SAP NetWeaver-program, måste den ändras omedelbart efter distributionen. För SQL Server kan den här sorteringsändringen göras med följande steg så snart den virtuella datorn har distribuerats och en administratör kan logga in på den distribuerade virtuella datorn:
- Öppna ett Windows-kommandofönster som administratör.
- Ändra katalogen till C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
- Kör kommandot: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=
<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2<local_admin_account_name> är kontot, som definierades som administratörskontot när den virtuella datorn distribuerades för första gången via galleriet.
Processen bör bara ta några minuter. Utför följande steg för att se till att steget fick rätt resultat:
- Öppna SQL Server Management Studio.
- Öppna ett frågefönster.
- Kör kommandot sp_helpsort i SQL Server-huvuddatabasen.
Önskat resultat bör se ut så här:
Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data
Om resultatet är annorlunda stoppar du distributionen och undersöker varför installationskommandot inte fungerade som förväntat. Distribution av SAP NetWeaver-program till SQL Server-instans med andra SQL Server-kodsidor än den som nämns stöds INTE för NetWeaver-distributioner.
SQL Server-hög tillgänglighet för SAP i Azure
Med SQL Server i Azure IaaS-distributioner för SAP har du flera olika möjligheter att lägga till för att distribuera databasskiktet med hög tillgänglighet. Azure tillhandahåller olika serviceavtal för drifttid för en enskild virtuell dator med olika Azure-blocklagringar, ett par virtuella datorer som distribuerats i en Azure-tillgänglighetsuppsättning eller ett par virtuella datorer som distribuerats i Azure Tillgänglighetszoner. För produktionssystem förväntar vi oss att du distribuerar ett par virtuella datorer i en VM-skalningsuppsättning med flexibel orkestrering mellan två tillgänglighetszoner. Mer information finns i jämförelse av olika distributionstyper för SAP-arbetsbelastningar . En virtuell dator kör den aktiva SQL Server-instansen. Den andra virtuella datorn kör den passiva instansen
SQL Server-kluster med hjälp av Windows Scale-out File Server eller en delad Azure-disk
Med Windows Server 2016 introducerade Microsoft Lagringsutrymmen Direct. Baserat på Lagringsutrymmen, direktdistribution, stöds SQL Server FCI-klustring i allmänhet. Azure erbjuder även delade Azure-diskar som kan användas för Windows-klustring. För SAP-arbetsbelastningar stöder vi inte dessa ha-alternativ.
Leverans av SQL Server-logg
En funktion med hög tillgänglighet är SQL Server-loggöverföring. Om de virtuella datorer som deltar i HA-konfigurationen har lösning för arbetsnamn är det inga problem. Konfigurationen i Azure skiljer sig inte från någon konfiguration som görs lokalt när det gäller att konfigurera loggleverans och principerna kring loggleverans. Information om SQL Server-loggleverans finns i artikeln Om loggöverföring (SQL Server).
SQL Server-loggöverföringsfunktionen användes knappast i Azure för att uppnå hög tillgänglighet i en Azure-region. I följande scenarier använde SAP-kunder dock loggleveransen lyckades med Azure:
- Haveriberedskapsscenarier från en Azure-region till en annan Azure-region
- Haveriberedskapskonfiguration från lokal plats till en Azure-region
- Klipp ut scenarier från lokalt till Azure. I dessa fall används loggleverans för att synkronisera den nya databasdistributionen i Azure med det pågående produktionssystemet lokalt. Vid tidpunkten för överskärningen stängs produktionen av och den ser till att de senaste och senaste säkerhetskopieringarna av transaktionsloggen överfördes till Azure-databasdistributionen. Sedan öppnas Distributionen av Azure-databasen för produktion.
SQL Server AlwaysOn
Som Always On stöds för SAP lokalt (se SAP Note #1772688) stöds det i kombination med SAP i Azure. Det finns några särskilda överväganden när det gäller att distribuera SQL Server-tillgänglighetsgruppens lyssnare (ska inte förväxlas med Azure-tillgänglighetsuppsättningen). Därför krävs vissa olika installationssteg.
Några saker att tänka på när du använder en tillgänglighetsgruppslyssnare är:
- Det går bara att använda en tillgänglighetsgruppslyssnare med Windows Server 2012 eller senare som gästoperativsystem för den virtuella datorn. För Windows Server 2012 kontrollerar du att uppdateringen för att aktivera SQL Server-tillgänglighetsgrupplyssnare på Windows Server 2008 R2 och Windows Server 2012-baserade virtuella Microsoft Azure-datorer har tillämpats .
- För Windows Server 2008 R2 finns inte den här korrigeringen. I det här fallet skulle AlwaysOn behöva användas på samma sätt som databasspegling. Genom att ange en redundanspartner i anslutningssträngen (som görs via SAP default.pfl-parametern dbs/mss/server – se SAP Note #965908).
- Med hjälp av en tillgänglighetsgruppslyssnare måste du ansluta de virtuella databasdatorerna till en dedikerad lastbalanserare. Du bör tilldela statiska IP-adresser till nätverksgränssnitten för dessa virtuella datorer i AlwaysOn-konfigurationen (definiera en statisk IP-adress beskrivs i den här artikeln). Statiska IP-adresser jämfört med DHCP förhindrar tilldelning av nya IP-adresser i fall där båda de virtuella datorerna kan stoppas.
- Det krävs särskilda steg när du skapar WSFC-klusterkonfigurationen där klustret behöver en särskild TILLDELAd IP-adress, eftersom Azure med dess aktuella funktioner skulle tilldela klusternamnet samma IP-adress som den nod som klustret skapas på. Det här beteendet innebär att ett manuellt steg måste utföras för att tilldela klustret en annan IP-adress.
- Tillgänglighetsgruppens lyssnare kommer att skapas i Azure med TCP/IP-slutpunkter, som tilldelas till de virtuella datorer som kör de primära och sekundära replikerna i tillgänglighetsgruppen.
- Det kan finnas ett behov av att skydda dessa slutpunkter med ACL:er.
Detaljerad dokumentation om hur du distribuerar Always On med SQL Server på virtuella Azure-datorer, till exempel:
- Introduktion till SQL Server AlwaysOn-tillgänglighetsgrupper på virtuella Azure-datorer.
- Konfigurera en AlwaysOn-tillgänglighetsgrupp på virtuella Azure-datorer i olika regioner.
- Konfigurera en lastbalanserare för en AlwaysOn-tillgänglighetsgrupp i Azure.
- Metodtips för HADR-konfiguration (SQL Server på virtuella Azure-datorer)
Kommentar
När du läser Introduktion till SQL Server AlwaysOn-tillgänglighetsgrupper på virtuella Azure-datorer läser du om SQL Server:s DNN-lyssnare (Direct Network Name). Den här nya funktionen introducerades med SQL Server 2019 CU8. Den här nya funktionen gör användningen av en Azure-lastbalanserare som hanterar den virtuella IP-adressen för tillgänglighetsgruppens lyssnare föråldrad.
SQL Server AlwaysOn är den vanligaste funktionen för hög tillgänglighet och haveriberedskap som används i Azure för distributioner av SAP-arbetsbelastningar. De flesta kunder använder Always On för hög tillgänglighet i en enda Azure-region. Om distributionen endast är begränsad till två noder har du två alternativ för anslutning:
- Använda lyssnaren för tillgänglighetsgrupp. Med lyssnaren för tillgänglighetsgrupp måste du distribuera en Azure-lastbalanserare.
- Med SQL Server 2016 SP3, SQL Server 2017 CU 25 eller SQL Server 2019 CU8 eller senare SQL Server-versioner på Windows Server 2016 eller senare kan du använda DNN-lyssnaren (Direct Network Name) i stället för en Azure-lastbalanserare. DNN eliminerar kravet på en Azure-lastbalanserare.
Användning av anslutningsparametrarna för SQL Server Database-spegling bör endast övervägas för att undersöka problem med de andra två metoderna. I det här fallet måste du konfigurera anslutningen för SAP-programmen på ett sätt där båda nodnamnen namnges. Exakt information om en sådan KONFIGURATION på SAP-sidan dokumenteras i SAP Note #965908. Med det här alternativet behöver du inte konfigurera en lyssnare för tillgänglighetsgrupp. Och med det ingen Azure-lastbalanserare och med det kan undersöka problem med dessa komponenter. Men kom ihåg att det här alternativet bara fungerar om du begränsar tillgänglighetsgruppen till att omfatta två instanser.
De flesta kunder använder SQL Server AlwaysOn-funktionerna för haveriberedskapsfunktioner mellan Azure-regioner. Flera kunder använder också möjligheten att utföra säkerhetskopior från en sekundär replik.
SQL Server-transparent datakryptering
Många kunder använder SQL Server transparent datakryptering (TDE) när de distribuerar sina SAP SQL Server-databaser i Azure. SQL Server TDE-funktionen stöds fullt ut av SAP (se SAP Note #1380493).
Tillämpa SQL Server TDE
Om du utför en heterogen migrering från en annan databas, som körs lokalt, till Windows/SQL Server som körs i Azure, bör du skapa din tomma måldatabas i SQL Server i förväg. Som nästa steg använder du SQL Server TDE-funktioner mot den här tomma databasen. Anledningen till att du vill utföra i den här sekvensen är att det kan ta ett tag att kryptera den tomma databasen. SAP-importprocesserna importerar sedan data till den krypterade databasen under stilleståndstiden. Kostnaden för att importera till en krypterad databas har en mycket lägre tidspåverkan än att kryptera databasen efter exportfasen i fasen för stilleståndstid. Negativa upplevelser gjordes när du försökte tillämpa TDE med SAP-arbetsbelastning som körs ovanpå databasen. Rekommendationen behandlar därför distributionen av TDE som en aktivitet som måste utföras utan eller låg SAP-arbetsbelastning på den specifika databasen. Från SQL Server 2016 på kan du stoppa och återuppta TDE-genomsökningen som utför den inledande krypteringen. Dokumentet transparent datakryptering (TDE) beskriver kommandot och informationen.
I de fall där du flyttar SAP SQL Server-databaser från en lokal plats till Azure rekommenderar vi att du testar vilken infrastruktur du kan få krypteringen tillämpad snabbast på. I det här fallet bör du ha följande fakta i åtanke:
- Du kan inte definiera hur många trådar som används för att tillämpa datakryptering på databasen. Antalet trådar är huvudsakligen beroende av antalet diskvolymer som SQL Server-data och loggfiler distribueras över. Innebär att ju mer distinkta volymer (enhetsbeteckningar), desto fler trådar används parallellt för att utföra krypteringen. En sådan konfiguration motsäger lite med tidigare förslag på diskkonfiguration om att skapa ett eller ett mindre antal lagringsutrymmen för SQL Server-databasfilerna på virtuella Azure-datorer. En konfiguration med några volymer skulle leda till att några trådar kör krypteringen. En enda trådkryptering läser 64 KB-omfattningar, krypterar den och skriver sedan en post i transaktionsloggfilen, vilket anger att omfattningen krypterades. Därför är belastningen på transaktionsloggen måttlig.
- I äldre SQL Server-versioner blev säkerhetskopieringskomprimering inte längre effektiv när du krypterade SQL Server-databasen. Det här beteendet kan bli ett problem när din plan var att kryptera SQL Server-databasen lokalt och sedan kopiera en säkerhetskopia till Azure för att återställa databasen i Azure. Sql Server-säkerhetskopieringskomprimering kan uppnå ett komprimeringsförhållande på faktor 4.
- Med SQL Server 2016 introducerade SQL Server nya funktioner som gör det möjligt att komprimera säkerhetskopiering av krypterade databaser på ett effektivt sätt. Mer information finns i den här bloggen .
Använda Azure Key Vault
Azure erbjuder tjänsten för ett Key Vault för att lagra krypteringsnycklar. SQL Server på andra sidan erbjuder en anslutningsapp för att använda Azure Key Vault som arkiv för TDE-certifikaten.
Mer information om hur du använder Azure Key Vault för SQL Server TDE-listor som:
- Konfigurera Azure Key Vault-integrering för SQL Server på virtuella Azure-datorer (Resource Manager).
- Fler frågor från kunder om SQL Server transparent datakryptering – TDE + Azure Key Vault.
Viktigt!
Med SQL Server TDE, särskilt med Azure Key Vault, rekommenderar vi att du använder de senaste korrigeringarna av SQL Server 2014, SQL Server 2016 och SQL Server 2017. Anledningen är att baserat på kundfeedback tillämpades optimeringar och korrigeringar på koden. Kontrollera till exempel KBA #4058175.
Minsta distributionskonfigurationer
I det här avsnittet föreslår vi en uppsättning minsta konfigurationer för olika storlekar av databaser under SAP-arbetsbelastning. Det är för svårt att bedöma om dessa storlekar passar din specifika arbetsbelastning. I vissa fall kan vi vara generösa när det gäller minne jämfört med databasens storlek. Å andra sidan kan diskstorleken vara för låg för vissa av arbetsbelastningarna. Därför bör dessa konfigurationer behandlas som vad de är. Det är konfigurationer som bör ge dig en punkt att börja med. Konfigurationer för att finjustera dina specifika krav på arbetsbelastning och kostnadseffektivitet.
Ett exempel på en konfiguration för en liten SQL Server-instans med en databasstorlek mellan 50 GB och 250 GB kan se ut som
| Konfiguration | Virtuell databasdator | Kommentarer |
|---|---|---|
| VM-typ | E4s_v3/v4/v5 (4 vCPU/32 GiB RAM) | |
| Accelererat nätverk | Aktivera | |
| SQL Server-version | SQL Server 2019 eller senare | |
| Antal datafiler | 4 | |
| Antal loggfiler | 1 | |
| Antal temporära datafiler | 4 eller standard sedan SQL Server 2016 | |
| Operativsystem | Windows Server 2019 eller senare | |
| Diskaggregering | Lagringsutrymmen om du vill | |
| Filsystem | NTFS | |
| Formatera blockstorlek | 64 KB | |
| # och typ av datadiskar | Premium Storage v1: 2 x P10 (RAID0) Premium Storage v2: 2 x 150 GiB (RAID0) – standard-IOPS och dataflöde eller motsvarande Premium SSD v2 |
Cache = Skrivskyddad för Premium Storage v1 |
| # och typ av loggdiskar | Premium storage v1: 1 x P20 Premium Storage v2: 1 x 128 GiB – standard-IOPS och dataflöde eller motsvarande Premium SSD v2 |
Cache = NONE |
| Maximal minnesparameter för SQL Server | 90 % av det fysiska RAM-minnet | Förutsatt att en enskild instans |
Ett exempel på en konfiguration eller en liten SQL Server-instans med en databasstorlek mellan 250 GB och 750 GB, till exempel ett mindre SAP Business Suite-system, kan se ut som
| Konfiguration | Virtuell databasdator | Kommentarer |
|---|---|---|
| VM-typ | E16s_v3/v4/v5 (16 vCPU/128 GiB RAM) | |
| Accelererat nätverk | Aktivera | |
| SQL Server-version | SQL Server 2019 eller senare | |
| Antal datafiler | 8 | |
| Antal loggfiler | 1 | |
| Antal temporära datafiler | 8 eller standard sedan SQL Server 2016 | |
| Operativsystem | Windows Server 2019 eller senare | |
| Diskaggregering | Lagringsutrymmen om du vill | |
| Filsystem | NTFS | |
| Formatera blockstorlek | 64 KB | |
| # och typ av datadiskar | Premium Storage v1: 4 x P20 (RAID0) Premium Storage v2: 4 x 100 GiB – 200 GiB (RAID0) – standard-IOPS och 25 MB/sek extra dataflöde per disk eller motsvarande Premium SSD v2 |
Cache = Skrivskyddad för Premium Storage v1 |
| # och typ av loggdiskar | Premium storage v1: 1 x P20 Premium Storage v2: 1 x 200 GiB – standard-IOPS och dataflöde eller motsvarande Premium SSD v2 |
Cache = NONE |
| Maximal minnesparameter för SQL Server | 90 % av det fysiska RAM-minnet | Förutsatt att en enskild instans |
Ett exempel på en konfiguration för en medelstor SQL Server-instans med en databasstorlek mellan 750 GB och 2 000 GB, till exempel ett medelstort SAP Business Suite-system, kan se ut som
| Konfiguration | Virtuell databasdator | Kommentarer |
|---|---|---|
| VM-typ | E64s_v3/v4/v5 (64 vCPU/432 GiB RAM) | |
| Accelererat nätverk | Aktivera | |
| SQL Server-version | SQL Server 2019 eller senare | |
| Antal dataenheter | 16 | |
| Antal loggenheter | 1 | |
| Antal temporära datafiler | 8 eller standard sedan SQL Server 2016 | |
| Operativsystem | Windows Server 2019 eller senare | |
| Diskaggregering | Lagringsutrymmen om du vill | |
| Filsystem | NTFS | |
| Formatera blockstorlek | 64 KB | |
| # och typ av datadiskar | Premium Storage v1: 4 x P30 (RAID0) Premium Storage v2: 4 x 250 GiB – 500 GiB – plus 2 000 IOPS och 75 MB/sek dataflöde per disk eller motsvarande Premium SSD v2 |
Cache = Skrivskyddad för Premium Storage v1 |
| # och typ av loggdiskar | Premium storage v1: 1 x P20 Premium Storage v2: 1 x 400 GiB – standard-IOPS och extra dataflöde på 75 MB/sek eller motsvarande Premium SSD v2 |
Cache = NONE |
| Maximal minnesparameter för SQL Server | 90 % av det fysiska RAM-minnet | Förutsatt att en enskild instans |
Ett exempel på en konfiguration för en större SQL Server-instans med en databasstorlek på mellan 2 000 GB och 4 000 GB, till exempel ett större SAP Business Suite-system, kan se ut som
| Konfiguration | Virtuell databasdator | Kommentarer |
|---|---|---|
| VM-typ | E96(d)s_v5 (96 vCPU/672 GiB RAM) | |
| Accelererat nätverk | Aktivera | |
| SQL Server-version | SQL Server 2019 eller senare | |
| Antal dataenheter | 24 | |
| Antal loggenheter | 1 | |
| Antal temporära datafiler | 8 eller standard sedan SQL Server 2016 | |
| Operativsystem | Windows Server 2019 eller senare | |
| Diskaggregering | Lagringsutrymmen om du vill | |
| Filsystem | NTFS | |
| Formatera blockstorlek | 64 KB | |
| # och typ av datadiskar | Premium Storage v1: 4 x P30 (RAID0) Premium Storage v2: 4 x 500 GiB – 800 GiB – plus 2 500 IOPS och 100 MB/sek dataflöde per disk eller motsvarande Premium SSD v2 |
Cache = Skrivskyddad för Premium Storage v1 |
| # och typ av loggdiskar | Premium storage v1: 1 x P20 Premium Storage v2: 1 x 400 GiB – plus 1 000 IOPS och 75 MB/sek extra dataflöde eller motsvarande Premium SSD v2 |
Cache = NONE |
| Maximal minnesparameter för SQL Server | 90 % av det fysiska RAM-minnet | Förutsatt att en enskild instans |
Ett exempel på en konfiguration för en stor SQL Server-instans med en databasstorlek på 4 TB+, till exempel ett stort globalt använt SAP Business Suite-system, kan se ut som
| Konfiguration | Virtuell databasdator | Kommentarer |
|---|---|---|
| VM-typ | M-serien (1,0 till 4,0 TB RAM) | |
| Accelererat nätverk | Aktivera | |
| SQL Server-version | SQL Server 2019 eller senare | |
| Antal dataenheter | 32 | |
| Antal loggenheter | 1 | |
| Antal temporära datafiler | 8 eller standard sedan SQL Server 2016 | |
| Operativsystem | Windows Server 2019 eller senare | |
| Diskaggregering | Lagringsutrymmen om du vill | |
| Filsystem | NTFS | |
| Formatera blockstorlek | 64 KB | |
| # och typ av datadiskar | Premium Storage v1: 4+ x P40 (RAID0) Premium Storage v2: 4+ x 1 000 GiB – 4 000 GiB – plus 4 500 IOPS och 125 MB/s-dataflöde per disk eller motsvarande Premium SSD v2 |
Cache = Skrivskyddad för Premium Storage v1 |
| # och typ av loggdiskar | Premium storage v1: 1 x P30 Premium Storage v2: 1 x 500 GiB – plus 2 000 IOPS och 125 MB/sek dataflöde eller motsvarande Premium SSD v2 |
Cache = NONE |
| Maximal minnesparameter för SQL Server | 95 % av det fysiska RAM-minnet | Förutsatt att en enskild instans |
Den här konfigurationen är till exempel den virtuella databaskonfigurationen för en SAP Business Suite på SQL Server. Den här virtuella datorn är värd för 30 TB-databasen för den enda globala SAP Business Suite-instansen av ett globalt företag med över $ 200B årliga intäkter och över 200 000 heltidsanställda. Systemet kör all ekonomisk bearbetning, försäljning och distributionsbearbetning och många fler affärsprocesser från olika områden, inklusive Nordamerika löner. Systemet körs i Azure sedan början av 2018 med virtuella Datorer i Azure M-serien som virtuella databasdatorer. Som hög tillgänglighet använder systemet AlwaysOn med en synkron replik i en annan tillgänglighetszon i samma Azure-region. Och en annan asynkron replik i en annan Azure-region. NetWeaver-programlagret distribueras i de senaste D(a)/E(a) virtuella datorfamiljerna.
| Konfiguration | Virtuell databasdator | Kommentarer |
|---|---|---|
| VM-typ | M192dms_v2 (192 vCPU/4 196 GiB RAM) | |
| Accelererat nätverk | Aktiverat | |
| SQL Server-version | SQL Server 2019 | |
| Antal datafiler | 32 | |
| Antal loggfiler | 1 | |
| Antal temporära datafiler | 8 | |
| Operativsystem | Windows Server 2019 | |
| Diskaggregering | Lagringsutrymmen | |
| Filsystem | NTFS | |
| Formatera blockstorlek | 64 KB | |
| # och typ av datadiskar | Premium Storage v1: 16 x P40 eller motsvarande Premium SSD v2 | Cache = Skrivskyddad |
| # och typ av loggdiskar | Premium Storage v1: 1 x P60 eller motsvarande Premium SSD v2 | Använda skrivaccelerator |
| # och typ av tempdb-diskar | Premium Storage v1: 1 x P30 eller motsvarande Premium SSD v2 | Ingen cachelagring |
| Maximal minnesparameter för SQL Server | 95 % av det fysiska RAM-minnet |
Allmän SQL Server för SAP i Azure Sammanfattning
Det finns många rekommendationer i den här guiden och vi rekommenderar att du läser den mer än en gång innan du planerar din Azure-distribution. I allmänhet bör du dock följa de bästa SQL Server på Azure-specifika rekommendationer:
- Använd den senaste SQLServer-versionen, till exempel SQL Server 2022, som har flest fördelar i Azure.
- Planera noggrant SAP-systemlandskapet i Azure för att balansera datafillayouten och Azure-begränsningarna:
- Har inte för många diskar, men har tillräckligt för att säkerställa att du kan nå din nödvändiga IOPS.
- Du kan bara strecka över diskar om du behöver uppnå ett högre dataflöde.
- Har inte för många diskar, men har tillräckligt för att säkerställa att du kan nå din nödvändiga IOPS.
- Installera aldrig programvara eller placera filer som kräver beständighet på D:\-enheten eftersom den inte är beständig. Allt på den här enheten kan gå förlorat vid omstart av Windows eller omstart av virtuell dator.
- Använd din SQL Server AlwaysOn-lösning för att replikera databasdata.
- Använd alltid namnmatchning, förlita dig inte på IP-adresser.
- Använd de senaste SQL Server-korrigeringarna med hjälp av SQL Server TDE.
- Var försiktig med att använda SQL Server-avbildningar från Azure Marketplace. Om du använder SQL Server en måste du ändra instanssortering innan du installerar något SAP NetWeaver-system på den.
- Installera och konfigurera SAP-värdövervakning för Azure enligt beskrivningen i distributionsguiden.
Nästa steg
Läs artikeln