Redigera

Dela via

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

Azure
Azure Virtual Machines

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:

Diagram som visar en regional distributionsarkitektur.

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

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.

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, men du kan också använda en plats-till-plats-anslutning. Använd zonredundanta Azure ExpressRoute- eller VPN-gatewayer 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 (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.)

Kommentar

Som anges i SAP Note 2731110 ska du inte placera någon virtuell nätverksinstallation (NVA) mellan programmet och databaslagren för någon SAP-programstack. På så sätt introduceras betydande bearbetningstid för datapaket och programmets prestanda blir oacceptabelt långsammare.

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 30 TiB, kan du använda virtuella datorer i Mv3-serien .

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 SAP HANA-datorn kan köras som en virtuell Gen2-dator och kan, när den frigörs, ändras till den största virtuella datorn som är tillgänglig i din region.

Närhetsplaceringsgrupper (PPG). När virtuella datorer distribueras i tillgänglighetszoner är svarstiden i zonen vanligtvis idealisk för nästan alla SAP HANA-användningar. Om du vill optimera nätverksfördröjningen ytterligare kan du använda närhetsplaceringsgrupper. Det 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 samordna 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

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 30 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 30 TiB. För OLAP-program (Online Analytical Processing) kan kapaciteten för utskalningsminne vara så hög som 16 x 15,2 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.

Storage

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:

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 Support är 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-balancern stöder inte zonredundans och inaktuell. 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 med den primära databasinstansen. SAP HANA active/read-enabled architecture is optionally available (SLES/RHEL) where a second virtual IP addressed on the load balancer is used to direct network traffic to the secondary SAP HANA instance on another VM for read-intense workloads.

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 med IP-adressen för lastbalanserarens klientdel.

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 om status 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.

Diagram som visar en arkitektur med haveriberedskap.

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.

Kommentar

Om det uppstår en regional katastrof som orsakar en stor redundanshändelse för många Azure-kunder i en region garanteras inte målregionens resurskapacitet . Precis som alla Azure-tjänster fortsätter Azure Site Recovery att lägga till funktioner. Den senaste informationen om Azure-till-Azure-replikering finns i supportmatrisen.

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

Kommentar

Kombinera inte SAP HANA-inbyggd krypteringsteknik med Azure Disk Encryption eller Värdbaserad kryptering på samma lagringsvolym. Operativsystemsstartdiskar för virtuella Linux-datorer har inte heller stöd för Azure Disk Encryption. När du använder inbyggd SAP HANA-kryptering kombinerar du den i stället med kryptering på serversidan, som aktiveras automatiskt. Tänk på att användningen av kundhanterade nycklar kan påverka lagringsdataflödet.

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:

Deltagare

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

Huvudförfattare:

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

Nästa steg

Läs mer om komponentteknikerna:

Utforska relaterade arkitekturer: