SAP-arbetsbelastning på en virtuell Azure-dator – scenarier som stöds

  • Artikel
  • 22 minuter för att läsa

Att utforma SAP NetWeaver-, Business One- eller S/4HANA-systemarkitektur i Azure öppnar många olika möjligheter för olika arkitekturer och verktyg att använda för att få en skalbar, effektiv och Hybris mycket tillgänglig distribution. Även om det är beroende av operativsystemet eller DBMS som används finns det begränsningar. Dessutom stöds inte alla scenarier som stöds lokalt på samma sätt i Azure. Det här dokumentet går igenom de icke-tillgänglighetskonfigurationer som stöds och konfigurationer och arkitekturer med hög tillgänglighet som endast använder virtuella Azure-datorer. Information om scenarier som stöds med hana stora instanserfinns i artikeln Scenarier som stöds för hana stora instanser.

Konfiguration på två nivåer

En SAP 2-nivåkonfiguration anses vara uppbyggd av ett kombinerat lager i SAP DBMS och programlagret som körs på samma server eller VM-enhet. Den andra nivån anses vara användargränssnittslagret. När det gäller en konfiguration med två nivåer delar DBMS- och SAP-programlagret resurserna för den virtuella Azure-datorn. Därför måste du konfigurera de olika komponenterna så att komponenterna inte konkurrerar om resurser. Du måste också vara noga med att inte överprenumerera på den virtuella datorns resurser. En sådan konfiguration ger inte någon hög tillgänglighet utöver Azure-serviceavtalen för de olika Azure-komponenter som ingår.

En grafisk representation av en sådan konfiguration kan se ut så här:

Enkel konfiguration på två nivåer

Sådana konfigurationer stöds med Windows, Red Hat, SUSE och Oracle Linux för DBMS-system i SQL Server, Oracle, Db2, maxDB och SAP ASE för produktions- och icke-produktionsfall. För SAP HANA som DBMS stöds den här typen av konfigurationer endast för icke-produktionsfall. Detta inkluderar även distributionsfallet för stora Azure HANA-instanser. För alla OS/DBMS-kombinationer som stöds i Azure stöds den här typen av konfiguration. Det är dock obligatoriskt att du anger konfigurationen av DBMS och SAP-komponenterna på ett sätt som DBMS och SAP-komponenterna inte konkurrerar om minnes- och cpu-resurser och därmed överskrider de fysiska tillgängliga resurserna. Detta måste göras genom att begränsa det minne som DBMS kan allokera. Du måste också begränsa DET utökade SAP-minnet på programinstanser. Du måste också övervaka cpu-förbrukningen för den virtuella datorn totalt för att se till att komponenterna inte maximerar CPU-resurserna.

Anteckning

För SAP-produktionssystem rekommenderar vi ytterligare konfigurationer för hög tillgänglighet och eventuell haveriberedskap enligt beskrivningen senare i det här dokumentet

Konfiguration på 3 nivåer

I sådana konfigurationer separerar du SAP-programlagret och DBMS-lagret i olika virtuella datorer. Det gör du vanligtvis för större system och av skäl som är mer flexibla för resurserna i SAP-programlagret. I den enklaste konfigurationen finns det ingen hög tillgänglighet utöver Azure-serviceavtalen för de olika Azure-komponenterna som ingår.

Den grafiska representationen ser ut så här:

Diagram som visar en enkel konfiguration på 3 nivåer.

Den här typen av konfiguration stöds på Windows, Red Hat, SUSE och Oracle Linux för DBMS-system i SQL Server, Oracle, Db2, SAP HANA, maxDB och SAP ASE för produktions- och icke-produktionsfall. Det här är standarddistributionskonfigurationen för stora Azure HANA-instanser. För att förenkla har vi inte gjort skillnad mellan SAP Central Services och SAP-dialoginstanser i SAP-programlagret. I den här enkla 3-nivåkonfigurationen skulle det inte finnas något skydd för hög tillgänglighet för SAP Central Services.

Anteckning

För SAP-produktionssystem rekommenderar vi ytterligare konfigurationer för hög tillgänglighet och eventuell haveriberedskap enligt beskrivningen senare i det här dokumentet

Flera DBMS-instanser per virtuell dator eller hana stor instansenhet

I den här konfigurationstypen är du värd för flera DBMS-instanser per virtuell Azure-dator eller hana stor instansenhet. Motivationen kan vara att ha färre operativsystem för underhåll och med lägre kostnader. Andra skäl kan vara att ha mer flexibilitet och effektivitet genom att dela resurser för en större virtuell dator eller HANA stor instansenhet mellan flera DBMS-instanser. Hittills har de här konfigurationerna främst visat sig för icke-produktionssystem.

En konfiguration som denna kan se ut så här:

Flera DBMS-instanser i en enhet

Den här typen av DBMS-distribution stöds för:

Om du kör flera databasinstanser på en värd måste du se till att de olika instanserna inte konkurrerar om resurser och därmed överskrider den virtuella datorns fysiska resursgränser. Detta gäller särskilt för minne där du behöver kapa det minne som vem som helst av instanserna som delar den virtuella datorn kan allokera. Det kan också vara sant för processorresurserna som de olika databasinstanserna kan använda. Alla DBMS som nämns har konfigurationer som tillåter begränsning av minnesallokering och CPU-resurser på instansnivå. För att ha stöd för en sådan konfiguration för virtuella Azure-datorer förväntas diskarna eller volymerna som används för data och logg-/gör om-loggfilerna för de databaser som hanteras av de olika instanserna separeras. Eller med andra ord ska data eller logg-/gör om-loggfiler för databaser som hanteras av en annan DBMS-instans inte dela samma diskar eller volymer.

Diskkonfigurationen för hana stora instanser levereras konfigurerad och beskrivs i Scenarier som stöds för HANA stora instanser.

Anteckning

För SAP-produktionssystem rekommenderar vi ytterligare konfigurationer för hög tillgänglighet och eventuell haveriberedskap enligt beskrivningen senare i det här dokumentet. Virtuella datorer med flera DBMS-instanser stöds inte med de konfigurationer för hög tillgänglighet som beskrivs senare i det här dokumentet.

Flera SAP-dialoginstanser i en virtuell dator

I många fall har flera dialoginstanser distribuerats på bare metal-servrar eller till och med på virtuella datorer som körs i privata moln. Anledningen till sådana konfigurationer var att skräddarsy vissa SAP-dialoginstanser för vissa arbetsbelastningar, affärsfunktioner eller arbetsbelastningstyper. Anledningen till att inte isolera dessa instanser i separata virtuella datorer var arbetet med underhåll och åtgärder för operativsystemet. Eller i många fall kostnaderna om värden eller operatören av den virtuella datorn ber om en månadsavgift per VM som drivs och administreras. I Azure har ett scenario med flera SAP-dialoginstanser i en enda virtuell dator stöd för produktion och icke-produktion i operativsystemen för Windows, Red Hat, SUSE och Oracle Linux. SAP-kernelparametern PHYS_MEMSIZE, som är tillgänglig på Windows och moderna Linux-kernels, ska anges om flera SAP Application Server-instanser körs på en enda virtuell dator. Vi rekommenderar också att du begränsar expansionen av SAP Extended Memory på operativsystem, till exempel Windows där automatisk tillväxt av det utökade SAP-minnet implementeras. Detta kan göras med SAP-profilparametern em/max_size_MB .

Vid konfiguration på 3 nivåer där flera SAP-dialoginstanser körs i virtuella Azure-datorer kan det se ut så här:

Diagram som visar en konfiguration på 3 nivåer där flera SAP-dialoginstanser körs på virtuella Azure-datorer.

För att förenkla har vi inte gjort skillnad mellan SAP Central Services och SAP-dialoginstanser i SAP-programlagret. I den här enkla 3-nivåkonfigurationen skulle det inte finnas något skydd för hög tillgänglighet för SAP Central Services. För produktionssystem rekommenderar vi inte att du lämnar SAP Central Services oskyddat. Mer information om så kallade multi-SID-konfigurationer kring SAP Central-instanser och hög tillgänglighet för sådana multi-SID-konfigurationer finns i senare avsnitt i det här dokumentet.

Skydd med hög tillgänglighet för SAP DBMS-lagret

När du ska distribuera SAP-produktionssystem måste du överväga hot standby-typen av konfigurationer med hög tillgänglighet. Särskilt med SAP HANA, där data måste läsas in i minnet innan de kan få tillbaka fullständig prestanda och skalbarhet, är tjänstläsning i Azure inte ett perfekt mått för hög tillgänglighet.

I allmänhet stöder Microsoft endast konfigurationer och programvarupaket med hög tillgänglighet som beskrivs i avsnittet SAP-arbetsbelastning i docs.microsoft.com. Du kan läsa samma instruktion i SAP-anteckningen #1928533. Microsoft kommer inte att ge stöd för andra programramverk med hög tillgänglighet som inte dokumenterats av Microsoft med SAP-arbetsbelastning. I sådana fall är tredjepartsleverantören av ramverket för hög tillgänglighet den stödjande parten för konfigurationen med hög tillgänglighet, som måste engageras av dig som kund i supportprocessen. Undantag kommer att nämnas i den här artikeln.

I allmänhet stöder Microsoft en begränsad uppsättning konfigurationer med hög tillgänglighet på virtuella Azure-datorer eller hana stora instansenheter. För de scenarier som stöds av HANA – stora instanser läser du dokumentet Supported scenarios for HANA Large Instances(Scenarier som stöds för hana stora instanser).

För virtuella Azure-datorer stöds följande konfigurationer för hög tillgänglighet på DBMS-nivå:

Viktigt

I inget av de scenarier som beskrivs ovan stöder vi konfigurationer av flera DBMS-instanser på en virtuell dator. Innebär i vart och ett av fallen att endast en databasinstans kan distribueras per virtuell dator och skyddas med de metoder för hög tillgänglighet som beskrivs. Att skydda flera DBMS-instanser under Windows kluster eller pacemaker-redundanskluster stöds INTE just nu. Oracle Data Guard stöds också endast för enskilda instanser per VM-distribution.

Olika databassystem kan vara värdar för flera databaser under en DBMS-instans. Som i fallet med SAP HANA flera databaser finnas i flera databascontainrar (MDC). I de fall där dessa konfigurationer för flera databaser fungerar inom en redundansklusterresurs stöds dessa konfigurationer. Konfigurationer som inte stöds är fall där flera klusterresurser krävs. Som för konfigurationer där du definierar flera SQL Server tillgänglighetsgrupper, under en SQL Server instans.

DBMS HA-konfiguration

Beroende på DBMS-operativsystemen kan komponenter som Azure Load Balancer behövas eller inte som en del av lösningsarkitekturen.

Mer specifikt för maxDB måste lagringskonfigurationen vara annorlunda. I maxDB måste data och loggfiler finnas på delad lagring för konfigurationer med hög tillgänglighet. Endast för maxDB stöds delad lagring för hög tillgänglighet. För alla andra DBMS är separata lagringsstackar per nod de enda diskkonfigurationer som stöds.

Andra ramverk för hög tillgänglighet är kända för att finnas och är kända för att köras Microsoft Azure också. Microsoft har dock inte testa dessa ramverk. Om du vill skapa konfigurationen för hög tillgänglighet med dessa ramverk måste du samarbeta med leverantören av programvaran för att:

  • Utveckla en distributionsarkitektur
  • Distribution av arkitekturen
  • Stöd för arkitekturen

Viktigt

Microsoft Azure Marketplace erbjuder en mängd olika mjuka apparater som tillhandahåller lagringslösningar ovanpå inbyggd Azure-lagring. Dessa mjuka apparater kan även användas för att skapa NFS-resurser som teoretiskt sett skulle kunna användas i SAP HANA skalningsdistributioner där en reservnod krävs. Av olika skäl stöds ingen av dessa mjuka lagringsenheter för någon av DBMS-distributionerna av Microsoft och SAP på Azure. Distributioner av DBMS på SMB-resurser stöds inte alls just nu. Distributioner av DBMS på NFS-resurser är begränsade till NFS 4.1-resurser på Azure NetApp Files.

Hög tillgänglighet för SAP Central Service

SAP Central Services är en andra felpunkt i DIN SAP-konfiguration. Därför måste du även skydda dessa processer för centrala tjänster. Erbjudandet som stöds och dokumenteras för SAP-arbetsbelastningar kan läsas så här:

Av de listade lösningarna behöver du en supportrelation med SIOS för att stödja produkten och för att interagera Datakeeper med SIOS direkt i händelse av problem. Beroende på hur du har licensierat Windows, Red Hat och/eller SUSE OS kan du också behöva ha ett supportavtal med din OS-leverantör för att få fullt stöd för de angivna konfigurationerna för hög tillgänglighet.

Konfigurationen kan också visas så här:

Konfiguration av DBMS och ASCS HA

Till höger i grafiken visas SAP Central Services med hög tillgänglig. Förutom att SAP Central-tjänsterna skyddas med ett ramverk för redundanskluster som kan redundansredundans i händelse av ett problem, finns det en nödvändig NFS- eller SMB-resurs med hög tillgänglighet eller en delad Windows-disk för att se till att sapmnt och den globala transportkatalogen är tillgänglig oberoende av förekomsten av en enda virtuell dator. Ytterligare några av lösningarna, till exempel Windows Failover Cluster Server och Pacemaker, kommer att kräva en Azure-lastbalanserare för att dirigera eller dirigera om trafik till en felfri nod.

I listan som visas nämns inte Oracle Linux operativsystem. Oracle Linux stöder inte Pacemaker som ett klusterramverk. Om du vill distribuera ditt SAP-system på Oracle Linux och du behöver ett ramverk för hög tillgänglighet för Oracle Linux måste du arbeta med tredjepartsleverantörer. En av leverantörerna är SIOS med deras Protection Suite för Linux som stöds av SAP på Azure. Mer information finns i SAP-#1662610 – Supportinformation för SIOS Protection Suite för Linux för mer information.

Lagring som stöds med SAP Central Services-scenarierna som anges ovan

Eftersom endast en delmängd av Azure-lagringstyperna tillhandahåller NFS- eller SMB-resurser med hög tillgång som kvalitet för användningen i våra SAP Central Services-klusterscenarier finns en lista över lagringstyper som stöds

  • Windows Redundansklusterserver med Windows skalningsfilserver kan distribueras på alla interna Azure-lagringstyper, förutom Azure NetApp Files. Rekommendationen är dock att använda Premium Storage på grund av överordnade serviceavtal i dataflöde och IOPS.
  • Windows Klusterserver för växling vid fel med SMB Azure NetApp Files stöds på Azure NetApp Files. SMB-resurser på Azure-filtjänster stöds INTE just nu.
  • Windows Klusterserver för växling vid fel med delad Windows-disk baserat på SIOS kan distribueras på alla interna Datakeeper Azure-lagringstyper, förutom Azure NetApp Files. Rekommendationen är dock att använda Premium Storage på grund av överordnade serviceavtal i dataflöde och IOPS.
  • SUSE eller Red Hat Pacemaker med NFS-resurser Azure NetApp Files stöds på Azure NetApp Files.
  • SUSE Pacemaker som använder drdb en konfiguration mellan två virtuella datorer stöds med hjälp av interna Azure-lagringstyper, förutom Azure NetApp Files. Rekommendationen är dock att använda Premium Storage på grund av överordnade serviceavtal i dataflöde och IOPS.
  • Red Hat Pacemaker som använder glusterfs för att tillhandahålla NFS-resurs stöds med hjälp av interna Azure-lagringstyper, Azure NetApp Files. Rekommendationen är dock att använda Premium Storage på grund av överlägset serviceavtal i dataflöde och IOPS.

Viktigt

Microsoft Azure Marketplace erbjuder en mängd olika mjuka apparater som tillhandahåller lagringslösningar ovanpå inbyggd Azure-lagring. Dessa mjuka apparater kan användas för att skapa NFS- eller SMB-resurser som teoretiskt sett även skulle kunna användas i redundanskluster i SAP Central Services. Dessa lösningar stöds inte direkt för SAP-arbetsbelastning av Microsoft. Om du väljer att använda en sådan lösning för att skapa din NFS- eller SMB-resurs måste stöd för SAP Central Service-konfigurationen tillhandahållas av den tredje part som äger programvaran i den mjukt lagringsenheten.

