Granska metodtips för mycket stor databasmigrering

Slutförd

Följande riktlinjer baseras på verkliga kundprojekt och de lärdomar som härleds från dessa projekt. Riktlinjerna identifierar scenarier som har misslyckats tidigare. Ett exempel är rekommendationen att inte använda UNIX-servrar eller virtualiserade servrar som R3load-exportservrar:

• Exportprestanda är ofta en faktor som påverkar den totala stilleståndstiden. Ofta är den nuvarande maskinvaran mer än 4-5 år gammal och är oöverkomligt dyr att uppgradera.
• Det är därför viktigt att få den maximala exportprestanda som är praktisk att uppnå.
• Tidigare projekt har ägnat man veckor eller till och med man månader åt att försöka finjustera R3load-exportprestanda på UNIX eller virtualiserade plattformar innan de gav upp och använde Intel R3load-servrar.
• Intel-servrar med dubbla socketar är billiga och ger betydande prestandavinster, i vissa fall större än mindre justeringsförbättringar på UNIX- eller virtualiserade servrar.
• Kunder har ofta befintliga virtuella datorgrupper, men oftast stöder de inte moderna avlastnings- eller SR-IOV-tekniker. Ofta är VMware-versionen gammal, oskickad eller inte konfigurerad för högt nätverksdataflöde och låg svarstid. R3load-exportservrar kräver snabba trådprestanda och extremt högt nätverksdataflöde. R3load-exportservrar kan köras i 10–15 timmar med nästan 100 % processor- och nätverksanvändning. Detta är inte det vanliga användningsfallet för de flesta VMware-servergrupper och de flesta VMware-distributioner har aldrig utformats för att hantera en arbetsbelastning som R3load.

Dricks

Investera inte tid på att optimera R3load-exportprestanda på UNIX- eller virtualiserade plattformar. Att göra det slösar inte bara tid utan kommer att kosta mycket mer än att köpa billiga Intel-servrar i början av projektet. VLDB-migreringskunder uppmanas därför att se till att projektteamet har snabba moderna R3load-exportservrar tillgängliga i början av projektet. Detta sänker projektets totala kostnad och risk.

Bästa praxis

• Undersöka och inventera det aktuella SAP-landskapet. Identifiera nivåerna för SAP-supportpaketet och ta reda på om korrigering krävs för att stödja mål-DBMS. I allmänhet bestäms operativsystemets kompatibilitet av SAP-kerneln och DBMS-kompatibiliteten bestäms av SAP_BASIS korrigeringsnivå.
• Skapa en lista över SAP OSS-anteckningar som måste tillämpas i källsystemet, till exempel uppdateringar för SMIGR_CREATE_DDL. Överväg att uppgradera SAP-kernels i källsystemen för att undvika stora ändringar under migreringen till Azure (till exempel. Om ett system kör en gammal 7.41-kernel uppdaterar du till de senaste 7.45 i källsystemet för att undvika stora ändringar under migreringen).
• Utveckla och dokumentera lösningen för hög tillgänglighet och haveriberedskap. Dokumentationen bör dela upp lösningen i DB-lagret, ASCS-lagret och SAP-programserverlagret. Separata lösningar kan krävas för fristående lösningar som TREX eller liveCache.
• Utveckla ett storleks- och konfigurationsdokument som beskriver typerna av virtuella Azure-datorer och lagringskonfigurationen. Hur många premiumdiskar, hur många datafiler, hur distribueras datafiler mellan diskar, användning av lagringsutrymmen, NTFS-formatstorlek = 64 kb. Dokumentsäkerhetskopiering/återställning och DBMS-konfiguration, till exempel minnesinställningar, maximal grad av parallellitet och traceflags.
• Utveckla ett dokument för nätverksdesign, inklusive virtuellt nätverk, undernät, NSG och UDR-konfiguration.
• Dokumentera och implementera säkerhets- och härdningskoncept. Ta bort Internet Explorer, skapa en Active Directory-container för SAP-tjänstkonton och -servrar och tillämpa en brandväggsprincip som blockerar alla utom ett begränsat antal nödvändiga portar.
• Skapa ett designdokument för OS/DB-migrering som beskriver konceptet paket- och tabelldelning, antal R3loads, SQL Server traceflags, sorterade/osorterade, Oracle RowID-inställning, SMIGR_CREATE_DDL inställningar, Perfmon-räknare (till exempel BCP-rader/s och BCP-dataflöde kb/sek, CPU, minne), RSS-inställningar, accelererade nätverksinställningar, loggfilkonfiguration, BPE-inställningar, TDE-konfiguration.
• Skapa ett diagram med en färdplan som visar förloppet för R3load-exporten/-importen för varje testcykel. Detta gör att migreringsteamet kan kontrollera om justeringar och ändringar förbättrar R3load-export- eller importprestanda. X-axeln är antalet paket som har slutförts och Y-axeln är den förflutna tiden. Den här färdplanen är också kritisk under produktionsmigreringen så att den planerade förloppet kan jämföras med den faktiska förloppet och eventuella problem som identifieras tidigt.
• Skapa en prestandatestplan. Identifiera de översta ~20 onlinerapporterna, batchjobben och gränssnitten. Dokumentera indataparametrarna (till exempel datumintervall, försäljningskontor, anläggning, företagskod osv.) och körningar i det ursprungliga källsystemet. Jämför med körningen i Azure. Om det finns prestandaskillnader kör du SAT, ST05 och andra SAP-verktyg för att identifiera ineffektiva instruktioner.
• Granska distribution och konfiguration och se till att klustrets timeouter, kernels, nätverksinställningar, storlek på NTFS-format överensstämmer med designdokumenten. Ange perfmonräknare på viktiga servrar för att registrera grundläggande hälsoparametrar var 90:e sekund. Kontrollera att SAP-servrarna finns i en separat AD-container och att containern har en grupprincip som tillämpas på den med brandväggskonfiguration.
• Kontrollera att migreringskonsulten för lead-OS/DB är licensierad! Begär konsultnamnet, s-användaren och certifieringsdatumet. Öppna ett OSS-meddelande till BC-INS-MIG och be SAP bekräfta att konsulten är aktuell och licensierad.
• Om möjligt har hela projektteamet associerat med VLDB-migreringsprojektet på en fysisk plats och inte geografiskt utspridda över flera kontinenter och tidszoner.
• Kontrollera att det finns en korrekt reservplan och att den är en del av det övergripande schemat.
• Välj snabb trådantal Intel CPU-modeller för R3load-exportservrarna. Använd inte "Energy Saver"-processormodeller eftersom de har lägre prestanda och inte använder servrar med 4 socketar. Intel Xeon E5 Platinum 8158 är ett bra exempel.

Metodtips för att undvika problem

• Underleverantör inte en konsultorganisation för att utföra exporten och underleverantör en annan konsultorganisation för att utföra importen. Ibland läggs källsystemet ut och hanteras av en konsultorganisation eller partner och en kund vill migrera till Azure och byta till en annan partner. På grund av den snäva kopplingen mellan export- och importjustering och konfiguration är det osannolikt att tilldelningen av dessa uppgifter till olika organisationer ger ett bra resultat.
• Spara inte på Azure-maskinvaruresurser under migreringen och gå live. Virtuella Azure-datorer debiteras per minut och kan enkelt minskas i storlek. Under en VLDB-migrering använder du den mest kraftfulla virtuella datorn som är tillgänglig. Kunder har framgångsrikt gått live på 200-250% överdimensionerade system, sedan stabiliserats när de kör överdimensionerade system. När du har övervakat systemanvändningen i 4–6 veckor minskas virtuella datorer med överkapacitet i storlek eller avstängning till lägre kostnader.