Migracja on-prem do Azure SQL: kolejność, która ogranicza ryzyko

Krok 1. Wybór usługi docelowej

Azure SQL to rodzina usług, a różnice między nimi decydują o zakresie zmian w aplikacjach. Wybór warto zrobić świadomie, zanim zespół zacznie oceniać kompatybilność, bo każda usługa ma inne ograniczenia i inny podział odpowiedzialności.

Przeniesienie na maszynę wirtualną, czyli klasyczny lift-and-shift, bywa najszybsze, ale przenosi do chmury także całą dotychczasową pracę utrzymaniową. Usługi zarządzane zdejmują ją z zespołu, w zamian wymagając dopasowania aplikacji i procesów.

Na tym etapie warto też ustalić model licencjonowania. W modelu opartym na rdzeniach wirtualnych posiadane licencje SQL Server z aktywnym Software Assurance można wykorzystać dzięki Azure Hybrid Benefit, co wyraźnie zmienia koszt usługi. Dla niektórych baz, zwłaszcza o zmiennym obciążeniu, rozsądniejsza może być warstwa bezserwerowa Azure SQL Database. Te decyzje wpływają na budżet bardziej niż drobne różnice w rozmiarze.

Krok 2. Ocena kompatybilności

Ocenę zaczynamy od narzędzi Microsoftu, na przykład Azure Migrate, które sprawdzają bazy pod kątem funkcji nieobsługiwanych w wybranej usłudze i proponują rozmiar na podstawie zebranych danych wydajnościowych. Raport z narzędzia jest jednak dopiero punktem wyjścia, bo pomija elementy, których nie widać w samej bazie:

• zadania SQL Server Agent i pakiety SSIS uruchamiane na tym samym serwerze,
• serwery połączone i zapytania odwołujące się do innych baz po nazwie,
• procedury korzystające z systemu plików, poczty bazy danych lub poleceń systemu operacyjnego,
• zależność od strefy czasowej serwera, ponieważ Azure SQL Database działa w czasie UTC, a w Managed Instance strefę wybiera się przy tworzeniu instancji,
• sortowanie (collation) na poziomie instancji, od którego zależy porównywanie tekstów, na przykład w tabelach tymczasowych.

Osobnym tematem jest poziom zgodności bazy (compatibility level). Po migracji można go początkowo pozostawić na dotychczasowej wartości, co ogranicza ryzyko zmian w planach zapytań, a podnieść dopiero po porównaniu wydajności w Query Store. Takie rozdzielenie dwóch zmian, czyli przeniesienia i aktualizacji zachowania optymalizatora, ułatwia ustalenie przyczyny, jeśli coś zacznie działać wolniej.

Krok 3. Dane referencyjne i zależności między bazami

Dane referencyjne, czyli słowniki produktów, cenniki, kursy walut, struktury organizacyjne czy kody kontrahentów, rzadko mają jednego właściciela i często są kopiowane między bazami przez zadania nocne, wyzwalacze albo ręczne skrypty. W środowisku lokalnym wszystko działa, bo bazy stoją na tej samej instancji. Po migracji części baz te powiązania przestają działać, często bez wyraźnego błędu.

Dlatego przed planowaniem fal migracji ustalamy:

• które bazy są źródłem danych referencyjnych, a które je tylko kopiują,
• jakim mechanizmem i jak często dane są synchronizowane,
• które bazy muszą migrować razem, bo zapytania łączą je bezpośrednio,
• czy kopiowanie można zastąpić jednym źródłem dostępnym przez widok, interfejs API lub replikację.

Typowy przykład to cennik utrzymywany w bazie systemu sprzedażowego i kopiowany co noc do bazy magazynowej oraz do hurtowni. Jeśli w pierwszej fali do Azure trafi tylko baza magazynowa, nocne zadanie przestanie działać, bo nie zobaczy już bazy docelowej pod dotychczasową nazwą. Magazyn będzie pracował na coraz starszych cenach, a różnicę ktoś zauważy dopiero przy rozliczeniu.

Z tej analizy wynika kolejność fal. Bazy powiązane silnymi zależnościami migrują razem, a źródła danych referencyjnych na początku albo z zachowaniem synchronizacji w obie strony na czas przejściowy.

Krok 4. Aplikacja, która „tylko czyta”

Na liście zależności zawsze są systemy opisane jako mało istotne, bo „tylko czytają” dane: raporty, arkusze z połączeniem ODBC, narzędzia analityczne, integracje partnerów. Właśnie one najczęściej przestają działać po migracji, bo nikt nie uwzględnił ich w testach. Typowe przyczyny to:

