Köra SAP NetWeaver i Windows på Azure

Den här referensarkitekturen 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 (DBMS) som stöds förutom SAP HANA.

Det första diagrammet visar SAP NetWeaver i en Windows miljö i ett scenario med en tillgänglighetsuppsättning. Arkitekturen använder Azure NetApp Files för det delade fillagret och en närhetsplaceringsgrupp för bättre prestanda:

Ladda ned Visio fil som visar den här arkitekturen.

Det andra diagrammet visar SAP NetWeaver i en Windows miljö. Tillgänglighetszoner används för förbättrad motståndskraft:

Ladda ned Visio fil som visar den här arkitekturen.

Arkitektur

Den här referensarkitekturen beskriver ett produktionssystem. Den distribueras med specifika vm-storlekar (VM) som kan ändras för att tillgodose organisationens behov. Den kan reduceras till en enda virtuell dator. Nätverkslayouten är avsevärt förenklad för att demonstrera arkitekturprinciperna. Det är inte avsett att beskriva ett fullständigt företagsnätverk.

Dessa komponenter krävs:

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 topologi av nav och ekrar. Ekrarna är det virtuella nätverk som används för SAP-program och databasnivåer.

Peering för virtuella nätverk. Den här arkitekturen använder en nätverkstopologi av nav och ekrar med flera virtuella nätverk som är peer-samman. 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 ingen prestandaförseing 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 Jumpbox och Active Directory).

Virtuella datorer. Den här arkitekturen använder virtuella datorer för programnivå och databasnivå, grupperade så här:

• SAP NetWeaver. Programnivån använder virtuella Windows för att köra SAP Central Services och SAP-programservrar. De virtuella datorer som kör centrala tjänster konfigureras som ett Windows Server-redundanskluster för hög tillgänglighet. De stöds av en Windows Scale-Out-server med Lagringsutrymmen Direct eller delade Azure-diskar.

• AnyDB. Databasnivån kör AnyDB som databasen, till exempel Microsoft SQL Server, Oracle eller IBM Db2.

• Jump box (kallas även för en skyddsvärd). Administratörer använder den här förbättrade säkerhetsdatorn för att ansluta till de andra virtuella datorerna. Det är vanligtvis en del av delade tjänster, till exempel domänkontrollanter och säkerhetskopieringstjänster. Om Secure Shell Protocol (SSH) och Remote Desktop Protocol (RDP) är de enda tjänsterna som används för serveradministration är en Azure Bastion värd ett alternativ. Men om du använder andra hanteringsverktyg, som SQL Server Management Studio eller SAP-frontend, använder du en traditionell, själv distribuerad jumpbox.

• Windows Server Active Directory domänkontrollanter. Domänkontrollanterna används för identitetshantering av alla virtuella datorer och användare i domänen.

Lastbalanserare. Lastbalanserare används för att distribuera trafik till virtuella datorer i undernätet på programnivå. För hög tillgänglighet använder du den inbyggda SAP Web Dispatcher, Azure Load Balancereller nätverksutrustning. Ditt val beror på trafiktypen (t.ex. HTTP eller SAP-gränssnittet) eller vilka nätverkstjänster som krävs, t.ex. Secure Sockets Layer (SSL)-avslutning.

Tillgänglighetsuppsättningar. Virtuella datorer för alla pooler och kluster (Web Dispatcher, SAP-programservrar, centraltjänster och databaser) grupperas i separata tillgänglighetsuppsättningar. Minst två virtuella datorer etableras per roll. Tillgänglighetsuppsättningar ökar tillgängligheten för program och virtuella datorer. De gör det via hantering av värdsystemfel eller underhållshändelser genom att distribuera rollinstanser till flera värdar. Ett alternativ är att använda Tillgänglighetszoner för att förbättra arbetsbelastningens tillgänglighet, enligt beskrivningen längre fram i den här artikeln.

Zonredundant gateway. Azure ExpressRoute eller VPN-gatewayer kan distribueras mellan zoner för att skydda mot zonfel. Se Zonredundant virtuella nätverksgatewayer för att förstå skillnaderna mellan en zonindead distribution och en zonredundant distribution.

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

Nätverkssäkerhetsgrupper. Om du vill begränsa inkommande, utgående och intra-undernätstrafik i det virtuella nätverket skapar du nätverkssäkerhetsgrupper.

Programsäkerhetsgrupper. Om du vill definiera mer utförliga nätverkssäkerhetsprinciper baserat på arbetsbelastningar som är centrerade på program använder du programsäkerhetsgrupper i stället för explicita IP-adresser. De gör att du kan 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 använda ExpressRoute Global ReachExpressRoute FastPath, som beskrivs senare i den här artikeln.

Azure Storage. Azure Storage datapersistence för en virtuell dator i form av en virtuell hårddisk (VHD). Vi rekommenderar Azure Managed Disks.

Rekommendationer

Den här arkitekturen beskriver en liten distribution på produktionsnivå. Distributionen varierar beroende på dina affärskrav, så tänk på dessa rekommendationer som utgångspunkt.

Virtuella datorer

I programserverpooler och kluster justerar du 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.

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

SAP Web Dispatcher (SWD)

Komponenten Web Dispatcher används som lastbalanserare för SAP-trafik mellan SAP-programservrarna. För att uppnå hög tillgänglighet för Web Dispatcher-Azure Load Balancer används för att implementera antingen redundansklustret med SWD:er eller den parallella SWD-konfigurationen. En detaljerad beskrivning av lösningen finns i Hög tillgänglighet för SAP Web Dispatcher.

Programserverpool

SAP SMLG-transaktionen används ofta för att hantera inloggningsgrupper för ABAP-programservrar och för att belastningsutjämna inloggningsanvändare. Andra transaktioner, till exempel SM61 för batch-servergrupper och RZ12 för RFC-grupper, belastningsutjämnar även inloggningsanvändare. De här transaktionerna använder belastningsutjämningsfunktioner i meddelandeservern för SAP Central Services för att distribuera inkommande sessioner eller arbetsbelastningar mellan SAP-programserverpoolen för SAP- API:er och RFC-trafik.

SAP Central Services-kluster

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

Det finns flera alternativ för filresurskluster. Vi rekommenderar att du använder Azure Files-resurser som fullständigt hanterade, molnbaserade SMB- eller NFS-resurser. Ett alternativ till Azure Files är Azure NetApp Files, som tillhandahåller högpresterande NFS- och SMB-resurser.

Du kan också implementera filresursen med hög tillgänglighet på Central Services-instanserna med hjälp av WSFC med Skalbar filserver och funktionen Lagringsutrymmen Direct i Windows Server 2016 och senare. Den här lösningen stöder Windows kluster med hjälp av en filresurs som Scale-Out server som klusterdelade volym (CSV).

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 även produkter från tredje part 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 CSV till klusterprogramvaran.

Microsoft stöder flera ASCS-instanser med olika system-ID:n (SID) som distribuerats på ett Windows-kluster över flera filresurser som betjänas av samma Skalbar filserver kluster. Den här konfigurationen kan hjälpa dig att minska infrastrukturkostnaderna.

Vid klusternätverkspartitionering använder klusterprogramvaran röster för att avgöra vilket segment av nätverket och dess associerade tjänster som ska fungera som hjärnan i det nu fragmenterade klustret. Windows erbjuder ett antal kvorummodeller. Den här lösningen använder Azure-molnvittne eftersom det är enklare och ger mer tillgänglighet än ett beräkningsnodvittne. Azure-filresursvittnet är ett annat alternativ för att ge en kvorumröst för klustret.

I en Azure-distribution ansluter programservrarna till de centrala tjänsterna med hög tillgänglighet via de virtuella värdnamnen för ASCS- eller ERS-tjänsterna. Dessa värdnamn tilldelas till klustrets IP-konfiguration på frontend-sidan för lastbalanseraren. Azure Load Balancer har stöd för flera IP-adresser för frontend så att både VIRTUELLA IP-adresser (VIP) för ASCS och ERS kan begränsas till en lastbalanserare.

Tillgänglighetsuppsättningar

Tillgänglighetsuppsättningar distribuerar servrar till olika fysiska infrastrukturer och uppdateringsgrupper för att förbättra tjänstens tillgänglighet. För att uppfylla serviceavtal(SLA)lägger du till virtuella datorer som utför samma roll i en tillgänglighetsuppsättning. På så sätt kan du skydda mot planerade och oplanerade avbrott som uppstår vid underhåll av Azure-infrastrukturen eller på grund av maskinvarufel. För att få ett högre serviceavtal måste du ha två eller flera virtuella datorer per tillgänglighetsuppsättning.

Alla virtuella datorer i en uppsättning måste utföra samma roll. Blanda inte servrar med olika roller i samma tillgänglighetsuppsättning. Placera till exempel inte en ASCS-nod i samma tillgänglighetsuppsättning som programservrarna.

Du kan distribuera Azure-tillgänglighetsuppsättningar Azure-tillgänglighetszoner när du använder en närhetsplaceringsgrupp.

Nätverk

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

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 åtsega administrativ trafik från företagstrafik.

I Azure är det virtuella nätverket ett programvarudefinierat nätverk som skickar all trafik via samma nätverks fabric. Därför är det inte nödvändigt att använda flera nätverkskort av prestandaskäl. Men om din organisation behöver åtsega 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-nätverkskort stöder flera IP-adresser. Det här stödet följer den rekommenderade sap-praxis att använda virtuella värdnamn för installationer. En fullständig disposition finns i SAP-anteckningen 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 in 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 en nätverkssäkerhetsgrupp är associerad med ett undernät gäller den för alla servrar i undernätet och ger mer kontroll över servrarna. Konfigurera dem med hjälp av Azure Portal,PowerShelleller 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-routnings-peering som upprättas mellan två eller flera ExpressRoute-anslutningar för att överbrygga två ExpressRoute-routningsdomäner. Global Reach minskar svarstiden när nätverkstrafiken passerar fler än en ExpressRoute-anslutning. Den är för närvarande endast tillgänglig för privat peering på ExpressRoute-kretsar.

Just nu finns det inga åtkomstkontrollistor för nätverk (ACL) eller andra attribut som kan ändras i Global Reach. Därför annonseras alla vägar som lärts in av en viss ExpressRoute-krets (från en lokal plats och Azure) via krets-peering till den andra ExpressRoute-kretsen. Vi rekommenderar att du upprättar filtrering av nätverkstrafik lokalt för att begränsa åtkomsten till resurser.

ExpressRoute FastPath

FastPath kallas även Microsoft Edge Exchange (MSEE) v2 och implementerar MSEE vid Azure-nätverkets startpunkt. Det minskar nätverkshoppen för de flesta datapaket.

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 peer-kopplade till ett som är anslutet till ExpressRoute fortsätter nätverkstrafiken från ditt lokala nätverk till de andra virtuella ekernätverken att skickas 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(S)-trafik till en pool med SAP-programservrar. Den här programlastbalanseraren tillhandahåller tjänster för programlager (kallas skikt 7 i ISO-nätverksmodellen) som kan utföra SSL-avslutning och andra avlastningsfunktioner.

Azure Load Balancer är en tjänst på nätverksöverföringslager (lager 4) som balanserar trafik 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 på Azure 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 Azure Standard Load Balancer för alla SAP-scenarier. Om virtuella datorer i serverpoolen kräver offentliga utgående anslutningar, eller om de används i en Azure-zondistribution, kräver standardlastbalanserarna fler konfigurationer när de är säkra som standard. De tillåter inte utgående anslutningar om du inte uttryckligen konfigurerar den.

För trafik från SAP GUI-klienter som ansluter till en SAP-server via DIAG-protokoll eller Remote Function Calls (RFC) balanserar Central Services-meddelandeservern belastningen via inloggningsgrupperna för SAP-programservern. Du behöver ingen annan lastbalanserare.

Azure Storage

Vissa organisationer använder standardlagring för sina programservrar. Hanterade standarddiskar stöds inte. Se SAP-anteckning 1928533. (SAP Service Marketplace-konto krävs.) Vi rekommenderar att du använder Premium Azure-hanterade diskar i samtliga fall. Observera att en nyligen genomförd uppdatering av SAP 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. Om du gör det kan du också dra nytta av serviceavtalet för en virtuell dator med en instans om du har en central SAP-stackinstallation.

I scenarier med hög tillgänglighet är delade Azure-diskar tillgängliga på Premium SSD och Ultra SSD Azure-diskar. Du kan använda delade Azure-diskar med Windows Server, SUSE Linux Enterprise Server 15 SP1 och senare och SUSE Linux Enterprise Server för SAP.

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

För säkerhetskopieringsdatalagret rekommenderar vi åtkomstnivåer för cool och arkivi Azure. Dessa lagringsnivåer är ett kostnadseffektivt sätt att lagra långlivade data som inte används ofta.

Ultradiskar minskar avsevärt diskfördröjningen och drar nytta av prestandakritiska program som SAP-databasservrarna. Jämför blocklagringsalternativ i Azure.

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

Saker att tänka på gällande prestanda

SAP-programservrar kommunicerar ständigt med databasservrarna. För prestandakritiska program som körs på databasplattformar aktiverar Skrivningsaccelerator för loggvolymen. Detta kan förbättra svarstiden för loggskrivningar. Skrivningsaccelerator är tillgängligt för virtuella datorer i M-serien. Använd accelererat nätverk för att optimera kommunikationen mellan servrar. Accelererat nätverk är endast tillgängligt för VM-serier som stöds, inklusive D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 och Ms/Mms. Mer information finns i Maximera VM-prestanda med accelererat nätverk.

För att uppnå ett högt IOPS- och diskbandbreddsgenomflöde gäller vanliga metoder för optimering av lagringsvolymprestanda för Azure-lagringslayout. Du kan till exempel kombinera flera diskar för att skapa en stripe-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.

Ultradiskar är nu tillgängliga för I/O-krävande program. Om de är tillgängliga rekommenderar vi dem via Skrivningsaccelerator Premium Storage. Du kan öka eller minska prestandamått individuellt, till exempel IOPS och MBps, utan att behöva starta om.

För SAP på Azure ger Azure Virtual Machines planering och implementering för SAP NetWeaver utmärkta råd om hur du optimerar Azure Storage för SAP-arbetsbelastningar på SQL Server.

Vi rekommenderar inte placering av någon virtuell nätverksinstallation (NVA) mellan programmet och databasskikten för någon SAP-programstack. Den här praxis 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 prioriterar samplacering och prestanda framför skalbarhet, tillgänglighet eller kostnad. De kan avsevärt förbättra användarupplevelsen för de flesta SAP-program. Skript är tillgängliga på GitHub.

Tillgänglighetszoner

Tillgänglighetszoner kan du distribuera virtuella datorer mellan zoner. Det vill säga fysiskt avgränsade platser inom en specifik Azure-region. Syftet är att förbättra tjänstens tillgänglighet, men tänk på prestanda när du distribuerar resurser med zoner.

Administratörer behöver en tydlig profil för nätverksfördröjning 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.

Skalbarhetsöverväganden

För SAP-programlagret erbjuder Azure en mängd olika storlekar på virtuella datorer för uppskalning och utskalning. En inkluderande lista finns i SAP note 1928533 - SAP Applications on Azure: Supported Products and Azure VM Types ( SAP-anteckningslista – 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 SAP-programservrar och Central Services-kluster uppåt, nedåt eller ut genom att lägga till fler instanser. 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. För företag som har ett mindre strikt serviceavtal tillhandahåller virtuella Azure-datorer med en instans med premiumdiskar ett serviceavtal för drifttid. När du distribuerar redundanta resurser i en tillgänglighetsuppsättning Tillgänglighetszoner över flera platser, ökas tjänstens tillgänglighet.

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

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 DispatcherAzure Load Balancer antingen redundansklustret eller den parallella Web Dispatcher-konfigurationen.

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

Embedded Web Dispatcher på ASCS är ett särskilt alternativ. Du bör ta hänsyn till rätt storlek på grund av ytterligare arbetsbelastning på ASCS.

Centrala tjänster på programservernivån

Hög tillgänglighet för de centrala tjänsterna implementeras med Windows Server Failover Cluster (WSFC). När klusterlagringen för redundansklustret distribueras i Azure kan du konfigurera den på två sätt: som en klustrad delad volym eller som en filresurs.

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

WSFC stöder användning av filresurser som betjänas av Skalbar filserver som klusterlagring. Scale-Out filserver tillhandahåller elastiska filresurser som du kan använda som en klusterdelade volym (CSV) för Windows klustret. Du kan dela ett Scale-Out-filserverkluster mellan flera SAP Central Services-instanser.

När detta skrivs används Scale-Out-filserver endast för design med hög tillgänglighet inom en Azure-zon. (Distribution mellan zoner stöds inte.) För haveriberedskap stöder Azure Site Recovery replikering av hela filserverklustret Scale-Out till en fjärrregion.

Det finns två sätt att konfigurera kluster med delade diskar i 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-klustret.

Du kan också använda SIOS DataKeeper för att:

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

Mer information om implementeringen finns i Clustering SAP ASCS on Azure (Klustra SAP ASCS i Azure).

Med introduktionen av Azure Standard Load Balancer kan du nu helt enkelt aktivera porten med hög tillgänglighet. På så sätt kan du undvika att konfigurera belastningsutjämningsregler för många SAP-portar. När du ställer in lastbalanserare i allmänhet, oavsett om de är lokala eller i Azure, aktiverar du dessutom funktionen Direct Server Return (kallas även flytande IPeller DSR). På så sätt kan serversvar kringgå lastbalanseraren. Den här direkta anslutningen ser till att lastbalanseraren inte blir en flaskhals i dataöverföringens väg. För SAP ASCS och databaskluster rekommenderar vi att du aktiverar DSR.

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.

Databasnivå

För den här referensarkitekturen har vi förutsättt att källdatabasen körs på AnyDB. Det vill säga en DBMS som SQL Server, SAP ASE, IBM Db2 eller Oracle. Databasnivåns inbyggda replikeringsfunktion 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 distribuerats över Tillgänglighetszoner

Tillgänglighetszoner är en logisk konstruktion som utformats för att förbättra arbetsbelastningens tillgänglighet och skydda programtjänster och virtuella datorer mot datacenteravbrott. Virtuella datorer i en enda zon behandlas som om de fanns i en enda uppdaterings- eller feldomän. När du väljer zonindelade distribution distribueras virtuella datorer i samma zon till fel- och uppgraderingsdomäner efter bästa försök.

I Azure-regioner som stöder den här funktionen ä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 i flera olika zoner måste du känna till nätverksfördröjningen i en zon och mellan målzoner. Du måste också veta hur känsliga dina distribuerade program är för nätverksfördröjning.

Ta hänsyn till följande när du bestämmer dig för att distribuera resurser över Tillgänglighetszoner:

• Svarstid mellan virtuella datorer i en zon.

• Svarstid mellan virtuella datorer i valda zoner.

• Tillgänglighet för samma Azure-tjänster (typer av virtuella datorer) i de valda zonerna.

Exempel på aktiv/inaktiv distribution

I den här exempeldistributionen refererar statusen aktiv/passiv till programmets tjänsttillstånd i zonerna. I programlagret finns alla fyra aktiva programservrar 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 det behövs.

Kluster med två noder för centrala tjänster och databastjänsterna sträcker sig över två zoner. Om zon 1 misslyckas körs centrala tjänster och databastjänsterna i zon 2. De passiva programservrarna i zon 2 aktiveras. När alla komponenter i SAP-systemet nu är samplacerade i samma zon minimeras nätverksfördröjningen.

Exempel på aktiv/aktiv distribution

I en aktiv/aktiv distribution byggs två uppsättningar programservrar över två zoner. I varje zon är två programservrar i varje uppsättning servrar inaktiva (stäng av). Därför finns det aktiva programservrar i båda zonerna under normal drift.

Centrala tjänster 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 centrala tjänster och databastjänsterna på grund av det fysiska avståndet mellan zoner.

Om zon 1 går offline redundanskopplas centrala tjänster och databastjänsterna till zon 2. Du kan ta de vilande programservrarna online för att tillhandahålla fullständig kapacitet för programbearbetning.

Överväganden kring haveriberedskap

Varje nivå i SAP-programstacken använder en annan DR-strategi.

Programservernivå

SAP-programservrarna innehåller inga affärsdata. I Azure är en enkel DR-strategi att skapa SAP-programservrar i den sekundära regionen och sedan stänga av dem. Om det finns konfigurationsändringar eller kerneluppdateringar på den primära programservern måste du tillämpa samma ändringar på de virtuella datorerna i den sekundära regionen. Du kan till exempel kopiera de körbara SAP-kernelfilerna till de virtuella datorerna för dr.dr.

För automatisk replikering av programservrar till en sekundär region rekommenderar vi att du Azure Site Recovery. Du kan också använda Azure Site Recovery för att konfigurera dr dr för en SAP NetWeaver-programdistribution med flera steg.

Centrala tjänster

Den här komponenten i SAP-programstacken bevarar inte affärsdata. För DR-skydd replikerar du antingen /sapmnt-innehållet till en virtuell dator i vänteläge i DR-regionen eller använder Azure Site Recovery för att replikera både klustret för centrala tjänster och Scale-Out serverklustret. Du kan också använda Site Recovery för att replikera Central Services-klustret med hjälp av SIOS DataKeeper-diskar.

Du kan skapa en virtuell dator i DR-regionen för att replikera rollen och innehållet för de centrala tjänsterna. Det enda innehåll från den primära centrala tjänstnoden som ska synkroniseras är /sapmnt-resursen. Om konfigurationsändringarna eller kerneluppdateringarna sker på de primära centrala tjänstservrarna måste du upprepa ändringarna på den virtuella datorn i dr dr-regionen. Mer information om den här replikeringsmetodens bygg-, kopierings- och test redundansprocess finns i SAP NetWeaver: Building a Hyper-V and Microsoft Azure-based Disaster Recovery Solution ( SAP NetWeaver: Skapa en Hyper-V- Microsoft Azure-baserad haveriberedskapslösning. Se "4.3. SAP SPOF layer (ASCS) (SAP SPOF-lagret (ASCS)).

När du implementerar hög tillgänglighet för centrala tjänster med hjälp av Scale-Out-filserver eller SIOS, stöder Site Recovery replikering och återställning av både det centrala tjänstklustret och Scale-Out-filservern/Storage Space Direct-klustret. Du kan också replikera och återställa Central Services-klustret med hjälp av SIOS DataKeeper-diskar.

Databasnivå

Det är bäst att använda en databas integrerade replikeringsteknik för dr. Till exempel SQL Server rekommenderar vi att du använder Always On-tillgänglighetsgrupper för att upprätta en replik i en fjärrregion och replikera transaktioner asynkront med hjälp av manuell redundans. Asynkron replikering undviker påverkan på prestanda för interaktiva arbetsbelastningar på den primära platsen. När du använder en manuell redundans kan du utvärdera effekten av dr.dr och avgöra om drift från DR-platsen är berättigad.

Om du använder Azure NetApp Files för databaslagring kanske du kan använda replikering mellan regioner för att replikera data till en sekundär region. Den här funktionen är för närvarande i förhandsversion, så utvärdera om den uppfyller dina krav för produktionsarbetsbelastningar.

DR för delade tjänster

Många IT-tjänster, som administrativa jumpboxar, molnbaserade katalogtjänster, säkerhetskopierings- och övervakningstjänster, delas av alla dina distribuerade molntillgångar. Replikera dina delade tjänster till DR-regionen med hjälp av det som tjänsterna tillhandahåller.

Automatiserad dr med Azure Site Recovery

Om du Azure Site Recovery att automatiskt skapa en fullständigt replikerad produktionsplats för den ursprungliga konfigurationen måste du köra anpassade distributionsskript. Till exempel Site Recovery först de virtuella datorerna i tillgänglighetsuppsättningar. Den kör sedan dina anpassade skript för att koppla den befintliga (fördefinierade) lastbalanseraren, där serverpoolen redan har definierats, till nätverkskortet för de virtuella redundansdatorerna. Ett exempel på det anpassade Site Recovery Automation Runbooks-skriptet finns på GitHub.

Överväganden för hantering och åtgärder

Backup

Databaser är kritiska arbetsbelastningar som kräver ett lågt mål för å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 SQL Server databaser som körs på virtuella datorer. Ett annat alternativ är att Azure Files ögonblicksbilder för att SQL Server databasfiler.

• Information om SAP på Oracle/Windows finns i avsnittet "Säkerhetskopiering/återställning" i Azure VM DBMS Deployment for SAP (Azure VM DBMS-distribution för SAP).

• För andra databaser, se säkerhetskopieringsrekommendationerna för din databasleverantör. Om databasen har stöd för Windows tjänsten Volume Shadow Copy (VSS) kan program konsekventa säkerhetskopieringar med VSS-ögonblicksbilder

Identitetshantering

Använd ett centraliserat identitetshanteringssystem 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 Lightweight Directory Access Protocol (LDAP), Azure Active Directory, 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 Azure Active Directory.

Övervakning

Azure Monitor avancerade verktyg för att samla in och analysera telemetri. De här verktygen hjälper dig att maximera prestanda och tillgänglighet för dina molnresurser och lokala resurser och program. (Azure Monitor innehåller nu Log Analytics och Application Insights.) Du kan använda Azure Monitor för att övervaka infrastruktur- och programavvikelser, aviseringsadministratörer och automatisera reaktioner på fördefinierade villkor.

Om du vill tillhandahålla SAP-baserad övervakning av resurser och tjänstprestanda för SAP-infrastrukturen använder du tillägget Azure SAP Enhanced Monitoring. Det här tillägget skickar övervakningsstatistik för Azure till SAP-programmet för övervakning av operativsystemet och DBA Cockpit-funktioner. Sap Enhanced Monitoring krävs för att köra SAP på Azure. Mer information finns i SAP note 2191498, "SAP on Linux with Azure: Enhanced Monitoring". (För att få åtkomst till SAP-anteckningar behöver du ett SAP Service Marketplace-konto.)

Azure Monitor för SAP-lösningar är framtidens riktning för en Azure-intern övervakningslösning från hela till slutet för SAP NetWeaver. Den här lösningen är för närvarande i förhandsversion och är endast tillgänglig i en begränsad uppsättning regioner. Du bör noggrant utvärdera om det uppfyller dina krav.

Azure Monitor för SAP-lösningar innehåller en omfattande inledande uppsättning mått och telemetri för övervakning. Måttdefinitionerna lagras som SQL frågor i JSON. Du kan ändra dem så att de uppfyller dina krav. Du kan hämta startuppsättningen med mått på GitHub.

Säkerhetsöverväganden

SAP har en egen användarhanteringsmotor (UME) som styr rollbaserad åtkomst och auktorisering i SAP-programmet och databaserna. Detaljerade riktlinjer för programsäkerhet finns i säkerhetsguiden för SAP NetWeaver.

För ytterligare nätverkssäkerhet bör du överväga att använda ett perimeternätverk som använder en virtuell nätverksinstallation (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 också routningsreglerna som konfigurerats i undernätet och undvik att dirigera trafik till en nva med en instans. Detta kan leda till avbrott i underhåll och nätverks- eller klusternodfel.

För infrastruktursäkerhet krypteras data under överföring och i vila. Avsnittet "Säkerhetsrekommendationer" i Azure Virtual Machines planering och implementering för SAP NetWeaver hanterar nätverkssäkerhet. Den här artikeln anger också 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 Windows virtuella datordiskar. Den 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 som hjälper dig att kontrollera och hantera diskkrypteringsnycklarna och hemligheterna i din nyckelvalvsprenumeration. Data på diskar i virtuella datorer krypteras i vila i din Azure-lagring.

För kryptering av vilodata krypterar SQL Server transparent datakryptering (TDE) SQL Server, Azure SQL Database och Azure SQL Data Warehouse datafiler. Mer information finns i SQL Server Azure Virtual Machines DBMS deployment for SAP NetWeaver.

Se som alltid till att hantera säkerhetsuppdateringar och korrigeringar för att skydda dina informationstillgångar. Överväg att använda en automatiseringsmetod från slutet till slut 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 bör du överväga att använda en av de begränsade virtuella datorstorlekarna för virtuell processor för att minska programvarulicensieringskostnaderna per virtuell processor.

Virtuella datorer

Den här arkitekturen använder virtuella datorer för programnivån och databasnivån. SAP NetWeaver-nivån använder Windows 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 jumpboxar för hantering.

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

• För arbetsbelastningar som inte har någon förutsägbar tid för slutförande eller resursförbrukning kan du överväga alternativet betala per användning.

• Överväg att använda Azure-reservationer om du kan åta dig att använda en virtuell dator under ett eller tre år. VM-reservationer kan minska kostnaderna med så mycket 72 procent som jämfört med betala per användning-priser.

Använd Azure Spot Virtual Machines för att köra arbetsbelastningar som kan avbrytas och inte kräver slutförande inom en fördefinierad tidsram eller ett serviceavtal. Azure distribuerar virtuella datorer för VM med plats när det finns tillgänglig kapacitet och tar bort dem när den behöver kapaciteten tillbaka. Kostnaderna för virtuella datorer för VM med vm med vm med Överväg virtuella spot-datorer för dessa arbetsbelastningar:

• Databehandlingsscenarier med höga prestanda, batchbearbetningsjobb eller program för visuell rendering.
• Testmiljöer, inklusive arbetsbelastningar för kontinuerlig integrering och kontinuerlig leverans.
• Storskaliga tillståndslösa program.

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

Virtuella datorer och tillgänglighetsuppsättningar

För alla pooler och kluster (Web Dispatcher, SAP-programservrar, centrala tjänster och databasen) grupperas de virtuella datorerna i separata tillgänglighetsuppsättningar. Tillgänglighetsuppsättningar kostar ingenting. Du betalar bara för varje VM-instans som du skapar.

Om du distribuerar en arbetsbelastning över Tillgänglighetszoner krävs inte tillgänglighetsuppsättningar.

Azure Load Balancer

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

Du debiteras bara för antalet konfigurerade regler för belastningsutjämning och utgående trafik. Ingående NAT-regler är kostnadsfria. Det debiteras ingen timkostnad för Standard Load Balancer 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å ett förbestämt pris. Se Azure ExpressRoute för mer information.

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

• Support av Azure-communityn

• SAP Community

• Stack Overflow för SAP

Relaterade resurser

I de här artiklarna finns mer information och exempel på SAP-arbetsbelastningar som använder samma teknik:

• Azure Virtual Machines planering och implementering för SAP NetWeaver

• Använda Azure som värd för och köra SAP-arbetsbelastningsscenarier

• Köra SAP-produktionsarbetsbelastningar med en Oracle Database på Azure

• Utvecklings-/testmiljöer för SAP-arbetsbelastningar på Azure