Dela via

Arkitektur och scenarier med hög tillgänglighet för SAP NetWeaver

  • Artikel

Terminologidefinitioner

Hög tillgänglighet: Refererar till en uppsättning tekniker som minimerar IT-avbrott genom att tillhandahålla affärskontinuitet för IT-tjänster via redundanta, feltoleranta eller redundansskyddade komponenter i samma datacenter. I vårt fall finns datacentret i en Azure-region.

Haveriberedskap: Syftar också på att minimera avbrott i IT-tjänster och deras återställning, men över olika datacenter som kan vara hundratals mil från varandra. I vårt fall kan datacenter finnas i olika Azure-regioner inom samma geopolitiska region eller på platser som du har upprättat som kund.

Översikt över hög tillgänglighet

SAP-hög tillgänglighet i Azure kan delas in i tre typer:

  • Hög tillgänglighet för Azure-infrastruktur:

    Till exempel kan hög tillgänglighet omfatta beräkning (VM), nätverk eller lagring och dess fördelar för att öka tillgängligheten för SAP-program.

  • Använda omstart av virtuella Datorer i Azure-infrastruktur för att skydda SAP-program:

    Om du bestämmer dig för att inte använda funktioner som Windows Server-redundansklustring (WSFC) eller Pacemaker i Linux används omstart av virtuella Azure-datorer. Den återställer funktioner i SAP-systemen om det finns någon planerad och oplanerad stilleståndstid för den fysiska Azure-serverinfrastrukturen och den övergripande underliggande Azure-plattformen.

  • Hög tillgänglighet för SAP-program:

    För att uppnå fullständig hög tillgänglighet för SAP-systemet måste du skydda alla kritiska SAP-systemkomponenter. Till exempel:

    • Redundanta SAP-programservrar.
    • Unika komponenter. Ett exempel kan vara en spof-komponent (single point of failure), till exempel en SAP ASCS/SCS-instans eller ett databashanteringssystem (DBMS).

SAP-hög tillgänglighet i Azure skiljer sig från SAP-hög tillgänglighet i en lokal fysisk eller virtuell miljö.

Det finns ingen sapinst-integrerad SAP-konfiguration med hög tillgänglighet för Linux som för Windows. Information om SAP-hög tillgänglighet lokalt för Linux finns i Partnerinformation med hög tillgänglighet.

Hög tillgänglighet för Azure-infrastruktur

Serviceavtal för virtuella datorer med en instans

Det finns för närvarande ett serviceavtal för en virtuell dator på 99,9 % med premiumlagring. För att få en uppfattning om vad tillgängligheten för en enskild virtuell dator kan vara kan du skapa produkten av de olika tillgängliga Azure-serviceavtalen.

Grunden för beräkningen är 30 dagar per månad eller 43 200 minuter. Till exempel motsvarar en driftstopp på 0,05 % 21,6 minuter. Som vanligt beräknas tillgängligheten för de olika tjänsterna på följande sätt:

(Tillgänglighetstjänst #1/100) x (tillgänglighetstjänst #2/100) x (tillgänglighetstjänst #3/100) *...

Till exempel:

(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 eller en total tillgänglighet på 99,75 %.

Flera instanser av virtuella datorer i samma tillgänglighetsuppsättning

För alla virtuella datorer som har två eller flera instanser distribuerade i samma tillgänglighetsuppsättning garanterar vi att du har en virtuell datoranslutning till minst en instans minst 99,95 % av tiden.

När två eller flera virtuella datorer ingår i samma tillgänglighetsuppsättning tilldelas varje virtuell dator i tillgänglighetsuppsättningen en uppdateringsdomän och en feldomän av den underliggande Azure-plattformen.

  • Uppdateringsdomäner garanterar att flera virtuella datorer inte startas om samtidigt under det planerade underhållet av en Azure-infrastruktur. Endast en virtuell dator startas om i taget.
  • Feldomäner garanterar att virtuella datorer distribueras på maskinvarukomponenter som inte delar en gemensam strömkälla och nätverksväxel. När servrar, en nätverksväxel eller en strömkälla genomgår en oplanerad stilleståndstid påverkas endast en virtuell dator.

Mer information finns i Hantera tillgängligheten för virtuella datorer i Azure med hjälp av tillgänglighetsuppsättningen.

Tillgänglighetszoner i Azure

Azure håller på att lansera ett koncept för Azure Tillgänglighetszoner i olika Azure-regioner. I Azure-regioner där Tillgänglighetszoner erbjuds har Azure-regionerna flera datacenter, som är oberoende när det gäller strömförsörjning, kylning och nätverk. Anledningen till att du erbjuder olika zoner i en enda Azure-region är att du kan distribuera program över två eller tre Tillgänglighetszoner som erbjuds. Förutsatt att problem i energikällor och/eller nätverk endast skulle påverka en infrastruktur för tillgänglighetszoner är programdistributionen i en Azure-region fortfarande fullt fungerande. Så småningom med viss minskad kapacitet eftersom vissa virtuella datorer i en zon kan gå förlorade. Men de virtuella datorerna i de andra två zonerna är fortfarande igång. De Azure-regioner som erbjuder zoner visas i Azure Tillgänglighetszoner.

När du använder Tillgänglighetszoner finns det några saker att tänka på. Listan över överväganden som:

  • Du kan inte distribuera Azure-tillgänglighetsuppsättningar i en tillgänglighetszon. Det är bara möjligt att kombinera tillgänglighetsuppsättningar och Tillgänglighetszoner med närhetsplaceringsgrupper. Mer information finns i artikeln Kombinera tillgänglighetsuppsättningar och tillgänglighetszoner med närhetsplaceringsgrupper.
  • Du kan inte använda Basic Load Balancer för att skapa redundansklusterlösningar baserade på Windows Redundansklustertjänster eller Linux Pacemaker. I stället måste du använda Azure Standard Load Balancer SKU.
  • Azure Tillgänglighetszoner ger inga garantier för ett visst avstånd mellan de olika zonerna i en region.
  • Nätverksfördröjningen mellan olika Azure-Tillgänglighetszoner i olika Azure-regioner kan skilja sig från Azure-region till region. Det skulle finnas fall där du som kund rimligen kan köra SAP-programskiktet som distribuerats över olika zoner eftersom nätverksfördröjningen från en zon till den aktiva virtuella DBMS-datorn fortfarande är acceptabel från en affärsprocesspåverkan. Det kan finnas kundscenarier där svarstiden mellan den aktiva virtuella DBMS-datorn i en zon och en SAP-programinstans på en virtuell dator i en annan zon kan vara för påträngande och inte acceptabel för SAP-affärsprocesserna. Därför måste distributionsarkitekturerna skilja sig åt med en aktiv/aktiv arkitektur för programmet eller aktiv/passiv arkitektur om svarstiden är för hög.
  • Det är obligatoriskt att använda Azure-hanterade diskar för distribution till Azure Tillgänglighetszoner.

Vm-skalningsuppsättning med flexibel orkestrering

I Azure erbjuder vm-skalningsuppsättningar med flexibel orkestrering ett sätt att uppnå hög tillgänglighet för SAP-arbetsbelastningar, ungefär som andra distributionsramverk som tillgänglighetsuppsättningar och tillgänglighetszoner. Med flexibel skalningsuppsättning kan virtuella datorer distribueras över olika tillgänglighetszoner och feldomäner, vilket gör det till ett lämpligt alternativ för att distribuera SAP-arbetsbelastningar med hög tillgänglighet.

Vm-skalningsuppsättning med flexibel orkestrering ger flexibiliteten att skapa skalningsuppsättningen inom en region eller sträcka sig över tillgänglighetszoner. När du skapar den flexibla skalningsuppsättningen i en region med platformFaultDomainCount>1 (FD>1) distribueras de virtuella datorerna i skalningsuppsättningen över det angivna antalet feldomäner i samma region. Å andra sidan skulle skapandet av den flexibla skalningsuppsättningen mellan tillgänglighetszoner med platformFaultDomainCount=1 (FD=1) distribuera de virtuella datorerna mellan olika zoner och skalningsuppsättningen skulle också distribuera virtuella datorer mellan olika feldomäner inom varje zon på bästa sätt. För SAP-arbetsbelastning stöds endast flexibel skalningsuppsättning med FD=1.

Fördelen med att använda flexibla skalningsuppsättningar med FD=1 för distribution mellan zonindelningar, i stället för traditionell distribution av tillgänglighetszoner är att de virtuella datorer som distribueras med skalningsuppsättningen distribueras över olika feldomäner i zonen på bästa sätt. För att undvika de begränsningar som är kopplade till användning av närhetsplaceringsgrupp för att säkerställa virtuella datorers tillgänglighet i alla Azure-datacenter eller under varje nätverksrygg rekommenderar vi att du distribuerar SAP-arbetsbelastningar mellan tillgänglighetszoner med flexibel skalningsuppsättning med FD=1. Den här distributionsstrategin säkerställer att virtuella datorer som distribueras i varje zon inte är begränsade till ett enda datacenter eller nätverksrygg, och alla SAP-systemkomponenter, till exempel databaser, ASCS/ERS och programnivå, är begränsade på zonnivå.

För ny DISTRIBUTION av SAP-arbetsbelastningar mellan tillgänglighetszoner rekommenderar vi därför att du använder flexibel skalningsuppsättning med FD=1. Mer information finns i dokumentet vm-skalningsuppsättning för SAP-arbetsbelastning .

Planerat och oplanerat underhåll av virtuella datorer

Två typer av Azure-plattformshändelser kan påverka tillgängligheten för dina virtuella datorer:

  • Planerade underhållshändelser är regelbundna uppdateringar som Microsoft gör till den underliggande Azure-plattformen. Uppdateringarna förbättrar den övergripande tillförlitligheten, prestandan och säkerheten för plattformsinfrastrukturen som dina virtuella datorer körs på.
  • Oplanerade underhållshändelser inträffar när maskinvaran eller den fysiska infrastrukturen som ligger bakom den virtuella datorn har misslyckats på något sätt. Det kan vara lokala nätverksfel, lokala diskfel eller andra fel på racknivå. När ett sådant fel upptäcks migrerar Azure-plattformen automatiskt den virtuella datorn från den felaktiga fysiska servern som är värd för den virtuella datorn till en felfri fysisk server. Sådana händelser är sällsynta, men de kan också leda till att den virtuella datorn startas om.

Mer information finns i Underhåll av virtuella datorer i Azure.

Redundans i Azure Storage

Data i ditt lagringskonto replikeras alltid för att säkerställa hållbarhet och hög tillgänglighet, och uppfyller Azure Storage-serviceavtalet även vid tillfälliga maskinvarufel.

Eftersom Azure Storage behåller tre avbildningar av data som standard är användningen av RAID 5 eller RAID 1 på flera Azure-diskar onödig.

Mer information finns i Azure Storage-replikering.

Azure Managed Disks

Hanterade diskar är en resurstyp i Azure Resource Manager, är ett rekommenderat lagringsalternativ i stället för virtuella hårddiskar (VHD) som lagras i Azure Storage-konton. Hanterade diskar överensstämmer automatiskt med en Azure-tillgänglighetsuppsättning för den virtuella dator som de är anslutna till. De ökar tillgängligheten för din virtuella dator och de tjänster som körs på den.

Mer information finns i Översikt över Azure Managed Disks.

Vi rekommenderar att du använder hanterade diskar eftersom de förenklar distributionen och hanteringen av dina virtuella datorer.

Jämförelse av olika distributionstyper för SAP-arbetsbelastning

Här är en snabb sammanfattning av de olika distributionstyper som är tillgängliga för SAP-arbetsbelastningar.

Funktioner Vm-skalningsuppsättning med flexibel orkestrering (FD=1) Tillgänglighetszon Tillgänglighetsuppsättning
Distributionsbeteende Instanser hamnar i 1, 2 eller 3 tillgänglighetszoner och distribueras över olika rack inom varje zon efter bästa förmåga Instanser hamnar i 1, 2 eller 3 tillgänglighetszoner Instanser hamnar inom regionen och distribueras över olika fel-/uppdateringsdomäner
Tilldela virtuella datorer och hanterade diskar till en specifik tillgänglighetszon Ja Ja Nej
Feldomän – Maximal spridning (Azure sprider maximalt instanser) Ja Nej Ja, baserat på antalet feldomäner som definierades när de skapades.
Justering av feldomän för beräkning till lagring Nej Nej Ja
Kapacitetsreservation Ja (tilldela kapacitetsreservation på VM-nivå) Ja Nej

Kommentar

Distributionsalternativ för hög tillgänglighet för SAP-arbetsbelastningar

När du distribuerar en SAP-arbetsbelastning med hög tillgänglighet i Azure är det viktigt att ta hänsyn till de olika tillgängliga distributionstyperna och hur de kan tillämpas i olika Azure-regioner (till exempel mellan zoner, i en enda zon eller i en region utan zoner). Följande tabell visar flera alternativ för hög tillgänglighet för SAP-system i Azure-regioner.

Systemtyp Över olika zoner i en region I en singezon i en region I en region utan zoner
SAP-system med hög tillgänglighet Flexibel skalningsuppsättning med FD=1 Tillgänglighetsuppsättningar med närhetsplaceringsgrupper Tillgänglighetsuppsättningar
Tillgänglighetsuppsättningar och Tillgänglighetszoner med närhetsplaceringsgrupper Flexibel skalningsuppsättning med FD=1 (välj endast en zon) Flexibel skalningsuppsättning med FD=1 (inga zoner definieras)
Tillgänglighetszoner Tillgänglighetsuppsättningar
  • Distribution över olika zoner i en region: För högsta tillgänglighet bör SAP-system distribueras mellan olika zoner i en region. Detta säkerställer att SAP-systemet fortsätter att vara tillgängligt i en annan zon om en zon inte är tillgänglig. Om du distribuerar en ny SAP-arbetsbelastning mellan tillgänglighetszoner rekommenderar vi att du använder flexibla vm-skalningsuppsättningar med distributionsalternativet FD=1. Det gör att du kan distribuera flera virtuella datorer över olika zoner i en region utan att behöva oroa dig för kapacitetsbegränsningar eller placeringsgrupper. Skalningsuppsättningsramverket ser till att de virtuella datorer som distribueras med skalningsuppsättningen distribueras över olika feldomäner i zonen på bästa sätt. Alla SAP-komponenter med hög tillgänglighet som SAP ASCS/ERS, SAP-databaser distribueras över olika zoner, medan flera programservrar i varje zon distribueras över olika feldomäner på bästa sätt.
  • Distribution i en enda zon i en region: Om du vill distribuera ditt SAP-system med hög tillgänglighet regionalt på en plats med flera tillgänglighetszoner, och om det är viktigt att alla komponenter i systemet finns i en enda zon, rekommenderar vi att du använder tillgänglighetsuppsättningar med distributionsalternativet Närhetsplaceringsgrupper. Med den här metoden kan du gruppera alla SAP-systemkomponenter i en enda tillgänglighetszon, vilket säkerställer att de virtuella datorerna i tillgänglighetsuppsättningen är spridda över olika fel- och uppdateringsdomäner. Även om den här distributionen justerar beräkning till lagringsfeldomäner garanteras inte närhet. Men eftersom det här distributionsalternativet är regionalt stöder det inte Azure Site Recovery för haveriberedskap från zon till zon. Dessutom begränsar det här alternativet hela SAP-distributionen till ett datacenter, vilket kan leda till kapacitetsbegränsningar om du behöver ändra SKU-storleken eller skalbara programinstanser.
  • Distribution i en region utan zoner: Om du distribuerar DITT SAP-system i en region som inte har några zoner rekommenderar vi att du använder tillgänglighetsuppsättningar. Det här alternativet ger redundans och feltolerans genom att placera virtuella datorer i olika feldomäner och uppdatera domäner.

Viktigt!

Det bör noteras att distributionsalternativen för Azure-regioner bara är förslag. Den lämpligaste distributionsstrategin för ditt SAP-system beror på dina specifika krav och din miljö.

Använda hög tillgänglighet i Azure-infrastrukturen för att skydda SAP-program

Om du bestämmer dig för att inte använda funktioner som WSFC eller Pacemaker i Linux (stöds för SUSE Linux Enterprise Server 12 och senare och Red Hat Enterprise Linux 7 och senare) används omstart av virtuella Azure-datorer. Den återställer funktioner i SAP-systemen om det finns någon planerad och oplanerad stilleståndstid för den fysiska Azure-serverinfrastrukturen och den övergripande underliggande Azure-plattformen.

Mer information om metoden finns i Använda omstart av virtuella Datorer i Azure-infrastruktur för att uppnå högre tillgänglighet för SAP-systemet.

Hög tillgänglighet för SAP-program i Azure IaaS

För att uppnå fullständig hög tillgänglighet för SAP-systemet måste du skydda alla kritiska SAP-systemkomponenter. Till exempel:

  • Redundanta SAP-programservrar.
  • Unika komponenter. Ett exempel kan vara en spof-komponent (single point of failure), till exempel en SAP ASCS/SCS-instans eller ett databashanteringssystem (DBMS).

I nästa avsnitt beskrivs hur du uppnår hög tillgänglighet för alla tre kritiska SAP-systemkomponenter.

Arkitektur med hög tillgänglighet för SAP-programservrar

Windows-logotyp. Windows och Linux-logotyp. Linux

Du behöver vanligtvis ingen specifik lösning med hög tillgänglighet för SAP-programservern och dialoginstanserna. Du får hög tillgänglighet genom redundans och konfigurerar flera dialoginstanser i olika instanser av virtuella Azure-datorer. Du bör ha minst två SAP-programinstanser installerade i två instanser av virtuella Azure-datorer.

Beroende på distributionstyp (flexibel skalningsuppsättning med FD=1, tillgänglighetszon eller tillgänglighetsuppsättning) måste du distribuera SAP-programserverinstanserna i enlighet med detta för att uppnå redundans.

  • Flexibel skalningsuppsättning med platformFaultDomainCount=1 (FD=1): SAP-programservrar som distribueras med flexibel skalningsuppsättning (FD=1) distribuerar de virtuella datorerna mellan olika tillgänglighetszoner och skalningsuppsättningen distribuerar även virtuella datorer mellan olika feldomäner inom varje zon på bästa sätt. Detta säkerställer att om en zon inte är tillgänglig fortsätter DE SAP-programservrar som distribueras i en annan zon att vara tillgängliga.
  • Tillgänglighetszon: SAP-programservrar som distribueras över tillgänglighetszoner säkerställer att virtuella datorer sträcker sig över olika zoner för att uppnå redundans. Detta säkerställer att om en zon inte är tillgänglig fortsätter DE SAP-programservrar som distribueras i en annan zon att vara tillgängliga. Mer information finns i SAP-arbetsbelastningskonfigurationer med Azure Tillgänglighetszoner
  • Tillgänglighetsuppsättning: SAP-programservrar som distribueras i tillgänglighetsuppsättningen ser till att virtuella datorer distribueras över olika feldomäner och uppdateringsdomäner. När du placerar virtuella datorer i olika uppdateringsdomäner kontrollerar du att de virtuella datorerna inte uppdateras samtidigt under planerat underhållsavbrott. Att placera virtuella datorer i olika feldomäner säkerställer att den virtuella datorn skyddas mot maskinvarufel eller strömavbrott i ett datacenter. Men antalet fel- och uppdateringsdomäner som du kan använda i Azure-tillgänglighetsuppsättningen i en Azure-skalningsenhet är begränsat. Om du fortsätter att lägga till virtuella datorer i en enda tillgänglighetsuppsättning skulle två eller flera virtuella datorer slutligen hamna i samma fel- eller uppdateringsdomän. Mer information finns i avsnittet Azure-tillgänglighetsuppsättningar i dokumentet Planering och implementering av virtuella Azure-datorer för SAP NetWeaver.

Ohanterade diskar: När du använder ohanterade diskar med tillgänglighetsuppsättning är det viktigt att känna igen att Azure Storage-kontot blir en enda felpunkt. Därför är det absolut nödvändigt att ha minst två Azure-lagringskonton, där minst två virtuella datorer distribueras. I en idealisk konfiguration distribueras diskarna för varje virtuell dator som kör en SAP-dialoginstans i ett annat lagringskonto.

Viktigt!

Vi rekommenderar starkt att du använder Azure-hanterade diskar för dina SAP-installationer med hög tillgänglighet. Eftersom hanterade diskar automatiskt överensstämmer med tillgänglighetsuppsättningen för den virtuella dator som de är anslutna till ökar de tillgängligheten för den virtuella datorn och de tjänster som körs på den.

Arkitektur med hög tillgänglighet för en SAP ASCS/SCS-instans i Windows

Windows-logotyp. Windows

Du kan använda en WSFC-lösning för att skydda SAP ASCS/SCS-instansen. Baserat på typen av klusterresurskonfiguration (filresurs eller delad disk) kan du referera till lämplig lösning baserat på din lagringstyp.

Arkitektur med hög tillgänglighet för en SAP ASCS/SCS-instans i Linux

Linux-logotyp. Linux

I Linux beror konfigurationen av SAP ASCS/SCS-instanskluster på operativsystemets distribution och vilken typ av lagring som används. Vi rekommenderar att du implementerar lämplig lösning enligt ditt specifika operativsystemklusterramverk.

SAP NetWeaver multi-SID-konfiguration för en klustrad SAP ASCS/SCS-instans

Windows-logotyp. Fönster

Multi-SID stöds med WSFC, med hjälp av filresurs och delad disk. Mer information om arkitektur med hög tillgänglighet för flera SID i Windows finns i:

Linux-logotyp. Linux

Multi-SID-klustring stöds i Linux Pacemaker-kluster för SAP ASCS/ERS, begränsat till fem SAP-SID:er i samma kluster. Mer information om arkitektur med hög tillgänglighet för flera SID i Linux finns i:

Hög tillgänglighet för DBMS-instans

I ett SAP-system är ÄVEN DBMS-servrarna den enda felpunkten. Därför är det viktigt att skydda databasen genom att implementera en lösning med hög tillgänglighet. Lösningen med hög tillgänglighet för DBMS varierar beroende på vilken databas som används för SAP-systemet. Följ riktlinjerna för att uppnå hög tillgänglighet för databasen baserat på din databas.

Databas DR-rekommendation
SAP HANA HANA System Replication (HSR)
Oracle Oracle Data Guard
IBM DB2 Haveriberedskap med hög tillgänglighet (HADR)
Microsoft SQL Microsoft SQL AlwaysOn
SAP ASE ASE HADR Always On