Redigera

SAP-distribution i Azure med hjälp av en Oracle-databas

Azure ExpressRoute
SAP HANA on Azure Large Instances
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

Den här referensarkitekturen visar en uppsättning beprövade metoder för att köra en SAP NetWeaver med hög tillgänglighet med Oracle Database i Azure. Arkitekturprinciperna är os-agnostiska, men om inget annat anges antas arkitekturen vara baserad på Linux.

Det första diagrammet visar en referensarkitektur för SAP på Oracle i Azure. Arkitekturen använder tillgänglighetsuppsättningar.

Diagram över arkitekturen för ett SAP-produktionssystem på Oracle i Azure.

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

Kommentar

För att distribuera den här referensarkitekturen behöver du lämplig licensiering av SAP-produkter och andra tekniker som inte kommer från Microsoft.

Komponenter

Den här referensarkitekturen beskriver ett typiskt SAP-produktionssystem som körs på Oracle Database i Azure, i en distribution med hög tillgänglighet för att maximera systemets tillgänglighet. Arkitekturen och dess komponenter kan anpassas baserat på affärskrav (RTO, RPO, drifttidsförväntningar, systemroll) och potentiellt reduceras till en enda virtuell dator. Nätverkslayouten är förenklad för att demonstrera arkitekturhuvudnamnen för en sådan SAP-miljö och är inte avsedd att beskriva ett fullständigt företagsnätverk.

Nätverk

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 en lokal miljö via en virtuell privat nätverksgateway (VPN) som distribueras i navet i en hubb-ekertopologi. SAP-program och -databaser finns i ett eget virtuellt ekernätverk. De virtuella nätverken delas upp i separata undernät för varje nivå: program (SAP NetWeaver), databasen och delade tjänster (till exempel Azure Bastion).

Den här arkitekturen delar upp adressutrymmet för det virtuella nätverket i undernät. Placera programservrar på ett separat undernät och databasservrar på en annan. 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 och separera säkerhetsreglerna som gäller för databaser från programservrar.

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 tillhandahåller 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.

Zonredundant 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 . Azure ExpressRoute- eller VPN-gatewayer kan distribueras mellan zoner för att skydda mot zonfel. Se Zonredundanta virtuella nätverksgatewayer för att förstå skillnaderna mellan en zonindelad distribution och en zonredundant distribution. Här är det värt att nämna att de IP-adresser som används måste vara standard-SKU för en zondistribution av gatewayerna.

Nätverkssäkerhetsgrupper. Om du vill begränsa inkommande, utgående och intraundernätstrafik i det virtuella nätverket skapar du nätverkssäkerhetsgrupper som i sin tur tilldelas till specifika undernät. DATABAS- och programundernät skyddas med arbetsbelastningsspecifika NSG:er.

Programsäkerhetsgrupper. Om du vill definiera detaljerade nätverkssäkerhetsprinciper i dina NSG:er baserat på arbetsbelastningar som är centrerade på program använder du programsäkerhetsgrupper i stället för explicita IP-adresser. De låter dig gruppera virtuella datorer efter namn och hjälpa dig att skydda program genom att filtrera trafik från betrodda segment i nätverket.

Nätverkskort (NIC). 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 framtvinga olika principer för åtkomstkontroll i varje undernät.

Azure NIC stöder flera IP-adresser. Det här stödet överensstämmer med den rekommenderade SAP-metoden att använda 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.)

Virtuella datorer

Den här arkitekturen använder virtuella datorer (VM). För SAP-programnivå distribueras virtuella datorer för alla instansroller – webbsändar- och programservrar – både SAP (A)SCS och ERS för centrala tjänster samt programservrar (PAS, AAS). Justera antalet virtuella datorer baserat på dina krav. Planerings - och implementeringsguiden för Azure Virtual Machines innehåller information om hur du kör SAP NetWeaver på virtuella datorer.

På samma sätt används virtuella Oracle-datorer, både för Oracle Database och virtuella Oracle-övervakare. De virtuella övervakningsdatorerna i den här arkitekturen är mindre jämfört med faktiska databasservrar.

  • Begränsade virtuella vCPU-datorer. För att eventuellt spara kostnader för Oracle-licensiering bör du överväga att använda virtuella VCPU-begränsade virtuella datorer
  • Certifierade VM-familjer för SAP. Mer information om SAP-stöd för typer av virtuella Azure-datorer 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.)

Närhetsplaceringsgrupper (PPG). För att optimera nätverksfördröjningen kan du använda närhetsplaceringsgrupper, vilket gynnar samverkan, vilket innebär att virtuella datorer finns i samma datacenter för att minimera programfördröjningen. De kan avsevärt förbättra användarupplevelsen för de flesta SAP-program. På grund av potentiella begränsningar med PPG:er bör du lägga till databasen AvSet i SAP-systemets PPG sparsamt och endast när det krävs för svarstid mellan SAP-program och databastrafik. Mer information om användningsscenarier för PPG:er finns i den länkade dokumentationen.

Virtuella datorer i generation 2 (Gen2). Azure erbjuder valet när du distribuerar virtuella datorer om de ska vara generation 1 eller 2. Virtuella datorer i generation 2 stöder viktiga funktioner som inte är tillgängliga för virtuella datorer i generation 1. Särskilt för mycket stora Oracle-databaser är detta viktigt eftersom vissa VM-familjer som Mv2 eller Mdsv2 endast stöds som virtuella Gen2-datorer. På samma sätt kan SAP på Azure-certifiering för vissa nyare virtuella datorer kräva att de bara är Gen2 för fullständigt stöd, även om Azure tillåter båda. Mer information finns i SAP Note 1928533 – SAP-program på Microsoft Azure: Produkter som stöds och typer av virtuella Azure-datorer.

Eftersom alla andra virtuella datorer som stöder SAP tillåter valet av endast Gen2 eller Gen1+2 selektivt rekommenderar vi att du distribuerar alla virtuella SAP-datorer som Gen2, även om minneskraven är mycket låga. Även de minsta virtuella datorerna som en gång distribuerades som Gen2 kan skalas upp till den största tillgängliga med en enkel frigöring och storleksändring. Virtuella Gen1-datorer kan bara ändras till vm-familjer som tillåts köra virtuella Gen1-datorer.

Lagring

Den här arkitekturen använder Azure-hanterade diskar för virtuella datorer och Azure Files NFS eller Azure NetApp Files för alla krav på delad NFS-lagring, till exempel sapmnt- och SAP-transport-NFS-volymer. Riktlinjer för lagringsdistribution med SAP i Azure finns i detalj i arbetsbelastningsguiden för Azure Storage-typer för SAP

  • Certifierad lagring för SAP. Information om certifierade VM-typer för SAP-användning finns i informationen i SAP-2015553 och SAP-anteckning 2039619.
  • Lagringsdesign för SAP på Oracle. Du hittar en rekommenderad lagringsdesign för SAP på Oracle i Azure i Azure Virtual Machines Oracle DBMS-distribution för SAP-arbetsbelastning. Den här artikeln innehåller specifik vägledning om filsystemlayout, rekommendationer för diskstorlek och andra lagringsalternativ.
  • Lagra Oracle Database-filer. I Linux ext4- eller xfs-filsystem måste de användas för databas-, NTFS- för Windows-distributioner. Oracle ASM stöds också för Oracle-distributioner för Oracle Database 12c Version 2 och senare.
  • Alternativ till hanterade diskar. Du kan också använda Azure NetApp Files för Oracle-databasen. Mer information finns i DOKUMENTATIONen om SAP-2039619 och Oracle i Azure. Azure Files NFS-volymer är inte avsedda för lagring av Oracle Database-filer, till skillnad från Azure NetApp Files.
  • Azure Premium SSD v2 är utformat för prestandakritiska arbetsbelastningar som SAP. Se Distribuera en Premium SSD v2 för den här lagringslösningens fördelar och dess aktuella begränsningar.

