Best practices voor zeer grote databasemigratie onderzoeken

Voltooid

De volgende richtlijnen zijn gebaseerd op echte klantprojecten en de lessen die zijn afgeleid van deze projecten. De richtlijnen identificeren scenario's die in het verleden niet succesvol zijn geweest. Een voorbeeld is de aanbeveling om GEEN UNIX-servers of gevirtualiseerde servers te gebruiken als R3load-exportservers:

• De exportprestaties zijn vaak een gatingsfactor voor de algehele downtime. Vaak is de huidige hardware meer dan 4-5 jaar oud en is het te duur om te upgraden.
• Het is daarom belangrijk om de maximale exportprestaties te verkrijgen die praktisch zijn om te bereiken.
• Eerdere projecten hebben manweken of zelfs manmaanden besteed aan het afstemmen van de R3load-exportprestaties op UNIX- of gevirtualiseerde platforms, voordat u Intel R3load-servers opgeeft en gebruikt.
• Dual-socket commodity Intel-servers zijn goedkoop en leveren aanzienlijke prestatieverbeteringen, in sommige gevallen groter dan kleine afstemmingsverbeteringen mogelijk op UNIX- of gevirtualiseerde servers.
• Klanten hebben vaak bestaande virtuele-machinefarms, maar deze bieden meestal geen ondersteuning voor moderne offload- of SR-IOV-technologieën. Vaak is de VMware-versie oud, niet-gepatcht of niet geconfigureerd voor hoge netwerkdoorvoer en lage latentie. R3load-exportservers vereisen snelle threadprestaties en extreem hoge netwerkdoorvoer. R3load-exportservers kunnen gedurende 10-15 uur worden uitgevoerd op bijna 100% CPU- en netwerkgebruik. Dit is niet het typische gebruiksscenario van de meeste VMware-farms en de meeste VMware-implementaties zijn nooit ontworpen om een workload zoals R3load te verwerken.

Tip

Investeer geen tijd in het optimaliseren van de R3load-exportprestaties op UNIX- of gevirtualiseerde platforms. Dit zal niet alleen tijd verspillen, maar kost veel meer dan het kopen van goedkope Intel-servers aan het begin van het project. VLDB-migratieklanten worden daarom gevraagd ervoor te zorgen dat het projectteam snelle moderne R3load-exportservers heeft die beschikbaar zijn aan het begin van het project. Hierdoor worden de totale kosten en het risico van het project verlaagd.

Aanbevolen procedures

• Enquête en inventariseer het huidige SAP-landschap. Identificeer de niveaus van het SAP-ondersteuningspakket en bepaal of patching is vereist om de doel-DBMS te ondersteunen. Over het algemeen wordt de compatibiliteit van het besturingssysteem bepaald door de SAP-kernel en wordt de DBMS-compatibiliteit bepaald door het SAP_BASIS patchniveau.
• Maak een lijst met SAP OSS-notities die moeten worden toegepast in het bronsysteem, zoals updates voor SMIGR_CREATE_DDL. Overweeg om de SAP-kernels in de bronsystemen te upgraden om een grote wijziging te voorkomen tijdens de migratie naar Azure (bijvoorbeeld. Als een systeem een oude 7.41-kernel uitvoert, werkt u bij naar de nieuwste 7.45 op het bronsysteem om een grote wijziging tijdens de migratie te voorkomen).
• Ontwikkel en documenteer de oplossing voor hoge beschikbaarheid en herstel na noodgevallen. De documentatie moet de oplossing opsplitsen in de databaselaag, ASCS-laag en SAP-toepassingsserverlaag. Er zijn mogelijk afzonderlijke oplossingen vereist voor zelfstandige oplossingen, zoals TREX of liveCache.
• Ontwikkel een formaat- en configuratiedocument waarin de typen en opslagconfiguratie van Azure Virtual Machine worden weergegeven. Hoeveel Premium-schijven, hoeveel gegevensbestanden, hoe worden gegevensbestanden verdeeld over schijven, gebruik van opslagruimten, NTFS-indelinggrootte = 64 kB. Ook documentback-up/herstel en DBMS-configuratie, zoals geheugeninstellingen, maximale mate van parallelle uitvoering en traceflags.
• Ontwikkel een document voor netwerkontwerp, waaronder virtueel netwerk, subnet, NSG en UDR-configuratie.
• Documenteer en implementeer het concept voor beveiliging en beveiliging. Verwijder Internet Explorer, maak een Active Directory-container voor SAP-serviceaccounts en -servers en pas een firewallbeleid toe dat alle, maar een beperkt aantal vereiste poorten blokkeert.
• Maak een ontwerpdocument voor het besturingssysteem/DB met details van het concept voor het splitsen van pakketten en tabellen, aantal R3loads, SQL Server-traceflags, gesorteerd/niet-gesorteerd, Oracle RowID-instelling, SMIGR_CREATE_DDL-instellingen, Prestatiemeteritems (zoals BCP-rijen per seconde en BCP-doorvoer kb/sec, CPU, geheugen), RSS-instellingen, versnelde netwerkinstellingen, logboekbestandsconfiguratie, BPE-instellingen, TDE-configuratie.
• Maak een grafiek vluchtplan met de voortgang van de R3load-export/import voor elke testcyclus. Hierdoor kan het migratieteam valideren of de afstemming en wijzigingen de prestaties van R3load-export of -import verbeteren. De X-as is het aantal pakketten voltooid en de Y-as is de verstreken tijd. Dit vluchtplan is ook essentieel tijdens de productiemigratie, zodat de geplande voortgang kan worden vergeleken met de werkelijke voortgang en elk probleem dat vroeg is geïdentificeerd.
• Maak een prestatietestplan. Identificeer de belangrijkste ~20 onlinerapporten, batchtaken en interfaces. Documenteer de invoerparameters (zoals datumbereik, verkoopkantoor, fabriek, bedrijfscode, enzovoort) en runtimes op het oorspronkelijke bronsysteem. Vergelijk met de runtime in Azure. Als er prestatieverschillen zijn, worden SAT, ST05 en andere SAP-hulpprogramma's uitgevoerd om inefficiënte instructies te identificeren.
• Controleer de implementatie en configuratie en zorg ervoor dat time-outs voor clusters, kernels, netwerkinstellingen, NTFS-indelingsgrootte allemaal consistent zijn met de ontwerpdocumenten. Stel prestatiemeteritems op belangrijke servers in om elke 90 seconden basisstatusparameters vast te leggen. Controleer of de SAP-servers zich in een afzonderlijke AD-container bevinden en of er een groepsbeleid op de container is toegepast met firewallconfiguratie.
• Controleer of de lead OS/DB-migratieconsultant een licentie heeft. Vraag de naam van de consultant, de gebruiker en de certificeringsdatum aan. Open een OSS-bericht naar BC-INS-MIG en vraag SAP om te bevestigen dat de consultant actueel en gelicentieerd is.
• Indien mogelijk moet het hele projectteam zijn gekoppeld aan het VLDB-migratieproject binnen één fysieke locatie en niet geografisch verspreid over verschillende continenten en tijdzones.
• Zorg ervoor dat er een goed terugvalplan is en dat het deel uitmaakt van de algemene planning.
• Selecteer het snelle aantal Intel CPU-modellen voor de R3load-exportservers. Gebruik geen CPU-modellen voor 'energiebesparing' omdat ze lagere prestaties hebben en geen 4-socketservers gebruiken. Intel Xeon E5 Platinum 8158 is een goed voorbeeld.

Best practices om problemen te voorkomen

• Deel geen adviesorganisatie uit om de export uit te voeren en een andere adviesorganisatie uit te besteden om de import uit te voeren. Af en toe wordt het bronsysteem uitbesteed en beheerd door één adviesorganisatie of partner en een klant wil migreren naar Azure en overschakelen naar een andere partner. Vanwege de nauwe koppeling tussen export en importafstemming en configuratie, is het onwaarschijnlijk dat het toewijzen van deze taken aan verschillende organisaties een goed resultaat oplevert.
• Besnoem niet op Azure-hardwarebronnen tijdens de migratie en ga live. Azure Virtual Machines worden per minuut in rekening gebracht en kunnen eenvoudig worden verkleind. Gebruik tijdens een VLDB-migratie de krachtigste virtuele machine die beschikbaar is. Klanten zijn met succes live gegaan op 200-250% oversized systemen en zijn vervolgens gestabiliseerd tijdens het uitvoeren van oversized systemen. Nadat u het systeemgebruik gedurende 4-6 weken hebt bewaakt, worden virtuele machines met overtollige capaciteit verkleind of afgesloten om de kosten te verlagen.