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

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

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 några referenser till specifika DBMS-system i det här kapitlet. I stället hanteras de specifika DBMS-systemen i det här dokumentet, efter det här dokumentet.

Definitioner

I hela dokumentet används dessa termer:

• IaaS: Infrastruktur som en tjänst.

• PaaS: Plattform som en tjänst.

• SaaS: Programvara som en tjänst.

• SAP-komponent: Ett enskilt SAP-program som ERP Central Component (ECC), Business Warehouse (BW), Solution Manager eller Enterprise Portal (EP). SAP-komponenter kan baseras på traditionella ABAP eller Java-tekniker eller på ett icke-NetWeaver-baserat program, till exempel affärsobjekt.

• SAP-miljö: En eller flera SAP-komponenter grupperas logiskt för att utföra en affärsfunktion, till exempel utveckling, kvalitetssäkring, utbildning, haveriberedskap eller produktion.

• SAP-landskap: Den här termen avser hela SAP-tillgångarna i en kunds IT-landskap. SAP-landskap innehåller alla produktions- och icke-produktionsmiljöer.

• SAP-system: Kombinationen av ett DBMS-lager och ett programlager i, till exempel ett SAP ERP-utvecklingssystem, ett SAP Business Warehouse-testsystem eller ett SAP CRM-produktionssystem. I Azure-distributioner stöds inte uppdelning av dessa två lager mellan lokala och Azure. Därför distribueras ett SAP-system antingen lokalt eller i Azure. Du kan distribuera de olika systemen i ett SAP-landskap i Azure eller lokalt. Du kan till exempel distribuera SAP CRM-utvecklings- och testsystemen i Azure men distribuera SAP CRM-produktionssystemet lokalt.

• Flera platser: Beskriver ett scenario där virtuella datorer distribueras till en Azure-prenumeration som har plats-till-plats-, multisite- eller Azure ExpressRoute-anslutning mellan lokala datacenter och Azure. I den vanliga Azure-dokumentationen beskrivs även dessa typer av distributioner som scenarier över flera platser.

  Orsaken till anslutningen är att utöka lokala domäner, lokal Active Directory och lokal DNS till Azure. Det lokala landskapslandskapet utökas till Azure-tillgångarna i prenumerationen. Med det här tillägget kan de virtuella datorerna ingå i den lokala domänen. Domänanvändare av den lokala domänen kan komma åt servrarna och köra tjänster på dessa virtuella datorer, t.ex. DBMS-tjänster. Kommunikation och namnmatchning mellan virtuella datorer som distribuerats lokalt och virtuella datorer som distribuerats i Azure är möjligt. Det här scenariot är det vanligaste scenariot som används för att distribuera SAP-tillgångar i Azure. Mer information finns i Planera och utforma för VPN Gateway.

Vissa Microsoft-dokumentation beskriver scenarier mellan olika platser lite annorlunda, särskilt för konfigurationer med hög tillgänglighet i DBMS. När det gäller SAP-relaterade dokument handlar scenariot mellan olika platser om plats-till-plats eller privat ExpressRoute-anslutning och ett SAP-landskap som är distribuerat mellan den lokala miljön och Azure.

Resurser

Det finns andra artiklar om SAP-arbetsbelastning på Azure. Börja med SAP-arbetsbelastning på Azure: Kom igång och välj sedan ditt intresseområde.

Följande SAP-anteckningar är relaterade SAP på Azure med avseende på det område som tas upp i det här dokumentet.

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

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

I allmänhet är Windows, Linux och DBMS installation och konfiguration i stort sett samma som alla virtuella datorer eller datorer utan operativsystem som du installerar lokalt. Det finns vissa implementeringsbeslut för arkitektur och systemhantering som skiljer sig åt när du använder Azure IaaS. Det här dokumentet beskriver de specifika skillnader i arkitektur- och systemhantering som du bör förbereda dig för när du använder Azure IaaS.

Storage struktur för en virtuell dator för RDBMS-distributioner

Följ det här kapitlet genom att läsa och förstå informationen som presenteras i:

• Azure Virtual Machines planering och implementering för SAP NetWeaver
• Azure Storage-typer för SAP-arbetsbelastning
• Vilken SAP-programvara stöds för Azure-distributioner
• SAP-arbetsbelastning på en virtuell Azure-dator – scenarier som stöds

Du måste förstå och känna till de olika VM-Series och skillnaderna mellan standard- och premiumlagring innan du läser det här kapitlet.

För Azure-blocklagring rekommenderas användning av Azure-hanterade diskar starkt. 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. Om du ändrar tidigare rekommendationer rekommenderar vi att du har separata Azure-diskar för:

• Operativsystemet (bas-VHD eller OS VHD)
• Körbara filer för databashanteringssystem
• Körbara SAP-filer som /usr/sap

En konfiguration som separerar dessa komponenter i tre olika Azure-diskar kan resultera i högre återhämtning eftersom omfattande logg- eller dump-skrivningar av DBMS- eller SAP-körbara filer inte stör os-diskens diskkvoter.

DBMS-data och transaktions-/gör om-loggfiler lagras i Block storage eller Azure NetApp Files som stöds i Azure. De lagras på separata diskar och ansluts som logiska diskar till den ursprungliga virtuella datorn med Azure-operativsystemavbildningen. För Linux-distributioner dokumenteras olika rekommendationer, särskilt för SAP HANA. Läs artikeln om Azure Storage för SAP-arbetsbelastning för funktionerna och stödet för de olika lagringstyperna för ditt scenario.

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

• Antalet datafiler.
• Antalet diskar som innehåller filerna.
• IOPS-kvoter 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 lagrings- eller nätverksgenomflödet som en virtuell dator kan tillhandahålla.
• Svarstiden kan Azure Storage olika typer av svarstider.
• Serviceavtal för virtuella datorer.

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

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 premiumlagring. Vanligtvis bestämmer du dig för att använda en viss typ av virtuell dator baserat på cpu- och minneskrav. Du kan också överväga kraven på IOPS, svarstid och diskgenomflöde som vanligtvis skalas med antalet diskar eller typen av premiumlagringsdiskar. Antalet IOPS och dataflödet som ska uppnås av varje disk kan styra diskstorleken, särskilt med premiumlagring.

Placeringen av databasfilerna, logg- och gör om-filerna och den typ av Azure Storage du använder definieras av IOPS, svarstid och dataflödeskrav. Mer specifikt för Azure Premium Storage för att uppnå tillräckligt med IOPS kan du behöva använda flera diskar eller använda en större Premium Storage-disk. Om du använder flera diskar skapar du en programvarustrimp över diskarna som innehåller datafilerna eller loggen och gör om filer. I sådana fall är serviceavtalen för IOPS och diskgenomflöde för de underliggande premiumlagringsdiskarna eller högsta möjliga IOPS för standardlagringsdiskar ackumulativa för den resulterande stripe-uppsättningen.

Om ditt IOPS-krav överskrider vad en enskild virtuell hårddisk kan tillhandahålla balanserar du antalet 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 programvara stripe över de olika diskarna. Placera sedan ett antal datafiler för SAP DBMS på LUN som är uppskalat från programvarustrimlan. Antalet diskar i remsan styrs av IOPS-krav, krav på diskgenomflöde och volymkrav.

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

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

• Konfigurera programvaru-RAID på Linux med HJÄLP av MDADM
• Konfigurera LVM på en virtuell Linux-dator i Azure med LVM

För Azure Ultra-diskar är striping inte nödvändigt eftersom du kan definiera IOPS och diskgenomflöde oberoende av diskens storlek.

Hanterade eller icke-hanterade diskar

Ett Azure-lagringskonto är en administrativ konstruktion och ett ämne med begränsningar. Begränsningarna skiljer sig mellan standardlagringskonton och Premium Storage-konton. Information om funktioner och begränsningar finns i Azure Storage skalbarhets- och prestandamål.

Kom ihåg att det finns en gräns för IOPS per lagringskonto för standardlagring. Se raden som innehåller den totala förfrågningsfrekvensen i artikeln Azure Storage skalbarhets- och prestandamål. Det finns också en inledande gräns för antalet lagringskonton per Azure-prenumeration. Balansera virtuella hårddiskar för det större SAP-liggande sap-liggande mellan olika lagringskonton för att undvika att nå gränserna för dessa lagringskonton. Det här är omedvetet arbete när du pratar om några hundra virtuella datorer med mer än tusen virtuella hårddiskar.