Hög tillgänglighet

Den föregående arkitekturen visar en distribution med hög tillgänglighet, där varje programskikt finns på två eller flera virtuella datorer. Följande komponenter används.

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 öka tillgängligheten för resurser. Information om 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.

Lastbalanserare.Azure Load Balancer används för att distribuera trafik till virtuella datorer i SAP-undernäten. När du införlivar Azure Load Balancer i en zonindelad distribution av SAP måste du välja standard-SKU-lastbalanseraren. Basic SKU-balanseraren stöder inte zonredundans.

Tänk på beslutsfaktorerna när du distribuerar virtuella datorer mellan tillgänglighetszoner för SAP. Användning av närhetsplaceringsgrupper med en distribution av tillgänglighetszoner måste utvärderas och endast användas för virtuella datorer på programnivå.

Kommentar

Tillgänglighetszoner har stöd för hög tillgänglighet inom regionen, men de är inte effektiva för DR. Avstånden mellan zoner är för korta. Typiska DR-regioner bör vara minst 16 mil från den primära regionen.

Oracle-specifika komponenter. Virtuella Oracle Database-datorer distribueras i en tillgänglighetsuppsättning eller i olika tillgänglighetszoner. Varje virtuell dator innehåller en egen installation av databasprogramvaran och den vm-lokala databaslagringen. Konfigurera synkron databasreplikering via Oracle Data Guard mellan databaserna för att säkerställa konsekvens och tillåta låga RTO- och RPO-tjänsttider om enskilda fel inträffar. Förutom de virtuella databasdatorerna behövs ytterligare virtuella datorer med Oracle Data Guard Observer för en snabbstartskonfiguration för Oracle Data Guard. De virtuella Oracle-övervakarens virtuella datorer övervakar databasen och replikeringsstatusen och underlättar databasredundans på ett automatiserat sätt, utan att behöva någon klusterhanterare. Databasreplikeringshantering kan utföras och sedan använda Oracle Data Guard Broker för enkel användning.

Mer information om Oracle Data Guard-distribution finns i

Den här arkitekturen använder inbyggda Oracle-verktyg utan någon faktisk klusterkonfiguration eller behovet av en lastbalanserare på databasnivån. Med Oracle Data Guard snabbstartsredundans och SAP-konfiguration automatiseras redundansväxlingen och SAP-program ansluter till den nya primära databasen igen om en redundansväxling sker. Olika klusterlösningar från tredje part finns som ett alternativ, till exempel SIOS Protection Suite eller Veritas InfoScale, information om vilken distribution som finns i respektive tredjepartsleverantörs dokumentation.

Oracle RAC. Oracle Real Application Cluster (RAC) är för närvarande inte certifierat eller stöds inte av Oracle i Azure. Oracle Data Guard-tekniker och arkitektur för hög tillgänglighet kan dock ge mycket motståndskraftiga SAP-miljöer med skydd mot rack, datacenter eller regionala avbrott i tjänsten.

NFS-nivå. För alla SAP-distributioner med hög tillgänglighet måste en elastisk NFS-nivå användas, vilket ger NFS-volymer för SAP-transportkatalog, sapmnt volym för SAP-binärfiler samt ytterligare volymer för (A)SCS- och ERS-instanser. Alternativ för att ange en NFS-nivå är

SAP-kluster för centrala tjänster. Den här referensarkitekturen kör Central Services på diskreta virtuella datorer. Central Services är en potentiell enskild felpunkt (SPOF) när den distribueras till en enda virtuell dator. För att implementera en lösning med hög tillgänglighet krävs klusterhanteringsprogram som automatiserar redundansväxling av (A)SCS- och ERS-instanser till respektive virtuell dator. Eftersom detta är starkt kopplat till den valda NFS-lösningen

Den valda klusterlösningen kräver en mekanism för att avgöra vilken virtuell dator som ska betjäna respektive tjänst om programvara eller infrastruktur inte är tillgänglig. Med SAP på Azure är två alternativ tillgängliga för Linux-baserad implementering av STONITH – hur du hanterar virtuella datorer eller program som inte svarar

  • SUSE-Linux-onlySBD (STONITH Block Device) – med hjälp av en eller tre ytterligare virtuella datorer som fungerar som iSCSI-exporter av en liten blockenhet, som används regelbundet av de faktiska virtuella klustermedlemsdatorerna, två (A)SCS/ERS-virtuella datorer i den här klusterpoolen. De virtuella datorerna använder dessa SBD-monteringar för att avge röster och därmed uppnå kvorum för klusterbeslut. Arkitekturen som finns på den här sidan innehåller INTE de 1 eller 3 ytterligare virtuella SBD-datorerna. RedHat stöder inte några SBD-implementeringar i Azure och därför är det här alternativet endast tillgängligt för SUSE SLES-operativsystemet.
  • Azure Fence Agent. Utan att använda ytterligare virtuella datorer används Azure-hanterings-API:et för regelbundna kontroller av vm-tillgänglighet.

Guider som är länkade i avsnittet NFS-nivå innehåller nödvändiga steg och design för respektive klusterval. Azure-certifierade klusterhanterare från tredje part kan också användas för att tillhandahålla hög tillgänglighet för SAP:s centrala tjänster.

SAP-programserverpool. Två eller flera programservrar där hög tillgänglighet uppnås genom belastningsutjämningsbegäranden via SAP-meddelandeservern eller webbsändartjänsten. Varje programserver är oberoende och det krävs ingen belastningsutjämning för nätverket för den här poolen med virtuella datorer.

SAP web dispatcher pool. 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 Azure Load Balancer antingen redundansklustret eller den parallella konfigurationen av Web Dispatcher.

Embedded Web Dispatcher på (A)SCS är ett speciellt alternativ. Du bör ta hänsyn till korrekt storleksändring på grund av ytterligare arbetsbelastning på (A)SCS.

För internetuppkopplad kommunikation rekommenderar vi en fristående lösning i perimeternätverket (även kallat DMZ) för att uppfylla säkerhetsproblem.

Windows-distributioner. Det här dokumentet, som vi började med, fokuserar främst på Linux-baserade distributioner. För användning med Windows gäller samma arkitekturprinciper och det finns inga arkitekturskillnader med Oracle mellan Linux och Windows.

För SAP-programdel, se informationen i arkitekturguiden Kör SAP NetWeaver i Windows på Azure.

Att tänka på

Haveriberedskap

Följande diagram visar arkitekturen för ett SAP-produktionssystem på Oracle i Azure. Arkitekturen tillhandahåller DR och använder tillgänglighetszoner.

Diagram som visar en arkitektur för ett SAP-produktionssystem i Oracle i Azure.

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

Varje arkitekturskikt 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.

Backup

Säkerhetskopiering för Oracle i Azure kan göras på flera sätt:

  • Azure Backup.Azure tillhandahöll och underhålls skript för Oracle Databases för att underlätta Oracle-åtgärder före och efter säkerhetskopiering.
  • Azure Storage. Använda filbaserade databassäkerhetskopior, till exempel schemalagda med SAP:s BR-verktyg, som ska lagras och versionshanteras som filer/kataloger i Azure Blob NFS, Azure Blob eller Azure Files-lagringstjänster. Se dokumenterad information om hur du uppnår både Oracle-data och loggsäkerhetskopior.
  • Säkerhetskopieringslösningar från tredje part. Se arkitekturen för din provider för lagring av säkerhetskopior med stöd för Oracle i Azure.

För virtuella datorer som inte är databaser rekommenderas Azure Backup för virtuell dator för att skydda virtuella SAP-programdatorer och omge infrastruktur som SAP Web Dispatcher.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Nästa steg

Communities

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

Mer information och exempel på SAP-arbetsbelastningar som använder samma tekniker finns i de här artiklarna: