Planowanie migracji danych

Ukończone

Projekt modernizacji platformy danych ma pięć etapów, które są zwykle wykonywane w podanej kolejności.

W naszym globalnym scenariuszu sprzedawcy detalicznego zarząd zatwierdził projekt modernizacji i zaczynasz organizować pracowników i inne zasoby. Aby optymalnie skonfigurować i przypisać zadania, musisz dokładnie zrozumieć fazy projektu.

W tej lekcji zapoznasz się bardziej szczegółowo z każdym z pięciu etapów.

Inicjowanie i odnajdywanie

Projekty modernizacji platformy danych są zwykle inicjowane w celu spełnienia wymagań biznesowych lub prawnych. Dlatego ważne jest, aby uwzględnić te potrzeby i uzyskać wsparcie od wyższego szczebla kadry kierowniczej. Pierwszym krokiem jest wykonanie ćwiczenia odnajdywania, które obejmuje następujące zagadnienia:

• Ocena bieżącego środowiska

  Wiele infrastruktur IT zwykle ewoluuje w ciągu wielu lat, być może nawet dziesięcioleci. W tym czasie firma i pracownicy mogą zmieniać się ogromnie w zakresie, w jakim mogą już nie być ekspertami w systemach, które organizacja ma. W niektórych rzadkich przypadkach organizacje mogą nawet zapomnieć, że nadal istnieją pewne systemy.

• Sprawdzanie zależności między istniejącymi aplikacjami i bazami danych

  Należy zająć trochę czasu, aby zrozumieć, w jaki sposób aplikacje wchodzą w interakcje z bazami danych istniejącymi w sieci. Ponadto należy również zrozumieć wszelkie zależności między bazami danych, które mogą istnieć, aby można było grupować bazy danych razem w grupach logicznych. Wykonując to ćwiczenie, użyjesz logicznych grup baz danych jako podstawy do migracji ich na platformę Azure jako jedną jednostkę.

• Wyświetlanie listy typów obciążeń systemów

  Wyświetlanie listy typów obciążeń dla zidentyfikowanych serwerów baz danych zapewnia wgląd w ich użycie. Obciążenia mogą być podzielone na kategorie jako analityczne (OLAP) lub transakcyjne (OLTP) na podstawie tego, czy są intensywnie odczytywane, czy zapisu. Pomaga to zdecydować, do której technologii platformy danych ma być migrowana. Dalsza kategoryzacja może obejmować obciążenia wsadowe lub decyzyjne.

Ocena

Podczas etapu oceny informacje zebrane w fazie odnajdywania są używane do przeprowadzenia kompleksowej oceny zidentyfikowanych obciążeń w celu ustalenia następujących elementów:

• Wszelkie potencjalne blokady migracji
• Wszelkie zmiany powodujące niezgodność, które wymagają poprawek po migracji
• Funkcje platformy Azure, których mogą używać obciążenia

Należy to ustalić, wypełniając bieżącą ocenę obciążenia i ocenę kryteriów obciążenia:

• Bieżąca ocena obciążenia

  Zidentyfikowane serwery i aplikacje bazy danych są podzielone na kategorie i potwierdzone w celu ustalenia następujących elementów: ilość danych i oczekiwane wskaźniki wzrostu, średnie użycie zasobów i ich krytyczne znaczenie dla firmy. Ten etap stanowi również możliwość rozważenia łączenia lub likwidowania lokalnych baz danych w celu zmniejszenia liczby baz danych do migracji i obniżenia całkowitego kosztu posiadania.

• Ocena kryteriów obciążenia

  W ocenie kryteriów obciążenia należy użyć wyników z bieżącej oceny obciążenia i zdefiniować kryteria po migracji do uruchamiania zidentyfikowanych obciążeń.

  Załóżmy, że zidentyfikowano intensywnie używany transakcyjny serwer baz danych w godzinach szczytu, ale z niskim użyciem poza godzinami szczytu. W ocenie kryteriów obciążenia należy zdefiniować kryteria po migracji, takie jak migracja do usługi Azure SQL Database z automatycznym skalowaniem w celu obsługi szczytowych obciążeń.

Planowanie

Etap planowania projektu modernizacji platformy danych obejmuje określenie platformy docelowej, podejścia do migracji i planów ograniczania ryzyka dla wszelkich planowanych lub nieplanowanych przerw.

W fazie planowania procesu modernizacji platformy danych istnieje siedem terminów opisujących sposób obsługi przenoszenia aplikacji i danych z istniejącego środowiska lokalnego do nowego środowiska opartego na chmurze (publicznego lub prywatnego):

#	Faza	Akcja	opis
1.	Pozostać	Nic nie rób	Ciągła modernizacja przy jednoczesnym uwzględnieniu długoterminowych opcji pozostałych usług lokalnych.
2.	Ponowne hostowanie	Migrowanie do IaaS	Takie podejście eliminuje potrzebę zarządzania centrum danych i zapewnia wyższy zwrot z inwestycji (ROI) za pomocą niższego całkowitego kosztu posiadania (TCO).
3.	Refaktoryzacja	Migracja do usług IaaS lub PaaS z minimalnymi zmianami aplikacji	Takie podejście eliminuje potrzebę zarządzania centrum danych i zapewnia wyższy zwrot z inwestycji (ROI) za pomocą niższego całkowitego kosztu posiadania (TCO). Może również umożliwić mniejsze obciążenie związane z zarządzaniem poprzez konsolidację baz danych.
4.	Zmiana architektury	Ponowne zapisywanie podstawowych aspektów aplikacji w celu korzystania z technologii w chmurze	Umożliwia korzystanie z nowoczesnych składników, zmniejsza wdrażanie kodu i ułatwia wdrażanie infrastruktury i usług DevOps.
5.	Ponowne kompilowanie	Ponowne kompilowanie aplikacji w celu korzystania z technologii PaaS lub bezserwerowych	Ponowne kompilowanie platform danych i aplikacji przy użyciu nowszych technologii umożliwia korzystanie z wbudowanej wysokiej dostępności platformy Azure, zwiększa przenośność aplikacji i skalowalność oraz minimalizuje potencjalne luki w umiejętnościach między technologią używaną a personelem pomocniczym/opracowywaniem aplikacji.
6.	Replace	Zastępowanie aplikacji przez nowszą aplikację lub rozwiązanie SaaS	Rozważ metodę zamiany, gdy aplikacja ma zależności od urządzeń fizycznych dołączonych do serwera lub gdy ściśle integruje się z infrastrukturą lokalną.
7.	Wycofaj	Likwiduj aplikacje, które nie są już wymagane	Podejście wycofywania powinno być brane pod uwagę, gdy starsze aplikacje i bazy danych nie są już używane, ponieważ nie ma wymagań biznesowych ani prawnych, aby je zachować.

Na poniższym wykresie przedstawiono ilość nakładu pracy wymaganego przez każdy termin w porównaniu z wartością uzyskaną przez firmę z migracji.

• Opcje elementu docelowego platformy

  Dostępne są dwie opcje wysokiego poziomu, jeśli chodzi o wybór platformy docelowej.

  • Infrastruktura jako usługa (IaaS) — w tym podejściu przeprowadzisz migrację danych na maszynę wirtualną z zainstalowanym programem SQL Server.

  • Platforma jako usługa (PaaS) — w tym podejściu zmigrujesz dane do usługi platformy danych, która odpowiada obciążeniu. W przypadku obciążeń transakcyjnych dotyczyłoby to usługi Azure SQL Database lub Azure SQL Managed Instance. W przypadku obciążeń typu przetwarzanie analityczne online (OLAP) wymaga to usługi Azure Synapse Analytics.

