SAP S/4HANA i Linux på Azure

Den här guiden visar en uppsättning beprövade metoder för att köra S/4HANA och Suite på HANA i en miljö med hög tillgänglighet som stöder haveriberedskap (DR) i Azure. Fiori-informationen gäller endast för S/4HANA-program.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Den här guiden beskriver ett vanligt produktionssystem. Den här arkitekturen distribueras med storlekar för virtuella datorer (VM) som du kan ändra för att uppfylla organisationens behov. För att passa dina affärsbehov kan du minska den här konfigurationen till en enda virtuell dator.

I den här guiden förenklas nätverkslayouten avsevärt för att demonstrera arkitekturprinciper. Det är inte avsett att beskriva ett fullständigt företagsnätverk.

Arkitekturen använder följande komponenter. Vissa delade tjänster är valfria.

Azure Virtual Network. Tjänsten Virtuellt nätverk ansluter på ett säkert sätt Azure-resurser till varandra. I den här arkitekturen ansluter ett virtuellt nätverk till en lokal miljö via en gateway som distribueras i hubben för en hubb-ekertopologi. Ekern är det virtuella nätverk som används för SAP-programmen och databasnivåerna.

Peering för virtuella nätverk. Den här arkitekturen använder flera virtuella nätverk som är peer-kopplade tillsammans. Den här topologin erbjuder nätverkssegmentering och isolering för tjänster som distribueras i Azure. Peering ansluter nätverk transparent via Microsofts stamnätverk och medför inte prestandastraff om det implementeras i en enda region. Separata undernät används för varje nivåprogram (SAP NetWeaver), databas och för delade tjänster, till exempel jump box och Windows Server Active Directory.

Vms. Den här arkitekturen använder virtuella datorer som kör Linux för programnivån och databasnivån, grupperade på följande sätt:

• Programnivå. Det här arkitekturlagret innehåller Fiori-klientdelsserverpoolen, SAP Web Dispatcher-poolen, programserverpoolen och SAP Central Services-klustret. För hög tillgänglighet för centrala tjänster på Azure som körs på virtuella Linux-datorer krävs en tjänst för nätverksfilresurser med hög tillgänglighet, till exempel NFS-filresurser i Azure Files, Azure NetApp Files, klustrade NFS-servrar (Network File System) eller SIOS Protection Suite för Linux. Om du vill konfigurera en filresurs med hög tillgänglighet för Central Services-klustret i Red Hat Enterprise Linux (RHEL) kan du konfigurera GlusterFS på virtuella Azure-datorer som kör RHEL. På SUSE Linux Enterprise Server (SLES) 15 SP1 och senare versioner eller SLES för SAP-program kan du använda delade Azure-diskar på ett Pacemaker-kluster för att uppnå hög tillgänglighet.

• SAP HANA. Databasnivån använder två eller flera virtuella Linux-datorer i ett kluster för att uppnå hög tillgänglighet i en uppskalningsdistribution. HANA-systemreplikering (HSR) används för att replikera innehåll mellan primära och sekundära HANA-system. Linux-klustring används för att identifiera systemfel och underlätta automatisk redundans. En lagringsbaserad eller molnbaserad fäktningsmekanism måste användas för att säkerställa att det misslyckade systemet isoleras eller stängs av för att undvika klustrets split-brain-tillstånd. I HANA-utskalningsdistributioner kan du uppnå hög tillgänglighet för databasen med något av följande alternativ:

  • Konfigurera HANA-väntelägesnoder med hjälp av Azure NetApp Files utan Linux-klustringskomponenten.
  • Skala ut utan väntelägesnoder med hjälp av Azure Premium Storage. Använd Linux-kluster för redundans.

• Azure Bastion. Med den här tjänsten kan du ansluta till en virtuell dator med hjälp av webbläsaren och Azure-portalen, eller via den interna SSH- eller RDP-klienten som redan är installerad på den lokala datorn. Om endast RDP och SSH används för administration är Azure Bastion en bra lösning. Om du använder andra hanteringsverktyg, till exempel SQL Server Management Studio eller en SAP-klientdel, använder du en traditionell självdistribuerad hopplåda.

Privat DNS tjänst.Azure Privat DNS tillhandahåller en tillförlitlig och säker DNS-tjänst för ditt virtuella nätverk. Azure Privat DNS hanterar och löser domännamn i det virtuella nätverket utan att behöva konfigurera en anpassad DNS-lösning.

Lastbalanserare. Om du vill distribuera trafik till virtuella datorer i SAP-programnivåundernätet för hög tillgänglighet rekommenderar vi att du använder Azure Standard Load Balancer. Observera att Standard Load Balancer tillhandahåller ett säkerhetslager som standard. Virtuella datorer som ligger bakom Standard Load Balancer har inte utgående internetanslutning. Om du vill aktivera utgående Internet på de virtuella datorerna måste du uppdatera standardkonfigurationen för lastbalanseraren. Du kan också använda Azure NAT Gateway för att få utgående anslutning. För hög tillgänglighet för SAP-webbaserade program använder du den inbyggda SAP Web Dispatcher eller en annan kommersiellt tillgänglig lastbalanserare. Basera ditt val på:

• Din trafiktyp, till exempel HTTP eller SAP GUI.
• De nätverkstjänster som du behöver, till exempel SSL-avslutning (Secure Sockets Layer).

Standard Load Balancer stöder flera virtuella IP-adresser på klientsidan. Det här stödet är idealiskt för klusterimplementeringar som innehåller följande komponenter:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Enqueue Replication Server (ERS)

Dessa två komponenter kan dela en lastbalanserare för att förenkla lösningen.

Standard Load Balancer stöder även SAP-kluster med flera systemidentifierare (multi-SID). Med andra ord kan flera SAP-system på SLES eller RHEL dela en gemensam infrastruktur med hög tillgänglighet för att minska kostnaderna. Vi rekommenderar att du utvärderar kostnadsbesparingarna och undviker att placera för många system i ett kluster. Azure stöder högst fem SID per kluster.

Programgateway. Azure Application Gateway är en lastbalanserare för webbtrafik som du kan använda för att hantera trafiken till dina webbprogram. Traditionella lastbalanserare fungerar på transportskiktet (OSI-lager 4 – TCP och UDP). De dirigerar trafik baserat på källans IP-adress och port till en mål-IP-adress och port. Application Gateway kan fatta routningsbeslut baserat på ytterligare attribut för en HTTP-begäran, till exempel URI-sökvägen eller värdhuvuden. Den här typen av routning kallas belastningsutjämning för programlager (OSI lager 7). S/4HANA erbjuder webbprogramtjänster via Fiori. Du kan belastningsutjämning den här Fiori-klientdelen, som består av webbappar, med hjälp av Application Gateway.

Gateway. En gateway ansluter distinkta nätverk och utökar ditt lokala nätverk till ett virtuellt Azure-nätverk. Azure ExpressRoute är den rekommenderade Azure-tjänsten för att skapa privata anslutningar som inte går via det offentliga Internet, men du kan också använda en plats-till-plats-anslutning . För att minska svarstiden är ExpressRoute Global Reach och ExpressRoute FastPath anslutningsalternativ som beskrivs senare i den här artikeln.

Zonredundant gateway. Du kan distribuera ExpressRoute- eller VPN-gatewayer över zoner för att skydda mot zonfel. Den här arkitekturen använder zonredundanta virtuella nätverksgatewayer för återhämtning i stället för en zonindelad distribution som baseras på samma tillgänglighetszon.

Närhetsplaceringsgrupp. Den här logiska gruppen lägger en begränsning på virtuella datorer som distribueras i en tillgänglighetsuppsättning eller en VM-skalningsuppsättning. En närhetsplaceringsgrupp föredrar samplacering, vilket placerar virtuella datorer i samma datacenter för att minimera programfördröjningen.

Nätverkssäkerhetsgrupper. Om du vill begränsa inkommande, utgående och intraundernätstrafik i ett virtuellt nätverk kan du skapa nätverkssäkerhetsgrupper.

Programsäkerhetsgrupper. Om du vill definiera detaljerade nätverkssäkerhetsprinciper som baseras på arbetsbelastningar och är centrerad på program använder du programsäkerhetsgrupper i stället för explicita IP-adresser. Du kan gruppera virtuella datorer efter namn och säkra program genom att filtrera trafik från betrodda segment i nätverket.

Azure Storage. Lagring ger datapersistence för en virtuell dator i form av en virtuell hårddisk. Vi rekommenderar Azure-hanterade diskar.

Rekommendationer

Den här arkitekturen beskriver en liten distribution på produktionsnivå. Distributionerna varierar beroende på affärskrav, så tänk på de här rekommendationerna som utgångspunkt.

Virtuella datorer

I programserverpooler och kluster justerar du antalet virtuella datorer baserat på dina krav. Detaljerad information om hur du kör SAP NetWeaver på virtuella datorer finns i planerings- och implementeringsguiden för Azure Virtual Machines. Guiden gäller även för SAP S/4HANA-distributioner.

Mer information om SAP-stöd för typer av virtuella Azure-datorer och dataflödesmått (SAPS) finns i SAP Note 1928533. För att få åtkomst till SAP-anteckningar behöver du ett SAP Service Marketplace-konto. En lista över certifierade virtuella Azure-datorer för HANA-databasen finns i SAP Certified and Supported SAP HANA Hardware Directory (SAP Certified and Supported SAP HANA Hardware Directory).

SAP Web Dispatcher

Komponenten Web Dispatcher används för belastningsutjämning av SAP-trafik mellan SAP-programservrarna. För att uppnå hög tillgänglighet för SAP Web Dispatcher implementerar Azure Load Balancer antingen ett redundanskluster eller en parallell web dispatcher-konfiguration. För internetuppkopplad kommunikation är en fristående lösning i perimeternätverket den rekommenderade arkitekturen för att uppfylla säkerhetsproblem. Embedded Web Dispatcher på ASCS är ett speciellt alternativ. Om du använder det här alternativet bör du överväga lämplig storleksändring på grund av den extra arbetsbelastningen på ASCS.

Fiori-klientdelsserver (FES)

Den här arkitekturen uppfyller många krav och förutsätter att den inbäddade Fiori FES-modellen används. Alla teknikkomponenter installeras på själva S/4-systemet, vilket innebär att varje S/4-system har en egen Fiori-startplatta. Konfigurationen av hög tillgänglighet för den här distributionsmodellen är S/4-systemets– inga extra kluster eller virtuella datorer krävs. Därför visar arkitekturdiagrammet inte FES-komponenten.

En beskrivning av de primära distributionsalternativen – antingen inbäddade eller hubb, beroende på scenarier – finns i SAP Fiori-distributionsalternativ och systemlandskapsrekommendationer. För enkelhetens skull och prestanda är programvaruversionerna mellan Fiori-teknikkomponenterna och S/4-programmen tätt kopplade. Den här konfigurationen gör en hubbdistribution som bara passar några få, smala användningsfall.

Om du använder FES Hub-distributionen är FES en tilläggskomponent till den klassiska SAP NetWeaver ABAP-stacken. Konfigurera hög tillgänglighet på samma sätt som du skyddar en ABAP-programstack med tre nivåer som har klustrad eller flera värdfunktioner: använd ett väntelägesserverdatabaslager, ett klustrat ASCS-lager med NFS med hög tillgänglighet för delad lagring och minst två programservrar. Trafiken lastbalanseras via ett par Web Dispatcher-instanser som kan vara antingen klustrade eller parallella. För Internetuppkopplade Fiori-appar rekommenderar vi en FES-hubbdistribution i perimeternätverket. Använd Azure Web Application Firewall på Application Gateway som en kritisk komponent för att avleda hot. Använd Microsoft Entra ID med SAML för användarautentisering och enkel inloggning för SAP Fiori.

Vissa internetuppkopplade designexempel för inkommande/utgående trafik finns i Inkommande och utgående Internetanslutningar för SAP i Azure.

Pool för programservrar

För att hantera inloggningsgrupper för ABAP-programservrar är det vanligt att använda SMLG-transaktionen för att lastbalansera inloggningsanvändare, använda SM61 för batchservergrupper, använda RZ12 för RFC-grupper (remote function call) och så vidare. Dessa transaktioner använder den belastningsutjämningsfunktion som finns i centraltjänstmeddelandeservern för att distribuera inkommande sessioner eller arbetsbelastningar mellan poolen med SAP-programservrar som hanterar SAP GUIs och RFC-trafik.

SAP Central Services-kluster

Du kan distribuera Central Services till en enskild virtuell dator när serviceavtalet för azure-tillgänglighet på en instans (SLA) uppfyller dina krav. Den virtuella datorn blir dock en potentiell enskild felpunkt (SPOF) för SAP-miljön. För en central tjänstdistribution med hög tillgänglighet använder du antingen NFS via Azure Files eller Azure NetApp Files-tjänsten och ett Central Services-kluster.

Ett annat alternativ är att använda delade Azure-diskar för att uppnå hög tillgänglighet. På SLES 15 SP1 och senare eller SLES för SAP-program kan du konfigurera ett Pacemaker-kluster med hjälp av Delade Azure-diskar för Linux.

Alternativt kan du använda en NFS-filresurs för det delade Linux-klustrets lagring.

I en Azure-distribution ansluter programservrarna till centraltjänsterna med hög tillgänglighet via de virtuella värdnamnen för Central Services- eller ERS-tjänsterna. Dessa värdnamn tilldelas till klusterklientdelens IP-konfiguration för lastbalanseraren. Load Balancer har stöd för flera ip-adresser på klientdelen, så både de virtuella IP-adresserna för Central Services och ERS kan konfigureras till en lastbalanserare.

Linux-klusterstöd för ASCS-installation med flera SID på Azure är nu allmänt tillgängligt. Att dela ett tillgänglighetskluster mellan flera SAP-system förenklar SAP-liggande.

Nätverk

Den här arkitekturen använder en topologi med nav-ekrar, där det virtuella hubbnätverket fungerar som en central anslutningspunkt till ett lokalt nätverk. Ekrarna är virtuella nätverk som peerkopplas med hubben. Du kan använda ekrarna för att isolera arbetsbelastningar. Trafik flödar mellan det lokala datacentret och hubben via en gatewayanslutning.

Nätverkskort (NÄTVERKSKORT)

Traditionella lokala SAP-distributioner implementerar flera nätverkskort per dator för att skilja administrativ trafik från företagstrafik. I Azure är det virtuella nätverket ett programvarudefinierat nätverk som skickar all trafik via samma nätverksinfrastruktur. Därför är det inte nödvändigt att använda flera nätverkskort för prestandaöverväganden. Men om din organisation behöver separera trafik kan du distribuera flera nätverkskort per virtuell dator, ansluta varje nätverkskort till ett annat undernät och sedan använda nätverkssäkerhetsgrupper för att tillämpa olika principer för åtkomstkontroll.

Azure NIC stöder flera IP-adresser. Det här stödet överensstämmer med den praxis som SAP rekommenderar att du använder virtuella värdnamn för installationer, enligt beskrivningen i SAP-962955. För att få åtkomst till SAP-anteckningar behöver du ett SAP Service Marketplace-konto.

Undernät och nätverkssäkerhetsgrupper

Den här arkitekturen delar upp adressutrymmet för det virtuella nätverket i undernät. Du kan associera varje undernät med en nätverkssäkerhetsgrupp som definierar åtkomstprinciperna för undernätet. Placera programservrar i ett separat undernät. På så sätt kan du skydda dem enklare genom att hantera säkerhetsprinciperna för undernätet i stället för de enskilda servrarna.

När du associerar en nätverkssäkerhetsgrupp med ett undernät gäller nätverkssäkerhetsgruppen för alla servrar i undernätet och ger detaljerad kontroll över servrarna. Konfigurera nätverkssäkerhetsgrupper med hjälp av Azure-portalen, PowerShell eller Azure CLI.

ExpressRoute Global Reach

Om din nätverksmiljö innehåller två eller flera ExpressRoute-kretsar kan ExpressRoute Global Reach hjälpa dig att minska nätverkshopp och kortare svarstid. Den här tekniken är en BGP-routningspeering (Border Gateway Protocol) som konfigureras mellan två eller flera ExpressRoute-kretsar för att överbrygga två ExpressRoute-routningsdomäner. Global Reach sänker svarstiden när nätverkstrafiken passerar mer än en ExpressRoute-krets. Den är för närvarande endast tillgänglig för privat peering på ExpressRoute-kretsar.

För närvarande finns det inga listor över nätverksåtkomstkontroll eller andra attribut som kan ändras i Global Reach. Därför annonseras alla vägar som har lärts av en viss ExpressRoute-krets (från lokal plats och Azure) över kretsens peering till den andra ExpressRoute-kretsen. Vi rekommenderar att du etablerar filtrering av nätverkstrafik lokalt för att begränsa åtkomsten till resurser.

ExpressRoute FastPath

FastPath implementerar Microsoft Edge-utbyten vid startpunkten för Azure-nätverket. FastPath minskar nätverkshopp för de flesta datapaket. Därför sänker FastPath nätverksfördröjningen, förbättrar programmets prestanda och är standardkonfigurationen för nya ExpressRoute-anslutningar till Azure.

För befintliga ExpressRoute-kretsar kontaktar du Azure-supporten för att aktivera FastPath.

FastPath stöder inte peering för virtuella nätverk. Om andra virtuella nätverk är peerkopplade med ett som är anslutet till ExpressRoute skickas nätverkstrafiken från ditt lokala nätverk till de andra virtuella ekernätverken till den virtuella nätverksgatewayen. Lösningen är att ansluta alla virtuella nätverk till ExpressRoute-kretsen direkt.

lastbalanserare

SAP Web Dispatcher hanterar belastningsutjämning av HTTP-trafik (S) till en pool med SAP-programservrar. Den här programvarulastbalanseraren erbjuder tjänster på programnivå (kallas layer 7 i ISO-nätverksmodellen) som kan avsluta SSL och andra avlastningsfunktioner.

Load Balancer är en tjänst för nätverksöverföringslager (lager 4) som balanserar trafiken med hjälp av en hash med fem tupplar från dataströmmar. Hashen baseras på käll-IP, källport, mål-IP, målport och protokolltyp. Load Balancer används i klusterkonfigurationer för att dirigera trafik till den primära tjänstinstansen eller den felfria noden om det finns ett fel. Vi rekommenderar att du använder Azure Standard Load Balancer för alla SAP-scenarier. Observera att Standard Load Balancer är säkert som standard och att inga virtuella datorer bakom Standard Load Balancer har utgående internetanslutning. Om du vill aktivera utgående Internet på de virtuella datorerna måste du justera standardkonfigurationen för lastbalanseraren .

För trafik från SAP GUI-klienter som ansluter till en SAP-server via DIAG-protokollet eller RFC balanserar centraltjänstmeddelandeservern belastningen via SAP-programserverns inloggningsgrupper. Ingen extra lastbalanserare behövs.

Lagring

Vissa kunder använder standardlagring för sina programservrar. Eftersom standardhanterade diskar inte stöds, som anges i SAP-1928533, rekommenderar vi att du använder Premium Azure-hanterade diskar eller Azure NetApp Files i alla fall. En ny uppdatering av SAP-anteckningen 2015553 exkluderar användningen av standard hdd-lagring och standard-SSD-lagring för några specifika användningsfall.

Eftersom programservrar inte är värdar för några affärsdata kan du också använda de mindre P4- och P6 Premium-diskarna för att hantera kostnader. Information om hur lagringstypen påverkar serviceavtalet för vm-tillgänglighet finns i Serviceavtal för virtuella datorer. För scenarier med hög tillgänglighet är funktioner för delade Azure-diskar tillgängliga på Azure Premium SSD och Azure Ultra Disk Storage. Mer information finns i Hanterade Azure-diskar.

Du kan använda delade Azure-diskar med Windows Server, SLES 15 SP 1 och senare eller SLES för SAP. När du använder en Delad Azure-disk i Linux-kluster fungerar den delade Azure-disken som en STONITH-blockenhet (SBD). Det erbjuder en kvorumröstning i en partitioneringssituation för klusternätverk. Den här delade disken har inget filsystem och stöder inte samtidiga skrivningar från flera virtuella klustermedlemsdatorer.

Azure NetApp Files har inbyggda fildelningsfunktioner för NFS och SMB.

För NFS-resursscenarier tillhandahåller Azure NetApp Files tillgänglighet för NFS-resurser som kan användas för /hana/shared, /hana/dataoch /hana/log volymer. Tillgänglighetsgarantin finns i SLA för Azure NetApp Files. Om du använder Azure NetApp Files-baserade NFS-resurser för /hana/data volymerna och /hana/log måste du använda NFS v4.1-protokollet. /hana/shared För volymen stöds NFS v3-protokollet.

För datalagret för säkerhetskopiering rekommenderar vi att du använder lågfrekvent åtkomstnivå i Azure och arkiverar åtkomstnivåer. Dessa lagringsnivåer är kostnadseffektiva sätt att lagra långlivade data som används sällan. Du kan också överväga att använda standardnivån Azure NetApp Files som säkerhetskopieringsmål eller säkerhetskopieringsalternativ för Azure NetApp Files. För en hanterad disk är den rekommenderade nivån för säkerhetskopieringsdata azure-lågfrekvent eller arkivåtkomstnivå.

Ultra Disk Storage och Azure NetApp Files ultraprestandanivå minskar avsevärt diskfördröjningen och gynnar prestandakritiska program och SAP-databasservrarna.

Azure Premium SSD v2 är utformat för prestandakritiska arbetsbelastningar som SAP. Se Distribuera en Premium SSD v2 för information om den här lagringslösningens fördelar och dess aktuella begränsningar.

Prestandaöverväganden

SAP-programservrar kommunicerar ständigt med databasservrarna. För prestandakritiska program som körs på valfri databasplattform, inklusive SAP HANA, aktiverar du Write Accelerator för loggvolymen om du använder Premium SSD v1. Detta kan förbättra svarstiden för loggskrivning. Premium SSD v2 använder inte skrivaccelerator. Skrivacceleratorn är tillgänglig för virtuella datorer i M-serien.

Om du vill optimera kommunikation mellan servrar använder du accelererat nätverk. De flesta generell användning och beräkningsoptimerade VM-instansstorlekar som har två eller flera vCPU:er har stöd för accelererat nätverk. På instanser som stöder hypertrådning stöder virtuella datorinstanser med fyra eller fler vCPU:er accelererat nätverk.

Mer information om prestandakrav för SAP HANA finns i SAP-anmärkning 1943937 – Kontrollverktyg för maskinvarukonfiguration. För att få åtkomst till SAP-anteckningar behöver du ett SAP Service Marketplace-konto.

För att uppnå högt dataflöde för IOPS och diskbandbredd gäller de vanliga metoderna för prestandaoptimering av lagringsvolymer för din lagringslayout. Om du till exempel kombinerar flera diskar för att skapa en randig diskvolym kan du förbättra I/O-prestanda. Genom att aktivera läscachen på lagringsinnehåll som ändras sällan kan du öka hastigheten för datahämtning. Rekommendationer om lagringskonfigurationer för olika VM-storlekar när du kör SAP HANA finns i LAGRINGskonfigurationer för virtuella SAP HANA Azure-datorer.

Azure Premium SSD v2 är utformat för prestandakritiska arbetsbelastningar som SAP. Se Azure-hanterade disktyper för att lära dig mer om dess fördelar och begränsningar och optimala användningsscenarier.

Ultra Disk Storage är en ny generation lagring som uppfyller intensiva IOPS och kraven på överföringsbandbredd för program som SAP HANA. Du kan dynamiskt ändra prestanda för ultradiskar och oberoende konfigurera mått som IOPS och MB/s utan att starta om den virtuella datorn. När Ultra Disk Storage är tillgängligt rekommenderar vi Ultra Disk Storage i stället för skrivningsaccelerator.

Vissa SAP-program kräver frekvent kommunikation med databasen. Nätverksfördröjning mellan program- och databasskikten kan på grund av avstånd påverka programmets prestanda negativt. Närhetsplaceringsgrupper i Azure anger en placeringsbegränsning för virtuella datorer som distribueras i tillgänglighetsuppsättningar. I den logiska konstruktionen för en grupp prioriteras samplats och prestanda framför skalbarhet, tillgänglighet och kostnad. Närhetsplaceringsgrupper kan avsevärt förbättra användarupplevelsen för de flesta SAP-program. Skript och verktyg som är tillgängliga på GitHub för närhetsplaceringsgrupper finns i Azure Närhetsplaceringsgrupper.

Placeringen av en virtuell nätverksinstallation (NVA) mellan programmet och databasskikten i en SAP-programstack stöds inte. NVA kräver en betydande tid för att bearbeta datapaket. Det innebär att programmets prestanda blir oacceptabelt långsammare.

Vi rekommenderar också att du överväger prestanda när du distribuerar resurser med tillgänglighetszoner, vilket kan förbättra tjänstens tillgänglighet, enligt beskrivningen senare i den här artikeln. Överväg att skapa en tydlig nätverksfördröjningsprofil mellan alla zoner i en målregion. Den här metoden hjälper dig att bestämma resursplacering för minsta svarstid mellan zoner. Om du vill skapa den här profilen kör du ett test genom att distribuera små virtuella datorer i varje zon. Rekommenderade verktyg för testet är PsPing och Iperf. Ta bort de här virtuella datorerna efter testningen. Ett testverktyg för svarstid för offentliga domäner som du kan använda i stället finns i Svarstidstest för tillgänglighetszon.

Azure NetApp Files har unika prestandafunktioner som möjliggör realtidsjustering som uppfyller behoven i de mest krävande SAP-miljöerna. Prestandaöverväganden att tänka på när du använder Azure NetApp Files finns i Storlek för HANA-databas i Azure NetApp Files.

Skalbarhetsöverväganden

På SAP-programskiktet erbjuder Azure ett brett utbud av VM-storlekar för att skala upp och skala ut. En inkluderande lista finns i "SAP-program på Azure: Produkter som stöds och typer av virtuella Azure-datorer" i SAP Note 1928533. För att få åtkomst till SAP-anteckningar behöver du ett SAP Service Marketplace-konto. Fler typer av virtuella datorer certifieras kontinuerligt, så du kan skala upp eller ned i samma molndistribution.

På databasskiktet kör den här arkitekturen SAP HANA S/4-program på virtuella Azure-datorer som kan skala upp till 24 terabyte (TB) i en instans. Om din arbetsbelastning överskrider den maximala VM-storleken kan du använda en konfiguration med flera noder för så mycket som 96 TBs (4 x 24) för OLTP-program (onlinetransaktionsbearbetning). Mer information finns i Certifierad och stödd SAP HANA-maskinvarukatalog.

