Dela via

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

  • Artikel

Den här guiden är en del av dokumentationen om hur du implementerar och distribuerar SAP-programvara i Microsoft Azure. Innan du läser den här guiden kan du läsa planerings - och implementeringsguiden och artiklarna i planeringsguiden. Det här dokumentet beskriver de allmänna distributionsaspekterna av SAP-relaterade DBMS-system på virtuella Microsoft Azure-datorer (VM) med hjälp av IaaS-funktionerna (Infrastruktur som en tjänst).

Dokumentet kompletterar SAP-installationsdokumentationen och SAP Notes, som representerar de primära resurserna för installationer och distributioner av SAP-programvara på angivna plattformar.

I det här dokumentet introduceras överväganden för att köra SAP-relaterade DBMS-system på virtuella Azure-datorer. Det finns få referenser till specifika DBMS-system i det här dokumentet. I stället hanteras de specifika DBMS-systemen i andra databassystemspecifika dokument.

Resurser

Det finns andra artiklar tillgängliga om SAP-arbetsbelastningar i Azure. Börja med SAP-arbetsbelastningen i Azure: Kom igång och välj sedan ditt intresseområde.

Följande SAP-anteckningar är relaterade till SAP på Azure när det gäller det område som beskrivs i det här dokumentet.

Anteckningsnummer Title
1928533 SAP-program i Azure: Produkter som stöds och typer av virtuella Azure-datorer
2015553 SAP på Microsoft Azure: Supportkrav
1999351 Felsöka förbättrad Azure-övervakning för SAP
2178632 Viktiga övervakningsmått för SAP på Microsoft Azure
1409604 Virtualisering i Windows: Förbättrad övervakning
2191498 SAP på Linux med Azure: Förbättrad övervakning
2039619 SAP-program på Microsoft Azure med hjälp av Oracle-databasen: Produkter och versioner som stöds
2233094 DB6: SAP-program i Azure med IBM DB2 för Linux, UNIX och Windows: Ytterligare information
2243692 Linux på en virtuell IaaS-dator (Microsoft Azure): SAP-licensproblem
2578899 SUSE Linux Enterprise Server 15: Installationsanteckning
1984787 SUSE LINUX Enterprise Server 12: Installationsanteckningar
2772999 Red Hat Enterprise Linux 8.x: Installation och konfiguration
2002167 Red Hat Enterprise Linux 7.x: Installation och uppgradering
2069760 Installation och uppgradering av Oracle Linux 7.x SAP
1597355 Växlingsutrymmesrekommendering för Linux
2799900 Central Technical Note för Oracle Database 19c
2171857 Oracle Database 12c: Stöd för filsystem i Linux
1114181 Oracle Database 11g: Stöd för filsystem i Linux
2969063 Mikrokodsverifieringen misslyckades i HCMT på Azure
3246210 Azure – HCMT misslyckas under vissa diskprestandatester

Information om alla SAP-anteckningar för Linux finns i SAP-communityns wiki.

Du behöver en fungerande kunskap om Microsoft Azure-arkitektur och hur virtuella Microsoft Azure-datorer distribueras och drivs. Mer information finns i Azure-dokumentationen.

I allmänhet är installation och konfiguration av Windows, Linux och DBMS i stort sett desamma som alla virtuella datorer eller datorer utan operativsystem som du installerar lokalt. Det finns vissa beslut om arkitektur- och systemhanteringsimplementering som skiljer sig när du använder Azure IaaS. Det här dokumentet beskriver de specifika skillnader i arkitektur- och systemhantering som ska förberedas för när du använder Azure IaaS.

Lagringsstruktur för en virtuell dator för RDBMS-distributioner

Om du vill följa det här kapitlet läser du och förstår informationen som presenteras i:

För Azure-blocklagring är användningen av Azure-hanterade diskar obligatorisk. Mer information om Hanterade Azure-diskar finns i artikeln Introduktion till hanterade diskar för virtuella Azure-datorer.