• adres serwera wpisany na stałe w pliku konfiguracyjnym, arkuszu lub raporcie,
• uwierzytelnianie Windows, które w Azure SQL Database trzeba zastąpić kontami Microsoft Entra ID lub loginami SQL,
• dostęp sieciowy: zapora, prywatny punkt końcowy, trasa z biura lub od partnera,
• starsze sterowniki, które nie obsługują wymaganej wersji protokołu TLS,
• większe opóźnienie sieci, przez które raport wykonujący tysiące drobnych zapytań działa wielokrotnie dłużej niż w serwerowni.

Każdy taki odbiorca danych dostaje w planie testów osobny scenariusz i właściciela, który potwierdzi wynik. Sprawdzenie, czy połączenie się udaje, nie wystarczy. Potrzebny jest test na rzeczywistym zestawie danych i z pomiarem czasu wykonania.

Problem opóźnień dotyczy też samych aplikacji, jeśli w pierwszej fali do chmury trafia baza, a serwer aplikacji zostaje w serwerowni. Aplikacja, która przy jednym kliknięciu użytkownika wykonuje setki zapytań, będzie odczuwalnie wolniejsza nawet przy dobrym łączu. Dlatego bazę i jej główną aplikację planujemy w tej samej fali albo przynajmniej mierzymy wpływ opóźnienia na kopii przed decyzją.

Krok 5. Fale migracji i próba

Migrację dzielimy na fale, zaczynając od baz o niskim ryzyku i dobrze znanych zależnościach. Pierwsza fala służy sprawdzeniu procesu: sieci, uprawnień, monitoringu, kopii zapasowych i komunikacji z użytkownikami. Kolejne fale korzystają z tych doświadczeń. W każdej fali obowiązuje ta sama kolejność:

1. próba migracji na kopii produkcyjnej z pomiarem czasu przeniesienia danych,
2. testy funkcjonalne i wydajnościowe z udziałem właścicieli aplikacji,
3. wybór metody: migracja offline z kopii zapasowej albo migracja online z bieżącą synchronizacją, gdy dopuszczalne okno przestoju jest krótkie,
4. ustalenie kryteriów powrotu i sposobu przełączenia aplikacji z powrotem na źródło,
5. przełączenie produkcyjne i okres wzmożonego monitoringu.

Przy migracji online do Managed Instance można skorzystać z mechanizmów takich jak link Managed Instance albo usługa Log Replay, które utrzymują synchronizację aż do chwili przełączenia. Dla Azure SQL Database wybór metod migracji online jest węższy, co warto uwzględnić już przy wyborze usługi docelowej.

Po każdym przełączeniu następuje okres wzmożonej opieki, zwykle od kilku dni do dwóch tygodni. Zespół porównuje czasy zapytań z danymi zebranymi przed migracją, obserwuje błędy połączeń i zbiera zgłoszenia użytkowników w jednym miejscu. Środowisko źródłowe pozostaje w tym czasie dostępne w trybie tylko do odczytu, żeby można było szybko sprawdzić, jak dane wyglądały przed przeniesieniem.

Zanim padnie decyzja o lift-and-shift

Przeniesienie wszystkiego na maszyny wirtualne bywa rozsądnym pierwszym krokiem, gdy termin wyznacza koniec umowy na serwerownię albo koniec wsparcia dla starszej wersji SQL Server. Tę decyzję warto jednak podjąć na podstawie oceny, a nie zamiast niej. Jeśli ocena pokazuje, że większość baz może przejść do usług zarządzanych bez dużych zmian, lift-and-shift oznacza płacenie za utrzymanie, którego można było uniknąć.

Porównanie wariantów warto oprzeć na pełnym koszcie posiadania w perspektywie kilku lat: licencjach, mocy obliczeniowej, magazynie, kopiach zapasowych, wysokiej dostępności i pracy zespołu. Maszyna wirtualna często wygląda taniej w cenniku, dopóki nie doliczy się kosztu aktualizacji systemu, konfiguracji klastra i dyżurów, które w usłudze zarządzanej są wliczone w cenę.

• Usługa docelowa wybrana dla każdej bazy, z krótkim uzasadnieniem
• Raport kompatybilności uzupełniony o zadania, pakiety i serwery połączone
• Mapa danych referencyjnych i zależności między bazami
• Lista odbiorców danych „tylko do odczytu” z właścicielami testów
• Kolejność fal i wyniki próby na kopii produkcyjnej
• Kryteria powrotu uzgodnione przed pierwszym przełączeniem

Planujecie przeniesienie baz do Azure SQL?

Przygotujemy ocenę kompatybilności, mapę zależności i kolejność fal, zanim harmonogram trafi do budżetu.

Porozmawiaj z ekspertem