Arkitektur och scenarier för hög tillgänglighet för SAP NetWeaver
Terminologidefinitioner
Hög tillgänglighet: Avser en uppsättning tekniker som minimerar IT-avbrott genom att tillhandahålla affärskontinu hos 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å minimering av avbrott i IT-tjänster och deras återställning, men mellan olika datacenter som kan vara hundratals mil från varandra. I vårt fall kan datacenter finnas i olika Azure-regioner i samma geopolitiska region eller på platser som du har upprättat som kund.
Översikt över hög tillgänglighet
HÖG TILLGÄNGLIGHET FÖR SAP i Azure kan delas in i tre typer:
Hög tillgänglighet för Azure-infrastruktur:
Hög tillgänglighet kan till exempel omfatta beräkning (VM), nätverk eller lagring och dess fördelar med att öka tillgängligheten för SAP-program.
Använda omstart av virtuella datorer i Azure-infrastrukturen för att uppnå högre tillgänglighet för SAP-program:
Om du bestämmer dig för att inte använda funktioner som Windows Server Failover Clustering (WSFC) eller Pacemaker på Linux, används omstart av virtuella Azure-datorer. Det skyddar SAP-system mot planerade och oplanerade driftstopp i 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. 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).
HÖG TILLGÄNGLIGHET FÖR SAP i Azure skiljer sig från SAP med hög tillgänglighet i en lokal fysisk eller virtuell miljö. I följande artikel om hög tillgänglighet och affärskontinuisering för SAP NetWeaver i virtuella miljöer med VMware och Hyper-V på Microsoft Windows beskrivs standardkonfigurationer för SAP med hög tillgänglighet i virtualiserade miljöer på Windows.
Det finns ingen sapinst-integrerad SAP-konfiguration med hög tillgänglighet för Linux eftersom det finns för Windows. Information om SAP med hög tillgänglighet lokalt för Linux finns i Information om partner 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 Premium Storage. Om du vill 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. Ett stillestånd på 0,05 % motsvarar till exempel 21,6 minuter. Som vanligt beräknas tillgängligheten för de olika tjänsterna på följande sätt:
(Availability Service #1/100) * (Availability Service #2/100) * (Tillgänglighetstjänst #3/100) * ...
Exempel:
(99,95/100) * (99,9/100) * (99,9/100) = 0,9975 eller en övergripande 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 anslutning till minst en instans minst 99,95 % av gångerna.
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ätverkss switch. När servrar, en nätverksväxel eller en strömkälla genomgår ett oplanerat driftstopp påverkas bara en virtuell dator.
Mer information finns i Hantera tillgängligheten för virtuella Windows i Azure.
En tillgänglighetsuppsättning används för att uppnå hög tillgänglighet för:
- Redundanta SAP-programservrar.
- Kluster med två eller flera noder (till exempel virtuella datorer) som skyddar SPOF:er, till exempel en SAP ASCS/SCS-instans eller en DBMS.
Tillgänglighetszoner i Azure
Azure är under utveckling för att lansera ett koncept för Azure-tillgänglighetszoner i olika Azure-regioner. I Azure-Tillgänglighetszoner som erbjuds har Azure-regionerna flera datacenter, som är oberoende av strömförsörjning, kylning och nätverk. Anledningen till att erbjuda olika zoner inom en enda Azure-region är att du kan distribuera program över två eller tre Tillgänglighetszoner erbjuds. Förutsatt att problem med strömkällor och/eller nätverk skulle påverka en tillgänglighetszonsinfrastruktur, är programdistributionen i en Azure-region fortfarande fullt funktionell. Så småningom med viss minskad kapacitet eftersom vissa virtuella datorer i en zon kan gå förlorade. Men virtuella datorer i de andra två zonerna är fortfarande igång. De Azure-regioner som erbjuder zoner visas i Azure-tillgänglighetszoner.
Med 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. Du måste välja antingen en tillgänglighetszon eller en tillgänglighetsuppsättning som distributionsram för en virtuell dator.
- Du kan inte använda Basic-Load Balancer för att skapa lösningar för redundanskluster baserat Windows klustertjänster för växling vid fel eller Linux Pacemaker. I stället måste du använda Azure Standard Load Balancer-SKU:n
- Azure-tillgänglighetszoner ger inte några garantier på ett visst avstånd mellan de olika zonerna inom en region
- Nätverksfördröjningen mellan olika Azure-tillgänglighetszoner olika Azure-regioner kan skilja sig från Azure-region till region. Det kommer att finnas fall där du som kund rimligen kan köra SAP-programlagret distribuerat över olika zoner eftersom nätverksfördröjningen från en zon till den aktiva virtuella DBMS-datorn fortfarande är acceptabel på grund av affärsprocesspåverkan. Det kommer att finnas kundscenarier där svarstiden mellan den aktiva virtuella DBMS-datorn i en zon och en SAP-programinstans i en virtuell dator i en annan zon kan vara för störande och inte acceptabel för SAP-affärsprocesserna. Därför måste distributionsarkitekturerna vara annorlunda 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 att distribuera till Azure-tillgänglighetszoner
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 periodiska uppdateringar som Görs av Microsoft till den underliggande Azure-plattformen. Uppdateringarna förbättrar övergripande tillförlitlighet, prestanda och säkerhet 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 omfatta 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 ovanliga, men de kan också göra att den virtuella datorn startas om.
Mer information finns i Hantera tillgängligheten för virtuella Windows 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, vilket uppfyller serviceavtalet Azure Storage även vid tillfälliga maskinvarufel.
Eftersom Azure Storage behåller tre avbildningar av data som standard är det onödigt att använda RAID 5 eller RAID 1 på flera Azure-diskar.
Mer information finns i Azure Storage replikering.
Azure Managed Disks
Managed Disks är en resurstyp i Azure Resource Manager som rekommenderas att användas i stället för virtuella hårddiskar (VHD) som lagras i Azure Storage-konton. Hanterade diskar justeras automatiskt med en Azure-tillgänglighetsuppsättning för den virtuella dator som de är anslutna till. De ökar tillgängligheten för den virtuella datorn 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.
Använda Azure-infrastruktur med hög tillgänglighet för att uppnå högre tillgänglighet för SAP-program
Om du bestämmer dig för att inte använda funktioner som WSFC eller Pacemaker på Linux (stöds för närvarande endast för SUSE Linux Enterprise Server [SLES] 12 och senare) används omstart av virtuella Azure-datorer. Det skyddar SAP-system mot planerade och oplanerade driftstopp i den fysiska Azure-serverinfrastrukturen och den övergripande underliggande Azure-plattformen.
Mer information om den här metoden finns i Använda omstart av virtuella datorer i Azure-infrastrukturen för att uppnå högre tillgänglighet för SAP-systemet.
Hög tillgänglighet för SAP-program på Azure IaaS
För att uppnå fullständig hög tillgänglighet för SAP-systemet måste du skydda alla kritiska SAP-systemkomponenter. 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 viktiga SAP-systemkomponenter.
Arkitektur med hög tillgänglighet för SAP-programservrar
Det här avsnittet gäller för:
Windows och
Linux
Vanligtvis behöver du inte någon specifik lösning för hög tillgänglighet för SAP-programservern och dialoginstanserna. Du uppnå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.
Bild 1: SAP-programserver med hög tillgänglighet
Du måste placera alla virtuella datorer som är värdar för SAP-programserverinstanser i samma Azure-tillgänglighetsuppsättning. En Azure-tillgänglighetsuppsättning säkerställer att:
Alla virtuella datorer ingår inte i samma uppdateringsdomän.
En uppdateringsdomän säkerställer att de virtuella datorerna inte uppdateras samtidigt under planerat underhållsavbrott.De grundläggande funktionerna, som bygger på olika uppdaterings- och feldomäner i en Azure-skalningsenhet, introducerades redan i avsnittet uppdateringsdomäner.
Alla virtuella datorer ingår inte i samma feldomän.
En feldomän säkerställer att virtuella datorer distribueras så att ingen enskild felpunkt påverkar tillgängligheten för alla virtuella datorer.
Antalet uppdaterings- och feldomäner som kan användas av en Azure-tillgänglighetsuppsättning i en Azure-skalningsenhet är begränsat. Om du fortsätter att lägga till virtuella datorer i en enda tillgänglighetsuppsättning kommer två eller flera virtuella datorer så småningom att hamna i samma fel eller uppdateringsdomän.
Om du distribuerar några SAP-programserverinstanser på deras dedikerade virtuella datorer, förutsatt att vi har fem uppdateringsdomäner, visas följande bild. Det faktiska maximala antalet uppdaterings- och feldomäner inom en tillgänglighetsuppsättning kan komma att ändras i framtiden:
2: Hög tillgänglighet för SAP-programservrar i en Azure-tillgänglighetsuppsättning
Mer information finns i Hantera tillgängligheten för virtuella Windows i Azure.
Mer information finns i avsnittet om Tillgänglighetsuppsättningar för Azure i dokumentet Planering och implementering av virtuella Azure-datorer för SAP NetWeaver.
Ohanterade diskar: Eftersom Azure Storage-kontot är en potentiell felpunkt är det viktigt att ha minst två Azure-lagringskonton där minst två virtuella datorer distribueras. I en idealisk konfiguration skulle diskarna för varje virtuell dator som kör en SAP-dialoginstans distribueras 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 på Windows
Du kan använda en WSFC-lösning för att skydda SAP ASCS/SCS-instansen. Lösningen har två varianter:
Klustra SAP ASCS/SCS-instansen med hjälp av klustrade delade diskar: Mer information om den här arkitekturen finns i Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a cluster shared disk(Klustra en SAP ASCS/SCS-instans på ett Windows-redundanskluster med hjälp av en klusterdelade disk).
Klustra SAP ASCS/SCS-instansen med hjälp av filresurs: Mer information om den här arkitekturen finns i Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using file share(Klustra en SAP ASCS/SCS-instans på ett Windows redundanskluster med filresursen ).
Klustra SAP ASCS/SCS-instansen med anf SMB-resurs: Mer information om den här arkitekturen finns i Cluster Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using ANF SMB file share (Klusterkluster en SAP ASCS/SCS-instans på ett Windows-redundanskluster med anf SMB-filresurs).
Arkitektur med hög tillgänglighet för en SAP ASCS/SCS-instans i Linux
Mer information om klustring av SAP ASCS/SCS-instansen med hjälp av SLES-klusterramverket finns i Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer på SUSE Linux Enterprise Server för SAP-program. För alternativ HA-arkitektur på SLES, som inte kräver NFS med hög tillgänglighet, se Guide för hög tillgänglighet för SAP NetWeaver på SUSE Linux Enterprise Server med Azure NetApp Files för SAP-program.
Mer information om klustring av SAP ASCS/SCS-instansen med hjälp av Red Hat-klusterramverket finns i Azure Virtual Machines hög tillgänglighet för SAP NetWeaver på Red Hat Enterprise Linux
SAP NetWeaver-konfiguration med flera SID för en klustrad SAP ASCS/SCS-instans
Multi-SID stöds med WSFC med hjälp av filresurs och delad disk.
Mer information om arkitektur med hög tillgänglighet med flera SID på Windows finns i:
Multi-SID-klustring stöds på Linux Pacemaker-kluster för SAP ASCS/ERS, begränsat till fem SAP SID i samma kluster. Mer information om arkitektur med hög tillgänglighet med flera SID i Linux finns i:
- Guide för hög hög användning för SAP NW på virtuella Azure-datorer på SLES för SAP-program med flera SID
- Guide för hög säkerhetsnivå för SAP NW på virtuella Azure-datorer på RHEL för SAP-program med flera SID
DBMS-instans med hög tillgänglighet
DBMS är också en enda kontaktpunkt i ett SAP-system. Du måste skydda den med hjälp av en lösning med hög tillgänglighet. Följande bild visar en SQL Server AlwaysOn-lösning med hög tillgänglighet i Azure, med Windows Server Failover Clustering (Redundansklustring för server) och azures interna lastbalanserare. SQL Server AlwaysOn replikerar DBMS-data och loggfiler med hjälp av en egen DBMS-replikering. I det här fallet behöver du inte en klusterdelade disk, vilket förenklar hela installationen.
Bild 3: Exempel på en SAP DBMS med hög tillgänglighet med SQL Server AlwaysOn
Mer information om hur du SQL Server DBMS i Azure med hjälp av Azure Resource Manager-distributionsmodellen finns i följande artiklar:
Mer information om klustring SAP HANA DBMS i Azure med hjälp av Azure Resource Manager-distributionsmodellen finns i Hög tillgänglighet för SAP HANA på virtuella Azure-datorer (VM).