SAP-arbetsbelastningar i Azure: checklista för planering och distribution

  • Artikel
  • 24 minuter för att läsa

Den här checklistan är utformad för kunder som flyttar SAP NetWeaver-, S/4HANA- och Hybris-program till Azure-infrastruktur som en tjänst. Under projektets varaktighet bör en kund och/eller SAP-partner granska checklistan. Det är viktigt att notera att många av kontrollerna utförs i början av projektet och under planeringsfasen. När distributionen är klar kan enkla ändringar i distribuerad Azure-infrastruktur eller SAP-programvaruuppdateringar 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 konstruera om och testa eventuella nödvändiga ändringar. Överväg inte att den här checklistan är klar. Beroende på din situation kan du behöva utföra många fler kontroller.

Checklistan innehåller inte uppgifter som är oberoende av Azure. Till exempel ändras SAP-programgränssnitt under en flytt till Azure-plattformen eller till en värdleverantör.

Den här checklistan kan också användas för system som redan har distribuerats. Nya funktioner, som Skrivningsaccelerator och Tillgänglighetszoner, och nya typer av virtuella datorer kan ha lagts till sedan du distribuerade. Därför är det bra att granska checklistan regelbundet för att se till att du är medveten om nya funktioner i Azure-plattformen.

Project förberedelse- och planeringsfasen

Under den här fasen planerar du migreringen av din SAP-arbetsbelastning till Azure-plattformen. Under den här fasen måste du åtminstone skapa följande dokument och definiera och diskutera följande element i migreringen:

  1. 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 ansvarstilldelningsmatris (RACI) som definierar de berörda parternas ansvarsområden och tilldelningar. Börja på en hög nivå och arbeta med mer detaljerade nivåer under planeringen och de första distributionerna.
    • En lösningsarkitektur på hög nivå.
    • Ett beslut om vilka Azure-regioner som distributionen ska gå till. Se listan över Azure-regioner. Information om vilka tjänster som är tillgängliga i varje region finns i Produkt tillgänglig per region.
    • En nätverksarkitektur för att ansluta från en lokal plats till Azure. Börja bekanta dig med skissen för virtuellt datacenter för Azure.
    • Säkerhetsprinciper för att köra affärsdata med stor påverkan i Azure. Om du vill veta mer om datasäkerhet börjar du med azure-säkerhetsdokumentationen.
  2. Dokument om teknisk design. Det här dokumentet ska innehålla:
  3. En inventering av alla SAP-gränssnitt (SAP och icke-SAP).
  4. Design av grundläggande tjänster. Den här designen bör innehålla följande objekt:
  5. Microsoft Professional eller Premier Support kontrakt. Identifiera din Microsoft Technical Account Manager (TAM) om du har ett Premier Support-avtal med Microsoft. Information om SAP-supportkrav finns i SAP-supportanteckningen #2015553.
  6. Antalet Azure-prenumerationer och kärnkvoten för prenumerationerna. Öppna supportbegäranden för att öka kvoter för Azure-prenumerationer efter behov.
  7. 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.
  8. En automatiserad distributionsmetod. Målet med automatiseringen av infrastrukturdistributioner i Azure är att distribuera på ett deterministiskt sätt och få deterministiska resultat. Många kunder använder PowerShell- eller CLI-baserade skript. Men det finns olika tekniker med öppen källkod som du kan använda för att distribuera Azure-infrastruktur för SAP och även installera SAP-programvara. Du hittar exempel på GitHub:
  9. Definiera en regelbunden granskning av design och distribution mellan dig som kund, systemintegratör, Microsoft och andra berörda parter.

Du kan köra ett pilotprojekt före eller under projektplanering och förberedelser. Du kan också använda pilotfasen för att testa metoder och utformningar 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 ställer in 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 pilottestet.

  1. Optimera dataöverföringen till Azure. Det optimala valet är starkt beroende av det specifika scenariot. Överföringen från den lokala platsen till Azure ExpressRoute snabbast om ExpressRoute-kretsen har tillräckligt med bandbredd. I andra scenarier går det snabbare att överföra via Internet.
  2. För en heterogen SAP-plattformsmigrering som omfattar export och import av data testar och optimerar du export- och importfaserna. För stora migreringar där SQL Server är målplattformen hittar du rekommendationer. Du kan använda Migration Monitor/SWPM om du inte behöver en kombinerad lanseringsuppgradering. Du kan använda SAP DMO-processen när du kombinerar migreringen med en SAP-lanseringsuppgradering. För att göra det måste du uppfylla vissa krav för källans och målets DBMS-plattformskombination. Den här processen dokumenteras i Databasmigreringsalternativ (DMO) för SUM 2.0 SP03.
    1. Exportera till källa, exportera filuppladdning till Azure och importera prestanda. Maximera överlappningen mellan export och import.
    2. Utvärdera databasens volym på mål- och målplattformarna för storleksändring av infrastrukturen.
    3. Validera och optimera tidsinställningen.
  3. Teknisk validering.
    1. VM-typer.
      • Granska resurserna i SAP-supportanteckningarna, i SAP HANA-maskinvarukatalogen och i SAP PAM igen. Kontrollera att det inte finns några ändringar i de virtuella datorer som stöds för Azure, operativsystemsutgåvningar som stöds för dessa typer av virtuella datorer och SAP- och DBMS-versioner som stöds.
      • Validera storleksändringen för ditt program och den infrastruktur som du distribuerar i Azure igen. Om du flyttar befintliga program kan du ofta härleda nödvändiga SAPS från den infrastruktur som du använder och sap benchmark-webbsidan och jämföra den med SAPS-numren som anges i SAP-supportanteckningen #1928533. Tänk också på den här artikeln om SAPS-klassificeringar.
      • Utvärdera och testa storleksändringen för dina virtuella Azure-datorer med avseende på maximalt lagringsgenomflöde och nätverksgenomflöde för de VM-typer som du valde under planeringsfasen. Du hittar data här:
    2. Lagring.
      • Kontrollera dokumenttyperna Azure Storage SAP-arbetsbelastning
      • Använd minst Azure Standard SSD storage för virtuella datorer som representerar SAP-programlager och för distribution av DBMS som inte är prestandakänsliga.
      • I allmänhet rekommenderar vi inte att du använder Azure Standard HDD diskar.
      • Använd Azure Premium Storage för virtuella DBMS-datorer som är fjärrprestandakänsliga.
      • Använd Azure Managed Disks.
      • Använd Azure Skrivningsaccelerator för DBMS-loggenheter med M-serien. Tänk på Skrivningsaccelerator gränser och användning, enligt dokumenten i Skrivningsaccelerator.
      • För de olika DBMS-typerna kontrollerar du den allmänna SAP-relaterade DBMS-dokumentationen och den DBMS-specifika dokumentation som det allmänna dokumentet pekar på.
      • Mer information om SAP HANA finns i SAP HANA konfigurationer och åtgärder förinfrastruktur på Azure.
      • Montera aldrig Azure-datadiskar på en virtuell Linux-dator i Azure med hjälp av enhets-ID:t. Använd i stället den universellt unika identifieraren (UUID). Var försiktig när du till exempel använder grafiska verktyg för att montera Azure-datadiskar. Dubbelkolla posterna i /etc/fstab för att kontrollera att UUID används för att montera diskarna. Mer information finns i den här artikeln.
    3. Nätverk.
      • Testa och utvärdera din virtuella nätverksinfrastruktur och distributionen av dina SAP-program över eller inom olika virtuella Azure-nätverk.
      • Utvärdera metoden med nav och ekrar för virtuell nätverksarkitektur eller mikrosegmentering i ett enda virtuellt Azure-nätverk. Basera utvärderingen på: 1. Kostnader för datautbyte mellan peer-peerade virtuella Azure-nätverk. Information om kostnader finns i Virtual Network priser. 2. Fördelar med 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 är till för fall där program eller virtuella datorer som finns i ett undernät i det virtuella nätverket blev en säkerhetsrisk. 3. Central loggning och granskning av nätverkstrafik mellan lokala platser, yttervärlden och det virtuella datacentret som du skapade i Azure.
      • Utvärdera och testa datasökvägen mellan SAP-programlagret och SAP DBMS-lagret.
      • Kontrollera att Azure Accelererat nätverk är aktiverat på de virtuella datorer som används i SAP-programlagret och SAP DBMS-lagret. Tänk på att olika operativsystemnivåer krävs för att stödja accelererat nätverk i Azure:
        • Windows Server 2012 R2 eller senare.
        • SUSE Linux 12 SP3 eller senare.
        • RHEL 7.4 eller senare.
        • Oracle Linux 7.5. Om du använder RHCKL-kerneln krävs version 3.10.0-862.13.1.el7. Om du använder Oracle UEK-kerneln krävs version 5.
      • Testa och utvärdera nätverksfördröjningen mellan de virtuella datorerna på SAP-programnivån och virtuella DBMS-datorer enligt SAP-supportanteckningarna #500235 och #1100926. Utvärdera resultaten mot vägledningen om nätverksfördröjning i SAP-supportanteckningen #1100926. Nätverksfördröjningen ska vara inom ett måttligt eller bra intervall. Undantag gäller för trafik mellan virtuella datorer och HANA Large Instance-enheter, enligt dokumenten i den här artikeln.
      • Kontrollera att ILB-distributioner har ställts in för att använda direkt serverretur. Den här inställningen minskar svarstiden när Azure ILB används för konfigurationer med hög tillgänglighet på DBMS-lagret.
      • Om du använder en Azure Load Balancer med Linux-gästoperativsystemet kontrollerar du att nätverksparametern för Linux net.ipv4.tcp_timestamps har angetts till 0. Den här rekommendationen står i konflikt med rekommendationer i äldre versioner av SAP-anteckningen #2382421. SAP-anteckningen har nu uppdaterats för att ange att den här parametern måste anges till 0 för att fungera med Azure-lastbalanserare.
      • Överväg att använda närhetsplaceringsgrupper i Azure för att få optimal nätverksfördröjning. Mer information finns i Närhetsplaceringsgrupper i Azure för optimal nätverksfördröjning med SAP-program.
    4. Distributioner med hög tillgänglighet och haveriberedskap.
      • Om du distribuerar SAP-programlagret utan att definiera en specifik Azure-tillgänglighetszon ser du till att alla virtuella datorer som kör SAP-dialoginstanser eller mellanprograminstanser i ett enda SAP-system distribueras i en tillgänglighetsuppsättning.
      • Om du inte behöver hög tillgänglighet för SAP Central Services och DBMS kan du distribuera dessa virtuella datorer till samma tillgänglighetsuppsättning som SAP-programlagret.
      • Om du skyddar SAP Central Services och DBMS-lagret 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.
      • Om du distribuerar till Azure-tillgänglighetszoner kan du inte använda tillgänglighetsuppsättningar. Men du måste se till att distribuera de aktiva och passiva centrala tjänstnoderna till två olika Tillgänglighetszoner. Använd Tillgänglighetszoner som har den lägsta svarstiden mellan dem. Tänk på att du måste använda Azure Standard Load Balancer för att upprätta Windows- eller Pacemaker-redundanskluster för DBMS- och SAP Central Services-lagret över Tillgänglighetszoner. Du kan inte använda Basic-Load Balancer för zonindemässiga distributioner.
    5. Tidsgränsinställningar.
      • Kontrollera SAP NetWeaver-utvecklarspårningarna för SAP-instanserna för att se till att det inte finns några anslutningsavbrott mellan den lokala servern och SAP-arbetsprocesserna. Du kan undvika dessa anslutningsavbrott 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.
      • För att undvika GUI-timeouter mellan lokala SAP GUI-gränssnitt och SAP-programlager som distribueras i Azure kontrollerar du om dessa parametrar har angetts 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 note #2743751.
      • Om du använder en Windows för redundanskluster ska du se till att tiden för att reagera på icke-dynamiska noder är korrekt inställd för Azure. Artikeln Tuning Failover Cluster Network Thresholds (Justera nätverkströsklar för redundanskluster) innehåller en lista över parametrar och hur de påverkar känsligheten för redundans. Förutsatt att klusternoderna finns i samma undernät bör du ändra dessa parametrar:
        • SameSubNetDelay = 2000
        • SameSubNetThreshold = 15
        • RoutingHistorylength = 30
    6. Os Inställningar eller korrigeringar
  4. Testa procedurerna för hög tillgänglighet och haveriberedskap.
    1. Simulera redundanssituationer genom att stänga av virtuella datorer (Windows gästoperativsystemet) eller placera operativsystem i panic-läge (Linux-gästoperativsystemet). Det här steget hjälper dig att ta reda på om redundanskonfigurationerna fungerar som de ska.
    2. Mät hur lång tid det tar att köra en redundans. 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 redundans.
      • Om SAP HANA data tar för lång tid kan du överväga att etablera mer lagringsbandbredd.
    3. Testa din säkerhetskopierings-/återställningssekvens och tidsinställning och gör ändringar om du behöver. Kontrollera att säkerhetskopieringstiderna räcker. Du måste också testa återställnings- och tidsåterställningsaktiviteterna. Se till att återställningstiderna ligger inom RTO-serviceavtalen oavsett var ditt RTO förlitar sig på en databas- eller VM-återställningsprocess.
    4. Testa dr-funktioner och arkitektur mellan regioner.
  5. Säkerhetskontroller.
    1. Testa giltigheten för din Azure-arkitektur för rollbaserad åtkomstkontroll (Azure RBAC). Målet är att separera och begränsa åtkomst och behörigheter för olika team. Till exempel ska MEDLEMMAR i SAP-basteamet kunna distribuera virtuella datorer och tilldela diskar från Azure Storage till ett visst virtuellt Azure-nätverk. 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.
    2. Kontrollera att nätverkssäkerhetsgruppen och ASC-reglerna fungerar som förväntat och skydda de skyddade resurserna.
    3. Se till att alla resurser som behöver krypteras är krypterade. Definiera och implementera processer för att backa upp certifikat, lagra och komma åt dessa certifikat och återställa de krypterade entiteterna.
    4. Använd Azure Disk Encryption för OS-diskar där det är möjligt från en OS-supportpunkt.
    5. Se till att du inte använder för många krypteringslager. I vissa fall är det klokt att använda Azure Disk Encryption tillsammans med en av DBMS-transparent datakryptering-metoderna för att skydda olika diskar eller komponenter på samma server. På en SAP DBMS-server kan till exempel Azure Disk Encryption (ADE) aktiveras på operativsystemets startdisk (om operativsystemet stöder ADE) och dessa datadiskar som inte används av DBMS-datapersistencefilerna. Ett exempel är att använda ADE på disken som har DBMS TDE-krypteringsnycklarna.
  6. Prestandatestning. I SAP gör du följande jämförelser baserat på SAP-spårning och -mått:
    • Jämför i förekommande fall de 10 främsta onlinerapporterna med din aktuella implementering.
    • Jämför i förekommande fall de 10 främsta batchjobben med din aktuella implementering.
    • Jämför dataöverföringar via gränssnitt i SAP-systemet. Fokusera på gränssnitt där du vet att överföringen går mellan olika platser, till exempel från en lokal plats till Azure.

