Planera och implementera en SAP-distribution i Azure

  • Artikel

I Azure kan organisationer hämta de molnresurser och tjänster de behöver utan att slutföra en lång anskaffningscykel. Men att köra SAP-arbetsbelastningen i Azure kräver kunskap om tillgängliga alternativ och noggrann planering för att välja Azure-komponenter och arkitektur för att driva din lösning.

Azure erbjuder en omfattande plattform för att köra dina SAP-program. Azures erbjudanden för infrastruktur som en tjänst (IaaS) och PaaS (plattform som en tjänst) kombineras för att ge dig optimala val för en lyckad distribution av hela SAP-företagslandskapet.

Den här artikeln kompletterar SAP-dokumentationen och SAP Notes, de primära källorna för information om hur du installerar och distribuerar SAP-programvara på Azure och andra plattformar.

Definitioner

I den här artikeln använder vi följande termer:

  • SAP-komponent: Ett enskilt SAP-program som SAP S/4HANA, SAP ECC, SAP BW eller SAP Solution Manager. En SAP-komponent kan baseras på traditionell ADVANCED Business Application Programming (ABAP) eller Java-teknik, eller så kan det vara ett program som inte är baserat på SAP NetWeaver, till exempel SAP BusinessObjects.
  • SAP-miljö: Flera SAP-komponenter som är logiskt grupperade för att utföra en affärsfunktion, till exempel utveckling, kvalitetssäkring, utbildning, haveriberedskap eller produktion.
  • SAP-landskap: Hela uppsättningen SAP-tillgångar i en organisations IT-landskap. SAP-landskapet innehåller alla produktions- och icke-produktionsmiljöer.
  • SAP-system: Kombinationen av ett databashanteringssystemskikt (DBMS) och ett programlager. Två exempel är ett SAP ERP-utvecklingssystem och ett SAP BW-testsystem. I en Azure-distribution kan dessa två lager inte distribueras mellan lokalt och Azure. Ett SAP-system måste antingen distribueras lokalt eller distribueras i Azure. Du kan dock använda olika system i ett SAP-landskap i antingen Azure eller lokalt.

Resurser

Startpunkten för dokumentation som beskriver hur du är värd för och kör en SAP-arbetsbelastning i Azure är Kom igång med SAP på en virtuell Azure-dator. I artikeln hittar du länkar till andra artiklar som omfattar:

  • SAP-arbetsbelastningsspecifika funktioner för lagring, nätverk och alternativ som stöds.
  • SAP DBMS-guider för olika DBMS-system i Azure.
  • SAP-distributionsguider, både manuella och automatiserade.
  • Information om hög tillgänglighet och haveriberedskap för en SAP-arbetsbelastning i Azure.
  • Integrering med SAP i Azure med andra tjänster och program från tredje part.

Viktigt!

För krav, installationsprocessen och information om specifika SAP-funktioner är det viktigt att läsa SAP-dokumentationen och guiderna noggrant. Den här artikeln beskriver endast specifika uppgifter för SAP-programvara som är installerad och drivs på en virtuell Azure-dator (VM).

Följande SAP-anteckningar utgör grunden för Azure-vägledningen för SAP-distributioner:

Anteckningsnummer Title
1928533 SAP-program i Azure: Produkter som stöds och storleksändring
2015553 SAP på Azure: Supportkrav
2039619 SAP-program i Azure med hjälp av Oracle Database
2233094 DB6: SAP-program i Azure med IBM Db2 för Linux, UNIX och Windows
1999351 Felsöka förbättrad Azure-övervakning för SAP
1409604 Virtualisering i Windows: Förbättrad övervakning
2191498 SAP på Linux med Azure: Förbättrad övervakning
2731110 Stöd för virtuella nätverksinstallationer (NVA) för SAP på Azure

Allmänna standard- och maxbegränsningar för Azure-prenumerationer och -resurser finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar.

Scenarier

SAP-tjänster anses ofta vara bland de mest verksamhetskritiska programmen i ett företag. Programmens arkitektur och åtgärder är komplexa och det är viktigt att se till att alla krav för tillgänglighet och prestanda uppfylls. Ett företag tänker vanligtvis noga på vilken molnleverantör som ska välja att köra sådana affärskritiska affärsprocesser.

Azure är den idealiska offentliga molnplattformen för affärskritiska SAP-program och affärsprocesser. De flesta aktuella SAP-program, inklusive SAP NetWeaver- och SAP S/4HANA-system, kan finnas i Azure-infrastrukturen idag. Azure erbjuder mer än 800 cpu-typer och virtuella datorer som har många terabyte minne.

Beskrivningar av scenarier som stöds och vissa scenarier som inte stöds finns i SAP på virtuella Azure-datorer som stöds. Kontrollera dessa scenarier och de villkor som anges som inte stöds när du planerar arkitekturen som du vill distribuera till Azure.

För att distribuera SAP-system till Azure IaaS eller till IaaS i allmänhet är det viktigt att förstå de betydande skillnaderna mellan erbjudandena för traditionella privata moln och IaaS-erbjudanden. En traditionell värd eller outsourcer anpassar infrastrukturen (nätverks-, lagrings- och servertyp) till den arbetsbelastning som en kund vill vara värd för. I en IaaS-distribution är det kundens eller partnerns ansvar att utvärdera deras potentiella arbetsbelastning och välja rätt Azure-komponenter för virtuella datorer, lagring och nätverk.

För att samla in data för att planera distributionen till Azure är det viktigt att:

  • Ta reda på vilka SAP-produkter och -versioner som stöds i Azure.
  • Utvärdera om de operativsystemversioner som du planerar att använda stöds med de virtuella Azure-datorer som du väljer för dina SAP-produkter.
  • Ta reda på vilka DBMS-versioner på specifika virtuella datorer som stöds för dina SAP-produkter.
  • Utvärdera om det är nödvändigt att uppgradera eller uppdatera SAP-landskapet för att anpassa till de operativsystem och DBMS-versioner som krävs för att uppnå en konfiguration som stöds.
  • Utvärdera om du behöver flytta till olika operativsystem för distribution i Azure.

Information om SAP-komponenter som stöds i Azure, Azure-infrastrukturenheter och relaterade operativsystemversioner och DBMS-versioner beskrivs i SAP-programvara som stöds för Azure-distributioner. Den kunskap som du får när du utvärderar support och beroenden mellan SAP-versioner, operativsystemversioner och DBMS-versioner har stor inverkan på dina ansträngningar att flytta dina SAP-system till Azure. Du får lära dig om betydande förberedelser är inblandade, till exempel om du behöver uppgradera din SAP-version eller byta till ett annat operativsystem.

Första stegen för att planera en distribution

Det första steget i distributionsplaneringen är inte att leta efter virtuella datorer som är tillgängliga för att köra SAP-program.

De första stegen för att planera en distribution är att arbeta med efterlevnads- och säkerhetsteam i din organisation för att avgöra vilka gränsvillkor som gäller för distribution av vilken typ av SAP-arbetsbelastning eller affärsprocess i ett offentligt moln. Processen kan vara tidskrävande, men det är ett viktigt grundarbete att slutföra.

Om din organisation redan har distribuerat programvara i Azure kan processen vara enkel. Om ditt företag är mer i början av resan kan större diskussioner vara nödvändiga för att ta reda på de gränsvillkor, säkerhetsvillkor och företagsarkitektur som gör att vissa SAP-data och SAP-affärsprocesser kan hanteras i ett offentligt moln.

Planera för efterlevnad

En lista över Microsofts efterlevnadserbjudanden som kan hjälpa dig att planera för dina efterlevnadsbehov finns i Microsofts efterlevnadserbjudanden.

Planera för säkerhet

Information om SAP-specifika säkerhetsproblem, till exempel datakryptering för vilande data eller annan kryptering i en Azure-tjänst, finns i Översikt över Azure-kryptering och Säkerhet för ditt SAP-landskap.

Organisera Azure-resurser

Om du inte har gjort den här uppgiften ännu planerar du tillsammans med säkerhets- och efterlevnadsgranskningen hur du organiserar dina Azure-resurser. Processen omfattar att fatta beslut om:

  • En namngivningskonvention som du använder för varje Azure-resurs, till exempel för virtuella datorer och resursgrupper.
  • En prenumerations- och hanteringsgruppsdesign för din SAP-arbetsbelastning, till exempel om flera prenumerationer ska skapas per arbetsbelastning, per distributionsnivå eller för varje affärsenhet.
  • Företagsomfattande användning av Azure Policy för prenumerationer och hanteringsgrupper.

För att hjälpa dig att fatta rätt beslut beskrivs många detaljer om företagsarkitekturen i Azure Cloud Adoption Framework.

Underskatta inte den inledande fasen av projektet i planeringen. Först när du har avtal och regler för efterlevnad, säkerhet och Azure-resursorganisation bör du gå vidare med distributionsplaneringen.

Nästa steg är att planera geografisk placering och nätverksarkitekturen som du distribuerar i Azure.

Azures geografiska områden och regioner

Azure-tjänster är tillgängliga i separata Azure-regioner. En Azure-region är en samling datacenter. Datacenter innehåller den maskinvara och infrastruktur som är värd för och kör De Azure-tjänster som är tillgängliga i regionen. Infrastrukturen innehåller ett stort antal noder som fungerar som beräkningsnoder eller lagringsnoder, eller som kör nätverksfunktioner.

En lista över Azure-regioner finns i Azure-geografiska områden. En interaktiv karta finns i Global Infrastruktur i Azure.

Alla Azure-regioner erbjuder inte samma tjänster. Beroende på vilken SAP-produkt du vill köra, storlekskraven och det operativsystem och DBMS du behöver, är det möjligt att en viss region inte erbjuder de VM-typer som krävs för ditt scenario. Om du till exempel kör SAP HANA behöver du vanligtvis virtuella datorer i de olika vm-familjerna i M-serien. Dessa VM-familjer distribueras endast i en delmängd av Azure-regioner.

När du börjar planera och fundera på vilka regioner du ska välja som primär region och så småningom sekundär region, måste du undersöka om de tjänster som du behöver för dina scenarier är tillgängliga i de regioner som du överväger. Du kan lära dig exakt vilka typer av virtuella datorer, Azure-lagringstyper och andra Azure-tjänster som är tillgängliga i varje region i Produkter som är tillgängliga per region.

Länkade Azure-regioner

I en länkad Azure-region aktiveras replikering av vissa data som standard mellan de två regionerna. Mer information finns i Replikering mellan regioner i Azure: Affärskontinuitet och haveriberedskap.

Datareplikering i ett regionpar är kopplat till typer av Azure Storage som du kan konfigurera för att replikera till en parad region. Mer information finns i Lagringsredundans i en sekundär region.

Lagringstyperna som stöder parkopplad regiondatareplikering är lagringstyper som inte är lämpliga för SAP-komponenter och en DBMS-arbetsbelastning. Användbarheten för Azure Storage-replikering är begränsad till Azure Blob Storage (i säkerhetskopieringssyfte), filresurser och volymer samt andra lagringsscenarier med långa svarstider.

När du söker efter kopplade regioner och de tjänster som du vill använda i dina primära eller sekundära regioner är det möjligt att de Azure-tjänster eller VM-typer som du tänker använda i din primära region inte är tillgängliga i den parkopplade region som du vill använda som en sekundär region. Eller så kan du fastställa att en länkad Azure-region inte är acceptabel för ditt scenario på grund av dataefterlevnadsskäl. För dessa scenarier måste du använda en icke-trappad region som en sekundär region eller haveriberedskapsregion, och du måste konfigurera en del av datareplikeringen själv.

Tillgänglighetszoner

Många Azure-regioner använder tillgänglighetszoner för att fysiskt separera platser i en Azure-region. Varje tillgänglighetszon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk. Ett exempel på hur du använder en tillgänglighetszon för att förbättra återhämtning är att distribuera två virtuella datorer i två separata tillgänglighetszoner i Azure. Ett annat exempel är att implementera ett ramverk med hög tillgänglighet för ditt SAP DBMS-system i en tillgänglighetszon och distribuera SAP (A)SCS i en annan tillgänglighetszon, så att du får det bästa serviceavtalet i Azure.

Mer information om serviceavtal för virtuella datorer i Azure finns i den senaste versionen av serviceavtal för virtuella datorer. Eftersom Azure-regioner utvecklas och utökas snabbt utvecklas topologin för Azure-regionerna, antalet fysiska datacenter, avståndet mellan datacenter och avståndet mellan Azure-tillgänglighetszoner. Ändringar i nätverksfördröjningen när infrastrukturen ändras.

Följ riktlinjerna i SAP-arbetsbelastningskonfigurationer med Azure-tillgänglighetszoner när du väljer en region som har tillgänglighetszoner. Ta också reda på vilken zonindelad distributionsmodell som passar bäst för dina behov, vilken region du väljer och din arbetsbelastning.

Feldomäner

Feldomäner representerar en fysisk felenhet. En feldomän är nära relaterad till den fysiska infrastruktur som finns i datacenter. Även om ett fysiskt blad eller rack kan betraktas som en feldomän finns det ingen direkt en-till-en-mappning mellan ett fysiskt databehandlingselement och en feldomän.

När du distribuerar flera virtuella datorer som en del av ett SAP-system kan du indirekt påverka Azure Fabric-kontrollanten att distribuera dina virtuella datorer till olika feldomäner, så att du kan uppfylla kraven för tillgänglighets-SERVICEavtal. Du har dock inte direkt kontroll över fördelningen av feldomäner över en Azure-skalningsenhet (en samling med hundratals beräkningsnoder eller lagringsnoder och nätverk) eller tilldelning av virtuella datorer till en specifik feldomän. Om du vill manövrera Azure Fabric-kontrollanten för att distribuera en uppsättning virtuella datorer över olika feldomäner måste du tilldela en Azure-tillgänglighetsuppsättning till de virtuella datorerna vid distributionstillfället. Mer information finns i Tillgänglighetsuppsättningar.

Uppdateringsdomäner

Uppdateringsdomäner representerar en logisk enhet som anger hur en virtuell dator i ett SAP-system som består av flera virtuella datorer uppdateras. När en plattformsuppdatering inträffar går Azure igenom processen med att uppdatera dessa uppdateringsdomäner en i taget. Genom att sprida virtuella datorer vid distributionstiden över olika uppdateringsdomäner kan du skydda DITT SAP-system mot potentiell stilleståndstid. På samma sätt som feldomäner är en Azure-skalningsenhet uppdelad i flera uppdateringsdomäner. Om du vill manövrera Azure Fabric-kontrollanten för att distribuera en uppsättning virtuella datorer över olika uppdateringsdomäner måste du tilldela en Azure-tillgänglighetsuppsättning till de virtuella datorerna vid distributionstillfället. Mer information finns i Tillgänglighetsuppsättningar.

Diagram that depicts update domains and failure domains.

Tillgänglighetsuppsättningar

Virtuella Azure-datorer i en Azure-tillgänglighetsuppsättning distribueras av Azure Fabric-kontrollanten över olika feldomäner. Fördelningen över olika feldomäner är att förhindra att alla virtuella datorer i ett SAP-system stängs av under infrastrukturunderhåll eller om ett fel inträffar i en feldomän. Som standard ingår inte virtuella datorer i en tillgänglighetsuppsättning. Du kan bara lägga till en virtuell dator i en tillgänglighetsuppsättning vid distributionstillfället eller när en virtuell dator distribueras om.

Mer information om Azure-tillgänglighetsuppsättningar och hur tillgänglighetsuppsättningar relaterar till feldomäner finns i Azure-tillgänglighetsuppsättningar.

Viktigt!

Tillgänglighetszoner och tillgänglighetsuppsättningar i Azure är ömsesidigt uteslutande. Du kan distribuera flera virtuella datorer till en specifik tillgänglighetszon eller till en tillgänglighetsuppsättning. Men inte både tillgänglighetszonen och tillgänglighetsuppsättningen kan tilldelas till en virtuell dator.

Du kan kombinera tillgänglighetsuppsättningar och tillgänglighetszoner om du använder närhetsplaceringsgrupper.

När du definierar tillgänglighetsuppsättningar och försöker blanda olika virtuella datorer i olika VM-familjer inom en tillgänglighetsuppsättning kan det uppstå problem som hindrar dig från att inkludera en viss typ av virtuell dator i en tillgänglighetsuppsättning. Anledningen är att tillgänglighetsuppsättningen är bunden till en skalningsenhet som innehåller en viss typ av beräkningsvärd. En viss typ av beräkningsvärd kan bara köras på vissa typer av VM-familjer.

Du kan till exempel skapa en tillgänglighetsuppsättning och distribuera den första virtuella datorn i tillgänglighetsuppsättningen. Den första virtuella datorn som du lägger till i tillgänglighetsuppsättningen finns i Edsv5 VM-familjen. När du försöker distribuera en andra virtuell dator, en virtuell dator som finns i M-familjen, misslyckas den här distributionen. Anledningen är att Edsv5-seriens virtuella datorer inte körs på samma värdmaskinvara som de virtuella datorerna i M-familjen.

Samma problem kan uppstå om du ändrar storlek på virtuella datorer. Om du försöker flytta en virtuell dator från Edsv5-familjen och till en vm-typ som finns i M-familjen misslyckas distributionen. Om du ändrar storlek till en vm-familj som inte kan finnas på samma värdmaskinvara måste du stänga av alla virtuella datorer som finns i tillgänglighetsuppsättningen och ändra storlek på dem för att kunna köras på den andra värddatortypen. Information om serviceavtal för virtuella datorer som distribueras i en tillgänglighetsuppsättning finns i Serviceavtal för virtuella datorer.

Vm-skalningsuppsättningar med flexibel orkestrering

Vm-skalningsuppsättningar med flexibel orkestrering ger en logisk gruppering av plattformshanterade virtuella datorer. Du har ett alternativ för att skapa skalningsuppsättningar inom regionen eller sträcka dig över flera tillgänglighetszoner. När du skapar den flexibla skalningsuppsättningen i en region med platformFaultDomainCount>1 (FD>1) distribueras de virtuella datorerna i skalningsuppsättningen över det angivna antalet feldomäner i samma region. Å andra sidan skulle skapandet av den flexibla skalningsuppsättningen mellan tillgänglighetszoner med platformFaultDomainCount=1 (FD=1) distribuera virtuella datorer över den angivna zonen och skalningsuppsättningen skulle också distribuera virtuella datorer mellan olika feldomäner i zonen på bästa sätt.

För SAP-arbetsbelastning stöds endast flexibel skalningsuppsättning med FD=1. Fördelen med att använda flexibla skalningsuppsättningar med FD=1 för distribution mellan zonindelningar, i stället för traditionell distribution av tillgänglighetszoner är att de virtuella datorer som distribueras med skalningsuppsättningen distribueras över olika feldomäner i zonen på bästa sätt. Mer information om distribution av SAP-arbetsbelastningar med skalningsuppsättning finns i guiden för flexibel distribution av vm-skalning.

När du distribuerar en SAP-arbetsbelastning med hög tillgänglighet i Azure är det viktigt att ta hänsyn till de olika tillgängliga distributionstyperna och hur de kan tillämpas i olika Azure-regioner (till exempel mellan zoner, i en enda zon eller i en region utan zoner). Mer information finns i Distributionsalternativ med hög tillgänglighet för SAP-arbetsbelastningar.

Dricks

För närvarande finns det inget direkt sätt att migrera SAP-arbetsbelastning som distribueras i tillgänglighetsuppsättningar eller tillgänglighetszoner till flexibel skala med FD=1. För att göra växeln måste du återskapa den virtuella datorn och disken med zonbegränsningar från befintliga resurser på plats. Ett projekt med öppen källkod innehåller PowerShell-funktioner som du kan använda som exempel för att ändra en virtuell dator som distribueras i tillgänglighetsuppsättningen eller tillgänglighetszonen till flexibel skalningsuppsättning med FD=1. Ett blogginlägg visar hur du ändrar ett HA- eller icke-HA SAP-system som distribuerats i tillgänglighetsuppsättningen eller tillgänglighetszonen till flexibel skalningsuppsättning med FD=1.

Närhetsplaceringsgrupper

Nätverksfördröjning mellan enskilda virtuella SAP-datorer kan ha betydande konsekvenser för prestanda. Nätverkets tur och retur-tid mellan SAP-programservrar och DBMS kan särskilt ha stor inverkan på affärsprogram. Optimalt finns alla beräkningselement som kör dina virtuella SAP-datorer så nära som möjligt. Det här alternativet är inte möjligt i alla kombinationer och Azure kanske inte vet vilka virtuella datorer som ska hålla ihop. I de flesta situationer och regioner uppfyller standardplaceringen kraven på svarstid för tur och retur i nätverket.

När standardplacering inte uppfyller kraven på tur och retur i ett SAP-system kan närhetsplaceringsgrupper åtgärda detta behov. Du kan använda närhetsplaceringsgrupper med platsbegränsningarna i Azure-regionen, tillgänglighetszonen och tillgängligheten inställda för att öka motståndskraften. Med en närhetsplaceringsgrupp är det möjligt att kombinera både tillgänglighetszoner och tillgänglighetsuppsättningar samtidigt som olika uppdaterings- och feldomäner anges. En närhetsplaceringsgrupp bör endast innehålla ett enda SAP-system.

Även om distribution i en närhetsplaceringsgrupp kan resultera i den mest svarstidsoptimerade placeringen, har distribution med hjälp av en närhetsplaceringsgrupp också nackdelar. Vissa VM-familjer kan inte kombineras i en närhetsplaceringsgrupp, eller så kan du stöta på problem om du ändrar storlek mellan VM-familjer. Begränsningarna för VM-familjer, regioner och tillgänglighetszoner kanske inte stöder samlokalisering. Mer information och information om fördelarna och potentiella utmaningar med att använda en närhetsplaceringsgrupp finns i Scenarier för närhetsplaceringsgrupp.

Virtuella datorer som inte använder närhetsplaceringsgrupper bör vara standarddistributionsmetoden i de flesta situationer för SAP-system. Den här standardinställningen gäller särskilt för zonindelade (en enda tillgänglighetszon) och distributioner mellan zonindelningar (virtuella datorer som är distribuerade mellan två tillgänglighetszoner) för ett SAP-system. Användning av närhetsplaceringsgrupper bör begränsas till SAP-system och Azure-regioner om det endast krävs av prestandaskäl.

Azure-nätverk

Azure har en nätverksinfrastruktur som mappar till alla scenarier som du kanske vill implementera i en SAP-distribution. I Azure har du följande funktioner:

  • Åtkomst till Azure-tjänster och åtkomst till specifika portar i virtuella datorer som program använder.
  • Direktåtkomst till virtuella datorer via Secure Shell (SSH) eller Windows Remote Desktop (RDP) för hantering och administration.
  • Intern kommunikation och namnmatchning mellan virtuella datorer och Azure-tjänster.
  • Lokal anslutning mellan ett lokalt nätverk och Azure-nätverk.
  • Kommunikation mellan tjänster som distribueras i olika Azure-regioner.

Detaljerad information om nätverk finns i Azure Virtual Network.

Att utforma nätverk är vanligtvis den första tekniska aktiviteten som du utför när du distribuerar till Azure. Stöd för en central företagsarkitektur som SAP ofta är en del av de övergripande nätverkskraven. I planeringsfasen bör du dokumentera den föreslagna nätverksarkitekturen så detaljerat som möjligt. Om du gör en ändring vid ett senare tillfälle, som att ändra en nätverksadress för undernätet, kan du behöva flytta eller ta bort distribuerade resurser.

Virtuella Azure-nätverk

Ett virtuellt nätverk är en grundläggande byggsten för ditt privata nätverk i Azure. Du kan definiera nätverkets adressintervall och separera intervallet i nätverksundernät. Ett nätverksundernät kan vara tillgängligt för en virtuell SAP-dator att använda eller så kan det dedikeras till en viss tjänst eller ett specifikt syfte. Vissa Azure-tjänster, till exempel Azure Virtual Network och Azure Application Gateway, kräver ett dedikerat undernät.

Ett virtuellt nätverk fungerar som en nätverksgräns. En del av den design som krävs när du planerar distributionen är att definiera det virtuella nätverket, undernäten och adressintervallen för privata nätverk. Du kan inte ändra tilldelningen av virtuella nätverk för resurser som nätverkskort (NIC) för virtuella datorer när de virtuella datorerna har distribuerats. Om du ändrar till ett virtuellt nätverk eller till ett adressintervall för undernätet kan du behöva flytta alla distribuerade resurser till ett annat undernät.

Nätverksdesignen bör uppfylla flera krav för SAP-distribution:

  • Inga virtuella nätverksinstallationer, till exempel en brandvägg, placeras i kommunikationssökvägen mellan SAP-programmet och DBMS-lagret av SAP-produkter via SAP-kerneln, till exempel S/4HANA eller SAP NetWeaver.
  • Nätverksroutningsbegränsningar tillämpas av nätverkssäkerhetsgrupper (NSG:er) på undernätsnivå. Gruppera IP-adresser för virtuella datorer i programsäkerhetsgrupper (ASG:er) som underhålls i NSG-reglerna och tillhandahålla behörighetsgrupper för roll, nivå och SID.
  • VIRTUELLA SAP-program och databasdatorer körs i samma virtuella nätverk, inom samma eller olika undernät i ett enda virtuellt nätverk. Använd olika undernät för virtuella program- och databasdatorer. Du kan också använda dedikerade program och DBMS ASG:er för att gruppera regler som gäller för varje arbetsbelastningstyp i samma undernät.
  • Accelererat nätverk är aktiverat på alla nätverkskort för alla virtuella datorer för SAP-arbetsbelastningar där det är tekniskt möjligt.
  • Säkerställa säker åtkomst för beroende av centrala tjänster, inklusive för namnmatchning (DNS), identitetshantering (Windows Server Active Directory-domäner/Microsoft Entra-ID) och administrativ åtkomst.
  • Ge åtkomst till och av offentliga slutpunkter efter behov. Exempel är för Azure-hantering för ClusterLabs Pacemaker-åtgärder med hög tillgänglighet eller för Azure-tjänster som Azure Backup.
  • Använd endast flera nätverkskort om de är nödvändiga för att skapa utsedda undernät som har egna vägar och NSG-regler.

Exempel på nätverksarkitektur för SAP-distribution finns i följande artiklar:

Överväganden för virtuella nätverk

