Eksplorowanie bardzo dużej migracji bazy danych
Systemy SAP przeniesione do chmury platformy Azure często obejmują duże międzynarodowe systemy "pojedynczego wystąpienia globalnego". Te systemy są wiele razy większe niż pierwsze systemy klienta wdrożone, gdy platforma Azure została po raz pierwszy certyfikowana dla obciążeń SAP.
Bardzo duże bazy danych (VLDB) są teraz często przenoszone na platformę Azure. Rozmiary baz danych powyżej 20 TB wymagają dodatkowych technik i procedur w celu przeprowadzenia migracji ze środowiska lokalnego na platformę Azure w ramach akceptowalnego przestoju i niskiego ryzyka.
Ogólne omówienie
W pełni zoptymalizowana bardzo duża migracja bazy danych powinna osiągnąć około 2 TB na godzinę przepływności migracji na godzinę lub ewentualnie więcej. Oznacza to, że składnik transferu danych migracji o rozmiarze 20 TB można wykonać w około 10 godzin. Należy wykonać różne kroki przetwarzania poprocesowego i weryfikacji. Ogólnie rzecz biorąc, przy odpowiednim czasie przygotowania i testowania niemal każdy system klienta o dowolnym rozmiarze można przenieść na platformę Azure.
Migracje bazy danych VLDB wymagają znacznej umiejętności, uwagi na szczegóły i analizy. Na przykład efekt netto podziału tabeli musi być mierzony i analizowany. Podziały dużej tabeli na ponad 50 eksportów równoległych mogą znacznie skrócić czas potrzebny na wyeksportowanie tabeli, ale zbyt wiele podziałów tabel może spowodować drastyczny wzrost czasu importu. W związku z tym należy obliczyć i przetestować efekt netto podziałów tabeli. Ekspert licencjonowany konsultant ds. migracji systemu operacyjnego/bazy danych zapozna się z pojęciami i narzędziami. Wyróżniamy część zawartości specyficznej dla platformy Azure dla migracji bazy danych VLDB.
W szczególności zajmujemy się heterogeniczną migracją systemu operacyjnego/bazy danych na platformę Azure z programem SQL Server jako docelową bazą danych przy użyciu narzędzi, takich jak R3load i Migmon. Kroki migracji nie są przeznaczone do jednorodnych kopii systemowych, kopii, w której architektura dbMS i procesora (Endian Order) pozostaje taka sama. Ogólnie rzecz biorąc, jednorodne kopie systemowe powinny mieć niski przestój niezależnie od rozmiaru systemu DBMS, ponieważ wysyłka dziennika może służyć do synchronizowania kopii bazy danych na platformie Azure.
Diagram blokowy ilustrowany typowym migracją systemu operacyjnego/bazy danych VLDB i przejściem na platformę Azure następuje po kluczowych punktach:
Bieżący źródłowy system operacyjny/baza danych jest często AIX, HPUX, Solaris lub Linux; i DB2 lub Oracle.
Docelowy system operacyjny to Windows, Suse 12.3, Redhat 7.x lub Oracle Linux 7.x.
Docelowa baza danych to zazwyczaj SQL Server lub Oracle 12.2.
Wydajność wątków IBM pSeries, Solaris SPARC i HP Superdome jest drastycznie niższa niż tanie nowoczesne serwery intel, dlatego R3load jest uruchamiany na oddzielnych serwerach Intel.
Oprogramowanie VMware wymaga specjalnego dostrajania i konfiguracji, aby osiągnąć dobrą, stabilną i przewidywalną wydajność sieci. Zazwyczaj serwery fizyczne są używane jako serwer R3load, a nie maszyny wirtualne.
Często są używane cztery serwery eksportu R3load, chociaż nie ma limitu liczby serwerów eksportu. Typowa konfiguracja to:
- Serwer eksportu 1 — przeznaczony dla największych tabel 1–4 (w zależności od niesymetryczności dystrybucji danych w źródłowej bazie danych)
- Eksportowanie serwera 2 — przeznaczonego do tabel z podziałami tabel
- Eksportowanie serwera 3 — przeznaczonego do tabel z podziałami tabel
- Eksportowanie serwera 4 — wszystkie pozostałe tabele
Pliki zrzutu eksportu są przesyłane z dysku lokalnego na serwerze R3load firmy Intel do platformy Azure przy użyciu narzędzia AzCopy za pośrednictwem publicznego Internetu. Jest to zwykle szybsze niż za pośrednictwem usługi ExpressRoute.
Kontrolka i sekwencja importu odbywa się za pośrednictwem pliku sygnału (SGN), który jest generowany automatycznie po zakończeniu wszystkich pakietów eksportu. Umożliwia to eksportowanie/importowanie częściowo równoległe.
Importowanie do programu SQL Server lub Oracle ma strukturę podobną do eksportu przy użyciu czterech serwerów importu. Te serwery będą oddzielnymi dedykowanymi serwerami R3load z przyspieszoną siecią. Zaleca się, aby nie używać serwerów aplikacji SAP do tego zadania.
Bazy danych VLDB zwykle używają maszyn wirtualnych E64v3, m64 lub m128 z usługą Premium Storage. Dziennik transakcji można umieścić na lokalnym dysku SSD, aby przyspieszyć zapisy dziennika transakcji i usunąć liczbę operacji we/wy dziennika transakcji i przepustowość operacji we/wy z limitu przydziału maszyny wirtualnej. Po migracji dziennik transakcji powinien zostać umieszczony na trwałym dysku.