I en grundläggande konfiguration rekommenderar vi vanligtvis en distributionsstruktur där operativsystemet, DBMS och eventuella SAP-binärfiler är åtskilda från databasfilerna. Vi rekommenderar att du har separata Azure-diskar för:

  • Operativsystemet (bas-VHD eller OS VHD)
  • Körbara databashanteringssystem
  • SAP-körbara filer som /usr/sap
  • DBMS-datafiler
  • DBMS gör om loggfiler

En konfiguration som separerar dessa komponenter i fem olika volymer kan leda till högre återhämtning eftersom överdriven användning på en volym inte nödvändigtvis stör användningen av andra volymer så länge vm-lagringskvoten och gränserna inte överskrids.

DBMS-data- och transaktions-/omloggfilerna lagras i Azure Support ed blocklagring eller Azure NetApp Files. Azure Files eller Azure Premium Files stöds inte som lagring för DBSM-data och/eller gör om loggfiler med SAP-arbetsbelastning. De lagras på separata diskar och ansluts som logiska diskar till den ursprungliga virtuella Azure-operativsystemavbildningsdatorn. För Linux-distributioner dokumenteras olika rekommendationer. Läs artikeln azure storage types for SAP workload for the capabilities and the support of the different storage types for your scenario (Azure Storage types for SAP workload for the capabilities and the support of the different storage types for your scenario). Specifikt för SAP HANA börjar du med artikeln sap hana azure virtual machine storage configurations.

När du planerar disklayouten hittar du den bästa balansen mellan dessa objekt:

  • Antalet datafiler.
  • Antalet diskar som innehåller filerna.
  • IOPS-kvoterna för en enskild disk eller NFS-resurs.
  • Dataflödet per disk eller NFS-resurs.
  • Antalet ytterligare datadiskar som är möjliga per VM-storlek.
  • Det övergripande dataflödet för lagring eller nätverk som en virtuell dator kan tillhandahålla.
  • Svarstiden som olika Azure Storage-typer kan ge.
  • Vm Storage IOPS och dataflödeskvot.
  • Vm-nätverkskvot om du använder NFS – trafik till NFS-resurser räknas mot den virtuella datorns nätverkskvot och INTE lagringskvoten.
  • Serviceavtal för virtuella datorer.

Azure tillämpar en IOPS-kvot per datadisk eller NFS-resurs. Dessa kvoter skiljer sig åt för diskar som finns på de olika Azure-blocklagringslösningarna eller -resurserna. I/O-svarstiden skiljer sig också mellan dessa olika lagringstyper.

Var och en av de olika typerna av virtuella datorer har ett begränsat antal datadiskar som du kan ansluta. En annan begränsning är att endast vissa typer av virtuella datorer kan använda, till exempel premiumlagring. Vanligtvis bestämmer du dig för att använda en viss typ av virtuell dator baserat på processor- och minneskraven. Du måste också tänka på kraven för IOPS, svarstid och diskgenomflöde som vanligtvis skalas med antalet diskar eller typen av premiumlagringsdiskar v1. Antalet IOPS och det dataflöde som ska uppnås av varje disk kan diktera diskstorleken, särskilt med Premium Storage v1. Med Premium Storage v2 eller Ultra Disk kan du välja etablerad IOPS och dataflöde oberoende av diskkapaciteten.

Kommentar

För DBMS-distributioner rekommenderar vi starkt Azure Premium Storage (v1 och v2), Ultra-disk eller Azure NetApp Files-baserade NFS-resurser för alla data, transaktionsloggar eller omgjorda filer. Det spelar ingen roll om du vill distribuera produktions- eller icke-produktionssystem. Svarstiden för Standard HDD eller SSD i Azure är inte acceptabel för någon typ av produktionssystem.

Kommentar

För att maximera Azures SLA för enskilda virtuella datorer måste alla diskar som är anslutna vara Azure Premium Storage (v1 eller v2) eller Azure Ultra-disktypen, som innehåller den virtuella basdisken (Azure Premium Storage).

Kommentar

Värd för huvuddatabasfiler, till exempel data och loggfiler, för SAP-databaser på lagringsmaskinvara som finns i samlokala datacenter från tredje part intill Azure-datacenter stöds inte. Lagring som tillhandahålls via programvaruinstallationer som finns på virtuella Azure-datorer stöds inte heller för det här användningsfallet. För SAP DBMS-arbetsbelastningar stöds endast lagring som representeras som intern Azure-tjänst för data- och transaktionsloggfiler för SAP-databaser i allmänhet. Olika DBMS kan ha stöd för olika Azure-lagringstyper. Mer information finns i artikeln Azure Storage-typer för SAP-arbetsbelastning

Placeringen av databasfilerna, loggen och omfilerna samt vilken typ av Azure Storage du använder definieras av kraven på IOPS, svarstid och dataflöde. Specifikt för Azure Premium Storage v1 kan du, för att uppnå tillräckligt med IOPS, tvingas använda flera diskar eller använda en större premiumlagringsdisk. Om du använder flera diskar skapar du en programvaruremsa över diskarna som innehåller datafilerna eller loggen och gör om filerna. I sådana fall är serviceavtalen för IOPS och diskdataflödet för de underliggande premiumlagringsdiskarna eller den högsta möjliga IOPS för standardlagringsdiskar ackumulativa för den resulterande stripe-uppsättningen.

Om ditt IOPS-krav överskrider vad en enda virtuell hårddisk kan tillhandahålla, balanserar du den IOPS som behövs för databasfilerna över ett antal virtuella hårddiskar. Det enklaste sättet att distribuera IOPS-belastningen mellan diskar är att skapa en programvaruremsa över de olika diskarna. Placera sedan ett antal datafiler i SAP DBMS på LUN:erna som är utskurna ur programvaruremsan. Antalet diskar i randen drivs av IOPS-krav, krav på diskgenomflöde och volymkrav.

Windows Storage Striping Windows

Vi rekommenderar att du använder Windows Lagringsutrymmen för att skapa stripe-uppsättningar över flera virtuella Azure-hårddiskar. Använd minst Windows Server 2012 R2 eller Windows Server 2016.

Linux-lagringslistning Linux

Endast MDADM och Logical Volume Manager (LVM) stöds för att skapa en programvaru-RAID på Linux. Mer information finns i:

För Azure Premium Storage v2 och Ultra Disk kanske striping inte behövs eftersom du kan definiera IOPS och diskdataflöde oberoende av diskens storlek.

Kommentar

Eftersom Azure Storage behåller tre avbildningar av de virtuella hårddiskarna är det inte meningsfullt att konfigurera en redundans när du streckar. Du behöver bara konfigurera striping så att I/Os distribueras över de olika virtuella hårddiskarna.

Hanterade eller icke-hanterade diskar

Ett Azure Storage-konto är en administrativ konstruktion och även ett ämne med begränsningar. Information om funktioner och begränsningar finns i Skalbarhets- och prestandamål för Azure Storage. För standardlagring bör du komma ihåg att det finns en gräns för IOPS per lagringskonto. Se raden som innehåller total begärandefrekvens i artikeln skalbarhets- och prestandamål för Azure Storage. Det finns också en inledande gräns för antalet lagringskonton per Azure-prenumeration. Från och med 2017 introducerade Azure begreppen Azure Managed Disks som hjälper dig att ta hand om all administration av lagringskonton. Att använda Azure-hanterade diskar är standard för distribution för SAP-arbetsbelastning i Azure.

Viktigt!

Med tanke på fördelarna med Azure Managed Disks är det obligatoriskt att du använder Azure Managed Disks för dina DBMS-distributioner och SAP-distributioner i allmänhet.

Om du råkar ha EN SAP-arbetsbelastning som ännu inte använder hanterade diskar kan du gå till:

Cachelagring för virtuella datorer och datadiskar

När du monterar diskar på virtuella datorer kan du välja om I/O-trafiken mellan den virtuella datorn och de diskar som finns i Azure Storage cachelagras.

Följande rekommendationer förutsätter dessa I/O-egenskaper för standard-DBMS:

  • Det är mest en läsarbetsbelastning mot datafiler i en databas. Dessa läsningar är prestandakritiska för DBMS-systemet.
  • Skrivning mot datafiler sker i bursts baserat på kontrollpunkter eller en konstant ström. I genomsnitt över en dag finns det färre skrivningar än läsningar. I motsats till läsningar från datafiler är skrivningarna asynkrona och innehåller inga användartransaktioner.
  • Det finns knappast några läsningar från transaktionsloggen eller gör om filer. Undantag är stora I/Os när du utför säkerhetskopior av transaktionsloggar.
  • Den huvudsakliga belastningen mot transaktions- eller omloggfiler är skrivningar. Beroende på vilken typ av arbetsbelastning du har kan du ha I/Os så litet som 4 KB eller, i andra fall, I/O-storlekar på 1 MB eller mer.
  • Alla skrivningar måste bevaras på disken på ett tillförlitligt sätt.

För Azure Premium Storage v1 finns följande cachelagringsalternativ:

  • Ingen
  • Lästa
  • Skrivskydd
  • None + Write Accelerator, som endast är för virtuella Datorer i Azure M-serien
  • Läs - och skrivaccelerator, som endast gäller för virtuella Datorer i Azure M-serien

För Premium Storage v1 rekommenderar vi att du använder Läs cachelagring för datafiler i SAP-databasen och väljer Ingen cachelagring för diskarna med loggfiler.

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.

För distributioner i M-serien rekommenderar vi att du endast använder Azure Write Accelerator för diskarna i dina loggfiler. Mer information, begränsningar och distribution av Azure Write Accelerator finns i Aktivera skrivningsaccelerator.

För Premium Storage v2, Ultra Disk och Azure NetApp Files erbjuds inga cachelagringsalternativ.

Icke-existerande Azure-diskar

Virtuella Azure-datorer erbjuder icke-existerande diskar när en virtuell dator har distribuerats. Om en virtuell dator startas om kan allt innehåll på dessa enheter raderas. Det är givet att datafiler och loggfiler och omgjorda filer av databaser inte under några omständigheter ska finnas på dessa icke-baserade enheter. Det kan finnas undantag för vissa databaser, där dessa icke-baserade enheter kan vara lämpliga för tempdb- och temp tablespaces.

Mer information finns i Förstå den tillfälliga enheten på virtuella Windows-datorer i Azure.

Windows nonpersisted disk Windows

Enhet D på en virtuell Azure-dator är en icke-fristående enhet som backas upp av vissa lokala diskar på Azure-beräkningsnoden. Eftersom det inte är aktiverat går alla ändringar som görs i innehållet på enhet D förlorade när den virtuella datorn startas om. Ändringarna omfattar filer som har lagrats, kataloger som har skapats och program som har installerats.

Linuxnonpersisted disk Linux

Virtuella Linux Azure-datorer monterar automatiskt en enhet på /mnt/resource som är en icke-baserad enhet som backas upp av lokala diskar på Azure-beräkningsnoden. Eftersom det inte är aktiverat går alla ändringar som görs i innehåll i /mnt/resource förlorade när den virtuella datorn startas om. Ändringarna omfattar filer som har lagrats, kataloger som har skapats och program som har installerats.

Återhämtning i Microsoft Azure Storage

Microsoft Azure Storage lagrar den grundläggande virtuella hårddisken, med operativsystem och anslutna diskar eller blobbar, på minst tre separata lagringsnoder. Den här typen av lagring kallas lokalt redundant lagring (LRS). LRS är standard för alla typer av lagring i Azure.

Det finns andra redundansmetoder. Mer information finns i Azure Storage-replikering.

Kommentar

Azure Premium Storage v1 och v2, Ultra Disk och Azure NetApp Files är den rekommenderade typen av lagring för virtuella DBMS-datorer och diskar som lagrar databaser och loggar och gör om filer. Med undantag för Premium Storage v1 är LRS den enda tillgängliga redundansmetoden för dessa lagringstyper. Därför måste du konfigurera databasmetoder för att aktivera databasdatareplikering till en annan Azure-region eller tillgänglighetszon. Databasmetoder inkluderar SQL Server Always On, Oracle Data Guard och HANA System Replication.

Återhämtning av VM-noder

Azure erbjuder flera olika serviceavtal för virtuella datorer. Mer information finns i den senaste versionen av serviceavtalet för virtuella datorer. Eftersom DBMS-lagret är viktigt för tillgängligheten i ett SAP-system måste du förstå olika distributionstyper och underhållshändelser. Mer information om dessa begrepp finns i Hantera tillgängligheten för virtuella datorer i Azure.

Den minsta rekommendationen för DBMS-scenarier för produktion med en SAP-arbetsbelastning är att:

  • Distribuera två virtuella datorer med den valda distributionstypen i samma Azure-region.
  • Kör dessa två virtuella datorer i samma virtuella Azure-nätverk och ha nätverkskort anslutna från samma undernät.
  • Använd databasmetoder för att hålla ett hett vänteläge med den andra virtuella datorn. Metoderna kan vara SQL Server Always On, Oracle Data Guard eller HANA System Replication.

Du kan också distribuera en tredje virtuell dator i en annan Azure-region och använda samma databasmetoder för att tillhandahålla en asynkron replik i en annan Azure-region.

Överväganden för Azure-nätverk

I storskaliga SAP-distributioner använder du skissen för Azure Virtual Datacenter. Använd den för konfiguration av virtuella nätverk och behörigheter och rolltilldelningar till olika delar av organisationen.

Dessa metodtips är resultatet av tusentals kunddistributioner:

  • De virtuella nätverk som SAP-programmet distribueras till har inte åtkomst till Internet.
  • De virtuella databasdatorerna körs i samma virtuella nätverk som programskiktet, avgränsade i ett annat undernät än SAP-programskiktet.
  • De virtuella datorerna i det virtuella nätverket har en statisk allokering av den privata IP-adressen. Mer information finns i IP-adresstyper och allokeringsmetoder i Azure.
  • Routningsbegränsningar till och från de virtuella DBMS-datorerna anges inte med brandväggar installerade på de lokala virtuella DBMS-datorerna. I stället definieras trafikroutning med nätverkssäkerhetsgrupper (NSG:er).
  • Om du vill separera och isolera trafik till den virtuella DBMS-datorn tilldelar du olika nätverkskort till den virtuella datorn. Varje nätverkskort får en annan IP-adress och varje nätverkskort tilldelas till ett annat virtuellt nätverksundernät. Varje undernät har olika NSG-regler. Isolering eller separation av nätverkstrafik är ett mått för routning. Den används inte för att ange kvoter för nätverkets dataflöde.

Kommentar

Att tilldela statiska IP-adresser via Azure innebär att tilldela dem till enskilda virtuella nätverkskort. Tilldela inte statiska IP-adresser i gästoperativsystemet till ett virtuellt nätverkskort. Vissa Azure-tjänster som Azure Backup förlitar sig på att det primära virtuella nätverkskortet i gästoperativsystemet är inställt på DHCP och inte på statiska IP-adresser. Mer information finns i Felsöka säkerhetskopiering av virtuella Azure-datorer. Om du vill tilldela flera statiska IP-adresser till en virtuell dator tilldelar du flera virtuella nätverkskort till en virtuell dator.

Varning

Det går inte att konfigurera virtuella nätverksinstallationer i kommunikationsvägen mellan SAP-programmet och DBMS-lagret i ett SAP NetWeaver-, Hybris- eller S/4HANA-baserat SAP-system. Den här begränsningen är av funktions- och prestandaskäl. Kommunikationssökvägen mellan SAP-programlagret och DBMS-lagret måste vara direkt. Begränsningen inkluderar inte asg- och NSG-regler om dessa ASG- och NSG-regler tillåter en direkt kommunikationsväg. Detta inkluderar även trafik till NFS-resurser som är värdar för DBMS-data och gör om loggfiler.

Andra scenarier där virtuella nätverksinstallationer inte stöds finns i:

Virtuella nätverksinstallationer i kommunikationsvägar kan enkelt fördubbla nätverksfördröjningen mellan två kommunikationspartner. De kan också begränsa dataflödet i kritiska sökvägar mellan SAP-programlagret och DBMS-lagret. I vissa kundscenarier kan virtuella nätverksinstallationer orsaka att Pacemaker Linux-kluster misslyckas. Det här är fall där kommunikationen mellan Linux Pacemaker-klusternoderna kommunicerar med deras SBD-enhet via en virtuell nätverksinstallation.

Viktigt!

En annan design som inte stöds är uppdelningen av SAP-programskiktet och DBMS-lagret i olika virtuella Azure-nätverk som inte är peer-kopplade till varandra. Vi rekommenderar att du separerar SAP-programskiktet och DBMS-lagret med hjälp av undernät i ett virtuellt Azure-nätverk i stället för med hjälp av olika virtuella Azure-nätverk.

Om du bestämmer dig för att inte följa rekommendationen och i stället separera de två lagren i olika virtuella nätverk måste de två virtuella nätverken vara peer-kopplade.

Tänk på att nätverkstrafik mellan två peerkopplade virtuella Azure-nätverk är föremål för överföringskostnader. Enorma datavolymer som består av många terabyte utbyts mellan SAP-programlagret och DBMS-lagret. Du kan ackumulera stora kostnader om SAP-programskiktet och DBMS-lagret är åtskilda mellan två peerkopplade virtuella Azure-nätverk.

Använda Azure Load Balancer för att omdirigera trafik

Användning av privata virtuella IP-adresser som används i funktioner som SQL Server AlwaysOn eller HANA System Replication kräver konfiguration av en Azure-lastbalanserare. Lastbalanseraren använder avsökningsportar för att fastställa den aktiva DBMS-noden och dirigera trafiken uteslutande till den aktiva databasnoden.

Om det finns en redundansväxling av databasnoden behöver SAP-programmet inte konfigurera om. I stället återansluter de vanligaste SAP-programarkitekturerna mot den privata virtuella IP-adressen. Samtidigt reagerar lastbalanseraren på nodens redundans genom att omdirigera trafiken mot den privata virtuella IP-adressen till den andra noden.

Azure erbjuder två olika SKU:er för lastbalanserare: en grundläggande SKU och en standard-SKU. Baserat på fördelarna med installation och funktionalitet bör du använda Standard SKU för Azure-lastbalanseraren. En av de stora fördelarna med standardversionen av lastbalanseraren är att datatrafiken inte dirigeras via själva lastbalanseraren.

Ett exempel på hur du kan konfigurera en intern lastbalanserare finns i artikeln Självstudie: Konfigurera en SQL Server-tillgänglighetsgrupp på virtuella Azure-datorer manuellt

Kommentar

Det finns skillnader i beteendet för den grundläggande SKU:n och standard-SKU:n som rör åtkomsten till offentliga IP-adresser. Hur du kringgår begränsningarna för standard-SKU:n för åtkomst till offentliga IP-adresser beskrivs i dokumentet Offentlig slutpunktsanslutning för virtuella datorer med Azure Standard Load Balancer i SAP-scenarier med hög tillgänglighet

Distribution av värdövervakning

För produktionsanvändning av SAP-program på virtuella Azure-datorer kräver SAP att du kan hämta värdövervakningsdata från de fysiska värdar som kör de virtuella Azure-datorerna. En specifik SAP-värdagentkorrigeringsnivå krävs som aktiverar den här funktionen i SAPOSCOL och SAP Host Agent. Den exakta korrigeringsnivån dokumenteras i SAP Note 1409604.

Om du vill ha mer information om distributionen av komponenter som levererar värddata till SAPOSCOL och SAP Host Agent och livscykelhantering av dessa komponenter börjar du med artikeln Implementera Azure VM-tillägget för SAP-lösningar.

Nästa steg

Mer information om en viss DBMS finns i: