Erkunden der Migration sehr großer Datenbanken
Zu den SAP-Systemen, die in die Azure-Cloud verlagert werden, gehören häufig große multinationale „Single Global Instance“-Systeme. Diese Systeme sind oft um ein Vielfaches größer als die Systeme, die bei der anfänglichen Zertifizierung der Azure-Plattform für SAP-Workloads bereitgestellt wurden.
Sehr große Datenbanken (Very Large Databases, VLDB) werden nun häufig in Azure verlagert. Bei Datenbankgrößen von mehr als 20 TB sind zusätzliche Techniken und Verfahren erforderlich, um die Migration von einem lokalen Standort zu Azure mit einer akzeptablen Downtime und mit geringem Risiko zu realisieren.
Allgemeine Übersicht
Bei einer vollständig optimierten VLDB-Migration sollte ein Migrationsdurchsatz von etwa 2 TB pro Stunde oder mehr erreicht werden. Dies bedeutet, dass die Phase der Datenübertragung bei einer 20-TB-Migration in etwa 10 Stunden durchgeführt werden kann. Es müssen verschiedene Schritte für Nachbearbeitung und Validierung ausgeführt werden. Im Allgemeinen können – mit genügend Zeit für Vorbereitungen und Tests – Kundensysteme fast jeder Größe zu Azure verlagert werden.
VLDB-Migrationen erfordern ein hohes Maß an Fachkenntnis, Detailgenauigkeit und Analyse. So muss beispielsweise die Nettoauswirkung einer Tabellenaufteilung gemessen und analysiert werden. Die Aufteilung einer großen Tabelle in mehr als 50 parallele Exporte kann die Zeit für den Export einer Tabelle beträchtlich verkürzen, aber zu viele Tabellenaufteilungen können zu einer drastischen Erhöhung der Importzeiten führen. Daher muss die Nettoauswirkung der Tabellenaufteilung berechnet und getestet werden. Ein erfahrener, lizenzierter Berater für Betriebssystem/Datenbankmigrationen ist mit diesen Konzepten und Tools vertraut. Wir heben einige Azure-spezifische Inhalte für VLDB-Migrationen hervor.
Insbesondere werden wir uns mit der heterogenen Migration von Betriebssystemen/Datenbanken zu Azure mit SQL Server als Zieldatenbank befassen, bei der Tools wie R3load and Migration Monitor (MIGMON) zum Einsatz kommen. Die Migrationsschritte gelten nicht für homogene Systemkopien, d. h. für Kopien, bei denen DBMS und Prozessorarchitektur (Endian-Format) unverändert bleiben. Im Allgemeinen sollte bei homogenen Systemkopien, unabhängig von der DBMS-Größe, die Downtime gering sein, da der Protokollversand zum Synchronisieren einer Kopie der Datenbank in Azure verwendet werden kann.
Ein Blockdiagramm, das eine typische VLDB OS/DB-Migration und die Verschiebung zu Azure veranschaulicht, folgt nach den wichtigsten Punkten:
Das aktuelle Quellbetriebssystem/die aktuelle Quelldatenbank ist häufig AIX, HPUX, Solaris oder Linux und DB2 oder Oracle.
Das Zielbetriebssystem ist entweder Windows, Suse 12.3, Red Hat 7.x oder Oracle Linux 7.x
Die Zieldatenbank ist in der Regel entweder SQL Server oder Oracle 12.2.
Die Threadleistung von IBM pSeries, Solaris SPARC-Hardware und HP Superdome ist erheblich geringer als die von kostengünstigen modernen Intel-Standardservern. Daher wird R3load auf separaten Intel-Servern ausgeführt.
VMware erfordert für eine gute, stabile und vorhersagbare Netzwerkleistung eine spezielle Optimierung und Konfiguration. In der Regel werden physische Server und keine virtuellen Computer (VMs) als R3load-Server verwendet
Üblicherweise werden vier R3load-Exportserver verwendet, es gibt jedoch keine Beschränkung für die Anzahl der Exportserver. Eine typische Konfiguration könnte wie folgt aussehen:
- Exportserver 1: vorgesehen für die größten 1–4 Tabellen (abhängig vom Grad der Verzerrung der Datenverteilung in der Quelldatenbank)
- Exportserver 2: vorgesehen für Tabellen mit Tabellenaufteilungen
- Exportserver 3: vorgesehen für Tabellen mit Tabellenaufteilungen
- Exportserver 4: für alle übrigen Tabellen
Exportdumpdateien werden mithilfe von AzCopy über das öffentliche Internet vom lokalen Datenträger auf dem Intel-basierten R3load-Server zu Azure übertragen. Dies ist in der Regel schneller als über ExpressRoute.
Steuerung und Sequenzierung des Imports erfolgen über die Signaldatei (SGN), die automatisch generiert wird, wenn alle Exportpakete abgearbeitet sind. Dies ermöglicht einen halbparallelen Export/Import.
Der Import in SQL Server oder Oracle ist mit der Verwendung von vier Importservern ähnlich strukturiert wie der Export. Für diese Server werden separate dedizierte R3load-Server mit beschleunigtem Netzwerkbetrieb verwendet. Für diese Aufgabe sollten keine SAP-Anwendungsserver verwendet werden.
Für sehr große Datenbanken kommen in der Regel VMs vom Typ E64v3, m64 oder m128 mit Storage Premium zum Einsatz. Das Transaktionsprotokoll kann auf dem lokalen SSD-Datenträger gespeichert werden, damit Schreibvorgänge in das Transaktionsprotokoll beschleunigt werden und die IOPS des Transaktionsprotokolls und die E/A-Bandbreite nicht in das VM-Kontingent einfließen. Nach der Migration sollte das Transaktionsprotokoll auf einem persistenten Datenträger gespeichert werden.