Överväganden för tillgänglighet

Resursredundans är det allmänna temat i infrastrukturlösningar med hög tillgänglighet. Serviceavtal för tillgänglighet för virtuella datorer med en instans för olika lagringstyper finns i Serviceavtal för virtuella datorer. Om du vill öka tjänsttillgängligheten i Azure distribuerar du VM-resurser med vm-skalningsuppsättningar med flexibel orkestrering, tillgänglighetszoner eller tillgänglighetsuppsättningar.

I den här distribuerade installationen av SAP-programmet replikeras basinstallationen för att uppnå hög tillgänglighet. För varje lager i arkitekturen varierar designen för hög tillgänglighet.

Distributionsmetoder

I Azure kan SAP-arbetsbelastningsdistributionen vara antingen regional eller zonindelad, beroende på kraven på tillgänglighet och återhämtning i SAP-programmen. Azure tillhandahåller olika distributionsalternativ, till exempel VM-skalningsuppsättningar med flexibel orkestrering (FD=1), tillgänglighetszoner och tillgänglighetsuppsättningar, för att förbättra resursernas tillgänglighet. Information om tillgängliga distributionsalternativ och deras tillämplighet i olika Azure-regioner (inklusive mellan zoner, inom en enda zon eller i en region utan zoner) finns i Arkitektur och scenarier med hög tillgänglighet för SAP NetWeaver.

Web Dispatcher på programservernivån

Du kan uppnå hög tillgänglighet med hjälp av redundanta Web Dispatcher-instanser. Mer information finns i SAP Web Dispatcher i SAP-dokumentationen. Tillgänglighetsnivån beror på storleken på programmet som finns bakom Web Dispatcher. I små distributioner med få skalbarhetsproblem kan du samplacerar Web Dispatcher med de virtuella ASCS-datorerna. På så sätt sparar du på oberoende operativsystemunderhåll och får hög tillgänglighet på samma gång.

Centrala tjänster på programservernivån

För hög tillgänglighet för centrala tjänster på virtuella Azure Linux-datorer använder du lämpligt tillägg för hög tillgänglighet för den valda Linux-distributionen. Det är vanligt att placera de delade filsystemen på NFS-lagring med hög tillgänglighet med hjälp av SUSE DRBD eller Red Hat GlusterFS. För att tillhandahålla en NFS med hög tillgänglighet och eliminera behovet av ett NFS-kluster kan du använda andra kostnadseffektiva eller robusta lösningar som NFS via Azure Files eller Azure NetApp Files i stället. Som en sidoanteckning kan Azure NetApp Files-resurser vara värd för SAP HANA-data och loggfiler. Den här konfigurationen möjliggör utskalningsdistributionsmodellen HANA med väntelägesnoder, medan NFS över Azure Files är bra för fildelning som inte är databasbaserad med hög tillgänglighet.

NFS över Azure Files har nu stöd för filresurser med hög tillgänglighet för både SLES och RHEL. Den här lösningen fungerar bra för filresurser med hög tillgänglighet, till exempel /sapmnti , /saptrans i SAP-installationer.

Azure NetApp Files stöder hög tillgänglighet för ASCS på SLES. Detaljerad information om HÖG tillgänglighet för ASCS på RHEL finns i SIOS Protection Suite för Linux.

Den förbättrade Azure Fence Agent är tillgänglig för både SUSE och Red Hat och ger betydligt snabbare tjänstredundans än den tidigare versionen av agenten.

Ett annat alternativ är att använda delade Azure-diskar för att uppnå hög tillgänglighet. På SLES 15 SP 1 och senare eller SLES för SAP kan du konfigurera ett Pacemaker-kluster med hjälp av delade Azure-diskar för att uppnå hög tillgänglighet.

På Azure Standard Load Balancer kan du aktivera porten med hög tillgänglighet och undvika behovet av att konfigurera belastningsutjämningsregler för många SAP-portar. Om du aktiverar funktionen för direktserverretur (DSR) när du konfigurerar en lastbalanserare kan serversvar på klientförfrågningar kringgå lastbalanseraren. Den här funktionen kallas även flytande IP. Lastbalanseraren kan vara lokal eller i Azure. Den här direktanslutningen gör att lastbalanseraren inte blir flaskhalsen i dataöverföringens sökväg. För ASCS- och HANA DB-kluster rekommenderar vi att du aktiverar DSR. Om virtuella datorer i serverdelspoolen kräver offentlig utgående anslutning krävs mer konfiguration .

För trafik från SAP GUI-klienter som ansluter till en SAP-server via DIAG-protokollet eller RFC balanserar meddelandeservern för Central Services belastningen med hjälp av SAP-programserverns inloggningsgrupper. Ingen extra lastbalanserare behövs.

Programservrar på programservernivån

Du kan uppnå hög tillgänglighet genom att belastningsutjämning av trafik i en pool med programservrar.

ASCS-nivå

Precis som med programserverlagret är den ofta distribuerade HANA-lösningen med hög tillgänglighet för Linux Pacemaker.

Databasnivå

Arkitekturen i den här guiden visar ett SAP HANA-databassystem med hög tillgänglighet som består av två virtuella Azure-datorer. Den interna funktionen för systemreplikering på databasnivån ger antingen manuell eller automatisk redundans mellan replikerade noder:

• För manuell redundans distribuerar du mer än en HANA-instans och använder HSR.
• För automatisk redundans använder du både HSR- och Linux-tillägg med hög tillgänglighet (HAE) för din Linux-distribution. Linux HAE tillhandahåller klustertjänsterna till HANA-resurserna, identifierar felhändelser och samordnar redundansen av felaktiga tjänster till den felfria noden.

Distribuera virtuella datorer mellan tillgänglighetszoner

Tillgänglighetszoner kan förbättra tjänstens tillgänglighet. Zoner refererar till fysiskt avgränsade platser i en specifik Azure-region. De förbättrar tillgängligheten för arbetsbelastningen och skyddar programtjänster och virtuella datorer mot datacenterstopp. Virtuella datorer i en enda zon behandlas som om de fanns i en enda uppdaterings- eller feldomän. När zonindelad distribution väljs distribueras virtuella datorer i samma zon till fel- och uppgraderingsdomäner på bästa sätt.

I Azure-regioner som stöder den här funktionen är minst tre zoner tillgängliga. Det maximala avståndet mellan datacenter i dessa zoner är dock inte garanterat. Om du vill distribuera ett SAP-system med flera nivåer mellan zoner måste du känna till nätverksfördröjningen i en zon och mellan målzoner och hur känsliga dina distribuerade program är för nätverksfördröjning.

Ta hänsyn till dessa överväganden när du bestämmer dig för att distribuera resurser mellan tillgänglighetszoner :

• Svarstid mellan virtuella datorer i en zon
• Svarstid mellan virtuella datorer mellan valda zoner
• Tillgänglighet för samma Azure-tjänster (VM-typer) i de valda zonerna

Exempel på aktiv/passiv distribution

I den här exempeldistributionen refererar statusen aktiv/passiv till programtjänsttillståndet i zonerna. I programskiktet finns alla fyra aktiva programservrarna i SAP-systemet i zon 1. En annan uppsättning med fyra passiva programservrar är inbyggd i zon 2 men stängs av. De aktiveras bara när de behövs.

Kluster med två noder för Central Services och databasen sträcker sig över två zoner. Om zon 1 misslyckas körs centraltjänster och databastjänster i zon 2. De passiva programservrarna i zon 2 aktiveras. Med alla komponenter i det här SAP-systemet i samma zon minimeras nätverksfördröjningen.

Exempel på aktiv/aktiv distribution

I en aktiv/aktiv distribution skapas två uppsättningar programservrar i två zoner. I varje zon är två programservrar i varje uppsättning inaktiva eller avstängda. Det innebär att det finns aktiva programservrar i båda zonerna i normal drift.

ASCS- och databastjänsterna körs i zon 1. Programservrarna i zon 2 kan ha längre nätverksfördröjning när de ansluter till ASCS- och databastjänsterna på grund av det fysiska avståndet mellan zoner.

Om zon 1 går offline redundansväxlar ASCS- och databastjänsterna till zon 2. De vilande programservrarna kan anslutas online för att ge fullständig kapacitet för programbearbetning.

DR-överväganden

Varje nivå i SAP-programstacken använder en annan metod för att tillhandahålla DR-skydd. Information om dr-strategier och implementering finns i Översikt över haveriberedskap och riktlinjer för infrastruktur för SAP-arbetsbelastningar och riktlinjer för haveriberedskap för SAP-program.

Kostnadsöverväganden

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure.

Mer information finns i kostnadsavsnittet i Microsoft Azures välstrukturerade ramverk.

Virtuella datorer

Den här arkitekturen använder virtuella datorer som kör Linux för hanterings-, SAP-program- och databasnivåerna.

Det finns flera betalningsalternativ för virtuella datorer i allmänhet:

• För arbetsbelastningar utan förutsägbar tid för slutförande eller resursförbrukning bör du överväga alternativet betala per användning.

• Överväg att använda Azure-reservationer om du kan checka in på att använda en virtuell dator under ett eller tre år. Vm-reservationer kan avsevärt minska kostnaderna. Du kan betala så lite som 72 procent av kostnaden för en betala per användning-tjänst.

• Använd virtuella Azure-datorer för oanvänd kapacitet för att köra arbetsbelastningar som kan avbrytas och som inte kräver slutförande inom en fördefinierad tidsram eller ett serviceavtal. Azure distribuerar virtuella datorer med oanvänd kapacitet när det finns tillgänglig kapacitet och avlägsnar dem när de behöver kapaciteten tillbaka. Kostnader som är associerade med virtuella datorer med oanvänd kapacitet är lägre än för andra virtuella datorer. Överväg virtuella datorer med oanvänd kapacitet för dessa arbetsbelastningar:

  • Scenarier för databehandling med höga prestanda, batchbearbetningsjobb eller visuella renderingsprogram
  • Testmiljöer, inklusive kontinuerlig integrering och arbetsbelastningar för kontinuerlig leverans
  • Storskaliga tillståndslösa program

• Azure Reserved Virtual Machine Instances kan minska din totala ägandekostnad genom att kombinera priser för Azure Reserved Virtual Machine Instances med en betala per användning-prenumeration så att du kan hantera kostnader för förutsägbara och variabla arbetsbelastningar. Mer information om det här erbjudandet finns i Azure Reserved Virtual Machine Instances (Azure Reserved Virtual Machine Instances).

En översikt över priser finns i Prissättning för virtuella Linux-datorer.

Load Balancer

I det här scenariot används Azure-lastbalanserare för att distribuera trafik till virtuella datorer i undernätet på programnivå.

Du debiteras endast för antalet konfigurerade regler för belastningsutjämning och utgående trafik. REGLER för inkommande nätverksadressöversättning (NAT) är kostnadsfria. Det debiteras ingen timavgift för Standard Load Balancer när inga regler har konfigurerats.

ExpressRoute

I den här arkitekturen är ExpressRoute den nätverkstjänst som används för att skapa privata anslutningar mellan ett lokalt nätverk och virtuella Azure-nätverk.

All inkommande dataöverföring är kostnadsfri. All utgående dataöverföring debiteras baserat på en fördefinierad hastighet. Mer information finns i Prissättning för Azure ExpressRoute.

Hanterings- och driftöverväganden

Tänk på följande för att hålla systemet igång i produktion.

Azure Center for SAP solutions

Azure Center for SAP solutions är en lösning från slutpunkt till slutpunkt som gör att du kan skapa och köra SAP-system som en enhetlig arbetsbelastning i Azure och som ger en smidigare grund för innovation. Dessutom skapar den guidade distributionsupplevelsen för Azure Center for SAP-lösningar de nödvändiga komponenterna för beräkning, lagring och nätverk som du behöver för att köra SAP-systemet. Det hjälper dig sedan att automatisera installationen av SAP-programvaran enligt Microsofts metodtips. Du kan dra nytta av hanteringsfunktionerna för både nya och befintliga Azure-baserade SAP-system. Mer information finns i Azure Center for SAP-lösningar.

Backup

Du kan säkerhetskopiera SAP HANA-data på många sätt. När du har migrerat till Azure fortsätter du att använda befintliga säkerhetskopieringslösningar som du har. Azure tillhandahåller två inbyggda metoder för säkerhetskopiering. Du kan säkerhetskopiera SAP HANA på virtuella datorer eller använda Azure Backup på filnivå. Azure Backup är BackInt-certifierat av SAP. Mer information finns i Vanliga frågor och svar om Azure Backup och supportmatris för säkerhetskopiering av SAP HANA-databaser på virtuella Azure-datorer.

Identitetshantering

Använd ett centraliserat identitetshanteringssystem för att styra åtkomsten till resurser på alla nivåer:

• Ge åtkomst till Azure-resurser via rollbaserad åtkomstkontroll i Azure (Azure RBAC).

• Bevilja åtkomst till virtuella Azure-datorer via Lightweight Directory Access Protocol (LDAP), Microsoft Entra ID, Kerberos eller något annat system.

• Stöd för åtkomst i själva apparna via de tjänster som SAP tillhandahåller, eller använd OAuth 2.0 och Microsoft Entra ID.

Övervakning

För att maximera tillgängligheten och prestandan för program och tjänster i Azure använder du Azure Monitor, en omfattande lösning för att samla in, analysera och agera på telemetri från dina molnmiljöer och lokala miljöer. Azure Monitor visar hur program presterar och identifierar proaktivt problem som påverkar dem och de resurser som de är beroende av. För SAP-program som körs på SAP HANA och andra större databaslösningar, se Azure Monitor for SAP-lösningar för att lära dig hur Azure Monitor för SAP kan hjälpa dig att hantera tillgänglighet och prestanda för SAP-tjänster.

Säkerhetsfrågor

SAP har en egen användarhanteringsmotor (UME) för att styra rollbaserad åtkomst och auktorisering i SAP-programmet och databaserna. Mer information finns i SAP HANA Security: En översikt.

För att förbättra nätverkssäkerheten bör du överväga att använda ett perimeternätverk som använder en NVA för att skapa en brandvägg framför undernätet för Web Dispatcher och Fiori-klientdelsserverpoolerna. Kostnaden för dataöverföring är en anledning till att placera aktiva klientdelsservrar som kör Fiori-appar i samma virtuella nätverk som S/4-systemen. Alternativet är att placera dem i perimeternätverket och ansluta dem till S/4 via en virtuell nätverkspeering.

För infrastruktursäkerhet krypteras data under överföring och i vila. Avsnittet "Säkerhetsöverväganden" i SAP NetWeaver på Azure Virtual Machines – Planerings- och implementeringsguiden innehåller information om nätverkssäkerhet som gäller för S/4HANA. Den guiden anger också de nätverksportar som ska öppnas i brandväggarna för att tillåta programkommunikation.

För att kryptera virtuella Linux-diskar har du olika alternativ, enligt beskrivningen i Översikt över diskkryptering. För SAP HANA-kryptering med vilande data rekommenderar vi att du använder den inbyggda SAP HANA-krypteringstekniken. Stöd för Azure-diskkryptering för specifika Linux-distributioner, versioner och avbildningar finns i Azure-diskkryptering för virtuella Linux-datorer.

För SAP HANA-kryptering med vilande data rekommenderar vi att du använder den inbyggda SAP HANA-krypteringstekniken.

Communities

Communities kan svara på frågor och hjälpa dig att konfigurera en lyckad distribution. Tänk på följande resurser:

• Köra SAP-program på Microsoft Platform-bloggen
• Azure Community Support
• SAP Community
• Stack Overflow SAP

Deltagare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

• Ben Trinh | Huvudarkitekt

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Mer information och exempel på SAP-arbetsbelastningar som använder samma tekniker som den här arkitekturen finns i följande artiklar:

• Distribuera SAP S/4HANA eller BW/4HANA på Azure
• Planering och implementering av Azure Virtual Machines för SAP NetWeaver
• Använda Azure för att vara värd för och köra SAP-arbetsbelastningsscenarier

Relaterade resurser

• Köra SAP-produktionsarbetsbelastningar med hjälp av en Oracle Database i Azure