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 ett förhandsvillkor för det här dokumentet bör du ha läst dokumentet Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning och andra guider i dokumentationen för SAP-arbetsbelastningenpå Azure.

I allmänhet bör du överväga att använda de senaste versionerna SQL Server för att köra SAP-arbetsbelastning i Azure IaaS. De senaste SQL Server ger bättre integrering med några av Azure-tjänsterna och funktionerna. Eller ha ändringar som optimerar åtgärder i en Azure IaaS-infrastruktur.

Vi rekommenderar att du läser artikeln Vad är SQL Server på Azure Virtual Machines (Windows) innan du fortsätter.

I följande avsnitt sammanställs och nämns delar av dokumentationen under länken ovan. Information om SAP nämns också och vissa begrepp beskrivs i detalj. Vi rekommenderar dock starkt att du går igenom dokumentationen ovan först innan du läser SQL Server-specifik dokumentation.

Det finns vissa SQL Server IaaS-specifik information som du bör känna till innan du fortsätter:

• SQL versionsstöd: För SAP-kunder stöds SQL Server 2008 R2 och senare på Microsoft Azure Virtual Machine. Tidigare versioner stöds inte. Mer information finns i den här allmänna supportöversikten. I allmänhet stöds SQL Server 2008 även av Microsoft. Men på grund av betydande funktioner för SAP, som introducerades med SQL Server 2008 R2, är SQL Server 2008 R2 den lägsta versionen för SAP. I allmänhet bör du överväga att använda de senaste versionerna SQL Server för att köra SAP-arbetsbelastning i Azure IaaS. De senaste SQL Server ger bättre integrering med några av Azure-tjänsterna och funktionerna. Eller ha ändringar som optimerar åtgärder i en Azure IaaS-infrastruktur. Därför är dokumentet begränsat till SQL Server 2016 och SQL Server 2017.
• SQL prestanda: Microsoft Azure värd Virtual Machines fungerar bra jämfört med andra erbjudanden för virtualisering i offentliga moln, men enskilda resultat kan variera. Läs artikeln Metodtips för prestanda för SQL Server Azure Virtual Machines.
• Använda avbildningar Azure Marketplace: Det snabbaste sättet att distribuera en Microsoft Azure virtuell dator är att använda en avbildning från Azure Marketplace. Det finns avbildningar i Azure Marketplace, som innehåller de SQL Server versionerna. Avbildningarna där SQL Server redan är installerade kan inte användas omedelbart för SAP NetWeaver-program. Orsaken är standardinställningen för SQL Server är installerad i dessa avbildningar och inte den sortering som krävs av SAP NetWeaver-system. Om du vill använda sådana bilder kan du läsa stegen som beskrivs i kapitlet Använda en SQL Server-bild från Microsoft Azure Marketplace.
• SQL Server stöd för flera instanser i en enda virtuell Azure-dator: Den här distributionsmetoden stöds. Tänk dock på resursbegränsningar, särskilt när det gäller 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 förhindra att du implementerar samma arkitektur för flera instanser som du kan implementera lokalt. Från och med konfigurationen och interferensen med att dela de resurser som är tillgängliga i en enda virtuell dator måste samma överväganden som lokalt beaktas.
• Flera SAP-databaser i SQL Server instans på en enda virtuell dator: Som ovan stöds konfigurationer som dessa. Överväganden för flera SAP-databaser som delar delade resurser för SQL Server instans är samma som för lokala distributioner. Ytterligare ha andra gränser, till exempel antalet diskar som kan kopplas till en viss typ av virtuell dator i åtanke. Eller kvotgränser för nätverk och lagring för specifika typer av virtuella datorer som detaljerade storlekar för virtuella datorer i Azure.

Rekommendationer på VM-/VHD-struktur för SAP-relaterade SQL Server distributioner

I enlighet med den allmänna beskrivningen operativsystem, SQL Server körbara filer och för SAP 2-nivåsystem ska de körbara SAP-filer finnas eller installeras separata Azure-diskar. De flesta av de SQL Server systemdatabaserna används vanligtvis inte på hög nivå av SAP NetWeaver-arbetsbelastningen. Systemdatabaserna för SQL Server (master, msdb och modell) bör dock vara tillsammans med de andra SQL Server kataloger på en separat Azure-disk. SQL Server tempdb ska antingen finnas på den icke-erfarna D:\ eller på en separat disk.

• Med alla SAP-certifierade VM-typer (se SAP Note 1928533), kan förutom virtuella datorer i A-serien, tempdb-data och loggfiler placeras på den icke-beständiga D:\ Bilresa.
• För äldre SQL Server versioner, där SQL Server installerar tempdb med en datafil som standard, rekommenderar vi att du använder flera tempdb-datafiler. Var medveten om D:\ enhetsvolymer skiljer sig beroende på typen av virtuell dator. För exakta storlekar på D:\ på de olika virtuella datorerna läser du artikeln Storlekar för virtuella Windows i Azure.

Dessa konfigurationer gör att tempdb kan förbruka mer utrymme och viktigare IOPS och lagringsbandbredd än vad systemenheten kan tillhandahålla. The nonpersistent D:\ -enheten erbjuder också bättre I/O-svarstid och dataflöde (med undantag för virtuella datorer i A-serien). För att fastställa rätt tempdb-storlek kan du kontrollera tempdb-storlekarna på befintliga system.

En VM-konfiguration som kör SQL Server med en SAP-databas och där tempdb-data och tempdb-loggfil placeras på D:\ -enheten skulle se ut så här:

Diagrammet ovan visar ett enkelt fall. Mer information finns i artikeln Överväganden för Azure Virtual Machines DBMS-distributionför SAP-arbetsbelastning, Azure-lagringstyp, antal och storlek på diskar beror på olika faktorer. Men i allmänhet rekommenderar vi:

• Använda en stor volym som innehåller SQL Server datafiler. Orsaken till den här konfigurationen är att det i verkligheten finns flera SAP-databaser med databasfiler av olika storlek med olika I/O-arbetsbelastning.
• Använd D:-enheten för tempdb så länge prestandan är tillräckligt bra. Om den övergripande arbetsbelastningen är begränsad i prestanda genom att tempdb finns på D:\ -enhet som du kan behöva överväga att flytta tempdb för att separera Azure Premium Storage- eller Ultra-diskdiskar enligt rekommendationer i den här artikeln.

Special för virtuella datorer i M-serien

För virtuella Datorer i Azure M-serien kan svarstiden som skrivs till transaktionsloggen minskas av faktorer, jämfört med Azure Premium Storage prestanda, när du använder Azure Skrivningsaccelerator. Därför bör du distribuera Azure Skrivningsaccelerator för de virtuella hårddiskar som utgör volymen för SQL Server transaktionsloggen. Information kan läsas i dokumentet Skrivningsaccelerator.

Formatera diskarna

Till SQL Server NTFS-blockstorleken för diskar som innehåller SQL Server och loggfiler vara 64 kB. Du behöver inte formatera D:\ Bilresa. Den här enheten är förformaterad.

För att säkerställa att återställningen eller skapandet av databaser inte initierar datafilerna genom att nollställa innehållet i filerna bör du se till att användarkontexten som SQL Server-tjänsten körs i har en viss behörighet. Vanligtvis har användare i Windows administratörsgruppen dessa behörigheter. Om SQL Server-tjänsten körs i användarkontexten för en icke-Windows-administratörsanvändare måste du tilldela användaren användarbehörigheten Utför volymunderhållsåtgärder. Se informationen i den här Microsoft Knowledge Base artikeln: https://support.microsoft.com/kb/2574695

Effekt av databaskomprimering

I konfigurationer där I/O-bandbredd kan bli en begränsningsfaktor kan varje mått, som minskar IOPS, hjälpa till att stretcha arbetsbelastningen som man kan köra i ett IaaS-scenario som Azure. Om du inte har gjort det än rekommenderar både SAP SQL Server och Microsoft att du tillämpar komprimering på sidan innan du laddar upp en befintlig SAP-databas till Azure.

Rekommendationen att utföra databaskomprimering innan du överför till Azure ges av två skäl:

• Mängden data som ska laddas upp är lägre.
• Varaktigheten för komprimeringskörningen är kortare förutsatt att man kan använda starkare maskinvara med fler processorer eller högre I/O-bandbredd eller mindre I/O-svarstid lokalt.
• Mindre databasstorlekar kan leda till lägre kostnader för diskallokering

Databaskomprimering fungerar också i en Azure Virtual Machines som den gör lokalt. Mer information om hur du komprimerar befintliga SAP NetWeaver SQL Server databaser finns i artikeln Förbättrat SAP-komprimeringsverktyg MSSCOMPRESS.

SQL Server 2014 och senare – Lagra databasfiler direkt på Azure Blob Storage

SQL Server 2014 och senare versioner kan du lagra databasfiler direkt i Azure Blob Store utan "omslutning" av en virtuell hårddisk runt dem. I synnerhet med standard-Azure Storage eller mindre VM-typer möjliggör den här typen av distribution scenarier där du kan lösa gränserna för IOPS som skulle tillämpas av ett begränsat antal diskar som kan monteras på vissa mindre VM-typer. Det här distributions sättet fungerar för användardatabaser, men inte för systemdatabaser i SQL Server. Det fungerar även för data och loggfiler för SQL Server. Om du vill distribuera en SAP SQL Server-databas på det här sättet i stället för att "omsluta" den till virtuella hårddiskar bör du tänka på följande:

• Det Storage konto som används måste finnas i samma Azure-region som det som används för att distribuera den virtuella SQL Server körs i.
• Överväganden som anges tidigare angående distributionen av virtuella hårddiskar över Azure Storage-konton gäller även för den här distributionsmetoden. Innebär att I/O-åtgärder räknas mot gränserna för Azure Storage konto.
• I stället för att redovisa mot den virtuella datorns lagrings-I/O-kvot kommer trafiken mot lagringsblobar som representerar SQL Server-data och loggfiler att redovisas i den virtuella datorns nätverksbandbredd för den specifika VM-typen. Information om nätverks- och lagringsbandbredd för en viss typ av virtuell dator finns i artikeln Storlekar Windows virtuella datorer i Azure.
• Genom att push-pusha fil-I/O via nätverkskvoten delar du huvudsakligen lagringskvoten och använder den totala bandbredden för den virtuella datorn endast delvis.
• IOPS- och I/O-dataflödesprestandamålen som Azure Premium Storage har för de olika diskstorlekarna gäller inte längre. Även om blobarna som du skapade finns i Azure Premium Storage. Målen dokumenteras i artikeln High-performance Premium Storage and managed disks for VMs( Högpresterande prestanda och hanterade diskar för virtuella datorer). När du placerar SQL Server-datafiler och loggfiler direkt på blobar som lagras i Azure Premium Storage kan prestandaegenskaperna vara annorlunda jämfört med virtuella hårddiskar på Azure Premium Storage.
• Värdbaserad cachelagring som är tillgänglig för Azure Premium Storage diskar är inte tillgänglig när du placerar SQL Server-datafiler direkt på Azure-blobar.
• På virtuella datorer i M-serien kan Azure Skrivningsaccelerator inte användas för att stödja skrivningar på en millisekund mot den virtuella SQL Server-transaktionsloggfilen.

Information om den här funktionen finns i artikeln SQL Server datafiler i Microsoft Azure

Rekommendationen för produktionssystem är att undvika den här konfigurationen och i stället välja placering av SQL Server-data och loggfiler på virtuella Azure Premium Storage-hårddiskar i stället för direkt på Azure-blobar.

SQL Server 2014-buffertpooltillägg

SQL Server 2014 introducerade en ny funktion som kallas buffertpooltillägg. Den här funktionen utökar buffertpoolen för SQL Server, som lagras i minnet med en cache på andra nivån som backas upp av lokala SSD:er för en server eller virtuell dator. Buffertpooltillägget gör det möjligt att behålla en större arbetsuppsättning data "i minnet". Jämfört med att komma åt Azure Standard Storage åtkomst till tillägget av buffertpoolen, som lagras på lokala SSD:er för en virtuell Azure-dator, är många faktorer snabbare. Om du jämför buffertpooltillägget med Azure Premium Storage Read Cache, vilket rekommenderas för SQL Server-datafiler, förväntas inga betydande fördelar för buffertpooltillägg. Anledningen är att både cacheminnen (SQL Server buffer pool extension och Premium Storage Read Cache) använder de lokala diskarna i Azure-beräkningsnoden.

Erfarenheter från tiden med SQL Server buffertpooltillägg med SAP-arbetsbelastning är blandade och tillåter fortfarande inte tydliga rekommendationer om huruvida du ska använda det i samtliga fall. Det bästa är att arbetsminnet som SAP-programmet kräver passar i huvudminnet. Med Azure som erbjuder virtuella datorer med upp till 4 TB minne bör det vara möjligt att behålla arbetsminnet. Användningen av buffertpooltillägget är därför begränsad till vissa sällsynta fall och bör inte vara ett vanligt fall.

Överväganden för säkerhetskopiering/återställning för SQL Server

När du SQL Server till Azure måste du granska säkerhetskopieringsmetoden. Även om systemet inte är ett produktionssystem måste SAP-databasen som SQL Server säkerhetskopieras regelbundet. Eftersom Azure Storage behåller tre avbildningar är en säkerhetskopia nu mindre viktig när det gäller att kompensera för en lagringskrasch. Prioritetsorsaken för att upprätthålla en korrekt säkerhetskopierings- och återställningsplan är mer att du kan kompensera för logiska/manuella fel genom att ange funktioner för återställning till tidpunkt. Målet är därför att antingen använda säkerhetskopior för att återställa databasen till en viss tidpunkt eller att använda säkerhetskopiorna i Azure för att seeda ett annat system genom att kopiera den befintliga databasen.

Om du vill titta på SQL Server olika säkerhetskopieringsmöjligheter i Azure kan du läsa artikeln Säkerhetskopiering och återställning för SQL Server i Azure Virtual Machines. Artikeln beskriver flera olika möjligheter.

Manuella säkerhetskopieringar

Det finns flera möjligheter att utföra "manuella" säkerhetskopieringar genom att:

1. Utföra konventionella SQL Server säkerhetskopieringar till direktkopplade Azure-diskar. Den här metoden har fördelen att du snabbt har säkerhetskopior tillgängliga för systemuppdateringar och för att bygga upp nya system som kopior av befintliga SAP-system
2. SQL Server 2012 CU4 och senare kan backa upp databaser till en Azure-lagrings-URL.
3. File-Snapshot säkerhetskopieringar för databasfiler i Azure Blob Storage. Den här metoden fungerar bara när SQL Server data och loggfiler finns i Azure Blob Storage

Den första metoden är välkänd och används i många fall även i den lokala världen. Du får dock uppgiften att lösa den långsiktiga säkerhetskopieringsplatsen. Eftersom du inte vill behålla dina säkerhetskopior i 30 eller fler dagar i den lokalt anslutna Azure Storage behöver du antingen använda Azure Backup Services eller något annat säkerhetskopierings-/återställningsverktyg från tredje part som innehåller åtkomst- och kvarhållningshantering för dina säkerhetskopior. Eller så skapar du en stor filserver i Azure med Windows lagringsutrymmen.

Den andra metoden beskrivs närmare i artikeln om SQL Server säkerhetskopiering till URL. Olika versioner av SQL Server har vissa varianter av den här funktionen. Därför bör du läsa dokumentationen för ditt specifika SQL Server versionskontroll. Observera att den här artikeln innehåller många begränsningar. Du kan antingen utföra säkerhetskopieringen mot:

• En enda Azure-sidblob, som sedan begränsar säkerhetskopieringsstorleken till 1 000 GB. Den här begränsningen begränsar också det dataflöde som du kan uppnå.
• Flera (upp till 64) Azure-blockblobar, som möjliggör en teoretisk säkerhetskopieringsstorlek på 12 TB. Tester med kunddatabaser visade dock att den maximala säkerhetskopieringsstorleken kan vara mindre än den teoretiska gränsen. I det här fallet ansvarar du för att hantera kvarhållning av säkerhetskopior och åtkomst till säkerhetskopiorna också.

Automatiserad säkerhetskopiering för SQL Server

Automatisk säkerhetskopiering tillhandahåller en automatisk säkerhetskopieringstjänst för SQL Server Standard- och Enterprise-utgåvor som körs på en Windows virtuell dator i Azure. Den här tjänsten tillhandahålls av SQL Server IaaS-agenttillägget, som installeras automatiskt på SQL Server Windows virtuella datoravbildningar i Azure Portal. Om du distribuerar dina egna operativsystemavbildningar SQL Server installeras måste du installera VM-tilläggen separat. De nödvändiga stegen dokumenteras i den här artikeln.

Mer information om funktionerna i den här metoden finns i följande artiklar:

• SQL Server 2014: Automatiserad säkerhetskopiering för SQL Server 2014 Virtual Machines (Resource Manager)
• SQL Server 2016/2017: Automatisk säkerhetskopiering v2 för Azure Virtual Machines (Resource Manager)

Om du tittar på dokumentationen kan du se att funktionerna med de SQL Server nya versionerna har förbättrats. Mer information om hur SQL Server säkerhetskopieringar publiceras i artikeln om SQL Server Managed Backup för att Microsoft Azure. Den teoretiska storleksgränsen för säkerhetskopiering är 12 TB. Automatiserade säkerhetskopieringar kan vara en bra metod för säkerhetskopieringsstorlekar på upp till 12 TB. Eftersom flera blobar skrivs till parallellt kan du förvänta dig ett dataflöde som är större än 100 MB/s.

Azure Backup för SQL Server virtuella datorer

Den här nya metoden SQL Server säkerhetskopieringar erbjuds från och med juni 2018 som offentlig förhandsversion av Azure Backup services. Metoden för att säkerhetskopiera SQL Server är samma som andra verktyg från tredje part som använder, nämligen SQL Server VSS/VDI-gränssnittet för att strömma säkerhetskopior till en målplats. I det här fallet är målplatsen Azure Recovery Service-valvet.

En mer detaljerad beskrivning av den här säkerhetskopieringsmetoden, som ger många fördelar med konfigurationer för central säkerhetskopiering, övervakning och administration finns på sidan Säkerhetskopiera SQL Server databaser till Azure.

Lösningar för säkerhetskopiering från tredje part

För ett stort antal SAP-kunder fanns det ingen möjlighet att börja om och introducera fullständiga nya säkerhetskopieringslösningar för den del av sap-miljön som kördes på Azure. Därför behövde de befintliga säkerhetskopieringslösningarna användas och utökas till Azure. Att utöka befintliga säkerhetskopieringslösningar till Azure fungerade vanligtvis bra med de flesta av huvudleverantörerna på det här området.

Använda en SQL Server-avbildning från Microsoft Azure Marketplace

Microsoft erbjuder virtuella datorer i 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 täcka behovet av licenser genom att skapa virtuella datorer med SQL Server redan installerat. Följande överväganden måste göras för att kunna använda sådana avbildningar för SAP:

• De SQL Server versioner som inte är utvärderingsversioner får högre kostnader än en "Windows"-vm som distribueras från Azure Marketplace. I de här artiklarna kan du jämföra priser: https://azure.microsoft.com/pricing/details/virtual-machines/windows/ och https://azure.microsoft.com/pricing/details/virtual-machines/sql-server-enterprise/ .
• Du kan bara använda SQL Server versioner som stöds av SAP.
• Sorteringen av SQL Server-instansen, som installeras på de virtuella datorer som erbjuds i Azure Marketplace är inte sorteringen som SAP NetWeaver kräver att SQL Server-instansen körs. Du kan ändra sorteringen med hjälp av anvisningarna i följande avsnitt.

Ändra sorteringen SQL Server microsoft-dator Windows/SQL Server dator

Eftersom SQL Server avbildningar i Azure Marketplace inte har ställts in för att använda sorteringen, vilket krävs av SAP NetWeaver-program, måste den ändras omedelbart efter distributionen. Den SQL Server sorteringsändringen kan till exempel utfö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örskonto 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 om steget resulterade i rätt resultat:

• Öppna SQL Server Management Studio.
• Öppna ett frågefönster.
• Kör kommandofilen sp_helpsort den SQL Server huvuddatabasen.

Det önskade resultatet 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 av SAP och undersöker varför installationskommandot inte fungerade som förväntat. Distribution av SAP NetWeaver-program till SQL Server-instans med SQL Server andra kodsidor än den som nämns ovan stöds INTE.

SQL Server High-Availability 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 DBMS-lagret med hög tillgänglig. Som vi redan har diskuterat i Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning tillhandahåller Azure olika serviceavtal för drifttid för en enskild virtuell dator och ett par virtuella datorer som distribueras i en Azure-tillgänglighetsuppsättning. Antagandet är att du arbetar mot serviceavtalet för drifttid för dina produktionsdistributioner som kräver distribution i Azure Availability Sets. I sådana fall måste du distribuera minst två virtuella datorer i en sådan tillgänglighetsuppsättning. En virtuell dator kör den aktiva SQL Server instansen. Den andra virtuella datorn kör den passiva instansen

SQL Server Klustring med Windows uppskalningsfilserver eller delad Azure-disk

Med Windows Server 2016 introducerade Microsoft Lagringsutrymmen Direct. Baserat på Lagringsutrymmen Direct Deployment stöds SQL Server FCI-klustring i allmänhet. Azure erbjuder även delade Azure-diskar som kan användas för Windows kluster. För SAP-arbetsbelastningar stöder vi inte dessa ha-alternativ.

SQL Server Loggleverans

En av metoderna för hög tillgänglighet (HA) är SQL Server loggleverans. Om de virtuella datorer som deltar i HA-konfigurationen har fungerande namnmatchning är det inga problem. Konfigurationen i Azure skiljer sig inte från någon konfiguration som görs lokalt relaterat till att konfigurera loggleverans och principerna kring loggleverans. Information om SQL Server loggleverans finns i artikeln Om loggleverans (SQL Server).

Funktionen SQL Server loggleverans användes nästan inte i Azure för att uppnå hög tillgänglighet inom en Azure-region. Men i följande scenarier använde SAP-kunder loggleverans med Azure:

• Haveriberedskapsscenarier från en Azure-region till en annan Azure-region
• Haveriberedskapskonfiguration från lokal plats till en Azure-region
• Cut-over-scenarier från lokal plats till Azure. I dessa fall används loggleverans för att synkronisera den nya DBMS-distributionen 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 DBMS-distributionen. Sedan öppnas Azure DBMS-distributionen för produktion.

Databasspegling

Databasspegling som stöds av SAP (se SAP Note 965908) förlitar sig på att definiera en redundanspartner i SAP-anslutningssträngen. I de olika lokala fallen förutsätter vi att de två virtuella datorerna finns i samma domän och att användarkontexten för de två SQL Server-instanserna körs under en domänanvändare och har tillräcklig behörighet i de två SQL Server instanserna. Därför skiljer sig inte konfigurationen av databasspegling i Azure mellan en typisk lokal installation/konfiguration.

Från och Cloud-Only distributioner är den enklaste metoden att ha en annan domänkonfiguration i Azure för att ha dessa virtuella DBMS-datorer (och helst dedikerade virtuella SAP-datorer) inom en domän.

Om en domän inte är möjlig kan du också använda certifikat för slutpunkterna för databasspegling enligt beskrivningen här: Använda certifikat för en databasspeglingsslutpunkt (Transact-SQL)

En självstudie om att konfigurera databasspegling i Azure finns här: Databasspegling (SQL Server)

Ständig aktivering av SQL Server

Eftersom 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 du distribuerar SQL Server-tillgänglighetsgruppens lyssnare (ska inte förväxlas med Azure-tillgänglighetsuppsättningen) eftersom Azure för stunden inte tillåter att ett AD/DNS-objekt skapas eftersom det är möjligt lokalt. Därför är vissa olika installationssteg nödvändiga för att lösa det specifika beteendet i Azure.

Några saker att tänka på när du använder en lyssnare för tillgänglighetsgrupp är:

• Du kan bara använda en lyssnare för tillgänglighetsgrupp med Windows Server 2012 eller högre som gästoperativsystem för den virtuella datorn. För Windows Server 2012 måste du se till att korrigeringen tillämpas:https://support.microsoft.com/kb/2854082
• För Windows Server 2008 R2 finns inte den här korrigeringen och Always On måste användas på samma sätt som databasspegling genom att ange en redundanspartner i anslutningssträngen (görs via parametern SAP default.pfl dbs/mss/server – se [SAP-anteckningen 965908]).
• När du använder en lyssnare för en tillgänglighetsgrupp måste de virtuella databas datorerna anslutas till en dedikerad Load Balancer. För att undvika att Azure tilldelar nya IP-adresser i fall där båda virtuella datorerna tillfälligt stängs av, bör du tilldela statiska IP-adresser till nätverksgränssnitten för de virtuella datorerna i Always On-konfigurationen (definiera en statisk IP-adress beskrivs i den här artikeln)
• Det krävs särskilda åtgärder när du skapar WSFC-klusterkonfigurationen där klustret behöver en särskild TILLDELAd IP-adress, eftersom Azure med dess aktuella funktioner tilldelar klustret 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 en annan IP-adress till klustret.
• 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 av 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 i virtuella Azure-datorer:

• Introduktion SQL Server Always On-tillgänglighetsgrupper på virtuella Azure-datorer.
• Konfigurera en Always On-tillgänglighetsgrupp på virtuella Azure-datorer i olika regioner.
• Konfigurera en lastbalanserare för en Always On-tillgänglighetsgrupp i Azure.

SQL Server Always On är den vanligaste funktionen för hög tillgänglighet och haveriberedskap som används i Azure för SAP-arbetsbelastningsdistributioner. De flesta kunder använder Always On för hög tillgänglighet inom en enda Azure-region. Om distributionen är begränsad till endast två noder har du två alternativ för anslutning:

• Använda lyssnaren för tillgänglighetsgrupp. Med tillgänglighetsgruppens lyssnare måste du distribuera en Azure-lastbalanserare.
• Med SQL Server version 2019 CU8 eller senare versioner där du kan använda DNN-lyssnaren (Direct Network Name) i stället. Detta eliminerar kravet på en Azure-lastbalanserare.
• Använda anslutningsparametrarna för SQL Server databasspegling. 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 SAP-konfiguration finns dokumenterad i SAP Note #965908. Med det här alternativet behöver du inte konfigurera en tillgänglighetsgruppslyssnare. Och utan Azure-lastbalanserare för SQL Server hög tillgänglighet. Kom dock ihåg att det här alternativet bara fungerar om du begränsar tillgänglighetsgruppen så att den omfattar två instanser.

Ett stort antal kunder använder funktionen SQL Server Always On för haveriberedskap mellan Azure-regioner. Flera kunder använder också möjligheten att utföra säkerhetskopieringar från en sekundär replik.

SQL Server transparent datakryptering

Det finns många kunder som använder SQL Server transparent datakryptering (TDE) när de distribuerar sina SAP SQL Server databaser i Azure. Den SQL Server TDE-funktionen stöds fullt ut av SAP (se SAP Note #1380493).

Tillämpa SQL Server TDE

I de fall där du utför en heterogen migrering från en annan DBMS 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 skulle du tillämpa SQL Server TDE-funktioner. Medan du fortfarande kör produktionssystemet lokalt. Anledningen till att du vill utföra i den här sekvensen är att processen för att kryptera den tomma databasen kan ta en stund. SAP-importprocesserna skulle sedan importera data till den krypterade databasen under driftstoppsfasen. Omkostnaderna för att importera till en krypterad databas har en mycket lägre tidspåverkan än kryptering av databasen efter exportfasen i nedtidsfasen. Negativa upplevelser gjordes när du försökte tillämpa TDE med SAP-arbetsbelastningen som körs ovanpå databasen. Därför behandlar rekommendationen distributionen av TDE som en aktivitet som måste utföras utan SAP-arbetsbelastning på den specifika databasen.

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 använda för att få krypteringen att tillämpas snabbast. För detta bör du ha dessa 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 i hög grad beroende av antalet diskvolymer som SQL Server och loggfiler distribueras över. Innebär att ju fler distinkta volymer (enhetsbeteckningar) desto fler trådar används parallellt för att utföra krypteringen. En sådan konfiguration strider mot lite med ett tidigare förslag om diskkonfiguration om att skapa ett eller ett mindre antal lagringsutrymmen för SQL Server-databasfiler på virtuella Azure-datorer. En konfiguration med ett litet antal volymer skulle leda till ett litet antal trådar som kör krypteringen. En enda trådkryptering läser 64 KB-omfattningar, krypterar den och skriver sedan en post i transaktionsloggfilen, vilket talar om att omfattningen har krypterats. Därför är belastningen på transaktionsloggen måttlig.
• I äldre versioner SQL Server komprimering av säkerhetskopior inte längre effektivitet när du krypterade din SQL Server databasen. Det här beteendet kan utvecklas till ett problem när din plan var att kryptera din SQL Server-databas lokalt och sedan kopiera en säkerhetskopia till Azure för att återställa databasen i Azure. SQL Server säkerhetskopieringskomprimering uppnår vanligtvis komprimeringsförhållandet faktor 4.
• Med SQL Server 2016 SQL Server nya funktioner som gör det möjligt att komprimera krypterade databaser på ett effektivt sätt. Mer information finns på den här bloggen.

Om du behandlar tillämpningen av TDE-kryptering utan endast lite SAP-arbetsbelastning bör du testa i din specifika konfiguration om det är bättre att använda TDE på din SAP-databas lokalt eller att göra det i Azure. I Azure har du verkligen mer flexibilitet när det gäller överetablering av infrastruktur och krymper infrastrukturen när TDE har tillämpats.

Använda Azure Key Vault

Azure erbjuder en tjänst för en Key Vault att lagra krypteringsnycklar. SQL Server på den andra sidan en anslutningsapp för att använda Azure Key Vault som lagring för TDE-certifikaten.

Mer information om hur du använder Azure Key Vault för SQL Server TDE-listor som:

• Utökningsbar nyckelhantering med Azure Key Vault (SQL Server).
• SQL Server TDE Extensible Key Management Using Azure Key Vault - Setup Steps.
• SQL Server för & felsökning.
• Fler frågor från kunder om SQL Server transparent datakryptering – TDE + Azure Key Vault.

Allmän SQL Server för SAP på 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 viktigaste allmänna DBMS på Azure-specifika rekommendationer:

1. Använd den senaste DBMS-versionen, SQL Server 2017, som har de största fördelarna i Azure.
2. Planera noggrant ditt SAP-systemlandskap i Azure för att balansera datafilslayouten och Azure-begränsningarna:
   • Ha inte för många diskar, men tillräckligt för att säkerställa att du kan nå din IOPS som krävs.
   • Om du inte använder Managed Disks bör du komma ihåg att IOPS också är begränsat per Azure Storage-konto och att Storage-konton är begränsade i varje Azure-prenumeration(mer information).
   • Strimlar bara över diskar om du behöver uppnå ett högre dataflöde.
3. Installera aldrig programvara eller placera filer som kräver beständighet på D:\ eftersom den inte är permanent och allt på den här enheten försvinner vid en Windows omstart.
4. Använd inte diskcachelagring för Azure Standard Storage.
5. Använd inte geo-replikerade Azure Standard-Storage-konton. Använd Lokalt redundant för DBMS-arbetsbelastningar.
6. Använd DBMS-leverantörens HA/DR-lösning för att replikera databasdata.
7. Använd alltid Namnmatchning, förlita dig inte på IP-adresser.
8. Använd SQL Server TDE och tillämpa de senaste SQL Server korrigeringarna.
9. Använd högsta möjliga databaskomprimering. Vilket är sidkomprimering för SQL Server.
10. Var försiktig med SQL Server använda bilder från Azure Marketplace. Om du använder SQL Server måste du ändra instansens sortering innan du installerar SAP NetWeaver-system på den.
11. Installera och konfigurera SAP-värdövervakning för Azure enligt beskrivningen i distributionsguiden.

Nästa steg

Läs artikeln

• Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning