SQL Server w Azure

SQL Server w Azure obejmuje warianty od maszyn wirtualnych po w pełni zarządzaną usługę Azure SQL Database.

SQL Server w Azure: trzy modele uruchomienia

Określenie „SQL Server w Azure” obejmuje kilka odmiennych sposobów korzystania z silnika bazodanowego Microsoftu. W przypadku Azure Virtual Machines instalowany jest klasyczny SQL Server działający w systemie Windows Server albo Linux na maszynie wirtualnej. Administrator zachowuje wtedy szeroką kontrolę nad systemem operacyjnym, konfiguracją instancji, plikami baz danych, agentem SQL Server, harmonogramami zadań oraz dodatkowymi składnikami. Microsoft udostępnia obrazy maszyn z licencją SQL Server albo warianty, w których używana jest własna licencja zgodna z warunkami licencjonowania.

Azure SQL Database jest usługą relacyjnej bazy danych zarządzaną przez platformę Azure. Użytkownik nie administruje systemem operacyjnym ani fizycznym serwerem, a Microsoft odpowiada za znaczną część utrzymania infrastruktury, aktualizacji i mechanizmów wysokiej dostępności. Azure SQL Managed Instance stanowi osobny model zarządzany, którego interfejs i zakres zgodności są bliższe pełnej instancji SQL Server niż pojedynczej bazie w Azure SQL Database. Wybór modelu wpływa między innymi na dostępne funkcje, sposób migracji, poziom kontroli administracyjnej i strukturę kosztów.

Azure Virtual Machines z instancją SQL Server

Maszyna wirtualna z SQL Server jest właściwym rozwiązaniem wtedy, gdy aplikacja wymaga zachowania zachowania pełnej instancji, określonych ustawień systemu albo dostępu do funkcji niedostępnych w usługach bazodanowych zarządzanych. Można konfigurować między innymi lokalizację plików danych i dziennika transakcji, ustawienia pamięci, maksymalną liczbę stopni równoległości, poziom kompatybilności bazy oraz zadania SQL Server Agent. Konfiguracja dysków Azure powinna uwzględniać osobno obciążenie odczytu i zapisu danych, dziennika transakcji oraz plików tymczasowych tempdb.

SQL Server na Azure VM nadal wymaga czynności administracyjnych typowych dla instalacji lokalnej. Należy planować aktualizacje silnika i systemu operacyjnego, monitorować wolne miejsce, opóźnienia operacji wejścia-wyjścia, wykorzystanie pamięci i procesora, stan kopii zapasowych oraz błędy zapisane w dzienniku SQL Server. Dostęp sieciowy można ograniczać regułami sieciowej grupy zabezpieczeń, zaporą systemu Windows lub Linux oraz ustawieniami samego SQL Server. Do połączeń aplikacji należy używać szyfrowania zgodnego z konfiguracją instancji, a dane uwierzytelniające powinny być przechowywane poza kodem aplikacji.

Azure SQL Database i Managed Instance

Azure SQL Database udostępnia bazę jako usługę bez konieczności zarządzania maszyną wirtualną. W modelu pojedynczej bazy zasoby są przypisane do określonej bazy, natomiast w modelu elastic pool wiele baz korzysta ze wspólnej puli zasobów. Wydajność zależy od wybranego modelu zakupowego i poziomu usług, między innymi liczby jednostek DTU albo parametrów vCore, limitów pamięci, przepustowości i liczby operacji wejścia-wyjścia. Azure SQL Database obsługuje język T-SQL, ale nie jest pełną kopią instancji SQL Server: część funkcji instancji, poleceń administracyjnych i zależności systemowych może wymagać zmiany podczas migracji.

Azure SQL Managed Instance udostępnia środowisko bardziej zbliżone do instancji SQL Server i może obsługiwać wiele baz w ramach jednego zarządzanego wystąpienia. Jest przeznaczone między innymi do migracji aplikacji, które korzystają z funkcji instancyjnych, takich jak bazy systemowe, SQL Server Agent lub połączenia między bazami, z zastrzeżeniem aktualnie obsługiwanego zakresu funkcji. Zarówno Azure SQL Database, jak i Managed Instance oferują automatyzowane mechanizmy kopii zapasowych i odtwarzania do punktu w czasie, lecz szczegóły retencji, limitów i dostępnych poziomów usług zależą od konkretnej oferty Azure.

Migracja, połączenia i diagnostyka SQL Server w Azure

Przenoszenie bazy do Azure powinno rozpocząć się od inwentaryzacji wersji SQL Server, poziomu kompatybilności, rozmiaru baz, obciążenia procesora i pamięci, wzorca operacji wejścia-wyjścia oraz zależności aplikacji. Narzędzia Microsoft, takie jak Data Migration Assistant, mogą wykrywać problemy ze zgodnością przed migracją, ale wynik analizy trzeba zweryfikować w środowisku testowym. Należy sprawdzić między innymi zadania SQL Server Agent, logowania, uprawnienia, linked servers, procedury składowane, rozszerzenia oraz połączenia aplikacji zapisane w konfiguracji.

Diagnostyka obejmuje warstwę aplikacji, sieci i samego silnika. Przydatne są metryki Azure Monitor, dzienniki diagnostyczne, widoki dynamicznego zarządzania SQL Server oraz analiza planów wykonania zapytań. Warto rozróżniać opóźnienie wynikające z blokad, braków indeksów, niewystarczających zasobów, ograniczeń przepustowości dysków i błędów uwierzytelniania. W Azure SQL Database i Managed Instance trzeba dodatkowo kontrolować limity wybranego poziomu usług oraz stan połączeń sieciowych, a w SQL Server na Azure VM także zdrowie systemu operacyjnego, dysków i usług uruchomionych na maszynie. Przed zmianą konfiguracji należy potwierdzić działanie kopii zapasowej i możliwość odtworzenia bazy.