Redundanskluster för SAP Central Services med flera SID

För att minska antalet virtuella datorer som behövs i stora SAP-landskap kan SAP köra SAP Central Services-instanser av flera olika SAP-system i konfiguration av redundanskluster. Imagine fall där du har 30 eller fler NetWeaver- eller S/4HANA-produktionssystem. Utan klustring med flera SID-datorer skulle dessa konfigurationer kräva 60 eller fler virtuella datorer i 30 eller fler Windows eller klusterkonfigurationer för pacemaker-redundanskluster. Förutom de DBMS-redundanskluster som krävs. Att distribuera flera centrala SAP-tjänster mellan två noder i en konfiguration av ett redundanskluster kan minska antalet virtuella datorer avsevärt. Men att distribuera flera SAP Central-tjänstinstanser i en klusterkonfiguration med två noder har också vissa nackdelar. Problem med en enskild virtuell dator i klusterkonfigurationen gäller för flera SAP-system. Underhåll på gästoperativsystemet som körs i klusterkonfigurationen kräver mer samordning eftersom flera SAP-produktionssystem påverkas. Verktyg som SAP LaMa stöder inte kluster med flera SID i systemkloningsprocessen.

I Azure stöds en klusterkonfiguration med flera SID för Windows med ENSA1 och ENSA2. Rekommendationen är att inte kombinera den äldre enqueue Replication Service-arkitekturen (ENSA1) med den nya arkitekturen (ENSA2) i ett kluster med flera SID. Information om en sådan arkitektur finns dokumenterad i artiklarna

För SUSE stöds även ett kluster med flera SID som baseras på Pacemaker. Hittills stöds konfigurationen för:

  • Högst fem SAP ASCS/SCS-instanser
  • Den gamla isarkitekturen för replikeringsservern (ENSA1)
  • Klusterkonfigurationer med två noder

Konfigurationen dokumenteras i guiden Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer på SUSE Linux Enterprise Server för SAP-program med flera SID

Ett kluster med flera SID:er med en replikreplikeringsserver ser schemat ut som

Diagram som visar ett kluster med flera SID:er med Enqueue Replication server (Aktivera replikeringsserver).

SAP HANA utskalningsscenarier

SAP HANA utskalningsscenarier stöds för en delmängd av de HANA-certifierade virtuella Azure-datorerna enligt listan i SAP HANA maskinvarukatalogen. Alla virtuella datorer som är markerade med "Ja" i kolumnen "Klustring" kan användas för OLAP- eller S/4HANA-utskalning. Konfigurationer utan vänteläge stöds med de Azure Storage typerna av:

SAP HANA utskalningskonfigurationer för OLAP eller S/4HANA med väntelägesnoder stöds exklusivt med NFS-delad värd på Azure NetApp Files.

Mer information om exakta lagringskonfigurationer med eller utan väntelägesnod finns i artiklarna:

Mer information om hana stora instanser som stöds FÖR HANA-utskalningskonfigurationer finns i följande dokumentation:

Haveriberedskapsscenario

Det finns en mängd olika scenarier för haveriberedskap som stöds. Vi definierar haveriberedskap som arkitekturer, vilket bör kompensera för en fullständig Azure-region som går utanför rutnätet. Det innebär att målet för haveriberedskap måste vara en annan Azure-region som mål för att köra ditt SAP-landskap. Vi separerar metoder och konfigurationer i DBMS-lager och icke-DBMS-lager.

DBMS-lager

För DBMS-lagret stöds konfigurationer som använder dbms interna replikeringsmekanismer som Always On, Oracle Data Guard, Db2 HADR, SAP ASE Always-On eller HANA System Replication. Det är obligatoriskt att replikeringsströmmen i sådana fall är asynkron, i stället för synkron som i vanliga scenarier med hög tillgänglighet som distribueras inom en enda Azure-region. Ett typiskt exempel på en sådan dbMS-haveriberedskapskonfiguration som stöds beskrivs i artikeln om SAP HANA tillgänglighet i Azure-regioner. Den andra bilden i det avsnittet beskriver ett scenario med HANA som exempel. De huvuddatabaser som stöds för SAP-program kan distribueras i ett sådant scenario.

