Migracja lokalnego środowiska Microsoft SQL Server do środowiska chmurowego

Dlaczego do chmury? – czyli parę słów wstępu

Żyjemy w czasie postępującej przemiany w sferze IT, znacząca ilość firm przenosi istniejące lub tworzy nowe systemy informatyczne w środowiskach chmurowych. W wielu przypadkach krytycznym czynnikiem dla poprawnego działania systemu jest odpowiedni dostęp do danych. Dzięki rozwiązaniom chmurowym możemy zapewnić dowolny poziom wysokiej dostępności oraz wymaganą wydajność dla wybranej części lub całości systemu. Jednym z najstarszych i ciągle używanych rozwiązań w sferze relacyjnych baz danych jest Microsoft SQL Server, według danych dostępnych na stronie db-enginges SQL Server jest obecnie w TOP 3 najbardziej popularnych silników baz danych. To właśnie o migracji MS SQL Server do chmury chciałbym dziś opowiedzieć.

Jeśli do chmury to do której? – czyli najlepsze miejsce dla Microsoft SQL Servera.

Naturalnym i bardzo trafnym kierunkiem przy migracji SQL Servera jest Azure, czyli usługa chmurowa firmy Microsoft. Chmura od Microsoft daje nam bardzo duże możliwości w zakresie wyboru usługi docelowej podczas procesu migracji. Tak jak w innych platformach chmurowych migrować możemy na platformę IaaS. Jednak na Azure migracja SQL Servera możliwa jest także na kilka dedykowanych usług PaaS, każda z nich posiada swoje zalety oraz indywidualny zbiór funkcjonalności.

Dodatkowo na Azure znajdziemy szereg narzędzi ułatwiających nam wybór odpowiedniej usługi docelowej oraz usługi pozwalające minimalizację narzutu administracyjnego podczas migracje SQL Servera do chmury.

Azure kusi nas nie tylko dużymi możliwościami technicznymi, ale też bardzo ciekawymi aspektami finansowymi. Migracja SQL Server na Azure pozwala zaoszczędzić fundusze w stosunku do innych usługodawców chmurowych czy nawet środowiska On-Premise.

„Save up to 88% vs. AWS Relational Database Service (RDS)”

Źródło – https://cutt.ly/blbDoch

Źródło – https://cutt.ly/ylbDd3j

Jeśli rozpatrujemy migracje SQL Server na Azure, dostajemy od Microsoft 3 główne możliwości. Dwie z tych usług znajdują się w modelu Platform as a Service (PaaS), a jedna w modelu Infrastructure as a Service (IaaS).

Źródło – https://cutt.ly/plbDjQv

Rozwiązaniem najbliższym do SQL Servera znanego z On-Premise jest model IaaS (SQL Server on Azure VM). Polega on na użyciu najbardziej natywnych rozwiązań dostępnych w chmurze Azure i skonfigurowaniu większości komponentów własnoręcznie. Kluczowymi komponentami, którymi musimy, zarządzać są sieć wirtualna, wysoka dostępność, dyski (oraz ich backupy), administracja maszynami wirtualnymi oraz ich systemem operacyjnym i na końcu administracja całą baza danych, jaką jest Microsoft SQL Server. Podejście takie jest najłatwiejszym podejściem jeśli chcemy zastosować tzw. migrację „lift and shift”. W porównaniu z wersjami PaaS zrzekamy się wielu plusów chmury, ale zyskujemy pełną zgodność z on-premisową wersją Microsoft SQL Server. Zgodność ta jest bardzo istotna, jeśli przy migracji nie chcemy wprowadzać żadnych zmian w bazach lub w naszym obecnym systemie wykorzystujemy np. niestandardowe dodatki.

Jeśli chodzi o samo rozwiązanie, opiera się ono na przygotowaniu środowiska, na którym stworzymy maszynę wirtualną, na której zainstalowany jest SQL Server, cały proces instalacji możemy przeprowadzić własnoręcznie lub skorzystać gotowych obrazów maszyn wirtualnych przygotowanych przez zespół Microsoft. Dużym plusem stworzenia takich maszyn na Azure jest korzystanie z błogosławieństw chmury, jakimi są między innymi szybkość tworzenia nowych środowisk, nieograniczone zasoby chmury czy szerokie możliwości zapewnienia wysokiej dostępności dla naszych serwerów.

Bardzo istotną sprawą przy wyborze modelu IaaS jest rezerwacja zasobów oraz program Hybrid Benefits. Rezerwacja zasobów pozwala na znaczące zmniejszenie miesięczny kosztów ponoszonych przez klienta Azure, przy czym nadal niewymagane są jakiekolwiek płatności „z góry”. Hybrid Benefits pozwala natomiast „przynieść” licencje zakupionej na środowiska On-Premise do chmury! Dzięki czemu potrafi znacząco zmniejszyć miesięczny koszt utrzymania środowiska.

Źródło – https://cutt.ly/albDQTy

W modelu PaaS Azure może zaproponować dwa rozwiązania Azure SQL Database oraz Managed Instance.

Moim zdaniem usługę Azure SQL Database można określić jako prawie idealny system baz danych w modelu PaaS. Azure SQL pozwala nam na stworzenie wielu baz danych zgodnych z T-SQL. Jeśli chodzi o wysoką dostępność zależnie od wybranej specyfikacji nasza baza, może posiadać nawet 99.995% SLA oraz być globalnie replikowana pomiędzy regionami. Azure SQL cechuje się minimalnym narzutem administracyjnym, usługa ta określana jest jako „fully managed and always up to date”.

Microsoft troszczy się o to by nasza baza, była zawsze zaktualizowana do najnowszej wersji dodatkowo, zapewnia on też narzędzia do łatwego poprawiania wydajności bazy oraz do konfiguracji wysokiej dostępności czy automatyzacji backupów.

Zmniejszenie narzutu administracyjnego niestety wiąże się też ze zmniejszonymi możliwościami w zarządzaniu bazą. Należy także zaznaczyć to, że Azure SQL Database nie jest także w pełni kompatybilna z on-premisową wersją, brakuje niektórych funkcjonalności czy wszystkich możliwości autentykacji.

Domyślnie każde wystąpienie Azure SQL Database rozliczanie jest miesięcznie w wybranym modelu finansowania. Główne dwa modele to znane z on-premise licencjonowanie per core oraz model dostępny tylko na Azure Database Transaction Units (DTU). DTU polega na aprowizowaniu jednostek DTU będących połączeniem mocy CPU, ilości dostępnej pamięci RAM oraz przepływów dyskowych.

Dodatkowo warto dodać kilka słów o usłudze, jaką jest Elastic Pools. Usługa ta pozwala na łączenie pojedynczych baz danych w pule, w których współdzielą one dostępne zasoby. Rozwiązanie to jest idealnie, jeśli posiadamy bazy danych posiadające różne i nieprzewidywalne obciążenia.

Źródło – https://cutt.ly/IlbDIO2

Drugą usługą PaaS dostępną w Azure jest Managed Instance, usługa ta jest bardzo zbliżona w swojej budowie do SQL Servera w wersji IaaS. Przy tworzeniu wystąpienia zarządzanego musimy stworzyć konkretną sieć oraz podsieci, tworzymy jeden server, na którym możemy tworzyć wiele baz danych i to za server ponosimy opłaty. Znika możliwość zastosowania DTU, jedynym modelem płatności zostają rdzenie. Usługę Managed Instance powołać możemy w dwóch wersjach General Purpose oraz Business Critical, porównać je możemy do znanych z Microsoft SQL Server wersji Standard oraz Enterprise (dokładne porównanie znaleźć można pod tym linkiem).

Jako, że zarządzamy pełną siecią wirtualną, musimy też myśleć o sposobie dostępu do bazy. Możemy zastosować połączenia VPN (P2S,S2S) czy ExpressRoute lub wystawić naszą bazę na publiczny Internet tworząc w sieci public endpoint.

Managed Instance jako usługa PaaS zapewnia nam wiele ułatwiających życie funkcjonalności takich jak:

• zautomatyzowane backupy (w tym backupy PITR),
• automatyczne update,
• łatwość skalowania,
• zarządzanie bezpieczeństwem danych,
• użycie Elastic Pools (w wersji public preview).

Managed Instance jest usługą będąca gdzieś pomiędzy klasycznym PaaS-owym rozwiązaniem Azure SQL Database a pełnym SQL Serverem na maszynach wirtualnych. Pozwala na prawie 100% zgodność z Microsoft SQL Server, nadal minimalizując narzut administracyjny jako usługa PaaS (między innymi nie musimy zajmować się administracją systemem operacyjnym).

Źródło – https://cutt.ly/PlbDSdU

Która usługa jest dla mnie? – czyli o tym, jak znaleźć odpowiednie rozwiązanie.

Po zapoznaniu się z dostępnymi usługami docelowymi należy ocenić która z nich jest dla nas najbardziej trafna. Tutaj wziąć pod uwagę trzeba kilka czynników i odpowiedzieć sobie na kilka pytań. Między innymi musimy znać odpowiedź na poniższe pytania:

• Czy chcemy oraz, czy możemy wprowadzić zmiany w migrowanej bazie danych?
• Jak dużo pracy możemy włożyć w zmiany potrzebne przy migracji bazy?
• Czy możemy wprowadzić zmiany w autentykacji aplikacji/użytkowników do bazy?
• Jak bardzo zależy nam na minimalizacji narzutu administracyjnego po przejściu do chmury?
• Jakie mamy wymagania co do wysokiej dostępności (HA&DR) i backupów oraz czy chcemy sami nimi zarządzać?
• Czy potrzebujemy wszystkich funkcjonalności dostępnych w On-Premise SQL Server?

Oprócz powyższych pytań moim zdaniem proponuje wykonać assesment dostępny dzięki aplikacji Data Migration Assistant (DMA). DMA jest aplikacją stworzoną przez Microsoft, która pozwoli nam ocenić, to jak nasza baza przygotowana jest do migracji na konkretną usługę. Po zainstalowaniu aplikacji na naszym serwerze możemy jako źródło migracji wybrać konkretną bazę, do której mamy dostęp i określić usługę, do której chcemy się migrować. DMA wykona szereg testów, które jako wynik przedstawią nam możliwe komplikacje przy migracji do wybranej usługi.

Żeby łatwiej było zrozumieć proces pracy DMA, rozważmy taki przykład. Posiadamy instancje MS SQL Server na której zainstalowane są dwie bazy DB1 oraz DB2. W bazie DB1 posiadamy funkcje lub widoki które odwołują się do bazy DB2, co jest normalnym rozwiązaniem w świecie SQL Server tzw. Cross-Database query. Chcemy migrować obydwie bazy do usługi Azure SQL, wykonujemy assesment dostępny dzięki DMA i jako wynik dostaniemy informację, że Azure SQL niestety nie wspiera Cross-Database query. W tej sytuacji możemy migrować nasze bazy np. na Managed Instance gdzie Cross-Database query, jest jak najbardziej obsługiwane.

DMA pozwala na znalezienie o wiele bardziej zawiłych problemów i warto je stosować jako weryfikację naszych pomysłów migracyjnych. Dodatkowo DMA pozwala nam na automatyczną migrację pojedynczych baz z On-Premise do usługi Azure SQL Database.

Przed każdą migracją należy sprawdzić, czy zbiór funkcjonalności wybranej usługi docelowej pokrywa się z obecnie wykorzystywanymi funkcjonalnościami w świecie On-Premise.

Warto również zauważyć, że szczególnie w usługach PaaS istnieją ograniczenia w zakresie rozwiązań SSRS,SSAS oraz SSIS. Większość z tych rozwiązań jest dostępna jako usługi dodatkowe (kolejne usługi chmurowe) jednak są one dodatkowo płatne oraz wymagają dodatkowego wysiłku przy migracji.

No dobrze, ale jak to wszystko zmigrować? – czyli o tym, jak Microsoft próbuje nam ułatwić życie.

Żadna migracja nie ma prawa się udać bez dwóch elementów bazy źródłowej oraz bazy docelowej. Naturalnie bazę źródłową posiadamy oraz jej specyfikację znamy, co jednak z usługą docelową? Jeśli nasza firma posiada już jakieś usługi na Azure to na pewno, posiada też jakieś Azure Active Directory (AAD). AAD jest odpowiednikiem znanego z on-premise Active Directory, czyli usługi odpowiadającej za zarządzanie tożsamością w organizacji. Gdy uzyskamy już dostęp do AAD czyli jesteśmy w stanie potwierdzić, że my to my potrzebujemy subskrypcji Azure. Subskrypcja pozwala nam na tworzenie nowych usług, zarządzanie kosztami oraz jest formą określającą zakres usług, za który będzie co miesiąc płacili. Teraz zależnie od sposobu migracji tworzymy usługę docelową lub usługę Azure Migrate – pozwoli ona nam na łatwą migrację z źródłowej bazy danych. Podsumowując mamy konto w AAD, posiadamy też subskrypcje – możemy zająć się już migracją.

Wyżej pisałem o DMA, aplikacja ta nazywana jest mniejszym bratem usługi Database Migration Services (DMS). To właśnie DMS jest częścią Azure Migrate oraz docelową usługą rekomendowaną przez Microsoft do migracji wszelkiego rodzaju workload-u bazodanowego. DMS pozwala na migrację baz z on-premisowego SQL Servera ale także na migrację z innych silników baz danych np. z Oracle. W większości przypadków DMS może migrować nasze bazy w dwóch trybach Online oraz Offline, dzięki takim możliwościom możemy doprowadzić do migracji „nearly zero downtime„.

W mojej opinii DMS ma także bardzo dużą zaletę w postaci możliwości pracy hybrydowej. Domyślnie DMS jest powoływany jako usługa w chmurze, która łączy się ze środowiskiem źródłowym. Jednak dla dużych firm mocno dbających o swoje bezpieczeństwo bardzo często spotykam się z sytuacją gdzie źródłowe bazy danych, są odizolowane od przychodzącego ruchu z Internetu. W tym momencie wkracza usługa DMS w wersji hybrydowej pozwala ona na instalacji punktu przejściowego w naszej sieci on-premise, który łączy naszą źródłową bazę danych z usługą DMS w chmurze.

Źródło – https://cutt.ly/vlbDJqp

Oprócz DMS istnieją też inne sposoby migracji. Możemy użyć prostych rozwiązań jak backup źródłowej bazy danych do Azure Blob Storage oraz restore na docelowej usłudze. Jako kolejne przykładowe proste rozwiązanie przy migracji na SQL Server on VM możemy użyć backupu dysków z naszego obecnego datacenter i w ten sposób próbować odtworzyć pełny SQL Server na maszynie. Dodatkowo użyć możemy replikacji transakcyjnej gdzie jako cel ustalimy np. Managed Instance.

Wartym zauważenia jest także fakt, że czasami potrzeba w 100% bezprzestojowej migracji bazy do chmury. Taką usługę gwarantują rozwiązania Real-Time Data Repliaction jak HVR. Pozwalają one na migracje danych praktycznie bez narzutu generowanego na bazie źródłowej czytając logi bazy bezpośrednio z dysku. HVR możemy hostować na wiele sposobów jednak ciekawą informacją jest to że jest on dostępny jako oficjalna usługa na Azure Marketplace.

Źródło – https://cutt.ly/rlbD1tp

Fajnym dodatkiem wartym zauważenia jeśli nasze bazy danych ssą na prawdę duże jest Azure Data Box. Usługa ta pozwala nam na umówienie z Microsoft konkretnej daty w której za pomocą firmy kurierskiej Microsoft przyśle nam skrzynkę z dyskami na które przegrać możemy swoje dane (Max 1 PB danych), następnie dane te zostaną przewiezione do centrum danych zarządzanego przez Microsoft i po pewnym czasie dane te dostępne będą dla nas w chmurze.

Podsumowanie

Jeśli mógłbym podsumować powyższy tekst jednym zdaniem to byłoby to:

Każda migracja wymaga indywidualnego wielowymiarowego rozważenia.

Przy każdej migracji należy przemyśleć, na jakich zaletach chmury nam najbardziej zależy. Czy jest to łatwa, prosta i szybka migracja (lift and shift), czy może jednak wolimy włożyć więcej pracy w migracje bazy, by później cieszyć się minimalnym narzutem administracyjnym?

Mam nadzieję, że artykuł ten pomógł czytelnikowi zrozumieć zagadnienie migracji bazy Microsoft SQL Server na platformę Azure i przekonał go, że warto taką migrację wykonać.

Jeśli po przeczytaniu tego tekstu jesteście Państwo zainteresowani taką migracją bądź uważacie Państwo, że warto by było skonsultować Wasze pomysły, zapraszam do kontaktu.