SAP-arbetsbelastningar i Azure: Checklista för planering och distribution
Artikel
Den här checklistan är utformad för kunder som flyttar SAP-program till Azure-infrastruktur som en tjänst. SAP-program i det här dokumentet representerar SAP-produkter som kör SAP-kerneln, inklusive SAP NetWeaver, S/4HANA, BW och BW/4 med flera. Under projektets varaktighet bör en kund och/eller SAP-partner granska checklistan. Det är viktigt att observera att många av kontrollerna slutförs i början av projektet och under planeringsfasen. När distributionen är klar kan enkla ändringar i distribuerad Azure-infrastruktur eller SAP-programvaruversioner bli komplexa.
Granska checklistan vid viktiga milstolpar under projektet. Om du gör det kan du identifiera små problem innan de blir stora problem. Du har också tillräckligt med tid för att återskapa och testa nödvändiga ändringar. Överväg inte att checklistan är klar. Beroende på din situation kan du behöva utföra ytterligare kontroller.
Checklistan innehåller inte uppgifter som är oberoende av Azure. Till exempel ändras SAP-programgränssnitten under en flytt till Azure-plattformen eller till en värdleverantör. SAP-dokumentationen och supportanteckningarna innehåller även ytterligare uppgifter, som inte är Specifika för Azure men som måste ingå i din övergripande planeringschecklista.
Den här checklistan kan också användas för system som redan har distribuerats. Nya funktioner eller ändrade rekommendationer kan gälla för din miljö. Det är användbart att regelbundet granska checklistan för att se till att du är medveten om nya funktioner i Azure-plattformen.
Huvudinnehållet i det här dokumentet ordnas på flikar i ett typiskt projekts kronologiska ordning. Se innehållet på varje flik och överväg varje nästa flik för att bygga vidare på åtgärder som utförts och utbildningar som erhölls i föregående fas. För produktionsmigrering bör innehållet på alla flikar beaktas och inte bara produktionsfliken. Information om hur du mappar vanliga projektfaser med den fasdefinition som används i den här artikeln finns i tabellen nedan.
Checklista för distributionsfaser
Exempel på projektfaser eller milstolpar
Förberedelse- och planeringsfas
Projektets kick-off/design- och definitionsfas
Pilotfasen
Tidig validering/konceptbevis/pilot
Icke-produktionsfas
Slutförande av detaljerad design/icke-produktionsmiljöversioner/testfas
Produktionsförberedelsefas
Genrep/godkännandetest för användare/mock cut-over/go-live checkar
Under den här fasen planerar du migreringen av DIN SAP-arbetsbelastning till Azure-plattformen. Dokument som planeringsguide för SAP i Azure och Cloud Adoption Framework för SAP beskriver många ämnen och hjälp som information i förberedelserna. Under den här fasen måste du åtminstone skapa följande dokument, definiera och diskutera följande element i migreringen:
Designdokument på hög nivå
Det här dokumentet ska innehålla:
Den aktuella inventeringen av SAP-komponenter och -program samt en målprograminventering för Azure.
En ansvarsfördelningsmatris (RACI) som definierar de berörda parternas ansvarsområden och tilldelningar. Börja på en hög nivå och arbeta till mer detaljerade nivåer under planeringen och de första distributionerna.
En lösningsarkitektur på hög nivå. Metodtips och exempelarkitekturer från Azure Architecture Center bör konsulteras.
En nätverksarkitektur för att ansluta från en lokal plats till Azure. Börja bekanta dig med begreppet landningszon i Azure Enterprise-skala.
Säkerhetsprinciper för att köra affärsdata med hög påverkan i Azure. Om du vill veta mer om datasäkerhet börjar du med Azure-säkerhetsdokumentationen.
Lagringsstrategi för blockenheter (Managed Disk) och delade filsystem (till exempel Azure Files eller Azure NetApp Files) som bör förfinas ytterligare till filsystemstorlekar och layouter i det tekniska designdokumentet.
Tekniskt designdokument
Det här dokumentet ska innehålla:
Ett blockdiagram för lösningen som visar SAP- och icke-SAP-program och -tjänster
Ett SAP Quicksizer-projekt baserat på affärsdokumentvolymer. Utdata från Quicksizer mappas sedan till beräknings-, lagrings- och nätverkskomponenter i Azure. Alternativt till SAP Quicksizer, noggrann storleksändring baserat på aktuell arbetsbelastning för käll-SAP-system. Med hänsyn till tillgänglig information, till exempel DBMS-arbetsbelastningsrapporter, SAP EarlyWatch-rapporter, beräknings- och lagringsprestandaindikatorer.
Arkitektur för affärskontinuitet och haveriberedskap.
Detaljerad information om versioner av OS, DB, kernel och SAP-supportpaket. Det är inte nödvändigtvis sant att varje version av operativsystemet som stöds av SAP NetWeaver eller S/4HANA stöds på virtuella Azure-datorer. Detsamma gäller för DBMS-versioner. Kontrollera följande källor för att justera och vid behov uppgradera SAP-versioner, DBMS-versioner och OS-versioner för att säkerställa SAP- och Azure-support. Du måste ha versionskombinationer som stöds av SAP och Azure för att få fullständig support från SAP och Microsoft. Om det behövs måste du planera för uppgradering av vissa programvarukomponenter. Mer information om SAP-, OS- och DBMS-programvara som stöds finns här:
SAP-anteckning 2039619. Den här anteckningen definierar Oracle-supportmatrisen för Azure. Oracle stöder endast Windows och Oracle Linux som gästoperativsystem i Azure för SAP-arbetsbelastningar. Den här support-instruktionen gäller även för SAP-programskiktet som kör SAP-instanser, så länge de innehåller Oracle-klienten.
Virtuella Azure-datorer som stöds av SAP HANA visas på SAP-webbplatsen. Information om varje post innehåller detaljer och krav, inklusive operativsystemversion som stöds. Detta kanske inte matchar den senaste versionen av operativsystemet enligt SAP-2235581.
Hanterade diskar som är anslutna till varje virtuell dator
Filsystemlayouter och storleksändring
SMB- och/eller NFS-volymlayout och -storlekar, monteringspunkter där det är tillämpligt
Arkitektur för hög tillgänglighet, säkerhetskopiering och haveriberedskap
Baserat på RTO och RPO definierar du hur arkitekturen för hög tillgänglighet och haveriberedskap måste se ut.
Förstå användningen av olika distributionstyper för optimalt skydd.
Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastningar och relaterade dokument. I Azure stöds inte användning av en konfiguration av delad disk för DBMS-lagret, som till exempel beskrivs för SQL Server. Använd i stället lösningar som:
Information om haveriberedskap i Azure-regioner finns i lösningarna som erbjuds av olika DBMS-leverantörer. De flesta stöder asynkron replikering eller loggleverans.
För SAP-programlagret avgör du om du ska köra dina affärsregressionstestsystem, som helst är repliker av dina produktionsdistributioner, i samma Azure-region eller i din DR-region. I det andra fallet kan du rikta in dig på det affärsregressionssystemet som DR-mål för dina produktionsdistributioner.
För projekt som krävs för att stanna kvar i en enda region av efterlevnadsskäl bör du överväga en kombinerad HADR-konfiguration med hjälp av Azure Tillgänglighetszoner.
En inventering av alla SAP-gränssnitt och anslutna system (SAP och icke-SAP).
Utformning av grundläggande tjänster. Den här designen bör innehålla följande objekt, varav många omfattas av landningszonacceleratorn för SAP:
Nätverkstopologi i Azure och tilldelning av olika SAP-miljöer
Active Directory- och DNS-design.
Identitetshanteringslösning för både slutanvändare och administration
Säkerhetsåtgärder för Azure-resurser och arbetsbelastningar i
Säkerhetskoncept för att skydda din SAP-arbetsbelastning. Detta bör omfatta alla aspekter – nätverks- och perimeterövervakning, program- och databassäkerhet, skydd av operativsystem och eventuella infrastrukturåtgärder som krävs, till exempel kryptering. Identifiera kraven med dina efterlevnads- och säkerhetsteam.
Microsoft rekommenderar antingen Professional Direct-, Premier- eller Unified Support-kontrakt. Identifiera dina eskaleringsvägar och kontakter för support med Microsoft. Sap-supportkrav finns i SAP-2015553.
Dataminskning och datamigreringsplan för migrering av SAP-data till Azure. För SAP NetWeaver-system har SAP riktlinjer för hur du begränsar mängden stora mängder data. Se den här SAP-guiden om datahantering i SAP ERP-system. En del av innehållet gäller även för NetWeaver- och S/4HANA-system i allmänhet.
En automatiserad distributionsmetod. Många kunder börjar med skript med hjälp av en kombination av PowerShell, CLI, Ansible och Terraform.
Microsofts utvecklade lösningar för SAP-distributionsautomatisering är:
Definiera en regelbunden design- och distributionsgranskningstakt mellan dig som kund, systemintegratör, Microsoft och andra berörda parter.
Pilotfas (rekommenderas starkt)
Du kan köra ett pilotprojekt före eller under projektplanering och förberedelse. Du kan också använda pilotfasen för att testa metoder och design som gjorts under planerings- och förberedelsefasen. Och du kan utöka pilotfasen för att göra den till ett verkligt konceptbevis.
Vi rekommenderar att du konfigurerar och validerar en fullständig HADR-lösning och säkerhetsdesign under en pilotdistribution. Vissa kunder utför skalbarhetstester under den här fasen. Andra kunder använder distributioner av SAP-sandbox-system som en pilotfas. Vi antar att du redan har identifierat ett system som du vill migrera till Azure för piloten.
Optimera dataöverföring till Azure. Det optimala valet är starkt beroende av det specifika scenariot. Om privat anslutning krävs för databasreplikering är Azure ExpressRoute snabbast om ExpressRoute-kretsen har tillräckligt med bandbredd. I andra scenarion går det snabbare att överföra via Internet. Du kan också använda ett dedikerat VPN för migrering för privat anslutning till Azure. Alla sökvägar för migreringsnätverk under pilottest bör spegla användningen för framtida produktionssystem, vilket eliminerar eventuella effekter på arbetsbelastningar – SAP eller icke-SAP – som redan körs i Azure.
För en heterogen SAP-migrering som omfattar export och import av data testar och optimerar du export- och importfaserna. För migrering av stora SAP-miljöer går du igenom tillgängliga metodtips. Använd lämpligt verktyg för migreringsscenariot, beroende på dina SAP-käll- och målversioner, DBMS och om du kombinerar migrering med andra uppgifter som versionsuppgradering eller till och med Unicode- eller S/4HANA-konvertering. SAP tillhandahåller Migration Monitor/SWPM, SAP DMO eller DMO med systemflytt, förutom andra metoder för att minimera stilleståndstiden som är tillgänglig som separat tjänst från SAP. I de senaste versionerna av SAP DMO med systemflytt stöds även användningen av azcopy för dataöverföring via Internet, vilket möjliggör den snabbaste nätverksvägen internt.
Migrera mycket stora databaser (VLDB) till Azure för SAP
Teknisk validering
Beräknings-/VM-typer
Granska resurserna i SAP-supportanteckningar, i SAP HANA-maskinvarukatalogen och i SAP PAM igen. Se till att matcha virtuella datorer som stöds för Azure, operativsystemversioner som stöds för dessa typer av virtuella datorer och sap- och DBMS-versioner som stöds.
Utvärdera och testa storleken på dina virtuella Azure-datorer för maximalt lagrings- och nätverksdataflöde för de vm-typer som du valde under planeringsfasen. Information om prestandabegränsningar för virtuella datorer är tillgängliga, för lagring är det viktigt att överväga gränsen för maximalt diskdataflöde som inte är tillgängligt för storleksändring. Överväg noggrant storlek och tillfälliga effekter av disk- och VM-nivåstoppar.
Testa och avgöra om du vill skapa egna OS-avbildningar för dina virtuella datorer i Azure eller om du vill använda en avbildning från Azure Compute-galleriet (tidigare kallat delat bildgalleri). Om du använder en avbildning från Azure-beräkningsgalleriet ska du använda en avbildning som återspeglar supportavtalet med din OS-leverantör. För vissa OS-leverantörer kan du med Azure Compute Gallery ta med dina egna licensavbildningar. För andra OS-avbildningar ingår stöd i priset som anges av Azure.
Med egna OS-avbildningar kan du lagra nödvändiga företagsberoenden, till exempel säkerhetsagenter, härdning och anpassningar direkt i avbildningen. På så sätt distribueras de omedelbart med varje virtuell dator. Om du bestämmer dig för att skapa egna OS-avbildningar kan du hitta dokumentationen i följande artiklar:
Om du använder Linux-avbildningar från Azure-beräkningsgalleriet och lägger till härdning som en del av distributionspipelinen måste du använda de avbildningar som är lämpliga för SAP som tillhandahålls av Linux-leverantörerna.
Använd som minst Azure Standard SSD-lagring för virtuella datorer som representerar SAP-programlager och för distribution av DBMS som inte är prestandakänsliga. Tänk på att olika Azure-lagringstyper påverkar serviceavtalet för enkel VM-tillgänglighet.
I allmänhet rekommenderar vi inte användning av Standard HDD-diskar i Azure för SAP.
För de olika DBMS-typerna kontrollerar du den generiska SAP-relaterade DBMS-dokumentationen och DBMS-specifik dokumentation som det första dokumentet pekar på. Använd disklistning över flera diskar med premiumlagring (v1 eller v2) för databasdata och loggområde. Kontrollera att lvm-disklistning är aktiv och med rätt randstorlek med kommandot "lvs -a -o+lv_layout,lv_role,stripes,stripe_size,devices" på Linux, se egenskaper för lagringsutrymmen i Windows.
Optimal lagringskonfiguration med SAP HANA finns i LAGRINGskonfigurationer för virtuella SAP HANA Azure-datorer.
Använd LVM för alla diskar på virtuella Linux-datorer, eftersom det möjliggör enklare hantering och onlineexpansion. Detta inkluderar volymer på enskilda diskar, till exempel /usr/sap.
Nätverk
Testa och utvärdera infrastrukturen för det virtuella nätverket och distributionen av dina SAP-program över eller inom de olika virtuella Azure-nätverken.
Utvärdera metoden hub-and-spoke eller virtual WAN virtual network architecture med diskreta virtuella nätverk(er) ekrar för SAP-arbetsbelastning. För mindre skala, mikrosegmenteringsmetod i ett enda virtuellt Azure-nätverk. Basera den här utvärderingen på:
Fördelar med en snabb frånkoppling av peering mellan virtuella Azure-nätverk i stället för att ändra nätverkssäkerhetsgruppen för att isolera ett undernät i ett virtuellt nätverk. Den här utvärderingen gäller fall då program eller virtuella datorer som finns i ett undernät i det virtuella nätverket blev en säkerhetsrisk.
Central loggning och granskning av nätverkstrafik mellan lokalt, omvärlden och det virtuella datacenter som du skapade i Azure.
Utvärdera och testa datasökvägen mellan SAP-programlagret och SAP DBMS-lagret.
Placering av virtuella Azure-nätverksinstallationer i kommunikationssökvägen mellan SAP-programmet och DBMS-lagret av SAP-system som kör SAP-kerneln stöds inte.
Placering av SAP-programskiktet och SAP DBMS i olika virtuella Azure-nätverk som inte är peer-kopplade stöds inte.
Kontrollera att accelererat nätverk är aktiverat på varje virtuell dator som används för SAP.
Testa och utvärdera nätverksfördröjningen mellan virtuella DATORER på SAP-programnivå och virtuella DBMS-datorer enligt SAP-anteckningar 500235 och 1100926. Förutom SAP:s niping kan du använda verktyg som sockperf eller ethr för tcp-svarstidsmätning. Utvärdera resultaten mot vägledningen för nätverksfördröjning i SAP-1100926. Nätverksfördröjningen bör vara inom det måttliga eller bra intervallet.
Optimera nätverkets dataflöde på virtuella datorer med hög vCPU, som vanligtvis används för databasservrar. Särskilt viktigt för HANA-utskalning och alla stora SAP-system. Följ rekommendationerna i den här artikeln för optimering.
För optimal nätverksfördröjning bör du följa riktlinjerna i artikeln närhetsplaceringsscenarier. Ingen användning av närhetsplaceringsgrupper för zonindelade eller zonöverskridande distributionsmönster.
Kontrollera korrekt tillgänglighet, routning och säker åtkomst från SAP-liggande till alla nödvändiga Internetslutpunkter, till exempel os-korrigeringsdatabaser, distributionsverktyg eller tjänstslutpunkt. Om SAP-miljön på samma sätt tillhandahåller en offentligt tillgänglig tjänst, till exempel SAP Fiori eller SAProuter, kontrollerar du att den kan nås och skyddas.
Distributioner med hög tillgänglighet och haveriberedskap
Använd alltid standardlastbalanserare för klustrade miljöer. Den grundläggande lastbalanseraren dras tillbaka.
Välj lämpliga distributionsalternativ beroende på vilken systemkonfiguration du föredrar i en Azure-region, oavsett om det handlar om att sträcka sig över zoner, finnas i en enda zon eller arbeta i en zonlös region.
För att skydda SAP:s centrala tjänster och DBMS-lager för hög tillgänglighet med hjälp av passiv replikering, placerar du de två noderna för SAP Central Services i en separat tillgänglighetsuppsättning och de två DBMS-noderna i en annan tillgänglighetsuppsättning. Blanda inte program-VM-roller i en tillgänglighetsuppsättning.
För distribution mellan zonindelningar konfigurerar du systemet med flexibel skalningsuppsättning med FD=1 och distribuerar de aktiva och passiva noderna för centrala tjänster och DBMS-lagret i två olika tillgänglighetszoner. Använd två tillgänglighetszoner som har den lägsta svarstiden mellan dem.
För distribution mellan zonindelningar rekommenderar vi att du använder flexibel skalningsuppsättning med FD=1 över standarddistribution av tillgänglighetszoner.
Om du använder Azure Load Balancer tillsammans med Linux-gästoperativsystem kontrollerar du att Linux-nätverksparametern net.ipv4.tcp_timestamps är inställd på 0. Den här rekommendationen står i konflikt med rekommendationer i äldre versioner av SAP-2382421. SAP-anteckningen har nu uppdaterats för att ange att den här parametern måste vara inställd på 0 för att fungera med Azure-lastbalanserare.
Tidsgränsinställningar
Kontrollera SAP NetWeaver-utvecklarspårningarna för SAP-instanserna för att se till att det inte finns några anslutningsbrytningar mellan den köade servern och SAP-arbetsprocesserna. Du kan undvika dessa anslutningsbrytningar genom att ange följande två registerparametrar:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Mer information finns i KeepAliveTime.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Mer information finns i KeepAliveInterval.
Om du vill undvika GUI-timeouter mellan lokala SAP GUI-gränssnitt och SAP-programlager som distribueras i Azure kontrollerar du om dessa parametrar anges i default.pfl eller instansprofilen:
rdisp/keepalive_timeout = 3600
rdisp/keepalive = 20
För att förhindra avbrott i etablerade anslutningar mellan SAP-processen och SAP-arbetsprocesserna måste du ange parametern enque/encni/set_so_keepalive till true. Se även SAP-2743751.
Om du använder en konfiguration av Windows-redundanskluster kontrollerar du att tiden för att reagera på noder som inte svarar är korrekt inställd för Azure. Artikeln Tuning Failover Cluster Network Thresholds listar parametrar och hur de påverkar känslighet för redundans. Förutsatt att klusternoderna finns i samma undernät bör du ändra följande parametrar:
SameSubNetDelay = 2000 (antal millisekunder mellan "pulsslag")
SameSubNetThreshold = 15 (maximalt antal på varandra följande missade pulsslag)
Om du vill köra HANA på SAP läser du de här anteckningarna och dokumentationen, utöver SAP:s icke-Azure-specifika dokumentation och andra supportanteckningar:
Azure-specifika SAP-anteckningar som är länkade till SAP-stödkomponenterna BC-OP-NT-AZR eller BC-OP-LNX-AZR. Gå igenom anteckningarna i detalj eftersom de innehåller uppdaterade lösningar
Testa procedurerna för hög tillgänglighet och haveriberedskap
Simulera redundanssituationer med hjälp av ett verktyg som NotMyFault (Windows) eller för att sätta operativsystem i panikläge eller inaktivera nätverksgränssnittet med ifdown (Linux). Det här steget hjälper dig att ta reda på om dina redundanskonfigurationer fungerar som de är utformade.
Mät hur lång tid det tar att köra en redundansväxling. Om tiderna är för långa bör du tänka på följande:
För SUSE Linux använder du SBD-enheter i stället för Azure Fence-agenten för att påskynda redundansväxlingen.
För SAP HANA kan du överväga att etablera mer lagringsbandbredd om omladdningen av data tar för lång tid.
Testa sekvensen och tidpunkten för säkerhetskopiering/återställning och gör korrigeringar om du behöver det. Kontrollera att säkerhetskopieringstiderna är tillräckliga. Du måste också testa återställnings- och tidsåterställningsaktiviteterna. Kontrollera att återställningstiderna ligger inom dina RTO-serviceavtal oavsett var din RTO förlitar sig på en databas- eller vm-återställningsprocess.
Testa dr-funktioner och arkitektur mellan regioner, kontrollera att RPO och RTO matchar dina förväntningar
Säkerhetskontroller
Testa giltigheten för din rollbaserade Azure-arkitektur för åtkomstkontroll (Azure RBAC). Uppdelning av uppgifter kräver att olika team separerar och begränsar åtkomst och behörigheter. Sap Basis-teammedlemmar bör till exempel kunna distribuera virtuella datorer och tilldela diskar från Azure Storage till en viss virtuell Azure-dator. Men SAP Basis-teamet bör inte kunna skapa egna virtuella nätverk eller ändra inställningarna för befintliga virtuella nätverk. Medlemmar i nätverksteamet bör inte kunna distribuera virtuella datorer till virtuella nätverk där SAP-program och virtuella DBMS-datorer körs. Medlemmar i det här teamet bör inte heller kunna ändra attribut för virtuella datorer eller till och med ta bort virtuella datorer eller diskar.
Kontrollera att alla resurser som behöver krypteras är krypterade. Definiera och implementera processer för att säkerhetskopiera certifikat, lagra och komma åt dessa certifikat och återställa de krypterade entiteterna.
För lagringskryptering är kryptering på serversidan med plattformshanterad nyckel (SSE-PMK) aktiverad för varje lagringstjänst som används för SAP i Azure som standard, inklusive hanterade diskar, Azure Files och Azure NetApp Files. Nyckelhantering med kundhanterade nycklar kan övervägas om det behövs för kundägd nyckelrotation.
Värdbaserad kryptering på serversidan bör inte aktiveras av prestandaskäl på virtuella Linux-datorer i M-serien.
Använd inte Azure Disk Encryption på Linux med SAP eftersom OS-avbildningar för SAP inte stöds.
Databasinbyggt kryptering distribueras av de flesta SAP på Azure-kunder för att skydda DBMS-data och säkerhetskopior. transparent datakryptering (TDE) har vanligtvis inga märkbara prestandakostnader, ökar säkerheten avsevärt och bör övervägas. Hantering och plats för krypteringsnycklar måste skyddas. Databaskryptering sker i den virtuella datorn och är oberoende av lagringskryptering, till exempel SSE.
Prestandatestning i SAP, baserat på SAP-spårning och mätningar, gör följande jämförelser:
Inventering och baslinje för det aktuella lokala systemet.
SAR-rapporter/perfmon.
STAT spårar de 10 främsta onlinerapporterna.
Samla in batchjobbhistorik.
Fokustestning för att verifiera prestanda för affärsprocesser. Jämför inte maskinvaru-KPI:er från början och i ett vakuum, bara när du felsöker eventuella prestandaskillnader.
Jämför i tillämpliga fall de 10 främsta onlinerapporterna med din aktuella implementering.
Jämför i tillämpliga fall de 10 främsta batchjobben med din aktuella implementering.
Jämför dataöverföringar via gränssnitt till SAP-systemet. Fokusera på gränssnitt där du vet att överföringen sker mellan olika platser, till exempel lokalt till Azure.
Icke-produktionsfas
I den här fasen förutsätter vi att du efter ett lyckat pilotprojekt eller konceptbevis (POC) börjar distribuera icke-produktionsbaserade SAP-system till Azure. Införliva allt du har lärt dig och upplevt under POC i den här distributionen. Alla kriterier och steg som anges för POC:er gäller även för den här distributionen.
Under den här fasen distribuerar du vanligtvis utvecklingssystem, enhetstestsystem och testsystem för affärsregression till Azure. Vi rekommenderar att minst ett icke-produktionssystem i en SAP-programrad har den fullständiga konfiguration med hög tillgänglighet som det framtida produktionssystemet kommer att ha. Här följer några uppgifter som du behöver utföra under den här fasen:
Innan du flyttar system från den gamla plattformen till Azure samlar du in resursförbrukningsdata, till exempel CPU-användning, lagringsdataflöde och IOPS-data. Samla särskilt in dessa data från DBMS-lagerenheterna, men samla även in dem från programlagerenheterna. Mät även nätverks- och lagringsfördröjning. Anpassa storlek och design med insamlade data. Verktyg som syststat, KSAR, nmon och nmon analyzer för Excel bör användas för att samla in och presentera resursutnyttjande under perioder med hög belastning.
Registrera systemens användningstidsmönster för tillgänglighet. Målet är att ta reda på om icke-produktionssystem måste vara tillgängliga hela dagen, varje dag eller om det finns icke-produktionssystem som kan stängas av under vissa faser i en vecka eller månad.
Omvärdera valet av operativsystemavbildning, VM-generering (generation 2 i SAP-landskapet) och strategi för os-korrigering.
Se till att uppfylla SAP-supportkraven för Microsoft-supportavtal. Se SAP-anteckning 2015553.
Se SAP-anteckningar relaterade till Azure, t.ex . anteckning 1928533, för nya VM-SKU:er och nyligen stödda versioner av OPERATIVSYSTEM och DBMS. Jämför prissättningen för nya typer av virtuella datorer med priserna för äldre typer av virtuella datorer så att du kan distribuera virtuella datorer med bästa pris/prestanda-förhållande.
Kontrollera SAP-supportanteckningarna, SAP HANA-maskinvarukatalogen och SAP PAM igen. Kontrollera att det inte fanns några ändringar i virtuella datorer som stöds för Azure, operativsystemversioner som stöds på dessa virtuella datorer och som stöds av SAP- och DBMS-versioner.
Kontrollera SAP-webbplatsen för nya HANA-certifierade SKU:er i Azure. Jämför prissättningen för nya SKU:er med de som du planerade att använda. Så småningom gör du nödvändiga ändringar för att använda de som har det bästa förhållandet mellan pris och prestanda.
Anpassa distributionsautomationen så att den använder nya typer av virtuella datorer och införliva nya Azure-funktioner som du vill använda.
Efter distributionen av infrastrukturen testar och utvärderar du nätverksfördröjningen mellan virtuella datorer i SAP-programskiktet och virtuella DBMS-datorer, enligt SAP-anteckningar 500235. Utvärdera resultaten mot vägledningen för nätverksfördröjning i SAP-1100926. Nätverksfördröjningen bör vara inom det måttliga eller bra intervallet. Förutom att använda verktyg som niping, sockperf eller ethr använder du SAP:s HCMT-verktyg för nätverksmätningar mellan virtuella HANA-datorer för utskalning eller systemreplikering.
Om svarstiden är högre än förväntat mellan virtuella datorer kan du följa riktlinjerna i artikeln närhetsplaceringsscenarier.
Utför alla andra kontroller som anges för proof-of-concept-fasen innan du tillämpar arbetsbelastningen.
När arbetsbelastningen gäller registrerar du resursförbrukningen för systemen i Azure. Jämför den här förbrukningen med poster från din gamla plattform. Justera storleken på den virtuella datorn för framtida distributioner om du ser att du har stora skillnader. Tänk på att även när du minskar storleken, lagringen och nätverksbandbredden för virtuella datorer.
Experimentera med funktioner och processer för systemkopiering. Målet är att göra det enkelt för dig att kopiera ett utvecklingssystem eller ett testsystem, så att projektteam snabbt kan få nya system.
Optimera och förbättra teamets rollbaserade åtkomst, behörigheter och processer i Azure för att se till att du har olika uppgifter. Kontrollera samtidigt att alla team kan utföra sina uppgifter i Azure-infrastrukturen.
Öva, testa och dokumentera procedurer för hög tillgänglighet och haveriberedskap så att personalen kan utföra dessa uppgifter. Identifiera brister och anpassa nya Azure-funktioner som du integrerar i dina distributioner.
Produktionsförberedelsefas
I den här fasen samlar du in det du upplevde och lärde dig under dina distributioner som inte är produktionsbaserade och tillämpar det på framtida produktionsdistributioner.
Slutför eventuella nödvändiga SAP-versionsuppgraderingar av dina produktionssystem innan du flyttar till Azure.
Kom överens med företagsägarna om funktionella tester och affärstester som måste utföras efter migreringen av produktionssystemet.
Kontrollera att dessa tester har slutförts med källsystemen på den aktuella värdplatsen. Undvik att utföra tester för första gången när systemet har flyttats till Azure.
Testa processen med att migrera produktionssystem till Azure. Om du inte flyttar alla produktionssystem till Azure under samma tidsperiod skapar du grupper av produktionssystem som måste finnas på samma värdplats. Testa datamigrering, inklusive anslutna icke-SAP-program och gränssnitt.
Här följer några vanliga metoder:
Använd DBMS-metoder som säkerhetskopiering/återställning i kombination med SQL Server AlwaysOn, HANA-systemreplikering eller loggleverans för att hämta och synkronisera databasinnehåll i Azure.
Använd säkerhetskopiering/återställning för mindre databaser.
Använd SAP DMO-processen för scenarier som stöds för att antingen flytta eller om du behöver kombinera migreringen med en SAP-versionsuppgradering och/eller flytta till HANA. Tänk på att inte alla kombinationer av käll-DBMS och mål-DBMS stöds. Mer information finns i de specifika SAP-supportanteckningarna för de olika versionerna av DMO. Till exempel databasmigreringsalternativet (DMO) för SUM 2.0 SP15.
Testa om dataöverföringsdataflödet är bättre via Internet eller via ExpressRoute, om du behöver flytta säkerhetskopior eller SAP-exportfiler. Om du flyttar data via Internet kan du behöva ändra några av de regler för nätverkssäkerhetsgrupp/programsäkerhetsgrupp som du måste ha på plats för framtida produktionssystem.
Samla in resursförbrukningsdata innan du flyttar system från din gamla plattform till Azure. Användbara data omfattar CPU-användning, lagringsdataflöde och IOPS-data. Samla särskilt in dessa data från DBMS-lagerenheterna, men samla även in dem från programlagerenheterna. Mät även nätverks- och lagringsfördröjning.
Kontrollera SAP-anteckningarna igen och de operativsysteminställningar som krävs, SAP HANA-maskinvarukatalogen och SAP PAM. Kontrollera att det inte fanns några ändringar i virtuella datorer som stöds för Azure, operativsystemversioner som stöds på dessa virtuella datorer och som stöds av SAP- och DBMS-versioner.
Uppdatera distributionsautomationen för att ta hänsyn till de senaste besluten om VM-typer och Azure-funktioner.
Skapa en spelbok för att reagera på planerade Azure-underhållshändelser. Bestäm i vilken ordning system och virtuella datorer ska startas om för planerat underhåll.
Öva, testa och dokumentera procedurer för hög tillgänglighet och haveriberedskap så att personalen kan utföra dessa uppgifter under migreringen och omedelbart efter direkt beslut.
Go-live-fas
Under go-live-fasen ska du följa de spelböcker som du utvecklade under tidigare faser. Kör de steg som du har testat och övat på. Acceptera inte ändringar i sista minuten i konfigurationer och processer. Slutför även följande steg:
Kontrollera att Övervakning av Azure-portalen och andra övervakningsverktyg fungerar. Använd Azure-verktyg som Azure Monitor för infrastrukturövervakning. Azure Monitor för SAP för en kombination av KPI:er för operativsystem och program, så att du kan integrera alla i en instrumentpanel för synlighet under och efter live-användning.
För nyckeltal för operativsystemet:
I Linux kontrollerar du att sysstat-verktyget är installerat och samlar in information med jämna mellanrum
Efter datamigreringen utför du alla valideringstester som du kommit överens om med företagsägarna. Acceptera endast valideringstestresultat när du har resultat för de ursprungliga källsystemen.
Kontrollera om gränssnitten fungerar och om andra program kan kommunicera med de nyligen distribuerade produktionssystemen.
Kontrollera transport- och korrigeringssystemet via SAP-transaktionens STMS.
Utför databassäkerhetskopior när systemet har släppts för produktion.
Utför vm-säkerhetskopieringar för virtuella SAP-programlagerdatorer när systemet har släppts för produktion.
För SAP-system som inte ingick i den aktuella go-live-fasen men som kommunicerar med DE SAP-system som du flyttade till Azure under den här fasen måste du återställa värdnamnsbufferten i SM51. Om du gör det tas de gamla cachelagrade IP-adresserna som är associerade med namnen på de programinstanser som du flyttade till Azure bort.
Efter produktion
Den här fasen handlar om övervakning, drift och administration av systemet. Från SAP-synpunkt gäller de vanliga uppgifter som du var skyldig att utföra på din gamla värdplats. Slutför även dessa Azure-specifika uppgifter:
Granska Azure-fakturor för system med höga avgifter. Installera en kultur av finOps och skapa en Azure-kostnadsoptimeringsfunktion i din organisation.
Optimera pris-/prestandaeffektiviteten på den virtuella datorn och lagringssidan.
När SAP på Azure har stabiliserats måste fokus övergå till en kultur med kontinuerlig storleksändring och kapacitetsgranskningar. Till skillnad från lokalt, där vi är stora under en lång period, är rätt storleksändring en viktig fördel med att köra SAP på Azure-arbetsbelastningar, och noggrann kapacitetsplanering kommer att vara nyckeln.
Optimera de tider då du kan stänga av system.
När lösningen har stabiliserats i Azure kan du överväga att flytta från en kommersiell modell med betala per användning och utnyttja reserverade Azure-instanser.
Planera och köra regelbundna haveriberedskapstest.
Definiera och implementera din strategi kring "ever-greeneing", för att anpassa din egen färdplan till Microsofts SAP on Azure-översikt för att dra nytta av utvecklingen av tekniken.
Checklista för SAP på Azure-infrastruktur
När du har distribuerat infrastruktur och program och innan varje migrering startar kontrollerar du att:
Rätt typer av virtuella datorer distribuerades med rätt attribut och lagringskonfiguration.
De virtuella datorerna är på ett uppdaterat operativsystem, DBMS och SAP Kernel version och korrigering och operativsystemet, DB och SAP Kernel uniform i hela liggande
Virtuella datorer skyddas och härdas efter behov och på ett enhetligt sätt i respektive miljö.
För Azure NetApp Files används rätt monteringsalternativ och volymerna har rätt storlek på rätt lagringsnivå.
Använda Azure-tjänster – Azure Files eller Azure NetApp Files – för alla SMB- eller NFS-volymer eller resurser. NFS-volymer eller SMB-resurser kan nås av respektive SAP-miljö eller enskilda SAP-system. Nätverksroutning till NFS/SMB-servern går via adressutrymme för privata nätverk med hjälp av privat slutpunkt om det behövs.
Inga virtuella nätverksinstallationer finns i kommunikationsvägen mellan SAP-programmet och DBMS-lagret av SAP-system baserat på SAP NetWeaver eller ABAP Platform.
Alla lastbalanserare för SAP-komponenter med hög tillgänglighet använder standardlastbalanserare med flytande IP- och HA-portar aktiverade.
SAP-program och DBMS VM:er placeras i samma eller olika undernät i ett virtuellt nätverk eller i virtuella nätverk som är direkt peerkopplade.
Regler för program- och nätverkssäkerhetsgrupper tillåter kommunikation efter behov och planeras och blockerar kommunikationen där det behövs.
Timeout-inställningarna har angetts korrekt, enligt beskrivningen tidigare.
Om du använder närhetsplaceringsgrupper kontrollerar du om tillgänglighetsuppsättningarna och deras virtuella datorer distribueras till rätt PPG.
Nätverksfördröjning mellan virtuella DATORER i SAP-programnivå och virtuella DBMS-datorer testas och verifieras enligt beskrivningen i SAP-anteckningar 500235 och 1100926. Utvärdera resultaten mot vägledningen för nätverksfördröjning i SAP-1100926. Nätverksfördröjningen bör vara inom det måttliga eller bra intervallet.
Kryptering implementerades vid behov och med lämplig krypteringsmetod.
Egna krypteringsnycklar skyddas mot förlust, förstörelse eller skadlig användning.
Gränssnitt och andra program kan ansluta till den nyligen distribuerade infrastrukturen.
Automatiserade kontroller och insikter i SAP-liggande
Flera av kontrollerna ovan är incheckade på automatiserat sätt med SAP på Azure Quality Check Tool. Dessa kontroller kan köras automatiskt med det angivna projektet med öppen källkod. Även om ingen automatisk reparation av problem som hittas utförs varnar verktyget om konfigurationen mot Microsofts rekommendationer.
Ytterligare verktyg för enklare distributionskontroller och dokumentresultat, planera nästa reparationssteg och i allmänhet optimera din SAP på Azure-liggande är:
Azure Well-Architected Framework granska En utvärdering av din arbetsbelastning med fokus på de fem huvudpelarna för tillförlitlighet, säkerhet, kostnadsoptimering, driftseffektivitet och prestandaeffektivitet. Stöder SAP-arbetsbelastningar och rekommenderas att köra en granskning i början och efter varje projektfas.
Azure Inventory Söker efter SAP En öppen källkod Azure Monitor-arbetsbok, som visar ditt Azure-lager med intelligens för att markera konfigurationsavvikelse och förbättra kvaliteten.