Köra SAP NetWeaver i Windows på Azure

Den här guiden visar en uppsättning beprövade metoder för att köra SAP NetWeaver i en Windows-miljö i Azure med hög tillgänglighet. Databasen är AnyDB, SAP-termen för alla databashanteringssystem som stöds (DBMS) förutom SAP HANA.

Arkitektur

Följande diagram visar SAP NetWeaver i en Windows-miljö.

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

Den här guiden beskriver ett produktionssystem. Systemet distribueras med specifika storlekar för virtuella datorer (VM) som du kan ändra för att tillgodose organisationens behov. Systemet kan reduceras 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.

Arbetsflöde

Virtuella nätverk. Azure Virtual Network-tjänsten ansluter Azure-resurser till varandra med förbättrad säkerhet. I den här arkitekturen ansluter det virtuella nätverket till ett lokalt nätverk via en Azure ExpressRoute-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. Det virtuella hubbnätverket används för delade tjänster som Azure Bastion och säkerhetskopiering.

Peering för virtuella nätverk. Den här arkitekturen använder en nätverkstopologi för nav och eker med flera virtuella nätverk som är peer-kopplade tillsammans. Den här topologin ger nätverkssegmentering och isolering för tjänster som distribueras i Azure. Peering möjliggör transparent anslutning mellan peerkopplade virtuella nätverk via Microsofts stamnätverk. Det medför inte någon prestandaförsedd om den distribueras inom en enda region. Det virtuella nätverket är indelat i separata undernät för varje nivå: program (SAP NetWeaver), databasen och delade tjänster som Bastion och en säkerhetskopieringslösning från tredje part.

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

• SAP NetWeaver. Programnivån använder virtuella Windows-datorer för att köra SAP Central Services- och SAP-programservrar. För hög tillgänglighet konfigureras de virtuella datorer som kör Central Services i ett Windows Server-redundanskluster. De stöds av antingen Azure-filresurser eller Azure-delade diskar.

• AnyDB. Databasnivån kör AnyDB som databas, som kan vara Microsoft SQL Server, Oracle eller IBM Db2.

• Bastion-tjänsten. Administratörer använder en förbättrad säkerhets-VM som kallas skyddsvärd för att ansluta till andra virtuella datorer. Det är vanligtvis en del av delade tjänster, till exempel säkerhetskopieringstjänster. Om Secure Shell Protocol (SSH) och Remote Desktop Protocol (RDP) är de enda tjänster som används för serveradministration är en Azure Bastion-värd en bra lösning. Om du använder andra hanteringsverktyg, till exempel SQL Server Management Studio eller SAP Frontend, använder du en traditionell, självdistribuerad hoppruta.

Privat DNS-tjänst. Azure Private DNS tillhandahåller en tillförlitlig och säker DNS-tjänst för ditt virtuella nätverk. Azure Private DNS hanterar och löser domännamn i det virtuella nätverket, utan att du behöver 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 en Azure-standardlastbalanserare. Observera att en standardlastbalanserare ger en säkerhetsnivå som standard. Virtuella datorer som ligger bakom en standardlastbalanserare har inte utgående Internetanslutning. Om du vill aktivera utgående Internet på de virtuella datorerna måste du uppdatera standardkonfigurationen för lastbalanseraren. 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).

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

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

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

Standard-SKU stöder även SAP-kluster med flera systemidentifierare (multi-SID). Med andra ord kan flera SAP-system i Windows dela en gemensam infrastruktur med hög tillgänglighet för att spara kostnader. Utvärdera kostnadsbesparingarna och undvik 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 porten 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).

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

Programsäkerhetsgrupper. Om du vill definiera detaljerade, arbetsbelastningsbaserade nätverkssäkerhetsprinciper som är centrerade på program använder du programsäkerhetsgrupper i stället för explicita IP-adresser. Programsäkerhetsgrupper är ett sätt att gruppera virtuella datorer efter namn och hjälpa dig att skydda program genom att filtrera trafik från betrodda segment i nätverket.

Gateway. En gateway ansluter distinkta nätverk och utökar ditt lokala nätverk till det virtuella Azure-nätverket. Vi rekommenderar att du använder ExpressRoute 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 . Om du vill minska svarstiden eller öka dataflödet kan du överväga ExpressRoute Global Reach och ExpressRoute FastPath, enligt beskrivningen senare i den här artikeln.

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 skiljer sig åt baserat 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 Planering och implementering av Azure Virtual Machines för SAP NetWeaver.

Mer information om SAP-stöd för azure VM-typer och dataflödesmått (SAPS) finns i SAP-1928533. För att få åtkomst till SAP-anteckningar behöver du ett SAP Service Marketplace-konto.

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 Web Dispatcher-komponenten används Load Balancer för att implementera antingen redundansklustret för Web Dispatcher-instanser eller den parallella konfigurationen av Web Dispatcher. En detaljerad beskrivning av lösningen finns i Hög tillgänglighet för SAP Web Dispatcher.

Pool för programservrar

SAP SMLG-transaktionen används ofta för att hantera inloggningsgrupper för ABAP-programservrar och för att lastbalansera inloggningsanvändare. Andra transaktioner, till exempel SM61 för batchservergrupper och RZ12 för RFC-grupper (Remote Function Call), belastningsutjämning av inloggningsanvändare. Dessa transaktioner använder belastningsutjämningsfunktionen i meddelandeservern för SAP Central Services för att distribuera inkommande sessioner eller arbetsbelastningar mellan SAP-programservrarnas pool för SAP GUIs och RFC-trafik.

SAP Central Services-kluster

Den här arkitekturen kör Central Services på virtuella datorer på programnivån. Central Services är en potentiell enskild felpunkt (SPOF) när den distribueras till en enda virtuell dator. Om du vill implementera en lösning med hög tillgänglighet använder du antingen ett filresurskluster eller ett kluster med delad disk.

Det finns flera alternativ för filresurser med hög tillgänglighet. Vi rekommenderar att du använder Azure Files-resurser som fullständigt hanterade, molnbaserade SMB-resurser (Server Message Block) eller NFS-resurser (Network File System). Ett alternativ till Azure Files är Azure NetApp Files, som tillhandahåller högpresterande NFS- och SMB-resurser.

Du kan också implementera filresurser med hög tillgänglighet på Central Services-instanserna med hjälp av ett Windows Server-redundanskluster med Azure Files. Den här lösningen stöder också ett Windows-kluster med delade diskar med hjälp av en delad Azure-disk som den klusterdelade volymen. Om du föredrar att använda delade diskar rekommenderar vi att du använder delade Azure-diskar för att konfigurera ett Windows Server-redundanskluster för SAP Central Services-kluster.

Det finns också partnerprodukter som SIOS DataKeeper Cluster Edition från SIOS Technology Corp. Det här tillägget replikerar innehåll från oberoende diskar som är anslutna till ASCS-klusternoderna och visar sedan diskarna som en klusterdelad volym till klusterprogramvaran.

Om du använder partitionering av klusternätverk använder klusterprogramvaran kvorumröster för att välja ett segment av nätverket och dess associerade tjänster för att fungera som hjärnan i det fragmenterade klustret. Windows erbjuder många kvorummodeller. Den här lösningen använder Cloud Witness eftersom det är enklare och ger mer tillgänglighet än ett vittne för beräkningsnoder. Azure-filresursvittnet är ett annat alternativ för att tillhandahålla en klusterkvorumröstning.

I en Azure-distribution ansluter programservrarna till centraltjänsterna med hög tillgänglighet med hjälp av de virtuella värdnamnen för ASCS- eller ERS-tjänsterna. Dessa värdnamn tilldelas till klusterklientdelens IP-konfiguration för lastbalanseraren. Load Balancer stöder flera klientdels-IP-adresser, så både VIRTUELLA IP-adresser (ASCS) och ERS (VIP) kan bindas till en lastbalanserare.

Nätverk

Den här arkitekturen använder en topologi med nav-ekrar. Det virtuella hubbnätverket fungerar som en central anslutningspunkt till ett lokalt nätverk. Ekrarna är virtuella nätverk som peerkopplar med hubben och isolerar SAP-arbetsbelastningarna. Trafik flödar mellan det lokala datacentret och hubben via en gatewayanslutning.

Nätverkskort (NÄTVERKSKORT)

Nätverkskort möjliggör all kommunikation mellan virtuella datorer i ett virtuellt nätverk. 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 av prestandaskäl. Men om din organisation behöver separera trafik kan du distribuera flera nätverkskort per virtuell dator och ansluta varje nätverkskort till ett annat undernät. Du kan 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. En fullständig disposition finns 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-anslutningar kan ExpressRoute Global Reach hjälpa dig att minska nätverkshopp och svarstider. Den här tekniken är en BGP-routning (Border Gateway Protocol) som konfigureras mellan två eller flera ExpressRoute-anslutningar för att överbrygga två ExpressRoute-routningsdomäner. Global Reach minskar svarstiden när nätverkstrafiken passerar mer än en ExpressRoute-anslutning. 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 är utformat för att förbättra datasökvägsprestanda mellan ditt lokala nätverk och ditt virtuella nätverk. När den är aktiverad skickar FastPath nätverkstrafik direkt till virtuella datorer i det virtuella nätverket och kringgår gatewayen.

För alla nya ExpressRoute-anslutningar till Azure är FastPath standardkonfigurationen. 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. Den här funktionen är för närvarande i allmänt tillgänglig förhandsversion.

lastbalanserare

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

Azure 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ömmarna. Hashen baseras på käll-IP, källport, mål-IP, målport och protokolltyp. I SAP-distributioner i Azure används Load Balancer i klusterkonfigurationer för att dirigera trafik till den primära tjänstinstansen eller till den felfria noden om det finns ett fel.

Vi rekommenderar att du använder Standard Load Balancer för alla SAP-scenarier. Om virtuella datorer i serverdelspoolen kräver offentlig utgående anslutning, eller om de används i en Azure-zondistribution, kräver Standard Load Balancer ytterligare konfigurationer eftersom de är säkra som standard. De tillåter inte utgående anslutning om du inte uttryckligen konfigurerar den.

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. För den här typen av konfiguration behöver du ingen annan lastbalanserare.

Storage

Vissa organisationer använder standardlagring för sina programservrar. Standardhanterade diskar stöds inte. Se SAP-1928533. För att få åtkomst till SAP-anteckningar behöver du ett SAP Service Marketplace-konto. Vi rekommenderar att du använder azure-hanterade premiumdiskar i alla fall. En nyligen uppdaterad SAP-anteckning 2015553 exkluderar användningen av Standard HDD-lagring och Standard SSD-lagring för några specifika användningsfall.

Programservrar är inte värdar för affärsdata. Du kan också använda de mindre P4- och P6 Premium-diskarna för att minimera kostnaderna. Genom att göra det kan du dra nytta av serviceavtalet för en virtuell dator med en instans om du har en central SAP Stack-installation.

För scenarier med hög tillgänglighet kan du använda Azure-filresurser och delade Azure-diskar. Azure Premium SSD-hanterade diskar och Azure Ultra Disk Storage är tillgängliga för delade Azure-diskar och Premium SSD är tillgängligt för Azure-filresurser.

Lagring används också av Cloud Witness för att underhålla kvorum med en enhet i en fjärransluten Azure-region, bort från den primära region där klustret finns.

För datalagret för säkerhetskopiering rekommenderar vi lågfrekvent åtkomstnivå i Azure och arkivåtkomstnivåer. Dessa lagringsnivåer är ett kostnadseffektivt sätt att lagra långlivade data som används sällan.

Azure Premium SSD v2-disklagring är utformat för prestandakritiska arbetsbelastningar som transaktionsbearbetningssystem online som konsekvent behöver svarstid under millisekunder i kombination med högt IOPS och dataflöde.

Ultra Disk Storage minskar diskfördröjningen avsevärt. Därför gynnar det prestandakritiska program som SAP-databasservrarna. Information om hur du jämför blocklagringsalternativ i Azure finns i Typer av hanterade Azure-diskar.

För ett delat datalager med hög tillgänglighet och höga prestanda använder du Azure NetApp Files. Den här tekniken är särskilt användbar för databasnivån när du använder Oracle, och även när du är värd för programdata.

Prestandaöverväganden

SAP-programservrar kommunicerar ständigt med databasservrarna. För prestandakritiska program som körs på databasplattformar aktiverar du Skrivaccelerator för loggvolymen om du använder Premium SSD v1. Detta kan förbättra svarstiden för loggskrivning. 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.