• Wybieranie platformy docelowej według funkcji

  • Azure SQL Database — użyj, jeśli obszar powierzchni aplikacji ma zakres bazy danych. Usługa SQL Database oferuje rozwiązanie o niskiej konserwacji, które może być doskonałym rozwiązaniem dla niektórych obciążeń.

  • Elastyczne pule usługi Azure SQL Database — pule elastyczne umożliwiają przydzielanie zasobów magazynu i zasobów obliczeniowych do grupy baz danych, a nie konieczności zarządzania zasobami dla każdej bazy danych osobno. Ponadto pule elastyczne są łatwiejsze do skalowania niż pojedyncze bazy danych, w których skalowanie poszczególnych baz danych nie jest już potrzebne z powodu zmian wprowadzonych w elastycznej puli.

  • Bezserwerowa usługa Azure SQL Database — efektywne jest obniżenie kosztów w środowiskach deweloperskich i testowych. Funkcja opóźnienia automatycznego wstrzymywania umożliwia ustawienie nieaktywnego okresu przed automatycznym wstrzymaniem bazy danych. Możesz wybrać od 1 godziny do 7 dni lub wyłączyć. Podczas ponownego uzyskiwania dostępu do bazy danych wznawia ona i powoduje naliczanie opłat za magazyn tylko podczas wstrzymania.

  • Azure SQL Managed Instance — byłoby odpowiednie do użycia, jeśli obszar powierzchni aplikacji jest zakresem wystąpienia i wymaga funkcji niedostępnych w usłudze Azure SQL Database, takich jak:

    • Agent SQL
    • MSDTC
    • DQS
    • MDS
    • Poczta bazy danych
    • PolyBase
    • Obsługa serwerów połączonych
    • Obsługuje nowe usługi w chmurze platformy Azure, takie jak wykrywanie zagrożeń

  • Program SQL Server na maszynie wirtualnej platformy Azure — użyj, jeśli obszar powierzchni aplikacji jest zakresem wystąpienia i wymaga funkcji niedostępnych w usłudze Azure SQL Managed Instance, takich jak usługi SQL Server Reporting Services (SSRS), SQL Server Analysis Services (SSAS) i usługi SQL Server Integration Services (SSIS).

  • Azure Synapse Analytics — jeśli masz aplikacje, które uruchamiają złożone zapytania w dużej ilości danych, które mogą korzystać z masowego przetwarzania równoległego (MPP), aby skrócić czas przetwarzania zapytań.

Aby wyświetlić listę funkcji obsługiwanych w każdej ofercie PaaS dla języka SQL, zobacz Porównanie funkcji: Azure SQL Database i Azure SQL Managed Instance.

• Wybieranie platformy docelowej według kosztów

  • Azure SQL Database — charakter typu "platforma jako usługa" usługi Azure SQL Database znacznie zmniejsza koszty administracji i zarządzania w przypadku bardziej tradycyjnego programu SQL Server w topologii IaaS platformy Azure, ponieważ większość wymaganych zadań jest ukończona w tle przez firmę Microsoft. Na dużą skalę można zaoszczędzić dużo czasu i wysiłku.

  • Elastyczne pule usługi Azure SQL Database — elastyczne pule usługi Azure SQL Database zapewniają znaczne oszczędności dla wielu baz danych z nieprzewidywalnymi wymaganiami dotyczącymi użycia. Zasoby obliczeniowe są współużytkowane, unikając nadmiernej aprowizacji i obniżając koszty konserwacji i administrowania serwerem.

  • Usługa Azure SQL Managed Instance — usługa SQL Managed Instance jest oferowana tym klientom, którzy chcą w pełni zarządzanej usługi, gdzie mogą łatwo podnieść i zmienić środowisko lokalne przy minimalnych zmianach konfiguracji. Środowisko oferuje co najmniej 8 rdzeni i do 8 TB magazynu i znajduje się w izolowanej sieci wirtualnej. Ta oferta jest doskonała dla klientów, którzy chcą szybko dostać się do chmury i chcą uniknąć narzutów na konserwę maszyn wirtualnych.

  • Program SQL Server na maszynie wirtualnej platformy Azure — w porównaniu z ofertami PaaS program SQL Server uruchomiony na maszynach wirtualnych platformy Azure ma wyższe koszty obliczeniowe, magazynowe i zarządzania, ale zapewnia większą kontrolę nad programem SQL Server i infrastrukturą.

  • Azure Synapse Analytics — usługa Azure Synapse Analytics może obniżyć koszty dzięki wykorzystaniu architektury MPP do przetwarzania złożonych zapytań w ciągu kilku minut, a nie godzin.

• Migracje w trybie offline a online

  Na etapie planowania należy rozważyć, czy wykonujesz migrację w trybie offline, czy w trybie online. W przypadku migracji w trybie offline przestój aplikacji rozpoczyna się w tym samym czasie, kiedy rozpoczyna się migracja. Aby ograniczyć czas przestoju wymagany do przekroczenia do nowego środowiska po zakończeniu migracji, użyj migracji online. Zaleca się przetestowanie migracji w trybie offline w celu ustalenia, czy przestój jest akceptowalny; jeśli nie, wykonaj migrację online. Ponadto opcje online i offline mogą być niedostępne w zależności od wybranej platformy Azure.