Vissa konfigurationer för virtuella nätverk har specifika överväganden att tänka på.

  • Konfigurationen av virtuella nätverksinstallationer i kommunikationssökvägen mellan SAP-programlagret och DBMS-lagret av SAP-komponenter med hjälp av SAP-kerneln, till exempel S/4HANA eller SAP NetWeaver, stöds inte.

    Virtuella nätverksinstallationer i kommunikationsvägar kan enkelt fördubbla nätverksfördröjningen mellan två kommunikationspartner. De kan också begränsa dataflödet i kritiska sökvägar mellan SAP-programlagret och DBMS-lagret. I vissa scenarier kan virtuella nätverksinstallationer orsaka att Pacemaker Linux-kluster misslyckas.

    Kommunikationssökvägen mellan SAP-programlagret och DBMS-lagret måste vara en direkt sökväg. Begränsningen inkluderar inte ASG- och NSG-regler om ASG- och NSG-reglerna tillåter en direkt kommunikationsväg.

    Andra scenarier där virtuella nätverksinstallationer inte stöds är:

  • Det går inte att separera SAP-programskiktet och DBMS-lagret i olika virtuella Azure-nätverk. Vi rekommenderar att du separerar SAP-programskiktet och DBMS-lagret med hjälp av undernät i samma virtuella Azure-nätverk i stället för med hjälp av olika virtuella Azure-nätverk.

    Om du konfigurerar ett scenario som inte stöds och separerar två SAP-systemlager i olika virtuella nätverk måste de två virtuella nätverken varapeer-kopplade.

    Nätverkstrafik mellan två peer-kopplade virtuella Azure-nätverk är föremål för överföringskostnader. Varje dag utbyts en enorm mängd data som består av många terabyte mellan SAP-programlagret och DBMS-lagret. Du kan få stora kostnader om SAP-programlagret och DBMS-lagret är åtskilda mellan två peerkopplade virtuella Azure-nätverk.

Namnmatchning och domäntjänster

Att matcha värdnamn till IP-adress via DNS är ofta ett viktigt element för SAP-nätverk. Du har många alternativ för att konfigurera namn och IP-matchning i Azure.

Ofta har ett företag en central DNS-lösning som ingår i den övergripande arkitekturen. Flera alternativ för att implementera namnmatchning i Azure internt, i stället för att konfigurera egna DNS-servrar, beskrivs i Namnmatchning för resurser i virtuella Azure-nätverk.

Precis som med DNS-tjänster kan det finnas ett krav på att Windows Server Active Directory ska vara tillgängligt för de virtuella SAP-datorerna eller tjänsterna.

IP-adresstilldelning

En IP-adress för ett nätverkskort förblir begärd och används under hela förekomsten av en virtuell dators nätverkskort. Regeln gäller för både dynamisk och statisk IP-tilldelning. Det är fortfarande sant om den virtuella datorn körs eller stängs av. Dynamisk IP-tilldelning släpps om nätverkskortet tas bort, om undernätet ändras eller om allokeringsmetoden ändras till statisk.

Det är möjligt att tilldela fasta IP-adresser till virtuella datorer i ett virtuellt Azure-nätverk. IP-adresser omtilldelas ofta för SAP-system som är beroende av externa DNS-servrar och statiska poster. IP-adressen förblir tilldelad, antingen tills den virtuella datorn och dess nätverkskort har tagits bort eller tills IP-adressen inte har tilldelats. Du måste ta hänsyn till det totala antalet virtuella datorer (körs och stoppas) när du definierar ip-adressintervallet för det virtuella nätverket.

Mer information finns i Skapa en virtuell dator som har en statisk privat IP-adress.

Kommentar

Du bör välja mellan statisk och dynamisk IP-adressallokering för virtuella Azure-datorer och deras nätverkskort. Gästoperativsystemet för den virtuella datorn hämtar den IP-adress som tilldelas nätverkskortet när den virtuella datorn startas. Du bör inte tilldela statiska IP-adresser i gästoperativsystemet till ett nätverkskort. Vissa Azure-tjänster som Azure Backup förlitar sig på att det primära nätverkskortet är inställt på DHCP och inte på statiska IP-adresser i operativsystemet. Mer information finns i Felsöka säkerhetskopiering av virtuella Azure-datorer.

Sekundära IP-adresser för SAP-värdnamnvirtualisering

Varje virtuell Azure-dators nätverkskort kan ha flera TILLDELADE IP-adresser. En sekundär IP-adress kan användas för ett virtuellt SAP-värdnamn som mappas till en DNS A-post eller DNS PTR-post. En sekundär IP-adress måste tilldelas till Azure NIC:s IP-konfiguration. En sekundär IP-adress måste också konfigureras statiskt i operativsystemet eftersom sekundära IP-adresser ofta inte tilldelas via DHCP. Varje sekundär IP-adress måste komma från samma undernät som nätverkskortet är bundet till. En sekundär IP-adress kan läggas till och tas bort från ett Azure-nätverkskort utan att stoppa eller frigöra den virtuella datorn. Om du vill lägga till eller ta bort den primära IP-adressen för ett nätverkskort måste den virtuella datorn frigöras.

Kommentar

Vid sekundära IP-konfigurationer stöds inte Azure-lastbalanserarens flytande IP-adress. Azure-lastbalanseraren används av SAP-arkitekturer med hög tillgänglighet med Pacemaker-kluster. I det här scenariot aktiverar lastbalanseraren de virtuella SAP-värdnamnen. Allmän vägledning om hur du använder virtuella värdnamn finns i SAP Note 962955.

Azure Load Balancer med virtuella datorer som kör SAP

En lastbalanserare används vanligtvis i arkitekturer med hög tillgänglighet för att tillhandahålla flytande IP-adresser mellan aktiva och passiva klusternoder. Du kan också använda en lastbalanserare för en enskild virtuell dator för att lagra en virtuell IP-adress för ett virtuellt SAP-värdnamn. Att använda en lastbalanserare för en enskild virtuell dator är ett alternativ till att använda en sekundär IP-adress på ett nätverkskort eller att använda flera nätverkskort i samma undernät.

Standardlastbalanseraren ändrar standardsökvägen för utgående åtkomst eftersom dess arkitektur är säker som standard. Virtuella datorer som ligger bakom en standardlastbalanserare kanske inte längre kan nå samma offentliga slutpunkter. Några exempel är en slutpunkt för en uppdateringslagringsplats för operativsystemet eller en offentlig slutpunkt för Azure-tjänster. Alternativ för att tillhandahålla utgående anslutning finns i Offentlig slutpunktsanslutning för virtuella datorer med hjälp av Azures standardlastbalanserare.

Dricks

Den grundläggande lastbalanseraren ska inte användas med någon SAP-arkitektur i Azure. Den grundläggande lastbalanseraren är schemalagd att dras tillbaka.

Flera virtuella nätverkskort per virtuell dator

Du kan definiera flera virtuella nätverkskort (vNIC) för en virtuell Azure-dator, där varje virtuellt nätverkskort har tilldelats till alla undernät i samma virtuella nätverk som det primära virtuella nätverkskortet. Med möjligheten att ha flera virtuella nätverkskort kan du börja konfigurera nätverkstrafikavgränsning om det behövs. Till exempel dirigeras klienttrafik via det primära virtuella nätverkskortet och viss administratörs- eller serverdelstrafik dirigeras via ett andra virtuellt nätverkskort. Beroende på vilket operativsystem och den avbildning du använder kan trafikvägar för nätverkskort i operativsystemet behöva konfigureras för korrekt routning.

Typen och storleken på en virtuell dator avgör hur många virtuella nätverkskort en virtuell dator kan ha tilldelats. Information om funktioner och begränsningar finns i Tilldela flera IP-adresser till virtuella datorer med hjälp av Azure-portalen.

Att lägga till virtuella nätverkskort till en virtuell dator ökar inte den tillgängliga nätverksbandbredden. Alla nätverksgränssnitt har samma bandbredd. Vi rekommenderar att du endast använder flera nätverkskort om virtuella datorer behöver komma åt privata undernät. Vi rekommenderar ett designmönster som förlitar sig på NSG-funktioner och som förenklar kraven för nätverk och undernät. Designen bör använda så få nätverksgränssnitt som möjligt och optimalt bara ett. Ett undantag är HANA-utskalning, där ett sekundärt virtuellt nätverkskort krävs för det interna HANA-nätverket.

Varning

Om du använder flera virtuella nätverkskort på en virtuell dator rekommenderar vi att du använder ett primärt nätverkskorts undernät för att hantera användarnätverkstrafik.

Accelererat nätverk

För att ytterligare minska nätverksfördröjningen mellan virtuella Azure-datorer rekommenderar vi att du bekräftar att Azure-accelererat nätverk är aktiverat på varje virtuell dator som kör en SAP-arbetsbelastning. Även om accelererat nätverk är aktiverat som standard för nya virtuella datorer bör du kontrollera tillståndet enligt distributionschecklistan. Fördelarna med accelererat nätverk är avsevärt bättre nätverksprestanda och svarstider. Använd den när du distribuerar virtuella Azure-datorer för SAP-arbetsbelastningar på alla virtuella datorer som stöds, särskilt för SAP-programlagret och SAP DBMS-lagret. Den länkade dokumentationen innehåller stödberoenden för operativsystemversioner och VM-instanser.

Lokala anslutningsmöjligheter

SAP-distributionen i Azure förutsätter att en central, företagsomfattande nätverksarkitektur och kommunikationshubb finns på plats för att aktivera lokal anslutning. Lokal nätverksanslutning är nödvändig för att tillåta användare och program att få åtkomst till SAP-landskapet i Azure för att få åtkomst till andra centrala organisationstjänster, till exempel den centrala infrastrukturen för DNS, domän och säkerhets- och korrigeringshantering.

Du har många alternativ för att tillhandahålla lokal anslutning för din SAP i Azure-distributionen. Nätverksdistributionen är oftast en nätverkstopologi med nav-ekrar, eller ett tillägg av hub-spoke-topologin, ett globalt virtuellt WAN.

För lokala SAP-distributioner rekommenderar vi att du använder en privat anslutning via Azure ExpressRoute. För mindre SAP-arbetsbelastningar, fjärranslutna regioner eller mindre kontor är VPN-lokal anslutning tillgänglig. Att använda ExpressRoute med en VPN-plats-till-plats-anslutning som en redundanssökväg är en möjlig kombination av båda tjänsterna.

Utgående och inkommande Internetanslutning

Ditt SAP-landskap kräver anslutning till Internet, oavsett om det är för att ta emot uppdateringar av operativsystemets lagringsplats, upprätta en anslutning till SAP SaaS-programmen på deras offentliga slutpunkter eller för att få åtkomst till en Azure-tjänst via dess offentliga slutpunkt. På samma sätt kan du behöva ge dina klienter åtkomst till SAP Fiori-program, med Internetanvändare som har åtkomst till tjänster som tillhandahålls av ditt SAP-landskap. Din SAP-nätverksarkitektur kräver att du planerar för sökvägen mot Internet och för inkommande begäranden.

Skydda ditt virtuella nätverk med hjälp av NSG-regler genom att använda nätverkstjänsttaggar för kända tjänster och genom att upprätta routning och IP-adresser till brandväggen eller andra virtuella nätverksinstallationer. Alla dessa uppgifter eller överväganden ingår i arkitekturen. Resurser i privata nätverk måste skyddas av nätverksbrandväggarna Layer 4 och Layer 7.

Kommunikationsvägar med Internet är i fokus för en metodtipsarkitektur.

Virtuella Azure-datorer för SAP-arbetsbelastningar

Vissa azure VM-familjer är särskilt lämpliga för SAP-arbetsbelastningar, och vissa mer specifikt för en SAP HANA-arbetsbelastning. Sättet att hitta rätt typ av virtuell dator och dess förmåga att stödja din SAP-arbetsbelastning beskrivs i Vilken SAP-programvara stöds för Azure-distributioner. SAP Note 1928533 visar även en lista över alla certifierade virtuella Azure-datorer och deras prestandafunktioner enligt saps-prestandamåttet (SAPS) om de gäller. De VM-typer som är certifierade för en SAP-arbetsbelastning använder inte överetablering för PROCESSOR- och minnesresurser.

Förutom att bara titta på valet av typer av virtuella datorer som stöds måste du kontrollera om dessa VM-typer är tillgängliga i en viss region baserat på produkter som är tillgängliga per region. Minst lika viktigt är att avgöra om följande funktioner för en virtuell dator passar ditt scenario:

  • PROCESSOR- och minnesresurser
  • Bandbredd för in- och utdataåtgärder per sekund (IOPS)
  • Nätverksfunktioner
  • Antal diskar som kan anslutas
  • Möjlighet att använda vissa Azure-lagringstyper

Information om hur du hämtar den här informationen för en specifik FM-familj och typ finns i Storlekar för virtuella datorer i Azure.

Prismodeller för virtuella Azure-datorer

För en prismodell för virtuella datorer kan du välja det alternativ som du föredrar att använda:

  • En prismodell för betala per användning
  • En ettårsplan för reserverade eller sparande
  • En reserverad plan eller sparplan på tre år
  • En prismodell för oanvänd kapacitet

Detaljerad information om priser för virtuella datorer för olika Azure-tjänster, operativsystem och regioner finns i Priser för virtuella datorer.

Mer information om prissättning och flexibilitet för ettåriga och treåriga sparplaner och reserverade instanser finns i följande artiklar:

Mer information om spotpriser finns i Azure Spot Virtual Machines.

Prissättningen för samma typ av virtuell dator kan variera mellan Azure-regioner. Vissa kunder har nytta av att distribuera till en billigare Azure-region, så information om priser per region kan vara till hjälp när du planerar.

Azure erbjuder också alternativet att använda en dedikerad värd. Med hjälp av en dedikerad värd får du mer kontroll över korrigeringscykler för Azure-tjänster. Du kan schemalägga korrigeringar för att stödja ditt eget schema och cykler. Det här erbjudandet är specifikt för kunder som har en arbetsbelastning som inte följer den normala arbetsbelastningscykeln. Mer information finns i Dedikerade Azure-värdar.

Användning av en dedikerad Azure-värd stöds för en SAP-arbetsbelastning. Flera SAP-kunder som vill ha mer kontroll över infrastrukturkorrigeringar och underhållsplaner använder dedikerade Azure-värdar. Mer information om hur Microsoft underhåller och korrigerar Azure-infrastrukturen som är värd för virtuella datorer finns i Underhåll för virtuella datorer i Azure.

Operativsystem för virtuella datorer

När du distribuerar nya virtuella datorer för ett SAP-landskap i Azure, antingen för att installera eller migrera ett SAP-system, är det viktigt att välja rätt åtgärdssystem för din arbetsbelastning. Azure erbjuder ett stort urval av operativsystemavbildningar för Linux och Windows och många lämpliga alternativ för SAP-system. Du kan också skapa eller ladda upp anpassade avbildningar från din lokala miljö, eller så kan du använda eller generalisera från bildgallerier.

Mer information om vilka alternativ som är tillgängliga finns:

Planera för en uppdateringsinfrastruktur för operativsystemet och dess beroenden för din SAP-arbetsbelastning om det behövs. Överväg att använda en mellanlagringsmiljö för lagringsplatser för att hålla alla nivåer i ett SAP-landskap (sandbox-miljö, utveckling, förproduktion och produktion) synkroniserade med samma versioner av korrigeringar och uppdateringar under uppdateringsperioden.

Virtuella datorer av generation 1 och generation 2

I Azure kan du distribuera en virtuell dator som antingen generation 1 eller generation 2. Stöd för virtuella datorer av generation 2 i Azure visar de Azure VM-familjer som du kan distribuera som generation 2. Artikeln innehåller också funktionella skillnader mellan virtuella datorer av generation 1 och generation 2 i Azure.

När du distribuerar en virtuell dator avgör operativsystemavbildningen som du väljer om den virtuella datorn ska vara en virtuell dator av generation 1 eller generation 2. De senaste versionerna av alla operativsystemavbildningar för SAP som är tillgängliga i Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux och Windows eller Oracle Enterprise Linux) är tillgängliga i både generation 1 och generation 2. Det är viktigt att noggrant välja en avbildning baserat på avbildningsbeskrivningen för att distribuera rätt generation av virtuell dator. På samma sätt kan du skapa anpassade operativsystemavbildningar som generation 1 eller generation 2, och de påverkar den virtuella datorns generation när den virtuella datorn distribueras.

Kommentar

Vi rekommenderar att du använder virtuella datorer i generation 2 i alla dina SAP-distributioner i Azure, oavsett vm-storlek. Alla de senaste virtuella Azure-datorerna för SAP är genereringskompatibla eller är begränsade till endast generation 2. Vissa VM-familjer stöder för närvarande endast virtuella datorer i generation 2. Vissa VM-familjer som snart kommer att vara tillgängliga kanske bara stöder generation 2.

Du kan avgöra om en virtuell dator är generation 1 eller endast generation 2 baserat på den valda operativsystemavbildningen. Du kan inte ändra en befintlig virtuell dator från en generation till en annan generation.

Det går inte att ändra en distribuerad virtuell dator från generation 1 till generation 2 i Azure. Om du vill ändra genereringen av den virtuella datorn måste du distribuera en ny virtuell dator som är den generation som du vill använda och installera om programvaran på den nya generationen av den virtuella datorn. Den här ändringen påverkar endast den virtuella datorns grundläggande VHD-avbildning och påverkar inte datadiskarna eller anslutna NFS-resurser (Network File System) eller SMB-resurser (Server Message Block). Datadiskar, NFS-resurser eller SMB-resurser som ursprungligen tilldelades till en virtuell dator av generation 1 kan kopplas till en ny virtuell dator av generation 2.

Vissa VM-familjer, till exempel Mv2-serien, stöder endast generation 2. Samma krav kan gälla för nya VM-familjer i framtiden. I det scenariot kan en befintlig virtuell dator av generation 1 inte ändras så att den fungerar med den nya virtuella datorfamiljen. Utöver Kraven för Azure-plattformens generation 2 kan dina SAP-komponenter ha krav som är relaterade till en virtuell dators generation. Information om eventuella krav i generation 2 för den virtuella datorfamilj som du väljer finns i SAP Note 1928533.

Prestandabegränsningar för virtuella Azure-datorer

Som ett offentligt moln är Azure beroende av att dela infrastruktur på ett säkert sätt i hela kundbasen. För att aktivera skalning och kapacitet definieras prestandagränser för varje resurs och tjänst. På beräkningssidan av Azure-infrastrukturen är det viktigt att överväga de gränser som definieras för varje VM-storlek.

Varje virtuell dator har olika kvoter för disk- och nätverksdataflöde, antalet diskar som kan anslutas, om den har lokal tillfällig lagring som har sitt eget dataflöde och IOPS-gränser, minnesstorlek och hur många vCPU:er som är tillgängliga.

Kommentar

När du fattar beslut om VM-storlek för en SAP-lösning i Azure måste du överväga prestandagränserna för varje VM-storlek. De kvoter som beskrivs i dokumentationen representerar de teoretiska högsta uppnåeliga värdena. Prestandagränsen för IOPS per disk kan uppnås med små I/O-värden (indata/utdata) (till exempel 8 KB), men det kanske inte uppnås med stora I/O-värden (till exempel 1 MB).

Precis som virtuella datorer finns samma prestandagränser för varje lagringstyp för en SAP-arbetsbelastning och för alla andra Azure-tjänster.

När du planerar för och väljer virtuella datorer som ska användas i SAP-distributionen bör du tänka på följande faktorer:

  • Börja med minnes- och CPU-kraven. Avgränsa SAPS-kraven för CPU-kraft i DBMS-delen och SAP-programdelarna. För befintliga system kan SAPS som är relaterade till den maskinvara som du använder ofta fastställas eller uppskattas baserat på befintliga SAP Standard Application Benchmarks. För nyligen distribuerade SAP-system slutför du en storleksövning för att fastställa SAPS-kraven för systemet.

  • För befintliga system bör I/O-dataflödet och IOPS på DBMS-servern mätas. För nya system bör storleksövningen för det nya systemet också ge dig en allmän uppfattning om I/O-kraven på DBMS-sidan. Om du är osäker måste du så småningom genomföra ett konceptbevis.

  • Jämför SAPS-kravet för DBMS-servern med DEN SAPS som de olika VM-typerna av Azure kan tillhandahålla. Informationen om SAPS för de olika typerna av virtuella Azure-datorer finns dokumenterad i SAP Note 1928533. Fokus bör ligga på den virtuella DBMS-datorn först eftersom databaslagret är lagret i ett SAP NetWeaver-system som inte skalas ut i de flesta distributioner. SAP-programskiktet kan däremot skalas ut. Enskilda DBMS-guider beskriver de rekommenderade lagringskonfigurationerna.

  • Sammanfatta dina resultat för:

    • Antalet virtuella Azure-datorer som du förväntar dig att använda.
    • Enskilda VM-familj och VM-SKU:er för varje SAP-lager: DBMS, (A)SCS och programserver.
    • I/O-dataflödesmått eller krav på beräknad lagringskapacitet.

TJÄNSTEN STORA HANA-instanser

Azure erbjuder beräkningsfunktioner för att köra en uppskalnings- eller skalbar stor HANA-databas på ett dedikerat erbjudande som kallas SAP HANA på stora Azure-instanser. Det här erbjudandet utökar de virtuella datorer som är tillgängliga i Azure.

Kommentar

HANA Large Instances-tjänsten är i slutläge och accepterar inte nya kunder. Det är fortfarande möjligt att tillhandahålla enheter för befintliga HANA Large Instances-kunder.

Lagring för SAP på Azure

Virtuella Azure-datorer använder olika lagringsalternativ för beständighet. Enkelt uttryckt kan de virtuella datorerna delas in i beständiga och tillfälliga eller icke-beständiga lagringstyper.

Du kan välja mellan flera lagringsalternativ för SAP-arbetsbelastningar och för specifika SAP-komponenter. Mer information finns i Azure Storage för SAP-arbetsbelastningar. Artikeln beskriver lagringsarkitekturen för varje del av SAP: operativsystem, binärfiler för program, konfigurationsfiler, databasdata, logg- och spårningsfiler och filgränssnitt med andra program, oavsett om de lagras på disken eller används på filresurser.

Tillfällig disk på virtuella datorer

De flesta virtuella Azure-datorer för SAP erbjuder en tillfällig disk som inte är en hanterad disk. Använd endast en tillfällig disk för förbrukningsbara data. Data på en tillfällig disk kan gå förlorade under oförutsedda underhållshändelser eller vid omdistribution av virtuella datorer. Prestandaegenskaperna för den tillfälliga disken gör dem idealiska för växlings-/sidfiler i operativsystemet.

Inga program- eller icke-utökningsbara operativsystemdata ska lagras på en tillfällig disk. I Windows-miljöer används den tillfälliga enheten vanligtvis som enhet D. I Linux-system är monteringspunkten ofta /dev/sdb-enhet, /mnt eller /mnt/resource.

Vissa virtuella datorer erbjuder inte en tillfällig enhet. Om du planerar att använda dessa VM-storlekar för SAP kan du behöva öka storleken på operativsystemdisken. Mer information finns i SAP Note 1928533. För virtuella datorer som har en tillfällig disk får du information om den tillfälliga diskstorleken och IOPS- och dataflödesgränserna för varje VM-serie i Storlekar för virtuella datorer i Azure.

Du kan inte ändra storlek direkt mellan en VM-serie som har tillfälliga diskar och en VM-serie som inte har tillfälliga diskar. För närvarande misslyckas en storleksändring mellan två sådana vm-familjer. En lösning är att återskapa den virtuella datorn som inte har en tillfällig disk i den nya storleken med hjälp av en ögonblicksbild av operativsystemdisken. Behåll alla andra datadiskar och nätverksgränssnittet. Lär dig hur du ändrar storlek på en virtuell dator som har en lokal tillfällig disk till en vm-storlek som inte gör det.

Nätverksresurser och volymer för SAP

SAP-system kräver vanligtvis en eller flera nätverksfilresurser. Filresurserna är vanligtvis något av följande alternativ:

  • En SAP-transportkatalog (/usr/sap/trans eller TRANSDIR).
  • SAP-volymer eller delade sapmnt - eller saploc-volymer för att distribuera flera programservrar.
  • Arkitekturvolymer med hög tillgänglighet för SAP (A)SCS, SAP ERS eller en databas (/hana/delad).
  • Filgränssnitt som kör program från tredje part för filimport och -export.

I dessa scenarier rekommenderar vi att du använder en Azure-tjänst, till exempel Azure Files eller Azure NetApp Files. Om dessa tjänster inte är tillgängliga i de regioner du väljer, eller om de inte är tillgängliga för din lösningsarkitektur, är alternativen att tillhandahålla NFS- eller SMB-filresurser från självhanterade, VM-baserade program eller från tjänster från tredje part. Se SAP Note 2015553 om begränsningar för SAP-stöd om du använder tjänster från tredje part för lagringslager i ett SAP-system i Azure.

På grund av nätverksresursernas ofta kritiska karaktär, och eftersom de ofta är en enskild felpunkt i en design (för hög tillgänglighet) eller process (för filgränssnittet), rekommenderar vi att du förlitar dig på varje azure-intern tjänst för sin egen tillgänglighet, SLA och återhämtning. I planeringsfasen är det viktigt att tänka på följande faktorer:

  • NFS- eller SMB-resursdesign, inklusive vilka resurser som ska användas per SAP-system-ID (SID), per liggande och per region.
  • Storlek på undernät, inklusive IP-kravet för privata slutpunkter eller dedikerade undernät för tjänster som Azure NetApp Files.
  • Nätverksroutning till SAP-system och anslutna program.
  • Användning av en offentlig eller privat slutpunkt för Azure Files.

Information om krav och hur du använder en NFS- eller SMB-resurs i ett scenario med hög tillgänglighet finns i Hög tillgänglighet.

Kommentar

Om du använder Azure Files för dina nätverksresurser rekommenderar vi att du använder en privat slutpunkt. I händelse av ett zonfel omdirigeras NFS-klienten automatiskt till en felfri zon. Du behöver inte montera om NFS- eller SMB-resurserna på dina virtuella datorer.

Säkerhet för ditt SAP-landskap

För att skydda din SAP-arbetsbelastning i Azure måste du planera flera säkerhetsaspekter:

  • Nätverkssegmentering och säkerheten för varje undernät och nätverksgränssnitt.
  • Kryptering på varje lager i SAP-liggande.
  • Identitetslösning för slutanvändare och administrativ åtkomst och tjänster för enkel inloggning.
  • Övervakning av hot och åtgärder.

Avsnitten i det här kapitlet är inte en fullständig lista över alla tillgängliga tjänster, alternativ och alternativ. Den innehåller en lista över flera metodtips som bör beaktas för alla SAP-distributioner i Azure. Det finns andra aspekter att ta upp beroende på företagets eller arbetsbelastningskraven. Mer information om säkerhetsdesign finns i följande resurser för allmän Azure-vägledning:

Skydda virtuella nätverk med hjälp av säkerhetsgrupper

Planeringen av SAP-landskapet i Azure bör omfatta en viss grad av nätverkssegmentering, med virtuella nätverk och undernät som endast är dedikerade till SAP-arbetsbelastningar. Metodtips för undernätsdefinition beskrivs i Nätverk och i andra Azure-arkitekturguider. Vi rekommenderar att du använder NSG:er med ASG:er i NSG:er för att tillåta inkommande och utgående anslutningar. När du utformar ASG:er kan varje nätverkskort på en virtuell dator associeras med flera ASG:er, så att du kan skapa olika grupper. Skapa till exempel en ASG för virtuella DBMS-datorer som innehåller alla databasservrar i ditt landskap. Skapa en annan ASG för alla virtuella datorer (program och DBMS) för ett enda SAP SID. På så sätt kan du definiera en NSG-regel för den övergripande databasens ASG och en annan, mer specifik regel endast för DEN SID-specifika ASG:n.

NSG:er begränsar inte prestanda med de regler som du definierar för NSG. För att övervaka trafikflödet kan du aktivera NSG-flödesloggning med loggar som utvärderas av ett SIEM(Information Event Management) eller intrångsidentifieringssystem (IDS) för att övervaka och agera på misstänkt nätverksaktivitet.

Dricks

Aktivera NSG:er endast på undernätsnivå. Även om NSG:er kan aktiveras på både undernätsnivå och nätverkskortsnivå är aktivering på båda ofta ett hinder i felsökningssituationer vid analys av nätverkstrafikbegränsningar. Använd NSG:er på nätverkskortsnivån endast i exceptionella situationer och när det behövs.

Privata slutpunkter för tjänster

Många Azure PaaS-tjänster nås som standard via en offentlig slutpunkt. Även om kommunikationsslutpunkten finns i Azures serverdelsnätverk exponeras slutpunkten för det offentliga Internet. Privata slutpunkter är ett nätverksgränssnitt i ditt eget privata virtuella nätverk. Via Azure Private Link projicerar den privata slutpunkten tjänsten till ditt virtuella nätverk. Valda PaaS-tjänster nås sedan privat via IP-adressen i nätverket. Beroende på konfigurationen kan tjänsten vara inställd på att endast kommunicera via privat slutpunkt.

Att använda en privat slutpunkt ökar skyddet mot dataläckage, och det förenklar ofta åtkomsten från lokala och peer-kopplade nätverk. I många situationer förenklas nätverksroutningen och processen för att öppna brandväggsportar, som ofta behövs för offentliga slutpunkter. Resurserna finns redan i nätverket eftersom de nås av en privat slutpunkt.

Information om vilka Azure-tjänster som erbjuder alternativet att använda en privat slutpunkt finns i Private Link-tillgängliga tjänster. För NFS eller SMB med Azure Files rekommenderar vi att du alltid använder privata slutpunkter för SAP-arbetsbelastningar. Mer information om avgifter som uppstår med hjälp av tjänsten finns i Priser för privata slutpunkter. Vissa Azure-tjänster kan eventuellt inkludera kostnaden för tjänsten. Den här informationen ingår i en tjänsts prisinformation.

Kryptering

Beroende på företagets principer kan kryptering utöver standardalternativen i Azure krävas för dina SAP-arbetsbelastningar.

Kryptering för infrastrukturresurser

Som standard krypteras hanterade diskar och bloblagring i Azure med en plattformshanterad nyckel (PMK). Dessutom stöds BYOK-kryptering (Bring Your Own Key) för hanterade diskar och bloblagring för SAP-arbetsbelastningar i Azure. För kryptering av hanterade diskar kan du välja mellan olika alternativ, beroende på företagets säkerhetskrav. Bland alternativen för Azure-kryptering finns:

  • PMK för kryptering på lagringssidan (SSE) (SSE-PMK)
  • Kundhanterad SSE-nyckel (SSE-CMK)
  • Dubbel kryptering i vila
  • Värdbaserad kryptering

Mer information, inklusive en beskrivning av Azure Disk Encryption, finns i en jämförelse av Azure-krypteringsalternativ.

Kommentar

Använd för närvarande inte värdbaserad kryptering på en virtuell dator som finns i M-seriens VM-familj när du kör med Linux på grund av en potentiell prestandabegränsning. Användningen av SSE-CMK-kryptering för hanterade diskar påverkas inte av den här begränsningen.

Använd inte Azure Disk Encryption för SAP-distributioner på Linux-system. Azure Disk Encryption innebär att kryptering körs på de virtuella SAP-datorerna med hjälp av CMK:er från Azure Key Vault. För Linux stöder Inte Azure Disk Encryption operativsystemavbildningar som används för SAP-arbetsbelastningar. Azure Disk Encryption kan användas på Windows-system med SAP-arbetsbelastningar, men kombinera inte Azure Disk Encryption med intern databaskryptering. Vi rekommenderar att du använder intern databaskryptering i stället för Azure Disk Encryption. Mer information finns i nästa avsnitt.

Precis som med hanterad diskkryptering är Azure Files-kryptering i vila (SMB och NFS) tillgängligt med PMK:er eller CMK:er.

För SMB-nätverksresurser granskar du noggrant Azure Files och operativsystemberoenden med SMB-versioner eftersom konfigurationen påverkar stödet för kryptering under överföring.

Viktigt!

Vikten av en noggrann plan för att lagra och skydda krypteringsnycklarna om du använder kundhanterad kryptering kan inte överskattas. Utan krypteringsnycklar är krypterade resurser som diskar otillgängliga och kan leda till dataförlust. Överväg att skydda nycklarna och åtkomsten till nycklarna till endast privilegierade användare eller tjänster.

Kryptering för SAP-komponenter

Kryptering på SAP-nivå kan delas upp i två lager:

  • DBMS-kryptering
  • Transportkryptering

För DBMS-kryptering stöder varje databas som stöds för en SAP NetWeaver- eller SAP S/4HANA-distribution inbyggd kryptering. Transparent databaskryptering är helt oberoende av all infrastrukturkryptering som finns i Azure. Du kan använda SSE och databaskryptering samtidigt. När du använder kryptering är platsen, lagringen och förvaringen av krypteringsnycklar mycket viktigt. Förlust av krypteringsnycklar leder till dataförlust eftersom du inte kan starta eller återställa databasen.

Vissa databaser kanske inte har någon databaskrypteringsmetod eller kräver kanske ingen dedikerad inställning för att aktivera. För andra databaser kan DBMS-säkerhetskopior krypteras implicit när databaskryptering aktiveras. Se följande SAP-dokumentation för att lära dig hur du aktiverar och använder transparent databaskryptering:

Kontakta SAP eller din DBMS-leverantör för support om hur du aktiverar, använder eller felsöker programkryptering.

Viktigt!

Det kan inte överskattas hur viktigt det är att ha en noggrann plan för att lagra och skydda dina krypteringsnycklar. Utan krypteringsnycklar kan databasen eller SAP-programvaran vara otillgängliga och du kan förlora data. Överväg noggrant hur du skyddar nycklarna. Tillåt endast åtkomst till nycklarna av privilegierade användare eller tjänster.

Transport- eller kommunikationskryptering kan tillämpas på SQL Server-anslutningar mellan SAP-motorer och DBMS. På samma sätt kan du kryptera anslutningar från SAP-presentationsskiktet (SAPGui-säker nätverksanslutning eller SNC) eller en HTTPS-anslutning till en webbklientdel. Se programleverantörens dokumentation för att aktivera och hantera kryptering under överföring.

Hotövervakning och aviseringar

Börja med att använda organisationens arkitektur för att distribuera och använda hotövervaknings- och aviseringslösningar. Azure-tjänster ger skydd mot hot och en säkerhetsvy som du kan införliva i din övergripande SAP-distributionsplan. Microsoft Defender för molnet uppfyller kravet på skydd mot hot. Defender för molnet är vanligtvis en del av en övergripande styrningsmodell för en hel Azure-distribution, inte bara för SAP-komponenter.

Mer information om siem-lösningar (security information event management) och soar-lösningar (security orchestration automated response) finns i Microsoft Sentinel-lösningar för SAP-integrering.

Säkerhetsprogramvara i virtuella SAP-datorer

SAP Note 2808515 för Linux och SAP Note 106267 för Windows beskriver krav och metodtips när du använder virusskannrar eller säkerhetsprogram på SAP-servrar. Vi rekommenderar att du följer SAP-rekommendationerna när du distribuerar SAP-komponenter i Azure.

Hög tillgänglighet

SAP-hög tillgänglighet i Azure har två komponenter:

  • Hög tillgänglighet för Azure-infrastruktur: Hög tillgänglighet för Azure-beräkning (VM), nätverk och lagringstjänster samt hur de kan öka tillgängligheten för SAP-program.

  • Hög tillgänglighet för SAP-program: Hur det kan kombineras med hög tillgänglighet för Azure-infrastrukturen med hjälp av tjänståterställning. Ett exempel som använder hög tillgänglighet i SAP-programvarukomponenter:

    • En SAP (A)SCS- och SAP ERS-instans
    • Databasservern

Mer information om hög tillgänglighet för SAP i Azure finns i följande artiklar:

Pacemaker i Linux och Windows Server-redundanskluster är de enda ramverken för hög tillgänglighet för SAP-arbetsbelastningar som stöds direkt av Microsoft på Azure. Andra ramverk för hög tillgänglighet stöds inte av Microsoft och behöver design, implementeringsinformation och driftsstöd från leverantören. Mer information finns i Scenarier som stöds för SAP i Azure.

Haveriberedskap

Ofta är SAP-program bland de mest affärskritiska processerna i ett företag. Baserat på deras betydelse och den tid som krävs för att fungera igen efter ett oförutseddt avbrott bör scenarier för affärskontinuitet och haveriberedskap (BCDR) planeras noggrant.

Information om hur du hanterar det här kravet finns i Översikt över haveriberedskap och riktlinjer för infrastruktur för SAP-arbetsbelastning.

Backup

Som en del av din BCDR-strategi måste säkerhetskopiering för DIN SAP-arbetsbelastning vara en integrerad del av alla planerade distributioner. Säkerhetskopieringslösningen måste omfatta alla lager i en SAP-lösningsstack: virtuell dator, operativsystem, SAP-programlager, DBMS-lager och alla delade lagringslösningar. Säkerhetskopiering för Azure-tjänster som används av din SAP-arbetsbelastning och för andra viktiga resurser som kryptering och åtkomstnycklar måste också ingå i din säkerhetskopiering och BCDR-design.

Azure Backup erbjuder PaaS-lösningar för säkerhetskopiering:

  • VM-konfiguration, operativsystem och SAP-programlager (storleksändring på hanterade diskar) via Azure Backup för virtuell dator. Granska supportmatrisen för att kontrollera att din arkitektur kan använda den här lösningen.
  • SQL Server - och SAP HANA-databasdata och loggsäkerhetskopiering. Den innehåller stöd för databasreplikeringstekniker, till exempel HANA-systemreplikering eller SQL Always On och stöd mellan regioner för parkopplade regioner.
  • Säkerhetskopiering av filresurser via Azure Files. Kontrollera stödet för NFS eller SMB och annan konfigurationsinformation.

Om du distribuerar Azure NetApp Files är alternativ för säkerhetskopiering tillgängliga på volymnivå, inklusive SAP HANA- och Oracle DBMS-integrering med en schemalagd säkerhetskopiering.

Azure Backup-lösningar erbjuder ett alternativ för mjuk borttagning för att förhindra skadlig eller oavsiktlig borttagning och för att förhindra dataförlust. Mjuk borttagning är också tillgängligt för filresurser som du distribuerar med hjälp av Azure Files.

Säkerhetskopieringsalternativ är tillgängliga för en lösning som du skapar och hanterar själv, eller om du använder programvara från tredje part. Ett alternativ är att använda tjänsterna med Azure Storage, bland annat genom att använda oföränderlig lagring för blobdata. Det här självhanterade alternativet krävs för närvarande som ett alternativ för DBMS-säkerhetskopiering för vissa databaser som SAP ASE eller IBM Db2.

Använd rekommendationerna i Metodtips för Azure för att skydda och validera mot utpressningstrojanattacker .

Dricks

Se till att din säkerhetskopieringsstrategi omfattar skydd av distributionsautomation, krypteringsnycklar för Azure-resurser och transparent databaskryptering om den används.

Säkerhetskopiering mellan regioner

För alla krav på säkerhetskopiering mellan regioner fastställer du mål för återställningstid (RTO) och mål för återställningspunkt (RPO) som erbjuds av lösningen och om det matchar din BCDR-design och dina behov.

SAP-migrering till Azure

Det går inte att beskriva alla migreringsmetoder och alternativ för de många olika SAP-produkter, versionsberoenden och interna operativsystem och DBMS-tekniker som är tillgängliga. Projektteamet för din organisation och representanter från tjänstleverantörssidan bör överväga flera tekniker för en smidig SAP-migrering till Azure.

  • Testa prestanda under migreringen. En viktig del av SAP-migreringsplaneringen är teknisk prestandatestning. Migreringsteamet måste ge nyckelpersonalen tillräckligt med tid och tillgänglighet för att köra program och teknisk testning av det migrerade SAP-systemet, inklusive anslutna gränssnitt och program. För en lyckad SAP-migrering är det viktigt att jämföra körningen före och efter migreringen och noggrannheten för viktiga affärsprocesser i en testmiljö. Använd informationen för att optimera processerna innan du migrerar produktionsmiljön.

  • Använda Azure-tjänster för SAP-migrering. Vissa VM-baserade arbetsbelastningar migreras utan ändring till Azure med hjälp av tjänster som Azure Migrate eller Azure Site Recovery eller ett verktyg från tredje part. Bekräfta noggrant att operativsystemets version och DEN SAP-arbetsbelastning som körs stöds av tjänsten.

    Ofta stöds inte databasarbetsbelastningar avsiktligt eftersom en tjänst inte kan garantera databaskonsekvens. Om DBMS-typen stöds av migreringstjänsten är databasändrings- eller omsättningshastigheten ofta för hög. De mest upptagna SAP-systemen uppfyller inte den ändringsfrekvens som migreringsverktyg tillåter. Problem kanske inte visas eller identifieras förrän produktionsmigreringen. I många situationer är vissa Azure-tjänster inte lämpliga för migrering av SAP-system. Azure Site Recovery och Azure Migrate har ingen validering för en storskalig SAP-migrering. En beprövad SAP-migreringsmetod är att förlita sig på DBMS-replikerings- eller SAP-migreringsverktyg.

    En distribution i Azure i stället för en grundläggande vm-migrering är att föredra och enklare att utföra än en lokal migrering. Automatiserade distributionsramverk som Azure Center for SAP-lösningar och Azure Deployment Automation Framework möjliggör snabb körning av automatiserade uppgifter. Om du vill migrera ditt SAP-landskap till en ny distribuerad infrastruktur med hjälp av dbms interna replikeringstekniker som HANA-systemreplikering, DBMS-säkerhetskopiering och återställning eller SAP-migreringsverktyg använder du etablerade tekniska kunskaper om ditt SAP-system.

  • Uppskalning av infrastruktur. Under en SAP-migrering kan mer infrastrukturkapacitet hjälpa dig att distribuera snabbare. Projektteamet bör överväga att skala upp storleken på den virtuella datorn för att ge mer CPU och minne. Teamet bör också överväga att skala upp mängdlagring och nätverksdataflöde för virtuella datorer. På samma sätt kan du på VM-nivå överväga lagringselement som enskilda diskar för att öka dataflödet med burst-prestandanivåer på begäran och prestandanivåer för Premium SSD v1. Öka IOPS- och dataflödesvärdena om du använder Premium SSD v2 över de konfigurerade värdena. Förstora NFS- och SMB-filresurser för att öka prestandagränserna. Tänk på att Azure-hanteringsdiskar inte kan minskas i storlek, och att minskning av storlek, prestandanivåer och dataflödes-KPI:er kan ha olika nedkylningstider.

  • Optimera nätverks- och datakopiering. Att migrera ett SAP-system till Azure innebär alltid att flytta en stor mängd data. Data kan vara databas- och filsäkerhetskopior eller replikering, en dataöverföring från program till program eller en SAP-migreringsexport. Beroende på vilken migreringsprocess du använder måste du välja rätt nätverkssökväg för att flytta data. För många dataflyttsåtgärder är det snabbaste sättet att kopiera data till Azure Storage att använda Internet i stället för ett privat nätverk.

    Att använda ExpressRoute eller ett VPN kan leda till flaskhalsar:

    • Migreringsdata använder för mycket bandbredd och stör användaråtkomsten till arbetsbelastningar som körs i Azure.
    • Nätverksflaskhalsar lokalt, till exempel en brandvägg eller dataflödesbegränsning, identifieras ofta endast under migreringen.

    Oavsett vilken nätverksanslutning som används är nätverksprestandan för en dataström ofta låg. Om du vill öka dataöverföringshastigheten över flera TCP-strömmar använder du verktyg som stöder flera strömmar. Använd optimeringstekniker som beskrivs i SAP-dokumentationen och i många blogginlägg om det här ämnet.

Dricks

I planeringsfasen är det viktigt att överväga alla dedikerade migreringsnätverk som du använder för stora dataöverföringar till Azure. Exempel är säkerhetskopior eller databasreplikering eller användning av en offentlig slutpunkt för dataöverföringar till Azure Storage. Effekten av migreringen på nätverkssökvägar för dina användare och program bör förväntas och minimeras. Som en del av nätverksplaneringen bör du överväga alla faser av migreringen och kostnaden för en delvis produktiv arbetsbelastning i Azure under migreringen.

Stöd och åtgärder för SAP

Några andra områden är viktiga att tänka på före och under SAP-distributionen i Azure.

Azure VM-tillägg för SAP

Azure Monitoring Extension, Enhanced Monitoring och Azure Extension for SAP refererar alla till ett VM-tillägg som du behöver distribuera för att tillhandahålla grundläggande data om Azure-infrastrukturen till SAP-värdagenten. SAP-anteckningar kan referera till tillägget som Övervakningstillägg eller Utökad övervakning. I Azure kallas det Azure-tillägg för SAP. I supportsyfte måste tillägget installeras på alla virtuella Azure-datorer som kör en SAP-arbetsbelastning. Mer information finns i Azure VM-tillägget för SAP.

SAProuter för SAP-stöd

För att hantera ett SAP-landskap i Azure krävs anslutning till och från SAP i supportsyfte. Vanligtvis är anslutningen i form av en SAProuter-anslutning, antingen om den är via en krypteringsnätverkskanal via Internet eller via en privat VPN-anslutning till SAP. Metodtips och exempelimplementering av SAProuter i Azure finns i ditt arkitekturscenario i Inkommande och utgående Internetanslutningar för SAP i Azure.

Nästa steg