Det finns stöd för att använda en mindre virtuell dator som målinstans i haveriberedskapsregionen eftersom den virtuella datorn inte upplever den fullständiga arbetsbelastningstrafiken. Om du gör det måste du tänka på följande:

  • Mindre VM-typer tillåter inte att många diskar är anslutna än mindre virtuella datorer
  • Mindre virtuella datorer har mindre dataflöde för nätverk och lagring
  • Storleksändring mellan VM-familjer kan vara ett problem när de olika virtuella datorerna samlas in i en Azure-tillgänglighetsuppsättning eller när storleksändringen ska ske mellan M-seriens familj och Mv2-familjen med virtuella datorer
  • Processor- och minnesförbrukning för att databasinstansen ska kunna ta emot strömmen med ändringar med minimal fördröjning och tillräckligt med PROCESSOR- och minnesresurser för att tillämpa ändringarna med minimal fördröjning på data

Mer information om begränsningar för olika VM-storlekar finns på sidan vm-storlekar

En annan metod som stöds för att distribuera ett DR-mål är att ha en andra DBMS-instans installerad på en virtuell dator som kör en DBMS-instans av en SAP-instans som inte är i produktion. Detta kan vara lite mer utmanande eftersom du behöver ta reda på vad som krävs för minne, CPU-resurser, nätverksbandbredd och lagringsbandbredd för de specifika målinstanser som ska fungera som huvudinstans i DR-scenariot. Särskilt i HANA rekommenderar vi starkt att du konfigurerar den instans som fungerar som DR-mål på en delad värd så att data inte läses in i DR-målinstansen i förväg.

För DR-scenarier med hana-stor instans kontrollerar du följande dokument:

Anteckning

Användningen av Azure Site Recovery har inte testats för DBMS-distributioner under SAP-arbetsbelastning. Därför stöds det inte för DBMS-skiktet i SAP-system vid den här tidpunkten. Andra replikeringsmetoder från Microsoft och SAP som inte finns med i listan stöds inte. Användning av programvara från tredje part för replikering av DBMS-lagret av SAP-system mellan olika Azure-regioner måste stödjas av programvaruleverantören och kommer inte att stödjas via Microsoft- och SAP-supportkanaler.

Icke-DBMS-lager

För SAP-programlagret och eventuella resurser eller lagringsplatser som behövs används de två huvudscenarierna av kunder:

  • Haveriberedskapsmålen i den andra Azure-regionen används inte för produktion eller icke-produktion. I det här scenariot distribueras helst inte de virtuella datorer som fungerar som haveriberedskapsmål och avbildningen och ändringarna i avbildningarna av SAP-programlagret för produktion replikeras till haveriberedskapsregionen. En funktion som kan utföra en sådan uppgiftAzure Site Recovery . Azure Site Recovery ett azure-till-Azure-replikeringsscenario som det här.
  • Katastrofåterställningsmålen är virtuella datorer som faktiskt används av icke-produktionssystem. Hela SAP-miljön är utspridd i två olika Azure-regioner med produktionssystem, vanligtvis i en region och icke-produktionssystem i en annan region. I många kunddistributioner har kunden ett icke-produktionssystem som motsvarar ett produktionssystem. Kunden har förinstallerade programinstanser för produktion på icke-produktionssystem på programnivån. Vid en redundans skulle icke-produktionsinstanserna stängas av, de virtuella namnen på de virtuella produktions datorerna flyttades till de virtuella datorerna som inte var i produktion (när de har tilldelar nya IP-adresser i DNS) och de förinstallerade produktionsinstanserna kommer igång

SAP Central Services-kluster

SAP Central Services-kluster som använder delade diskar (Windows), SMB-resurser (Windows) eller NFS-resurser är lite svårare att replikera. På Windows är Windows Storage replikering en möjlig lösning. I Linux är rsync en fungerande lösning.

Scenario som inte stöds

Det finns en lista över scenarier som inte stöds för SAP-arbetsbelastning i Azure-arkitekturer. Stöds inte innebär att SAP och Microsoft inte kommer att kunna stödja dessa konfigurationer och behöver skjuta upp till en eventuellt involverad tredjeparts som tillhandahöll programvara för att upprätta sådana arkitekturer. Två av kategorierna är:

  • Storage: Det finns ett antal mjuka lagringsenheter på Azure Marketplace. Några av leverantörerna erbjuder egen dokumentation om hur du använder dessa mjuka lagringsenheter i Azure som är relaterade till SAP-programvara. Stöd för konfigurationer eller distributioner som omfattar sådana mjuka lagringsenheter måste tillhandahållas av leverantören av dessa mjuka lagringsenheter. Detta visas också i SAP-supportanteckningen #2015553
  • Ramverk för hög tillgänglighet: Endast pacemaker och Windows Server-redundanskluster stöds ramverk för hög tillgänglighet för SAP-arbetsbelastning på Azure. Som tidigare nämnts beskrivs och dokumenteras lösningen av SIOS Datakeeper av Microsoft. Komponenterna i SIOS måste dock Datakeeper stödjas via SIOS som leverantör som tillhandahåller dessa komponenter. SAP listade även andra certifierade ramverk för hög tillgänglighet i olika SAP-anteckningar. Några av dem certifierades även av tredjepartsleverantören för Azure. Stöd för konfigurationer som använder dessa produkter måste dock tillhandahållas av produktleverantören. Olika leverantörer har olika integrering i SAP-supportprocesserna. Du bör klargöra vilken supportprocess som fungerar bäst för den specifika leverantören innan du bestämmer dig för att använda produkten i SAP-konfigurationer som distribueras i Azure.
  • Delade diskkluster där databasfiler finns på delade diskar stöds inte med undantag för maxDB. För alla andra databaser är lösningen som stöds att ha separata lagringsplatser i stället för en SMB- eller NFS-resurs eller delad disk för att konfigurera scenarier med hög tillgänglighet

Andra scenarier som inte stöds är scenarier som:

  • Distributionsscenarier som ger längre nätverksfördröjning mellan SAP-programnivån och SAP DBMS-nivån i SAP:s gemensamma arkitektur, som visas i NetWeaver, S/4HANA och t.ex. Hybris . Du måste bland annat:
    • Distribuera en av nivåerna lokalt medan den andra nivån distribueras i Azure
    • Distribuera SAP-programnivån för ett system i en annan Azure-region än DBMS-nivån
    • Distribuera en nivå i datacenter som är samplacerade till Azure och den andra nivån i Azure, förutom där ett sådant arkitekturmönster tillhandahålls av en inbyggd Azure-tjänst
    • Distribuera virtuella nätverks installationer mellan SAP-programnivån och DBMS-lagret
    • Utnyttja lagring som finns i datacenter som är sambelägna i Azure-datacentret för SAP DBMS-nivån eller sap global transportkatalog
    • Distribuera de två lagren med två olika molnleverantörer. Du kan till exempel distribuera DBMS-nivån i Oracle Cloud Infrastructure och programnivån i Azure
  • Klusterkonfigurationer för Multi-Instance HANA Pacemaker
  • Windows Klusterkonfigurationer med delade diskar via SOFS eller SMB på ANF för SAP-databaser som stöds på Windows. I stället rekommenderar vi att du använder intern replikering med hög tillgänglighet för de specifika databaserna och använder separata lagringsstackar
  • Distribution av SAP-databaser som stöds på Linux med databasfiler som finns i NFS-resurser ovanpå ANF, med undantag för SAP HANA, Oracle på Oracle Linux och Db2 på Suse och Red Hat
  • Distribution av Oracle DBMS på andra gästoperativsystem än Windows och Oracle Linux. Se även SAP-supportanteckning #2039619

Scenarier som vi inte har testat och därför inte har någon erfarenhet av listan som:

  • Azure Site Recovery replikera virtuella datorer på DBMS-nivå. Därför rekommenderar vi att du använder databasens inbyggda asynkrona replikeringsfunktioner för konfiguration av potentiell haveriberedskap

Nästa steg

Läs nästa steg i Azure-Virtual Machines planering och implementering för SAP NetWeaver