Zeer grote databasemigratie verkennen
SAP-systemen die zijn verplaatst naar de Azure-cloud, omvatten nu vaak grote multinationale systemen met één globaal exemplaar. Deze systemen zijn vaak groter dan de eerste klantsystemen die zijn geïmplementeerd toen het Azure-platform voor het eerst werd gecertificeerd voor SAP-workloads.
Zeer grote databases (VLDB) worden nu vaak verplaatst naar Azure. Voor databasegrootten van meer dan 20 TB zijn extra technieken en procedures vereist om een migratie van on-premises naar Azure te realiseren binnen een acceptabele downtime en met een laag risico.
Overzicht op hoog niveau
Een volledig geoptimaliseerde zeer grote databasemigratie moet ongeveer 2 TB per uur migratiedoorvoer per uur of mogelijk meer bereiken. Dit betekent dat het gegevensoverdrachtonderdeel van een migratie van 20 TB in ongeveer 10 uur kan worden uitgevoerd. Er moeten verschillende postprocessen en validatiestappen worden uitgevoerd. Over het algemeen kan met voldoende tijd voor voorbereiding en testen vrijwel elk klantsysteem van elke grootte worden verplaatst naar Azure.
VLDB-migraties vereisen aanzienlijke vaardigheden, aandacht voor detail en analyse. Het netto-effect van een tabelsplitsing moet bijvoorbeeld worden gemeten en geanalyseerd. Het splitsen van een grote tabel in meer dan 50 parallelle exportbewerkingen kan de tijd die nodig is om een tabel te exporteren aanzienlijk verkorten, maar te veel tabelsplitsingen kunnen leiden tot drastisch hogere importtijden. Daarom moet het netto-effect van tabelsplitsingen worden berekend en getest. Een deskundige besturingssysteem/DB-migratieconsultant moet bekend zijn met de concepten en hulpprogramma's. We markeren enkele specifieke Azure-inhoud voor VLDB-migraties.
In het bijzonder hebben we te maken met heterogene OS/DB-migratie naar Azure met SQL Server als doeldatabase met behulp van hulpprogramma's zoals R3load en Migmon. De migratiestappen zijn niet bedoeld voor homogene systeemkopieën, een kopie waarin de DBMS en processorarchitectuur (Endian Order) hetzelfde blijft. In het algemeen moeten homogene systeemkopieën weinig downtime hebben, ongeacht de GROOTTE van DBMS, omdat logboekverzending kan worden gebruikt om een kopie van de database in Azure te synchroniseren.
Een blokdiagram dat wordt geïllustreerd van een typische VLDB OS/DB-migratie en de overstap naar Azure volgt na de belangrijkste punten:
Het huidige bron-besturingssysteem/DB is vaak AIX, HPUX, Solaris of Linux; en DB2 of Oracle.
Het doelbesturingssystemen zijn Windows, Suse 12.3, Redhat 7.x of Oracle Linux 7.x.
De doeldatabase is meestal SQL Server of Oracle 12.2.
IBM pSeries, Solaris SPARC-hardware en HP Superdome threadprestaties zijn drastisch lager dan goedkope moderne Intel-basisservers, dus R3load wordt uitgevoerd op afzonderlijke Intel-servers.
VMware vereist speciale afstemming en configuratie om goede, stabiele en voorspelbare netwerkprestaties te bereiken. Normaal gesproken worden fysieke servers gebruikt als R3load-server en niet als virtuele machines.
Meestal worden er vier R3load-servers voor export gebruikt, hoewel er geen limiet is voor het aantal exportservers. Een typische configuratie is:
- Exportserver 1: toegewezen aan de grootste 1-4 tabellen (afhankelijk van hoe scheeftrekken de gegevensdistributie zich in de brondatabase bevindt).
- Exportserver 2 : toegewezen aan tabellen met tabelsplitsingen.
- Server exporteren 3: toegewezen aan tabellen met tabelsplitsingen.
- Exportserver 4 : alle resterende tabellen.
Dumpbestanden exporteren worden overgebracht van de lokale schijf op de Intel-server voor R3load naar Azure met behulp van AzCopy via openbaar internet. Dit is doorgaans sneller dan via ExpressRoute.
Controle en volgorde van de import vindt plaats via het signaalbestand (SGN) dat automatisch wordt gegenereerd wanneer alle exportpakketten zijn voltooid. Dit maakt een semi-parallelle export/import mogelijk.
Importeren naar SQL Server of Oracle is vergelijkbaar met de export, met behulp van vier importservers. Deze servers zijn afzonderlijke toegewezen R3load-servers met versneld netwerken. Het wordt aanbevolen dat de SAP-toepassingsservers niet voor deze taak zijn.
VLDB-databases gebruiken doorgaans E64v3-, m64- of m128-vm's met Premium Storage. Het transactielogboek kan op de lokale SSD-schijf worden geplaatst om schrijfbewerkingen in transactielogboeken te versnellen en de IOPS- en IO-bandbreedte van het transactielogboek te verwijderen uit het quotum voor virtuele machines. Na de migratie moet het transactielogboek op een permanente schijf worden geplaatst.
