Utforska mycket stor databasmigrering

Slutförd

SAP-system som flyttas till Azure-molnet innehåller nu ofta stora multinationella system med "enskild global instans". Dessa system är många gånger större än de första kundsystemen som distribuerades när Azure-plattformen först certifierades för SAP-arbetsbelastningar.

Mycket stora databaser (VLDB) flyttas nu ofta till Azure. Databasstorlekar över 20 TB kräver extra tekniker och procedurer för att uppnå en migrering från lokalt till Azure inom en acceptabel stilleståndstid och med låg risk.

Översikt på hög nivå

En fullständigt optimerad mycket stor databasmigrering bör uppnå cirka 2 TB per timmes migreringsflöde per timme eller eventuellt mer. Det innebär att dataöverföringskomponenten i en 20 TB-migrering kan utföras på cirka 10 timmar. Olika steg för efterbearbetning och validering måste utföras. I allmänhet kan du flytta nästan alla kundsystem av valfri storlek till Azure med tillräckligt med tid för förberedelse och testning.

VLDB-migreringar kräver stor kompetens, uppmärksamhet på detaljer och analys. Till exempel måste nettoeffekten av en tabelldelning mätas och analyseras. Uppdelningar av en stor tabell i mer än 50 parallella exporter kan avsevärt minska den tid det tar att exportera en tabell, men för många tabelldelningar kan leda till drastiskt ökade importtider. Därför måste nettoeffekten av tabelldelningar beräknas och testas. En expertlicensierad OS/DB-migreringskonsult bör känna till begreppen och verktygen. Vi lyfter fram ett visst Azure-specifikt innehåll för VLDB-migreringar.

I synnerhet hanterar vi heterogen OS/DB-migrering till Azure med SQL Server som måldatabas med hjälp av verktyg som R3load och Migmon. Migreringsstegen är inte avsedda för homogena systemkopior, en kopia där DBMS- och processorarkitekturen (Endian Order) förblir desamma. I allmänhet bör homogena systemkopior ha låg stilleståndstid oavsett DBMS-storlek, eftersom loggleverans kan användas för att synkronisera en kopia av databasen i Azure.

Ett blockdiagram som illustreras av en typisk VLDB OS/DB-migrering och flytt till Azure följer efter nyckelpunkterna:

  • Det aktuella källoperativsystemet/DATABASEN är ofta AIX, HPUX, Solaris eller Linux. och DB2 eller Oracle.

  • Måloperativsystemet är antingen Windows, Suse 12.3, Redhat 7.x eller Oracle Linux 7.x.

  • Måldatabasen är vanligtvis antingen SQL Server eller Oracle 12.2.

  • IBM pSeries, Solaris SPARC-maskinvara och HP Superdome trådprestanda är drastiskt lägre än billiga moderna Intel-råvaruservrar, därför körs R3load på separata Intel-servrar.

  • VMware kräver särskild justering och konfiguration för att uppnå bra, stabil och förutsägbar nätverksprestanda. Vanligtvis används fysiska servrar som R3load-server och inte virtuella datorer.

  • Vanligtvis används fyra R3load-exportservrar, men det finns ingen gräns för antalet exportservrar. En typisk konfiguration är:

    • Exportera server 1 – dedikerad till de största 1–4 tabellerna (beroende på hur skev datadistributionen är på källdatabasen).
    • Exportera server 2 – dedikerad till tabeller med tabelldelningar.
    • Exportera server 3 – dedikerad till tabeller med tabelldelningar.
    • Exportera server 4 – alla återstående tabeller.
  • Exportera dumpfiler överförs från den lokala disken i den Intel-baserade R3load-servern till Azure med azcopy via offentligt Internet. Detta är vanligtvis snabbare än via ExpressRoute.

  • Kontroll och sekvens av importen sker via den signalfil (SGN) som genereras automatiskt när alla exportpaket har slutförts. Detta möjliggör en halvparallell export/import.

  • Importen till SQL Server eller Oracle är strukturerad på samma sätt som exporten med hjälp av fyra importservrar. Dessa servrar skulle vara separata dedikerade R3load-servrar med accelererat nätverk. Vi rekommenderar att SAP-programservrarna inte används för den här uppgiften.

  • VLDB-databaser använder vanligtvis virtuella datorer med E64v3, m64 eller m128 med Premium Storage. Transaktionsloggen kan placeras på den lokala SSD-disken för att påskynda transaktionsloggskrivningar och ta bort transaktionsloggens IOPS- och I/O-bandbredd från kvoten för den virtuella datorn. Efter migreringen ska transaktionsloggen placeras på en sparad disk.

Diagram som visar en typisk databasmigrering av V L D B-operativsystem och flytt till Azure.