Utforska pilotfasen

Slutförd

Piloten kan köras parallellt med projektplanering och förberedelse. Den här fasen kan också användas för att testa alternativ som identifierats i planerings- och förberedelsefasen. Som en del av piloten rekommenderar vi att du konfigurerar och validerar en fullständig HA/DR-lösning samt säkerhetsdesign. I vissa fall kan det också vara möjligt att använda den här fasen för att utföra skalbarhetstester eller distribuera SAP-sandbox-system. För att köra en pilot bör kunderna börja med att identifiera ett icke-kritiskt system som de vill migrera till Azure och fortsätta genom att utföra följande uppgifter:

1. Optimera dataöverföring till Azure

Metoden och resultatet är starkt beroende av en kunds anslutning till Azure. Beroende på mängden data kan det vara möjligt att använda för detta ändamål ExpressRoute, plats-till-plats-VPN eller offline-dataöverföringstjänster som Azure Data Box eller Azure Import/Export Service.

2. Sap heterogen plattformsmigrering

Vid en sap-heterogen plattformsmigrering som omfattar export och import av databasdata, testar och optimerar du export- och importfaserna. För stora heterogena migreringar som riktar sig mot SQL Server, se SAP OS/DB-migrering till SQL Server – Vanliga frågor och svar. Du kan använda Migration Monitor/SWPM om du inte behöver kombinera migreringen med en versionsuppgradering eller SAP Database Migration Option (DMO) på annat sätt. Mer information finns i Alternativet databasmigrering (DMO) för SUM – Introduction ( Databasmigreringsalternativ ) för SUM – Introduction (Introduktion). I båda fallen använder du följande steg:

• Mät tiden för att exportera från källan, ladda upp exporterat innehåll till Azure och utför import. Maximera överlappningen mellan export och import.
• Använd jämförelsen mellan käll- och måldatabaserna för att korrekt storleksanpassa målinfrastrukturen.
• Verifiera och optimera tidsinställningen.

3. Utföra teknisk validering

Typer av virtuella datorer

• Referera till SAP-supportanteckningar, SAP HANA-maskinvarukatalog och SAP Product Availability Matrix (PAM) för att säkerställa noggrannheten i informationen om azure virtual machine-SKU:er som stöds, operativsystemversioner som stöds för dessa Azure Virtual Machine-SKU:er och SAP- och DBMS-versioner som stöds.
• Verifiera storleken på infrastrukturen och de programkomponenter som du distribuerar i Azure. När du migrerar befintliga program bör du kunna hämta nödvändiga SAPS baserat på befintlig telemetri. Hämta SAP-riktmärket och jämför det med SAPS-numren som anges i SAP Note #1928533. Dessutom refererar du till informationen i SAPS-klassificeringar på Virtuella Azure-datorer – var du ska leta och var du kan bli förvirrad.
• Utvärdera och testa storleken på dina virtuella Azure-datorer när det gäller maximalt dataflöde för lagring och nätverksdataflöde för de olika typer av virtuella datorer som du valde i planeringsfasen. Dessa data finns i Storlekar för virtuella datorer i Azure. När gästoperativsystemet för den virtuella Azure-datorn är Windows är det viktigt att överväga maximalt diskdataflöde som inte har kopplats till storlek. När det gäller Linux är det också viktigt att överväga maximalt diskdataflöde som inte har använts för storleksändring.

Storage

• Använd Azure Standard SSD-lagring som minimum för virtuella datorer som representerar SAP-programlager och för icke-prestandakänslig DBMS-distribution och använd Azure Premium Storage för alla virtuella DBMS-datorer som är prestandakänsliga.
• Undvik att använda Azure Standard HDD-diskar.
• Använd Azure-hanterade diskar.
• Aktivera Azure Write Accelerator för DBMS-loggenheter med virtuella datorer i M-serien. Tänk på dokumenterade begränsningar för skrivacceleratorer och användningsbegränsningar.
• För DBMS-relaterad lagringsinformation, se Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning samt DBMS-specifik dokumentation som refereras i det dokumentet.
• För SAP HANA-distributioner kan du läsa konfigurationer och åtgärder för SAP HANA-infrastruktur i Azure.
• Montera aldrig Azure-datadiskar på en virtuell Azure Linux-dator med hjälp av enhets-ID:t. Använd i stället den universellt unika identifieraren (UUID). Var försiktig när du använder grafiska verktyg för att montera en Azure-datadisk. Dubbelkolla posterna i /etc/fstab för att se till att diskarna är monterade med UUID. Mer information finns i Ansluta till den virtuella Linux-datorn för att montera den nya disken.

Nätverk

Testa och utvärdera din virtuella nätverksinfrastruktur och distributionen av dina SAP-program över eller i de virtuella Azure-nätverken.

1. Utvärdera metoden för hubb- och ekerarkitektur för virtuella nätverk eller mikrosegmentering i ett enda virtuellt Azure-nätverk baserat på följande kriterier:

   • Kostnader på grund av datautbyte mellan peerkopplade virtuella Azure-nätverk (mer information finns i prissättningen för virtuella Azure-nätverk.
   • Jämförelse mellan möjligheten att avsluta peering mellan virtuella Azure-nätverk och användningen av NSG:er för att isolera undernät i ett virtuellt nätverk i fall där program eller virtuella datorer som finns i ett undernät i det virtuella nätverket blir en säkerhetsrisk.
   • Central loggning och granskning av nätverkstrafik mellan lokalt, Internet och det virtuella Azure-datacentret.

2. Utvärdera och testa datasökvägen mellan SAP-programskiktet och SAP DBMS-lagret. Som en del av utvärderingen bör du tänka på följande:

   • Det går inte att placera virtuella nätverksinstallationer i kommunikationssökvägen mellan SAP-programmet och DBMS-lagret i ett SAP NetWeaver-, Hybris- eller S/4HANA-baserat SAP-system.
   • Det går inte att placera SAP-programskiktet och SAP DBMS i olika virtuella Azure-nätverk som inte är peer-kopplade.
   • Det stöds för att använda Azure Application Security Groups (ASG: er) och nätverkssäkerhetsgrupper (NSG: er) för att styra trafikflödet mellan SAP-programskiktet och SAP DBMS-lagret.

3. Kontrollera att Azure Accelerated Networking är aktiverat på de virtuella datorer som används på SAP-programlagret och SAP DBMS-lagret. Tänk på os-kraven för stöd för accelererat nätverk i Azure:

   • Windows Server 2012 R2 eller senare versioner
   • SUSE Linux 12 SP3 eller nyare versioner
   • RHEL 7.4 eller senare versioner
   • Oracle Linux 7.5. RHCKL-kerneln kräver version 3.10.0-862.13.1.el7. Oracle UEK-kerneln kräver version 5.

4. Testa och utvärdera nätverksfördröjningen mellan den virtuella SAP-programnivådatorn och den virtuella DBMS-datorn enligt SAP Note #500235 och SAP Note #1100926. Utvärdera resultaten mot vägledning om nätverksfördröjning för SAP Note #1100926. Nätverksfördröjningen bör ligga inom intervallet måttlig till bra.

5. Kontrollera att Azures interna distributioner av lastbalanserare (ILB) har konfigurerats för att använda Direct Server Return. Den här inställningen minskar svarstiden i fall där ILB:er används för konfigurationer med hög tillgänglighet på DBMS-lagret.

6. Om du använder En Azure-lastbalanserare tillsammans med Linux-gästoperativsystem kontrollerar du att Linux-nätverksparametern net.ipv4.tcp_timestamps är inställd på 0. Observera att detta strider mot de allmänna rekommendationerna i SAP Note #2382421. SAP-anteckningen har uppdaterats för att återspegla det faktum att parametern måste anges till 0 för att fungera tillsammans med Azure-lastbalanserare.

Distributioner med hög tillgänglighet och haveriberedskap

• Om du distribuerar SAP-programskiktet utan att rikta in dig på specifika Azure-tillgänglighetszoner kontrollerar du att alla virtuella datorer som kör SAP-dialoginstanser eller mellanprograminstanser av samma SAP-system distribueras i samma tillgänglighetsuppsättning.

  • Om du inte behöver hög tillgänglighet för SAP Central Services och DBMS kan dessa virtuella datorer distribueras till samma tillgänglighetsuppsättning som SAP-programskiktet.

• Om du behöver skydda SAP Central Services och DBMS-lagret för hög tillgänglighet med passiva repliker distribuerar du de två noderna för SAP Central Services i en 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. I stället bör du se till att du distribuerar de aktiva och passiva Central Services-noderna till två olika tillgänglighetszoner, vilket ger den minsta svarstiden mellan zoner.

• Tänk på att du måste använda Azure Standard-lastbalanserare när du skapar Windows Server- eller Pacemaker-baserade redundanskluster för DBMS- och SAP Central Services-lagret mellan tillgänglighetszoner. Den grundläggande lastbalanseraren stöder inte zonindelade distributioner.

Tidsgränsinställningar

• Kontrollera SAP NetWeaver-utvecklarspårningar av SAP-instanser och kontrollera att det inte finns några anslutningsavbrott mellan enqueue-servern och SAP-arbetsprocesserna. Dessa anslutningsbrytningar kan undvikas genom att ange dessa 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 anger du följande parametrar i default.pfl eller instansprofilen:

  • rdisp/keepalive_timeout = 3600
  • rdisp/keepalive = 20

• Om du använder ett Windows-redundanskluster kontrollerar du att parametrarna som avgör redundans som utlöses av icke-dynamiska noder är korrekt inställda. Microsoft TechCommunity-artikeln Tuning Failover Cluster Network Thresholds listar parametrar och deras inverkan på redundansbeteendet. Anta till exempel att klusternoderna finns i samma undernät och se till att konfigurera redundansparametrar på följande sätt:

  • SameSubNetDelay = 2000

  • SameSubNetThreshold = 15

  • RoutingHistorylength = 30

  • Testa procedurer för hög tillgänglighet och haveriberedskap:

    • Simulera redundans genom att stänga av Azure Virtual Machines (Windows gästoperativsystem) eller placera operativsystem i panikläge (Linux-gästoperativsystem).

    • Mät de gånger det tar att slutföra redundansväxlingar. 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 Fencing Agent för att påskynda redundansväxlingen.
      • För SAP HANA kan du förbättra lagringsprestandan om det tar för lång tid att ladda om data.

    • Testa säkerhetskopiering/återställningssekvens och tidsinställning och justera vid behov. Kontrollera att det inte bara räcker med säkerhetskopieringstider. Testa även återställningen och ta tid på återställningsaktiviteterna. se till att återställningstiderna ligger inom dina RTO-serviceavtal där din RTO förlitar sig på en databas- eller återställningsprocess för virtuella datorer.

    • Testa DR-funktioner och arkitektur.

4. Utföra säkerhetskontroller

• Testa giltigheten för den rollbaserade Azure-åtkomstmetoden (RBAC) som du implementerade. Målet är att separera och begränsa åtkomst och behörigheter som delegerats till olika team. Som ett exempel bör SAP Basis-teammedlemmar kunna distribuera Azure Virtual Machines till ett visst virtuellt Azure-nätverk och tilldela diskar till dessa virtuella Azure-datorer. SAP Basis-teamet bör dock inte kunna skapa nya virtuella nätverk eller ändra inställningarna för befintliga virtuella nätverk. Omvänt bör medlemmar i nätverksteamet inte kunna distribuera Virtuella Azure-datorer till virtuella nätverk där SAP-program och virtuella DBMS-datorer körs. Medlemmar i nätverksteamet bör inte heller kunna ändra attribut för virtuella datorer eller ta bort virtuella datorer och deras diskar.
• Kontrollera att NSG-reglerna fungerar som förväntat och skydda de skyddade resurserna.
• Verifiera kryptering i vila och under överföring. Definiera och implementera processer för att säkerhetskopiera, lagra och komma åt certifikat samt verifiera återställningsprocessen för krypterade entiteter.
• Använd Azure Disk Encryption för OS-diskar.
• Överväg en pragmatisk metod när du bestämmer om du vill implementera en krypteringsmekanism. Utvärdera till exempel om det är nödvändigt att tillämpa både Azure Disk-kryptering och DBMS Transparent Database Encryption.

5. Testprestanda

I migreringsscenarier använder du SAP-spårning och mätningar för att jämföra piloten med den aktuella implementeringen baserat på:

• De 10 främsta onlinerapporterna
• De 10 främsta batchjobben
• Dataöverföringar via gränssnitt till SAP-systemet, med fokus på trafik mellan platser