Användning av standardlagring för DBMS-distributioner tillsammans med en SAP-arbetsbelastning rekommenderas inte. Referenser och rekommendationer för standardlagring är därför begränsade till den här korta artikeln

För att undvika det administrativa arbetet med att planera och distribuera virtuella hårddiskar över olika Azure-lagringskonton introducerade Microsoft Azure Managed Disks 2017. Hanterade diskar är tillgängliga för standardlagring och premiumlagring. De största fördelarna med hanterade diskar jämfört med icke-hanterade diskar är:

• För hanterade diskar distribuerar Azure automatiskt de olika virtuella hårddiskarna mellan olika lagringskonton vid distributionen. På så sätt används inte lagringskontobegränsningar för datavolym, I/O-dataflöde och IOPS.
• Med hjälp av hanterade diskar Azure Storage vi begreppen i Azure-tillgänglighetsuppsättningar. Om den virtuella datorn är en del av en Azure-tillgänglighetsuppsättning distribueras den virtuella bas-VHD:n och den anslutna disken för en virtuell dator till olika fel- och uppdateringsdomäner.

Om du vill konvertera från ohanterade till hanterade diskar kan du se:

• Konvertera en Windows virtuell dator från ohanterade diskar till hanterade diskar.
• Konvertera en virtuell Linux-dator från ohanterade diskar till hanterade diskar.

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 främst en läsarbetsbelastning mot datafiler i en databas. Dessa läsningar är prestandakritiska för DBMS-systemet.
• Skrivning mot datafiler sker i burst-fel baserat på kontrollpunkter eller en konstant dataström. I genomsnitt under en dag finns det färre skrivningar än läsningar. Motsatsen till läsningar från datafiler är dessa skrivningar asynkrona och rymmer inte några användartransaktioner.
• Det finns nästan inga läsningar från transaktionsloggen eller redofiler. Undantag är stora I/O när du säkerhetskopierar transaktionsloggar.
• Den huvudsakliga belastningen mot transaktions- eller redologgfiler är skrivningar. Beroende på typen av arbetsbelastning kan du ha I/O 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 standardlagring är de möjliga cachetyperna:

• Ingen
• Läs
• Läsa/Skriva

För att få konsekventa och deterministiska prestanda anger du cachelagringen på standardlagringen för alla diskar som innehåller DBMS-relaterade datafiler, logg- och gör om-filer och tabellutrymmet till NONE. Cachelagringen av den virtuella bas-VHD:en kan finnas kvar med standardinställningen.

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

• Ingen
• Läs
• Läsning/skrivning
• Ingen + Skrivningsaccelerator, som endast är för virtuella datorer i Azure M-serien
• Läsa + Skrivningsaccelerator, som endast är för virtuella datorer i Azure M-serien

För Premium Storage rekommenderar vi att du använder Cachelagring av läsning för datafiler i SAP-databasen och väljer Ingen cachelagring för diskarna i loggfilerna.

För distributioner i M-serien rekommenderar vi att du använder Azure Skrivningsaccelerator för din DBMS-distribution. Mer information, begränsningar och distribution av Azure Skrivningsaccelerator finns i Aktivera Skrivningsaccelerator.

För Ultra disk och Azure NetApp Files finns inga alternativ för cachelagring.

Icke-persistent-diskar i Azure

Virtuella Azure-datorer erbjuder icke-persistent-diskar när en virtuell dator har distribuerats. Vid omstart av en virtuell dator rensas allt innehåll på enheterna. Det är givet att datafiler och logg- och omkondrap-filer för databaser inte under några omständigheter ska finnas på dessa icke-enskilda enheter. Det kan finnas undantag för vissa databaser, där dessa icke-begränsade enheter kan vara lämpliga för tempdb- och temp-tabellrymder. Undvik att använda dessa enheter för virtuella datorer i A-serien eftersom dessa icke-äldsta enheter har begränsat dataflöde med den virtuella datorfamiljen.

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

Windows

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

Linux

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

Microsoft Azure Storage återhämtning

Microsoft Azure Storage lagrar den grundläggande virtuella hårddisken, med operativsystem och anslutna diskar eller blobar, 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.

Vm-nodåter återhämtning

Azure erbjuder flera olika serviceavtal för virtuella datorer. Mer information finns i den senaste versionen av serviceavtalet för Virtual Machines. Eftersom DBMS-lagret är kritiskt för tillgängligheten i ett SAP-system måste du förstå tillgänglighetsuppsättningar, Tillgänglighetszoner och underhållshändelser. Mer information om dessa begrepp finns i Hantera tillgängligheten för virtuella Windows i Azure och Hantera tillgängligheten för virtuella Linux-datorer i Azure.

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

• Distribuera två virtuella datorer i en separat tillgänglighetsuppsättning i samma Azure-region.
• Kör dessa två virtuella datorer i samma virtuella Azure-nätverk och ha nätverkskort som är anslutna till samma undernät.
• Använd databasmetoder för att ha ett hett vänteläge med den andra virtuella datorn. Metoder 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.

Information om hur du ställer in Azure-tillgänglighetsuppsättningar finns i den här självstudien.

Nätverksöverväganden för Azure

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

Dessa metodtips är resultatet av hundratals kunddistributioner:

• De virtuella nätverk som SAP-programmet distribueras till har inte åtkomst till Internet.
• De virtuella databas datorerna körs i samma virtuella nätverk som programlagret, avgränsade i ett annat undernät från SAP-programlagret.
• 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 konfigureras 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 olika IP-adresser och varje nätverkskort tilldelas till olika virtuella nätverksundernät. Varje undernät har olika NSG-regler. Isolering eller avgränsning 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.

Använd två virtuella datorer för din DBMS-produktionsdistribution i en Azure-tillgänglighetsuppsättning eller mellan två Azure-tillgänglighetszoner. Använd också separat routning för SAP-programlagret och hanterings- och drifttrafik till de två virtuella DBMS-datorerna. Se följande bild:

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

Användningen av privata virtuella IP-adresser som används i funktioner som SQL Server Always On 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 exklusivt till den aktiva databasnoden.

Om det finns en redundans för databasnoden behöver inte SAP-programmet konfigureras om. I stället återansluter de vanligaste SAP-programarkitekturerna till den privata virtuella IP-adressen. Under tiden reagerar lastbalanseraren på nodens redundans genom att dirigera om 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 funktioner bör du använda Standard-SKU för Azure Load Balancer. 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å Azure Virtual Machines manuellt

Azure-accelererat nätverk

För att ytterligare minska nätverksfördröjningen mellan virtuella Azure-datorer rekommenderar vi att du väljer Azure-accelererat nätverk. Använd den när du distribuerar virtuella Azure-datorer för en SAP-arbetsbelastning, särskilt för SAP-programlagret och SAP DBMS-lagret.

Windows

Information om hur du distribuerar virtuella datorer med accelererat nätverk för Windows finns i Skapa en Windows virtuell dator med accelererat nätverk.

Linux

Mer information om Linux-distribution finns i Skapa en virtuell Linux-dator med accelererat nätverk.

Distribution av värdövervakning

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

Mer information om distributionen av komponenter som levererar värddata till SAPOSCOL och SAP-värdagenten och livscykelhanteringen av dessa komponenter finns i distributionsguiden.

Nästa steg

Mer information om en viss DBMS finns i:

• DBMS-distribution för SAP-arbetsbelastning för SQL Server på Azure Virtual Machines
• DBMS-distribution för SAP-arbetsbelastning för Oracle på Azure Virtual Machines
• IBM DB2 Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning
• DBMS-distribution för SAP-arbetsbelastning för SAP ASE på Azure Virtual Machines
• Distribution av SAP maxDB, live-cache och innehållsserver i Azure
• Användarguide för SAP HANA på Azure
• SAP HANA hög tillgänglighet för virtuella Azure-datorer
• Säkerhetskopieringsguide för SAP HANA virtuella Azure-datorer