Köra SAP HANA i Azure (stora instanser)

Den här referensarkitekturen visar en uppsättning beprövade metoder för att köra SAP HANA på Azure (stora instanser) med hög tillgänglighet (HA) och haveriberedskap (DR). Det här erbjudandet kallas HANA Large Instances (HLI) och distribueras på fysiska servrar i Azure-regioner. Den här lösningen visar ett enkelt uppskalningsscenario för att demonstrera grundläggande begrepp i distributionen och driften av ett SAP HANA-system i Azure. Alternativ finns i andra installationsscenarier för STORA HANA-instanser.

Arkitektur

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

Arbetsflöde

Den här arkitekturen består av följande infrastrukturkomponenter.

• Virtuellt nätverk. Tjänsten Azure Virtual Network (VNet) ansluter på ett säkert sätt Azure-resurser till varandra och delas upp i separata undernät för varje lager. SAP-programlager distribueras på virtuella Azure-datorer (VM) för att ansluta till HANA-databasskiktet som finns på stora instanser.

• HLI Revision 4.5-nätverk. Från och med juli 2021 är den uppdaterade revisionen av HLI Rev 4 tillgänglig. Den uppdaterade implementeringen [rev4.5] innehåller många förbättringar i infrastrukturen, till exempel 100 Gb/s-nätverk för NFS-lagringen och bättre nätverksredundans för DB-servern. I den här designen distribueras HLI-servrarna i Azure-datacenter i nära fysisk närhet till de virtuella Azure-datorer där SAP-programservrarna körs. När den används tillsammans med en [ExpressRoute FastPath][fastpath]-konfiguration höjer Rev 4.5 programprestanda. Dessa nätverksfunktioner stöder även distributionerna Rev 3 och Rev 4.

• Virtuella datorer (VM) . Virtuella datorer används i SAP-programskiktet och det delade tjänstskiktet. Den senare innehåller en hoppruta som används av administratörer för att konfigurera hana-stora instanser och för att ge åtkomst till andra virtuella datorer. Om du vill samplacera SAP-programservrarna i samma datacenter med HANA Large Instance-enheterna använder du närhetsplaceringsgrupper.

• HANA Stor instans. Den här fysiska servern är certifierad för att uppfylla SAP HANA:s standarder för anpassad datacenterintegrering (TDI) för körning av SAP HANA. Den här arkitekturen använder två stora HANA-instanser: en primär och en sekundär beräkningsenhet. Hög tillgänglighet på datalagret tillhandahålls via HANA System Replication (HSR).

• Par med hög tillgänglighet. En grupp hana-blad för stora instanser hanteras tillsammans för att tillhandahålla databasredundans och tillförlitlighet.

• Microsoft Enterprise Edge (MSEE). MSEE är en anslutningspunkt från en anslutningsleverantör eller din nätverksgräns via en ExpressRoute-krets.

• Nätverkskort (NIC). För att aktivera kommunikation tillhandahåller HANA Large Instance-servern fyra virtuella nätverkskort som standard. Den här arkitekturen kräver ett nätverkskort för klientkommunikation, ett andra nätverkskort för den nod-till-nod-anslutning som krävs av HSR, ett tredje nätverkskort för HANA Large Instance Storage och ett fjärde för iSCSI som används i klustring med hög tillgänglighet.

• NFS-lagring (Network File System). NFS-servern stöder nätverksfilresursen som ger säker datapersistence för HANA Large Instance.

• ExpressRoute. ExpressRoute är den rekommenderade Azure-nätverkstjänsten för att skapa privata anslutningar mellan ett lokalt nätverk och virtuella Azure-nätverk som inte går via det offentliga Internet. Virtuella Azure-datorer ansluter till STORA HANA-instanser med en annan ExpressRoute-anslutning. ExpressRoute-anslutningen mellan det virtuella Azure-nätverket och de stora HANA-instanserna konfigureras som en del av Microsoft-erbjudandet.

• Gateway. ExpressRoute Gateway används för att ansluta det virtuella Azure-nätverk som används för SAP-programskiktet till HANA Large Instance-nätverket. Använd SKU: n med höga prestanda eller ultraprestanda .

• Haveriberedskap (DR). Alternativen för DR är HANA System Replication (HSR), HANA-filsäkerhetskopiering och återställning eller lagringsreplikering. På begäran kan Microsoft Service Management-teamet konfigurera lagringsservrar och volymer. Du ansvarar för att schemalägga ögonblicksbilden av lagringen, testa systemet och bekanta dig med återställningsprocessen. Andra överväganden gäller programnivån för SAP NetWeaver och SAP S/4HANA i Azure.

Rekommendationer

Kraven kan variera, så använd dessa rekommendationer som utgångspunkt.

BERÄKNING AV STORA HANA-instanser

STORA HANA-instanser är fysiska servrar baserade på Processorarkitekturen Intel Broadwell och Cascade Lake och konfigureras i en stor instansstämpel, dvs. en specifik uppsättning servrar eller blad. En beräkningsenhet är lika med en server eller ett blad, och en stämpel består av flera servrar eller blad. Inom en stor instansstämpel delas inte servrar och är dedikerade till att köra en kunds distribution av SAP HANA.

En mängd olika SKU:er är tillgängliga för STORA HANA-instanser med stöd för upp till 24 TB enkel instans (120 TB utskalning) minne för BW/4HANA eller andra SAP HANA-arbetsbelastningar.

Välj en SKU som uppfyller storlekskraven som du fastställde i dina arkitektur- och designsessioner. Se alltid till att storleken gäller för rätt SKU. Funktionerna och distributionskraven varierar beroende på typ, och tillgängligheten varierar beroende på region. Du kan också stega upp från en SKU till en större SKU.

Microsoft hjälper till att upprätta konfigurationen av den stora instansen, men det är ditt ansvar att verifiera operativsystemets konfigurationsinställningar. Se till att granska de senaste SAP-anteckningarna för din exakta Linux-version.

Lagring

Lagringslayouten implementeras enligt rekommendationen för TDI för SAP HANA. HANA Large Instances levereras med en specifik lagringskonfiguration för standard-TDI-specifikationerna. Du kan dock köpa ytterligare lagringsutrymme i steg om 1 TB.

För att stödja kraven i verksamhetskritiska miljöer, inklusive snabb återställning, används NFS och inte direktansluten lagring. NFS-lagringsservern för STORA HANA-instanser finns i en miljö med flera klientorganisationer, där klientorganisationer är åtskilda och skyddade med hjälp av beräknings-, nätverks- och lagringsisolering.

Om du vill ha stöd för hög tillgänglighet på den primära platsen använder du olika lagringslayouter. I en utskalning med flera värdar delas till exempel lagringen. Ett annat alternativ för hög tillgänglighet är programbaserad replikering, till exempel HSR. För DR används dock en ögonblicksbildsbaserad lagringsreplikering.

Nätverk

Den här arkitekturen använder både virtuella och fysiska nätverk. Det virtuella nätverket är en del av Azure Infrastructure as a Service (IaaS) och ansluter till ett diskret fysiskt HANA Large Instances-nätverk via ExpressRoute-kretsar . En lokal gateway ansluter dina arbetsbelastningar i det virtuella Azure-nätverket till dina lokala platser.

Alla HANA Large Instance-distributioner sedan juli 2019 använder Rev 4-stämplar, som distribueras i närheten av de Virtuella Azure-värdar som används för SAP-programservrarna. Därför minimerar Rev 4-distributionen nätverksfördröjningen mellan program- och databasskikten.

HANA Stora instansnätverk är isolerade från varandra för säkerhet. Instanser som finns i olika regioner kommunicerar inte med varandra, förutom för den dedikerade lagringsreplikeringen. För att kunna använda HSR krävs dock kommunikation mellan regioner. [Azure Global Reach] [globalreach], IP-routningstabeller eller proxyservrar kan användas för att aktivera HSR för flera regioner.

Alla virtuella Azure-nätverk som ansluter till STORA HANA-instanser i en region kan korsanslutas via ExpressRoute till HANA Large Instances i en sekundär region.

ExpressRoute-kretsen för STORA HANA-instanser ingår som standard under etableringen. För konfiguration krävs en specifik nätverkslayout, inklusive obligatoriska CIDR-adressintervall (Classless Inter-Domain Routing) och domänroutning. Mer information finns i INFRASTRUKTUR och anslutning för SAP HANA (stora instanser) i Azure.

Om du vill sänka nätverksfördröjningen och förbättra prestandan kan du överväga att aktivera FastPath (kallas även MSEE v2). Med den här nätverkskonfigurationen kan trafik från lokalt till det virtuella Azure-nätverket och från det virtuella nätverket till HANA Large Instances kringgå Azure-gatewayen.

Att tänka på

Skalbarhet

Om du vill skala upp eller ned kan du välja bland många storlekar på servrar som är tillgängliga för STORA HANA-instanser. De kategoriseras som typ I och typ II och skräddarsys för olika arbetsbelastningar. Välj en storlek som kan växa med din arbetsbelastning under de kommande tre åren. Det finns också ett års åtaganden.

En distribution med flera värdar används vanligtvis för BW/4HANA-distributioner som en typ av strategi för databaspartitionering. När detta skrivs kan BW/4HANA på STORA HANA-instanser skalas ut till 120 TB. Om du vill skala ut planerar du placeringen av HANA-tabeller före installationen. Från infrastruktursynpunkt är flera värdar anslutna till en delad lagringsvolym, vilket möjliggör snabb övertagande av väntelägesvärdar om en av beräkningsarbetsnoderna i HANA-systemet misslyckas.

S/4HANA och SAP Business Suite på HANA på ett enda blad kan skala upp till 24 TB med en nod med en enda instans. HANA Large Instances och Azure Storage-infrastrukturen har också stöd för utskalningsdistributioner av S/4HANA och BW/4HANA. Specifika SKU:er som är certifierade för utskalning finns i [SAP-certifierad maskinvarukatalog][directory].

Minneskraven för HANA ökar när datavolymen växer. Använd systemets aktuella minnesförbrukning som grund för att förutsäga framtida förbrukning och mappa sedan din efterfrågan till en av HANA Large Instances-storlekarna.

Om du redan har SAP-distributioner tillhandahåller SAP rapporter som du kan använda för att kontrollera de data som används av befintliga system och beräkna minneskraven för en HANA-instans. Se till exempel följande SAP-anteckningar (åtkomst kräver ett SAP Service Marketplace-konto):

• SAP Note 1793345 – Storleksändring för SAP Suite på HANA
• SAP Note 1872170 – Svit på HANA- och S/4 HANA-storleksrapport
• SAP Note 2121330 – Vanliga frågor och svar: SAP BW på HANA Sizing Report
• SAP Note 1736976 – Storleksrapport för BW på HANA
• SAP Note 2296290 – Ny storleksrapport för BW på HANA

Tillgänglighet

Resursredundans är det allmänna temat i infrastrukturlösningar med hög tillgänglighet. Arbeta med SAP, din systemintegrerare eller Microsoft för att korrekt utforma och implementera en strategi för hög tillgänglighet och haveriberedskap . Den här arkitekturen följer Azure Service Level Agreement (SLA) för HANA på Azure (stora instanser). Om du vill utvärdera dina tillgänglighetskrav bör du överväga enskilda felpunkter, önskad drifttid för tjänster och dessa vanliga mått:

• Mål för återställningstid (RTO) innebär hur lång tid hana-servern för stora instanser inte är tillgänglig.

• Mål för återställningspunkt (RPO) innebär den maximala tillåtna perioden då kunddata kan gå förlorade på grund av ett fel.

För hög tillgänglighet distribuerar du mer än en instans i ett HA-par och använder HSR i synkront läge för att minimera dataförlust och stilleståndstid. Utöver en lokal installation med hög tillgänglighet med två noder stöder HSR replikering på flera nivåer, där en tredje nod i en separat Azure-region registreras till den sekundära repliken av det klustrade HSR-paret som replikeringsmål. Detta utgör en replikeringskedja.

Redundansväxlingen till DR-noden är en manuell process utan Linux-klustring. För automatisk felidentifiering och redundansväxling kan du konfigurera Pacemaker för ytterligare lägre stilleståndstid som orsakas av programvaru- eller maskinvarufel. Från och med HANA 2.0 SPS 04 stöder HSR även replikering med flera mål. I stället för en daisy-kedja har den här typen av replikering en primär och flera sekundära prenumeranter.

När du konfigurerar HANA Large Instances HSR med automatisk redundans kan du be Microsoft Service Management-teamet att konfigurera en STONITH-enhet för dina HANA Large Instances-servrar.

Haveriberedskap

Den här arkitekturen stöder haveriberedskap mellan STORA HANA-instanser i olika Azure-regioner. Det finns två sätt att stödja DR med STORA HANA-instanser:

• Lagringsreplikering. Det primära lagringsinnehållet replikeras ständigt till de fjärranslutna DR-lagringssystemen som är tillgängliga på den avsedda DR HANA Large Instances-servern. I lagringsreplikeringen läses HANA-databasen inte in i minnet. Det här dr-alternativet är enklare ur ett administrationsperspektiv. Om du vill avgöra om detta är en lämplig strategi bör du överväga databasens inläsningstid mot tillgänglighets-SLA: et. Med lagringsreplikering kan du också utföra återställning till tidpunkt. Om dr för flera syften (kostnadsoptimerad) har konfigurerats måste du köpa ytterligare lagringsutrymme av samma storlek på dr-platsen. Microsoft tillhandahåller ögonblicksbilder av självbetjäningslagring och redundansskript för HANA-redundans som en del av HANA Large Instances-erbjudandet.

• HSR med flera nivåer eller flera mål med en tredje replik i DR-regionen (där HANA-databasen läses in på minnet). Det här alternativet stöder en snabbare återställningstid men stöder inte återställning till tidpunkt. HSR kräver ett sekundärt system. HANA-systemreplikeringstrafik som är avsedd för DR-platsen kan dirigeras via proxyservrar som nginx- eller IP-tabeller. Alternativt kan Global Reach användas för att länka samman ExpressRoute-kretsarna, vilket gör att tillåtna användare kan ansluta till HANA Large Instances-enheten direkt.

Kostnadsoptimering

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

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

SKU:er kan påverka faktureringsmodellen. Här följer några kostnadsöverväganden.

Virtuella datorer

I den här referensarkitekturen används virtuella datorer för att hantera SAP-program, SAP-tjänster och delade tjänster, till exempel hopprutor för hantering. Det finns vissa certifierade SKU:er för STORA HANA-instanser. Konfigurationerna beror på arbetsbelastning, CPU-resurser, önskat minne och budget.

SKU:er för STORA HANA-instanser är tillgängliga som reserverade VM-instanser. Azure-reservationer kan sänka din kostnad om du kan checka in på ett eller tre års period. Vm-reservationer kan minska kostnaderna med upp till 72 procent jämfört med betala per användning-priser. Du får en specialbyggd SAP HANA-infrastruktur med beräkning, lagring och nätverk. HANA Large Instances är kopplat till NFS-lagring och nätverk och ger inbyggt stöd för säkerhetskopieringar via ögonblicksbilder av lagring, hög tillgänglighet och haveriberedskap och utskalningskonfigurationer. Om din arbetsbelastning inte har en förutsägbar tid för slutförande eller resursförbrukning bör du överväga alternativet betala per användning.

Använd Översikt över Azure-sparplan och kombinera med Azure-reservationer. Azure-sparplanen är en flexibel kostnadsbesparande plan som genererar betydande besparingar jämfört med betala per användning-priser. Du godkänner ett ett- eller treårskontrakt och får rabatter på berättigade beräkningstjänster. Besparingarna gäller för dessa beräkningstjänster oavsett region, instansstorlek eller operativsystem. Mer information finns i dokumentationen om Azure-sparplan.

Använd virtuella Azure Spot-datorer för att köra arbetsbelastningar som kan avbrytas och som inte kräver slutförande inom en fördefinierad tidsram eller ett serviceavtal.

Mer information finns i avsnittet "SAP HANA on Azure Large Instances" i HLI for SAP HANA Virtual Machines Pricing (Priser för virtuella SAP HANA-datorer).

Azure ExpressRoute

För den här arkitekturen används Azure ExpressRoute som nätverkstjänst för att skapa privata anslutningar mellan ett lokalt nätverk och virtuella Azure-nätverk. Virtuella Azure-datorer ansluter till STORA HANA-instanser med en annan ExpressRoute-anslutning och en ExpressRoute-gateway. Höga prestanda eller ultraprestanda är den rekommenderade SKU:n.

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.

Backup

Välj bland flera tillgängliga alternativ baserat på dina affärsbehov.

Mer information om en gör-det-själv-metod för säkerhetskopiering och fler alternativ som tillhandahålls med STORA HANA-instanser finns i artikeln [Säkerhetskopiering och återställning][säkerhetskopieringsåterställning].

Hanterbarhet

Övervaka HANA-resurser för stora instanser, till exempel CPU, minne, nätverksbandbredd och lagringsutrymme, med hjälp av SAP HANA Studio, SAP HANA Cockpit, SAP Solution Manager och andra inbyggda Linux-verktyg. HANA Large Instances Type I SKU:er levereras inte med inbyggda övervakningsverktyg. Typ II SKU:er erbjuder fördefinierade diagnostikverktyg för systemaktivitetsloggning och felsökning.

Microsoft erbjuder grundläggande verktyg och resurser som hjälper dig att övervaka STORA HANA-instanser i Azure. Microsofts supportteam kan också hjälpa dig att felsöka tekniska problem.

Säkerhet

• Sedan slutet av 2018 krypteras HANA Large Instances-lagring som standard.

• Data under överföring mellan STORA HANA-instanser och virtuella datorer krypteras inte. Om du vill kryptera dataöverföringen aktiverar du den programspecifika krypteringen. Se SAP Note 2159014 – Vanliga frågor och svar: SAP HANA Security.

• Isolering ger säkerhet mellan klienterna i hana-miljön för stora hana-instanser med flera klientorganisationer. Klientorganisationer isoleras med hjälp av sitt eget VLAN.

• Metodtips för Azure-nätverkssäkerhet ger användbar vägledning.

• Precis som med all distribution rekommenderas härdning av operativsystem, inklusive härdning av SUSE Linux-avbildningen för SAP i Azure.

• För fysisk säkerhet är åtkomsten till Azure-datacenter begränsad till endast behörig personal. Inga kunder kan komma åt de fysiska servrarna.

Mer information finns i SAP HANA Security – En översikt. (Ett SAP Service Marketplace-konto krävs för åtkomst.)

Communities

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

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

Deltagare

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

Huvudförfattare:

• Ben Trinh | Huvudarkitekt

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

Relaterade resurser

Du kanske vill granska följande Azure-exempelscenarier som demonstrerar specifika lösningar med hjälp av samma tekniker:

• Köra SAP-produktionsarbetsbelastningar med hjälp av en Oracle Database på Azure
• Utvecklings-/testmiljöer för SAP-arbetsbelastningar i Azure