Kör SAP HANA för virtuella Linux-datorer i en skalbar arkitektur på Azure

Den här referensarkitekturen visar en uppsättning beprövade metoder för att köra SAP HANA i en uppskalningsmiljö med hög tillgänglighet som stöder haveriberedskap i Azure. Den här implementeringen fokuserar endast på databasskiktet.

Arkitektur

Den här referensarkitekturen beskriver ett vanligt produktionssystem. Du kan välja storlekar för virtuella datorer för att tillgodose organisationens behov. Den här konfigurationen kan också reduceras till en virtuell dator, beroende på affärskrav.

Följande diagram visar en referensarkitektur för SAP HANA i Azure:

Ladda ned en Visio-fil som innehåller diagrammen i den här artikeln.

Arbetsflöde

Den här referensarkitekturen beskriver en typisk SAP HANA-databas som körs 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 ExpressRoute-gateway som distribueras i hubben för en hubb-ekertopologi. SAP HANA-databasen finns i ett eget virtuellt ekernätverk. De virtuella ekernätverken innehåller ett undernät för de virtuella databasdatorerna (VM).

Om program som ansluter till SAP HANA körs på virtuella datorer bör de virtuella programdatorerna finnas i samma virtuella nätverk men i ett dedikerat programundernät. Om SAP HANA-anslutningen inte är den primära databasen kan de virtuella programdatorerna också finnas i andra virtuella nätverk. Genom att dela upp i undernät efter arbetsbelastning blir det enklare att aktivera nätverkssäkerhetsgrupper (NSG) för att ange säkerhetsregler som endast gäller för virtuella SAP HANA-datorer.

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. 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. De IP-adresser som används måste vara standard-SKU för en zondistribution av gatewayerna.

Nätverkssäkerhetsgrupper (NSG). Om du vill begränsa inkommande och utgående nätverkstrafik för 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 (ASG). 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 nätverksgränssnitt för 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 inte nödvändigt att använda flera nätverkskort av prestandaskäl. Flera nätverkskort delar samma nätverksflödesgräns för en virtuell dator. 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). Azure erbjuder en nodskalning på upp till 23,5 Tebibyte (TiB) minne på virtuella datorer. SAP Certified and Supported SAP HANA Hardware Directory listar de virtuella datorer som är certifierade för SAP HANA-databasen. Mer information om SAP-stöd för typer av virtuella datorer och dataflödesmått (SAPS) finns i SAP Note 1928533 – SAP-program på Microsoft Azure: Produkter som stöds och typer av virtuella Azure-datorer. (För att få åtkomst till den här och andra SAP-anteckningar krävs ett SAP Service Marketplace-konto.)

Microsoft och SAP certifierar gemensamt en rad storlekar för virtuella datorer för SAP HANA-arbetsbelastningar. Mindre distributioner kan till exempel köras på en virtuell Edsv4 - eller Edsv5-dator med 160 GiB eller mer RAM-minne. Om du vill ha stöd för de största SAP HANA-minnesstorlekarna på virtuella datorer, så mycket som 23 TiB, kan du använda virtuella datorer i Mv2-serien . Typer av virtuella M208-datorer uppnår cirka 260 000 SAPS och virtuella M832ixs-datortyper ger cirka 795 900 SAPS.

Virtuella datorer i generation 2 (Gen2). När du distribuerar virtuella datorer kan du använda antingen virtuella datorer av generation 1 eller generation 2. Virtuella datorer i generation 2 stöder viktiga funktioner som inte är tillgängliga för virtuella datorer i generation 1. För SAP HANA är detta särskilt viktigt eftersom vissa VM-familjer, som Mv2 och 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 HANA tillåter valet av endast Gen2 eller Gen1+2 selektivt rekommenderar vi att du distribuerar alla virtuella SAP-datorer endast som Gen2. Detta gäller även för virtuella datorer med låga minnesbehov. Även den minsta virtuella Datorn Med 160 GiB SAP HANA kan köras som en virtuell Gen2-dator och när den frigörs kan den storleksändras till den största virtuella datorn som är tillgänglig i din region och prenumeration.

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 svarstiden mellan SAP HANA och ansluta virtuella programdatorer. För själva SAP HANA-arkitekturen behövs inga PPG:er, de är bara ett alternativ för att samplacera SAP HANA med virtuella datorer på programnivå. 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. Eftersom PPG:er begränsar arbetsbelastningar till ett enda datacenter kan en PPG inte omfatta flera tillgänglighetszoner.

Komponenter

• Azure Virtual Network
• Azure ExpressRoute
• Azure Virtual Machines
• Azure NetApp Files
• Azure Load Balancer
• Azure Disk Storage

Att tänka på

I det här avsnittet beskrivs viktiga överväganden för att köra SAP HANA på Azure.

Skalbarhet

Den här arkitekturen kör SAP HANA på virtuella datorer som kan skala upp till 23 TiB i en instans.

Om din arbetsbelastning överskrider den maximala storleken på den virtuella datorn rekommenderar vi att du använder HANA-konfigurationer med flera noder. För OLTP-program (Online Transaction Processing) kan den totala utskalningskapaciteten vara så hög som 4 x 23 TiB. För OLAP-program (Online Analytical Processing) kan kapaciteten för utskalningsminne vara så hög som 16 x 7,6 TiB. Du kan till exempel distribuera SAP HANA i en utskalningskonfiguration med vänteläge på virtuella datorer – som kör antingen Red Hat Enterprise Linux eller SUSE Linux Enterprise Server – med Hjälp av Azure NetApp Files för delade lagringsvolymer.

Lagring

Den här arkitekturen använder Azure-hanterade diskar för lagring på de virtuella datorerna eller Azure NetApp Files. Riktlinjer för lagringsdistribution med hanterade diskar finns i detalj i dokumentet konfigurationer för SAP HANA Azure Virtual Machine Storage. Alternativt till hanterade diskar kan Azure NetApp Files NFS-volymer användas som lagringslösning för SAP HANA.

För att uppnå höga in-/utdataåtgärder per sekund (IOPS) och dataflöde för disklagring gäller även de vanliga metoderna för prestandaoptimering av lagringsvolymer för Azure Storage-layout. Om du till exempel kombinerar flera diskar med LVM för att skapa en randig diskvolym förbättras I/O-prestanda. Cachelagring av Azure-diskar spelar också en viktig roll för att uppnå nödvändiga I/O-prestanda.

För SAP HANA-loggdiskar som körs på Azure Premium SSD v1 använder du någon av följande tekniker på platser som innehåller /hana/log för produktion:

• Skrivaccelerator (på virtuella datorer i M-serien)
• Ultradiskar (på antingen virtuella datorer i M- eller E-serien)
• Azure NetApp Files (på virtuella datorer i M- eller E-serien)

Dessa tekniker behövs för att konsekvent uppfylla den nödvändiga lagringsfördröjningen på mindre än 1 ms.

Azure Premium SSD v2 är utformat för prestandakritiska arbetsbelastningar som SAP. Skrivaccelerator krävs inte när /hana/log körs på Premium SSD v2. Information om den här lagringslösningens fördelar och aktuella begränsningar finns i Distribuera en Premium SSD v2.

Mer information om prestandakrav för SAP HANA finns i SAP Note 1943937 – Kontrollverktyget för maskinvarukonfiguration.

• Kostnadsmedveten lagringsdesign för icke-produktionssystem. För SAP HANA-miljöer som inte kräver maximal lagringsprestanda i alla situationer kan du använda en lagringsarkitektur som är optimerad för kostnad. Det här valet av lagringsoptimering kan gälla för lite använda produktionssystem eller vissa SAP HANA-miljöer som inte är produktionsbaserade. Det kostnadsoptimerade lagringsalternativet använder en kombination av Standard SSD i stället för Premium- eller Ultra SSD som används för produktionsmiljöer. Den kombinerar även filsystemen /hana/data och /hana/log på en enda uppsättning diskar. Riktlinjer och metodtips är tillgängliga för de flesta VM-storlekar. Om du använder Azure NetApp Files för SAP HANA kan du använda storleksreducerade volymer för att uppnå samma mål.

• Ändra storlek på lagring vid uppskalning. När du ändrar storlek på en virtuell dator på grund av ändrade affärsbehov eller på grund av en växande databasstorlek kan lagringskonfigurationen ändras. Azure stöder onlinediskexpansion, utan avbrott i tjänsten. Med en randig diskkonfiguration, som används för SAP HANA, bör en storleksändringsåtgärd utföras på samma sätt som alla diskar i volymgruppen. Att lägga till fler diskar i en volymgrupp kan eventuellt obalansera de randiga data. Om du lägger till fler diskar i en lagringskonfiguration är det mycket bättre att skapa en ny lagringsvolym på nya diskar. Kopiera sedan innehållet under stilleståndstid och ändra monteringspunkter. Slutligen tar du bort den gamla volymgruppen och underliggande diskar.

• Azure NetApp Files-programvolymgrupp. För distributioner med SAP HANA-filer som finns på Azure NetApp Files NFS-volymer gör programvolymgrupper att du kan distribuera alla volymer enligt bästa praxis. Den här processen säkerställer också optimala prestanda för din SAP HANA-databas. Information finns om hur du fortsätter med den här processen. Det kräver manuella åtgärder. Tillåt lite tid för skapandet.

Hög tillgänglighet

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

Lastbalanserare.Azure Load Balancer används för att distribuera trafik till virtuella SAP HANA-datorer. När du införlivar Azure Load Balancer i en zonindelad distribution av SAP kontrollerar du att du väljer standard-SKU-lastbalanseraren. Basic SKU-balanseraren stöder inte zonredundans. I den här arkitekturen fungerar Load Balancer som den virtuella IP-adressen för SAP HANA. Nätverkstrafik skickas till den aktiva virtuella datorn där den primära databasinstansen körs. SAP HANA-aktiv/läsaktiverad arkitektur är tillgänglig (SLES/RHEL) där en andra virtuell IP-adress som adresseras på lastbalanseraren används för att dirigera nätverkstrafik till den sekundära SAP HANA-instansen på en annan virtuell dator för läsintensiva arbetsbelastningar.

Standard Load Balancer tillhandahåller ett säkerhetslager som standard. Virtuella datorer som ligger bakom Standard Load Balancer har inte utgående Internetanslutning. Om du vill aktivera utgående Internet på dessa virtuella datorer måste du uppdatera standardkonfigurationen för lastbalanseraren . Dessutom kan du också använda en Azure NAT Gateway för att få utgående anslutning.

För SAP HANA-databaskluster måste du aktivera Direct Server Return (DSR), även kallat flytande IP. Med den här funktionen kan servern svara på IP-adressen för lastbalanserarens klientdel. Den här direktanslutningen gör att lastbalanseraren inte blir flaskhalsen i dataöverföringens sökväg.

Distributionsalternativ. I Azure kan SAP-arbetsbelastningsdistributionen vara antingen regional eller zonindelad, beroende på kraven på tillgänglighet och återhämtning i SAP-programmen. Azure tillhandahåller olika distributionsalternativ, till exempel VM-skalningsuppsättningar med flexibel orkestrering (FD=1), tillgänglighetszoner och tillgänglighetsuppsättningar, för att förbättra 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.

SAP HANA. För hög tillgänglighet körs SAP HANA på två eller flera virtuella Linux-datorer. SAP HANA System Replication (HSR) används för att replikera data mellan de primära och sekundära (replik) SAP HANA-systemen. HSR används också för haveriberedskap mellan regioner eller flera zoner. Beroende på svarstiden i kommunikationen mellan dina virtuella datorer kan synkron replikering användas i en region. HSR mellan regioner för haveriberedskap körs i de flesta fall på ett asynkront sätt.

För Linux Pacemaker-klustret måste du bestämma vilken klusterstängselmekanism som ska användas. Klusteravgränsning är en process för att isolera en misslyckad virtuell dator från klustret och starta om den. För RedHat Enterprise Linux (RHEL) är Azure fence agent den enda fäktningsmekanism som stöds för Pacemaker i Azure. För SUSE Linux Enterprise Server (SLES) kan du använda antingen Azure Fence Agent eller STONITH Block Device (SBD). Jämför redundanstiderna för varje lösning och välj en lösning baserat på dina affärskrav för mål för återställningstid (RTO) om det finns en skillnad.

Azure Fence-agent. Den här fäktningsmetoden förlitar sig på Azure ARM-API:et, där Pacemaker frågar ARM-API:et om statusen för båda de virtuella SAP HANA-datorerna i klustret. Om en virtuell dator misslyckas, till exempel om operativsystemet inte svarar eller om den virtuella datorn kraschar, använder klusterhanteraren återigen ARM-API:et för att starta om den virtuella datorn och om det behövs misslyckas SAP HANA-databasen till den andra aktiva noden. För detta ändamål används ett huvudnamn för tjänsten (SPN) med en anpassad roll för att fråga och starta om virtuella datorer för att auktorisera mot ARM-API:et. Ingen annan infrastruktur behövs, de virtuella SBD-datorerna i arkitekturritningarna distribueras inte om Azure Fence-agenten används.

SBD. STONITH Block Device (SBD) använder en disk som används som blockenhet (rå, utan filsystem) av klusterhanteraren. Den här disken, eller diskar om flera, fungerar som en röst. Var och en av de två klusternoder som kör SAP HANA kommer åt SDB-diskarna och läser/skriver regelbundet till dem små bitar av information om status. Varje klusternod känner därför till statusen för den andra utan att bara beroende på nätverk mellan de virtuella datorerna.

Helst distribueras tre små virtuella datorer i en tillgänglighetsuppsättning eller i en tillgänglighetszon. Varje virtuell dator exporterar små delar av en disk som en blockenhet som nås av de två SAP HANA-klusternoderna. Tre virtuella SBD-datorer säkerställer att tillräckligt många röstningsmedlemmar är tillgängliga vid planerad eller oplanerad stilleståndstid för någon av de virtuella SBD-datorerna.

Du kan också använda virtuella SBD-datorer, men du kan använda en delad Azure-disk i stället. SAP HANA-klusternoderna får sedan åtkomst till den enskilda delade disken. Den delade disken kan vara lokalt (LRS) eller zonindelad (ZRS) redundant, om ZRS är tillgängligt i din Azure-region.

Haveriberedskap

Följande arkitektur visar en HANA-produktionsmiljö i Azure som tillhandahåller haveriberedskap. Arkitekturen innehåller tillgänglighetszoner.

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.

Utöver en lokal implementering med hög tillgänglighet med två noder stöder HSR replikering på flera nivåer och multitarget . HSR stöder därför replikering mellan zoner och mellan regioner. Multitarget-replikering är tillgänglig för SAP HANA 2.0 SPS 03 och senare.

Kontrollera målregionens resurskapacitet.

Azure NetApp Files. Som ett alternativ kan Azure NetApp Files användas för att tillhandahålla en skalbar och högpresterande lagringslösning för SAP HANA-data och loggfiler. Azure NetApp Files stöder ögonblicksbilder för snabb säkerhetskopiering, återställning och lokal replikering. För innehållsreplikering mellan regioner kan Azure NetApp Files Replikering mellan regioner användas för att replikera ögonblicksbilddata mellan två regioner. Information om replikering mellan regioner och ett white paper som beskriver alla aspekter för haveriberedskap med Azure NetApp Files finns tillgängliga.

Backup

SAP HANA-data kan säkerhetskopieras på många sätt. När du har migrerat till Azure kan du fortsätta att använda befintliga lösningar för partnersäkerhetskopiering som du redan har. Azure tillhandahåller två inbyggda metoder: SAP HANA-säkerhetskopiering på filnivå och Azure Backup för SAP HANA via Backint-gränssnittet.

För säkerhetskopiering på SAP HANA-filnivå kan du använda valfritt verktyg, till exempel hdbsql eller SAP HANA Studio, och lagra säkerhetskopieringsfilerna på en lokal diskvolym. En vanlig monteringspunkt för den här säkerhetskopieringsvolymen är /hana/backup. Dina säkerhetskopieringsprinciper definierar datakvarhållningsperioden på volymen. Så snart säkerhetskopieringen har utförts bör en schemalagd uppgift kopiera säkerhetskopieringsfilerna till Azure Blob Storage för förvaring. De lokala säkerhetskopieringsfilerna sparas för en bra återställning.

Azure Backup erbjuder en enkel lösning i företagsklass för arbetsbelastningar som körs på virtuella datorer. Azure Backup för SAP HANA ger fullständig integrering med SAP HANA-säkerhetskopieringskatalogen och garanterar databaskonsekventa, fullständiga eller tidpunktsåterställda återställningar. Azure Backup är BackInt-certifierad av SAP. Se även vanliga frågor och svar om Azure Backup och supportmatrisen.

Azure NetApp Files ger stöd för ögonblicksbildsbaserade säkerhetskopior. Integrering med SAP HANA för programkonsekventa ögonblicksbilder sker via verktyget Azure Application Consistent Snapshot (AzAcSnap). Ögonblicksbilderna som skapas kan användas för återställning till en ny volym för systemåterställning eller kopiering av SAP HANA-databasen. Ögonblicksbilder som skapats kan användas för haveriberedskap, där de fungerar som återställningspunkt med SAP HANA-loggar som sparats på en annan NFS-volym.

Övervakning

För att övervaka dina arbetsbelastningar i Azure kan du med Azure Monitor samla in, analysera och agera på telemetri från dina molnmiljöer och lokala miljöer.

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äkerhet

Många säkerhetsåtgärder används för att skydda konfidentialitet, integritet och tillgänglighet för ett SAP-landskap. För att skydda användaråtkomst, till exempel, har SAP en egen användarhanteringsmotor (UME) för att styra rollbaserad åtkomst och auktorisering i SAP-programmet och databaserna. Mer information finns i SAP HANA Security – En översikt.

För vilande data ger olika krypteringsfunktioner säkerhet enligt följande:

• Tillsammans med den inbyggda SAP HANA-krypteringstekniken bör du överväga att använda en krypteringslösning från en partner som stöder kundhanterade nycklar.

• Om du vill kryptera virtuella datordiskar kan du använda funktioner som beskrivs i Översikt över diskkryptering.

• SAP Database-servrar: Använd transparent datakryptering som erbjuds av DBMS-providern (till exempel inbyggd SAP HANA-krypteringsteknik) för att skydda dina data och loggfiler och för att säkerställa att säkerhetskopiorna också krypteras.

• Data i fysisk Azure-lagring (kryptering på serversidan) krypteras automatiskt i vila med en Hanterad Azure-nyckel. Du kan också välja en kundhanterad nyckel (CMK) i stället för den Hanterade Azure-nyckeln.

• Information om stöd för Azure Disk Encryption för vissa Linux-distributioner, versioner och avbildningar finns i Azure Disk Encryption for Linux VMs (Azure Disk Encryption för virtuella Linux-datorer).

För nätverkssäkerhet använder du nätverkssäkerhetsgrupper (NSG:er) och Azure Firewall eller en virtuell nätverksinstallation på följande sätt:

• Använd NSG:er för att skydda och kontrollera trafiken mellan undernät och program-/databaslager. Använd endast NSG:er för undernät. NSG:er som tillämpas på både nätverkskort och undernät leder ofta till problem under felsökningen och bör användas sällan om någonsin.

• Använd den virtuella Azure Firewall - eller Azure-nätverksinstallationen för att inspektera och kontrollera routningen av trafik från det virtuella hubbnätverket till det virtuella ekernätverket där dina SAP-program finns, och även för att kontrollera din utgående Internetanslutning.

För Användare och auktorisering implementerar du rollbaserad åtkomstkontroll (RBAC) och resurslås på följande sätt:

• Följ principen om lägsta behörighet med hjälp av RBAC för att tilldela administrativa privilegier på IaaS-nivåresurser som är värdar för din SAP-lösning i Azure. Det grundläggande syftet med RBAC är segregering och kontroll av uppgifter för dina användare/grupp. RBAC är utformat för att endast bevilja den mängd åtkomst till resurser som behövs för att göra det möjligt för användare att utföra sina jobb.

• Använd resurslås för att förhindra oavsiktliga eller skadliga ändringar. Resurslås hjälper till att förhindra administratörer från att ta bort eller ändra viktiga Azure-resurser där din SAP-lösning finns.

Fler säkerhetsrekommendationer finns i microsoft- och SAP-artiklar.

Communities

Communities kan svara på frågor och hjälpa dig att konfigurera en lyckad distribution. Överväg följande communities:

• Azure Community Support

• SAP Community

• SAP på Stack Overflow

Deltagare

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

Huvudförfattare:

• Robert Biro | Senior arkitekt

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

Nästa steg

Läs mer om komponentteknikerna:

• Vad är Azure ExpressRoute?
• Vad är Azure Bastion?
• Vad är Power BI?
• Använda anslutningsappen för SAP Business Warehouse i Power BI Desktop
• SAP-arbetsbelastningskonfigurationer med Azure-tillgänglighetszoner
• Vad är Azure Backup-tjänsten?
• Om Site Recovery
• Vad är Azure Load Balancer?
• Anslut till SAP HANA-databaser i Power BI
• Vad är Azure NetApp Files?
• Introduktion till Azure Managed Disks
• Virtuella Linux-datorer i Azure
• Installation av SAP HANA på virtuella Azure-datorer
• Vad är Azure Virtual Network?
• Nätverkssäkerhetsgrupper
• SAP HANA-haveriberedskap med Azure NetApp Files

Relaterade resurser

Utforska relaterade arkitekturer:

• Kör en Linux-VM på Azure
• Kör SAP BW/4HANA med virtuella Linux-datorer i Azure
• SAP S/4HANA i Linux på Azure
• Arkitekturguide för SAP i Azure