För att uppnå högt IOPS- och diskflöde följer du de vanliga metoderna för prestandaoptimering av lagringsvolymer, som gäller för Azure Storage-layout. Du kan till exempel placera flera diskar tillsammans för att skapa en randig diskvolym för att förbättra I/O-prestanda. Om du aktiverar läsningscachen för lagring av innehåll som ändras sällan går datahämtningen snabbare.

Premium SSD v2 ger högre prestanda än Premium SSD och är i allmänhet billigare. Du kan ange en Premium SSD v2-disk till valfri storlek som stöds och göra detaljerade justeringar av prestanda utan avbrott.

Ultra Disk Storage är tillgängligt för I/O-intensiva program. Där dessa diskar är tillgängliga rekommenderar vi dem via Premium-lagring för skrivningsacceleratorer . Du kan öka eller minska prestandamått som IOPS och MBIT/s individuellt utan att behöva starta om.

Vägledning om hur du optimerar Azure Storage för SAP-arbetsbelastningar på SQL Server finns i Planering och implementering av Azure Virtual Machines för SAP NetWeaver.

Placeringen av en virtuell nätverksinstallation (NVA) mellan programmet och databaslagren för en SAP-programstack stöds inte. Den här metoden introducerar betydande bearbetningstid för datapaket, vilket leder till oacceptabla programprestanda.

Närhetsplaceringsgrupper

Vissa SAP-program kräver frekvent kommunikation med databasen. Programmets fysiska närhet och databasskikten påverkar nätverksfördröjningen, vilket kan påverka programmets prestanda negativt.

För att optimera nätverksfördröjningen kan du använda närhetsplaceringsgrupper som anger en logisk begränsning för de virtuella datorer som distribueras i tillgänglighetsuppsättningar. Närhetsplaceringsgrupper gynnar samplacering och prestanda jämfört med skalbarhet, tillgänglighet eller kostnad. De kan avsevärt förbättra användarupplevelsen för de flesta SAP-program. Skript som är tillgängliga på GitHub från SAP-distributionsteamet finns i Skript.

Tillgänglighetszoner

Tillgänglighetszoner är ett sätt för dig att distribuera virtuella datorer mellan datacenter, som är fysiskt avgränsade platser i en specifik Azure-region. Syftet med dem är att förbättra tjänstens tillgänglighet. Men att distribuera resurser mellan zoner kan öka svarstiden, så tänk på prestandaöverväganden.

Administratörer behöver en tydlig nätverksfördröjningsprofil mellan alla zoner i en målregion innan de kan fastställa resursplaceringen med minsta svarstid mellan zoner. Om du vill skapa den här profilen distribuerar du små virtuella datorer i varje zon för testning. Rekommenderade verktyg för dessa tester är PsPing och Iperf. När testerna är klara tar du bort de virtuella datorer som du använde för testning. Som ett alternativ kan du överväga att använda ett verktyg för svarstidskontroll mellan zoner i Azure.

Skalbarhetsöverväganden

För SAP-programlagret erbjuder Azure ett brett utbud av VM-storlekar för att skala upp och skala ut. En inkluderande lista finns i SAP Note 1928533 – SAP-program på Azure: Produkter som stöds och Typer av virtuella Azure-datorer. För att få åtkomst till SAP-anteckningar behöver du ett SAP Service Marketplace-konto.

Du kan skala upp och ned SAP-programservrar och Central Services-kluster. Du kan också skala ut eller in dem genom att ändra antalet instanser som du använder. AnyDB-databasen kan skalas upp och ned men skalas inte ut. SAP-databascontainern för AnyDB stöder inte horisontell partitionering.

Ö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.

Med Azure kan SAP-arbetsbelastningsdistribution 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 tillgängligheten för resurser. 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.

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.

Web Dispatcher på programservernivån

Komponenten Web Dispatcher används som lastbalanserare för SAP-trafik mellan SAP-programservrarna. För att uppnå hög tillgänglighet för SAP Web Dispatcher implementerar Load Balancer antingen redundansklustret eller den parallella konfigurationen av Web Dispatcher.

För internetriktad kommunikation rekommenderar vi en fristående lösning i perimeternätverket, som även kallas DMZ, 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.

Centrala tjänster på programservernivån

Hög tillgänglighet för centraltjänsterna implementeras med ett Windows Server-redundanskluster. När klusterlagringen för redundansklustret distribueras i Azure kan du konfigurera den på två sätt: som en klustrad delad disk eller som en klustrad filresurs.

• Vi rekommenderar att du använder Azure Files som fullständigt hanterade, molnbaserade SMB- eller NFS-resurser. Ett annat sätt är att använda Azure NetApp Files, som tillhandahåller högpresterande NFS- och SMB-resurser i företagsklass.

• Det finns två sätt att konfigurera kluster med delade diskar på Azure. Först rekommenderar vi att du använder delade Azure-diskar för att konfigurera ett Windows Server-redundanskluster för SAP Central Services. Ett implementeringsexempel finns i ASCS-kluster med hjälp av delade Azure-diskar. Ett annat sätt att implementera en klustrad delad disk är att använda SIOS DataKeeper för att utföra följande uppgifter:

  • Replikera innehållet på oberoende diskar som är anslutna till klusternoderna.
  • Abstrahera enheterna som en klusterdelad volym för klusterhanteraren.

  Mer information om implementering finns i Klustring av SAP ASCS på Azure med SIOS.

Om du använder Standard Load Balancer kan du aktivera porten med hög tillgänglighet. På så sätt kan du undvika att behöva konfigurera belastningsutjämningsregler för flera SAP-portar. När du konfigurerar Azure-lastbalanserare aktiverar du även Direct Server Return (DSR), som även kallas flytande IP. Detta ger ett sätt för serversvar att kringgå lastbalanseraren. Den här direktanslutningen gör att lastbalanseraren inte blir en flaskhals i dataöverföringens sökväg. Vi rekommenderar att du aktiverar DSR för ASCS- och databaskluster.

Programtjänster på programservernivån

Hög tillgänglighet för SAP-programservrarna uppnås genom belastningsutjämning av trafik i en pool med programservrar. Du behöver inte klusterprogramvara, SAP Web Dispatcher eller Azure-lastbalanseraren. SAP-meddelandeservern kan belastningsutjämning klienttrafik till de programservrar som definierats i en ABAP-inloggningsgrupp av transaktionen SMLG.

Databasnivå

I den här arkitekturen körs källdatabasen på AnyDB – en DBMS som SQL Server, SAP ASE, IBM Db2 eller Oracle. Den inbyggda replikeringsfunktionen på databasnivån ger antingen manuell eller automatisk redundans mellan replikerade noder.

Implementeringsinformation om specifika databassystem finns i Azure Virtual Machines DBMS-distribution för SAP NetWeaver.

Virtuella datorer som distribueras mellan tillgänglighetszoner

En tillgänglighetszon består av ett eller flera datacenter. Den är utformad för att förbättra tillgängligheten för arbetsbelastningar och skydda programtjänster och virtuella datorer mot datacenterstopp. Virtuella datorer i en enda zon behandlas som om de fanns i en enda feldomän. När du väljer zonindelad distribution distribueras virtuella datorer i samma zon till feldomäner på bästa sätt.

I Azure-regioner som stöder flera zoner är minst tre zoner tillgängliga. Men det maximala avståndet mellan datacenter i dessa zoner är 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. Du behöver också veta 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/inaktiv 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 databastjänsterna sträcker sig över två zoner. Om zon 1 misslyckas körs Central Services och databastjänsterna i zon 2. De passiva programservrarna i zon 2 aktiveras. Med alla komponenter i det här SAP-systemet som nu finns 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. Inom varje zon är två programservrar i varje uppsättning servrar inaktiva eftersom de stängs av. Det innebär att det finns aktiva programservrar i båda zonerna under normal drift.

Central Services 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 Central Services och databastjänsterna på grund av det fysiska avståndet mellan zoner.

Om zon 1 går offline redundansväxlar Central Services och databastjänsterna till zon 2. Du kan ta de vilande programservrarna online för att tillhandahålla 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.

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-programvara enligt Microsofts bästa praxis. 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.

Om du behöver mer kontroll över underhållshändelser eller maskinvaruisolering kan du distribuera dina virtuella datorer på dedikerade värdar för prestanda eller efterlevnad.

Backup

Databaser är kritiska arbetsbelastningar som kräver ett mål för låg återställningspunkt (RPO) och långsiktig kvarhållning.

• För SAP på SQL Server är en metod att använda Azure Backup för att säkerhetskopiera SQL Server-databaser som körs på virtuella datorer. Ett annat alternativ är att använda Azure Files-ögonblicksbilder för att säkerhetskopiera SQL Server-databasfiler.

• För SAP på Oracle/Windows, se avsnittet "Säkerhetskopiering/återställning" i Azure VM DBMS Deployment for SAP.

• Andra databaser finns i rekommendationerna för säkerhetskopiering för databasprovidern. Om databasen stöder Windows Volume Shadow Copy Service (VSS) använder du VSS-ögonblicksbilder för programkonsekventa säkerhetskopior.

Identitetshantering

Använd ett centraliserat identitetshanteringssystem som Microsoft Entra ID och Usluge domena aktivnog direktorijuma (AD DS) för att styra åtkomsten till resurser på alla nivåer:

• Ge åtkomst till Azure-resurser med hjälp av rollbaserad åtkomstkontroll i Azure (Azure RBAC).

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

Stöd för åtkomst i själva programmen med hjälp av 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 för 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. Detaljerad vägledning för programsäkerhet finns i säkerhetsguiden för SAP NetWeaver.

För mer nätverkssäkerhet 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.

Du kan distribuera en NVA för att filtrera trafik mellan virtuella nätverk, men placera den inte mellan SAP-programmet och databasen. Kontrollera även de routningsregler som har konfigurerats i undernätet och undvik att dirigera trafik till en nva med en instans. Detta kan leda till underhållsavbrott och nätverks- eller klusternodfel.

För infrastruktursäkerhet krypteras data under överföring och i vila. Information om nätverkssäkerhet finns i avsnittet "Säkerhetsrekommendationer" i Planering och implementering av Azure Virtual Machines för SAP NetWeaver. Den här artikeln anger även de nätverksportar som du behöver öppna i brandväggarna för att tillåta programkommunikation.

Du kan använda Azure Disk Encryption för att kryptera virtuella Windows-diskar. Den här tjänsten använder BitLocker-funktionen i Windows för att tillhandahålla volymkryptering för operativsystemet och datadiskarna. Lösningen fungerar också med Azure Key Vault för att hjälpa dig att styra och hantera diskkrypteringsnycklar och hemligheter i din nyckelvalvsprenumeration. Data på de virtuella datordiskarna krypteras i vila i Azure Storage.

För data-i-vila-kryptering krypterar SQL Server transparent datakryptering (TDE) SQL Server, Azure SQL Database och Azure Synapse Analytics-datafiler. Mer information finns i SQL Server Azure Virtual Machines DBMS-distribution för SAP NetWeaver.

Överväg att distribuera Microsoft Sentinel (förhandsversion) om du vill övervaka hot inifrån och utanför brandväggen. Lösningen tillhandahåller kontinuerlig hotidentifiering och analys för SAP-system som distribueras i Azure, i andra moln eller lokalt. Distributionsvägledning finns i Distribuera hotövervakning för SAP i Microsoft Sentinel.

Som alltid kan du hantera säkerhetsuppdateringar och korrigeringar för att skydda dina informationstillgångar. Överväg att använda en automatiseringsmetod från slutpunkt till slutpunkt för den här uppgiften.

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.

Om din arbetsbelastning kräver mer minne och färre processorer kan du överväga att använda en av de begränsade vm-storlekarna för virtuella vCPU-datorer för att minska kostnaderna för programvarulicensiering som debiteras per vCPU.

Virtuella datorer

Den här arkitekturen använder virtuella datorer för programnivån och databasnivån. SAP NetWeaver-nivån använder virtuella Windows-datorer för att köra SAP-tjänster och -program. Databasnivån kör AnyDB som databas, till exempel SQL Server, Oracle eller IBM DB2. Virtuella datorer används också som hopprutor för hantering.

Det finns flera betalningsalternativ för virtuella datorer:

• För arbetsbelastningar som inte har någon 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 finns i Azure Reserved Virtual Machine Instances (Azure Reserved Virtual Machine Instances).

Load Balancer

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

Du debiteras endast för antalet konfigurerade belastningsutjämnings- och utgående regler, plus de data som bearbetas via lastbalanseraren. 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.

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 för 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:

• 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