Icke-produktionsfas

I den här fasen antar vi att du efter en lyckad pilot eller poC (Proof of Concept) börjar distribuera SAP-system som inte är i produktion till Azure. Inkludera allt du har lärt dig och haft under POC till den här distributionen. Alla kriterier och steg som anges för POC gäller även för den här distributionen.

Under den här fasen distribuerar du vanligtvis utvecklingssystem, enhetstestningssystem och testsystem för affärs regression till Azure. Vi rekommenderar att minst ett icke-produktionssystem i en SAP-programrad har den fullständiga konfiguration för hög tillgänglighet som det framtida produktionssystemet kommer att ha. Här är några ytterligare steg som du behöver utföra under den här fasen:

  1. 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 även samla in dem från programlagerenheterna. Mät även nätverks- och lagringsfördröjning.
  2. Registrera systemets tidsmönster för tillgänglighetsanvändning. 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.
  3. Testa och ta reda på om du vill skapa dina egna OS-avbildningar för dina virtuella datorer i Azure eller om du vill använda en avbildning från Azure Azure Compute Gallery (kallades tidigare för Shared Image Gallery). Om du använder en avbildning från Azure Compute Gallery använder du en avbildning som återspeglar supportavtalet med din OS-leverantör. För vissa OS-leverantörer kan Azure Compute Gallery ta med dina egna licensavbildningar. För andra OS-avbildningar ingår stöd i det pris som anges av Azure. Om du bestämmer dig för att skapa egna os-avbildningar hittar du dokumentation i följande artiklar:
  4. Om du använder SUSE- och Red Hat Linux-avbildningar från Azure Compute Gallery måste du använda avbildningarna för SAP som tillhandahålls av Linux-leverantörerna i Azure Compute Gallery.
  5. Se till att uppfylla SAP-supportkraven för Microsofts supportavtal. Se SAP-supportanteckningen #2015553. För HANA – stora instanser, se Registreringskrav.
  6. Se till att rätt personer får meddelanden om planerat underhåll så att du kan välja bästa stilleståndstid.
  7. Sök ofta efter Azure-presentationer på kanaler som Channel 9 för nya funktioner som kan gälla för dina distributioner.
  8. Kontrollera SAP-anteckningar som rör Azure, t.ex. supportanteckning #1928533, för nya VM-SKU:er och nyligen stödda OS- och DBMS-versioner. Jämför prissättningen för nya typer av virtuella datorer med de äldre typerna av virtuella datorer, så att du kan distribuera virtuella datorer med bästa pris/prestanda-förhållande.
  9. Kontrollera SAP-supportanteckningarna, SAP HANA maskinvarukatalogen och SAP PAM. Kontrollera att det inte fanns några ändringar i de virtuella datorer som stöds för Azure, os-versioner som stöds på de virtuella datorerna och de SAP- och DBMS-versioner som stöds.
  10. På SAP-webbplatsen finns nya HANA-certifierade SKU:er i Azure. Jämför prissättningen för nya SKU:er med de som du planerar att använda. Så småningom kan du göra nödvändiga ändringar för att använda dem som har bästa pris/prestanda-förhållande.
  11. Anpassa dina distributionsskript så att de använder nya typer av virtuella datorer och lägg till nya Azure-funktioner som du vill använda.
  12. Efter distributionen av infrastrukturen testar och utvärderar du nätverksfördröjningen mellan virtuella DATORER på SAP-programlager och virtuella DBMS-datorer, enligt SAP-supportanteckningarna #500235 och #1100926. Utvärdera resultaten mot vägledningen om nätverksfördröjning i SAP-supportanteckningen #1100926. Nätverksfördröjningen ska vara inom ett måttligt eller bra intervall. Undantag gäller för trafik mellan virtuella datorer och HANA Large Instance-enheter enligt dokumenten i den här artikeln. Se till att inga av begränsningarna som anges i Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastningar och SAP HANA-infrastrukturkonfigurationer och -åtgärder i Azure gäller för distributionen.
  13. Se till att dina virtuella datorer distribueras till rätt närhetsplaceringsgrupp i Azureenligt beskrivningen i Närhetsplaceringsgrupper i Azure för optimal nätverksfördröjning med SAP-program.
  14. Utför alla andra kontroller som anges för konceptbevisfasen innan du tillämpar arbetsbelastningen.
  15. 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 VM-storleksändringen för framtida distributioner om du ser att det finns stora skillnader. Tänk på att även när du minskar datastorlek, lagring och nätverksbandbredd för virtuella datorer.
  16. 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 projektteamen snabbt kan få nya system.
  17. Optimera och förbättra ditt teams rollbaserade åtkomst, behörigheter och processer i Azure för att se till att du har en uppdelning av uppgifter. Samtidigt bör du se till att alla team kan utföra sina uppgifter i Azure-infrastrukturen.
  18. Övning, testning och dokument med 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.

