Prozkoumání velmi rozsáhlé migrace databází
Systémy SAP přesunuté do cloudu Azure teď běžně zahrnují velké mezinárodní systémy "jediné globální instance". Tyto systémy jsou mnohokrát větší než první zákaznické systémy nasazené při prvním certifikaci platformy Azure pro úlohy SAP.
Velmi rozsáhlé databáze (VLDB) se teď běžně přesouvají do Azure. Velikosti databází větší než 20 TB vyžadují další techniky a postupy pro dosažení migrace z místního prostředí do Azure v přijatelném výpadku a s nízkým rizikem.
Podrobný přehled
Plně optimalizovaná velmi velká migrace databáze by měla dosáhnout přibližně 2 TB za hodinu propustnost migrace za hodinu nebo více. To znamená, že komponentu přenosu dat migrace 20 TB je možné provést přibližně za 10 hodin. Je potřeba provést různé kroky postprocesu a ověření. Obecně platí, že s dostatečným časem pro přípravu a testování téměř jakéhokoli zákaznického systému jakékoli velikosti je možné přesunout do Azure.
Migrace VLDB vyžadují značné dovednosti, pozornost k podrobnostem a analýze. Například čistý účinek rozdělení tabulky musí být měřen a analyzován. Rozdělení velké tabulky na více než 50 paralelních exportů může výrazně snížit čas potřebný k exportu tabulky, ale příliš mnoho rozdělení tabulek může způsobit výrazně vyšší dobu importu. Proto musí být vypočítán a testován čistý účinek rozdělení tabulek. Odborník licencovaný konzultant pro migraci operačního systému nebo databáze by měl být obeznámen s koncepty a nástroji. Zvýrazníme určitý obsah Azure pro migrace VLDB.
Konkrétně se zabýváme heterogenní migrací operačního systému nebo databáze do Azure s SQL Serverem jako cílovou databází pomocí nástrojů, jako je R3load a Migmon. Kroky migrace nejsou určené pro homogenní systémové kopie, kopii, kde dbMS a architektura procesoru (Endian Order) zůstává stejná. Obecně platí, že homogenní kopie systému by měly mít nízký výpadek bez ohledu na velikost DBMS, protože expedici protokolu je možné použít k synchronizaci kopie databáze v Azure.
Blokový diagram znázorňuje typickou migraci operačního systému nebo databáze VLDB a přechod do Azure za klíčovými body:
Aktuální zdrojový operační systém/databáze je často AIX, HPUX, Solaris nebo Linux; a DB2 nebo Oracle.
Cílovým operačním systémem je Windows, Suse 12.3, Redhat 7.x nebo Oracle Linux 7.x.
Cílová databáze je obvykle SQL Server nebo Oracle 12.2.
Výkon vláken IBM pSeries, Solaris SPARC a hp Superdome je výrazně nižší než nízkonákladové moderní komoditní servery Intel, proto se R3load spouští na samostatných serverech Intel.
Pro dosažení dobrého, stabilního a předvídatelného výkonu sítě vyžaduje VMware speciální ladění a konfiguraci. Fyzické servery se obvykle používají jako server R3load, nikoli virtuální počítače.
Běžně se používají čtyři servery R3load pro export, ale počet exportovaných serverů není nijak omezený. Typická konfigurace by byla:
- Export serveru 1 – vyhrazený pro největší tabulky 1–4 (v závislosti na tom, jak nerovnoměrná distribuce dat je ve zdrojové databázi).
- Export serveru 2 – vyhrazené pro tabulky s rozdělením tabulek
- Export serveru 3 – vyhrazené pro tabulky s rozdělením tabulek.
- Export serveru 4 – všechny zbývající tabulky
Soubory s výpisem paměti exportu se přenesou z místního disku na serveru Intel R3load do Azure pomocí AzCopy přes veřejný internet. Obvykle je to rychlejší než přes ExpressRoute.
Řízení a posloupnost importu se provádí prostřednictvím souboru signálu (SGN), který se automaticky vygeneruje při dokončení všech exportovaných balíčků. To umožňuje částečně paralelní export/import.
Import do SQL Serveru nebo Oracle je strukturovaný podobně jako export pomocí čtyř serverů pro import. Tyto servery by byly samostatné vyhrazené servery R3load s akcelerovanými síťovými službami. Doporučuje se, aby aplikační servery SAP nejsou pro tuto úlohu.
Databáze VLDB obvykle používají virtuální počítače E64v3, m64 nebo m128 se službou Premium Storage. Transakční protokol lze umístit na místní disk SSD, aby se urychlily zápisy transakčních protokolů a odebraly vstupně-výstupní šířku pásma transakčního protokolu a vstupně-výstupní šířky pásma z kvóty virtuálního počítače. Po migraci by se transakční protokol měl umístit na trvalý disk.
