Nagyon nagy adatbázis-migrálás felfedezése
Az Azure-felhőbe áthelyezett SAP-rendszerek ma már gyakran tartalmaznak nagy nemzetközi "egyetlen globális példány" rendszereket. Ezek a rendszerek sokszor nagyobbak, mint az első üzembe helyezett ügyfélrendszerek, amikor az Azure-platformot először minősítették SAP-számítási feladatokhoz.
A nagyon nagy adatbázisok (VLDB) mostantól gyakran átkerülnek az Azure-ba. A 20 TB-nál nagyobb adatbázisméretek további technikákat és eljárásokat igényelnek a helyszíniről az Azure-ba való migráláshoz elfogadható állásidőn belül és alacsony kockázattal.
Magas szintű áttekintés
A teljes mértékben optimalizált, nagyon nagy méretű adatbázis-migrálás óránként körülbelül 2 TB-os migrálási átviteli sebességet érhet el óránként vagy akár többet is. Ez azt jelenti, hogy a 20 TB-os migrálás adatátviteli összetevője körülbelül 10 óra alatt elvégezhető. Különböző utófeldolgozási és érvényesítési lépéseket kell végrehajtani. Általánosságban elmondható, hogy a megfelelő előkészítési és tesztelési idővel szinte bármilyen méretű ügyfélrendszer áthelyezhető az Azure-ba.
A VLDB-migrálások jelentős jártasságot, részletes figyelmet és elemzést igényelnek. Egy tábla felosztásának nettó hatását például mérni és elemezni kell. A nagy táblák több mint 50 párhuzamos exportálásra való felosztása jelentősen csökkentheti a táblázat exportálásához szükséges időt, de a túl sok táblafelosztás drasztikusan megnövelheti az importálási időket. Ezért a táblák felosztásának nettó hatását ki kell számítani és tesztelni kell. Egy szakértő licenccel rendelkező operációsrendszer-/db-migrálási tanácsadó ismeri a fogalmakat és eszközöket. Kiemelünk néhány Azure-specifikus tartalmat a VLDB-migrálásokhoz.
Különösen az Azure-ba irányuló heterogén operációsrendszer-/ADATBÁZIS-migrálással foglalkozunk, céladatbázisként sql serverrel, például R3load és Migmon eszközökkel. A migrálási lépések nem homogén rendszerpéldányokra szolgálnak, egy olyan példányra, ahol a DBMS és a processzorarchitektúra (Endian Order) változatlan marad. Általánosságban elmondható, hogy a homogén rendszerpéldányoknak a DBMS méretétől függetlenül alacsony állásidővel kell rendelkezniük, mivel a naplók szállításával szinkronizálható az adatbázis egy példánya az Azure-ban.
Egy tipikus VLDB OS/DB-migrálást szemléltető blokkdiagram, amely a főbb pontok után az Azure-ba való áttérést követi:
A jelenlegi forrás operációs rendszer/ADATBÁZIS gyakran AIX, HPUX, Solaris vagy Linux; és DB2 vagy Oracle.
A cél operációs rendszer Windows, Suse 12.3, Redhat 7.x vagy Oracle Linux 7.x.
A céladatbázis általában SQL Server vagy Oracle 12.2.
Az IBM pSeries, a Solaris SPARC hardver és a HP Superdome szál teljesítménye drasztikusan alacsonyabb, mint az alacsony költségű modern Intel árukiszolgálók, ezért az R3load külön Intel-kiszolgálókon fut.
A VMware speciális hangolást és konfigurációt igényel a jó, stabil és kiszámítható hálózati teljesítmény eléréséhez. A fizikai kiszolgálók általában R3load-kiszolgálóként használatosak, nem pedig virtuális gépekként.
Általában négy exportálási R3load-kiszolgálót használnak, bár nincs korlátozva az exportálási kiszolgálók száma. Egy tipikus konfiguráció a következő:
- 1. exportálási kiszolgáló – a legnagyobb 1-4 táblához dedikált (attól függően, hogy az adateloszlás hogyan van eltolva a forrásadatbázison)
- 2. kiszolgáló exportálása – táblaeloszlással rendelkező tábláknak dedikált
- 3. kiszolgáló exportálása – táblaeloszlással rendelkező tábláknak dedikált
- 4. kiszolgáló exportálása – az összes többi tábla
Az exportálási memóriaképfájlok átvitele az Intel-alapú R3load-kiszolgáló helyi lemezéről az Azure-ba az AzCopy nyilvános interneten keresztül történő használatával történik. Ez általában gyorsabb, mint az ExpressRoute-on keresztül.
Az importálás vezérlése és sorrendje a jelfájlon (SGN) keresztül történik, amely az összes exportálási csomag befejezésekor automatikusan létrejön. Ez lehetővé teszi a félig párhuzamos exportálást/importálást.
Az SQL Serverre vagy az Oracle-be történő importálás az exportáláshoz hasonlóan, négy importálási kiszolgáló használatával történik. Ezek a kiszolgálók külön dedikált R3load-kiszolgálók lennének, gyorsított hálózatkezeléssel. Javasoljuk, hogy ehhez a feladathoz ne használja az SAP-alkalmazáskiszolgálót.
A VLDB-adatbázisok általában E64v3, m64 vagy m128 rendszerű virtuális gépeket használnak a Premium Storage használatával. A tranzakciónapló elhelyezhető a helyi SSD-lemezen a tranzakciónapló írásának felgyorsítása és a tranzakciónapló IOPS- és IO-sávszélességének eltávolítása érdekében a virtuálisgép-kvótából. A migrálás után a tranzakciónaplót egy fenntartott lemezre kell helyezni.