Przekształcanie i optymalizowanie

Ocena i planowanie zidentyfikowałyby aspekty aplikacji i bazy danych, które wymagają pracy po migracji, które przekształcają lub optymalizują funkcję w celu zapewnienia pomyślnej migracji. Transformacja zwykle obejmuje pracę, która wymaga naprawienia lub zmiany aspektu bazy danych.

Optymalizacja zwykle polega na wprowadzeniu modyfikacji migrowanej bazy danych w celu skorzystania z funkcji lub optymalizacji jej użycia na platformie Azure.

Na przykład przekształcenie może obejmować zmodyfikowanie procedury składowanej lub zapytania SQL zawierającego składnię, która nie jest obsługiwana w docelowej bazie danych. Wymagałoby to dostosowania składni w celu zapewnienia zgodności z nową platformą bazy danych, zapewniając bezproblemowe działanie procedury składowanej lub zapytania bez żadnych problemów w środowisku docelowym.

• Przekształcać

  Aby zapewnić pomyślne środowisko po migracji, może być konieczne wprowadzenie co najmniej jednej z poniższych zmian w bazie danych.

  • Instalowanie uaktualnień wersji przed migracją

  • Naprawianie błędów zidentyfikowanych przez narzędzia do oceny migracji

  • Implementowanie zmian schematu bazy danych

  • Migrowanie istniejących zintegrowanych usług baz danych na platformę Azure

  • Obsługa obciążeń usług SSIS w chmurze

• Optymalizacja

  Podczas migracji może istnieć co najmniej jedna z poniższych wskazówek dotyczących optymalizacji, które należy wykonać, aby upewnić się, że Twoja organizacja uzyskuje największe korzyści z inwestycji na platformie Azure.

  • Ocena, jakie nowe funkcje mogą być dostępne na platformie docelowej

  • Zmiana struktury obciążeń na bardziej ekonomiczne lub wydajne zestawy

  • Wybierz najwyższy poziom usług i warstwę wydajności podczas migracji, a następnie skaluj w dół po zakończeniu migracji

  • Upewnij się, że obciążenia mają odpowiedni rozmiar

  • Zminimalizuj odległość między plikiem BACPAC a docelowym centrum danych

  • Wyłącz automatyczne statystyki na czas migracji.

  • Partycjonuj tabele i indeksy.

  • Upuść indeksowane widoki i utwórz je ponownie po zakończeniu

Migrowanie, weryfikowanie i korygowanie

Ta faza obejmuje samą migrację, a co ważne kroki weryfikacji i kroki korygowania wymagane do potwierdzenia pomyślnej migracji. Poprzednie etapy planowania, oceny i transformacji zapewnią, że wszystko jest gotowe do migracji i działa prawidłowo po przeniesieniu na platformę Azure. Wszystko, co pozostało do zrobienia, to przygotowanie wymaganych narzędzi migracji, ukończenie migracji i uruchomienie weryfikacji funkcjonalności i wydajności po migracji w celu zapewnienia spójności danych ze źródłową bazą danych.

Zagadnienia dotyczące migracji, walidacji i korygowania

Istnieje wiele narzędzi, których można użyć do przeprowadzenia migracji do wybranej platformy docelowej. Te narzędzia zostaną omówione w innych modułach. W międzyczasie należy wziąć pod uwagę następujące kwestie podczas kończenia migracji:

• Zrozumienie wymagań dotyczących obciążenia jako punktu wyjścia
• Wybierz niekrytyczne obciążenia lub bazy danych o niskim priorytcie na potrzeby migracji początkowo
• Uruchamianie migracji testowej
• Testowanie bazy danych pod kątem problemów
• Testowanie planu w celu ograniczenia ryzyka związanego z przestojami i problemami ze zgodnością
• Ocena narzędzi migracji na podstawie zakłóceń w celu zmniejszenia ryzyka przestoju bazy danych
• Stale iteracja procesu migracji
• Rozważ okna obsługi dostępne dla aplikacji i bazy danych przeznaczone do migracji
• Przełącz stare bazy danych i aplikacje w tryb offline
• Testowanie aplikacji innych firm
• Tworzenie nowych planów odzyskiwania po awarii i konserwacji