Fas för produktionsförberedelse

I den här fasen samlar du in det du har lärt dig under icke-produktionsdistributioner och tillämpar det på framtida produktionsdistributioner. Du måste också förbereda arbetet med dataöverföringen mellan din aktuella värdplats och Azure.

  1. Slutför nödvändiga SAP-lanseringsuppgraderingar av dina produktionssystem innan du flyttar till Azure.
  2. Överens med företagsägare om funktions- och affärstester som måste utföras efter migreringen av produktionssystemet.
  3. 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 efter att systemet har flyttats till Azure.
  4. Testa processen med att migrera produktionssystem till Azure. Om du inte flyttar alla produktionssystem till Azure under samma tidsram skapar du grupper av produktionssystem som måste finnas på samma värdplats. Testa datamigrering. Här är några vanliga metoder:
    • Använd DBMS-metoder som säkerhetskopiering/återställning i kombination med SQL Server Always On, HANA System Replication eller Loggleverans för att seeda och synkronisera databasinnehåll i Azure.
    • Använd säkerhetskopiering/återställning för mindre databaser.
    • Använd SAP Migration Monitor, som är integrerat i SAP SWPM, för att utföra heterogena migreringar.
    • Använd SAP DMO-processen om du behöver kombinera migreringen med en SAP-lanseringsuppgradering. Tänk på att inte alla kombinationer av käll-DBMS och mål-DBMS stöds. Du hittar mer information i de specifika SAP-supportanteckningarna för de olika versionerna av DMO. Till exempel databasmigreringsalternativet (DMO) för SUM 2.0 SP04.
    • Testa om dataflödet för dataöverföring ä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 behöver ha på plats för framtida produktionssystem.
  5. Samla in resursförbrukningsdata innan du flyttar system från din gamla plattform till Azure. Användbara data omfattar processoranvändning, lagringsdataflöde och IOPS-data. Samla särskilt in dessa data från DBMS-lagerenheterna, men även samla in dem från programlagerenheterna. Mät även nätverks- och lagringsfördröjning.
  6. Kontrollera SAP-supportanteckningarna och de nödvändiga os-inställningarna, SAP HANA för maskinvaran och SAP PAM. Kontrollera att det inte fanns några ändringar i de virtuella datorer som stöds för Azure, os-versioner som stöds på de virtuella datorerna och vilka SAP- och DBMS-versioner som stöds.
  7. Uppdatera distributionsskript för att ta hänsyn till de senaste besluten som du har tagit om VM-typer och Azure-funktioner.
  8. När du har distribuerat infrastruktur och program kontrollerar du att:
    • Rätt typer av virtuella datorer har distribuerats med rätt attribut och lagringsstorlekar.
    • De virtuella datorerna finns på rätt och önskade OS-versioner och korrigeringar och är enhetliga.
    • Virtuella datorer härdas vid behov och på ett enhetligt sätt.
    • Rätt programuppdateringar installerades och distribuerades.
    • De virtuella datorerna distribuerades i Azure-tillgänglighetsuppsättningar som planerat.
    • Azure Premium Storage används för svarstidskänsliga diskar eller där serviceavtalet för en virtuell dator på 99,9 % krävs.
    • Azure Skrivningsaccelerator distribueras korrekt.
    • Azure-hanterade diskar används exklusivt.
    • Virtuella datorer har distribuerats till rätt tillgänglighetsuppsättningar och Tillgänglighetszoner.
    • Azure-accelererat nätverk är aktiverat på de virtuella datorer som används i SAP-programlagret och SAP DBMS-lagret.
    • Inga virtuella Azure-nätverksutrustning finns i kommunikationsvägen mellan SAP-programmet och DBMS-lagret i SAP-system som baseras på SAP NetWeaver, Hybris eller S/4HANA.
    • Regler för programsäkerhetsgrupp och nätverkssäkerhetsgrupp tillåter kommunikation efter behov och planerad och blockerar kommunikationen där det behövs.
    • Tidsgränsinställningarna är korrekt inställda, enligt beskrivningen ovan.
    • Virtuella datorer distribueras till rätt närhetsplaceringsgrupp i Azureenligt beskrivningen i Närhetsplaceringsgrupper i Azure för optimal nätverksfördröjning med SAP-program.
    • Nätverksfördröjningen mellan virtuella DATORER på SAP-programlager och virtuella DBMS-datorer testas och valideras enligt beskrivningen i SAP-supportanteckningarna #500235 och #1100926. Utvärdera resultaten mot vägledningen om nätverksfördröjning i SAP-supportanteckningen #1100926. Nätverksfördröjningen ska vara inom ett måttligt eller bra intervall. Undantag gäller för trafik mellan virtuella datorer och HANA Large Instance-enheter enligt dokumenten i den här artikeln.
    • Kryptering implementerades vid behov och med lämplig krypteringsmetod.
    • Gränssnitt och andra program kan ansluta den nyligen distribuerade infrastrukturen.
  9. Skapa en spelbok för att reagera på planerat Azure-underhåll. Fastställ i vilken ordning system och virtuella datorer ska startas om för planerat underhåll.

Go-Live-fas

Under go-live-fasen bör du följa de spelböcker som du utvecklade under tidigare faser. Kör de steg som du testade och övade på. Acceptera inte ändringar i konfigurationer och processer i sista minuten. Utför även följande steg:

  1. Kontrollera att Azure Portal och andra övervakningsverktyg fungerar. Vi rekommenderar Windows prestandaövervakaren (perfmon) för Windows och SAR för Linux.
    • CPU-räknare.
      • Genomsnittlig CPU-tid, total (alla processorer)
      • Genomsnittlig CPU-tid, varje enskild processor (128 processorer på virtuella M128-datorer)
      • CPU-kerneltid, varje enskild processor
      • Cpu-användartid, varje enskild processor
    • Memory.
      • Ledigt minne
      • Minnessidan in/sekund
      • Minnessida ut/sekund
    • Disk.
      • Diskläsning i KBps per enskild disk
      • Diskläsningar/sekund, per enskild disk
      • Diskläsning i mikrosekunder/läsning per enskild disk
      • Diskskrivning i KBps per enskild disk
      • Diskskrivning/sekund, per enskild disk
      • Diskskrivning i mikrosekunder/läsning per enskild disk
    • Nätverk.
      • Nätverkspaket i/s
      • Nätverkspaket ut/sekund
      • Nätverks-KB in/sekund
      • Nätverkets KB ut/sekund
  2. Efter datamigreringen utför du alla valideringstester som du kommit överens om med företagets ägare. Acceptera valideringstestresultat endast när du har resultat för de ursprungliga källsystemen.
  3. Kontrollera om gränssnitten fungerar och om andra program kan kommunicera med de nyligen distribuerade produktionssystemen.
  4. Kontrollera transport- och korrigeringssystemet via SAP-transaktions-STMS.
  5. Utför databassäkerhetskopior när systemet har släppts för produktion.
  6. Utför VM-säkerhetskopieringar för de virtuella datorerna på SAP-programnivån när systemet har släppts för produktion.
  7. 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 go-live-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 har flyttat till Azure bort.

Efter produktion

Den här fasen handlar om övervakning, drift och administration av systemet. Från SAP-perspektiv gäller de vanliga uppgifter som du behövde utföra på din gamla värdplats. Utför även följande Azure-specifika uppgifter:

  1. Granska Azure-fakturor för system med hög debitering.
  2. Optimera pris-/prestandaeffektivitet på vm-sidan och lagringssidan.
  3. Optimera tiderna när du kan stänga av system.

Nästa steg

Läs följande artiklar: